path: root/local/bugs.log

# BUGS.V29 -- Known bugs in the frozen IRAF Version 2.9 (and previous
# versions).   Started 15JUN90.
#
# Record Format:
#
#	NUMBER:		record number, decimal, sequential.
#	MODULE:		package.task or library.procedure or 'unknown' or ...
#	SYSTEM:		versions of iraf in which bug was present
#	DATE:		date bug logged, unix format date string
#	FROM:		user login name
#	BUG:		description of the bug
#	STATUS:		'fixed in V2.X', 'unresolved', etc.
#
# New records are added to the tail of the bugfile.  Left justify field labels,
# indent text to the first tab stop, one blank line between bug entries.
# ----------------------------------------------------------------------------

NUMBER:	120
MODULE:	apphot.daofind
SYSTEM:	V2.8
DATE:	Fri Mar 30 08:02:12 MST 1990
FROM:	davis

BUG:	In rare circumstances daofind may abort with a "pixel file truncation
        error" when trying to read back the convolved images it has just 
	written. This only occurs on certain sized images and is due to
	the interaction of the read, write and boundary extension in image
	i/o. For example daofind works fine on a 640 by 1024 image but fails on
	one that is 641 by 1025 pixels.

STATUS:	The problem is fixed in 2.9. The solution was to add an imflush
	statement to flush the image i/o buffers after the write was
	complete and before initiating the read. There is no workaround.
	Contact the IRAF group for a fix.

NUMBER:	121
MODULE:	utilities.curfit
SYSTEM:	V2.9
DATE:	Mon May 21 15:12:40 MST 1990
FROM:	sjacoby

BUG:	The errors in the coefficients reported by CURFIT are incorrect when
	points have been rejected from the sample by the iterative rejection
	algorithm.  User deleted points are handled properly, but points 
	automatically rejected by sigma criteria are being incorrectly 
	included in the coefficient error calculation.

STATUS:	The bug is fixed in V2.10.  There is no workaround, unless the user
	can identify and delete by hand those points the algorithm would reject.

NUMBER:	122
MODULE:	cl
SYSTEM:	V2.9 DECstation/IRAF
DATE:	Wed May 23 20:58:47 MST 1990
FROM:	tody

BUG:	If IRAFARCH is not defined in the user environment, an attempt
	to run the CL in DECstation/IRAF will fail with the message
	"... /bin.f68881/cl.e not found".  This is caused by a malformed
	if-else (missing else) on line 41 of hlib$cl.csh.

STATUS:	A simple workaround is to define "setenv IRAFARCH mips" in the
	user environment before starting the CL.  This bug is so easy to
	fix however, that a permanent fix is probably the best approach.
	Merely edit the file iraf/unix/hlib/cl.csh and change the "if" on
	line 41 to "else if".

NUMBER:	123
MODULE:	imtranspose
SYSTEM:	V2.9
DATE:	Wed Jun  6 08:37:42 MST 1990
FROM:	davis

BUG:	Imtranspose fails with an "unknown pixel type error" on image of
	type ushort.

STATUS:	The bug has been fixed in 2.10. There is no workaround except to
	change the pixel type of the image to int or long.

NUMBER:	124
MODULE:	proto.imedit
SYSTEM:	V2.9, V2.8
DATE:	Wed Jun  6 09:22:54 MST 1990
FROM:	valdes

BUG:	The fixpix format input interpolates across the longer dimension
	rather than the shorter dimension.  If the region is a complete
	column/line then no correction is made.

STATUS:	Now fixed.  For square or nearly square regions the interpolation
	across the longer dimension is probably adequate.  Other workarounds
	are to use FIXPIX itself or convert the fixpix format file to regular
	cursor input to imedit (which then also allows use of any of the other
	options).

NUMBER:	125
MODULE:	apextract.apscatter
SYSTEM:	V2.9
DATE:	Mon Jun 11 17:35:22 MST 1990
FROM:	valdes

BUG:	When specifying a "line" to be plotted a check is made against the
	wrong image axis; i.e. if a line is specified then it forced to
	be in the range 1 to the number of image columns and vice-versa
	for the other axis.

STATUS:	This has been fixed.  There is no workaround but the task will
	still function correctly even though it is not possible to examine
	some image lines or columns.  The effect becomes obvious only in
	significantly nonsquare images.

NUMBER:	126
MODULE:	apphot package 
SYSTEM:	V2.9
DATE:	Wed Jun 27 16:47:34 MST 1990
FROM:	davis

BUG:	Due to fractional pixel effects the sky fitting routines in apphot
	can fail to preallocate enough space to hold the sky pixels, resulting
	in a memory corruption error or a segmentation violation on exit
	from a task. This condition occurs rarely most often when the sky
	fitting annulus is very narrow. All the apphot tasks which do
	sky fitting are affected.

STATUS:	The bug is fixed in 2.10. There is no workaround although increasing
	the width of the sky fitting annulus slightly may bypass the
	problem. Contact the IRAF group for a fix.

NUMBER:	127
MODULE:	artdata.mkobjects
SYSTEM:	V2.9
DATE:	Mon Jul  2 11:41:14 MST 1990
FROM:	valdes

BUG:	Objects which fall partially off the lower edges of the image
	(objects with centers near the (1,1) image origin) are shifted
	by 1 pixel to larger coordinates.

STATUS:	This bug is caused by incorrect rounding of negative numbers.  The
	bug has been fixed.  The workarounds are to either compensate
	for the error in the analysis or offset the coordinates to
	larger values (say by using the offset parameters) and make a
	larger image which can then be trimmed with IMCOPY.  The tricky
	thing is knowing when the objects go off the edge since the
	full object size depends on seeing and the specified dynamic range.

NUMBER:	128
MODULE:	IMFORT
SYSTEM:	V2.9
DATE:	Tue Jul 10 10:33:02 MST 1990
FROM:	tody

BUG:	In IRAF V2.9, IMFORT has a bug which prevents access to images not
	in the current working directory.  If one tries to access an image
	using a pathname an error message such as "image not found (.imh)"
	is seen.

STATUS:	The workaround is to CD (SET DEF) to the directory before accessing
	the image.  A patch (patch #2) is available in the IRAF network
	archive which can be installed to fix the bug.  Installation
	instructions are given in the README files for each supported
	architecture (SOS4, VMS5, etc.).

NUMBER:	129
MODULE:	onedspec.splot, onedspec.calibrate
SYSTEM:	V2.9
DATE:	Tue Jul 10 17:07:46 MST 1990
FROM:	valdes

BUG:	In SPLOT the first pixel is ignored.  In CALIBRATE the wavelength
	scale for extinction correction will be in error by one pixels.

STATUS:	These two bugs are related because the header parameter NP1,
	which is the offset to the first valid pixel, should be zero in
	most cases but a bug fix in Nov. 1989 put in a minimum value of 1.
	The symptom in SPLOT is to lose the first pixel but the
	wavelength scale is correctly compensated.  In CALIBRATE the
	wavelength scale is not compensated though the error should be
	extremely small since the calibrations are interpolations from
	a smooth curve.  There is no easy work around for SPLOT.  If
	the one pixel wavelength error in CALIBRATE is a concern one
	could reset the wavelength zero point parameter W0 or CRVAL1 to
	be greater by WPC or CDELT1; i.e. make the starting wavelength
	parameter refer to pixel 2.  Note that this will make the
	wavelengths wrong for SPLOT and other ONEDSPEC tasks.  This bug
	is corrected in V2.10.

NUMBER:	130
MODULE:	artdata.mkobjects
SYSTEM:	V2.9
DATE:	Thu Jul 19 15:14:14 MST 1990
FROM:	valdes

BUG:	The radius parameter for the "gaussian" model PSF is being used as
	a full width instead of a radius as intended and described in the
	documentation.  The effect is to give narrower stars than expected.

STATUS:	The workaround is to give a FWHM for the gaussian model instead of
	a radius at half maximum.

NUMBER:	131
MODULE:	artdata.mkobjects
SYSTEM:	V2.9
DATE:	Mon Jul 23 10:53:43 MST 1990
FROM:	valdes

BUG:	The moffat function size scaling (as set by the radius parameter)
	is incorrect.

STATUS: The shape of the function is based on the correct beta but the size
	is scaled for a function with beta of:
	
		beta1 = 2 * beta - 2

	Another way to look at it is that the flux level corresonding to
	the specified radius is different than the half intensity.  The
	actual flux level is:

		F(radius) = 0.5 ** (beta / beta1)

	Finally, the radius which must be specified, rfudge, to get a
	desired radius at half intensity, rhalf, is:

		rfudge = rhalf * sqrt ((2**(1/beta1)-1) / (2**(1/beta)-1))

	Note that there is no error for beta=2, the size is too large
	for beta>2, and the size is too small for beta<2.

	The workaround is to adjust the specified radius for a desired
	radius at half intensity using the above formula.

NUMBER:	132
MODULE:	utilities.curfit
SYSTEM:	V2.9
DATE:	Mon Jul 30 17:37:48 MST 1990
FROM:	davis

BUG:	Curfit was crashing with a segmentation violation when it tried to
	fit the second file of data or second image in a list of images.
	The pointer to the icfit data structure was being freed after
	the first file of data was fit and not reallocated before the
	next fit resulting in a reference to an undefined pointer.

STATUS:	The bug has been fixed in 2.10. There is no workaround except
	to use a script to loop over a large number of input data files.

NUMBER:	133
MODULE:	math$gsurfit/dgsder
SYSTEM:	V2.9
DATE:	Wed Aug  1 16:27:43 MST 1990
FROM:	davis

BUG:	Due to a typographical error in the file math$gsurfit/gsder.gx,
	dgsder (the routine which computes the derivative of a double
	precision surface) was inadvertantly calling salloc with a pointer
	address instead of an array size. If the assigned pointer value
	is very large this can cause an "out of memory error" in any task
	which calls dgsder.

	Currently the only task affected by this bug is TRANSFORM
	in the LONGSLIT package.

STATUS: The bug is fixed in 2.10. There is no workaround. Contact NOAO for
	a fix.

NUMBER:	134
MODULE:	XC (SPP compiler)
SYSTEM:	Sun/IRAF V2.9  (Sun systems only)
DATE:	Wed Aug  8 10:04:34 MST 1990
FROM:	tody

BUG:	Sun/IRAF V2.9 will not work with the SunOS 1.3 or 1.3.1 Fortran
	compiler (which Sun came out with after IRAF was released).  The
	new Sun compiler locates important executables such as f77, cc,
	etc., in a nonstandard place, one of the Fortran libraries has
	been done away with, the command line arguments have changed,
	etc. (in short Sun has completely revamped their compiler).

STATUS: A new version of XC is available from IRAF site support which
	will work with the new compiler.  Note that although this allows
	the compiler to be used, and it appears to be possible to compile
	and link programs, the IRAF V2.9 libraries were compiled with the
	old Sun Fortran compiler and we cannot be certain that these
	libraries are fully compatible with the new compiler and its
	libraries.  Also, the default host compiler flags supplied with
	Sun/IRAF MKPKG are not necessarily what is best for the new
	compiler.  Most likely these are not serious problems, but
	Sun/IRAF will not fully support the new compiler until we have had
	time to recompile the full system for a future release.

NUMBER:	135
MODULE:	noao.artdata.mkobjects
SYSTEM:	V2.9
DATE:	Thu Aug  9 09:24:41 MST 1990
FROM:	valdes

BUG:	The general cumulative profile file input for both the PSF and a
	an object type does not work.  The error is can't open image
	even though the file is not an image.

STATUS:	This bug is due to the inability of the image access checking routine
	to distinguish images from regular files.  Because of the order
	of the logic the task always checks to see if the specified file
	is an image template first, decides it is an image, and then
	fails with the error can't open image.  There is no work around.
	Those requiring this capability wil have to contact site support
	for help.

NUMBER:	136
MODULE:	wfits/rfits
SYSTEM:	V2.9
DATE:	Mon Aug 27 07:37:57 MST 1990
FROM:	davis

BUG:	Wfits sometimes crashed with a segmentation violation when
	files were written with a non-standard block size (block_factor > 10).
	The error was in the code which 0-filled the unused portion of the
	last output block,  and occurred if the unused portion of that
	block was greater than 2880 bytes.

	Rfits sometimes reported read errors when it tried to read tapes
	with a non-standard block size (blocks not a multiple of 2880
	bytes). Rfits was not always counting the number of characters read
	from the tape correctly when the read attempted to cross tape record
	boundaries. Tapes with small block sizes like 512 and 1024 were
	the most affected.

STATUS:	Both bugs have been fixed in version 2.10 and the 2.9.1 patch.

NUMBER:	137
MODULE:	IMDKERN
SYSTEM:	V2.9
DATE:	Thu Sep  6 11:59:44 MST 1990
FROM:	tody

BUG:	There is a bug in the V2.9 version of the IMDKERN graphics kernel
	(used to draw color graphics overlays on the image display) which
	can cause the kernel to die on a segmentation violation when run
	as a connected subkernel.

STATUS:	The workaround is to spool the graphics metacode for the plot in
	a file and then plot this file using the IMDKERN task in PLOT.
	The bug is fixed in the V2.9.1 patch, available from the IRAF
	network archive.

NUMBER:	138
MODULE:	images.convolve
SYSTEM:	V2.9
DATE:	Wed Nov 28 13:38:17 MST 1990
FROM:	davis

BUG:	CONVOLVE was terminating with the error "Kernel rows are different
	lengths" if the user supplied a 1D kernel without the terminating
	delimiter character ';'. For example the valid kernel "1.0 2.0 1.0;"
	would work but the equally valid "1.0 2.0 1.0" would not. 2D kernels
	did not have this problem.

STATUS:	The bug is fixed in IRAF 2.10. The workaround is to always append
	the delimiter character to the kernel.

NUMBER:	139
MODULE:	noao.artdata.mkobjects
SYSTEM:	V2.9-V2.9.1
DATE:	Tue Dec  4 12:00:32 MST 1990
FROM:	valdes

BUG:	Memory associated with the stellar, galaxy, and cosmic ray templates
	is not freed in the tasks MKOBJECTS and MKNOISE.  Repeated executions
	(without flushing the process) eventually overflows the swap
	space or causes out of memory errors.

STATUS:	The bug is caused by a simple typo and has been fixed.  Large amounts
	of memory are tied up only with a large number of repeated calls.
	Normally all objects are created in one step rather than repeated
	calls to add individual objects and so there is generally no
	difficulty.  The work around when using these tasks in a loop
	is to add a "flprcache" call to flush the process after each
	call or set of calls.

NUMBER:	140
MODULE:	dataio.rfits
SYSTEM:	V2.9
DATE:	Thu Dec  6 11:38:42 MST 1990
FROM:	davis

BUG:	A command of the form "rfits mta 1-8 "" oldirafname+" will generate
	the message "ERROR: T_RFITS: Error reading output file name" because
	the code was not dealing properly with an empty output file list.

STATUS:	Rfits has been modified in 2.10 so that a temporary output file
	name is created if oldirafname is true or a clear error message
	is generated if oldirafname is false, and the user has set the
	output file name to "". The workaround is to avoid setting
	the output file name to "".

NUMBER:	141
MODULE:	identify
SYSTEM:	V2.9
DATE:	Wed Dec 19 16:47:06 MST 1990
FROM:	valdes

BUG:	The automatic line identification algorithm fails to find some
	lines in certain circumstances.

	The source of the problem is when multiple lines in the line
	list end up being centered in the same place in the data.  For
	example if two lines in the list are 4888.1234 and 4889.1234,
	the second one is intrinsically weak, and the data is low
	resolution (say 3A per pixel) then as far as the data is
	concerned there is just one line.  This line will be marked
	twice with the same position but different wavelengths.  The
	complication is that valid weaker lines will be removed based
	on the maxfeatures criteria (for example only the 50 highest
	peak values are kept of which say 10 are multiple assignments
	to the same peaks in the data).   Then after the lines are
	found the minsep criteria is applied to winnow out the multiple
	assignments to the same pixel leaving 40 lines found and 10 of
	the weaker valid lines not found.  This is a complex  behavior
	dependent on data resolution, the initial dispersion solution,
	the line list (the problem occurs with dense line lists used
	for high resolution such as the thorium list used with lower
	resolution data), and the maxfeatures and match parameters.

STATUS:	The bug fix is to winnow out the multiple identifications to
	the same pixel before selecting the maxfeatures strongest
	lines.  The workaround most likely to work is to reduce the
	match parameter so that some of the multiple identifications
	are thrown out based on wavelength differences with the
	dispersion function estimates.  Another thing is to increase
	maxfeatures but this will result in many undesired weak lines.


NUMBER:	142
MODULE:	testphot.daophot.psf
SYSTEM:	V2.9
DATE:	Tue Feb  5 16:39:13 MST 1991
FROM:	davis

BUG:	The task psf in testphot.daophot was writing incorrect values of the
	zero point position of the psf "XPSF" and "YPSF" into the psf image
	header. Although this was not a problem for the constant psf fitting
	code, the variable psf fitting code was interpolating in the wrong
	place in the look-up table, resulting in a very strange looking psf
	fit. In effect the coordinate system of the look-up table was shifted
	with respect to the image.

STATUS:	The bug has been fixed in the ftp archive version of testphot and on
	all our local nodes (orion, gemini, ursa). Users can either get a
	new version of testphot from the archive or contact the IRAF group
	for a patch since only one file is affected.

NUMBER:	143
MODULE:	images.imsurfit
SYSTEM:	V2.9
DATE:	Mon Feb 25 10:03:39 MST 1991
FROM:	davis

BUG:	There is a bug in the bad pixel rejection code in the IMSURFIT task
	which occurs when the parameter upper > 0.0 and lower = 0.0, or
	if lower > 0.0 and upper = 0.0. In the former case all points with
	negative residuals were rejected instead of none, and in the latter
	case all points with positive residuals were rejected instead of
	none. IMSURFIT was computing the rejection limits by multiplying
	the computed standard deviation by upper and lower respectively
	without checking for the zero case.

STATUS:	The big is fixed in IRAF 2.10. There is no workaround, except to
	set upper or lower to very large values if you do not want to
	reject pixels.

NUMBER:	144
MODULE:	artdata
SYSTEM:	V2.9.1
DATE:	Mon Mar  4 09:43:28 MST 1991
FROM:	valdes

BUG:	The tasks sometimes fail when the output image is in STF (.hhh) format.
	This is due to a problem in how image header comments are put in
	the image header affecting only the STF format.  Note that the
	original version released with V2.9 does not provide header
	comments and so it does not have a problem.  The newer version with
	this STF header problem came as part of V2.9.1.

STATUS:	This problem has been fixed in the next version of the package.
	The only workaround is to use OIF (.imh) format and then convert
	to STF format with IMCOPY.

NUMBER:	145
MODULE:	apextract
SYSTEM:	V2.9
DATE:	Wed Mar 27 16:57:13 MST 1991
FROM:	valdes

BUG:	For some default background functions and sample regions a singular
	solution error can occur.  This is caused by defining the function
	range to be the entire image dimension while the sample region is
	only a small part of this range.  It probably also depends on the
	function type and order and the degree of curvature in the fitted
	data.  When apertures are read from the database or reset by the
	'b' mode in APEDIT the fitting limits are set to the limits of the
	sample region.

STATUS:	The singular solution message should be harmless.  Reading apertures
	from a database does not have this problem.  Entering the 'b' mode in
	APEDIT (where the message might be seen) and exiting will fix the
	fitting function properly.  Of course if background subtraction
	is not required this problem does not arise.  The problem has
	been fixed for V2.10.

NUMBER:	146
MODULE:	images.geomap
SYSTEM:	V2.9
DATE:	Tue Apr  9 14:08:45 MST 1991
FROM:	davis

BUG:	Geomap would not permit the user to fit cross-terms (terms containing
	x*y) in the the x coordinate fit if xxorder=2 and xyorder=2, or in
	the y coordinate fit if yxorder==2 and yyorder=2. For higher order
	fits cross-term fitting was enabled.

STATUS:	This bug has been fixed in IRAF 2.10. There is no workaround.

NUMBER:	147
MODULE:	ccdred.mkskycor ccdred.mkillumcor
SYSTEM:	V2.9
DATE:	Tue Apr 16 16:42:36 MST 1991
FROM:	valdes

BUG:	The CCDMEAN parameter computed by the task MKSKYCOR and MKILLUMCOR
	is computed incorrectly in the sense that it is smaller than the
	correct value by a small amount.  The last few lines of the image
	were not accumulated before dividing by the number of pixels in
	the output image.

STATUS:	This bug has been fixed for V2.10.  One workaround is to use
	yboxmin of 0.  The other workaround is to use IMSTATISTICS and
	HEDIT to compute and replace the correct value.  Failing to do so
	and then correcting images with CCDPROC will slightly change the
	data level which may be acceptable.

NUMBER:	148
MODULE:	ecdispcor, msdispcor
SYSTEM:	V2.9
DATE:	Mon Apr 22 13:23:09 MST 1991
FROM:	valdes

BUG:	The combining options "sum", "average", "minmax" do not work correctly.
	The cause is failing to clear an array between each spectrum so
	that as subsequent spectra are added the preceding spectra are
	multiply added.

STATUS:	The workaround is to dispcor each order to the same dispersion
	with onedspec output format and then add or average the spectra
	with imcombine.  The problem is fixed for V2.10.

NUMBER:	149
MODULE:	artdata.mkobjects
SYSTEM:	V2.9
DATE:	Mon Jun 10 10:44:47 MST 1991
FROM:	valdes

BUG:	The PSF position angle (parameter pa) is intended to be input
	as degrees and converted  internally to radians.  The conversion is
	not being done with the effect that the input position angle is
	being interpreted as radians.

STATUS:	The conversion has been added to the program; a simple use of
	the DEGTORAD macro.  The workaround is to specify the position
	angle in radians.  Note that the object position angles specified
	in the object list are correctly interpreted as degrees.

NUMBER:	150
MODULE:	dataio.wfits
SYSTEM:	V2.9
DATE:	Tue Jun 11 13:04:44 MST 1991
FROM:	davis

BUG:	Wfits was setting the IRAFNAME image header keyword to a blank
	string if the input image was a section. This was done originally
	to avoid rfits trying to rename the output image (if parameter
	oldirafname = yes) to an image section, but had the side effect
	of making IRAFNAME useless for book-keeping purposes.

STATUS:	Wfits has been modified in 2.10 to write the full image specification
	including the image section but minus the directory specification
	in the IRAFNAME keyword. Rfits has been modified to check for and remove
	any image section before renaming the output image to the orginal
	iraf name. If the renaming fails for any reason, then the name
	specified by the iraf_file parameter will be used as before.

NUMBER:	151
MODULE:	noao.twodspec.longslit.fitcoords
SYSTEM:	V2.6-V2.9
DATE:	Fri Jul 12 08:38:03 MST 1991
FROM:	valdes

BUG:	Fitting a single trace made along the x or horizontal axis
	does not work correctly.

STATUS:	The workaround is to transpose the data and trace the feature
	vertically.  This is corrected in V2.10.

NUMBER:	152
MODULE:	images.imshift
SYSTEM:	V2.9
DATE:	Mon Jul 29 11:42:28 MST 1991
FROM:	davis

BUG:	Imshift was not correctly initializing the shifts file descriptor to
	NULL, when the shifts_file parameter was set to "", sometimes causing
	a later conditional test in the code to fail.

	This bug is triggered when a user sets shifts_file to a file name
	and then sets it back to "" without flushing the process cache,
	as may happen after repeated executions in a script.

STATUS:	The bug has been fixed in 2.10. There is no workaround except to
	flush the process cache between executions.

NUMBER:	153
MODULE:	digiphot.apphot.apselect
SYSTEM:	V2.9
DATE:	Mon Aug 12 15:07:29 MST 1991
FROM:	davis

BUG:	Apselect can sometimes fail with a segmentation violation if the
	input file has variable length records, (as can be the case for
	example if the user changes the number of apertures interactively,
	or if the user has defined polygons of various sizes)
	if the first record is not the longest record in the file,
	and if the size of the variable length record exceeds 20, the
	initial guess for buffer allocation.

STATUS:	The bug has been fixed in 2.10. There is no workaround except to
	ensure that the longest record comes first in the output file.

NUMBER:	154
MODULE:	proto.fixpix
SYSTEM:	V2.9
DATE:	Tue Aug 13 12:27:17 MST 1991
FROM:	valdes

BUG:	Interpolation across columns with type double images does not work.

STATUS:	Fixed in V2.10.  There is no workaround other than to avoid this
	rare combination of datatype and direction of interpolation.

NUMBER:	155
MODULE:	apphot.radprof
SYSTEM:	V2.9
DATE:	Mon Aug 26 11:25:36 MST 1991
FROM:	davis

BUG:	1. Radprof was computing the total intensity of the fitted radial
	profile by integrating (RP) instead of the physically meaningful
	quantity 2 * PI * (r * RP).

	2. The computed total intensity (TINORM)  was too small by a factor
	equal to the profile step size in pixels, although the shape of the
	curve was correct.

STATUS: Both bugs have been fixed in 2.10. Bug 1 was fixed some time ago
	at the request of a user at ST, but was not previously logged.
	There is no workaround. Bug 2 was only recently discovered. 
	The workaround is to multiply the quantity TINORM by the step size
	in pixels, and compare it to the aperture photometry results.
	The two numbers should be equal to within the expected errors.

NUMBER:	156
MODULE:	images.imstatistics
SYSTEM:	V2.9
DATE:	Tue Sep 24 09:17:16 MST 1991
FROM:	davis

BUG:	The mode statistic was not being computed correctly in imstatistics,
	because the parabolic interpolation correction for computing the
	histogram peak was being applied in the wrong direction.

STATUS:	The bug has been fixed in IRAF 2.10 and the help page which uses
	dev$pix as an example has been modified appropriately. There is no
	workaround.

NUMBER:	157
MODULE:	XC compiler
SYSTEM:	V2.9 Sun/IRAF, all versions
DATE:	Wed Oct  9 14:22:11 MST 1991
FROM:	tody

BUG:	XC will not recognize the V1.4 Sun Fortran compiler.  The bug is due
	to XC looking for V1.3 and finding V1.4 instead.

STATUS:	The workaround is to do a "ln -s f77-1.4 f77-1.3" in /usr/lang, or
	wherever the compiler is installed.

NUMBER:	158
MODULE:	dataio.rfits
SYSTEM:	V2.9
DATE:	Wed Oct  9 15:50:36 MST 1991
FROM:	davis

BUG:	IRAF 2.9 rfits was not reading fits files with short last logical
	records correctly, i.e. records not correctly padded out to 2880
	bytes. For each output image line contained or partially contained
	in the final short record, an error message was generated,
	and incorrect data was written to the output image.

STATUS:	The bug has been fixed in 2.10 and was not a problem in IRAF 2.8
	and earlier. The workaround is to use Unix dd command or the IRAF
	reblock task to reformat the file.

NUMBER:	159
MODULE:	images.imstatistics
SYSTEM:	V2.9
DATE:	Fri Oct 11 13:54:19 MST 1991
FROM:	davis

BUG:	The computed value of the kurtosis was 1.0 too small, i.e. a
	Gaussian distribution  would have a computed kurtosis of -1.0
	instead of 0.0.

STATUS:	The bug has been fixed in IRAF 2.10. The workaround is to add
	1.0 to the computed value of the kurtosis.

NUMBER:	160
MODULE:	onedspec.standard
SYSTEM:	V2.9
DATE:	Thu Oct 17 09:22:06 MST 1991
FROM:	valdes

BUG:	If the calibration bandpasses are less than a pixel wide the flux
	summation is incorrectly done when both endpoints are within the
	same pixel; the code assumed that the two endpoint pixels were
	not the same.  Generally the calibration data, in onedstds$, has
	much larger bandpasses than typical spectra and so this bug has
	not be seen except in one reported case where a private calibration
	file with very small bandpasses was used.

STATUS:	Fixed in V2.10.  The workarounds are to revise the calibration
	file to larger bandpasses (if using a private version), resample
	the spectra to smaller dispersion, or, the best choice, specify
	the bandpass widths and separations in the task to override the
	calibration file bandpasses and interpolate the calibration file
	data.

NUMBER:	161
MODULE:	apextract.apsum
SYSTEM:	V2.9
DATE:	Wed Oct 30 11:02:38 MST 1991
FROM:	valdes

BUG:	If the background regions go off the image, due to tilts in the
	spectrum such as with echelle data, while the object apertures
	remains on the image a segmentation violation occurs.  This will
	only happen with one-sided background regions as otherwise this
	condition could not occur.  The error is caused by a failure to
	check for an error condition from background fitting.

STATUS:	This error is fixed in V2.10.  The workaround is to insure
	at least part of the background regions are on the image while the
	object aperture is on the image.  This would be true if background
	regions are defined on both sides of the aperture.  Note that it is
	ok for the object aperture and background regions to both be off
	the the image.  The source fix is simple and could be supplied if
	absolutely necessary.

NUMBER:	162
MODULE:	reidentify
SYSTEM:	V2.9
DATE:	Mon Nov 18 10:27:25 MST 1991
FROM:	valdes

BUG:	If reference features are identified in user coordinates other than
	pixels, usually Angstroms for arc lines, and the user forgets to
	type 'f' to fit a dispersion function, then REIDENTIFY will
	compute a very large coordinate shift and then fail to trace
	any features.

STATUS:	The workaround is to recognize this behavior and then go back and
	do a dispersion function fit for the reference.  The logical bug
	in the task is fixed in V2.10.

NUMBER:	163
MODULE:	artdata.gallist
SYSTEM:	V2.9
DATE:	Tue Nov 26 17:07:03 MST 1991
FROM:	valdes

BUG:	The randomization of the galaxy size distribution when using the
	Schecter luminosity function is incorrect.  Instead of a 20% range
	about the scaled eradius/sradius for a given magnitude a range of
	100% is computed coupled with a reduction of the size by a factor
	of 2.5.

STATUS:	There is no workaround for the increased dispersion but the factor
	of 2.5 in the size can be compensated by adjusting the eradius
	parameter.  This has been fixed in V2.10

NUMBER:	164
MODULE:	artdata.gallist
SYSTEM:	V2.9
DATE:	Tue Nov 26 17:11:37 MST 1991
FROM:	valdes

BUG:	The axial ratios for elliptical galaxies when a mixture of spiral
	elliptical galaxies is computed are incorrect.  In particular
	there will be axial ratio values greater than 1 in the output
	file.

STATUS:	The work around is to compute the elliptical and spiral galaxy
	data separately.  This has been fixed in V2.10.

NUMBER:	165
MODULE:	plot.pvector, proto.imexamine
SYSTEM:	V2.9
DATE:	Wed Dec 11 11:32:36 MST 1991
FROM:	davis

BUG:	Profiles computed and plotted using the pvector task or the 'v'
	key in imexamine occasionally show glitches, where 1-3 pixels
	have bad values. This bug was traced to any error in
	the column limits computed by the code which reads the
	image pixels. As a result the image interpolator was requesting
	values off the ends of the pixel array producing bad output values.

STATUS:	The bug has been fixed in 2.10. There is no workaround.

NUMBER:	166
MODULE:	apphot.polyphot
SYSTEM:	V2.9
DATE:	Tue Feb 25 16:37:41 MST 1992
FROM:	davis

BUG:	The intersection points of an image line and a polygon could be
	incorrectly translated into a list of line segments if the polygon
	was concave and contained one or more sides exactly collinear with
	the image line. The symptom of this problem is a larger than expected
	difference (larger than can be accounted for by fractional pixel
	effects) in the computed area of the polygon as it is shifted
	to different positions in the image (shifting by floating point
	numbers tends to remove the condition of exact collinearity);
	or larger than expected differences in the area and flux
	of the same object measured with the same polygonal aperture
	at slightly different positions in different images (again
	shifting the polygon tends to remove the condition of exact
	collinearity).

STATUS:	The bug has been fixed in 2.10. There is no work around except to
	alter the shape of the polygon slightly.

NUMBER:	167
MODULE:	images.imstatistics
SYSTEM:	V2.9
DATE:	Tue Mar 10 14:58:59 MST 1992
FROM:	davis

BUG:    Precision was being lost unnecessarily in the computation of the
	standard deviation, skew, and kurtosis because two of the
	intermediate variables in the computation were real instead of
	double precision.

STATUS:	The bug is fixed in 2.10. There is no workaround.

NUMBER:	168
MODULE:	noao.twodspec.longslit.fluxcalib
SYSTEM:	V2.9
DATE:	Thu Mar 19 11:27:18 MST 1992
FROM:	valdes

BUG:	Flux calibrating a short pixel type image will produce a short
	pixel type output image which is generall all zeros since the
	typical flux values are of order 10e-14.

STATUS:	The workaround is to convert the images to real (with chpixtype for
	instance) before flux calibrating.  For V2.10 the output image
	will be of type real pixels.

NUMBER:	169
MODULE:	imred.irs.batchred, imred.iids.batchred
SYSTEM:	V2.10
DATE:	Mon Jul  6 10:01:35 MST 1992
FROM:	valdes

BUG:	The PROCESS script generated by BATCHRED included parameters no
	longer part of STANDARD and CALIBRATE.  Running this task produces
	the error

	ir> process
	ERROR on line 9: parameter `recformat' not found
	    process ()
	    process ()

STATUS:	To be fixed in V2.10.0.  The workaround is to edit the process.cl
	script generated by BATCHRED and delete two cases of "recformat=yes,"
	and one case of "apertures='',".

NUMBER:	170
MODULE:	apphot
SYSTEM:	V2.9
DATE:	Wed Jul  8 17:43:45 MST 1992
FROM:	davis

BUG:	The apphot tasks were failing to close up the coordinate files
	in the case that 1) the number of input images was greater
	than one and 2) the input coords parameter was set to "default".
	If the input image list was sufficiently long the task could run
	out of file descriptors producing a system error.

STATUS:	The bug is fixed in 2.10.0. The workaround is to break the image
	lists into smaller groups (<= ~ 60).

NUMBER:	171
MODULE:	apextract.apfit, apextract.apflatten
SYSTEM:	V2.10.0
DATE:	Thu Jul  9 16:17:01 MST 1992
FROM:	valdes

BUG:	In these tasks which output the difference, ratio, or fit
	based on a profile model the profile model is low by a factor of
	the gain.  Thus if the gain is not one the results will not be
	correct.  For example APFLATTEN will produce flat field values
	within the aperture which are multiplied by the gain except outside
	the apertures.  The workarounds are either to use a gain of 1 or
	correct the output such as with IMARITH.  The latter option may be
	difficult to apply for APFLATTEN since special steps need to be
	taken for the interaperture values.  Note that using an gain of 1
	even though the true gain is higher will often be unimportant,
	especially if cosmic ray cleaning is not done.

STATUS:	Fixed in V2.10.1.

NUMBER:	172
MODULE:	onedspec
SYSTEM:	V2.10.0
DATE:	Mon Jul 20 14:24:07 MST 1992
FROM:	valdes

BUG:	The ability to extract and operate on long slit images using the
	dispaxis/nsum parameters does not work.  There is no workaround;
	which is particularly unfortunate since TOONEDSPEC is no longer
	available.  One must resort to APEXTRACT to extract 1D spectra
	from long slit images.

STATUS:	Fixed in V2.10.1

NUMBER:	173
MODULE:	images.gauss
SYSTEM:	V2.10
DATE:	Thu Jul 23 08:17:27 MST 1992
FROM:	davis

BUG:	An incorrect convolution kernel is computed in the case theta=90.0,
	0.0 < ratio < 1.0, and bilinear=yes. The long axis of the kernel is
	aligned along the x axis instead of the y axis as intended.

	The workaround is to set bilinear=no.

STATUS: Fixed in 2.10.1	

NUMBER:	174
MODULE:	onedspec.dopcor
SYSTEM:	V2.10.1
DATE:	Thu Jul 30 16:29:31 MST 1992
FROM:	valdes

BUG:	There is a sign error in the conversion from velocity to redshift.
	Thus one has to change the sign of velocities to get the effect
	described in the documentation.  The documentation was also
	misleading in how to add a redshift in that one needs to complement
	the redshift (1/(1+z)-1) rather than reverse the sign of the
	redshift.  The example is therefore incorrect.

STATUS:	The task has been modified to correct the sign error and to add
	consistency checks on the redshifts and velocities.  The help
	has been improved and the erroneous example corrected.

NUMBER:	175
MODULE:	tv.imexamine
SYSTEM:	V2.9-V2.10.1
DATE:	Fri Jul 31 12:06:34 MST 1992
FROM:	valdes

BUG:	Attempting to use a single column or line at the top or left edge
	(high column/line numbers) of an image yields an out-of-bounds
	message.  For some reason (typo?) the simple test for out-of-bounds
	had an greater than or equal to with the edge rather than a greater
	than.  There is no workaround.

STATUS:	Fixed for V2.10.2

NUMBER:	176
MODULE:	images.imsurfit
SYSTEM:	V2.9.2 and later
DATE:	Mon Aug  3 15:12:01 MST 1992
FROM:	davis

BUG:	There is a typo in the imsurfit code which reads the sections file,
	which can result in some sections specified by the user being ignored
	in the fitting process. Whether or not the code executes correctly
	depends on section specifications themselves since the intended
	test "if (y2 < y1)" was actually coded as "if (y2 < x1)".

STATUS:	The bug is fixed in 2.10.1. There is no workaround.

NUMBER:	177
MODULE:	images.imcombine, ccdred.combine, onedspec.scombine
SYSTEM:	V2.10-V2.10.1
DATE:	Wed Aug 12 10:30:19 MST 1992
FROM:	valdes

BUG:	The minmax rejection option when used with a final average and with
	weights does not correct for the rejected pixels in the weights
	normalization.  For example with four images having identical
	weights and rejecting the high and low the final output is the sum
	of the middle pixels divided by 4 instead of 2.  There is no
	workaround.  If the weights are equal the end result is just that
	the mean intensity levels are low by a constant factor.  However,
	when the weights are not equal the final result will have pixel
	position dependent effects.

STATUS:	Fixed for V2.10.2

NUMBER:	178
MODULE:	images.fmedian
SYSTEM:	V2.9
DATE:	Tue Aug 18 11:31:49 MST 1992
FROM:	davis

BUG:	The fmedian task can crash with a segmentation violation or a
	floating operand error if image pixel to integer mapping is turned
	off (hmin = zmin and hmax = zmax) and the input image contains
	data outside the range defined by zmin and zmax. The bug is not
	seen often because for most ccd images the data is between -32768
	and 32767.

STATUS:	The bug is fixed in 2.10.1. The work-around is to either let zmin and
	zmax default to the image minimum and maximum or set hmin and hmax
	to numbers that are slightly different from hmin and hmax.

NUMBER:	179
MODULE:	daophot.allstar
SYSTEM:	V2.10
DATE:	Wed Sep 16 14:37:46 MST 1992
FROM:	davis

BUG:	If 1) cache=no, or cache=yes and memory preallocation fails for one or
	more of the data, scratch or weight arrays, 2) one or more of the
	groups has greater than maxgroup stars, 3) regrouping is 
	performed on the too large group and 4) the first star in the
	next non-regrouped group has a y value less than the y value of
	the first star in one of the regrouped groups, allstar can
	fail with an "attempt to access the scratch, weight, or data pixels
	randomly" error.

STATUS:	The bug is fixed in 2.10.2. Possible work arounds include: 1) setting
	cache=yes instead of no if the machine has enough memory and swap
	space 2) setting the maxgroup parameter to a larger value than the
	default value of 60 3) decreasing the fitting radius somewhat since
	this affects the grouping process.

NUMBER:	180
MODULE:	identify/reidentify
SYSTEM:	V2.10.1
DATE:	Wed Sep 16 16:24:05 MST 1992
FROM:	valdes

BUG:	If a spectrum is shifted using IMSHIFT with a positive shift
	then the physical pixel coordinates are incorrectly computed.
	The workaround is to reset the WCS with WCSRESET.

STATUS:	Fixed in V2.10.2.

NUMBER:	181
MODULE:	ccdred.ccdproc
SYSTEM:	V2.9(?) V2.10.1
DATE:	Tue Sep 22 08:40:14 MST 1992
FROM:	valdes

BUG:	When using STF images with a flat field that has been processed but
	has lost the CCDMEAN keyword CCDPROC will produce an error of the
	form:

	    ERROR: OPEN: File does not exist (tmp4294ha.hhd)

	A flat field in this state would most likely be produced by
	FLATCOMBINE with preprocessing before combining selected.  The
	combined flat field will lack the CCDMEAN keyword.

	The workarounds are to either use OIF images or add the CCDMEAN
	keyword manually.  This would be done by using IMSTAT to compute
	the mean and adding the CCDMEAN keyword with that value using
	HEDIT.

STATUS:	The error is ignored by CCDPROC in V2.10.2.  The reason for the
	error when calling imunmap with an image which has been created
	but for which no pixel data has been written is under investigation.

NUMBER:	182
MODULE:	apnormalize
SYSTEM:	V2.10.1
DATE:	Tue Sep 22 13:40:26 MST 1992
FROM:	valdes

BUG:	The parameter t_nlost is missing from the parameter file apnorm1.par.
	When attempting to run APNORMALIZE there will be an error message
	concerning this parameter.  It can be fixed if desired by adding
	the following line after line 63 in the file
	iraf$noao/twodspec/apextract/apnorm1.par:

	t_nlost,i,h,)aptrace.nlost,,,>aptrace.nlost

	After adding this parameter one must "unlearn apnorm1".  There is
	no workaround other than to add the parameter.

STATUS:	Fixed in V2.10.2

NUMBER:	183
MODULE:	doargus, dohydra, dofibers, skysub
SYSTEM:	Newimred, V2.10.0, V2.10.1
DATE:	Wed Sep 23 15:57:40 MST 1992
FROM:	valdes

BUG:	When using the skyedit option to review and eliminate bad sky
	apertures there is a limit to the number of sky apertures that
	can be retained.  Exceeding this limit can cause the CL to crash.
	The limit is determined by how many aperture
	numbers can be fit into 160 characters in a string of the form
	11,12,13,...; for 2 digit aperture numbers this would be a
	little over 50 sky apertures.  The workarounds are to use less
	than about 50 sky apertures or to not use the sky edit option.

STATUS:	Planned to be fixed in V2.10.2.

NUMBER:	184
MODULE:	splot
SYSTEM:	V2.10.1
DATE:	Thu Sep 24 08:48:57 MST 1992
FROM:	valdes

BUG:	The '(' and ')' keys for scrolling through multiple spectra images
	does not work properly in cases where the aperture numbers are
	not the same as the line number.  The only workaround is to use
	the explicit '#' key to access particular apertures.

STATUS:	Fixed in V2.10.2

NUMBER:	185
MODULE:	imcombine, ccdred.combine, onedspec.scombine
SYSTEM:	V2.9
DATE:	Thu Oct  1 17:06:23 MST 1992
FROM:	valdes

BUG:	When using the CCDCLIP or CRRJECT rejection option with mclip=yes
	(which is the default) a minimum of 3 images/spectra is required.
	This means that two image/spectrum cosmic ray rejection doesn't
	work as intended.  The workaround is to use mclip=no.  This is
	equivalent for two images/spectra since the median and average are
	the same in this case.

STATUS:	Fixed in V2.10.2.

NUMBER:	186
MODULE:	ccdred.ccdproc
SYSTEM:	V2.9-V2.10.1
DATE:	Mon Oct 26 11:04:21 MST 1992
FROM:	valdes

BUG:	If an image is processed which has an unknown CCD type it will have
	the minimum replace operation applied to it.  This operation is
	only supposed to apply to flat field types.  The workarounds are
	to setup/define a translation allowing the CCD types to be
	determined or to set the minreplace parameter to a very large
	negative value to avoid limiting the data.  Note that this will
	only apply to data which has low or negative values in the first
	place.

STATUS:	Fixed for V2.10.2.

NUMBER:	187
MODULE:	echelle.dofoe
SYSTEM:	V2.9
DATE:	Thu Oct 29 10:32:12 MST 1992
FROM:	valdes

BUG:	When there is a second arc it is incorrectly extracted with a
	.ms extension instead of a .ec extension causing downstream
	processing to fail.  The workaround is to rename the file
	to .ec and then start again.

STATUS:	Fixed in V2.10.2.

NUMBER:	188
MODULE:	longslit.fitcoords
SYSTEM:	V2.6-2.10.1
DATE:	Wed Nov 11 10:43:43 MST 1992
FROM:	valdes

BUG:	FITCOORDS is supposed to ignore features which have an INDEF
	for the line identification.  This was not happening but instead
	some random value was substituted for the INDEF.  The workaround
	is to avoid creating features with INDEF in IDENTIFY.

STATUS:	In V2.10.2 any features with INDEF line ids will be ignored.

NUMBER:	189
MODULE:	onedspec.splot/specplot
SYSTEM:	V2.10-V2.10.2
DATE:	Fri Dec  4 09:41:16 MST 1992
FROM:	valdes

BUG:	The units conversion to millimeters and centimeters is off by a
	factor of 10 too large.  The inverse function on these units
	will be off by a corresponding amount.

STATUS:	Fixed for the next release.

NUMBER:	190
MODULE:	longslit.fitcoords
SYSTEM:	V2.10-V2.10.2
DATE:	Mon Dec  7 11:05:09 MST 1992
FROM:	valdes

BUG:    If "combine=yes" and the input images do not have the same fit axis
	a segmentation error occurs.  The task is supposed to ignore all
	images which don't agree with the first image in the fit axis but
	there is a bug where it attempts to clean up for a skipped image
	using a NULL pointer.  The workaround is to check that all the
	images being combined have the same fit axis.  Note that a likely
	cause of this error is to inadvertently have combine=yes though
	what is really desired is combine=no to fit all the inputs
	separately in which case both fit axes can be done in one
	execution.

STATUS:	It is fixed and a warning is now printed when mismatched fit axes
	are encountered indicating which input image(s) are ignored.
	Currently expected to be released with V2.10.3.

NUMBER:	191
MODULE:	apextract.apscatter (and in related packages)
SYSTEM:	V2.10-V2.10.2
DATE:	Tue Dec  8 17:24:34 MST 1992
FROM:	valdes

BUG:	If interactive=no then the smooth parameter is ignored and the
	scattered light subtraction will not apply the smoothing along
	the dispersion.  There is no way around this.  The only suggested
	partial workaround is to leave interactive=yes, set fitsmooth=no
	and fitscatter=no, and then answer NO for the queries.  With
	a list of images this will then process all further images with
	no queries.

STATUS:	Fixed for the next release of the APEXTRACT package (expected to be
	V2.10.3).

NUMBER:	192
MODULE:	photcal.fitparams
SYSTEM:	V2.10
DATE:	Thu Dec 17 17:22:04 MST 1992
FROM:	davis

BUG:	The fitparams task could produce incorrect weight, chi, and fitted
	parameter error estimates in the case that weighting=photometric, 
	nreject > 1, and low_reject > 3.0 || high_reject > 3.0.
	This problem was occuring because the weight array was not
	being reinitialized correctly after each iteration of the rejection
	cycle. The actual problem was in the inlfit package routine
	inlfit$inreject.gx.

STATUS:	The bug is fixed for the next release of IRAF. The work around is
	to use interactive bad point deletion with the graphics cursor instead
	of the automatic iterative rejection algorithm.

NUMBER:	193
MODULE:	sensfunc
SYSTEM:	V2.9-2.10.2
DATE:	Mon Dec 21 13:01:36 MST 1992
FROM:	valdes

BUG:	SENSFUNC will not work when the standards file has a starting
	wavelength greater than the ending wavelength.  The workarounds
	are to linearize the spectra with an increasing wavelength,
	flip the spectra in STANDARD (i.e. standard spec[-*]), or
	edit the standards file to reverse the starting and ending
	wavelengths.  In the latter two cases the sensitivity function will
	then have a reversed sense from the data but the calibration will
	still correctly match wavelengths.

STATUS:	It is the intention that no spectral task care which way the
	wavelength runs relative to the pixels.  SENSFUNC has been
	modified to work in either case for the next release.

NUMBER:	194
MODULE:	splot
SYSTEM:	V2.10.2
DATE:	Thu Dec 31 10:34:52 MST 1992
FROM:	valdes

BUG:	The 'e' key in SPLOT either produces a floating operand error or
	a nonsensical equivalent width when the data values are less than
	about 1e-10 such as is the case with flux calibrated spectra.
	This problem was introduced due to a change in a system routine.
	The workaround is to scale the data, say with IMARITH or SARITH,
	to yield pixel values near unity.  The equivalent width and
	wavelengths will be independent of the scaling and the other flux
	quantities will simply have the same scale factor.

STATUS:	Fixed for the next release.

NUMBER:	195
MODULE:	daophot.allstar
SYSTEM:	V2.10
DATE:	Sun Jan  3 11:04:59 MST 1993
FROM:	davis

BUG:	In crowded regions allstar could occasionally refuse to 1) fit a
	bright star or group of bright stars, or 2) fail to converge to
	reasonable x,y, and magnitude values for a group of bright
	stars by the time the number of iterations equaled maxiter,
	resulting in a group of stars with very poor subtractions and
	large chi values.

	The problem was caused by a bug in the code which steps through the
	stellar groups, subtracting off the current best fit for all the
	stars, to produce a residuals image. Due to this bug, on occasion
	stars which should have been subtracted from the residuals image
	were not being subtracted. Since the residuals image is used to
	determine the relative errors and weights, which in turn are used
	to control the bad data rejection algorithm, allstar sometimes
	refused to fit stars because the residuals were too big or could
	not converge to a reasonable value. This bug is data dependent
	but is most likely to be a problem if, 1) the stellar detection
	threshold is very low, 2) allstar has to do a lot of regrouping to
	get the groups below maxgroup in size 3) the fitting radius is
	large resulting in very large groups.

STATUS:	This bug is only a problem in 2.10 (not in the external testphot
	package) and has been fixed for the next release of IRAF. There
	is no reliable workaround for allstar, but the nstar task which fits
	fixed groups does not have this problem.

NUMBER:	196
MODULE:	splot
SYSTEM:	V2.10.2
DATE:	Fri Jan  8 16:39:01 MST 1993
FROM:	valdes

BUG:	Use of "zero" in the option parameter (or ymin=0.) or the 'b' key
	with flux calibrated data causes a plot with limits -0.01 and 0.01
	making the data appear all zero.  The workaround is to set the
	minimum value to a number much smaller than the data but not
	exactly zero.  For example setting ymin=1e-30 when the data
	is around 1e-14.  This plot limit behavior applies to all tasks
	(GRAPH, IMPLOT) but is most likely to appear in SPLOT with flux
	calibrated data.

STATUS:	A change to a system routine is required and has been requested.

NUMBER:	197
MODULE:	images.imcombine, ccdred.combine (and related scripts)
SYSTEM:	V2.10.2
DATE:	Wed Jan 20 15:54:28 MST 1993
FROM:	valdes

BUG:	When reject=[avsigclip|sigclip|ccdclip|crreject|pclip], combine=average,	mclip=yes, and nkeep!=0 there is a rare possiblity of a segmentation
	error.  This is more likely the fewer pixels are allowed to be
	rejected.  This occurs in the step where the pixels with the lowest
	residuals are added back after too many are rejected and the
	pattern of rejections is such that only low pixels have been rejected.
	The sure workaround is to change the combine option to a median
	or mclip=no.  However, changing other parameters such as nkeep,
	the sigma thresholds, or the combining algorithm is likely to
	avoid the problem.

STATUS:	Fixed for V2.10.3.

NUMBER:	198
MODULE:	images.imcombine
SYSTEM:	V2.10.2
DATE:	Wed Jan 20 16:30:10 MST 1993
FROM:	valdes

BUG:	The CCDCLIP and CRREJECT algorithms quietly fail to reject any pixels.
	The basic source code is actually correct but due to a dependency
	condition based on file dates the wrong derived code wes used
	resulting in a mismatched argument list.  This mismatch generally
	results in the rejection algorithm seeing that there are zero
	images to process and so no rejection is done.  The workarounds
	are to use a different rejection option or the CCDRED.COMBINE
	version which is the same except for the ccdtype, keyword
	mapping, and filter subset features.

STATUS:	Fixed in V2.10.3.

NUMBER:	199
MODULE:	tv.wcslab
SYSTEM:	V2.10
DATE:	Thu Jan 28 11:10:51 MST 1993
FROM:	davis

BUG:	Wcslab was failing with the error "error processing newline" for
	images which were sections of a higher dimensioned parent images,
	and whose coordinate system was "physical" or not recognized
	recognized by wcslab, e.g. glon,glat. The actual error message
	was coming from the cl and was due to a trailing \n in the
	string passed to the error trapping routine. The actual problem was due
	to an error in the wcslab axis mapping code which was failing
	to take proper account of an existing axis map.

STATUS:	The bug is fixed in 2.10.3. A possible workaround is to temporarily set
	the wcsdim parameter in the image header to be equal to the dimension
	of the image.

NUMBER:	200
MODULE:	astutil.rvcorrect
SYSTEM:	V2.10-V2.10.2
DATE:	Mon Feb  1 10:31:22 MST 1993
FROM:	valdes

BUG:	When using RVCORRECT with a list of input images that don't have
	the OBSERVAT keyword, the observatory name supplied by the user in
	the parameter file is truncated to two characters.  An error
	message is printed and a prompt is issued for another name.
	Replying to this prompt allows the task to complete; i.e. the reply
	to the prompt is not truncated.  This is caused by a typo in
	RVCORRECT which reads only the first two characters from the
	observatory parameter.  The workarounds are to either enter the
	proper observatory when prompted or set the observatory in the
	image headers under the keyword OBSERVAT.

STATUS:	Fixed for the next release (currently expected to be V2.10.3).

NUMBER:	201
MODULE:	identify
SYSTEM:	V2.10-V2.10.2
DATE:	Wed Feb  3 16:49:36 MST 1993
FROM:	valdes

BUG:	The 'i' initialize key fails to initialize the wavelength scale.

STATUS:	Fixed in V2.10.3.

NUMBER:	202
MODULE:	apscatter, doecslit
SYSTEM:	V2.10-V2.10.2
DATE:	Fri Feb  5 15:25:52 MST 1993
FROM:	valdes

BUG:	When using the APSCATTER option (either directly or in the
	DOECSLIT script) without specifying an output name instead
	of a temporary image name being used for intermediate results
	the name ".imh" is used.  This is a hidden file and if the
	task aborts or is aborted it will be left behind and prevent
	any further use of this task.  The workaround is to recognize
	that this is why it fails to work and delete the image
	".imh".

STATUS:	Fixed in V2.10.3.

NUMBER:	203
MODULE:	sarith, scombine, splot
SYSTEM:	V2.10-V2.10.2
DATE:	Wed Feb 10 10:55:11 MST 1993
FROM:	valdes

BUG:	In certain circumstance (listed below) when the dispersion coordinates
	are inverted to get pixel coordinates the wrong pixel coordinates
	are obtained.  In practice this is important only when resampling
	spectra such as in arithmetic or combining between two spectra
	as might occur with SARITH, SCOMBINE, or the function mode in
	SPLOT.  It also can cause a problem with the SPLOT equivalent width
	options (giving a floating divide by zero).  This problem does NOT
	apply to DISPCOR!  The conditions under which this problem occurs
	are when all the following apply:

	    1.  Multispec coordinate system images with more than one
		spectrum.
	    2.  The spectra have different coordinate systems; i.e.
		are not all at a common coordinate system.
	    3.  The spectrum aperture numbers differ from the line
		numbers; for example line 1 is aperture 3 and line 3
		is aperture 1.  Note that if an image section is
		used this will change the line number so even if
		the apertures are the same as the line numbers in
		the original image this will not be true with an
		image section.

	In many applications DISPCOR is used to linearize all spectra
	to a common dispersion system.  This problem does not apply
	to such data.  It is likely to affect echelle spectra and users
	who use nonlinear dispersion coordinates.  The workarounds are
	to assign aperture numbers sequentially increasing with pixel
	coordinate when extracting, renumber the apertures with the
	renumber option in SCOPY, dispersion correct to a common system
	with DISPCOR, separate the spectra into ONEDSPEC images before
	doing the arithmetic/combining, or avoid arithmetic/combining
	operations.

	What is happening is that the coordinate transformations
	between pixel and world coordinates are (x,l) <-> (w, a)
	where x is the pixel image coordinates along the dispersion,
	l is the line number, w is the wavelength, and a is the aperture
	number.  Note that the image line maps to an aperture and vice-versa.
	The bug is that instead of using the aperture number the inverse
	transformation being used is (w,l) -> (x,?).  So unless the
	line number happens to be the same as the aperture number or
	the dispersion functions are the same for all apertures the
	dispersion function from the wrong spectrum is used for the
	inversion.

STATUS:	This will be fixed in V2.10.3.

NUMBER:	204
MODULE:	daophot
SYSTEM:	V2.10
DATE:	Tue Feb 16 09:08:48 MST 1993
FROM:	davis

BUG:	The parameters psfrad, fitrad, and matchread were being written
	to the daopars parameter set in pixel units instead of scale units
	if the daophot task update parameter was on.

STATUS:	Fixed for the next release of iraf. There is no workaround except
	to turn off the update parameter or always check the input
	parameters using the verify parameter.

NUMBER:	205
MODULE:	imslice
SYSTEM:	V2.9
DATE:	Tue Feb 16 13:52:34 MST 1993
FROM:	davis

BUG:	Removed a check that was preventing imslice from being used to reduce
	the dimensionality of images where the length of the slice_dimension
	= 1.

STATUS:	Fixed for the next version of iraf. The work around is to use imcopy.

NUMBER:	206
MODULE:	photcal.obsfile
SYSTEM:	V2.10
DATE:	Mon Mar  1 15:18:47 MST 1993
FROM:	davis

BUG:	The obsfile task was not decoding the image names correctly from the
	obsparams file, when obsfile was being called directly from the cl
	rather than from the script tasks mknobsfile and mkobsfile. Since
	obsfile could not match the names of the images in obsparams with
	those in imsets it simply ignored the contents of the obsparams
	file.

STATUS:	The bug is fixed for the next release of iraf. There is no workaround.

NUMBER:	207
MODULE:	splot
SYSTEM:	V2.10-V2.10.2
DATE:	Tue Mar  2 14:47:45 MST 1993
FROM:	valdes

BUG:	When doing arithmetic between two spectra and an invalid image
	name is entered for the second spectrum , usually because of a
	typo, the correct error message is returned.  However, attempting
	to repeat the operation, say with the correct image name, results
	in a segmentation error and the task aborts.  This will continue
	to happen until the task is flushed from the process cache.  The
	workaround is simple to flush the processes cache with
	the command "flpr splot".

STATUS:	Fixed for the next release (V2.10.3)

NUMBER:	208
MODULE:	adccdrom.catalog
SYSTEM:	adccdrom external package: archive prior to March 4, 1993
DATE:	Thu Mar  4 16:03:16 MST 1993
FROM:	valdes

BUG:	Use of the "evsptype" function results in a segmenation or bus
	error.  This was caused by using a wrong pointer datatype.
	There is no workaround other than to not use this function.
	However the external package archive was updated.

STATUS:	Fixed in the archive version of March 4, 1993.

NUMBER:	209
MODULE:	doslit, doecslit
SYSTEM:	V2.10-V2.10.2
DATE:	Wed Mar 17 11:10:30 MST 1993
FROM:	valdes

BUG:	The input list of arcs is sorted alphabetically and first sorted
	arc is used as the arc reference rather than the first specified
	by the user.  The workaround is to rename the desired reference
	arc to be first alphabetically.

STATUS:	Fixed in V2.10.3.

NUMBER:	210
MODULE:	photcal.mknobsfile,photcal.mkobsfile,photcal.obsfile
SYSTEM:	V2.10
DATE:	Fri Apr  2 11:45:11 MST 1993
FROM:	davis

BUG:	The mknobsfile,mkobsfile, and obsfile task were occasionally dropping
	stars from the output observations file in the case that: 1) the
	parameter allfilters=no, 2) there were multiple matches to a
	given star in 1 or more filters, and 3) the closet matching star was
	not the first candidate star found.

	This bug was occuring because the code was correctly matching to
	the nearest of the possible candidate stars, but was not resetting
	the matching index from the previous star, confusing the indexing
	scheme, and causing the incorrectly matched star to be dropped
	from the list.

STATUS:	The bug is fixed in 2.10.3. There is no fullproof workaround but
	accurately determining the shifts between frames and using small
	matching tolerances will minimize the problem.


NUMBER:	211
MODULE:	longslit.fitcoords
SYSTEM:	V2.10 - V2.10.2
DATE:	Mon Apr  5 10:01:12 MST 1993
FROM:	valdes

BUG:	When there are many samples to be fit an 'Out of memory" error can
	occur.  This is caused by repeatedly opening an image section
	for each sample and failing to close it.  If there are enough
	samples this can cause memory to run out.  If this happens on
	other than the first invocation of FITCOORDS then the workaround
	is to flush the process cache between executions, "flpr fitcoords".
	If it happens on the first execution then the only workaround is to
	reduce the amount of data being fit by using a larger step size,
	and avoiding multiple runs of REIDENTIFY (since redoing an
	IDENTIFY appends to the database rather than replacing resulting
	in multiple entries).  For marginal cases it might be possible to
	make sure the process has the maximum amount of memory
	available by minimizing memory use by other processes.

STATUS:	This is a rather severe bug which is fixed in V2.10.3.

NUMBER:	212
MODULE:	scombine
SYSTEM:	V2.10-V2.10.2
DATE:	Thu Apr 22 09:54:07 MST 1993
FROM:	valdes

BUG:	When combining spectra which have log sampling (DC-FLAG=1) and
	one chooses log=yes the dispersion per pixel parameter is incorrectly
	computed in the output.  The workaround is to use the
	first=yes option.

STATUS:	Fixed in V2.10.3

NUMBER:	213
MODULE:	images.imcombine ccdred.combine
SYSTEM:	V2.9-V2.10.2
DATE:	Mon May 10 14:57:05 MST 1993
FROM:	valdes

BUG:	When using a median combining operation, no rejection or with
	mclip=no, and outputing a sigma image, the sigma image is incorrect.
	This is due to the median computation destroying some of the
	input data values before the sigma is computed.  The workaround
	when both output median and sigma images are desired is to used
	one the rejection options with mclip=yes.  By choosing the
	rejection option sigclip with low and high sigma thresholds
	of 1000 no pixels will be rejected and the results are the
	same as not specifying a rejection algorithm.

STATUS:	Fixed in V2.10.3.

NUMBER:	214
MODULE:	scopy, sarith
SYSTEM:	V2.10-V2.10.2
DATE:	Thu May 20 17:07:53 MST 1993
FROM:	valdes

BUG:	When using SCOPY or SARITH with a specified wavelength range,
	w1 and w2 not equal to INDEF, and rebin=yes the spectra are
	correctly resampled to the requested wavelength interval but
	the coordinate system in the header is updated incorrectly.
	The coordinates may be off by a fraction of a pixel.  For
	example if w1=6400 and w2=6600 the output data will have
	the first pixel at 6400 but the coordinate reported by
	LISPIXEL or any other task might be 6400.25 (where the
	dispersion is, say, 3 Angstroms per pixel).  This error
	is caused during the conversion from logical to physical
	pixel coordinates when the physical coordinates are treated
	as integer; i.e. a wavelength of 6400 for the first logical
	pixel might be physical pixel 185.325 but it is then
	truncated to 185 and the coordinate system is set so
	that physical pixel 185 is 6400 and pixel 185.325 is
	6400.25.  This is a subtle error which may be discovered
	by looking at the coordinate of the first pixel with LISTPIX
	and comparing it with the requested wavelength of the first pixel.

STATUS:	Fixed in V2.10.3.

NUMBER:	215
MODULE:	imcombine, ccdred.combine
SYSTEM:	V2.10-V2.10.2
DATE:	Wed May 26 14:06:15 MST 1993
FROM:	valdes

BUG:	The following combination of parameters give a floating divide
	by zero due to an error in the code.  Rejection is CRRJECT or
	CCDCLIP, grow is greater than zero, and the images are offset.
	The simplest workaround is to not use a growing factor (grow=0).

STATUS:	Fixed in V2.10.3

NUMBER:	216
MODULE:	noao.astutil.asttimes
SYSTEM:	V2.9
DATE:	Thu May 27 15:01:18 MST 1993
FROM:	valdes

BUG:	The epoch printed is not clearly defined and the siderial time is
	incorrect by a few seconds.  There is also a gross error at the
	new year for observatories with a negative time zone.  The epoch
	used is the day of the year, including the fraction of the day,
	divided by a Julian year of 365.25 days.  However the siderial
	time calculation assumes a J2000 Julian epoch which is not the
	same as the previous definition.  The previous epoch definition
	is also no smoothly continuous at the new year since some years
	have 366 days and other 365 and no years have 365.25 days.
	Other tasks in the ASTUTIL package also use the astronomical
	time routines but it appears that generally the error cancels
	out (because the date->epoch->julian date transformations use
	the same epoch definition) or is insignificant (such as in
	precession or air mass calculations).

STATUS:	For V2.10.3 the routines have been modified to consistently use
	J2000 epochs.  ASTTIMES will print these epochs and the
	sideral times will not have the errors of a few seconds.

NUMBER:	217
MODULE:	identify
SYSTEM:	V2.9
DATE:	Fri Jun  4 10:00:06 MST 1993
FROM:	valdes

BUG:	The labels associated with marked features are not correctly
	updated when a feature is deleted.  The effect is that the
	wrong labels get associated with the features after deletion.
	There is no workaround though the labels are informational
	so the main job of determining dispersion functions is unaffected.

STATUS:	Fixed in V2.10.3.

NUMBER:	218
MODULE:	fitprofs
SYSTEM:	V2.9
DATE:	Tue Jun  8 09:11:06 MST 1993
FROM:	valdes

BUG:	When the dispersion axis is 2 and the number of lines is greater
	than the number of columns a floating operand error can occur.
	This is caused by dimensioning an array by the number of columns
	rather than the number of elements along the dispersion axis.
	The workaround is to either use an image section to make the
	number of lines equal to the number of columns or to transpose
	the image.  Transposing the image also requires reseting some
	of the WCS keywords.

STATUS:	Fixed in V2.10.3.

NUMBER:	219
MODULE:	images.geomap
SYSTEM:	V2.9
DATE:	Wed Jul  7 11:04:31 MST 1993
FROM:	davis

BUG:	If the input coordinate file contains fewer than 3 stars  geomap
	dies with a segmentation violation. The problem was caused by
	some missing errchk statements in the error handling code, with the
	result that geomap tried to evaluate a non-existent solution.

STATUS:	The problem has been fixed in 2.10.3. 

NUMBER:	220
MODULE:	ptools.pconvert
SYSTEM:	V2.9
DATE:	Wed Jul 28 08:34:39 MST 1993
FROM:	davis

BUG:	In append mode the pconvert task was refusing to append data to
	columns derived from multi-valued quantities in the original
	apphot/daophot text output,  e.g. MAG[1].

	The problem was due to an extraneous escape character "\"
	infront of the "[" in the column specification (this is required
	for column template expansion, but not for column definition).

STATUS:	Fixed in 2.10.3. There is no work-around.

NUMBER:	221
MODULE:	images.imcombine, ccdred.combine
SYSTEM:	V2.9-V2.10.2
DATE:	Wed Aug  4 15:48:03 MST 1993
FROM:	valdes

BUG:	When the number of input images + number of output images +
	logfile (if used) is exactly 60 the task fails with error 757.  For
	example if there are 59 input images, an output image, and no
	logfile this error occurs.  The workaround is to add or eliminate
	the logfile or else change the number of input or output images.

STATUS:	Fixed in V2.10.3.

NUMBER:	222
MODULE:	images.fit1d, generic.background, longslit.background
SYSTEM:	V2.10-V2.10.2
DATE:	Fri Aug  6 10:36:36 MST 1993
FROM:	valdes

BUG:	When the input and output images are the same the last part of
	the image will not be modified.  The workaround is to use
	a different output image and then, if desired, delete the
	original and rename the new image to the original image.

STATUS:	Fixed for V2.10.3.

NUMBER:	223
MODULE:	photcal.fitparams
SYSTEM:	V2.10
DATE:	Sun Aug  8 15:05:17 MST 1993
FROM:	davis

BUG:	Errors in the catalog and observations variables were not being
	added to the total error computed for an observation by the fitparams
	task if these variables were used in a set equation, the set equation
	was then used in one or more of the transformation equations, and the
	weighting parameter was set to photerrors. 

STATUS: The bug is fixed in iraf 2.10.3. Possible workarounds include use of
	the weighting=equations option and avoiding the use of the set
	equations in transformations equations.

NUMBER:	224
MODULE:	apnormalize
SYSTEM:	V2.10 - V2.10.2
DATE:	Fri Aug 27 18:40:27 MST 1993
FROM:	valdes

BUG:	When the dispersion axis is 1 and the "cenorm" option is selected
	the result is not correct.  One workaround would be to transpose
	the image and the other is to not use the "cenorm" option.

STATUS:	Fixed in V2.10.3

NUMBER:	225
MODULE:	apfit, apnormalize
SYSTEM:	V2.10 - V2.10.2
DATE:	Fri Aug 27 18:42:14 MST 1993
FROM:	valdes

BUG:	The results of the "fit" and "difference" in APFIT and of
	APNORMALIZE are incorrect by a factor of the gain.  This is
	basically the same bug as 171 which was not correctly fixed.
	The workarounds are to use a gain of 1.

STATUS:	Fixed in V2.10.3

NUMBER:	226
MODULE:	artdata.mkobjects
SYSTEM:	V2.9-V2.10.2
DATE:	Fri Sep 17 14:13:24 MST 1993
FROM:	valdes

BUG:	The scales of the "expdisk" and "devauc" images are incorrect due
	to an integer truncation error.  The error is such that the actual
	output radius for a given input radius is given by the formulas:

	expdisk:  rout = rin * int(ln(D)/1.6783) / ln(D)/1.6783
	devauc:   rout = rin * int(ln(D)/7.67)**4) / (ln(D)/7.67)**4

	where D is the dynamic range parameter in the ARTDATA package
	parameters, ln() is the natural logarithm, int() is the integer
	truncation function, and ** is the exponentiation operator.
	From this one can, fudge the input radii to give the
	desired output radii, select a dynamic range where the correction
	factor is 1, or account for this as needed when the artificial
	image is analyzed.  The simplest thing is to adjust the dynamic
	range; for example, a dynamic range of 126514 for the "expdisk"
	model is the closest to the default value of 10000 which will give
	correct output scales.

STATUS:	Fixed in V2.10.3

NUMBER:	227
MODULE:	longslit.transform
SYSTEM:	V2.8-V2.10.2
DATE:	Sun Sep 19 14:21:35 MST 1993
FROM:	valdes

BUG:	If the requested output coordinates extend outside of the input
	data range, the interpolated output data very near the edge
	may suffer a small stretch distortion.  The error is confined
	to the end 50th of the image and the magnitude of the stretch
	depends on the specifics of the requested output sampling.
	The workaround is to either creating an output image
	which extends beyond the input data range.

STATUS:	Fixed in V2.10.3

NUMBER:	228
MODULE:	images.imsurfit
SYSTEM:	V2.9
DATE:	Wed Sep 22 13:29:23 MST 1993
FROM:	davis

BUG:    Bugs in the bad pixel rejection code were causing the imsurfit task
	to either 1) hang or crash with a segmentation violation or 2)
	display oscillating behavior (sigmas which would decrease then 
	increase again after succesive iterations), if the number of 
	detected bad pixels was very large. The first problem was caused
	by a failure of the code to allocate sufficient space for the bad
	pixel list. The second problem was caused by a failure of the code
	to correctly resolve overlapping regions in some circumstances,
	causing the same pixels to be alternately rejected and included
	in the fit.

STATUS:	Fixed in 2.10.3.

NUMBER:	229
MODULE:	images.imcombine, ccdred.combine
SYSTEM:	V2.9
DATE:	Fri Sep 24 10:40:31 MST 1993
FROM:	valdes

BUG:	If an offset file is specified as containing absolute offsets
	but with all the offsets equal then the combining acted like
	relative offsets except the output image size would be that
	of the absolute offsets and garbage appears in the final
	lines/columns.  The workaround is to either not have
	identical offsets or combine the images without offsets
	and then paste the result into a bigger empty image at
	the desired offset with IMCOPY.

STATUS:	Fixed in V2.10.3.

NUMBER:	230
MODULE:	images.imcombine, ccdred.combine
SYSTEM:	V2.9
DATE:	Fri Sep 24 10:45:00 MST 1993
FROM:	valdes

BUG:	The documentation says that scale and zero offset factors specified
	by an @file of header keyword are multiplicative and additive.
	However they are used as divisive and subtractive.  The workaround
	is to know the values should be input as divisive and
	subtractive.

STATUS:	In V2.10.3 this has been fixed so the input is as defined in
	the documentation.

NUMBER:	231
MODULE:	imcombine, ccdred.combine
SYSTEM:	V2.10.2
DATE:	Tue Nov  9 09:17:12 MST 1993
FROM:	valdes

BUG:	If there are fewer pixels at some point than that specified by nkeep
	parameter, such as caused by offsetting, thresholding, or masking,
	then the tasks try to add data from the nonexistent images resulting
	either in garbage or a segmentation violation.  The workaround
	is to use nkeep or 1 or 0 rather a higher value unless there
	are no offsets or other factors that will result in a smaller
	number of points than the number of images at some points.

STATUS:	This has been fixed for V2.10.3.  This also resulted in a change
	in how a negative nkeep is used.  In the new version, if one
	specifies a maximum number to reject, that number applies to
	the initial set of pixels rather than to the total number of
	images.

NUMBER:	232
MODULE:	images.geomap
SYSTEM:	V2.9
DATE:	Wed Dec 29 16:39:24 MST 1993
FROM:	davis

BUG:	Geomap was computing an incorrect coordinate transformation if the
	functional form of the coordinate transformation was "chebyshev"
	or "legendre" x fit x or y order was > than 2 and the y fit was
	linear (x and y order equal to 2), or if the y fit x or y order
	was > 2 and the x fit was linear (x and y order equal to 2).
	This was occurring because geomap was incorrectly redefining the
	functional form of the linear fit to be "polynomial".

STATUS:	Fixed in 2.10.3. There is no direct workaround but setting the
	cross terms parameter of the linear fit to "yes" will avoid
	the problem at the expense of computing one extra term in the fit.

NUMBER:	233
MODULE:	apphot package tasks
SYSTEM:	V2.9
DATE:	Fri Dec 31 14:46:23 MST 1993
FROM:	davis

BUG:	If the number of input images is greater than one, the number of
	output files is exactly equal to one, and the input coordinate
	file(s) do not contain any decodable coordinates, the input coordinate
	file rather than the empty output file is deleted. The problem
	occurs because the output file name is not being correctly stored
	as the tasks looped through the input image list.

STATUS:	The bug is fixed in 2.10.3. The workaround is to make sure at least
	one of the coordinate files contains valid coordinates.

NUMBER:	234
MODULE:	onedspec.standard
SYSTEM:	V2.10-V2.10.2
DATE:	Fri Jan  7 09:38:51 MST 1994
FROM:	valdes

BUG:	When using STANDARD on a long slit spectrum with a dispersion axis
	of 2 (where each column is treated as a spectrum) the task uses the
	length of the second axis rather than the first axis to define the
	number of spectra.  If the second axis length is greater than the
	first axis then the last column is processed repeatedly.  One may
	limit this by using the apertures parameter to specify just the
	columns; i.e. 1-250 in a 250x800 images.  If the number is smaller
	then some of the columns will not be processed.  On workaround is
	to transpose the image but then some fudging of the WCS will be
	necessary.  Another workaround would be to use SCOPY to extract all
	the spectra to a multispec format.

STATUS:	Fixed for the next release.

NUMBER:	235
MODULE:	digiphot.apphot.fitpsf
SYSTEM:	V2.9
DATE:	Mon Jan 17 14:18:33 MST 1994
FROM:	davis

BUG:	In cases where the fitting box was entirely off the image or there
	were too few pixels in the fitting box to fit the psf model (e.g.
	< 5 in the case of function=radgauss), the output fitted parameter
	and parameter error arrays were not being initialized correctly.
	Instead, although the fit was correctly tagged with the appropriate
	error code, the results of the previous fit were written to the
	output file.

STATUS:	Fixed in 2.10.3. There is no workaround except to make sure that
	the fitting box contains enough pixels and/or to check the error
	codes of the fitted objects.

NUMBER:	236
MODULE:	digiphot.photcal.invertfit
SYSTEM:	V2.10
DATE:	Wed Jan 19 08:03:42 MST 1994
FROM:	davis

BUG:	On VMS systems the invertfit task will crash with an adjustable
	array dimension error if the user has no defined set equations
	in his/her configuration file. In this case invertfit passes a
	2D array with a zero length first dimension to a subroutine,
	triggering a run time error under VMS, even though the array is
	never accessed.

STATUS:	Fixed in 2.10.3. The workaround is to include a dummy set equation
	in the transformation section of the configuration file.

NUMBER:	237
MODULE:	IEEE NaN support
SYSTEM:	Sun/IRAF V2.10, V2.10.1, V2.10.2
DATE:	Fri Jan 21 15:55:46 MST 1994
FROM:	tody

BUG:    When converting native floating point to IEEE floating point (as
	when writing FITS files), V2.10 IRAF has a feature which allows
	pixels with a reserved floating point value to be replaced by IEEE
	NaN on output.  In V2.10 Sun/IRAF, the code which does this was
	correct, but the wrong version of the affected object module was
	present in the system library (libvops.a) and in the IRAF shared
	image (S6.e).  This would cause zero to be written as the output
	IEEE value instead of NaN.

STATUS:	Fixed in V2.10.3 or later.  So far as I know the core IRAF system
	does not use this feature but it is used by some layered packages,
	e.g., STWFITS.  The bug only comes into play when mapping of NaNs on
	output is enabled by the application being used.  This is probably
	not a serious bug in most cases, but if the zeros are a problem the
	bug can be fixed by rebuilding the IRAF shared library S6.e.  Contact
	the IRAF group for advice on how to do this.

NUMBER:	238
MODULE:	ccdred.combine
SYSTEM:	V2.10
DATE:	Tue Feb 15 14:04:14 MST 1994
FROM:	valdes

BUG:	When combining images with separate exposure and dark times the
	final dark time recorded in the header is actually the exposure
	time; so the final dark time and exposure time will always be the
	same.  The correct dark time is computed but the wrong thing
	is being written to the image.  This is likely to be of relevance
	for combining dark frames when the dark times of the individual
	frames are not the same as the exposure times.  The workaround
	is to copy the dark time to the exposure time with HEDIT in
	the dark frames before combining.  Note that this bug
	applies to the script DARKCOMBINE since it calls COMBINE.

STATUS:	This is a simple typo code fix which has been made for the V2.11
	release.

NUMBER:	239
MODULE:	onedspec tasks
SYSTEM:	V2.10 - V2.10.2
DATE:	Sat Mar  5 16:05:55 MST 1994
FROM:	valdes

BUG:    Applying IMSHIFT with a positive shift can cause errors in
	the ONEDSPEC tasks.  Negative shifts do not cause a problem.  The
	same problem has been noted previous in bug log number 180 for
	IDENTIFY and REIDENTIFY.  Errors occur when a wavelength is
	transformed to a pixel coordinate.  This happens in a number of
	operations in SPLOT.  There are various workarounds depending on
	what is desired.  A WCSRESET of the physical coordinate system can
	be used though this will cause the dispersion coordinates to also
	shift; i.e. then the shift will move the pixel relative to the
	image data array and the wavelength coordinate system.  As a
	general rule use of IMSHIFT with spectra, particularly dispersion
	calibrated spectra, should be avoided.

STATUS:	The problems have been fixed for V2.11.

NUMBER:	240
MODULE:	ptools.pexamine
SYSTEM:	V2.10
DATE:	Tue Mar 15 08:43:20 MST 1994
FROM:	davis

BUG:	If either or both of the columns specified by the pexamine task
	parameters xcolumn or ycolumn is undefined in the input image data,
	then pexamine will crash with a segmentation violation if the user
	types the o keystroke command in image cursor input mode. The problem
	occurs because the o keystroke command switches the task to graphics
	cursor mode, and tries to move the graphics cursor to a point in the
	default x-y plot which is undefined.

STATUS:	The bug is fixed in 2.11. The workaround is to set the xcolumn and
	ycolumn parameters to a column that is defined in the input data.

NUMBER:	241
MODULE:	sarith, scopy
SYSTEM:	V2.10
DATE:	Tue Apr 12 13:56:49 MST 1994
FROM:	valdes

BUG:	If a spectrum is "multispec" with more than 127 APID keywords the
	tasks will fail with a segmentation violation.  This is due to
	a limit in a keyword template expansion step.  The work around
	is to delete some of the keywords with:

		cl> hedit <images> apid1?? del+

	Note that you can't delete them all since HEDIT has the same
	limit.  The APID strings can be restored from an aperture
	identification file using SAPERTURES at a later time.

STATUS:	In V2.11 the limit on the number of keywords in a template
	expansion has been increased to 1024.

NUMBER:	242
MODULE:	sarith
SYSTEM:	V2.10-2.10.2
DATE:	Thu Apr 28 13:51:04 MST 1994
FROM:	valdes

BUG:	Contrary to the help documentation, SARITH fails to allow a single
	second spectrum operand to be repeated when the first operand
	is a list.  This is a bug.  The workaround is to repeat the
	second operand as often as necessary even if it is the same
	name.

STATUS:	Fixed for V2.11.

NUMBER:	243
MODULE:	rotate/imlintran/geotran
SYSTEM:	V2.10
DATE:	Wed May 11 10:36:18 MST 1994
FROM:	davis

BUG:	Geotran was erroneously overriding the output image size requested by
	the user if: 1) no geomap database was defined, 2) the output size
	requested by the user was larger the size required to see the whole
	input image assuming no origin shift. The tasks rotate/imlintran
	were also affected by this problem.


STATUS:	The bug has been fixed for the next release. There is no workaround.

NUMBER:	244
MODULE:	imcombine, combine, scombine
SYSTEM:	V2.10
DATE:	Wed May 25 11:10:50 MST 1994
FROM:	valdes

BUG:	When combine=average, reject=(sigclip, avsigclip, ccdclip, or pclip),
	and mclip=yes (the value of mclip does not matter for pclip) the
	average will be incorrect if the number of low pixels rejected is
	greater than the number of unrejected pixels.  For example if 3 low
	pixels are rejected and only 2 pixels remain then the final average
	will be incorrect for that pixel.  There is no workaround other
	than to avoid this combination of parameters.

STATUS:	Fixed in V2.11.

NUMBER:	211.1
MODULE:	longslit.fitcoords
SYSTEM:	V2.10 - V2.10.2
DATE:	Sat Jun  4 09:49:39 MST 1994
FROM:	valdes

BUG:	When there are many samples to be fit an 'Out of memory" error can
	occur.  This is caused by repeatedly opening an image section
	for each sample and failing to close it.  If there are enough
	samples this can cause memory to run out.  If this happens on
	other than the first invocation of FITCOORDS then the workaround
	is to flush the process cache between executions, "flpr fitcoords".
	If it happens on the first execution then the only workaround is to
	reduce the amount of data being fit by using a larger step size,
	and avoiding multiple runs of REIDENTIFY (since redoing an
	IDENTIFY appends to the database rather than replacing resulting
	in multiple entries).  For marginal cases it might be possible to
	make sure the process has the maximum amount of memory
	available by minimizing memory use by other processes.

	A second manifestation of this problem occurs when using STF
	format (the SDAS group format).  The error is

		ERROR: 827 <image>
	
	where <image> is the image section.  This message means that
	the task has opened too many files and could not open the file
	which translates the error code.  This behavior occurs because
	STF format image keep the image header open unlike the .imh
	format.  The workarounds are the same as decribed previously.


STATUS:	This is a rather severe bug which is fixed in V2.11.

NUMBER:	246
MODULE:	images.imcombine, ccdred.combine, onedspec$scombine
SYSTEM:	V2.10.2
DATE:	Mon Jun  6 17:03:15 MST 1994
FROM:	valdes

BUG:	In rare circumstances when using one of the clipping algorithms
	nkeep > 0 the task will not complete because it has entered
	a nonterminating loop.  This occurs when too many
	pixels are rejected and two or more rejected pixels have
	equal residuals the equal residual points are added back.
	However this is done within the iterative loop and after
	adding back the pixels the task finds there are now more than
	nkeep pixels and so repeats the loop with the same result.
	The work around is to change nkeep.  A change is likely
	to fix the specific case.  A value of zero for nkeep will
	avoid the problem entirely but with the possibility of
	rejecting all pixels.

STATUS:	The adding back of pixels should be done outside the iterative
	loop and this change has been made for the next release (V2.11).

NUMBER:	247
MODULE:	photcal.fitparams
SYSTEM:	V2.10
DATE:	Mon Jun 13 16:12:33 MST 1994
FROM:	davis

BUG:	If the fitparams task parameter weighting is set to "photometric"
	or "equations", the addscatter parameter is set to "yes", and
	either the number of parameters to be fit equals the number of data
	points, or the fit has no scatter, fitparams will crash with a
	floating operand error. This occurs because the expression used
	to estimate the additional scatter to be added to the weights in the
	next iteration of the fit goes to 0 in the denominator, causing a
	divide by zero error.

STATUS: The bug is fixed in 2.11. The workaround is to set weighting to
	"uniform" or set the addscatter parameter to "no".

NUMBER:	248
MODULE:	image.imcombine,ccdred.combine,onedspec.scombine
SYSTEM:	V2.10.2
DATE:	Mon Jun 13 18:50:46 MST 1994
FROM:	valdes

BUG:	When the rejection algorithm is avsigclip, sigclip, avsigclip, or
	crreject and mclip=no and nkeep is not zero there is the rare
	possibility of a segmentation violation.  This occurs when more
	than the maximum number of pixels is rejected and several of the
	rejected pixels have the same residual relative to the average.
	The workarounds are to reduce nkeep (possibly to zero), use
	mclip=yes, use another rejection algorithm, or adjust the sigma
	values.

STATUS:	This problem is fixed for V2.11.

NUMBER:	249
MODULE:	sarith
SYSTEM:	V2.10
DATE:	Tue Jun 21 14:35:17 MST 1994
FROM:	valdes

BUG:	When doing a binary operation with a constant second operand and
	"onedspec" output format the constant used is incorrect due
	to a bug in which the number is used as a real number but is
	actually a double precision number.  The incorrect value can
	be seen in the verbose output.  For example:

	    cl> sarith specin - 48.5 specout format=onedspec verbose+
	    specin[1]  -  3.128906  -->  specout.0001

	The workaround is to use multispec output format for the operation.
	A later SCOPY can then be used to convert formats if desired.

STATUS:	Fixed in V2.11.

NUMBER:	250
MODULE:	photcal.mknobsfile,mkobsfile,obsfile
SYSTEM:	V2.10
DATE:	Wed Jun 22 17:16:03 MST 1994
FROM:	davis

BUG:	The mknobsfile/mkobsfile/obsfile tasks were omitting stars from the
	output observations file for image sets where there was only a single
	image per image set, and that image was not the last image in the
	image set.

STATUS:	The bug has been fixed in 2.11. One possible work around is to
	set the tolerance parameter to 0, run mknobsfile/mkobsfile/obsfile on
	image sets with only one defined image separately from the other image
	sets, and concatenate the results from the two runs.

NUMBER:	251
MODULE:	sarith, scopy
SYSTEM:	V2.10.0 - V2.10.2
DATE:	Wed Jun 29 17:32:20 MST 1994
FROM:	valdes

BUG:	For multispec spectra which have a doppler factor in the coordinate
	system description (a non-zero value for the 7th field following
	the number of pixels) making a copy or doing arithmetic will
	cause the wavelength zero point to be off by a factor of
	1/(1-z*z).  The workarounds are to either avoid introducing
	a doppler factor, accounting for the error, or explicitly
	setting w1,w2 (but note bug #214).

STATUS:	Fixed 10/92 and included in V2.11.

NUMBER:	252
MODULE:	utilities.polyfit
SYSTEM:	V2.10
DATE:	Mon Jul 11 09:17:27 MST 1994
FROM:	davis

BUG:	The computation of chisqr and stdev are too large by a factor
	if yavg ** 2 if the weighting parameter is "instrumental" and
	abs(yavg) if the weighting parameter is "statistical".

STATUS:	Fixed in 2.11. There is no workaround except to apply the 
	correction factors manually.

NUMBER:	253
MODULE:	transform, apall, apsum
SYSTEM:	V2.9
DATE:	Mon Jul 25 14:14:57 MST 1994
FROM:	valdes

BUG:	The extraction of dispersion calibrated long slit data, the
	result of TRANSFORM, does not properly pass on the dispersion
	information.  One symptom of this is that if the dispersion axis is
	2 then the final extracted spectrum will have a wavelength per
	pixel corresponding to the first axis in the CD1_1 keyword.  Note
	that there is also a correct WPC and CDELT1 keyword.  This does not
	cause a problem when using V2.9 ONEDSPEC routines because WPC has
	precedence over CD1_1.  However in taking this data to V2.10 the
	precedence was changed and CD1_1 is used in preference to WPC or
	CDELT1.  So a task like V2.10 SPLOT will plot the spectra with an
	incorrect dispersion.  The work around to update the header for
	V2.10 is update the CD1_1 keywords or delete them:

	    cl> hedit <1D spectra> cd1_1 '(wpc)'
	    cl> hedit <1D spectra> cd1_1 del+

STATUS:	The aperture extraction in V2.10 correctly passes on the
	dispersion coordinates produced by TRANSFORM during the
	long slit reductions.

NUMBER:	254
MODULE:	longslit.transform
SYSTEM:	V2.10-V2.10.2
DATE:	Sat Aug  6 12:14:32 MST 1994
FROM:	valdes

BUG:	If DISPAXIS=2 and one specifies log sampling (ylog=yes)
	then the specified sampling is done correctly but the header
	coordinate description is incorrect.  Specifically the starting
	wavelength, CRVAL2, is given as a linear wavelength rather
	than a log wavelength.  Display of this spectrum, say with
	SPLOT, produces a wavelength scale which is very compressed
	at the starting wavelength.  The workaround is to fix the header
	of the transformed image with

	    cl> hedit <images> crval2 "(log10(crval2))" update+

STATUS:	Fixed in versions after V2.10.2

NUMBER:	254
MODULE:	longslit.transform
SYSTEM:	V2.10-V2.10.2
DATE:	Sat Aug  6 12:54:42 MST 1994
FROM:	valdes

BUG:	If DISPAXIS=2 and one specifies log sampling (ylog=yes)
	then the specified sampling is done correctly but the header
	coordinate description is incorrect.  Specifically the starting
	wavelength, CRVAL2, is given as a linear wavelength rather
	than a log wavelength.  Display of this spectrum, say with
	SPLOT, produces a wavelength scale which is very compressed
	at the starting wavelength.  The workaround is to fix the header
	of the transformed image with

	    cl> hedit <images> crval2 "(log10(crval2))" update+

	This was caused by a typo where parameter xlog was used
	where ylog should have been.  Another thing to be aware
	of is that extraction of a 1D spectrum from the 2D
	spectrum with the APEXTRACT tasks will propagate the error.
	For such data SPLOT crashes because it tries to evaluate
	an impossibly large decimal exponent.

STATUS:	Fixed in versions after V2.10.2

NUMBER:	255
MODULE:	apall, apsum
SYSTEM:	V2.10-V2.10.2
DATE:	Tue Aug  9 10:47:21 MST 1994
FROM:	valdes

BUG:	When extracting spectra with dispaxis=1 (spectra horizontal) using
	variance weighting and/or cleaning with a gain other than 1 then
	occasionally a "floating operand error" or some arithmetic
	exception can occur.  This is caused by reference to unitialized
	memory during application of the gain.  The uninitialized memory
	does not affect the results but if an invalid arithmetic value
	is encountered it will cause the extraction to abort.  The
	workarounds in this case are to use a gain of 1 if it is
	reasonable otherwise to transpose the image and reset the
	wcs (with wcsrest <image> wcs=physical) and the dispaxis
	value.

STATUS:	Fixed after V2.10.2.

NUMBER:	256
MODULE:	ccdproc
SYSTEM:	V2.8-V2.10.3
DATE:	Mon Aug 29 13:57:03 MST 1994
FROM:	valdes

BUG:	If the calculation datatype is set to short, calculation of the
	CCDMEAN value is incorrect and, if used during flat fielding, will
	give incorrect scaling for the flat fielding.  The workarounds are
	to not use short for the calculation datatype though it is ok to
	use short output datatype to save diskspace.  Note that if no
	calculation datatype is specified it defaults to real so it takes
	an explicit setting of pixeltype="short short" or "real short" to
	force this bug to appear.

STATUS:	Fixed after V2.10.3.

NUMBER:	257
MODULE:	mkfringe, mkillumcor, mkillumflat, mkskycor, mkskyflat
SYSTEM:	V2.8-V2.10.3
DATE:	Mon Aug 29 16:25:11 MST 1994
FROM:	valdes

BUG:	If the tasks are run more than once without flushing the process
	then a segmentation violation or error attempting to access an
	unopened file is likely to occur.  The workaround is to flush the
	process cache with "flpr" before running any of these tasks.

STATUS:	Fixed future versions.

NUMBER:	258
MODULE:	reidentify
SYSTEM:	V2.10-V2.10.3
DATE:	Thu Sep 15 10:29:50 MST 1994
FROM:	valdes

BUG:	If a step of zero is specified the task will hang in an infinite
	loop.  The way the step is used is to increment/decrement the starting
	line until the ends of the image are reached.  With a step of
	zero this will never happen.  However, if one is interested in
	only reidentifying a single line in a 2D image it seems
	reasonable to set the step to zero.  The actually method is
	to set the step to a very large number.

STATUS:	For the next release the case of a zero step is checked and
	causes REIDENTIFY to only reidentify the reference line in
	other images.

NUMBER:	259
MODULE:	images.tv.tvmark
SYSTEM:	V2.10
DATE:	Mon Oct  3 09:01:29 MST 1994
FROM:	davis

BUG:	The tvmark append (a) keystroke command does not function correctly 
	under Solaris IRAF 2.10.3 BETA. The objects to be appended to the
	coordinate list are marked correctly on the image display but are not
	appended to the output coordinate file.

	The problem is apparently caused by a failure to call the flush
	command before doing a seek to EOF. On SunOS systems the seek to
	EOF appears to force a flush, while on Solaris systems it
	does not, resulting in the appended objects never being written
	to the output file.

STATUS:	Fixed for the next release of IRAF. There is no workaround.

NUMBER:	260
MODULE:	digiphot.daophot.seepsf
SYSTEM:	V2.10
DATE:	Mon Oct  3 13:08:46 MST 1994
FROM:	davis

BUG:	The seepsf task was forcing the output psf image to be less than or
	equal 23 pixels square, corresponding to a psfrad less than or equal
	to 11 pixels, no matter what the actual psfrad in the input image
	psf was. The computed portion of the output psf image was correct.
	The problem was that seepsf was using the wrong quantity to compute
	the default size of the output psf image.

STATUS:	Fixed in 2.10.3. There is no workaround.

NUMBER:	261
MODULE:	apphot package tasks
SYSTEM:	V2.10
DATE:	Tue Oct  4 09:21:04 MST 1994
FROM:	davis

BUG:	The directory information was inadvertantly being stripped from
	the default input/output file specifications. For example the phot
	task would look for the default input coordinate file in the
	current directory even though, the file specification was dir$default.
	Similarly the default output file was being written to the
	current directory,  even though the file specification was dir$default.
	Directory information was not being stripped from fully specified
	file names.

STATUS:	Fixed in the next release of iraf.  

NUMBER:	262
MODULE:	echelle.doecslit
SYSTEM:	V2.10-V2.10.2
DATE:	Thu Oct  6 16:21:57 MST 1994
FROM:	valdes

BUG:	DOECSLIT fails to actually use the recentered and (optionally)
	retraced apertures determined for each object spectrum when
	it extracts the orders.  Instead it ignores the object apertures
	and uses the reference spectrum apertures.  This can be seen
	since the actual apertures used for extraction are saved in
	the database and they will be the same as the reference
	aperture.  There are no workarounds other than to modify
	the script or to do the extractions separately with APALL
	and then use DOECSLIT for the remainder of the operations.

STATUS:	This fixed in versions after V2.10.2.

NUMBER:	263
MODULE:	photcal.mkapfile
SYSTEM:	V2.10
DATE:	Thu Oct 13 11:37:48 MST 1994
FROM:	davis

BUG:	If there was more than one photometry file in the input file list
	mkapfile was quitting with the error "ERROR on line 187: cannot open
	`file'" for writing. This was caused by the script trying to append
	to an existing file with "> file" instead of ">> file".

STATUS:	Fixed for the next release of IRAF.

NUMBER:	264
MODULE:	rv.fxcor
SYSTEM:	V2.10
DATE:	Thu Oct 13 15:32:33 MST 1994
FROM:	fitz

BUG:	The batch processing code was not initializing the task structure
	properly and a "Memory has been corrupted" error can occur when
	processing in batch and the template spectrum has to be rebinned.
	The bug is not seen if it's the object spectrum that is rebinned.
	Possible workarounds include rebinning the data to a common disp-
	ersion and starting wavelength before correlating, setting the 
	'rebin' parameter to force it to rebin to the object's dispersion,
	or else just process interactively.  The code change is trivial
	for sites who wish to fix it.

STATUS:	Fixed in versions after V2.10.3beta.

NUMBER:	265
MODULE:	expanding file templates on Solaris
SYSTEM:	SunOS/IRAF V2.10.2 executing on Solaris
DATE:	Fri Oct 14 13:27:26 MST 1994
FROM:	tody

BUG:    Various users have reported a subtle problem in IRAF which occurs
	when SunOS/IRAF version 2.10.2 is run on a Solaris system in
	compatibility mode.  On occasion IRAF code which reads host
	directories may not "see" all the files in a directory.  Hence file
	and image templates may not expand correctly, omitting some of the
	files in a directory.

STATUS:	This problem is not present in the native Solaris version of IRAF,
	Solaris/IRAF V2.10.3BETA.  The solution is to update to this version.
	If V2.10.2 must be used, use host system facilities (e.g. ls, provided
	as a foreign task in unix/iraf systems) to expand file templates.  

NUMBER:	266
MODULE:	apphot.daofind
SYSTEM:	V2.10
DATE:	Thu Oct 20 13:57:31 MST 1994
FROM:	davis

BUG:	If the sigma parameter was left at its default value of INDEF, a 
	floating point overflow value would result when daofind was run
	from the apphot package.  The problem was the result of a missing
	check for INDEF in the code.

STATUS:	This bug was not a problem for versions of IRAF prior to 2.10.3 BETA
	and has been fixed for the next release of IRAF. The workaround is to 
	set the sigma parameter to some reasonable value.

NUMBER:	267
MODULE:	rv.rvidlines
SYSTEM:	V2.10.3beta
DATE:	Thu Oct 20 14:44:50 MST 1994
FROM:	valdes

BUG:	The intent of this program is that if the header information
	does not exist to compute heliocentric velocities it should
	simply compute observed velocities.  However, the trap for
	this conditions in not correct so instead the program quits.
	The only workaround is to add dummy keywords for those
	missing and ignore the heliocentric results.

STATUS:	Fixed after version V2.10.3beta.

NUMBER:	268
MODULE:	imexpr
SYSTEM:	V2.10.3
DATE:	Tue Oct 25 11:42:52 MST 1994
FROM:	tody

BUG:	The "imexpr @file" way of invoking imexpr doesn't work; imexpr
	reports a syntax error due to the newline at the end of the text
	file containing the expression.

STATUS:	Fixed in the V2.10.3 patch.  To workaround the bug, either put the
	expression on the command line or enter it as a macro function in
	an expression database file.

NUMBER:	269
MODULE:	artdata.gallist
SYSTEM:	V2.9-V2.10.3beta
DATE:	Sat Oct 29 16:56:56 MST 1994
FROM:	valdes

BUG:	The internal absorption model for disk galaxies is not being applied
	as described in the help.  Regardless of the absorption parameter
	there is no absorption correction to the magnitudes of the disk
	galaxies at any inclination.  There is no workaround.

STATUS:	Fixed after V2.10.3beta.

NUMBER:	270
MODULE:	imshift, magnify, xregister, geotran
SYSTEM:	V2.10
DATE:	Fri Dec  9 10:48:34 MST 1994
FROM:	davis

BUG:    Flux may not be conserved when the IMSHIFT, MAGNIFY, XREGISTER, or
	GEOTRAN tasks are run on undersampled data using the spline3
	interpolant.  In the worst case situation, completely undersampled
	data, fractional y shifts of 0.4-0.6, and placement near the top or
	bottom of the data buffer, the discrepancy is ~ +/- 0.3%. For
	well-sampled data the discrepancy is negligible. For y shifts which
	are exactly 0.0 there is no problem.

	The cause of the problem was that the number of edge lines being
	allocated for the spline3 buffers was too small for undersampled
	data and some of the power in the high frequency components of the
	interpolant was being lost.

STATUS:	Fixed for next release of iraf.

NUMBER:	271
MODULE:	photcal.mknobsfile,photcal.mkobsfile,photcal.mkapfile,ptools.pdump
SYSTEM:	V2.10.3BETA
DATE:	Tue Dec 20 10:47:32 MST 1994
FROM:	davis

BUG:	A reference was being to a tables.ttools.tdump task parameter outside
	the loop for processing ST binary tables in the pdump and mkapfile
	scripts, resulting in an "unknown task tdump" error when the tables
	package was undefined or defined incorrectly. The pdump error could
	in turn produce the same error in the mknobsfile and mkobsfile tasks.
	
STATUS:	Fixed for the next release in iraf. The workaround is to install the
	tables package. If this is not feasible contact the iraf group for
	a fix.

NUMBER:	272
MODULE:	dispcor
SYSTEM:	V2.10.3BETA
DATE:	Mon Jan 16 13:01:54 MST 1995
FROM:	valdes

BUG:	When the input spectra are in equispec format (all spectra with the
	same linear dispersion relation) and there are aperture numbers
	which are greater than the number of image lines then the error
	"WFMSPEC: Coordinate out of bounds" may occur.  Such a situation
	will only occur when resampling an an already dispersion corrected set
	of spectra and not when using an IDENTIFY or ECIDENTIFY database.
	This is due to a logical error in the code concerning mapping of
	aperture numbers to line numbers.  The workarounds are to use
	SARITH if simply extracting a region, extract the spectra to
	onedspec format with SCOPY, or change the WCS with:

		cl> hedit <images> cd2_2,cdelt2 1000 update+
		cl> hedit <images> crpix2 1 add+

STATUS:	Fixed for the next release.

NUMBER:	273
MODULE:	dopcor
SYSTEM:	V2.10.3BETA
DATE:	Wed Jan 18 17:22:38 MST 1995
FROM:	valdes

BUG:	For multispec spectra which have independent wavelengths for each
	spectrum (identified by system=multispec in the header) there
	is a bug such that if there are more than 8 spectra the message:

	Warning: MWCS: too many coordinate transformation (ctran) descriptors
	ERROR: segmentation violation

	appears.  Most commonly this will affect echelle data.  The
	workaround is to apply DOPCOR with the aperture parameter
	in groups of 8 or less spectra.  For example:

	    cl> dopcor obj.ec obj1.ec -120 isvel+ add- ap=1-8
	    cl> dopcor obj1.ec obj1.ec -120 isvel+ add- ap=9-16
	    ...

	Note the second and subsequent steps work in place.

STATUS:	This bug, which is a typo in the code, is fixed for a release after
	V2.10.3BETA (possibly the Solaris patch) and V2.11.

NUMBER:	274
MODULE:	doslit (specred, kpnocoude, kpnoslit)
SYSTEM:	V2.10.3BETA
DATE:	Tue Jan 24 13:56:11 MST 1995
FROM:	valdes

BUG:	If the first object spectrum has more than one object on the
	slit and apertures are defined for them then after doing
	the dispersion solution on the reference arc the following
	error occurs:

	    ERROR ... - Missing reference for aperture 2

	This is a bug, introduced in V2.10.3BETA, since the intent of the
	task is to allow multiple apertures per long slit spectrum.  It is
	caused by using the apertures from the first object as the
	apertures for the arc reference.  The workarounds are 1) make the
	first object image be one that has only one aperture (other objects
	can have multiple apertures) or 2) when in IDENTIFY doing the arc
	reference dispersion solutions do 'k' after finishing the
	dispersion solution to step to the other (unnecessary) apertures
	and do a solution with 'a' 'c' and 'f' (all center and fit).

STATUS:	Fixed in later versions.

NUMBER:	275
MODULE:	apnormalize
SYSTEM:	V2.10.3BETA
DATE:	Fri Jan 27 17:16:35 MST 1995
FROM:	valdes

BUG:	In bug numbers 171 and 225 it was noted that when using variance
	weighting or cleaning in APNORMALIZE the result would end up
	scaled by the gain value.  The fix was to divide the result
	by the gain.  However, the default parameters for APNORMALIZE
	do not call for variance weighting or cleaning and so the
	gain and readnoise are not read.  The uninitialized value
	of the gain used to divide the result of APNORMALIZE is
	zero causing a divide by zero error.  The workaround is
	to set the weights paraemter to "variance".  The actually
	weighting and gain and readnoise parameters are not important
	to this algorithm.

STATUS:	This only affects version V2.10.3BETA and will be fixed in
	later versions.

NUMBER:	276
MODULE:	imexamine
SYSTEM:	V2.8-V2.10.2
DATE:	Tue Jan 31 15:06:41 MST 1995
FROM:	valdes

BUG:	The standard deviation values returned by the 'm' key in IMEXAMINE
	can be inaccurate when the mean data value is large and the standard
	deviation is relatively small.  This is due to calculation
	of the standard deviation formula using the difference in the sum of
	squares and the square of the sum with real precision.  The
	workarounds are to use IMSTATISTICS with an image section or
	to first subtract something like the mean value from the image
	before using IMEXAMINE.

STATUS:	In V2.10.3 and after the calculation is done in double precision
	and the standard deviation is as accurate as IMSTATISTICS.

NUMBER:	277
MODULE:	photcal.mknobsfile,mkobsfile,obsfile
SYSTEM:	V2.10.3BETA
DATE:	Thu Feb  9 13:25:36 MST 1995
FROM:	davis

BUG:	The time of observation and airmass columns are switched in the
	output observations file if position matching is turned off,
	resulting in the airmass being written under the otime column
	and vice versa.

STATUS:	Fixed for the next release of iraf. One possible workaround is
	to simply switch the column numbers in the configuration file
	since the number can still be read in correctly.

NUMBER:	278
MODULE:	splot, fitprofs
SYSTEM:	V2.10.3BETA
DATE:	Thu Feb 16 18:17:59 MST 1995
FROM:	valdes

BUG:	The new error estimates for Gaussian profile fitting and deblending
	computed if a noise model is given are incorrect when there is more
	than one line being fit; though they are roughly correct.  This is
	caused by an indexing error such that the error is not always the
	68% (1 sigma) point and the error on a particular line is really a
	mixture of measurements from all the lines.  There estimates are
	valid for single line Gaussian fits.  There is no workaround.

STATUS:	Fixed in subsequent versions.

NUMBER:	279
MODULE:	doslit, doecslit
SYSTEM:	V2.10-V2.10.2
DATE:	Fri Feb 17 10:06:09 MST 1995
FROM:	valdes

BUG:	If no arc image or standard star image is specified an error such as

	ERROR on line 103: OPEN: File does not exist (tmp$iraf1665j)
	    doecslit ()

	will appear.  This is true even if one is not dispersion correcting
	or standard star fluxing.  Thus, even if dispcor=no or fluxcal=no
	you must put a placeholder image name in the arcs and standard
	parameters.

STATUS:	Fixed in V2.10.3 and later such that not specifying arc and standard
	star images is ok if not dispersion or flux calibrating.

NUMBER:	280
MODULE:	sensfunc
SYSTEM:	V2.6-V2.10.3
DATE:	Wed Feb 22 11:18:52 MST 1995
FROM:	valdes

BUG:	Deleted points and deleted stars are not excluded from the grey
	shift calculation.  This is a bug in the sense that this is not
	what most users would expect.  In particular, if a star is
	deleted and it is the one with the highest apparent sensitivity
	one would not expect the rest of the data to be shifted to match
	this deleted star.  For the case of deleting a star and excluding
	it from the grey shift calculation the workaround is to delete
	the data from the input data file.

STATUS:	Deleted points are excluded from the grey shift calculation in
	future versions.

NUMBER:	281
MODULE:	splot
SYSTEM:	V2.10.3beta
DATE:	Thu Feb 23 16:10:43 MST 1995
FROM:	valdes

BUG:	The 't', '/' combination for continuum flattening spectra fails for
	flux calibrated data and instead produces a spectrum which is
	identically 1.  A check to avoid division by zero fails to
	discriminate flux calibrated data (any value less than about 1E-8)
	as different from zero.  The resultant value of 1 is used when
	the divide by zero condition is detected.

STATUS:	Fixed in future releases.

NUMBER:	282
MODULE:	fit1d
SYSTEM:	V2.10.3beta
DATE:	Thu Feb 23 16:16:41 MST 1995
FROM:	valdes

BUG:	The ratio output does not work in V2.10.3beta due to a typo error
	in the code.  The workaround is to output the fit and use
	IMARITH to take the ratio.

STATUS:	Fixed in future releases.

NUMBER:	283
MODULE:	ptools.pexamine
SYSTEM:	V2.10
DATE:	Thu Feb 23 16:23:12 MST 1995
FROM:	davis

BUG:	On Dec Alpha systems pexamine will crash with an invalid floating
	point operation error if the user tries to plot the histogram
	of an array with the h keystroke command.

STATUS:	The problem was caused by a typo in a statement which resulted in
	a memory access of the end of an array. The bug is fixed for the
	next release of iraf. There is no workaround.

NUMBER:	284
MODULE:	photcal.mknobsfile,photcal.mkobsfile
SYSTEM:	V2.10
DATE:	Wed Mar 22 07:56:37 MST 1995
FROM:	davis

BUG:	A very serious problem has been found in the iraf 2.10.3 and digiphotx
	mknobsfile/mkobsfile scripts.  Running mknobsfile/mkobsfile on files
	written by the allstar/nstar tasks (but not the phot task) may corrupt
	the input files. This is definitely not problem for
	mknobsfile/mkobsfile in 2.10.2 and earlier version of iraf or for
	digiphotx linked with versions 1.2.1 and earlier of the tables package.

	The problem crept in when the tables package was modified to support
	text tables.  The error check in mknobsfile/mkobsfile previously
	used to detect whether an input file was a text file or binary
	table began to fail for allstar/nstar files. The code thought the
	text file was a binary table, opened it as such, and attempted to
	edit it. Although the code was smart enough to detect that the
	proper columns etc were not present and did not do any actual editing,
	simply opening and closing the file as a table in READ_WRITE mode
	caused to file to be rewritten and its format corrupted.

STATUS:	This problem has been fixed for the next release of iraf and in the
	forth-coming 2.10.3 patch as well as in the ftp archive version of
	digiphotx. If you are running later versions of tables there is no
	workaround except installing the patch and/or the new version of
	digiphotx. We have confirmed that there is a problem running
	mknobsfile/mkobsfile with tables 1.3.2 and 1.3.3 and that there
	was definitely not a problem with tables 1.2.1 and earlier but are
	not certain of the status of intermediate versions.


NUMBER:	285
MODULE:	echelle.ecidentify
SYSTEM:	V2.9-V2.10.3
DATE:	Tue Apr 11 10:55:54 MST 1995
FROM:	valdes

BUG:	The 'x' key to find a shift between a set of features and the peaks
	in the data fails with a memory access error (i.e. segmentation
	violation).  There is no workaround to use this key though the
	's' key can be used with a known line to set and apply a shift.

STATUS:	Fixed for the next release.

NUMBER:	286
MODULE:	onedspec.sbands
SYSTEM:	V2.10.3
DATE:	Wed Apr 12 09:33:20 MST 1995
FROM:	valdes

BUG:	The output formating for the flux column produces 0.00 when the
	spectra are flux calibrated; i.e. have very small values of
	order 1E-14.  The workaround is to multiply the spectrum by
	an appropriate large number and remember the scaling used.

STATUS:	The formating will be changed to allow exponential notation
	in a future release.

NUMBER:	287
MODULE:	photcal.mkapfile,photcal.apfile
SYSTEM:	V2.10
DATE:	Fri Apr 28 10:00:14 MST 1995
FROM:	davis

BUG:	The filter id keyword read from the input photometry files was
	not being written correctly to the output magnitudes file, resulting
	in a filter id of INDEF for all images.

STATUS:	Fixed for the next release iraf release. There is no workaround.

NUMBER:	288
MODULE:	ptools.pexamine
SYSTEM:	V2.10
DATE:	Mon May  1 09:16:17 MST 1995
FROM:	davis

BUG:	The colon commands :rinner and :router were incorrectly defined as
	:rin and :rout in the pexamine definitions file. In addition the
	new router value was being written back into the rinner parameter,
	a bug that was masked by the previous problem.

STATUS:	Fixed for the next release of iraf. The workaround is to use the
	:epar radplot command and edit the parameter set as a whole.

NUMBER:	289
MODULE:	apscatter
SYSTEM:	V2.9-V2.10.3
DATE:	Wed May  3 16:50:54 MST 1995
FROM:	valdes

BUG:	When not smoothing the scattered light surface along the dispersion,
	smooth=no, and there are multiple apertures the task may abort
	with the error "Range descriptor undefined".  This occurs when
	the number of scattered light  points being fit across the
	dispersion changes as the spacing between apertures changes.
	This is probably a rare event.  The only workaround is to
	add the smoothing along the dispersion.

STATUS:	Fixed in after V2.10.3.

NUMBER:	290
MODULE:	scopy, sarith
SYSTEM:	V2.10.3
DATE:	Sat May 13 13:54:11 MST 1995
FROM:	valdes

BUG:	When spectra are modified with SPLOT and then written out, the
	current display units are also recorded.  SCOPY and SARITH
	incorrectly create new spectra with the dispersion units set to the
	display units.  For units which are linearly related (such as any
	between wavelength units or between energy/frequency units) this
	causes no problem.  However, for other pairs of units, such as
	dispersion units of angstroms but display units of EV, the new
	coordinate system will not match the spectrum pixels.  The
	workarounds are to avoid this situation or change the "units" in
	the copied/output spectrum back to the original units with
	WCSEDIT.

STATUS:	Fixed in V2.10.4

NUMBER:	291
MODULE:	argus.msresp1d, hydra.msresp1d
SYSTEM:	V2.10.2
DATE:	Mon May 22 09:38:27 MST 1995
FROM:	valdes

BUG:	The task MSRESP1D in the ARGUS and HYDRA packages will produce
	an error reporting that there is no param file.  This is caused
	by an error in specifying a directory name.  The workaround
	is either to interactively type the following after loading
	the desired package:

	    ar> redefine msresp1d=specred$msresp1d.cl

	or change the system files argus$argus.cl and hydra$hydra.cl so
	that "msred" becomes "specred".

STATUS:	Fixed in V2.10.3 and later.

NUMBER:	292
MODULE:	imexamine
SYSTEM:	V2.10-V2.10.4
DATE:	Wed May 31 10:08:47 MST 1995
FROM:	valdes

BUG:	The output of the 'x' and 'y' keys is not written to the logfile
	if one is used.  There is no workaround other than copying
	the terminal output in some way.  Note the task RIMCUR can
	be used to get coordinates from an image in both pixel and
	world coordinates.

STATUS:	Fixed in subsequent releases.

NUMBER:	293
MODULE:	register, geotran
SYSTEM:	V2.10
DATE:	Fri Jun  9 16:43:56 MST 1995
FROM:	davis

BUG:	If the xsample or ysample parameters are greater than 1 and
	the nxblock or nyblock parameters are smaller than the image
	dimensions, register/geotran may fail with a memory corruption
	error.

	The error was due to a buffering error in the y coordinate
	interpolation surface.

STATUS:	Fixed for the next release of iraf. The workaround is to set
	xsample and ysample back to 1, which makes coordinate evaluation
	slower for high order surfaces but does not make much difference
	for simple surfaces, or set nxblock and nyblock to be larger than
	the input image size.

NUMBER:	294
MODULE:	photcal.mkapfile,photcal.apfile
SYSTEM:	V2.10
DATE:	Tue Jun 13 17:25:01 MST 1995
FROM:	davis

BUG:	Mkapfile/apfile may terminate prematurely or hang with a floating
	overflow exception if the input data  is such that it is difficult
	to determine a good value for the Moffat function radius parameter
	RO. In this case RO can be driven towards and beyond 0 which produces
	the overflow. 

STATUS:	A check was added to the code to trap this condition and report a
	fitting error. Possible work arounds including upping the default
	number of parameters to be fit from 3 to 4 and/or deleting the
	suspect data from the input file.

NUMBER:	295
MODULE:	dofibers, dohydra, doargus
SYSTEM:	V2.10-V2.10.4
DATE:	Wed Jun 14 14:44:15 MST 1995
FROM:	valdes

BUG:	The use of subapertures does not work and aborts with the error

	    ERROR on line 28: Bad aperture/column/line list

	This is caused by an incorrect aperture range in the script
	code.  There is no workaround other than not use subapertures
	or modifying the script code.

STATUS:	Fixed for the next release.

NUMBER:	296
MODULE:	digiphot.apphot.daofind
SYSTEM:	V2.10
DATE:	Mon Jun 19 09:34:40 MST 1995
FROM:	davis

BUG:	If the datamin parameter is set above the sky level of the image
	the code which computes the x and y positions of the detected
	objects can crash with a floating divide by zero error for the
	fainter objects.

STATUS:	Fixed for the next release of iraf. The workaround is to set the
	datamin parameter to a more reasonable value.

NUMBER:	297
MODULE:	longslit, longslit.identify, longslit.reidentify
SYSTEM:	V2.10.0
DATE:	Mon Jun 19 14:08:46 MST 1995
FROM:	valdes

BUG:	This is a tardy bug report since I noticed this major bug is not
	actually in the bug log.  In the first release of V2.10 there was
	a serious bug in the ONEDSPEC tasks which apply to 2D images such
	as long slit data.  The tools would not access dispersion lines
	beyond 2.  The most common symtom is that IDENTIFY will only
	show lines 1 and 2 in long slit data.  Normally one encounters
	this in the LONGSLIT package.  If one uses a section parameter of
	"middle lines" IDENTIFY will show the image section [*,2].
	REIDENTIFY is similarly limited to the first two dispersion lines.
	There is no workaround other than to upgrade V2.10 to any
	higher version.  It was first fixed in V2.10.1


STATUS:	Fixed in V2.10.1 and later.

NUMBER:	298
MODULE:	onedspec.sbands
SYSTEM:	V2.10-V2.10.4
DATE:	Fri Jun 30 09:25:30 MST 1995
FROM:	valdes

BUG:	When the number of input bandpasses is greater than 10 a segmentation
	violation error occurs.  This is a bug in the memory allocation
	logic of the task.  The workaround is to break up the bandpasses
	into groups of 10 or less (it might work up to 20 but is not
	guarenteed).

STATUS:	Fixed in later versions.

NUMBER:	299
MODULE:	daophot.seepsf
SYSTEM:	V2.10
DATE:	Mon Jul  3 17:24:04 MST 1995
FROM:	davis

BUG:	Seepsf was crashing with a floating operand error if the input psf
	image was a purely analytic function, keyword varorder=-1. This
	error was accidentally introduced when the previous seepsf error
	(bug log # 260) was fixed.

STATUS:	Fixed in 2.11 and in the external addon package digiphotx. One
	possible workaround is make the psf image with varorder=0, then
	make a copy of it setting all the pixel values to 0.0 with
	imarith, and inputing the new image to seepsf.

NUMBER:	300
MODULE:	dispcor
SYSTEM:	V2.10.4
DATE:	Thu Jul 13 11:08:04 MST 1995
FROM:	valdes

BUG:	A new capability was added in V2.10.4 to allow DISPCOR to work
	with IDENTIFY database files containing only a shift and no
	dispersion function.  This would occur when using IDENTIFY to
	compute a shift to previously dispersion corrected spectra.  This
	does not work correctly when there is more than one aperture in an
	image.  The workaround is to separate multiaperture images into
	single aperture images with SCOPY and then do the
	IDENTIFY/REIDENTIFY and DISPCOR.

STATUS:	Fixed in later versions.

NUMBER:	301
MODULE:	daophot.seepsf (Dec Alpha)
SYSTEM:	V2.10
DATE:	Tue Jul 18 10:14:50 MST 1995
FROM:	davis

BUG:	Seepsf will terminate with an FPE error on the Dec Alpha machine
	if the the psf model is not analytic. The problem was caused by
	as missing test which resulted in an out-of-bounds array reference
	in some cases. On other systems the FPE error did not occur
	but pixels outside the psf radius were not being set to 0 as intended
	but were instead were interpolated in the noisy edges of the
	look-up table. Pixels inside the psf radius are correct.

STATUS:	Fixed for the next release of iraf and in the ftp archive version.
	There is no workaround.

NUMBER:	302
MODULE:	apscatter
SYSTEM:	V2.10-V2.10.4
DATE:	Tue Jul 18 17:35:37 MST 1995
FROM:	valdes

BUG:	If the aperture trace functions cross or cause the apertures
	to overlap then the algorithm for finding the scattered light
	pixels outside the apertures gets confused.  This can have the
	consequence of either using data within an aperture or a memory
	error (memory corrupted or segmentation violation).  The workaround
	is to insure the aperture definitions and traces do not behave in
	this way.  One way to check this is with APEDIT after the apertures
	have been defined and traced.  In APEDIT you can examine various
	lines with ":line #" and the data line and apertures will be
	shown.  Look at the first line and last line in particular.  The
	interactive option of APSCATTER selecting various lines can also be
	used though this may crash in the same way.

STATUS:	A different algorithm will be used in the next release to
	correctly find the scattered light points even in the unreasonable
	case where the apertures cross.

NUMBER:	303
MODULE:	rv.fxcor
SYSTEM:	V2.10-V2.10.4
DATE:	Wed Jul 26 15:59:57 MST 1995
FROM:	fitz

BUG:	In rare cases a Gaussian fit would converge to a nonsensical result
	(e.g. a sigma of 3e10) and would cause a "floating overflow" error
	when the results were written out.  The fix requires a trivial
	code change, as a workaround select a different set of points for
	the initial fit by adjusting the 'width' parameter or interactively
	with the 'g' or 'y' keystrokes.

STATUS:	Fixed for the next release.

NUMBER:	304
MODULE:	proto.wcsreset
SYSTEM:	V2.10
DATE:	Tue Aug  1 09:12:11 MST 1995
FROM:	davis

BUG:	Wcsreset was refusing to reinitialize the world coordinate system
	of any image whose world coordinate system was not support by the
	iraf mwcs system, mostly images with unrecognized sky projection
	types.

STATUS:	Fixed in 2.11. There is no workaround except to edit the headers
	directly with hedit or hfix.

NUMBER:	305
MODULE:	apextract tasks
SYSTEM:	V2.10-V2.10.4
DATE:	Wed Aug  2 13:57:09 MST 1995
FROM:	valdes

BUG:	If the image header has an invalid DISPAXIS value, for example
	a value of -9999, there is no warning and bad things happen.  If
	the value is less than 0 then the editing plot will show a flat
	line with an X range 1-2.  If the value is 0 or greater than 2 then
	the aperture axis will be shown as either 1 (for even values) or 2
	(for odd values)  but tracing will fail and extraction will produce
	a floating operand error.  The workaround is to either delete the
	invalid keyword and use the "dispaxis" parameter or fix the image
	header value.

STATUS:	In subsequent releases there will be a warning message and the
	invalid value will be ignored.  The "dispaxis" value will then
	be used.

NUMBER:	306
MODULE:	identify
SYSTEM:	V2.10-V2.10.4
DATE:	Thu Aug  3 13:12:43 MST 1995
FROM:	valdes

BUG:	The rarely used :add command to add lines can cause a segmentation
	violation when exiting.  The results are still valid and the error
	can be ignored.  A workaround is that after adding the lines and
	doing whatever is desired, a stored past solution can be read or an
	intialization be done.

STATUS:	Fixed in later versions.

NUMBER:	307
MODULE:	splot
SYSTEM:	V2.10.3-V2.10.4
DATE:	Fri Aug 11 18:54:55 MST 1995
FROM:	valdes

BUG:	When writing out a spectrum with the 'i' key an error about
	the keyword WAT1_002 not being found or cannot be deleted may
	occur.  Because this occurs in graphics mode the error may flash by
	too fast to see (with XGTERM) and you may be repeatedly prompted
	for an output image.  This loop can only be killed by killing the
	CL.  The cause of this is a bug in SPLOT which occurs if there are
	BANDIDn keywords as produced by extraction with the APEXTRACT
	package.  This problem has been reported with DEC ALPHA but could
	potentially affect any V2.10.3-V2.10.4 system.

	The workaround is to delete the BANDID keywords, which are
	only used for documentation currently, using HEDIT.  You 
	can then use SPLOT and write out modified spectra with 'i'.

STATUS:	Fixed in future versions.

NUMBER:	308
MODULE:	artdata.mkobjects
SYSTEM:	V2.9-V2.10.4
DATE:	Mon Aug 14 09:55:27 MST 1995
FROM:	valdes

BUG:	When using an image either as a PSF model or as an object
	model the result is very subtly wrong in the fluxes.
	The problem showed up when using a symmetrical PSF model
	and the resulting star or galaxy profile was not symmetric
	at a low level.  The measured centroid was off by 0-0.05
	pixels.  This is caused by a numerical precision error
	that occasionally adds an extra subpixel to the flux
	computed for an output pixel.  There is no workaround
	though the effect can be minimized by using a larger
	number of subpixels.  However, the effect is very small
	and simulations with added noise would likely swamp the
	error.

STATUS:	Fixed in later versions.

NUMBER:	309
MODULE:	sfit, continuum
SYSTEM:	V2.10.3-V2.104
DATE:	Tue Aug 15 18:33:59 MST 1995
FROM:	valdes

BUG:	When the capability to select on bands was added the logic to
	check whether all lines and bands have been fit to simple.  The
	effect is that if a subset of lines is fit covering all bands then
	later attempts to fit other lines will fail because the task will
	see that all bands have been done but doesn't realize some
	lines have not been done.  The workaround is to set the
	override parameter to yes.

STATUS:	In later versions the check on the bands is not done.  The user
	is responsible for dealing with multiband data.

NUMBER:	310
MODULE:	daophot.psf
SYSTEM:	V2.10
DATE:	Mon Aug 28 08:55:09 MST 1995
FROM:	davis

BUG:	Using the 'd' or ':d' keystroke commands will cause a segmentation
	violation on Solaris systems and may cause problems on other systems,
	although apparently not on SunOS systems. The problem was caused
	by a subroutine which was being called with an unused output variable 
	set to a constant

STATUS:	Fixed for the next release of iraf. One possible workaround is to
	fit the psf with the 'f' keystroke command and then use the 's'
	or ':s' keystroke command to examine and optinally delete the star.

NUMBER:	311
MODULE:	ccdred.cosmicrays
SYSTEM:	V2.10.3-V2.10.4
DATE:	Mon Sep 25 16:14:16 MST 1995
FROM:	valdes

BUG:	The bad pixel output file is no longer just the coordinates of the
	replaced pixels but it also includes the flux and ratio values.
	These extra columns were intended only for development of the
	interative training option but accidentally were included in the
	release.  The problem this causes is that it is no longer correct
	to simply use this file with ccdred.badpiximage.  The workaround is
	to use the FIELDS tasks to select the first and second columns and
	then use that in BADPIXIMAGE.

STATUS:	The extra output is eliminated in the next release.

NUMBER:	312
MODULE:	slist, bplot
SYSTEM:	V2.10.3-V2.10.4
DATE:	Tue Sep 26 14:27:26 MST 1995
FROM:	valdes

BUG:	A segmentation error may occur when running SLIST and BPLOT (the
	latter calls SLIST).  This error has been reported with LINUX
	IRAF but could occur with other versions.  The output of SLIST
	is correct and the error occurs when the task finishes and
	frees memory.  When running SLIST separately you can just
	ignore the error.  This is more of a problem with BPLOT.
	There is no workaround for BPLOT.  Contact iraf@noao.edu
	for assistance with the BPLOT problem.

STATUS:	Fixed for the next patch or release of IRAF.

NUMBER:	313
MODULE:	badpiximage
SYSTEM:	V2.9-V2.10.2
DATE:	Mon Oct  2 18:10:45 MST 1995
FROM:	valdes

BUG:	If the output bad pixel image is specified as a pixel list format
	image, the .pl extension, the image is likely to contain bad values
	or cause a system exception (segmentation violation or bus error).
	This is due to a problem in the system code that writes the pl
	data to disk.  The workaround is to output the bad pixel
	image in one of the other image formats (such as .imh) and then
	use IMCOPY to copy to the .pl format if desired.

STATUS:	This problem is fixed in V2.10.3 and later versions.  For reference
	see the system notes for imwrpx.x on 3/7/94.

NUMBER:	314
MODULE:	apphot centering routines
SYSTEM:	V2.10.2 and earlier
DATE:	Thu Oct  5 11:15:21 MST 1995
FROM:	davis

BUG:	A bug in the centering algorithms thresholding code resulted in the
	cthreshold parameter being interpreted as the threshold in counts
	above (below) which pixels were used for centering rather than
	the threshold in counts above (below) the local data minimum
	(maximum). The problem occurred because the local data minimum
	maximum was being computed but not entered into the appropriate
	data structure.

STATUS:	This bug is not a problem for 2.10.3 and later versions of apphot
	or for the version of apphot in digiphotx.

NUMBER:	315
MODULE:	photcal.mkapfile
SYSTEM:	V2.10
DATE:	Sat Oct  7 12:04:01 MST 1995
FROM:	davis

BUG:	Mkapfile could terminate prematuringly with a floating divide by zero
	error in interactive mode or a fit did not converge error in non-
	interactive mode, if the input photometry files were binart ST tables.
	The problem was caused by missing commas in the tables column
	template string which resulted in some of the input aperture radii
	not being correctly read in to mkapfile.

STATUS:	Fixed in 2.11 and in the external addon package digiphotx. There is
	no workaround but using input photometry files written in text format
	instead of ST tables will avoid the problem.

NUMBER:	316
MODULE:	images.imcombine, ccdred.combine, onedspec.scombine
SYSTEM:	V2.10 - V2.4
DATE:	Thu Oct 19 12:24:43 MST 1995
FROM:	valdes

BUG:	In the PCLIP rejection option, if more than the maximum number
	of pixels that are allowed to be rejected (set by the nkeep
	parameter) are rejected at some point along the output line then
	for all subsequent pixels in that line the rejection threshold will
	be much higher.  Thus there may be pixels that should be rejected
	but will not be.  The workaround is to set nkeep to zero.  Note
	that since the sigma is estimated based on the difference between
	the median and some percentile pixel you are guarenteed never to
	reject all the pixels.


STATUS:	Fixed in later versions.

NUMBER:	317
MODULE:	dofibers,dohydra,doargus
SYSTEM:	V2.10-V2.10.4
DATE:	Fri Oct 27 11:08:16 MST 1995
FROM:	valdes

BUG:	The option to divide each fiber aperture into subapertures for
	independent dispersion calibration before combining them (that is
	nsubaps > 1) does not work correctly.  The first subapertures are
	all correctly put on the specified same dispersion scale.  However,
	subsequent subapertures are put on a different dispersion scale so
	that combining them is incorrect.  There is no workaround other
	than to not use the subaperture option.  The code change is a
	simple script change.  In files srcfibers$proc.cl and
	srcfibers$batch.cl the value of samedisp (only occurs once in each
	file) in the calls to DISPCOR needs to be changed to a value of
	yes.

STATUS:	Fixed in subsequent versions.

NUMBER:	318
MODULE:	apall, apedit
SYSTEM:	V2.10 - V2.10.4
DATE:	Fri Oct 27 15:34:14 MST 1995
FROM:	valdes

BUG:	When an aperture identification file is used and the user changes
	the aperture number with the 'i' or 'o' keys the beam number of
	the changed aperture was not changed.  This would cause the beam
	number for these apertures to disagree with the aperture
	identification file.  These keys are used when the initial
	guess as the ordering of multiple apertures, such as with
	multifiber data, is off due to a missing initial fiber.  The
	apertures could be correctly reordered with 'o' except for the
	aperture used as the fiducial.  For the reductions which use
	the beam number to identify the type of data (such as in
	DOFIBERS) this will cause the fiducial aperture to possibly be
	treated incorrectly.  The workaround is to use 'o' twice from
	two different apertures or use 'j' to reset the beam number of
	the fiducial aperture.

STATUS:	The software was modified so that an 'i' or 'o' resets the beam
	number to that specified in the aperture identification file
	for the new aperture number.

NUMBER:	319
MODULE:	ptools.tbdump,ptools.pdump
SYSTEM:	V2.10
DATE:	Thu Nov  2 08:59:26 MST 1995
FROM:	davis

BUG:	If the input photometry file is an ST binary table and the expression
	parameter is not equal to "yes", then an intermediate binary
	table file is left in the tmp$ area on task termination. This
	problem was occurring because the script was calling delete instead
	of tdelete, and delete does not know about the .tab extension.

STATUS:	Fixed in the next release of IRAF. There is no workaround except to
	delete the files from the tmp$ directory.

NUMBER:	320
MODULE:	sfit, continuum
SYSTEM:	V2.10-V2.10.2
DATE:	Wed Nov  8 13:54:36 MST 1995
FROM:	valdes

BUG:	If one has a list of images containing multiple spectra per image,
	such as with echelle or multifiber data,
	and one uses the SKIP option for a particular aperture followed
	by selection of skip the spectrum, then instead of just skipping the
	same aperture in all the images it will skip all the spectra in
	all the images.  The report will be a warning that there are no
	spectra to fit in the subsequent images.

	A related bug is that one may not specify a single aperture
	in the list of apertures.

STATUS:	Fixed in V2.10.3 and later.  These bugs were caused by an error in
	the ranges package.

NUMBER:	321
MODULE:	calibrate (in onedspec, longslit, and imred spectral packages)
SYSTEM:	V2.10.3-V2.10.4
DATE:	Mon Dec  4 17:48:49 MST 1995
FROM:	valdes

BUG:	If the AIRMASS keyword is not in the image header but other
	keywords from which the airmass may be computed (RA,DEC,ST or
	DEC,HA) are present, the computation of the airmass is not properly
	returned causing a floating point exception.  Note that if
	it can't compute the airmass at all the user prompted for
	the airmass as intended.

	The workaround is to set the airmass keyword in the header
	using either SETAIRMASS or ASTHEDIT.

STATUS:	Fixed for the next release.

NUMBER:	322
MODULE:	daophot.nstar
SYSTEM:	V2.10.3 and later
DATE:	Fri Jan  5 11:48:10 MST 1996
FROM:	davis

BUG:	In rare circumstances nstar can fail with floating operand errors due
	to a singular fitting matrix. This circumstance is most likely to occur
	when the fitting radius is small, the sky is being refitted, and the
	initial guesses for the parameters to be fit are very poor.

	If a group is too large to be fit, e.g. the group size is greater
	than the value of the maxgroup parameter, nstar may fail with
	memory corruption errors. This occurs because the error code
	array is not being properly reallocated in this circumstance and
	the error code values run off the end of the error code array.

STATUS:	Fixed for iraf 2.11 and in the ftp archive version of digiphot. A
	workaround for the second problem is to increase the value of the
	maxgroup parameter. Tweaking the fitting parameters, e.g. increasing
	the value of fitrad, may workaround the first problem.

NUMBER:	323
MODULE:	scopy, sarith
SYSTEM:	V2.10 - V2.10.4
DATE:	Mon Jan 22 15:06:10 MST 1996
FROM:	valdes

BUG:	When using SCOPY or SARITH with a wavelength range specified
	in the reverse sense of the data and without rebinning a
	segmentation error occurs.  By reverse sense this means if the
	spectra have decreasing wavelength with increasing pixel then the
	limits are specified with the starting pixel less than the ending
	pixel (or vice-versa). The task resamples any and all associated
	spectra such as the sky and sigma spectra.  However, in this
	particular case it was applied without checking whether such
	spectra exist which cause the memory access error.  The workaround
	is to specify the limits in the same sense as the dispersion if the
	direction really doesn't matter or to flip the spectrum with an
	image section.  An example of the last case for a 1D spectrum would
	be:

		cl> scopy spec1[-*] spec2 w1=3600 w2=5600 rebin=no

	where spec1 has decreasing wavelength with increasing pixel.


STATUS:	Fixed in the next release.

NUMBER:	324
MODULE:	photcal.mkapfile,photcal.apfile
SYSTEM:	V2.10
DATE:	Mon Jan 29 17:13:22 MST 1996
FROM:	davis

BUG:	The mkapfile/apfile tasks can go into an infinite loop while
	fitting the seeing radius RO for an image if the input image objects
	are not stars, e.g. are cosmic rays or galaxies.  Objects for which
	there is no good data at all can produce a floating point error in the
	plotting code because the data limits of the plot are not
	being set properly.

STATUS:	Both problems have been fixed for the next release of IRAF and
	in the version of photcal in the external addon package digiphotx.
	For both problems the workaround is to eliminate the bad data
	from the input photometry file.

NUMBER:	325
MODULE:	onedspec tasks, splot
SYSTEM:	V2.10.3-V2.10.4 (before patch 1)
DATE:	Tue Jan 30 10:01:17 MST 1996
FROM:	valdes

BUG:	In V2.10.4 patch 1 the syntax for storing the coordinate system
	keywords (WAT...) was changed such that the closing quote occurs
	at the end of the string rather than the end of the card.  This
	makes the multispec format spectra incompatible with V2.10.3
	and V2.10.4 before patch1 in various tasks such as SPLOT.  The
	behavior is:

        In V2.10.3:
	  ERROR: Unknown coordinate system `multispec''
	In V2.10.4:
	  WARNING: Unknown coordinate system `multispec'' - assuming `linear'.

	In V2.10.3 this is a fatal error while in V2.10.4 this is a warning
	(however it will then not correctly interpret the coordinates).
	The workaround is to edit the image header as follows:

	    cl> hedit <images> wat0_001 "system=multispec x"

	The extra " x" is needed to force a space after the system name.
	After this the data will be compatible with all V2.10 versions.

STATUS:	There is no "fix" to this backward compatibility problem.  When
	moving to earlier versions users must apply the workaround.

NUMBER:	326
MODULE:	identify, ecidentify
SYSTEM:	V2.10 - V2.10.4
DATE:	Thu Feb  8 11:23:32 MST 1996
FROM:	valdes

BUG:	The 'y' key to find all peaks in a spectrum has a bug where none
	or only some of the peaks will be found.  When any peak, found by a
	peak finding algorithm, fails to be centered then all subsequent
	peaks are skipped.  There is no workaround though adjusting
	parameters that control the centering (threshold, fwidth, cradius,
	minsep) and/or decreasing "maxfeatures" to find the strongest
	features which should be less likely to fail.


STATUS:	Fixed for the next release.

NUMBER:	327
MODULE:	apphot interactive tasks
SYSTEM:	V2.10.3 and later
DATE:	Mon Feb 12 14:37:55 MST 1996
FROM:	davis

BUG:	The m keystroke command was performing a "measure next object"
	operation (the n keystroke command) instead of a "move to next
	object operation" as intended.

STATUS:	Fixed for the next release of iraf. The work around is to use the :m
	keystroke command.

NUMBER:	328
MODULE:	images.imexpr
SYSTEM:	V2.10
DATE:	Thu Feb 15 15:34:52 MST 1996
FROM:	davis

BUG:	The imexpr task was incorrectly decoding image name operands of the
	form "#.extension" (where # stands for a number, e.g. 123.imh) and
	"../path/image.extension" (e.g. ../dev/pix.im) as numbers, 123.0
	in the first case, 0.0 in the second.

STATUS:	Fixed for the next release of iraf. The only workaround is to rename
	the image if it has the form "#.extension", and avoid image path
	names that begin with "..".

NUMBER:	329
MODULE:	daophot tasks
SYSTEM:	V2.10
DATE:	Tue Feb 20 15:52:30 MST 1996
FROM:	davis

BUG:	If one of the numerical fields to be read from the input photometry 
	file (e.g. ID) is adjacent to another numerical field and there
	is no white sapce between them, then the numerical field could be
	extracted incorrectly. This most likely to occur when the id numbers
	are large, e.g. 10003, and the image and / or coordinate file name
	begins with a number, e.g. 8649.imh or 8649.coo.1.

STATUS:	Fixed for the next release of iraf. The workaround is to replace
	the numerical part of the image or coordinate file name with an
	alphabetic one of the same length.

NUMBER:	330
MODULE:	imexamine
SYSTEM:	V2.10 - V2.10.4
DATE:	Tue Feb 27 08:49:27 MST 1996
FROM:	valdes

BUG:	The 1D gaussian fitting options,  j and k, do not work with world
	coordinates (wcs = world).   The workaround  is to do the fitting
	in logical coordinates (wcs=logical) and separately translate the
	fit parameters to the desired world coordinates.

STATUS:	Fixed for the next release.

NUMBER:	331
MODULE:	daophot.allstar
SYSTEM:	V2.10
DATE:	Thu Mar  7 13:27:11 MST 1996
FROM:	davis

BUG:	Allstar may crash with a floating point exception error if the
	input readout noise value is exactly zero. The cause of the crash
	is uninitialized memory in the scratch image. Most of the time the
	bug is harmless as the affected pixels are never used in the fitting
	process. However if the affected portion of memory happens to contain
	illegal floating point numbers then a crash may occur. Users are
	most likely to encounter this problem if they run the daophot
	test script daotest, although so far such crashes have only been
	reported for allstar under iraf 2.10.4 on the Dec Alpha.

STATUS:	Fixed for the next release of iraf and in the version of daophot in
	the external addon package digiphotx. The workaround is to set the
	readout noise to a positive number.

NUMBER:	332
MODULE:	apphot.daofind, daophot.daofind
SYSTEM:	V2.10
DATE:	Mon Mar 18 09:06:06 MST 1996
FROM:	davis

BUG:	The is a bug in the daofind centering code which results in incorrect
	fractional pixel corrections being computed for the detected objects.
	This error can most easily be detected by plotting the histogram of
	the fractional pixel corrections for an image with a large number
	of detected objects. The histogram will be modulated at around the
	20% level with "peaks" around the 0.33 and 0.66 fractional pixel
	values.

	This bug is also present in the standalone version of daophot ii.
	Users concerned about this bug should obtain a fix from Peter
	Stetson.

STATUS:	This bug is fixed for the next release of iraf and in the external
	addon package digiphotx version of daofind. There is no workaround
	although it should be emphasized that this bug does not affect
	the centers computed by the psf fitting code in the peak, nstar,
	and allstar tasks. Users concerned with precision in the find
	step should upgrade their software, or recenter the objects with
	the phot "centroid" (fast) or "gauss" (more precise) routines.

NUMBER:	333
MODULE:	daophot.psf
SYSTEM:	V2.10
DATE:	Wed Mar 20 13:59:27 MST 1996
FROM:	davis

BUG:	If the daopars function parameter is set to auto and the best fitting
	function is either moffat25 or moffat15, the psf model look-up tables
	if any will be computed incorrectly. The problem occurs because
	only the 3 fitted parameters (the beta parameter is held fixed) are
	being saved and restored correctly. The array element that should
	hold the fixed beta value is instead occupied by the equivalent
	parameter for the last computed function the penny function.

STATUS:	Fixed for the next release of iraf and in the version of daophot in the
	external addon package digiphotx. The workaround is to run psf twice,
	once to determine the best fitting function (as this is being
	determined correctly), and then again with the function parameter
	set to the selected function.

NUMBER:	334
MODULE:	ccdred.ccdproc
SYSTEM:	V2.10
DATE:	Fri Mar 22 11:43:30 MST 1996
FROM:	valdes

BUG:	If the subset keyword used by CCDPROC (the image header keyword
	defined in the translation file as something such as FILTERS)
	has a value whose first word is longer than 15 characters an error
	will given: "No flat field calibration image of subset ... found".
	The two simplest workarounds are to edit the subsets file
	(the file name is in the CCDRED package parameters) so that
	the translation of the subset string given in the first column is a
	short unique name in the second column.  The other solution is to
	edit the image headers with HEDIT to make the first word of the
	subset string be less than 15 characters.

STATUS:	Fixed for the next release.

NUMBER:	335
MODULE:	tv.imedit
SYSTEM:	V2.9-V2.10.4
DATE:	Tue Mar 26 11:59:02 MST 1996
FROM:	valdes

BUG:	When the search radius is not zero and an aperture center for
	a circular aperture is nearer the bottom or left edge of the image
	than half the radius of the circular aperture the replacement
	region will be incorrectly defined.  This is most apparent with
	constant replacement.  The work-around is to turn off the search
	option (search=0.) or to keep the replacement aperture far
	enough from the edge.

STATUS:	Fixed in the next release.

NUMBER:	336
MODULE:	plot.implot
SYSTEM:	V2.10 - V2.10.4p1
DATE:	Wed Mar 27 09:26:36 MST 1996
FROM:	valdes

BUG:	When line or column from a 2D image which is constant (all pixels
	with the same value) is plotted, selecting another line or
	column with the 'l' or 'c' using the right plot axis does not
	work.  The workarounds are to either use :l or :c to select
	the desired line or set a y range with unequal limits using
	:y.

STATUS:	Fixed in the next release.

NUMBER:	337
MODULE:	images.xregister
SYSTEM:	V2.10
DATE:	Wed Apr  3 14:36:35 MST 1996
FROM:	davis

BUG:	Xregister was dying with a floating point error on the Dec Alpha
	if the coords parameter was defined. 
	
STATUS:	The bug was caused by a type conversion problem in an array reference.
	There is no workaround other than to set the initial shifts using
	the xlag and ylag parameters rather than the coords parameter. This
	bug could potentially cause problems on other machines, although
	so far this has not been observed.


NUMBER:	338
MODULE:	scopy, sarith, dohydra, dofibers, and possibly other onedspec tasks
SYSTEM:	V2.10 - V2.10.4p1
DATE:	Thu Apr 18 11:47:29 MST 1996
FROM:	valdes

BUG:	When working with "multispec" format data (echelle data or
	multiple spectra with different dispersion functions as would
	occur if DISPCOR is used without linearizing the spectra to
	the same dispersion system) the SCOPY and SARITH task
	may fail with a floating point exception.  This is caused
	by use of an uninitialized array.  Because it depends on
	what values are in the array it can be sporatic.  It appears
	to be more likely to occur with the Dec/Alpha/OSF1 version.
	There are other tasks which may, in rare cases, also encounter
	this.  This will only  occur with tasks that are creating a new
	output spectrum.  The workarounds are to avoid cases with differing 
	dispersions in the same image such as by linearizing all
	spectra to the same dispersion function in multifiber or
	multislit data.  This particularly applies to using DOHYDRA and
	DOFIBERS with params.linearize=no.  For echelle data there is no
	good option other than to avoid having to use SCOPY/SARITH after
	dispersion calibration.

STATUS:	Fixed in later versions.

NUMBER:	339
MODULE:	photcal.invertfit
SYSTEM:	V2.10
DATE:	Thu May  2 11:11:20 MST 1996
FROM:	davis

BUG:	Due to a floating point precision problem, the invertfit task could
	occasionally go into an infinite loop on Linux systems.

STATUS:	Fixed for the next release of iraf and in the ftp archive version
	of digiphotx. There is no workaround.

NUMBER:	340
MODULE:	standard
SYSTEM:	V2.10.4p2 Solaris
DATE:	Mon Jun 10 16:47:38 MST 1996
FROM:	valdes

BUG:	In V2.10.4p2 for Solaris there is an optimizer bug in the executable
	for the task STANDARD.  The flux values are incorrectly
	calculated.  This will be seen if the bandpasses are plotted.  The
	boxes will not cover the spectrum.  Other indications of trouble
	will be the flux values in the output data file will be
	monotonically increasing and the sensitivity function solution will
	be odd.  The only workaround is to get a corrected executable (see
	ftp://iraf.noao.edu/pub/x_onedspec.ssolp2.readme).

STATUS:	Fixed for the next release.  Another patch may be considered.

NUMBER:	341
MODULE:	rv.fxcor
SYSTEM:	V2.10
DATE:	Wed Jun 26 16:27:30 MST 1996
FROM:	fitz

BUG:	There is a bug in the rv correction code in which images that do
	not have an OBSERVAT keyword in the header have the heliocentric
	correction computed using KPNO as the observatory regardless of the
	task 'observatory' parameter setting.  The only workarounds are to
	either add an OBSERVAT keyword to each image, or create a dummy
	observatory database where the 'kpno' entry contains the information
	for the observatory you're really using, you would need to define
	an "obsdb" environment variable to this file to make use of it.
	A code change fixing this bug is available from iraf site support.

STATUS:	Fixed for versions after V2.10.4p2

NUMBER:	342
MODULE:	dohydra, doargus, dofibers
SYSTEM:	V2.10-V2.10.4p2
DATE:	Fri Jun 28 16:30:04 MST 1996
FROM:	valdes

BUG:	The fiber extraction task will produce funny results in various ways
	if the "apidtable" file does not have the format

	    aperture  beam  title

	WITH THE TITLE QUOTED if there are blanks in the title.  The problems
	will still only occur if the first part of the title is numeric
	so that the task SAPERTURES, used in the script, interprets the
	value as dispersion information.

STATUS:	This is warning and indication of what to check if funny results
	are obtained.  How problems with bad formating of the file
	can be avoided is under investigation.

NUMBER:	343
MODULE:	apphot.daofind, daophot.daofind
SYSTEM:	V2.10.4 patch2
DATE:	Mon Jul 22 08:29:12 MST 1996
FROM:	davis

BUG:	In rare circumstances daofind can fail with a floating operand
	error. This bug is caused by a divide by zero error in the 
	new (2.10.4 patch2) roundness statistic computation.

STATUS:	Fixed for the next release of iraf and the addon package digiphotx.
	There is no workaround.

NUMBER:	344
MODULE:	imcombine, combine
SYSTEM:	V2.10.2-V2.10.4
DATE:	Thu Aug  1 09:00:22 MST 1996
FROM:	valdes

BUG:	When there are exactly three images, mclip=yes, and scales, zero
	levels, or weights are computed and are not all the same there is a
	bug that will confuse the scales and weights for about 1/6 of the
	pixels.  This becomes more significant as the scales/zeros/weights
	differ more from each other.  This affects computation of the
	weighted average (combine=average) and the sigma clipping
	algorithms (ccdclip, crrej, sigclip, avsigclip, and pclip).
	In addition, even if the scales/zeros are all the same but the
	gains and read noise values are different for the ccdclip or
	crrej algorithms the gains and read noise values will be misapplied
	in 1/6 of the cases.

	The bug is that when mclip=yes the pixels are sorted and the
	idenification of which image each pixel came from is kept.  When
	there are exactly three images an explict sort is done but in one
	of the six possible orders of the 3 pixels the identification
	mapping to the image is wrong for two of the pixels.  Thus the
	wrong scale, zero, weight, gain, or read noise will be used.  If
	they are equal there is no problem but if they are not equal the
	weighted average and the scaling of the sigmas in the clipping
	rejection algorithms will be wrong.  If the values are close there
	is still little error.

	The effects of this are probably negligible in most cases
	unless the scales or CCD parameters of the images are grossly
	different.  The only workaround is to set mclip=no.

STATUS:	Fixed for the next release expected to be V2.11.

NUMBER:	345
MODULE:	rv.rvcorrect, astutil.rvcorrect
SYSTEM:	V2.10
DATE:	Mon Aug 26 21:43:48 MST 1996
FROM:	fitz

BUG:	The KEYWPARS pset is not declared for the RVCORRECT task even though
	it is available for use.

STATUS:	Fixed for versions later than V2.10.4p2.  The workaround is to add the
	line
		keywpars,pset,h,"",,,"Header keyword translation pset" 

	to the file astutil$rvcorrect.par and rv$rvcorect.par. Declarations
	in the help page for RVCORRECT should be made in the 
	rv$doc/rvcorrect.hlp and astutil$doc/rvcorrect.hlp files if needed,
	users can cut-n-paste the entry from the rv$doc/fxcor.hlp page if
	needed.

NUMBER:	346
MODULE:	nmisc.psfmeasure, nmisc.starfocus, nmisc.kpnofocus
SYSTEM:	NMISC V12-p1 and earlier
DATE:	Thu Aug 29 13:32:30 MST 1996
FROM:	valdes

BUG:	If the scale parameter is set to other than one and the PSF
	being measured is sufficiently small then the computed PSF
	sizes will be incorrect.  The workaround is to use a scale
	of 1 to compute widths in pixels and then convert to some
	other scale separately.

STATUS:	Fixed in NMISC V12-p2

NUMBER:	347
MODULE:	noao.rv.fxcor
SYSTEM:	V2.10p2 and earlier
DATE:	Thu Sep 12 14:52:16 MST 1996
FROM:	fitz

BUG: 	The normalized reference spectrum was being copied from the object
	spectrum when the image names were the same as a form of optimization.
	This could fail in cases where the 'n' key was used to move through
	a list to get the next object and the object spectrum was previously
	rebinned at a different dispersion causing artificial shifts in 
	the data.  The code was modified to always compute a normalization
	to avoid this in all cases.  Workarounds include rebinning all
	spectra to a common dispersion or setting the 'rebin' param to be
	'object'.

STATUS:	Fixed in versions after V2.10.4p2.

NUMBER:	348
MODULE:	artdata.mkobjects
SYSTEM:	V2.10-V2.10.4p2
DATE:	Tue Oct  1 10:35:05 MST 1996
FROM:	valdes

BUG:	The routine for computing Poisson deviates does not check for
	negative input values which can lead to a floating point
	exception.  This routine can be called with negative values if the
	objects being created have negative values and the "poisson"
	parameter is yes.  Negative values in the model objects can occur
	if image template models are used either for the objects or for the
	PSF.  The workarounds are to make sure the object models do not
	have negative values, to use a "background" parameter sufficiently
	large to make the object+background be non-negative, or to not add
	Poisson noise.  The first option is the rigorously correct
	solution.  The case that identified this bug was with an
	empirically generated PSF that produced some negative values at the
	edge of the PSF template.

STATUS:	The Poisson deviate routine now returns zero if the input
	Poisson mean is negative.

NUMBER:	349
MODULE:	astutil.pdm
SYSTEM:	-V2.10.4p2
DATE:	Tue Oct  1 16:49:49 MST 1996
FROM:	valdes

BUG:	When there are fewer than 100 input data points the calculation of
	theta is incorrect.  This is because the calculation does not take
	into account use of overlapping period bins for the small N case.
	The theta plot values will be incorrect (negative) but the shape
	appears to be approximately correct.  It is not clear how the error
	acts in detail.  One workaround is to increase the number of data
	points, say by replication, to greater than 100 points.  Note that
	the shape of the theta curve will be different even if the error
	was not present because of the change in binning from overlapping
	bins to non-overlapping bins.

STATUS:	Fixed for the next release.

NUMBER:	350
MODULE:	echelle.doecslit
SYSTEM:	V2.10.4
DATE:	Thu Oct  3 13:29:40 MST 1996
FROM:	valdes

BUG:	In V2.10.4 the batch option of DOECSLIT does not work.  The
	workaround is to run DOECSLIT with the batch option turned on
	until it tries to run the background processing and fails with
	an error.  At this point all the interactive things have been done.
	Now run DOECSLIT directly in the background with:

	    ec> doecslit <images> splot- >& dev$null&

	Be sure the list of images is the same or at least includes
	images previously used in the interactive step.

STATUS:	Fixed for the next release.

NUMBER:	351
MODULE:	center1d
SYSTEM:	V2.9-V2.10.4
DATE:	Thu Oct 24 13:11:29 MST 1996
FROM:	valdes

BUG:	This subroutine algorithm is used in many places such as APFIND,
	APRECENTER, APEDIT, APTRACE, IDENTIFY, REIDENTIFY, ECIDENTIFY, and
	ECREIDENTIFY (and possibly more).  One feature of this algorithm is
	that if the centering width parameter is less than or equal to one
	pixel it will find the nearest local maximum (minimum) to the
	starting point.  The bug was that unless the starting point is a
	local minimum (maximum) it would simple return the nearest pixel to
	the starting point.  There is no workaround.

STATUS:	Fixed for the next release.

NUMBER:	352
MODULE:	starfocus, kpnofocus
SYSTEM:	nmisc external package earlier than V12-p3
DATE:	Thu Oct 24 17:27:55 MST 1996
FROM:	valdes

BUG:	The routine that fits a parabola to the three lowest points when
	estimating the best FWHM could crash or give poor results when
	the focus values are large.  For example focus values around
	10000.  The workaround is to use focus values which are
	small (less than 1000).

STATUS:	Fixed in NMISC V12-p3

NUMBER:	353
MODULE:	astutil.pdm
SYSTEM:	-V2.10.2
DATE:	Wed Nov  6 11:32:16 MST 1996
FROM:	valdes

BUG:	PDM will only draw graphs with points.  The points are often very
	difficult to see.  There is a parameter, which is not documented
	in the help page up to V2.10.4p2, called "pluspoint" that is
	supposed to define the maximum number of data points for which
	plus symbols are used before going to points.  However there
	is a bug that prevents this feature from working.

STATUS:	The pluspoint parameter works in V2.10.3 and later and is documented
	in versions later than V2.10.4p2.

NUMBER:	354
MODULE:	scombine
SYSTEM:	V2.10-V2.10.4p2
DATE:	Mon Nov 11 11:39:41 MST 1996
FROM:	valdes

BUG:	The option to use image header keywords for the scale, zero,
	and weight values by specifying the parameter values as
	"!<keyword>" does not work.  The symptoms are either an error that
	the image header keyword does not exist or all the scale, zero, or
	weight values come out the same.  The workaround is to put the
	values into a file and use the file input option.  For example one
	cannot use 'weight="!wtkeyword" but one can do the following:

	    on> hselect <spectra> wtkeyword yes > wts
	    on> scombine <spectra> weight="@wts"

	where <spectra> are the list of spectra and "wtkeyword" is the
	keyword in the images to use for the weights.

STATUS:	Fixed for the next release.

NUMBER:	355
MODULE:	apall, apsum
SYSTEM:	V2.10-V2.10.4p2
DATE:	Tue Nov 12 16:36:10 MST 1996
FROM:	valdes

BUG:	If dispaxis=1 and using cleaning or variance weighted extraction
	with a gain > 1 and with a large number of apertures which have
	differing widths it is possible to get a floating overflow error.
	The workarounds are to either multiply the images by the gain
	and then set the gain to 1 for the extraction or transpose
	the images so that dispaxis=2.

STATUS:	Fixed in the next release.

NUMBER:	356
MODULE:	splot
SYSTEM:	V2.10.4 (including p1 and p2)
DATE:	Tue Dec  3 12:02:39 MST 1996
FROM:	valdes

BUG:	Any units string in the "units" parameter that contains whitespace,
	such as "km/s 400 ang" "inv cm", will fail to be recognized.  This
	is because the whitespace is removed to check for a null string.
	This means such units cannot be specified for SPLOT to start up
	with.  The work around is to change the units interactively
	with :units.

STATUS:	Fixed for the next release.

NUMBER:	357
MODULE:	splot
SYSTEM:	V2.10-V2.10.4p2
DATE:	Fri Jan 10 16:33:32 MST 1997
FROM:	valdes

BUG:	The 'a' key for expanding a region with y scaling based on the
	values in the selected region can be wrong if the dispersion is
	non-linear.  This is because the inversion from dispersion
	coordinate to pixel is done assuming a linear dispersion.  The
	symptom is that the y scale will not cover the data.  If the data
	is sufficiently sloped and the dispersion sufficiently non-linear
	it is possible the graph window will be outside the range of the
	data yielding an empty plot.  The workaround is to use the 'w'
	windowing keys such as 'e'.

STATUS:	Fixed for the next release.

NUMBER:	358
MODULE:	dofibers, dohydra, doargus
SYSTEM:	V2.10-V2.10.2
DATE:	Wed Jan 15 09:32:23 MST 1997
FROM:	valdes

BUG:	When there are more than 127 fibers and the aperture identification
	file has titles for all the fibers these script tasks will fail
	either with a segmentation violation or the error
	"Too many field names in image header field name template".
	This is caused by calls to SCOPY and SARITH in the scripts
	which trigger the previously recorded Bug #241.  The only
	work around is to not use aperture titles.  At the end of
	the processing one may associate titles with the apertures
	using SAPERTURES.

STATUS:	Fixed in version 2.10.3.

NUMBER:	359
MODULE:	calibrate (onedspec, longslit, imred spectral packages)
SYSTEM:	V2.10.3-V2.10.4p2
DATE:	Wed Jan 22 11:18:52 MST 1997
FROM:	valdes

BUG:	The flux calibration of spectra with non-linear dispersion is
	incorrect.  Instead of dividing by the wavelength width of each
	pixel the width of the pixel corresponding to the image line is
	used for all pixels at a given line; (i.e. the width of pixel 2 is
	used for all pixels in the spectrum of the second line in a
	multispec image).  Since a linear dispersion has constant pixel
	width by definition, this bug does not affect linearized spectra.
	The magnitude of the error depends on how non-linear the dispersion
	is; i.e.  how much the widths of the pixels vary.  The workaround
	is to linearize the spectra first with DISPCOR.

STATUS:	Fixed for the next release.

NUMBER:	360
MODULE:	splot
SYSTEM:	-V2.10p2
DATE:	Thu Feb  6 15:53:00 MST 1997
FROM:	valdes

BUG:	Equivalent widths and line fluxes measured with the 'e' and 'h' keys
	will have the wrong sign if the wavelength increment per pixel in
	the spectrum image is negative; i.e. the dispersion units decrease
	with increasing pixel number.  This is because these quantities are
	computed in pixels and then converted to wavelength units by
	multiplying by the wavelength increment per pixel rather than the
	absolute value.  Note that SPLOT always plots with dispersion units
	increasing to the right whether or not the actual order of pixels
	in the image has increasing or decreasing wavelength with
	increasing pixel number.  The only error is one of sign and the
	workaround is to take account of this sign error when reporting
	equivalent widths.  The convention is that absorption lines have
	positive equivalent widths.

STATUS:	Fixed for the next release.

NUMBER:	361
MODULE:	scombine
SYSTEM:	V2.10.3-V2.10.4p2
DATE:	Wed Feb 19 11:19:14 MST 1997
FROM:	valdes

BUG:	If several multispec images with the "equispec" coordinate system
	(headers "WAT0_001 = 'system=equispec'" and with APNUM keyword)
	are being combined by aperture where the set of apertures in each
	image are not the same and if the first image in the input list
	does not contain all the apertures then an error about a missing
	aperture will occur.  For example:

	    ERROR: Image header parameter not found (APNUM79)

	More precisely, the problem occurs if the output image will
	have more apertures than in the first input image.

	The workarounds are to either put an image which has all the
	apertures first in the input list or use the "aperture" parameter
	to select fewer or an equal number of apertures to the first
	image.  For example:

	    cl> scombine a,b,c,d out1 apertures=1-50
	    cl> scombine a,b,c,d out2 apertures=51-100
	    cl> scopy out1,out2 out

	where the input images contain apertures 1 to 60 but there with
	missing apertures in each image.  Image a has 50 apertures.
	Note that it is alright to specify apertures that do not exist
	as long as the number of existing apertures does not exceed
	the number in the first input image.

STATUS:	Fixed for the next release.

NUMBER:	362
MODULE:	daophot.pstselect, daophot.psf
SYSTEM:	V2.10
DATE:	Fri Feb 21 13:17:11 MST 1997
FROM:	davis

BUG:	The pstselect and psf task were not reinitializing the psf star list
	correctly when more than one image was being analyzed in a single
	execution of either task. In the case of pstselect, psf stars whose ids
	were identical to the ids of psf stars in previous images were being
	arbitrarily rejected from the psf star list. In the case of psf, psf
	stars from previous lists could be retained in the list, although
	this was unlikely because the positions and magnitudes would usually
	result in the star being severely down-weighted or rejected from the
	fit.

STATUS:	Fixed for 2.11 and in the ftp archive version of the addon package
	digiphotx. The workaround is to use pstselect and psf on a single
	image at a time.  The z keystroke command in the psf task will also
	reinialize the list properly.

NUMBER:	363
MODULE:	dispcor
SYSTEM:	V2.10.2-V2.10.4p2
DATE:	Tue Mar  4 09:17:37 MST 1997
FROM:	valdes

BUG:	Input spectra which are in two dimensional images, have an "equispec"
	coordinate system, and log sampled (DC-FLAG=1), are not properly
	resampled by DISPCOR.  One dimensional images and "multispec"
	coordinate systems do not have this problem.  The workaround is to
	convert all the spectra to one dimensional images with SCOPY and
	format="onedspec".

STATUS:	Fixed for the next release.

NUMBER:	364
MODULE:	onedspec
SYSTEM:	V2.10-V2.10.4p2
DATE:	Tue Mar  4 11:55:48 MST 1997
FROM:	valdes

BUG:	The coordinate function driver, the system software that evaluates
	coordinates, for multispec format spectra incorrectly inverts
	wavelengths to pixels for the case of log sampled coordinates
	with a doppler shift.  This will cause various tasks to misbehave
	such as equivalent width measurements in SPLOT.  The log
	sampling occurs when using DISPCOR with log=yes and the doppler
	shift is added to the coordinate system when DOPCOR is run.
	The workaround is to not run DOPCOR on log sampled multispec
	spectra (such as echelle data) and correct any measurements
	made for doppler shifts after the fact.  To determine if
	you have this type of format you will "specN=" strings in
	WAT keywords.  In these strings the third number will be 1
	for log sampling and the seventh number will be non-zero
	for the doppler correction.

STATUS:	Fixed in the next release.

NUMBER:	365
MODULE:	apall, apsum
SYSTEM:	V2.10.4
DATE:	Wed Apr  2 12:27:20 MST 1997
FROM:	valdes

BUG:	The "strip" format option may fail with the error

	    No write permission on file (String_File)

	Unfortunately there is no workaround for this error.
	Contact iraf@noao.edu for a fix.

STATUS:	Fixed for the next release.

NUMBER:	366
MODULE:	implot
SYSTEM:	V2.10.4 Dec Alpha OSF1
DATE:	Thu Apr  3 11:36:07 MST 1997
FROM:	valdes

BUG:	Attempting to plot a 3D image, even if the third dimension is only
	1 (i.e. [512,512,1]), results in "ERROR: FPE" on Dec Alpha/OSF1.
	This does not occur on the Sun versions.  The workaround is
	to use an image section:

	    cl> implot im3d[*,*,1]

STATUS:	To be fixed in a future version.

NUMBER:	367
MODULE:	images.tv.tvmark
SYSTEM:	V2.10
DATE:	Thu Apr 17 15:02:40 MST 1997
FROM:	davis

BUG:	The 'a' keystroke command can produce a segmentation violation
	when 1) the coordinates file does not exist at task startup time,
	and 2) the label parameter is set to "yes". So far this bug
	has only been reported on Sun Solaris systems.

	The bug is due to a failure to initialize the label string to ""
	in the call to the routine which actually draws the mark.

STATUS:	Fixed for the next release of IRAF. The workaround is to create
	an empty coordinates file before starting tvmark or to avoid
	use of the label feature.

NUMBER:	368
MODULE:	images.geotran
SYSTEM:	V2.10
DATE:	Tue Apr 29 16:46:38 MST 1997
FROM:	davis

BUG:	Geotran fails if the user: 1) sets any of xmin, xmax, ymin, ymax
	explicitly, and 2) xmin > xmax or ymin > ymax. The failure is
	occuring because the computed number of columns or lines is
	negative in that case.

STATUS:	Fixed for 2.11. The workaround is to always ensure that xmin < xmax
	and ymin < ymax and perform any image flipping after the fact.

NUMBER:	369
MODULE:	images.median,images.mode
SYSTEM:	V2.10
DATE:	Fri May 16 10:22:26 MST 1997
FROM:	davis

BUG:	The pixels in alternating lines on the far right side of an image
	may be in error due to a bug in the merge-sort algorithm indexing
	code that is triggered when the sliding median filter turns the
	corner.

STATUS:	This bug is fixed in iraf 2.11 and was never a problem for the median
	and mode tasks in the mfilters addon package or in any of the other
	mfilters tasks.

NUMBER:	370
MODULE:	standard
SYSTEM:	V2.10-V2.10.4
DATE:	Tue May 27 10:09:21 MST 1997
FROM:	valdes

BUG:	The task is supposed to only include bandpasses which are entirely
	within the spectrum data.  However, this turns out not to be the
	case and partial bandpasses are used without any corresponding
	correction to the calibration fluxes.  This means the end points
	may cause a spurious behavior in the sensitivity function
	calculation unless the endpoints are ignored.  The workarounds
	are either to delete the points in the standard data file or
	when fitting the sensitivity function in SENSFUNC.

STATUS:	Fixed for V2.11.

NUMBER:	371
MODULE:	apphot.daofind, daophot.daofind
SYSTEM:	V2.10
DATE:	Tue Jun 24 10:50:44 MST 1997
FROM:	davis

BUG:	Daofind can fail with a divide by zero error in rare cicumstances
	due to a failure to trap a potential divide by zero in the
	x and y centering code. The problem is most likely to occur if
	the detection threshold is very low, or if very bad values of
	sigma, gain, or readout noise are supplied.

STATUS:	Fixed for 2.11.

NUMBER:	372
MODULE:	images.imexpr
SYSTEM:	V2.10
DATE:	Mon Jun 30 10:00:41 MST 1997
FROM:	davis

BUG:	Expressions involving the J, K, etc operands may be evaluated
	incorrectly if the I operand does not preceed them in the expression.

STATUS:	Fixed for 2.11. The workaround is to include a dummy term containing
	I in the expression, e.g. 0.0 * I, before the J, K, etc appear.

NUMBER:	373
MODULE:	longslit.response
SYSTEM:	V2.11Beta
DATE:	Thu Jul 10 11:47:18 MST 1997
FROM:	valdes

BUG:	The Beta version of V2.11 has a bug such that if the dispersion
	axis is 1 and the threshold parameter is not INDEF then the
	resulting response image will be incorrect.  The error is a typo
	that reversed the column and line indices in the division by the
	normalization spectrum.

STATUS:	Fixed for the V2.11 release.

NUMBER:	374
MODULE:	sarith
SYSTEM:	V2.10-V2.11Beta
DATE:	Tue Jul 15 10:27:11 MST 1997
FROM:	valdes

BUG:	The power option ^ does not work.  The workaround is to use
	the multiple steps of taking the log, multiplying, and taking
	the anti-log.

STATUS:	Fixed in V2.11.

NUMBER:	375
MODULE:	images.xregister, immatch.xregister
SYSTEM:	V2.10
DATE:	Fri Jul 25 14:59:18 MST 1997
FROM:	davis

BUG:	The xregister task was failing if: 1) the correlation parameter was
	set to "fourier" and, 2) at least one of the correlation regions was
	entirely off the input image. If this circumstance occurred all
	subsequent region shifts for the current and succedding images
	are set to INDEF, and if all the shifts for a given image were
	INDEF, the total shift was set to 0.0.

STATUS:	Fixed in 2.11 and in the version of the external addon package
	immatch, now renamed to immatchx.

NUMBER:	376
MODULE:	images.imhistogram, plot.phistogram
SYSTEM:	V2.10
DATE:	Thu Jul 31 16:08:51 MST 1997
FROM:	davis

BUG:	Images with pixel values outside the legal integer range can produce
	invalid floating point operation errors in the imhistogram and
	phistogram tasks in some circumstances.

STATUS:	Fixed for 2.11. In most but not all cases modifying the histogram
	binning parameters z1 and z2 will work around the problem.

NUMBER:	377
MODULE:	splot, identify, and all onedspec tasks operating on 2D images
SYSTEM:	V2.10.3-V2.11beta
DATE:	Wed Aug  6 14:39:37 MST 1997
FROM:	valdes

BUG:	Beginning with V2.10.3 the ONEDSPEC tasks allow using previously
	transposed 2D images.  However if the image is also flipped, say
	with the command:

	    cl> imtranspose im1[-*,*] im2

	then these tasks can fail with an arithmetic error such as
	"floating operand" depending on the dispersion axis.  The
	workaround is to reset the physical and/or world coordinates with
	WCSRESET.

STATUS:	Fixed for V2.11.

NUMBER:	378
MODULE:	onedspec.sfit, onedspec.continuum
SYSTEM:	V2.10-V2.11
DATE:	Wed Sep  3 10:56:08 MST 1997
FROM:	valdes

BUG:	When there is an error accessing an input image, such as specifying
	a non-existant image, the error given is:
	    ERROR: With range specification for `lines or bands'
	This is due to the structure of the program that first uses the
	the image sizes to set the acceptible limits of the lines and
	bands to be fit.  If there are no images the limits are zero
	lines and bands and the above error occurs.

STATUS:	This bug log documents the behavior as of V2.11.  Modifications have
	yet to be determined.

NUMBER:	379
MODULE:	plot.phistogram
SYSTEM:	V2.11
DATE:	Sat Oct  4 14:58:58 MST 1997
FROM:	davis

BUG:	Phistogram fails with a segmentation violation for text file input.
	This bug was inadvertantly introduced by the fixmade to bug 376.

STATUS:	Fixed for the next release of IRAF. There is no workaround.

NUMBER:	380
MODULE:	imcombine/combine
SYSTEM:	V2.11
DATE:	Tue Oct 21 14:09:34 MST 1997
FROM:	valdes

BUG:	With STF format images (GEIS files) there is a limit of 58 images
	that can be combined.  More than this will produce a cannot
	open file error on an image.  The workaround is to either
	convert the images to another format or stack the images
	using IMSTACK and then combine with the "project" option.


STATUS:	Fixed for the next patch or release.

NUMBER:	381
MODULE:	dimsum
SYSTEM:	V2.11
DATE:	Wed Oct 22 09:20:46 MST 1997
FROM:	valdes

BUG:	When using DIMSUM with V2.11 you must have image type inheritance
	enabled; for example 'reset imtype="imh,inherit"'.  This may
	be set in your login.cl or loginuser.cl or on the command line
	(type "flpr" when resetting on the command line).  If inheritance
	is not enabled then mask files will be converted to non-mask
	files causing the reductions to fail.

STATUS:	A solution is being determined.

NUMBER:	382
MODULE:	splot
SYSTEM:	V2.11
DATE:	Thu Oct 23 09:23:46 MST 1997
FROM:	valdes

BUG:	When doing a profile fit on data that has negative values and
	using the default INDEF values for sigma0 and invgain that turn off
	error computations the error message "Cannot compute errors with
	non-zero gain and negative pixel values" is produced.  The warning
	can be ignored.  To eliminate it (remembering that this only occurs
	with negative values in the spectrum) the workaround is to set
	invgain to zero and sigma0 to a positive value.

STATUS:	This is fixed for a future patch or release.

NUMBER:	383
MODULE:	dataio.rfits
SYSTEM:	V2.11
DATE:	Tue Nov  4 09:38:35 MST 1997
FROM:	davis

BUG:    Header listing as slow because rfit is reading through the data instead
	of skipping it if: 1) the make_image parameter is no, 2) there are
	no fits extensions in the file, and 3) the tapecap parameter fe is
	undefined. This bug affects the 2.11 version of rfits only, and was
	introduced when support for fits image extensions was added.

STATUS:	Fixed for the next release of iraf. If fast header listing is required
	the workaround is to use the old version of rfits, orfits in the
	obsolete package.

NUMBER:	384
MODULE:	artdata: mkobjects, mknoise, mk2dspec
SYSTEM:	V2.9 - V2.11
DATE:	Wed Nov 19 10:40:55 MST 1997
FROM:	valdes

BUG:	The ARTDATA tasks which can record comments from an input data
	file in the image header will produce improper headers if the input
	data has tab characters.  The consequence of this only affects FITS
	files produced directly through the FITS kernel or using WFITS to
	write a FITS file from some other image format.  Such FITS files
	will have malformed headers and when using the FITS kernel a possible
	error is "Pixel storage file is truncated".  The most common
	way this problem can occur is with MKOBJECTS using object lists
	produced by STARLIST or GALLIST which generate comments with tab
	characters in them.  The workarounds are to turn off the "comments"
	parameter in the task to eliminate the writing of the data file
	comment information to the header or not producing a FITS file from
	the created image.

STATUS:	Fixed after the initial V2.11 release.

NUMBER:	385
MODULE:	dataio.import
SYSTEM:	V2.11
DATE:	Fri Dec 12 13:43:33 MST 1997
FROM:	fitz

BUG:	Use of the red(), green(), or blue() functions in the outbands
	expression parameter can cause the size of the output image to
	be incorrectly computed, resulting in a "Negative or zero length
	dimension" error.

STATUS:	Fixed for the next patch or release.  There is no workaround.

NUMBER:	386
MODULE:	immatch.linmatch
SYSTEM:	V2.11
DATE:	Mon Dec 15 12:24:52 MST 1997
FROM:	davis

BUG:	Linmatch could crash with a floating operand error if the bscale scaling
	algorithm was one of "mean", "median", or "mode", and the reference
	image contained one or more regions with a zero-valued mean, median,
	or mode. The error was in the computation of the error in the bscale
	value.

STATUS:	Fixed for the next release of iraf. The only work around is to choose
	the regions used for scaling carefully.

NUMBER:	387
MODULE:	identify,autoidentify,reidentify
SYSTEM:	V2.10.4 - V2.11.1
DATE:	Mon Jan 12 14:39:26 MST 1998
FROM:	valdes

BUG:	If the coordinate list has duplicate values it is possible to
	get a floating divide by zero error when using the automatic
	line identification algorithm.  For example using the 'x'
	key in IDENTIFY or using the autoidentify algorithm in
	REIDENTIFY.

STATUS:	A change in V2.11.2 eliminates duplicate lines automatically as
	well as no longer requiring the line lists to be sorted.

NUMBER:	388
MODULE:	doecslit
SYSTEM:	V2.10-V2.11.1
DATE:	Tue Jan 27 10:54:07 MST 1998
FROM:	valdes

BUG:	If dispcor=no, splot=no, and batch=yes, so the task will go directly
	to batch extraction without needing to do any dispersion calibration,
	the following error will occur.

	ERROR on line 475: Attempt to access undefined local variable `arcref'.

	This is due to failing to initialize this variable when dispcor=no
	but attempting to pass it's value to the batch stage.  The
	workaround is to not use batch execution in this case.

STATUS:	Fixed for a future release.

NUMBER:	389
MODULE:	proto.fixpix
SYSTEM:	V2.11-V2.11.1
DATE:	Thu Jan 29 16:27:19 MST 1998
FROM:	valdes

BUG:	Depending on the details of the regions being fixed and the
	interpolation directions it is possible that some regions that are
	specified to be fixed will not be fixed.  This is caused by
	subtleties of how the image is both read and written during the
	processing.  The only workaround is to try doing the fixing in
	several steps; such as by going back to the regions that were not
	changed and using FIXPIX with the regions separated to one at a
	time.

STATUS:	This is fixed for the next release.

NUMBER:	390
MODULE:	dataio.export
SYSTEM:	V2.11
DATE:	Mon Feb  2 19:46:41 MST 1998
FROM:	fitz

BUG:	The outbands expression

	    setcmap(zscale(i1,@"i_minpixval",@"i_maxpixval"),"heat")

	will fail to find the colormap name properly because of a confusion
	in counting the quotes when parsing the expression resulting in a 
	"Cannot open requested colormap file" message.

STATUS:	Fixed in V2.11.2.  A code change is required to fix this bug.  As a
	workaround users can first use export to create an IRAF image of
	the scaled values, and then again to apply to colormap.  For example

	    cl> export dev$pix foo imh \
	    >>>     outbands="zscale(i1,@"i_minpixval",@"i_maxpixval")"
	    cl> export foo bar gif outbands="setcmap(i1,"heat")

NUMBER:	391
MODULE:	splot, fitprofs
SYSTEM:	V2.10-V2.11.1
DATE:	Thu Feb 12 10:29:40 MST 1998
FROM:	valdes

BUG:	A mixture of profile types in deblending or profile fitting
	may result in a floating point error.  The only mixture that
	will work is if the first profile is "voigt".  So what works is all
	profiles of the same type or voigt first plus anything else.  This
	means the only combination that will not work and for which there
	is no workaround is a combination of "lorentz" and "gaussian".

STATUS:	Fixed in the next release.

NUMBER:	392
MODULE:	splot, fitprofs
SYSTEM:	V2.10-V2.11.1
DATE:	Thu Feb 12 11:01:44 MST 1998
FROM:	valdes

BUG:	This is an amendment to buglog 391.  The error reported in buglog
	391 will only occur when computing errors with the bootstrap
	method.  The fitting without the error computation can use any
	combination of profiles.

STATUS:	The error is fixed in the next release.

NUMBER:	393
MODULE:	rv.fxcor
SYSTEM:	V2.11.1
DATE:	Tue Feb 17 14:57:11 MST 1998
FROM:	fitz

BUG:	When computing a deblended fit to the correlation peak the task
	may trigger a "floating overflow" exception when quitting the
	deblending routine.

STATUS:	The bug occurs only when the velocities for each component cannot
	be computes and are returned as INDEF values.  Starting with V2.11
	the double-precision value of INDEF was changed to 10e308 and will
	cause an overflow when it's converted to real when saving values in
	the task structure.  A code change is required to fix this.  As a
	workaround be sure that all necessary keywords are in the image
	header prior to the correlation so velocities can be computed.  A
	list of missing keywords is printed in the verbose output listing
	generated by the 'v' keystroke when the 'verbose' parameter is
	'long' or 'txtonly', use the initial fit of a single function to
	get these keywords prior to deblending.

	Fixed for the next release.

NUMBER:	394
MODULE:	apall, apsum
SYSTEM:	V2.11 - V2.11.1
DATE:	Thu Feb 19 15:11:13 MST 1998
FROM:	valdes

BUG:	When the output format is "echelle" and the "extras" information is
	produced (extras=yes and background subtraction or cleaning or
	variance weighting) then the header information may come out
	for a 2D images instead of a 3D image.  The consequence of this
	is that SPLOT or other ONEDSPEC tasks will not be able to find
	and use the extra data.  This appears to happen with Solaris
	and not with SunOS so there is some system dependence on whether
	this happens or not.  The workaround is to edit the header to
	change WCSDIM to 3 and add the keywords CD3_3 and LTM3_3 with
	value of 1:
	    
	    cl> hedit <ec images> wcsdim 3
	    cl> hedit <ec images> cd3_3 1.
	    cl> hedit <ec images> ltm3_3 1.

	Another workaround is to set the output format to "multispec"
	instead of "echelle".  If nsubaps=1 then there is no difference
	except for the image name extension between the two formats.

STATUS:	Fixed for the next patch or release.

NUMBER:	395
MODULE:	IMFORT
SYSTEM:	PCIX V2.11.1, DUNX V2.11.1
DATE:	Tue Feb 24 09:51:19 MST 1998
FROM:	tody

BUG:	When run on a byte-swapped platform (e.g. the DEC Alpha or a PC)
	IMFORT can generate images that have the byte swap flag set
	incorrectly in the image headers, causing the image pixels to be
	improperly byte swapped: image reads either return wildly invalid
	pixels or abort with a floating invalid exception.

STATUS:	The temporary fix is to install a new libimfort.a.  New versions of
	this library are available in the archives for PCIX (PC-IRAF) and
	DUNX (Digital Unix for the DEC Alpha).  This will be fixed more
	formerly in the upcoming V2.11.2 patch.  See the section at the end
	of the README file in each distribution directory for additional
	comments or other platform specific notes.

NUMBER:	396
MODULE:	setjd
SYSTEM:	V2.11.1 (affects Linux/Slackware and possibly other systems)
DATE:	Tue Mar 10 12:38:29 MST 1998
FROM:	valdes

BUG:	There is an incorrect procedure declaration.  For some systems this
	does not cause a problem but at least with IRAF V2.11 for Linux
	(Slackware) this produces a "floating point exception" error.
	Contact iraf@noao.edu for either a code fix or a binary upgrade.

STATUS:	Fixed for the next patch or release following V2.11.1.

NUMBER:	397
MODULE:	ccdproc, fixpix
SYSTEM:	V2.11 - V2.11.1
DATE:	Fri Mar 20 15:10:23 MST 1998
FROM:	valdes

BUG:	When using "fixpix=yes" in CCDPROC or using the FIXPIX task on a
	a single long list of input images in one execution
	the error "ERROR: 757 <filename>" will occur.  This error
	means that too many files have been opened and not closed.  This is
	caused by a bug in accessing the mask that fails to close the mask
	after each image is finished.  The limit is about 58 images
	when using a text file description of the bad pixels and 116
	images when using a bad pixel mask (a .pl file).  The workaround
	is to break up the processing into smaller sets of images.
	If using a text file bad pixel description one can increase
	the number of images by converting to a pixel mask file using
	the task PROTO.TEXT2MASK.

STATUS:	This will be fixed in future releases.

NUMBER:	398
MODULE:	daophot.psf
SYSTEM:	V2.11 and earlier
DATE:	Wed Apr 15 09:12:38 MST 1998
FROM:	davis

BUG:	If a path name is including in the output psf image specification
	then the psfimage image name written in the output group and psf
	star photometry files may include a control character which is
	expressed as ^P. This causes trouble for those daophot tasks which
	try to read the group file, e.g. nstar.

STATUS:	The bug was caused by accessing the psf image template list with a file
	template command and has been fixed for the next release of IRAF
	and in the external addon package digiphotx. The work around is
	to remove the ^P character from the photometry files with the editor.

NUMBER:	399
MODULE:	IMEDIT on FITS files
SYSTEM:	V2.11 - V2.11.1
DATE:	Thu Apr 16 09:31:26 MST 1998
FROM:	valdes

BUG:	If multiple FITS format images are edited the output FITS image
	may have the header of an earlier input image rather than the
	header of the image which was edited.  The workaround is to
	edit images one at a time and type "flpr" between executions.

STATUS:	This is a problem with the FITS kernel image caching which will
	be fixed in a future patch or release.

NUMBER:	400
MODULE:	scopy, sarith
SYSTEM:	V2.10-V2.11.1
DATE:	Fri Apr 17 16:04:13 MST 1998
FROM:	valdes

BUG:	When using SCOPY or SARITH with rebin=yes on spectra which have
	non-linear dispersion functions the resulting spectra will have
	an incorrect dispersion function.  The problem is the dispersion
	function will be linear but the dispersion type value is still
	set to non-linear.  Attempting to use this spectrum will cause
	an error, such as a segmentation violation, because the software
	will look for the non-linear dispersion coefficients which do
	not exist.  One may use rebin=no to extract a desired wavelength
	range without rebinning the spectra or use DISPCOR to resample
	the spectra to a specific dispersion range.

STATUS:	Fixed for the next patch or release.

NUMBER:	401
MODULE:	astutil.asthedit
SYSTEM:	V2.10-V2.11.1
DATE:	Fri May 15 11:44:19 MST 1998
FROM:	valdes

BUG:	The if-else-endif syntax does not work correctly.  The following
	example shows what doesn't work even though correctly specified.

	    if (dec > 45)
		print ("above 45")
	    else
		print ("below 45")
	    endif

	This will only execute the if part if dec > 45 and do nothing if
	dec < 45.  The bug is that a single word is considered to be
	a keyword and so "else" and "endif" are interpreted as keywords
	and not statements.  The workaround is as shown below using the same
	example.

	    if (dec > 45)
		print ("above 45")
	    else = else
		print ("below 45")
	    endif = endif

	The same applies to the special statment "quit" which needs to
	be issued as "quit = quit".

STATUS:	Fixed for a future release.

NUMBER:	402
MODULE:	reidentify
SYSTEM:	V2.11-V2.11.1
DATE:	Mon Jun  1 10:08:25 MST 1998
FROM:	valdes

BUG:	When using REIDENTIFY to trace spatial positions in long slit data
	for distortion calibration, an incorrect shift is used when
	switching from tracing in decreasing line/column numbers to tracing
	in increasing numbers.  The shift used is that between the
	reference point and the lowest line/column and it is applied to the
	next increasing point from the reference position.  If this shift
	is significant then this can cause the features to either fail to
	be found or to have the wrong features found.

	Normally for long slit distortion calibration in the initial
	identifications of features to trace (with IDENTIFY) no function is
	fit between the measured positions and the reference positions
	(which are usually the same as the measured positions).  By fitting
	a function the problem will be avoided.  Any function will do since
	FITCOORDS later fits its own function and the IDENTIFY/REIDENTIFY
	function is never used.

STATUS:	This is fixed for future releases.

NUMBER:	403
MODULE:	fixpix, ccdproc, display
SYSTEM:	V2.11-V2.11.1
DATE:	Fri Jun  5 09:45:47 MST 1998
FROM:	valdes

BUG:	When fixing regions by interpolation along columns/across lines,
	which may be set by the user or automatically by finding the
	narrowest direction across a region of bad pixels, it is possible
	to get a segmentation error or error related to referencing invalid
	memory.  Whether this error occurs depends on the contents
	of memory.  If no error occurs the result is correct.

	One workaround is to use only interpolation across columns/along
	lines if this makes sense.  Another workaround is to add a dummy
	region with interpolation along columns covering all the columns.
	For example the first or last line as in "1 3072 1 1" for an image
	with 3072 columns.  It is also possible to break up the operation
	in FIXPIX using multiple passes.  For example if a bad pixel region
	is described by the rectangle "2000 3024 510 512" then two passes
	using "2000 2500 510 512" and "2500 3024 510 512" may work.

STATUS:	Fixed in the next release.

NUMBER:	404
MODULE:	dohydra
SYSTEM:	V2.11 - V2.11.1
DATE:	Thu Jun 25 08:51:47 MST 1998
FROM:	valdes

BUG:	A segmentation error can occur when using a WIYN/HYDRA image for the
	aperture identification information.  The workaround is to use a text
	aperture identification file rather than the image.  One can use
	the supplied ".iraf" file or create a file from the header.  The
	following command can easily generate an aperture identification
	file from the contents of the image header.

	    cl> hselect <image> SLFIB* yes | translit STDIN '"' '\n' > apid

	This will have blank lines between the entries but they are ignored
	by DOHYDRA.

STATUS:	Fixed for the next release.

NUMBER:	405
MODULE:	splot
SYSTEM:	V2.10.3-V2.11.1
DATE:	Tue Jul 14 10:52:39 MST 1998
FROM:	valdes

BUG:	For multispec data where the number of pixels is different for each
	spectrum, such as can occur with echelle orders, the last pixel
	is corrupted when writing out with the 'i' key.  The last pixel
	value is replaced by the value of the first pixel outside the
	defined range of the spectrum.  This value is usually zero.
	For echelle data the different length orders would occur when
	dispersion correcting with fixed dispersion for all orders rather
	than having each order take a dispersion that preserves the full
	wavelength range and the same number of pixels.  There is no
	simple workaround.

STATUS:	Fixed for the next release.

NUMBER:	406
MODULE:	dataio.import
SYSTEM:	V2.11
DATE:	Tue Jul 14 12:02:31 MST 1998
FROM:	fitz

BUG:	When IMPORTing formats with native colormaps such as GIF and when
	not specifying the 'outbands' parameter images will be converted
	without applying the colormap and converting to grayscale.  The
	resulting image looks like garbage and is simply the color indices
	of the image.  The error is caused by a bad flag initialization,
	the workaround is to explicitly set the outbands parameter so the
	processing initializes the flag correctly.  For example

	    	cl> import foo bar outbands="b1"

	'b1' is the default image operator and it's use in the outbands
	param will cause the colormap to be applied.

STATUS:	Fixed for V2.11.2

NUMBER:	407
MODULE:	ccdproc, fixpix, display
SYSTEM:	V2.11 - V2.11.1
DATE:	Mon Jul 20 11:41:47 MST 1998
FROM:	valdes

BUG:	When fixing pixels by interpolation with a non-empty mask that has only
	interpolation along lines there is the possibility of getting
	a segmentation violation at the end of the processing.  A parameter
	used when freeing memory is not initialized in this case.
	There is no workaround except adding a dummy region that
	interpolates along columns or setting FIXPIX to interpolate
	only along columns.

STATUS:	Fixed for next release.

NUMBER:	408
MODULE:	ccdred.ccdmask
SYSTEM:	V2.10-V2.11.1
DATE:	Fri Aug 14 10:11:44 MST 1998
FROM:	valdes

BUG:	Single bad pixels are not found.  There is no workaround.  The code
	fix is simple.  In file noao$imred/ccdred/src/t_ccdmask.x change
	line 198

	from:   if (data[i,j] < low && data[i,j] > high) {
	to:     if (data[i,j] < low || data[i,j] > high) {

	Contact iraf@noao.edu for instructions on how to update an
	IRAF package, in this case CCDRED.

STATUS:	Fixed for next release.

NUMBER:	409
MODULE:	dispcor
SYSTEM:	V2.10-V2.11.1
DATE:	Tue Aug 25 14:43:55 MST 1998
FROM:	valdes

BUG:	When users directly add (with HEDIT rather than using REFSPECTRA)
	both REFSPEC1 and REFSPEC2 keywords without weights (where the
	weights are assumed to be 1) or the specified weights do not
	add up to 1, the resulting dispersion is wrong.  The dispersion
	values used are the weighted sum from the reference spectra but
	the bug is that the weights are not normalized to unit sum.
	Thus if both weights are 1 then the computed dispersion value
	is twice what it should be.  The workaround is to make sure
	that the weights have a unit sum.  When only a single reference
	spectrum is used it is fine to simply specify the reference
	spectrum image name since the default weight is 1.  However, if
	two reference spectra are specified then both weights must be
	specified.  The format for the REFSPEC keywords is image name
	followed by weight with a space between; for example,

	    REFSPEC1 = 'arc1 0.5'
	    REFSPEC2 = 'arc2 0.5'


STATUS:	Fixed in the next release.

NUMBER:	410
MODULE:	crutil.crmedian
SYSTEM:	V1.1: May 1998
DATE:	Fri Sep  4 09:59:20 MST 1998
FROM:	valdes

BUG:	On images with more than about 500K pixels the median operation is
	done in overlapping blocks of lines.  The amount of overlap is
	half of the line median size "lmed".  The bug is that on output
	the overlap regions end up being zero.  There is no workaround
	except to reinstall the new version of the package.

STATUS:	Fixed in V1.2: Sep 4, 1998.

NUMBER:	411
MODULE:	imutil.imarith
SYSTEM:	V2.11
DATE:	Wed Sep 16 08:44:02 MST 1998
FROM:	davis

BUG:	Imarith fails with a segmentation violation if the noact parameter
	is set to "yes". The bug was occurring because the code was trying
	to update the header of a non- existent output image.

STATUS:	Fixed for the next release of IRAF. There is no workaround.

NUMBER:	412
MODULE:	imcombine
SYSTEM:	V2.11
DATE:	Tue Oct 13 11:16:46 MST 1998
FROM:	valdes

BUG:	Updating of the image coordinate system when combining offset images
	is not being done correctly.  The effect is that the header of the
	combined image corresponds to the first image.  One workaround is
	to look at the offsets printed by IMCOMBINE.  Then redo the
	combining putting the image which shows offsets of (0,0) (if there
	is one) as the first in the list to combine.  A more general
	workaround is to look at the first image listed and get the offsets
	(for example (220,50)) and use these to update the header.  To
	update the header using the offsets printed for the first image

	cl> hedit outimage crpix1 '(crpix1+220)'
	cl> hedit outimage crpix2 '(crpix2+50)'

	where 220 and 50 would be replaced by the offsets from the IMCOMBINE
	listing.  This will fix the work coordinate system.  If the
	physical coordinate system also needs to be correct do the
	same with the keywords LTV1 and LTV2 replacing CRPIX1 and CRPIX2.
	Note that this extends to higher dimensions if combining images
	with more than 2 dimensions.

STATUS:	Fixed for the next release.

NUMBER:	413
MODULE:	fitprofs
SYSTEM:	V2.10-V2.11
DATE:	Thu Nov  5 16:38:02 MST 1998
FROM:	valdes

BUG:	If the maximum difference of the spectrum to the initial background
	over the fitting region is less than 1 and no peak value or a value
	of INDEF is given in the "position" file then a floating overflow
	type of error will occur.  This is a bug in the code.  The
	workarounds are to explicitly give a peak value in the position
	file or scale the spectrum (such as by multiplying spectrum by
	some number) so that the peak to background is greater than 1.

STATUS:	Fixed for the next release.

NUMBER:	414
MODULE:	dispcor
SYSTEM:	V2.10-2.11.1
DATE:	Tue Nov 17 10:20:38 MST 1998
FROM:	valdes

BUG:	If the weights when interpolating between two dispersion reference
	solutions are given to more than three digits in the REFSPEC
	keywords they are internally truncated to three digits.  Using
	DISPCOR to produce non-linear dispersion coefficients in the image
	headers will have the three digit weights which may not add up to 1
	to the level of 0.1%.  This can cause small shifts in the evaluated
	wavelengths.  If DISPCOR is used to linearize the dispersion the
	same effect will apply.  This bug is related to bug 409.  The
	workaround solution is to make sure the weights in the REFSPEC
	keywords add up to 1 within the first three digits.  THIS BUG
	CAN CAUSE SYSTEMATIC ERRORS IN RADIAL VELOCITY MEASUREMENTS
	WHEN USING MULTIPLE WEIGHTED DISPERSION SOLUTIONS.

STATUS:	In future releases all occurences of the weight values in the
	REFSPEC keywords and in the non-linear coefficients will use
	eight significant digits.  Furthermore, the dispersion function
	evaluation for multiple weighted dispersion functions will
	normalize the weights to avoid any systematic error regardless
	of the weight values.


NUMBER:	415
MODULE:	reidentify
SYSTEM:	V2.11 - V2.11.1
DATE:	Thu Dec  3 11:19:10 MST 1998
FROM:	valdes

BUG:	When interactive=yes and the task starts on the first image in
	the "images" list (that is after doing the "reference" image)
	in interactive mode (that is an aswer of "NO" has not been given
	during the reidentification of the "reference" image), the dispersion
	function parameters are reset to "spline3" of order 1 with no
	rejection rather than inheriting the reference solution parameters.
	The workarounds are to not use the "interactive" except of
	the reference image or enter the interactive identify stage
	for the first solution of each image and in the fitting reset the
	function parameters to the desired values.

STATUS:	Fixed for the next release.

NUMBER:	416
MODULE:	dataio.import
SYSTEM:	V2.11.0-V2.11.1
DATE:	Thu Dec 10 14:24:37 MST 1998
FROM:	fitz

BUG:	One dimensional raw data is not converted properly, resulting in
	an image with no pixel data.  The fix requires a code change, sites
	needing this should contact site support.  As a workaround the
	'dims' parameter should be set to a 2-D string such as 

	    cl> import foo bar format=raw dims="1024,1"

	The resulting image will be a [1024,1] and can be reduced to 1-D
	if needed using the IMSLICE task.

STATUS:	Fixed for V2.11.2

NUMBER:	417
MODULE:	astutil.ccdtime
SYSTEM:	V2.10-V2.11.1
DATE:	Mon Jan  4 12:01:27 MST 1999
FROM:	valdes

BUG:	The extinction value is ignored and a value of 1 mag/airmass
	is used.  There is no work around other than to adjust the results
	by hand.  The version of CCDTIME used through the NOAO Web page
	exposure time calculator (for NOAO instruments) is correct as of
	Sept 1998.

STATUS:	Fixed for future releases.

NUMBER:	418
MODULE:	immatch.wcscopy
SYSTEM:	V2.11
DATE:	Thu Jan  7 13:57:57 MST 1999
FROM:	davis

BUG:	Wcscopy does not copy the reference image RADECSYS, EQUINOX, and
	MJD-WCS keywords  to the input image. The resulting numerical
	coordinate system will be correct but the coordinate system
	definition may be lost.

STATUS:	Fixed for the next release of IRAF. The workaround is to update
	the RADECSYS, EQUINOX, and MJD-WCS keywords by hand or use the
	ccmap or ccsetwcs tasks to do the updating.

NUMBER:	419
MODULE:	images.immatch.xyxymatch,images.imcoords.ccxymatch
SYSTEM:	V2.11
DATE:	Mon Feb 22 16:43:19 MST 1999
FROM:	davis

BUG:	When the number of reference files is greater than one and equal to
	the number of input files, xyxymatch and ccxymatch are using the
	last file in the reference file list as the reference file, instead
	of matching the input and reference files one to one.

STATUS:	The problem was caused by a missing break statement in both cases.
	The work-around is to run xyxyatch and ccxymatch once for every
	reference and input file pair or use a script to do the file
	management. Fixed for the next patch.

NUMBER:	420
MODULE:	identify
SYSTEM:	V2.10-2.11.1
DATE:	Mon Mar  8 13:27:24 MST 1999
FROM:	valdes

BUG:	If one uses the 'l' key to identify lines from a line list in a
	spectrum that is wavelength calibrated and has physical coordinates
	different from logical coordinates, wrong results or a system error
	(such as a segmentation error) will occur.  This is due to
	conversion of the line list coordinate to a physical pixel
	coordinate and attempting to use this to find a peak in the
	spectrum where the routine expects a logical coordinate.  This
	situation is quite rare and does not occur in normal data
	reductions.

	Logical and physical pixel coordinates become different if a
	section of a spectrum is extracted; such as with IMCOPY or SCOPY.
	The workaround is to reset the physical coordinates to be the same
	as the logical coordinates with the command

	    cl> wcsreset <image> wcs=physical

STATUS:	Fixed for the next release.

NUMBER:	421
MODULE:	daophot.peak, daophot.nstar, daophot.allstar
SYSTEM:	V2.11
DATE:	Mon Apr 12 13:43:18 MST 1999
FROM:	davis

BUG:	The daophot peak, nstar, and allstar tasks can crash with a floating
	divide by 0 (Solaris) or floating exception (Linux) if the predicted 
	error computation goes to 0.0. This can happen if the predicted
	model is 0.0 (most likely to occur at large radii from the object
	being fit) , the readout noise is 0.0, and the profile error is
	0.0.

STATUS:	Fixed for the next release of IRAF. The workaround is to make sure
	that the readout noise is set > 0.0.

NUMBER:	422
MODULE:	daophot.psf
SYSTEM:	V2.11
DATE:	Mon Apr 19 10:49:29 MST 1999
FROM:	davis

BUG:	In rare circumstances the psf task can crash with a floating point
	error when computing the analytic portion of the psf. So far this
	has only been observed on Linux systems but it could potentially be
	a problem for other machines as well.

STATUS:	The problem is caused by division by a very small number in the
	weight computation and happens when the point being added to the
	fit is very close to fitrad pixels from the center of the analytic
	function. There is no true workaround but changing the value of
	fitfit slightly or choosing another analytic function may avoid the
	problem.

NUMBER:	423
MODULE:	astcalc, asthedit
SYSTEM:	V2.11-V2.11.1
DATE:	Thu Apr 22 13:41:41 MST 1999
FROM:	valdes

BUG:	The "imdel" function name in ASTHEDIT and ASTCALC is not recognized
	because of an error in the program.  Instead this function is
	recognized with the name "imde".

STATUS:	Fixed for the next release.

NUMBER:	424
MODULE:	rv.fxcor
SYSTEM:	V2.10-V2.11.1
DATE:	Thu Apr 22 14:07:13 MST 1999
FROM:	fitz

BUG:	The verbose output listing for a deblended fit reports only the
	first velocity component.  There is no workaround.  The code
	fix required is to edit line 298 of rv$rvvfit.x and change

	from:     call pargd (rv_shift2vel(rv,DBL_SHIFT(rv,1)))
	to:	  call pargd (rv_shift2vel(rv,DBL_SHIFT(rv,i)))

        Contact iraf@noao.edu for instructions on how to update an
        IRAF package, in this case RV.

STATUS: Fixed for next release.

NUMBER:	425
MODULE:	focas
SYSTEM:	external package
DATE:	Fri May 21 10:28:59 MST 1999
FROM:	valdes

BUG:	The command FDISPLAY in the IRAF FOCAS external package fails to
	find the command.  There is an error in the focas.cl file which
	defines how FOCAS tasks are called by IRAF.

	Within IRAF the FOCAS display command was changed to be "fdisplay"
	to avoid conflict with the IRAF display command.  Initially this
	was done by translating the command FDISPLAY in IRAF to execute the
	command DISPLAY in Unix (which was the name of the executable).
	However, in Unix there was also a common conflict with another
	command having the name DISPLAY.  So the Makefile was modified to
	create an executable fdisplay (from the display.c source).  So now
	IRAF needs to call fdisplay in Unix when fdisplay is typed.

	The file focas.cl needs to be changed from

	    task $fdisplay = $display

	to

	    task $fdisplay = $foreign

	Bye out of the package and reload it after making the change to
	have it take effect.


STATUS:	Will be fixed in a future release.

NUMBER:	426
MODULE:	sarith
SYSTEM:	V2.10-V2.11.1
DATE:	Fri May 28 16:31:04 MST 1999
FROM:	valdes

BUG:    The option to have a single second operand when operating on a
	list of first operands does not work.  For example to divide a set
	of spectra by a constant value or a single image.  The behavior
	will be to print the message "Warning: Error in second operand".
	The output will still be created but with a value of zero
	everywhere.  The workaround is to make the second operand match the
	first.  For example:

	cl> sarith a,b,c / 10,10,10 d,e,f
	cl> sarith @list1 / @list2 @list3

	In the second example list2 might have the same image or constant
	repeated as many times as there are entries in list1.

STATUS:	Fixed for the next release.

NUMBER:	427
MODULE:	imcoords.wcsctran
SYSTEM:	V2.11
DATE:	Thu Jun  3 15:14:39 MST 1999
FROM:	davis

BUG:	The units are not always correctly initialized on successive runs
	of the wcsctran task. For example if units are set to 
	"hours native" on the first run and then reset to "" on the
	second run, the units used will be the initial units "hours native".

STATUS:	Fixed for the next release of IRAF. The work around is to do a flpr
	between runs.

NUMBER:	428
MODULE:	display
SYSTEM:	V2.11-V2.11.1
DATE:	Tue Jun 15 10:00:10 MST 1999
FROM:	valdes

BUG:    For large images when the fill option is used, bad pixel overlays
	do not work correctly.  The image data or bad pixel masks will
	appear scrunched up and the image data may appear streaked as the
	last line is replicated from the scrunched edge to the edge of the
	display.  The behavior depends on whether the overlay mask is given
	in the "overlay" parameter or in the "bpmask" parameter with
	"bpdisplay=overlay".  There is no workaround other than to avoid
	the fill option until the next release.

STATUS:	Fixed for the next release.

NUMBER:	429
MODULE:	immatch.geotran
SYSTEM:	V2.11
DATE:	Fri Jun 18 14:20:06 MST 1999
FROM:	davis

BUG:	Geotran was not decoding the transforms list correctly in the
	case that the number of images > 1 and the number of transforms
	is 1. In that situation geotran is supposed to use the same
	transform for all the input images. Instead it was complaining
	about not being able to find the transform for the second image.

	This bug was introduced when geotran was modified to use the
	image template expansion code to manage the transform list
	(part of supporting the mosaic image name syntax) instead of the
	file template expansion code.

STATUS:	Fixed for the next release of IRAF. The workaround is to create
	a transform list with one entry for each image, even if the entries
	are the same.

NUMBER:	430
MODULE:	fitcoords
SYSTEM:	V2.10-V2.11.1
DATE:	Wed Jul 21 16:52:49 MST 1999
FROM:	valdes

BUG:	When the fitting orders are higher than the data allow the task
	should report "No degrees of freedom" and abort but instead the
	error is not caught and the task proceeds causing various errors
	including segmentation violations, crashing the cl, and
	"task cursor not found".  One way this can be triggered inadvertently
	is if one forgets to trace the feature(s) with REIDENTIFY.
	The solutions are to remember to trace the features and to use
	orders that are lower than the number of points traced.

STATUS:	In the next release the task will report "No degrees of freedom"
	and abort rather than mysteriously crashing.  It will also
	report "Only one line or column measured" and abort if the
	feature(s) have not been traced to other lines or columns.


NUMBER:	431
MODULE:	dispcor
SYSTEM:	V2.10-V2.11
DATE:	Mon Jul 26 13:35:54 MST 1999
FROM:	valdes

BUG:	If an error occurs when reading echelle dispersion functions from the
	database a segmentation violation or related error will occur.  The
	error prompting this log is when the image uses two dispersion
	functions (there are REFSPEC1 and REFSPEC2 keywords) and the
	echelle dispersion functions do not have the same offset and
	slope.  The workaround for this particular error is to insure in
	ECIDENTIFY that the dispersion functions have the same offset using
	the 'o' key.

STATUS:	Fixed in V2.11.1

NUMBER:	432
MODULE:	dataio.export
SYSTEM:	V2.11.0-V2.11.2
DATE:	Fri Aug 20 20:10:42 MST 1999
FROM:	fitz

BUG:	Use of the cmap() function for combining 3 images into an 8-bit
 	PseudoColor image results in a garbage line at the top or bottom
	of the image (depending on format), this line is some random color.
	The problem is that the last image line processed is not flushed
	properly to the temp image used in the conversion.  The solution
	requires a code change to properly flush the image buffer.  

STATUS:	Fixed for the next release.  The IMCNV external package version of
	the task is updated with the fix or sites can contact site support
	for instructions on patching the system.  Workarounds are to write
	a 24-bit image instead and do the conversion using host tools, e.g.
	write a 24-bit rasterfile and convert to GIF afterwards.

NUMBER:	433
MODULE:	fitprofs
SYSTEM:	V2.10-V2.11.2
DATE:	Thu Aug 26 12:00:09 MST 1999
FROM:	valdes

BUG:	The option to output an image of the fit or residuals only includes
	the last profile component regardless of the "components"
	parameter value.

STATUS:	Fixed for the next release.

NUMBER:	434
MODULE:	tv.wcslab
SYSTEM:	V2.11.2 and earlier
DATE:	Sat Aug 28 11:03:21 MST 1999
FROM:	davis

BUG:	Wcslab was failing with the message "ERROR: MWCS: coordinate system
	not defined (physical)" on the Dec Alpha when usewcs=yes, and with
	a segmentation violation on Sun systems when the input image was
	undefined.

STATUS:	Fixed for the next release of IRAF. There is no work-around.

NUMBER:	435
MODULE:	photcal.fitparams
SYSTEM:	V2.11.2 only
DATE:	Mon Aug 30 08:22:45 MST 1999
FROM:	davis

BUG:    The fitparams task quits with a cannot write to string file error.	
	The problem was caused by a missing file dependency in the package
	mkpkg file, which resulted in a routine not being rebuilt.

STATUS:	Fixed for next patch/release of IRAF. Contact the IRAF group for a fix.

NUMBER:	436
MODULE:	astcalc, asthedit, rvcorrect
SYSTEM:	V2.11.2
DATE:	Mon Aug 30 10:17:18 MST 1999
FROM:	valdes

BUG:	The year is incorrectly determined as yy+1900+1900 when DATE-OBS
	is in the old FITS format (dd/mm/yy).  In other words, an extra
	1900 is added to the two digit year.  This is caused by a
	misunderstanding of where the 1900 is added.  This will make
	further calculations which use the year grossly incorrect.  The
	workaround is to manually edit the image headers to convert them to
	the new FITS format (yyyy-mm-dd).

STATUS:	Fixed for a future patch or release.

NUMBER:	437
MODULE:	astcalc
SYSTEM:	V2.10-V2.11.2
DATE:	Tue Aug 31 10:48:49 MST 1999
FROM:	valdes

BUG:	When ASTCALC is run on more than one image at a time the image
	is incorrectly opened twice and only closed once.  This has
	one consequence, if the list of images is large (greater than
	about 60) and they are in the Space Telescope Geiss format
	(the files with ??h and ??d extensions) then the task will
	run out of file descriptors with an error message such as

	    ERROR: 757 noao/lib$obsdb.dat
	    ERROR: 787 pix61.c0h4451ef

	The workarounds are 1) use smaller lists of images per execution,
	2) change the image format to imh or fits, 3) run the task in
	a script loop using one image at a time.

STATUS:	Fixed for the next release.

NUMBER:	438
MODULE:	mscred.mscimatch
SYSTEM:	V3.0-V3.2
DATE:	Fri Sep  3 11:07:46 MST 1999
FROM:	valdes

BUG:	The iterative rejection step (niterate > 0) produces a floating
	operand error on some systems such as Linux.  This was cased by
	an incorrect argument declaration which so whether is affects
	a system depends on the byte order used by the system.  The
	workarounds are to not use iterative rejection by setting
	niterate to zero, update to the latest distribution of MSCRED,
	or work on a machine where this error does not occur (such as
	Suns).

STATUS:	Fixed in V3.2.1.

NUMBER:	439
MODULE:	ccdred.cosmicrays
SYSTEM:	V2.11.2
DATE:	Fri Sep 17 13:56:16 MST 1999
FROM:	valdes

BUG:	Changes in include files related to graphics where not applied
	in the V2.11.2 update resulting in the graphics being garbled.
	The workarounds are 1) to delete the ccdred object libraries
	and rebuilt the executable (not recommended unless you really
	know what you are doing), 2) installing new binaries obtained
	from NOAO (contact iraf@noao.edu), or 3) installing the CRUTIL
	external package which also contains a version of COSMICRAYS.

STATUS:	Fixed for the next release.

NUMBER:	440
MODULE:	tv.wcslab
SYSTEM:	V2.11
DATE:	Fri Sep 17 15:06:47 MST 1999
FROM:	davis

BUG:	Wcslab could produce garbled plots if the projection was set to
	tnx, especially if the ra ~ 0 hours.

STATUS:	Fixed for the next patch / release of IRAF. A workaround is to
	change the wtype parameter to tan using wcsedit, make the plot,
	and then reset wtype to tnx. The wcslab overlay will lose a bit
	of accuracy but for most display purposes this should not matter.

NUMBER:	441
MODULE:	utilities.curfit
SYSTEM:	V2.11.2 (only)
DATE:	Tue Sep 21 14:01:15 MST 1999
FROM:	cheselka

BUG:	If run in non-interactive mode (in scripts, for example), a
	segmentation fault occurs.

	A workaround is to run the task interactively, set the 'cursor' 
	parameter to a disk file containing the command 'q', send graphics 
	output to dev$null, and the text output to a disk file.

	From the command line:

	cl> curfit dev$pix inter+ cursor=quit_command >G dev$null >& fit.info

	Or from a script:

	utilities.curfit (input="dev$pix", inter+, cursor="quit_command", \
		>G "dev$null", >& "fit.info")

	The resulting file (fit.info) will have a single line of junk at
	the top of the file, but will otherwise contain the fit data.

STATUS:	Fixed for the next release.

NUMBER:	442
MODULE:	doslit, dofibers, dohydra, doargus
SYSTEM:	V2.11.1-V2.11.2
DATE:	Fri Sep 24 17:01:26 MST 1999
FROM:	valdes

BUG:	When the new feature was added to allow an attempt to automatically
	determine the dispersion function, values of the parameters "crval"
	and "cdelt" both set to INDEF (the default parameter values) was
	supposed to skip the automatic identification.  An oddity of the CL
	prevented these tasks from seeing this case and so they always try
	to do an automatic solution.  With a large spectrum and a large
	line list and no guidelines as to the correct dispersion this can
	cause the tasks to take a very long time at the step where the
	dispersion is determined.  The workarounds are to set these values
	to something close to what is expected or to use a short line
	list.

STATUS:	Fixed for the next release.

NUMBER:	443
MODULE:	digiphot.daophot, digiphot.photcal
SYSTEM:	V2.11
DATE:	Tue Sep 28 08:43:02 MST 1999
FROM:	davis

BUG:	If the tables pacakge is undefined the daophot and pphotcal package
	scripts will hang which may require terminating the IRAF session. The
	problem is a missing ; in the daophot and photcal scripts which trips
	a cl bug.

STATUS:	Fixed for the next patch release of IRAF. The fix is to add the ;
	to the daophot script as follows. Change the 4 lines

	    } else {
		type "daophot$lib/warning.dat"
	    }
        }

	to 5 lines as follows

	    } else {
		type "daophot$lib/warning.dat"
	    }
        }
	;

	The same fix will work for the photcal script. The workaround
	is to install the tables package.



NUMBER:	444
MODULE:	imedit
SYSTEM:	V2.10-V2.11.2
DATE:	Fri Oct  1 09:03:48 MST 1999
FROM:	valdes

BUG:	The output image type will be that set by the "imtype"
	variable regardless of the image type of the input image or any
	explicit image type in the input and output image names.
	When the temporary editing buffer is created it is always created
	with the "imtype" value and when the output image is created
	from the edited temporary image it retains the image type of
	the temporary image.  The two workarounds are either to set
	"imtype" to the type desired for the output or copy the output
	image to the desired type after it is created.

STATUS:	In the next release if an explicit image type extension is specified
	for the output image name then that image type will be created for
	the temporary editing image and the final output image.  If no
	explicit type is given then the output will be that specified
	by the "imtype" variable.  In no case is the image type of the
	input image automatically used.

NUMBER:	445
MODULE:	ared.quad.quadproc
SYSTEM:	V2.11.2
DATE:	Fri Oct  8 16:25:14 MST 1999
FROM:	valdes

BUG:	ARED external package versions prior to "Rev 1.32 - Oct 8, 1999"
	installed with IRAF V2.11.2 cause the QUADPROC task to produce
	the error:

	ERROR: parameter `output' not found
	    quadproc (images=tryme.fits)

	QUADPROC is a script that calls CCDPROC and the parameter "output"
	is a new parameter in that task.  Installation of ARED includes
	copying the CCDPROC executable but not the parameter file.
	The workaround is either to get the latest version of ARED or
	edit the file quad$ccdproc.par (quad is defined after loading
	the quad package) to add the line:

	output,s,h,"",,,List of output CCD images

	after the first line.

STATUS:	ARED package updated to include the revised ccdproc.par file.

NUMBER:	446
MODULE:	rv.rvidlines, rv.rvreidlines
SYSTEM:	V2.11.2 (only)
DATE:	Tue Oct 12 11:34:07 MST 1999
FROM:	valdes

BUG:	For 1D spectra the error

	    PANIC in `/iraf/iraf/noao/bin.ssun/x_rv.e': Salloc underflow

	may occur due to an incorrect change in memory management.  This
	error may cause the CL to abort.  A workaround is to turn the 1D
	image into a 2D image of 1 line with the command:

	    cl> imstack spec spec2d

	where spec is the 1D spectrum and spec2D is the spectrum to use
	with RVIDLINES/RVREIDLINES.

STATUS:	Fixed for the next release.

NUMBER:	447
MODULE:	crutil.crnebula
SYSTEM:	CRUTIL V1.2 and earlier
DATE:	Tue Oct 19 15:04:41 MST 1999
FROM:	valdes

BUG:	The rin and rout parameters are ignored and the default values are
	hardwired in the task.  The only workaround is to edit the script
	crutil$src/crnebula.cl and in the rmedian statement replace the
	"1.5" with rin and the "6." with rout.

STATUS:	Fixed in V1.3: Oct 19, 1999 release.

NUMBER:	448
MODULE:	mscred.msccmatch
SYSTEM:	-V3.2
DATE:	Mon Oct 25 15:00:04 MST 1999
FROM:	valdes

BUG:	If the specified image name is more than 19 characters then the
	task will fail to center on the objects.  When verbose is yes you
	will see the same numbers printed for each object; i.e. one line is
	repeated many times.  The workarounds are to shorten the names by
	renaming, logical links, or possibly eliminating the ".fits"
	in the specified name.  In the latter case a name such as
	"abcdefghijklmnopqrs" will be ok but "abcdefghijklmnopqrs.fits" or
	"abcdefg*" will not work.

STATUS:	Fixed in a future version.

NUMBER:	449
MODULE:	ared.quad.quadproc
SYSTEM:	V2.0
DATE:	Fri Oct 29 12:52:13 MST 1999
FROM:	valdes

BUG:	This task assumes the image data is in "imh" format.  If it is
	not in this format then overscan and trim will not occur and
	further in the processing the following message will appear.

	ERROR on line 173: Bias section not specified or given as full image.

	The workaround is to change the image format to "imh".  Also change
	the "imtype" variable with "reset imtype=imh; flpr".  Getting the
	latest version of the ARED package source (ared.tar) will also fix
	this problem.  In this version the "imtype" variable must be set to
	match extension of the image type being used; e.g. "fits" for
	*.fits data.  The binaries do not need to be updated since the fix
	applies only to a script task.

STATUS:	Fixed in the current distribution from iraf.noao.edu.

NUMBER:	450
MODULE:	imfilter.fmedian,imfilter.frmedian,imfilter.fmode,imfilter.frmode
SYSTEM:	V2.11
DATE:	Fri Nov 19 14:20:16 MST 1999
FROM:	davis

BUG:	The fast median / mode filtering tasks will overflow producing
	pathological pixel values if the size of the filtering kernel
	xfilter * yfilter > 32767 and the number of pixels in 1 histogram
	bin happens to be > 32767 as may happen in bad pixel regions.

	The problem was due to the fact that for historical reason the
	algorithm histogram was stored as a short instead of an int.

STATUS:	Fixed for 2.11.3. The workaround is to try and keep the filter size
	< 32767 pixels in size, or to use the much slower median task.

NUMBER:	451
MODULE:	imcombine,ccdred.combine,mscred.combine,sflatcombine,flatcombine,zerocombine
SYSTEM:	V2.11.2-V2.11.3
DATE:	Tue Dec  7 10:33:32 MST 1999
FROM:	valdes

BUG:	The 2D grow option introduced in V2.11.2 and in MSCREDV3.2
	does not work with "minmax" rejection.  There is no workaround.

STATUS:	Fixed in later releases.

NUMBER:	452
MODULE:	mscred.msczero
SYSTEM:	MSCRED V3.2.3 (releases between Nov 17 and Dec 2)
DATE:	Fri Dec 10 12:14:10 MST 1999
FROM:	valdes

BUG:	A change made to allow MSCZERO to work on single images, such as
	after resampling and stacking, introduced the error

	   Warning: MWCS: dimension mismatch (mw_open)

	when attempting to apply a zero point correction update.  While
	the message says warning actually the coordinate system is
	not updated at all.  There is no workaround and requires
	the package to be updated.

STATUS:	Fixed in the Dec. 10, 1999 release.

NUMBER:	453
MODULE:	scopy
SYSTEM:	V2.11-V2.11.3
DATE:	Tue Dec 14 11:48:12 MST 1999
FROM:	valdes

BUG:	When copying out a region of a spectrum which is log-linear sampled
	(DC-FLAG=1) the coordinate system of the copied region is wrong.
	This applies whether or not the "rebin" parameter is set.  The
	workaround is to use DISPCOR; set "w1" and "w2" to the desired
	limits and set "log=yes".  This will do the same thing as
	SCOPY with "rebin=yes".  To extract a region without rebinning
	the simplest thing is to use an image section.  The pixel limits
	corresponding to the desired wavelength range will have to be
	determined in some way such as with SPLOT, LISTPIX, or calculated
	from the CRVAL/CDELT keywords (these are in log units for log-linear
	sampled spectra.

STATUS:	Fixed for the next release.

NUMBER:	454
MODULE:	proto.fixpix, ccdproc
SYSTEM:	V2.11-V2.11.3
DATE:	Wed Dec 15 14:30:44 MST 1999
FROM:	valdes

BUG:	Tasks which allow a text file description of bad pixels in addition
	to a bad pixel mask, which include fixpix and ccdproc, will fail
	with a 757 error when a large number of files are processed.  This
	might occur with a large @file or in many repeated calls without
	an intervening flushing of the process cache such as with flpr.
	This problem is caused by a system error that fails to free a file
	descriptor.  After a sufficient number of executions the number of
	available free file descriptors is depleted and the 757 error (too
	many open files ) is reported.  The workarounds are to either use
	bad pixel masks or to limit the number of images in each execution
	and to use flpr after a 50 or so images are processed.

STATUS:	A system fix is under investigation for the next release.

NUMBER:	455
MODULE:	mscrfits
SYSTEM:	MSCRED up to V3.2.3: December 10, 1999
DATE:	Thu Dec 16 11:46:48 MST 1999
FROM:	valdes

BUG:	If the original file names include a '.' other than that for
	the ".fits" extension it is correctly stored by MSCWFITS.  However,
	reading the tape with MSCRFITS either to list the contents
	or to restore the original file names will cause the part of
	the file name following the last '.' to be stripped.  Therefore
	the FITS tape files are correct but restoring or listing them
	by their disk file names when the tape was written will fail.

	For example, suppose the file name is "n1.abc.def.fits".  Then when
	it is written to tape the FILENAME keyword will contain
	"n1.abc.def".  Reading this tape file to list or restore the
	original name will consider the original file name to be "n1.abc".
	This bug is caused by stripping the extension (anything after the
	last '.' including the period) both when the file is written (a
	correct and useful behavior) and then when reading the stored
	FILENAME keyword (the incorrect behavior).

	The workarounds are 1) don't use '.' in the original file names, 2)
	read the files to disk without restoring the original file names
	and then use the FILENAME keyword in the primary header to identify
	the original file name and restore the name.  There is no workaround
	for getting a listing of the tape contents with the correct full
	original name other than using the fixed version.

STATUS:	Fixed for the next release.

NUMBER:	456
MODULE:	rv.fxcor
SYSTEM:	V2.11.3
DATE:	Thu Dec 23 13:43:57 MST 1999
FROM:	fitz

BUG:	Images with a DATE-OBS keyword value of the form CCYY-MM-DD with
	no associated time information will cause and floating point 
	exception when computing the heliocentric corrections.

STATUS:	The bug is caused by an incorrect Y2K fix which didn't properly
	check for this form of the DATE-OBS keyword in which the time
	returned as INDEF.  Workarounds include editing the keyword to
	include the UT time information with a command such as

	    hedit *.imh date-obs '(@"date-obs"//"T"//str(@"ut"))'

	A trivial code change and recompilation instructions are available
	by contacting site support.

	Fixed for the next release.

NUMBER:	457
MODULE:	crutil.crmedian
SYSTEM:	-V1.3: Oct 19, 1999
DATE:	Thu Jan  6 09:28:33 MST 2000
FROM:	valdes

BUG:	If the number of columns in the image is not an exact multiple
	of the sigma block size uninitialized values is used for the
	sigma values at the end of the lines.  This can cause floating
	point exceptions.  The only workaround is to use an image section
	to trim the number of columns in the image to a multiple of
	the sigma block size and adjust the sigma block size to minimimze
	the amount of trimming required.

STATUS:	The is fixed in a new version of the CRUTIL package now available.

NUMBER:	458
MODULE:	imcombine, combine
SYSTEM:	V2.11.3
DATE:	Wed Jan 12 13:32:54 MST 2000
FROM:	valdes

BUG:	When combining input images that have been dimensionally reduced
	(those have a WCSDIM keyword greater than the logical dimension
	of the image and having a WAXMAP01 keyword) and using offsets
	the error

	    Warning: MWCS: dimension mismatch (mw_gltermd)

	will appear.  Even though it says it is a warning it is really a
	fatal error and the task will quit.  Dimensional reduction occurs
	with copying out a lower dimensional section of an image; i.e.
	copying a 2D plane from a 3D image.  The workaround is to reset the
	headers of the input image to remove the dimensional reduction.
	This is done by deleting the keywords WCSDIM and WAXMAP01.

STATUS:	Fixed for the next release.

NUMBER:	459
MODULE:	apall/apsum
SYSTEM:	V2.11.2-V2.11.3 (sparc, ssun, redhat, linux, sol7)
DATE:	Thu Jan 20 11:16:14 MST 2000
FROM:	valdes

BUG:	The extraction tasks in APEXTRACT for the distributions of
	Sun/SunOS, Sun/Solaris, PC-IRAF/Slackware, PC-IRAF/Redhat, and
	PC-IRAF/Solaris7 accidentally used an older version (V2.10) of the
	extraction code.  For most purposes this simply means a couple
	of minor bugs fixed in V2.11 will be back.  The only significant
	change is that the feature to allow selection of the apertures
	to be extracted with the "aperture" parameter will be broken.

	There is no workaround other than to install new executables.
	These are available at ftp://iraf.noao.edu/misc/apextract2113/
	(and in the misc directory in the IRAF ftp mirror sites).
	The README file in the directory gives installation instructions.

STATUS:	Fixed in future releases.

NUMBER:	460
MODULE:	dispcor
SYSTEM:	V2.11.3
DATE:	Thu Jan 27 13:07:38 MST 2000
FROM:	valdes

BUG:	In V2.11.3 DISPCOR was enhanced to work on 2D (long slit) data.
	In the processes the "global" option was broken resulting
	in a segmentation violation if selected.  There is no workaround
	other than not to use the global option and, instead, manually
	set the target dispersion sampling to be the same for all
	spectra.

STATUS:	Fixed for the next release.

NUMBER:	461
MODULE:	apall/apsum
SYSTEM: V2.11.2-V2.11.3 (sparc, ssun, redhat, linux, sol7)
DATE:	Thu Jan 27 13:32:50 MST 2000
FROM:	valdes

BUG:	This is an addendum to buglog #459.  Another aspect of the incorrect
	source being used is that with "format=onedspec" the output names
	will be of the form root.0001.0001 instead of root.0001 where the
	root name and the number will differ.  The workarounds are to
	either rename the images after extraction or extract to multispec
	format and use SCOPY to separate the apertures into separate 1D
	images.  As noted in the previous buglog a fixed executable may
	be obtained and installed if desired.
	See ftp://iraf.noao.edu/misc/apextract2113/README.

STATUS:	Fixed in future releases.

NUMBER:	462
MODULE:	dispcor
SYSTEM:	V2.11.3
DATE:	Tue Feb  1 16:16:57 MST 2000
FROM:	valdes

BUG:	DISPCOR does not work correctly when linearizing spectra if there
	is more than one aperture in the file (that is multispec format
	data) and the aperture numbers are different than the line
	numbers.  This was found in the reduction of multifiber data where
	the aperture numbers are set to the fiber numbers.  What happens is
	that the dispersion solution from the wrong spectrum is applied
	during the linearizing.  There is no indication that the dispersion
	correction is incorrect.  The workarounds are to make sure that
	the aperture numbers correspond to the line numbers, to
	separate the spectra into individual 1D format, or to use
	"linearize=no".

STATUS:	This is a serious bug, particularly since there is no obvious
	indication of producing the wrong result.  A patch to V2.11.3
	is required to fix this problem.


NUMBER:	463
MODULE:	splot
SYSTEM:	V2.11-V2.11.3a
DATE:	Tue Feb 15 15:59:39 MST 2000
FROM:	valdes

BUG:	The 'h' key method for measuring equivalent widths will produce
	an arithmetic exception (such as divide by zero) when the pixel
	coordinate becomes large (say > 4000).  The exact error and limit
	value depends on the host system.  The workaround is to extract the
	desired piece of the spectrum into a shorter piece.  If you know
	the pixel coordinates you could use IMCOPY with an image section.
	If you know the wavelength region then use SCOPY.

	    on> imcopy longspec[5210:5310] temp
		or
	    on> scopy longspec temp w1=6140 w2=6143 rebin-

	    on> splot temp
	    <measure the line>

	Alternatively one can use one of the other methods for measuring
	equivalent widths such as 'e', 'k', or 'd'.

STATUS:	The algorithm is revised in the next release.

NUMBER:	464
MODULE:	proto.imextensions
SYSTEM:	V2.11-V2.11.3a
DATE:	Thu Feb 24 12:34:36 MST 2000
FROM:	valdes

BUG:	When using IMEXTENSIONS to expand a file with many extensions and
	including a image section or image kernel specification it is
	possible to overrun a string resulting in either a system error or
	an incomplete output list.  Each '[', ',', '*' character
	contributes to the possiblity of overrunning the string.  The
	maximum number of extensions that can be expanded without problem
	depends on the specific "input" list.  The workarounds are to avoid
	using image sections and image kernal specifications for large
	lists or to expand the list in pieces using the "index" parameter.

STATUS:	To be fixed in a future release.

NUMBER:	465
MODULE:	identify/reidentify
SYSTEM:	V2.11-V2.11.3p1
DATE:	Thu May  4 08:59:41 MST 2000
FROM:	valdes

BUG:	When using velocity units the database is written without the
	velocity reference point.  For example, units of "km/s 1 micron"
	will be written as "km/s".  Attempting to use the database will
	then not work since the velocity unit is not fully specified.
	The workarounds are either to use other units or edit the
	database file to restore the missing reference information.

STATUS:	Fixed for the next release.

NUMBER:	466
MODULE:	ared.quadproc
SYSTEM:	V2.1
DATE:	Tue Jun 20 13:47:03 MST 2000
FROM:	valdes

BUG:	When the imtype environment variable contains a comma, e.g.
	when imtype="fits,inherit", the following error occurs:

	ERROR on line 108: Attempt to access undefined local variable `len'

	The workaround is to change imtype to only include the extension
	being used; i.e. imtype=fits.

STATUS:	Fixed in version "2.2: 20 June 2000".

NUMBER:	467
MODULE:	dataio.export
SYSTEM:	V2.11 - V2.11.3a
DATE:	Fri Jun 23 09:51:22 MST 2000
FROM:	fitz

BUG:	The header text for the PGM and PPM formats is incomplete (i.e.
	missing the Y-dimension and max pixel value) for byte-swapped
	systems such as PCIX and Dec Alpha.  There is no workaround for
	this, contact site support for a code change or patched binary.

STATUS:	Fixed for future releases.

NUMBER:	468
MODULE:	astcalc, asthedit
SYSTEM:	-V2.11.3a
DATE:	Thu Jun 29 11:14:56 MST 2000
FROM:	valdes

BUG:	The "clput" function does not work and results in the error:

	ERROR: function `clput' requires 1 arguments

	This is caused by a typo in the source such that the function
	is not correctly interpreted.  There is no workaround other
	than fixing the source.

STATUS:	Fixed for the next release.

NUMBER:	469
MODULE:	specplot
SYSTEM:	-V2.11.3p1
DATE:	Mon Aug 14 11:01:13 MST 2000
FROM:	valdes

BUG:	You cannot specify units using the "units" parameter that consist
	of more than one word.  For example "log angstroms", "inv
	centimeter", or "km/s 4000 ang" will not work.  There is no error
	message and instead the default display units (the "units_display"
	attribute in the WAT keywords) are used.  The units can be set
	interactively with the ":units" colon command.  If you want to get
	such units running SPECPLOT non-interactively the only workaround
	is to set the "units_display" attribute.  This can be done either
	with careful header editing (HEDIT or HFIX) or by displaying with
	SPLOT, setting the units, and then writing out the spectrum.

STATUS:	Fixed in future releases.

NUMBER:	470
MODULE:	display / cursor readback
SYSTEM:	V2.11-V2.11.3
DATE:	Tue Sep  5 14:15:18 MST 2000
FROM:	valdes

BUG:	When an odd sized image is displayed into a frame buffer that is
	smaller than the image without filling, thus letting the display
	task trim the image to fit, the y cursor readback from the display
	server will be off by one.  The same behavior will also occur in x
	if the image is loaded with a flipped image section such as
	image[-*,*].  The error can be avoided in several ways.  One is to
	use a frame buffer size which is larger than the image, another is
	to use an image section that 1) is smaller than the frame buffer,
	2) is an even number of pixels in y, or 3) flips the
	image in y.

STATUS:	The is fixed in V2.11.4.

NUMBER:	471
MODULE:	mscred.mscsetwcs
SYSTEM:	-V4.1: September 15, 2000
DATE:	Mon Sep 18 09:32:46 MST 2000
FROM:	valdes

BUG:	This task will fail with the message

	ERROR on line 81: No write permission on file (String_File)

	when a long list of images is used.  The workaround is to
	break the operation up into smaller sets of images.

STATUS:	Fixed in the next release.

NUMBER:	472
MODULE:	mscred.ccdproc
SYSTEM:	V4.0 - V4.1: September 20, 2000
DATE:	Mon Oct  2 10:27:34 MST 2000
FROM:	valdes

BUG:	When a dependent calibration exposure, one that is not being processed
	directly but needs to be processed to continue with the specified
	target exposure, is processed a query

	List of output bad pixel masks:

	is given.  The workaround is to respond with carriage return or
	the equivalent of a null string "".  There will be two queries
	per calibration image.

STATUS:	Fixed in the V4.1: October 2, 2000 release.

NUMBER:	473
MODULE:	rv.fxcor
SYSTEM:	V2.11 - V2.11.3b  PC-IRAF
DATE:	Wed Oct 18 12:39:59 MST 2000
FROM:	fitz

BUG:	The main correlation plot would sometimes not be drawn when 
	using long spectra on a Linux system.  With spectra of ~10000
	points or more the main plot of the task would not display
	the ccf but would show the fit points and fit function.  This
	was traced to a bug improperly moving data to the plotting arrays.
	There is no reliable workaround, contact site support for a code
	change or patched binary.

STATUS:	Fixed for the next release.

NUMBER:	474
MODULE:	mscred.ccdproc
SYSTEM:	-V4.1: December 5, 2000
DATE:	Thu Dec  7 14:22:10 MST 2000
FROM:	valdes

BUG:	When a flat field is processed in a certain way as noted below,
	applying it to object data with CCDPROC will cause each flat field
	extension to be normalized differently.  This will be evident in
	the log file where the scale factor for the flat field extensions
	will be listed with different values rather than the same value.
	The flat fielded object image will then appear with different gain
	levels of the same relative magnitude as the flat field in each
	extension.  Note that small residual gain differences are normal
	due to dome flats not exactly matching the sky and these are
	removed by using sky flats.

	The incorrect behavior occurs when the flat field is processed
	after combining to a master flat field followed by making a
	new version of the flat field, such as when making a pupil ghost
	corrected flat field.  The error occurs because a time stamp for
	the CCDMEAN scaling keyword, the keyword CCDMEANT, is added by
	CCDPROC and checked against the time the image was last modified.
	After the first processing all the CCDMEAN keywords will correctly have
	the same value.  However, any modified version of the flat field
	will then invalidate the time stamp causing the next execution of
	CCDPROC that applies the flat field to compute new CCDMEAN values
	separately for each extension.  If the CCDMEANT keyword is absent
	then CCDPROC will not recompute the normalization value.  Thus the
	workaround is to delete the CCDMEANT keyword from all extensions
	either before making a new version of the flat field or in the flat
	field version to be applied by CCDPROC.

	In the most common case where individual flat fields are processed
	with scaling followed by combining to a master flat using the task
	FLATCOMBINE the bug does not occur because the scaling and
	combining operation eliminates the CCDMEANT keyword.  Also when the
	flat field is not modified after it has been processed by CCDPROC
	the error will not occur.  So almost all users will not have
	encountered this problem.

STATUS:	The MSCRED release of December 7, 2000 fixes this problem by
	having CCDPROC eliminate the CCDMEANT keyword when the flat
	field is first processed.

NUMBER:	475
MODULE:	mscred.ccdproc
SYSTEM:	V4.1 for Solaris (September 20 through December 7 releases)
DATE:	Tue Dec 12 14:28:14 MST 2000
FROM:	valdes

BUG:	Using BPM for the "fixfile" parameter when doing bad pixel mask
	corrections does not work with the prebuilt binaries.  Symptoms
	are that the bad pixels are not removed and the logfile, verbose
	output, and header processing keyword will indicate an EMPTY
	mask was used.  The workaround is to use !BPM for the value of
	the keyword or link the package yourself.

	This problem occured because the binaries were built using
	development libraries rather than the latest IRAF release
	libraries.  An error was introduced in the development system
	that causes the reported bug.

STATUS:	Fixed in releases after December 11.

NUMBER:	476
MODULE:	mscred: ccdproc zerocombine flatcombine darkcombine
SYSTEM:	- V4.1: December 7, 2000
DATE:	Wed Dec 13 09:57:43 MST 2000
FROM:	valdes

BUG:	When using bad pixel masks with fixpix=yes in CCDPROC (or when
	CCDPROC is called in the scripts ZEROCOMBINE, DARKCOMBINE, and
	FLATCOMBINE that do both processing and combining) the memory
	used internally for the masks is not released.  When doing many
	images this leads to a growing memory usage possibly resulting in
	an out-of-memory error.  People with machines having large amounts
	of memory may not notice this problem.  The workaround if this
	problem is encountered is to break up the processing into small
	groups of mosaic exposures and use "flpr" between executions of
	CCDPROC.  Releases after December 7, 2000 fix this problem so
	updating MSCRED is the other solution.

STATUS:	There is a two stage resolution of this bug.  Until a new version
	of IRAF is released, the current release of MSCRED.CCDPROC includes a
	flpr between the processing of each mosaic exposure.  Under a
	new version of IRAF the problem is also fixed at the system level.

NUMBER:	477
MODULE:	rvcorrect
SYSTEM:	-V2.11.3p1
DATE:	Wed Jan 31 12:15:37 MST 2001
FROM:	valdes

BUG:	If an image is specified in the "files" parameter instead of
	the "images" parameter it can cause an exception, erroneous
	output, or no output at all.

STATUS:	In future releases the task will detect images in the "files"
	list and print a warning.

NUMBER:	478
MODULE:	proto.fixpix
SYSTEM:	V2.11-V2.11.3p2
DATE:	Thu Feb  8 11:39:09 MST 2001
FROM:	valdes

BUG:	FIXPIX may report an out-of-memory error.  This is caused by an
	inefficient use of memory (using more memory without reclaiming
	previously used memory).  This behavior only occurs when interpolation
	along columns is performed.  One workaround is to use multiple passes
	with fewer regions to be fixed per pass.  Another option is to
	use only line interpolation if that is reasonable.

STATUS:	Fixed for the next release.

NUMBER:	479
MODULE:	mscred.ccdproc
SYSTEM:	V4.2: January 30, 2001 (only)
DATE:	Thu Feb  8 14:23:08 MST 2001
FROM:	valdes

BUG:	In V4.2 the default for CCDPROC was changed to "merge=yes" with the
	idea being that if data did not require merging then it would not
	affect the data.  However, the change was such that if an input
	list includes some previously processed and some unprocessed
	files then when a new image is processed the last skipped processed
	image in the list will be deleted.  If you have the backup option
	turned on the orignal data for the deleted processsed image will
	still be available otherwise the data will need to be retrieved
	from tape.  The workarounds are not to mix processed and
	unprocessed data in the input list or turn off the merge option.

STATUS:	Fixed in the V4.3: February 8, 2001 version.

NUMBER:	480
MODULE:	pdm
SYSTEM:	-V2.113b
DATE:	Thu Feb 22 16:36:42 MST 2001
FROM:	valdes

BUG:	If the input data does not begin with the minimum x value (when
	there are two or three columns) then a memory corruption error may
	occur.  Even if it does not occur, the theta statistic will come
	out wrong and so all results will be invalid.  The workaround is to
	make sure the first data point of the input file(s) is the minimum
	value.  One could also sort the files, though if multiple files are
	being merged they should be merged externally into one sorted file
	or else insure the first input file has the proper minimum.

STATUS:	A fix was made to fix the immediate problem.  It is not clear
	whether there are other possible problems due to lack of a
	sorted input.

NUMBER:	481
MODULE:	mscred.combine (flatcombine, etc.)
SYSTEM:	V4.3: February 8, 2001 - V4.4: March 6, 2001
DATE:	Tue Mar 20 10:20:33 MST 2001
FROM:	valdes

BUG:	When using scaling or zero offsets the normalization of the factors
	may be incorrect.  This bug is compiler dependent and affects
	PC-IRAF (Suse and Redhat were explicitly checked) but not Solaris
	or Alpha.  What is intended is that the scale and zero factors be
	normalized to the first image.  The incorrect behavior is that only
	the first image is normalized.  What you see in the terminal and
	logfile report on the scale factors is the first image has a
	scaling of 1 and offset of 0 and the other images have values which
	are not correct and usually appear grossly wrong.  There is no
	workaround when scaling is needed.  A new version of MSCRED is
	required.

STATUS:	Fixed in V4.4: March 20, 2001.

NUMBER:	482
MODULE:	splot
SYSTEM:	-V2.11.3p2
DATE:	Wed May 16 10:25:49 MST 2001
FROM:	valdes

BUG:	When using the 'e' key to measure equivalent widths along with the
	error computation, if any pixel in the spectrum is negative or zero
	the errors will be printed as zero.  The workaround is to replace
	all the negative or zero values with a small positive value.

STATUS:	This is fixed for the next release by setting the value to zero
	for computing the uncertainty in the pixel.

NUMBER:	483
MODULE:	immatch.psfmatch
SYSTEM:	V2.11
DATE:	Wed May 16 14:46:37 MST 2001
FROM:	davis

BUG:	There is a symmetry problem in the convolution step if the psf
	matching kernel does not have 180 degree rotational symmetry, due
	to the fact that convolution kernel is not being flipped properly 
	before doing the convolution. The workaround is to create the
	psf matching kernel, rotate it 180 degrees, and then apply it
	with psfmatch or use the psfmatching kernel directly with 
	fconvolve.

	A floating point error may occur in the replace algorithm in
	rare cases due to the input to the log function not being checked
	for 0.0 values. The only workaround is to try the filter options
	"none" or "model".


STATUS:	Fixed for the next release of iraf. A fixed version of psfmatch
	is available in the external addon package immatchx.

NUMBER:	484
MODULE: mscimage, geotran, rotate, imlintran, [g/s/w]register, imtranspose,
	im3dtran
SYSTEM:	V2.11
DATE:	Fri Jun  1 11:39:39 MST 2001
FROM:	valdes

BUG:    When writing an output FITS image extension, for example,

	    cl> imtranspose abc out.fits[ext2,append]

	the following type of error may occur

	    Attempt to write out of bounds on file (<image>.fits_NNNN)

	where NNNN is some four digit number.  This occurs when the input
	data is operated upon in subblocks where the line dimension is
	smaller than the output dimension.  Therefore, the workaround is to
	set the line buffer block size (e.g. nxblock or len_blk) to
	be the size of the largest image dimension.  Alternatively one
	can create a single image intermediate file and then append that
	to the output with IMCOPY.

	THIS ONLY APPLIES TO CREATING AN OUTPUT EXTENSION AND DOES NOT
	APPLY TO SIMPLE SINGLE FITS OUTPUT IMAGES.  The most common case
	where output extensions are used is when running the mosaic task
	MSCIMAGE which calls GEOTRAN internally.  The workaround for that
	task is to set "nxblock" to a value larger than the largest input
	extension dimension.

STATUS: This problem is under investigation.

NUMBER:	485
MODULE:	longslit.fitcoords
SYSTEM:	-V2.11.3b
DATE:	Mon Jun  4 11:43:22 MST 2001
FROM:	valdes

BUG:    The user coordinates from IDENTIFY are double precision and
	are written to the database with 9 digits of precision.  FITCOORDS
	reads and uses this data in real precision.  The deletion point
	file with the user coordinates of the delete points is written in
	real precision.  The comparison between the coordinates written to
	the deletion list and later read again and the data read from the
	IDENTIFY database is done as a direct comparison of two real
	values.  Because of how the conversion and rounding between text
	and floating point representations are done this can result in
	deleted points which are in the deletion file to not be restored as
	deleted in subsequent runs of FITCOORDS.  There is no easy
	workaround.  The only possiblity is to match the values in the
	deletion file with the IDENTIFY database file and make the ascii
	representation be the same.  Working in units which require fewer
	significant digits to represent the coordinates may improve the
	behavior.  For example when working in the IR use microns instead
	of Angstroms in IDENTIFY/REIDENTIFY.

STATUS:	The direct equality will be replaced by a tolerance comparison in
	a future release.

NUMBER:	486
MODULE:	images.imgeom.magnify
SYSTEM:	V2.11.2 and later
DATE:	Thu Jun 21 15:14:56 MST 2001
FROM:	davis

BUG:	In some circumstances the previous block of output image lines may be
        repeated in the output image rather than a new block computed. This
	bug affects IRAF 2.11.2 and later systems, and is the result of a typo
	made when the task was upgraded to use the new interpolants, image
	i/o boundary extension etc.

	The problem is most likely to occur when the output image scale
	is > than the output buffer size of 16 lines.


STATUS:	Fixed for the next release. Work around include doing the magnify in
	more than one step or using the imlintran task.

NUMBER:	487
MODULE:	ccdproc
SYSTEM:	V2.11
DATE:	Thu Jul  5 08:35:00 MST 2001
FROM:	valdes

BUG:	When applying a dark count correction, the dark count calibration
	image is scaled to the data being calibrated using the ratio of
	the dark times.  The dark time for an image is the "darktime"
	keyword and if this is absent "exptime", where these may be
	translated to other keywords if a translation is given in the
	instrument file.  When a value for the dark time is found it
	is used without checking for zero values.  Therefore, if the
	dark count image has a dark time value of zero a
	floating divide or floating exception will occur.  The
	workaround is to edit the header to add the appropriate
	values.

STATUS:	In the next release an appropriate error message will be given.

NUMBER:	488
MODULE:	imcoords.ccmap
SYSTEM:	V2.11
DATE:	Fri Jul 20 08:28:08 MST 2001
FROM:	davis

BUG:	If the input coordinate list spans 0.0 hours right ascension, and
	the refpoint parameter is set to "coords", ccmap may produce a
	bad estimate for the reference point and a bad solution.

STATUS:	Fixed for the next release of IRAF and in the external addon package
	immatchx. The work around is to set the ccmap refpoint parameter to
	"user", and either enter the reference coordinates manually, or read
	them them from the associated input image header.


NUMBER:	489
MODULE:	identify
SYSTEM:	V2.9-V2.11.3b
DATE:	Thu Aug  2 09:45:58 MST 2001
FROM:	valdes

BUG:	When identified features have labels and when some features are
	deleted during fitting the labels no longer correctly correspond
	with the features.  This only applies to deleting during fitting
	and there is no error when deleting features in the identify
	window.  What happens is that when a feature is deleted during
	fitting the internal list is compressed by shifting the higher
	features down.  But this is not being done with the labels so that
	the label of the deleted feature becomes the label of the next
	feature and all subsequent features also have the wrong label.  The
	result is incorrect labels for the features when labeling is turned
	on for the graphs and in the database files.  There is no effect on
	dispersion calibration.  If one does not care about the labels then
	there is nothing to be concerned about.  There is no work around
	other than to avoid deleting features in the fitting mode or
	editing the database file after the fitting.

STATUS:	Fixed for the next release.

NUMBER:	490
MODULE:	scombine
SYSTEM:	-V2.113b
DATE:	Thu Aug  9 11:22:15 MST 2001
FROM:	valdes

BUG:	If only the number of desired output pixels is given then one
	would expect that the dispersion limits of the input data would
	be used and the dispersion would be adjusted to give the desired
	number of pixels.  Instead the minimum dispersion is used and the
	ending dispersion limit is adjusted.  No combination of
	parameters will cause the dispersion to be adjusted to satisfy
	the other parameters.  The only workaround is to specify the
	desired dispersion.

STATUS:	Fixed for the next release.

NUMBER:	491
MODULE:	immatch.xregister
SYSTEM:	V2.11
DATE:	Wed Oct 17 15:01:18 MST 2001
FROM:	davis

BUG:	In interactive mode xregister is only using the first correlation
	region to compute the shifts, rather than averaging the shifts
	computed for all the regions.

STATUS:	Fixed for the next release of IRAF and in the external addon package
	immatchx. The woraround is to use non-interactive mode if possible. 

NUMBER:	492
MODULE:	imcoords.wcsctran
SYSTEM:	V2.11
DATE:	Sat Dec  8 10:32:24 MST 2001
FROM:	davis

BUG:	Wcsctran may fail with a "Cannot write to string_file" error if
	the input image is dimensionally reduced, i.e. a section of higher
	dimensioned parent image. The bug is caused by an uninitialized
	array. If the array is accidentally initialized to 0 the bug will
	not occur.

STATUS:	Fixed for IRAF 2.12. There is no workaround.

NUMBER:	493
MODULE:	mscred.ccdproc
SYSTEM:	V4.6
DATE:	Thu Feb 21 14:31:03 MST 2002
FROM:	valdes

BUG:	When the "xtalkcor" option is selected but no corrrection is
	performed, either because it was done previously or an error
	occurs, then various warning messages about deleting non-existent
	files will occur.  One way the crosstalk operation will fail is if
	the crosstalk calibration file is not found due to a missing
	XTALKFIL keyword, an error in specifying the file to use, or the
	file is not available.  When the error in ccdproc happens in the
	various combine scripts (zerocombine, flatcombine, etc.) with
	process=yes, this will abort these scripts.

	When the error occurs in running ccdproc directly, the warnings can
	be ignored or the crosstalk option can be turned off.  When this
	occurs in the combine scripts, causing them to abort, turn off the
	process option or the xtalkcor option in ccdproc.

STATUS:	The bug is due to a typo introduced during the last change to this
	task.  The bug is fixed in V4.7 of mscred.

NUMBER:	494
MODULE:	ccdmask
SYSTEM:	-V2.11.3
DATE:	Thu Feb 28 09:09:49 MST 2002
FROM:	valdes

BUG:	If the last line or column is found to be a bad pixel but the
	pixel has no interior neighbor which is bad, then the mask pixel
	value will be a number corresponding to the number of contiguous
	bad pixels along the last line or column which includes that
	pixel.  In other words the pixel will not be set to the specified
	linterp, cinterp, or eqinterp value.  Since the pixel is correctly
	identified as bad the mask may be used though if control over the
	direction of interpolation is needed the values should be reset as
	needed.

STATUS:	Fixed in V2.12.

NUMBER:	495
MODULE:	imcombine, ccdred.combine, mscred.combine
SYSTEM:	-V2.11.3
DATE:	Thu Apr 18 11:44:40 MST 2002
FROM:	valdes

BUG:	When combining with "offsets=wcs" or "offsets=world" and the
	LTV/LTM keywords are different between the images the offsets are
	incorrectly computed.  The workaround is to reset the physical
	coordinate sysetm with "wcsreset <images> wcs=physical".

STATUS:	Fixed in V2.12.  Version of combine in mscred prior to the
	date of this report also have this bug and later releases
	are fixed.

NUMBER:	496
MODULE:	guiapps.spectool
SYSTEM:	All
DATE:	Wed May 29 09:39:07 MST 2002
FROM:	valdes

BUG:	When spectool (or tutorial) is run multiple times without
	resetting the executable with "flpr", it is possible to get a
	segmentation violation before displaying any spectrum on the second
	or later executions in certain situations.  The main situation
	where this might occur is running spectool without a spectrum
	filename argument and then using the "Read" panel to browze for a
	spectrum to display.  The specific case where this bug was found
	was modifying the file template.  This bug is caused by an
	uninitialized pointer.  Note that after you have displayed a
	spectrum any error (including a segmentation error) will not be due
	to this bug.  The workaround is simply to use flpr between
	executions.  If an error occurs use flpr and continue though
	occasionally the terminal window may become locked and the xgterm
	might need to be restarted.

STATUS:	Fixed in distributions after the date of this report.

NUMBER:	497
MODULE:	imcombine, mscred.combine, mscred.mscimage
SYSTEM:	V2.12, mscred V4.7: May 2002
DATE:	Fri Jun 14 15:23:16 MST 2002
FROM:	valdes

BUG:	A segmentation violation (a reference to an invalid memory address)
	is possible because of a bug in a array length calculation.  This
	problem was seen with mscred.mscimage (which calls mscred.combine)
	on PC-IRAF.  Whether this occurs with other systems is unknown.
	The error occurs almost immediately.  There is no workaround if the
	error occurs.

STATUS:	A new version of mscred is available with the fix.  The next
	patch version of IRAF will fix the problem in imcombine.

NUMBER:	498
MODULE:	nmisc.starfocus, nmisc.specfocus, nmisc.psfmeasure
SYSTEM:	NMISC Jan 01, 2000 version for  Redhat/Linux
DATE:	Tue Jun 18 14:48:36 MST 2002
FROM:	valdes

BUG:	Running the PSF and focus tasks in the NMISC package on some
	systems can result in an immediate segmentation violation.  This
	was reported on PC-IRAF for RedHat, though it will likely occur
	on other similar systems.  There is no workaround but a new
	June 2002 distribution corrects this problem.  Note that
	in V2.12 these tasks are included in the package noao.obsutil
	and it is not necessary to install the nmisc package.  The
	bug is not present in the V2.12 obsutil version.

STATUS:	Fixed in a June 2002 distributions of the NMISC external package.

NUMBER:	499
MODULE:	immatch.xregister
SYSTEM:	V2.12
DATE:	Thu Jun 20 13:15:59 MST 2002
FROM:	davis

BUG:	If the xregister task parameter interactive = yes and the output
	images are defined then the computed shifts are not applied. This
	occurs because the reinitialization routine triggered by the 'n'
	keystroke command is in the wrong place. 

STATUS:	Fixed for the next patch / release of IRAF. The work around is to
	run xregister twice, once interactively to compute the shifts, and
	again non-interactively to apply them.

NUMBER:	500
MODULE:	apphot package
SYSTEM:	V2.12 and earlier
DATE:	Fri Jun 21 09:21:08 MST 2002
FROM:	davis

BUG:	In interactive mode the v keystroke will not update the aperture
	size or algorithm parameters correctly for the next measurement if
	the cursor position does not change significantly.

STATUS:	Fixed for the next patch / release of IRAF. The work around is to
	use the equivalent colon commands or move the cursor significantly
	after the last measurement.

NUMBER:	501
MODULE:	quadred.quadproc
SYSTEM:	V2.12
DATE:	Fri Jul  5 11:16:30 MST 2002
FROM:	valdes

BUG:	The QUADPROC task, which is essentially the same as the
	ARED.QUAD.QUADPROC external package version, can fail with
	a divide by zero error.  This is due to an script error where
	the multiamp data is not split into pieces.  The workarounds
	are to either use QUADRED.CCDPROC (which is the recommended
	replacement for QUADPROC anyway) or to copy, edit, and
	redefine the script subtask qproc.  For the latter workaround
	contact iraf support (iraf@noao.edu) for instructions.

STATUS:	Fixed for the next release.

NUMBER:	502
MODULE:	pl files and fixpix, imreplace, and others
SYSTEM:	V2.12
DATE:	Mon Jul 22 08:42:45 MST 2002
FROM:	valdes

BUG:	Between IRAF versions 2.11 and 2.12 there was a change in the
	structure of pixel list (pl) files to allow for larger images.  The
	change was made so that old format pl files can be read.  However,
	updating of old format files is not supported.  This means some
	tasks that truly work in-place, such as IMREPLACE, will fail.
	(Tasks that replace the input file by their result using a
	temporary intermediate file, which are more common, are not truly
	in-place operations and so do not have this problem.)  It is a bug
	that in-place update operations will result in the file being
	deleted.  Some tasks don't actually write out a pl file but
	internally modify it.  The task FIXPIX is in this class.  This will
	result in the same type of error.  Typically the error is "Cannot
	update image header".  The workaround is to use IMCOPY to create a
	new version of the pl files when starting with V2.11 or early files
	but working with V2.12.

STATUS:	There is currently no plan to support pl update operations on
	the older pl format.

NUMBER:	503
MODULE:	ccdred: mkfringe, mkillumcor, mkillumflat, mkskycor, mkskyflat
SYSTEM:	V2.11.2 - V2.12.1
DATE:	Wed Jul 31 11:47:49 MST 2002
FROM:	valdes

BUG:	In V2.11.2 the CCDPROC task added an "output" parameter.  Because
	the tasks listed above have the option to call CCDPROC to do
	preprocessing and also have a parameter "output" there can be
	confusion about the output parameter.  If the task output
	parameter is given explicitly on the command line; i.e.

	    cc> mkillumcor in out

	Then the correct output is produced.  However, if the task
	is excuted in hidden mode (such as with a :go from EPAR) or
	without the output on the command line where one expects a
	query, then the CCDPROC.OUTPUT parameter is used instead which
	can lead to either the input being replaced by the output or
	whatever is set in that parameter being used.

	The workarounds are 1) put the output name explicitly on the
	command line or 2) set the desired output name in the CCDPROC
	parameters.


STATUS:	Fixed for the next release.

NUMBER:	504
MODULE:	nproto.objmasks
SYSTEM:	V2.12-V2.12.1
DATE:	Tue Aug  6 16:03:28 MST 2002
FROM:	valdes

BUG:	This task may abort with a floating divide error.  This is caused
	by the first pass estimate of the background sigma using a
	planar fit.  The can produce zero or negative sigma values.
	The workaround is to set the "fitxorder" and "fityorder"
	parameters to 1 in the hidden parameters set objmasks1;
	i.e. epar objmasks1.

STATUS:	In the next release the initial sky will still be fit by a surface of
	some specified order but the initial sigma will be purely a
	constant.

NUMBER:	505
MODULE:	data.export
SYSTEM:	V2.11 - V2.12.1
DATE:	Fri Aug  9 15:03:10 MST 2002
FROM:	fitz

BUG:	The task was failing to write a PPM file properly when the input
	image contained an odd number of columns, resulting in a corrupted
	image.

STATUS:	PPM files interleave the pixels, but when there are an odd number of
	columns in the image the resulting line contains an odd number of
	bytes/line.  IRAF file I/O cannot properly write data and the task
	was not structured to buffer lines for a case such as this.  The
	task will now truncate the last column of the input image so the
	output will contain an even number of bytes.  The workaround is
	simply to copy out a new image with an even number of columns before
	running the task.

	Fixed for future releases or contact site support for a code change.

NUMBER:	506
MODULE:	imalign
SYSTEM:	-V2.12.1
DATE:	Mon Aug 19 11:36:28 MST 2002
FROM:	valdes

BUG:	The error "parameter `    7' not found" may occur, where the number
	may vary.  This is caused by a corruption of the centroiding
	information by the warning messages.  The workaround requires
	making a private copy of the script with a small change:

	cl> immatch			    	# load package
	im> copy immatch$imalign.* home$    	# copy to home directory
	im> edit home$imalign.cl	  	# edit private copy
	  Change: verbose=verbose, >& tmpfile)
	  To:     verbose=verbose, > tmpfile)
        im> redefine imalign=home$imalign.cl    # redefine imalign

	The warnings, which can be ignored, will now appear on the terminal.
	Contact iraf@noao.edu for more information.

STATUS:	The problem is fixed in the next release.

NUMBER:	507
MODULE:	imreplace
SYSTEM:	-V2.12.1
DATE:	Wed Sep  4 09:52:48 MST 2002
FROM:	valdes

BUG:	When using IMREPLACE with integer images and with a grow radius,
	the specified lower limit is not properly adjusted to include the
	lower limit if given as an integer.  With radius=0 a different
	subroutine is used and so it works correctly.  The workarounds are
	to use a fractional lower limit; i.e. 0.5 to include values of 1 or
	to convert to real images.

STATUS:	Fixed for the next release.

NUMBER:	508
MODULE:	imshift
SYSTEM:	-V2.12.1
DATE:	Thu Sep 12 17:05:20 MST 2002
FROM:	valdes

BUG:	Using a shift smaller than the precision of a real value
	(~10^-6) causes the image output to actually have a shift of 1
	pixel except at the edges.  This is caused by the fact that while
	the shift is seen as non-zero, one plus the shift is not
	seen as different from 1.  There is no workaround other than
	avoiding using very small shifts.  Note that using such small
	shifts is computationally not significant.

STATUS:	Fixed in the next release by doing computations in double
	precisions when appropriate.

NUMBER:	509
MODULE:	APPHOT: CENTER, FITPSF, FITSKY, PHOT, QPHOT, POLYPHOT, RADPROF, WPHOT
SYSTEM:	V2.12.1 and earlier
DATE:	Tue Oct  1 11:28:22 MST 2002
FROM:	fitz, valdes

BUG:	The handling of the "default" parameter value for coordinate lists
    	failed when the input list had more than one image, resulting in
	either an "Illegal file descriptor (bad fd or file not open)" 
	message or the task silently re-using the coordinate list from the
	first image.  The workaround is to explicitly specify the coordinate
	file list using a template, for example

		cl> phot *.fits coords="*.coo.1"


STATUS:	Fixed for the next release.  Contact site support for a patched
	binary or code changes.  Note that all tasks in this package which
	allow this value are affected and have been modified.

NUMBER:	510
MODULE:	mscred.ccdproc
SYSTEM:	-V4.7: June 14, 2002
DATE:	Wed Oct 23 14:56:41 MST 2002
FROM:	valdes

BUG:	The syntax for the "bleed" parameter of the form
	saturation-<constant> or saturation/<constant> is not recognized.
	This is due to a bug in parsing the string.  There is no workaround
	other than to use an explicit value, mean+<constant>, or
	mean*<constant>.

STATUS:	Fixed for the next release.

NUMBER:	511
MODULE:	crutil.craverage
SYSTEM:	-V2.12.1
DATE:	Wed Oct 23 15:49:21 MST 2002
FROM:	valdes

BUG:	If a new output mask is specified, as opposed to updating an existing
	mask, then the grow option will fail to grow the detected pixels.
	The workaround is to do the growing in a separate call to CRGROW.

STATUS:	This is revised for the next release.

NUMBER:	512
MODULE:	imcombine, mscred.combine (and related combine scripts)
SYSTEM:	V2.12, MSCRED V4.7
DATE:	Fri Oct 25 09:50:21 MST 2002
FROM:	valdes

BUG:	The log output from the combining when using masks will incorrectly
	show all the images using the same mask (the one for the last image).
	This is an error in the output formating and the correct masks will
	actually be used.  There is no workaround other than to ignore
	the incorrect output.

STATUS:	This is fixed in V2.12.1 and will be fixed in the next release
	of MSCRED.

NUMBER:	513
MODULE:	icfit (apextract, curfit, ...)
SYSTEM:	V2.12-V2.12.1
DATE:	Mon Nov 18 16:11:42 MST 2002
FROM:	valdes

BUG:	When a single fitting (sample) region is defined and binning is used
	(|naverage| > 1) such that only a single binned fitting point
	results, then incorrect results or a segmentation error may occur.

	A case where this occurs is in apall/apsum when a single background
	region is defined and a large binning value is set to use the
	median or average of the background sample regions.  An inobvious
	situation resulting in this is when there are actually two
	background regions on either side of an aperture which are defined
	relative to the aperture.  If the aperture is defined or moves too
	close to the edge of the image such that one of the background
	regions goes entirely off the image, then this error can be
	triggered.

	This problem behavior was introduced in V2.12 when the stability of
	the fit was improved by only fitting only over the range of the data
	selected in by the sample region(s) rather than over the entire
	data set.

	The only workaround is to avoid this case.  For apall/apsum one
	needs to check for a background region going off the edge or be
	sure to use |naverage| smaller than the width of the background
	regions to insure at least two fitting points.

STATUS:	The case of a single fitting point in binned data will be handled
	properly in the next release.

NUMBER:	514
MODULE:	sensfunc
SYSTEM:	All
DATE:	Fri Nov 22 11:56:05 MST 2002
FROM:	valdes

BUG:	This report is not actually a bug but a guide as to the source of
	the error "no degrees of freedom" from the task SENSFUNC.  If the
	standard star file used with the task STANDARD has the standard
	values in flux units instead of magnitudes there will be no
	apparent error from that task.  But the file produced will have
	zero or very small numbers for the points to be fit by SENSFUNC.
	Using this file with SENSFUNC produces the error "no degrees of
	freedom".  So if you see this error and it is not solved by using
	lower fitting orders then it is probably the values in the file
	produced by STANDARD were generated from an incorrect standard data
	file given in flux.

	Why this has come up is that if you retrieve standard star data
	from the ESO web pages be sure to get ones given in magnitudes
	and not in flux.

STATUS:	No change is contemplated at this time.

NUMBER:	515
MODULE:	ahedit/awcspars
SYSTEM:	-V2.12.1
DATE:	Tue Dec  3 09:27:02 MST 2002
FROM:	valdes

BUG:	The parameter awcspars.wraunits used by the task ahedit may take
	the values "", "degrees", "radians", and "hours".  However, the
	value "hours" is incorrectly interpreted as "degrees".  So to
	specify that the reference ra/longitude coordinate is in hours use
	the value "" which defaults to hours.

STATUS:	Fixed for the next release.

NUMBER:	516
MODULE:	xdimsum.xmosaic
SYSTEM:	- August 8, 2002
DATE:	Fri Jan 24 15:41:15 MST 2003
FROM:	valdes

BUG:	When defining the shifts interactively IMEXAMINE is used in a mode
	where it determines the maximum number of frames available in the
	display server (XIMTOOL, DS9, SAOimage, etc).  However, this was
	not working correctly and it would attempt to use frames which are
	not available with DS9 (currently up to V2.2) and servers other
	than XIMTOOL.  There is no workaround other than to update the
	software. (After installing the new version be sure to
	reset the parameters for xdshifts; "unlearn xdshifts").

STATUS:	The script XDSHIFTS was modified in XDIMSUM version January 24, 2003
	to allow control of the maximum number of frames with a default
	value suitable for all display servers.

NUMBER:	517
MODULE:	rv.rvidlines
SYSTEM:	V2.12-V2.12.1
DATE:	Thu Feb  6 15:01:26 MST 2003
FROM:	valdes

BUG:	The task first parses the date keyword given in KEYWPARS which
	sets the year, month, day, and optionally the UT.  But then
	it parses the UT keyword given in KEYWPARS in the same way
	as for the date.  If this keyword is not in YYYY-MM-DDTHH:MM:SS.S
	format then the year, month, and day are clobbered the program
	crashes.  So in this version there is no substitue to using
	this format for the date and setting the UT keyword to
	be the same as the date keyword.

STATUS:	Fixed in the next release.

NUMBER:	518
MODULE:	guiapps.spectool
SYSTEM:	V1.1: December 2000
DATE:	Mon Feb 17 10:17:03 MST 2003
FROM:	valdes

BUG:	The Voigt profile fitting will crash with a segmentation error
	(or possibly just produce a bad fit).  This is a programming error
	where a subroutine return argument was mistyped.  There is no
	workaround other than updating.

STATUS:	Fixed in next release of the GUIAPPS package.

NUMBER:	519
MODULE:	spectool
SYSTEM:	-V1.2: February 2003
DATE:	Wed Feb 19 12:28:59 MST 2003
FROM:	valdes

BUG:	This is not exactly a bug but a limitation.  The Voigt profile fitting
	requires a minimum value for the width parameters to avoid
	numerical problems.  The limit is the value, in the current
	dispersion units, corresponding 3.3% of a pixel.  Attempting to set
	the value any smaller, say with fitting of the parameter turned
	off, will still result in a returned value corresponding to the
	minumum.  If you want one of the values to be zero then the profile
	type should be set to Gaussian or Lorentzian.  If you want a fixed
	value smaller than the minimum the only workaround is to resample
	the spectrum to finer pixels.

STATUS:	A smaller minimum could be put into the code but there will always
	be some point and so no changed is currently planned.

NUMBER:	520
MODULE:	onedspec.telluric
SYSTEM:	-V2.12.2
DATE:	Mon Feb 24 12:18:04 MST 2003
FROM:	valdes

BUG:	When an error, such as invalid parameters or missing images, occurs
	the task first does some error clean up operations before reporting
	the error.  The problem with this is that the actual error message
	can get lost and a misleading message, such as environment variable
	or image header parameter not found, will be given.  Avoid this
	requires a code change.  One way to sometimes get to the true error
	is to eliminate the misleading error by setting a value for the
	missing evironment or header parameter.  Also check carefully all
	the task parameters since most error are the result of problems
	with them.

STATUS:	The error handling will be improved in the next release.

NUMBER:	521
MODULE:	mscred.ccdproc
SYSTEM:	V4.8: November 4, 2002
DATE:	Fri Mar 14 14:59:49 MST 2003
FROM:	valdes

BUG:	When using the "merge" option in conjunction with "bpmasks" output
	and "fixpix" the merged masks are not properly created.  They will
	have names "tmp...", will not contain the right pixels, nor will
	the BPM pointers in the data images be correct.  The workarounds
	are either not merge the amplifiers or do the merging first and
	then do the fixpix and saturation/bleed trail masking after the
	extensions are merged.

STATUS:	The latest version of MSCRED has this bug fixed.

NUMBER:	522
MODULE:	mscred
SYSTEM:	V4.8: March 2003 releases
DATE:	Fri Apr 11 15:40:16 MST 2003
FROM:	valdes

BUG:	A bug was introduced in the coordinate conversions between pixels
	and celestial coordinates in the March 2003 releases.  The bug
	affects MSCCMATCH, MSCZERO, MSCCTRAN, MSCTVMARK, MSCPIXAREA,
	MSCGETCAT, and MSCIMAGE.  The bug was to not deproject the
	tangent plane correctly.  There is no workaround other than
	to update.


STATUS:	The bug has been fixed a a new release made.

NUMBER:	523
MODULE:	dohydra, doargus, dofibers, do3fiber
SYSTEM:	V2.11-V2.12
DATE:	Wed May 21 15:16:02 MST 2003
FROM:	valdes

BUG:    When dispersion linearization is selected and the dispersion
	parameters are modified in response to "Change wavelength
	coordinate assignments?" the new parameters are not applied to the
	extractions.  One workaround is to not linearize and then later use
	DISPCOR to linearize.

	The code fix is simple.  In the directory srcfibers$
	($iraf/noao/imred/src/fibers) change samedisp=yes to samedisp=no in
	proc.cl.  There is only one occurrence.  If you don't have
	permissions to modify the installed version you can copy this file
	to your working directory, modify it, and redefine it (after
	loading the package) with "redefine proc=proc.cl".  If you use the
	batch option you need to do the same thing to the file batch.cl.

STATUS:	Fixed for V2.12.2.

NUMBER:	524
MODULE:	reidentify
SYSTEM:	-V2.12.1
DATE:	Tue May 27 15:16:39 MST 2003
FROM:	valdes

BUG:	When doing REIDENTIFY with refit=no the "User Shift" shown in the
	log output is wrong after the first reidentifications.  This is
	because the previous shift was being applied inappropriately when
	doing the next case.  This only affects the log output and not the
	results in the database.

STATUS:	Fixed for the next release.

NUMBER:	525
MODULE:	guiapps.xapphot.xguiphot
SYSTEM:	-V1.1 (Feb03)
DATE:	Fri May 30 13:34:46 MST 2003
FROM:	valdes

BUG:	When changing the directory in the Files->Files panel a memory
	corruption or segmentation error can occur.  This is caused by
	closing the previous information but not marking it as closed.
	The only workarounds are to avoid using the directories and
	file panel if this occurs.

STATUS:	Fixed in V1.2 (May03).

NUMBER:	526
MODULE:	disptrans
SYSTEM:	V2.11.3 - V2.12.1
DATE:	Wed Jun  4 10:53:33 MST 2003
FROM:	valdes

BUG:	The option to resample to constant steps in the transformed dispersion
	units (linearize=yes) was broken in V2.11.3 due to a change in
	subroutine arguments.  The workaround is to use linearize=no
	to change the dispersion function associated with the pixels and
	then use DISPCOR to resample to linear increments.

STATUS:	Fixed for V2.12.2.

NUMBER:	527
MODULE:	mscred.ccdproc
SYSTEM:	- V4.8 April 11, 2003
DATE:	Tue Jun 24 13:30:57 MST 2003
FROM:	valdes

BUG:	The "fixpix" option suffers from a bug in the system mask code
	which can cause large segments of the image to be marked and/or
	interpolated as bad.  This happens when there are bad pixels near
	the right edge of the mask.  There is no workaround other than
	not using the fixpix option or making masks with the bleed trail
	and saturation options.  In recent versions this bug has been fixed
	in RedHat systems (using the distributed binaries) but not on
	Solaris.

STATUS:	The system bug has been fixed for the next IRAF patch release.
	It is also fixed in the June, 2003 version of the ssun binaries
	for mscred.

NUMBER:	528
MODULE:	ARTDATA tasks using random numbers and URAND
SYSTEM:	-V2.12.2
DATE:	Thu Aug  7 12:38:19 MST 2003
FROM:	valdes

BUG:	Many tasks using random numbers in ARTDATA (GALLIST, STARLIST,
	MKNOISE, MKOBJECTS, MK1DSPEC, MKECHELLE) as well as UTILITIES.URAND
	have a parameter to provide the seed value and a feature to specify
	it as INDEF to set it based on the system clock.  This is to allow
	generation of different results each time the task is called.
	However, the clock-based seed only changes each second so if the
	same task is called rapidly enough the seed may not change between
	executions.  The workaround is to include some delay beween calls,
	such as using sleep in scripts and CL loops.

STATUS:	The tasks listed above have been modified for the next release
	to avoid the behavior described above.

NUMBER:	529
MODULE:	imcombine
SYSTEM:	V2.11-V2.11.3
DATE:	Mon Aug 11 12:13:29 MST 2003
FROM:	valdes

BUG:	When specifying a bad pixel mask output with the "plfile" parameter
	it is possible to get

	    Warning: Operation would overwrite existing image (<name>.pl)

	This occurs when a problem is encountered and the task tries again
	with a different parameters to avoid the problem.  The bug is that
	the pl file is not deleted before tryng again.  This retry behavior
	occurs for several reasons, most commonly when the number of images
	being combined exceeds a limit of about 250 images.  The workaround
	is to "reset imclobber=yes".  Note that this resets the clobber
	policy for all IRAF tasks so one should probably reset it to "no"
	after working around this IMCOMBINE bug.

STATUS:	This is fixed in V2.12.

NUMBER:	530
MODULE:	apall, apsum
SYSTEM:	-V2.12.1
DATE:	Tue Oct 21 14:00:15 MST 2003
FROM:	valdes

BUG:	When DISPAXIS=1 there is a potential for a segmentation violation
	due to referencing outside an array.  This is more likely with
	variance weighting and cleaning but is not limited to this case.
	The bug does not affect the results if the task completes without
	error.  The only workaround is to transpose the image so that
	DISPAXIS=2.

STATUS:	Fixed for the next release.

NUMBER:	531
MODULE:	mkheader
SYSTEM:	-V2.12.1
DATE:	Mon Nov 10 15:57:28 MST 2003
FROM:	valdes

BUG:	The error

	     Old format = "%s%*t<>\n")
	     ERROR: No write permission on file (String_File)

	occurs when the number of keywords being added exceeds the internal
	limits of the header.  The workaround is to ignore this error,
	clean up any problems in the last keyword added, and add more
	headers in additional steps.

STATUS:	The unclear error has been replaced by the warning "Possibly failed
	to add all keywords".  This change was added for V2.12.2.

NUMBER:	532
MODULE:	apextract tasks
SYSTEM:	V2.11.2 - V2.12.1
DATE:	Wed Dec  3 14:20:07 MST 2003
FROM:	valdes

BUG:	Support for extractions on image sections added in V2.10.4 was
	lost in the V2.11.2 release.  By lost we mean that any image
	section specified for the input data is automatically stripped.

STATUS:	The ability to specify input images sections is restored in the
	V2.12.2 release.

NUMBER:	533
MODULE:	sarith, scopy
SYSTEM:	V2.12.2
DATE:	Tue Mar  9 14:15:08 MST 2004
FROM:	valdes

BUG:	In V2.12.2 a bug was introduced such that the "merge" option no
	longer works.  It produces a segmentation violation type of error.
	The workaround is to produce a temporary file and then use SCOPY.

	DOES NOT WORK:
	    sarith a - b a clobber+ merge+
	WORKAROUND
	    sarith a - b c
	    scopy a,c a clobber+
	    imdel c

STATUS:	Fixed for the next release.

NUMBER:	534
MODULE:	test
SYSTEM:	V2.12
DATE:	Thu Mar 25 11:37:43 MST 2004
FROM:	fitz

BUG:	...bug

STATUS:	...fixed

NUMBER:	535
MODULE:	imcombine
SYSTEM:	V2.12.1-V2.12.2
DATE:	Thu Apr  8 16:48:28 MST 2004
FROM:	valdes

BUG:	When combining one-dimensional images usng offsets the result is wrong.
	The workaround is to promote the images to 2D using IMSTACK; i.e.
	"imstack im1 im2" where im1 is the 1D image and im2 is the 2D
	image with one line.

STATUS:	Fixed for the next release.

NUMBER:	536
MODULE:	apall, apsum
SYSTEM:	-V2.12.2
DATE:	Fri May 21 16:14:31 MST 2004
FROM:	valdes

BUG:	When an aperture trace is lost the region of the trace fit is less
	than the range of the dispersion.  However, during extraction the
	trace is evaluated at all points along the dispersion.  The
	extrapolation of the fit can cause problems resulting in errors
	such as out of memory or salloc underflow.  The only workaround
	is to eliminate the aperture with the bad trace or use the 
	interactive trace fitting options to constrain the fit, such as
	by adding dummy points, to give a well behaved trace fit.

STATUS:	In future releases evaluation of the trace will use
	fit at the end point when extrapolating outside the range of
	the fit.

NUMBER:	537
MODULE:	fixpix
SYSTEM:	-V2.12.2
DATE:	Tue Jun 22 14:19:28 MST 2004
FROM:	valdes

BUG:	Column interpolation does not work except under special circumstances.
	The bug is that a count is made of the number columns containing
	pixels to be replaced.  This number is incorrectly used in place of
	the number of columns in the image.  For instance if the
	description of the pixels to be fixed is a single column then the
	task only allows column interpolations in the first column.
	Knowing this one crude workaround is to specify one region to be a
	whole line; for instance the region consisting of the first image
	line.  The other workaround is to transpose the image, use line
	interpolation, and then transpose back.

STATUS:	Fixed for the next release.

NUMBER:	538
MODULE:	mscred.msccmatch
SYSTEM:	V4.8: November 6, 2003 -
DATE:	Thu Jul 15 13:59:37 MST 2004
FROM:	valdes

BUG:	In the November 6th release of MSCRED the task MSCCMATCH calls
	GEOMAP with the parameter "maxiter".  This parameter was added
	to GEOMAP in V2.12 IRAF.  Therefore, MSCCMATCH will abort with
	an error about "maxiter" when a recent version of MSCRED is
	installed and used with V2.11 IRAF.  The workarounds are to
	update IRAF, go back to an earlier version of MSCRED, or patch
	the immatch$geomap.par file to add the line

	maxiter,i,h,0,,,Maximum number of rejection iterations

STATUS:	Currently no changes are planned to maintain recent versions of
	MSCRED which are compatible with V2.11 IRAF.

NUMBER:	539
MODULE:	ccmap, ccsetwcs, msctpeak
SYSTEM:	-V2.12.2a
DATE:	Tue Aug 31 09:24:53 MST 2004
FROM:	valdes

BUG:	The code which updates image headers with a TNX/ZPX WCS solution
	produced by CCMAP could fail so that evaluation of coordinates from
	the image would not be correct or agree with CCTRAN.  The failure
	is more likely to occur with small pixel scales and higher order
	distortion functions.  The problem is due to an incorrect check for
	a singular matrix when determining the TNX coefficients for the
	header.  When the code decides the matrix is singular, coefficients
	are set to zero and the evaluation is wrong.  Since this either
	happens or doesn't happen it means that there is no problem with
	accuracy until the bug is triggered.  The problem is in the GSURFIT
	math library which could also affect other tasks built on it,
	though no problems related to it are known currently.

STATUS:	The bug was identified and fixed in the math library.

NUMBER:	540
MODULE:	ecidentify/ecreidentify
SYSTEM:	-V2.12.2a
DATE:	Fri Sep 10 13:02:53 MST 2004
FROM:	valdes

BUG:	ECIDENTIFY and ECREIDENTIFY are supposed to work in terms of "physical"
	coordinates which are independent of different image sections
	applied to the data at different stages in the reduction process.
	However, there was a bug where a transformation was applied in the
	wrong direction.  A symptom would be that marking a feature would
	put the tick mark in the wrong place.  The only workaround is to
	either avoid any image sections in the reduction steps leading up
	to these tasks or to make the two coordinate systems the same by
	resetting the physical coordinate system with WCSRESET
	(i.e. wcsreset <images> wcs=physcial).  For those less familiar
	with the logical and physical coordinate systems, if there are
	keywords beginning with LTV and LTM keywords in the header then
	there is a physical coordinate system defined which would usually
	be different than the image based logical coordinate system.

STATUS:	Fixed for the next release.

NUMBER:	541
MODULE:	ccsetwcs
SYSTEM:	-V2.12.2
DATE:	Fri Oct  8 13:49:01 MST 2004
FROM:	valdes

BUG:	The help says that one may specify a list of images and a single WCS
	database record but this does not work.  The workaround is to
	repeat the record name to match the number of images.

STATUS:	Fixed to work as described in the help for the next release.

NUMBER:	542
MODULE:	allstar
SYSTEM:	-V2.12.2a
DATE:	Thu Nov 18 13:37:44 MST 2004
FROM:	valdes

BUG:	When a field contains broad objects a divide by zero error can
	occur when computing the sharpness parameter.  There is no
	workaround when this happens.

STATUS:	This has been fixed for the next release.  An early release
	binary is available from the IRAF group (iraf@noao.edu).

NUMBER:	543
MODULE:	craverage
SYSTEM:	-V2.12.2
DATE:	Wed Nov 24 10:26:57 MST 2004
FROM:	valdes

BUG:	A segmentation violation will occur when the "crmask" parameter is
	set to an existing mask.  The intent was to allow an existing mask
	to be used to exclude known bad pixels from the calculation and then
	add the detected cosmic rays to the mask.  But a bug in the code
	prevents this from working.  The workaround is to not use an
	existing mask in "crmask".  If one wants to end up with a mask
	describing the detected cosmic rays as well as the previously
	determine bad pixels then specify a new mask and merge the
	detectected cosmic rays with the previous mask.  There is no
	workaround to allow using the pre-existing mask to exclude pixels
	from the calculation.

STATUS:	Fixed for the next release.

NUMBER:	544
MODULE:	echelle.scombine
SYSTEM:	V2.12.2
DATE:	Wed Jan 19 08:44:47 MST 2005
FROM:	valdes

BUG:	Changes to SCOMBINE in V2.12.2a made it a separate executable.  The
	ECHELLE package definitions, however, failed to be updated so when
	trying to run SCOMBINE from the echelle package the following error
	message is produced.

	    ERROR: task `scombine' has no param file

	The solution is editing the echelle$echelle.cl file so that it
	reads as shown below.  A simpler workaround is to load the onedspec
	package and run scombine from that package.

STATUS:	Fixed for the next release.

Modifications to echelle$echelle.cl:

...
task    continuum,
        deredden,
        dispcor,
        dopcor,
        ecidentify,
        ecreidentify,
        refspectra,
        sapertures,
        sarith,
        sflip,
        slist,
        specplot,
        specshift,
        splot           = "onedspec$x_onedspec.e"
task    scombine        = "onedspec$scombine/x_scombine.e"
...

Note that scombine has to be removed from the first block of task
definitions and added as a separate task statement.

NUMBER:	545
MODULE:	sarith
SYSTEM:	-V2.12.2a
DATE:	Tue Mar  8 10:46:27 MST 2005
FROM:	valdes

BUG:	When an output wavelength range is selected which does not overlap
	the input data and the output format is onedspec a segmentaion
	error occurs.  The correct warning message, "No pixels to extract"
	is printed but then the error cleanup was not handled correctly.
	This problem does not occur with multispec output which is,
	therefore, a workaround.  However, it is likely that the wavelength
	range was accidentally set incorrectly since an operation outside
	of the data is probably not intended.  Note that the correct
	behavior is to not produce an output spectrum in this case.

STATUS:	Fixed for the next release.

NUMBER:	546
MODULE:	mscred.ccdproc, mscred.mscmerge
SYSTEM:	-V4.8: May 11, 2004
DATE:	Fri Apr 15 16:55:02 MST 2005
FROM:	valdes

BUG:	CCDPROC produces a "Pixel subscript out of bounds" error when
	applying calibrations produced from binned and merged data.
	In other words, mosaic data with multiple amplifiers per
	CCD, which are taken with binning, will produce this error
	after running ZEROCOMBINE with merging enabled and applying
	this calibration to flat fields or objects.  This problem
	is caused by CCDPROC incorrectly updating the physical WCS
	for binned data.  This causes the merging of multiple amplifiers
	to produce incorrect section keywords.  This is particularly
	important for the CCDSEC keyword.  Attempting to apply merged
	calibrations with the invalid CCDSEC keyword causes the error.
	There are two workarounds.  One is to not merge the amplifiers
	at all or until all calibrations have been applied.  The other
	is to edit the CCDSEC keywords for merged calibration images
	produced by ZEROCOMBINE and FLATCOMBINE to reflect the true
	CCD section.  The error is normally that the first pixel in
	CCDSEC is zero rather than one.

STATUS:	Fixed for the next release of MSCRED.

NUMBER:	547 (see also 544)
MODULE:	argus, ctioslit, hydra, iids, irs, kpnocoude, kpnoslit
SYSTEM:	V2.12a-V2.12b
DATE:	Mon Apr 25 10:59:24 MST 2005
FROM:	valdes

BUG:    Changes to SCOMBINE in V2.12.2a made it a separate executable.  The
	package definitions for the packages listed above (see also number
	544 concerning the ECHELLE package) failed to be updated so when
	trying to run SCOMBINE (or a task that calls SCOMBINE such as
	DOHYDRA) the following error message is produced.

            ERROR: task `scombine' has no param file

	The solution is editing the <package>$<package>.cl file, where
	<package> is one of the modules listed above,  so that it reads as
	shown below.  A simpler workaround is to load the onedspec package
	and run scombine from that package.

STATUS: Fixed for the next release.

Modifications to <package>$<package>.cl:

...
task    ...,
	[scombine,]						<-- Delete line
	...,
	...		= onedspec$x_onedspec.e
task    scombine        = "onedspec$scombine/x_scombine.e"	<-- Add line
...

Note that scombine has to be removed from the first block of task
definitions and added as a separate task statement as shown.


NUMBER:	548
MODULE:	specplot
SYSTEM:	-V2.12.2a
DATE:	Mon May  2 11:03:20 MST 2005
FROM:	valdes

BUG:	When using a file for the cursor input the colon commands
	must include the x, y, and system values even if the spectrum
	is explicitly selected.  For example:

		0 0 1 :color[2] 2

	If this is not done then a floating exception results.  This is
	because the search for the nearest spectrum to the cursor position
	is always done even if the spectrum is specified explicitly.

STATUS:	In the next release the cursor position is optional.

NUMBER:	549
MODULE:	spectool
SYSTEM:	SPT V1.2: February 2003
DATE:	Tue Jun 21 11:35:40 MST 2005
FROM:	valdes

BUG:	When the arithmetic function needs to interpolate the spectrum it
	needs a parameter "interp" which was left out.  The workaround is
	to type 'string interp="poly5"' after loading the SPT package and
	before running SPECTOOL.

STATUS:	Fixed for a future release.

NUMBER:	550
MODULE:	spectool
SYSTEM:	SPT V1.2: February 2003
DATE:	Tue Jun 21 11:38:36 MST 2005
FROM:	valdes

BUG:	Use of spectra with the lookup world coordinate system, as produced
	by RSPECTEXT with "non-linear", causes various failures such as
	segmentation violations and memory corruption.  the workarounds are
	to use SPLOT and other equivalent tasks from the ONEDSPEC package.

STATUS:	The task is currently frozen.  This will be studied further if
	resources allow.

NUMBER:	551
MODULE:	doecslit
SYSTEM:	-V2.12.2
DATE:	Mon Nov 14 14:56:06 MST 2005
FROM:	valdes

BUG:	The sparams.refit parameter is not actually used during the arc
	reidentification step.  Instead doecslit will always attempt to
	refit the dispersion function.  There is no workaround other than
	fixing the appropriate script task doecslit$sdoarcs.cl to change
	the refit value from yes to sparams.refit.

STATUS:	Fixed for the next release.

NUMBER:	552
MODULE:	imcombine
SYSTEM:	V2.12.2
DATE:	Tue Feb 28 14:07:30 MST 2006
FROM:	valdes

BUG:	When the combine option is sum and weighting is selected an exception
	occurs.  The sum option was added as a later feature and a
	flag needed for weighting was not set.  There is no workaround to
	combine weighting and summing directly.  One can use "average" and
	the scale the result to the equivalent of a sum.

STATUS:	Fixed for V2.12.3.

NUMBER:	553
MODULE:	splot
SYSTEM:	-V2.12.3
DATE:	Tue May 16 11:08:14 MST 2006
FROM:	valdes

BUG:	If SPLOT is run more than once without flushing the process (flpr)
	then the default aperture will be that from the last execution.
	The consequence is that use of an image section to select an
	aperture in a multiaperture file may not display the intended
	spectrum.  The workaround is to use the command "flpr" before
	using an image section.

STATUS:	Fixed for the next release.

NUMBER:	554
MODULE:	dopcor
SYSTEM:	V2.13
DATE:	Tue May 23 16:11:05 MST 2006
FROM:	valdes

BUG:	The verbose output only prints information based for the last
	spectrum in a multispec file.  When a single correction is being
	applied to all apertures this is correct but when different
	corrections are being generated for different apertures, say when
	adding a correction to apertures which had different initial
	corrections applied this can be concerning.  The actual corrections
	are being applied correctly for each aperture but the verbose output
	may be misleading.  There is no workaround though it is not a data
	calibration error just a logging error.

STATUS:	To be fixed in a future release though no fix has yet been implemented.

NUMBER:	555
MODULE:	longslit.fitcoords
SYSTEM:	V2.13-Beta[12]
DATE:	Wed Jun 14 10:41:50 MST 2006
FROM:	valdes

BUG:	If the fitting axis is 2 (the identify/reidentify features are defined
	by cuts along the second axis) the y coordinate for the 2D fitting
	will be wrong.  You will notice this if data are plotted with one
	axis being the y coordinate.  The other way you would notice this
	is that the transformation won't correctly remove the distortions
	and make a correct wavelength solution.

	The only workaround is to transpose the data early before doing
	the feature identification and tracing.  Note that you must then
	also reset the physical WCS after the transpose with the command
	"wcsreset <images> wcs=physical".

STATUS:	Fixed for the next V2.13 release.

NUMBER:	556
MODULE:	splot, sarith, scombine, standard
SYSTEM:	-V2.13Beta
DATE:	Fri Oct 27 09:33:16 MST 2006
FROM:	valdes

BUG:	When matching one spectrum to another, the reference spectrum,
	for some operation (e.g. arithmetic, combining, standard star
	calibration) the first spectrum is converted to its natural
	WCS units.  If the reference spectrum is in different units
	the result will be wrong.  This is rare but a particular case
	is when SPLOT displays a spectrum in some units, possibly set
	by the display units in the header or by the task parameter,
	and then a binary arithmetic operation is performed using a
	second spectrum.  Even if the second spectrum has the same
	display units it may be resampled to match the reference
	spectrum in the wrong units.  The code solution is to always
	resample in the current units of the reference spectrum.

	The workaround for the SPLOT example is to use the ":units"
	command to put the initial spectrum into the natural units
	of the second spectrum.  After the arithmetic you can changes
	the units back if desired.

STATUS:	Fixed for a future release.

NUMBER:	557
MODULE:	splot
SYSTEM:	-V2.13beta
DATE:	Mon Dec  4 15:29:44 MST 2006
FROM:	valdes

BUG:	When the dispersion function for a spectrum is log sampled,
	e.g. DC-FLAG=1, and there is also a logical/physical pixel offset,
	i.e. LTV1 is not zero, then writing out a new spectrum with the
	'i' key the results in a wrong WCS.  There is no workaround.

STATUS:	Fixed for a future release.

NUMBER:	558
MODULE:	mscimage
SYSTEM:	all release up to date
DATE:	Fri Mar 30 11:04:18 MST 2007
FROM:	valdes

BUG:	MSCIMAGE defines the resampled output world coordinate system
	(WCS) using a reference image WCS.  If this reference image
	has a ZPN projection an error will occur.  This is because when
	the output WCS is set the ZPN projection is inherited from the
	reference image but MSCIMAGE does correctly setup the output ZPN
	projection from the reference image.  So one must use a reference
	image with another projection such as TAN.

	What is confusing is that wcssource="parameters" implies that
	the output WCS is entirely defined by the task parameters.
	This is true for everything but the WCS projection type which is
	taken from the input image.  There is no parameter to set the
	projection explicitly and the MSCIMAGE script would need to be
	edited to access the projection parameter in the underlying call
	to a hidden task MSCWTEMPLATE.	MSCIMAGE automatically changes
	input projections of "tnx" and "zpx" (distorted projections) to
	"tan" since the point of MSCIMAGE is to resample to a simpler
	undistorted WCS.  A change will be made to also do this for "zpn".

	The workarounds when the input data uses ZPN are to use a reference
	image that doesn't have a ZPN WCS or edit mscsrc$mscimage.cl
	to change projection="" to projection="tan" in the call to
	MSCWTEMPLATE.  The code change to MSCWTEMPLATE could also be
	made and the MSCRED package recompiled but this is a more complex
	process and users should contact iraf.net for help.

	The recommendation for users with the most recent version of IRAF
	is to use the task imcoords.mkcwcs to create a reference WCS.
	This task creates a dataless image with the desired WCS.  It is
	basically like defining the WCS using the MSCIMAGE parameters
	except you have control over the projection and the tangent
	position.  The only thing that is less obvious is that you must
	set a reference pixel.	When building a mosaic you might set this
	to be roughly in the middle of the field.  For instance if the
	final image will be roughly 4Kx4K you might choose a reference
	pixel at (2100,2100).

	If you don't have MKCWCS you can call MSCWTEMPLATE directly to do
	the same thing.  Leave the input and reference image parameters
	empty, set wcssource="parameters" and fill in the parameters
	including the projection as "tan".  This will leave the reference
	pixel at (0,0) so you would use HEDIT to set CRPIX1 and CRPIX2
	to the desired point.  Alternatively, you could make a list of
	all the extensions in the input and specify that as the input
	in MSCWTEMPLATE.  This then does exactly what mscimage would do
	put give you access to the projection parameter.  In other words
	making the reference image manually this way is equivalent to
	editing the mscimage.cl script.


STATUS:	Future releases of MSCRED will convert input ZPN WCS to TAN WCS
	automatically.

NUMBER:	559
MODULE:	longslit.transform
SYSTEM:	-V2.12.3
DATE:	Tue Aug  7 10:39:13 MST 2007
FROM:	valdes

BUG:	When using log resampling (xlog=yes or ylog=yes) it is possible to
	get a segmentation error.  This is caused by taking the log and
	anti-log of coordinates and not getting back exactly the same value
	due to real precision problems.  This process caused an attempt to
	go outside the valid range of the interpolator.  This may be a
	rare problem but if it does happen one may be able to use the
	x1, x2, y1, y2 values to work around the problem.  The workaround
	for a future release is to use double precision and to impose
	range limits on data passed to the interpolator.

STATUS:	Fixed for the next release.


NUMBER:	560
MODULE:	CCFIND
SYSTEM:	V2.14
DATE:	Wed Jan 23 15:56:04 MST 2008
FROM:	fitz

BUG:	For an image with a ZPN projection, the transform code in mwcs tries 
	to reference the parent image to get the PV matrix keywords. This task
    	called sk_decwcs() to open the WCS, but this routine then unmaps
    	the image.  When the task later uses the saved 'mw' pointer to 
	transform coords the ZPN reference to the parent image is invalid 
	and results in a segfault.  Changed the code to call sk_decim() 
	directly and operate on the currently open image instead.

	There is no workaround other than to not set the 'usewcs' parameter
	and to set the WCS using the other parameters.  Contact iraf.net for 
	a new binary if needed.

STATUS:	Fixed for the next release.  



NUMBER:	561
MODULE:	imstatistics, mimstat
SYSTEM:	V2.14
DATE:	Tue Jul 15 11:03:18 MST 2008
FROM:	valdes

BUG:	The user supplied upper and lower data limits may be exceeded if
        clipping is used.  For instance, if the limits exclude all pixels
        the clipping with behave as if no pixels are excluded.  If not
        all pixels are excluded and the clipping thresholds computed
        (number of sigma * standard deviation) exceed the limit then
        the clipping threshold is used.  The only workaround is to not
        use clipping if the limit values are supplied or check first
        with no clipping to see if all pixels are excluded.

STATUS:	Fixed for the next release.

NUMBER:	562
MODULE:	mscred.ccdproc
SYSTEM:	V4.8
DATE:	Tue Aug 12 12:19:30 MST 2008
FROM:	valdes

BUG:	The fix for bug number 546 was not fully correct.  It works for
	binned data but results in an error for data which is flipped
	(e.g. when CCDSEC/DETSEC have a starting column greater than
	the ending column as in '[2048:1025,1:2048]'.  The error
	is that the resulting CCDSEC in the processed image will
	be off by one.  This can result is losing a column when
	merging multiple amps.

STATUS:	Fixed for mscred V4.9.

NUMBER:	563
MODULE:	imexpr
SYSTEM:	-V2.14
DATE:	Tue Aug 12 15:12:04 MST 2008
FROM:	valdes

BUG:	Literal (quoted) strings cannot be used in expressions stored in the
	expression database.  The quotes are stripped and then the error is
	that an operand by that name is not found.  As a warning, single
	quotes in the database are not interchangable with double quotes as
	they are on the command line.  They are interpreted as character
	constants and something like 'abc' will be expanded to 'a bc'.

STATUS:	Double quoted strings allowed in next release.

NUMBER:	564
MODULE:	ccdmask
SYSTEM:	-V2.14.1
DATE:	Fri Aug 22 09:27:06 MST 2008
FROM:	valdes

BUG:	The output mask from ccdmask is incorrect if the task has been run
	previously without starting the executable fresh.  The workaround
	is to type "flpr ccdmask" before executing this task to force a
	fresh executable.

STATUS:	Undiagnosed at present.  Only the workaround has been defined.


NUMBER:	565
MODULE:	imextensions
SYSTEM:	V2.13-V2.14
DATE:	Mon Aug 25 16:24:33 MST 2008
FROM:	valdes

BUG:	Specifying an extension version or range of versions results in an
	integer divide by zero.  This is a bug for which there is no
	around.

STATUS:	Fixed for the next release.

NUMBER:	566
MODULE:	display
SYSTEM:	V2.12.4/V2.14
DATE:	Tue Aug 26 17:10:07 MST 2008
FROM:	valdes

BUG:	The "ocolors" parameter was being used in place of the "bpcolors"
	parameter.  There is no workaround.

STATUS:	Fixed for the next release.

NUMBER:	567
MODULE:	apall, apedit
SYSTEM:	V2.11-V2.14.1
DATE:	Tue Oct  7 10:53:14 MST 2008
FROM:	valdes

BUG:	The :parameters and :apertures commands cause the task to exit with
	an error that parameter "apertures" isn't found.  This problem has
	existed for a long time due to a missing parameter in the hidden
	parameter sets.

STATUS:	Fixed for the next release.

NUMBER:	568
MODULE:	imcombine
SYSTEM:	-V2.14.1
DATE:	Tue Oct  7 12:52:35 MST 2008
FROM:	valdes

BUG:	When using avsigclip, ccdclip, or sigclip rejection around the
	median (mclip=yes) the resulting final median may be incorrect.
	This will generally only occur if unusually small low sigma values,
	such as lsigma=1, are used.  This was due to using a wrong
	variable.

STATUS:	This is fixed for the next release.


NUMBER:	569
MODULE:	cosmicrays
SYSTEM:	-V2.14.1
DATE:	Mon Oct 13 10:33:15 MST 2008
FROM:	valdes

BUG:	The message

	    ERROR: PLIO: reference out of bounds on mask 

	occurs when the image is not 2D.  This can be a conceptual problem
	for data which define a higher dimensionality but with length of 1;
	e.g. [2048,2048,1].  This is effectively a 2D image but some
	IRAF tasks designed for 2D images can have problems with this.

	The workaround is simply to use a 2D image section:

	    cosmicrays image[*,*,1]

	Of course one can also convert the image to 2D with imcopy or imslice.

STATUS:	No updates are currently planned and users should use the workarounds
	noted above.

NUMBER:	570
MODULE:	imexpr, mskexpr, or tasks other asks using the expression evaluator
SYSTEM:	-V2.14.1
DATE:	Mon Nov  3 22:16:41 MST 2008
FROM:	valdes

BUG:	Use of the built-in functions mod, min, max, and median produce an
	"incompatible types" error even though the types of the arguments are
	correct.  This is a due to a coding error.  There is no workaround
	other than using alternative ways to express the desired
	expression.

STATUS:	Fixed for the next release.

NUMBER:	571
MODULE:	IMAGES.IMUTIL.HSELECT
SYSTEM:	V2.14
DATE:	Fri Jan  2 21:41:53 MST 2009
FROM:	fitz

BUG:	The use of a '$' in a field name was causing the 'missing' value
	to always be printed even if the field exists in the image.  This
	was caused by a failure to check for the character and removing it
	prior to getting the value from the header.  There is no workaround,
	the code change is trivial.

STATUS:	Fixed for the next release.

NUMBER:	572
MODULE:	dotasks
SYSTEM:	-V2.14
DATE:	Tue Apr 28 11:19:41 MST 2009
FROM:	valdes

BUG:	It is likely that the DO tasks (e.g. doslit) will not work correctly
	if the input image names have a path.  This is because
	internal database filenames are derived from the image names.
	The recommended action is to work in the data directory.

STATUS:	Work on these and related tasks is currently frozen and since
	there is a basic workaround (working in the data directory)
	nothing may be done for some time.

NUMBER:	573
MODULE:	mscimage
SYSTEM:	- V4.9 August, 2008
DATE:	Fri Sep 18 08:36:30 MST 2009
FROM:	valdes (discovered and diagosed by Thomas de Boer)

BUG:	The task ignores the parameters "boundary" and "blank" which are
	fixed to be "constant" and "0." respectively.

STATUS:	This is fixed for the next release.

NUMBER: 574
MODULE: daophot.psf
SYSTEM: -V2.14
DATE:   Tue Apr 13 22:01:52 MST 2010
FROM:   fitz

BUG:    The ":function" command was not properly saving the new function
        when refitting is done with the 'f' keystroke.  This is because the
        fitting function reinitializes the parameters to the startup
        values without first saving the modified function.

STATUS: Fixed for the next release

NUMBER: 575
MODULE: all tasks using the icfit tools
SYSTEM:  - V2.14
DATE:   Mon Jun 28 14:08:48 MST 2010
FROM:   valdes

BUG:    The icfit tools are used in many tasks involving 1D function fitting.
       These include onedspec tasks like continuum and identify.  The
       tools provide for a grow radius where any sigma rejected points
       have neighbors also rejected.  The logic was wrong
       in two ways; one where if a neighbor was also a rejected point
       it did not also reject neighbors of that point, and another where
       the grow radius units were used both as in pixels and in user
       coordinates.  In reality the grow is supposed to be in user
       coordinate units.  In addition some tasks, like continuum, incorrectly
       described the units adding to the confusion.

STATUS: Fixed for the next IRAF release.

NUMBER: 576
MODULE: imcombine
SYSTEM: V2.14
DATE:   Wed Nov 17 15:20:16 MST 2010
FROM:   valdes

BUG:    The addition of the image names using imcmb="$I" does not work for
        input images with a square bracket; e.g. foo[1], foo[im1], foo[*,*].
        The IMCMB value, in order to allow long filenames, is stripped of
        any path.  For an obscure reason related to VMS directories this
        code failed to find a rootname.

STATUS: This has been fixed for the next release.

NUMBER: 577
MODULE: dohydra, dofibers, doargus, do3fiber
SYSTEM: -V2.15.1
DATE:   Fri Feb 11 12:30:46 MST 2011
FROM:   valdes

BUG:    The tasks will shorten root input image names to six characters by
        using the first five and last characters.  Depending on the style
        of image names this can result in name conflicts.  The reason for
        this shortening is no longer known so it is now considered a bug.
        Workarounds are to be aware of this and rename image names to avoid
        conflicts.

STATUS: This is fixed in the next release.  The fix is to modify the file
        $iraf/noao/imred/src/fibers/proc.cl as shown (replace lines 125 to
        129 with "extn = extn // ".ms").  If you don't have permission
        to make this change then copy the file to your iraf "home$"
        directory, edit it, load the desired package, and then override
        the definition of the file with "redefine proc = home$proc.cl".

        125,129c125
        < i = strlen (extn)
        < if (i < 7)
        <     extn = extn // ".ms"
        < else
        <     extn = substr (extn, 1, 5) // substr (extn, i, i) // ".ms"
        ---
        > extn = extn // ".ms"


NUMBER:	578
MODULE:	splot, scombine, fxcor, identify tasks, dispcor, disptrans
SYSTEM:	v2.15-V2.15.1a  (64-bit platforms only)
DATE:	Tue Mar  8 21:57:38 MST 2011
FROM:	fitz

BUG:	The 64-bit port changes to smw.h improperly added a P2R() macro to 
	the APLOW/APHIGH macro declarations.  This was causing tasks with 
	2-D data to make an out-of-bounds request for data and leading to
	and error message such as

		ERROR: Pixel subscript out of bounds (spec.fits) 

	Normal onedspec data or use on 32-bit platforms is not affected.

STATUS:	Fixed for the next release.  A re-application of the v2.15.1a patch
	file will replace the affected binaries on 'linux64' and 'macintel'
	platforms.


NUMBER: 579
MODULE: onedspec.specplot
SYSTEM: V2.15
DATE:   Thu Mar 31 10:41:56 MST 2011
FROM:   fitz

BUG:    SPECPLOT can sometimes throw a segmentation violation or not
        recognize valid input spectra due to an incorrect macro definition
        on 64-bit platforms (linux64 and macintel only).

STATUS: This has been fixed for the next release.  Patched x_onedspec.e
        binaries can be installed from

          ftp://iraf.noao.edu/iraf/v215/support/<arch>/x_onedspec.e

        where the <arch> is either 'linux64' or 'macintel'.


NUMBER:	580
MODULE:	imcombine and variants
SYSTEM:	-V2.15.1
DATE:	Fri Apr  1 10:53:41 MST 2011
FROM:	valdes

BUG:	When the grow options is used with masks or partially overlapping
	data a segmentation could occur.  This is because when data is
	absent (because of non-overlap) or excluded (because of mask) an
	identifier value was not initialized.  The only workaround is to
	not use the grow options.

STATUS:	Fixed for future patches and releases.

NUMBER:	581
MODULE:	splot
SYSTEM:	V2.15-
DATE:	Mon Jun  6 17:21:27 MST 2011
FROM:	valdes

BUG:	When using the deblending options a memory free error occurs with
	64-bit versions.  This is caused by allocating an integer array and
	freeing it as a real array.

STATUS:	Fixed in future patches and releases.
NUMBER: 582
MODULE: utilities.curfit
SYSTEM: -V2.15.1
DATE:   Fri Jul 29 12:40:08 MST 2011
FROM:   valdes

BUG:    For input data with two or more values having the same x value
        there is an arithmetic exception when setting the niterate parameter
        greater than zero during interactive fitting.  This occurs because
        a check for the distance between two points for the purpose of the
        grow option divides by the distance.  This is done even if no growing
        is requested (grow=0).  The workaround is to edit the input so that
        the values are not exactly the same.

STATUS: This condition has been eliminated for the next release.

NUMBER: 583
MODULE: apall,
SYSTEM: V2.15
DATE: Mon Mar 5 08:51:03 MST 2012
FROM: valdes

BUG:    The optimal extraction for significantly tilted spectra, the Marsh
        algorithm, has bug which manifests only under 64-bit architectures.
        The symptom is a crash, usually a memory or segmentation panic.
        The only workarounds are 1) go to an 32-bit system or 2) don't
        use the optimal extraction option.

STATUS: Fixed for V2.16.


NUMBER:	584
MODULE:	cosmicrays
SYSTEM:	-V2.16
DATE:	Thu Aug  2 14:55:18 MST 2012
FROM:	iraf

BUG:	A pointer to a an array of pointers was used in one place as a real.
	This is an error (e.g. segmentation error) when integer and real
	arrays are not of the same size; i.e. on 64-bit architectures.
	There is no workaround other than using a 32-bit architecture.

STATUS:	Fixed in future updated.

NUMBER:	585
MODULE:	mscred.mscfinder.msctpeak, nfextern.msctools.mscfinder.msctpeak
SYSTEM:	V2.16
DATE:	Wed Aug  8 19:26:21 MST 2012
FROM:	valdes

BUG:	The IRAF system core version of the tables library now used changed
        in its default behavior when creating and reading tables without
	an explicit extension.  This results in the error:

	    ERROR: Table `/tmp/iraf?????' does not exist or cannot be opened.

	This requires a change to the script to use an explicit extension.
	A workaround is possible by editing the script but it is recommended
	that you just update the appropriate external package.

STATUS:	Fixed in the latest version of the packages.

NUMBER:	586
MODULE:	apsum/apall
SYSTEM:	V2.16
DATE:	Tue Mar 12 12:55:34 MST 2013
FROM:	valdes

BUG:	When cleaning or weighting and an aperture runs off the edge of the
	there was a bug that could allow referencing outside of the image
	data array.  The value would then be arbitrary which could produce
	errors such as floating or arithmetic exceptions.  The workaround
	is to eliminate apertures that go off the edge.

STATUS:	Fixed for the next release.