Initial commit

33 files changed, 15403 insertions, 0 deletions

diff --git a/doc/ports/README b/doc/ports/README
new file mode 100644
index 00000000..7e077261
--- /dev/null
+++ b/doc/ports/README
@@ -0,0 +1,23 @@
+This directory contains notes on the various IRAF ports.  Most of these
+files do not contain an up-to-date record of the current ports, but rather
+these are historical notes taken during each port.  The name of the host
+operating system is contained in each filename, while most files contain
+the relevant dates of ports or upgrades inside them.  Some of this material
+may be of use to persons contemplating future ports.
+
+Conventions:
+
+    aos		AOSVS  (Data General MV/10000)
+    ctio	Cerro Tololo Interamerican Observatory
+    isi		Integrated Systems; Jupiter workstation at IPAC
+    nso		National Solar Observatory
+    st		Space Telescope Science Institute
+    sun		Sun Microsystems
+    sun2	SUN-2 hardware, SUN V2.0
+    sun3	SUN-3 hardware, SUN V3.0
+    v22		IRAF V2.2 (etc.)
+
+Where different files would otherwise have the same name, they are
+distinguished by the date of the last modification to the system that
+was part of the original "notes" file.  For example, "sun3_062486.doc"
+is the "notes" file as it existed on a Sun-3 on June 24, 1986.
diff --git a/doc/ports/alliant_86.doc b/doc/ports/alliant_86.doc
new file mode 100644
index 00000000..9b372493
--- /dev/null
+++ b/doc/ports/alliant_86.doc
@@ -0,0 +1,589 @@
+Notes on the port of IRAF V2.3+ to the Alliant FX vector workstation,
+beginning 25 August 1986 (dct).  This is a continuation of a port started
+by Dennis Crabtree on 12 August, with some of the problems found then being
+fixed before the bootstrap or sysgen in this port.
+---------------------------------------------------------------------------
+
+Read tape onto VAX 780 using IRAF `reblock' task.  Worked great, except
+	that I allocated the drive in vms before running IRAF: this caused
+	the IRAF allocate to fail, causing a read error on the first
+	attempt to run reblock (confusing).  (8/25)
+
+Copied archive to the Alliant via the ethernet which runs the Excelan
+	network software.  The first attempt to unpack the archive on the
+	Alliant failed with a checksum error message from tar; this turned
+	out to be due to not specifying a binary transfer in TELNET before
+	copying the file (a newline was being inserted after every 512
+	bytes).  After retransmission to fix this, unpacked everything
+	successfully at /u2/iraf. (8/25)
+
+Notes -
+	There is a bug in the Excelan network software that causes it to
+	hang up the terminal if too many characters are transmitted,
+	forcing one to login on another terminal and STOP the process.
+
+	The Alliant died on a kernel panic (mfree failure) during one
+	of these network crashes and had to be rebooted.  Another time
+	it hung up in a hard loop when tyring to delete the large archive
+	file (bad disk block?) and had to be rebooted.
+
+	DAO uses Plessey PT-100G graphics terminals.  These have an awful
+	keyboard with keybounce and keylost problems.  A screen redraw takes
+	3 seconds.  The screen color is orange - not as bright as amber,
+	green, or white.  Other than that they seem fine - have not tried out
+	the graphics yet.  (8/25)
+
+	Tried the graphics finally, on VMS/IRAF.  The graphics resolution is
+	good (480x1000?) and vector drawing is fast.  Hardware cursor setting
+	is better than on the vt640 (shift and ctrl as used as accelerators,
+	and 45 degree motions are supported), but unfortunately there is no
+	software write cursor function, so the HJKL and other cursor write
+	features (as in in a zoom) do not work.  The alpha and graphics
+	memories are separate and can be displayed together, as on the vt640.
+
+	The main problems of this terminal are the keyboard, slow screen
+	redraw, and lack of a software write cursor function (but it is
+	better than a vt240!).  (8/30)
+
+local/.login
+	Set up the .login for the new system.  (8/25)
+
+Notes -
+	Tried using the vms COPY to copy the tar file to disk, to see if
+	that would work.  COPY produced a variable length, 10240 byte max
+	record length, carriage control etc. file as output, i.e., a text
+	file.  This explains why the initial attempt to read the tar tape
+	failed.  Probably the best way to distribute tar archives to VMS
+	sites is by making a BACKUP tape of a disk tar file.  This avoids
+	this type of confusion, and also gains access to the error recovery
+	provided by BACKUP.  (8/26)
+
+/usr/include/iraf.h
+/usr/bin/cl,mkiraf,etc.
+	Changed to point to /u2/.  (8/26)
+
+unix/hlib/[dir]mach.f
+	Commented out pdp-11 entries and uncommented IEEE entries.  In two of
+	the files, commented out the call to ILIBER; I don't think we want
+	that (should be fixed on Lyra).  (8/26)
+
+unix/hlib/iraf.h
+unix/hlib/mach.h
+	Changed the values of epsilonr, epsilond to the IEEE values.  Set the
+	byte swap flags to NO.  (8/26)
+
+unix/hlib/iraf.h
+	Set defines for and,or,xor to iand,ior,ieor.  Not is not.  (8/26)
+
+unix/hlib/mkiraf.csh
+	Changed iraf root directory to /u2/iraf.  (8/26)
+
+unix/hlib/mkpkg.inc
+	Set siteid to `dao', turned off ncar, calcomp kernels.  XC flags will
+	probably also have to be changed, but leave that for later.  (8/26)
+
+unix/as/zsvjmp.s
+unix/hlib/config.h
+unix/hlib/libc/spp.h
+	Wrote the ZSVJMP/ZDOJMP for the Alliant (as$zsvjmp.s), and set the
+	jump buffer size parameters in config.h and spp.h.  The current routine
+	saves the exception mask and all the floating point and vector
+	registers as well as the 68000 registers, which is more than is really
+	necessary.  (8/26)
+
+unix/os/zgtime.c
+unix/os/gmttolst.c
+unix/boot/bootlib/ostime.c
+	From looking at Dennis's notes I see that time.h is in <sys/time.h>
+	rather than <time.h> on the Alliant.  In fact it is referenced both
+	ways in the VAX/UNIX kernel, so I changed all references to
+	<sys/time.h>, don't know what the official answer to this one is.
+	Removed the link (added by Dennis) in /usr/include.  (8/26)
+
+unix/hlib/libc/iraf.h
+unix/os/zxwhen.c
+	In iraf.h, added a #define ALLIANT for use in HSI code.  In zxwhen,
+	replaced the array of vax exceptions by an #ifdef-ed array of
+	alliant specific hardware exceptions (hwx_).  (8/26)
+
+unix/os/zxwhen.c
+	The Alliant C compiler produced a syntax error for the declaration
+	for the pointer to function `vector'.  Presumably this was due to
+	vector being a reserved keyword to the Alliant C compiler; changed
+	the name to `vvector' and it compiled.  (8/26)
+
+unix/boot/spp/xc.c
+	Replaced f77 by the Alliant task `fortran' (the Alliant Fortran
+	compiler) to compile Fortran files.  Modified to use cc rather
+	than f77 to compile all other files.  Modified to add the .f
+	files produced from .x sources to the Fortran file list, rather
+	than the general source file list input to the C compiler (formerly
+	these files were processed by f77, which can compile anything).
+	Parameterized the names of the fortran compiler, the C compiler,
+	and the linker.  Deleted the "-u" flag, which is not supported on
+	the Alliant.  Changed the Fortran library name from `-lF77' to
+	`-lfortran'.  (8/26)
+
+	In the long run, XC needs to be rewritten to be more portable,
+	like mkpkg.  This is still the original unix compiler, which was
+	never intended to be ported.
+
+unix/boot/spp/rpp/ratlibf/Makefile
+unix/boot/spp/rpp/rppfor/Makefile
+	Modified to call `fortran' rather than `f77'.  (8/26)
+
+---------------------------
+(first attempt to bootstrap)
+
+unix/os/zfiomt.c
+	C compiler error.  The declaration of the automatic array in
+	the skip record forward function, i.e.,
+
+		char	buf[32768];
+
+	caused the fatal error `too many local variables' from the
+	C compiler.  I reduced the size to [28800].  Recall that this
+	used to be a small buffer, but I had to make it larger than the
+	maximum tape block size to avoid i/o errors on the SUNs.  Use
+	of malloc is undesirable since skip record forward might be
+	called many times in a loop.  In any case, this is an indication
+	that the Alliant C compiler has limited symbol table storage and
+	may have problems with large programs or modules.  (8/27)
+
+Note on Alliant Fortran compiler (task `fortran').
+	The compiler cannot handle a "-cO" flag on the command line.
+	The "-O" must be given as a separate flag.  (8/27)
+
+unix/boot/spp/rpp/ratlibf/dsfree.f
+	On line 20, the hollerith string contained a tab instead of a space,
+	causing the line length to exceed 20 characters.  (8/27)
+
+unix/boot/bootlib/mkpkg.csh
+	The executable nature of this .csh is a nusiance; a different way
+	should be found to do this.  (8/27)
+
+unix/hlib/mkpkg.inc
+	Changed the default compile flags to "-c -Ovg -AS -OM" for the Alliant.
+	(8/27)
+
+---------------------------
+(bootstrap completed)
+
+unix/hlib/alloc.e
+	Changed owner to root.  (8/27)
+
+sys/gio/gki/gkigca.x
+	The min() instrinsic function was being called with operands of mixed
+	type, i.e., int and short.  Restructured so that both operands were of
+	type int.  (8/27)
+
+sys/gio/gki/gkigca.x
+	In this case, the Alliant compiler found a real bug in a module.
+	The warning message `subscript out of range' was being produced
+	because Mems[] was being referenced with a compile time constant
+	subscript, caused by omission of the pointer variable from the
+	expression.  The bug was harmless, however, since the affected
+	argument (the device name string) was not being used by the called
+	procedure (close workstation).  (8/27)
+
+sys/vops/lz/mkpkg
+	Added $checkout libvops.a, etc., to the file header.  (8/27)
+
+sys/vops/ak/*.x
+sys/vops/lz/*.x
+unix/boot/generic/generic.c
+	The Alliant fortran compiler complains about use of (0,0) as a
+	complex constant.  This string is generated by the generic
+	preprocessor when the sequence 0$f is encountered (actually,
+	any sequence NN$f is permitted).  Modified the generic preprocessor
+	to turn NN$f into (NN.0,NN.0) for the complex datatype, and
+	deleted all the complex files (and associated integer files) in ak
+	and lz containing the string (0,0).  These will be automatically
+	regenerated by the preprocessor in the sysgen provided the integer
+	family member is not found - the mkpkg only checks the date (and
+	existence) of the integer file.  (8/27)
+
+pkg/system/help/t_lroff.x
+	Added an extern declaration for `getline', since it is passed by name
+	to the lroff function.  (8/27)
+
+pkg/cl/task.h
+	In the #define next_task, deleted the (unsigned) coercion.  This should
+	not be necessary as a pointer is already an unsigned quantity, and the
+	Alliant C compiler would fail with the message
+
+		`expression causes compiler loop: try simplifying'
+
+	when trying to compile the file (although the same macro was used in
+	lots of other places without problems - maybe it was causing parser
+	stack overflow in the problem cases, due to a complex context).  (8/27)
+
+unix/hlib/mkpkg.inc
+sys/vops/mkpkg
+	As an experiment, added a new environment variable XVFLAGS to
+	mkpkg.inc; this is used when compiling vectorized code to get
+	whatever compiler options are desirable for such code.  Added
+	a $set to the vops mkpkg to redefine XFLAGS as XVFLAGS so that
+	the vops package will be compiled for vectorization.  At present,
+	the value of XVFLAGS is the same as XFLAGS, i.e., vectorization
+	is permitted in both cases, except that the vectorization warning
+	messages are not turned off by the XVFLAGS.  (8/27)
+
+---------------------------
+(started the first full system sysgen)
+
+sys/gio/gki/gkiopen.x
+sys/gio/gki/gkititle.x
+	More `subscript out of bounds' errors, caused by omission of the
+	pointer `gki' from gki instruction field references.  (8/27)
+
+sys/fio/osfnlock.x
+	The procedure osfn_initlock was declared as an integer function but
+	the return value was never set, causing the fortran compiler to
+	complain `FUNCTION return value is not defined in this program unit'.
+	It turns out that the procedure is called as a subroutine everywhere,
+	so evidently the function declaration was not intended.  Changed it
+	to a subroutine.  So far, the Alliant fortran compiler is finding
+	more bugs in IRAF than IRAF is finding bugs in the compiler, a pleasant
+	turn of affairs.  (8/27)
+
+sys/vops/amap.gx
+	Broke the min/max expression in the do loop up into two statements
+	to defeat a compiler warning message for case short; an integer
+	expression was being used as one of the min/max operands for case
+	short.  (8/27)
+
+unix/boot/generic/tok.l
+	The external string variable xtype_string[] was declared as (char *)
+	rather than (char []) in tok.l, causing a runtime bus error on the
+	Alliant.  This construct works on the VAX because the linker is smart
+	enough to figure out what is going on, but clearly the construct is
+	not portable and should be avoided.  Probably it is always safe to
+	use (char *) in argument lists since a pointer value is always pushed
+	on the stack, but in extern declarations the array notatio must be
+	used.  (8/27)
+
+sys/osb/mkpkg
+sys/osb/achtb.gc
+sys/osb/achtu.gc
+sys/osb/achtzb.gc
+sys/osb/achtzu.gc
+	A warning message from the C compiler led to the disovery of some
+	old complex ACHT procedures in OSB.  There was a bug in these files
+	which had been fixed in the source .gc files, but type X had been
+	removed from the call to generic in the mkpkg, hence the complex
+	files were never regenerated.  It appears that type complex was dropped
+	at some point from the mkpkg, but the complex files were never
+	deleted.  The other file are more permissive with type coercion,
+	hence the problem was never discovered.  I restored type complex to
+	the mkpkg and added a complex case (requires special processing) to
+	each of the .gc files.  (8/27)
+
+sys/gio/ncarutil/sysint/ishift.x
+	This file contains source for two procedures IAND and IOR.  This would
+	not compile since the Fortran compiler already has intrinsic functions
+	with the same names; commented the offending procedures out as a
+	workaround.  (8/27)
+
+sys/ki/irafks.x
+	The procedure `kserver' was declared as a function but the return
+	value was never set, and the function was being called as a
+	subroutine.  Changed to a subroutine.  (8/27)
+
+math/iminterp/arider.x
+	This file contained the three procedures ii_pcpoly3, ii_pcpoly5,
+	and ii_pcspline3.  These were all declared as functions had no
+	return values and were always called as subroutines, hence I changed
+	them to subroutines.  Also, the same external names were used with
+	a different argument list in the file `mrider.x', leading to a very
+	serious library conflict - surprised it has not caused noticeable
+	runtime problems to date.  As a temporary solution,  I changed the
+	names to ia_* in the file arider.x to avoid this library conflict.
+	(8/27)
+
+pkg/xtools/icfit/icgdelete.gx
+pkg/xtools/icfit/icgundelete.gx
+pkg/onedspec/identify/icfit/icgdelete.gx
+pkg/onedspec/identify/icfit/icgundelete.gx
+	Each file contained two procedures which were declared as functions
+	but which did not return function values and which were called as
+	subroutines, hence I changed them to subroutines.  (8/27)
+
+pkg/images/imdebug/immake.x
+	Subroutine immake2 declared as a function.  (8/27)
+
+pkg/images/tv/display/iiswnd.x
+	Contained constructs such as `max (0, lut[i])', where `lut' is a short
+	integer array.  This caused a min/max type mismatch error.  Also, a
+	statement had a nonfunctional C like ; at the end.  (8/27)
+
+pkg/images/tv/cv/iism70/iishisto.x
+	Same problem, short integer variable `offset'.  (8/27)
+
+pkg/images/geometry/blkav.gx
+	Main procedure blkav$t declared as a function but used as a subroutine
+	everywhere.  (8/27)
+
+pkg/plot/gkiextract.x
+	In gke_make_index, `nchars_max = min...', contained an integer constant
+	and a short integer array element, causing a min/max argument type
+	mismatch.  (8/27)
+
+noao/onedspec/t_dispcor.x
+	Procedure dcorrect declared as a function is really a subroutine.
+	Also, it has a ridiculously large number of arguments.  (8/27)
+
+---------------------------
+(All compile time bugs found in this pass fixed.  Stripped all non-HSI
+(binaries and started another full sysgen to run overnight).
+
+kernel problems
+	When I came in in the morning the sysgen had completed successfully,
+	but the machine seemed rather sluggish.  Trying to work, I immediately
+	found that processes which used to run would hang up on a pseudo-run
+	state, completely uninterruptable, sometimes unstoppable, unkillable,
+	and so on.  Clearly a problem with the unix kernel, so I rebooted and
+	the symptoms went away.  Most likely this was a bug in the Alliant
+	unix kernel, which is common with new unix ports.  (8/28)
+
+math/interp/arider.x [OBSOLETE]
+	Missed one: the three procedures iidr_poly[35] and iidr_spline3 were
+	declared as functions but were really subroutines.  (8/28)
+
+pkg/images/tv/cv/iism70/iisrange.x
+	Lots of problems mixing int and short in calls to AND, OR.  (8/28)
+
+pkg/images/tv/cv/iism70/zsnap.x
+	This module caused the fortran compiler to core dump with an internal
+	error; it was trying to resolve mixed int/short operands in expressions
+	and couldn't handle this code, evidently.  (I feel much the same way
+	trying to read it.)
+
+	Deleted `int min(), max()' intrinsic function declarations.  Added an
+	itemp temporary to fix a couple min/max statements which mixed int
+	and short operands.  (8/28)
+
+pkg/images/tv/cv/iism70/iishisto.x
+	Lots and lots of compile time problems with short variables - took
+	several iterations to find them all.  (8/28)
+
+pkg/images/imarith/imsum.x
+	In module MXMNSS, the Fortran compiler coredumps when run with
+	global optimization (-Og).  Returns `error code 138': examination
+	of the corefile for `fortran1' (the first pass I presume) with adb
+	gives the reason as `bus-error page violation'.  Saved the offending
+	segment of code in local$bugs for a bug report to Alliant, and compiled
+	the routine without optimization.  (8/28)
+
+noao/mtlocal/cyber/cy_rbits.x
+	This file also causes the Fortran compiler to coredump and return
+	error code 138 - bus error page violation.  Generated the minimum
+	Fortran module that would demonstrate the bug and installed it in
+	local$bugs.  Hand compiled routine without optimization.  (8/28)
+
+noao/mtlocal/cyber/cyber.h, *.x
+	The data structure for this package included a field named POINTER.
+	This is a reserved keyword, and is converted by the preprocessor
+	into `int', eventually causing a compile time error on the Alliant
+	(and a memory overwrite problem on the VAX).  Aside from being a
+	reserved keyword, POINTER is not a very illuminating name for a
+	field of a structure: pointer to what?  After a little investigation,
+	changed the name to COEFF, since it appears that the field contains
+	a pointer to some sort of coefficient array.  (8/28)
+
+---------------------------
+All compile time problems have now been dealt with and all executables linked
+and installed in bin.  I tried running a couple of the executables, and
+incredibly, they ran without apparent error on the first attempt!  Of course,
+that is too good to be true, the next step is runtime testing of the system.
+
+dev/graphcap
+dev/termcap
+	Installed the local DAO additions to termcap and graphcap.  Rather
+	than have a modified version of the vt640 entry for DAO, changed the
+	name of the new logical device to vt640d.  (8/28)
+
+unix/hlib/mkiraf.csh
+	Set the default image storage directory to /u2 since it will be
+	empty when iraf is moved back to /iraf, and since there does not
+	seem to be any dedicated scratch area.  Added a comment for the
+	pt100g graphics terminal.  (8/28)
+
+unix/hlib/zzsetenv.def
+	Changed the names of the stdgraph and terminal devices to `pt100g'.
+	Did not set stdplot, stdimage, printer, since no such devices are
+	currently available from the Alliant.  (8/28)
+
+local/login.cl
+	Ran `mkiraf' to set up a new CL login for IRAF.  Tried starting the
+	CL and it hung up in pseudo-run mode as above.  The problem is
+	definitely in the unix kernel, but it appears likely that the bug
+	occurs when an IRAF VOS (not HSI) process runs - possibly it is
+	related to the call to the internal Alliant `setcontext' routine
+	(which traps to the kernel), called from ZSVJMP.  The system slows
+	way down when this occurs, so evidently it is hung in some sort of
+	tight kernel loop.  (8/28)
+
+(rebooted)
+
+process spawn problem
+	This is turning out to be a hard problem to locate.  ZSVJMP turned
+	out not to be the problem, and in fact it works fine.  The difference
+	between the IRAF processes and the UNIX processes is that the IRAF
+	processes use the fancy vector compiler.  The Alliant process header
+	contains a flag bit word describing the attributes of the process to
+	be run; the standard UNIX processes do not use any of the fancy
+	Alliant vector stuff, and in fact do not even use 68020 instructions.
+	The IRAF processes use 68020 instructions, vector instructions,
+	and something called multiple stacks.  Once the kernel gets corrupted,
+	processes with these attributes enter the pseudo-run state when we try
+	to exec them.  (8/29)
+
+(rebooted countless times)
+
+unix/os/zfiopr.c
+	After a lengthy battle, finally determined that due to some bug in
+	the Alliant kernel, ONLY A NORMAL PROCESS CAN EXEC A VECTOR PROCESS.
+	A vector process can exec a normal process with no problem, and a
+	normal process can exec a normal process, but if a vector process
+	execs a vector process the exec hangs in a tight kernel loop.
+	The workaround is for the vector process to exec a normal process
+	and have it turn around and exec the desired vector process.
+	I tried this, and it works, although there appear to be other less
+	serious bugs with IPC to be faced tomorrow.  (8/29)
+
+	[8/30 - IPC bug was not a real bug, just caused by "-c" switch not
+	[being passed to connected subprocess by `execute'.]
+
+unix/os/exec.c +
+unix/hlib/exec.e +
+unix/os/zfiopr.c
+unix/os/mkpkg.csh
+unix/os/mkpkg
+	Resolved the process connect problem as follows: [1] added a new
+	file exec.c (source for hlib$exec.e), which compiles into a nonvector
+	process to be called by the CL to spawn vector subprocesses;
+	[2] replaced the execl call in zfiopr.c/ZOPCPR by a call to execve
+	to spawn hlib$exec.e, which in turn spawns the IRAF suprocess.
+	Added entries to the mkpkg files to make the new modules.  (8/30)
+
+--------------------------------------
+ALLIANT/IRAF is now up and ready for runtime testing, Saturday morning,
+30 August.  Spent two days on the port and one and a half days figuring
+out the process connect problem.
+
+unix/hlib/iraf.h
+unix/hlib/mach.h
+	In checking out some operations upon indefinites, discovered that
+	the values of INDEFR and INDEFD in <iraf.h> had accidentally been
+	set to the values of EPSILON[RD].  This was causing INDEF comparison
+	failures for files that included <mach.h> since INDEF is also defined
+	there.  INDEF should not be defined in <mach.h> if it is already
+	defined in <iraf.h>, so I deleted the entries in <mach.h> and restored
+	the old values to <iraf.h>.  (8/30)
+
+unix/as/zsvjmp.s
+	Discovered a minor problem with the new ZDOJMP routine.  The address
+	of the error code was being returned, rather than the value, causing
+	error messages to come out as ERROR (*****, "..").  (8/30)
+
+(full sysgen and relink due to <iraf.h> and zsvjmp edits)
+
+Fatal Alliant hardware problem
+	Right away when trying to test out the IRAF science software I
+	ran into serious problems with floating point operations.  A little
+	investigation showed that the Alliant floating point hardware is
+	faulty.  Simple test programs were written in both Fortran and C to
+	print out the numbers 1.0, 2.0, 3.0: both failed.  Testing of the
+	floating point instructions with ADB revealed that add and subtract
+	are ok, but 1.0 * 2.0 is 2.1375, and 1.0 / 2.0 is 0.53125.  A simple
+	board swap should fix the problem (in fact it is probably a single
+	chip), but unfortunately this will prevent further testing of the
+	science software during this visit; virtually all programs that use
+	floating point produce invalid results, including all graphics
+	programs.  Testing of the system software can continue, as can
+	execution of most benchmark programs.  (8/30)
+
+	IMPORTANT NOTE -- Once this problem is fixed it will be necessary to
+	recompile the entire system (and any other non-IRAF software as well),
+	since any floating point decode operations performed by the compilers
+	will likely have failed, causing invalid floating point numbers to be
+	compiled into programs.  Hence these programs will fail even after the
+	hardware is fixed.
+
+unix/os/zopdpr.c
+	Had to make the same change here as in zfiopr.c, i.e., add a call to
+	the intermediate `exec.e' process to exec the bkg cl.  Note that this
+	is not necessary for zoscmd, since zoscmd execs one of the unix
+	shells, both of which are nonvector processes.  (8/31)
+
+Note on FTP
+vms/boot/rtar
+	A binary file transfer via FTP to VMS resulted in creation of a file
+	with an undefined record type.  Trying to unpack this file with RTAR
+	would immediately crash the VAX due to an exexpected exception during
+	a system call in the ACP (RMS).  This should not happen, of course,
+	but the real question is why FTP created a file with an undefined
+	record type.  Sure would be nice to have the IRAF networking software
+	up...  (9/1)
+
+unix/os/zgtime.c
+unix/hlib/libc/kernel.h (HZ)
+sys/etc/sysptime.x
+	Rewrote the timer utility routines to use only integer arithmetic,
+	so that I could run some benchmarks of the vector hardware.  (9/1)
+
+(relink)
+
+--------------------
+Timing tests
+	The Alliant documentation claims that use of the vector hardware will
+	increase performance by about a factor of 4.  This is borne out by my
+	tests.  The factor of 4 is determined by the ratio of the startup
+	time for a vector segment versus the time required to execute a
+	vector segment, where the segment length (number of elements in a
+	vector register) is 32 for the Alliant.
+
+	aaddr, 512x512
+		vectorized:	0.184 cpu
+		nonvector:	0.617 cpu
+
+(Moved new system to /iraf; deleted old system, it should be archived
+(somewhere and probably won't be looked at again anyhow.  I saved a copy
+(of the original Alliant notes file as notes.den.  Modified the links in
+(/usr/include and /usr/bin to point to /iraf.  Modified the pathnames in
+(hlib and hlib/libc).  (9/1)
+
+cleanup
+	Ran (most of) the standard benchmarks.  Deleted the /u2 version of
+	iraf.  (9/2)
+
+------------------------------
+Back at NOAO.  Problems reading tar file on VMS backup tape brought back from
+DAO.  This is probably due to problems with the DAO software so I shall
+document it here (copied from noao/lyra notes file).
+
+doc/ports/alliant_86.doc
+	Installed the notes file from the Alliant port.  There was some
+	problem with the backup/tar file I made on the Alliant, hence it was
+	not easy to get the notes file off the tape.  I had to use the new
+	SPLIT task to split the 24 Mb archive into 49 512000 byte segments,
+	and eventually determined that the notes file was at line 11115 of
+	segment 39!  The problems with the tape are almost certainly not with
+	the tape itself, since I did a backup/compare at DAO, and backup did
+	not report any problems when the tape was read.
+
+	I think the most likely culprit is the FTP software, which had to be
+	used to move the archive to the VMS VAX, since the DAO Alliant did not
+	have a tape drive.  FTP (binary mode) insisted on making a file with
+	an undefined VMS record type; this would cause RTAR to crash the VAX
+	if I tried to look at the file on the VMS VAX at DAO.  The 24 Mb archive
+	file has one enormous section which is all zeroed, and then in the
+	remainder of the archive all ascii zeroes appear to have been deleted
+	from the archive, causing the 512 byte TAR file headers to be much
+	shorter.  I tried the exact same operation (with a smaller test file)
+	using our Eunice FTP and everything worked fine.  The DAO TELNET
+	also gave problems; it would hang up if fed too much data too fast,
+	and would occasionally crash with a stack trace.  Based on these
+	experiences, I would certainly have to recommend the Wollongong
+	networking software over the other vendor.  (9/6)
diff --git a/doc/ports/aos_ctio.doc b/doc/ports/aos_ctio.doc
new file mode 100644
index 00000000..0fcc099c
--- /dev/null
+++ b/doc/ports/aos_ctio.doc
@@ -0,0 +1,233 @@
+System notes file for CTIO AOS/VS IRAF installation.
+9-17 April 1987
+
+System installed by Gary Lee Webb on 9 April.
+CL came up and ran with minor problems.
+
+Did not start keeping this notes file until 16 April (D.Tody).
+May have missed some important mods.
+
+Extant Bugs
+------------
+
+1. OS escapes.
+
+	Interrupting an OS escape often causes the escape mechanism to
+	get in a state where subsequent escapes will return immediately,
+	even though the command has been sent to the cli, sh, or whatever.
+	This leads to the CL and the host task reading from the terminal
+	at the same time, seizing alternate lines of input.
+
+2. Magtape i/o problem
+
+	CTIO has a standard DG tape drive and two Cipher tape drives.
+	The standard tape drive will accept transfers up to 32768 bytes
+	(or maybe 32767 bytes), which is what the zfiomt.c driver code
+	is written for.  The Cipher drives, however, have a maximum transfer
+	size of 8192 bytes, hence the max transfer size is device dependent
+	rather than just system dependent.  As a kludge fix for this I
+	added some site dependent logic to zfiomt.c, but a real fix will
+	probably require addition of the max transfer size to the dev$devices
+	file, and changes to the VOS code to deal with this.
+
+3. Path and script problems
+
+	There were a number of problems with missing directories and
+	confusion between executables and macro script tasks, leading to
+	failure of mkpkg, xc, etc.  I will try to get Gary to document these
+	better.
+	    One of the problems (glw) was the use of directories C_DIR and
+	F77_DIR to find the executable C and FORTRAN compilers.  Unfortunately,
+	there are no standard directories for these (other than they should be
+	in :UTIL), perhaps the standard C and F77 macros should be used rather
+	than having IRAF write its own?
+
+4. File dates
+
+	After the system installation, a mkpkg on any package results in
+	compilation of all of the files therein.  Evidently the file modify
+	dates are not being restored properly when a backed up system is
+	restored from tape.
+
+5. Installation (glw)
+
+	   The current link initialization macro will delete /TMP and link it
+	to /DEV. I see no reason to combine these and did not do so.
+	   For a user to be able to generate any processes under IRAF, he also
+	had to be a valid MV/UX user (i.e., have an entry in /ETC/PASSWD).  If
+	this is not a bug, it should be documented in the installation guide!
+	   There are !SOLPLs all over the place: a list of files to be changed
+	would be nice.
+
+6.  Worries... (glw)
+
+	   I note that the editor description files end with a .ed, just like
+	the SED temporary files, making them likely to be deleted accidentally.
+
+
+System Revisions
+--------------------
+
+aosvs/os/zfiomt.c
+	Did a kludge fix to set the max transfer size down to 8192 bytes
+	for devices other than mtb0.  (4/15 dct)
+
+dev/vi.ed
+	Changed the OS escape for VI from "vi" to "!vi" to cause the command
+	to be executed by CSH rather than CLI.  Also added an entry for the
+	vi500 to /etc/termcap, but I could never get VI to find the entry
+	for the device.  Tried setting TERMCAP in .cshrc to point to another
+	file, or directly to the vi500 termcap entry, but none of this made
+	any difference.  (4/16 dct)
+
+aosvs/os/prwait.c
+	The include file <sys/wait.h> was not being found; it turns out to
+	be in /usr/include on this system.  I had to reference the file as
+	"/usr/include/wait.h" rather than the expected <wait.h> to get the
+	module to compile.  It appears that the real include files are
+	coming from some other place (maybe a text library?) and that the
+	wait.h file is missing.  (4/16 dct)
+
+aosvs/boot/rtar/mkpkg
+	Added a "-B" flag to the $link call.  Without this the link fails
+	with a multiple reference to main.o, and unresolved externals for
+	all the bootlib routines.  It looked like this was missing from
+	most of the other boot packages too.  (4/16 dct)
+
+dev/slate.ed  (glw)
+	Added this file (guessing a lot!) to provide Dan's favorite editor.
+	It must work -- that's how I'm adding this comment!
+	Where is the documentation for the *.ed format?
+
+dev/sed.ed  (glw 16 IV 87)
+	Modified the command line to be SED/NOED to avoid leaving *.ed files
+	all over the place.
+
+dev/termcap (glw 16 IV 87)
+	Added lpt1, lpt4, and lpt5 printers, a/k/a adservs, diablo, laser.
+
+pkg/images/imdebug/mktest.x
+	Would integer overflow when creating a large image.  This is harmless
+	on the other systems, but it has to be guarded against on the MV as
+	it causes the task to abort.  (4/17)
+
+pkg/images/iminfo/t_imstat.x
+	Installed an optimized version of the IMSTAT task.  (4/18)
+
+aosvs/boot/mkpkg/*.[ch]
+	AOS/VS evidently cannot restore the modify dates of files when reading
+	a tape onto disk.  This causes mkpkg to try to recompile everything
+	when run for the first time on a newly installed system.  Modified the
+	mkpkg program to add a new flag "-u".  This flag, if present, causes
+	the dates of library modules to be forced to be no less than the date
+	of a magic file (currently hlib$iraf.h).  It is assumed that the date
+	of the magic file is about the same as the date at which the system
+	was installed.  To be precise, the file should be touched after the
+	tape is read in (already done for the CTIO system), and the first
+	time mkpkg is run on a package the -u flag should be used to forcibly
+	update the library module dates.  (4/18)
+
+---------------------------------------------------------------------
+From SKIP@SOLPL.AS.ARIZONA.EDU Thu May 28 12:14:58 1987
+Received: from noao.arpa by noao-lyra.arpa.noao (5.51/SAG.7)
+	id AA08983; Thu, 28 May 87 12:14:53 MST
+Received: from solpl.as.arizona.edu by noao.arpa (5.51/SAG.7)
+	id AA03426; Thu, 28 May 87 12:14:46 MST
+Received: by SOLPL.AS.ARIZONA.EDU (1.00/1.0)
+	  id AA00065; Thu, 28 May 87 12:14:20 mst
+Date: Thu, 28 May 87 12:14:20 mst
+From: Skip Schaller <SKIP@SOLPL.AS.ARIZONA.EDU>
+Message-Id: <8705281714.AA00065@SOLPL.AS.ARIZONA.EDU>
+To: chile@noao, tody@noao
+To: Dan@SOLPL.AS.ARIZONA.EDU, Smith@SOLPL.AS.ARIZONA.EDU,
+        Gary@SOLPL.AS.ARIZONA.EDU, Webb@SOLPL.AS.ARIZONA.EDU
+Fm:  Skip Schaller
+
+	I will be leaving Tucson on June 18 for Chile.  I will call you
+on Monday morning June 22.  I expect to be able to pitch in immediately
+if you so desire.  I will be in Chile until August 16.  Let me know as
+soon as you know what it is exactly that you want me to do for you.  If
+I can prepare anything here ahead of time, so much the better.
+
+	Please send me any AOSVS/IRAF bug reports as soon as possible.  It
+will be much easier for me to fix them here.
+
+
+	The following are my responses to the CTIO AOSVS/IRAF installation
+notes that I got from Doug Tody:
+
+1)  Keyboard interrupt during OS escape.
+	I duplicated this problem at solpl.  I will try to fix during
+this next update.  It may be an AOSVS problem and not fixable.
+
+2)  Magtape maximum record size for certain drives.
+	Doug changed the IRAF VOS just the other to deal with this problem.
+
+3) Pathname problems.
+	As far as I can tell (by looking at other AOSVS systems),
+F77_DIR and C_DIR are the standard DG directories for those languages.
+In any case, the installation manual tells you which scripts to check
+and modify to agree with your system.  (I had to do this for the
+Tenerife installation.  It was trivial.)  Unfortunately, the standard
+scripts cannot be used due to their lack of functionality and interface
+to mkpkg.
+
+4) File dates.
+	Hopefully by the next release, Doug's changes to mkpkg to update
+file dates for library members without recompiling, will be incorporated.
+Many DG sites have complained about AOSVS not restoring the original
+file modification times.
+
+5) Link installation problems.
+	The link installation script does NOT delete /TMP and link it to /DEV.
+Read it again.  With MV/UX installed, that part of the script does nothing.
+
+6) Problems with /etc/passwd.
+	I could not reproduce this problem at solpl.  I did reproduce it
+during the Tenerife installation.  I found out that the minimum needed
+was to have this file present with one entry for user "iraf".
+	Sometime ago I tried to eliminate IRAF dependence on this file
+by avoiding the use of those C subroutines given in the DG documentation
+that access this file.  Apparently, there is at least one more, execl ().
+In any event, the DG C subroutines should do something more graceful when it
+can't access the information it wants.  I will take this matter up with
+DG.  In the meantime, all current AOSVS/IRAF sites now have MV/UX so they
+should really keep this file up to date for all users.
+
+7) Node name changes.
+	There are NOT solpl!'s all over the place.  They are confined to
+the files which may contain site dependence.  In any event, since CTIO
+does not have any networking software, the IRAF networking is automatically
+turned off and the solpl!'s are harmless and need not be changed.  If there
+are any files that particularly bother you, give me their names and I'll
+see what I can do.
+
+8) Editor descriptor files (.ed).
+	The editor descriptor 'edit' was already provided so that SED
+does not generate files with conflicting extensions.
+
+9) Vi.
+	We execute vi directly from the CLI.  We use a slightly different
+entry for the vi500 in /etc/termcap than the one used by IRAF, so as to
+get around some DG bugs.  The user needs a .exrc file in his home directory
+to set the terminal type.
+
+10) Wait.c
+	The include file wait.c is missing from the DG C release and
+should be copied from :usr:include:wait.h to :util:c_dir:sys.
+
+11) Mkpkg -B flag.
+	The -B flag was present in the mkpkg file in the immediately superior
+directory, but I will put it in all the subdirectory mkpkg files as it
+should be.
+
+12) No documentation for dev$*.ed files.
+	I agree with you, Gary.  However it turns out that most of it
+is not necessary to change.
+
+13) image$imdebug/mktest.x
+	I reported the integer overflow problems to Doug some time ago
+when I ran the benchmarks.
+
+
+NNN
diff --git a/doc/ports/aos_port.doc b/doc/ports/aos_port.doc
new file mode 100644
index 00000000..fa88fcd2
--- /dev/null
+++ b/doc/ports/aos_port.doc
@@ -0,0 +1,223 @@
+/iraf/lib
+        clpackage.cl            Changed terminal name
+        config.h                AOSVS changes (HOST_CASE, etc.)
+        iraf.h                  AOSVS changes (added defines for and, or, etc.)
+        mach.h                  MV/10000 changes
+        make.h                  MV/UX changes
+/iraf/lib/libc
+        iraf.h                  AOSVS changes
+        kernel.h                AOSVS changes
+                                The buffer size for IPC was changed from 4096
+                                to 1024, because of the error:
+                                Warning: File Read Error (STDIN) when doing
+                                set | match tty ... or ... type x | type
+                                where x was 1024 or more bytes long.  This error                                was followed by a hangup on logout, apparently
+                                waiting for the sub-process to die after sending                                it 'bye'.  The kernel routine ZFIOPR was tested
+                                to record lengths of 4096 with no problems.  I
+                                don't understand this; it looks like a weird
+                                problem in FIO.
+        knames.h                AOSVS changes
+        libc.h                  AOSVS changes
+        math.h                  Added conditional for C math functions (nint)
+        spp.h                   AOSVS changes
+        xnames.h                AOSVS changes
+/iraf/math/bevington
+        chifit.f line 103       Ambiguous transfer of control to statement 70
+/iraf/math/curfit
+        OK
+/iraf/math/deboor
+        cwidth.f line 112       Dummy argument declaration order
+        dtblok.f line 18        "
+        factrb.f line 25        "
+        fcblok.f line 29        "
+        sbblok.f line 15        "
+        shiftb.f line 33        "
+        slvblk.f line 119       "
+        subbak.f line 16        "
+        subfor.f line 21        "
+/iraf/math/gsurfit
+        OK
+/iraf/math/iminterp
+        Makelib                 ii_spline mentioned twice
+/iraf/math/interp
+        interp.h                Renamed to interpdef.h
+        clginterp.x             Not found
+/iraf/math/llsq
+        sva.f lines 179 & 181   Comma needed after P edit descriptor
+/iraf/math/surfit
+        OK
+/iraf/pkg/cl
+        bkg.c 2 places          Declaration added for long c_clktime()
+        grammar.y               Yacc conflicts: 8 shift/reduce
+        main.c                  The declarations for "rootpackage" & "clpackage"                                were made consistent with those in builtin.c so
+                                that the "btbl" static table of builtins could
+                                be properly initialized.
+        main.c  envinit()       'lib/' changed to 'lib:' ?????
+        pfiles.c line 563       In addparam() prevent dereferencing a possibly
+                                NULL pointer.
+        task.h                  prevtask and tp++ (or ++tp) didn't work due to
+         builtin.c (2 places)   AOSVS alignment of pointers.  Note: the fix for
+         debug.c                VMS was not machine independent.
+         errs.c
+         exec.c (2 places)
+         pfiles.c
+        mem.h dereference()     Changed to be machine independent.  Previous
+                                definition assumed byte addressing.
+/iraf/pkg/help
+        nomore.x .f line 39     Relational operator with logical operands.
+        manout.x                In man_breakpage(), identifier "nlines_per_page"                                was changed to "n_per_page" to shorten length of                                subroutine statement.  (RPP maximum output line
+                                length is set to 74.)
+/iraf/pkg/help/lroff
+        output.x (3 places)     'col' multiply defined
+/iraf/pkg/softools/boot/mklib
+        makefile                AOSVS changes
+        mklib.c                 AOSVS changes
+        scanlib.c               AOSVS changes
+/iraf/pkg/softools/boot/spp
+        makefile                AOSVS changes
+        readme                  AOSVS comments added
+        xc.c                    AOSVS changes
+        xc.c procedure "fatal"  Missing argument to fprintf
+/iraf/pkg/softools/boot/spp/rpp
+        makefile                AOSVS changes
+/iraf/pkg/softools/boot/spp/rpp/ratlibc
+        amove.c                 Changed link/unlink to amove for AOSVS
+        getnow.c                Removed milliseconds
+        initst.c                Changed _NFILE to 16
+        makefile                AOSVS changes
+        ratdef.h                Added RF defines
+        readf.c                 Removed declaration for fread
+        writef.c                Removed declaration for fwrite
+/iraf/pkg/softools/boot/spp/rpp/ratlibf
+        caslab.f line 32        Warning: unreachable code
+        ctomn.f                 Changed and to iand
+        gitoc.f                 Changed and to iand
+        makefile                AOSVS changes
+/iraf/pkg/softools/boot/spp/rpp/rppfor
+        baderr.f                Declared argument to be character*(*)
+        errchk.f line 78        Missing argument to call to GNBTOK
+        gtok.f line 132         Commented out B = 10 * B + C - 48
+                                to avoid fixed point overflows.
+                                Not needed since radix conversion is done in XPP        makefile                AOSVS changes
+        synerr.f                Declared argument to be character*(*)
+/iraf/pkg/softools/boot/spp/xpp
+        decl.c                  Set MAXSYM = 200.  Needed to compile
+                                /iraf/sys/gio/nsppkern/gktopenws.x because of
+                                include file nspp.com.  Note: the overflow
+                                check in d_enter is wrong.
+        makefile                AOSVS changes
+        xppcode.c               After MACHDEP, changed int to int2, int4, etc.
+        xppmain.c               Check for NULL after calling getenv
+/iraf/pkg/system
+        delete.x line 48        Relational operator with logical operands
+        match.x  line 42        Relational operator with logical operands
+                 line 76        Relational operator with logical operands
+        page.x   line 204       Relational operator with logical operands
+        sort.x   line 290       "answer" declared twice
+/iraf/sys
+        OK
+        tsort cycle: libex.a    gamove, gadraw, elogr
+        tsort cycle: libsys.a   error,  erract, xerfmt, environ, realloc,
+                                        malloc, syserr, itoc
+                                environ, realloc, malloc, xerpop, erract,
+                                         xerfmt, gstrcpy
+                                xerpop, erract, putci,  flsbuf, fexbuf,
+                                        realloc, malloc
+                                putci,  flsbuf, fexbuf, realloc, xerpop,
+                                        erract, putline
+/iraf/sys/clio
+        OK
+/iraf/sys/etc
+        environ                 envgets broken out, to avoid tsort cycle
+/iraf/sys/fio
+        fclobber.x  .f line 67  Relational operator with logical operands
+        vfnmap.x  .f line 546   Relational operator with logical operands
+/iraf/sys/fmtio
+        dtoc3.x .f line 118     Parentheses needed for unary arithmetic operator        evexpr.x .f line 393    Relational operator with logical operands
+/iraf/sys/gio
+        elogd.x  .f line 29     Parentheses needed for unary arithmetic operator        elogr.x  .f line 29     Parentheses needed for unary arithmetic operator/iraf/sys/gio/cursor
+        OK
+        tsort cycle : libcur.a  gtrctrl, gtropenws, prpsio, giotr.
+/iraf/sys/gio/gki
+        OK
+/iraf/sys/gio/glabax
+        OK
+/iraf/sys/gio/nspp
+        i1mach.f                Copied from /iraf/sys/osb
+        r1mach.f                Copied from /iraf/sys/osb
+        ibit.s                  substituted ishift.f
+                                IAND - ignored
+                                IOR - ignored
+                                ISHIFT - calls ishiftc
+/iraf/sys/gio/nspp/mctr
+        OK
+/iraf/sys/gio/nspp/nspp
+        OK
+/iraf/sys/gio/nspp/utilities
+        conrec.f line 387       Character constant broken over 2 lines
+        conterp.f line 1518     Compilier warning: padded short constant: 2HLO
+                  line 1656     "
+/iraf/sys/gio/nsppkern
+        nspp.com                Changed all () to [].
+        pixels.f line 58        Arguments to intrinsic function not of same type/iraf/sys/gio/stdgraph
+        stgrcur.x .f line 66    Relational operator with logical operands
+/iraf/sys/imio
+        OK
+/iraf/sys/imio/db
+        idbpstr.x  .f line 77   IM_NAXIS not defined in imio.h
+/iraf/sys/imio/tf
+        OK
+/iraf/sys/ki
+        kinode.com              Added arrays n_local and n_nrefs.
+/iraf/sys/libc
+        mathc.c                 Added conditional for C math functions (nint)
+        printf.c &              The machine dependent technique of handling
+        scanf.c                         a variable number of arguments was only
+                                        very obscurely documented.  All the
+                                        appropriate references of argp++ (sic)
+                                        were changed to argp-- for AOSVS.
+        OK
+/iraf/sys/memio
+        OK
+/iraf/sys/mtio
+        OK
+/iraf/sys/os
+        MANY like zfaloc, zfiomt, zfiopr, zfrnam, zlocva, zmaloc, zmfree,
+                  zopdir, zopdpr, zraloc :      return (*status = XERR);   etc.
+                                C returning a value when CALLed by F77 causes
+                                        problems, at least with OPTimized code.
+        MANY                    AOSVS versions: zawset, zfacss, zfaloc, zfchdr,
+                zfgcwd, zfinfo, zfiomt, zfiopr, zfiost, zfmkcp, zfmkdr, zfpath,
+                zfprot, zfrnam, zfsubd, zfxdir, zglobl, zgtenv, zgtime, zinit,
+                zmain,  zmaloc, zopdir, zoscmd, zsvjmp, zxwhen
+        makelib                 Dependencies corrected, and updated for AOSVS
+        zcall.c                 Dereference usage of PFI
+                                Declare all arguments to be pointers
+        zfiolp.c line 116       Defererence "dispose"
+                 line 129       ZOSCMD called with character arguments
+        zfiopl.c line 101       Same as zfiolp line 116
+                 line 114       Same as zfiolp line 129
+        zfiopr.c line 55        Cast osfn as (char *)
+        zfiotx.c line 376       Dereference "status"
+        zlocpr.c                An extra dereference was needed for AOSVS
+        zmain.c  line 118       Cast osfn as (char *)
+        zopdir.c                Modified input argument
+/iraf/sys/osb
+        acht??.c                Modification of input argument
+        bytmov.c                Bug concerning undefined variable "otop"
+        bytmov.s                MV/10000 version
+        d1mach.f                Added entries for Data General MV/10000
+        i1mach.f                "
+        r1mach.f                "
+        makelib                 AOSVS version
+        mii.x                   Removed call to high level routine "error"
+/iraf/sys/tty
+        ttyopen.x  .f line 208  Relational operator with logical operands
+        ttyputs.x  .f line 43   Arguments to intrinsic function not of same type/iraf/sys/vops
+        OK
+/iraf/sys/vops/achtgen
+        OK
+/iraf/sys/vops/ak
+        Makelib                 Replaced .s modules with .x
+/iraf/sys/vops/lz
+        Makelib                 Replaced .s modules with .x
diff --git a/doc/ports/aux_port.doc b/doc/ports/aux_port.doc
new file mode 100644
index 00000000..743d453c
--- /dev/null
+++ b/doc/ports/aux_port.doc
@@ -0,0 +1,978 @@
+Begin IRAF port to Macintosh A/UX 2.0, 26Jan91.
+-----------------------------------------------
+
+unix/as
+unix/as.mac		+
+unix/bin
+unix/bin.mac		+
+unix/hlib/irafuser.csh
+	Set up a new "mac" architecture.  (01/26)
+
+unix/hlib/libc/iraf.h
+	Set the iraf root to point to /u1/iraf.  (01/26)
+
+unix/as.mac/ishift.s
+unix/as.mac/zsvjmp.s
+	Modified for the GNU assembler (GAS).  (01/26)
+
+unix/hlib/*.csh
+	Modified for A/UX.  (01/26)
+
+unix/hlib/config.h
+unix/hlib/libc/spp.h
+	Checked that LEN_JMPBUF was large enough to handle the setjmp
+	buffer used by A/UX.  (01/26)
+
+unix/boot/bootlib/mkpkg.sh
+unix/boot/generic/mkpkg.sh
+unix/boot/mkpkg/mkpkg.sh
+unix/boot/rmbin/mkpkg.sh
+unix/boot/rmfiles/mkpkg.sh
+unix/boot/rtar/mkpkg.sh
+unix/boot/spp/mkpkg.sh
+unix/boot/spp/mkxc.sh
+unix/boot/spp/rpp/mkpkg.sh
+unix/boot/spp/rpp/ratlibc/mkpkg.sh
+unix/boot/spp/rpp/ratlibf/mkpkg.sh
+unix/boot/spp/rpp/rppfor/mkpkg.sh
+unix/boot/spp/xpp/mkpkg.sh
+unix/boot/wtar/mkpkg.sh
+unix/boot/xyacc/mkpkg.sh
+unix/gdev/sgidev/mkpkg.sh
+unix/os/mkpkg.sh
+unix/shlib/mkpkg.sh
+	Changed all occurrences of "cc" to "$CC" and all occurrences of
+	"f77" to "$F77".  Changed all occurrences of "ranlib" to $RANLIB.
+	(01/26)
+
+unix/hlib/irafuser.csh
+	Added definitions for CC, F77, and RANLIB (set to "echo ranlib" for
+	A/UX, which uses COFF).  For the first attempt to compile the system
+	I am using gcc and the Absoft A/UX Fortran compiler.  Later I would
+	like to try f2c (Fortran to C translator) with gcc as an alternative
+	to the Absoft Fortran.  Early tests indicate that this should work,
+	and may produce better optimized code than the Absoft compiler.  I
+	have already verified that the A/UX f77 cannot be used to build iraf
+	- there were serious problems just trying to compile the files in
+	one directory.  (01/26)
+
+-------
+Begin bootstrap.  For this I have the GCC flags set to fairly restrictive
+values, enabling some optional warning messages, to flush out any
+questionable coding constructs.  GCC is also an ANSI C compiler, which may
+mean additional problems.  (01/26)
+
+unix/os/mkpkg.sh
+	GCC doesn't echo the filename (as in "file.c:") during compiles,
+	which I found annoying, so I changed the mkpkg.sh to use the Bourne
+	shell FOR construct to compile each file separately.  (01/26)
+
+unix/setarch.sh
+	The A/UX version of "test" does not have the -h flag to test for
+	symbolic links, so the existing script did not work.  Still trying
+	to a portable way to do this, I changed the script to use the
+	construct:  if [ "`ls -d as`" = "as" ]; then ...  (01/26)
+
+unix/os/alloc.c
+	1. The file header comment section contained the sequence "for the
+	/dev/* entries...".  The "/*" would cause a warning from gcc that
+	there might be a comment buried in another comment, which can cause
+	a comment to terminate prematurely.  In this case it was harmless
+	and indeed there was no error, but I changed the text to eliminate
+	the warning.
+	2. Moved the #include <sys/types.h> to before the #include <utmp.h>,
+	as the A/UX version of the latter requires the former.  (01/26)
+
+unix/os/getproc.c
+	1. Had to add
+
+	    #ifdef AUX
+	    #include <sys/mmu.h>
+	    #include <sys/page.h>
+	    #include <sys/region.h>
+	    #endif
+
+	before the #include <sys/proc.h>, to get the latter to compile.
+
+	2. In the A/UX nlist facility n_name is an array rather than a
+	pointer to char, so entries such as
+
+	    nl[0].n_name = "_proc";
+
+	had to be changed to
+
+	    strcpy (nl[0].n_name, "_proc");			(01/26)
+
+unix/os/prwait.c
+	In pr_getipc(), deleted unused variables error_code, error_status,
+	waitpid.  (01/26)
+
+unix/os/zalloc.c
+	1. In ZDVALL, deleted unused variable x_status.
+	2. Deleted unused variable i in loggedin().  (01/26)
+
+unix/os/zfioks.c
+	1. Deleted the old, commented out code for rcmd(), as variables
+	defined for this were being reported as unused.  Added a comment
+	explaining that rcmd and friendly-host authentication cannot be
+	used without making the process suid root.
+	2. Added #ifdef SYSV support for SysV termio.  Terminal driver
+	ioctls are used in this routine to set raw mode for the password
+	prompts.
+	3. GCC was complaining that the setjmp/longjmp used in zardks,
+	zawrks could cause certain register variables to become undefined
+	(op and nbytes in zardks, ofd in zawrks), so I changed the storage
+	class from register to auto for these variables.  (01/26)
+
+unix/os/zfiolp.c
+	I had to change the declaration
+
+	    static PKCHAR xnullstr[1] = XEOS;
+	to
+	    static PKCHAR xnullstr[1] = { XEOS };
+
+	(PKCHAR=short and XEOS=0) or GCC would complain about an invalid
+	initializer.  Must be a feature of the ANSI C syntax.  (01/26)
+
+unix/os/zfiotx.c
+unix/hlib/libc/kernel.h
+	1. Modified to add #ifdef SYSV support for SysV terminal i/o.
+	2. GCC complained about some functions which were used (default
+	storage class extern) and later declared static; added static
+	declarations for these functions to the file header to eliminate
+	these (harmless) warning messages.  (01/27)
+
+unix/os/zfxdir.c
+	Deleted unused local variable "ch".  (01/27)
+
+unix/os/zgcmdl.c
+	Deleted unused local variable "ev".  (01/27)
+
+unix/os/zgcmdl.c
+	Produced a coupld of "/* within comment" warning messages due an
+	example of some <iraf.h> code in the header comment.  Changed /* in
+	the example to /@ to avoid the (harmless) warning.  (01/27)
+
+unix/os/zgtime.c
+	Had to #ifndef SYSV the #include <sys/timeb.h> as this file does
+	not exist on SysV systems.  (01/27)
+
+unix/os/zmain.c
+	Deleted unused local variables "junk" and "wsetsize".  (01/27)
+
+unix/os/zwmsec.c
+	Added "static" to explicitly specify the storage class in the first
+	declarations of "napmsx", which is declared static in the source
+	given later in the file.  (01/27)
+
+unix/os/zxwhen.c
+	1. The system dependent definition "fcancel" would not work for A/UX;
+	added a #ifdef AUX version.
+	2. GCC did not realize that the call to kernel_panic in zxwhen was
+	an exit, and would warn that the value of variable "vex", used later
+	in the procedure, could be unitialized.  Added a statement to init
+	this to null to avoid the warning message.
+	3. In zxgmes, the char pointer to the returned error message was
+	not being initialized if no error had occurred.  Modified to return
+	the null string in this case.  (01/27)
+
+unix/os/zzstrt.c
+	Added #ifdef SUNOS4 conditionals around certain declarations which
+	are used only the #ifdef SUNOS4 code which follows, to avoid unused
+	variable warnings.  (01/27)
+
+unix/boot/bootlib/envinit.c
+	Deleted the unused variable "osfn" in loadpkgenv.  (01/27)
+
+unix/boot/bootlib/bootlib.h
+	Deleted the commented out #define NOVOS definition, which causes
+	a /* in comment warning and doesn't need to be in this file anyhow.
+	(01/27)
+
+unix/boot/bootlib/osfcopy.c
+	1. Deleted the unused variable "binary_file".
+	2. Added a return at the end of the function, to guarantee that
+	a function value was returned.  (01/27)
+
+unix/boot/bootlib/ostime.c
+	Modified with #ifdef SYSV for SysV.  This whole business needs to
+	be redone sometime to provide rigorously correct time primitives
+	for iraf.  (01/27)
+
+unix/boot/bootlib/vfn2osfn.c
+	Local variable "first_time" defined but never used.  (01/27)
+
+unix/boot/generic/generic.c
+	1. In copy_comment(), added an entry time initializer for the
+	local variable "flag".
+	2. GCC complained about the variable "ch" in evaluate_expr() possibly
+	being used before being initialized.  This looked harmless in this
+	case, but I added a global initializer to eliminate the warning
+	message.  (01/27)
+
+unix/boot/mkpkg/host.c
+	Deleted a couple of unused "exit_status" variables.  (01/27)
+
+unix/boot/mkpkg/host.c
+	Deleted unused variable "ip" in search_mkpkgfile().  (01/27)
+
+unix/boot/mkpkg/mkpkg
+unix/boot/mkpkg/mkpkg.h
+unix/boot/mkpkg/scanlib.c
+	1. Added a #include "mkpkg.h" to scanlib.c.  This file includes extern.h
+	which references a structure defined in mkpkg.h.
+	2. Deleted unused local variable "key" in h_scanlibrary().  (01/27)
+	3. Replaced the MAX_SYMBOLS definition in scanlib.c by MAX_LIBFILES,
+	as there is also a MAX_SYMBOLS in mkpkg.h which means something
+	quite different.  (01/29)
+
+unix/boot/mkpkg/sflist.c
+	In sf_scanlist, the GCC static analysis indicated that variable "tail"
+	could possibly be used without being initialized.  Added code to
+	initialize tail=head before scanning the list.  (01/27)
+
+unix/boot/mkpkg/tok.c
+	1. In do_if(), in the event of a syntax error the local variable "bval"
+	could be used without being initialized.  Once again probably harmless
+	but it makes GCC complain.
+	2. Unused variable "ch" in do_call().
+	3. Module do_include() was not returning an exit status in all
+	cases.  (01/27)
+
+unix/boot/rmfiles.c
+	1. Unused variable "i" in main().
+	2. Another warning from GCC static analysis suggesting that local
+	variable "fp" might be being used before being initialized (definitely
+	not in this case, but I added an initializer to avoid the message).
+	(01/27)
+
+unix/boot/wtar/wtar.c
+	Unused variable "op" in putheader().  (01/27)
+
+unix/boot/spp/xc.c
+	1. Unused variable "cmdbuf" in main().
+	2. Variable "append" in sys() could be used before being
+	initialized.  (01/27)
+
+unix/boot/spp/xpp/xppcode.c
+	1. Unused variable "irafdefs" in do_include().
+	2. parse_task_statement() did not return a function value in all cases.
+	3. accum() did not return a function value in all cases.
+	4. Unused variable "digit" in charcon().  Function did not return
+	a value in all cases.
+	5. Variable "value" not initialized in all cases (when an error
+	occurs, but it causes a warning message).  (01/27)
+
+unix/boot/spp/xpp/decl.c
+	Local variable "sp" was not being initialized in all cases (i.e.,
+	when an error occurred).  (01/27)
+
+unix/boot/spp/rpp/ratlibc/getlin.c
+	The local variable "c" was not being initialized in all cases.  (01/27)
+
+unix/mkpkg.sh
+	Commented out the SHLIB build code, as there is no shared library
+	support for Mac/IRAF yet.  (01/27)
+
+unix/gdev/sgidev/sgidispatch.c
+	Deleted unused local variables "maxch" and "status".  (01/27)
+
+--------------------------
+Second bootstrap attempt.  (01/27)
+
+unix/os/gmttolst.c
+	Added #ifdef SYSV support.  (01/27)
+
+unix/os/mkpkg.sh
+	Changed the "rm alloc.o" to "rm -f alloc.o", as the .o file is
+	not being left behind on this system, using GCC.  (01/27)
+
+unix/os/zfioks.c
+unix/hlib/irafuser.csh
+	GCC still warns that longjmp could clobber the values of several
+	local variables in this routine.  Evidently this is a feature of
+	ANSI C.  The values of automatic variables not declared "volatile"
+	are not guaranteed to be preserved in a longjmp.  Added a -DANSI
+	to irafuser.csh and some #ifdef ANSI code to zfioks.c to provide
+	the necessary (but not non-ANSI backwards compatible) definitions.
+	(01/27)
+
+unix/os/zfiotx.c
+	Another longjmp warning, this time in ZGETTX.  Variable "op" might
+	not be saved over a longjmp.  In this case I was able to avoid the
+	problem merely by moving the op initialization statement to after
+	the setjmp.  (01/27)
+
+unix/os/zfiopl.c
+	In zclspl, another case of an array aggregate initializer "= val;"
+	having to be changed to "= { val };" when initializing an array of
+	length 1.  (01/27)
+
+unix/os/zoscmd.c
+	Modified so that if SYSV is defined, "fork" is used instead of 
+	the BSD-ism "vfork".  (01/27)
+
+-------------------------
+Third bootstrap attempt.
+
+unix/boot/spp/rpp/ratlibf/*.f
+unix/boot/spp/rpp/rppfor/*.f
+	The Fortran compiler I am using (Absoft) is case sensitive by default
+	and does not append an underscore to symbol names.  For testing
+	purposes it would be most useful to have the Fortran names occupy
+	the same name space as the C library names, so I translated the
+	contents of all the above files to lower case.  (01/27)
+
+	[In retrospect this wasn't the best way to do this, the Fortran
+	compiler has a switch which does it more simply.  (01/29)]
+
+unix/boot/spp/rpp/ratlibc/ratdef.h
+	Removed the trailing underscore from the names of the Fortran
+	routines.  (01/27)
+
+unix/hlib/libc/knames.h
+unix/hlib/libc/xnames.h
+	Edited to remove the trailing underscore from all names.  (01/27)
+
+unix/boot/spp/rpp/ratlibr/defs
+unix/boot/spp/rpp/rpprat/defs
+	It probably doesn't matter, but these directories both have a copy
+	of the "defs" file and the files should be the same, but they aren't.
+	The version in rpprat has been changed to increase the size of
+	various size limiting buffers.  The fortran sources should be
+	regenerated using compatible defs files.  (01/28)
+
+unix/boot/spp/rpp/mkpkg.sh
+	RPP failed to link in the first bootstrap attempt.  To fix this
+	it was necessary to modify the $CC link command in the mkpkg.sh,
+	as follows:
+
+	    $CC $HSI_CF -t rpp.o librpp.a libf.a libc.a -lf77 -o rpp.e
+
+	The -t flag had to be added to avoid warnings about the inconsistent
+	sizes for the cdsmem common (see "defs", above).  The -lf77 had to
+	be added for the Absoft compiler, as evidently it uses library
+	functions for a few simple things like ABS that some RPP code
+	references.  (01/28)
+
+unix/boot/mkpkg/host.c
+	Added a #ifdef SYSV to the code which calls RANLIB, since this is
+	not used on SYSV (COFF) systems.  (01/28)
+
+unix/os/irafpath.c
+	Added a #ifdef AUX conditional to search the "unix/bin.mac" directory
+	for Mac/IRAF system files.  (01/28)
+
+unix/spp/rpp/rppfor/poicod.f
+	The HSI bootstrap completed successfully, although some things are
+	probably still not working correctly.  XC now runs but in my very
+	first compile test I ran into a nasty problem in the third party
+	Absoft Fortran compiler.  The compiler complains about the following
+	statement in fio$areadb.x being out of order:
+
+		memi(fp+15) = 0
+
+	Evidently it thinks this array assignment is a statement function
+	or something.  I was further able to isolate the problem with the
+	following source:
+
+	    subroutine areadb (fd)
+	    integer fd
+	    integer Memi(1)
+	    real    Memr(1)
+	    equivalence (Memi, Memr)
+	    common /Mem/ Memi
+	    save
+		memi(fd+15) = 0
+	    end
+
+	The compiler barfs on a syntax error on line 8 of this file, the
+	lone assignment statement.  With a little further testing I was
+	able to establish that this is due to case sensitivity in the
+	compiler!  Changing the memi to Memi causes the problem to go away.
+	To fix the problem in RPP I had to replace the file poicod.f by
+	a version that uses "mem" rather than "Mem" in the data strings.
+	(01/28)
+
+unix/hlib/libc/libc.h
+	The Absoft compiler prefixes the names of Fortran commons with C
+	(e.g., "Cfiocom", "Cmem", etc.) and omits the trailing underscore
+	as in C.  Modified libc.h to reflect the above naming scheme.  (01/28)
+
+---------------------------------
+Started first core system sysgen.  (01/28)
+
+sys/plio/plr2l.gx
+sys/plio/plp2l.gx
+sys/plio/pllsten.x
+sys/plio/pllrop.x
+	The Absoft Fortran compiler could not handle the following type of
+	statement in these files:
+
+	    ll_out[op] = M_DH + -dv
+
+	It was necessary to place parens around the (-dv) to avoid the
+	problem.  (01/29)
+
+unix/hlib/iraf.h
+unix/boot/spp/xpp/decl.c
+	1. There were a lot of problems in PLIO in the initial sysgen due to
+	the use of bitwise boolean intrinsics in these files.  The Absoft
+	compiler does have some bitwise functions but 1) they are typed,
+	not generic functions, and 2) a function which takes two short
+	integer arguments as input can return an integer result (contrary
+	to the documentation).  Also, this is not a problem but a comment,
+	but the compiler generates function calls for the bitwise operators,
+	which is rather inefficient.  The only way I could come up with to
+	work around these limitations was to define the bitwise intrinsics
+	in hlib$iraf.h as follows:
+
+		define	and	iand(int($1),int($1))
+		define	or	ior(int($1),int($1))
+		define	not	jnot(int($1))
+		define	xor	ieor(int($1),int($2))
+
+	2. Unfortunately the argument expansion in the above definitions
+	would cause problems with functions that declare the bitwise
+	intrinsics, i.e., that contains statements such as "int and()".
+	It was necessary to modify decl.c to add special processing for
+	function declarations so that any declarations of the bitwise
+	intrinsics could be omitted.  This may be a generally useful
+	addition as special processing of intrinsic functions might be
+	required on any system.  (01/29)
+
+sys/mwcs/mwtransd.x
+	This file also contained a "foo + -bar" construct requiring
+	parenthesis to get by the Absoft parser.  (01/29)
+
+sys/imfort/imemsg.x
+	This file contained four Fortran escapes (error message strings)
+	which ran over the 72 character line limit of Fortran, causing the
+	Absoft compiler to complain.  (01/29)
+
+unix/hlib/mkpkg.inc
+	Added the following default compile time flags:
+
+	    -f		Fold all symbol names to lower case.  This is needed
+			for some of the Fortran sources.
+
+	    -k		Restore all registers when a procedure returns.
+			This is necessary if Fortran modules are to be
+			called from C code.
+
+	Mac/IRAF also needs the -z link flag.  (01/29)
+
+sys/gio/nspp/portlib/gridal.f
+	The equivalence on line 4 was incorrect (or at least ill-advised)
+	due to a dimension error.  The code "mfmtx(1),ifmt(1))" should
+	have been "mfmtx(1),ifmt(1,1))".  (01/29)
+
+sys/gio/nspp/portlib/z8zpbd.f
+sys/gio/nspp/portlib/z8zpii.f
+	The Absoft compiler didn't want to permit use of DATA to initialize 
+	variables in common so I had to move all the remaining DATA
+	statements out of z8zpbd.f into run time initialization statements
+	in z8zpbd.f  (01/29)
+
+unix/boot/spp/xc.c
+	1. The routine printargs() was printing one more argument then there
+	was, due to a <= that should have been a < in a FOR loop.
+	2. Modified XC to use GCC for linking.  (01/29)
+
+-----------------------
+This took care of all the problems with the sysgen up to the attempt to
+link the first task.  Trying to build the system task, there was a file
+that did not compile.  Inexplicably the system hang twice requiring a
+reboot, once while linking and the other time while trying to do a mkpkg
+on the system task (the system hand requiring a reboot in my first attempt
+to link an iraf task!).  No idea why this happening.  (01/29)
+
+The above problem was due to the rebuilding of XC after the first sysgen.
+libsys.a and libvops.a existed this time so XC was not built NOVOS, which
+was no good as the entire kernel needs to be consistent one way or the
+other, and I haven't done runtime checks of the iraf libraries yet anyhow.
+(01/30)
+
+unix/hlib/mkfloat.csh
+	The tar -x flags are "tar -xpf" for BSD systems, and "tar -xof" for
+	SysV systems.  Added a new SET at the top to document the dependency
+	and set the value to -xof for AUX.  (01/30)
+
+unix/hlib/irafuser.csh
+unix/hlib/fc.csh
+unix/hlib/cl.csh
+	Set up two different architectures for Mac/IRAF.  These are the
+	following:
+
+		mf2	Absoft MacFortran II binaries
+		f2c	F2C/GCC binaries
+
+	F2C is a publically available Fortran to C translator, and GCC is
+	the GNU C compiler.  These can be combined to yield an interesting
+	Fortran compiler constructed from only publically available sources.
+	This is particularly interesting since we are already using GCC
+	as our C compiler for A/UX.  Initially I am building with the Absoft
+	compiler but I plan to try F2C/GCC later.  (01/30)
+
+mkpkg
+noao/mkpkg
+bin.generic		+
+	Edited the root mkpkg file to add entries "mf2" and "f2c" for setting
+	the bin.mf2 and bin.f2c architectures.  Deleted all the Sun
+	architecture entries.  Added a bin.generic subdirectory.  (01/30)
+
+pkg/system/help/lroff/textout.x
+	Modified to eliminate the ENTRY point.  (01/30)
+
+-----------------------
+First successful iraf process link on A/UX - xx_system.e  (01/30)
+
+unix/hlib/iraf.h
+unix/hlib/libc/xnames.h
+	The Absoft compiler does not append an underscore to function names
+	hence SPP/Fortran function names occupy the same name space as C
+	names.  Probably there are a number of SPP procedure names which
+	redefine standard C library or other host system names (this has also
+	been a problem with VMS/IRAF so fixing that system will be another
+	benefit of dealing with this here).  The first such name collision
+	found is GETPID.  Since the SPP getpid was calling the host getpid
+	an infinite loop would result.  This is probably what was causing
+	the system to hang up when XC was run earlier.  (01/30)
+
+	Summary of redefined names (to be added to as I locate them):
+
+		getpid
+
+	All such name collisions are handled by remapping the name in iraf.h
+	and libc/xnames.h.
+
+unix/boot/spp/xc.c
+unix/hlib/mkpkg.inc
+	Modified XC to use CC for linking (I was using GCC) and change the
+	"-/t" link flag in mkpkg.inc to "-/Wl,-t", which instructs CC to
+	hand off the flag -t to the linker.  (01/30)
+
+unix/os/zzstrt.c
+unix/os/zxwhen.c
+	Digging into the A/UX internals to see how A/UX handles the IEEE
+	exceptions I find that a function "initfpu" is called during process
+	startup.  It turns out though, that this function is a no-op!
+	From the assembler it appears that the current version is initfpu(){}.
+	Must be a placeholder for a future version of A/UX when it will be
+	done "right".  No changes to zzstrt/zxwhen yet until I figure out
+	how...  (01/30)
+
+unix/hlib/mkpkg.inc
+unix/hlib/mkpkg.sf.MF2
+	Uh oh...  Absoft compiler bug, and a troublingly simple one.  The
+	memio$sizeof.x procedure is only one line long:
+
+	    return (ty_size[dtype])
+
+	but the Absoft compiler with default optimization enabled is
+	eliminating most of the code and producing something which does
+	not even use the ty_size array.  Added the file to the mkpkg
+	special file list to be compiled without optimization.  (01/30)
+
+--------
+unix/hlib/mkpkg.sf.MF2
+	On March 27 I finally got a few more hours to play with this port;
+	looked into the next runtime bug in x_system.e.  It turned out to
+	be necessary to recompile file fio$fgetfd.x without optimization.
+	Once again, the bug was disturbing as it did not look like an
+	especially subtle bug.  It looked like the compiler was allocating
+	the same location on the stack in two places and the second reference
+	would overwrite the first.  After working around this one, I tried
+	running x_system.e and it failed again with another startup bug,
+	still trying to execute all the code in clopen.x.  It begins to
+	look bad for the Absoft compiler; if we can't get any further than
+	this I suspect the system will be riddled with optimizer bugs.  (3/29)
+
+--------
+I think it is time to give up on the Absoft compiler, at least for now, and
+try F2C instead.  (4/3)
+
+unix/hlib/irafuser.csh
+unix/hlib/mkpkg.sf.F2C			+
+	Configured for F2C architecture.  (4/3)
+
+unix/hlib/libc/libc.h
+unix/hlib/libc/xnames.h
+unix/hlib/libc/knames.h
+unix/boot/spp/rpp/ratlibc/ratdef.h
+unix/as.mac/zsvjmp.s
+	Restored the trailing underscores, since F2C adheres to this
+	convention.  (4/3)
+
+unix/hlib/iraf.h
+	Commented out the definitions for and,or,not,xor, since F2C uses
+	the SPP versions (which came originally from UNIX f77).  (4/3)
+
+sys/fmtio/ctotok.x
+	Local variable numch never used (this is old code so I don't know
+	why no other compiler has found this).  (4/3)
+
+sys/fmtio/evexpr.y
+sys/fmtio/evexpr.x
+	The second argument (a debug flag) to yyparse (xev_parse) is a
+	boolean, but xev_parse was being called elsewhere with an integer
+	argument.  Changed to a boolean since the Y*cc code contains many
+	if (yydebug) constructs.  (4/3)
+
+sys/etc/main.x
+	FREDIR is a subroutine but was being called as a function in one
+	place in this file.  (4/3)
+
+sys/tty/ttyputl.x
+	This file contained a statement  call putci (fd, "_")  which was
+	incorrect, since the argument "_" is type char but is supposed to
+	be integer.  (4/3)
+
+sys/gio/gopen.x
+	The pointer array graphcap_file was not being used.  (4/3)
+
+sys/pmio/pmplls.x
+	The second call to pl_plls was missing the ll_depth argument.  (4/3)
+
+sys/qpoe/qpppar.x
+	The second call to qp_sizeof was missing an argument.  (4/3)
+
+sys/imfort/bfio.x
+	There was an extra "status" argument to one of the calls to
+	zsttbf.  (4/3)
+
+unix/boot/spp/xc.c
+	Built the CC link time flag "-Wl,-t" directly into XC, since it
+	is needed to link iraf programs and is too much of a nusiance to
+	have to type when XC is used manually.  The flag turns off a linker
+	warning message warning about inconsistent lengths for commons.
+	(4/3)
+
+sys/gio/ncarutil/conran.f
+	Local variable LNGTHS not used.  (4/3)
+
+pkg/plot/crtpict/t_crtpict.x
+	A call to gardwrd was missing the maxch argument. (4/3)
+
+unix/hlib/install
+	1. Had trouble with the $hbin/sgi2* $hlib/sgi2* stuff in MODEFILES.
+	The second did not expand to anything and the string "$hlib/sgi2*"
+	was left in MODEFILES with the * unexpanded, causing problems later
+	when appended to a directory prefix.  Since there are not supposed
+	to be any executables in hlib anyhow I deleted the second reference.
+	2. In the code which checks the MODEFILES, I added a test to see
+	if the file exists as named, before looking for it in each of the
+	directories.  Referencing a nonexistent directory can cause the
+	script to bomb on A/UX (it shouldn't, but it does - a bug in csh).
+	3. Had to change /etc/chown to /bin/chown.  (4/3)
+
+pkg/plot/getdata.x
+	The statement if(nxrows) was incorrect as nxrows is integer.  (4/3)
+
+pkg/xtools/intrp.f
+unix/hlib/mkpkg.sf.F2C
+unix/as/intrp.c			+
+	F2C failed to produce correct C code for this file (which contains
+	multiple ENTRY points).  Hand edited the C version and added it to
+	the special file list.  (4/3)
+
+pkg/dataio/fits/fits_wpixels.x
+unix/hlib/mkpkg.sf.F2C
+unix/as/fits_wpixels.c		+
+	Same bug as above.  (4/3)
+
+pkg/plot/t_graph.x
+	Variable window declared but not used.  (4/3)
+
+pkg/plot/t_velvect.x
+	Variable nset declared but not used.  (4/3)
+
+sys/fmio/fmlfundel.x
+	The two calls to fmio_bind and fmio_errck were both lacking the
+	fm argument.  (5/3)
+
+sys/ki/kireceive.x
+	A call to strcpy was missing an argument.  (5/3)
+
+sys/imio/imopsf.x
+	The call to pl_ssize had an extra unused argument.  (5/3)
+
+sys/etc/pagefiles.x
+	ttyctrl, which is an integer function, was being called as a
+	subroutine.  (5/3)
+
+sys/gio/gopen.x
+	Local string variable graphcap never used.  (5/3)
+
+sys/imio/iki/oif/oifclose.x
+sys/imio/iki/oif/oifdelete.x
+	The integer function protect() was being called as a subroutine.
+	(5/3)
+
+sys/plio/plglr.gx
+	The routine pl_rangerop was being called incorrectly.  (5/3)
+
+sys/plio/plprop.gx
+	The VOPS routine argt (replace if greater than) was being
+	called incorrectly in three places.  (5/3)
+
+sys/plio/plascii.x
+	The subroutine pl_glpi() was being called as a function.  (5/3)
+
+sys/plio/pldebug.x
+	The integer function pl_l2ri() was being called as a subroutine.
+	(5/3)
+
+sys/pmio/pmglp.gx
+	The routine pl_pixrop was being called incorrectly.  (5/3)
+
+sys/qpoe/qpioopen.x
+	A call to syserr was being made where syserrs was intended.  (5/3)
+
+unix/os/zzstrt.c
+	Added a call to "setcompat (COMPAT_BSD)" to be executed upon
+	process startup.  This tells the kernel to use BSD semantics
+	when executing system calls.  This fixed a problem I was having
+	with ZWMSEC, which would result in the process being killed
+	with a SIGALRM when the interval timer interrupted, even though
+	a signal handler had been posted earlier with sigvec.  (5/4)
+
+unix/os/zzstrt.c
+	Here is another problem that, like the previous one, was very
+	indirect and hence difficult to track down.  The time-task feature
+	of iraf, e.g., "$imstat dev$pix", when run for the first time
+	in a new process, would return a clock time such as "-416:+0"
+	instead of "0:13" or whatever.  Thereafter it would be ok, until
+	the process was restarted.  This turned out to be due to the
+	clock time returned by the first call to ZGTIME being wrong.
+	The eventual solution was to add a call to TZSET to zzstrt to
+	initialize the SysV time stuff before any time calculations
+	take place.  What I suspect was happening is that in gmt_to_lst
+	I was accessing "timezone", which is a global data variable in
+	SysV, but the value was being changed sometime later in an
+	indirect call to TZSET.  Using a global variable for something
+	like this that is evidently not constant is a very questionable
+	feature of SVID (unless it is a bug in A/UX).  (5/5)
+
+unix/hlib/mkpkg.sf.F2C
+	It turns out that the A/UX version of bcopy does not work (is
+	destructive) for overlapping arrays, so I had to remove all the
+	entries for amov$t and bytmov from the special file list.  This
+	problem showed up as a segmentation violation in HELP.  (5/5)
+
+	All three of these last bugs were very difficult to track down -
+	essentially, in each case I eventually just guessed what it might
+	be, after tracking the problem down to a region of code.
+
+math/curfit/cvpower.gx
+	Changed a "amovk$t(INDEFR,...)" to "amovk$t(INDEF,...)".  The former
+	causes a real to be passed where a double is expected.  (5/6)
+
+sys/gio/cursor/grccmd.x
+	External pr_psio() declared but never used.  (5/6)
+
+sys/gio/stdgraph/stgclws.x
+	External std_onerror() declared but never used.  (5/6)
+
+sys/libc/qsort.c
+	The static function qst() was being used before being declared,
+	resulting in an extern/static declaration inconsistency.  (5/6)
+
+math/gsurfit/gs_f1deval.gx
+	In the line:   call amulk$t (Mem$t[sx], 2., Mem$t[sx], npts)
+	The real constant "2." was changed to the generic form "2$f".  (5/6)
+
+sys/ki/irafks.x
+        The "task irafks = onentry" was incorrect since ONENTRY is an integer
+        function.  This was harmless since the purpose of the task statement
+        was merely to get an iraf main, but I set up a dummy t_irafks task
+        to avoid the type clash.  (5/6)
+
+pkg/cl/bkg.c
+	Static function bkg_close() used before being declared static.
+	Added a static function declaration to the file header.  (5/6)
+
+pkg/cl/debug.c
+	Same as above, function dd_f().  (5/6)
+
+pkg/cl/edcap.c
+	Same as above, function map_escapes().  (5/6)
+
+pkg/cl/pfiles.c
+	Same as above, function mapname().  (5/6)
+
+pkg/cl/cl.x
+	Same problem as in irafks, above.  ONENTRY is a function and should
+	not be referenced as a subroutine in the task statement.  Added a
+	dummy t_cl procedure to avoid the type clash.  (5/6)
+
+unix/hlib/login.cl
+	The line
+	
+	    if (access ("home$loginuser.cl") cl < "home$loginuser.cl"
+
+	causes the following statement to be ignored if the IF is true.
+	This is a CL bug, but for now the workaround is to add a null
+	statement ; to the line following the IF.  (5/6)
+
+pkg/cl/gram.c
+	dumpparams() modified to write to t_out instead of t_stdout.
+	ccdphot related experiment.  (6/21)
+
+------------------
+Rebuilt HSI with VOS facilities.  (7/19)
+Started build of NOAO packages.  (7/20)
+
+unix/hlib/irafuser.csh
+	Added "-Wl,-t" to the HSI_CF flags.  This gets rid of a linker
+	warning about xercom changing size.  (7/20)
+
+--------------------
+System upgraded to V2.10.  Started with the SunOS version of the system
+from tucana, merged A/UX stuff back in, which many minor changes.  (10/01)
+
+unix/hlib/irafuser.csh
+	Added -traditional to the GCC flags, to avoid some problems
+	in the A/UX system includes, probably introduced in the upgrade to
+	A/UX 2.0.1.  (10/02)
+
+lib/libex.a
+	After the sysgen I had to do a "ar ts" on this file to regenerate
+	the symbol table; not clear why this library and no other.  Until
+	the reason is clear, no action.  (10/02)
+
+	[This appears to be a bug in AR; it is failing to properly generate
+	[the symbol table for very large libraries.  A manual "ar ts" seems
+	[to fix the problem, but this bug will cause problems with a sysgen.]
+
+sys/gio/ncarutil/pwrity.f
+	Unused variable LEN on line 335.  (10/02)
+
+sys/gio/ncarutil/pwrzi.f
+sys/gio/ncarutil/pwrzs.f
+sys/gio/ncarutil/pwrzt.f
+	Variables HIGH,WIDE,WHITE, and LNGTH not used (same problem in
+	all three files).  (10/02)
+
+math/gsurfit/mkpkg
+	Contained a statement $ifeq (USE_GENERIC, YES) which was incorrect,
+	as a lower case "yes" is required since $ifeq uses a simple string
+	comparison.  (10/02)
+
+math/nlfit/nlzero.gx
+	Multiple problems; two calls to aclr had an extra argument, but
+	invalid pointer references too.  (10/02)
+
+mkpkg
+	The special file list wasn't being used; this was traced to the
+	use of a symbol link to the iraf root directory.  One cannot
+	reference the iraf root via a link or directory path comparisons
+	will fail.  (10/03)
+
+sys/fio/fntgfn.x
+	A pattern such as "*%" would match all filenames, a potentially
+	disastrous feature if used, say, to delete host filenames containing
+	the % character.  % is dangerous because it is just another character
+	in a unix filename, but in iraf it is one of the the pattern
+	matching metachacters (substring editing).  The filename template
+	code was modified to 1) require at least two unescaped % characters
+	in a pattern for the % to be recognized as a metacharacter, and
+	2) to allow the % character to be escaped (the code was supposed
+	to do this but it was only partially implemented).  (10/14)
+
+----------------------------------------------------------------------
+Summer 1992 - Mac system upgraded to A/UX 3.0.  New versions of F2C and GCC
+installed.  V2.10 upgrade resumed Oct 13-14 1992.  There were a number of
+minor changes most of which are probably not worth recording here.  The
+main changes were to "f77" and "xc".  f77 is a script in /usr/local/bin
+which calls f2c and gcc to act as a Fortran compiler.  This was tuned to
+improve the integration of f2c and gcc.  XC was modified to support gcc
+better, e.g. omit .o files from compiles to avoid annoying gcc warnings,
+use gcc rather than cc for linking, search the right directories, etc.
+The new version of GCC (2.2.1) is quite a bit changed from what I used
+last year.  I had to make one bug fix to cpp to get source level debugging
+to work for .f files compiled with f77/f2c/gcc.
+
+diff/merged the HSI and did a fresh bootstrap, pretty routine.  (10/13)
+installed and built tables and noao.  (10/13-14)
+diff/merged the DEV directory.  (10/14)
+
+unix/hlib/install
+	Changed the code which checks the ownership and permissions of alloc.e.
+	On a/ux, ls -l prints the group by default, and this was causing the
+	old string comparison to fail.  (11/21/92)
+
+unix/os/zfioks.c
+unix/os/zfiotx.c
+	Changed some TCSETAF ioctl's to TCSETAW ioctl's.  The TCSETAF ioctl
+	claims to flush the output buffer before changing the terminal driver
+	settings, but output data was being lost.  Using TCSETAW appears to
+	avoid this problem.   (01/13 1993)
+
+unix/hlib/iraf.h
+unix/hlib/libc/spp.h
+	Changed the values of INDEFR and INDEFD to the following.
+
+	    INDEFR	3.4e38 
+	    INDEFD	1.7d308
+
+	and IS_INDEFR and IS_INDEFD were changed to
+
+	    IS_INDEFR	(($1) > 3.3e38)
+	    IS_INDEFD	(($1) > 1.6d308)
+
+	This was necessary as the floating point equality tests used to
+	check for INDEF were failing using F2C/GCC.  (01/15 1993)
+
+math/iminterp/arbpix.x
+math/interp/arbpix.x
+noao/astutil/t_setairmass.x
+noao/digiphot/photcal/evaluate/phprint.x
+noao/mtlocal/cyber/cykeywords.x
+noao/mtlocal/cyber/t_ridsfile.x
+noao/onedspec/ecidentify/ecline.x
+noao/onedspec/irsiids/t_bswitch.x
+noao/onedspec/irsiids/t_flatdiv.x
+noao/onedspec/irsiids/t_flatfit.x
+noao/onedspec/irsiids/t_sums.x
+noao/twodspec/apextract/peaks.x
+noao/twodspec/multispec/fitclean.x
+noao/twodspec/multispec/fitsmooth.x
+noao/twodspec/multispec/intgauss5.x
+noao/twodspec/multispec/peaks.x
+noao/twodspec/multispec/solve.x
+noao/twodspec/multispec/t_fitfunc.x
+pkg/bench/xctest/lintran.x
+pkg/images/lib/sigl2.x
+pkg/images/tv/display/sigl2.x
+pkg/images/tv/iis/src/sigl2.x
+pkg/lists/lintran.x
+pkg/plot/crtpict/sigl2.x
+pkg/proto/t_imscale.x
+sys/clio/clgeti.x
+sys/clio/clgetl.x
+sys/clio/clgetr.x
+sys/clio/clgets.x
+sys/clio/clglpi.x
+sys/clio/clglpl.x
+sys/clio/clglpr.x
+sys/clio/clglps.x
+sys/clio/clputi.x
+sys/gio/calcomp/t_calcomp.x
+	The above files were modified to replace "equals-INDEF" style
+	constructs with "IS_INDEF" constructs.  (01/15)
+
+unix/hlib/install
+	Added a number of "rm -f $TEMP" statements to delete any old $TEMP
+	files before attempting to create new ones.  (2/01)
+
+unix/os/zzstrt.c
+        Added #ifdef AUX code to enable the IEEE exceptions in the 68882.
+        There is no A/UX support for this so it had to be done in assembler
+        by writing to the FP control register.  (3/09 1993)
+
+unix/os/zxwhen.c
+        Added #ifdef AUX code to decode SIGFPE and print error messages
+        appropriate to the exception.  There is no A/UX support for this so
+        it was necessary to write assembler to read the FP status register
+        and test which exception occurred.  (3/09)
diff --git a/doc/ports/notes.aix b/doc/ports/notes.aix
new file mode 100644
index 00000000..203cff47
--- /dev/null
+++ b/doc/ports/notes.aix
@@ -0,0 +1,456 @@
+# Begin AIX IRAF configuration.  30Mar91.
+# RS/6000 Model 530, deskside, 24 Mb RAM 355+670 Mb disk, 24bit color.
+
+# lslpp -h bos.obj says the following.  This means our current OS is
+# 3001.  From the net I see that the latest release is 3003, so we
+# are a bit behind.  Also, the system was configured on 19-20 Sep 90.
+
+Option Name          State      Event      Date/Time Release         User Name
+-------------------- ---------- ---------- --------- --------------- ----------
+bos.obj              INACTIVE   COMMIT     02/02/90  03.01.0000.0000 root
+                     INACTIVE   APPLY      09/19/90  03.01.0001.0003 root
+                     ACTIVE     COMMIT     09/19/90  03.01.0001.0003 root
+
+unix/as
+unix/as.rs6000			+
+unix/bin
+unix/bin.rs6000			+
+	Set up AS and BIN directories for the machine architecture "rs6000.
+	(3/30)
+
+unix/as.rs6000/zsvjmp.c		+
+unix/os/mkpkg.sh
+unix/os/mkpkg
+	It won't be easy to generate the assembler version of zsvjmp.s for
+	the RS6000, so I set up a C version temporarily just to get things
+	to link.  The AIX CC doesn't have a -S flag and neither the AIX
+	assembler or architecture is simple, so it will take some work to
+	generate the assembler version.  (3/30)
+
+unix/hlib/libc/iraf.h
+	Set the iraf root to point to /u1/iraf.  (3/30)
+
+unix/hlib/config.h
+unix/hlib/libc/spp.h
+	Checked that LEN_JUMPBUF was big enough for this machine; it wasn't,
+	had to increase it from 64 to 65.  (3/30)
+
+unix/hlib/irafuser.csh
+unix/hlib/mkiraf.csh
+unix/hlib/fc.csh
+unix/hlib/cl.csh
+	Made changes to reflect the new iraf root and architecture.  (3/30)
+
+unix/shlib/mkpkg.sh
+unix/gdev/sgidev/mkpkg.sh
+unix/boot/rmfiles/mkpkg.sh
+unix/boot/mkpkg/mkpkg.sh
+unix/boot/rmbin/mkpkg.sh
+unix/boot/bootlib/mkpkg.sh
+unix/boot/wtar/mkpkg.sh
+unix/boot/generic/mkpkg.sh
+unix/boot/spp/mkpkg.sh
+unix/boot/spp/rpp/mkpkg.sh
+unix/boot/spp/rpp/rppfor/mkpkg.sh
+unix/boot/spp/rpp/ratlibc/mkpkg.sh
+unix/boot/spp/rpp/ratlibf/mkpkg.sh
+unix/boot/spp/xpp/mkpkg.sh
+unix/boot/xyacc/mkpkg.sh
+unix/boot/rtar/mkpkg.sh
+unix/os/mkpkg.sh
+	Replaced all the "cc" calls by $CC, the "f77" calls by $F77, and the
+	"ranlib" calls by $RANLIB.  (3/30)
+
+unix/hlib/irafuser.csh
+	Set the architecture (MACH) to rs6000.  Added definitions for CC, F77,
+	RANLIB.  (3/30)
+
+---------------
+Begin bootstrap attempts.  (3/30)
+
+unix/os/mkpkg.sh
+	Changed the "rm alloc.o" to "rm -rf alloc.o".  The AIX CC doesn't
+	leave the .o file behind.  (3/30)
+
+unix/hlib/irafuser.csh
+	Added compile time switches -D_BSD -D_NO_PROTO -D_BSDINCLUDES to
+	make the port go a little easier.  (3/30)
+
+unix/os/zfiomt.c
+	AIX has modified the unix tape interface as follows: 1) mtio.h is
+	not tape.h, 2) MTIOCTOP is STIOCTOP (ST = streaming tape), 3) struct
+	mtop is struct stop, 4) all the MTfoo ioctls are now STfoo, 5),
+	BSF/BSR are RSF/RSR.  Other than that things look very much the
+	same, just a few gratuitous name changes.  (3/30)
+
+unix/os/zfiopl.c
+unix/os/zfiolp.c
+	AIX CC insists that initializers be enclosed in { }.  Added brackets
+	to the initializers for the variable xnullstr in these two files.
+	(3/30)
+
+unix/os/zgtime.c
+unix/hlib/libc/kernel.h
+	Changed the macro define HZ to CLKFREQ.  The former is defined in
+	AIX and was causing a redefined symbol warning.  (3/30)
+
+unix/os/zxhwen.c
+	Modified the fcancel macro for the AIX stdio.h.  (3/30)
+
+AIX
+	1. The problem with pwd hanging the process in an infinite loop
+	recurred.  Once this happens any pwd will hang.  Evidently the only
+	way to clear the problem is to reboot.
+	2. Once a task hung and after a while I get an error message about
+	an NFS timeout, server felis not responding.  felis is the system I
+	am working on, the file access should be direct rather than NFS.
+	(3/31)
+
+unix/os/zwmsec.c
+	AIX likes signal handers to be declared type void rather than int.
+	Changed the #ifdef SUNOS4 to #ifdef _AIX.  (3/31)
+
+unix/boot/spp/rpp/ratlibc/ratdef.h
+	Removed the trailing underscores from all the Fortran callable C
+	externals.  AIX C and Fortran externals share the same name space
+	and both are preceeded by a leading period (rather than underscore)
+	in the host level symbol table.  (3/31)
+
+unix/hlib/libc/libc.h
+unix/hlib/libc/knames.h
+unix/hlib/libc/xnames.h
+	Same as above.  (3/31)
+
+unix/hlib/libc/setjmp.h
+	Commented out some SunOS #pragma stuff.  (3/31)
+
+unix/mkpkg.sh
+	Commented out shared library stuff.  (3/31)
+
+unix/hlib/libc/knames.h
+	Restored the trailing underscore to ushlib_,vshlib_,vshend_ to avoid
+	a name conflict on vshlib in zzstrt.c.  Since these are not Fortran
+	generated externals we can have a trailing underscore or not as we
+	wish.  (3/31)
+
+unix/boot/mkpkg/scanlib.c
+	AIX uses COFF libraries (actually something called extended COFF)
+	but for some reason they changed the <ar.h> symbols ARMAG, SARMAG,
+	and SARAMAG to AIAMAG, SAIAMAG, and SAIAAMAG (they changed the R to
+	IA in each name).  It was not clear what was the reason for this
+	change.  A perhaps more justifiable one was that ar_fmag and ar_name
+	are now elements of the union _ar_name.  With these changes the file
+	at least compiles.  (3/31)
+
+unix/os/irafpath.c
+	Added #ifdef _AIX conditional to cause bin.rs6000 to be searched.
+	(3/31)
+
+unix/boot/spp/xc.c
+	Modified for AIX.  The fortran compiler is xlf, host libraries are
+	-lxlf, -lm, [-lbsd].  Default no shared library (yet).  (3/31)
+
+unix/hlib/iraf.h
+	Bitwise intrinsic functions are AND,OR,NOT,XOR (same as SPP!) no
+	changes needed.  (3/31)
+
+unix/hlib/mach.h
+	An "od" test appears to indicate that the RS6000 byte ordering is
+	big-endian (same as Sun) so no byte swapping needed.  (3/31)
+
+AIX
+	The system IS pretty fast - only takes about 10min for a bootstrap.
+	(3/31)
+
+unix/hlib/install
+	1. Added #!/bin/csh at the top of the file.  The default root shell
+	is ksh and ksh was trying to exec the file.
+	2. Commented out the line with `mach` and added one set to rs6000.
+	3. Uncommented the exit 0 to skip the Suntools stuff.  (3/31)
+
+---------------------------
+Start sysgen attempts.  (3/31)
+
+unix/boot/spp/xpp/decl.c
+	XLF cannot compile integer*[2|4] functions (types char, short, and
+	long in SPP).  Upon enountering a routine declared, e.g.,
+
+		integer*4 function foo (args)
+
+	the compiler returns the message
+
+	        1.17   1514-105: (S) Variable functionfoo was declared as
+		array of type OBJECT-TIME.  This type of array is not
+		permitted in a main program.
+		1516-036: (S) Variable foo has undefined type.
+
+	this only happens for integer*2 and integer*4 functions.  The
+	Fortran manual states that only integer functions are allowed
+	(excluding the other types such as real etc.).  The compiler is
+	clearly treating the declaration as that of a variable rather
+	than a function.
+
+	This is potentially a very serious problem - we may not be able to
+	use integer*2 if it is not fully implemented.  As a workaround I am
+	going to try modifying the preprocessor to declare all integer-like
+	(char,short,int,long) functions as type integer.  This should
+	almost work, but will probably fail at runtime if char or short
+	functions are passed in the argument list to another procedure.
+	(3/31)
+
+unix/boot/mkpkg/scanlib.c
+	The archive file changes for AIX turned out to be far more extensive
+	than mere name changes, and I ended up spending several hours
+	figuring out how AIX archives work and rewriting this file.  A major
+	misconception that it took me some time to get over was that AIX
+	archives have a linked list of members, whereas UNIX systems have
+	a sequential list of members.  You HAVE to follow the links.  (3/31)
+
+AIX
+	The AIX implementation of symbolic links is funny, or at least the
+	"ls" task is.  A while back I had to add the -L flag to ls to get
+	it to list directories pointed to by symbolic links, but with that
+	flag set it will always follow links, and a command such as "ls -l"
+	on a link lists the pointed to file, not the link.  So far I have
+	not figured out how to get it to behave like "other" unix systems I
+	am familiar with (it is not clear AIX is really a unix variant so
+	I am not sure the "other" is accurate).  (3/31)
+
+unix/gdev/iism75/zrdm75.x
+	Towards the end of the file there were a couple of calls to MOD
+	with mixed type arguments (short and int).  It was necessary to
+	add an INT to the short arguments to make both argments integer
+	before XLF would accept the statements.  (3/31)
+
+-----------------
+Completed the first sysgen, although with many errors which I haven't begun
+to check out yet.  This thing IS fast - the full core system sysgen took
+only 2:26.  (4/1)
+
+AIX
+	A funny thing about the initial sysgen is that it produced libraries
+	and executables even in cases where there were serious errors.  This
+	may be big system policy (VMS is like this too to some extent) but
+	it is not standard for unix.  It causes problems because the objects,
+	even though broken, were produced with recent file, dates which
+	causes utilities like make/mkpkg to be useless for recompilation
+	following errors.  Maybe I can find a way around this but I shouldn't
+	have to.  (4/1)
+
+unix/hlib/iraf.h
+unix/hlib/libc/xnames.h
+	Added definitions to map the VOS name "getpid" to "xgtpid" at the
+	host library level.  On AIX Fortran and C names share the same name
+	space, and a name collision on getpid was causing infinite recursion.
+	(4/1)
+
+pkg/system/help/lroff/textout.x
+	This file failed to compile due to a complaint about the declaration
+	for the argument out to the ENTRY point textout.  Rather than look
+	into this I installed a version of the file from the AUX port which
+	eliminates the entry point, and the problem went away.  (4/1)
+
+dev/hosts
+	Added columba to hosts table.  (5/22/91 SRo)
+
+-------------------------------------
+Begin AIX/IRAF update to V2.10.  (8/10/92)
+AIX version 3.2.2.  Fortran version 2.2.
+
+unix/as.rs6000/zsvjmp.s
+	Added the RS/6000 version of zsvjmp.s.  It took over a day to learn
+	how to program in assembler on this machine (do to limited and
+	misleading documentation and tools) and about 20 minutes to write the
+	routine...  (8/09)
+
+-------------------------------------
+Performed a diff/merge of the HSI and merged changes into the V2.10 HSI.
+The bootstrap proceeded with only minor problems.  Started sysgen.  (8/10)
+
+unix/hlib/mkpkg.inc
+	Still tuning default fortran compilation switches.  Current set is
+	as follows: "-/qhalt=e -/qflttrap -/NQ20000".  (8/10)
+
+sys/gio/gki/gkiclosews.x
+	In the call to zcall2, "Mems[...]" was changed to "Mems[gki+...]".
+	(8/10)
+
+sys/imio/imsetr.x
+	There were a couple of occurrences of IM_PLFLAGS(im) where the (im)
+	was missing.  (8/10)
+
+lib/plio.h
+sys/plio/*
+	Assorted changes to resolve type clashes; see notes above from
+	original port.  (8/10)
+
+sys/qpoe/qpiomkidx.x
+	Type clash in two calls to min, referencing type short field of
+	bucket header.   (8/10)
+
+sys/mwcs/mwtransd.x
+	The AIX compiler did not like a "... * -ltv_1[i]" expression, had to
+	put parens around the -ltv_1[i] term.  (8/10)
+
+sys/vops/fftx.f
+	This routine contained a declaration "x(2), y(2)" where the arrays
+	X,Y are of arbitrary length.  Later on in the code the third and
+	fourth elements of each array were referenced and this caused a
+	compiler message about an incorrect constant array subscript.
+	Changed the declaration to "x(*), y(*)".  (8/10)
+
+sys/gio/ncarutil/agdflt.f
+sys/gio/ncarutil/agdash.f
+sys/gio/ncarutil/aglbls.f
+sys/gio/ncarutil/agsetp.f
+	The AIX compiler doesn't like the CHARACTER*504 declarations in these
+	files.   Had to change these to CHARACTER*500 to get the files to
+	compile.  That could be incorrect, but IRAF doesn't use this code
+	anyhow (but we will keep it around until the ncar stuff is phased
+	out).  (8/10)
+
+pkg/images/tv/display/iisofm.x
+	Added the "int" in "max (int(y[i]),..." to fix a type clash.  (8/10)
+
+pkg/images/tv/iis/ids/idsinit.x
+	Fixed a type clash in two calls to MIN.  (8/10)
+
+pkg/images/tv/iis/iism70/iissplit.x
+	Another type clash in a call to MIN.  (8/10)
+
+pkg/images/tv/imexamine/iejimexam.x
+	Type clash - same one as seen earlier on cephus with the DEC
+	compiler.  (8/10)
+
+pkg/images/imarith/iccclip.x
+pkg/images/imarith/icsclip.x
+pkg/images/imarith/icstat.x
+pkg/images/imarith/icaclip.x
+	More type clashes, again the same as seen on cephus.  (8/10)
+
+pkg/plot/t_gkidir.x
+	Another short/int type mismatch for MIN (that has been that way since
+	the dawn of time).  (8/11)
+
+noao/lib/mkpkg.inc
+noao/lib/mkpkg.sf.AIX3		+
+	Added artdata/t_mkechelle.x and astutil/t_gratings.x to the NOAO
+	package special file list.  These files have to be compiled with the
+	optimizer turned off on the RS/6000 or the compiler generates the
+	following message.
+
+	    1500-008: (S) COMPILER LIMIT EXCEEDED in astgrg: Program too
+	    complicated to be compiled. Compilation ended. Reduce the
+	    complexity of the program and recompile, or lower the level of
+	    optimization and recompile.
+	(8/11)
+
+noao/digiphot/daophot/daolib/erf.x
+noao/digiphot/daophot/daolib/dpevalpsf.x
+noao/digiphot/daophot/psf/dpgaussfit.x
+noao/digiphot/daophot/psf/dpsubgauss.x
+noao/digiphot/daophot/psf/dpwritepsf.x
+	This code defines and uses a function called ERF, but ERF is a
+	Fortran intrinsic function (at least on the IBM compiler).  Changed
+	the name to DAOERF.  (8/11)
+
+noao/onedspec/dispcor/refgspec.x
+	Mixed real/double in call to MOD.  (8/11)
+
+noao/onedspec/splot/fixx.x
+noao/onedspec/shdr.x
+noao/onedspec/t_deredden.x
+	Type clashes in intrinsics, already found and fixed on decstation.
+	(8/11)
+
+noao/onedspec/t_deredden.x
+	This file had another problem on the RS/6000 - syntax error in
+	expression.  Had to add parens in "y * (-2.09002)".  (8/11)
+
+noao/rv/coloncmds.x
+	The IBM compiler (like the decstation) also complained about cmd_write
+	being a function but no value was being returned.  (8/11)
+
+noao/rv/fftutil.x
+	The IBM compiler generated the following messages for this file:
+
+	    1514-047: (S) No initializations for this DATA statement will be
+	    done because of presence of syntax error.
+	    1515-019: (S) Syntax is incorrect.
+
+	Evidently this was due to the use of the name "data" for an argument
+	to the procedure fft_fixwrap.  There was nothing wrong with the code,
+	the compiler was in error in this case.  To workaround the problem
+	I changed the name of the data vector "data" to "v" in fft_fixwrap
+	and in the previous procedure.  (8/11)
+
+noao/imred/ccdred/src/icstat.x
+	Type mismatch problems, already run into on cephus.  (8/11)
+
+noao/imred/vtel/mscan.x
+	The function mtneedfileno() was declared boolean but used as an integer
+	function (which it is).  (8/11)
+
+unix/os/zzstrt.c
+unix/os/zxwhen.c
+	Added #ifdef _AIX code to these routines to enable and handle the
+	IEEE exceptions.  This is quite difficult on the RS/6000, compared
+	to most systems.  There really aren't any IEEE exceptions on this
+	machine.  To catch things like floating divide by zero it is necessary
+	to compile code -qflttrap, which causes a test-and-branch and trap
+	instruction to be compiled in line *after every floating point
+	instruction*.  If the floating instruction overflows, underflows,
+	or whatever, the branch will be skipped and the application generates
+	a SIGTRAP.  The ex_handler routine in zxwhen gets called by the trap.
+	At that point the floating point status register can be examined to
+	determine what "exception" occurred.  This appears to work but I
+	am still a bit uncomfortable about all this; the IBM documentation
+	is not very definitive and thus far I am unable to determine exactly 
+	how the RS/6000 hardware works (e.g., no where does it say exactly
+	what happens when, for example, floating underflow occurs).  (8/11)
+
+unix/boot/mkpkg/scanlib.c
+	While relinking the CL to test the exception handling code I noticed
+	a problem with mkpkg not reading the libpkg.a file.  This was traced
+	to a problem in scanlib.c, used to read AIX archive files.  The code
+	assumed that the first library member followed the file header.  This
+	is normally, but not always the case.  In reality the library member
+	list is a linked list and the offset to the list head is stored in
+	the file header.  (8/12)
+
+unix/hlib/mkpkg.sf.AIX3
+	I had a lot of trouble getting the integer divide-by-zero exception
+	to work.  Finally I determined (by studying assembled code with adb,
+	not from the info-hider) that the compiler needs to generate extra
+	instructions to check for a divide by zero.  The Fortran compiler
+	does this by default but the C compiler does not.  Studying the
+	C compiler documentation I could not find a switch to enable this
+	option, but fortunately a query to usenet revealed that "-qcheck"
+	was what I was looking for.  I inserted this in hlib$mkpkg.inc and
+	tried to rebuild the CL and got a number of messages such as the
+	following.
+
+	compile.c:
+	*** PROGRAM ERROR *** No OTHERWISE or WHEN for execution in SELECT...
+	*** PROGRAM ERROR *** No OTHERWISE or WHEN for execution in SELECT...
+	*** PROGRAM ERROR *** No OTHERWISE or WHEN for execution in SELECT...
+	cc: 1501-230 Internal compiler error; please contact your IBM repr...
+
+	Obviously some sort of compiler bug (C doesn't have these statements).
+	The workaround was to add only unop.c and binop.c, the CL files that
+	evaluate arithmetic expressions in scripts, to mkpkg.sf.AIX3.
+	Fortunately these files compile without the error messages.  (8/12)
+
+unix/os/zgcmdl.c
+	Modified this file to pick up the argument list on AIX systems.
+	There is no portable way to do this, one does it by linking an
+	executable and studying the symbol table with nm and adb, looking
+	for something which will give the address of the argument list.
+	So far every system has proved to have a way to do this (on AIX
+	there is a symbol called p_argv).  (8/12)
+
+unix/os/alloc.c
+	AIX magtape devices have names like "rmt.1", so I had to change
+	the code which checks for simple filenames to permit period.
+	This still excludes names like ../path, since / is not permitted.
+	(10/17)
diff --git a/doc/ports/notes.convex b/doc/ports/notes.convex
new file mode 100644
index 00000000..d6582383
--- /dev/null
+++ b/doc/ports/notes.convex
@@ -0,0 +1,761 @@
+Begin V2.8 CONVEX/IRAF BETA port, 6-8 August 1989.
+See also notes from October 1987 ALPHA port (appended).
+-------------------------------------------------------
+
+Summary:
+	Installation of V2.8 was straightforward except for a nasty bug
+	involving the host routine BCOPY.  I originally tried to use the
+	C code versions of AMOVC etc. (installed in AS).  This caused the
+	system environment list to become mangled, due to BCOPY modifying
+	the data it was copying during a copy used to shift by one char
+	to align the buffer in a REALLOC of the environment buffer.  The
+	speculation is that the BCOPY uses vector instructions, and if the
+	input and output arrays are aligned to within less than one vector
+	register length data can be corrupted due to the whole vector
+	segment being copied at once.
+
+	Aside from that, things came up fine.  There were several compiler
+	crashes with core dumps, but all but one of these were a result of
+	problems with the IRAF code or system configuration.  In general
+	the compiler seems to be in much better shape than during the
+	alpha port.
+
+	The final system is configured as follows: the HSI is generic (no
+	floating point, can run on any Convex), and two architectures are
+	supported, IEEE and NATIVE, corresponding to the two floating point
+	architecture options available for the Convex.
+
+	Detailed notes on the modifications made to port V2.8 BSD/IRAF follow.
+
+unix/as.convex/
+unix/as.convex/zsvjmp.s
+unix/bin.convex/
+	Added AS and BIN directories to the HSI for the Convex.  Installed
+	the zsvjmp.s written for the alpha port.
+
+unix/boot/bootlib/osputenv.c
+	Commented out the call to putenv() - there is no comparable facility
+	on the Convex.
+
+unix/boot/spp/mkxc.sh
+	Fixed a bug - the call to CC was not referencing $HSI_CF.
+
+unix/boot/spp/rpp/rppfor/declco.f
+	Replaced by a version that enables IMPLICIT NONE, which is how
+	undeclared variable detection is handled by the Convex compiler.
+
+unix/boot/spp/rpp/ratlibf/mkpkg.sh
+unix/boot/spp/rpp/rppfor/mkpkg.sh
+	Replaced the F77 by FC, the Convex fortran compiler.  There is no
+	F77 on the Convex.
+
+unix/boot/spp/xc.c
+	1. Replaced all F77 references by FC.
+	2. The link library list for the Convex is
+		-lF77 -lI77 -lD77 -lm -lmathC1
+	3. Modified the list of directories searched by sys() (for XPP and
+	RPP) to include /local/bin, /usr/local/bin, and /iraf/local/bin.
+	Merely another hack until the problem is fixed properly.
+	4. Modified the list of directories searched by run() (for FC) to
+	include /usr/convex, which is where FC resides on the Convex
+	(another hack until the problem is properly resolved).
+
+unix/boot/spp/xpp/xppcode.c
+	This HSI file turned out to have code in it (for converting HMS to
+	decimal floating) that used floating point.  Replaced by an
+	equivalent routine which uses only integer calculations.
+
+unix/hlib/iraf.h
+	The bitwise intrinsics for the Convex are IAND, IOR, IEOR, and NOT.
+
+unix/hlib/i1mach.f
+unix/hlib/r1mach.f
+unix/hlib/d1mach.f
+	Replaced by the Sun versions.
+
+unix/hlib/mkpkg.sf.CX
+noao/lib/mkpkg.sf.CX
+	Added special file lists for the Convex.  At present there is only
+	one special file, images$geometry/geofit.x, which has to be compiled
+	at O1 due to a fortran compiler bug.
+
+unix/hlib/irafuser.csh
+unix/hlib/libc/iraf.h
+unix/hlib/libc/libc.h
+unix/hlib/mkiraf.csh
+unix/hlib/mkpkg.inc
+unix/hlib/motd
+	Routine changes for the Convex.  Added a #define CONVEX to <iraf.h>.
+	MACH is set to `convex' in the irafuser.csh.  The HSI flags are
+
+	    setenv	HSI_CF	"-O -fx"
+	    setenv	HSI_FF	"-sa -fx -O0 -na -nv -nw"
+	    setenv	HSI_XF	"-q -/sa -/fx -/O0 -/na -/nv -/nw -z"
+
+	The MKPKG flags for the IEEE architecture are
+
+	    $set	FLOAT	= "fi"
+	    $set	XFLAGS	= "-c -q -/sa -/fi -/O2 -/na -/nw -/nv"
+	    $set	XSFLAGS	= "-c -q -/sa -/fi -/O1 -/na -/nw -/nv"
+	    $set	XVFLAGS	= "-c -q -/sa -/fi -/O2 -/na -/nw"
+	    $set	LFLAGS	= "-z -/fi"
+
+	and similarly for the NATIVE (Convex floating point) architecture.
+
+unix/os/getproc.c
+	This file, part of the tape drive allocation code, would not compile
+	on the Convex (it reads the kernel process table which is fairly
+	system dependent).  Commented out the offending code (a status value
+	is returned indicating that the user does not have any processes)
+	until the tape drive allocation problem can be resolved for the
+	Convex.
+
+unix/os/irafpath.c
+	Modified to look for files in unix/bin.convex if the machine type
+	is convex.
+
+unix/os/zxwhen.c
+	Added FPE hardware signal codes from <signal.h>.
+
+mkpkg
+noao/mkpkg
+bin.ieee/
+bin.native/
+noao/bin.ieee/
+noao/bin.native/
+noao/lib/mkpkg.inc
+unix/hlib/cl.csh
+unix/hlib/mkpkg.inc
+	Configured the system for two architectures, IEEE and NATIVE,
+	corresponding to the two floating point options on the Convex.
+	The HSI is compiled generic (no floating point dependencies),
+	hence is runnable on either type of Convex.
+
+dev/pix.imh
+dev/pix.pix
+dev/vdm.gki
+	Installed versions for the Convex (IEEE architecture only!).
+
+sys/gio/nspp/sysint/encd.f
+	Fixed a bug in this file - this was fixed once before but evidently
+	never got merged back into the master system.  The problem is the
+	statement
+
+	    if (len (char (ns + ichar ('0'))) .eq. 2) then
+
+	which is evidently unnecessary and which makes an illegal or at
+	least very questionable use of CHAR.
+
+sys/gio/ncarutil/sysint/ishift.x
+sys/gio/nspp/sysint/ishift.x
+	Commented out the code for IAND and IOR, since these are intrinsic
+	functions in Convex/Fortran.
+
+unix/hlib/install
+	Changed the machine type from `vax' to `convex'.
+
+----------
+Basic BETA port completed.  (8/8)
+
+----------
+August 8-10: on site at the VLA testing IRAF on the VLA system, which
+includes two Convexes (plus some Suns and VAXes).
+
+dev/devices
+	Configured for the Convex.  (8/11)
+
+unix/hlib/login.cl
+	Added EDT and EMACS as foreign tasks to the default USER package.
+	(8/11)
+
+unix/as/zsvjmp.s
+	An IMAGES task failed during testing while trying to create a type
+	DOUBLE image, indicating that the MEM common was not double word
+	aligned.  I was able to fix this by setting the symbol __mem_ (the
+	mem common) to the absolute value 0, which not only double word
+	aligns the common, it aligns it to any size, and simplifies 
+	debugging by arranging for SPP pointers to directly index process
+	virtual memory.  This technique (setting __mem_ to zero) did not
+	work for the Convex back when the alpha port was attempted.  (8/12)
+
+	[Postscript]  Setting mem to zero evidently was the cause of a
+	number of mysterious program crashes that occurred once the system
+	was relinked with the new zsvjmp.o with mem=0.  The problems went
+	away when things were relinked with the mem=0 commented out,
+	indicating that the mem=0 was the problem.  There was not time
+	to check this out, but my guess is that since on the Convex program
+	memory begins at 0x80000000, setting mem=0 causes very large pointer
+	offsets which can overflow to negative integer values.  I changed
+	zsvjmp.s to set mem=0x80000000 and the problems seem to have gone
+	away, and we still get double word alignment.  (8/13)
+
+unix/hlib/ic.csh +
+unix/hlib/install
+unix/hlib/login.cl
+unix/boot/spp/xc.c
+	Had problems getting IMFORT programs to link.
+	1. The solution was to modify XC (FC) to link against the Convex
+	library -lU77 when linking a host program.  This can only be done
+	when XC is called with the -h flag as the library will result in
+	a multiply defined loader error message if searched when linking
+	an SPP program.
+	2. The iraf foreign task FC now calls a new cshell script ic.csh,
+	which calls XC after first determining the floating point option
+	switch required to link IMFORT programs so that they are consistent
+	with IRAFARCH.  For example, if Convex/IRAF is running the IEEE
+	binaries, XC will be called with -/fi.
+	3. Modified the install script to make a link for ic.csh.  The new
+	task name stands for imfort-compile, and is not called FC because
+	that is the Convex Fortran compiler.  Possibly FC should not be
+	used as the command name in the USER package either, but I did
+	not want to change that as it is shown as FC in all the user
+	documentation.  (8/12)
+
+unix/hlib/cl.csh
+	Modified to define IRAFARCH if not already defined.  (8/12)
+
+unix/os/alloc.c
+	Modified to support the Convex tape allocation facilities.  Uses
+	the Convex TPALLOC and TPDEALLOC utilities to perform the actual
+	tape allocate/deallocate.  As a result, alloc.e no longer needs
+	to have suid-root, although the install script will still install
+	it that way.  Verified that local as well as remote network
+	allocation works.  (8/12)
+
+pkg/images/imarith/imcmode.gx
+	IMCOMBINE would fail when presented with a section containing pixels
+	that all had the same value.  The program would go into an infinite
+	loop in the code at the end of imcmode.gx.  Modified to avoid a
+	floating point equality test, and to add some limit checking in
+	a couple of places to avoid infinite looping.  (8/13)
+
+unix/hlib/mkfloat.csh
+	1. While using "mkpkg [ieee|generic]" etc. on teh Convex, the message
+	"usage: rm -[rif]" would sometimes appear.  This turned out to be due
+	to calling rm with a null file list when restoring from generic.
+	The fix was to to delete the file list file in the same command
+	which deletes the listed files, ensuring that there is at least
+	one file in the command.
+	2. Also reorganized the code somewhat to use only one RMBIN rather
+	than two, which speeds it up by a factor of two.  (8/14)
+
+unix/os/zmaloc.c
+	IMFORT programs would die on a memory allocator error: this was
+	traced to the fact that the custom memory allocator used for
+	BSD4.3/IRAF was still present in Convex/IRAF (which was built from
+	the BSD version).  Commented out the memory debug code in zmaloc.c
+	and all was well.  We will leave the applications relinked with the
+	custom memory allocator in for now, since they have already been
+	tested and did not show any problems.  (8/14)
+
+----------
+ALPHA port notes follow.
+
+CONVEX/IRAF Port.  D.Tody, beginning 26 October 1987.
+Using machine in Greenbelt, MD, as follows:
+-----------------------------------------------------------------------------
+	*********************************************************
+                        WELCOME  TO  C1EAST
+	*********************************************************
+	SYSTEM MANAGERS:  BRIAN CHRISTIANSON & DALE LANCASTER
+
+C1EAST  IS  A  CONVEX  C1-XP  MINI-SUPERCOMPUTER.
+
+	-  128 MEGABYTES OF PHYSICAL MEMORY 
+	-  1.5 GIGABYTES OF DISK SPACE
+	-  40 MFLOPS PEAK PERFORMANCE
+
+C1EAST IS CONFIGURED WITH:
+
+	-  25.6 MEGABYTES OF DISK BUFFER CACHE
+	-  64 USER SYSTEM
+	-  ETHERNET
+	-  IMAGEN LASER PRINTER
+
+	-  4.2 BSD UNIX, CONVEX RELEASE 6.1.1
+	-  VECTORIZING FORTRAN VERSION 3.0 
+	-  VECTORIZING C VERSION Beta 2.0 (vc 1.0 is still around)
+	-  ANSYS VERSION 4.2
+-----------------------------------------------------------------------------
+
+Snapshot of V2.6 IRAF restored to disk (/extra/iraf) by Convex.  (10/26)
+Logged in via modem, took a look at Convex/UNIX, configured the IRAF login.
+
+unix/as -> unix/as.vax
+unix/as/zsvjmp.s
+	Renamed the VAX assembler directory, and set up a new one for the
+	Convex.  Wrote ZSVJMP/ZDOJMP for the Convex.  This took a while,
+	and was one of the harder ones I have done, as the architecture and
+	the C setjmp/longmp are complex.  The machine has a RISC architecture
+	but nonetheless is fairly complex (and fast and expensive).  (11/2)
+
+unix/os/zxwhen.c
+	Modified the hardware specific exception codes table for the Convex.
+	In the process of doing this, discovered that the old code assumed
+	that hardware codes were distinct, while in fact they can be
+	numbered similarly for different signals.  Modified the ZXGMES
+	routine to work with hardware codes of the form SIGNAL+HWCODE rather
+	than the old HWCODE.  (11/2)
+
+unix/boot/spp/rpp/ratlibf/mkpkg.sh
+unix/boot/spp/rpp/rppfor/mkpkg.sh
+	Replaced "f77" by "fc".  (11/2)
+
+unix/hlib/irafuser.csh
+	Added an "-sa" flag for fc (the Convex Fortran compiler).  This flag
+	prevents static compilation of argument lists and is necessary if C
+	code is to be called from Fortran.  (11/2)
+
+unix/hlib/libc/spp.h
+unix/hlib/libc/libc.h
+unix/hlib/libc/iraf.h
+	Replaced the vax spp.h by the Sun version, which should be good
+	enough for now, and may even be correct (Convex evidently supports
+	IEEE floating as well as their native (Cray?) format).  Modified
+	the Fortran COMMON external names in libc.h to add the extra
+	leading underscore, used by the Convex Fortran compiler to make
+	common external names distinct from other Forran externals.
+	Edited the iraf.h file for the new $iraf (= /extra/iraf).  (11/2)
+
+unix/hlib/motd
+	Modified logo for the Convex.  (11/2)
+
+-------------------------------------
+Started up a bootstrap of the HSI.  This completed without incident, except
+for a great many copies of the following warning messages from FC:
+
+	Obsolete flag '-O' - flag '-no' assumed.
+	fc: Warning on line X of Y.f: label defined but never referenced.
+
+Modified HSI_FF (fc flags) in hlib$irafuser.csh to "-O1 -sa -nw" and repeated
+the bootstrap starting in the SPP directory.  This worked, but now the
+optimizer was enabled, and it helpfully produced a zillion of the following
+advisory messages:
+
+	fc: Advisory on line X of Y.f: more optimization is possible if this
+	function call has no side effects.
+
+Changed the flags to "-O1 -sa -nw -na" to fix this.  Tested the main HSI
+tasks (rmbin, rtar, wtar, mkpkg, xpp, rpp) and they all passed basic tests!.
+(11/2)
+
+unix/hlib/i1mach.f
+unix/hlib/d1mach.f
+unix/hlib/r1mach.f
+	Installed the versions for the Sun (IEEE floating etc.) for now.
+	This will probably need to be tweaked later.  (11/3)
+
+unix/hlib/iraf.h
+	Modified the name mappings for the bitwise intrinsic functions (and,
+	or, etc.).  For the Convex they are the same as in VMS Fortran.
+	Set values of INDEFR and INDEFD, as below.  (11/3)
+
+unix/boot/spp/xpp/xppcode.c
+	Changed the Fortran mappings of the SPP "char" and "short" type
+	coercion functions to "int2", which is implemented on the Convex.
+	(11/3)
+
+unix/boot/spp/xpp/decl.c
+	Convex Fortran supports IMPLICIT NONE, so I modified the code which
+	processes a procedure declaration to output this statement.  (11/3)
+
+unix/hlib/mach.h
+	Modified the values of various numeric constants.  The max exponent
+	for real is 38, for double is 307.  The INDEF values were modified
+	slightly.  The EPSILON values were very similar to those for the Sun.
+	Byte swapping is no - most significant byte first.  (11/3)
+
+unix/hlib/mkpkg.inc
+	Set the default compiler flags as follows:
+
+		XFLAGS	= "-cq -/O2 -/nw -/na -/nv"
+		XSFLAGS	= "-cq -/O1 -/nw -/na -/sa"
+		XVFLAGS	= "-cq -/O2"
+
+	I have added a new global flag variable XSFLAGS, to be used for the
+	VOS routines, i.e., for pure system code.  XFLAGS is for normal
+	scientific applications code, which is pure SPP or SPP/Fortran code,
+	and which would often benefit from vectorization.  System code may
+	call C routines (e.g., the kernel routines), and rarely involves
+	vector operations.  Distinguishing between the two broad classes
+	of codes is necessary on the Convex in order to permit static
+	allocation of procedure argument lists in Fortran (SPP) code.
+	If Fortran code is to call C routines, all arguments must be pushed
+	on the stack, hence this optimization option cannot be used in VOS
+	code (flag -sa disables static allocation of argument lists).
+
+	Optimization level O2 includes vectorization, O1 provides only local
+	and global scalar optimization but no vectorization.  The -n flags
+	turn off various compiler informative and warning messages, which one
+	normally will not want to see (except perhaps once during development).
+	These messages are enabled by default only for the VOPS routines.
+	(11/3)
+
+iraf$mkpkg
+sys/*/mkpkg
+	Added the line '$set XFLAGS = "$(XSFLAGS)"' to each VOS mkpkg file,
+	to override the default xflags with the xsflags.  In the root mkpkg,
+	added the $set to the "syslibs" program.  (11/3)
+
+unix/boot/spp/xc.c
+unix/boot/spp/mkxc.csh -> mkxc.sh
+	Modified XC to use "fc" rather than "f77" as the compiler; omitted
+	the -u flag, since this is done differently for Convex Fortran.
+	To the "run" code, added /usr/convex to the search path, since that
+	is where fc is located (a better solution would probably be to put
+	the path in the #define).  (11/3)
+
+local/bin/ +
+local/bin/xc -> $hlib/xc.e (etc.)
+	Only for the purposes of the port, set up a local/bin directory for
+	iraf, and put it on PATH in the .login.  This will work only for iraf,
+	but avoids having to make a request to the local system manager.
+	(11/3)
+
+------------------------------------
+Started up the first full sysgen.  (11/3)
+
+Summary of results of first full sysgen:
+	The sysgen ran to completion, but not without problems.  The spool file
+	was 19305 lines, 7205 lines when summarized (the extra stuff was
+	mostly advisory information about vectorizing the VOPS routines).
+	There were 23 serious runtime compiler errors of the form:
+
+	    fc: >>>>>   C O M P I L E R   E R R O R    <<<<<
+	    >>>>> See your system manager for help <<<<<
+	    Error : Compiler error on line X of Y.c.
+
+	These were distributed as follows:
+
+	  #times		Error Message
+
+	    16	Error : Compiler error on line 396 of misc.c.
+	     6	Error : Compiler error on line 155 of allocSReg.c.
+	     1	Error : Compiler error on line 584 of callintr.c.
+
+	Note that these are errors in the Fortran compiler, not errors in
+	the Fortran source.  The compiler routine which generated the error
+	is given in the message.  These errors prevented compilation of the
+	affected source file.
+
+	Other errors in the sysgen were [1] fc cannot compile .c files,
+	hence xc will have to be modified to call cc directly, and [2] in
+	sys/gio/ncarutil/sysint/ishift.x, functions IAND and IOR are defined
+	which appear to call themselves recursively, when the macros AND and
+	OR are expanded.  These are dealt with further below.  (11/4)
+
+local/bugs/
+local/bugs/spool.full
+local/bugs/spool.bugs
+	Created a BUGS directory for the Convex and stored therein copies of
+	all the Fortran sources which cause compiler time compiler failures,
+	plus copies of the full spooled output from the first sysgen, and an
+	edited digest of the same containing only the compiler error messages.
+	Verified that the files cannot be compiled even at optimization level 0.
+	All files compiled with optimization turned off EXCEPT one, the
+	sysint/support.f file from gio/ncarutil.  (11/4)
+
+sys/gio/ncarutil/sysint/support.f
+	The subroutine ENCD in this file contained a statement which would
+	cause the compiler to crash even with all optimization turned off.
+	The culprit is as follows:
+
+	    if (len (char (ns + ichar ('0'))) .eq. 2) then
+
+	This is a pretty strange statement, and after staring at it for
+	a while I decided that it would always be false (NS can take on
+	values only between 4 and 6) and commented it out.  Of course it
+	should not cause the complier to bomb, and I will report it to
+	Convex, but I think the code is incorrect and should be fixed.  (11/4)
+
+sys/gio/ncarutil/ishift.x
+	This file contains source for the functions IAND and IOR, written in
+	SPP and defined in terms of the SPP intrinsics AND and OR, which are
+	implemented as macro defines in hlib$iraf.h.  On the Convex these are
+	defined as the Fortran intrinsics IAND and IOR, but they are declared
+	as external functions, hence the Fortran compiler quite correctly
+	flags them as recursive references and fails to compiler the file.
+	A simple fix is to replace the calls to AND and OR by calls to the
+	OSB library functions ANDI and ORI; this is inefficient, but on the
+	Convex the calls in the NCAR code map directly to the Fortran
+	intrinsics anyhow, and if this were not the case the routines should
+	be encoded in assembler and put on the special file list.  (11/4)
+
+unix/hlib/mkpkg.sf
+	Added the 22 or so files with runtime compiler failures to the special
+	file list for CONVEX/IRAF.  Specifically:
+
+	$set	noao	= "iraf$noao/"
+	$set	XCP	= '& "$xc -cq -/no -/nw -/na &"'
+	$set	XCS	= '& "$xc -cq -/no -/sa -/nw -/na &"'
+
+	$special "sys$fio/":			fseti.x		$(XCS);
+	$special "math$iminterp/":		msifit.x	$(XCP);
+	$special "pkg$dataio/fits/":		fits_rheader.x	$(XCP)
+						fits_wheader.x	$(XCP);
+	$special "pkg$images/imarith/generic/":	imcmode.x	$(XCP);
+	$special "pkg$images/filters/":		t_convolve.x	$(XCP);
+	$special "pkg$plot/":			prows.x		$(XCP);
+	$special "pkg$utilities/":		t_curfit.x	$(XCP);
+	$special "$(noao)proto/":		t_bscale.x	$(XCP)
+						t_imscale.x	$(XCP);
+	$special "$(noao)onedspec/":		t_addsets.x	$(XCP)
+						t_bswitch.x	$(XCP)
+						t_dispcor.x	$(XCP)
+						t_flatfit.x	$(XCP)
+						t_sums.x	$(XCP)
+						t_widstape.x	$(XCP);
+	$special "$(noao)twodspec/apextract/":	excextract.x	$(XCP)
+						excstrip.x	$(XCP)
+						t_apnormalize.x	$(XCP);
+	$special "$(noao)twodspec/longslit/":	ilsetbins.x	$(XCP);
+	$special "$(noao)imred/ccdred/src/generic/":	imcmode.x $(XCP);
+	$special "$(noao)imred/dtoi/":		hdtoi.x		$(XCP);
+	(11/4)
+
+unix/boot/spp/xc.c
+	Modified to sort out .c source files and compile these separately
+	with CC (the original XC used f77, which would accept anything). (11/4)
+
+unix/as/zsvjmp.s
+	This file contains the code which attempts to set the address assigned
+	by the linker to the symbol __mem_ (the MEM common in Fortran) to 0.
+	This is not yet working on the Convex; get multiply defined symbol
+	errors.  I have commented this out for the moment in order to proceed.
+	(11/4)
+
+------------------------------------
+Second attempt at a sysgen.  Special files all compiled ok, but got loader
+errors as noted above, hence no executables.  After fixing zsvjmp.s I was
+able to successfully link an executable.  Tried running it, and wonder of
+wonders, it actually ran and produced a prompt!  The process did not quite
+run correctly, but most of the iraf main stuff was evidently working if we
+got that far, so this is encouraging.  (11/4)
+
+unix/hlib/mkpkg.inc
+unix/hlib/mkpkg.sf
+	I just remembered that there are a number of VOPS routines coded in
+	C in the OSB directory, which can be called by any applications code.
+	Fortran code compiled with static argument lists enabled cannot be
+	call C routines directly, so until the OSB routines can be recoded
+	in Fortran for Convex, I have added the -sa switch for applications
+	code as well as VOS code.  (11/4)
+
+----------------------------
+Third attempt at a sysgen.  Deleted all non-HSI binaries and started up a full
+sysgen.  Should work this time with all the above bug fixes.  (11/4)
+
+The sysgen completed normally, and this time suceeded in producing most of
+the executables.  The cl runs and most basic things work ok!  There are a
+number of runtime problems however, which need to be checked out.  Looking
+over the spooled output I find four more files that caused the compiler to
+crash, this time with a core dump, without even a compiler error message.
+The message from FC (indicating abnormal termination of a subprocess) is
+
+	fc: System error in /usr/convex/fskel
+
+The files causing the problem were t_imarith.x in images, and in math,
+gsaccum.x, gsrejectd.x, and isresolve.x.  Dale, my contact at Convex,
+says that there is a major new version of the Convex Fortran compiler,
+currently in beta test, and that I should try that.  I will proceed a bit
+further with the current binaries before starting up another full sysgen,
+as these have been running 8-9 hours.  (11/5)
+
+unix/hlib/mkpkg.sf
+	Added the above four files to the special file list, to be compiled
+	with optimization level -O1 rather than -O2 (no vectorization). (11/5)
+
+unix/hlib/mkpkg.sf
+	After adding the above files to the special file list and resuming
+	the compile of the gsurfit and surfit packages, more files requiring
+	special treatment were uncovered.  The total is now 34.  (11/5)
+
+-----------------------------
+With the math libraries now built, I was able to finish building the IMAGES
+package and tried out a few things - IMSTATR was about 3.5 cpusec, IMSHIFTR
+around 6+ cpusec.  Interactive plotting is not yet working due to some
+problem in the CL.  Error recovery in the CL is not yet working due to a
+problem in ZDOJMP, which has not yet been debugged.  Until this is fixed,
+any error will cause the CL to die.  (11/5)
+
+unix/boot/spp/xc.c
+	Modified to use version 4.0 of the Convex Fortran compiler.  (11/5)
+
+------------------------------------
+Sysgen 4.  Archived (local/oldfc.arc) and deleted all the old non-HSI binaries.
+Ready to start a full sysgen with the new compiler.  Will do this in such a
+way that the current executables remain intact for people to play with
+tomorrow.  (11/5)
+
+local/bugs.newfc +
+local/bugs -> local/bugs.oldfc
+	Set up separate bug directories for the old and new FC.  (11/5)
+
+unix/hlib/sf +
+unix/hlib/sf/main.x +
+unix/hlib/mkpkg.sf
+	The new sysgen has thus far compiled all the system libraries without
+	any compile time errors, hence looks much better (sysgen still in
+	progress; stay tuned).  Even with the new compiler, however, I am still
+	getting an incorrect warning message "illegal transfer out of IFERR
+	block" from the iraf main.  This was traced to the following code in
+	the main:
+
+		iferr (...)
+		    ;
+	or
+		call xerpsh
+		    ...
+		if (.not.xerpop()) then goto NN
+	    NN  continue
+
+	Even with the optimizer turned completely off, FC is chucking out the
+	call to XERPOP, causing the error message noted above.  Since this is
+	not an optimizer problem, the only way to fix it was to hack on the
+	source file.  The hacked version is in hlib$sf, and the file has been
+	added to the special file list for the new-fc.  This is a particularly
+	worrisome bug, as there may be cases such as this scattered all over
+	the system.  (11/5)
+
+-----------------------------
+Sysgen with new FC looks pretty good.  There was one fskel coredump (vectorizer
+evidently) which I will check out below.  (11/6)
+
+noao/onedspec/sensfunc/mkpkg
+noao/onedspec/sensfunc/sfgraphs.x -
+	Deleted this zero length junk file and fixed up the mkpkg.  (11/6)
+
+unix/hlib/mkpkg.sf
+	Added an entry for file dataio$reblock/reblock_file.x, which causes
+	fskel to coredump when compiled with level O2 optimization.  Entered
+	in special file list for level O1 optimization.  (11/6)
+
+unix/as/zsvjmp.s
+	Finished debugging ZSVJMP/ZDOJMP (this was the cause of the CL crashing
+	upon logout and during error recovery).  The Convex version of this
+	routine was easily the most complex I have thus far encountered.
+	The Convex architecture and instruction set is simple, no problem;
+	the problem here as the complexity of the longjmp() code used to
+	make ZDOJMP.  Instead of saving and restoring the machine context,
+	the routine actually pops successive stack frames off the machine
+	stack until it gets back to the stack frame of the ZSVJMP.  There
+	are special cases, e.g., the stack frame pushed by the OS for an
+	interrupt handler.  Twas a mess!   (11/12)
+
+-------------------------------------------------
+Resumed work on Convex port on 5 March - don't know how much time I have to
+spend on this, but a little anyhow, and maybe the compiler is better.
+
+	Cleaned up the some somewhat; moved some files to a save directory,
+	    deleted a lot of junk test files scattered about the system.
+	Redid the bootstrap without incident.
+	Deleted all binaries and started a full sysgen.  As of now (5 March
+	    5 pm) this is still in progress.  The CL and x_system.e are up
+	    and look fine.
+
+Here is the /etc/motd for the current Convex system:
+-------------------
+	*********************************************************
+                        WELCOME  TO  C1EAST
+	*********************************************************
+	SYSTEM WINGNUTS:  BRIAN CHRISTIANSON & DALE LANCASTER
+
+C1EAST  IS  A  CONVEX  C1-XP  MINI-SUPERCOMPUTER.
+	-  128 MEGABYTES OF PHYSICAL MEMORY 
+	-  1.5 GIGABYTES OF DISK SPACE
+	-  40 MFLOPS PEAK PERFORMANCE
+
+C1EAST IS CONFIGURED WITH:
+	-  12.8 MEGABYTES OF DISK BUFFER CACHE
+	-  64 USER SYSTEM
+	-  ETHERNET
+	-  IMAGEN LASER PRINTER
+	-  4.2 BSD UNIX, CONVEX RELEASE 6.1
+	-  VECTORIZING FORTRAN VERSION 4.0 with In-Lining
+	-  VECTORIZING C VERSION Beta 2.0 (vc 1.0 is still around)
+	-  ANSYS VERSION 4.2
+
+	CONVEX COVUEshell V7.0 installed. Look in /usr/doc for
+	new release notices.
+
+
+----------------------------------------------
+Resume testing yet again, this time with a new version of the Fortran
+compiler.
+
+unix/boot/spp/xc.c
+unix/hlib/mkpkg.inc
+	1. Added a new flag "-N" to XC.  Setting this flag causes XC to try to
+	use the beta test Fortran compiler, which is called as
+
+		/usr/convex/newfc/fc -B/usr/convex/newfc ...  
+
+	2. Added the -N flag to the flag macros in mkpkg.inc. (4/16)
+
+unix/as/zsvjmp.s
+unix/os/zdojmp.c +
+unix/os/mkpkg
+	Replaced the nativ ZSVJMP/ZDOJMP I originally wrote for the Convex
+	with a much simpler version which "piggybacks" on the C setjmp/longjmp.
+	The old file is zsvjmp.CONVEX.  (4/16)
+
+----------------------
+Deleted the main system binaries and started a new sysgen.  Will use the old
+HSI for now.  (4/16)
+
+	The sysgen ran to completion with minor problems.  One was the
+	appearance of the following warning message for every file, regardless
+	of the fact that none of our code uses any Convex Fortran preprocessor
+	facilities:
+
+	    fpp: WARNING: Use of fpp is being phased out; please update
+	    your program by removing uses of #define, #if, #ifdef
+
+	The second problem, more serious, what that a number of modules failed
+	to compile due to the IMPLICIT NONE statement being out of order; in
+	pointer functions, the Mem declarations were being output before the
+	IMPLICIT NONE (see below).  (4/17)
+
+unix/boot/spp/xpp/decl.c
+unix/boot/spp/rpp/rpprat/defs
+unix/boot/spp/rpp/rpprat/declco.r
+unix/boot/spp/rpp/rppfor/declco.f
+	1. In decl.c, deleted the code previously added to generate the
+	implicit none statement.  This is not the right place for it, as it
+	doesn't work for pointer functions.
+	2. In declco.r, added code to output theIMPLICIT NONE immediately
+	after a function or subroutine statement.
+	3. In defs, added a switch IMPNONE, which if defined, causes the
+	IMPLICIT NONE statements to be output.
+	4. Processed the fortran for declco.r and put it in rppfor/declco.f.
+	The defs and declco.r files were not updated on the Convex; I made
+	the changes on lyra since this is a generally useful mod, and only
+	copied the processed Fortran to the Convex.  (4/17)
+
+	... incremental sysgen now in progress...
+
+[Ran all benchmarks except [24]USER, networking, and IMLOADs.  No errors.]
+[4/18 SRo]
+[Ran all test procedures except magtape i/o; no errors.  4/27 SRo]
+
+hlib/mkpkg.sf
+	Added the following files to the special file list, to be compiled
+	with the old fc compiler, to avoid a fatal bug in the new 4.1 fc.
+
+	sys/imfort/clargs.x
+	sys/imfort/imemsg.x
+	sys/imfort/imokwl.x
+	sys/imfort/impixf.x
+	sys/imfort/imtypk.x
+	sys/gio/ncarutil/conlib/congen.f
+	sys/gio/ncarutil/conran.f
+	sys/gio/ncarutil/conrec.f
+	sys/gio/ncarutil/isosrf.f
+	sys/gio/ncarutil/threed.f
+	sys/gio/ncarutil/velvct.f
+	noao/onedspec/t_standard.x
+
+	(5/13 SRo)
+
+[Relink sysgen to replace the missing executables in bin$ prior to having ]
+[a tape cut for mailing to NOAO. (5/13 SRo)				  ]
diff --git a/doc/ports/notes.dsux b/doc/ports/notes.dsux
new file mode 100644
index 00000000..0f132092
--- /dev/null
+++ b/doc/ports/notes.dsux
@@ -0,0 +1,282 @@
+Begin port to DECstation 3100.  23 July 1989.
+Start with source only archive of VAX/Ultrix system.
+[note - rsh/tar hung up mysteriously while loading files onto decstation,
+[and had to be restarted].
+--------------------------
+
+unix/as.mips +
+unix/bin.mips +
+	Created AS and BIN directories for Dec/MIPS.  (7/23)
+
+unix/as.mips/zsvjmp.s
+	Prepared a dummy version of zsvjmp for the moment.  All this does is
+	set the output status value to zero.  (prepared by using the compiler
+	to generate the assembler source for a small C program).  (7/23)
+
+unix/boot/spp/xc.c
+	It appears that for some reason, the MIPS C compiler or linker will
+	not accept a file with a .e extension as the output (-o) file.
+	Had to modify XC to output a .E file temporarily, which is renamed
+	to .e after the link.  (7/23)
+
+unix/mkpkg.sh
+unix/os/mkpkg.sh
+unix/shlib/mkpkg.sh
+unix/boot/bootlib/mkpkg.sh
+unix/boot/generic/mkpkg.sh
+unix/boot/mkpkg/mkpkg.sh
+unix/boot/rmbin/mkpkg.sh
+unix/boot/rmfiles/mkpkg.sh
+unix/boot/rtar/mkpkg.sh
+unix/boot/spp/mkpkg.sh
+unix/boot/spp/mkxc.sh
+unix/boot/spp/rpp/mkpkg.sh
+unix/boot/spp/xpp/mkpkg.sh
+unix/boot/wtar/mkpkg.sh
+unix/boot/xyacc/mkpkg.sh
+unix/gdev/sgidev/mkpkg.sh
+unix/bin.mips/fixnames +
+	Modified all the mkpkg.sh files to generate .E files.  Added a
+	fixnames script to bin.mips to rename any .E files therein to .e,
+	and added code the the root mkpkg.sh to call fixnames at the
+	end of the bootstrap.  (7/23)
+
+unix/hlib/cl.csh
+unix/hlib/mkiraf.csh
+unix/hlib/install
+unix/hlib/libc/iraf.h
+	1. Modified the iraf root pathnames in these files.
+	2. In the install, also deleted the entries for edsym.e to avoid
+	an error message during the install.  (7/23)
+
+unix/hlib/extern.pkg
+	Commented out the stsdas entries.  (7/23)
+
+unix/hlib/mkpkg.inc
+unix/hlib/irafuser.csh
+unix/hlib/mkpkg.sf.MIPS
+	Set MACH to MIPS.  Added a case for machine type MIPS.  Added an
+	empty special file list.  (7/23)
+
+unix/hlib/motd
+	Modified to say DECstation/IRAF.  (7/23)
+
+unix/os/zxwhen.c
+	Added a #ifdef mips section with some hardware exception codes for
+	the MIPS.  (7/23)
+
+--------------------
+Start bootstrap.  (7/23)
+
+unix/hlib/irafuser.csh
+	Linking of RPP produced a "gp relocation out of range" error message.
+	It was necessary to compile with "-G 0" (no global variables indexed
+	by global pointer) in order to get this to go away.  (7/23)
+
+unix/boot/bootlib/mkpkg.sh
+	Modified to mv libboot.a to $hbin (../../bin) rather than $hlib,
+	since the libboot.a in $hlib is a symbolic link.  (7/23)
+
+--------------------
+Start sysgen.  (7/23)
+
+unix/as/gkiprint.o +
+unix/hlib/mkpkg.sf.MIPS
+	The file gkiprint.x would fail with a slew (like, 700) syntax and
+	other errors.  There was nothing wrong with the code and the few
+	workarounds I tried had no effect.  I finally managed to compile
+	the file by breaking it up into half a dozen pieces, compiling each
+	separately, and linking the resultant objects into a single large
+	object gkiprint.o.  Since this bug will probably go away before long
+	I merely placed the manually generated object file in AS, and made
+	an entry in the special file list to use this object.  (7/23)
+
+unix/as/imsetr.f +
+unix/hlib/mkpkg.sf.MIPS
+	In this case the file imsetr.f would cause the first pass of f77
+	to core dump (not an optimizer problem).  I had to hack the fortran
+	code to workaround the bug, placing the hacked file in AS.  The
+	offending statement was:
+
+               memi(im+33) = and (memi(+33) , not(1 ))
+
+	the following version is ok:
+
+               i = not(1)
+               memi(im+33) = and (memi(+33) , i)
+
+	The bug must have something to do with the bit intrinsics.  (7/23)
+
+unix/as/fseti.f +		# FIO
+unix/as/fmfcache.f +		# FMIO
+unix/as/fmlfbrd.f +
+unix/as/fmlfbwr.f +
+unix/as/fmlfcopy.f +
+unix/as/fmlfundel.f +
+unix/hlib/mkpkg.sf.MIPS
+	Modified to work around the same compiler bug as above.  The NOT of
+	any compile time integer constant used in an expression seems to
+	always cause a core dump.  (7/23)
+
+unix/boot/spp/xc.c
+unix/hlib/mkpkg.inc
+	1. In the first sysgen, x_images.e failed to link with a "gp relocation
+	out of range" type problem.  Recompiling the IMAGES package libpkg.a
+	with -G 0 fixed the problem.
+	2. Passing this flag through XC, however, was not possible without
+	a code change to XC, as there was no way to pass two consecutive
+	arguments such as "-G 0".  In order to support this XC was modified
+	to permit flags of the form "-/#flag", which are passed as "flag".
+	This is similar to "-/flag" which is passed as "-flag", except that
+	it allows flags with no "-" to be passed.  Hokey, but backwards
+	compatible and it solves the problem.  (7/23)
+
+-----------------
+Started sysgen of NOAO packages.  (7/23)
+
+noao/lib/database.o +
+noao/lib/mkpkg.inc
+noao/lib/mkpkg.sf.MIPS
+	The database.x file in DTOI would cause the compiler to become
+	terminally confused, as with gkiprint above.  Manually constructed
+	the database.o object, placed the latter in noao$lib, and modified
+	the NOAO special file list to use this object rather than try to
+	compile the file.  (7/24)
+
+unix/hlib/config.h
+unix/hlib/libc/spp.h
+	Set the size of the ZDOJMP jump buffer to 84 (83 ints for the jmp_buf
+	buffer plus 1 for the address of the status variable).  (7/24)
+
+unix/as.mips/zsvjmp.s
+	Wrote and installed the real zsvjmp.s.  (7/24)
+
+-------------------
+Sysgen/relink with new zsvjmp.
+Everything appears to work now.  (7/24)
+
+bin.mips
+noao/bin.mips
+	Stripped the BINS to save disk space, as it appeared that the symbol
+	table information is unusually large on the decstation.  (7/25)
+
+				Normal		Stripped
+
+	core system bin		  21.5		   16.0
+	noao bin		  18.0		   12.3
+				-------		--------
+				  39.5		   28.3		
+
+unix/as/zsvjmp.s
+	Modified slightly to eliminate a delay slot.  This failed to work
+	at first and I eventually discovered that the reason was that the
+	*assembler* was modifying my assembler code, reordering the
+	instructions and inserting nop's in delay slots, producing invalid
+	code!  I had to add a "noreorder" directive to get it to leave the
+	code alone.  (7/25)
+
+unix/os/zxwhen.c
+	As a first step in testing exception handling I tried the following
+	in the CL:
+
+		cl> = 5 / 0
+	
+	This caused the CL to core dump on the uncaught signal SIGTRAP.
+	On all other unix systems thus far, integer divide by zero has been
+	mapped to SIGFPE, but on the MIPS it is a trap.  Modified zxwhen.c
+	to map SIGTRAP onto the VOS exception class X_ARITH.  (7/25)
+
+unix/os/zzstrt.c
+	Added the following #ifdef mips code to zzstrt, to enable the overflow,
+	invalid, and divzero IEEE exceptions:
+
+		set_fpc_csr (get_fpc_csr() | 07000);
+
+	The {set|get}_fpc_csr() routines appear to be undocumented but I
+	found them anyhow by searching the symbol tables of the host libraries
+	in /usr/lib.  (7/25)
+
+	[LATER] Well, enabling the IEEE exceptions works, but somehow this
+	is making the software misbehave in a way I do not yet understand
+	and do not have time to look into right now.  Completely unrelated
+	things like "stty vt100", "imheader dev$pix" fail mysteriously with
+	the IEEE trap enable bits set in the FPU context and status register.
+	This doesn't make any sense and we will have to do without the IEEE
+	traps for now.  Possibly this is due to a bug in the OS which will
+	go away in the next release.
+
+unix/hlib/mkfloat.csh
+	The code in this script which lists the tar archive back with
+	"tar -tf", to verify that a good archive has been generated before
+	deleting the files, does not work on the DECstation.  The problem
+	is that tar -tf produces different output here than on the other
+	systems; the directories are listed as files in addition to the files.
+	I had to change the
+
+		tar -tf
+	to
+		tar -tf | grep -v '/$'
+
+	to get things to work.  (7/26)
+
+
+unix/bin.mips
+noao/bin.generic
+bin.generic
+	Stripped all the executables (HSI, IRAF, NOAO).
+	Made IRAF and NOAO generic. (7/26)
+
+
+Summary of various problems encountered.
+-------------------
+
+	fortran compiler core dumps
+	c compiler core dumps
+	cannot -o to a .e file
+	rsh|tar hung once
+	NO ADB!!
+	dbx dies occasionally with internal error: stack overflow
+	2 user limit on logins - prevents even having two windows
+	    open from Sun with a different rlogin session in each.
+	System is very fast single user; much slower if anything else
+	    is running on the machine (memory too small?).
+	System crashed on first day of testing with 2 users busy doing things.
+	    (there did not seem to be a system message file).
+	Some routines which use floating point produce different results on
+	    the MIPS than on other systems.  Examples thus far are the FITS
+	    programs, and IMHISTOGRAM.  No doubt more will be discovered.
+	IEEE exception handling is not working currently.
+
+
+----------------
+V2.8BETA system frozen and archived.  (7/26)
+
+----------------
+Begin upgrade to V2.9ALPHA, 6 DEC 1989.
+Working with newly arrived IRAF DECstation 3100!
+
+	Installed the V2.8ALPHA HSI.
+	Merged in all relevant V2.9 modifications to the HSI.
+
+unix/boot/spp/xc.c
+	Changed the syntax "-/#foo" -> "foo" to "-//foo" -> "foo" for
+	escaping command line arguments to XC.  (1/6)
+
+----------------
+Started a bootstap. (1/6)
+
+mkpkg
+	Extended the mkpkg summary filter in the root mkpkg to filter out
+	the great number of "local variable iyy never used" warning messages
+	produced by the MIPS compiler.  (1/6)
+
+pkg/plot/t_graph.x
+	This file contained a routine im_projection equivalent to a routine
+	of the same name in file improject.x, resulting in two externals of
+	the same name in the package library.  (1/7)
+
+unix/boot/spp/xc.c
+	To avoid a circular reference problem in the DS3100 Fortran libraries,
+	which causes an undefined symbols "s_abort" problem when linking some
+	programs, added a second search of libF77 to the end of the XC host
+	library link list, after the -lm.  (1/7)
diff --git a/doc/ports/notes.freebsd b/doc/ports/notes.freebsd
new file mode 100644
index 00000000..35cb36e0
--- /dev/null
+++ b/doc/ports/notes.freebsd
@@ -0,0 +1,215 @@
+FreeBSD/IRAF (PC-IRAF) port
+Tue Jul 16 18:38:15 MST 1996
+-------------------------------------------------------------------------------
+FreeBSD lepus 2.2-960612-SNAP FreeBSD 2.2-960612-SNAP
+Gateway P5-166, 64 MB RAM, 2 GB disk, Matrox MGA, 21" Vivitron
+HP DAT, SMC PCI-bus 10 Mb/s Ethernet
+
+This port to FreeBSD is being done using IRAF V2.11DEVELOP and the Linux HSI.
+The goal is to produce a single version of IRAF which can run on both Linux
+and FreeBSD, using separate architectures for each.
+-------------------------------------------------------------------------------
+
+mkpkg
+noao/mkpkg
+	Added "freebsd" architecture.  (7/16)
+
+bin.freebsd				+
+noao/bin.freebsd			+
+	Added "bin.freebsd" bindirs.  (7/16)
+
+unix/hlib/motd
+	This IRAF release will be called "PC-IRAF" rather than FreeBSD/IRAF,
+	since the intent is to support all PC-IRAF operating systems as
+	architectures.  (7/16)
+
+unix/hlib/irafuser.csh
+	1. Now supports both Linux and FreeBSD.
+	2. Compile flags are -O -DBSD -w -Wunused.
+	3. Link flags -static -lcompat.   Currently using the compatibility
+	library -lcompat for rexec (and ftime).  BSD doesn't like rexec but
+	there doesn't appear to be much of any alternative.  (7/16)
+
+unix/hlib/cl.csh
+unix/hlib/fc.csh
+unix/hlib/install
+	Modified to autosense the system type and to support both Linux and
+	FreeBSD.  (7/16)
+
+unix/hlib/mkpkg.inc
+unix/hlib/mkpkg.sf.FBSD
+	Added support for FreeBSD.  (7/16)
+
+unix/as.freebsd/zsvjmp.s
+	Using the Linux (i386) version of this file; the only difference is
+	that the jump point is _setjmp for BSD, ___setjmp for Linux.  (7/16)
+
+unix/os/irafpath.c
+	Added "freebsd".  (7/16)
+
+unix/os/zfaloc.c
+unix/os/zfiobf.c
+unix/os/zfioks.c
+unix/os/zfiotx.c
+	Added <unistd.h>, lseek type changed to off_t.  This appears to be
+	the new standard.  (7/16)
+
+unix/os/zxwhen.c
+	Extensive changes/additions for BSD.  FreeBSD appears to have fairly
+	complete exception handling facilities (including the IEEE exceptions).
+	Linux was weak in this area.  (7/16)
+
+unix/boot/mkpkg/host.c
+	BSD does not use ELF, but does use ranlib.  Symbolic link resolution
+	appears to be required.  (7/16)
+
+unix/boot/spp/xc.c
+	Since both BSD and Linux are GNU/F2C-based XC is very similar for
+	both systems.  Minor changes to support FreeBSD, such as adding
+	-lcompat to the host libraries, and disabling the ELF/aout stuff
+	except for Linux.  (7/16)
+
+unix/boot/spp/xpp/xppcode.c
+	Changed "warn" to a static function.  BSD has a library function
+	called warn, caused linker conflicts.  (7/16)
+
+pkg/dataio/fits/fits_wheader.x
+pkg/images/filters/median.x
+pkg/images/imarith/icscale.x
+pkg/images/tv/imexamine/iepos.x
+pkg/xtools/gtools/gtcolon.x
+pkg/xtools/inlfit/ingresults.gx
+	Assorted bugs detected at compile time by F2C.  (not sure the warnings
+	are getting disabled).  (7/16)
+
+sys/imfort/bfio.x
+	In zfaloc, the first arg to strpak was changed from fname (a Fortran
+	character variable which was incorrect) to sppname.  (7/17)
+
+noao/artdata/lists/stcolon.x
+	Variable lumfuncs not used.  (7/17)
+
+noao/digiphot/daophot/psf/dpmkpsf.x
+	dp_addstar called incorrectly.  (7/17)
+
+noao/onedspec/dispcor/dcio.x
+	Variable axis never used.  (7/17)
+
+noao/onedspec/identify/idshift.x
+	Function/subroutine confusion.  (7/17)
+
+noao/onedspec/sensfunc/sfoutput.x
+	Variable axis never used.  (7/17)
+
+noao/onedspec/splot/getimage.x
+	gt_setr called with an integer value.  (7/17)
+
+noao/onedspec/t_fitprofs.x
+	pargi called with boolean argument.  (7/17)
+
+noao/rv/rvfgauss.x
+	A couple of _old varables were declared but never used.  (7/17)
+
+noao/twodspec/apextract/apids.x
+	Variables ra, dec declared double but used as both pointers and
+	doubles.  (7/17)
+
+noao/twodspec/longslit/transform/t_transform.x
+	Variable axis not used.  (7/17)
+
+noao/imred/ccdred/src/t_ccdmask.x
+	Procedure cm_mask called with wrong arguments.  (7/17)
+
+noao/imred/ccdred/ccdtest/t_mkimage.x
+	Variable pixtypes not used.  (7/17)
+
+noao/imred/dtoi/hdicfit/hdicebars.x
+noao/imred/dtoi/hdicfit/hdicfit.h
+noao/imred/dtoi/hdicfit/hdicgfit.x
+noao/imred/dtoi/hdicfit/hdicggraph.x
+	Various type related problems.  (7/17)
+
+dev/hosts
+	Updated entry for lepus, which is no longer an A/UX system.  (7/19)
+
+unix/boot/mkpkg/host.c
+unix/boot/mkpkg/main.c
+unix/boot/mkpkg/mkpkg.h
+unix/boot/mkpkg/scanlib.c
+	Various mods to support source code debugging.  Mkpkg now supports
+	the -x flag.  If this is seen -x will be added to all flag defines
+	(XFLAGS, XVFLAGS, LFLAGS).  Mkpkg, whenever a library is referenced,
+	will check for a debug version of the library.  For example if the
+	library is libsys.a the debug version is libsys_p.a.  Calling mkpkg
+	as "mkpkg -x" automatically causes the _p.a versions of all libraries
+	to be updated, creating them and doing a full recompile if necessary,
+	without having to edit any mkpkg or mkpkg.inc files to modify the
+	compile/link flags.  The normal and debug versions of all libraries
+	are maintained independently.  (7/20)
+
+unix/boot/spp/xc.c
+	XC was also modified to support debugging via the -x switch.  Defining
+	the -x switch causes it to be passed on to xpp, rpp, and f77 which
+	is necessary to compile for debuging.  The -x switch also causes XC
+	to look for _p.a (debug) versions of any libraries.  For example,
+	if the command line is "-x libpkg.a -lstg" then XC will look for
+	libpkg_p.a and libstg_p.a, falling back on the normal versions of
+	the libraries if the debug versions are not found.  (7/20)
+
+unix/hlib/f77.sh
+	If the -x switch is given the intermediate C file is edited to replace
+	any "file.f" references with "file.x".  (7/20)
+
+unix/boot/spp/rpp/rpprat/common
+unix/boot/spp/rpp/rpprat/errchk.r
+unix/boot/spp/rpp/rpprat/initkw.r
+unix/boot/spp/rpp/rpprat/outdon.r
+unix/boot/spp/rpp/rpprat/ratfor.r
+	RPP was modified to generate "#line file.x" statements in the output
+	Fortran code to support source code debugging.  This is done only if
+	the -x flag is set.  F2C supports #line but most Fortran compilers
+	do not.  (7/20)
+
+unix/boot/spp/rpp/rpprat/Makefile
+	Added a call to sed to workaround a ratfor bug (generates an
+	unreachable statement).  This makes "make fort" fully automatic.
+	This is used to generate the .f files from the .r files.  (7/20)
+
+--------------------------
+The PC-IRAF (FreeBSD) HSI was erased in a botched rdist update from tucana.
+Reloaded from a 3-Sep-96 backup tape.  Tue Oct 29 16:05:37 MST 1996
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+--
diff --git a/doc/ports/notes.i386 b/doc/ports/notes.i386
new file mode 100644
index 00000000..0ab05de0
--- /dev/null
+++ b/doc/ports/notes.i386
@@ -0,0 +1,1124 @@
+Sun 386i (RoadRunner) Sun/IRAF port.  Begin 5 Oct 88.
+--------------------------------------------------------
+
+    o	Created the IRAF root directory at /files/vol/iraf in accordance
+	with the recommendations in the administration guide for 3rd party
+	software.
+
+    o	Moved in a copy of iraf from tucana.
+    o	Installed the SunOS 4.0 mods made earlier on taurus.
+
+sun/hlib/libc/iraf.h
+	Manually edited for the new root.
+
+/etc/fstab
+/usr/include/iraf.h +
+	Installed a symbolic link for iraf.h in /usr/include.  In order to
+	do this on the 386i, I had to remount the /usr file system read-write;
+	it was read-only at first for some reason.
+
+unix/bin.i386 +
+unix/as.i386 +
+	Added these directories.  "mach" is "i386" on the 386i.
+
+unix/as.i386/zsvjmp.s
+	Figured out enough of the 386i assembler to write a stubbed out
+	zsvjmp routine.  Will have to write a real one later.
+
+unix/sun/Makefile
+	Changed the float option to -fsingle as for the Sun4.
+	Added a "-o `mach` = "i386" condition to test for SunOS 4.0.
+
+------------------------
+Compiled GTERM and IMTOOL.  They seem to work!.
+Did a bootstrap.  Completed normally except that the library scanning code
+in MKPKG did not compile, no doubt due to the COFF objects on the 386i.
+Did an INSTALL to install the iraf links, GTERM, IMTOOL, etc.
+
+    o	Configured /usr/local.
+    o	Reconfigured my .sunview file (used to be .suntools) to use GTERM and
+	IMTOOL as on the Sun-3; came up ok.
+
+PROBLEMS
+	Window refresh is abysmally slow on the 386i.
+	Perfmeters sometimes core dump and die after running fine for a while.
+
+unix/hlib/irafuser.csh
+	Deleted the "-fsoft" entries - not used on the 386i.  (10/19)
+
+unix/boot/mkpkg/scanlib.c
+	Had to add
+
+		#ifdef i386
+		#define PORTAR 1
+		#endif
+	
+	at the top of the file to get include <ar.h> to define the appropriate
+	library format.  Also, on the 386i, the code which scans the library
+	has to deal with the following peculiarities:
+
+	    o	The first "file" in the archive is a dummy entry containing
+		symbol information; the name field is null, hence the code
+		can skip this entry by checking for archive members with
+		null-string names.
+
+	    o	The names of the archive members now have a trailing /,
+		e.g., "file.o/", followed by blank padding.  Previously
+		only the blank padding was there.  I modified the code to
+		accept either / or blank as the name delimiter.
+
+	I also added some debug code which prints the name and date of each
+	archive member as the library is scanned, if debug > 1.  These
+	changes should be portable to other systems.  (10/19)
+
+SUNBUG - f77
+	The command "f77 -c -O file.c" produces the following:
+
+		Assembler: /tmp/optim.01231.5.s
+			aline 1	: Warning: cannot field update- '.file' not
+			   on first line
+
+	This prevents use of f77 to compile C files, at least on the 386i!
+	(It works if the optimizer is not used).  Will have to modify XC to
+	use CC instead.  (10/19)
+
+unix/boot/spp/xc.c
+	1. Hacked XC to use F77 only to compile Fortran source files, and to
+	use CC for everything else.
+	2. Added /usr/local/bin to the list of directories to be searched for
+	commands like XPP and RPP.
+	3. Changed the defined names from "xpp.e" and "rpp.e" to "xpp" and
+	"rpp", since this is how they appear in /usr/local/bin.  (10/19)
+
+unix/hlib/mkpkg.inc
+unix/hlib/mkpkg.sf.I386 +
+	Added code for case FPU = i386 (not really an fpu), plus a special
+	file list for the 386.  (10/19)
+
+unix/hlib/cl.csh
+	Added a case for the i386, similar to that for sparc.  (10/19)
+
+---------------------
+Sysgen completed with a half a dozen files with errors, but no executables
+were linked due to a library conflict with the dummy zsvjmp.s I wrote.  (10/20)
+
+unix/as/zsvjmp.s
+unix/as/zzdebug.c
+	Wrote a ZSVJMP.S for the 386i (80386), plus a little test program to
+	make sure it works.  (10/20)
+
+---------------------
+Linked x_system.e and it runs on the first attempt!!  (10/20)
+Start another sysgen - ignore files that didn't compile for now, until we
+see which executables they prevent from being linked.
+
+sys/vops/acht.gx
+	On the 386i, statements of the form "b[i] = a[i]", where B was
+	COMPLEX and A was INTEGER*2, revealed a compiler error in the
+	386i Fortran compiler (the error was a syntax error in the assembler
+	code input to the system assembler).  I decided that assigning
+	an integer*2 to a complex in a straight assignment wasn't a very
+	safe thing to do anyhow, so the generic source was changed to
+	generate  "b[i] = complex(real(a[i]),0.0)" instead, whenever B
+	is complex and A isn't.  (10/20)
+
+sys/vops/amod.gx
+	No changes here, just logging the compiler bug.  The code is as
+	follows:
+
+	     do 110 i = 1, npix
+		c(i) = mod (a(i), b(i))
+
+	where A, B, and C are integer*2.  Once again, the compiler is
+	generating incorrect assembler for this case, causing a "syntax error"
+	from the assembler (evidently, because of the rather restrictive
+	instruction set of the 80386).  I am not sure there is anything in
+	IRAF that uses this routine anyhow, so we will try to ignore it for
+	now.  (10/20)
+
+unix/hlib/mach.h
+	1. Set the BYTE_SWAP[24] flags to YES - forgot to do that before the
+	sysgen, unfortunately.
+	2. Changed MAX_EXPONENTD and related variables (MAX_DOUBLE, INDEFD)
+	to reflect the fact that the max exponent for IEEE double is 2**1023
+	or 10**307.  (10/21)
+
+unix/hlib/mkpkg.sf.I386
+	Commented out the entries for as$ishift.s for now.  (10/21)
+
+noao/astutil/pdm/pdmstatistics.x			pdmstats.x
+noao/digiphot/apphot/center/apcentercolon.x		apcencolon.x
+noao/digiphot/apphot/center/aprefitcenter.x		aprefitcen.x
+noao/digiphot/apphot/center/apfitcenter.x		apfitcen.x
+noao/proto/t_mkhistogram.x				t_mkhgm.x
+	Shortened the names of the above source files.  These will not compile
+	on the 386i, which has a limit of 14 characters for the names of
+	modules in object libraries (which are COFF format libraries from
+	Sys V, hence the 14 char limit).  (10/21)
+
+unix/hlib/mpkg.sf.I386
+	Turned off the optimizer for conrec.f, srface.f, pwrzi.f.  An apparent
+	optimizer bug was causing declaration of an external which would cause
+	an unsatisfied exernal error at link time.  (10/21)
+
+pkg/images/iminfo/t_imstat.x
+	Replaced some ==INDEF constructs by IS_INDEF, and took the n=n+1 out
+	of the inner loop, since it isn't needed.  (10/21)
+
+unix/boot/mkpkg/host.c
+	Disabled the ranlib (library rebuild) on the 386, since it uses COFF
+	type libraries, which don't need to be ranlib-ed.  (10/21)
+
+unix/hlib/mach.h
+	For the moment, restored the former, incorrect for IEEE, values of
+	the machine constants for type double.  There are obviously a number
+	of bugs in the system where code assumes that the values for types
+	real and double are the same.  This will have to be addressed later
+	when there is more time to debug this.  (10/21)
+
+unix/hlib/mpkg.sf.I386
+unix/as/amods.s +
+	Edited the assembler for the VOPS amods routine (to work around the
+	compiler bug mentioned above) and placed the assembler version in
+	AS and added the file to the special file list for the 386i.  (10/21)
+
+-------------------
+	As far as I know, all bugs are now fixed and the system is up on
+	the 386i, although there is still a lot of work to be done on improving
+	the installation procedures, optimization to reduce paging, etc.
+	A full system mkpkg/relink (no compiles) took 23 minutes on the 386i.
+	(10/21)
+
+buglog
+	Cannot access 5!mta, although page 5!dev$devices works.  (10/22)
+	(May be VOS bug not 386i bug?).
+
+sys/fio/mkpkg
+sys/fio/ungetci.x +
+	Added a new routine UNGETCI to FIO.  Since there is an ungetc for getc,
+	there should be an ungetci for getci.  (10/22)
+
+buglog
+	The statement
+
+		if (1)
+		    ...
+
+	does NOT result in any errors or warnings from the Fortran compiler.
+	(10/22)
+
+unix/hlib/libc/*.h
+unix/hlib/irafuser.csh
+	In order to remove the need to modify anything in /usr (which wants
+	to be mounted read-only in the latest SunOS), I modified the HSI to
+	call the C compiler in such a way that $hlib/libc is searched for
+	include files, as well as the system directories.  This is done via
+	the HSI_CF environment definition in $hlib/irafuser.csh, which adds
+	$hlib/libc to the list of directories to be searched.  The C compiler,
+	presented with #include <iraf.h>, will load $hlib/iraf.h  To avoid
+	having the compiler resolve files like <stdio.h> etc. to $hlib/libc
+	as well, I had to prefix the names of all these files with a "u",
+	e.g., "ustdio.h", modifing the references in <iraf.h> as well.
+	Since the files are referenced only in <iraf.h>, this change should
+	be completely transparent.  (10/23)
+
+sys/memio/salloc.x
+	Hard to believe, but it appears that buffers allocated on the stack
+	are not necessarily aligned to TY_DOUBLE (proper alignment would
+	result for anything smaller).  (10/24)
+
+unix/boot/spp/xc.c
+	Added a link time -align mem_ switch to double word (actually page)
+	align the MEM common.  (11/11)
+
+unix/os/irafpath.c
+	Added a #ifdef i386 case.  (11/14)
+
+unix/boot/mkpkg/host.c
+	Added support for IRAFULIB (a user defined private library) to
+	the $checkout and $checkin directives.  For example, in
+
+		$checkout libex.a lib$
+
+	if file libex.a is found in IRAFULIB, that version is checked out,
+	rather than the one in the system directory lib$.  (11/15)
+
+-------------------------
+Log of changes for the Sun/IRAF shared library facility.  This was developed
+on the 386i initially.  This log was written on 28 December and summarizes the
+revisions made during the period Tue 20 Dec to Wed 28 Dec 1988.
+
+[background]
+	Although SunOS 4.0 supports dynamic linking, mapped files, and shared
+	libraries, currently only the C compiler can generate position
+	independent code (PIC).  Sun Fortran does not currently support shared
+	libraries since it cannot yet generate PIC code.  In any case, PIC
+	code executes less efficiently than nonrelocatable code, and the
+	dynamic linking required by relocatable shared libraries slows down
+	process startup.
+
+	Our strategy is to implement the equivalent of a shared library by
+	building a *nonrelocatable* shareable image (executable process),
+	and mapping it to a fixed address in the address space of client
+	processes at process startup time.  A transfer vector is used to
+	vector procedure calls to arbitrary offsets in the shared image,
+	allowing new shared images to be installed without having to relink
+	client processes (in most cases).  The mapped file feature of SunOS
+	4.0 is the only thing essential for this scheme to work, and it is
+	the lack of the mapped file capability which has prevented us from
+	implementing a shared library up until now.
+
+	Even when (and if) Sun/Fortran eventually adds support for PIC and
+	shared libraries, the mapped image approach we have followed here
+	may still be the best choice.  Despite the slight loss of execution
+	efficiency caused by the use of position independent code, use of
+	PIC is not likely to be a serious drawback.  More serious drawbacks
+	derive from the use of global data, and dynamic linking at runtime.
+	Dynamic linking, e.g., to set the address of a global variable for
+	which the location is not known until runtime, requires the
+	modification of every text page containing code which references the
+	variable.  Aside from the obvious time penalty during process startup 
+	while this linking and page copying is taking place, modification of
+	a text page defeats shared text, increasing memory and paging
+	requirements.
+
+	Trying to avoid this problem in a relocatable shared library can be
+	very difficult, requiring modification to source code if it can be
+	done at all.  The nonrelocatable approach we have followed guarantees
+	sharing of the entire text of the shared image and does not require
+	any changes to system or applications source code (provided no
+	interfaces have been violated).  There are other advantages which
+	derive from the facility being part of the Sun/IRAF HSI, e.g., if
+	iraf is linked on an NOAO node and later installed with a different
+	root on a remote node, there is no problem locating the shared library
+	at runtime.  Furthermore, since our approach requires on the part of
+	the host system only the ability to map files to fixed addresses,
+	and the ability to specify the base address of the text segment of
+	an image at link time, it should be applicable to other (non-Sun)
+	systems which may provide these capabilities but not shared libraries.
+
+unix/as.i386/zsvjmp.s
+	After a little experimentation I found that the .SET assembler macro
+	could be used to set the value of absolute symbols.  This allows MEM
+	to be located at virtual address 0, making shared libraries possible
+	for the 386i, and improving assembly level debugging as well.
+
+unix/shlib/README
+unix/shlib/S.nm.i386		external names in 386i shared library
+unix/shlib/S.nm.mc68020		external names in Sun-3 shared library
+unix/shlib/S.ver.i386		386i shared library version number
+unix/shlib/S.ver.mc68020	Sun-3 shared library version number
+unix/shlib/Slib.c		support code
+unix/shlib/aout.c		utility to decode a.out format process headers
+unix/shlib/coff.c		utility to decode COFF format process headers
+unix/shlib/edsym.c		called by XC to edit symbol table of .e file
+unix/shlib/mkpkg		mkpkg tie-in
+unix/shlib/mkpkg.sh		called to boostrap edsym.e
+unix/shlib/mkshlib.csh		script which does it all
+unix/shlib/omit.i386		external names to be excluded from 386i shlib
+unix/shlib/omit.mc68020		external names to be excluded from Sun-3 shlib
+
+	This directory contains all the code needed to build and maintain the
+	shared library.   The shell script mkshlib.csh, normally called via
+	the mkpkg, does all the work.  This constructs a name list for the
+	shared library, generates the assembler required for the transfer
+	vector modules (V.s and S.s), and links the shared image (S.e).
+
+	When building a new shared library, mkshlib checks to see if any
+	externals have been deleted from or added to the name list of the
+	old shared library.  If any externals have been deleted, the version
+	number is incremented and any applications linked with the shared
+	library will have to be relinked.  If there were no changes to the
+	name list or new externals have been added, then the version number
+	is not incremented, and existing applications are permitted to use
+	the new shared image without having to be relinked.  The shared image
+	is linked -Bstatic, meaning that any required host library procedures 
+	are bound at link time.
+
+	Only Fortran or Fortran-like externals are permitted, i.e., exported
+	from the shared image to the client via the transfer vector.  This is
+	necessary to permit clients to be linked -Bdyamic, allowing use of
+	the host system shared libraries (otherwise name conflicts would
+	occur at link time).
+
+	The objects produced by the SHLIB code are libshare.a (the shared
+	library) and S.e (the shareable image), discussed further below.
+
+bin/S.e +
+	The shared image.  This gets mapped into the address space of any
+	process linked with the shared library.  It is also a runnable process
+	in its own right; if run directly, it prints out some information
+	about itself and exits.  The full contents (minus the omitted
+	externals) of the EX, SYS, VOPS, and OS libraries are currently
+	linked into this image; other libraries may be added in the future,
+	e.g., some of the MATH libraries.  The transfer vector module V.o,
+	located at a fixed (absolute) offset in the image, is used to vector
+	procedure calls from the client process into the shared image.
+
+lib/libshare.a
+	The shared library.  This contains several object modules, including
+	a single object S.o consisting of a short header plus a name list
+	containing all the externals exported by the shared image.  Each
+	external (i.e., VOS procedure such as 'clgeti' etc.) appears in S.o
+	as an absolute symbol, pointing to a fixed location in the transfer
+	vector in the shared image.  Note that externals appear in S.o only
+	as symbols, hence no actual executable code gets linked into the
+	client process.  To link with the shared library, XC links with
+	libshare.a instead of libex.a,libsys.a,libvops.a,libos.a.
+
+unix/os/zmain.c
+	The zmain is the main procedure for an iraf process.  The first thing
+	the zmain does now is call ZZSTRT, which is described below.  Some
+	code was moved out of the zmain into ZZSTRT, and all references to
+	global variables in the kernel had to be eliminated, since the zmain
+	is no longer linked with the kernel procedures (which are off in the
+	shared image).  Other changes included the addition of calls to ZZSETK
+	to set the values of the kernel variables, and changes to the calling
+	sequence of IRAFMN to permit the address of SYSRUK and ONENTRY to be
+	passed in the argument list, rather than being bound at link time.
+
+unix/os/zzstrt.c
+	The function of this procedure, which has been a no-op in UNIX/IRAF
+	up until now, is to perform any runtime initialization of the kernel.
+	Currently, ZZSTRT maps and initializes the shared image, sets the
+	desired IEEE exceptions (partially implemented at present), sets the
+	process working set soft limits, and sets the default values of the
+	kernel variables via the new ZZSETK procedure.
+
+	Mapping and initializing the shared image is similar to what unix
+	does during startup of a normal process.  The shared image file is
+	opened, and the header is read to determine the sizes of the text,
+	data (initialized data), and bss (unitialized data) segments.
+	IRAF uses an additional shared image header segment containing the
+	file header and the FIO common (fiocom), which has to be directly
+	accessed by the client, making it necessary to locate it at a fixed
+	address in virtual memory.
+
+	The header segment containing the FIO common is then mapped read-write
+	private, meaning that if any pages are modified the client gets a
+	private copy of the page.  The text segment of the shared image is
+	mapped read-only shared.  The data segment is mapped read-write
+	private; pages are shared until modified by the client at runtime.
+	The BSS segment is then mapped onto an arbitrary file offset (zero)
+	and promptly zeroed, causing all of the pages to belong to the client.
+	Finally, the addresses of the unix malloc, realloc, and free procedures
+	are passed into the shared image (dynamic memory allocation must be
+	in the data space of the client), and the environment pointer in the
+	shared image is set to point to the environment of the client, so that
+	the VOS will see the host environment and command line arguments seen
+	by the client.
+
+	Both ZMAIN and ZZSTRT are linked directly into each client process,
+	since they are required to map in and initialize the shared image.
+	(S.e has its own private copies, of course).
+
+unix/os/zlocpr.c
+	ZLOCPR had to be modified to deal with the transfer vector.
+	The problem is that calls to ZLOCPR in the client image and in the
+	shared image must return the same value, since equality comparisons
+	of procedure entry points are are used to determine, e.g., if a
+	particular file driver is referenced.  ZLOCPR was modified to check
+	if the referenced procedure is actually a transfer vector entry,
+	returning the address of the actual procedure in the shared image
+	if so.  Since this is a host level procedure, this is done by
+	disassembling the JMP instruction in the transfer vector.
+
+unix/os/zshlib.c +
+	This object contains everything needed to link a process against the
+	standard libraries, ignoring the shared library.  Dummy shared image
+	descriptors and procedure entry points are defined so that the code
+	in ZMAIN and ZZSTRT will link properly.  At runtime, the startup code
+	determines that the shared library is not in use, skipping the map and
+	initialize operations.
+
+unix/os/zzsetk.c +
+	This new kernel procedure is used to initialize the values of all the
+	global kernel variables formerly initialized via EXTERN references in
+	the zmain.  A procedure (with transfer vector) must be used instead
+	of a series of global data references in order to be able to link
+	against the shared library.
+
+unix/boot/spp/xc.c
+	1. XC was modified to link against the shared library by default.
+	The new switch -z (as in VMS/IRAF) is used to link without using
+	the shared library.  Both the shared library and the shared image
+	may be in an IRAFULIB directory if desired.
+
+	2. If linking against the shared library, XC will by default call
+	EDSYM to edit the symbol table of the new executable, renaming the
+	symbols pointing to transfer vectors by prefixing a "V", and adding
+	new symbols to point into the shared image to the actual locations
+	of the VOS procedures referenced by the transfer vector.  This provides
+	symbols for debugging executables that used the shared image.
+
+	New XC switches:
+
+		-e	do not call edsym to do symbol editing
+		-s	strip executable (UNIX linker switch; for XC, defeats
+			    call to edsym).
+
+	edsym switches (accepted by XC):
+
+		-d	print symbol table
+		-k	do not delete "uninteresting" symbols
+		-n	do not modify any files
+		-t	omit transfer vector symbols to save some space
+		-T	delete all symbols associated with the shared library
+
+	3. The -align switch, formerly passed to the 386i linker to page
+	align the MEM common, was deleted since MEM is now assigned to
+	location zero with a .SET.
+
+sys/etc/main.x
+sys/etc/xmjbuf.x +
+	1. The calling sequence of the iraf main was modified to add sys_runtask
+	(SYSRUK) and onentry (ONENTY) as arguments, allowing a runtime rather
+	than link time reference.  This was necessary for the shared library
+	since SYSRUK and ONENTY are client symbols but are called by the iraf
+	main, which is in the shared image.  The new scheme is more flexible
+	in any case.
+	2. The new procedure XMJBUF is used to get an XCHAR pointer to the
+	zsvjmp/zdojmp context vector used by the iraf main for interrupt and
+	error recovery.  Again, a runtime procedural reference using a pointer
+	is necessary since the global data area cannot be referenced at link
+	time.  The CL uses both a custom onentry and a custom zdojmp context
+	vector in order to gain full control over command interpretation.
+
+unix/hlib/libc/libc.h
+unix/hlib/libc/knames.h
+unix/hlib/libc/xnames.h
+	1. In libc.h, the ZJUCOM reference was deleted since the XMJBUF
+	procedure is now used to access the interpreter context vector.
+	2. Entries for the new VOS and kernel procedures were added to
+	[xk]names.h.
+
+unix/hlib/irafuser.csh
+unix/hlib/mkpkg.inc
+mkpkg	[at iraf root]
+	1. The -z flag (no shared library) was added to the HSI_XF flags in
+	irafuser.csh, so that HSI executables will not use the shared image.
+	2. The mkpkg.inc now includes a switch USE_SHLIB, which if set causes
+	mkpkg to automatically update the shared library and shared image
+	during a sysgen.  This switch does not actually determine whether the
+	shared library is *used*, since that is determined by the -z switch
+	to XC at link time.
+	3. For Sun/IRAF, the switch -/Bstatic was added to LFLAGS so that
+	the iraf executables will be statically linked, rather than using the
+	SunOS shared library (e.g., libc.a).  This was not necessary - there
+	is no conflict between the iraf and SunOS shared libraries - but was
+	done to save disk space (see CAVEATS, below).
+
+unix/mkpkg.sh
+unix/shlib/mkpkg.sh
+	Will build the edsym.e utility and install it in HBIN during a
+	bootstrap.
+
+unix/hlib/install
+	Will make a link for EDSYM in the local/bin directory.
+
+pkg/cl/main.c
+	A call to XMJBUF was added to convert to a vectored procedure reference
+	to the main interpreter context vector.
+
+sys/gio/cursor/prpsinit.x
+sys/gio/cursor/mkpkg
+sys/etc/mkpkg
+sys/etc/prfindpr.x
+sys/etc/propcpr.x
+sys/etc/prsignal.x
+sys/etc/prfilbuf.x
+sys/etc/prgline.x
+sys/etc/prupdate.x
+sys/etc/prclcpr.x
+sys/etc/prstati.x
+sys/etc/prredir.x
+sys/etc/prgredir.x
+sys/etc/prclose.x
+sys/etc/proscmd.x		[moved from gio/cursor to ETC]
+sys/etc/prpsio.x		[moved from gio/cursor to ETC]
+sys/etc/prc.com			[moved from LIB to ETC]
+sys/etc/prpsload.x +
+	Most of the "pr" prefixed files, e.g., PRPSIO, were moved from
+	gio/cursor to ETC, and the file prc.com (the PR common) was moved
+	from LIB to ETC, making it a private common.  This was necessary
+	to avoid the global data reference, which would cause the process
+	control code to fail at runtime due to the client and shared image
+	having separate copies of the PRC common (another reason to not use
+	commons!).  PRPSIO was modified to use a loadable driver to provide
+	a runtime technique for linking to the graphics pseudofile i/o
+	procedures in gio/cursor.  In addition to making the shared library
+	cleaner to implement, this collects all of the process control code
+	together in one place in the VOS (in ETC - libsys.a), avoids some
+	circular library references, and makes it possible to use LIBC/stdio
+	in applications processes without an unresolved linker reference
+	to PRPSIO (STScI has run into this).
+
+	PRPSINIT is a procedure called by the CL at startup time to load
+	the gio/cursor graphics pseudofile i/o driver into PRPSIO.
+
+lib/syserr.h
+lib/syserrmsg
+	A new error SYS_PRPSIOEPA was added, in support of the above
+	modifications.
+
+pkg/images/filters/mkpkg
+pkg/images/filters/convolve.x
+pkg/images/filters/radcnvr.x	[used to be called acnvrr.x]
+	This code contained a routine ACNVRR which redefined a VOPS library
+	procedure, causing a multiply defined linker error when linking with
+	the shared library.  The offending procedure was renamed CNV_RADCNVR
+	(radially symmetric convolve, type real).  Applications should not
+	use reserved package prefixes.
+
+unix/os/zfunc.c +
+	A set of new kernel primitives ZFUNC1, ZFUNC2, ... ZFUNC9 were added.
+	These are similar to ZCALL[1-9], but allow calling of functions by
+	their LOCPR entry point address, as has long been possible with
+	subroutines and ZCALL.
+
+CAVEATS - Shared libraries
+	Several interesting things about SunOS were learned in the process of
+	implementing the Sun/IRAF shared library.
+
+	1. Linker Bug.  There is a bug in the SunOS linker.  The size of the
+	BSS area is not being computed accurately.  For processes with a very
+	small BSS section, this can lead to a BSS size of zero being computed.
+	Normally this does not cause a problem, since a small BSS area will
+	usually fit into the last page of the data area.  In some cases,
+	however, the small BSS area is in an additional page, but since BSS
+	is zero no BSS area is allocated during process startup, causing a
+	segmentation violation when the unix code tries to set the value of
+	the BSS global variable "environ" during process startup.  I managed
+	to avoid this problem by the subtle kludge of adding the following
+	declaration to the ZZSTRT object (which is linked into every iraf
+	process):
+
+		int	BSS_kludge[256];
+
+	This provides the process with enough BSS storage (statically allocated
+	unitialized data space) to avoid having the size of the BSS segment
+	being set to zero at link time.
+
+	2. Does using the SunOS shared libraries really save space?
+	For some reason which I was not able to determine, a small iraf
+	process linked -Bdyamic (the default, i.e., use the SunOS shared
+	libraries) always has a text segment of 75-85 Kb, even though the
+	sum of all the objects therein may be much less.  It appears that
+	the linker may be incorrectly computing the size of the text segment,
+	causing it to effectively be padded out to a size considerably larger
+	than what it should be.  Linking the process -Bstatic (no SunOS
+	shared libraries) avoids the bug, yielding a much smaller executable
+	file, even though more text space is actually required due to the
+	need to link in modules from the SunOS libraries which would otherwise
+	be shared.
+
+	3. Processes with a large BSS segment execute slowly.  One thing which
+	became very clear to me while working on image execution was that
+	processes with a large BSS segment take a long time to execute.
+	The reason is that the BSS segment must be zeroed during process
+	startup.  Zeroing a large region of mapped memory involves both the
+	cpu time required to zero the storage, plus all the mapped file i/o
+	(paging) required to initialize the mapped swap file pages.  This is
+	not a big deal for processes with a BSS segment in the N*10K region,
+	but if the BSS is N*100K or N*1000K, then it can take seconds.  The
+	moral is USE DYNAMICALLY RATHER THAN STATICALLY ALLOCATED BUFFERS.
+	I am going to modify some of the system code as a result of this
+	lesson, e.g., the CL currently statically allocates about 250K of
+	combined stack and dictionary buffer space.  In applications, BSS
+	storage is most commonly found as declarations of the form
+
+		char	fname[SZ_FNAME]
+		char	line[SZ_LINE]
+	
+	and so on.  This is of no consequence for small individual programs,
+	but can add up to a lot of BSS for large packages.  The unix "size"
+	utility may be used to determine the BSS requirements of a process.
+
+unix/boot/mkpkg/tok.c
+	An unrelated bug in MKPKG was fixed, which would cause one or the
+	other of IFOLDER or IFNEWER to fail, when presented with a list of
+	files to be compared.  The bug was that IFOLDER is not equivalent
+	to !IFNEWER when more than one file must be compared.  (12/28)
+
+unix/as.i386/README
+unix/as.i386/aclrb.c
+unix/as.i386/aclrc.c
+unix/as.i386/bytmov.c
+unix/as.i386/aclrs.c
+unix/as.i386/aclri.c
+unix/as.i386/aclrl.c
+unix/as.i386/aclrr.c
+unix/as.i386/aclrd.c
+unix/as.i386/amovc.c
+unix/as.i386/amovs.c
+unix/as.i386/amovi.c
+unix/as.i386/amovl.c
+unix/as.i386/amovr.c
+unix/as.i386/amovd.c
+unix/hlib/mkpkg.sf.I386
+	In an unrelated optimization, the above zero and move procedures
+	were added to AS.  These are written to use calls to the host
+	BZERO and BCOPY functions to zero or copy blocks of memory, taking
+	advantage of the special repeat-string-op instructions provided by
+	the 80386 cpu.  (12/28)
+
+sys/ki/irafks.x
+	In the open-binary-file code, the fprintf debug message was incorrectly
+	passing arg1 rather than arg2 as the file access mode.  (12/29)
+
+unix/boot/mkpkg/tok.c
+	In the $ifeq code, strcmp() would be called with a NULL string pointer
+	if the referenced environment variable was undefined.  (1/2)(1989)
+
+---------------------
+Moved shared library stuff to tucana (Sun-3) over the period 30Dec-2Jan.
+Reworked mkshlib.csh, edsym.c, zzstrt.c etc. for the "a.out" format object
+files used on the Sun-3; these are quite different than the Sys V COFF
+object format used on the 386i.
+
+---------------------
+Moved everything back to the 386i, rebuilt the shared library, and relinked
+the system.  Merged in all recent changes from tucana.  (1/3)
+
+---------------------
+Begin changes to better support layered external software.  (1/28)
+
+unix/os/zgtenv.c
+sys/etc/environ.x
+sys/etc/envgets.x
+	ZGTENV, ENVFIND, and ENVGETS were changed to make it possible to
+	discriminate between undefined environment variables, and variables
+	that have a null string value.  ERR is returned if the variable does
+	not exist; 0 if exists but has a null value.  Since most programs
+	do a <= 0 test to check for valid environment definitions, this should
+	be a fairly safe change, although some programs may be affected
+	(i.e., any program that only does an == 0 test).  (1/28)
+
+sys/libc/cenvget.c
+pkg/cl/builtin.c
+	Minor changes to allow for null valued environment variables.  (1/28)
+
+sys/fio/vfntrans.x
+	Added a new feature to virtual filename translation, to provide general
+	environment symbol replacement during translation.  This was needed to
+	support multiple architectures, e.g., different version of the PKG and
+	LIB directories, but it is a general facility which will be useful
+	for multiple versions of other types of directories and files as well.
+
+	For example, one might make the following definitions:
+
+		set arch = ""
+		set bin = iraf$bin(arch)/
+		set lib = iraf$lib(arch)/
+
+	Which become iraf$bin/ and iraf$lib/ by default.  If arch is defined
+	as, for example, ".ffpa", then we have iraf$bin.ffpa/ and likewise
+	for lib.  The default case, where arch is the null string, is what
+	required the revisions discussed earlier.  (1/28)
+
+-----------------
+The following revisions were made all together over a period of a couple
+of weeks and summarized on 2/21.
+
+pkg/system/help/helpdb.x
+pkg/system/help/helpdir.x
+pkg/system/help/modlist.x
+pkg/system/help/modtemp.x
+pkg/system/help/prdir.x
+pkg/system/help/prfile.x
+pkg/system/help/prhlpblk.x
+pkg/system/help/prsummary.x
+pkg/system/help/t_help.x
+pkg/system/help/tlist.x
+pkg/system/mkhelpdb.par
+	1. The compiled help database files are now stored externally in a
+	machine independent format.
+
+	2. HELP now permits multiple compiled help database files.  The
+	parameter / environment variable `helpdb' is now a file template
+	(e.g., a comma delimited list of files) specifying the helpdb files
+	to be combined to produce the composite help database to be used
+	at runtime.  HELP takes a little longer to respond the first time
+	while it is reading and combining all the files, but once the
+	composite database has been generated in-core all is as it was before.
+	If any of the helpdb files are modified, or if new files are added,
+	the incore composite database is automatically regenerated.
+
+	It is still necessary that all package names be unique; this
+	restriction will be removed in a future implementation but it is
+	too difficult to fix in the current program.
+
+dev/help.db -
+lib/helpdb.mip +
+	The old core sytem help database file dev$help.db has been deleted
+	and replaced by the new machine independent file lib$helpdb.mip,
+	which now contains only entries for core system help modules.
+	Each external layered package (noao, local, stsdas, etc.) will
+	have its own lib/helpdb.mip.
+	
+mkpkg
+	1. All references to the noao and local packages have been removed
+	from the root mkpkg file.  Layered packages are maintained
+	independently of the core system and separate mkpkg sysgens,
+	etc, are required for each package.
+	2. The `stripall' entry has been deleted leaving only `mkpkg strip'
+	for stripping the system.
+
+noao/README
+	Completely new README for the reorganized NOAO package.
+
+noao/bin +
+noao/bin.i386 +
+	NOAO now has its own BIN directory.  For Sun/IRAF, `bin' is a
+	symbolic link to the bin directory for the architecture for which
+	the system is currently configured, bin.i386 on my development
+	system.
+
+noao/lib/helpdb.mip +		compiled help database
+noao/lib/mkpkg.inc +		global mkpkg definitions for noao
+noao/lib/mkpkg.sf.I386 +	special file lists for various architectures
+noao/lib/mkpkg.sf.SUN3 +		"
+noao/lib/mkpkg.sf.SUN4 +		"
+noao/lib/root.hd +		root help directory for the noao packages
+noao/lib/strip.noao +		stripper file for the noao directories
+
+	The above files were added to noao$lib, the global library for the
+	NOAO packages.  All files are maintained in a machine independent
+	format and may be included in distributions.  Files like the mkpkg.*
+	include machine dependent information but are easily modified or
+	extended to support new architectures - there is no better way,
+	one must have things like special file lists for different
+	architectures (if there isn't one, as in a new port, the application
+	will still sysgen but there is a real possibility of undetected
+	compiler bugs).
+
+	The helpdb.mip is machine independent as well, and should be generated
+	by the developers of an exportable package, and included in the
+	distribution.  The ".mip" extension tells the HSI utilities such as
+	WTAR that it is a machine independent file and can be included in
+	"source only" archives.  It can be generated under V2.8 with a command
+	such as
+
+	    cl> mkhelpdb helpdir=noao$lib/root.hd helpdb=noao$lib/helpdb.mip
+
+	By default, MKHELPDB will generate the core system help database.
+
+noao/mkpkg
+	Added a `mkpkg strip' entry.  Other entries will need to be added
+	in the future to support multiple architecture switching for Sun/IRAF.
+
+noao/noao.cl
+	Added the following lines to the noao.cl file:
+
+		set	noaobin = "noao$bin(arch)/"
+		package	noao, bin = noaobin$
+
+	The bin= argument to package is required to tell the CL that noao
+	has its own bin directory and is discussed below.  The `noaobin'
+	definition permits user redefinition of the noao BIN directory,
+	as well as specification of the architecture for all packages
+	via the environment variable `arch', which is defined in terms
+	of `mach', which defines the machine architecture.
+
+pkg/cl/bkg.c
+pkg/cl/builtin.c
+pkg/cl/exec.c
+pkg/cl/main.c
+pkg/cl/prcache.c
+pkg/cl/task.c
+pkg/cl/task.h
+	The CL was modified to generalize the BIN directory scheme.  Formerly
+	executables could be stored either in the package directory or in BIN.
+	The same is true now except that there can be multiple BIN directories.
+	By default bin is iraf$bin/.  This may be overridden for a package by
+	specifying the package bin directory with a bin=bindir argument to
+	the PACKAGE directive (see example above).  The new bin will be used
+	for the referenced package and all subpackages of that package, unless
+	overridden by another PACKAGE directive.  Note that no bin-path
+	searching is involved; the CL never has more than two directories to
+	look in for a given executable, since every package has a well defined,
+	unique BIN directory.
+
+sys/etc/envgets.x
+sys/etc/environ.h
+sys/etc/environ.x
+sys/etc/envscan.x
+	1. ENVFIND will now return ERR if the named variable does not exist,
+	and a string length of zero if the variable exists but has a null
+	string value.
+	2. ENVSCAN now permits newline to be escaped in the value field,
+	permitting arbitrarily long value strings.  Leading whitespace is
+	discarded in each continuation line, allowing continuation text to
+	be left justified at any arbitrary column for readibility.
+	3. ENVSCAN recognizes both SET and RESET.
+	4. ENVSCAN now supports the "set @filename" syntax for inclusion
+	of other files containing set environment definitions.  All non
+	set or reset statements are ignored.
+	5. The max size value string is increased to 512 chars.
+
+	All of these changes hold also for the HSI version of ENVSCAN
+	(see the bootlib.envinit.c notes below).
+
+sys/fio/vfntrans.x
+	General environment variable replacement is now supported within
+	virtual filenames via the syntax "(envvar)", which is replaced
+	by the value of the named environment variable "envvar".  This is
+	different from logical directory replacement which replaces
+	everything to the left of the $.  (Perhaps we should have simply
+	used the unix symbol replacement syntax in the first place, but
+	it is too late to change now).  For example,
+
+		set mach = f68881
+		set arch = .(mach)
+		set bin = iraf$bin(arch)/
+
+	This point of this facility is that it allows any field of a filename
+	to be parameterized with an environment variable.  If the named
+	variable does not exist the null string is used.
+
+sys/imio/iki/ikiopen.x
+sys/libc/cenvget.c
+	Replaced an "envfind() == 0" by "envfind() <= 0" to reflect the fact
+	that ENVFIND can now return a negative value.
+
+unix/boot/bootlib/mkpkg
+unix/boot/bootlib/bootlib.h
+unix/boot/bootlib/osfn2vfn.c
+unix/boot/bootlib/vfn2osfn.c
+	The UNIX/IRAF HSI has been modified to use VOS filename mapping,
+	to facilitate use of the zzsetenv.def and extern.pkg logical directory
+	definitions, as well as all the other semantics of general filename
+	mapping.  Note that this requires use of libsys.a (etc.), but it
+	was done in such a way that if the library does not exist, bootstrap
+	filename mapping is used.  VOS filename mapping is used only if the
+	environment variable NOVOS is not defined at HSI bootstrap time; this
+	variable is defined in the file hlib$irafuser.csh which is assumed
+	to be referenced at login time by the account of whoever is doing
+	the bootstrap (normally user iraf).
+
+	A true bootstrap is performed with VOS filename mapping disabled,
+	and then repeated once a sysgen has been performed to generate the
+	VOS system libraries.  The HSI bootstrap filename mapping facilites
+	are adequate to compile the VOS but do not support external layered
+	packages.
+
+unix/boot/bootlib/envinit.c
+	This routine is used by the HSI to read the zzsetenv.def file.
+	This cannot be done with the VOS, even when VOS filename mapping
+	is in use, because the VOS routine envscan uses FIO (the filename
+	mapping primitives are much lower level, being layered on the kernel).
+	I made all the same changes as for ENVSCAN above, so that the
+	environment variables defined in hlib$extern.pkg will be defined
+	in the HSI.
+
+unix/boot/bootlib/osfpathname.c
+	1. Modified to avoid the null filename bug that appeared in VMS/IRAF
+	long ago (VMS/IRAF also uses VOS filename mapping).
+	2. Fixed a second bug that would probably only affect UNIX/IRAF.
+	The filename ".." was not being mapped properly on UNIX/IRAF, whereas
+	it worked fine on VMS/IRAF.  This was because on UNIX/IRAF the call
+	to vfn2osfn to translate the ".." to the pathname of the previous
+	directory, whereas on VMS/IRAF all it would do is pass it on, to be
+	used in the later call to ZFSUBD.
+
+unix/boot/bootlib/ossysfile.c
+	Added support for an applications defined system library search path,
+	e.g., for XC command line -llib library references, or <file.h> global
+	include file references.  LIB, HLIB, and any other system libraries
+	are searched first, followed by any package libraries as specified
+	by the environment variable `pkglibs'.  The latter is defined in
+	extern.pkg and this mechanism is intended as a way of extending the
+	global library mechanism to support applications libraries.  There is
+	a flaw - a search path opens the possibility of file name collisions,
+	resulting in the wrong file being used.  At least this will be obvious
+	if it occurs, and the search path is the simplest mechanism in this
+	case.
+
+	This HSI level library search path mechanism should not be confused
+	with the IRAFULIB facility used in UNIX/IRAF.  Any IRAFULIB directories
+	are searched *before* the system libraries, allowing custom versions
+	of system library files for testing or development purposes.  In the
+	case of the `pkglibs' the system libraries are searched first, with the
+	full search order being the IRAFULIBs, followed by the system libraries
+	(LIB, HLIB, and also BIN, bin.`mach` etc. for Sun/IRAF), and lastly
+	the package libraries in the order in which they appear in pkglibs.
+	There should be minimal execution time penalty from adding pkglibs
+	searching, since most global file references will be satisfied early
+	in the search by a system library.
+
+unix/boot/bootlib/osgetenv.c
+	Added VOS and NOVOS cases.  The VOS case calls ENVFIND to lookup
+	environment names.  This is required to make the environment used
+	for VOS filename mapping available in the HSI utilities, e.g.,
+	in mkpkg.
+
+unix/boot/mkpkg/mkpkg
+unix/boot/generic/mkpkg.sh
+unix/boot/mkpkg/mkpkg.sh
+unix/boot/rmbin/mkpkg.sh
+unix/boot/rmfiles/mkpkg.sh
+unix/boot/rtar/mkpkg.sh
+unix/boot/spp/mkpkg.sh
+unix/boot/spp/mkxc.sh
+unix/boot/spp/xpp/mkpkg.sh
+unix/boot/wtar/mkpkg.sh
+	All these files had to be modified to parameterize the list of
+	libraries to be used to link HSI executables.  Formerly libboot
+	and libos were being referenced explicitly, but now that the HSI
+	can be linked either VOS or NOVOS, the list can also include
+	libsys and libvops.  The parameter is the unix environment variable
+	HSI_LIBS defined in hlib$irafuser.csh.
+
+unix/hlib/clpackage.cl
+unix/hlib/clpackage.hd
+	Removed all references to local, noao, and stsdas.  External packages
+	now have their own root help directories and help database files, so
+	no entry in the clpackage.hd is required.  The external packages are
+	picked up by clpackage.cl by the following statements:
+
+		# Define the external (user-configurable) packages.
+		cl < hlib$extern.pkg
+
+	which executes the TASK statements in the extern.pkg to define the
+	external packages.  The environment variables in extern.pkg will
+	already have been defined by the zzsetenv.def @extern.pkg include,
+	so they are reset harmlessly when extern.pkg is reinterpreted by
+	the CL.
+
+unix/hlib/extern.pkg +
+unix/hlib/zzsetenv.def
+	1. Removed all references to noao, local, and stsdas from zzsetenv.def,
+	replacing these by the statement
+
+		set @hlib$extern.pkg
+
+	which includes set (actually reset) statements defining the root
+	directory of each external package.
+
+	For HELP, deleted the entries for helpdir and helpdb.  The helpdir
+	environment variable is no longer used, and helpdb has been moved
+	to extern.pkg.
+
+	2. Added the file hlib$extern.pkg, which is the sole link between the
+	core system and external packages.  To install an external package,
+	ALL that should be required is to make an entry in this file, after
+	reading the files onto disk (a mkpkg at the package root will also
+	be required if the package is distributed in source only form).
+	To deinstall a package, all one need do is comment out or delete
+	the related entries in extern.pkg, and backup and delete the external
+	package directory tree.  The core iraf system can be updated without
+	affecting external packages.
+
+	These things are possible ONLY if we strictly localize package files
+	to package trees, i.e., do not install library files and executables
+	from an external package in core system directories, do not rebuild
+	a central help database file, etc.  A further major advantage for
+	NOAO is that we can easily maintain private LOCAL packages, have
+	STSDAS on disk for our users, etc., without making modifications to
+	our export systems which would affect our distribution tapes.
+	By localizing the changes required to interface an external package
+	to a single file, we need only replace that one file to make a
+	distribution tape from one of our master systems.
+
+	For software maintenance purposes, developers should assume that ONLY
+	the root directory of their package tree is globally defined in the
+	HSI, and use only references such as "noao$lib/", "-llib", or
+	"<file.h>" in their applications (any VOS pathname relative to the
+	package root is acceptable).  Note that a package global library
+	may be set up by adding the path of the library directory (e.g.,
+	"noao$lib/") to the `pkglibs' entry in the extern.pkg.
+
+	Additional logical directories may be defined in the global package
+	mkpkg.inc and used in mkpkg files, but these logical directory names
+	will not be propagated to XC hence cannot be used in include file
+	references etc.  Additional environment variables could in principle
+	be added to the entry for the package in the extern.pkg, but I would
+	like to keep the interface as small as possible, localizing all
+	package information in the package itself as far as possible.
+
+	VMS/IRAF users should note that since XC executes in the context of
+	MKPKG in VMS/IRAF, mkpkg definitions may be propagated to XC (I
+	haven't tested this), but to make use of this side effect of how XC
+	is implemented in VMS/IRAF would be nonportable.
+
+unix/hlib/gripes.cl
+unix/hlib/gripesfile-
+	Commented out the code which appends gripes to the gripesfile, and
+	deleted the gripesfile.  We will use only electronic mail to enter
+	gripes from here on.
+
+unix/hlib/irafuser.csh
+	1. Added NOVOS and HSI_LIBS entries to define whether or not VOS file
+	name mapping is to be used in the HSI, and to list the libraries
+	to be searched to link HSI executables.  If libsys.a does not exist
+	NOVOS is automatically set, hence bootstrapping UNIX/IRAF on a source
+	only system will automatically generate the HSI without the VOS.
+	Redoing the bootstrap once the VOS is compiled will cause the HSI
+	to be rebuilt with VOS filename mapping, as may be required to compile
+	any external packages (the core system does not require VOS filename
+	mapping in the HSI).
+
+	2. Added a couple of utility command aliases.  `mkv' runs mkpkg with
+	the link flags set in such a way that the resultant executable has
+	symbols for the transfer vector entries.  This is necessary to be
+	able to see what VOS routines are being called from an application
+	when debugging (otherwise one sees an offset from vshlib_).  Perhaps
+	I should make this the default on our development system, even though
+	it almost doubles the size of the symbol table in each executable.
+
+	A second utility definition `mkz' runs mkpkg, linking without the
+	shared library (like xc -z).  These name may change but they should
+	serve to illustrate how to use the linker options for debugging.
+
+unix/hlib/libc/knames.h
+	Made several new entries.
+
+unix/hlib/login.cl
+	Added commented out commands to load the `noao' and `tv' packages.
+
+unix/hlib/mkpkg.inc
+unix/hlib/mkpkg.sf.I386
+unix/hlib/mkpkg.sf.OS4
+unix/hlib/mkpkg.sf.S34
+unix/hlib/mkpkg.sf.SUN3
+	1. In the mkpkg.inc, changed the FPU definition to MACH, since FPU
+	is too restrictive a name for what we use this switch for; MACH for
+	machine architecture comes closer.  Possible values of MACH are
+	f68881, ffpa etc. for Sun-3 hardware options, sparc for the Sun-4,
+	i386 for the Sun-386, vax for the VAX, and so on.  This switch is
+	used to select default compile and link flags, determine which
+	special file list to load, etc., allowing the generation of relatively
+	machine independent mkpkg definition files.
+
+unix/hlib/strip.iraf
+	1. Changed the name from stripper to strip.iraf (strip.noao etc. for
+	other packages.).  Deleted the stripall since I have never been happy
+	with what that level of stripping anyhow.  Still need to review the
+	action of the strip file to ensure that everything that can be deleted
+	is being deleted, to add something to strip executables on unix
+	systems, and so on.
+	2. Deleted all entries for the noao and local packages.  These packages
+	now have their own strip files.
+
+unix/os/zfacss.c
+	Modified to test for the null filename and return NO in that case.
+
+unix/os/zgtenv.c
+	Will now return ERR for a undefined variable, and 0 for a defined
+	variable with a null string value.
+
+unix/os/zmain.c
+unix/os/zshlib.c		[DEBUGGING POINTER]
+unix/os/zzstrt.c
+	Added a new command line switch "-w" to the zmain.  Currently this is
+	only used in Sun/IRAF.  Specifying -w causes the shared image text to
+	be mapped with write permission, allowing breakpoints to be set in
+	VOS routines.  This cannot be done by default because one has to
+	reserve swap space for the entire shared image text segment in order
+	to have write (copy on modify) permission.
+
+unix/shlib/mkpkg
+	Fixed a bug in the code used to delete old versions of the S.e shared
+	image files in BIN.
+
+--------- (end of accumulated notes) ------------
diff --git a/doc/ports/notes.irix b/doc/ports/notes.irix
new file mode 100644
index 00000000..487d3093
--- /dev/null
+++ b/doc/ports/notes.irix
@@ -0,0 +1,158 @@
+Begin IRIX/IRAF port/upgrade.
+Thu May 30 13:31:15 MST 1996
+------------------------------------------------------------------------------
+Host - almond (WIYN remote observing host)
+IRIX almond 5.3 11091812 IP22 mips
+150 Mhz MIPS R4400
+64 Mb RAM
+Indy 8-bit
+Vino video
+A2 Audio Processor
+IRIX 5.3
+
+Graphics board 0 is "NG1" graphics.
+	Managed (":0.0") 1280x1024 
+	8 bitplanes, NG1 revision 3, REX3 revision B, VC2 revision A
+ 	MC revision C, xmap9 revision A, cmap revision C, bt445 revision A
+	Display 1280x1024 @ 72Hz, monitor id 2
+
+Note - use "iiv" to view CD-ROM documentation.
+------------------------------------------------------------------------------
+The following are notes from the IRIX 5.3 port, which was done mostly during
+June 1-2 1996.  Sun Jul  7 13:01:50 MST 1996
+
+./local/notes.irix		+
+
+./local/.4Dwmrc
+./local/.cshrc
+./local/.exrc
+./local/.login
+	Customized for IRIX.  This includes a workable desktop via .4Dwmrc.
+
+./unix/hlib/extern.pkg
+	Minimal package list for the port.
+
+./unix/hlib/install
+	Changed "mach" (the HSI machine type) from ssol to irix.
+
+./unix/hlib/irafuser.csh
+	1. MACH is generated from uname differently than for Solaris.
+	2. IRIX/IRAF compile flags are -/DSYSV -/DSOLARIS.
+	3. IRIX/IRAF link flags are -lelf -lfpe.
+	4. No -Bstatic flag for IRIX.
+
+./unix/hlib/login.cl
+	FC calls XC directly in the conventional manner rather than using
+	hlib$fc.csh.
+
+./unix/hlib/mkiraf.csh
+./unix/hlib/mkpkg.inc
+./unix/hlib/motd
+	Minor customization.
+
+./unix/hlib/mkpkg.sf.IRIX	+
+	Pretty standard, did need to increase size of compiler tables for
+	fmtio$evvexpr.x and cl$ytab.c.
+
+./unix/os/irafpath.c
+	Added "irix" for #ifdef sgi.
+
+./unix/os/mkpkg
+./unix/os/mkpkg.sh
+	Deleted enbint.s (a solaris special routine).
+	Modified to use $CC to compile the assembler files, as we have done
+	recently on other platforms (allows compile flags to be used).
+
+./unix/os/zawset.c
+	Minor compile time customization (nuke solaris #define RLIMIT_RSS
+	RLIMIT_VMEM).  Poking arount it appears that IRIX handles the
+	set/getrlimit stuff ok.
+
+./unix/os/zxwhen.c
+	The error handler code was remarkably similar to Solaris (i.e. SYSV
+	I suppose), down to the codes for the arithmetic exceptions.  All I
+	had to change was a sigaction structure definition: solaris uses
+	sig.sa_sigaction, IRIX uses sig.sa_handler.
+
+./unix/os/zzstrt.c
+	Include <sigfpe.h> for IRIX.
+	The IEEE exception handling initialization for this platform consists
+	of:
+
+	>       sigfpe_[_UNDERFL].repls = _ZERO;
+	>       handle_sigfpes (_ON, _EN_OVERFL|_EN_DIVZERO |_EN_INVALID,
+	>           0, _ABORT_ON_ERROR, 0);
+
+	This enables exceptions for overflow, divide by zero, and invalid
+	operand.  It is also supposed to be possible to arrange for things
+	to underflow to zero, however it is not clear if it is possible to
+	do this without enabling the underflow exception.  I didn't have
+	time to look into it further, and the system passes all tests with
+	the underflow handling disabled.
+
+./unix/as.irix/zsvjmp.s
+	The DECstation (MIPS) version works also for IRIX - the SGI of course
+	uses a MIPS chip.
+	Checked size of SETJMP/ZSVJMP buffer; the Solaris value is larger than
+	needed for IRIX so I left it unchanged.
+
+./unix/boot/mkpkg/host.c
+	The ELF library code for solaris works fine for IRIX too.  The only
+	problem encountered was that during library updates the link mkpkg
+	creates to the actual library would be clobbered by the updated
+	library file which would subsequently be deleted, causing the mkpkg
+	to be a no-op.  Linux/IRAF had the same problem so I merged in the
+	"resolvefname" code from Linux/IRAF.  This takes a library name and
+	checks to see if it is a link and keeps this up until a fully 
+	resolved filename is obtained.  This is then used to perform the AR
+	updates.
+
+./unix/boot/spp/xc.c
+	Sysbindir (default compiler location) is /usr/bin.
+	System libraries are the conventional U77,F77,I77,U77, plus fpe, isam.
+	Implemented the -// syntax for passing on host switch arguments.
+
+./unix/boot/spp/xpp/xppcode.c
+	Had to declare errflag an external.
+
+./unix/gdev/sgidev/sgi2uapl.c
+./unix/gdev/sgidev/sgi2uhpgl.c
+./unix/gdev/sgidev/sgi2uimp.c
+./unix/gdev/sgidev/sgi2uqms.c
+	Various local variables named "sgi" caused problems here.  Changed
+	the names to "sgip".
+
+./dev/hosts
+	Replaced with newer version.
+
+./dev/pix.imh
+	Someone modified this on Tue 17:56:52 04-Jun-96.  I don't know who or
+	why, but the image appears the same.
+
+./dev/tapecap
+	Modified for IRIX 5.3.  The default configuration should provide
+	variable block size support ("v" in device name) so long as the
+	host level support for the device permits it.  See "man tps" for
+	information on the IRIX SCSI tape driver.
+
+./pkg/cl/globals.c
+./pkg/cl/grammar.h
+	Added global declarations for parse_state, proc_script, parse_pfile,
+	and changed the declarations in grammar.h to extern.
+
+./unix/boot/spp/xc.c.NOSHARE
+./unix/shlib/README
+./unix/shlib/mkpkg
+./unix/shlib/mkshlib.csh
+./unix/shlib/so_locations
+	The shared library code in IRIX looked remarkably similar to that in
+	DEC Alpha OSF/1 (including quickstart etc.) so I did an experiment
+	to implement shared libraries for IRIX/IRAF.  This pretty much worked,
+	but I had to set it aside due to some obscure runtime error occurring
+	during process startup, which I didn't have time to investigate.
+	The code is still there in case we get time to go back and look into
+	this further.
+
+------------------------------
+Fri Jul  5 18:04:26 MST 1996
+IRIX/IRAF distribution built.
diff --git a/doc/ports/notes.linux b/doc/ports/notes.linux
new file mode 100644
index 00000000..241dc3b0
--- /dev/null
+++ b/doc/ports/notes.linux
@@ -0,0 +1,325 @@
+Begin Sat Apr 29 21:05:25 MST 1995  Linux 1.1.93.
+Files actually set up initially last weekend.
+-----------------------------------------------------
+
+unix/hlib/irafuser.csh MACH is "linux", architecture is "linux" compiler is
+	GCC.  Set up generic compile and link flags for the moment.  (4/23)
+
+unix/hlib/mach.h
+	x86 boxes are little-endian so all the SWAP flags are set to YES
+	on this platform.  (4/23)
+
+unix/os/mkpkg.sh
+	1. Was using HSI_LIBS to link alloc.e, but the iraf libraries are not
+	used in this file.  Changed to use HSI_OSLIBS instead.
+	2. Deleted the reference to as$enbint.s, not used for Linux.  (4/29)
+
+(linux)
+	1. After booting typing "cd unix", which uses cdpath to go to
+	$iraf/unix, would hang the xterm.  The problem went away following
+	a reboot.
+	2. Got a bunch of failures to compile when doing a reboot of the 
+	HSI, no apparent reason (message said couldn't write .o files).
+	Started another reboot and the problem went away.
+	3. Manpages can be very brief and do not fully specify system or
+	library routines.
+	4. Problems with cut and past, not resolved.
+
+unix/os/zfiomt.c
+	The structure "mtpos" used in this file redefines a different
+	structure defined in <sys/mtio.h>.  Changed zfiomt.c to use _mtpos
+	for its internal structure.  (4/30)
+
+unix/os/zfiomt.c
+	Linux doesn't have SIGEMT.  Changed to use SIGABRT.  (4/30)
+
+unix/os/mkpkg
+	Commented out enbinit.s.  (4/30)
+
+unix/boot/gdev/sgidev/sgi2uapl.c
+	Added a #undef SOLARIS to cause the routine to use gethostname()
+	rather than sysinfo which is implemented differently in Solaris 
+	and Linux.  (4/30)
+
+unix/hlib/install
+	Minor changes for Linux.  (4/30)
+
+unix/hlib/motd
+	Modified for Linux/IRAF V2.10.4BETA.  (4/30)
+
+unix/boot/mkpkg/host.c
+	Added #undefs for SYSV and i386 to cause this code to use ranlib.
+	(4/30)
+
+----------------------------------------------
+Completed HSI bootstrap.  (4/30)
+
+unix/hlib/mkpkg.inc
+unix/hlib/mkpkg.sf.LINUX	+
+	Modified mkpkg.inc for Linux, no compile/link flags of note yet at
+	this point.  Add a base special file list for Linux, currently only
+	references the C files in AS.  (4/30)
+
+unix/boot/spp/xc.c
+	Modified the code which compiles "other" files (not .x or .f) to
+	explicitly compile only .c and .s files.  This prevents unrecognized
+	command line flags from confusing the code and causing a command to
+	be issued that contains nothing to be compiled.  (5/03)
+
+(linux)
+	Another Linux oddity with libraries: on linking the CL _zawrim_ would
+	always come up undefined, even though an "ar tv" of libds.a showed
+	it looked fine.  Deleting zawrim.o and updating the library made the
+	problem go away.  (5/03)
+
+unix/os/zfiond.c
+	Added a #include <sys/time.h>, needed to pick up the FD_SET etc.
+	definitions on Linux.  (5/03)
+
+unix/as.linux/ieee.gx
+	Installed the little-endian version (from OSF/1).  F2C complained
+	about statements following DATA so I had to rearrange the code in
+	ieemap$t a bit.  (5/03)
+
+unix/hlib/cl.csh
+unix/hlib/fc.csh
+	Deleted the uname stuff and just fixed MACH=linux.  Added linux
+	case code where needed.  (5/03)
+
+
+unix/as.linux/zsvjmp.s
+	I had to change the reference to `__setjmp' to `___setjmp' (3 under-
+	scores) to get the routine to call the function `__setjmp'.  (5/03)
+
+unix/os/zawset.c
+unix/hlib/libc/kernel.h
+	Installed the zawset (begmem) changes from tucana.  (5/03)
+
+
+Begin Sat Jul 22 20:24:16 MST 1995
+The Linux port was set aside for a time while IRAF V2.10.4 was prepared
+and our Linux system was upgraded to Slackware 2.3 and Linux 1.2.11.
+The port is being redone using Solaris/IRAF V2.10.4.  The above revisions
+will be merged before we resume taking notes.
+---------------------------------------------------------------------------
+
+unix/hlib/spy.cl
+	Added a Linux clause and set this to use "ps -axuf" for Linux.  The
+	"-f" option provides a parent/child ordering similar to sps.  (7/22)
+
+unis/os/zawset.c
+	Added an ifdef for Linux to cause it to uset {set|get}rlimit.  (7/22)
+
+unix/os/zgtime.c
+	Modified to use CLK_TCK (100 Hz), as on Solaris.  (7/22)
+
+unix/os/zpanic.c
+	Use SIGABRT on Linux rather than SIGEMT, which doesn't exist.
+	The Linux documentation doesn't specify which signals cannot be
+	caught, hopefully ABRT will do it.  (7/22)
+
+unix/boot/mkpkg/host.c
+	Linux uses the GNU "ar" to maintain object libraries.  This turns out
+	to have a bug which prevents it from properly updating a library which
+	is a symbolic link to the actual library.  The library is updated in
+	the current directory, and the symbolic link is replaced by the
+	updated library, hence the actual (remote) library is never updated.
+	To work around this a new internal function "resolvefname" was added
+	to host.c  This back traces any symbolic links and returns a fully
+	resolved library name.  (7/24)
+
+unix/os/zxwhen.c
+	I noticed during testing that when interrupting the cl or a task
+	run stand alone, while waiting for command input, that following
+	the interrupt processing the most recent block of input would be
+	reread and executed.  Evidently what happens is that Linux stdio
+	partially initializes the stdin file descriptor before the read,
+	and then never finishes initializing it since the read is interrupted
+	and never returns (in other words no critical section protection for
+	stdio).  The workaround was to extend the fcancel() macro in zxwhen
+	to reset both the input and output buffer pointers, and add a fcancel
+	for stdin to the error handler to cancel the input buffer if an
+	interrupt occurs.  (7/24)
+
+unix/os/zzstrt.c
+unix/os/zxwhen.c
+	These routines were further modified to implement exception handling
+	for Linux.  This turned out to be hard to do properly as about all
+	Linux provides is a simple signal() interface.
+
+	1. The first problem was that interrupts were being disabled after
+	the first interrupt, as signals are "one-shot" by default.  The fix
+	here was to re-register the signal handler after each signal, and
+	to reinitialize the FPU control register during process startup and
+	during exception recovery.
+
+	2. After getting some Intel hardware manuals and some time digging
+	around in the Linux kernel to see how signals are handled I finally
+	found that the kernel pushes a frame on the stack before entering the
+	user exception handler.  The EBP register can be used to get the
+	address of this frame.  This frame describes the cpu state at the
+	time that the exception occurred and includes the hardware trap
+	number.  This is sufficient to identify all system traps but only
+	identifies floating point exceptions to the coprocessor trap level.
+	The floating point unit status register has been cleared by the time
+	the user exception handler is entered and so far I haven't discovered
+	how to differentiate the floating point exceptions, but at least
+	things like the integer divide by zero and overflow exceptions are
+	properly diagnosed.  The kernel is saving the information on the
+	FPU status internally, but so far I haven't found out how to access
+	this information from the application.  (7/29)
+
+unix/boot/spp/xc.c
+	The f77 command on Linux, which is a shell script based on F2C,
+	erroneously returns an exit status of 4 when successfully compiling
+	a Fortran file.  This would cause commands such as "xc foo.x" to
+	fail to link the output program thinking that the compilation had
+	abort on an error.  To workaround this bug XC was modified to ignore
+	an exit status of 4 when calling f77 under Linux.  (7/30)
+
+unix/os/zgcmdl.c
+	Linux also uses xargc,xargv.  (7/30)
+
+dev/termcap
+	Added "lp" alias for "lpr", as used in zzsetenv.def.  (7/30)
+
+-------------------------
+Downloaded and built TABLES without incident.  (8/01)
+Built NOAO packages without incident.  (8/01)
+
+unix/os/zmain.c
+	Changed the call to exit() to _exit() for Linux.  I was having trouble
+	with tasks in NOAO and TABLES doing horrible things during process
+	shutdown (hanging up the console for minutes with the disk thrashing
+	heavily, or doing a panic shutdown).  Although I did not check it out
+	fully, this appeared to be due to an "onexit" feature of the GNU exit() calling
+	calling random parts of process memory with essentially unpredicable
+	results.  The simplest solution was to simply use _exit instead, which
+	avoids this feature.  (8/01)
+
+unix/hlib/f77.sh		+
+	Copied the default "f77" script that comes with Linux to $hlib/f77.sh.
+	The script was modified to eliminate the "f2ctmp_" prefix that it was
+	prepending to Fortran file names before compiling with GCC.  This
+	feature (used by the script to implement Fortran includes) breaks 
+	source code debugging since the file which is actually compiled has
+	the f2ctmp prefix and this file no longer exists after compilation.
+	This fix also eliminated the "exit 4" problem mentioned above in the
+	xc.c fix.  (8/02)
+
+unix/boot/spp/xc.c
+	Modified XC to use the f77.sh script as the Fortran compiler, instead
+	of "f77".  It will still fall back and use f77 if it can't find
+	f77.sh.  (8/02)
+
+unix/hlib/f77.sh
+	1. Modified so that the -w flag inhibits warning messages from both f2c
+	and gcc.  This is necessary to get rid of a few warning messages seen
+	when compiling the IRAF code which do not indicate any real problems.
+	2. Added a call to sed in the f2c call to workaround a bug in f2c
+	where -w fails to strip out all the lines of a multiline warning
+	message.  (8/02)
+
+-----------------
+Wed Aug 16 13:00:13 MST 1995
+System has been in testing since last thursday.
+
+dev/tapecap
+	Modified this file for Linux.  Linux has a nice tape interface
+	supporting variable block sizes, behavior is very standard, however
+	there is no support for compression or any non-generic tape features,
+	and the default maximum block size on a read is 32K.  (8/15)
+
+local/
+	Installed a Linux specific set of startup files for the IRAF
+	account.  (8/24)
+
+mkpkg
+noao/mkpkg
+	Added "linux" targets.  (8/28)
+
+unix/hlib/irafuser.csh
+	Added "-static" to the link flags for the HSI.  (8/28)
+
+unix/os/zfiotx.c
+	Added #ifdef LINUX code in a couple of places to cancel the input
+	stream if an interrupt occurs (workaround for same bug as in zxwhen
+	above).  (9/02)
+
+---------------------------------------
+Installed V2.10.4 patch1.  Bootstrap, sysgen-update.  (9/02)
+
+unix/hlib/install
+	Added "chmod -t /tmp" to allow multiuser deletion of files, e.g.
+	magtape lock files, in /tmp.  (9/03)
+
+local/*
+	Configured the login files for the IRAF account, including setting
+	up the window system.  Installed gzexe-compressed binaries for xgterm,
+	ximtool, and the tin newsreader in $iraf/local/bin.  Set up window
+	system to start up by default 5 seconds after logging in, using fvwm
+	as the window manager.  An "ADASS news" entry in the root menu accesses
+	the ADASS news using the tin executable provided.  (9/03)
+
+unix/boot/bootlib/osfiletype.c
+	Added ".gz" to the list of source file types.  (9/03)
+
+doc/rev2.hlp
+	Renamed this file to rev2.txt, it is not a help file.  (9/03)
+
+unix/hlib/strip.iraf
+noao/lib/strip.noao
+	Various minor enhancements and updates.  (9/03)
+
+bin.linuz		+
+noao.bin.linuz		+
+unix/hlib/cl.csh
+mkpkg
+noao/mkpkg
+	Added a new architecture "linuz", which is a gzexe (gzip compressed)
+	version of bin.linux.  (9/03)
+
+----------------------------------------------------------------
+V2.10.4 Linux/IRAF release cut.  (9/04)
+
+unix/hlib/install
+	Deleted reference to edsym.e, which is not used on Linux/IRAF.  (9/18)
+
+unix/boot/rtar/rtar.c
+	RTAR would immediately die on a segvio.  This was traced to the use
+	of a local variable "setuid" which evidently conflicts with some
+	Linux include file definitions.  Changed a number of local variables
+	in the program to static local variables and this fixed the problem.
+	(9/20)
+
+unix/hlib/f77.sh
+	Added a -b flag to allow calling f77 with the "-b i486-linuxaout" flag
+	to build a.out executables on ELF systems.  (1/03/96)
+
+unix/hlib/irafuser.csh
+	Added "-b -i486-linuxaout" to the HSI compile and link flags.  (1/03)
+
+unix/boot/spp/xc.c
+	Added "-b -i486-linuxaout" flags to all compile and link instances.
+	(1/03)
+
+unix/bin.linux/libf2c.a		+
+	Added a copy of the a.out version of libf2c.a to HBIN since this is
+	not present on Slackware ELF systems, and possibly other Linux
+	verisons.  (1/03)
+
+unix/os/mkpkg.sh
+	Changed the call to "as" to use $CC -c $HSI_CF instead, to cause any
+	platform specific flags to be used to assemble the files.  (5/29 1996)
+
+
+----------------------------
+TODO
+
+*** Provide sh/bash equivalent of irafuser.csh.
+
+Wed May 29 11:11:00 MST 1996
+	New version of spp/xpp/xppcode.c does not work on Linux - some problem
+	with tokens.  Using old version for now.
+
+
diff --git a/doc/ports/notes.mips b/doc/ports/notes.mips
new file mode 100644
index 00000000..c00dd6b0
--- /dev/null
+++ b/doc/ports/notes.mips
@@ -0,0 +1,398 @@
+# MIPS/IRAF alpha port.
+# System arrived on thursday 17 May.
+
+-----------------
+Configure UNIX (RISC/os 4.10)
+
+/etc/passwd
+/etc/hosts
+/etc/group
+/etc/fstab
+/etc/local_hostname
+/tucana/	+
+/u2		+
+	1. Usual local configuration of passwd,hosts,group,fstab.  NFS
+	mounted a number of tucana disks.
+	2. local_hostname is a MIPS special, used to set hostname (columba
+	in this case) and network parameters (netmask, broadcast).  (4/17)
+
+	[didn't do anything more with the system for several days...]
+
+/usr/adm/periodic/daily/10.makehosts.system
+/usr/hosts
+	Sometime later I discovered that /usr was 99% full and the directory
+	/usr/hosts contained over 8000 files totalling about 9 Mb.  There
+	turned out to be a crontab file which makes a link to rsh in /usr/hosts
+	for every node alias in /etc/hosts.  We like to keep a very large
+	hosts file around for reference, so this would end up producing an
+	enormous /usr/hosts.  It is not clear if /usr/hosts is needed; the
+	node name entries can be executed to rsh to the node so perhaps that
+	is what it is for.  Rather than disable the facility entirely, I
+	edited the makehosts script to make entries only for the local hosts.
+	(4/26)
+
+login customization
+	The MIPS is a nearly pure SysV UNIX machine with the default login,
+	which provides the SysV ls, ps, etc., the old unix kill, erase, etc.
+	characters for the terminal driver, and so on.  A bit of hunting
+	turned up the following interesting items.
+
+	/bds43/bin
+	/usr/ucb
+	    Contains 200 or so BSD commands which are no where else to be
+	    found, e.g., nroff, troff, lpr, head, etc., as well as BSD
+	    versions of popular commands like ls, stty (in some cases there
+	    are merely front ends to the SysV versions, like stty).
+
+	/usr/new
+	    Contains some interesting utilities, including LESS and PATCH,
+	    and a couple of things I hadn't seen before, VSAR (a screen
+	    oriented version of the SysV SAR) and VMSBACKUP (claims to be
+	    able to read VMS BACKUP tapes).
+
+	man pages
+	    PAGER can be defined as "less -cqm" to use less to page man
+	    pages.  There are two man programs, /bsd43/bin/man or /usr/ucb/man,
+	    which prints the BSD man pages, and /usr/bin/man, which prints
+	    the SysV man pages followed by other entries for the named topic,
+	    prompting each time the pager is exited.  Given the default search
+	    path, you have to type /usr/bin/man explicitly to get the SysV
+	    version.  
+
+	If the SysV STTY is used one needs to use "winsize" to set the
+	screen size for programs like LESS and VI.  (4/26)
+
+/usr/lib/cmplrs
+	This directory contains the runtime files for the compilers.  It
+	appears that the system as delivered by MIPS does not have the
+	latest (2.10) versions of the compilers installed.  The installed
+	versions are all 2.0.  I sent mail off to MIPS to see if we can
+	get the 2.10 compiler tape (we already have the 2.10 Fortran tape,
+	but this is useless on the MIPS without the 2.10 compiler backend
+	programs).  (4/26)
+
+/etc/printcap		+
+/usr/spool/*		+
+/etc/rc2.d/S01noao	+
+	Configured LPR for the noao devices.  (4/26)
+
+/usr/lib/tmac/tmac.s
+/usr/local/bin/itroff*	+
+/usr/local/bin/vpr	+
+/usr/local/bin/qdplot	+
+	Configured nroff/troff and the local noao troff and printer queues.
+	(4/26)
+
+/usr/lib/aliases
+	Installed the noao mail aliases file.  (4/26)
+
+------------------------
+Begin IRAF port to the MIPS.
+Start with DECstation/IRAF sources, since these are already set up to
+use the MIPS compilers.
+Using MIPS BSD43 programming environment.  (5/27)
+
+local/.login
+unix/hlib/cl.csh
+unix/hlib/irafuser.csh
+unix/hlib/libc/iraf.h
+unix/hlib/mach.h
+unix/hlib/mkpkg.inc
+	1. Set new iraf root.
+	2. In mach.h, change the byte swap parameters to NO.
+	3. Checked size of setjmp buffer; DECstation value is larger
+	than needed for MIPS, so leave it as is.  (5/27)
+
+bin.mips			+
+noao/bin.mips			+
+mkpkg
+unix/hlib/mkpkg.inc
+unix/hlib/mkpkg.sf.MIPS		+
+noao/mkpkg
+noao/lib/mkpkg.inc
+noao/lib/mkpkg.sf.MIPS		+
+unix/mkpkg.sh
+unix/setarch.sh			+
+unix/bin.mips			+
+unix/as.mips			+
+	Add support for architecture "mips".  (5/27)
+
+unix/os/irafpath.c
+unix/os/zgcmdl.c
+unix/os/zxwhen.c
+	1. irafpath.c and zgcmdl.c modified to discriminate between Ultrix
+	and RISC/os operating systems: #ifdef mips is true for both systems.
+	On a DECstation the architecture is known as "dsux", on a MIPS it
+	is "mips".
+	2. Modified zxwhen for the MIPS hardware exception codes.  (5/27)
+
+unix/boot/bootlib/osputenv.c
+	The MIPS does not have putenv, but it has setenv.  (5/27)
+
+unix/boot/mkpkg/host.c
+	The MIPS has COFF libraries, so disabled ranlib.  (5/27)
+
+unix/hlib/install
+	It turns out that when using the BSD version of CC, the include
+	files in /bsd43/usr/include are used rather than /usr/include.
+	Modified INSTALL to make an <iraf.h> link in both places (and
+	manually created the link in order to complete the bootstrap).  (5/27)
+
+-------------------
+Bootstrap successfully completed, except for alloc.c which failed to
+link.  Will take a look at that later.  (5/27)
+
+unix/boot/spp/xc.c
+	The MIPS is unusual in that it has two sets of compilers (or at
+	least compiler front-ends) and two sets of programming environments
+	for BSD and SysV.  For our purposes it is simplest to use the BSD
+	environment.  This necessitated a change to XC since we want to
+	use the versions of CC and F77 in /bsd43/bin rather than the SysV
+	versions in /usr/bin.
+
+	1. Modified "run" in XC to search /bsd43/bin before /usr/bin (we
+	should, of course, be using PATH instead).
+	2. Modified XC to link with F77 instead of CC.  Using CC is awkward
+	since the F77 libraries are hidden away in /bds43/usr/lib/cmplrs/...
+	(5/27)
+
+-------------------
+Begin sysgen.
+
+	The initial sysgen went well except for some problems with the F77
+	compiler, which was not installed properly when the system was set
+	up.  First I had to modify XC to use the /bsd43/bin versions of the
+	compilers (see above).  Even when this was done links would still
+	fail, due to the compiler being only partially installed.  I was
+	able to continue by faking a BSD F77 compiler by combining the 2.10
+	F77 front end and libraries with the cc2.0 back end.  The full compile
+	sysgen will have to be redone when the new compilers are properly
+	installed, and there is little point in pursuing any bugs until
+	this is done.  (5/27)
+
+math/deboor/mkpkg
+math/deboor/setdat.f		-
+math/deboor/setdat2.f		-
+math/deboor/setdat3.f		-
+	The DEBOORT math package turned out to have a set of files setdat.f,
+	setdat2.f, setdat3.f, all of which defined the same routine "setdat"
+	and which were being redundantly loaded into the library.  It turns
+	out that these routines are not part of the math library anyhow, and
+	are only used to generate test data for the test programs.  I moved
+	them to deboor/progs (the test programs source library) and deleted
+	the entries in the mkpkg file.  (5/27)
+
+sys/gio/gks/gcas.x
+	The MIPS librarian found another duplicate library entry here.  The
+	GKS emulation library has two files gca.x and gcas.x, both of which
+	define the same routine "gca".  Changed the gcas.x version to define
+	a subroutine "gcas" instead.  (These are integer and short versions
+	of the cell array routine - GCAS is a nonstandard IRAF extension to
+	GKS, which is not used anywhere to my knowledge).  (5/27)
+
+-------------------
+Sysgen complete.
+	
+	With these changes the first sysgen completed, except for x_images.e
+	which failed to link, probably due to the F77 compiler problems
+	discussed above.  Other than that the sysgen went remarkably well.
+	None of the problems we had with the MIPS compilers on the DECstation
+	were present on this system.  IRAF is up and running, minus IMAGES,
+	although from browsing the MIPS manuals I see that there are still
+	some subtle items to take care of.  (5/28)
+
+dev/hosts
+	Added an entry for node columba and tested iraf networking.  (5/28)
+
+unix/os/zmaloc.c
+	RISC/os uses the BSD 4.3 memory allocator, which allocates storage in
+	units that are a power of 2.  This can be very wasteful of space for
+	large buffers, so we don't want to use the default memory allocator.
+	MIPS provides a couple of other allocators as options, but I had
+	trouble using these with the BSD43 environment due to unresolved
+	symbols resulting from the SysV libraries not being searched.
+	The solution was to replace zmaloc.c by the version used on BSD 4.3
+	and Ultrix, which includes an older, simpler, and better behaved
+	memory allocator.  (5/28)
+
+unix/hlib/libc/iraf.h
+unix/os/zzstrt.c
+unix/os/zxwhen.c
+unix/os/zgcmdl.c
+unix/os/irafpath.c
+	Added a #define MIPS and a commented out #define DSUX.  This is more
+	direct than trying to use #ifdef mips (which is defined by the system)
+	since this is defined for both the MIPS and DECstation (at least) and
+	doesn't really tell us what system we are compiling for.  (5/28)
+
+MIPS bug
+	Running NM on a library with the output redirected causes a
+	segmentation fault when the process exits.  (cd /lib; nm *.a | ...).
+
+unix/os/zzstrt.c
+unix/os/zxwhen.c
+	Enabled the IEEE exceptions (overflow, divide by zero, and invalid
+	operand) for MIPS/IRAF processes.  Modified ZXWHEN to detect and
+	decode the floating point exceptions (this required doing bit tests
+	on the floating point control and status register).
+
+	To figure out how to do this I first did a "man -k ieee".  This
+	turned up a man page for fp[get|set][round|mask|sticky], which
+	looked like it would do the trick, except that evidently this routine
+	doesn't exist anywhere in the system (maybe it is a standard SysV
+	feature which MIPS doesn't support; the man page mentions the default
+	behavior on 3B systems).  By doing an "nm *.a | grep fp" on the system
+	libraries I eventually turned up set_fpc_csr/get_fpc_csr which is
+	what is actually implemented on the MIPS.  This seems to do the
+	trick; thus far, setting a nondefault FPCSR doesn't seem to introduce
+	any new problems.  (5/28)
+
+/etc/init.d/netdaemons
+/etc/rc2.d/S01noao
+/usr/local/bin/ntp		+
+/usr/spool/cron/crontabs/root
+	1. Had to add a command "route add default gateway 1" to allow network
+	access to the outside world.
+	2. Commented out the gated/routed daemons, which we don't need.
+	3. Installed a copy of NTP in local/bin, and set up cron to run it
+	once a day.  This sets the system clock from atomic clock at another
+	site, by requesting the time via the internet from a network time
+	daemon running on the remote node.  (Forgot to log it, but the timezone
+	had to be changed to MST a while back too).  (5/31)
+
+-----------------------
+New compilers (V2.10) installed and the system bootstrapped and fully
+recompiled from scratch.  Lacking a tape drive on the system, the compilers
+had to be installed manually from the raw distribution tape: I think I set
+up all the necessary links etc., but the installation was complex enough
+that it is difficult to be sure.  (6/19)
+
+Perusing the output of the sysgen, it appears that there were a number of
+problems with the V2.10 compile, whereas the sysgen with the V2.0 compilers
+went almost flawlessly.  At this point, from the nature of the errors I think
+they are real and not something induced by errors in the installation of the
+compilers.  Another problem was that the disk filled up during the sysgen,
+a dangerous problem which can cause errors such as zero length objects being
+inserted into libraries.
+
+At least one compiler bug was observed, this one harmless.  Some of the old
+NCAR and math library Fortran code contains statement functions.  The dummy
+variables in such statements functions result in "local variable X never used"
+warning messages.  (6/20)
+
+unix/hlib/mkpkg.inc
+	Added -Olimit 1024 to the default sysgen flags.  This sets the max
+	size in blocks of a procedure to be optimized.  With the default
+	value of 500 the compiler issued warnings for 7 files during the full
+	sysgen, and failed to optimize 9 procedures.  (6/20)
+
+math/deboor/core
+sys/gio/ncarutil/autograph/core
+sys/vops/core
+pkg/dataio/cardimage/core
+pkg/images/tv/cv/core
+pkg/images/geometry/core
+pkg/plot/core
+pkg/xtools/ranges/core
+pkg/xtools/core
+noao/imred/ccdred/src/generic/core
+noao/imred/vtel/core
+noao/onedspec/dispcor/core
+noao/twodspec/multispec/core
+	Discovered why the sysgen ran out of disk space - 12 Mb of core
+	files from compiler optimizer (uopt) crashes!   Deleted.  (6/20)
+
+----------------
+I tried recompiling a couple of the files that were associated with
+optimizer core dumps in the first sysgen, but could not duplicate the
+problem.  Started an incremental sysgen to compile the files skipped
+in the first sysgen, and this completed without any errors.  The system
+comes up and runs, ready for runtime testing.  (6/20)
+
+----------------
+/usr/local/bin/saoimage
+	Installed saoimage.  7.6 Mb left in /usr.  As there was so little
+	disk space, the RISC/os source for saoimage is currently in 
+	/tucana/tmp3/rooke/sao/riscos.  (6/21 SRo)
+
+/usr/man/manl/saoimage.man
+	Created /usr/man/manl, and placed saoimage manpage in it.  (6/21 SRo)
+
+----------------
+Resume testing on alpha port, 16 July 90.
+
+sys/vops/amov.gx
+	This routine could fail, corrupting the data array, in some cases
+	when the input and output arrays overlap.  The same problem exists
+	in standard V2.9 iraf except that in most iraf implementations,
+	a host optimized version of AMOV is used, hence the bug has not
+	been seen.  (7/16)
+
+unix/hlib/mkpkg.sf.MIPS
+	I added entries for the host optimized versions of AMOV, ACLR, etc.,
+	using the C versions in AS that use bcopy/bzero.  Unfortunately
+	it turned out that the MIPS version of bcopy also cannot be used
+	when the input and output arrays overlap in a certain way, hence
+	I had to copy out the entries for the AMOV and BYTMOV routines.
+	The optimized versions of the ACLR routines are still used.  (7/16)
+
+unix/as.mips/zsvjmp.o
+	I tried setting the address of MEM to zero and it worked on the MIPS.
+	The same code failed on the DECstation with a linker error.  (7/16)
+
+unix/os/zmain.c
+unix/os/zzsetk.c
+unix/os/zfiopr.c
+	Added a new facility to UNIX/IRAF for debugging interprocess
+	communication (IPC).  This feature will also be useful for debugging
+	tasks standalone, particularly in cases where a bug seen when the
+	task is run from the CL is difficult to reproduce when the task
+	is run standalone.  If LOGIPC is defined in the host environment,
+	the input and output IPC streams of each connected process with
+	process id PID are logged to the files PID.in and PID.out.  (7/18)
+
+unix/hlib/mkpkg.sf.MIPS
+	Added system/help/lroff/textout.x to the list of files requiring
+	compilation without optimization (actually it is the first such file
+	for this system).  Evidently the use of multiple entry points in
+	this procedure is running into an optimizer bug.  The argument "out",
+	which should be the address of "putline" was being transformed to
+	the address of "getline" somewhere in this routine, causing output
+	via textout to be discarded.  (7/18)
+
+sys/imfort/tasks/pcube.f
+	This file contained a subroutine containing the following sequence of
+	statements (irrelevant statements ommitted):
+
+		subroutine pcuber (pix, nx,ny,nz, i1,i2, j1,j2, k1,k2)
+		real	pix(nx,ny,nz)
+		integer	nx, ny, nz
+
+	On the MIPS, this produced a warning about nx/ny/nz already having
+	been declared.  Probably when the compiler processes the REAL
+	statement it assumes the parameters are type integer.  This seems
+	reasonable, so I moved the INTEGER card up before the REAL and the
+	warning went away.  (7/19)
+
+unix/os/zxwhen.c
+	While looking into a problem of a task aborting on a floating point
+	exception, I noticed that the IEEE exception being reported was
+	"floating inexact", which iraf does not enable.  It turned out that
+	both inexact and overflow were being signalled, but due to the way
+	the zxwhen code was written only the inexact was being reported.
+	Since we are not very interested in those exceptions which are not
+	enabled, I changed the code to check the exception bits for the
+	enabled exceptions before checking the others.
+
+	In this case the exception of interest was floating overflow, which
+	is occuring in the routine DET called by SPLOT.  It appears that
+	the matrix being input to this routine is garbage.  Since only the
+	one application is affected I will leave it to someone else to check
+	into it further.  (7/19)
+
+-------------
+Full system testing has been in progress for the past week or so.  Things
+looks pretty good.  One task is dying with an out of memory error; after
+hunting around a bit, I determined that the MIPS/SysV command used to
+monitor swap space usage is "swap l", which gives the free space in 512
+byte blocks.  (7/30).
diff --git a/doc/ports/notes.osf1 b/doc/ports/notes.osf1
new file mode 100644
index 00000000..09bb2399
--- /dev/null
+++ b/doc/ports/notes.osf1
@@ -0,0 +1,409 @@
+DEC Alpha OSF/1 V2.0 port.  Begun 28 December 1994.
+Based in part on the preliminary port done by Nelson Zarate of STScI.
+Starting point is the Solaris/IRAF system at V2.10.3.
+This platform is BSD-oriented with only partial SYSV support so we
+will use the BSD code in the HSI.
+--------------------------------------------------------------------------
+
+unix/hlib/motd
+	Edited the motd to indicate that the system is DEC-ALPHA/IRAF,
+	alpha test version.  (12/28)
+
+unix/hlib/irafuser.csh
+	Edited this file sufficiently to allow it to be sourced during login.
+	1. Set MACH to "alpha" using `uname -m`.
+	2. Set HSI flags to define "OSF1" for compile time ifdefs.  For the
+	moment set all other HSI compile and link flags to null.
+	3. Added some code to try to automatically determine $iraf if not
+	defined in the user's environment when the script is run.  A list
+	of standard root directories are searched for; these can be links
+	to the actual location and it will still work.  (12/28)
+
+unix/hlib/libc/spp.h
+	1. Set LEN_JUMPBUF to 2*(84+1) for the Alpha (the 2 is because IRAF
+	uses type int for the array while OSF1 uses type long).  (See also
+	hlib/config.h below).
+	2. Set XLONG to int (=32 bits) for this 64 bit machine.
+	3. Compiled osb/zzeps2.f and verified that the IEEE epsilons work.
+	4. OSF1 f77 evidently uses trailing underscores so it should not
+	be necessary to modify the Fortran/C name mappings.  (12/28)
+
+unix/hlib/libc/kernel.h
+	1. SIGFUNC is a pointer to void for OSF1.
+	2. OSF1 has bcopy but the manpage does not say whether it can handle
+	overlapping arrays, so we will use memmove/memset instead.  (12/28)
+
+unix/hlib/libc/setjmp.h
+	Comment out the #pragma unknown_control_flow, not support for OSF1
+	and there doesn't appear to be anything comparable.  (12/28)
+
+unix/os/getproc.c
+	Added an #ifdef OSF1 to cause the nlist-based code to be used.  (12/28)
+
+unix/os/irafpath.c
+	Added a #ifdef __alpha for the alpha architecture.  (12/28)
+
+unis/os/zfioks.c
+	Changed a number of #ifdef SOLARIS conditionals to #ifdef OSF1
+	where appropriate.  (for example use the select macros, updated
+	typing for socket calls).  (12/28)
+
+unis/os/zfiond.c
+	Modified to use the socket macros as above.  (12/28)
+
+unix/os/zgcmdl.c
+	Modified similarly to the Ultrix version, using the external __Argv
+	to pick up the host argument list.  (12/28)
+
+unix/os/zopdir.c
+	1. Modified to use <dirent.h>.  (12/28)
+	2. zopdir would pass back a pointer coerced to an int as the "file
+	descriptor" but this would fail on 64 bit systems where pointers
+	don't fit in 32 bits.  Modified the routine to allocate a kernel
+	file descriptor for the directory and pass back a normal fd instead.
+	(12/29)
+
+unix/os/zxwhen.c
+	Modified for OSF.  OSF1 has sigaction, so this is used for handling
+	the floating point exceptions (as with Solaris).  (12/28)
+
+unix/os/zzstrt.c
+	Modified to call the OSF1 function ieee_set_fp_control to enable the
+	invalid, divide by zero, and overflow exceptions.  (12/28)
+
+unix/os/zdojmp.c
+	Had to modify to treat jmpbuf as pointer to long rather than to int,
+	in order to retrieve the quadword address of the status variable
+	from jmpbuf[0] and to correctly compute jmpbuf[1].  (12/28)
+
+unix/as.alpha			+
+unix/as.alpha/zsvjmp.s		+
+	Set up an AS directory for the alpha/osf HSI.  Wrote an Alpha version
+	of zsvjmp.  The trick with this one, which I missed at first, was
+	to set register 27 (pv) to the address of setjmp before branching
+	into it.  The alpha procedure calling sequence assumes that the caller
+	of a procedure does this and it is required to set the global pointer
+	correctly for the procedure being executed.
+
+	The STScI version of zsvjmp (produced by technical support at DEC)
+	could not be used as it was just setjmp with the name changed.
+	The status argument used by zsvjmp was being ignored, and setjmp
+	was being called with the wrong jump buffer address.  (12/28)
+
+unix/hlib/mkpkg.inc
+unix/hlib/mkpkg.sf.OSF1		+
+	Set up a basic mkpkg.inc for OSF1.  (12/28)
+
+unix/.../mkpkg.sh
+	The OSF1 compilers refuses to produce a file with the extension ".e",
+	so all the HSI mkpkg.sh files were modified to use .E instead.  When
+	the executables are moved to $hbin the extension is changed to .e.
+	(12/28)
+
+unix/os/prwait.c
+	Like Solaris, OSF1 wait() wants an int exit_status argument.  (12/28)
+
+unix/os/zgtime.c
+	time() is of type time_t in OSF1.  (12/28)
+
+unix/os/gmttolst.c
+unix/boot/bootlib/ostime.c
+	These routines use ftime() which on OSF1 is only available in an
+	optional compatibility library.  Added a #ifdef OSF1 case which
+	uses localtime() instead of ftime to compute the timezone in
+	seconds west of GMT.  (12/28)
+
+unix/hlib/irafuser.csh
+	1. Set the default optimization level for Fortran files to -O3, to
+	disable inter-procedural optimization which causes a warning when
+	compiling files for a library.
+	2. Added a -lots reference to HSI_F77LIBS, this library is evidently
+	used internally by the Fortran compiler.  (12/28)
+
+unix/boot/wtar/wtar.c
+	Fixed a bug in WTAR involving coercion of a pointer to an integer
+	(line 536, bp = ...).  (12/28)
+
+unix/boot/spp/xc.c
+	Modified for OSF1.  The Solaris version pretty much works, about
+	all I had to modify was the list of Fortran libraries.  Also set
+	the default optimization to -O3 for f77 (-O1 for cc) and set up to
+	produce a .E output executable which is renamed to the .e version
+	internally.  (12/28)
+
+---------------------------
+Completed bootstrap.  (12/28)
+Attempted the first sysgen, numerous errors to be tracked down.
+
+unix/boot/spp/xc.c
+	Modified XC to call f77 with "-warn nounreachable" when compiling
+	SPP generated Fortran files.  Technically unreachable statements
+	occur naturally and harmlessly in some cases in SPP generated Fortran.
+	(for example in compile time conditionals).  (12/29)
+
+sys/gio/gks/gcas.x
+	Changed the procedure name from "gca" to "gcas".  There is already
+	another procedure in the same library called "gca".  "gcas" is
+	supposed to be the type short version.  (12/29)
+
+sys/gio/ncarutil/autograph/agrstr.f
+	Commented out statements number 901, 902: "no path to this statement".
+	These statements are never called as the code that calls them is also
+	commented out.  (12/29)
+
+sys/gio/ncarutil/autograph/agsave.f
+	Same thing, statement 901.  (12/29)
+
+sys/gio/ncarutil/conlib/consld.f
+	Commented out statement functions SCRTCH and IARVL.  These are never
+	called and result in a warning message.  (12/29)
+
+sys/gio/ncarutil/conrec.f
+	Commented out three lines around line 1226.  These lines were no
+	longer used because other code had been commented out, and were
+	resulting in a "Variable XX is used before it value has been
+	defined" warnings.  (12/29)
+
+sys/gio/nspp/sysint/encd.f
+	Commented out several lines that were no longer used and were causing
+	a "no path to this statement" warning.  (12/29)
+
+math/deboor/setdat2.f
+math/deboor/setdat3.f
+	This library contains three files setdat.f, setdat2.f, setdat3.f
+	all of which contain a procedure "setdat", causing library conflicts.
+	These routines are not really part of the library anyway and are
+	only used to generate data for examples in DeBoor's book, but to
+	avoid the library conflicts I changed the names of the second and
+	third procedures to setdt2, setdt3.  (12/29)
+
+pkg/xtools/icfit/icdosetupd.x
+	Problem with mixed type real and double arguments in calls to
+	the min and max intrinsic functions for xmin, xmax.  (12/29)
+
+pkg/cl/bkg.c
+pkg/cl/builtin.c
+pkg/cl/compile.c
+pkg/cl/config.h
+pkg/cl/debug.c
+pkg/cl/decl.c
+pkg/cl/errs.c
+pkg/cl/exec.c
+pkg/cl/gram.c
+pkg/cl/main.c
+pkg/cl/mem.h
+pkg/cl/modes.c
+pkg/cl/opcodes.c
+pkg/cl/opcodes.h
+pkg/cl/operand.c
+pkg/cl/param.c
+pkg/cl/prcache.c
+pkg/cl/scan.c
+pkg/cl/stack.c
+pkg/cl/task.c
+	The CL has long defined the dictionary and stack as arrays of
+	unsigned integer.  This causes problems on a 64 bit machine like
+	the Alpha where integer and pointer are not the same size. 
+	To avoid this problem a new type "memel" was defined in a typedef
+	in config.h.  The CL code was modified as necessary to declare
+	all dictionary and stack storage and references using this new
+	type.  (12/29)
+
+pkg/cl/scan.c
+	The varargs code in this routine failed to compile on the Alpha,
+	which defines va_list as a structure rather than a variable.
+	This caused a (va_list) cast to fail.  After studying this for
+	a while I couldn't find any way to safely and portably use varargs
+	to fake an argument list as an array.  The solution adopted was
+	to just make a normal call to sscanf, putting the variable number
+	of arguments on the argument list in the normal fashion as v[0],
+	v[1], v[2], and so on.  The current implementation imposes a
+	limit of at most 32 arguments for a CL scan operation.  (12/29-30)
+
+unix/as.alpha/ieee.gx
+unix/as.alpha/ieeed.x
+unix/as.alpha/ieeer.x
+	Installed the DEC little-endian versions of the IEEE conversion
+	routines.  (12/29)
+
+mkpkg
+noao/mkpkg
+	Added an entry for the "alpha" architecture.  (12/29)
+
+unix/hlib/mkfloat.csh
+	1. Modified to look for .E files as well as .e files.
+	2. The script was failing because tar -tf would output file names
+	with a trailing space after the filename (surely a bug in OSF1 tar).
+	Had to add a filter to trim the whitespace.
+	3. Modified the script to treat the "generic" architecture specially,
+	avoiding any attempt to restore any binaries etc.  (12/29)
+
+sys/libc/zzdebug.c -> zztest.c
+	Renamed zzdebug.c zztest.c to avoid a name conflict with the zzdebug.x
+	in the same directory.  (12/29)
+
+unix/hlib/libc/stdio.h
+	In struct _iobuf, changed the type declarations from long and int
+	to XLONG and XINT.  (12/29)
+
+unix/hlib/config.h
+	Also set LEN_JUMPBUF here (see above).  (12/29)
+
+dev/hosts
+	Added an entry for "lyra" to the hosts table.  (12/29)
+
+---------------------------
+Completed sysgen.  Core system runs now but a few bugs are evident and remain
+to be tracked down.  (12/29)
+
+dev/pix.imh
+dev/pix.pix
+dev/wpix.imh
+	Replaced these files with the little-endian versions from Ultrix/IRAF.
+	Having unreadable images was a major source of the "system" problems!
+	(12/30)
+
+lib/helpdb.mip
+noao/lib/helpdb.mip
+	The help system would not read these files...  Had to rebuild them
+	to get things to work.  Woops - I forgot to set the byte swap flags
+	in the HSI before building IRAF.  (12/30)
+
+unix/hlib/mach.h
+	Set all the SWAP variables to YES.  Did a sysgen update.  (12/30)
+
+unix/hlib/install
+	Modified the install script for OSF1.  (12/30)
+
+unix/boot/spp/xc.c
+unix/hlib/mkpkg.inc
+	Moved the "-taso" flag into XC.  This is needed to compile all
+	iraf programs on the Alpha, and users shouldn't have to type it
+	when running XC standalone outside of mkpkg.  (12/30)
+
+---------------------------
+Core system is up and running now with no serious bugs evident.
+Built bin.alpha for TABLES package.  The libraries built (all IRAF uses)
+but the compiler core dumped trying to link the executables.  Haven't
+looked into it yet.  Started a sysgen of NOAO.
+
+noao/artdata/t_mk1dspec.x
+	Fixed two cases of MAX called with arguments of different types,
+	in this case the real constants 1. and 0. were being compared to a
+	type double expression.  (12/30)
+
+noao/mtlocal/cyber/pow.inc
+noao/mtlocal/cyber/rrcopy/pow.inc -
+noao/mtlocal/cyber/rrcopy/rcrbits.x
+	The include file pow.inc contained some very small real constants
+	in the E-38 or E-39 range, which caused compile time evaluation errors.
+	The offending values in the table were replaced by the value 0.0.
+	Probably other platforms that don't report this problem have been
+	underflowing to zero when evaluationg the these values.  Deleted
+	the rrcopy of pow.inc and modified the include in rcrbits.x to
+	reference the version in the root directory instead.  (12/30)
+
+	This program is pretty much obsolete and should probably be retired,
+	but it is easier to fix the compile time problems for now.
+
+unix/hlib/mkpkg.sf.OSF1
+	Added cl$ytab.c to the list of special files for OSF1.  This file
+	needs to be compiled with -Olimit 2048 to have enough table space
+	to optimize such a large file.  (12/30)
+
+unix/hlib/fc.csh
+	Modified for OSF1.  The main change required was that the file
+	/usr/lib/cmplrs/fort/for_main.o must be explicitly included on the
+	link line in order to link the Fortran program.  (12/30 1994)
+
+---------------------------
+Merged in latest 2.10.3 revisions from tucana.  (2/16 1995)
+
+dev/tapecap
+	Modified the Ultrix/IRAF tapecap to add support for OSF/1.  Added
+	compressed and uncompressed DAT (TLZ06) unit 0, 1 entries.  These
+	worked on the first try, although I did have to add an ":se" to
+	make appending work after readting to EOT.  (3/01)
+
+unix/as.alpha/ieee.gx
+	I did not actually modify this file for the problem noted below,
+	but wanted to record this oddity of the Alpha architecture.  (3/01)
+
+	The inconsistency seen on the Alpha with the IEEE test files is not
+	due to the NaN values, which are handled correctly, but to the
+	special case negative zero (-0) value included in this test data.
+	For some reason the Alpha fp unit is generating an exception for an
+	operation comparing zero and negative zero.  Other platforms have
+	not had a problem with this (although one wonders what the correct
+	result should be in this case).  It does seem rather an odd problem
+	and it is not clear if it is worth worrying about.  If necessary we
+	can modify our IEEE i/o routines to map such values to positive zero
+	but I don't know if it is worth it, unless we find out that such
+	values can occur in real world data.
+
+---------------------------
+Merged in latest 2.10.4 revisions from tucana.  (4/20 1995)
+
+unix/os/mkpkg.sh
+	Modified the OS boot mkpkg.sh to use as$zshlib.s rather than
+	os$zshlib.c.  The mkpkg special file list was set up to do this, but
+	the wrong version was used when the system was bootstrapped.  (4/21)
+
+unix/hlib/mkpkg.sf.OSF1
+	Modified to compile as$zshlib.s without optimization, the default xc
+	flags produce a warning message when used to compile as$zshlib.s.
+	(4/21)
+
+unix/os/zxwhen.c
+	This code was modified to use signal instead of signal plus sigaction.
+	I was having problems with signals not being caught resulting in 
+	infinite loops.  See the comments in the code.  (5/03)
+
+unix/os/zawset.c
+	Installed new version from tucana.  (5/03)
+
+unix/hlib/libc/kernel.h
+	Modified values of SZ_DEFWORKSET and SZ_MAXWORKSET to 8 Mb and 256 Mb
+	as was done on tucana for ZAWSET above.  (5/03)
+
+unix/hlib/zzsetenv.def
+	Default printer changed to "lp".  (5/03)
+
+unix/os/mkpkg.sh
+	Fixed a couple minor problems found in redoing the bootstrap.
+	1. Changed HSI_LIBS to HSI_OSLIBS for building zalloc.e, which doesn't
+	use the IRAF libraries.
+	2. The "set zsrc = ..." was incorrect for the Bourne shell, changed
+	to BS syntax.  (5/03)
+
+unix/os/zawset.c
+	This routine would not work properly on OSF/1 even though it should
+	according to the docs (behavior should be the same as on other
+	systems).  Any attempt to set RLIMIT_RSS would fail, causing the
+	value 50 to be returned.  Modified the code to merely comment out
+	the setrlimit.  getrlimit still works and the routine will still
+	return an accurate indication of the physical memory available to a
+	process.  Probably this problem with setrlimit() explains why the
+	"limit" command in the cshell doesn't work either.  (5/09)
+
+unix/hlib/spy.cl
+	Updated to use ps -ef instead of px -axu.  (5/23)
+
+sys/fio/fioclean.x
+sys/fio/stropen.x
+	Two new internal routines str{set,get}mode were added to stropen.x.
+	These are used to set or query the file access mode as strored for
+	the string file, which represents these in a file-dependent way.
+	fio_cleanup was modified to force the access mode of a string file
+	to READ_ONLY before closing it during file cleanup, to prevent the
+	writing of the trailing EOS when closing a string file opened for
+	writing.  The latter could cause a segmentation violation if the
+	string buffer was no longer in a mapped region of memory, as is
+	possible if the string file is still open (i.e. not closed normally)
+	following task termination when fio_cleanup is called.  (6/06)
+
+---------------------------
+V2.10.4 release June 07 1995.
+
+unix/hlib/install
+	Changed /etc/mknod to /usr/sbin/mknod.   (6/21)
diff --git a/doc/ports/notes.solaris b/doc/ports/notes.solaris
new file mode 100644
index 00000000..46a5fed2
--- /dev/null
+++ b/doc/ports/notes.solaris
@@ -0,0 +1,514 @@
+Begin IRAF port to Solaris 2.3 
+Wed May 25 15:38:55 MST 1994
+----------------------------------------
+
+bin.ssun			+
+bin.ssun/IB.SSOL.SUN		+
+bin.sf2c			+
+bin.sf2c/IB.SSOL.F2C		+
+noao/bin.ssun			+
+noao/bin.ssun/IB.SSOL.SUN	+
+noao/bin.sf2c			+
+noao/bin.sf2c/IB.SSOL.F2C	+
+	Set up the Solaris platform (SSOL = Sun Solaris) and the two planned
+	Solaris architectures, SUN (Sun unbundled compilers) and F2C (F2C
+	and FSF compilers).  (5/25)
+
+unix/hlib/irafuser.csh
+	1. Replaced the `mach` reference by something that will work on both
+	SunOS and Solaris, using uname.
+	2. Modified to define either SUNOS or SOLARIS in HSI_CF, so that
+	kernel code can support both systems.  (5/25)
+
+unix/os/getproc.c
+	Added a Solaris version of uid_executing().  This reads /proc and
+	scans the process files to see if any belong to the given uid.  (5/25)
+
+unix/hlib/irafuser.csh
+unix/os/mkpkg.sh
+	1. alloc.e would no longer link without linking against the library
+	-ldl.  Note that -ldl can only be linked dynamic (no -Bstatic).
+	2. Added a new definition HSI_LFLAGS to irafuser.csh and modified the
+	mkpkg.sh in OS to use this to define the link flags for alloc.e.
+	This will probably have to be done for other HSI executables as well.
+	(5/25)
+
+unix/os/prwait.c
+	Solaris defines the exit_status argument to wait() differently and
+	the code had to be modified to allow for this.  (5/27)
+
+unix/os/zfioks.c
+	The select facility on Solaris uses fd_set, FD_SET, etc. and it
+	was necessary to add #ifdef SOLARIS code to reflect this.  (5/27)
+	
+
+Fri Jun 24 14:23:32 MST 1994
+----------------------------------------
+Resume port (elsewhere for the past month)
+
+unix/hlib/libc/kernel.h
+	Added a definition PFV; PFI is now a pointer to function returning
+	int, and PFV is a pointer to a function returning void.  Also added
+	a new definition SIGFUNC, which is whatever type signal() refers to
+	on the local system.  (6/24)
+
+unix/os/zfioks.c
+	1. Changed a number of PFI instances to SIGFUNC.
+	2. Changed the second two arguments to ks_onsig to type int*.  These
+	are not used and the actual type is different on Solaris than other
+	systems.  Probably the args should just be omitted but it may be
+	more portable to define a couple of dummy args.
+	3. The second argument to bind() is type (struct sockaddr *) in
+	Solaris, was (caddr_t) on other systems.  (6/24)
+
+unix/os/zfiotx.c
+	1. Deleted the import_fset, which apparently isn't used and which
+	contains a #define which conflicts with a Solaris one.
+	2. Changed a bunch of PFI instances to SIGFUNC.  Added some
+	(SIGFUNC) declarations to the signal handler arguments to signal().
+	3. Replaced the two dummy arguments (same as item 2 above) in three
+	instances of event handlers with dummy args declared (int *).  (6/24)
+
+unix/os/zopdir.c
+	Modified to use Solaris version of opendir/readdir.  (6/24)
+
+unix/os/zoscmd.c
+	Modified to use SIGFUNC instead of PFI, and to declare generic
+	dummy arguments for an event handler.  (6/24)
+
+unix/os/zshlib.c
+	Fixed a syntax error on the last line, an extra ';' following a
+	stubbed out function declaration.  (6/24)
+
+unix/os/zwmsec.c
+	1. Modified to use signal instead of sigvec; the latter is BSD specifc.
+	2. sigpause() takes a signal number instead of a signal mask.  Omitted
+	sigblock, which is no longer needed since we aren't using a mask, and
+	which doesn't exist on Solaris.
+	Possibly this routine should be completely rewritten on Solaris,
+	there may be better facilities for small timed delays.  (6/24)
+
+unix/os/zxwhen.c
+	1. For Solaris we must include <sys/siginfo.h> and <sys/ucontext.h>.
+	2. fcancel macro modified to use the constant BUFSIZ.
+	3. The table of hardware exceptions was modified to omit all
+	codes other than those for SIGFPE; the other codes (at least on
+	Solaris) alias with the FPE codes, and aren't used anywhere in
+	zxwhen anyway.  Added Solaris SIGFPE codes.
+	4. Modified calling sequence of exception handler ex_handler to
+	the form Solaris requires.  Added a statement to get the hardware
+	exception code out of the siginfo argument.
+	5. Replaced a number of PFI's by SIGFUNC's.  (6/25)
+
+unix/os/zfiomt.c
+	Modified signal handling code to use type SIGFUNC.  (6/25)
+
+unix/os/zzstrt.c
+	Made a few changes to get this code to compile, although the shared
+	library support isn't expected to work at this point.  (6/25)
+
+unix/hlib/irafuser.csh
+unix/os/zzstrt.c
+	Added a new define SHLIB, used to conditionally compile zzstrt for
+	shared library support.  (6/25)
+
+unix/boot/bootlib/bootlib.h
+	This file had a #ifdef UNIX in it, but this define is not defined
+	anywhere.  Modified to #ifdef VMS but assume unix otherwise.  (6/25)
+
+unix/hlib/irafuser.csh
+	Modified to define RANLIB as "echo ranlib" for Solaris.  (6/25)
+
+unix/hlib/kernel.h
+	Solaris doesn't have bcopy/bzero, so added a couple of #defines to
+	kernel.h to map these functions onto the equivalent Solaris versions
+	memmove/memset.  (6/25)
+
+unix/os/zoscmd.c
+unix/os/zopdpr.c
+unix/os/zfiopr.c
+	Replaced all calls to getdtablesize() by corresponding calls to
+	getrlimit().  (6/25)
+
+unix/os/zfgcwd.c
+	Replaced getwd() by getcwd().  (6/24)
+
+unix/boot/mkpkg/scanlib.c
+	It was necessary to add an (int) cast to  (int)fread(...) > 0
+	to avoid a warning message from the compiler, because fread has an
+	odd type on Solaris.  (6/25)
+
+unix/hlib/irafuser.csh
+	Added -lsocket -lnsl (the Solaris socket emulation library) to the
+	list of HSI host libraries used to link the HSI utilities.  (6/25)
+
+unix/boot/spp/xc.c
+	Made some minor changes to xc for Solaris - not clear yet what all
+	will be needed.  Most of it looks like it will work.  Added a #ifdef
+	conditional for the Solaris F77 libraries, taking the SunSoft
+	compiler as the builtin default.  Modified signal handling to use
+	SIGFUNC to be more portable.  (6/25)
+
+unix/boot/rmfiles/rmfiles.c
+	Added an "extern char *vfn2osfn()" declaration.  (6/25)
+
+unix/boot/spp/rpp/ratlibc/initst.c
+	Added a #ifdef conditional to access the stdio streams on Solaris.
+	(6/25)
+
+unix/gdev/sgidev/sgi2uapl.c
+unix/gdev/sgidev/sgi2uhpgl.c
+unix/gdev/sgidev/sgi2ueps.c
+	1. These files contained a number of cases where the file descriptor
+	"out" was declared int where (FILE *) was intended.
+	2. Replaced an instance of gethostname() in sgi2uapl.c by a call
+	to sysinfo().  (6/25)
+
+
+Sat Jun 25 23:26:24 MST 1994
+----------------------------------------
+Completed first bootstrap.  Try initial sysgen of core system.
+
+unix/boot/spp/xc.c
+	Modified xc to automatically do a "-t" when linking.  This disables
+	linker warnings about different size commons.  (6/26)
+
+unix/os/irafpath.c
+	Added a case for Solaris/sparc.  (6/26)
+
+mpkg
+as.ssol		+
+bin.ssol	+
+unix/setarch.sh
+unix/hlib/irafuser.csh
+	For Solaris/sparc the HSI AS and BIN are as.ssol and bin.ssol.
+	Hopefully it will be possible to use a single set of directories
+	for both the ssun and sf2c binary architectures.  (6/26)
+
+unix/hlib/install
+	Added some code to set the platform architecture automatically for
+	either SunOS or Solaris.  On a Solaris system the suntools stuff is
+	skipped.  (6/26)
+
+unix/boot/bootlib/envinit.c
+	Fixed a bug/typo in this code: "printf (stderr, ...)".  (6/26)
+
+unix/boot/bootlib/vfn2osfn.c
+	Several more cases of a null statement ";" at the end of this file.
+	This happens in dummy function constructs like "foo(){};".  (6/26)
+
+unix/hlib/mkpkg.inc
+	Added cases for IRAFARCH=ssun and sf2c.  (6/26)
+
+unix/hlib/mkpkg.sf.SSUN		+
+unix/hlib/mkpkg.sf.SF2C		+
+	Added starter special file lists for the two Solaris architectures.
+	(6/26)
+
+unix/as.ssol/zsvjmp.s
+	This assembler source appears to assemble ok, but I had to remove the
+	leading underscore from _zsvjmp_ as the SunSoft Fortran compiler
+	doesn't use leading underscores.  (6/26)
+
+
+Sun Jun 26 20:18:48 MST 1994
+----------------------------------------
+Completed first core system sysgen: system starts up and runs, but a number
+of bugs are evident.
+
+unix/hlib/irafuser.csh
+	HSI_XF now includes flags such as -/DSYSV -/DSOLARIS etc., so that
+	mkpkg can be used to update HSI libraries such as OS.  This is only
+	a temporary solution, ideally XC should accept HSI_CF.  (6/27)
+
+sys/fio/fdirname.x
+	There was an actual bug in this file that showed up during testing
+	of the new port.  zfxdir (kfxdir) was being used incorrectly to
+	test for the existence of host directory pathnames.  (6/27)
+
+unix/os/zopdir.c
+	The above testing also revealed a bug in this file.  This was
+	preventing commands such as "dir /" from working, due to a bug in
+	the code which strips trailing slashes from directory names.  (6/27)
+
+unix/os/zfiotx.c
+	1. Raw mode terminal i/o was not working properly on Solaris; output
+	data was being lost when raw mode was entered, even though the ioctl
+	used would (presumably) wait for the output to drain before changing
+	the terminal mode.  It is not clear what the connection might be,
+	but this was fixed by deleting the iflag=0, i.e., not resetting the
+	iflags, when entering raw mode.  Evidently clearing one of the
+	default input flags was the source of this problem, even though
+	ICANON was disabled.  Since ICANON is disabled we shouldn't need
+	to change the iflags anyway, so it should be safe to omit this.
+	In fact, it is probably safer to preserve all default terminal flags
+	by default and change only those affecting raw i/o, but at present
+	I will leave it fully setting the oflags and lflags, since this
+	is working.
+	2. Solaris also provides the POSIX termios interface which is the
+	recommended interface.  This appears to be a simple front end to
+	the termio ioctl interface.  I decided to avoid this for the moment
+	since the SYSV termio interface appears to be widely available.
+	(6/27)
+
+
+Sun Jul  3 23:08:27 MST 1994
+----------------------------------------
+Resume work on Solaris port.
+
+unix/as.ssol/enbint.s		+
+unix/os/zzstrt.c
+unix/os/zxwhen.c
+	After a bit more research got IEEE floating point exception handling
+	working under Solaris.  The new routine enbint.s is used to enable the
+	exceptions.  sigaction turned out to block SIGFPE when the handler
+	was called and it proved necessary to add the SA_NODEFER flag to 
+	prevent this.  (7/03)
+
+unix/os/zfioks.c
+unix/os/zfiond.c
+	Fixed a couple bugs that were keeping networking from working.
+	"RSH" was not being defined correctly in zfioks, and it was necessary
+	to add FD_ZERO calls to zero the select fd arrays before calling
+	FD_SET.  (7/04)
+
+sys/imfort/tasks/
+unix/hlib/fc.csh
+	Tested FC on the imfort tasks.  This worked without incident following
+	minor changes to the fc.csh script.  The only thing unusual is that
+	an IEEE retrospective is printed when the task exits, indicating
+	that the IEEE divzero,overflow,invalid exceptions were enabled.
+	This is annoying but is not exactly a bug (ieee_retrospective is always
+	called by Fortran programs, it just doesn't usually generate any
+	output), so for the moment I don't see the need to change anything
+	at present.  (7/04)
+
+Build of ssun binaries for TABLES proceeded without incident.  (7/04)
+
+unix/boot/bootlib/ossymlink.c
+	This file used #ifdef BSDUNIX incorrectly, preventing the #ifdef-ed
+	code from compiling on UNIX systems for which BSDUNIX was not set.
+	Changed the statement to #ifndef VMS.  (7/05)
+
+unix/shlib/zzzend.c
+	Deleted ";" at the end (empty declaration).  (7/10)
+
+unix/shlib/medit.c
+	Added a #define for bcopy, which doesn't exist in Solaris.  (7/10)
+
+unix/shlib/mkpkg
+	Modified to avoid use of ranlib on Solaris platforms.  (7/10)
+
+unix/boot/spp/mkxc.sh
+	Modified to do the compile and link in separate steps.  (7/14)
+
+unix/gdev/sgidev/sgi2uapl.c
+	Modified to put "%!PS" in the Postscript file header.  (7/19)
+
+dev/tapecap
+	Added Solaris support.  (7/20)
+
+unix/boot/spp/xc.c
+	Added -lintl to the list of builtin host libraries.  (7/23)
+
+unix/os/zfiotx.c
+	Rather than leaving iflags unmodified when raw mode is entered,
+	now clears several input processing flags, in particular CR is not
+	mapped to NL.  (7/23)
+
+unix/hlib/zzsetenv.def
+	Changed the default printer device to "lw".  (7/25)
+
+unix/shlib/Slib.c
+unix/shlib/edsym.c
+unix/shlib/elf.c		+
+unix/shlib/medit.c
+unix/shlib/mkpkg
+unix/shlib/mkpkg.sh
+unix/shlib/mkshlib.csh.ssol	+
+unix/shlib/zzzend.c
+unix/os/zzstrt.c
+	There were many changes here, especially to mkshlib.csh, edsym.c,
+	Slib,c, and zzend.c, to support IRAF shared libraries under Solaris.
+	Most of the changes were made earlier but I did not keep detailed
+	notes during development.  The changes are not fully backwards
+	compatible, so it will be necessary to configure separate shlib
+	directories for SunOS and Solaris.  (7/25)
+
+unix/hlib/mkpkg.inc
+	A wfits problem was traced to a bug in the Fortran optimizer using
+	SunSoft Fortran 2.0.1.  Compiling -O2 avoids the problem.  (7/29)
+
+unix/hlib/install
+	The install script was modified earlier to just exit when it came
+	to the gterm/imtool config stuff.  Modified this to continue on
+	with this, but to do only the X11 related configuration.  This
+	consists of making the /dev/imt fifos, installing the imtoolrc,
+	and checking that termcap and graphcap are sufficiently up to date
+	to contain xgterm and imtool entries.  (7/30)
+
+unix/hlib/libc/kernel.h
+unix/os/zfiotx.c
+unix/os/zzstrt.c
+	Replaced the terminal driver by a version which maintains a unique
+	descriptor for every hardware terminal device, regardless of the
+	file descriptor used to access the terminal.  (8/02)
+
+dev/graphcap
+	The xgterm graphcap entry now recognizes either CR or LF as the
+	trailer code for a cursor read.  (8/02)
+
+unix/boot/mkpkg/mkpkg
+	Changed "cc" to "$(CC)".  (8/17)
+
+unix/boot/spp/xc.c
+	XC now supports multiple packages in PKGENV.  (8/18)
+
+-----------------------------------------------------
+Solaris 2.10.3 release
+*** apus upgraded to Solaris 2.4, SunSoft V3.0 compilers ***
+
+unix/os/zfiotx.c
+	Installed the tty_reset bugfix.  (9/17)
+
+unix/os/getproc.c
+	This routine was omitting the "/proc" from pathnames of process
+	files in the /proc directory, causing uid_executing to always
+	return zero.  (10/05)
+
+-----------------------------------------------------
+Merged in V2.10.4 revisions from tucana.  (4/22 1995)
+
+unix/hlib/mkpkg.sf.SSUN
+	Added explicit $xc build commands to the special file list entries for
+	C files.  The default compile flags from mkpkg.inc would cause a
+	warning when applied to C files, as CC doesn't understand -O2.  (4/26)
+
+unix/shlib/mkshlib.ssol-sc2
+unix/shlib/mkshlib.ssol-sc3	+
+	Renamed mkshlib.csh.ssol to mkshlib.ssol-sc2.  This is the version for
+	the version 2x SunSoft compilers.  Started a variant mkshlib.ssol-sc3
+	for the version 3x compilers.  In this made various minor changes:
+	1) File header size increased from 0x74 to 0x78.
+	2) Compiler libraries and objects are now in /opt/SUNWspro/SC*/lib
+	instead of /opt/SUNWspro/SC*.
+	3) There is a new library -lsunmath which follows -lF77.  (4/26)
+
+unix/boot/spp/xc.c
+	Modified to add the -lsunmath library if used with the Version 3 or
+	greater SunSoft compilers.  XC attempt to automatically distinguish
+	Version 2 and Version 3 and do the right thing.  (4/26)
+
+unix/hlib/mkpkg.inc
+	Removed the -O2 switch from the standard compile flags in mkpkg.inc.
+	This was put in for an older version of the compilers and probably
+	isn't needed any longer.  This also avoids the problem of passing -O2
+	to the C compiler when compiling C code.  (4/26)
+
+-----------------------------------------------------
+Completed a full bootstrap and sysgen of V2.10.4 Solaris/IRAF using
+Solaris 2.4 and the SunSoft V3 compilers.  (4/26)
+
+unix/hlib/zzsetenv.def
+	Updated "version" to 2.10.4EXPORT.  (5/18)
+
+unix/hlib/spy.cl
+	Rewrote spy.cl to work on both BSD and SYSV systems (SunOS and
+	Solaris in the case of Solaris/IRAF).  (5/19)
+
+unix/os/zgtime.c
+	Modified for Solaris systems to use CLK_TCK (which does a runtime call
+	to sysconf) to get the clock frequency, instead of the compile time
+	kernel constant CLKFREQ.  On our development system CLK_TCK is 100,
+	rather than 60 which is the value compiled into the kernel.  (5/19)
+
+unix/os/gmttolst.c
+	In the internal routine get_timezone added a call to "tzset()" 
+	before accessing the external variable timezone.  This is necessary
+	to set the value of timezone in the first call after process
+	startup.  (5/19)
+
+unix/os/zoscmd.c
+	This fix was made to resolve a problem where EMACS or VI would
+	hang up when run from the CL and ctrl/g or ctrl/c was typed.
+	Evidently this was due to the code in zoscmd.c which pretends to
+	ignore interrupts while the child is executing, but in reality was
+	catching interrupts and setting a flag then continuing to wait for
+	the child process to terminate.  Evidently on SysV systems, or at
+	least on Solaris, the interrupt handler was causing the process
+	to read from the terminal, and wait() was not being reentered
+	folowing an interrupt causing both the parent and the child to read
+	from the terminal at the same time.  The fix was to modify zoscmd.c
+	so that on SYSV systems the parent does not post any interrupt
+	handler.  (5/19)
+
+unix/os/zzstrt.c
+unix/shlib/mkpkg
+bin.ssun/S10_5.4.e		+
+	It appears that the system library libsocket.a in Solaris is
+	incompatible between Solaris 2.3 and 2.4.  Networking is broken if
+	an IRAF executable linked under Solaris 2.3 is run on 2.4 and vice
+	versa.  Our workaround, at least for the moment, is to have different
+	versions of the IRAF shared image for different versions of solaris.
+	During startup an IRAF process will query the OS release number,
+	e.g. 5.3 (Solaris 2.3) or 5.4 (Solaris 2.4) and map the corresponding
+	shared image.  A mkpkg in unix/shlib updates the version of the
+	shared image corresponding to the OS release on which IRAF is
+	currently running.   The new shared image file names are S10_5.3.e
+	for Solaris 2.3 and S10_5.4.e for Solaris 2.4.  If the release
+	dependent version is not found the system will automatically fall
+	back to S10.e.  (5/22)
+
+-----------------------------------------------------
+Did another sysgen-relink and rebuilt the distribution files.  (5/22)
+
+unix/boot/spp/xc.c
+	Modified to compile only C and assembler files in the catch-all
+	compile phase.  Prevents compile attempts where the file list
+	contains only object files.  This was a problem under Solaris 2.5.
+	(10/19)
+
+unix/shlib/mkshlib.ssol-sc3
+	Modified to suport the SC4.0 compilers under Solaris 2.5.  There was
+	a bug in the script if both SC3.0.1 and SC4.0 compilers were present
+	in the same system.  The link line was slightly different for the
+	new compiler.  (10/19)
+
+unix/shlib/mkshlib.ssol-sc3		-
+unix/shlib/mkshlib.ssol-sc34		+
+	1. Changed the name of this file to sc34 since it supports both the SC3
+	and SC4 compilers.  Updated the comments accordingly.  
+	2. I tried changing the page alignment for the shared image from
+	0x2000 (8K) to 0x4000 (16K).  The intent was to support Sparc clones
+	with 16K pages.  It worked (at least on a Sun sparc), but would
+	produce a bogus version match please relink error message on startup
+	for old executables, due to relocation of the transfer vector.  I had
+	to set things back to 0x2000 as we can't afford to break old
+	executables for a patch.  (3/25 1996)
+
+unix/os/zmain.c
+	Added a #ifdef SYSV conditional to allow for different calling 
+	sequences for setpgrp() on SYSV and BSD systems.  (4/24)
+
+unix/os/zfinfo.c
+	Commented out the setpwent/getpwent, they are not needed on Solaris
+	and appear to cause an associated Solaris bug to crop up.  (8/16)
+
+-------------------------------------------
+V2.10.4 patch 2 released.  (5/22 1996)
+
+
+TODO
+    o	Tue Nov 21 12:50:24 MST 1995
+	XC assumes /opt/SUNWspro in isv3().
+
+    o	Thu Feb  1 11:54:17 MST 1996
+	Skip reports networking failure - AA05224
+
+    o	Mon Mar 11 12:24:55 MST 1996
+	Modify zawset.c to use actual physical memory as determined by sysconf.
+
+    o	Mon Mar 11 12:25:10 MST 1996
+    	Change SHLIB address from 0a000000 to 03c000000 to allow 1 Gb process
+	data segment.  This requires that all applications be relinked so
+	cannot be done until V2.11.
diff --git a/doc/ports/notes_orig.hp b/doc/ports/notes_orig.hp
new file mode 100644
index 00000000..da07675f
--- /dev/null
+++ b/doc/ports/notes_orig.hp
@@ -0,0 +1,657 @@
+1 February 1988,  HP/UX port, HP 9000 Series 800 Model 850
+Steve Rooke, NOAO
+
+[read tape from NOAO/lyra; source tape cut 30 Jan 88.
+[at least the last file, probably the whole last block worth of the tape
+[was missing, including the root mkpkg file.  Have been unable to dial in
+[to NOAO to recover.
+[Had to do this several times, trying dd then tar; couldn't write with
+[tar xp due to existence of an account with same group, user id, so had
+[to read as root, then chown/chgrp afterwards, in order to preserve file
+[dates.
+
+local/.login
+	Set iraf root to /aura/iraf; commented out mail command (didn't
+	like $user); modified stty to get rid of a bunch of Berkeley stuff.
+	This works:
+	    stty	tabs intr ^C kill ^U susp ^X eof ^Z erase ^H
+	(2/1 SRo)
+
+unix/*
+	Spliced Sun HSI into lyra source system, on the theory that there
+	will be less editing A#pqthan for a VAX.  (2/1 SRo)
+
+hlib/libc/iraf.h
+hlib/mkiraf.csh
+	Reset iraf root.  (2/1 SRo)
+
+/usr/include/iraf.h
+	Copied in from libc/iraf.h; there are no symbolic links in HP/UX
+	V1.2.  They will arrive in HP/UX V2.0 in March '88.
+	**TODO** remember to remove copy in /usr/include and replace
+	with sym.link when available.  (2/1 SRo)
+
+vms/*
+	Removed vms directory.  (2/1 SRo)
+
+hlib/mkfloat.csh -
+hlib/cl.csh -
+	Removed these sun-specific files.  The 9000 800 series has only
+	one kind of floating point hardware.  (2/1 SRo)
+
+osb/zzeps.[fe]
+	Compiled and ran zzeps; machine single & double precision same as
+	on the Suns (IEEE standard works, apparently).  (2/1 SRo)
+
+hlib/libc/spp.h
+	Increased LEN_JUMPBUF from 16 to 51, as /usr/include/setjmp.h 
+	allocates 50.  (2/1 SRo)
+
+local/.login
+local/ranlib
+	Removed /usr/ucb, /local/bin, and /usr/local/bin from search path
+	(not present here), and added $iraf/local.  Created a dummy shell
+	script called RANLIB, to avoid having to edit out the ranlib command
+	all over the system.  In HP/UX, AR performs the ranlib function.  (2/1)
+
+unix/os/zdojmp.c
+unix/os/mkpkg
+	Added Doug's new zdojmp.c from tucana (hardcopy), which uses UNIX
+	longjmp call, replacing some assembler code formerly used in 
+	as$zsvjmp.s.  (2/1 SRo)
+
+hlib/libc/iraf.h
+/usr/include/iraf.h
+	Commented out BSD43 define; "hpux" automatically defined for all
+	C files.  (2/2 SRo)
+
+os/zxwhen.c
+	Included FAULT and TRAP hardware exception codes from 
+	/etc/conf/h/signal.h.  (2/2 SRo)
+
+hlib/libc/kernel.h
+	Set _NFILE to 60 for HP/UX, MAXPROCS to 25 (as per maxuprc in
+	/etc/conf/gen/S800).  (2/2 SRo)
+
+hlib/irafuser.csh
+	Set all HSI compiler flags to "-O", which is optimization level 2,
+	the highest of 0,1,2.  (2/2 SRo)
+
+[Begin first bootstrap attempt.  cd $host; sh -x mkpkg.sh]
+unix/mkpkg.sh
+	Commented out "test" command and symbolic link from as.MACH to
+	as; no "test" in HP/UX, currently no symbolic links.  (2/2 SRo)
+
+unix/os/mkpkg.sh
+unix/as/zsvjmp.c
+	Temporarily replaced as/zsvjmp.s with as/zsvjmp.c in order to
+	get past compiler error.  Apparently if an error occurs in one
+	of the source modules listed on a cc command line, none of the
+	objects is produced (also see next entry).  (2/2 SRo)
+
+os/zxwhen.c
+	Modified reference to fp->_bufsiz; (HP/UX no longer has _bufsiz as
+	structure element; rather it is defined in terms of an external
+	bufendtab[] and existing structure elements):  fp->_bufsiz becomes
+	_bufsiz(fp) as per #define in stdio.h.  (2/2 SRo)
+
+os/alloc.c
+	Moved the #include <sys/types.h> after the #include <utmp.h>, as
+	the time_t symbol is defined in the former in HP/UX.  (2/2 SRo)
+
+hlib/libc/iraf.h
+hlib/libc/hpux.h
+	Added an `if hpux, include hpux.h' directive, and created the
+	latter.  Without symlinks, difficult to keep modifying iraf.h.
+	Iraf.h seems to be the best place to include special redefinitions
+	of system calls and the like that are in the HSI but not present
+	in HP/UX (or SysV).  This seems safer for later updates than editing
+	a dozen files all over the HSI.  hpux.h now contains:
+
+	    #define MAX_IPATHLEN  127			/* max IRAF pathlen */
+	    #define getwd(a)	  getcwd(a,(MAX_IPATHLEN+2)) 
+
+unix/boot/spp/rpp/mkpkg.sh
+	Removed the "kludge for Sun-4" code which used the command "mach",
+	apparently a SunOS command.  (2/2 SRo)
+
+unix/boot/bootlib/mkpkg.sh
+unix/boot/bootlib/rename.c
+	Added routine to simulate BSD "rename" call; we tried this with
+	macros, but turned out to be too complicated with error checking.
+	Mkpkg.sh only compiles rename.c if test "`uname`" = "HP-UX".  (2/2 SRo)
+
+local/.login
+	Added /usr/local/bin to path.  (2/2 SRo)
+
+unix/os/zfiotx.c
+	Removed "struct sgttyb ttystat;" statement from ZCLSTX, where
+	it was declared but not used.  (2/2 SRo)
+
+unix/os/zfgcmd.c
+hlib/libc/hpux.h
+	Added ifdefs hpux around getwd(x), which is now getcwd(x,MAXPATHLEN).
+	Removed similar redefinitions from hpux.h, which now has nothing
+	in it, and should be removed later if nothing further is added.
+	**TODO** Remove hlib/libc/hpux.h and include for it in iraf.h??
+	(2/2 SRo)
+
+hlib/libc/kernel.h
+	SysV does not use the sgttyb structure, and ioctl flags are different.
+	added #ifdefs to redefine part of the FIODES structure if hpux.  Should
+	later modify for a more general way to determine whether SysV at
+	compile time.  (2/2 SRo)
+
+unix/os/zfgcwd.c
+	SysV uses getcwd(p,maxlen) rather than getwd(p).  Ifdef'd.  (2/2 SRo)
+
+unix/os/zfiotx.c
+	Extensive modifications to support SysV termio, using #ifdefs, so
+	should still work with BSD.  (Would not compile with any references
+	to the BSD sgttyb structure.)  (2/[23] SRo)
+
+unix/os/zfioks.c
+	Added ifdefs around ioctl call for no echo while getting password.
+	(2/3 SRo)
+
+unix/boot/bootlib/ossettime.c
+	Ifdefs for hpux; in SysV utimes becomes utime, and the tv_sec
+	structure element from timeval has become UNSIGNED long.  (2/3 SRo)
+
+unix/boot/mkpkg/host.c
+	Same for another utime[s] call, unsigned long tv_sec.  (2/3 SRo)
+
+hlib/libc/kernel.h
+	Added extra structure element initialization for hpux (SysV)
+	fiodes structure (zglobl.c wouldn't compile).  (2/3 SRo)
+
+boot/spp/rpp/ratlibc/ratdef.h
+	HP-UX does not tack on trailing underscores to fortran 
+	external identifiers.  Removed same from all identifiers
+	in this include file.  (2/3 SRo)
+
+hlib/libc/knames.h
+hlib/libc/xnames.h
+	Removed trailing underscores from fortran external identifiers.
+	(2/3 SRo)
+
+unix/boot/spp/xc.c
+	Replaced FORTLIB[1-3] values with "-lcl", "-lm", and "" for HP-UX.
+	Symptom was unresolved external symbols "$$lr_wa_[8-13]", or
+	hpux "millicode" routines; "cl" stands for "compiler library".
+	(2/3 SRo)
+
+unix/boot/spp/rpp/mkpkg.sh
+	Added explicit "-lcl" after user libraries on CC command line.
+	The CC compiler in HP-UX does not automatically pass this
+	flag on to the loader (not set up for arbitrary mixing of C
+	and F77).  (2/3 SRo)
+
+[Bootstrap finally completes error-free.]
+
+unix/os/mkpkg.sh
+unix/as/zsvjmp.s
+	Installed Jim Dillon's just-completed zsvjmp assembler routine
+	(had a stub in there before), and restored os/mkpkg.sh to its
+	initial state.  (2/3 SRo)
+
+[Ran rmbin on the HSI and performed another bootstrap.]
+
+unix/hlib/mkpkg.inc
+	Removed Sun stuff; the hppa has no special compiler flags for
+	floating point.  (2/3 SRo)
+
+[Began sysgen at 16:55.  Proceeding smoothly at 18:00 except for numerous ]
+[warnings:  WARNING: TEST MAY FAIL DUE TO FLOATING POINT IMPRECISION (781)]
+
+[Thursday Feb. 4.
+[Sysgen completed at 02:03 2/4; this was a 9-hour sysgen.  There were 1011
+[of the fp imprecision warnings, and about 2 dozen errors of various kinds.
+[The spoolfile summary contained 2569 lines!  There was one fatal compiler
+[error plus several compiler deaths due to my having forgotten to map the
+[intrinsics AND etc.
+[The fp imprecision warnings result from "if (variable .eq. CONST)" in
+[HP-UX f77, and there is nothing we can do about them except turn off all
+[f77 compiler warnings with "-w".
+
+unix/hlib/iraf.h
+	Defined and=iand, or=ior, xor=ixor for HP-UX.  (2/4 SRo)
+
+TODO:  Remember to search for and delete .BAK files in the HSI.
+
+unix/boot/spp/xc.c
+	Modified to compile C source files with CC rather than F77.  There
+	were several places in the sysgen where we attempted to compile C
+	source with f77 (mkpkg.inc: USE_CCOMPILER is YES), in addition to
+	the CL C source.  HP-UX f77 does not recognize C source.  Desinger
+	feels that it should, and suspects it never came up before.  (2/4 SRo)
+
+sys/imfort/imemsg.x
+	This file contained a half dozen "%	msg = '...'" statements, 
+	where the quoted string exceeded column 72 (assuming the leading
+	tab got expanded into 8spaces).  Abbreviated each offending
+	character string to fit into 72 columns.  Obviously, only these
+	"%" source statements that bypass the preprocessor could possibly
+	exceed 72 columns, however we would not have noticed any that would
+	not have ended in a missing quote, so TODO:  filter all spp source
+	files for ^% lines longer than 72 chars, after expanding tabs.
+	(2/4 SRo)
+
+sys/gio/ncarutil/conbdn.f
+	There was an uncommented DATA statement at line 342, following
+	assignment statements, and the f77 compiler complained.  (2/4 SRo)
+
+sys/gio/ncarutil/conbd.f
+	Had to move a "data	first" statement up into its proper position
+	(it followed some assignment statements).  This was lower case, so
+	it looked not to be a typo as in the previous case.  
+	Also had to add dummy variable in data statement as cannot init
+	variables or arrays via data statement in named common in HP-UX.
+	(2/4 SRo)
+
+sys/gio/ncarutil/gridal.f
+	Compiler warned about compile-time algrbraic expressions that can
+	be reduced; there are stmts at lines 1554,1566 subtracting 0. from
+	an expression (harmless, no mods made, just noting).  (2/4 SRo)
+
+sys/gio/ncarutil/srfabd.f
+	Compiler complained (error) about illegal initialization of "first",
+	which was in a data statement and also in common.  Added a dummy
+	variable in data stmt, and subsequent assignment to "first".  (2/4 SRo)
+
+sys/gio/nspp/portlib/gridal.f
+	"ifmt" was declared to be two-dimensional, but it appeared in an
+	equivalence statement at line 217 with only one subscript.  (2/4 SRo)
+
+sys/gio/nspp/portlib/z8zpbd.f
+	More arrays & variables in common initialized in data statement
+	(mfmt[xy]).  (2/4 SRo)
+
+noao/onedspec/dbx/dbmore.x
+	This routine initializes an array with DATA that is in common.
+	Hacked for now, leaving to Frank V for later.  (2/4 SRo)
+
+noao/imred/dtoi/hdicfit/hdicgdelete.x
+	The int procedure icg_deleted() did not return a function value,
+	causing a proper error message from f77, but generating a fatal
+	error and infinite loop in the optimizer.  Hacked for now to
+	return (0).  TODO:  investigate hdicgdelete.x to see what, if
+	any, return value should be generated.  (2/4 SRo)
+
+unix/boot/mkpkg/host.c
+	Finally noticed that the system libraries were disappearing instead
+	of being checked into lib$.  There is code in host.c that attempts
+	to copy the file if it cannot be moved any other way, but it must
+	never have been tested for moving a file to a directory, because the
+	creat() call took as its new file name just the host pathname of lib$,
+	lacking the name of the library.  Since u_fcopy() looked like it was
+	intended to be a general copy routine, I added a strcat in the calling
+	routine to append the library to the directory.  This ought to be
+	investigated (TODO), in case anything other than a file in the local
+	directory is the "old" file.
+	(2/4 SRo)
+
+[Began new sysgen at 17:21:22 PST 2/4/1988.  Still leaving in the compiler  ]
+[warnings; when all have been checked out, the flag "-w" ought to be added  ]
+[to mkpkg.inc; there is no way to ignore just the floating-compare warnings.]
+
+math/interp/arider.x
+	Compiler objected that real function did not return value.  Kludged
+	the three returns to "return (0.0)".  (2/4 SRo)
+
+unix/boot/spp/xc.c
+	XC was correctly compiling C source with "cc" rather than "f77" now,
+	but immediately afterwards was also trying to compile them with f77.
+	Fixed the subsequent filter that I hadn't noticed earlier.  This will
+	necessitate a followup sysgen (mostly a relink), as XC thought it
+	shouldn't try to link after getting run errors from UNIX.  (2/4 SRo)
+
+[This doesn't look so good... dates of object modules do not appear to
+[be in the object libraries, and mkpkg is recompiling all files regardless.
+[Getting too late to fix tonight.  Also, using cc to link (passed from XC)
+[results in a fatal /bin/ld error...
+
+unix/os/zawset.c
+	Finally (manually) got past enough loader problems to find the 
+	unresolved symbols... [gs]etrlimit() not implemented in SysV.
+	As this is not critical code for basic port purposes, merely
+	stubbed out for now.  TODO:  find some way to implement this in
+	SysV/HP-UX.  Investigate plock() for HP-UX only (real-time programming
+	manual)  (2/5 SRo)
+
+unix/os/zwmsec.c
+	In SysV, sigvec() is sigvector(), with no other changes.  Used ifdefs.
+	(2/5 SRo)
+
+unix/boot/spp/xc.c
+	Set FORTLIB3 to "-lbsdipc", the HP-UX library containing the likes
+	of rexec(); networking probably won't work anyway, but it might be
+	worth a try.  (2/5 SRo)
+
+unix/os/zfprot.c
+	Added #ifdef hpux to redefine rindex().  (2/5 SRo)
+
+[HIATUS -- Accidentally trashed this entire notes file last night with
+[a typo (redirecting some error output to the end of this notes file
+[with ">&" rather than ">>").  File recovered from Friday (2/5) noon backup
+[by Bob Desinger.  There were about 11 hours of time during which a moderate
+[number of notes file entries were made that were lost.  The following are
+[from memory but will have to be verified by diff'ing back in Tucson.
+
+unix/os/zawset.c
+	Could not immediately find a way to alter the working set size on this
+	system, so simply ifdef'd out the entire body of the routine to get
+	past unresolved symbol (getrlimit) at load time.
+	TODO: adjust workingset size in SysV?  (2/5 Sro)
+
+unix/os/zopdpr.c
+	No way to alter the timesharing (as opposed to HP-UX extended realtime)
+	priority of another process.  Ifdef'd around the [gs]etpriority calls.
+	(2/5 SRo)
+
+unix/boot/mkpkg/scanlib.c
+	In HP-UX, the object libraries have a different structure than under
+	BSD.  The symbol table is the first "module", immediately after the
+	8-byte magic header, then is followed by N modules.  When the space
+	allocated to the first symbol table entry is full, apparently, a symbol
+	table extension is tacked on.  Since module names are terminated with a
+	"/", and none of the symbol table entries has a module name, module
+	names beginning with "/" are always symbol table entries, so we check
+	each module to see if it is the latter, and skip file_size bytes if so.
+	Also, in exercising the code:
+	    while (fread (&arf, 1, sizeof(arf), fp) > 0) {
+	it was apparent that the structure was not being passed correctly.
+	Though the size and number of instances seemed to be reversed, that
+	should have been harmless, but the structure itself was not being
+	passed correctly to fread.  Solved with the following:
+	    while (fread (arf, sizeof(arf), 1, fp) > 0) {
+	(2/5 SRo)
+
+unix/os/zlocpr.c
+	The CL was dying at startup time, after trying to set an entry
+	point address in fseti().  Determined that the f77 EXTERN declaration
+	generates an address pointing to the address of the external function.
+	Modified zlocpr.c to use onenOxD extra level of indirection.  For some
+	reason, the typedef PFI declaration does not work; left the declaration
+	of proc as "int *proc" (something to do with how the compiler handles
+	"()" as part of a declaration??).  (2/5 SRo)
+
+unix/hlib/mkpkg.inc
+	Added "-w" flag to turn off all compiler warnings.  All such warnings
+	have already been investigated and accounted for, and the 1011 floating
+	compare warnings clutter up the spoolfiles unnecessarily.  (2/5 SRo)
+
+unix/boot/mkpkg/host.c
+	Cleaned up a bug I had introduced earlier in moving file to directory.
+	(2/6 SRo)
+
+sys/gio/nspp/sysint/ishift.x
+sys/gio/ncarutil/sysint/ishift.x
+	Both these files had their own "iand" and "ior" functions, generating a
+	compiler error, as "and" -> "iane:rtd" already, in hlib$iraf.h; as it
+	is the last day, I don't have time to recompile the whole system
+	by placing some redefinition in iraf.h; the procedure calls are
+	the same as those supplied by HP-UX, so just commented out the
+	ncar equivalents.  (2/6 Sro)
+
+noao/astutil/asttools/pdmstatistics.x
+noao/twodspec/apextract/t_apnormalize.x
+	Ha!  Just like the Masscomp, TAR will not write files that have
+	a "." in the 14th position, and reports no error message.  These
+	files are missing from the system.  (2/6 SRo)
+	
+noao/imred/dtoi/hdicfit/hdicebars.f
+unix/hlib/mkpkg.sf
+	This file generates a fatal internal error in the 2nd pass of the
+	optimizer, after staying in a loop for a very long time.  Left
+	f77 source with HP.  Added to special file list.  (2/6 SRo)
+
+noao/twodspec/multispec/fitclean.f
+noao/twodspec/multispec/fitsmooth.f
+unix/hlib/mkpkg.sf
+	These files generate fatal address compiler errors in 2nd pass
+	of optimizer.  Left with HP.  Added to special file list.  (2/6 SRo)
+
+noao/imred/dtoi/hdicgundelete.x
+noao/imred/ccdred/t_badpiximage.x
+noao/imred/ccdred/t_mkfringecor.x
+noao/imred/ccdred/t_mkillumflat.x
+	Files missing; "." in 14th column.  (2/6 SRo)
+
+[Several minor errors in new relink-sysgen; didn't compile newly-added
+[files in mkpkg.sf w/o pass2 optimization, irafks tried to call rename.
+[Still getting:
+    
+    dictionary starts at 1073968624 (010000672760)
+    pfileload, task cl
+    task `cl' has no param file
+    Fatal startup error.  CL dies.
+
+[irafks.e failed to link because our kludged "rename" routine is in
+[bootlib, not libos, of course.  TODO:  investigate better way to handle
+[rename(); getting late, so won't try anything now.
+
+[Continuation of notes file begin 2/1/88 for HP-UX port]
+
+unix/os/mkpkg.sh
+	Separate compilation of zsvjmp.s; pass 2 of the optimizer causes the
+	routine to fail!  (2/11 SRo)
+
+sys/fio/open.x
+sys/fio/filopn.x
+	After grubbing around for a while trying to figure out what was
+	wrong with file descriptors and/or os channels, tried compiling
+	these routines without optimization.  For the first time, this
+	permitted getting all the way to the "cl>" prompt, but with all
+	the CL debugging turned on.  I used ADB to turn off debugging
+	(cldebug/W 0), but it kept getting turned on automatically.
+	I was able to have the system task do a successful long directory
+	listing of hlib$motd, but was unable to type it out.  Everything
+	looked so badly garbled, that:
+
+unix/hlib/mkpkg.inc
+	Set optimization flag to "O1" rather than "O2".  If all works well
+	tomorrow morning, I'll at least know I'm looking at optimizer, not
+	system, bugs.  (2/11 SRo)
+
+[Ran RMBIN from the root; started new sysgen.]
+
+[5-hour sysgen, only minor incidents, mostly due to missing >14char filenames]
+[Same startup symptoms firing up CL:
+    
+    dictionary starts at 1073968624 (010000672760)
+    pfileload, task cl
+    task `cl' has no param file
+    Fatal startup error.  CL dies.
+
+[Recompiling fio$filopn.x with NO optimization (rest of system is now at
+[opt level 1 rather than 2 originally) gets past that problem but again
+[cldebugging is turned on automatically so at 1200 baud you have to wait
+[about 5 minutes for the prompt.  A lot of things are still screwed up --
+[can't access hlib$motd (can from system process run standalone); the
+[command "show iraf" generates an error with no return to the prompt;
+[^C then causes error recursion and the CL dies.
+
+unix/hlib/config.h
+	Finally realized there was another LEN_JUMPBUF after seeing the
+	global variable cldebug get trashed by setjmp after 16 words, same
+	as the old LEN_JUMPBUF in the Sun HSI.  Increased to 51, started 
+	another sysgen.  (2/12 SRO)
+
+[CL comes up fine now, and all the builtins I tested work fine.  "directory"
+[results in an eventual core dump, with possible error recursion.  Running
+[the system process standalone just generates a segmentation violation.
+[As I am working from home, without access to printouts or another terminal,
+[I decided to take advantage of another 48 hours before getting back to the
+[office by stripping all binaries and recompiling everything with NO
+[optimization (last sysgen was with -O1).  Since filopn.x generates a fatal
+[error even compiled with -O1, I consider it reasonable to gen the whole
+[system without opt, then fix all the non-opt bugs, then start increasing
+[the level of optimization to see just how bad it is.  (2/14 SRo)
+
+Best so far.  CL comes up fine, can do direN	|ctory listings etc. without
+system process dying.  IMDEBUG/MKIMAGE still coredumps with no warning to6\D5|
+the CL, and when "bye" is given, the CL warns about an error in the subprocess
+then hangs.  2 ^C's generate error recursion with CL death.  Apparently there
+are some routines causing fatal problems even with optimization level 1, but
+at least there are some other bugs to isolate first before tackling opt.
+(2/15 SRo)
+
+unix/hlib/iraf.h
+unix/hlib/libc/xnames.h
+	Defined getpid as xgetpd; with no trailing underscores in HP-UX,
+	SPP getpid collides with UNIX getpid.  (Symptom was infinite
+	recursion in getpid->zgtpid->getpid...)  (2/16 SRo)
+
+unix/hlib/motd
+	Updated banner page for HP-UX.  (2/16 SRo)
+
+unix/as/zsvjmp.s
+	Set value of "status" to zero, as this had been neglected originally.
+	Symptom was infinite error recursion in the CL for commands such as
+	"lpar junk" (not infinite stack accumulation, due to the nature of
+	setjmp/longjmp).  (2/18 SRo)
+
+[Another relink sysgen, as everything links with zsvjmp.s]
+
+[MKHELPDB got stuck; name collision between spp rename and faked UNIX 
+[routine.
+
+unix/hlib/iraf.h
+unix/hlib/libc/xnames.h
+unix/os/zfrnam.c
+unix/boot/bootlib/rename.c -
+	Defined RENAME as xfrnam to avoid name collision, removed earlier
+	rename.c, which didn't belong in bootlib in the first place, and
+	added u_rename() function to zfrnam.c.  (2/19 SRo)
+
+pkg/cl/main.c
+	Modified memneed() to add memory on 64-bit boundaries.  Otherwise,
+	there is a bus error whenever a double floating point word that
+	is not 64-bit aligned (in actual memory, not just relative to
+	some data structure) is loaded into a floating point register.
+	Must also have next fix as well.  (2/25 SRo)
+
+pkg/cl/pfiles.c
+	In one place, after a call to memneed(), there was verification
+	code to assure synchronization; this failed when memneed() was
+	modified to be 64-bit aligned.  Current fix is a shameless hack.
+	(2/25 SRo)
+
+[Success!!  I can load packages, stat images, get graphics in a gterm
+[window over the phone lines from "urand | graph", etc.  There will
+[doubtless be further bugs when more exhaustive testing is undertaken,
+[but things look far better than at any time up til now.
+
+dev/pix.imh
+dev/pix.pix
+	Due to tape problems when I originally prepared the source tape,
+	the standard dev$pix 512*512 short image was not on tape.  I brought
+	a separate tape with the binary image in FITS format, but forgot
+	to read it in before I had to dash off to the airport, so I built
+	the image from a Mandelbrot set test program I copied over the 
+	phone line into local/sr/mandel.x.  (2/29 SRo)
+
+unix/hlib/alloc.e
+	Had Jim Dillon change ownership to root.  (2/29 SRo)
+
+unix/hlib/iraf.h
+	Name collision with getuid(); defined as xgetud.  Symptom was
+	segmentation violations in wfits and in the CL when attempting
+	to allocate the drive.  (2/29 SRo)
+
+dev/devices
+	Cleaned up and added all relevant aliases.  SysV uses /dev/rmt/*
+	and /dev/mt/* for raw and block special device names respectively;
+	only the sysmgr is supposed to be able to use /dev/mt/* devices,
+	so these need not be added as aliases.  However, the standard
+	AT&T device installation leaves the tape head positioned after
+	the 2nd EOF mark during write/close; if special minor device
+	names are added, the interface is "berkeley style".  Convention
+	adopted here was a trailing "b" for those device names, for lack
+	of anything better.  The device bits are as follows for Berkeley:
+
+	    crw-rw-rw-   (...) 0x140000 Mar  1 17:39 /dev/rmt/0hb
+	    crw-rw-rw-   (...) 0x1c0000 Mar  1 17:39 /dev/rmt/0hnb
+	    crw-rw-rw-   (...) 0x120000 Mar  1 17:38 /dev/rmt/0mb
+	    crw-rw-rw-   (...) 0x1a0000 Mar  1 17:39 /dev/rmt/0mnb
+
+	IRAF entry for drive 0 on the "hpufoca" machine is as follows:
+
+	    mta		rmt/0hnb rmt/0hb rmt/0mnb rmt/0mb \
+			rmt/0hn rmt/0h rmt/0mn rmt/0m 
+	    mta.6250	rmt/0hnb rmt/0hb rmt/0mnb rmt/0mb \
+			rmt/0hn rmt/0h rmt/0mn rmt/0m
+	    mta.1600	rmt/0mnb rmt/0mb rmt/0hnb rmt/0hb \
+			rmt/0mn rmt/0hn rmt/0h
+
+	The numeral is the drive number, h=high, m=medium, and l=low
+	density, "n" is for no-rewind.  This does appear more rational
+	than BSD UNIX.  (3/1 SRo)
+
+noao/astutil/pdm/pdmstats.x
+noao/astutil/pdm/mkpkg
+	Transferred this file over the phone, formerly called
+	pdmstatistics.x, >14 chars; lost during 1st sysgen.  (3/1 SRo)
+
+noao/twodspec/apextract/t_apnorm.x
+noao/twodspec/apextract/mkpkg
+	Transferred from noao; >14 chars.  (3/1 SRo)
+
+noao/ccdred/src/t_badpixim.x
+noao/ccdred/src/mkpkg
+	Same.  (3/1 SRo)
+
+[Ran RMBIN and began a new sysgen to ensure recent changes to iraf.h
+[get picked up everywhere (just relinked a couple of executables by hand
+[after getuid() change).  (3/1 SRo)
+[Tue Mar  1 19:47:39 PST 1988 -->  Wed Mar  2 00:48:55 PST 1988
+[5-hour sysgen (full recompile & relink); roughly same as on Model 850.
+
+noao/imred/dtoi/hdicfit/hdicgundel.x
+noao/imred/dtoi/mkpkg
+	Re-transmitted this file (formerly named hdicgundelete.x), which
+	got deleted during one of the last sysgens, as it still had >14
+	chars, and the .o file replaced the .x file during compilation.
+	Although renamed back on lyra, it still was not returning function
+	values, so just added 2 "return(0)"'s.  (3/2 SRo)
+
+noao/imred/ccdred/src/t_mkfringe.x
+noao/imred/ccdred/src/t_mkillumft.x
+noao/imred/ccdred/src/mkpkg
+	Transferred these files with shortened names from Tucson; >14 char
+	files were trashed earlier.  (3/2 SRo)
+
+[Ran IRAF test procedures, including tape drive ones, and using the
+[dev$pix created from the Mandelbrot Set, as original one didn't make
+[it.  No problems encountered.  (3/2 SRo)
+
+[Ran benchmarks over dialin, excluding image display, networking, and
+[multiple-terminal graphics ones.  No software problems encountered.  (3/2 SRo)
+
+unix/os/zfrnam.c
+	Had neglected to unlink oldfile when implementing BSD rename()
+	with link/unlink.  (3/2 SRo)
+
+local/terminfo
+local/terminfo/s/sun
+local/terminfo/s/sun24
+local/terminfo/s/sun34
+local/terminfo/s/sun40
+	Created this directory to hold private terminfo descriptions.
+	A new description may be compiled by first using untic(1M) to 
+	decompile one of the existing entries in /usr/lib/terminfo/?/file,
+	editing the result, setting the environment variable TERMINFO
+	to a pathname, and running tic(1M) to compile the entry.  Tic
+	actually creates the single-letter subdirectory, and names the
+	resulting file from EACH alias in the untic'd file.  To use a
+	non-standard terminfo description, here sun40:
+
+	    % setenv TERMINFO $iraf/local/terminfo
+	    % setenv TERM sun40
+
+	(3/8 SRo)
+
+[ Tar tape cut for CFHT; no further work expected to be done on hpufoca
+[ system at Foster City.  HP-UX/IRAF maintenance & update will now be done
+[ on Model 825 at CFHT.  (3/8 SRo)
diff --git a/doc/ports/notes_v22.st b/doc/ports/notes_v22.st
new file mode 100755
index 00000000..230ab876
--- /dev/null
+++ b/doc/ports/notes_v22.st
@@ -0,0 +1,1185 @@
+Space Telescope Science Institute		iraf$local/notes.st 
+
+[ Many of the below notes and bugs have long been fixed, however the CL   ]
+[ changes have yet to be fully integrated into both ST and NOAO versions, ]
+[ so we'll keep them around for a little longer.  Some notes have been    ]
+[ added below (in [[ ]]) where necessary/appropriate.   JJT 8-Mar-1986    ]
+
+--------------------------------
+Monday  23-DEC-1985 17:32:26.42
+ 
+Subject: CL Changes  Nov-Dec 1985
+	 (T.McGlynn, J.Travisano)
+
+grammar.y
+	- delete opnl's in procedure declarations to eliminate s/r conflicts.
+	- create LP and RP for parentheses to eliminate some expressions.
+	- repositioned initialization processing.
+	- modified var_decls slightly.
+	- if/else fixes, so don't need { if ... }.
+	- better syntax error reporting in scripts: gives (correct) line number,
+	  points to offending position, and continues parsing script for errors.
+
+history.c  gram.c
+	- changes to support above grammar changes
+
+history.c  exec.c  pfiles.c  decl.c
+	- changes to deal with script line numbers correctly, i.e.
+	  task->t_scriptln, which is used in syntax error messages; also,
+	  a fix in the skip_to() function in decl.c.
+
+history.c
+	- problem of getting a "begin" in the history when running (or parsing)
+	  a procedure script was fixed.  The original command is now recorded
+	  in the history (and logfile) correctly.  Unfortunately, there is
+	  one case where this does not work -- when get an error parsing the
+	  parameter declarations in a procedure script.
+
+eparam.c
+	- format changes for real arrays (so exponent shows up)
+	- tried to fix MOVE_END problem when going across page boundaries;
+	  can't seem to find the bug, so for now just print out a message that 
+	  says to use NEXT_PAGE a few times instead of MOVE_END.
+
+pfiles.c  param.c  gram.c
+	- added support for '\r' and '\f', so can be used in prompt strings 
+	  for better formatting control  (\f not fully supported in EPAR yet)
+
+modes.c  decl.c  pfiles.c
+	- whitespace-only filename parameters are turned into null strings;
+	  so users can check null filenames easily in a script (fn != "")
+	  without having to deal with whitespace.  Filenames with whitespace
+	  only are not really legal anyway (?).
+
+modes.c 
+	- bug fix to prevent trashing of enumerated parameters in certain
+	  instances.  
+
+param.h
+	- minor typo   'ai' --> 'ar'
+ 
+--------------------------------
+Friday  27-DEC-1985 14:47:48.01
+ 
+Subject: CL history editor		[[ known feature ]]
+ 
+The following is another lexmodes=yes problem:
+
+	pl> contour img1[*:16,*:16]
+		...
+	pl> surface ^^
+	surface img1[*:16
+	Warning: ...
+
+The get-arguments code in pkg/cl/history.c checks for comma-delimited strings.
+Putting the whole argument in quotes, i.e. "img1[*:16,*:16]", and then using
+^^ works fine.  (No fix/change was made.)
+ 
+--------------------------------
+Friday   3-JAN-1986 14:59:06.87
+ 
+Subject: Local vars in CL procedure scripts
+ 
+It is generally assumed that local variables in CL procedure scripts, i.e.
+those after the "begin" statement, will be initialized by the user with 
+simple assignment statements.  There is one (possibly more) case where this
+assumption can cause problems.  For example,
+
+			...
+		begin
+			string  buf
+
+			if (fscan (plist, buf) != EOF) ...
+			...
+
+Here, "buf" is used before being initialized, and the result is an error
+saying "Attempt to use uninitialized local variable 'buf'".  Perhaps local,
+uninitialized variables should be initialized automatically by the CL, but
+have done nothing to fix/change this yet; just making a note of it.
+ 
+--------------------------------
+Tuesday   7-JAN-1986 15:37:59.59
+ 
+Subject: Miscellaneous
+ 
+These are various notes and suggestions by IRAF users at STScI and elsewhere.
+I decided to finally add them all here since they were beginning to pile up
+on various scraps of paper on my desk.  Some of them are minor bugs, but most
+are suggestions of some kind.  Nothing has been done with any of them in terms
+of IRAF changes.  Most of the text is from mail messages or typed in verbatim 
+from paper copies.  Any notes by me (JayT) are indicated in brackets [].
+
+
+From ST users:
+
+CL
+   Would it be possible to put a feature into iraf whereby you say
+'task=xxx', which would then set a default so that you could just 
+type lpar, or an input, without having to specify which task?  
+Ie, instead of having to type 'xxx.infile=etc', you could specify
+the task and then just type 'infile=etc', with iraf filling in
+the task name.  This would not interfere with those who like the
+system as it is, but could streamline things for those of us who
+like the way AIPS does things.
+
+Integer parameters
+  We have encountered another peculiar feature of IRAF.  Suppose you have a
+parameter that is declared as integer in a .par file, and the user attempts
+to put in a value for that integer that exceeds the range of INT*4.  The cl
+fills in that parameter with the value 'indef', a character string.  When
+SDAS goes to read the parameter, we get a crash because the parameter is not
+in integer form.  Now, it seems that a parameter declared as an integer ought
+to be an integer no matter what, not a character string.  Wouldn't it be better
+to leave the parameter value unchanged from its current or default value rather
+than put in this string?
+
+
+From RAL users:
+
+CL Parser
+	li> ?? | words | match ':' stop+| sort | table
+
+	does NOT work correctly, but separating the "+|" to "+ |" works okay.
+
+Help on parameter prompt
+	It is very complicated to provide additional help at the prompt for
+	parameter stage especially for non-string parameters.  This facility
+	is almost essential to provide a user-friendly interface. 
+	For example:
+		A string specified in the parameter file is output if ? is
+		typed in response to a prompt or possibly even enter the help
+		system.
+
+	[NOTE: One can make the prompt quite verbose, up to something
+	like 2K characters; e.g., many SDAS prompts are long and multiline.]
+
+Range check and default display in sexagesimal
+	There needs to be an option in the parameter file to cause the range
+	check and default information to be output in sexagesimal.  For example,
+	it is ugly to type in 12:34:56.7 and have it reappear as 12.582417.
+
+Date type
+	I think there ought to be special facilities for handling dates.  At
+	present you can't enter a date all in one line (except using a
+	grotty fudge involving sexagesimal, which precludes proper range
+	checking), and if you enter the Y,M,D separately you can get things
+	like 1985 2 30 past the range checks.
+
+
+From U. of Cal/San Diego (Doug Tudhope):
+
+lists.gcursor [and imcursor]		[[ fixed in feb release ]]
+	Get syntax error line 2.  [known "feature" since CL2 grammar]
+
+	[NOTE: doing an "lpar gcursor" activates the graphics cursor, 
+	but then get an error of "EOF encountered in list parameter..."]
+
+plot.graph task
+	If only 2 points are given, only the axes are drawn, e.g.
+
+		pl> graph STDIN
+		10 10
+		20 20
+		<EOF>
+			axes, but no line!
+		pl>
+
+images.imtranspose
+	Made a transposed output file of a real 190*800 image -> 800*190
+	but neither onedspec.splot nor images.implot would work on it.
+	they stopped with "reserved operand fault".
+	When imcopy run on transposed image, got "pixel storage file truncated".
+ 
+--------------------------------
+Tuesday   7-JAN-1986 15:51:02.98
+ 
+Subject: pkg/softools/boot/spp/xc.c  [VMS]	[[ now in vms/boot/spp/ ]]
+ 
+Added EXTEND_SOURCE option for calling Fortran compiler from XC.  This lets
+source statements go up to column 132 (instead of 72).  One line added to
+source:
+
+fcompile() {
+	...
+	sp = strcpy (outbuf, F77);
++	sp = strcpy (sp, "/EXTEND");	/* Allow statement in cols 1-132 */
+	if (portable)
+	...
+}
+ 
+--------------------------------
+Tuesday   7-JAN-1986 16:11:20.85
+ 
+Subject: pkg/images/tv/display/deanza/*		[[ updated in march ]]
+ 
+Deanza now works with tv/display under VMS!  All of the source files and Deanza
+libraries are here.  See the README file for more detailed information.
+
+Also changed "pkg/image/tv/display/mkpkg.com" to make the Deanza code instead
+of the IIS-dependent code. 
+ 
+--------------------------------
+Wednesday   8-JAN-1986 12:21:09.73
+ 
+Subject: pkg/imred/.../*.e		[[ fixed with new iraf$bin/ dir ]]
+ 
+The ONEDSPEC executables are copied all over the place into IMRED.  Comments in
+the mkpkg.com files say this is to use different par files for different
+directories.  There's GOT to be a better way, as this eats up a lot of
+diskspace (and tape as well at distribution time), which we always seem to be
+running up against here.
+ 
+--------------------------------
+Friday  10-JAN-1986 15:29:37.13
+ 
+Subject: More SDAS concerns/suggestions
+ 
+Environment variables	[[ discussed, to be resolved ]]
+	When a script task ends or a user bye's from a package, all "set"
+	declarations made in the task or since the package started are
+	"popped" during task restoration.  Comments in pkg/cl/exec.c indicate
+	that this is for keeping the environment the same across processes.
+
+	However, this can lead to confusion.  If a user does a "set stdgraph="
+	and later bye's out of a package, stdgraph reverts back to the 
+	previous value, just as any other environment variable.  The same
+	thing occurs in script tasks during the restore, making it difficult
+	to have global environment variables.  Putting a "keep" in scripts at
+	various places can get around this to some degree, but it's sometimes
+	awkward.
+
+Process cache
+	SDAS has been set up under IRAF such that the user can choose which
+	version of SDAS he wants (baseline|standard|develop).  This choice
+	can be made when starting the sdas package or any of its packages.
+	There is a problem, however, when running a package from 'standard'
+	and then running the 'develop' version when the executable is already
+	out there.  When a task is invoked, it will simply use the subprocess
+	already in the cache, even though it's a different executable (with
+	the same IRAF logical name).
+
+	The suggestion that came up was to do an implicit "flprcache" whenever
+	there is a "bye" to a package, i.e. when all the tasks associated with
+	the executable are gone.  I've looked at this a little bit and don't
+	see an easy way of determining when we're bye'ing from a package which
+	has tasks that are in an executable.  I imagine there's a decent amount
+	of overhead associated with checking all the tasks associated with
+	an executable as well.  In general, getting rid of old executables
+	does make sense if they're not longer referenced, since it frees up 
+	system and user resources (especially important on VMS given the
+	large process and executable sizes).
+
+Table parameters
+	SDAS and CDBS now have a new type of input file, a table, which may or 
+	may not have a header as well.  They have asked if it would be easy
+	to add a new parameter (or two) to IRAF, i.e. a table parameter and
+	possibly a table-with-header parameter.
+
+	I don't think this is a good idea, as it is something which only
+	benefits SDAS and CDBS, and does very little if anything for IRAF.
+	I have encouraged the SDAS people to find an SDAS-only solution to
+	this problem using existing IRAF facilities.  One simple way is to
+	have tasks which use tables to have a 'type' parameter which tells
+	if the input file is a table or something else.
+ 
+--------------------------------
+Tuesday  14-JAN-1986 08:48:36.11
+ 
+Subject: doc/clintro*	[[ missing again, noao has most recent version ]]
+ 
+Copied the TeX source for the CL User's Intro doc from Peter's directory
+to the general IRAF DOC directory.
+ 
+--------------------------------
+Tuesday  14-JAN-1986 10:49:06.01
+ 
+Subject: Size of IRAF...	[[ resolved w/ Feb release ]]
+ 
+A concern has risen, once again, on the size of IRAF.  Garrett Jernigan
+(Berkeley Space Sciences Lab) has mentioned problems finding diskspace to
+handle all of IRAF.  The suggestion he made to Peter was "to split the source,
+obj and executables into separate libraries for the distribution, or at least
+put them into different sub-directories.  If either a tape could be generated
+that only had executables, or that had the whole works, but allowed only the
+required files for execution to be loaded it would be a real boon."  I guess
+this means having something analagous to the bin/, src/ scheme in Unix.
+
+I think a better solution to this is to add something to the installation docs
+to describe how to load only parts of IRAF, i.e. everything, or no source,
+etc., so the IRAF installer can load only the parts needed/desired.  Both Tar
+and Backup can handle selective copying in some manner. 
+ 
+--------------------------------
+Tuesday  14-JAN-1986 11:37:46.40
+ 
+Subject: CL strings
+ 
+It is currently impossible to get the length of a string in the CL.  This
+should be quite trivial to implement, but it is not.  The documentation on
+"paramaters" states that p_length contains the maximum length of the string,
+though in reality, saying =param.p_length simply prints the string, just as
+=param does. 
+
+There should be some way of getting the current length of a string, since it
+could be used as the 'last' parameter in stridx, for getting the rest of a
+string starting at column n.  ST users have continually asked me about ways to
+get the current length of a string parameter (e.g., from within a CL script).
+
+One solution is to change the meaning of some of the parameter attributes for
+string parameters to something which makes more sense: 
+
+	p_length  --  contains the current string length, updated whenever
+		      the parameter is changed.
+	p_max     --  contains the maximum string length
+
+These would require changes primarily in param.c and gram.c.
+
+Also, currently trying an =param.p_min or p_max on a string parameter results 
+in an access violation.
+
+
+===> Released new Public version of IRAF at STScI,  Mon Jan 13, 1986 <===
+
+===> Sent Notes, CL changes, SDAS-related items to KPNO,  Thu Jan 16, 1986 <===
+
+ 
+--------------------------------
+Thursday  16-JAN-1986 13:58:15.69
+ 
+Subject: pkg/cl/config.h
+ 
+Changed DICTSIZE from 20000 to 25000 and STACKSIZ from 4000 to 8000, to deal
+with large scripts and tasks with zillions of parameters now used at STScI
+which have been causing some overflows.  The VMS CL's executable size is no
+larger, since uninitialized arrays are allocated at run-time. 
+
+Also changed NFGPROC from 4 to 3.  Originally changed in an effort to improve
+performance, it's causing more problems with page-file quotas because of the
+very large SDAS executables, so back it goes.
+ 
+--------------------------------
+Friday  17-JAN-1986 09:25:22.96
+ 
+Subject: Loading packages from within procedure scripts	  [[ resolved below ]]
+ 
+It is a known "feature" in the CL that packages cannot be loaded from within a
+procedure script or from within braces.  An old-style script, like the current
+IRAF package scripts, can contain statements which load packages (e.g. onedspec
+loads the list and plot packages). 
+
+Loading packages from within procedure scripts should be supported at some
+point (if possible).  SDAS uses procedure scripts almost exclusively now, even
+their package scripts are procedures. 
+
+Checking into it a little bit, it appears that putting a `keep' statement in
+the package script fixes this problem.  But this is not a good solution for
+general interactive use.  A possible solution is to add an implicit `keep' when
+a cl() call is made from a script called by a script (as in most package
+scripts).  This may be the easiest solution and will require no changes to
+existing package scripts. 
+ 
+--------------------------------
+Monday  20-JAN-1986 11:17:09.92
+ 
+Subject: pkg/language/doc		[[ used Feb release instead ]]
+ 
+A few minor changes to the help text; typos, corrections, added examples, etc.
+ 
+--------------------------------
+Monday  20-JAN-1986 16:42:18.87
+ 
+Subject: pkg/cl/Makelib			[[ use mkpkg instead ]]
+ 
+Corrected Makelib file to contain correct include files for CL source.
+ 
+--------------------------------
+Tuesday  21-JAN-1986 12:25:29.74
+ 
+Subject: pkg/system/gripes.cl		[[ now in vms/hlib/ ]]
+ 
+Changed to mail entire gripe text to IRAF development account, as in KPNO
+version, and not just a message that a gripe has been made.  Also changed
+to use `userid' for the From field instead of `home'.
+ 
+--------------------------------
+Tuesday  21-JAN-1986 15:37:48.27
+ 
+Subject: pkg/cl/grammar.y
+ 
+Added initialization code for the label list structure used for goto statements
+in CL scripts.  Simply added "label1 = NULL;" statements to the three places in
+the grammar where things are initialized.  The absence of this would eventually
+cause access violations and other fatal side effects when goto's were used
+again and again. 
+ 
+--------------------------------
+Wednesday  22-JAN-1986 09:12:46.73
+ 
+Subject: pkg/cl/builtin.c		[[ fixed at noao too ]]
+ 
+Two instances of
+		flags != LT_PFILE;
+changed to
+		flags &= ~LT_PFILE;
+ 
+--------------------------------
+Friday  24-JAN-1986 08:11:29.20
+ 
+Subject: pkg/cl/pfiles.c
+ 
+Added line to reset parse state in certain circumstances within a script.
+ 
+--------------------------------
+Tuesday  28-JAN-1986 09:16:18.48
+ 
+Subject: sys/fmtio/lexnum.x		[[ fixed at noao too ]]
+ 
+A previous fix to lexdata.xi caused a bug in lexnum.x to show up, although the
+relation between the two is unknown.  The stk_ip[] array in lexnum() was
+declared as short; this would sometimes overflow since it was storing pointers
+which could be quite large.  This showed up when a user tried to add a field in
+an image header with 'hedit', resulting in an arithmetic trap.  The fix is to 
+declare stk_ip[] as int instead of short. 
+ 
+--------------------------------
+Tuesday  28-JAN-1986 11:06:27.14
+ 
+Subject: GIO and graphcap		[[ fixed in Feb release ]]
+ 
+Setting stdgraph to tek4014 results in an "openws: illegal graphics window"
+error message when running the graph task.  Using showcap to see what is
+really in the graphcap entry shows that although it points back to tek4012,
+all of the upper case values (X1,X2,Y1,Y2,etc) do not get set properly.
+ 
+--------------------------------
+Tuesday  28-JAN-1986 11:44:54.72
+ 
+Subject: pkg/cl/exec.c			[[ #ifdef st stuff removed 3/11 ]]
+ 
+Quick patch to allow packages to be loaded from within any type of script. This
+fix has been #ifdef ST'd for now (ST is #define'd in config.h). Basically, when
+a "cl" or "clbye" statement is encountered within a script, the package is kept
+for the duration of the script task that called it. 
+ 
+--------------------------------
+Tuesday  28-JAN-1986 16:29:25.83
+ 
+Subject: pkg/twodspec/longslit/apdefine.x	[[ fixed at noao too ]]
+ 
+Was getting a lot of "adjustable array dimension errors" when running apdefine.
+The following changes fixed them: 
+
+	real  apdata[3, naps]	 -->  real  apdata[3, NAPS]
+	real  imdata[npts]	 -->  real  imdata[ARB]
+
+In the original code, if 'naps' or 'npts' were invalid (e.g., zero or negative)
+when the arrays were declared, this error occurred. 
+ 
+--------------------------------
+Monday   3-FEB-1986 10:25:45.69
+ 
+Subject: iraf$vms/loc.c		[[ ST tool, moved to local/ ]]
+ 
+Threw together a quick and dirty Lines-of-Code counter to handle C, SPP,
+Fortran, MACRO and Ratfor source files for IRAF.  It only counts non-blank and
+non-comment lines, considering them "executable".  (NASA folks like this
+software metric to see how much we're supporting.) 
+ 
+--------------------------------
+Monday   3-FEB-1986 13:00:23.77
+ 
+Subject: pkg/twodspec/longslit/apextract.x	[[ fixed in Feb release ]]
+ 
+Changed
+	int	fopen(), ...
+to
+	int	open(), ...
+
+Would result in a "bad file descriptor" error message in IRAF/VMS since open()
+function was assumed to be real instead of int.
+ 
+--------------------------------
+Tuesday   4-FEB-1986 13:40:44.07
+ 
+Subject: sys/os/zopcpr.c  [VMS Kernel]
+ 
+Added the following initialization code before the call to ZOPNPR to prevent
+error recovery problems which occurred occasionally. 
+
+	*inchan = *outchan = XERR;
+ 
+--------------------------------
+Tuesday   4-FEB-1986 15:43:51.21
+ 
+Subject: sys/tty/ttyputl.x	[[ see below... ]]
+ 
+The parameter 'map_cc' in this routine is declared as 'int', but everything
+that calls it (e.g. lprint, type, page, help), passes in a 'bool'.  This is
+probably a bug and most certainly a possible portability problem.  I did not
+change anything, but 'map_cc' should probably be treated as a 'bool' in this
+routine.
+ 
+--------------------------------
+Wednesday   5-FEB-1986 13:47:01.28
+ 
+Subject: pkg/cl/exec.c
+ 
+In mk_startupmsg(), added redirection support for STDERR, so the iraf main will
+know about it as well as STDIN and STDOUT (for STDERR, the string sent down is
+" 5> $").  A low-level SPP routine used by SDAS for error logging depends on
+knowing the redirection status of STDERR. 
+ 
+--------------------------------
+Wednesday   5-FEB-1986 16:30:12.55
+ 
+Subject: sys/os/zfiopr.c  [VMS]		[[ in Feb release ]]
+ 
+Made changes in the memory allocation strategy.  Instead of using _zmaloc and
+then mapping to it, let the $crmpsc and $mgblsc system services create and map
+the global memory sections.  This is a simpler and more standard way of doing
+things, according to the examples in the VMS documentation.  The system service
+$deltva is used to delete the sections. 
+
+These changes were prompted by spurious errors when creating connected
+subprocesses, with the following VMS error from $crmpsc: 
+
+	SECTBLFUL, section table (process/global) is full
+
+There is a system paramater (GBLPAGFIL) that controls this and may be too low.
+However, the initial implementation of zfiopr with _zmaloc may have been
+causing some troubles as well.  Memory sections may not have been fully
+unmapped/deleted because of problems with memory (de)allocation in the context
+of global pagefile sections.  The solution mentioned attacks this concern,
+and it is better than changing system parameters in the long run.
+
+Inter-process communication still works fine with this new implementation of
+zfiopr and I haven't been able to recreate the error above, so I'm hoping it's
+fixed and behaves better as far as deallocation of global pagefile sections.
+
+Warning: DEC recommends that programs which allocate memory not mix allocation
+techniques (lib$get_vm vs. $cretva/$expreg), so there still may be some strange
+problems.  The full warning is in the VMS System Services manual and some notes
+on it are in sys/os/zvaloc.c. 
+ 
+--------------------------------
+Wednesday  12-FEB-1986 09:07:16.44
+ 
+Subject: sys/os/zmain.c  [VMS]
+ 
+For interactive HOST and non-batch DETACHED processes, the error channel is now
+set to the output channel explicitly.  It used to be opened as a separate
+channel to the VMS SYS$ERROR.  This makes no difference within IRAF, as FIO
+(and the CL) keeps track of them as separate entities.  It does, however, give
+us more control over the VMS SYS$ERROR stream, for example, to redirect
+SYS$ERROR to a file to get SDAS tracebacks, etc. 
+
+Also modified to translate SYS$ERROR for the logical assignments made when a
+connected subprocess (rather than assigning in/out/tt/command to "SYS$ERROR").
+ 
+--------------------------------
+Wednesday  12-FEB-1986 09:22:34.24
+ 
+Subject: pkg/cl/eparam.c
+ 
+A number of changes have been made:
+
+	- bug fixes for arrays and multiline prompts, and movement in 
+	  multiple pages when these things are around.
+	- bug fixes for old patches - the "real" bugs have been found 
+ 	  and fixed.
+	- enhancement for hidden parameters; now, Eparam output of hidden
+	  params (when showall set in epinit) is similar to Lparam, i.e.,
+	  `(name = value) prompt' and for arrays,  `(name) prompt \n values'
+	- updated and added comments where appropriate (and necessary)
+	- made all debugging/diagnostic code (within eparam) print at the
+	  bottom of the screen, to prevent screen rolling while in eparam.
+	  cldebug messages elsewhere still cause screen craziness, however.
+	- a bit of code reorganizing and cleaning up
+
+Eparam continues to get harder to debug.  Some of the changes here will
+hopefully make future debugging easier.  At some point, much of this code
+should probably be redesigned/rewritten (as mentioned before).
+ 
+--------------------------------
+Wednesday  12-FEB-1986 13:01:46.18
+ 
+Subject: pkg/language/language.hd		[[ use Feb release instead ]]
+ 
+Added entry for 'stridx', pointing at "string.hlp"
+ 
+--------------------------------
+Thursday  13-FEB-1986 13:08:00.00
+ 
+Subject: pkg/cl/gquery.c
+ 
+This is used by EPARAM for checking ranges and enumerated values.  Fixed some
+bugs in the range message generation.  Old messages would stay around in a
+static array and show up on different parameters in Eparam; modified to null
+out string when no range specified.  Also did a little bit of cleanup on the
+source file.
+ 
+--------------------------------
+Thursday  13-FEB-1986 13:13:01.10
+ 
+Subject: sys/os/zxwhen.c  [VMS]
+ 
+Changed TRACEBACK code (conditionally compiled to show VMS tracebacks rather
+than recovering) to force traceback to a file as well as the terminal.  This
+also gets rid of the double traceback seen when subprocesses abort.  The output
+file is called ".ERROR", and will be written in the user's current directory
+(if writable).
+ 
+--------------------------------
+Thursday  13-FEB-1986 17:12:52.80
+ 
+Subject: pkg/cl/decl.c
+ 
+Changes to deal with parameters declared in the procedure statement that are
+later defined as hidden.  We print out a warning message and override the mode,
+from hidden to auto.  If the user really wants a parameter hidden, it should
+not be in the procedure statement, as this can screw up positional arguments. 
+ 
+--------------------------------
+Thursday  13-FEB-1986 17:54:59.57
+ 
+Subject: abbreviations in the CL
+ 
+This "feature" continually comes up here at ST.  A lot of people are writing
+scripts here and always having problems with abbreviations.  The comments
+in the abbrev() function in pkg/cl/modes.c says that only interactive (or
+batch) tasks can be abbreviated, meaning tasks called from within scripts
+must always be fully spelled out.
+
+I imagine the original reason for this was to insure "good" script programming
+practices at the expense of convenience.  However, when writing front ends that
+use tasknames as parameters and then call lparam, eparam, etc. (e.g.,
+system.mkscript), it forces the user to type the taskname in full, which makes
+it inconsistent with normal interactive usage.
+ 
+--------------------------------
+Friday  14-FEB-1986 08:27:57.42
+ 
+Subject: pkg/clpackage/clpackage.men		[[ fixed ]]
+ 
+typo:  'utilties' --> 'utilities' for System package
+ 
+--------------------------------
+Friday  14-FEB-1986 09:35:58.21
+ 
+Subject: package rearrangement for ST	[[ to be further resolved ]]
+ 
+Put most of the KPNO-specific and general IRAF packages into a new package
+called NOAO.  This is to avoid name conflicts and confusion with the ST
+software, especially SDAS and CDBS.  The files affected are: 
+
+		lib/clpackage.cl
+	+	lib/noao.cl
+		pkg/clpackage/clpackage.hd
+		pkg/clpackage/clpackage.men
+	+	pkg/clpackage/noao.hd
+	+	pkg/clpackage/noao.men
+
+CLPACKAGE now consists of:  sdas noao language lists softools system.
+ 
+--------------------------------
+Friday  21-FEB-1986 14:34:26.46
+ 
+Subject: lib/clpackage.cl login.cl		[[ now vms/hlib/ ]]
+ 
+Changed startup file and template login.cl so filewait="no" is the default.
+Too many "Waiting for access to file" messages, especially on the logfiles,
+which are in heavy use around here for lots of things besides what the CL
+puts in them.
+ 
+--------------------------------
+Tuesday  25-FEB-1986 13:48:30.21
+ 
+Subject: pkg/cl/builtin.c
+ 
+clhidetask():  Removed check for tasks without parameter files.  This should
+not matter when hiding a task.  The inability to hide foreign tasks prompted
+this change. 
+ 
+--------------------------------
+Monday   3-MAR-1986 13:25:02.14
+ 
+Subject: pkg/cl/eparam.c
+ 
+Minor change in eparam to clear the bottom line before returning to the CL.
+This clears the "<key> for Help" message from the command line, to avoid
+confusion. 
+ 
+--------------------------------
+Thursday   6-MAR-1986 09:24:31.20
+ 
+Subject: system package, copy and rename
+ 
+Copy does not allow wildcard files as output, but rename does.  Thus, copy
+seems to be modelled after the Unix cp whereas rename acts like the VMS task of
+the same name.  This seems inconsistent and is sometimes annoying to users
+here. 
+
+Also, if the copy command cannot read the input file for some reason, the
+resulting error message says that it can't create the output file (because the
+call to zfmkcp fails).  This is misleading, and is due to the logic in
+fio$fcopy and fmkcopy, which check only for the existence of the input file and
+not whether it can be read. 
+
+
+----------------------------------------------------------
+Merge Notes -- NOAO Feb release 
+Starting March 6, 1986  Jay Travisano
+
+Mostly ST-specific notes, but some notes on VMS/IRAF...
+----------------------------------------------------------
+
+Read backup tape to [iraf.new...].  Will merge IRAFX changes into that and then
+	backup whole thing; NOAO has made a lot more changes than we have. 
+
+doc/vmsnotes.* --> doc/ports/*
+	save old vmsnotes files, may be useful
+
+vms/hlib/irafuser.com
+	site-dependent changes; also added MYDISK job logical to deal with
+	dollar signs in disk names.  Will change mkiraf.com to use MYDISK
+	if can't get rid of dollar sign in home disk.  Also, reinstate
+	IMDIRDISK for the IRAFTMP directory...
+***
+	We don't have system logical names without '$' in them and even the 
+	physical names have them too (VAX cluster).  Having another system
+	logical name without the '$' is not the answer here, since we have
+	over 30 cluster disks.  Forcing IRAF sites to change system logicals
+	is an unreasonable method to avoid the '$' (as the installation doc
+	recommends).  It may be easy at NOAO but our experience here and
+	at other VMS-only sites shows otherwise; system managers around here
+	are even reluctant sometimes to raise users' paging file quotas, as
+	it requires more pagefile space on the system disks.
+
+	One solution to this is to have a fully supported (consistent) escape
+	mechanism.  The "disk\\$newton:[irafx]" works in most cases 
+	and is used currently at ST.  The MYDISK job logical for the home
+	directory in the login.cl also helps out.
+
+	A better solution perhaps is to change vfnmap/vfntrans so that 
+	during logical dir translation, a check is added to see if we have
+	an OS path.  If so, don't bother rescanning the string for more
+	logical directories.  This would allow
+
+		set junk = "disk$newton:[iraf.local.jay]"
+		type junk$file
+
+	and after the first translation of "junk$", it would realize that
+	we've got an OS path and continue on with the "file" portion.
+***
+
+vms/hlib/libc/iraf.h
+	site changes for ST; not crazy about site disk and dir names in this
+	file which must be moved to sys$library.  assuming vms logicals
+	will be set correctly so won't need to read this file at run-time.
+
+vms/hlib/gripes.cl
+	added subject to mail message
+	use USERID instead of HOME for From field
+
+vms/hlib/install*.com
+	changed for ST; only install CL and SYSTEM package here
+
+vms/hlib/irafemacs.com
+	newer version of emacs command file, plus a few minor changes for IRAF
+
+vms/hlib/zzsetenv.def
+vms/hlib/login.cl
+vms/hlib/mkpkg.inc
+	setups for ST
+
+vms/hlib/mkiraf.com
+	use MYDISK job logical instead of SYS$DISK; avoids '$' garbage.
+
+vms/os/net/zfioks.c
+	turned on DECnet instead of TCP; never worked all that well, but we'll
+	try it again
+
+vms/os/zmain.c
+	merged in our changes and updated comments
+
+vms/os/zopcpr.c
+	merged in old change missing from noao distribution
+
+vms/os/zxwhen.c
+	merged in new traceback handling stuff
+	*NOTE*: this is currently turned ON for ST, for debugging of access
+	violations and arithmetic faults.  To turn it off, #define NOTRACEBACK.
+
+vms/os/rms.c
+	(debug) references to EP2 changed to _EP2
+
+vms/boot/spp/xc.c
+	added /EXTEND qualifier for Fortran; allow statements in cols 1-132
+
+dev/devices
+	magtape entries for ST cluster
+
+pkg/cl/tests/*
+	Note in Unix notes file says this was deleted because it wasn't used 
+	anymore.  In fact, it has been used here at ST for (crude) regression 
+	testing when making CL changes.  Have moved these into my (Jay) 
+	private directory in case they're needed in the future.
+
+vms/boot/spp/rpp/mkpkg.com
+	DCL syntax errors in "if f$search()" line:
+		() screwed up
+		"then" missing
+	(I booted the tools from scratch, to test everything out)
+
+pkg/cl/*
+	used ST version as a base; merged in NOAO changes where necessary
+
+pkg/cl/mkpkg
+	added lines to lex and yacc the grammar, if stsci and vms, since we
+	muck around with the grammar too.
+	also, typo in install comment (move to bin$, not lib$)
+
+vms/hlib/notes.com rcscom.com  -->  local/
+	these are ST-specific tools; notes file (notes.st) will also be here
+
+doc/ports/ <-- old vms/ctio.hlp vmsprog.hlp  (from old distribution)
+
+backup current ST develop/experimental version (IRAFX) to tape
+backup new merged version to IRAFX
+remake...
+testing...
+everything looks good...
+
+Networking w/ DECnet seems to work fine; tried remote file access, remote
+subprocesses (will be useful for IDM access).  Tried very simple remote tape
+access and didn't work; seemed to abort quickly though as if it failed on
+local host.  The noao notes file says it won't work on VMS because of the
+process structure; not sure what this means exactly -- looks like it should
+work with the allocation built into the kernel server as it is now.  Will
+look into it more later...
+
+dev/hosts
+	set up ST nodes
+***
+	took out the single quotes on the vms executable name (from noao).
+	can't access  "node!iraf$file"  with them in, i.e., the "iraf$"
+	logical doesn't get set up correctly.  appears that the quotes are 
+	left over from some previous syntax.  don't think noao has vms 
+	servers (for tcp) yet (?).
+***
+
+vms/hlib/irafuser.com
+	changed most job logicals to process ones, since they aren't needed
+	at the job level, and job table space is limited around here.
+	(Process logicals are automatically copied when spawning DCL commands 
+	or background jobs.)  So, now (at least for ST),
+		job logicals:  IRAFDISK (IMDIRDISK) IRAFTMP IRAFIRAF IRAFHOST 
+				IRAFHLIB
+	    process logicals:  IRAFLIB IRAFBIN IRAFLIBC IRAFVMS batch-logicals
+
+vms/hlib/mkiraf.com
+	bypass sections that delete login.cl and uparm files;
+	let a new version of the login.cl be made in case user must go
+	back.  for uparm files, the 'out of date' message will be enough
+	to tell the user to do an unlearn.  besides, the sdas par files
+	don't change that much (or do they?)  In any event, I'd get lots of
+	complaints if everyone's par files disappear when running mkiraf.
+
+vms/gdev/
+	made library as is, to resolve link references w/ irafks, display and
+	cv.  For deanza at ST, probably won't use this interface; easier to
+	use old deanza code until new display code and image interfaces are
+	in place.
+
+pkg/language/doc/edit.hlp
+	typo: edcapf --> edcap
+
+pkg/system/doc/directory.hlp
+	typo: \fb --> \fB
+
+pkg/*
+	many packages list a 'revisions' task in the help menu but don't
+	have one in the package; I imagine this is a future enhancement.
+
+pkg/images/tv/display/mkpkg
+                     /deanza/*
+	Added temporary deanza code (vms and stsci dependent).  Changed mkpkg
+	in display/ to make the deanza/ subdir instead.  
+
+dev/graphcap
+	added entry for `deanza'; no more .imh files...Yeah!
+	added entries for Selanar-enhanced vt100 (vt100s), and Pericom.
+
+dev/termcap
+	added/updated ST entries.
+
+vms/hlib/clpackage.cl
+	changed 'page' to 'type'.  if a long motd, user may inadvertantly
+	type ahead and get all screwed up, so just type the message out.
+
+pkg/cl/grammar.l
+	modified to accept double precision real numbers on input, e.g.
+
+		cl> task.param=12d20
+
+	used to give a syntax error.  Simple change in lex input, namely:
+	[eE] --> [eEdD] for real numbers.
+
+vms/as/README
+vms/as/cstr.mar  +
+	Added assembler versions of LIBC string routines; added to list in 
+	README file.  These are much faster than the LIBC string routines
+	written in C, and although they may not make a significant increase 
+	in performance of the CL, we have them, so why not use them.
+
+sys/libc/mkpkg
+	Modified to use as$cstr.s if available, otherwise use the portable 
+	routines written in C.
+
+vms/boot/mkpkg/mkpkg.help
+	typo:  \fmkpkg --> \fBmkpkg
+
+math/mkpkg
+	added "$purge lib$" at end of 'mathgen'
+
+-----------------------
+CL Logging Enhancements
+Feb/Mar 1986
+-----------------------
+
+The following enhancements to the CL logging facilities were made:
+
+	1) a 'putlog' builtin was added, so a user's script or program 
+	   can log important messages and errors
+	2) added logging from the CL itself, when script and executable
+	   tasks are started/stopped (i.e., a task trace)
+	3) errors are logged, from the CL, when from a script or executable
+	4) background logging supported (a result of above changes)
+
+These functions are parameter controlled, by the CL parameter `logmode', e.g.,
+
+	cl> logmode = "commands background error trace"
+			(nocommands nobackground noerror notrace)
+
+The old `keeplog' parameter has the same function, turning the whole thing 
+on or off.
+
+Note:	To avoid file access conflicts (e.g. bkg logging), the environment 
+	variable 'filewait' must be set to "no".  (This is now the default 
+	at ST.)  As a result, some log messages, especially those from the 
+	background, may still not get to the (single) logfile.  The use of 
+	multiple logfiles is encouraged because of this, but SDAS developers 
+	and testers prefer a single logfile with everything in it.  Not much 
+	we can do to change their minds.
+
+
+Source changes in pkg/cl/:
+
+builtin.c
+	Added clputlog() function for the 'putlog' builtin.
+	Added code so that the clerror() function calls putlog with 
+	the error message, when logging is on.
+
+history.c
+	Fixed the code for shared logfile access.  Modified so login/logout
+	messages are not printed for background jobs.
+	Added putlog() function, which formats the log messages from the
+	user and/or the CL and writes to logfile.
+	Added reset_logfile() function to reopen logfile if name is changed.
+	This is only for share_logfile=no and has not been tested here,
+	but it's just a close and reopen.
+
+exec.c
+	Added code to log a message when starting/stopping a script or
+	executable task.  This is the "trace" feature.
+
+bkg.c
+	Added code to log a message when a background job is started or 
+	completes.
+
+errs.c
+	Added code to log the error messsage if a script or executable task
+	(and it hasn't already been logged by clerror()).	
+
+param.h
+	Added P_CL value for p_flags field of the param structure.  This
+	is used to test (quickly) whether a parameter is a CL parameter.
+
+param.c
+	Added check in paramset() for a CL parameter (p_flags & P_CL);
+	if so, call parse_clmodes() (below).
+
+modes.c
+	Added parse_clmodes(), to parse logging control parameter and
+	epinit/ehinit parameters and to call reset_logfile() if logfile
+	name is changed.
+
+clmodes.h
+	Added extern declarations for logging/epinit/ehinit variables
+
+eparam.c
+history.c
+cl.par
+	"epinit" and "ehinit" changed from environment variables to CL params
+	as per mail discussion with Doug.  Removed all setoption() stuff as 
+	this is now taken care of in parse_clmodes() (in modes.c).
+
+hlib/clpackage.cl
+	Removed epinit and ehinit env vars.
+
+hlib/login.cl
+	Added commented out default values for logging and epinit/ehinit
+	parameters to the template login.cl file.
+
+pkg/language/doc/cl.hlp
+		 ehistory.hlp
+		 eparam.hlp
+	Modified due to move of epinit/ehinit vars to CL parameters and
+	addition of new logging parameter.  
+
+pkg/language/language.hd 
+	     language.men
+pkg/language/doc/logging.hlp   +
+		 putlog.hlp   +
+	Added help for the "logging" discussion and the "putlog" builtin.  
+	The "logging" man page talks about the CL logging as a whole, 
+	discussing the parameters involved in a little more detail than the 
+	help on the cl.
+
+-------------------
+
+pkg/cl/*
+	Cleaned up some of the CL source code; mostly just removed some
+	old, useless cldebug statements, etc.  Also cleaned up grammar.y
+	a lot, at least to make the style consistent and more readable.
+	Gram.c and decl.c also got a bit of this as well.
+
+pkg/cl/README
+	Updated text; still referred to Unix "make" and VMS DCL/Makelib
+	generation techniques.
+ 
+--------------------------------
+Monday  24-MAR-1986 12:01:48.70
+ 
+Subject: VMS/IRAF Plotting
+ 
+dev/graphcap
+	Added entries for QMS, EQMS, and NULL (testing) for STScI.
+
+vms/os/ vms.h
+	zfipol.c
+	mcsub.c   +
+	mkpkg
+
+Implemented ZFIOPL for VMS to use NCAR Metacode translator (MCVAX).  A
+spoolfile is written in the necessary VMS file format by ZFIOPL.  On close,
+MCVAX is started up as a subprocess and commands are sent to it to set the
+device (from graphcap DD string), read the spoolfile, and plot until finished. 
+
+This code may depend on peculiarities of the ST version of MCVAX which I don't
+know about. 
+ 
+--------------------------------
+Tuesday  25-MAR-1986 11:53:12.75
+ 
+Subject: vms/boot/bootlib/vfn2osfn.c
+ 
+Changed to return a null string if an error occurs mapping the file; it used to
+return the last result of a filename mapping operation.  This would to lead to
+problems in mkpkg, e.g., 
+
+	$delete dir$sub/file.c
+
+If this file did not exist, the previous filename returned by vfn2osfn() would
+be deleted.
+ 
+--------------------------------
+Wednesday  26-MAR-1986 12:04:53.81
+ 
+Subject: mkpkg
+
+vms/boot/mkpkg/tok.c
+	$ifdef/$ifndef was not working -- bug when setting boolean variable; 
+	fixed.
+
+	changed os_cmd() to host_xc() for do_omake(), do_link(), do_xc(), so
+	the VMS DOCVCL routine can be used (to eliminate some spawning).
+ 
+vms/boot/mkpkg/host.c
+	docvcl() -- don't check return status and change to XYES/XNO; 
+		leave as is (OK or ...)
+
+	added host_xc() routine to call docvcl().
+
+vms/boot/spp/xc.c
+	bug fix -- `firstobj' variable was not being reinited to NULL; caused
+	problems with above host_xc() changes.  Added reinit in do_cleanup().
+
+vms/boot/mkpkg/mkpkg
+	added ../spp/xc.c dependency for xcsub.c
+ 
+--------------------------------
+Friday  28-MAR-1986 09:37:16.83
+ 
+Subject: ttyputline and map_cc
+ 
+pkg/system/lprint.x    
+	   page.x  
+	   type.x
+	./help/houtput.x
+
+	Changed map_cc from bool to int to work correctly with ttyputline(),
+	which expects an int and checks for YES/NO.  In VMS Fortran, .true. is 
+	encoded as a -1, not a 1 (YES).  To change ttyputline() would mean
+	changing the LIBC interface c_ttyputline() so that it knew about this
+	feature of the host Fortran, so let's use the int YES/NO method.
+ 
+--------------------------------
+Friday  28-MAR-1986 10:12:49.38
+ 
+Subject: graphcap entry for selanar hirez 100xl
+ 
+Not sure if this is a graphcap entry problem or a limitation on the selanar
+itself:  When in cursor mode in a task (e.g. onedspec.splot), typing 'c' to
+print the cursor position will print "x,y: ... ..." in the lower left hand
+corner, but then immediately erase it.  Help via '?' does the same thing, i.e.,
+gets printed and erased immediately. 
+ 
+--------------------------------
+Wednesday   2-APR-1986 13:22:46.16
+ 
+Subject: pkg/cl/edcap.c
+ 
+Added the editor name to the eparam help page.
+ 
+--------------------------------
+Wednesday   2-APR-1986 15:24:20.96
+ 
+Subject: vms/boot/bootlib/dcl.c
+ 
+Added interrupt support.  When ^C typed, return status of dcl() (and os_cmd)
+will be SYS_XINT, so MKPKG can deal with the error as on Unix. 
+ 
+--------------------------------
+Wednesday   2-APR-1986 16:51:37.03
+ 
+Subject: vms/boot/spp/...
+ 
+xc.c 		fixed inconsistencies in error/status checking, removed
+		old code, rearranged some functions (main to front, etc).,
+		and general cleanup.
+xc.com		command file to make xc (only)
+mkpkg.com 	call xc.com
+ 
+--------------------------------
+Thursday   3-APR-1986 08:06:49.57
+ 
+Subject: editor
+ 
+Just realized that "editor" is still an environment variable, used by
+eparam/ehistory and the edit builtin.  Epinit/ehinit have been changed to CL
+parameters during the logging changes, but I forgot about this one. 
+
+Should we change "editor" to a CL parameter, too?  If so, it would require
+changes in  pkg/cl/edcap.c,builtin.c,cl.par  and the help files for 
+eparam,ehistory,edit,cl. 
diff --git a/doc/ports/nsoport.hlp b/doc/ports/nsoport.hlp
new file mode 100644
index 00000000..334471aa
--- /dev/null
+++ b/doc/ports/nsoport.hlp
@@ -0,0 +1,193 @@
+.help
+NOAO/NSO IRAF/UNIX installation, Nov. 14-15 1985, S. Rooke
+.br
+
+     A full binary copy of lyra!/iraf (in two tapes) was loaded into the
+sunspot! VAX-11/750 running UNIX at NSO.  The following notes describe the
+various steps taken in the installation.
+
+
+.nf
+1.  Leonard Sitongia selected his /u1/ root directory for IRAF as it contained
+    about 100 Mb in its disk partition.
+
+	% mv /u1 /iraf
+	% vi /etc/fstab		# replace "u1" with "iraf" for ra1d
+	% mount /iraf
+	% vi /etc/group		# add IRAF group members so we can see who
+				# owns the various IRAF files
+	% vipw 			# yanked IRAF group members' entries from
+				# /etc/passwd/aquila
+    Now have /iraf with 100000 bytes available; IRAF developers have accounts
+    for the duration of the installation, mainly so we can easily look at
+    file ownerships.
+
+2.  Read the two tapes into /iraf.
+
+	% cd /iraf
+	% tar -xpf /dev/rmt0	# 1st tape contains /iraf... minus sys/*
+	  (load second tape)
+	% mkdir /iraf/sys
+	% cd sys
+	% tar xp
+
+	    TAPE READ ERROR AFTER libsys.a
+	    tu0: hard error bn25780 mbsr=13080 <ATTN, DTCMP, DTABT, MBEXC>
+	    cr=100 <INCUPE>
+	    ds=54640 <ERR, MOL, WRL, DPR, DRY, PES>
+	
+3.  At this point we looked at the tar listing, and saw that the only files
+    that didn't make it were the following six:
+
+	    Mkpkg.sh
+	    libcur.a
+	    libmain.o
+	    libstg.a
+	    prelink.e
+	    zzsetenv.def
+
+    Not realizing immediately that the 2 libraries must have been development
+    ones (the real ones were already in /iraf/lib), we attempted to bring 
+    them across from Tucson using TIP(xmodem).  
+
+	% vi /etc/remote	# set Tucson baud rate (1200) for Robotics modem
+	% tip us-0		# (U.S. Robotics modem looks in /etc/remote)
+	    (now talking to modem)
+	    atdp 1,602,3259251
+	    (got message from micom at remote, in Tucson)
+	    (had to request class "102" rather than class "2").
+	2% xmodem -sb filename <cr>
+	    (got xmodem message)
+	~? 			# to get help from sunspot! tip; look for 
+				# "receive xmodem binary"
+	~(			# (got prompt for local file name)
+
+    Thus we copied the 2 libraries and Mkpkg.sh over (we would rebuild the
+    other files from files already present).  We also brought over some files
+    from lyra!/u2/rooke... for working on graphcap and stdgraph.
+
+4.  We now have almost the full binary IRAF under root directory /iraf/.
+    Now proceed to set up links outside the /iraf/ directories into a few
+    critical files within it so that all users can access them from a unix
+    shell.
+
+	% su
+	% cd /usr/include
+	% ln -s $iraf/lib/libc/iraf.h iraf.h
+	% cd /local/bin
+	% ln -s $iraf/lib/mkiraf.csh	mkiraf
+	% ln -s $iraf/lib/cl.e		cl
+	% ln -s $iraf/lib/mklib.e	mklib
+	% ln -s $iraf/lib/xc.e		xc
+
+5.  We now configure the magtape device tables and give the KI a real host
+    name then do a "sysgen".
+
+	% vi /iraf/dev/hosts	# create entries for "sunspot!" and "penumbra!"
+	% vi /iraf/lib/libc/kernel.h	# find "TAPEDRIVE_TABLE"; enter correct
+					# magtape devices for sunspot!
+	% su
+	% cd /iraf/sys
+	% make >& spool &
+
+	    (inspecting the spool file found a phase error on envscan.o
+	    from ranlib: libsys.a; mangled string table.
+
+	    % cd /iraf/sys/etc
+	    % rm envscan.o
+	    % touch envscan.x
+	    % cd ..
+	    % make >& spool &		# this time it was OK.
+
+    We have now completed the sysgen; however, there had been a minor stdgraph
+    kernel bug which was removed in a development version of stg_encode I had
+    tip'd over; I replaced /iraf/sys/gio/stdgraph/stgencode.x and rebuilt the
+    stdgraph kernel manually:
+
+	% cd /iraf/sys/gio/stdgraph
+	% make >& spool &
+
+	    (Make wouldn't work; it turned out there was a spurious SPACE
+	    character in the Makefile: "make lib" rather than "makelib" on
+	    the "all: " line; fixed this and rebuilt.)
+
+6.  By analogy with the Johns Hopkins installation, since the system
+    libraries had been modified, I went ahead with relinking the applications
+    packages; furthermore, I had a development version of showcap which I
+    used to replace /iraf/pkg/plot/tshowcap.x with in order to debug the
+    vt240 graphcap entries later on.
+
+	% su
+	% cd /iraf
+	% csh -x Mkpkg.sh >& spool &
+
+    However, talking with Doug Tody during this relink, I found out we only
+    needed to rebuild the DATAIO package.  To save time, I killed the relink,
+    observed that it had been in the middle of the IMAGES package, and 
+    manually completed the IMAGES rebuild:
+
+	% cd /iraf/pkg/images
+	% make >& spool &
+
+    (DATAIO had already successfully built, along with several others.  I made
+    sure that the PLOT package had built successfully with the showcap
+    change.)
+
+7.  All compile-time operations are now complete; we need only modify the
+    run-time environment for terminal and graphcap entries and set up for
+    local "mkiraf"'s.
+
+	% cd /iraf/dev
+	% vi termcap		# provide vt240 entry
+	% vi graphcap		# provide vt240 entry; this was yanked from
+				# my development ReGIS graphcap file which
+				# I had previously "tip"'d over.
+	% cd /iraf/lib
+	% vi mkiraf.csh		# setenv users /u2/compsup/mother/irafusers
+				# and directory names at the bottom (prob. no
+				# changes in these); changed 2 lines about
+				# vt100 vs vt640 to vt240 vs some other term.
+
+	% vi clpackage.cl	# change default device names, version, site:
+
+	    set	printer		= "imagen"		--> "tp"
+	    set	stdgraph	= "vt640"		--> "vt240"
+	    set	stdimage	= "iism70"		--> "? (I forget)"
+	    set	stdplot		= "versatec"		--> "tp"
+	    set	terminal	= "vt100"		--> "vt240"
+	    set	version		= "NOAO/IRAF V2.0"	--> "NOAO/NSO/IRAF V2.0"
+
+	% vi login.cl		# uncommented printer, stdimage, stdplot and
+				# gave them the local names.
+				
+    We also "bgrep"'d some zzsetenv.def files to make sure they weren't 
+    pointing to Tucson pathnames.
+
+8.  This completed the non-graphics part of the installation.  We were now able
+    to bring up the cl successfully:
+
+	% cd (user's main iraf directory)
+	% mkiraf
+	% vi login.cl		# modify as desired
+	% cl
+
+9.  The remainder of the installation involved setting up a workable ReGIS
+    graphcap for NSO's vt240's.  I copied the development graphcap entry I
+    had previously created for the ENCORE HostStation100, and went through
+    the vt240 Programmer's Summary capability by capability.  There were
+    about six changes from the hs100.  Graphics output then worked correctly,
+    but we had the same problem reading the cursor that I had had with the
+    hs100 in Tucson.  It turned out later, back in Tucson, that the problem
+    was that I was directing the cl to "lib$xstdgraph.e" (the "kf" parameter)
+    in graphcap, rather than to "cl" itself.  The precedence for the cl
+    process, when it receives a read-cursor request, is to take the kernel
+    name from the graphcap entry, regardless of the fact that the cl (or
+    any other process) was linked directly with the stdgraph kernel code
+    and calls gki_inline_kernel().  Thus the "kf" parameter in graphcap
+    must point to the cl itself in order to use the inline kernel.  At
+    present, cursor readback does not work with an external kernel.
+
+    Several days after the installation (Nov. 20) I called the "kf" change
+    in to Leonard at NSO.  He made the change and checked out "implot" and
+    "=gcur", and said they worked correctly with no further changes to our
+    ReGIS graphcap.
diff --git a/doc/ports/sun2_032786.doc b/doc/ports/sun2_032786.doc
new file mode 100644
index 00000000..298139db
--- /dev/null
+++ b/doc/ports/sun2_032786.doc
@@ -0,0 +1,152 @@
+SUN/IRAF V2.2 Installation, 6 March 1986	Sun-2, software floating point
+------------------------------------------------------------------------------
+
+/usr/iraf/*****
+/usr/iraf
+	Located IRAF root directory at /usr/iraf, created iraf/local
+	for personal file storage.  Unpacked tar archive of v2.2, 6 Mar
+	version, from master VAX/UNIX system "lyra".  (3/6)
+
+/usr/iraf/local/
+	Unpacked earlier Sun archive of /usr/iraf/local; this contains
+	development stuff for Sun graphics kernels, plus the .login file
+	for the IRAF account.  It is important that this file sources
+	$iraf/unix/hlib/irafuser.csh to pick up environment definitions
+	and aliases.  Make sure iraf root and home directories match
+	the real thing.  (3/6)
+
+unix/as
+unix/as/ishift.s
+unix/as/zsvjmp.s
+	Moved the VAX as/ to unix/vaxas.  Created an empty unix/as and
+	copied the two SUN .s files into it from unix/mc68000.  (3/6)
+
+unix/hlib/mach.h
+unix/hlib/libc/spp.h
+	Set EPSILONR and EPSILOND for the SUN as in unix/mc68000/README.
+	Set BYTE_SWAP2 and BYTE_SWAP4 to NO in mach.h.  (3/6)
+
+unix/hlib/mkmlist.csh
+	Changed bgrep to grep, since bgrep not available in standard
+	UNIX.  (Not important, doesn't have to work, so the efficiency
+	of bgrep on the development machine is worth the mach. dependence.)
+	(3/6)
+
+home$.login
+unix/hlib/mkiraf.csh
+unix/hlib/libc/iraf.h
+	Changed all occurrences of iraf root directory pathname.  (3/6)
+
+unix/hlib/mkpkg.inc
+	Set USE_CALCOMP to no.  (3/6)
+
+/usr/include/iraf.h	-> $hlib/libc/iraf.h
+	Establish this symbolic link as superuser (i.e. %su; cd /usr/include; 
+	ln -s $hlib/libc/iraf.h iraf.h).  This is necessary for compiling
+	IRAF programs.	(3/6)
+
+TODO: unix/hlib/[dif]mach.f
+	These files were NOT set up for the Sun, since we did not have the
+	values, but this should be done later.  Once modified, a mkpkg at the
+	root will recompile all affected programs.
+
+TODO: unix/as/*.x
+	It would be nice to have some additional assembler modules for 
+	efficiency reasons.  See unix/vaxas.  Coding of these can be left
+	for later.
+
+
+/usr/iraf/hlib/libc/kernel.h
+    Commented out DEBUGMEM in order to use the standard UNIX malloc rather
+    than IRAF's version.  This is necessary for some reason on the Sun for
+    SunCGI programs to be callable from SPP programs.  (3/6)
+
+------------------------------------------------------------------------------
+That completes the initial setup.  Now we bootstrap the system.
+
+	% cd $iraf/unix
+	% sh -x mkpkg.csh >& spool &
+
+This builds all the bootstrap utilities, then as a final step compiles the
+portion of LIBSYS in host/gdev, which exercises MKPKG, XC, etc.  If all that
+works things are in excellent shape.  (3/6)
+
+/usr/bin/alloc		-> $hlib/alloc.e
+/usr/bin/generic	-> $hlib/generic.e
+/usr/bin/mkpkg		-> $hlib/mkpkg.e
+/usr/bin/rmbin		-> $hlib/rmbin.e
+/usr/bin/rmfiles	-> $hlib/rmfiles.e
+/usr/bin/rtar		-> $hlib/rtar.e
+/usr/bin/wtar		-> $hlib/wtar.e
+/usr/bin/xc		-> $hlib/xc.e
+	Establish these symbolic links as superuser (e.g. cd /usr/include; 
+	ln -s $hlib/mkiraf.csh mkiraf).  These are required for regular
+	users who do not have a .cshrc or .login which sources
+	$iraf/unix/hlib/irafuser.csh, for running the cl or mkiraf.
+	Ordinarily we only link xc, mkiraf, and mkpkg here, but since we're
+	doing development on the Sun outside IRAF, the rest are useful. (3/6)
+
+unix/hlib/alloc.e
+	This file must belong to root, since it needs root permissions at
+	runtime to allocate devices.  Do the following:
+
+	% cd $hlib
+	% su
+	% /etc/chown 0 alloc.e		(3/6)
+
+-------------------------------------------
+The bootstrap is now complete.  The next step is to do a full system compile.
+
+There are 5 files that need to be hand-compiled without optimization (from
+previous experience on the SUN) to avoid getting in an infinite loop in pass
+c2 of the compiler.  "xc -c" each file to create an object file in its
+directory; mkpkg will then avoid recompiling it.  Note:  see local/bugs
+README for description of "-P" for partial optimization instead.
+
+	sys/fio/fstati.x
+	math/bevington/matinv.f
+	sys/gio/nspp/portlib/gridal.f
+	sys/ki/irafks.x
+	pkg/twodspec/longslit/transform/igsfit/igsfit.f
+
+(The last file wasn't included in the initial hand-compile, but stalled
+the later sysgen in an infinite loop; placed here for completeness next time.)
+Now perform the full system compile (sysgen).
+
+	% cd $iraf
+	% mkpkg >& spool &				(3/6)
+
+	The sysgen was started at 17:02 on March 6, 1986.  It stalled at 9:47
+	Friday March 7, in an infinite loop in:
+	    pkg$twodspec/longslit/transform/igsfit/igsfit.f
+	I hand-compiled it and restarted the sysgen at 13:30, renaming the first
+	spool file spool1.  (3/7)
+
+	The sysgen finished at 15:53 with no further errors (the "Termination
+	code 9" in $iraf/spool is due to another stall in igsfit -- I had
+	hand-compiled the wrong file, so mkpkg stalled again; this time I just
+	killed the lowest-level process and ran mkpkg from longslit/transform
+	by hand during the main sysgen, and later checked that there weren't
+	any collision problems).
+
+	Clock time was thus 19:08 hours, but at least 5 of these hours saw two
+	interactive users (mostly editing, but some compiling) competing for
+	resources.  (3/7)
+
+/usr/bin/xc		-> $hlib/xc.e
+	Established this symbolic link as superuser, now what we have a
+	CL in $iraf/bin.  This completes the software-building part of the
+	installation.  (3/7)
+
+unix/as/ishift.s
+	Would not do a right shift, since the 68010 uses two different
+	instructions to do left and right shifts, unlike the vax, which
+	allows the shift argument to be negative.  Changed to use the ROL
+	and ROR instructions.  (3/14)
+
+sys/gio/stdgraph/stgdrawch.x
+	When stdgraph kernel attempted to draw high-quality text, it 
+	began drawing lines and garbage text all over the screen until it
+	hit a segmentation violation.  Traced to module sgch_flush(),
+	"call stg_polyline (pl, op / 2)", (SHORT op), where stg_polyline
+	wanted an INT for the 2nd argument.  Changed to "int (op / 2)".  (3/27)
diff --git a/doc/ports/sun2_042386.doc b/doc/ports/sun2_042386.doc
new file mode 100644
index 00000000..c2807994
--- /dev/null
+++ b/doc/ports/sun2_042386.doc
@@ -0,0 +1,141 @@
+SUN/IRAF V2.3 Installation, 17 April 1986	Sun-2, software floating point
+------------------------------------------------------------------------------
+
+/usr/iraf/*****
+/usr/iraf
+	Located IRAF root directory at /usr/iraf, created iraf/local
+	for personal file storage.  Unpacked tar archive of v2.3, 17 Apr
+	version, from master VAX/UNIX system "lyra".  (4/17)
+
+unix/as
+unix/as/ishift.s
+unix/as/zsvjmp.s
+	Moved the VAX as/ to unix/vaxas.  Created an empty unix/as and
+	copied the two SUN .s files into it from unix/mc68000.  (4/17)
+
+unix/hlib/mach.h
+unix/hlib/libc/spp.h
+	Set EPSILONR and EPSILOND for the SUN as in unix/mc68000/README.
+	Set BYTE_SWAP2 and BYTE_SWAP4 to NO in mach.h.  (4/17)
+
+unix/hlib/mkmlist.csh
+	Changed bgrep to grep, since bgrep not available in standard
+	UNIX.  (Not important, doesn't have to work, so the efficiency
+	of bgrep on the development machine is worth the mach. dependence.)
+	(4/17)
+
+home$.login
+unix/hlib/mkiraf.csh
+unix/hlib/libc/iraf.h
+	Changed all occurrences of iraf root directory pathname.  (4/17)
+
+unix/hlib/mkpkg.inc
+	Set USE_CALCOMP to no.  (4/17)
+
+/usr/include/iraf.h	-> $hlib/libc/iraf.h
+	Establish this symbolic link as superuser (i.e. %su; cd /usr/include; 
+	ln -s $hlib/libc/iraf.h iraf.h).  This is necessary for compiling
+	IRAF programs.	(4/17)
+
+unix/hlib/[dir]1mach.f
+	Commented out the VAX data statements, and uncommented the IEEE/
+	68000 data statements.  (4/17)
+
+TODO: unix/as/*.x
+	It would be nice to have some additional assembler modules for 
+	efficiency reasons.  See unix/vaxas.  Coding of these can be left
+	for later.
+
+/usr/iraf/hlib/libc/kernel.h
+    Commented out DEBUGMEM in order to use the standard UNIX malloc rather
+    than IRAF's version.  This is necessary for some reason on the Sun for
+    SunCGI programs to be callable from SPP programs.  (4/17)
+
+------------------------------------------------------------------------------
+That completes the initial setup.  Now we bootstrap the system.
+
+	% cd $iraf/unix
+	% sh -x mkpkg.csh >& spool &
+
+This builds all the bootstrap utilities, then as a final step compiles the
+portion of LIBSYS in host/gdev, which exercises MKPKG, XC, etc.  If all that
+works things are in excellent shape.  (4/17)
+
+/usr/bin/alloc		-> $hlib/alloc.e
+/usr/bin/generic	-> $hlib/generic.e
+/usr/bin/mkpkg		-> $hlib/mkpkg.e
+/usr/bin/rmbin		-> $hlib/rmbin.e
+/usr/bin/rmfiles	-> $hlib/rmfiles.e
+/usr/bin/rtar		-> $hlib/rtar.e
+/usr/bin/wtar		-> $hlib/wtar.e
+/usr/bin/xc		-> $hlib/xc.e
+/usr/bin/cl		-> $hlib/cl.e
+	Establish these symbolic links as superuser (e.g. cd /usr/include; 
+	ln -s $hlib/mkiraf.csh mkiraf).  These are required for regular
+	users who do not have a .cshrc or .login which sources
+	$iraf/unix/hlib/irafuser.csh, for running the cl or mkiraf.
+	Ordinarily we only link xc, mkiraf, and mkpkg here, but since we're
+	doing development on the Sun outside IRAF, the rest are useful. (4/17)
+
+unix/hlib/alloc.e
+	This file must belong to root, since it needs root permissions at
+	runtime to allocate devices.  Do the following:
+
+	% cd $hlib
+	% su
+	% /etc/chown 0 alloc.e		(4/17)
+
+-------------------------------------------
+The bootstrap is now complete.  The next step is to do a full system compile.
+
+There are 5 files that need to be hand-compiled without optimization (from
+previous experience on the SUN) to avoid getting in an infinite loop in pass
+c2 of the compiler.  "xc -c" each file to create an object file in its
+directory; mkpkg will then avoid recompiling it.  Note:  see local/bugs
+README for description of "-P" for partial optimization instead.
+
+	sys/fio/fstati.x
+	math/bevington/matinv.f
+	sys/gio/nspp/portlib/gridal.f
+	sys/ki/irafks.x
+	pkg/twodspec/longslit/transform/igsfit/igsfit.f
+
+    (The following two entries are from the previous NOTES file on tucana;
+    I'm not sure if this ishift is the correct one:  Doug indicated that
+    the fixed ishift on tucana hadn't made it back to lyra, but DIFF showed
+    only half of a comment line difference between the lyra version and the
+    version unpacked from the $iraf/unix directory in the tucana archive.
+    The stgdrawch.x fix also hadn't made it back to lyra prior to cutting
+    the tape for this installation.)
+
+    unix/as/ishift.s
+	    Would not do a right shift, since the 68010 uses two different
+	    instructions to do left and right shifts, unlike the vax, which
+	    allows the shift argument to be negative.  Changed to use the ROL
+	    and ROR instructions.
+
+    sys/gio/stdgraph/stgdrawch.x
+	    When stdgraph kernel attempted to draw high-quality text, it 
+	    began drawing lines and garbage text all over the screen until it
+	    hit a segmentation violation.  Traced to module sgch_flush(),
+	    "call stg_polyline (pl, op / 2)", (SHORT op), where stg_polyline
+	    wanted an INT for the 2nd argument.  Changed to "int (op / 2)".
+
+Now perform the full system compile (sysgen).
+
+	% cd $iraf
+	% mkpkg >& spool &				(4/17)
+
+	Begun at Thu Apr 17 13:13:22 MST 1986; ended at Fri Apr 18 06:35:16
+	MST 1986, for a sysgen time of 17h22m.  The only suspicious thing in
+	the spoolfile was in XTOOLS, where mkpkg could not find module or
+	label "generic".  (4/20)
+
+$iraf/bin/x_cv.e
+$iraf/bin/x_display.e
+$iraf/vms/
+	Removed these files and directories to free up disk space.  (4/20)
+
+(help database)
+	Ran MKHELPDB from the CL, having neglected to do so immediately
+	after the sysgen.  (4/23)
diff --git a/doc/ports/sun2_062486.doc b/doc/ports/sun2_062486.doc
new file mode 100644
index 00000000..d483e475
--- /dev/null
+++ b/doc/ports/sun2_062486.doc
@@ -0,0 +1,134 @@
+SUN/IRAF V2.3 Installation, 13 June 1986.	Sun-2, software floating point
+--------------------------------------------------------------------------------
+
+/usr/iraf/
+	Ran rmbin on bin, sys, pkg, math, lib, local, unix.  Unpacked
+	source-only archive from master VAX/UNIX system "lyra" of
+	12-June-86 17:00.  (6/13)
+
+unix/as/
+unix/as/ishift.s
+unix/as/zsvjmp.s
+	Deleted VAX contents of as/, copied mc68000/ishift.SUN and
+	zsvjmp.SUN to as/*.s.  (6/13)
+
+unix/hlib/[dir]1mach.f
+	Commented out pdp (vax) data statements and uncommented IEEE
+	statements.  (6/13)
+
+unix/hlib/mach.h
+unix/hlib/libc/spp.h
+	Replaced EPSILONR and EPSILOND with values from unix/mc68000/README.
+	Set both BYTE_SWAPs to NO in mach.h.  (6/13)
+
+unix/hlib/mkiraf.csh
+	Edited iraf root to new pathname.  (6/13)
+
+unix/hlib/mkpkg.inc
+	Set USE_CALCOMP to "no".  (6/13)
+
+unix/hlib/libc/iraf.h
+	Changed iraf root pathname.  (6/13)
+
+unix/hlib/libc/kernel.h
+	Commented out DEBUGMEM (i.e. use standard UNIX malloc())
+	in order that spp programs can call SunCGI.  (6/13)
+
+unix/
+	Bootstrap (sh -x mkpkg.csh); no problems.  (6/13)
+
+unix/hlib/alloc.e
+	As su, "/etc/chown 0 alloc.e" so it can allocate devices.  (6/13)
+
+/usr/bin/alloc		-> $hlib/alloc.e
+/usr/bin/generic	-> $hlib/generic.e
+/usr/bin/mkpkg		-> $hlib/mkpkg.e
+/usr/bin/rmbin		-> $hlib/rmbin.e
+/usr/bin/rmfiles	-> $hlib/rmfiles.e
+/usr/bin/rtar		-> $hlib/rtar.e
+/usr/bin/wtar		-> $hlib/wtar.e
+/usr/bin/xc		-> $hlib/xc.e
+/usr/bin/cl		-> $hlib/cl.e
+	Made sure these symbolic links existed.  (6/13)
+	
+--------------------------------------------------------------------------------
+Bootstrap is complete.  Hand-compile the Sun f77 optimizer-bug routines before
+performing the full recompile sysgen.
+
+sys/fio/fstati.x					F77 runtime
+math/bevington/matinv.f					F77 runtime
+sys/gio/nspp/portlib/gridal.f				F77 runtime
+sys/ki/irafks.x						F77 runtime
+noao/twodspec/longslit/transform/igsfit/igsfit.f	F77 runtime
+	All these files have to be hand-compiled without optimization 
+	from previous experience with the Sun V2.0 f77 compiler; none
+	of these files nor their .x parents have changed since last
+	built on a Sun-2.  (6/13)
+
+iraf/
+	Began full compile & link sysgen at 16:33.  (6/13)
+
+fio/fioclean.x
+	Fixed null pointer bug.  (6/14)
+
+bin/x_display.e
+bin/x_cv.e
+images/tv/cv/libpkg.a
+images/tv/display/libpkg.a
+	Removed to free up disk space.  (6/14)
+
+$iraf
+	Unpacked an incremental archive from lyra! to bring us current
+	to 09:15 June 20, 1986.  Performed an incremental sysgen from
+	the root.  (6/20)
+
+noao/twodspec/apextract/*
+	The preceding sysgen failed to find all files in icfit/* except
+	for 3 source files.  To be safe, I (sr) made a complete archive
+	of apextract from lyra at 10:20, unpacked it, and did a "mkpkg
+	update" from here.  (6/20)
+
+pkg/images/geometry/t_imtranspose.x			F77 runtime
+	f77 optimizer bug was causing "Pixel subscript out of bounds"
+	in imtranspose.  Compiled without optimization from cl with
+	"cl> !mkpkg xflags=-c; cd ..; mkpkg update".  (6/20)
+
+noao/twodspec/apexold/*
+	Because of old file dates and because this directory on lyra
+	was created only by renaming the directory itself, it didn't
+	get copied in the incremental tar earlier this week.  Made
+	a fresh archive on lyra and a "mkpkg update".  (6/20)
+
+$iraf
+	Unpacked a lyra! incremental archive taken at 14:40 June 21;
+	performed a root incremental sysgen.  (6/21)
+
+$iraf
+	Unpacked a lyra! incremental archive taken at 08:10 June 23;
+	performed a root incremental sysgen.  (6/23)
+
+noao/lib/scr/*
+noao/twodspec/apexold/*
+noao/twodspec/apextract/*
+	Replaced with full archives from lyra! to attempt to clear up bugs
+	possibly related to renaming, rather than copying, files on lyra!
+	since the June 12 full archive -- these could be missed by the
+	incremental archives (find . -mtime -N).  MKPKG updates in both
+	apextract directories.  (6/23)
+
+pkg/cl/unop.c
+	Changed call to sscanf (sval, "%f", &rresult) in case OP_REAL to
+	sscanf (sval, "%lf", &rresult) because on SUNs, only the first
+	four bytes starting at rresult were being written into (rresult
+	is declared "double").  Should be changed on master system as well.
+	(6/23)
+
+--------------------------------------------------------------------------------
+June 24, 1986:  Extensive testing for several days has revealed no further
+bugs particular to the SUN-2 in its implementation at NOAO (SUN V2.0, no
+fpa, no array processor).  Although we do not have a 1/2" tape drive on the
+SUN-2, the SUN-3's have a known bug which appears to be SUN's problem --
+I/O error when trying to backspace-record when the drive is positioned between
+the two EOF marks written at close time.  It is probable we will have a
+workaround for this bug in early July.
+--------------------------------------------------------------------------------
diff --git a/doc/ports/sun2_102885.doc b/doc/ports/sun2_102885.doc
new file mode 100644
index 00000000..adf5055c
--- /dev/null
+++ b/doc/ports/sun2_102885.doc
@@ -0,0 +1,190 @@
+SUN/IRAF V2.0 Installation, 28 October 1985	Sun-2, software floating point
+------------------------------------------------------------------------------
+
+find . \! -type d -print > _files	# get list of nondirectory files
+grep '\.[aoe]$' _files > _bin		# find binaries
+grep '\.s$' _files > _mach		# find assembler files
+ls _bin | grep '[2-9] iraf' > _links	# find binary files with links
+rm _bin					# delete binary files
+
+deleted all .[aoe] files (22 Mb)
+not necessary to edit Makefiles
+
+/usr/include/iraf.h
+	Made symbolic link in pointing to /iraf/lib/libc/iraf.h; necessary
+	before compiling any C programs.
+
+built mklib.e
+built preprocessor: xc.e, xpp.e, rpp.e
+built generic.e	(had to do this manually; no Makefile)
+	lex generic.l; cc lex.yy.c -lln -o generic.e
+
+/usr/bin
+	Made symbolic links for unix tasks cl, xc, mklib, mkiraf
+
+lib/*.e
+	Made symbolic links for xc.e, xpp.e, rpp.e, mklib.e generic.e
+
+lib/libc/spp.h
+lib/mach.h
+	Changed defn of machine epsilon (use Fort program in osb).
+	Set byte swap flags to NO.
+
+sys/os/zsvjmp.s
+	Replaced VAX version with MC68000 version.
+
+sys/osb/bitpak.s
+sys/osb/bitupk.s
+sys/osb/bytmov.s
+	Edited Makelib to replace bitpak.s and bitupk.s with the portable
+	version in bitfields.c.  Likewise replaced bytmov.s with bytmov.c.
+
+sys/vops/ak/Makelib
+sys/vops/lz/Makelib
+	Commented out the VAX .s optimized files in the Makelib, and
+	uncommented the portable .x versions.
+
+cd sys; make >& spool &			# start sysgen of system libraries
+	(pass c2 of f77 hung in infinite loop on fio$fstati.f; optimizer bug)
+
+cd libc; mklib -O >& spool &		# make libc.a (C runtime library)
+
+
+(peruse output from sysgen and fix compile time bugs)
+----------------------------------
+
+sys/gio/gki/gkigetwcs.x
+	Array 'ret' no longer used, deleted.
+
+sys/vops/achtXY
+	When datatype X is the same as Y, the loop variable I is not used
+	(no action taken).
+
+pkg/softools/boot/spp/xpp/decl.c
+	The XPP declarations code which output the argument list for a
+	procedure could sometimes generate an output line too long for RPP to
+	handle.  The code was breaking the argument list after 8 arguments
+	had been output, a simplistic technique which would fail when the
+	identifiers were too large.  Changed to keep track of the output
+	column and break lines that are close to 80 cols in length.
+
+sys/libc/ckimapc.c
+	Local variable maxch redefines argument; argument maxch not used to
+	control length of output string.
+
+pkg/system/x_systest.x
+pkg/system/system.cl
+	Procedure mtdevlist was still being referenced in this package.
+
+(system package, cl came up with no problems)
+
+
+cd math; make >& spool &
+-------------------------------------
+
+math/Makefile
+math/Makelib
+	Added a Makelib to the math directory, with an entry for each math
+	package.  Set up Makefile to make all the libraries.  Must still 
+	be linked to lib when done, if not already.
+
+math/bevington/matinv.f
+	Apparent optimizer failure in matinv.f.  Recompiled successfully
+	without optimization.
+
+(all other math libraries compiled successfully; linked em all into /iraf/lib)
+
+
+cd /iraf; csh -x Mkpkg.sh >& spool &
+-----------------------------------------------
+
+pkg/*/Mkpkg.sh
+	The "rm -f *.e" causes the script to abort without doing anything if
+	there is no .o or .e file to delete.  Got around this with a temporary
+	fix, i.e, making a junk.e in each directory before doing the rm.
+
+As expected, the links failed due to the following libraries not being present
+in lib$ yet:
+
+	all math libraries		math/
+	xtools				pkg/xtools
+	nspp				sys/gio/nspp
+	ncar				sys/gio/ncarutil
+	gks				sys/gio/gks
+	calcomp				local UNIX (not IRAF) library
+
+sys/gio/ncarutil/ishift.s
+sys/gio/nspp/ishift.s
+	Wrote SUN/MC68000 version.
+
+sys/gio/nspp/*
+	The usual complaints about questionable or nonportable constructs
+	in the NCAR fortran.
+
+sys/gio/nspp/nspp/gridal.f
+	Optimizer failure.
+
+sys/gio/nspp/utilities/conrec.f
+	Invalid hollerith specification on line 387; count is incorrect due
+	to continuation.  Changed to quoted string.
+
+pkg/Mkpkg.sh
+	Reordered packages to make the lower level packages first.
+	In particular, imred cannot be made until after onedspec.
+
+pkg/softools/boot/spp/xc.c
+pkg/softools/boot/spp/xpp/xppmain.c
+	Added a fflush(stderr) after each write to stderr.  On the SUN stderr
+	appears not to be flushed automatically when i/o is redirected to an
+	ordinary file.
+
+pkg/dataio/lib/cyboow.s
+	Wrote a stubbed out SPP version of these procedures so that the DATAIO
+	package can be linked.
+
+pkg/images/tv/display/t_mkdisplay.x
+	Changed the obsolete IM_PIXELS to IM_PIXOFF.
+
+pkg/twodspec/longslit/Makefile
+	Would not make the library before linking, causing a rebuild to fail.
+	x_aperture.e was made first, but mklib was called only for x_longslit.e.
+
+ADB usage note:
+	Breakpoints should be set at procedure+4 to get a correct stack trace
+	showing the arguments to the procedure (vs. +2 on the VAX).
+
+pkg/twodspec/longslit/Makefile (etc. in subdirs)
+	Turned off the -F -g; this is for debugging and should NOT be turned
+	on in an installed package (the images are larger and there is no
+	optimization).  Also, the f77 compiler aborted with a DBX error
+	related to a call to an external procedure passed as an argument to
+	a procedure (file igsfit.f).  I did not investigate further; hand
+	compilation of the procedure worked.
+
+sys/libc/cfpath.c
+	The third (maxch) argument was being passed to FPATHNAME by value
+	rather than by reference.
+
+dev/uhosts
+dev/hosts
+dev/hostlogin
+	Added more machines to the network tables.
+
+pkg/images/Mkpkg.sh
+	Added entry for subpackage imdebug.
+
+pkg/images/imdebug/Mkpkg.sh
+	New file.
+
+dev/helpdb
+	Recompiled the help database (in the CL using the mkhelp task in the
+	softools package).
+
+sys/libc/cfmapfn.c
+	The third (maxch) argument was being passed to FPATHNAME by value
+	rather than by reference.
+
+pkg/system/allocate.cl
+	As a temporary fix, commented out the call to UNIX to allocate a
+	device.  Removed the enumerated device names from the parameter file
+	since device names are not constant strings (this was never correct).
diff --git a/doc/ports/sun2_skyfpa.unc b/doc/ports/sun2_skyfpa.unc
new file mode 100644
index 00000000..fcc97f48
--- /dev/null
+++ b/doc/ports/sun2_skyfpa.unc
@@ -0,0 +1,168 @@
+SUN/IRAF installation U. North Carolina, Sun-3 UNIX on Sun-2 hardware.
+Beginning 24 September 1986, dct.
+----------------------------------------------------
+
+unix/...
+	Deleted all binary files (should have been done before distribution).
+	(9/24)
+
+local/.login
+unix/hlib/mkiraf.csh
+unix/hlib/mkpkg.inc
+	Changed the -f68881 flags to -fsky.  (9/24)
+
+cd unix; sh -x mkpkg.csh >& spool &
+	Started up the first bootstrap.  (9/24)
+
+-------------------------
+(Resume 27 Sept)
+Bootstrap succeeded without any apparent problems, except that there were
+still binaries in lib, so the mkpkg in gdev did not recompile the IIS
+interface into libsys.a.  
+
+	- Ran RMBIN on the non-HSI directories to get rid of the binaries.
+	  Worked fine, except that it also deleted the .login file which
+	  contained some control codes which fooled RMBIN into thinking it
+	  was a binary file.
+
+Next, tried mkpkg again in GDEV.  This failed immediately with RPP generating
+an error message something like `unknown x$type directive'.  Traced this to
+a Fortran optimizer bug in rpp/ratlibf/enter.f.  Compiled that module and
+tried again.  Failed again: this time it ran, but some of the symbols came
+out with all the characters set to the | character.  Traced this one to yet
+another (very similar) optimizer bug in spp/rppfor/ludef.f.  Fixed that one
+and relinked, and this time was able to compile GDEV, although by this time
+I have little confidence in the quality of the compiled objects!!
+
+local/bugs/unc/enter.[fs]
+local/bugs/unc/ludef.[fs]
+	Generated the assembler for these bugs and captured it with tip so
+	that we can send it to the place where bugs go at SUN.  (9/27)
+
+unix/hlib/SUN_kludge/precomp.csh
+	Changed the -f68881 switches to -fsky.  (9/27)
+
+-----------------------------------------------
+Started the first full sysgen.
+	cd $hlib/SUN_kludge; precomp.csh
+	cd $iraf
+	mkpkg >& spool &		(9/27)
+
+unix/hlib/mkiraf.csh
+	Set root imdir to /usr/tmp.  (9/28)
+
+Sysgen Progress:  (9/28)
+	There were a couple of problems with the sysgen, but mostly it seems to
+	be running ok.  This machine is very slow, the Sun-3 is MUCH faster.
+
+	[1] When I rebuilt gdev manually (due to the problems with the SPP),
+	    I was in a subdirectory hence did not make everything.  This caused
+	    some of the links in the main sysgen to come up short.  This is
+	    not unusual; probably a mkpkg gdev should be included in the
+	    main sysgen, just in case it was missed in the bootstrap, or in
+	    case libsys.a was deleted.
+
+	[2] There were some f77 failures in VOPS, despite the reduction in the
+	    command line lenth to 400.  This is almost certainly a bug in the
+	    f77 program itself.  The error message is
+
+	    Compiler error on line 0 of (null): invalid flag c
+
+	    Where c is some character.  This always happens to a file at or
+	    near the end of the file list (maybe 384 would be a good length?).
+	    The workaround until Sun gets this fixed is simply to  mkpkg
+	    again, that will recompile the remaining files.
+
+	    NOTE - NOTE - NOTE - I just discovered some Sun docs noting bugs
+	    in the V3.1 f77.  One is "f77 cannot handle more than about forty
+	    source files in a single command".  This is the problem we have
+	    here.
+
+	(fixed these items and restarted sysgen, keeping libraries thus far
+	(compiled intact.)
+
+unix/boot/mkpkg/host.c
+	Decreased the size of the host command line to 320 characters to
+	avoid the above mentioned f77 40-file bug.  (9/28)
+
+---------------------------------------
+Begin testing, x_system.e, cl.e,...
+	We have very serious problems here.  x_system.e runs, but most of
+	the tasks misbehave in one way or another.  The cl just hangs up
+	during startup.
+
+unix/os/zmain.c
+unix/os/zopdpr.c
+unix/os/zfiopr.c
+unix/os/zoscmd.c
+	The runtime problem mentioned above turned out to be due to the Sky
+	floating point board ignoring all floating point instructions; the
+	last operand sent would be the one read back, with no operation
+	being performed.  Took a while to figure this one out: everything
+	was being compiled and linked correctly with the -fsky option,
+	and indeed the skyboard startup code was being called during process
+	startup.
+
+	What it finally turned out to be was the series of close() cy{alls in
+	the IRAF main.  These were used to close the unwanted file
+	descriptors inherited from the parent process via the usual UNIX
+	convention of passing all open files on to the child.  Unfortunately,
+	the sky board is opened as a file during process startup, before the
+	IRAF main is entered, hence the IRAF main would immediately close
+	it down and all floating point would thereafter fail miserably.
+
+	The solution was to use the new 4.2BSD `fcntl' to set the close-on-exec
+	flag on the unwanted file descriptors (3 on) before calling execl().
+	It is conceivable there might be problems with using this in
+	conjunction with vfork (don't want to affect parents file descriptors,
+	e.g., if execl fails), but I think it will probably work; more
+	testing is warranted later.  (^R
+{9/28)
+
+--------------------------------------------
+With this fix and a relink, CL runs, spawning system process, etc.
+Sysgen resumed at its incredibly slow pace; will check back later for further
+tests.  (9/28)
+
+Sysgen completed normally (Monday 29 September)
+Begin testing.
+
+sys/gio/gascale.x
+	IMPLOT failed immediately on the first attempt.  The problem was traced
+	to a Fortran optimizer bug in this routine - very straightforward code,
+	too.  My confidence in this compiler is pretty low this point.
+	A few more of these, and we should recompile the entire system without
+	optimization; it is probably already justified.  (9/28)
+
+	Moved sample bug file into in local/bugs/unc.  It is a register
+	allocation bug in a case statement; the code is testing the value of
+	a register that was never loaded with the value it is supposed to
+	be testing.
+
+image templates
+	The image template code is returning garbage image names; imheader,
+	imstat, etc., fail on dev$pix.
+
+----------------------------------------
+That does it, we recompile everything without optimization.  The bootstrap
+appears to be ok, so we will not redo that.  Probably VOPS can be compiled
+with optimization, that would gain back much of the speed for image operators.
+I will leave the executables in case anyone wants to use them; they will be
+replaced automatically when the sysgen reaches the link stage.  (9/29)
+
+unix/hlib/mkpkg.inc
+	Remove -O flag.  (9/29)
+
+cd $hlib/SUN_kludge; precomp.csh
+	This step not necessary since we are not using the optimizer,
+	nor the -f68881 switch, which gave problems with complex.  (9/29)
+
+cd $iraf; rmbin lib pkg noao		(except keep the optimized VOPS)
+cd gdev; mkpkg
+cd $iraf; mkpkg >& spool &		(and renice it)
+
+---------------------------------
+Sysgen completed; ran a few tests and things?`[5'4llright.  (9/30)
+
+	TODO:	as root, `chown 0 $hlib$alloc.e'
+		backup system, strip it to save space (probably)
diff --git a/doc/ports/sun3_042586.doc b/doc/ports/sun3_042586.doc
new file mode 100644
index 00000000..03f26c72
--- /dev/null
+++ b/doc/ports/sun3_042586.doc
@@ -0,0 +1,250 @@
+SUN/IRAF V2.3 Installation, 14 April 1986	Sun-3, software floating point
+------------------------------------------------------------------------------
+
+/usr/iraf/
+	Unpacked a source-only TAR archive made on lyra this afternoon;
+	didn't first delete anything.  Made sure we had a .login with
+	$iraf defined as the local IRAF root (/usr/iraf/).  (4/14)
+
+/usr/include/iraf.h
+	As Superuser, "ln -s unix/hlib/libc/iraf.h ."  (4/14)
+
+/usr/bin/alloc		-> $hlib/alloc.e
+/usr/bin/generic	-> $hlib/generic.e
+/usr/bin/mkpkg		-> $hlib/mkpkg.e
+/usr/bin/rmbin		-> $hlib/rmbin.e
+/usr/bin/rmfiles	-> $hlib/rmfiles.e
+/usr/bin/rtar		-> $hlib/rtar.e
+/usr/bin/wtar		-> $hlib/wtar.e
+/usr/bin/xc		-> $hlib/xc.e
+/usr/bin/cl		-> $hlib/cl.e
+	As Superuser, performed these symbolic links.  (4/14)
+
+unix/hlib/mkiraf.csh
+unix/hlib/libc/iraf.h
+	Modified IRAF root pathname, HOST definition; irafuser.csh not
+	modified, as $iraf is defined in the IRAF account .login.  (4/14)
+
+unix/hlib/mkmlist.csh
+	Changed bgrep to grep, since bgrep not available in standard
+	UNIX.  (Not important, doesn't have to work, so the efficiency
+	of bgrep on the development machine is worth the mach. dependence.)
+	(4/14)
+
+as/
+vaxas/
+mc68000/
+	Moved as/ to $iraf/vaxas/;  moved $iraf/mc68000/ishift.SUN,
+	zsvjmp.SUN to as/ishift.s, zsvjmp.s.  (Now that we have a
+	SUN-3 with 68020, the BYTPAK etc. assembler sources should also be
+	implemented).  (4/14)
+
+unix/hlib/mach.h
+unix/hlib/libc/spp.h (EPSILON)
+	Compiled osb$zzeps.f with "f77 -O -f68881 -o zzeps.e zzeps.f";
+	ran it to check hardware floating point epsilon; turned out to
+	be same as software floating point to 4 places.  Modified machine
+	epsilon and byte-swapping definitions (see unix/mc68000/README).
+	(4/14)
+
+unix/hlib/[dir]1mach.f
+	Commented out the VAX lines and uncommented the IEEE floating
+	point lines for the 68000.  (4/15)
+
+unix/hlib/mkpkg.inc
+	Modified XFLAGS to "-c -O -f68881" for our hardware floating point
+	option.  To verify that this works, I examined zzeps.e, compiled with
+	the same flags, with adb and found that, indeed, only single arguments
+	were being passed and actual floating point instructions were being
+	generated.  Set USE_CALCOMP to NO.  (4/15)
+
+unix/hlib/libc/kernel.h
+	Commented out DEBUGMEM in order to use the standard UNIX malloc rather
+	than IRAF's version.  This is necessary for some reason on the Sun for
+	SunCGI routines to be callable from SPP programs.  (4/15)
+
+unix/hlib/libc/iraf.h
+	Added definition for SUN3; the Sun IRAF kernel is still mostly 
+	identical with the VAX kernel, but zxwhen.c needs to know if it
+	is being compiled on a Sun-3.  (4/15)
+
+unix/
+	Attempted a bootstrap; had to make the following modification to 
+	get it to work:  (4/15)
+
+unix/os/zxwhen.c
+	Renamed structure vax_exception to hwx_exception; added ifdef branch
+	for SUN3 FPE traps-to-strings structure.  (The version that compiled
+	under the Sun-2 failed to compile under the Sun-3.)  (4/15)
+	
+unix/
+	Performed a bootstrap with "sh -x mkpkg.csh >& spool &".  
+	The only error showing was in bootlib/mkpkg.csh, "syntax error
+	at line 13:  `end of file' unexpected", presumably due to the
+	conditional construct, and possibly a CSHELL bug (libboot.a
+	built correctly and ended up in $hlib as it should anyway).  (4/15)
+
+unix/hlib/alloc.e
+	This file must belong to root, since it needs root permissions at
+	runtime to allocate devices.  Do the following:
+
+	% cd $hlib
+	% su
+	% /etc/chown 0 alloc.e		(4/15)
+
+-------------------------------------------
+The bootstrap is now complete.  The next step is to do a full system compile.
+
+
+	Attempted a "mkpkg >& spool &" from the root directory.  Got compiler
+	failure in fio$; "Compiler error line 0 of (null):  invalid flag
+	s...y...s...t...e...m...=" when trying to compile fowner.f.  Also
+	got similar errors in fmtio$gstrcat.f and other places.  No further
+	files from the original XC command line were compiled.  Common
+	denominator was the length of the command line to the f77 compiler.
+	Made the following change:  (4/15)
+
+unix/boot/mkpkg/host.c
+	Changed SZ_CMD from 512 to 400; this shortens the command line
+	that MKPKG constructs for XC.  Rebuilt MKPKG with "sh -x mkpkg.csh".
+	(4/15)
+
+
+	Started another sysgen.  Noticed compiler errors on the following
+	files; let the sysgen continue while fixing them.
+
+	sys/fmtio/gctod.f
+	sys/fmtio/xtoc.f
+	    These routines had to be hand-compiled without switch "-f68881".
+	    Made copies of the fortran in local/bugs, and hand-compiled
+	    each routine in its own directory.  Something to do with complex
+	    numbers?  Since it didn't look like they affected anything else,
+	    just did a "mkpkg" to load them back into libsys and let the
+	    sysgen continue.  (4/15)
+
+	sys/vops/ak/abeqkx.f
+	sys/vops/ak/abeqx.f
+	sys/vops/ak/abgekx.f
+	sys/vops/ak/abgtkx.f
+	sys/vops/ak/ablekx.f
+	sys/vops/ak/abltkx.f
+	sys/vops/ak/abnekx.f
+	sys/vops/ak/abnex.f
+	sys/vops/ak/advzx.f
+	sys/vops/lz/allnx.f
+	sys/vops/lz/alogx.f
+	sys/vops/lz/arcpx.f
+	sys/vops/lz/arczx.f
+	    Same with these routines; again, all contained complex datatypes.
+	    Hand-compiled, then a "mkpkg" from vops.  (4/16)
+
+unix/hlib/mkpkg.inc
+	Changed LFLAGS from "" to "-f68881" to get pick up the references
+	generated by the same switch during default compilation.  This may
+	cause a problem with those files hand-compiled without this switch
+	due to compiler errors.  (4/16)
+
+pkg/dataio/reblock/t_reblock.x		   line	56
+pkg/dataio/cardimage/t_wcardimage.x		39
+pkg/images/imutil/imdelete.x			43
+pkg/onedspec/t_widstape.x			65
+pkg/plot/gkiextract.x				99
+pkg/utilities/t_translit.x			41, 68
+pkg/imred/vtel/dicoplot.x			324
+pkg/imred/vtel/tcopy.x				59
+pkg/imred/vtel/vtfix.x				60
+pkg/imred/vtel/writevt.x			42
+	All these lines tested a boolean conditional against "true" or "false".
+	The Sun-3 f77 compiler refused to compile these; all were changed to
+	just the name of the boolean or !boolean as appropriate.  
+	This was only done on the Sun, since this is an experimental version;
+	mail will be sent on lyra.  (4/16)
+
+pkg/images/tv/display/iisers.x
+	No change made, since there is no need for this code on the Sun,
+	and it looked like there were non-obvious consequences in other
+	routines for changing either the values or changing shorts to ints.
+	However, note should be taken on lyra that "erase" is a short integer,
+	and it is being assigned to ERASE (in one of the local include
+	files), which has the value "32768" -- too high by one, apparently.
+
+pkg/images/tv/cv/iism70/iiscursor.x
+pkg/images/tv/cv/iism70/zclear.x
+	Also no change made, but similar problem:  the include file
+	definitions IREAD (100000B) and ERASE (32768) are being used
+	in assignments to short integers, in one case "32768+256".  (4/16)
+
+unix/boot/spp/xc.c
+	Added references for the standard Fortran libraries -lI77 and -lU77,
+	plus a reference to the temporary library $hlib/libk.a, which contains
+	several routines referenced by the Fortran compiler, but not provided
+	in any SUN library.  See below.  (4/25)
+
+unix/hlib/SUN_kludge/
+	This a temporary directory added to build the kludge library libk.a
+	so that IRAF programs can be linked on the SUN-3.  Source for the
+	following routines were added:
+
+		Fc_eq		compare complex numbers for equality
+		Fc_conv_h	convert complex to short
+		Fh_conv_c	convert short to complex
+
+	The conversion routines appear to have been overlooked by SUN, and
+	should be added to /usr/lib/libF77.a.  (4/25)
+
+unix/mkpkg.csh
+	Added a line to compile the kludge library during the bootstrap. (4/25)
+
+unix/hlib/mkpkg.inc
+	Added the flag "-f68881" to LFLAGS (the linker flags).  This is
+	necessary to get the linker to reference /lib/Mcrt1.o rather than
+	/lib/Fcrt1.o.  If this is not done and one attempts to link code
+	compiled with the -f68881 switch, an unresolved reference to
+	the external "f68881_used" will result.  (4/25)
+
+sys/osb/miiupk16.x
+sys/osb/miiupk32.x
+	Replaced by the new versions from lyra, which fix the BYTE_SWAP
+	bug.  (4/25)
+
+sys/gio/nspp/portlib/flush.f
+sys/gio/nspp/portlib/flash[13].f
+sys/gio/nsppkern/gktcancel.f
+sys/gio/nsppkern/gktclear.f
+sys/gio/nsppkern/gktclose.f
+sys/gio/ncarutil/sysint/spps.f
+	Changed the name of the NSPP routine "flush" to "mcflsh" to avoid
+	a library conflict with the Fortran FLUSH.  (4/25)
+
+pkg/images/tv/display/iisers.x
+pkg/images/tv/cv/iism70/iiscursor.x
+pkg/images/tv/cv/iism70/zclear.x
+	All these files produced a compiler bug due to a compile time
+	assignment of an unsigned short integer number 1XXXXX into a
+	short variable.  Had to change these to run time assignments to
+	get the desired truncation assignment.  (4/25)
+
+local/.login
+local/login.cl
+	Aliased XC to 'xc -f68881' since all floating point is handled that
+	way on this machine.  (4/25)
+
+unix/hlib/libc/finfo.h
+	The fi_owner field of the finfo structure was not dimensioned
+	properly, causing the storage allocated for the structure to be
+	overrun.  This was found in a call to pfileopen/filetime in the
+	CL; the finfo structure is allocated space on the stack, hence the
+	stack was being corrupted.  This was a fairly serious bug which has
+	been in the system for a long time.  (4/25)
+
+[[ The system is now up (4/25) ]]
+
+dev/pix
+dev/pix.pix
+	Moved the test image over from lyra:
+
+		wfits dev$pix /u2/tody/pix.fits		(on VAX lyra)
+		rfits lyra!/u2/tody/pix.fits		(on SUN)
+	    
+	We ought to add a dev$pix.fits file so that the test image is
+	available on source only archives.  (4/25)
diff --git a/doc/ports/sun3_062486.doc b/doc/ports/sun3_062486.doc
new file mode 100644
index 00000000..16a1107e
--- /dev/null
+++ b/doc/ports/sun3_062486.doc
@@ -0,0 +1,202 @@
+SUN/IRAF V2.3 Installation, 12 June 1986	Sun-3, MC68881 floating point
+------------------------------------------------------------------------------
+
+/usr/iraf/local/notes
+	Began this new notes file.  All subsequent pathnames assume
+	"/usr/iraf/" preceding them.  (6/12)
+
+unix/
+	Made a tar backup in /tmp2/iraf/tuc_unix.arc.  (6/12)
+
+local/
+	Made a tar backup in /tmp2/iraf/tuc_local.arc.  (6/12)
+
+bin/
+lib/
+pkg/
+sys/
+unix/
+	Ran rmbin to remove all binary files.  (6/12)
+
+/usr/iraf/
+	Unpacked new "wtar -o" source-only archive from lyra.  (6/12)
+
+unix/as/
+unix/mc68000
+	Replaced VAX contents of as/ with those from mc68000; renamed
+	.SUN's to .s's.  (6/12)
+
+unix/mkpkg.csh
+	Replaced with the one from the archive; contains SUN_kludge
+	mkpkg.csh command.  (6/12)
+
+unix/hlib/[dir]1mach.f
+	Replaced with those from archive for 68000; using MC68000
+	versions of machine-independent stuff for nspp software.  (6/12)
+
+unix/hlib/mach.h
+	Compared with archive and replaced with archive version to pick
+	up BYTE_SWAP[24] = NO, and to use the 68000 fp epsilons.  (6/12)
+
+unix/hlib/motd
+	Short message about SUN/IRAF system testing.  (6/12)
+
+unix/hlib/mkpkg.inc
+	Ran diff; replaced from archive to pick up 68000 compiler
+	and linker switches for this SUN-3, which has MC 68881 floating
+	point (XFLAGS -c -O -f68881; LFLAGS -f68881).  Set USE_CALCOMP
+	to NO.  (6/12)
+
+unix/hlib/mkiraf.csh
+	Replaced iraf root definition.  (6/12)
+
+unix/hlib/libc/iraf.h
+	Changed root directory to /usr/iraf/, added "#define SUN3".  (6/12)
+
+unix/hlib/libc/kernel.h
+	Commented out DEBUGMEM so that the normal UNIX malloc() is
+	used.  This was and probably still is necessary in order to
+	link with SUNCGI.  (6/12)
+
+unix/hlib/libc/spp.h
+	Ran diff; replaced with archive version to pick up MC68000
+	fp epsilons.  (6/12)
+
+unix/boot/mkpkg/host.c
+	Changed SZ_CMD from 512 to 400 to get around SUN-3 f77 command-
+	line bug.  (6/12)
+
+unix/boot/spp/xc.c
+	Ran diff; replaced with archive version to pick up all the
+	extra Fortran library definitions and command-line args.  (6/12)
+
+unix/os/zxwhen.c
+	Ran diff; replaced with archive version to pick up Sun floating
+	point exception definitions.  (6/12)
+
+local/notes
+	Renamed to notes.vax.  (6/12)
+
+local/login.cl
+	Renamed root directory in "home"; aliased "xc" to "xc -f68881".  (6/12)
+
+/usr/include/iraf.h	-> $hlib/libc/iraf.h
+	Made sure this symbolic link existed.  (6/12)
+
+unix/	[BOOTSTRAP]
+	Attempted bootstrap ("sh -x mkpkg.csh").  (6/12)
+
+unix/boot/bootlib/mkpkg.csh
+	This time the bootstrap failed because of the "unexpected end of
+	file" error and did NOT create libboot.a.  Resolved by inserting
+	"#! /bin/csh -f" as the first line.  (6/13)
+
+unix/	[BOOTSTRAP]
+	Successful bootstrap this time.  (6/13)
+	
+unix/hlib/alloc.e
+	Changed ownership to root in order to allocate devices at runtime.
+	(6/13)
+
+/usr/bin/alloc		-> $hlib/alloc.e
+/usr/bin/generic	-> $hlib/generic.e
+/usr/bin/mkpkg		-> $hlib/mkpkg.e
+/usr/bin/rmbin		-> $hlib/rmbin.e
+/usr/bin/rmfiles	-> $hlib/rmfiles.e
+/usr/bin/rtar		-> $hlib/rtar.e
+/usr/bin/wtar		-> $hlib/wtar.e
+/usr/bin/xc		-> $hlib/xc.e
+/usr/bin/cl		-> $hlib/cl.e
+	Made sure these symbolic links existed.  (6/13)
+
+sys/fmtio/gctod.f				F77 compile-time
+sys/fmtio/xtoc.f				F77 compile-time
+sys/vops/ak/abeqkx.f				F77 compile-time
+sys/vops/ak/abeqx.f				F77 compile-time
+sys/vops/ak/abgekx.f				F77 compile-time
+sys/vops/ak/abgtkx.f				F77 compile-time
+sys/vops/ak/ablekx.f				F77 compile-time
+sys/vops/ak/abltkx.f				F77 compile-time
+sys/vops/ak/abnekx.f				F77 compile-time
+sys/vops/ak/abnex.f				F77 compile-time
+sys/vops/ak/advzx.f				F77 compile-time
+sys/vops/lz/allnx.f				F77 compile-time
+sys/vops/lz/alogx.f				F77 compile-time
+sys/vops/lz/arcpx.f				F77 compile-time
+sys/vops/lz/arczx.f				F77 compile-time
+	Hand-compiled without "-f68881" switch (but with optimization);
+	otherwise the compiler fails due to complex datatype expressions.
+	This will be the case until the next Sun f77 release.  (6/13)
+
+sys/fmtio/fprfmt.x				F77 run-time
+	Hand-compiled without optimization (but with "-f68881").  Have not
+	yet determined source of problem (symptom was garbage appearing
+	in text files) -- pursue shortly.  (6/13)
+
+$iraf
+	Started sysgen at 10:22.  (6/13)
+
+dev/devices
+	Replaced with version from suntest!, since we now have a 1/2 inch
+	tape drive on tucana.  Added mtb entry for the 1/4 inch drive.  (6/13)
+
+noao$onedspec/getnimage.x			F77 run-time
+	There is a bug in the optimizer which seems to be caused by a
+	logical comparison to MAX_INT.  To get around the problem do the
+	following after a full sysgen.  (6/19)
+
+		touch getnimage.x; mkpkg xflags=-c fluxcal; mkpkg install
+
+$iraf
+	Unpacked an incremental archive from lyra to bring tucana up
+	to current as of 09:15 June 20, 1986.  Performed an incremental
+	sysgen.  (6/20)
+
+noao/twodspec/apextract/*
+	The preceding MKPKG found the entire contents of icfit/* missing
+	except for 3 source files.  To be safe, I (sr) made a complete
+	archive of lyra!/...apextract/* and unpacked it here, followed
+	by another root sysgen.  (6/20)
+
+noao/twodspec/apexold/*
+	Because this directory was created by renaming the directory
+	apextract after the full archive of June 12, it had old file
+	dates and the incremental archives this week didn't pick it
+	up.  Unpacked a full archive and MKPKG'd.  (6/20)
+
+sys/gio/cursor/grcwcs.x				F77 run-time
+	Apparent f77 optimizer bug; hand-compiling w/o optimization
+	and relinking the CL clears up the problem of IMPLOT's "l"
+	and "c" commands returning bad pixel rows/columns.  Before,
+	clgcur was sometimes returning the y coordinate in pixel, 
+	rather than data, units -- i.e. in WCS 1 rather than 2.  Haven't
+	had time to try to isolate the source of the optimizer bug.  (6/21)
+
+$iraf
+	Unpacked an incremental archive from lyra! current to 14:40 June
+	21; performed an incremental sysgen.  (6/21)
+
+noao/mtlocal/r2df/r2df.com
+	The preceding sysgen died because this file was missing; it had 
+	a date earlier than the incremental archive, so was missed.
+	Added it and rebuilt mtlocal.  (6/21)
+
+$iraf
+	Unpacked an incremental archive from lyra! current to 08:15 June
+	23; performed an incremental sysgen.  (6/23)
+
+noao/lib/scr/*
+noao/twodspec/apextract/*
+noao/twodspec/apexold/*
+	Unpacked full, not incremental, archives from lyra! to pick up any
+	files missed during the incremental archives as a result of renaming
+	rather than copying files since the June 12 full archive.  mkpkg
+	updates in both apextract directories.  (6/23)
+
+pkg/cl/unop.c
+	Changed call to sscanf (sval, "%f", &rresult) in case OP_REAL to
+	sscanf (sval, "%lf", &rresult) because "rresult" is declared type
+	"double", and on the SUNs, sscanf was only writing into the first
+	four bytes of rresult, giving erroneous answers to REAL coercion,
+	as in "cl> =real(imgets.value)".  Should be changed on master system
+	as well.  (6/23)
diff --git a/doc/ports/sun3_f77Obugs.doc b/doc/ports/sun3_f77Obugs.doc
new file mode 100644
index 00000000..1f06a3e5
--- /dev/null
+++ b/doc/ports/sun3_f77Obugs.doc
@@ -0,0 +1,1666 @@
+# f77 source programs and corresponding assembler code generated with 
+# "f77 -S -O -f68881" that cause run-time failure, where the corresponding
+# unoptimized code does not.
+#===============================================================================
+# fprfmt.f:
+      integer function fprfmt (ival)
+      integer ival
+      logical ivalad
+      integer ctoi
+      integer stridx
+      integer*2 ch
+      integer*2 chrlwr
+      integer fd
+      integer ip
+      integer width
+      integer decpl
+      integer col
+      integer leftjy
+      integer radix
+      integer fmtste
+      integer ofilee
+      integer formar
+      integer*2 fillcr
+      integer*2 format(161 +1)
+      integer*2 obuf(1024+1)
+      integer sw0001
+      common /fmtcom/ fd,ip,width,decpl,col,leftjy,radix,fmtste, ofilee,
+     *formar,fillcr,format,obuf
+      integer*2 st0001(17)
+      integer*2 st0002(35)
+      integer*2 st0003(1)
+      save
+      integer iyy
+      data (st0001(iyy),iyy= 1, 8) / 98, 99,100,101,102,103,104,109/
+      data (st0001(iyy),iyy= 9,16) /111,114,115,116,117,119,120,122/
+      data (st0001(iyy),iyy=17,17) / 0/
+      data (st0002(iyy),iyy= 1, 8) / 87, 97,114,110,105,110,103, 58/
+      data (st0002(iyy),iyy= 9,16) / 32, 85,110,107,110,111,119,110/
+      data (st0002(iyy),iyy=17,24) / 32,102,111,114,109, 97,116, 32/
+      data (st0002(iyy),iyy=25,32) /116,121,112,101, 32, 99,104, 97/
+      data (st0002(iyy),iyy=33,35) /114, 10, 0/
+      data st0003 / 0/
+         sw0001=(fmtste)
+         goto 110
+120      continue
+            ivalad = .false.
+         goto 111
+130      continue
+            goto 2
+140      continue
+            goto 3
+150      continue
+            goto 4
+160      continue
+            goto 5
+170      continue
+            goto 6
+180      continue
+            goto 7
+110      continue
+            if (sw0001.lt.1.or.sw0001.gt.7) goto 111
+            goto (120,130,140,150,160,170,180),sw0001
+111      continue
+         if (.not.(format(ip) .eq. 0 .or. format(ip) .ne. 37 )) goto 190
+            width = (-999)
+            decpl = (-999)
+            formar = (-999)
+            fillcr = 32
+            leftjy = 0
+            fmtste = 1
+            fprfmt = (1)
+            goto 100
+190      continue
+            ip = ip + 1
+191      continue
+         if (.not.(format(ip) .eq. 42 )) goto 200
+            ip = ip + 1
+            if (.not.(ivalad)) goto 210
+               fmtste = 2
+               fprfmt = (0 )
+               goto 100
+210         continue
+2           ivalad = .true.
+            if (.not.(ival .lt. 0)) goto 220
+               leftjy = 1
+               goto 221
+220         continue
+               leftjy = 0
+221         continue
+            fillcr = 32
+            width = abs (ival)
+            goto 201
+200      continue
+            if (.not.(format(ip) .eq. 45)) goto 230
+               leftjy = 1
+               ip = ip + 1
+               goto 231
+230         continue
+               leftjy = 0
+231         continue
+            fillcr = 32
+            if (.not.(format(ip) .eq. 48)) goto 240
+               if (.not.((format(ip+1).ge.48.and.format(ip+1).le.57) .or
+     *         . format(ip+1) .eq. 42 )) goto 250
+                  fillcr = 48
+                  ip = ip + 1
+                  goto 251
+250            continue
+                  fillcr = 32
+251            continue
+240         continue
+            if (.not.(format(ip) .eq. 42 )) goto 260
+               ip = ip + 1
+               if (.not.(ivalad)) goto 270
+                  fmtste = 3
+                  fprfmt = (0 )
+                  goto 100
+270            continue
+3              ivalad = .true.
+               if (.not.(ival .lt. 0)) goto 280
+                  leftjy = 1
+                  goto 281
+280            continue
+                  leftjy = 0
+281            continue
+               width = abs (ival)
+               goto 261
+260         continue
+            if (.not.(ctoi (format, ip, width) .le. 0)) goto 290
+               width = (-999)
+290         continue
+261         continue
+201      continue
+         if (.not.(width .eq. 0)) goto 300
+            width = (-999)
+300      continue
+         if (.not.(format(ip) .eq. 46)) goto 310
+            ip = ip + 1
+            if (.not.(format(ip) .eq. 42 )) goto 320
+               ip = ip + 1
+               if (.not.(ivalad)) goto 330
+                  fmtste = 4
+                  fprfmt = (0 )
+                  goto 100
+330            continue
+4              ivalad = .true.
+               decpl = ival
+               goto 321
+320         continue
+            if (.not.(ctoi (format, ip, decpl) .le. 0)) goto 340
+               decpl = (-999)
+340         continue
+321         continue
+            goto 311
+310      continue
+            decpl = (-999)
+311      continue
+         if (.not.(format(ip) .eq. 42 )) goto 350
+            ip = ip + 1
+            if (.not.(ivalad)) goto 360
+               fmtste = 5
+               fprfmt = (0 )
+               goto 100
+360         continue
+5           ivalad = .true.
+            formar = ival
+            goto 351
+350      continue
+            formar = format(ip)
+            ip = ip + 1
+351      continue
+         if (.not.((formar.ge.65.and.formar.le.90))) goto 370
+            formar = (formar+97-65)
+370      continue
+         ch = formar
+         if (.not.(stridx (ch, st0001) .le. 0)) goto 380
+            call putlie (5, st0002)
+            call fmterr (st0003, format, ip-1)
+            formar = (-999)
+            goto 381
+380      continue
+         if (.not.(formar .eq. 114 )) goto 390
+            ch = chrlwr (format(ip))
+            ip = ip + 1
+            if (.not.(ch .eq. 42 )) goto 400
+               if (.not.(ivalad)) goto 410
+                  fmtste = 6
+                  fprfmt = (0 )
+                  goto 100
+410            continue
+6              ivalad = .true.
+               radix = ival
+               goto 401
+400         continue
+            if (.not.((ch.ge.48.and.ch.le.57))) goto 420
+               radix = (ch-48)
+               goto 421
+420         continue
+            if (.not.((ch.ge.97.and.ch.le.122))) goto 430
+               radix = ch - 97 + 10
+               goto 431
+430         continue
+               radix = 10
+               ip = ip - 1
+431         continue
+421         continue
+401         continue
+            goto 391
+390      continue
+         if (.not.(formar .eq. 119 .or. formar .eq. 116 )) goto 440
+            ivalad = .false.
+440      continue
+391      continue
+381      continue
+         if (.not.(ivalad)) goto 450
+            fmtste = 7
+            fprfmt = (0 )
+            goto 100
+450      continue
+7        ivalad = .true.
+         fmtste = 1
+         fprfmt = (1)
+         goto 100
+100      return
+      end
+c     leftjy  left_justify
+c     fmterr  fmt_err
+c     fmtste  fmt_state
+c     ivalad  ival_already_used
+c     fillcr  fill_char
+c     putlie  putline
+c     ofilee  ofile_type
+c     formar  format_char
+#-------------------------------------------------------------------------------
+# fprfmt.s:
+	.data
+	.data1
+	.bss
+	.data
+	.globl	_fprfmt_
+	.comm	_fmtcom_,2416
+	.globl	_ctoi_
+	.globl	_stridx_
+	.globl	_putlie_
+	.globl	_fmterr_
+	.globl	_chrlwr_
+	.align 4
+	.text
+|#PROC# 07
+
+	.bss
+	.align	4
+VAR_SEG1:
+	.skip	10
+	.data1
+	.align	2
+L1D186:
+	.long	5
+	LF1	=	228
+	LS1	=	8432
+	LFF1	=	208
+	LSS1	=	0
+	LP1	=	20
+	.text
+	.globl	_fprfmt_
+_fprfmt_:
+	link	a6,#-228
+	moveml	#8432,sp@
+	movl	a6@(8),a5
+	movl	_fmtcom_+4,d4
+	movl	VAR_SEG1+4,d5
+	cmpl	#1,_fmtcom_+28
+	jge	L77020
+	jra	L77005
+L77007:
+	moveq	#1,d5
+	movl	a5@,d7
+	jge	L77043
+	movl	d5,_fmtcom_+20
+	jra	L77044
+L77009:
+	moveq	#1,d5
+	movl	a5@,d7
+	jge	L77078
+	movl	d5,_fmtcom_+20
+	jra	L77079
+L77011:
+	moveq	#1,d5
+	movl	a5@,_fmtcom_+12
+	jra	L77109
+L77013:
+	moveq	#1,d5
+	movl	a5@,d7
+	jra	L77118
+L77015:
+	moveq	#1,d5
+	movl	a5@,_fmtcom_+24
+	jra	LY00019
+L77017:
+	moveq	#1,d5
+	jra	LY00006
+L77018:
+	movl	_fmtcom_+28,d0
+	moveq	#8,d7
+	cmpl	d7,d0
+	bcc	L77005
+	addw	d0,d0
+	movw	pc@(6,d0:w),d0
+	jmp	pc@(2,d0:w)
+L1I1:
+	.word	L77023-L1I1
+	.word	L77004-L1I1
+	.word	L77007-L1I1
+	.word	L77009-L1I1
+	.word	L77011-L1I1
+	.word	L77013-L1I1
+	.word	L77015-L1I1
+	.word	L77017-L1I1
+	jra	L77005
+L77020:
+	cmpl	#7,_fmtcom_+28
+	jle	L77018
+	jra	L77005
+L77023:
+	jra	L77005
+L77030:
+	addql	#1,d4
+	movl	d4,d7
+	lea	_fmtcom_+40,a0
+	movw	a0@(0,d7:l:2),d0
+	extl	d0
+	moveq	#42,d6
+	cmpl	d6,d0
+	jne	L77035
+	addql	#1,d7
+	movl	d7,d4
+	tstl	d5
+	jeq	L77007
+	moveq	#2,d6
+	jra	LY00016
+L77024:
+	movl	#-999,_fmtcom_+8
+	movl	#-999,_fmtcom_+12
+	movl	#-999,_fmtcom_+36
+	movw	#32,_fmtcom_+40
+	clrl	_fmtcom_+20
+LY00006:
+	moveq	#1,d6
+	moveq	#1,d7
+	jra	LY00010
+L77129:
+	movl	d4,_fmtcom_+4
+	asll	#1,d4
+	addl	#_fmtcom_+40,d4
+	movl	d4,sp@-
+	jbsr	_chrlwr_
+	addqw	#4,sp
+	movl	_fmtcom_+4,d4
+	addql	#1,d4
+	extl	d0
+	movl	d0,d7
+	moveq	#42,d6
+	cmpl	d6,d7
+	jne	L77136
+	tstl	d5
+	jeq	L77015
+	moveq	#6,d6
+	jra	LY00016
+L77136:
+	moveq	#48,d6
+	cmpl	d6,d7
+	jlt	L77146
+	moveq	#57,d6
+	cmpl	d6,d7
+	jgt	L77146
+	moveq	#-48,d6
+	addl	d6,d7
+	movl	d7,_fmtcom_+24
+	jra	LY00019
+L77146:
+	moveq	#97,d6
+	cmpl	d6,d7
+	jlt	L77152
+	moveq	#122,d6
+	cmpl	d6,d7
+	jgt	L77152
+	moveq	#-87,d6
+	addl	d6,d7
+	movl	d7,_fmtcom_+24
+	jra	LY00019
+L77152:
+	moveq	#10,d7
+	movl	d7,_fmtcom_+24
+	moveq	#-1,d7
+	addl	d7,d4
+	jra	LY00019
+LY00020:
+	movl	d4,_fmtcom_+4
+	pea	v.17
+	pea	L1D186
+	jbsr	_putlie_
+	addqw	#8,sp
+	movl	_fmtcom_+4,d0
+	moveq	#-1,d7
+	addl	d7,d0
+	movl	d0,a6@(-20)
+	pea	a6@(-20)
+	pea	_fmtcom_+42
+	pea	v.18
+	jbsr	_fmterr_
+	lea	sp@(12),sp
+	movl	_fmtcom_+4,d4
+	movl	#-999,_fmtcom_+36
+LY00019:
+	tstl	d5
+	jeq	L77017
+	moveq	#7,d6
+	jra	LY00016
+L77110:
+	addql	#1,d4
+	tstl	d5
+	jeq	L77013
+	moveq	#5,d6
+	jra	LY00016
+L77096:
+	addql	#1,d7
+	movl	d7,d4
+	tstl	d5
+	jeq	L77011
+	moveq	#4,d6
+LY00016:
+	moveq	#0,d7
+LY00010:
+	movl	d7,d0
+	movl	d6,_fmtcom_+28
+	movl	d4,_fmtcom_+4
+	movl	d5,VAR_SEG1+4
+	moveml	a6@(-228),#8432
+	unlk	a6
+	rts
+L77004:
+	moveq	#0,d5
+L77005:
+	lea	_fmtcom_+40,a0
+	movw	a0@(0,d4:l:2),d0
+	extl	d0
+	movl	d0,d7
+	jeq	L77024
+	moveq	#37,d6
+	cmpl	d6,d7
+	jeq	L77030
+	jra	L77024
+L77035:
+	moveq	#45,d4
+	cmpl	d4,d6
+	jne	L77052
+	moveq	#1,d6
+	movl	d6,_fmtcom_+20
+	addql	#1,d7
+	jra	L77053
+L77043:
+	clrl	_fmtcom_+20
+L77044:
+	movw	#32,_fmtcom_+40
+	tstl	d7
+	jlt	L77046
+	jra	LY00023
+L77088:
+	movl	#-999,_fmtcom_+8
+	jra	L77091
+L77052:
+	clrl	_fmtcom_+20
+L77053:
+	movw	#32,_fmtcom_+40
+	movl	d7,d6
+	asll	#1,d6
+	lea	_fmtcom_+40,a0
+	movw	a0@(0,d6:l),d0
+	extl	d0
+	moveq	#48,d4
+	cmpl	d4,d0
+	jne	L77057
+	lea	_fmtcom_+42,a0
+	movw	a0@(0,d6:l),d0
+	extl	d0
+	movl	d0,d4
+	moveq	#48,d6
+	cmpl	d6,d4
+	jlt	L77061
+	moveq	#57,d6
+	cmpl	d6,d4
+	jgt	L77061
+	jra	L77058
+L77057:
+	lea	_fmtcom_+40,a0
+	movw	a0@(0,d7:l:2),d0
+	extl	d0
+	moveq	#42,d6
+	cmpl	d6,d0
+	jne	L77070
+	addql	#1,d7
+	movl	d7,d4
+	tstl	d5
+	jeq	L77009
+	moveq	#3,d6
+	jra	LY00016
+L77065:
+	movw	#32,_fmtcom_+40
+	jra	L77057
+L77058:
+	movw	#48,_fmtcom_+40
+	addql	#1,d7
+	jra	L77057
+L77061:
+	moveq	#42,d6
+	cmpl	d6,d4
+	jne	L77065
+	jra	L77058
+L77070:
+	movl	d7,_fmtcom_+4
+	movl	d7,_fmtcom_+4
+	pea	_fmtcom_+8
+	pea	_fmtcom_+4
+	pea	_fmtcom_+42
+	jbsr	_ctoi_
+	lea	sp@(12),sp
+	moveq	#0,d1
+	tstl	d0
+	sle	d1
+	negb	d1
+	movl	d1,a6@(-52)
+	movl	_fmtcom_+4,d4
+	tstl	d1
+	jeq	LY00002
+	movl	#-999,_fmtcom_+8
+	jra	LY00002
+L77078:
+	clrl	_fmtcom_+20
+L77079:
+	tstl	d7
+	jge	LY00023
+L77046:
+	negl	d7
+LY00023:
+	movl	d7,_fmtcom_+8
+LY00002:
+	tstl	_fmtcom_+8
+	jeq	L77088
+L77091:
+	lea	_fmtcom_+40,a0
+	movw	a0@(0,d4:l:2),d0
+	extl	d0
+	moveq	#46,d7
+	cmpl	d7,d0
+	jne	L77105
+	addql	#1,d4
+	movl	d4,d7
+	lea	_fmtcom_+40,a0
+	movw	a0@(0,d7:l:2),d0
+	extl	d0
+	moveq	#42,d6
+	cmpl	d6,d0
+	jeq	L77096
+	movl	d7,_fmtcom_+4
+	movl	d7,_fmtcom_+4
+	pea	_fmtcom_+12
+	pea	_fmtcom_+4
+	pea	_fmtcom_+42
+	jbsr	_ctoi_
+	lea	sp@(12),sp
+	moveq	#0,d1
+	tstl	d0
+	sle	d1
+	negb	d1
+	movl	d1,a6@(-48)
+	movl	_fmtcom_+4,d4
+	tstl	d1
+	jeq	L77109
+L77105:
+	movl	#-999,_fmtcom_+12
+L77109:
+	lea	_fmtcom_+40,a0
+	movw	a0@(0,d4:l:2),d0
+	extl	d0
+	movl	d0,d6
+	moveq	#42,d7
+	cmpl	d7,d6
+	jeq	L77110
+	movl	d6,d7
+	addql	#1,d4
+L77118:
+	moveq	#65,d6
+	cmpl	d6,d7
+	jlt	L77123
+	moveq	#90,d6
+	cmpl	d6,d7
+	jgt	L77123
+	moveq	#32,d6
+	addl	d6,d7
+L77123:
+	movw	d7,VAR_SEG1+8
+	movl	d7,_fmtcom_+36
+	movl	d4,_fmtcom_+4
+	pea	v.16
+	pea	VAR_SEG1+8
+	jbsr	_stridx_
+	addqw	#8,sp
+	moveq	#0,d1
+	tstl	d0
+	sle	d1
+	negb	d1
+	movl	d1,a6@(-44)
+	movl	_fmtcom_+4,d4
+	tstl	d1
+	jne	LY00020
+	cmpl	#114,_fmtcom_+36
+	jeq	L77129
+	cmpl	#119,_fmtcom_+36
+	jeq	L77017
+	cmpl	#116,_fmtcom_+36
+	jne	LY00019
+	jra	L77017
+	.globl	f68881_used
+	.data1
+	.align 4
+v.16:
+	.long	0x620063,0x640065
+	.long	0x660067,0x68006d
+	.long	0x6f0072,0x730074
+	.long	0x750077,0x78007a
+	.word	0x0
+	.align 4
+v.17:
+	.long	0x570061,0x72006e
+	.long	0x69006e,0x67003a
+	.long	0x200055,0x6e006b
+	.long	0x6e006f,0x77006e
+	.long	0x200066,0x6f0072
+	.long	0x6d0061,0x740020
+	.long	0x740079,0x700065
+	.long	0x200063,0x680061
+	.long	0x72000a
+	.word	0x0
+	.align 4
+v.18:
+	.skip	2
+#===============================================================================
+#     ==========================
+#     FORTRAN for get_next_image
+#     ==========================
+      integer function getnee (infile, recors, nrecs, image, szname)
+      integer infile
+      integer nrecs
+      integer szname
+      integer recors(3,100)
+      integer*2 image(szname+1)
+      integer nextnm
+      integer stat
+      logical flag1
+      logical flag2
+      logical flag3
+      integer*2 image0(63 +1)
+      integer clgfil
+      integer getney
+      integer xstrln
+      common /gnicom/ flag1, flag2
+      integer*2 st0001(6)
+      save
+      data st0001 / 46, 37, 48, 52,100, 0/
+      data flag3/.true./
+         if (.not.(flag1 .or. flag3)) goto 110
+            nextnm = -1
+            call rstgey ()
+110      continue
+         if (.not.(nrecs .eq. 2147483647)) goto 120
+            stat = clgfil (infile, image, szname)	#<--- Never executed
+            goto 121
+120      continue
+            if (.not.(flag1)) goto 130
+               stat = clgfil (infile, image0, szname)
+               if (.not.(stat .eq. -2)) goto 140
+                  getnee = (stat)
+                  goto 100
+140            continue
+130         continue
+            stat = getney (recors, nextnm)
+            if (.not.(stat .ne. -2)) goto 150
+               call xstrcy(image0, image, szname)
+               call sprinf (image(xstrln(image)+1), szname, st0001)
+               call pargi (nextnm)
+150         continue
+121      continue
+         flag1 = .false.
+         flag3 = .false.
+         getnee = (stat)
+         goto 100
+100      return
+      end
+
+#====================================================================
+#Optimized assembly
+#====================================================================
+
+_getnee_+4:		moveml	d4/d5/d6/d7,sp@
+			tstl	_gnicom_
+			beqs	_getnee_+0x30
+			bras	_getnee_+0x20
+_getnee_+0x12:		movl	d7,d0
+			moveml	a6@(-0x50),d4/d5/d6/d7
+			unlk	a6
+			rts
+			bras	_getnee_+0x38
+			moveq	#-1,d6
+			movl	d6,ARR_SEG5+0x294
+			jsr	_rstgey_
+			bras	_getnee_+0x38
+			tstl	v.150+0x90
+			bnes	_getnee_+0x20
+			movl	a6@(8),d4
+			movl	a6@(0x18),d5
+			movl	a6@(0x14),d6
+			movl	a6@(0x10),a0
+			cmpl	#0x7fffffff,a0@		<--------
+			beq	_getnee_+0xd4		<-------- Causes return
+			tstl	_gnicom_
+			beqs	_getnee_+0x76
+			movl	d5,sp@-
+			pea	ARR_SEG5+0x298
+			movl	d4,sp@-
+			bsrl	_clgfil_
+			lea	sp@(0xc),a7
+			movl	d0,d7
+			moveq	#-2,d4
+			cmpl	d4,d7
+			beqs	_getnee_+0x12
+			pea	ARR_SEG5+0x294
+			movl	a6@(0xc),sp@-
+			jsr	_getney_
+			addqw	#8,sp
+			movl	d0,d7
+			moveq	#-2,d4
+			cmpl	d4,d7
+			beqs	_getnee_+0xd4
+			movl	d5,sp@-
+			movl	d6,sp@-
+			pea	ARR_SEG5+0x298
+			bsrl	_xstrcy_
+			lea	sp@(0xc),a7
+			pea	v.150+0x84
+			movl	d5,sp@-
+			movl	d6,sp@-
+			bsrl	_xstrln_
+			addqw	#4,sp
+			asll	#1,d0
+			addl	d6,d0
+			movl	d0,sp@-
+			bsrl	_sprinf_
+			lea	sp@(0xc),a7
+			pea	ARR_SEG5+0x294
+			bsrl	_pargi_
+			addqw	#4,sp
+_getnee_+0xd4:		clrl	_gnicom_
+			clrl	v.150+0x90
+			bra	_getnee_+0x12
+
+_resete_:		linkw	a6,#0
+			movl	#1,_gnicom_
+			unlk	a6
+			rts
+
+_addspc_:		linkw	a6,#-0xec
+			moveml	d3/d4/d5/d6/d7/a3/a4/a5,sp@
+			fmovex	fp7,a6@(-0xcc)
+			moveq	#0,d6
+			movl	a6@(0x14),a0
+			movl	a0@,a5
+			tstl	a5
+			bnes	_addspc_+0x8e
+			moveq	#-1,d6
+			bras	_addspc_+0x8e
+			moveq	#1,d4
+			movl	a4@,d7
+			subl	d4,d7
+			tstl	d7
+			blt	_addspc_+0xb4
+
+
+#===============================================================================
+# grcwcs.f:
+      subroutine grcscs (stream, sx, sy, wx, wy, wcs)
+      integer stream
+      real sx
+      real sy
+      real wx
+      real wy
+      integer wcs
+      logical Memb(1)
+      integer*2 Memc(1)
+      integer*2 Mems(1)
+      integer Memi(1)
+      integer*4 Meml(1)
+      real Memr(1)
+      double precision Memd(1)
+      complex Memx(1)
+      equivalence (Memb, Memc, Mems, Memi, Meml, Memr, Memd, Memx)
+      common /Mem/ Memd
+      integer w
+      integer tr
+      real mx
+      real my
+      real ct(2,4)
+      integer grcses
+      integer gtrint
+      save
+         tr = gtrint (stream)
+         call grcscc (sx, sy, mx, my)
+         if (.not.(memi(tr+16) .eq. 0)) goto 110
+            wcs = grcses (tr, mx, my)
+            goto 111
+110      continue
+            wcs = memi(tr+16)
+111      continue
+         w = ((tr)+154+(wcs)*11)
+         call grcsen (w, ct)
+         call grcnds (ct, mx, my, wx, wy)
+100      return
+      end
+      subroutine grcsen (w, ct)
+      logical Memb(1)
+      integer*2 Memc(1)
+      integer*2 Mems(1)
+      integer Memi(1)
+      integer*4 Meml(1)
+      real Memr(1)
+      double precision Memd(1)
+      complex Memx(1)
+      equivalence (Memb, Memc, Mems, Memi, Meml, Memr, Memd, Memx)
+      common /Mem/ Memd
+      integer w
+      real ct(2,4)
+      real worign
+      real scale
+      real m1
+      real m2
+      real w1
+      real w2
+      integer transn
+      integer ax
+      real elogr
+      save
+         do 110 ax = 1, 2 
+            if (.not.(ax .eq. 1)) goto 120
+               transn = memi(w+8)
+               w1 = memr(w)
+               w2 = memr(w+1)
+               m1 = memr(w+4)
+               m2 = memr(w+5)
+               goto 121
+120         continue
+               transn = memi(w+9)
+               w1 = memr(w+2)
+               w2 = memr(w+3)
+               m1 = memr(w+6)
+               m2 = memr(w+7)
+121         continue
+            if (.not.(transn .eq. 0 )) goto 130
+               worign = w1
+               scale = (m2 - m1) / (w2 - w1)
+               goto 131
+130         continue
+            if (.not.(transn .eq. 1 .and. w1 .gt. 0 .and. w2 .gt. 0)) 
+     *      goto 140
+               worign = log10 (w1)
+               scale = (m2 - m1) / (log10(w2) - worign)
+               goto 141
+140         continue
+               worign = elogr (w1)
+               scale = (m2 - m1) / (elogr(w2) - worign)
+141         continue
+131         continue
+            ct(ax,1) = transn
+            ct(ax,2) = scale
+            ct(ax,3) = worign
+            ct(ax,4) = m1
+110      continue
+111      continue
+100      return
+      end
+      subroutine grcwcc (ct, wx, wy, mx, my)
+      real wx
+      real wy
+      real mx
+      real my
+      real ct(2,4)
+      real v
+      integer transn
+      integer ax
+      real elogr
+      save
+         do 110 ax = 1, 2 
+            transn = nint (ct(ax,1))
+            if (.not.(ax .eq. 1)) goto 120
+               v = wx
+               goto 121
+120         continue
+               v = wy
+121         continue
+            if (.not.(transn .eq. 0 )) goto 130
+               goto 131
+130         continue
+            if (.not.(transn .eq. 1)) goto 140
+               v = log10 (v)
+               goto 141
+140         continue
+               v = elogr (v)
+141         continue
+131         continue
+            v = ((v - ct(ax,3)) * ct(ax,2)) + ct(ax,4)
+            if (.not.(ax .eq. 1)) goto 150
+               mx = v
+               goto 151
+150         continue
+               my = v
+151         continue
+110      continue
+111      continue
+100      return
+      end
+      subroutine grcnds (ct, mx, my, wx, wy)
+      real mx
+      real my
+      real wx
+      real wy
+      real ct(2,4)
+      real v
+      integer transn
+      integer ax
+      real aelogr
+      save
+         do 110 ax = 1, 2 
+            transn = nint (ct(ax,1))
+            if (.not.(ax .eq. 1)) goto 120
+               v = mx
+               goto 121
+120         continue
+               v = my
+121         continue
+            v = ((v - ct(ax,4)) / ct(ax,2)) + ct(ax,3)
+            if (.not.(transn .eq. 0 )) goto 130
+               goto 131
+130         continue
+            if (.not.(transn .eq. 1)) goto 140
+               v = 10.0 ** v
+               goto 141
+140         continue
+               v = aelogr (v)
+141         continue
+131         continue
+            if (.not.(ax .eq. 1)) goto 150
+               wx = v
+               goto 151
+150         continue
+               wy = v
+151         continue
+110      continue
+111      continue
+100      return
+      end
+      integer function grcses (tr, mx, my)
+      logical Memb(1)
+      integer*2 Memc(1)
+      integer*2 Mems(1)
+      integer Memi(1)
+      integer*4 Meml(1)
+      real Memr(1)
+      double precision Memd(1)
+      complex Memx(1)
+      equivalence (Memb, Memc, Mems, Memi, Meml, Memr, Memd, Memx)
+      common /Mem/ Memd
+      integer tr
+      real mx
+      real my
+      integer w
+      integer wcs
+      integer closes
+      real tol
+      real sx1
+      real sx2
+      real sy1
+      real sy2
+      real distae
+      real olddie
+      real xcen
+      real ycen
+      integer nin
+      integer in(16 )
+      save
+         nin = 0
+         closes = 1
+         olddie = 1.0
+         tol = (1.192e-7) * 10.0
+         do 110 wcs = 1, 16 
+            w = ((tr)+154+(wcs)*11)
+            sx1 = memr(w+4)
+            sx2 = memr(w+5)
+            sy1 = memr(w+6)
+            sy2 = memr(w+7)
+            xcen = (sx1 + sx2) / 2.0
+            ycen = (sy1 + sy2) / 2.0
+            if (.not.(abs ((sx2-sx1) - 1.0) .lt. tol .and. abs ((sy2-sy1
+     *      ) - 1.0) .lt. tol)) goto 120
+               goto 110
+120         continue
+            distae = ((mx - xcen) ** 2) + ((my - ycen) ** 2)
+            if (.not.(distae .le. olddie)) goto 130
+               closes = wcs
+               olddie = distae
+130         continue
+            if (.not.(mx .ge. sx1 .and. mx .le. sx2 .and. my .ge. sy1 .
+     *      and. my .le. sy2)) goto 140
+               nin = nin + 1
+               in(nin) = wcs
+140         continue
+110      continue
+111      continue
+         if (.not.(nin .eq. 1)) goto 150
+            grcses = (in(1))
+            goto 100
+150      continue
+         grcses = (closes)
+         goto 100
+100      return
+      end
+c     gtrint  gtr_init
+c     grcses  grc_selectwcs
+c     grcscs  grc_scrtowcs
+c     olddie  old_distance
+c     grcsen  grc_settran
+c     transn  transformation
+c     distae  distance
+c     grcscc  grc_scrtondc
+c     closes  closest_wcs
+c     grcnds  grc_ndctowcs
+c     grcwcc  grc_wcstondc
+c     worign  worigin
+#-------------------------------------------------------------------------------
+# grcwcs.s:
+	.data
+	.data1
+	.bss
+	.data
+	.data1
+	.bss
+	.data
+	.data1
+	.bss
+	.data
+	.data1
+	.bss
+	.data
+	.data1
+	.bss
+	.data
+	.globl	_grcscs_
+	.comm	_mem_,8
+	.globl	_gtrint_
+	.globl	_grcscc_
+	.globl	_grcses_
+	.globl	_grcsen_
+	.globl	_grcnds_
+	.globl	_elogr_
+	.globl	_grcwcc_
+	.globl	_i_nint
+	.globl	_aelogr_
+	.align 4
+	.text
+|#PROC# 07
+
+	.bss
+	.align	4
+VAR_SEG1:
+	.skip	16
+	.bss
+	.align	4
+ARR_SEG1:
+	.skip	32
+	LF1	=	20
+	LS1	=	128
+	LFF1	=	16
+	LSS1	=	0
+	LP1	=	28
+	.text
+	.globl	_grcscs_
+_grcscs_:
+	link	a6,#-20
+	movl	d7,sp@
+	movl	a6@(8),sp@-
+	jbsr	_gtrint_
+	addqw	#4,sp
+	movl	d0,VAR_SEG1+4
+	pea	VAR_SEG1+12
+	pea	VAR_SEG1+8
+	movl	a6@(16),sp@-
+	movl	a6@(12),sp@-
+	jbsr	_grcscc_
+	lea	sp@(16),sp
+	movl	VAR_SEG1+4,d0
+	lea	_mem_+60,a0
+	movl	a0@(0,d0:l:4),d7
+	jne	L77006
+	pea	VAR_SEG1+12
+	pea	VAR_SEG1+8
+	pea	VAR_SEG1+4
+	jbsr	_grcses_
+	lea	sp@(12),sp
+	movl	a6@(28),a0
+	movl	d0,a0@
+	jra	L77007
+L77006:
+	movl	a6@(28),a0
+	movl	d7,a0@
+L77007:
+	movl	a6@(28),a0
+	movl	a0@,d0
+	movl	d0,d1
+	addl	d1,d1
+	addl	d1,d0
+	asll	#2,d1
+	addl	d1,d0
+	movl	VAR_SEG1+4,d1
+	addl	#154,d1
+	addl	d1,d0
+	movl	d0,VAR_SEG1
+	pea	ARR_SEG1
+	pea	VAR_SEG1
+	jbsr	_grcsen_
+	addqw	#8,sp
+	movl	a6@(24),sp@-
+	movl	a6@(20),sp@-
+	pea	VAR_SEG1+12
+	pea	VAR_SEG1+8
+	pea	ARR_SEG1
+	jbsr	_grcnds_
+	lea	sp@(20),sp
+	movl	a6@(-20),d7
+	unlk	a6
+	rts
+|#PROC# 07
+
+	.bss
+	.align	4
+VAR_SEG2:
+	.skip	32
+	.data1
+	.align	2
+L2D24:
+	.long	0
+	.data1
+	.align	2
+L2D22:
+	.long	0
+	LF2	=	432
+	LS2	=	15612
+	LFF2	=	392
+	LSS2	=	63
+	LP2	=	12
+	.text
+	.globl	_grcsen_
+_grcsen_:
+	link	a6,#-432
+	moveml	#15612,sp@
+	fmovem	#63,a6@(-392)
+	moveq	#1,d7
+	movl	d7,VAR_SEG2+20
+	movl	a6@(12),d0
+	moveq	#20,d7
+	addl	d7,d0
+	movl	d0,a6@(-4)
+	movl	a6@(12),d0
+	moveq	#12,d7
+	addl	d7,d0
+	movl	d0,a6@(-8)
+	movl	a6@(12),d0
+	addql	#4,d0
+	movl	d0,a6@(-12)
+	movl	a6@(12),d0
+	moveq	#-4,d7
+	addl	d7,d0
+	movl	d0,a6@(-16)
+	movl	a6@(8),a0
+	movl	a0@,d7
+	asll	#2,d7
+	movl	#_mem_+16,d0
+	addl	d7,d0
+	movl	d0,a6@(-20)
+	movl	#_mem_+12,d0
+	addl	d7,d0
+	movl	d0,a6@(-24)
+	movl	#_mem_,d0
+	addl	d7,d0
+	movl	d0,a6@(-28)
+	movl	#_mem_+-4,d0
+	addl	d7,d0
+	movl	d0,a6@(-32)
+	movl	#_mem_+28,d0
+	addl	d7,d0
+	movl	d0,a6@(-36)
+	movl	#_mem_+24,d0
+	addl	d7,d0
+	movl	d0,a6@(-40)
+	movl	#_mem_+20,d2
+	addl	d7,d2
+	movl	#_mem_+8,d3
+	addl	d7,d3
+	movl	#_mem_+4,d4
+	addl	d7,d4
+	movl	#_mem_+32,d5
+	addl	d7,d5
+	movl	VAR_SEG2+20,d6
+	asll	#2,d6
+	movl	d6,a2
+	addl	a6@(-4),a2
+	movl	d6,a3
+	addl	a6@(-16),a3
+	movl	d6,a4
+	addl	a6@(-12),a4
+	movl	d6,d0
+	addl	a6@(-8),d0
+	movl	d0,a5
+L77011:
+	moveq	#4,d7
+	cmpl	d7,d6
+	jne	L77015
+	movl	a6@(-36),a0
+	movl	a0@,d7
+	movl	a6@(-32),a0
+	fmoves	a0@,fp3
+	movl	a6@(-28),a0
+	fmoves	a0@,fp2
+	movl	a6@(-24),a0
+	fmoves	a0@,fp7
+	movl	a6@(-20),a0
+	jra	LY00000
+L77015:
+	movl	d5,a0
+	movl	a0@,d7
+	movl	d4,a0
+	fmoves	a0@,fp3
+	movl	d3,a0
+	fmoves	a0@,fp2
+	movl	d2,a0
+	fmoves	a0@,fp7
+	movl	a6@(-40),a0
+LY00000:
+	fmoves	a0@,fp5
+	tstl	d7
+	jne	L77020
+	fmovex	fp3,fp6
+	fmovex	fp5,fp0
+	fsubx	fp7,fp0
+	fmovex	fp2,fp1
+	fsubx	fp3,fp1
+	jra	LY00001
+L77020:
+	cmpl	#1,d7
+	jne	L77027
+	fcmps	L2D24,fp3
+	fjngt	L77027
+	fcmps	L2D22,fp2
+	fjngt	L77027
+	flog10x	fp3,fp0
+	fmovex	fp0,fp6
+	fmovex	fp5,fp0
+	fsubx	fp7,fp0
+	flog10x	fp2,fp1
+	fsubx	fp6,fp1
+LY00001:
+	fdivx	fp1,fp0
+	fmovex	fp0,fp4
+L77021:
+	fmovel	d7,fp0
+	fmoves	fp0,a3@+
+	fmoves	fp4,a4@+
+	fmoves	fp6,a5@+
+	fmoves	fp7,a2@+
+	addql	#4,d6
+	moveq	#8,d7
+	cmpl	d7,d6
+	jle	L77011
+	fmovem	a6@(-392),#63
+	moveml	a6@(-432),#15612
+	unlk	a6
+	rts
+L77027:
+	fmoves	fp3,VAR_SEG2+12
+	pea	VAR_SEG2+12
+	jbsr	_elogr_
+	addqw	#4,sp
+	fmoves	d0,fp6
+	fmoves	fp2,VAR_SEG2+16
+	pea	VAR_SEG2+16
+	jbsr	_elogr_
+	addqw	#4,sp
+	fmoves	d0,fp0
+	fsubx	fp6,fp0
+	fsubx	fp7,fp5
+	fdivx	fp0,fp5
+	fmovex	fp5,fp4
+	jra	L77021
+|#PROC# 07
+
+	.bss
+	.align	4
+VAR_SEG3:
+	.skip	12
+	LF3	=	264
+	LS3	=	15608
+	LFF3	=	228
+	LSS3	=	7
+	LP3	=	12
+	.text
+	.globl	_grcwcc_
+_grcwcc_:
+	link	a6,#-264
+	moveml	#15608,sp@
+	fmovem	#7,a6@(-228)
+	moveq	#1,d7
+	movl	a6@(20),a2
+	movl	a6@(24),d3
+	movl	a6@(8),d6
+	movl	d6,d0
+	moveq	#20,d5
+	addl	d5,d0
+	movl	d0,a6@(-4)
+	movl	d6,d0
+	addql	#4,d0
+	movl	d0,a6@(-8)
+	movl	d6,d0
+	moveq	#12,d5
+	addl	d5,d0
+	movl	d0,a6@(-12)
+	movl	a6@(12),a0
+	fmoves	a0@,fp5
+	movl	a6@(16),a0
+	fmoves	a0@,fp6
+	moveq	#-4,d5
+	addl	d5,d6
+	movl	d6,a6@(-24)
+	asll	#2,d7
+	movl	d7,a3
+	addl	a6@(-4),a3
+	movl	d7,d4
+	addl	d6,d4
+	movl	d7,a4
+	addl	d0,a4
+	movl	d7,a5
+	addl	a6@(-8),a5
+L77034:
+	movl	d4,sp@-
+	jbsr	_i_nint
+	addqw	#4,sp
+	movl	d0,d6
+	moveq	#0,d0
+	moveq	#4,d5
+	cmpl	d5,d7
+	seq	d0
+	negb	d0
+	movl	d0,d5
+	jeq	L77038
+	fmovex	fp5,fp7
+	jra	L77039
+L77038:
+	fmovex	fp6,fp7
+L77039:
+	tstl	d6
+	jeq	LY00002
+	cmpl	#1,d6
+	jne	L77048
+	flog10x	fp7,fp0
+	fmovex	fp0,fp7
+	jra	LY00002
+L77050:
+	fmoves	fp7,a2@
+	jra	L85
+L77048:
+	fmoves	fp7,VAR_SEG3
+	pea	VAR_SEG3
+	jbsr	_elogr_
+	addqw	#4,sp
+	fmoves	d0,fp7
+LY00002:
+	fsubs	a4@,fp7
+	fmuls	a5@,fp7
+	fadds	a3@,fp7
+	tstl	d5
+	jne	L77050
+	movl	d3,a0
+	fmoves	fp7,a0@
+L85:
+	addql	#4,d7
+	addqw	#4,a5
+	addqw	#4,a4
+	addql	#4,d4
+	addqw	#4,a3
+	moveq	#8,d6
+	cmpl	d6,d7
+	jle	L77034
+	fmovem	a6@(-228),#7
+	moveml	a6@(-264),#15608
+	unlk	a6
+	rts
+|#PROC# 07
+
+	.bss
+	.align	4
+VAR_SEG4:
+	.skip	12
+	LF4	=	264
+	LS4	=	15608
+	LFF4	=	228
+	LSS4	=	7
+	LP4	=	12
+	.text
+	.globl	_grcnds_
+_grcnds_:
+	link	a6,#-264
+	moveml	#15608,sp@
+	fmovem	#7,a6@(-228)
+	moveq	#1,d7
+	movl	a6@(20),a2
+	movl	a6@(24),d3
+	movl	a6@(8),d6
+	movl	d6,d0
+	moveq	#12,d5
+	addl	d5,d0
+	movl	d0,a6@(-4)
+	movl	d6,d0
+	addql	#4,d0
+	movl	d0,a6@(-8)
+	movl	d6,d0
+	moveq	#20,d5
+	addl	d5,d0
+	movl	d0,a6@(-12)
+	movl	a6@(12),a0
+	fmoves	a0@,fp5
+	movl	a6@(16),a0
+	fmoves	a0@,fp6
+	moveq	#-4,d5
+	addl	d5,d6
+	movl	d6,a6@(-24)
+	asll	#2,d7
+	movl	d7,a3
+	addl	a6@(-4),a3
+	movl	d7,d4
+	addl	d6,d4
+	movl	d7,a4
+	addl	d0,a4
+	movl	d7,a5
+	addl	a6@(-8),a5
+L77060:
+	movl	d4,sp@-
+	jbsr	_i_nint
+	addqw	#4,sp
+	movl	d0,d6
+	moveq	#0,d0
+	moveq	#4,d5
+	cmpl	d5,d7
+	seq	d0
+	negb	d0
+	movl	d0,d5
+	jeq	L77064
+	fmovex	fp5,fp7
+	jra	L77065
+L77064:
+	fmovex	fp6,fp7
+L77065:
+	fsubs	a4@,fp7
+	fdivs	a5@,fp7
+	fadds	a3@,fp7
+	tstl	d6
+	jeq	LY00004
+	cmpl	#1,d6
+	jne	L77074
+	ftentoxx	fp7,fp0
+	fmovex	fp0,fp7
+	jra	LY00004
+L77076:
+	fmoves	fp7,a2@
+	jra	L121
+L77074:
+	fmoves	fp7,VAR_SEG4
+	pea	VAR_SEG4
+	jbsr	_aelogr_
+	addqw	#4,sp
+	fmoves	d0,fp7
+LY00004:
+	tstl	d5
+	jne	L77076
+	movl	d3,a0
+	fmoves	fp7,a0@
+L121:
+	addql	#4,d7
+	addqw	#4,a5
+	addqw	#4,a4
+	addql	#4,d4
+	addqw	#4,a3
+	moveq	#8,d6
+	cmpl	d6,d7
+	jle	L77060
+	fmovem	a6@(-228),#7
+	moveml	a6@(-264),#15608
+	unlk	a6
+	rts
+|#PROC# 07
+
+	.bss
+	.align	4
+VAR_SEG5:
+	.skip	52
+	.bss
+	.align	4
+ARR_SEG5:
+	.skip	64
+	.data1
+	.align	2
+L5D70:
+	.single	0r1.00000000000000000e+00
+	.data1
+	.align	2
+L5D68:
+	.single	0r1.00000000000000000e+01
+	.data1
+	.align	2
+L5D67:
+	.single	0r1.19200000000000000e-07
+	.data1
+	.align	2
+L5D49:
+	.single	0r2.00000000000000000e+00
+	.data1
+	.align	2
+L5D41:
+	.single	0r-1.00000000000000000e+00
+	LF5	=	356
+	LS5	=	8444
+	LFF5	=	328
+	LSS5	=	63
+	LP5	=	8
+	.text
+	.globl	_grcses_
+_grcses_:
+	link	a6,#-356
+	moveml	#8444,sp@
+	fmovem	#63,a6@(-328)
+	moveq	#0,d3
+	moveq	#1,d2
+	movl	L5D70,VAR_SEG5+4
+	fmoves	L5D68,fp0
+	fmuls	L5D67,fp0
+	fmoves	fp0,VAR_SEG5+40
+	moveq	#1,d6
+	movl	a6@(16),a0
+	movl	a0@,a6@(-60)
+	movl	a6@(12),a0
+	fmoves	a0@,fp2
+	movl	a6@(8),a0
+	movl	a0@,d0
+	addl	#154,d0
+	movl	d0,a6@(-36)
+	movl	d3,d0
+	asll	#2,d0
+	movl	d6,d5
+	movl	d5,d1
+	addl	d1,d1
+	addl	d1,d5
+	asll	#2,d1
+	addl	d1,d5
+	addl	#ARR_SEG5+-4,d0
+	movl	d0,a5
+	movl	d5,d4
+	addl	a6@(-36),d4
+	jra	L77087
+LY00009:
+	moveq	#1,d7
+	cmpl	d7,d3
+	jne	L77108
+	movl	ARR_SEG5,d7
+LY00008:
+	movl	d7,d0
+	fmovem	a6@(-328),#63
+	moveml	a6@(-356),#8444
+	unlk	a6
+	rts
+LY00006:
+	addql	#1,d6
+	moveq	#11,d7
+	addl	d7,d5
+	addl	d7,d4
+	cmpl	#176,d5
+	jgt	LY00009
+L77087:
+	movl	d4,d7
+	asll	#2,d7
+	lea	_mem_+12,a0
+	fmoves	a0@(0,d7:l),fp6
+	lea	_mem_+16,a0
+	fmoves	a0@(0,d7:l),fp4
+	lea	_mem_+20,a0
+	fmoves	a0@(0,d7:l),fp5
+	lea	_mem_+24,a0
+	fmoves	a0@(0,d7:l),fp3
+	fmovex	fp6,fp0
+	faddx	fp4,fp0
+	fdivs	L5D49,fp0
+	fmoves	fp0,VAR_SEG5+28
+	fmovex	fp5,fp0
+	faddx	fp3,fp0
+	fdivs	L5D49,fp0
+	fmoves	fp0,VAR_SEG5+32
+	fmovex	fp4,fp7
+	fsubx	fp6,fp7
+	fadds	L5D41,fp7
+	fabsx	fp7,fp0
+	fcmps	VAR_SEG5+40,fp0
+	fjnlt	L77092
+	fmovex	fp3,fp7
+	fsubx	fp5,fp7
+	fadds	L5D41,fp7
+	fabsx	fp7,fp0
+	fcmps	VAR_SEG5+40,fp0
+	fjlt	LY00006
+L77092:
+	fmovex	fp2,fp7
+	fsubs	VAR_SEG5+28,fp7
+	fmoves	fp7,a6@(-20)
+	fmoves	a6@(-60),fp7
+	fsubs	VAR_SEG5+32,fp7
+	fmoves	fp7,a6@(-24)
+	fmoves	a6@(-20),fp7
+	fmulx	fp7,fp7
+	fmoves	a6@(-24),fp1
+	fmulx	fp1,fp1
+	faddx	fp1,fp7
+	fcmps	VAR_SEG5+4,fp7
+	fjnle	L77096
+	movl	d6,d2
+	fmoves	fp7,VAR_SEG5+4
+L77096:
+	fcmpx	fp6,fp2
+	fjnge	LY00006
+	fcmpx	fp4,fp2
+	fjnle	LY00006
+	fcmps	a6@(-60),fp5
+	fjnle	LY00006
+	fcmps	a6@(-60),fp3
+	fjnge	LY00006
+	addql	#1,d3
+	addqw	#4,a5
+	movl	d6,a5@
+	jra	LY00006
+L77108:
+	movl	d2,d7
+	jra	LY00008
+	.globl	f68881_used
+	.data1
+#===============================================================================
diff --git a/doc/ports/sun4_sep87.doc b/doc/ports/sun4_sep87.doc
new file mode 100644
index 00000000..e10f5232
--- /dev/null
+++ b/doc/ports/sun4_sep87.doc
@@ -0,0 +1,296 @@
+Begin port of Sun/IRAF to the Sun-4 (RISC/sparc cpu).
+Beginning Saturday, 26 Sep 1987 (dct).
+=========================================
+
+V2.5 release was installed on the disk at /usr/iraf and stripped of all m68x
+binaries, by Skip before I started.
+
+/etc/termcap
+/usr/local/* +
+/local -> /usr/local +
+	The first step was to add some local utilities to the standard Sun
+	release.  Added entries for terminals sun{24,34,40,54},unixpc to the
+	termcap (unixpc is so I can work from home).  Added a bunch of stuff
+	in local, e.g., less, egrep, top, sps, mon, a modified 'man' which
+	uses less, etc.  (9/26)
+
+cd $iraf/unix
+sh -x mkpkg.sh >& spool &
+	Did a trial bootstrap just to see what would fail.  The only files
+	giving problems were, as expected, as$zsvjmp.s and os$zxwhen.c. (9/26)
+
+unix/os/zxwhen.c
+	Replaced the entire hardware exception initialization list by a
+	version which will work on any sun (680XX or sparc) or a Vax.  (9/26)
+
+unix/hlib/libc/iraf.h
+	Deleted the BSD42 and BSD43 entries, which were never used.  Replaced
+	with BSDUNIX (which has still not been used but will be, along with
+	a SYSVUNIX or some such).  In zxwhen.c, the #ifdefs use the system
+	type names defined by the C compiler, e.g., vax, sparc, m68k, etc.
+	(9/26)
+
+bin
+bin.sparc +
+bin.ffpa -
+bin.f68881 -
+	Deleted the .ffpa and .f68881 binaries for this host, and added a
+	bin.sparc directory for the sparc binaries.  Set bin to point to this.
+	(9/26)
+
+unix/mkpkg.sh
+unix/as -> unix/as.`mach`
+unix/as.vax
+unix/as.sparc +
+unix/as.mc68020 +
+	The different assemblers are quite incompatible, even on a Sun.
+	To make it possible to maintain sources for all Suns in one Sun/IRAF
+	source, I set up as.XX directories for the assembler sources for
+	each main hardware type, and made as a symbolic link to the particular
+	version in use.  The value of as is set automatically by mkpkg.sh
+	during a bootstrap.  Note that this does not necessarily work when
+	using a single source to maintain multiple versions of the system;
+	I will wait and resolve that later.  (9/26)
+
+unix/as.sparc/zsvjmp.s
+	Wrote a zsvjmp/zdojmp for the sparc architecture.  This was not
+	difficult, except for the time required to figure out the machine
+	architecture and assembler, which is not very well documented in the
+	gamma release of the SunOS for the Sun-4.  (9/26-27)
+
+cd $iraf/unix
+sh -x mkpkg.sh >& spool &
+	Did a real bootstrap, this time it completed with no errors.  (9/27)
+
+unix/hlib/mkpkg.inc
+unix/hlib/mkpkg.sf
+	In mkpkg.inc, set the FPU option to 'sparc'.  Added some $ifeq code
+	to set the XFLAGS,LFLAGS,XVFLAGS different for sparc than anything
+	else, since no -/fparc is tolerated on the commands to the compiler
+	programs.  In the mkpkg.sf, deleted all the old special file entries
+	having to do with compiler bugs, since we have a completely new set
+	of compilers to deal with on this machine (they really are very
+	different, especially in the optimization and code generation).  (9/27)
+
+local/.login
+	Commented out the code which sets FLOAT_OPTION, since the compilers
+	give errors if this is set to 'sparc', even on a sparc cpu (this is
+	inconsistent).  (9/27)
+
+unix/hlib/cl.csh
+	Added support for machine type 'sparc'.  (9/27)
+
+cd $iraf
+mkpkg >& spool &
+	Tried to do a sysgen of the full system.  This died on the very first
+	file, with rpp.e going into an infinite loop.  This was traced to an
+	optimizer bug in rpp.e, see below.  (9/27)
+
+unix/boot/spp/rpp/mkpkg.sh
+	Added some code to compile rpp/rppfor/outch.f without optimization,
+	to work around an optimizer bug which would cause an infinite loop.
+	(9/27)
+
+cd $iraf
+mkpkg >& spool &
+	Successfully started up a sysgen of the full system and went home
+	for the day.  (9/27)
+
+unix/hlib/mkpkg.sf
+	When I checked the next day, the sysgen was hung in an infinite loop
+	in the optimizer (iropt), trying to compile pkg$lists/unique.x.
+	Added an entry with flags "-cq -P" to the special file list, allowing
+	the file to be compiled.  Checking back over the spooled output,
+	I found that the only other file giving problems was pkg$cl/ytab.c,
+	which produced the following error message when compiled:
+
+	    Routine  _yyparse  too big: 
+		use a lower level of optimization or 
+		increase stack limit and / or 
+		size of swap space 
+
+	    compiler(iropt) error:	alloca: out of memory 
+
+	This was due to the static control flow analysis perfomed by the 
+	fancy new 3 level C code optimizer that comes with the Sun-4.
+	The yyparse routine (the parser) in the CL is a very large function,
+	and it is not surprising that it overflows something.  In this case
+	the runtime data structures required for the static flow analysis
+	exceeded something like 10 Mb (!), causing the compiler to run out
+	of memory.  Added the file to the special file list with the flags
+	"-cq -/O2" (the default -O gives -O3 or third level optimization).
+	(9/28)
+
+-------------------
+With these changes, the sysgen completed normally.  Some brief testing showed
+that x_system.e would run stand alone, but the CL would die on a bus error.
+Some interesting comparisons of object and executable sizes:
+
+                                BSD(11/750)     Sun-3      Sun-4
+                du -s bin          17345        16801      20593
+                du -s lib           3234         2932       3787
+
+	Hence, it turns out that the binaries for the Sun-4 with its RISC cpu 
+	are not that much larger than for the CISC machines, after all.
+	The slighly larger disk file size of the BSD VAX compared to the Sun-3
+	was due to the symbol table in the (unstripped) executables being
+	larger for BSD than for the Sun.  (9/28)
+
+sys/etc/envreset.x
+	The bus error in the CL turned out to be due to a short being passed
+	as an int in a procedure call in the above routine.  It took me a
+	while to figure this out, due to the time required to learn to use
+	ADB on a RISC machine.  Most of this was just becoming familiar with
+	the machine architecture, but it is a bit harder to match the
+	assembler up with the high level code on a RISC machine, due to the
+	many similar looking simple little instructions, and the heavy
+	optimization performed by the compiler.  A lot of little ADB things
+	are different - the register set in the sparc architecture is like
+	nothing you have ever seen before, the pipelining is visible (the
+	instruction after a branch or function call is always executed
+	even if the branch is taken, and is shown AFTER the branch!),
+	the arguments to a procedure seem to be always passed in registers
+	(haven't tried any procedures with very long argument lists yet),
+	so on.  One interesting discovery was that there are no MUL and DIV
+	instructions in the RISC cpu!.  These are implemented as subroutines,
+	but seem to be pretty fast nonetheless (but about 6 times slower than
+	an add).  (9/28)
+
+	[With this change the CL now comes up fine, and all the little system
+	[things I tried work.  zdojmp/zsvjmp are not working correctly in
+	[the CL, although they worked fine in a C test program I wrote, and
+	[they work fine in x_system.e run stand alone.]
+
+unix/hlib/libc/setjmp.h
+	Added a "#pragma unknown_control_flow", #ifdef-ed for the sparc.
+	This is necessary to tell the C optimizer that any routine which calls
+	setjmp (zsvjmp_) may trash the registers or do other strange things.
+	This was the cause of the zsvjmp failure in the CL (C) code.  (9/29)
+
+dev/help.db
+	Rebuilt the help datbase - all is well.  (9/29)
+
+----------------------------
+A little further testing immediately shows further problems, although a lot
+of stuff is working correctly now.  We still have a very buggy system here.
+Did not get much time to work on this today.  (9/29)
+
+pkg/cl/unop.c
+pkg/cl/binop.c
+pkg/cl/opcodes.c
+	The problem with the CL getting confused about whether certain files
+	existed or not turned out to be due to another IRAF bug, rather than
+	a Sun bug.  The problem was the macro VALU(o) in the CL.  This checks
+	the operand type and conditionally accesses and returns either the
+	integer or real value.  This was being used to fetch the value of a
+	boolean operand, and it was natural for the code to assume that VALU
+	would return an integer value for a boolean operand.  Not so, however.
+	The datatype of the conditional expression used in this macro is
+	evaluated at compile time, hence is double rather than int, and the
+	CL was doing boolean operations on double floating quantities.
+
+	This has gone undetected up until now, but for some reason zero values
+	were testing not zero-floating on the sparc cpu.  Integer 0 was being
+	loaded into a floating register, and the floating result after a
+	convert integer to double instruction was a very small floating point
+	number (exponent -212), with value exactly 0 when printing the binary
+	floating number in hex.  Evidently binary zero is not the same as
+	floating zero on this cpu.  (9/30)
+
+----------------------------
+Did a new sysgen to relink all executables to pick up bug fixes.
+Things seem to be working pretty well now.  Known problems:
+
+	Contour dies on a segmentation violation every time,
+	    and ERROR RECOVER IS NOT WORKING (the latter is true
+	    on all systems I think, and must be due to a bug in
+	    this program)
+
+local/sun
+local/sun/Makefile
+	Deleted this code and replaced by the new (3.4) version from tucana.
+	Rebuilt suntools.e.  This died on the first attempt due to a symbol
+	CPUTYPE=-mc68010 in the Makefile that came with the suntools code
+	from Sun, on the Sun-4!  Modified the Makefile in local/sun to call
+	the suntool Makefile with CPUTYPE="", and suntools.e was built
+	successfully.  (9/30)
+
+cd $hlib
+install
+	Installed the custom suntools software.  This has not yet been tested,
+	since I am working remotely.  (9/30)
+
+
+Begin IRAF Installation on ORION (NOAO/Tucson Sun-4)
+SunOS Release Sys4BETA1 (ORION) #1: Fri Oct 23 13:09:29 PDT 1987
+----------------------------------------------------------------
+
+Did a little UNIX level configuring, as orion only just came up:
+	Replaced termcap by tucana version.
+	Replaced /etc/group by tucana version.
+	Created /usr/local; someone else installed sources; I compiled and
+	    installed sps, man, less, etc.
+	NOTE: the f77 compiler is back-ordered, so we nabbed the GAMMA
+	    release compiler from hercules, until ours comes in.
+
+Created directory on /usr, read in V2.6 export version from lyra (same as
+	prepared for the Convex Port).
+
+Configured Sun-3 kernel from tucana for the Sun-4:
+	Made as a link to as.sparc.
+	Replaced mkpkg.inc and mkpkg.sf by the Sun-4 versions.
+	Uncommented #pragma in hlib/libc/setjmp.h.
+	Fixed a bug in boot/spp/rpp/mkpkg.sh (mach -> `mach`).
+
+Booted the system successfully.
+Started a full sysgen and went home.  (10/23)
+
+Examine spooled output from Sysgen (10/24):
+--------------------------------------------
+
+sys/fmtio/evexpr.x
+	Failed with the message:
+	    f77: Fatal error in iropt: Segmentation fault (core dumped)
+	But it compiled just fine when I ran mkpkg on the directory. (??)
+
+noao/onedspec/sensfunc/mkpkg
+noao/onedspec/sensfunc/sfgraphs.x
+	Deleted the junk file (zero length) sfgraphs.x, and its entry in
+	the mkpkg file list.  (10/24)
+
+local/tasks
+	There was a problem here caused by my forgetting to delete the binaries
+	when I moved the Sun/IRAF version of local over from tucana.  (10/24)
+
+local/sun/mksuntools.csh
+	Contained the statement "rm -rf *", used to delete the old 'suntool'
+	subdirectory before building a new one.  If the directory already
+	happended to be empty, this would cause rm to return an error exit
+	status, causing the script to terminate prematurely.  The suntools
+	executable would appear to be built correctly, but gterm and imtool
+	would not run.  (10/24)
+
+unix/hlib/mkpkg.sf
+unix/hlib/libc/setjmp.h
+	Had problems with register allocation again in the CL main, where
+	setjmp (ZSVJMP) is used.  Unlike the case with the gamma release,
+	the #pragmas in <libc/setjmp.h> did not fix things this time, so I
+	had to add the affected files to the special file list to be
+	compiled with no optimization.  (10/24)
+
+unix/hlib/mkpkg.inc
+unix/hlib/mkpkg.sf.SUN3
+unix/hlib/mkpkg.sf.SUN4
+	Replaced mkpkg.sf by two versions, one each for the Sun-3 and Sun-4.
+	The one to be used is conditionally loaded via a $ifeq statement in
+	the mkpkg.inc file.  (10/24)
+
+local/sun/imtool.c
+	There is a bug in the C library SCANF routines: scanning a perfectly
+	legal input string with a format such as "%f%f%f..." results in the
+	scan terminating after processing only the first floating point number.
+	I had to rewrite a section of code in IMTOOL to use the lower level
+	ATOF conversion routine to read the wcs file.  (10/25)
+
+	[The above was due to us getting a BETA release of the OS, and went
+	[away when we got the GAMMA release.]
diff --git a/doc/ports/sun_f77bugs.doc b/doc/ports/sun_f77bugs.doc
new file mode 100644
index 00000000..e4a39469
--- /dev/null
+++ b/doc/ports/sun_f77bugs.doc
@@ -0,0 +1,15 @@
+Different problems were encountered in both Sun-2's and Sun-3's
+with the f77 compiler.  On the Sun-2, the problems were in the
+optimizer.  See the "sun2*.doc" files for documentation on which
+IRAF source files generated compile-time and run-time problems.
+
+On the Sun-3, the worst problem was that Sun forgot about complex
+datatypes after Sun V2.0.  See the notes in the "sun3*.doc" files.
+Sun still (June 24) has not solved the problem, but Doug Tody came
+up with workarounds; look for the string "kludge" in "sun3_042586.doc"
+and in the directory $iraf/unix/hlib/SUN_kludge/.
+
+There were also three IRAF source files that generated run-time
+errors on the Sun-3 due to bugs in the "-f68881" version of the f77
+optimizer; these files are documented in "sun3_f77Obugs.doc".
+
diff --git a/doc/ports/unix.isi b/doc/ports/unix.isi
new file mode 100644
index 00000000..a45b8c9c
--- /dev/null
+++ b/doc/ports/unix.isi
@@ -0,0 +1,87 @@
+From rooke Thu Feb 27 11:35:41 1986
+Received: by lyra.noao.UUCP (4.12/4.7)
+	id AA06429; Thu, 27 Feb 86 11:35:35 mst
+Date: Thu, 27 Feb 86 11:35:35 mst
+From: rooke (Steve Rooke)
+Message-Id: <8602271835.AA06429@lyra.noao.UUCP>
+To: tody
+Subject: Ebert's mail
+Status: R
+
+>From ipac3!rick Wed Feb 26 19:35:54 1986
+Received: from noao.UUCP (carina) by lyra.noao.UUCP (4.12/4.7)
+	id AA03007; Wed, 26 Feb 86 19:35:50 mst
+Received: by noao.UUCP (4.12/4.7)
+	id AA27537; Wed, 26 Feb 86 19:36:52 mst
+Received: by ipac3.ARPA (4.12/4.7)
+	id AA10161; Wed, 26 Feb 86 18:32:49 pst
+Date: Wed, 26 Feb 86 18:32:49 pst
+From: ipac3!rick (Rick Ebert)
+Message-Id: <8602270232.AA10161@ipac3.ARPA>
+To: rooke@noao
+Subject: IRAF @ IPAC    [up]
+Cc: noao\!tody
+Status: RO
+
+Steve,
+
+The news is mostly good:  IRAF is up at IPAC!  The blessed event
+occurred at 11:44:46 PST on 26 Feb.  The new addition weighed in at
+a little over 46Mb.
+
+All of our trouble seems to have been related to an obstinate fortran
+optimizer.  Once I figured out how to turn off that -O flag everywhere
+in IRAF's mkpkg, it all fell into place. (As promised, a list of
+files that gave our optimizer indigestion follows, but I'm convinced
+the problem is with some northern California compiler writers and not
+with IRAF.)
+
+I did run into a problem quite quickly though.  I managed to make the
+help data base by doing this:
+
+cl> softools
+so> mkhelpdb
+
+IRAF proceeded to produce lots of stuff.
+With many of the "help" requests that I tried the formatted manual
+page printed on the screen as expected, followed by a listing of
+what appeared to an unformatted copy of the same help file (there
+were lots of .xx commands at the beginning of lines).  Once this
+starts to print out, a response of "n" to "More?" causes the whole
+of iraf to crash.  If I coax it with an interupt I receive the message,
+
+ERROR: subprocess is hung: process should be killed
+
+wait several seconds and interupt again, then I'm back in the csh
+(this is probably our unix doing houskeeping).
+
+Not a very well documented bug, but I wanted to get it to you
+right away.  The "help" is all I have to learn IRAF! (Sob, poor me).
+
+Rick Ebert, Infrared Processing and Analysis Center (IPAC)
+Cal Tech   MS 100/22, Pasadena, CA 91125
+
+Ma Bell: 818-584-2963 (MWF)
+UUCP: ipac3!rick
+
+"Problem" files:
+
+./sys/fio/fwtacc.x
+./pkg/system/help/helpdb.x
+./pkg/system/help/prfile.x
+./pkg/system/directory.x
+./pkg/system/isdir.x
+./pkg/onedspec/identify/isdir.x
+./pkg/system/lprint.x
+./pkg/system/page.x
+./pkg/xtools/isdirectory.x
+./pkg/dataio/imtext/rt_rwpix.x
+./pkg/dataio/cyber/rrcopy/rc_rheader.x
+./pkg/dataio/cyber/rrcopy/read_rcopy.x
+./pkg/dataio/cyber/t_ridsfile.x
+./pkg/dataio/cyber/read_dumpf.x
+./pkg/dataio/cyber/read_pft.x
+./pkg/images/geometry/geogmap.x
+------that-is-all---------------------
+
+
diff --git a/doc/ports/vms_jan85.st b/doc/ports/vms_jan85.st
new file mode 100644
index 00000000..3ad46793
--- /dev/null
+++ b/doc/ports/vms_jan85.st
@@ -0,0 +1,994 @@
+Notes file for VMS/IRAF V2.2 Installation
+Beginning 16 January 1985 (code prepared on UNIX)
+------------------------------------------------
+
+vms/*
+	Moved unix/* to vms/*.  (1/16)
+
+vms/os/*
+	Moved the current VMS kernel into host$os.  (1/16)
+
+vms/os/mkpkg
+	Wrote mkpkg file for OS.  (1/16)
+
+vms/as/*.s
+	Replaced all these assembler files by their VMS equivalents.  Deleted
+	all the arithmetic VOPS machine files, as they are not worth it on 
+	VMS (probably not worth it any more on UNIX, either).  Wrote the new
+	routine ACLR.S for VMS.  (1/17)
+
+vms/os/zsvjmp.s
+	Moved to AS. (1/17)
+
+vms/os/str.s
+	Added _strupk, _strpak, since the VMS kernel references these
+	internally, they need to be in LIBOS.  Added the underscore to avoid
+	conflict with the OSB (C) versions used by the VOS.  I know it seems
+	wasteful to duplicate essentially the same routine in different parts
+	of the system, but the subsystem interfaces must be respected.  The
+	alternative is to add the routines to the kernel, but this involves
+	an expensive interface modification, and I don't think its worth it
+	for such trivial little routines.  (1/17)
+
+vms/os/zfiotx.c
+vms/os/zfioty.c
+vms/os/zfrnam.c
+	Changed references to strpak, strupk to _strpak, _strupk.  (1/17)
+
+vms/hlib/*
+	Set up the HLIB directory.  This involved minor edits to config.h,
+	clpackage.cl, etc., and most of the .cl scripts therein.  Moved in
+	all the .com files from the original "vms" directory from V2.0 of
+	VMS/IRAF.  Added logical names for TMP and HOST to irafuser.com,
+	also logical names for MKPKG, RMBIN, etc.  (1/18)
+
+vms/hlib/libc/iraf.h
+	Modified for VMS.  The remaining files are now the same for both
+	UNIX/IRAF and VMS/IRAF.  (1/18)
+
+vms/boot/bootlib/*
+	Minor changes for VMS.  (1/19-20)
+
+vms/boot/generic/*
+	Minor changes for VMS.  (1/20)
+
+vms/boot/mkpkg/*
+	Fairly extensive changes for VMS.  Picked up the SCANLIB code from
+	the old VMS mkpkg; for the rest (mkpkg/host.c) I just modified the
+	new UNIX code as necessary for VMS.  Still using the docvcl() stuff
+	to call XC, which is a kludge, but presumably it helps cut down on
+	process spawns.  (1/20-21)
+
+vms/boot/mkpkg/scanlib.c,rec.c
+	Had second thoughts about this code.  A full but null sysgen must be
+	incredibly slow on anything less than an 8600, since the old vms mklib
+	would physically open and read each file to map an object file name
+	into an object module name to get a date.  Even on the 8600 it is
+	probably an order of magnitude slower than the new MKPKG on the UNIX
+	750.  Opening the source files with the C i/o can also change the file
+	modify dates, and the modify date is valuable information which I hate
+	to lose.
+
+	To avoid this dreadful situation, I have decided to not use the VMS
+	librarian at all to track object module dates.  Instead, for each
+	library there is an associated module date database file, e.g.,
+	libsys.mlb for libsys.olb.  This is updated by MKPKG when
+	objects are inserted into the library.  If modules are replaced in
+	the library at the VMS level, MKPKG will simply recompile those
+	modules when eventually it is run (unless a utility program is run
+	to update the .mlb dates).  But since the new MKPKG is such a screamer
+	anyhow, there is no need to use REPLACE.COM, or whatever, to update
+	modules in libraries - and the thing is dangerous anyhow (it is easy
+	to put the module in the wrong library, for example).
+
+	This approach has the further advantage that the technique and the
+	code are both portable and can be reused on other systems that, like
+	VMS, do not manage libraries the way we would like.  (1/21)
+
+vms/boot/rmbin
+vms/boot/rtar
+vms/boot/wtar
+	No changes for VMS, other than to replace the mkpkg.csh by a mkpkg.com.
+	(1/22)
+
+vms/boot/xyacc
+	Not supported on VMS.  (1/22)
+
+vms/boot/spp/[...]
+	Some work was required here for VMS.  The VMS version of RATLIBC was
+	picked up wholesale, but the UNIX versions of RATLIB[RF], RPPRAT, and
+	RPPFOR were used without change (these contain recent revisions which
+	were documented elsewhere).  The VMS version of SPP.C was used (it
+	does more), but the UNIX versions XPPMAIN.C, XPPCODE.C, and DECL.c
+	were used, since they should be portable, now address all of the
+	issues dealt with in the VMS versions, and have recent revisions.
+	The VMS version of XC.C was used with very minor revisions.  DCL.C
+	(the special ZOSCMD) was moved to BOOTLIB and hooked into os_cmd().
+
+	To summarize, the VMS versions of XC.C, RPP.C, and RATLIBC were used
+	with minor changes since they have been extensively modified for VMS.
+	The UNIX versions of the remaining files were used since they should
+	work for VMS, and it is desirable to minimize the differences between
+	the two versions to ease future merges.
+
+	A DCL mkpkg.com was written for each directory under SPP.  These are
+	for bootstrap purposes and will always recompile everything.  It is
+	assumed that some version of LIBSYS and LIBVOPS is available for
+	filename mapping purposes.  (1/22)
+
+vms/os/zfiomt.c
+	Removed the device table stuff, since the drive argument to ZZOPMT
+	is now the VMS device name.  Density checking is performed at allocate
+	time by the VOS.  It appears that the density is not being set
+	anywhere.  (1/22)
+
+vms/os/zalloc.c +
+vms/os/cltape.c -
+vms/os/devtable.c -
+	Added the two new kernel routines ZDVALL and ZDVOWN, in the file
+	zalloc.c.  They were easy to generate as the original cltape.c code
+	was quite well structured.  Deleted the files cltape.c and devtable.c
+	since they are no longer used.  (1/22)
+
+-------------------------------------------
+That completes the coding modifications for VMS/IRAF, done on UNIX.
+System moved to VMS for compile test beginning the 23rd.  (1/22)
+
+(edited the mkpkg.coms, fixed compile time bugs, not worth recording here)
+
+vms/boot/generic/lexyy.c
+	Made the same changes for VMS as were made for the Lex/C output of
+	xpp.l.  Should add editor script in UNIX version to make these
+	changes whenever lexyy.c is generated.  (1/23)
+
+vms/os/zfnbrk.x
+vms/os/zfxdir.x
+vms/os/zfpath.x
+vms/os/zfsubd.x
+	Replaced these SPP source files by equivalent C versions, to simplify
+	bootstrapping the system.  It is just as easy to work on XCHAR arrays
+	in a C program as char arrays, hence there is no advantage to using
+	SPP for these routines.  (1/23)
+
+TODO
+	Note - ZFNBRK differs from the UNIX version in that it ignores \ in
+	filenames (rather than interpreting them as directory delimiters).
+	Should merge back into UNIX version, too.  (1/23)
+
+vms/boot/bootlib/osfn2vfn.c
+vms/boot/bootlib/vfn2osfn.c
+	Added #undefs for fprintf, strcpy to cancel out the defines in libc.h.
+	(1/23)
+
+vms/hlib/libc/xnames.h
+vms/hlib/libc/xnames.no_
+	Added a define for VFNUNMAP.  (1/23)
+
+vms/os/zzstrt.c
+vms/hlib/libc/knames.h
+vms/hlib/libc/knames.no_
+	Discovered that the VMS kernel does not have the entry points _zstartup
+	and _zshutdown.  These are used in programs that do not have a ZMAIN.
+	They are currently no-ops in both UNIX and VMS, but in general it sure
+	seems that they might be needed; the bootstrap utilities would not
+	link because the routines were missing.  If we are going to have them
+	they should be Fortran callable too, so I changed the names to ZZSTRT
+	and ZZSTOP and added them to the VMS kernel (as no-ops).  (1/23)
+
+vms/boot/*
+	Replaced all references to _zstartup and _zshutdown by references to
+	ZZSTRT and ZZSTOP.  (1/23)
+
+vms/boot/rtar/rtar.c
+	Declared getblock() at the head of the file and deleted the local
+	definitions in each procedure.  (1/23)
+
+vms/hlib/libc/xnames.h
+vms/hlib/libc/xnames.no_
+vms/boot/bootlib/vfn2osfn.c
+vms/boot/bootlib/envinit.c
+	Use of the VOS for filename mapping requires initialization of the
+	iraf environment table.  VFN2OSFN will now initialize the env. table
+	the first time it is called, taking SET declarations from the
+	zzsetenv.def file in hlib.  Added a define for ENVINIT to xnames.h
+	to initialize the env data structures; ENVPUTS is called to make
+	entries in the table.  The bootlib init procedure is _envinit(). (1/23)
+
+vms/boot/bootlib/osfpathname.c
+	Added call to vfn2osfn() before call to ZFPATH.  (1/23)
+
+vms/boot/bootlib/oschdir.c
+	Replaced call to os_fpathname() by call to ZFSUBD, since the former
+	produces an OS filename rather than an OS directory name, and VMS
+	insists on the latter.  (1/23)
+
+vms/boot/hlib/libc/spp.h
+	Added a definition OSOK to spp.h.  This is the value a foreign task
+	should return for normal successful completion, i.e., 0 for UNIX,
+	and 1 for VMS.  (1/23)
+
+vms/boot/mkpkg/host.c
+vms/boot/mkpkg/modlist.c
+vms/boot/bootlib/*.c
+	Lots of changes to the system interface code to get MKPKG to work
+	properly on VMS.  (1/23-24)
+
+vms/boot/bootlib/osdir.c
+	This code was rewritten to vfnopen the directory at diropen time
+	for efficiency reasons.  Debugged the VOS filename mapping interface.
+	RMBIN was used to test the OSDIR code.  (1/24)
+
+vms/boot/hlib/libc/libc.h
+	Added a #ifdef to turn off LIBC name redefinitions, for programs like
+	the bootstrap utilities which need to import_libc, but which want to
+	use the host system strcpy, printf, etc.  (1/24)
+
+vms/boot/rtar.c
+vms/os/zfiotx.c
+	I had a binary file on a supposedly text only tar tape.  The file would
+	pass the ZFACSS test and appear to be a text file.  RTAR would try to
+	use ZFIOTX to write the output file; the result was an access violation
+	in ZPUTTX, presumably because of the binary data. (1/24)
+
+	[not yet resolved]
+
+vms/boot/rmbin				[!!! NASTY BUG !!!]
+vms/os/zfdele.c
+	Ran into an interesting problem with RMBIN.  This task reads through
+	a directory, deleting any binary files found.  The problem is that on
+	VMS, while the directory is open for reading, one cannot delete any
+	files in the directory because the directory file is locked.  Not only
+	does this make RMBIN fail, it will also make a regular file delete,
+	create, rename, etc., fail, if the request is issued while another
+	process is reading from the directory!!!  This means that bkg jobs
+	will mysteriously bomb out at random intervals on a file error. (1/24)
+
+	[not yet resolved]
+
+sys/mkpkg
+	Added a $purge lib$ to the end of the sysgen section (after updating
+	all the system libraries).  This will purge all the old versions of
+	the libraries after a sysgen.  In the first attempt at a full sysgen
+	on the 24th, MKPKG went into a loop and filled up a disk, creating
+	43 versions of each system library!  (1/25)
+
+sys/mkpkg/pkg.c
+	The MKPKG loop mentioned earlier turned out to be due to a bug in the
+	VMS C stdio.  FTELL returns the offset of the current record, rather
+	than the offset of the next record as the documentation states (and as
+	is necessary for UNIX compatibility).  MKPKG would therefore repeat
+	the last command after pushing (ftell) and restoring (fseek) its state
+	to call a lower level module.  This explains the problem, but does not
+	explain how it ever worked as well as it did in the first trial; we
+	may not know the whole story yet.
+
+	No choice but to add an #ifdef vms to pop_context() in pkg.c to skip
+	forward one line after an FSEEK.  (1/25)
+
+vms/os/net/kutil.c
+	Eliminated the reference to the macro define IRAFDIR, which has been
+	deleted.  (1/25)
+
+vms/mkpkg
+	Added a call at the end to MKPKG to update LIBOS, since the bootstrap
+	does not get the networking stuff.  (1/25)
+
+sys/libc/cfnames.c -
+	Deleted this file, which was apparently forgotten about after the
+	contents were unpacked into separate files.  (1/25)
+
+vms/boot/mkpkg/pkg.c
+	As expected, the FTELL/FSEEK problem has not yet been resolved.  After
+	running tests for several hours, most of which worked, I was unable to
+	isolate the problem.  Simple little test programs always work correctly
+	(i.e., they always seek to the wrong line).  I was able to determine
+	that when it fails it is because FTELL returns the wrong offset.  It is
+	conceivable that MKPKG could be corrupting a stdio data structure, but
+	I doubt it.  More likely there is a bug in the VMS FTELL.
+
+	The next attempt at a workaround is to avoid the use of FTELL entirely
+	for VMS.  Instead, I wrote a little package k_getc, k_fgets, k_ftell,
+	k_fseek.  The getc counts characters, the ftell returns the char
+	offset, and the fseek rewinds the bloody file and reads so many
+	characters to get to the seek position.  With this change, "mkpkg -n"
+	was able to traverse the system successfully.  This code could be
+	useful on any system, so I will leave it in with a switch; there is
+	little effect on speed.  (1/25)
+
+vms/os/zfiotx.c
+	It appears that the RTAR crash when writing binary data into a text
+	file was due to the lack of overflow checking in ZPUTTX.  Added
+	overflow checking.  (1/25)
+
+------------
+Started a full sysgen on 25 January.  This ran to completion, uncovering the
+usual assortment of compile time bugs not found on UNIX/IRAF.
+
+NOTE TO VMS/IRAF PROGRAMMERS
+	To relink a package executable for debugging on VMS, enter the
+	following command to relink with the "-x" flag:
+
+		mkpkg lflags=-x
+
+	For most packages, this will produce a debug version of x_test.e in
+	the local directory.  The user package in the IRAF login.cl file
+	defines a foreign task "mkdebug" to make this easier:
+
+		task $mkdebug = "$mkpkg lflags=-x"
+
+	After debugging is complete, the following command will relink and
+	install a new executable:
+
+		mkpkg update
+
+	Alternatively, you can always type in a long "xc -x ..." command.
+	DCL .com files should not be used in the SYS or PKG directories.
+
+sys/mkpkg
+	Made compilation of libmain.o optional, under control of a switch in
+	hlib$mkpkg.inc.  The VMS XC does not need a separate object module,
+	hence it is turned off for VMS.  LIBMAIN is a prelinked object module
+	on UNIX, and will eventually be the sharable library on VMS, once we
+	figure out how to have MKPKG udpated during a sysgen.  (1/26)
+
+vms/hlib/libcalcomp.a			[SITE DEPENDENT]
+	Copied the VMS version of this library into HLIB.  The source for the
+	library is local and is not part of IRAF.  To link with this library,
+	one must reference the C runtime library CRTLIB.OLB in their login.com
+	file.  Other sites may have a different version of the calcomp library,
+	or the Versaplot library, any of which will probably do as well for
+	the GIO calcomp kernel.  (1/26)
+
+math/llsq/sva.for
+	On lines 179, 181, the comma at the end of the line was in column 73,
+	hence VMS/FORTRAN would ignore it.  Moved to column 7 of the first
+	continuation line.  (1/26)
+
+pkg/dataio/idsmtn/bswap6.c
+	Changed the  [include "iraf.h"]  to  [include <iraf.h>].  (1/26)
+
+pkg/images/geometry/geotran.x
+	On line 531, changed a couple of '0's to '0.'s in calls to the intrinsic
+	function MAX (argument type mismatch).  (1/26)
+
+pkg/local/mkpkg
+	Disabled the PERITEK code on VMS.  This is a local, UNIX dependent pkg 
+	(written by a staff astronomer) not intended for use outside of NOAO.
+	Will compile now only if site=noao and hostid=unix.  (1/26)
+
+pkg/local/intrp.f
+	Near the end of file, contained a line that extended way beyond col 72.
+	Detabbed the file and made extra continuation for the long line.  Has
+	already been updated on UNIX/IRAF (where I did the detab).  (1/26)
+
+pkg/onedspec/identify/idpeak.x
+	Argument type mismatch in call to max().  (1/26)
+
+pkg/twodspec/longslit/transform/trtransform.x
+	Several array arguments were dimensioned using variables NX,NY defined
+	in COMMON.  Changed to ARB to get it to compile (the original is not
+	legal Fortran), but passing the array dimensions via common is a more
+	serious problem.  (1/26)
+
+pkg/utilities/t_polyfit.x
+pkg/utilities/pfregres.f +
+	The polyfit task called the Bevington procedure REGRES which implicitly
+	called a function with the explicit external name FCTN.  The source
+	for FCTN was provided with that for the polyfit task, but the VMS
+	librarian would store it in a separate library object module.  Hence,
+	at link time REGRES causes a backwards reference to FCTN in the package
+	library, but since that library had already been searched the module
+	would not be found and the link would fail.
+
+	This could be solved by moving FCTN into a separate object file not
+	in the package library, and linking it explicitly by name.  Instead,
+	I copied the source for REGRES into the local file pfregres.f, and
+	added a reference to FCTN (renamed pf_fctn) in the pf_regres argument
+	list as an external.  The real problem here is the Bevington library,
+	a simple instructional tool which was never intended to be used in an
+	application such as ours.  Coupling to the outside world via a reserved
+	external name (FCTN) is as bad as common coupling.  In both cases the
+	information should come into the procedure in an obvious way via the
+	argument list.  (1/26)
+
+	The new code should be tested.
+
+pkg/imred/vtel/readvt.x
+	Assignment to DO variable `subswath' within loop.  Recoded to use a
+	FOR loop.  (1/26)
+
+pkg/mkpkg
+	Added a "purge [...]" at the end, to be executed only on a vms host.
+	(1/26)
+
+-------------
+(End of compile time bug fixes)
+(All of the above files where also updated in UNIX/IRAF, so that the PKG
+(sources are still identical in both systems).
+
+
+pkg/cl/opcodes.c	[+  globaldef]
+pkg/cl/globals.c	[+  globaldef]
+pkg/cl/main.c		[+2 globalref]
+	I was forced to add #ifdef vms globaldef, globalref nonsense to these
+	files to enable a standard XC call to link the CL.  I suspect that
+	linking C data-only modules will be a problem on other systems as well;
+	in the future, we may want to outlaw data only modules in portable C
+	code.  (1/26)
+
+(With this last fix, the new system is fully up and seems to be running
+(fine, performing all basic functions normally).
+
+dev/devices
+	Edited for VMS.  Decided to use the third field ("aliases" for UNIX)
+	to pass the density at device allocation time.  For VMS it appears
+	the density must be set at ALLOCATE (mount) time.  (1/26)
+
+vms/hlib/devstatus.cl
+	Edited for VMS.   After printing the IRAF status (which is obtained
+	by a direct inquiry to VMS, not by just looking for a lock file),
+	devstatus will scan the device table dev$devices and do a
+	"!show devices/full device" to print the VMS info.  (1/26)
+
+pkg/cl/scan.c
+	Would only skip blanks between the tokens; will now skip both spaces
+	and tabs.  (1/26)
+
+vms/boot/spp/xc.c
+	Modified to actually create a shareable image with no traceback when
+	the -n flag is specified (it was a no-op before).  Doesn't seem very
+	useful yet (the resultant image cannot be executed or installed),
+	but it will be useful for testing purposes.  (1/26)
+
+vms/hlib/devstatus.cl
+	Added a boolean param verbose, default no, controlling whether the
+	SHOW DEV info is printed.  Since the IRAF device status now comes
+	from VMS, we no longer need the VMS output, and it is a lot faster
+	without it.  (1/26)
+
+vms/hlib/login.cl
+	Added a default NOAO USER package to the default login.cl.  This serves
+	as a starter package for each user to modify as they wish.  Each site
+	will wish to set up their own default package.  (1/27)
+
+vms/os/open.c
+	Modified to provide shared access to files opened for reading, to
+	avoid the locked directory problem mentioned earlier.  (1/27)
+
+sys/etc/syserr.x
+	In syserrs, added a check for overflow on the error message string.
+	These messages do not necessarily come from <syserrmsg>, and can be
+	quite long.  (1/27)
+
+sys/ki/kiconnect.x
+	Added a call to ki_gethosts() if the node table has not yet been
+	read.  There are circumstances (although unusual) in which ki_connect
+	can be called before the node table has been read, causing the system
+	to try to open the resource on the local node.  (1/27)
+
+(All these bugs I am fixing have been in the system for some time, they
+(are not new with this release...)
+
+vms/os/zmain.c
+vms/os/zfiopr.c
+	Added support for monitoring IPC messages a run time, a useful tool
+	for debugging connected subprocesses.  To enable logging of IPC
+	communications for a process, the programmer runs the VMS PATCH
+	facility to set the value of the global variable debug_ipc to 1.
+	The process must first be linked -x (or -M) to get the address of
+	the variable debug_ipc.
+
+		cl> mkdebug
+		cl> adb x_test
+		DBG> ev debug_ipc
+		1D58
+		DBG> exit
+		cl> !patch x_pkg
+		PATCH> deposit 1d58=1
+		PATCH> update
+		PATCH> exit
+
+	This is similar to the way one does this on UNIX.  (1/29)
+
+sys/fmtio/lexnum.x
+	Changed stk_ip[] from short to int.  (1/29)
+
+pkg/cl/builtin.c
+	Changed two instances of
+		
+		flags != LT_PFILE;
+	to
+		flags &= ~LT_PFILE; 	(1/29)
+
+sys/clio/zfiocl.x
+	There was some confusion between bytes and chars here, causing the
+	numstr[..] = EOS to overwrite the static "xfer" string, resulting in
+	the command "x(3,2044)" being sent to the CL.  This would cause
+	tasks which read from the standard input to fail.  (1/29)
+
+pkg/system/help/t_help.x
+	Added , to the stridxs search for pattern metacharacters, so that
+	commands like "help taska,taskb" do not stop after printing only the
+	first task.  (1/29)
+
+pkg/images/tv/display/imdopen.x
+pkg/images/tv/cv/iism70/imdopen.x
+	Added an include <knet.h>.  (1/29)
+
+vms/os/net/zfioks.c
+	Modified to not return a channel value of zero, which makes the KI
+	think the server has not been connected, even though it has.  (1/29)
+
+Proposed Changes based on recent Installation Experiences
+----------------------
+The following observations followed a trip to the Univ. of Wash. to install
+IRAF and interface the display software to the model 75 IIS.  This served
+as a test case to refine our installation procedures before the release.
+
+	- The quota requirements need to be better defined.  In this case
+	    the paging file quota was too small, and we had problems spawing
+	    connected subprocesses.
+	- Make the [iraf.local] directory a standard thing, to hold all
+	    local and VMS junk, e.g., login.com, test login.cl and uparm,
+	    notes file, sysbull.dat, etc. etc.
+	- Replace IMAGEDISK by a definition of the default image storage
+	    directory, which need not be a disk device.
+	- The symbol IRAF (used to load the logical names) collides with
+	    the iraf system login IRAF.  Mail cannot be sent to IRAF, it
+	    has to be sent to _IRAF, which is confusing to the user.
+	    Solution: use "IRAF" for the system login, [IRAF] for the
+	    root directory, and IRAFDEFS for the symbol which used to be
+	    called IRAF.
+	- Add a new subdirectory off the root called BIN, and install all
+	    the executables there.  Modify the CL to read the parameter
+	    files from the source directories for the package, rather than
+	    constraining the .par files to be in the same directory as the
+	    executable.
+	- Add a utility to strip the system of all sources, objects, and
+	    libraries not needed at runtime or for simple user software
+	    development applications.  All machines do not need to have
+	    a full copy of the system with all sources.
+	- We need to include NSPP/MCVAX in the distribution, so that people
+	    can get hardcopy on a Versatec or Printronix.
+
+(end of observations)
+-----------------------
+
+vms/gdev/zfiogd.x
+	Broke iism70, iism75 into two separate cases, calling two separate
+	sets of interface procedures for each device.  (2/5)
+
+vms/gdev/iism75/*
+	Added a new subdirectory IISM75 containing the interface procedures
+	for the Model 75 IIS.  This device was interfaced without any changes
+	at all to the existing high level code, which was written for the
+	Model 70.  Instead, the IISM75 procedures perform transformations on
+	the data stream to and from the physical device.  M70 output
+	instructions are converted to M75 format, and M75 responses are
+	converted to M70 format.  In effect, we have added software to convert
+	the model 75 back into a 70.  This makes it possible for us to modify
+	the complex high level software and test in on the model 70, with a
+	reasonable expectation that it will still work on the 75 as well. (2/5)
+
+vms/gdev/iism70/m70io.f
+	The .for QIO interface procedures in gdev/iism70 are used for both
+	the model 70 and 75 (probably they should be moved into a separate
+	directory).  The M70IO procedure would fail with the max transfer
+	size set to 32768 bytes.  This was traced to the following expression
+	in a QIO call:
+
+		%val(2*count)
+
+	Here, `count' is a short integer variable.  The result of the
+	expression is a long integer.  The Fortran compiler would do the
+	multiplication with short integer arithmetic and then convert the
+	result to long integer, causing the unsigned integer result to overflow
+	into the sign bit, causing sign extension and an invalid QIO request
+	resulting in a cryptic insufficient working set message from VMS.
+
+	The solution was to store count into a long integer temporary before
+	evaluating the expression.  Applying the INT intrinsic function to
+	COUNT had no effect.  Note also that one might assume that 2 is of
+	type "integer" and that the multiplication would be evaluated using
+	integer arithmetic, but that is not how this compiler does it.
+
+	After this modification, the interface still failed, no doubt due
+	to the same problem elsewhere in the interface; I did not persue the
+	matter any further.  I am documenting this carefully here because it
+	illustrates the danger of short integer arithmetic with the VMS
+	Fortran compiler, and anyone using such arithmetic must understand
+	in detail how such expressions are evaluated.  Short integer arithmetic
+	was used in this particular application only because I cribbed the
+	QIO level interface routines from somewhere else, and they were
+	written to be compiled /I2.  (2/5)
+
+pkg/images/tv/display/iisrcr.x
+	Added a 30 millisecond delay, so that cursor loop applications (e.g.,
+	to window the display) do not hog the cpu polling the system in an
+	infinite loop.  (2/5)
+
+dev/graphcap
+	Added an entry for the CIT-414a graphics terminal.  (2/5)
+
+sys/tty/mkpkg
+sys/tty/ttyclear.x
+sys/tty/ttyclln.x
+sys/tty/ttyctrl.x
+sys/tty/ttydelay.x
+sys/tty/ttygoto.x
+sys/tty/ttyputs.x
+sys/tty/ttywrite.x
+	In the process of developing a graphcap for the CIT-414a, I found
+	a problem with the TTY interface.  The interface was set up to
+	operate upon EOS delimited control strings.  This would prevent
+	inclusion of NULs in the control string (used to generate delays),
+	since the NUL would be interpreted as the EOS.  A new routine TTYWRITE
+	was added, and TTYPUTS was modified to call STRLEN and then TTYWRITE.
+	The remaining routines were modified to call TTYWRITE rather than
+	TTYPUTS.  I considered adding a notation to be used in control strings
+	to represent delays, but did not do so since the resultant TERMCAP
+	entries would no longer be compatible with UNIX TERMCAP.  Instead,
+	one must explicitly include the nulls as \0\0\0 in the control strings.
+	(2/5)
+
+sys/gio/stdgraph/stdgraph.h
+sys/gio/stdgraph/stgencode.x
+	Added a new operator !! to the stdgraph encoder, used to generate
+	millisecond delays by inserting NUL characters into the output text.
+	The delay in milliseconds is popped from the stack.  For example,
+	(#20!!) is a 20 millisecond delay.  (2/5)
+
+sys/gio/stdgraph/t_showcap.x
+	Modified to use the count returned by the encoder to find the end
+	of the output string, rather than assuming that the control string
+	is EOS delimited.  This is necessary because the string may contain
+	embedded NUL characters.  SHOWCAP will represent these as \0 in
+	diagnostic output.  (2/5)
+
+dev/graphcap
+	Made a pass through this and made minor revisions to bring the comments
+	up to date.  Deleted all the "old graphcap" stuff at the end of the
+	file, as the code which used it has all been deleted.  (2/6)
+
+vms/boot/mkpkg/host.c
+	Modified h_outcheck() ($checkout) to always check out the latest
+	version of a file, even if a local file already exists with the
+	same name as the file to be checked out (the old version is deleted
+	and a new version is checked out).  (2/6)
+
+vms/boot/mkpkg/tok.c
+	Added verbose messages to do_copyfile() and do_movefile().  (2/6)
+
+vms/os/zgtenv.c
+vms/hlib/libc/iraf.h
+sys$library:iraf.h
+	After having what appeared to be problems with the passing of logical
+	names to subprocesses spawned by batch queue jobs, I added the logical
+	name table lookup code from UNIX/IRAF to the VMS version of ZGTENV.
+	This code will fetch the values of the three essential logical names
+	IRAF, HOST, or TMP from the file <iraf.h> at runtime, if not found in
+	the VMS environment.  These logical names are currently defined as VMS
+	logical names in hlib$irafuser.com as well, but these values can be
+	deleted should it prove desirable, and the system will automatically
+	pick up the default values from <iraf.h>.  This is the way this works
+	on UNIX/IRAF too.  (2/6)
+
+vms/boot/boot/*		[UNRESOLVED]
+	This is a problem with the bootstrap utilities.  At present, these
+	work great when run interactively from either DCL or the CL.
+	Even background execution works, provided the subprocess type of
+	bkg job is used.  When run in a batch queue, however, my test case
+	(MKPKG) apparently completes successfully (an executable is linked),
+	but the spool file contains a DCL dump claiming that the MKPKG died
+	during startup because it could not find a file (it looks like the
+	hlib$zzsetenv.def file, but the RMS error message does not give the
+	file name).  No other output is produced.  I looked for a while but
+	could not figure out where the real output is going, or why this
+	apparently ficticious error output is being generated.  Since the
+	MKPKG job apparently completes normally, it must be something during
+	job termination, but I don't have time to look into this further
+	now.  (2/6)
+
+vms/os/net/zfioks.c
+vms/os/net/inet.h
+	Reduced the max transfer size to 32256.  A transfer size of 32768 or
+	larger causes the Wollongong network driver to crash VMS (this was
+	reported before, but the value checked for was still too large). (2/9)
+
+pkg/images/tv/display/iisopn.x
+	Added a strupk to unpack devinfo before calling ki_gnode.  (2/9)
+
+pkg/images/tv/display/zsttim.x
+	Added code to multiply the max buffer size by 2 if "packit" is set,
+	allowing twice as many pixels to be stored in the same space.  (2/9)
+
+vms/os/zgtenv.c
+	We don't want to use VMS logical names like "IRAF" and "TMP" because
+	problems are likely due to name collisions.  On the other hand, we
+	don't want to change the IRAF names.  The solution adopted was to
+	have ZGTENV, when asked to lookup NAME, look for IRAFNAME first.
+	This allows all logical names to be defined in irafuser.com with the
+	IRAF prefix.
+
+	The exact sequence of events followed by ZGTENV when a request for NAME
+	is received is the following:
+
+	    [1]	Look in VMS land for IRAFNAME.
+	    [2] If NAME is one of "IRAF", "HOST", or "TMP", the three host level
+		logical names required by the IRAF VOS, and the VMS lookup for
+		"IRAFIRAF", "IRAFHOST", or "IRAFTMP" failed, fetch the default
+		value from <iraf.h>.
+	    [3] Lastly, simply look in the VMS tables for NAME.
+
+vms/hlib/irafuser.com
+vms/hlib/mkiraf.com
+	Now defines the following machine dependent logical names:
+
+	    IRAFDISK		locates IRAF root at IRAFDISK:[IRAF]
+	    IRAFTMP		default TMP directory (public)
+
+	    fast,batch,slow	aliases for batch queues
+	    (SYS$NODE)		not needed for 4.X VMS.
+
+	The remaining definitions in irafuser.com are site independent.
+	The old logical IMDIRDISK has been replaced by IRAFTMP.  The latter
+	is needed in any case to define the IRAF "tmp$", and it was desirable
+	for the default image storage location to be a directory rather than a
+	disk.  MKIRAF was modified to create the default user IMDIR as a
+	subdirectory of the directory IRAFTMP.  The temporary logical names
+	IRAF, HOST, and TMP were replaced by IRAFIRAF, IRAFHOST, and IRAFTMP.
+	The logical names EDT and VI were replaced by IRAFEDT and IRAFVI,
+	under the assumption that code will be added to EDCAP to define what
+	name to pass to the host to run the editor.  It was annoying to have
+	an important symbol like VI used by IRAF, and always calling the
+	editor via the very slow @irafvi.com script.  (2/11)
+
+	TODO: add "host command" string to EDCAP, modify CL to use it.
+
+VMS Environment
+	This is a summary of the VMS environment configuration recommended
+	for IRAF.
+
+		IRAF			Symbol, loads irafuser.com
+		IRAFDISK		Logical name, disk iraf sources are on
+		IRAFTMP			Default public scratch directory
+
+		IRAFDISK:[IRAF]		Root directory of iraf on IRAFDISK
+		IRAFDISK:[IRAF.LOCAL]	Login directory for vms user "IRAF".
+
+	If no IMDIR is defined, the CL uses IRAFTMP.  The default IMDIR
+	created by MKIRAF is the subdirectory .USER] of IRAFTMP.  The system
+	should be installed under the login name IRAF.  IRAF related VMS
+	mail should be sent to user IRAF (no need to use _iraf).  (2/11)
+
+pkg/cl/builtin.c
+pkg/cl/edcap.c
+pkg/cl/globals.c
+pkg/cl/eparam.h
+	Added a new field EDITOR_CMD to the EDCAP database.  The "escape"
+	field contains the command to be sent to the host system to run the
+	editor.  The function HOST_EDITOR() accesses edcap and returns the
+	command string for the named editor.  (2/11)
+
+dev/edt.ed
+dev/emacs.ed
+dev/vi.ed
+	Added an EDITOR_CMD entry to each table file.  (2/11)
+
+vms/hlib/clpackage.cl
+vms/hlib/zzsetenv.def
+	Since the CL is an IRAF task run from the host, it reads the default
+	zzsetenv.def file during startup.  Since this file already defines
+	all the logical directories, I moved the remaining non CL specific
+	SET definitions from clpackage.cl to zzsetenv.def.  The clpackage.cl
+	file is now machine and site independent, and is one less file to
+	have to worry about during an installation.  Since the system package
+	is loaded during startup now, I also replaced the fscan stuff, used
+	to type the message of the day, by a call to PAGE.  (2/12)
+
+sys/ki/kishownet.x
+pkg/system/netstatus.x
+pkg/system/system.cl,x_system.x
+	Added function ki_shownet (outfd), used to print the network status.
+	Added a task NETSTATUS to the system package which simply calls the new
+	function and prints the network status as seen by x_system.e. (2/12)
+
+dev/hosts
+dev/uhosts
+	Updated these tables.  (2/12)
+
+vms/os/zopdpr.c
+	This interface routine was modified to give the user more control over
+	the priority of "interactive" background jobs (bkg jobs run as
+	subprocesses, rather than in a batch queue).  The syntax is as follows:
+
+		& [+|-]N
+
+	where +(-) causes the bkg job to run at a higher(lower) priority than
+	the parent, and N is a decimal number.  If neither + or - appears N is
+	the absolute priority of the process.
+
+	For example,
+
+		&15		run job at priority level 15
+		&-1		run job at a priority one level down
+
+	The default if nothing is specified is to run the job at a priority
+	level one less that that of the parent.  (2/12)
+
+vms/os/zgtenv.c
+	This procedure was returning ERR if it could not find the name or the
+	output string overflowed.  Changed to return 0, as is the standard for
+	operators that return string values.  (2/12)
+
+iraf$mkpkg
+	Added an "update" entry point to the root mkpkg, so that I don't
+	have to run update twice in sys and pkg when relinking the system.
+	(2/12)
+
+dev/edt.ed
+dev/emacs.ed
+	Added the NEXT_PAGE and PREV_PAGE operators as indicated in the ST
+	notesfile, received last month in the mail (the VI edcap file was
+	updated some time ago).  There was a conflict for EDT; there was a
+	duplicate entry for MOVE_START which used the same code as one of
+	the new commands (keypad-7).  I solved the problem by deleting the
+	duplicate entry.  (2/12)
+
+pkg/cl/builtin.c
+	Everywhere there was a reference to the _pname (physical task name)
+	for an executable file, added a call to findexe() to get the name
+	of the executable which is actually used.  If this is not done,
+	things like testing to see if a process is in the cache (prc, flpr)
+	fail.  (2/12)
+
+sys/sys.hd
+host/os/doc/os.hd
+	Changed sys$ references to host$ references to reflect the relocation
+	of OS to the HOST directories.  (2/12)
+
+pkg/images/tv/cv/ids/idsfont.x
+pkg/images/tv/cv/iism70/idsoptn.x -
+	There was a name collision with the routines IDS_OPEN and IDS_OPTN.
+	The latter was a no-op in any case, so I deleted it and commented
+	out the only reference to it in IDS_FONT.  (2/13)
+
+sys/gio/cursor/grcwaitp.x
+	Modified to display the "wait" message again after the user responds
+	to the previous "wait" with a space bar, causing the system help
+	to be printed.  (2/13)
+
+dev/termcap
+dev/graphcap
+	Added a few new entries to each file, contributed from our early 
+	test sites.  Updated the cached entries.  (2/13)
+
+pkg/language/*
+	Extensively revised, edited, corrected, extended, brought up to
+	date, added new examples, etc. the manual pages for the CL.
+	Most of the changes were minor, but some important new material
+	was added.  Manual pages were added for those tasks added since
+	the docs were originally written.  A manual page CURSORS was
+	added for cursor mode.  The BEGIN and END manual pages were
+	deleted since these keywords are merely components of the PROCEDURE
+	declaration, not entities in themselves.  (2/12-13)
+
+softools/*.hlp
+	Added manual pages for all the softools utilities, including all
+	bootstrap utilities (generic, mkpkg, rtar, wtar, rmbin, mkhelpdb,
+	hdbexamine, mkmanpage, etc.).  (2/13)
+
+pkg/cl/builtin.c
+	Deleted a couple of task placeholder entries for the language package
+	and added a couple others, so that "? lan" will prompt with a certain
+	set of tasks or functions.  The keywords and common intrinsic fcns
+	are excluded.  (2/15)
+
+dev/termcap
+	Added a new device entry VMSPRINT, used to queue print jobs to the
+	standard VMS print queue SYS$PRINT.  (2/15)
+
+sys/imio/imfort/ +
+vms/os/zgcmdl.c +
+	Added a new interface IMFORT, the Fortran programmer's interface to
+	IRAF images.  This is implemented as the library lib$libfort.a.
+	Linking requires also libsys.a, libvops.a, and libos.a.  Documentation
+	is in the README file, and a manual is on the way.  The interface is
+	minimal at present.
+
+	A new routine, ZGCMDL, was added to the kernel to support IMFORT
+	(I also have plans for it for the LIBC interface, to be able to
+	emulate main(argc,argv)).  This in available in IMFORT as the
+	Fortran callable procedure GCMDLN.  The idea is that the user
+	interfaces their Fortran (or C) program to the CL as a foreign task,
+	then calls it with arguments like any other task.  The Fortran program
+	gets the command line and parses it in memory to get the arguments.
+	(1/17)
+
+vms/os/zfiopr.c
+	We have been having problems connecting subprocesses, so I added a
+	call to _zerror if the create and/or map global section fails when
+	setting up IPC, so that hopefully we can determine why.  (2/18)
+
+sys/etc/propcpr.x
+	A very minor change, while looking over this code.  Added an errchk
+	for the syserr SYS_PROVFL, to prevent a memory overrun in the event
+	that there are no more process slots.  (2/18)
+
+vms/hlib/gripes.cl
+	Modified the gripes script to send the entire text of the gripe to
+	IRAF (as in UNIX/IRAF), rather than just a line stating that a gripe
+	has been posted.  On our system, mail to IRAF on any node is
+	forwarded to a central node, with the mail file for IRAF on that
+	node serving as the central gripes database.  A copy of the gripe
+	is still appended to the gripesfile on the local node.  The temporary
+	file was moved from TMP to UPARM and the extension ".txt" was added
+	to keep VMS mail happy.  The second temporary file for the mail
+	message is no longer created, since the osfn() function now allows
+	us to pass the host name of the first tempfile to the host mail
+	program.  (2/19)
+
+vms/os/zfiopr.c
+	Installed a new version of this driver from ST, which should fix
+	the IPC connect failure problem we have been experiencing lately.
+	ST went though the same thing several weeks ago.  The problem was
+	traced to a SECTBLFUL (section table full) problem in VMS.  This is
+	fixable by rebuilding VMS with a larger table (param GBLPAGFIL),
+	but the new driver will hopefully avoid the problem altogether,
+	avoiding the need for sites istalling IRAF to change a system
+	parameter.  The recent debug_ipc mods were merged into the new
+	driver.  (2/19)
+
+exception handling 	[UNRESOLVED]
+	After relinking the system with the new IPC driver from ST, we had
+	problems when interrupting subprocesses.  Relinking with the old
+	IPC driver helped, but while testing I continued to have problems
+	with exception handling.  Nothing I have done in recent history
+	should have anything to do with these problems, so I ran the same
+	tests on an executable in the old system (untouched for some months).
+	Exactly the same thing happened there, so evidently the problem has
+	been with us for some time.
+
+	The test is this: I run the x_system.e process standalone, entering
+	the command "count files=*.x", and then <ctrl/c> interrupt the
+	task while it is running.  Five times out of six, or thereabouts,
+	it will work, going through error recovery successfully.  When it
+	fails VMS prints the message "improperly handled condition" along
+	with a dump of the stack and registers, and does a panic shutdown of
+	the process.  This is preceeded by an access violation message.
+
+--------------------------------------------------------------------------
+VMS/IRAF V2.2 frozen on 21 Feb.
+
+
+vms/hlib/mkpkg.e
+	Relinked; old executable was using an obsolete version of zgetenv
+	that had a bug.  (3/4)
+
+pkg/cl/config.h
+	Doubled the size of the stack and increased the dictionary from 20K
+	to 30K.  (3/6)
+
+dev/termcap
+	Added an entry for device "imagend", the new imagen on node draco,
+	plus an alias "imagena" for the original imagen on node aquila. (3/13)
+
+sys/ki/kireceive.x
+	Will now echo "out of band" error messages to STDERR, prefixed by
+	the node name, before returning ERR on the kernel server channel.
+	(3/14)
+
+sys/osb/miiupk16.x
+sys/osb/miiupk32.x
+	These procedures were modifying their input arguments.  (3/14)
+
+mkpkg, zgtenv.c	[OBSERVATION]
+	We are running with two different versions of the system, IRAF and
+	IRAFX.  When I linked a process with mkpkg from the IRAFX CL I found
+	that the old IRAF libraries were being used.  The pathnames in the
+	global <iraf.h>, read by ZGTENV when it cannot find IRAF etc. in
+	the VMS tables, were still set for the old system.  After editing
+	<iraf.h> and repeating the mkpkg, the IRAFX libraries were accessed.
+	This proves that indeed the logical names are NOT always getting passed
+	down through all the process spawns, and the new ZGTENV facility is
+	doing its job.  (3/14)
diff --git a/doc/ports/vms_oct85.st b/doc/ports/vms_oct85.st
new file mode 100644
index 00000000..d4e23104
--- /dev/null
+++ b/doc/ports/vms_oct85.st
@@ -0,0 +1,786 @@
+Space Telescope Science Institute	IRAF Notes  (File: iraf$vms/notes)
+
+ 
+--------------------------------
+Wednesday  23-OCT-1985 14:20:08.71
+ 
+Subject: I/O redirection support for IRAF/VMS
+ 
+Added the ability to do I/O redirection on the command line (Unix-style).
+
+	interactive	$ cl
+	i/o to files	$ cl  <infile  >outfile     (or >>outfile)
+
+This allows people to run the CL in a VMS batch job or as a "background" 
+subprocess, specifying the CL commands in a text file.
+
+
+sys$os/zmain.c
+	Added code to support I/O redirection  (parsing, file setup, etc.)
+
+sys$os/zfiotx.c, zfiofi.c
+	Fixed ZSEKTX to work correctly (had troubles with redirected i/o for
+	some reason).
+
+	Changed append mode access so it has RMS Update access (for seeking).
+
+pkg$cl/exec.c
+	Added a global variable 'logout_on_eof' (default=0), which is set
+	by the VMS ZMAIN when I/O is redirected to files.  If the user forgets
+	to put the 'logout' command in the infile, then EOF will get him out.
+	Otherwise, it's very easy to fill up a disk with "ERROR: use 'logout'.."
+	messages in a file, something we definitely want to avoid.
+
+	This is only a TEMPORARY fix.  The same thing happens under Unix, so 
+	maybe their should be some way of handling this in a general,
+	system-independent way.  Will users use the CL with input from a file 
+	instead of the terminal?  They are here (for now) and the capability 
+	should probably be supported, since it is automatically supported 
+	under Unix.
+
+	This fix does not affect normal operation of the CL in interactive mode;
+	the user still has to say 'logout' to get out of the CL.
+
+	Note:  If a user has a parameter which has a range specified, and the
+	value is out-of-range, while running the CL in this "OS-background"
+	mode, it will probably just loop until death saying "parameter out of
+	range", and fill up a disk with these error messages.  This is also
+	a problem, but not sure how (or if) to fix it; the user should make
+	sure that the parameters are indeed correct when running the CL this
+	way to avoid this problem (?).
+ 
+--------------------------------
+Friday  25-OCT-1985 17:16:02.53
+ 
+Subject: pkg$cl/eparam.c
+ 
+Hacked EPARAM to fix a number of problems with multi-line prompts, arrays,
+and other things.  There are still a few known "features", but they are so
+obscure and such special cases that I'm not going to worry about them now
+(there are easy ways to "reset" eparam to fix these offset problems).
+
+Also, changes so that value field is not overwritten by prompt string.
+ 
+--------------------------------
+Wednesday  30-OCT-1985 09:40:22.45
+ 
+Subject: Parameter cacheing  (pkg$cl/exec.c)
+ 
+Parameter cacheing mechanism (pkg$cl/exec.c  mk_startupmsg, sys$etc/main.x,
+clio$clcache.x, etc.) does not handle array parameters.  Eventually, it should,
+but this will mean some non-trivial changes in all of these places.  There
+are a few places in SDAS that do indeed have array parameters, so the course
+of action for now is to not pass them in the startup message (as is done with
+list-structured parameters).  This fix is a simple "if" statement in exec.c/
+mk_startupmsg().
+ 
+--------------------------------
+Monday   4-NOV-1985 12:33:48.79
+ 
+Subject: pkg$cl/grammar.y (ytab.c)  decl.c
+ 
+Bug fixes for 'real' declarations with negative values for min and max.
+ 
+--------------------------------
+Monday   4-NOV-1985 14:34:10.38
+ 
+Subject: pkg$cl/lex.sed lex.com (for lexyy.c)
+ 
+Added editor functions to change (YYLMAX 200) --> (YYLMAX 2048), so lexical
+analyzer can handle long prompts given in procedure scripts.
+ 
+--------------------------------
+Monday   4-NOV-1985 15:35:36.85
+ 
+Subject: pkg$cl/linkcl.com [VMS]
+ 
+Changed to generate the CLDATE file in MACRO rather than C (i.e. cldate.mar).
+This is so IRAF/VMS sites don't need a C compiler to relink IRAF (one site had
+this problem already).
+ 
+--------------------------------
+Tuesday   5-NOV-1985 16:22:14.70
+ 
+Subject: pkg$cl/task.c
+ 
+Additional check added before strncmp() call in ltasksrch() to check first
+character first.  Some profiling on Unix showed this to cut down the calls to
+strncmp() significantly. 
+ 
+--------------------------------
+Wednesday  20-NOV-1985 08:59:41.61
+ 
+Subject: sys$os/  [VMS Kernel]
+ 
+The VMS Kernel routines have been overhauled.  The large number of changes
+consisted of: deleting obsolete code, consolidating common code segments,
+some name changing, improving readability and consistency, and some tweaks
+for efficiency.  Most of the changes were indeed cosmetic, in an effort to 
+bring the code into conformance with the IRAF coding standards (though perhaps
+not 100% there).  To list all the changes would be impossible, so here are
+some of the major ones...
+
+A number of files have been renamed, as well as support routine names, to be 
+more descriptive (and to remove the "z" on many of the support routine names).
+
+File name changes:
+	zconvtim.c  -->  convtime.c
+	zexit.c	    -->  exit.c
+	zget*.c     -->  get*.c
+	zprocname.c -->  procname.c
+	ztrnlg.c    -->  tranlog.c
+	zfiofi.c    -->  rms.c
+	ast.c	    deleted (no longer needed)
+
+Function name changes:
+	_zopnfi, _zclsfi  -->  _rms_open, _rms_close
+	_ztrnlg, _zcrelg  -->  _tranlog, _createlog
+	_zrequestio       -->  _zqio
+	_zsttfi		deleted
+	others...
+
+New files:
+	dirname.c
+	queue.c
+	eprintf.c	(from Kitt Peak, VMS net stuff)
+
+The file status functions (formerly in _zsttfi) have all been moved into each
+of the ZFIO* drivers, with appropriate buffer size values in the include file
+"vms.h".  Some of these values have been modified, where appropriate, or as a
+result of recommendations from Kitt Peak.
+
+No effort was made to completely redesign anything, though some files and
+routines were restructured quite a bit.  The effect on executable sizes of 
+these changes is negligible.
+
+--------------------------------
+Friday  22-NOV-1985 10:43:50.93
+ 
+Subject: pkg$softools/boot/...
+ 
+All of the VMS source code for the boot utilities (MKLIB, XC, support ...)
+have been overhauled to look like the rest of IRAF (at least partially), just 
+as the VMS Z routines.  Besides a few name changes because of Z-routine
+name changes, there was only 1 functional modification:
+
+	pkg$softools/boot/spp/xc.c	[VMS]
+			     /dcl.c +
+		Changed to use the function DCL instead of ZOSCMD.  DCL does
+		everything ZOSCMD does without all the weird features to 
+		support interactive commands.  The output is much more 
+		consistent here as well, no longer generating ".;" and ".LOG;"
+		files all over the place when running XC and MKLIB in batch
+		or background.  (DCL is essentially an earlier, stripped-down
+		version of what eventually became ZOSCMD).
+ 
+--------------------------------
+Monday  25-NOV-1985 15:41:56.73
+ 
+Subject: Support for VMS batch jobs
+ 
+The VMS kernel has been modified to support VMS batch jobs as well as
+parallel subprocesses for IRAF background jobs.  Changes in the higher level
+IRAF code is necessary to selectively use these two options.  Since the
+calling sequence for ZOPDPR has been changed, the new one is currently 
+commented out until these higher level changes are finished (at Kitt Peak).
+
+[received CL and system lib changes, 9-DEC]
+
+The changes include:
+
+	ZOPDPR -- extra parameter 'batch_queue', null or "" for subprocesses,
+		  a batch queue name for a VMS batch job.  A few new routines
+		  in this module were added and everything was reorganized a
+		  bit.
+
+	ZMAIN  -- some extra checks were added to deal with the batch case.
+
+	ZFIOTX -- In ZSEKTX, added a check for STDIN/STDOUT when a VMS batch
+		  job.  This is necessary to avoid seek errors on NLA0: and
+		  the batch log file.  (VMS really makes it hard to deal with 
+		  I/O in a consistent manner.)
+
+	queue.c - Contains VMS batch and print queue support functions.  Used
+		  by ZOPDPR and ZFIOLP.
+ 
+--------------------------------
+Monday   2-DEC-1985 09:40:50.23
+ 
+Subject: pkg$cl/builtin.c
+ 
+Changed SZ_FNAME to SZ_PATHNAME in cledit() to handle longer VMS filenames
+resulting from filename mapping.
+ 
+--------------------------------
+Monday   9-DEC-1985 08:27:39.00
+ 
+Subject: pkg$cl/prcache.c
+ 
+Interrupts were not being enabled if connected subprocess create failed.
+Added call to intr_enable() in before returning NULL.
+ 
+--------------------------------
+Tuesday  10-DEC-1985 12:39:20.67
+ 
+Subject: New version of IRAF/VMS from Kitt Peak.  Merge notes:
+ 
+sys/os/*
+	Remerged the VMS kernel.  No major problems, even though we both had 
+	made a number of changes.  Will test it all out soon.
+
+sys/os/net/decnet.c +
+	   zfioks.c
+	   Makelib
+	   eprintf.c --> ../
+
+	Added support for DECnet, though this is not fully tested yet.  This 
+	is a compile time option (DECnet or TCP) in ZFIOKS and will not affect
+	the TCP implementation.  The eprintf.c file was moved to the sys/os/ 
+	directory, since some debugging code there uses it now as well.
+
+sys/gio/gks/gtx.f
+	Did NOT use KPNO version of file since it was calling f77upk with
+	the wrong number of arguments.  There is no min-length arg to f77upk
+	in either version of IRAF.
+
+sys/osb/f77pak.f
+	Changed DO loop to pop out when done, rather than going around until
+	it reaches 9999.
+
+sys/gio/ncarutil/sysint/uliber.f
+	Following change need to compile on VMS.
+		integer*2(80) sppmsg  -->  integer*2  sppmsg(80)
+
+pkg/images/imarith/imadiv.x
+		   imamax.x
+		   imamin.x
+		   (>>> imarith.x)
+	POINTER --> PIXEL
+
+pkg/imred/generic/Makelib, x_generic.x, generic.cl
+	Removed references to 'cmdstr' in these files.  Assumed 'cmdstr' was
+	moved to the system pkg, since no cmdstr.* files on the tape. (?)
+
+sys/fio/vfnmap.x
+	Reference to ztslee changed to zwmsec.
+
+pkg/system/x_systest.x
+	Removed reference to mtdevlist.
+
+pkg/images/tv/display/t_mkdisplay.x
+	Moved call to open_display_header to AFTER getting name of stdimage
+	and frame number.  Was before it, resulting in dev$_0.imh, instead
+	of dev$deanza_1.imh.
+
+pkg/language/doc/*.hlp
+	Some of these files were updated recently to correct errors, typos,
+	misspellings, etc.  Forgot to note these changes before.
+
+Testing re-merged system
+	Tested out a number of the usual things: CL, test scripts, SYSTEM and
+	LISTS pkgs, some graphics and image tasks, etc.  Everything seems to
+	be working okay.  There are still a number of known bugs, especially
+	in eparam and procedure scripts (history gets a 'begin' in the history
+	for procedure scripts).  I'll be looking into these again soon.
+
+VMS Batch Jobs
+	Tested out the CL with both types of background jobs, subprocesses and
+	batch.  Both work fine.  A logfile for the batch job case is kept
+	in the user's sys/login directory with a name like "12345678_D_1.LOG",
+	(i.e., like detached subprocess names).  This logfile is largely
+	login garbage, but if the user does not redirect output, it will go
+	here as well.  When things settle down and everything is working okay,
+	we may want to have the logfile deleted, or add an option for keeping
+	it or not.
+
+	Logical names for batch queues work as expected.  For example, the 
+	following can be done:
+
+		$ define  b  sys$batch
+		$ define  f  localfastbatch
+		$ define  s  localslowbatch
+			...
+
+		cl> task >&task.out &f	   # IRAF bkg job to 'localfastbatch'
+
+	This means that zopdpr.c can remain system-independent, with system
+	dependent batch queues set up in logical names or spelled out fully
+	when in the CL.
+
+Magtapes
+	Tested the tape stuff with all the new changes from Kitt Peak merged
+	in.  Used mtexamine and rfits and was able to read in about 20 small
+	FITS images and run some tasks from the images and plot pkgs on them 
+	with no problems.  
+
+
+======>  Sent tape of changes above to KPNO  (16-Dec-1985)  <=====
+
+ 
+--------------------------------
+Tuesday  17-DEC-1985 16:07:42.04
+ 
+Subject: sys/os/zpanic.c
+ 
+Bugs in formatting the error message fixed.
+ 
+--------------------------------
+Tuesday  17-DEC-1985 16:29:52.99
+ 
+Subject: sys/os/zmain.c
+ 
+Changed code in _get_prtype() to figure out whether we're a batch job
+by examining the PCB status bits, instead of the process name.  If the user
+sets his process name in the login.com file, then the background CL starts
+up thinking it's a regular host process.
+
+
+===> Sent above fixes to KPNO  17-Dec <===
+
+ 
+--------------------------------
+Wednesday  18-DEC-1985 12:36:34.43
+ 
+Subject: dev/*.ed
+ 
+Added NEXT_PAGE and PREV_PAGE sequences to edcap files for EDT, EMACS and VI.
+
+edt --
+	NEXT_PAGE        \033Ow		 keypad-7
+	PREV_PAGE	 \033OP\033Ow	 gold-7
+
+	(In edt, prev_page is really keypad-5,keypad-7, but this would
+	 set direction backwards; gold-7 in edt is "command", which is not
+	 used in eparam anyway.)
+
+emacs --
+	NEXT_PAGE	^V		^V
+	PREV_PAGE	\eV		ESC-V
+	PREV_PAGE	\ev		ESC-v
+
+vi --
+	NEXT_PAGE	^F		^F
+	(Nothing added for PREV_PAGE; not sure what to use, since ^B and ^U 
+	 are already being used.)
+ 
+--------------------------------
+Wednesday  18-DEC-1985 16:43:41.78
+ 
+Subject: pkg/cl/builtin.c
+ 
+Fixed a bug in clflprcache() so that everything is not flushed if the named
+task is not found in the process cache.  Previously, if a user said 
+
+	cl> flprcache notask
+	Warning: 'notask' not in cache
+
+Then everything would go anyway, including locked tasks.  The fix is simply
+to do a 'continue' in the while loop when we print out this warning message.
+ 
+--------------------------------
+Wednesday  18-DEC-1985 18:44:37.98
+ 
+Subject: sys/fmtio/lexdata.xi
+ 
+Changed action table for  +/-  in state QRX from Rvt to QRX.  This is to fix
+a bug when getting numbers like 1.0e-10 which returned nchars=3 instead of
+nchars=7.  This code is (eventually) used to check the type of command line
+arguments in the CL when lexmodes=yes, which is where the problem was first
+noticed. 
+
+The code in lexnum.x along with the action table are somewhat difficult to
+follow and there may be other implications here which are not apparent, but
+based on other entries in the table, this looked like it was indeed a bug.
+Ran the debug code in sys/debug/nop.x (lex task) and things worked correctly
+in all cases tested.
+ 
+--------------------------------
+Friday  20-DEC-1985 11:42:48.72
+ 
+Subject: VMS batch jobs and DCL commands
+ 
+When running a DCL command as an IRAF/VMS batch job (e.g. a foreign task), if
+the output just goes into the logfile, it ends up being written into files with
+names like .;1 and .;2, etc.  This goes back to all the old crazies with the
+funny ZOSCMD to defeat slow spawning and still provide interactive
+capabilities.  The user should redirect output in this case somewhere else and
+not let it go to the VMS logfile.  Tried a few changes in zoscmd.c and open.c
+to no avail, so I'm just going to let this slide for now. 
+ 
+--------------------------------
+Monday  23-DEC-1985 08:50:37.80
+ 
+Subject: pkg/system/help/Help.hlp
+ 
+Formatting change to fix indentation:
+
+		.ls
+		helpdb = "helpdb"
+to
+		.ls helpdb = "helpdb"
+ 
+--------------------------------
+Monday  23-DEC-1985 10:35:15.82
+ 
+Subject: Help task (discussion)
+ 
+Some SDAS users have voiced a "concern" over the help task.  When saying "help
+abc", everything that matches "abc" is given, even if something has already
+matched it in the current package.  This is confusing to novice users, even
+though it is documented in the help that it will perform this way.  A more
+concrete example: 
+
+	cl> system
+	sy> help co
+		... concatenate
+		... copy
+		... count
+		... imred.coude
+		... language.command
+		...
+	
+Would it be possible (and/or desireable) to stop the searching if help is found
+somewhere in the current package for a named task or abbreviation?  
+
+Another problem is getting help on something in a different package than what
+was intended because of a common abbreviation (and no help file for the task in
+the current package).  The fix for this might be to limit the help search to
+the current loaded packages, unless an explicit pkg-template.module-template
+were given by the user. 
+
+To go one step further, a suggestion by some SDAS people was to have an extra
+parameter that controlled the search.  For example, if matchall=yes, then help
+would act as it does currently, otherwise, it would only search the current
+package. 
+ 
+--------------------------------
+Monday  23-DEC-1985 17:32:26.42
+ 
+Subject: CL Changes  Nov-Dec 1985
+	 (T.McGlynn, J.Travisano)
+
+grammar.y
+	- delete opnl's in procedure declarations to eliminate s/r conflicts.
+	- create LP and RP for parentheses to eliminate some expressions.
+	- repositioned initialization processing.
+	- modified var_decls slightly.
+	- if/else fixes, so don't need { if ... }.
+	- better syntax error reporting in scripts: gives (correct) line number,
+	  points to offending position, and continues parsing script for errors.
+
+history.c  gram.c
+	- changes to support above grammar changes
+
+history.c  exec.c  pfiles.c  decl.c
+	- changes to deal with script line numbers correctly, i.e.
+	  task->t_scriptln, which is used in syntax error messages; also,
+	  a fix in the skip_to() function in decl.c.
+
+history.c
+	- problem of getting a "begin" in the history when running (or parsing)
+	  a procedure script was fixed.  The original command is now recorded
+	  in the history (and logfile) correctly.  Unfortunately, there is
+	  one case where this does not work -- when get an error parsing the
+	  parameter declarations in a procedure script.
+
+eparam.c
+	- format changes for real arrays (so exponent shows up)
+	- tried to fix MOVE_END problem when going across page boundaries;
+	  can't seem to find the bug, so for now just print out a message that 
+	  says to use NEXT_PAGE a few times instead of MOVE_END.
+
+pfiles.c  param.c  gram.c
+	- added support for '\r' and '\f', so can be used in prompt strings 
+	  for better formatting control  (\f not fully supported in EPAR yet)
+
+modes.c  decl.c  pfiles.c
+	- whitespace-only filename parameters are turned into null strings;
+	  so users can check null filenames easily in a script (fn != "")
+	  without having to deal with whitespace.  Filenames with whitespace
+	  only are not really legal anyway (?).
+
+modes.c 
+	- bug fix to prevent trashing of enumerated parameters in certain
+	  instances.  
+
+param.h
+	- minor typo   'ai' --> 'ar'
+ 
+--------------------------------
+Friday  27-DEC-1985 14:47:48.01
+ 
+Subject: CL history editor
+ 
+The following is another lexmodes=yes problem:
+
+	pl> contour img1[*:16,*:16]
+		...
+	pl> surface ^^
+	surface img1[*:16
+	Warning: ...
+
+The get-arguments code in pkg/cl/history.c checks for comma-delimited strings.
+Putting the whole argument in quotes, i.e. "img1[*:16,*:16]", and then using
+^^ works fine.  (No fix/change was made.)
+ 
+--------------------------------
+Friday   3-JAN-1986 14:59:06.87
+ 
+Subject: Local vars in CL procedure scripts
+ 
+It is generally assumed that local variables in CL procedure scripts, i.e.
+those after the "begin" statement, will be initialized by the user with 
+simple assignment statements.  There is one (possibly more) case where this
+assumption can cause problems.  For example,
+
+			...
+		begin
+			string  buf
+
+			if (fscan (plist, buf) != EOF) ...
+			...
+
+Here, "buf" is used before being initialized, and the result is an error
+saying "Attempt to use uninitialized local variable 'buf'".  Perhaps local,
+uninitialized variables should be initialized automatically by the CL, but
+have done nothing to fix/change this yet; just making a note of it.
+ 
+--------------------------------
+Tuesday   7-JAN-1986 15:37:59.59
+ 
+Subject: Miscellaneous
+ 
+These are various notes and suggestions by IRAF users at STScI and elsewhere.
+I decided to finally add them all here since they were beginning to pile up
+on various scraps of paper on my desk.  Some of them are minor bugs, but most
+are suggestions of some kind.  Nothing has been done with any of them in terms
+of IRAF changes.  Most of the text is from mail messages or typed in verbatim 
+from paper copies.  Any notes by me (JayT) are indicated in brackets [].
+
+
+From ST users:
+
+CL
+   Would it be possible to put a feature into iraf whereby you say
+'task=xxx', which would then set a default so that you could just 
+type lpar, or an input, without having to specify which task?  
+Ie, instead of having to type 'xxx.infile=etc', you could specify
+the task and then just type 'infile=etc', with iraf filling in
+the task name.  This would not interfere with those who like the
+system as it is, but could streamline things for those of us who
+like the way AIPS does things.
+
+Integer parameters
+  We have encountered another peculiar feature of IRAF.  Suppose you have a
+parameter that is declared as integer in a .par file, and the user attempts
+to put in a value for that integer that exceeds the range of INT*4.  The cl
+fills in that parameter with the value 'indef', a character string.  When
+SDAS goes to read the parameter, we get a crash because the parameter is not
+in integer form.  Now, it seems that a parameter declared as an integer ought
+to be an integer no matter what, not a character string.  Wouldn't it be better
+to leave the parameter value unchanged from its current or default value rather
+than put in this string?
+
+
+From RAL users:
+
+CL Parser
+	li> ?? | words | match ':' stop+| sort | table
+
+	does NOT work correctly, but separating the "+|" to "+ |" works okay.
+
+Help on parameter prompt
+	It is very complicated to provide additional help at the prompt for
+	parameter stage especially for non-string parameters.  This facility
+	is almost essential to provide a user-friendly interface. 
+	For example:
+		A string specified in the parameter file is output if ? is
+		typed in response to a prompt or possibly even enter the help
+		system.
+
+	[NOTE: One can make the prompt quite verbose, up to something
+	like 2K characters; e.g., many SDAS prompts are long and multiline.]
+
+Range check and default display in sexagesimal
+	There needs to be an option in the parameter file to cause the range
+	check and default information to be output in sexagesimal.  For example,
+	it is ugly to type in 12:34:56.7 and have it reappear as 12.582417.
+
+Date type
+	I think there ought to be special facilities for handling dates.  At
+	present you can't enter a date all in one line (except using a
+	grotty fudge involving sexagesimal, which precludes proper range
+	checking), and if you enter the Y,M,D separately you can get things
+	like 1985 2 30 past the range checks.
+
+
+From U. of Cal/San Diego (Doug Tudhope):
+
+lists.gcursor [and imcursor]
+	Get syntax error line 2.  [known "feature" since CL2 grammar]
+
+	[NOTE: doing an "lpar gcursor" activates the graphics cursor, 
+	but then get an error of "EOF encountered in list parameter..."]
+
+plot.graph task
+	If only 2 points are given, only the axes are drawn, e.g.
+
+		pl> graph STDIN
+		10 10
+		20 20
+		<EOF>
+			axes, but no line!
+		pl>
+
+images.imtranspose
+	Made a transposed output file of a real 190*800 image -> 800*190
+	but neither onedspec.splot nor images.implot would work on it.
+	they stopped with "reserved operand fault".
+	When imcopy run on transposed image, got "pixel storage file truncated".
+ 
+--------------------------------
+Tuesday   7-JAN-1986 15:51:02.98
+ 
+Subject: pkg/softools/boot/spp/xc.c  [VMS]
+ 
+Added EXTEND_SOURCE option for calling Fortran compiler from XC.  This lets
+source statements go up to column 132 (instead of 72).  One line added to
+source:
+
+fcompile() {
+	...
+	sp = strcpy (outbuf, F77);
++	sp = strcpy (sp, "/EXTEND");	/* Allow statement in cols 1-132 */
+	if (portable)
+	...
+}
+ 
+--------------------------------
+Tuesday   7-JAN-1986 16:11:20.85
+ 
+Subject: pkg/images/tv/display/deanza/*
+ 
+Deanza now works with tv/display under VMS!  All of the source files and Deanza
+libraries are here.  See the README file for more detailed information.
+
+Also changed "pkg/image/tv/display/mkpkg.com" to make the Deanza code instead
+of the IIS-dependent code. 
+ 
+--------------------------------
+Wednesday   8-JAN-1986 12:21:09.73
+ 
+Subject: pkg/imred/.../*.e
+ 
+The ONEDSPEC executables are copied all over the place into IMRED.  Comments in
+the mkpkg.com files say this is to use different par files for different
+directories.  There's GOT to be a better way, as this eats up a lot of
+diskspace (and tape as well at distribution time), which we always seem to be
+running up against here.
+ 
+--------------------------------
+Friday  10-JAN-1986 15:29:37.13
+ 
+Subject: More SDAS concerns/suggestions
+ 
+Environment variables
+	When a script task ends or a user bye's from a package, all "set"
+	declarations made in the task or since the package started are
+	"popped" during task restoration.  Comments in pkg/cl/exec.c indicate
+	that this is for keeping the environment the same across processes.
+
+	However, this can lead to confusion.  If a user does a "set stdgraph="
+	and later bye's out of a package, stdgraph reverts back to the 
+	previous value, just as any other environment variable.  The same
+	thing occurs in script tasks during the restore, making it difficult
+	to have global environment variables.  Putting a "keep" in scripts at
+	various places can get around this to some degree, but it's sometimes
+	awkward.
+
+Process cache
+	SDAS has been set up under IRAF such that the user can choose which
+	version of SDAS he wants (baseline|standard|develop).  This choice
+	can be made when starting the sdas package or any of its packages.
+	There is a problem, however, when running a package from 'standard'
+	and then running the 'develop' version when the executable is already
+	out there.  When a task is invoked, it will simply use the subprocess
+	already in the cache, even though it's a different executable (with
+	the same IRAF logical name).
+
+	The suggestion that came up was to do an implicit "flprcache" whenever
+	there is a "bye" to a package, i.e. when all the tasks associated with
+	the executable are gone.  I've looked at this a little bit and don't
+	see an easy way of determining when we're bye'ing from a package which
+	has tasks that are in an executable.  I imagine there's a decent amount
+	of overhead associated with checking all the tasks associated with
+	an executable as well.  In general, getting rid of old executables
+	does make sense if they're not longer referenced, since it frees up 
+	system and user resources (especially important on VMS given the
+	large process and executable sizes).
+
+Table parameters
+	SDAS and CDBS now have a new type of input file, a table, which may or 
+	may not have a header as well.  They have asked if it would be easy
+	to add a new parameter (or two) to IRAF, i.e. a table parameter and
+	possibly a table-with-header parameter.
+
+	I don't think this is a good idea, as it is something which only
+	benefits SDAS and CDBS, and does very little if anything for IRAF.
+	I have encouraged the SDAS people to find an SDAS-only solution to
+	this problem using existing IRAF facilities.  One simple way is to
+	have tasks which use tables to have a 'type' parameter which tells
+	if the input file is a table or something else.
+ 
+--------------------------------
+Tuesday  14-JAN-1986 08:48:36.11
+ 
+Subject: doc/clintro*
+ 
+Copied the TeX source for the CL User's Intro doc from Peter's directory
+to the general IRAF DOC directory.
+ 
+--------------------------------
+Tuesday  14-JAN-1986 10:49:06.01
+ 
+Subject: Size of IRAF...
+ 
+A concern has risen, once again, on the size of IRAF.  Garrett Jernigan
+(Berkeley Space Sciences Lab) has mentioned problems finding diskspace to
+handle all of IRAF.  The suggestion he made to Peter was "to split the source,
+obj and executables into separate libraries for the distribution, or at least
+put them into different sub-directories.  If either a tape could be generated
+that only had executables, or that had the whole works, but allowed only the
+required files for execution to be loaded it would be a real boon."  I guess
+this means having something analagous to the bin/, src/ scheme in Unix.
+
+I think a better solution to this is to add something to the installation docs
+to describe how to load only parts of IRAF, i.e. everything, or no source,
+etc., so the IRAF installer can load only the parts needed/desired.  Both Tar
+and Backup can handle selective copying in some manner. 
+ 
+--------------------------------
+Tuesday  14-JAN-1986 11:37:46.40
+ 
+Subject: CL strings
+ 
+It is currently impossible to get the length of a string in the CL.  This
+should be quite trivial to implement, but it is not.  The documentation on
+"paramaters" states that p_length contains the maximum length of the string,
+though in reality, saying =param.p_length simply prints the string, just as
+=param does. 
+
+There should be some way of getting the current length of a string, since it
+could be used as the 'last' parameter in stridx, for getting the rest of a
+string starting at column n.  ST users have continually asked me about ways to
+get the current length of a string parameter (e.g., from within a CL script).
+
+One solution is to change the meaning of some of the parameter attributes for
+string parameters to something which makes more sense: 
+
+	p_length  --  contains the current string length, updated whenever
+		      the parameter is changed.
+	p_max     --  contains the maximum string length
+
+These would require changes primarily in param.c and gram.c.
+
+Also, currently trying an =param.p_min or p_max on a string parameter results 
+in an access violation.
diff --git a/doc/ports/vmsbugs.doc b/doc/ports/vmsbugs.doc
new file mode 100644
index 00000000..e67d62e1
--- /dev/null
+++ b/doc/ports/vmsbugs.doc
@@ -0,0 +1,328 @@
+From stsci Thu Jan 17 08:30:15 1985
+Received: by lyra.noao.UUCP (4.12/4.7)
+	id AA10600; Thu, 17 Jan 85 08:30:03 mst
+Date: Thu, 17 Jan 85 08:30:03 mst
+From: stsci (Space Telescope )
+Message-Id: <8501171530.AA10600@lyra.noao.UUCP>
+To: tody
+Status: R
+
+Doug,
+
+	Here is a list of bugs, changes, suggestions, etc. compiled during
+the port of IRAF to VMS.
+
+	Some of the bugs have the bug fixes listed here; others were too
+elusive and/or time-consuming to try to figure out at this time.  When you 
+get the latest, greatest VMS version of IRAF, what changes we made will 
+certainly be there;  we'll probably send along RCS files as well so you could
+easily update some of your files.  However, most of the changes are
+just a few lines here and there.
+
+	We await any comments or any bug fixes you have there...
+
+				Jay and Fred
+
+P.S.
+	We were discussing using mapped sections such as sdas
+uses for static files. There is one major difference in the way that
+iraf and sdas handle static (image) files. In the sdas routine
+a pointer is passed back to where the image resides in memory. This
+is due to the way the mapped sections work in VMS. In Iraf the zroutine
+is given a pointer to where the data is to reside, so we have to do
+a memory copy for each image reference, and may not be more efficient
+than just writing to or reading from disk. Can you see any easy
+way around this problem, or maybe an additional flag to zopnsf which
+indicates that a pointer is to be passed back from zardsf or zawrsf
+for the data rather than a passing in a pointer to where the data is to
+be read to or written from?    (fred)
+
+
+----------------------------------------------------------------------------
+
+
+			------------------------
+			NOTES file for IRAF (VMS)
+			------------------------
+
+
+Contents:
+		1.	Bugs 
+
+		2.	Portability Considerations
+
+		3.	Source file name changes
+
+
+-------------------------------------------------------------------------------
+
+
+1.	Bugs 
+
+	/pkg/cl/bkg.c
+		In rbkgfile(), following fix:
+			... fgets (set, fp) ...    	TO
+			... fgets (set, SZ_LINE, fp) ...
+
+	/sys/libc/qsort.c	--	qcmp()    -->  (*qcmp)()
+	/sys/libc/cfilbuf.c	--	filbuf()  -->  (*filbuf)()
+
+	/sys/vops/advz.x	--	'$t' missing for generic function
+	/sys/vops/advz*.x	--	procedure advz[idx...]
+
+						(extra files ?)
+	/sys/vops/ak/aif*.x	--	aiftrrr.x
+	/sys/vops/ak/aff*.x	--	afftrxx.x,  afftxrr.x,  afftxxx.x
+	/sys/vops/ak/acjgx.x	--	acjgxx.x
+
+	/sys/fio/fdebug.x	--	"int and()" statement missing
+	/sys/fio/fputtx.x	--	"int and()" statement missing
+	/sys/fio/fgetfd.x	--	"int or()"  statement missing
+
+	/pkg/cl/pfiles.c	--	pfcopyback()
+		'pt' was going NULL before 'pf' in a for loop check;
+		was changed to check for 'pt' being NULL instead of 'pf'
+
+	/pkg/cl/builtin.c, binop.c, bkg.c, history.c, lexicon.c,
+		debug.c, errs.c, exec.c, pfiles.c
+
+		problem getting to next task by doing  'tp++'; due to VMS
+		alignment of structures.  Fixed with a macro definition in
+		/pkg/cl/task.h  for "next_task()", namely:
+
+		#define  next_task(tp)  \
+			((struct task *)((unsigned)tp + (TASKSIZ * BPI)))
+		#define  prevtask  next_task(currentask)
+
+
+	/pkg/help/lroff/output.x --	references constant MAX_INT
+					"include <mach.h>" statement missing
+
+	/pkg/lists/tokens.x	--	last_nscan() --> last_nscan
+
+	SPP/RPP compiler bug	--
+
+			define  and  jiand	(e.g. in <iraf.h>)
+
+			if (x == FIVE  &&  y == SIX) ...	(SPP)
+			if (x == FIVE  &   y == SIX) ...	(RPP)
+			if (x .eq. 5  .jiand.  y .eq. 6) ...	(FORTRAN)
+
+		only occurs when a macro is replaced before the '&&', 
+		in this case FIVE.
+
+	/sys/fio/vfnmap.x
+		vfnunmap() -- when an OS extension was (un)mapped to a null
+			      IRAF extension, the character count returned
+			      was not right:
+				(e.g.)	doc.dir --> doc   but nchars = 7
+                              This caused problems later on in the directory
+	                      task of the system package.
+			The fix:
+					...   {
+				vfn[extn_offset-1] = EOS
+				op = extn_offset - 1		<-- was missing
+			        }	...
+
+	/sys/fio/vfntrans.x
+		filename mapping for directories sometimes doesn't work;
+			sys$  -->  drb4:[irafx.sys]sys   instead of
+				   drb4:[irafx.sys]
+		made a quick fix in zopdir() and zfchdr() to deal with this
+		for now; can't seem to locate the exact problem in vfntrans.x
+
+	/sys/fio/vfnmap.x
+		When deleting a file and the parameter subfiles=yes, and
+		no mapping file is currently in directory, a null mapping
+		file is (sometimes) created.  Then doing a system.directory 
+		fails when trying to read this null mapping file.
+
+		E.g.  cl> delete aaabbb.ccc
+			subfiles=yes (default .par file)
+
+			delete() is called with 'aaabbb.ccc' and then
+				'aaabbb.ccc.zsf', which is degenerate;
+				therefore, if a mapping file doesn't 
+				exist, it is created.
+
+		Haven't fixed this yet; not sure about the best way to go.
+		Some simple suggestions:
+
+		  --	Could somehow figure out whether the file is being
+			added or deleted (i.e. was vfnmap() called from 
+			vfnadd() or vfndel()?).  
+
+		  --	Or, whenever a mapping file is created, it has the 
+			appropriate header info in it rather than being null?  
+
+		  --	Or, some special case of reading null mapping files?
+
+
+	/sys/etc/environ.x
+		env_hash()  
+			return (sum**2 / CONSTANT)
+
+		causes integer overflow on VMS; changed to:  (for now)
+			return ( int( float(sum) / CONSTANT * float(sum) ) )
+
+	arithmetic overflows:
+		/sys/etc/urand.x  and  others...
+
+		These seem to occur in a few places, sometimes purposely.
+		An easy VMS fix is to use "FORTRAN/NOCHECK file", but it's
+		a pain to have to remember which files need this special
+		treatment.
+
+	/sys/fio/
+		Seems to be a bug in the file i/o related to writing 
+		asynchronously to binary files.  In VMS, this is REALLY
+		asynchronous, and it caused problems when trying to write
+		the help database;  making VMS do it synchronously (like
+		UNIX) fixed the problem, for now anyway.
+
+		It may be that a single buffer is being played with between
+		the write and the wait;  at least that's what it looks like
+		in some of the binary files that were written -- there were
+		missing blocks and misaligned data, which were there when
+		displayed on the terminal.  
+
+		I don't think it's a problem with RMS, since double buffering
+		was used to test the binary file driver, with success.
+
+
+	/pkg/system/directory.x
+		- call strcat ("$", Memc[template])    -->
+ 		  call strcat ("$", Memc[template], SZ_FNAME)
+
+		- should sort and output the file name list ONLY 
+				if (nfiles > 0)
+		  otherwise, an "adjustable array error" occurs in qsort()
+		  (i.e. an array with dimension of 0 is passed to qsort,
+		        causing VMS to complain)
+
+
+-------------------------------------------------------------------------------
+
+
+2.	Portability Considerations
+
+
+	(life would be easier if most source files and include files did
+	 not need to be mapped ... especially C source files)
+	
+			--	no underscores
+			--	only alphanumeric
+			--	case insensitive (i.e. lower case)
+			--	(9 chars).(3 chars)
+
+	(Notes: Some source file names and references to include files
+		had to be changed to create the filename mapping in the 
+		first place, see list below.  
+
+		This is not so crucial now, since XC and XPP have been
+		written/modified to handle filename mapping.  But, it
+		still does cause problems when making bug fixes to source
+		files with degenerate names and trying to keep track of
+		them with RCS.  Of course, 99% of the mapping problems will
+		disappear with VMS V4.0.)
+
+	also, directories should be case insensitive:
+		/sys/vops/AK	-->  ak
+		/sys/vops/LZ	-->  lz
+
+
+	sys/libc/cfilbuf.c	--	filbuf  -->  vfilbuf (VMS)
+					since 'FILBUF' gets translated to
+					'filbuf' on VMS, not 'filbuf_', 
+					which causes a conflict:
+						FILBUF and (*filbuf)()
+
+
+	SPP coding conventions that cause problems for VMS FORTRAN compiler:
+
+	a)  multiple declarations, e.g.
+
+			int  ip
+			   ...
+			int  ip, this, that
+
+	    files:	/sys/fmtio/ctoi.x
+			/sys/fmtio/sscan.x
+			/sys/fmtio/chdeposit.x
+			/pkg/system/sort.x
+
+	b)  'real' function, e.g.
+
+		real (dval, 0)  -->  real (dval, 0.0)
+			/sys/fmtio/gctod.x
+
+	c)  array declarations in procedures, e.g.
+
+		procedure proc1 (array, count)
+		type  array (count)
+		int   count		# should be BEFORE array declaration
+					# (tries to use 'count' as a REAL)
+			/sys/fmtio/patmatch.x
+			/pkg/utilities/t_translit.x
+						makeset(), filset()
+
+
+	and(), or(), not()  -->  andi(), ori(), noti() ???
+		lots of references in /sys/fio/ to these procedures 
+		(added them for VMS, using andi(),...)
+	xor()  referenced in  /sys/vops/...axorki.x
+		(added xor() for VMS, using xori())
+
+	FIO
+		file mode "APPEND" -- create the file if non-existent??
+		UNIX (and now VMS) do this automatically, but system
+		reference document isn't clear about this.  Without this
+		feature,  /pkg/system/bugmail.cl and revisions.cl  don't work.
+
+	I/O drivers
+		ZMAIN passes the EPA of the read driver to IRAF_MAIN() ...
+
+		This is OK in UNIX (and VMS, for now), but may have cases 
+		where I/O is to different devices and the drivers are NOT 
+		compatible.  (I don't know enough of the internals of 
+		other operating systems to say for sure that this is a
+		problem, but it seems like it could be.)
+
+		Eg.   STDIN from a file and STDOUT to terminal
+
+		If the file and terminal drivers are incompatible, then
+		things won't work.  We may eventually have some problems
+		in this area with VMS, especially if we start to support
+		some network I/O access.  Eventually, we may store the
+		actual read/write function in the channel structure and 
+		check it whenever a read/write function is called; that is,
+		override the higher level IRAF I/O at the kernel level.
+
+	zardlp() function referenced in  /sys/etc/lpopen.x ??
+		(added dummy function for VMS)
+
+
+	modf()  function used in  /pkg/cl/unop.c
+		was missing from /sys/libc/
+		(added  modf.mar  to /sys/os/ for VMS)
+
+
+-------------------------------------------------------------------------------
+
+
+3.	Source file name changes
+
+
+	/pkg/softools/boot/spp/xpp/xpp_main.c  -->  xppmain.c
+
+	Necessary for file name mapping:
+
+		/sys/memio/ty_size.dat  -->  tysize.dat
+
+		/sys/memio/coerce.x, salloc.x, sizeof.x
+			include "ty_size.dat"  -->  include "tysize.dat"
+
+
+-------------------------------------------------------------------------------
+
+
diff --git a/doc/ports/vmsport.doc b/doc/ports/vmsport.doc
new file mode 100644
index 00000000..63e09193
--- /dev/null
+++ b/doc/ports/vmsport.doc
@@ -0,0 +1,1271 @@
+> From stsci Mon Dec 17 06:37:53 1984
+> Received: by lyra.noao.UUCP (4.12/4.7)
+> 	id AA15814; Mon, 17 Dec 84 06:37:48 mst
+> Date: Mon, 17 Dec 84 06:37:48 mst
+> From: stsci (Space Telescope )
+> Message-Id: <8412171337.AA15814@lyra.noao.UUCP>
+> To: tody
+> Subject: VMS .dir files
+> Status: R
+> 
+> Doug,
+> 
+> Had some questions on how you handle directory files, especially in VMS.
+> The filename mapping stuff takes a ".DIR" file on VMS and strips it off
+> for IRAF.  Is there a need to go the other way, and if so, how do you do
+> it ?  Do you keep a flag that says that a particular file is a DIRECTORY_FILE?
+> The reason I ask, is that ZFINFO is supposed to tell whether a file is
+> a directory file.  Before, for VMS, zfinfo just looked for the ".DIR"
+> extension.  I have since modified it to do an additional check on files
+> with null extensions, if it doesn't find the file in the 1st place.
+> (since testing the single directory bit in the file header on VMS takes
+> about 100 lines of code!!)  I guess my overall question here is do you map
+> the names back, somehow, for the case of zfinfo, or should I just keep my
+> extra little check in there in case a file with a null extension comes in?
+
+The directory files are unique in the filename mapping scheme because they
+have no extension in IRAF form, as when listing a directory (this is controlled
+by the extension mapping string in config.h).  This is necessary for
+compatibility with UNIX and to ease pathname generation, e.g., "a/b/c" is
+easy to generate if directory filenames are returned as "a", "b", etc.,
+but no so easy if they are "a.d", "b.d", and so on.  If we used the second
+form with the ".d" extension, and tried to add the ability to generate the
+extension on UNIX via an FSTAT call on each file, listing a directory on UNIX
+would be prohibitively expensive.  If we put the ".d" extension explicitly
+in the directory name on UNIX, then it would have to appear explicitly in
+all UNIX pathnames and other directory file references.
+
+For these and other reasons, it seemed that the simplest solution was to
+omit the extension for directory references.  Directory files are almost always
+referenced in a context where it is known that the file is a directory,
+hence the kernel can add the extension if it needs to.  Normally the kernel
+will receive a directory filename with a null extension.  ZFINFO should
+definitely make an explicit check to see if a file is a directory, rather
+than merely looking at the filename.  As far as I can remember, all other
+kernel primitives know if they are dealing with a directory file.  Note that
+ZFACSS was recently modified to add the DIRECTORY_FILE file type, used when
+checking for the existence of a directory file (the new filetype tells the
+kernel to add the ".dir" extension).
+
+The high level code does not maintain any flags telling which files are
+directory files.  In no case is a directory extension appended, except in
+a machine dependent name entered by the user.
+
+> Also, re filename mapping, it seems that filenames without extensions
+> (including
+> directory files once they've been mapped on VMS) don't get listed correctly
+> by the directory task in /pkg/system/.  It seems to be a problem with
+> /sys/clio/fntgfn.x, but I'm not sure - I'll see if I can locate it and fix it.
+> It does the following:
+> 
+> 	Files  --> File
+> 	Makefile  -->  Makefi
+> 	README   -->  READM
+
+The function of FNTGFN is to expand filename templates, i.e., read VFN's from
+a directory or directories using DIROPEN, select all filenames which match a
+pattern, returning a list of filenames as output.  It is unlikely that this
+code could perturb a filename in the manner described.  I recommend writing
+an SPP test program which calls DIROPEN to verify that VFN's are being read
+from the directory correctly, before doing anything to FNTGFN.  The latter
+package should be machine independent.
+ 
+By the way, the DIRECTORY task has bugs (machine independent) which are
+annoying, but should not affect the basic operation of the routine.
+These will be fixed eventually with a new version of DIRECTORY, but this
+is not a high priority item at present.
+
+> Other than that, things are coming along; the system and help packages are up
+> and running standalone, and the CL is coming along -- we had to backtrack a 
+> little and redo the old fixes for VMS...
+> 
+> Jay.
+
+
+> From stsci Mon Dec 17 13:58:50 1984
+> Received: by lyra.noao.UUCP (4.12/4.7)
+> 	id AA22347; Mon, 17 Dec 84 13:58:44 mst
+> Date: Mon, 17 Dec 84 13:58:44 mst
+> From: stsci (Space Telescope )
+> Message-Id: <8412172058.AA22347@lyra.noao.UUCP>
+> To: tody
+> Subject: iraf
+> Status: R
+> 
+> Doug,
+>   I hope you didn't get that last letter. I got hugh up on. Any way, I have a
+> couple of iraf questions. I will start with the simple one first.
+> How long should
+> EOF last in the terminal driver?? Currently I return EOF once for each time it
+> is typed. THis could be changed to only happening at beginning of line, or so
+> that EOF is given for every call to zgetty after the first EOF is typed.
+
+Treat EOF like a character, except that EOF is not returned if there is any
+data left to return.  An input line, delimited by EOF but not newline, is
+returned as a line of text not delimited by newline, followed by EOF in the
+next read.  The next read after that will return the next line of text from
+the terminal, i.e., EOF does not "stick".
+
+>   Also I got my problem fixed with task definitions. I had a tp = tp + TASKSIZ
+> instead of tp = tp + TASKSIZ * BPI. We had to changed to this format since
+> TASKSIZ * BPI is different from the actual size of the task structure in
+> VMS. I changed all of the tp++ and tp + 1 to this format. Also I decided to
+> use a macro instead to get to the next task structure so I didn't run into
+> the problem again.
+
+Right, I recognize that as one of the more subtle bugs that Jim discovered
+working with the prototype version of the system.  Sorry that the bugfix did
+not get into the version of the CL that you received.
+
+>   Now for a couple of problems. The cl currently gets up on its own, but will
+> not talk to any subprocesses. What happens is that it sends the one piece
+> of data to the subprocess, and then the subprocess kind of takes off and reads
+> millions of bytes of data instead of just 4 (internal length of data package).
+> It apears from the debugs that I get that zardpr is not being used to get
+> the data??? I don't know if you have seen this before.
+
+You might have a look at the UNIX version of ZFIOPR.  This driver contains
+support for debugging IPC.  Debugging IPC with the OS debugger is difficult
+or impossible.  I instead put a debugging switch in the driver (an external
+variable named debug_ipc, settable with the debugger before or during
+execution), which causes debugging information to be printed during task
+execution.  There is also a "-C" flag on the UNIX IRAF Main which causes
+the task to run standalone in CONNECTED mode, using the IPC driver, but packs
+and unpacks char data so that I can run in IPC mode from a terminal.
+Installing something similar in the VMS IPC driver would make it easier to
+debug problems involving IPC.
+
+If ZARDPR is not being called to read from CLIN it may be because the integer
+entry point address of ZARDPR, as returned by ZLOCPR, is not being passed
+correctly to the IRAF Main by the ZMAIN.
+
+I am not sure what the 4 byte quantity referred to is.  The 4 byte record
+header used in the UNIX IPC driver is peculiar to UNIX and is not necessary
+on a system which supports record level IPC i/o.  UNIX pipes are byte streams,
+causing record boundaries to be lost, and I had to use the 4 byte header to keep
+records intact across the pipe.  All knowledge of the 4 byte record header
+is concentrated into the UNIX IPC driver.  The high level code merely
+calls ZARDPR, ZAWRPR, and ZAWTPR to read and write headerless records.
+
+> Opps got hung up on again... 
+>   Another problem I had was with the -c flag. It seems that irafmain redirects
+> i/o to the null device on task startup and shutdown. After redirecting
+> STDOUT and STDERR, it sets them with fseti so that they are no longerT
+> 
+> Hung up again...
+> redirected, but does not swap the fd's back again. Then on task shutdown, it
+> does through and closes the users files that weren't kept and manages to
+> close the redirected stdout and stderr because they were copeid into a file
+> descriptor greater than last_fd. Have you seen this before??. This also
+> may be my problem with subprocess also.
+>                                 fred.
+> 
+
+The STDOUT and STDERR streams are redirected to the null file during
+process startup when in CONNECTED mode (when process is spawned by CL).
+Redirection is effected with FREDIR and cancelled with CLOSE, not FSETI.
+FSETI is used to set the redirect flag in FIO if the stream has been
+redirected remotely by the CL.
+
+The redirection to dev$null during startup and shutdown is a new wrinkle
+added to the IPC protocol since the Sys.Int.Ref.Man was written.  What
+happens is:
+
+	cl spawns subprocess
+					subprocess runs IRAF Main
+					Main redirs STDOUT,STDERR -> dev$null
+	cl sends envlist (sequence of
+	    SET statements)
+	cl sends chdir curdir
+	cl sends "_go_"
+					Main cancels redirection
+
+The CL (actually, etc$propen.x) must send the "_go_" command to the subproc
+to tell it that process startup is complete.  Output is discarded during
+startup to avoid deadlock due to two processes writing to the IPC at the
+same time.
+
+Redirection is cancelled when the "_go_" is received by closing the affected
+files.  The FD's are swapped back at CLOSE time.  If the redirection during
+startup is not being cancelled it is probably because the Main is not seeing
+the "_go_" command.
+> From stsci Thu Dec 20 09:05:22 1984
+> Received: by lyra.noao.UUCP (4.12/4.7)
+> 	id AA05472; Thu, 20 Dec 84 09:05:17 mst
+> Date: Thu, 20 Dec 84 09:05:17 mst
+> From: stsci (Space Telescope )
+> Message-Id: <8412201605.AA05472@lyra.noao.UUCP>
+> To: tody
+> Subject: help db
+> Status: R
+> 
+> Doug,
+> 
+> Jay here; having a bit of trouble with the help database.  Running help
+> standalone, I can do a mkhelpdb on lib$root.hd and it gets all the way to
+> the end before dying.  It seems to die when it tries to make the root/index
+> entry, though I'm a little shaky on what's actually going on there.
+> 
+> Does it read back the entire help db and then try to make a full index ?
+> If so, then the problem is probably in our binary file driver.  That's what
+> it looks like to me, anyway.  Any ideas, suggestions on where to look?...
+
+I could help more if I knew more about how it is dying.  On UNIX one usually
+gets a fault which can be caught by the debugger, after which one does a
+stack trace to find out where the crash occurred.  The most common cause of
+faults are memory violations of various flavors.  Unfortunately any bugs
+having to do with memory violations are usually hard to track down, because
+the fault is often not remotely related to the bug which caused memory to be
+overwritten.  In the event of a memory violation of unknown origin I usually
+take the brute force debugging approach, i.e., I first find out what region
+of memory is getting clobbered and then repeatedly rerun the program, doing
+a binary search for the code which is causing memory to be clobbered by
+setting breakpoints in time sequence.  This always works but requires intimate
+knowledge of the code and a good debugger.  Probably you should try to avoid
+this and check the low level routines first.
+
+From what you are saying it sounds like the problem is most likely in
+hdb_make_rhd() in helpdb.x.  I agree that the most likely cause of the problem
+is the binary file driver.  During compilation compiled help directories are
+appended to the help database.  This is done as follows:
+
+	NOTE is called to note the one-indexed XCHAR offset at which
+	    the next segment will be written.  FIO keeps track of this
+	    itself (not the kernel) hence this should not be the problem.
+	WRITE is called twice to append the two parts of a compiled help
+	    directory to the output file.  Since output is buffered there
+	    may or may not be a corresponding call to ZAWRBF.
+
+This sequence is repeated for each help directory in the system.  When the
+tree has been exhausted the file position is NOTEd and used to compute the
+length of the data area.  HDB_MAKE_RHD is then called to make the root
+help directory, taking the following FIO operations:
+
+	SEEK to the beginning of the data area.  This will lead to a file
+	    fault to the file buffer containing the seek offset, i.e.,
+	    ZARDBF will be called to read in a file buffer somewhere back
+	    toward the beginning of the file.  This is something to check
+	    since it is a random access and most or all file accesses thus
+	    far tested have been sequential.
+
+	READ is called to read in the entire data area.  The resulting kernel
+	    level operations are likely to be the following:
+
+		- ZAWRBF to flush the buffer at the end of the file
+		- a sequence of ZARDBF calls to read the file buffers
+		    containing the data segment (which is large, about 70KB).
+		- for each ZARDBF there will be one or more calls to AMOVC,
+		    which is optimized in assembler calling the VAX MOVC3
+		    instruction (check that).
+
+The memory allocation routines are absolutely crucial to all of this (and to
+the whole system), and are another possible source of trouble.  In particular,
+you might check ZRALOC, which is rarely used but is definitely used here.
+The things to check are the pointer (if the buffer moves, is the returned
+pointer a pointer to XCHAR) and the data alignment (if the buffer moves, the
+buffer contents should be simply copied as a byte array with no byte shifts;
+the high level code will shift the data to correct any alignment problems).
+
+> Also, the help tasks like lroff, mkhelpdb, and hdbexamine - can they be
+> run from under the CL ?  I can't seem to get them to work there , so I'm
+> just running them standalone...
+> 
+> Jay
+> 
+
+These tasks are available in the package SOFTOOLS and are nothing special.
+They should run just like any other task.  It is misleading because the
+source is in pkg$help and the task declarations are in pkg$softools.
+I will put a comment in the README.
+
+--Doug
+> From stsci Thu Dec 20 11:32:09 1984
+> Received: by lyra.noao.UUCP (4.12/4.7)
+> 	id AA06285; Thu, 20 Dec 84 11:32:02 mst
+> Date: Thu, 20 Dec 84 11:32:02 mst
+> From: stsci (Space Telescope )
+> Message-Id: <8412201832.AA06285@lyra.noao.UUCP>
+> To: tody
+> Subject: file name mapping
+> Status: R
+> 
+> Doug,
+>   I am running into a couple of small problems. I am trying to use VFNDEL
+> from xc. I have a file name t_rcardimage.x. I generate t_rcardimage.r and
+> then t_rcardimage.f. At this point t_rcardimage.f maps to tj8rcarde.for
+> which I would guess is correct. I then delete the entry for t_rcardimage.r
+> the mapping for t_rcardimage.f then changes to t_widsout.r. Have you
+> seen this before? Also from the cl if i delete a file in a directory and
+> then try to do a directory listing of that directory I get:
+> "Cannot open file drb4:[...]zzfnmap.zvf". May question is does the
+> filename mapping still have the mapping file open for write or read_write
+> access?? VMS has a tendancy to lock files against read if someone else is
+> writing it.
+>                                  fred.
+
+Fred--
+
+    This one is a bug in the high level code.  The filename mapping code could
+not delete files with long filenames properly.  There were two independent
+bugs, for which I have included fixes below.  I have tested this on UNIX
+after compilation with the VMS file parameters in config.h (that's the best
+I can do without going to a lot of trouble).
+
+The bug was such that file deletion of a file with a long filenames will have
+corrupted your zzfnmap.zvf mapping file (the first long filename will have
+been overwritten).  After the bug fix, however, the mapping file will again
+be readable and can probably be patched up with a rename or something.
+
+FIO knows whether or not the OS locks files opened for writing, as is the case
+for VMS.  If the file is locked by another process FIO will wait for it to
+become available.  FIO is careful to open the mapping file for as brief a time
+as possible to minimize contention problems.  Care is taken to avoid deadlock
+between concurrent processes in cases such as a rename where it may be
+necessary to open two different mapping files (what a pain that was...).
+This sort of thing should not be a source of problems unless there is a bug.
+See fio$doc/vfn.hlp if you want to know the nasty details.
+
+By the way, if a file such as "t_rcardimage.x" should appear as "t_rcarde.x"
+in a directory listing, that is a sign that FIO could not find an entry for
+the file in the mapping file.  You reported something like this a while back.
+Let me know if the problem should recur.
+
+	--Doug.
+
+
+[1] VFNMAP.X line 115, old ......................................:
+
+    define	FN_VFN		Memc[M_FNMAP($1)+($2*2-2)*LEN_FN]
+    define	FN_OSFN		Memc[M_FNMAP($1)+($2*2-1)*LEN_FN]
+
+[1] VFNMAP.X line 115, new
+
+    define	FN_VFN		Memc[M_FNMAP($1)+(($2)*2-2)*LEN_FN]
+    define	FN_OSFN		Memc[M_FNMAP($1)+(($2)*2-1)*LEN_FN]
+
+
+[2] VFNMAP.X line 729, old ......................................:
+
+    # entire MFD is written to the mapping file.
+
+    checksum = vvfn_checksum (Memi[mfd+1], (len_file - 1) * SZ_INT)
+    ntrys = ntrys + 1
+
+[2] VFNMAP.X line 729, new
+
+    # entire MFD is written to the mapping file.  Note that the
+    # file will contain garbage at the end following a file
+    # deletion (the file list gets shorter but the file does not).
+    # Compute checksum using only the valid file data, since that
+    # is how it is computed when the file is updated.
+
+    len_file = LEN_MFD - (MAX_LONGFNAMES - M_NFILES(mfd)) *
+	(SZ_FNPAIR / SZ_STRUCT)
+    checksum = vvfn_checksum (Memi[mfd+1], (len_file-1) * SZ_INT)
+
+    ntrys = ntrys + 1
+Re: file not closed when filename mapping --
+
+    I fixed the same bug in the version here, so you won't see it next time
+around.
+
+> From stsci Wed Jan  2 06:42:10 1985
+> Received: by lyra.noao.UUCP (4.12/4.7)
+> 	id AA26294; Wed, 2 Jan 85 06:42:05 mst
+> Date: Wed, 2 Jan 85 06:42:05 mst
+> From: stsci (Space Telescope )
+> Message-Id: <8501021342.AA26294@lyra.noao.UUCP>
+> To: tody
+> Subject: file i/o
+> Status: R
+> 
+> Doug,
+>   We had a problem with the interaction between iraf file i/o and the
+> zroutines. The problem seems to be with the asynchronousity. If we do the
+> same thing as unix everything flys, but if we make it asychronous, it falls
+> apart. The file name mapping works just fine, and so have our tests with it
+> running asychronously [[synchronously?]].  Is it possible that the iraf fio
+> plays with the buffer before the operation has completed??
+
+The FIO code was written to call ZAWTBF after every i/o request, before using
+the buffer, but this mode of operation has never been tested since UNIX is not
+asynchronous.  My feeling is that it is not worthwhile to test this mode of
+operation until FIO supports more than one buffer per file.  The current
+interface still supports only one buffer internally, so you have to wait on
+every i/o operation in any case, and having asynchronous primitives does not
+make much difference (I just use very large buffers when I want it to go fast).
+Unless you can find the bug in FIO without spending a lot of time, it might
+be best to leave this until I modifiy FIO to support multiple buffers,
+at which time the bug will certainly disappear.  For the moment it is
+sufficient to test the asynchronous features of the zroutines outside FIO.
+
+>   Has anything happened with the new process caching. We do the impression
+> (oops got) that there would be more changes in the cl. Something about having
+> a bunch of processes loaded but not having the nesting and always being at
+> the cl prompt? You had mentioned something about this before, and we were
+> wondering if it might have got lost somewhere in getting the tape.
+
+All of the process caching code is brand new, written to use the new process
+control code accessed via LIBC.  The CL process cache code is a package
+contained wholly within the file "prcache.c".  This version supports nesting
+of calls from one process to another (although deadlock will occur if the
+cache fills up).  The newest parts of the CL are the files "prcache.c",
+"main.c", and "bkg.c".
+
+>   Also with the text i/o the file size may not represent the actual size
+>   (in characters) of the file, due to VMS standard record files. Will this
+>   be a problem. Any Iraf created files will have the correct size since
+>   they are stream_lf.
+> 			  Fred & Jay
+
+This is ok, the file size need be known accurately only for binary files.
+For text files the file size is not used for anything serious (see the
+description of FSTT_FILSIZE in the manual page for ZFIOTX).
+
+Glad to hear that the filename mapping code is working well.  It is crucial
+to the port, and I was concerned about bugs since it is such a complex
+package.
+		Doug
+Fred and Jay:
+
+    Answers to recent questions follow.  Is the system ready yet for me to
+look at over the modem?  When you get it to a state where you feel it is
+working fairly well, I would like to fire it up and try a few things.
+
+	Doug.
+
+> From stsci Thu Jan 17 08:30:15 1985
+> Received: by lyra.noao.UUCP (4.12/4.7)
+> 	id AA10600; Thu, 17 Jan 85 08:30:03 mst
+> Date: Thu, 17 Jan 85 08:30:03 mst
+> From: stsci (Space Telescope )
+> Message-Id: <8501171530.AA10600@lyra.noao.UUCP>
+> To: tody
+> Status: R
+> 
+> Doug,
+> 
+> 	Here is a list of bugs, changes, suggestions, etc. compiled during
+> the port of IRAF to VMS.
+> 
+> 	Some of the bugs have the bug fixes listed here; others were too
+> elusive and/or time-consuming to try to figure out at this time.  When you 
+> get the latest, greatest VMS version of IRAF, what changes we made will 
+> certainly be there;  we'll probably send along RCS files as well so you could
+> easily update some of your files.  However, most of the changes are
+> just a few lines here and there.
+> 
+> 	We await any comments or any bug fixes you have there...
+> 
+> 				Jay and Fred
+
+Thanks a lot for the bug reports.  I will wait and install these bug fixes
+during the upcoming system integration period when I get the new VMS version
+of the system back from you guys.
+
+I have been working on some of the more subtle bugs here and will send you
+a bug list and/or code updates at some point.  I have a few hard to catch
+bugs to track down yet before this will be worthwhile.
+
+> P.S.
+> 	We were discussing using mapped sections such as sdas
+> uses for static files. There is one major difference in the way that
+> iraf and sdas handle static (image) files. In the sdas routine
+> a pointer is passed back to where the image resides in memory. This
+> is due to the way the mapped sections work in VMS. In Iraf the zroutine
+> is given a pointer to where the data is to reside, so we have to do
+> a memory copy for each image reference, and may not be more efficient
+> than just writing to or reading from disk. Can you see any easy
+> way around this problem, or maybe an additional flag to zopnsf which
+> indicates that a pointer is to be passed back from zardsf or zawrsf
+> for the data rather than a passing in a pointer to where the data is to
+> be read to or written from?    (fred)
+
+My impression from a glance at the VMS system services was that the create
+and map section function could be broken into smaller functions.  The idea
+was that ZARDSF, when requested to read/map file segment A onto memory
+segment M, could unmap M (from the paging file) and remap it onto A.
+A subsequent ZARDSF on the same M would unmap from file segment A and
+remap onto file segment B.  ZCLSSF would unmap file segment B (etc.)
+and remap onto the paging file.  When using the static file driver, the
+high level system code will see to it that M is always aligned on a virtual
+memory page boundary and is an integral number of pages.
+
+Will that work?  If not something can be done, but at least conceptually
+it makes sense to me, and it would eliminate artifical distinctions between
+the two types of i/o.
+
+> From stsci Tue Jan 22 12:44:59 1985
+> Received: by lyra.noao.UUCP (4.12/4.7)
+> 	id AA22373; Tue, 22 Jan 85 12:44:51 mst
+> Date: Tue, 22 Jan 85 12:44:51 mst
+> From: stsci (Space Telescope )
+> Message-Id: <8501221944.AA22373@lyra.noao.UUCP>
+> To: tody
+> Subject: vfn mapping
+> Status: RO
+> 
+> Doug,
+>   We are having a problem with degenerate directory names. It appears that the
+> filename mapping handles degenerate filenames, but no directory names
+> contained within the path to that file. Is this correct? I would guess that
+> the translation should be done in vfn_translate some where.
+>                                      fred.
+
+The mapping file is not used for directory names for performance reasons.
+First, OS filenames are not mapped at all.  An OS filename is any filename
+for which ZFXDIR returns an OS directory prefix (the test is necessarily
+machine dependent).  Pathnames containing directory names are parsed by
+VFN_TRANSLATE, extracting successive directory names.  Each directory name
+is processed through VFN_ENCODE to map illegal characters, then through
+VFN_SQUEEZE to make it fit in an OS filename.  It is possible that multiple
+directory names will map to the same internal name.
+
+It is possible to modify the mapping code to use the mapfile for long
+directory names, but I would prefer to make everyone use short names.
+Is the problem with names in the system you got from us?  We will change
+the directory names if so.  Long directory names will also lead to problems
+with truncation of pathnames, hence should be avoided in any case.
+> From stsci Wed Jan 23 10:40:52 1985
+> Received: by lyra.noao.UUCP (4.12/4.7)
+> 	id AA05645; Wed, 23 Jan 85 10:06:56 mst
+> Date: Wed, 23 Jan 85 10:06:56 mst
+> From: stsci (Space Telescope )
+> Message-Id: <8501231706.AA05645@lyra.noao.UUCP>
+> To: tody
+> Status: RO
+> 
+> DIFFERENCES /MERGED=1/OUTPUT=DISK$USER1:[IRAF.FRED]DOUG.TXT;1-
+>     DISK$USER1:[IRAFX.SYS.FIO]VFNTRANS.X;5-
+>     DISK$USER1:[IRAFX.SYS.FIO]VFNTRANS.X;4
+> 
+>   Also, back to the static file driver. There are a number of hitches with
+> mapping the file into the user's buffer. One problem with mapped sections
+> is that we may run into the working set limit or paging file limit when
+> mapping a file. Another is that the buffer pointer must point to a virtual
+> address which has not been "created", so the pages in the user's buffer
+> must be freed. The users buffer must be on a virtual page boundry.
+> Also remote files cannot be used in a mapped section due
+> to DECNET and RMS restrictions. Also in writting an image out to disk, the
+> create mapped section cannot be into the users buffer, since the data would
+> be lost, So a memory copy would be necessary. Also should a mapping be
+> undone after a wait, so that the buffer can be reused, and what should
+> be done about requests which overlap in some of the pages? Do you see any
+> easy ways around these? In sdas a pointer to where the data is to be read
+> or written is returned. This removes the problems of page overlap, memory
+> copies, and page allignment.
+>                                    fred.
+
+I think I need to go into more detail on the scheme I had in mind for the 
+static file driver, including more information on how FIO works.  The file
+i/o zroutines are designed to be called only by FIO under carefully controlled
+circumstances.
+
+FIO works internally by "paging" file segments the size of a FIO buffer into
+the FIO buffer.  A file is a series of logical pages, each the size of the
+FIO buffer, which is in turn an integral number of disk blocks in size.
+FIO guarantees that these logical pages will not overlap; if this were not
+the case, ordinary i/o would not work properly, let alone static file i/o.
+
+A "file fault" occurs when i/o is done to a file segment not currently
+mapped into a FIO buffer.  If the file is open for RW access the file segment
+will be read into the FIO buffer.  This is true for both reads and writes.
+A write causes the file segment to be faulted into the buffer, followed by
+modification of the buffer contents.  Nothing is actually written to the
+file until another file fault occurs, causing the modified buffer to be updated
+on disk.  There is one exception to this scheme: when a write occurs which
+would write the entire file segment, the read is skipped to save i/o.
+
+All of the above discussion concerns only FIO, and is independent of whether
+the file is a static file, an ordinary disk file, a DECNET file, or whatever.
+A static file is by definition a file which does not change in size while
+i/o is in progress.  At open time file space has already been allocated and
+the system knows exactly where the file blocks are, making optimization
+possible.  A static file is never created by ZOPNST.  It either already
+exists or is preallocated by ZFALOC.
+
+FIO buffer space for a static file is allocated before i/o occurs (before
+any sections are mapped) by the MEMIO procedure VMALLOC, which ensures that
+the buffer is allocated on a virtual memory page boundary.  VMALLOC calls
+ZMALOC to allocate a conventional buffer larger than necessary, computes
+the offset of the first page boundary, and returns a pointer to that page
+to the caller.  On VMS, VMALLOC would therefore allocate a potentially
+large segment of storage in the paging file.  The paging file space would
+probably be freed very shortly therafter, but it is possible to run out
+of space in the paging file if very large buffers are to be allocated.
+The virtual page count limit of the process must be large enough to
+accommodate the buffer, but since no i/o will be incurred the working set
+size should not matter.  If I understand VMS correctly, the principal
+expense in allocating a large, say 1 MB buffer will be the expense of
+initializing the associated 16 pages of process page table space.  This will
+likely incur several page faults (to fault in the pages of the page table),
+plus .1 second or so to initialize the page table entries.
+
+The initial operations required to map an entire section into memory for FIO
+are thus the following:
+
+	open calls ZOPNST to assign a channel for the section file
+	VMALLOC calls ZMALOC to allocate a buffer the size of the section
+	    (i.e., the size of the pixel storage file).  Pages are
+	    initially allocated from the system paging file.
+
+The next operation will almost certainly be a ZARDST to "fault" the file
+into the FIO buffer, which is probably the size of the entire image.  ZAWTST
+would be called next to get the status of the read.  No further FIO faults
+would be incurred while accessing the image, since all of the data is
+effectively accessible in memory.  Eventually ZCLSST or possibly ZAWRST,
+ZAWTST, ZCLSST would be called when the file is closed.
+
+I see the functions of the static file i/o routines in terms of VMS system
+service calls as follows:
+
+	ZOPNST	Assign file to a channel.
+
+	ZARDST	Unmap buffer pages with $DELTVA.  Map buffer pages onto
+		new section with $CRMPSC.
+
+	ZAWRST	Call $UPDSEC to update the section on disk.  Do non unmap
+		pages as they may be reused.  If the pages are not mapped
+		(very unlikely) perform a map and copy operation or just
+		return ERR.
+
+	ZAWTST	Static file i/o is not really asynchronous.  Just return
+		status.
+
+	ZSTTST	Easy.
+
+	ZCLSST	Unmap all sections associated with the file.  It may be
+		necessary to remap sections back onto the paging file to
+		keep the VMS memory allocator happy, but it is not necessary
+		for IRAF reasons since file buffer space is freed when the
+		file is closed.
+
+
+Response to specific questions:
+
+> The users buffer must be on a virtual page boundry.
+
+Alignment on virtual page boundaries is not a serious problem; the
+current VMALLOC procedure already does so.
+
+> Also remote files cannot be used in a mapped section due to DECNET and
+> RMS restrictions.
+
+The static file driver scheme works well here because it makes it possible
+to access files via DECNET if we wish to do so, by copying the data rather
+than mapping it.  This would be slow if the entire image were being mapped,
+but might be worthwhile in some cases, since the software would at least
+function.
+
+> In writting an image out to disk, the create mapped section cannot be into
+> the users buffer, since the data would be lost, So a memory copy would
+> be necessary.
+
+The buffer is mapped by a ZARDST call onto the section file, hence no
+copy operation is necessary.  ZAWRST merely updates any modified pages.
+
+> Also should a mapping be undone after a wait, so that the buffer can
+> be reused..
+
+I/o to mapped sections would not be asyncronous.  The wait primitive would
+only return a status value.  Pages would be unmapped only at close time
+and when the buffer is faulted (in a FIO sense) onto another section.
+
+> what should be done about requests which overlap in some of the pages?
+
+FIO does not permit such overlaps.  FIO divides a file into a series of
+logical pages the size of a FIO buffer.  All i/o is initiated on logical
+page boundaries.  The FIO buffer is an integral number of disk blocks in
+size.
+
+If there are serious problems with the scheme I have described (e.g.,
+because it does not fit the real VMS) then let me know and there are probably
+things we can do.  For example, VMALLOC could have a special kernel routine
+instead of calling ZMALOC, and might only allocate virtual space without
+mapping it, not using the VMS memory allocator at all to avoid conflicts.
+
+
+> From stsci@aquila.noao Wed Jan 30 11:21:12 1985
+> Received: from aquila.noao.UUCP by lyra.noao.UUCP (4.12/4.7)
+> 	id AA00912; Wed, 30 Jan 85 11:21:09 mst
+> Received: by aquila.noao.UUCP (4.12/4.7)
+> 	id AA21711; Wed, 30 Jan 85 07:28:33 mst
+> Date: Wed, 30 Jan 85 07:28:33 mst
+> From: stsci@aquila.noao (Space Telescope )
+> Message-Id: <8501301428.AA21711@aquila.noao.UUCP>
+> To: tody@lyra.noao
+> Subject: fortran hex values
+> Status: RO
+> 
+> Doug,
+>   We have just run into a non-protable problem. In VMS fortran hex values look
+> like '111111'x and in unix fortran they look like x'111111'. Neither compiler
+> will accept the other. (oops portable above). Do you know which is supposed to
+> be standard??. The other way around it would be to run all fortran files
+> through the cpp on our end, so that we can use ifdefs as you can under unix.
+>                              fred.
+
+
+The Fortran standard permits only decimal integer constants.  The octal and
+hex forms noted are both nonstandard exceptions and cannot be used in portable
+Fortran code.  There are many other things just like this, e.g., ! comments,
+byte, integer*N, logical*N, etc. datatypes, nonstandard intrinsic functions,
+do while, identifiers which are nonalphanumeric or which are longer than
+six characters, continuation longer than a few lines, inclusion of character
+in common blocks, use of normal data statement to initialize data in common
+blocks, passing an integer*2 to a function which expects an integer
+or vice versa, use of ichar for byte operations, and so on.  A simple
+preprocessor like cpp is a big help but will not solve problems like the !
+comments and identifiers longer than six chars, and I don't think it does
+anything about octal, hex, character, etc. constants.
+
+
+> ZGTENV (new kernel procedure)
+
+    I changed the specifications trivially to make it consistent with the
+other kernel procedures.  See the code in the new version of IRAF I recently
+sent you on tape.  I also modifed TTY to permit device unit specs etc in
+device names.  The ZMKDIR primitive has not been specified because it is not
+yet proven that we need it (I started to add it for making subdirectories
+off UPARM in the CL).
+
+
+From stsci Fri Feb 15 06:37:12 1985
+Received: by lyra.noao.UUCP (4.12/4.7)
+	id AA15277; Fri, 15 Feb 85 06:37:06 mst
+Date: Fri, 15 Feb 85 06:37:06 mst
+From: stsci (Space Telescope )
+Message-Id: <8502151337.AA15277@lyra.noao.UUCP>
+To: tody
+Subject: IRAF things...
+Status: RO
+
+Doug,
+
+Got the tape read on to VMS with rtar;  had to make some small mods to read
+from tape.  Seems the C lib read() function can't handle it.  We found all
+the different files and new files, and are remaking the entire system.
+
+Some thoughts and questions:
+
+> 1.  Fred was wondering whether there exists some documentation on XC and Mklib
+>     other than what's in the source files.
+
+There is no additional documentation at present.  XC is however much
+like the UNIX cc and f77 commands.
+
+> 2.  In much of the GIO, FIO, IMIO source files, you have 2 conventions for
+>     include files, namely  include "gio.h" and include <gio.h>.  This works
+>     fine in UNIX because you have linked files to iraf$lib/, but on VMS this
+>     means we have to have 2 copies of the .h files.  We are taking it upon
+>     ourselves to change all the "fio.h", "gio.h" etc. to <fio.h>, <gio.h>,...
+>     It makes more sense to us, and to IRAF in general, it seems.  Is this
+>     okay with you?
+
+I agree that it is best to avoid links for portability reasons, but sometimes
+they make things much easier.  Regarding the "file" and <file> problem, I agree
+that it is desirable to have only one copy of an include file (and of course
+the link provides this on UNIX).  To eliminate the possibility of error on VMS
+we will have to get rid of the "file" references, but only in cases where the
+named file is global, i.e., referenced in more than one directory.  Whenever
+possible I use local include files rather than global ones to reduce the
+coupling between different parts of the system, and this should not be changed.
+
+This problem with eliminating the local copy of a global include file is
+that the package source is no longer self contained.  When a package is
+listed or moved the included file may be omitted.
+
+Include files are not the only linked files.  There are also linked libraries
+and executables.  In all cases I have tried to restrict the number of links
+to 2 to make it obvious where the second entry is.  The use of links for
+libraries and executables can be eliminated by use of file moves or copies,
+e.g., with a "make install" in the package Makefile (see pkg$cl/).  This
+solution works fine for executables, but there are problems with libraries.
+Probably the best solution is to modify Mklib to permit library names like
+"lib$libsys.a".
+
+> 3.  Some of the VOPS routines have .s versions as well as .x ones.  The 
+>     Makelib files don't always use the .s files, but they're there.  We've
+>     been converting your .s files to VMS .mar files (added to the filename
+>     mapping pairs), and using them instead of the .x files, updating the
+>     Makelib files appropriately.  Some of the .s files (e.g. /vops/AK/aadd*.x)
+>     are simply output from the fortran compiler, possibly w/ a few things
+>     taken out.
+
+Sounds good.  It seems to me that we can have both the unix and vms assembler
+sources in the same directory with the filename mapping selecting the file to
+be used when the extension is mapped (on VMS, the UNIX files should appear
+as "file\.s" in directory listings).  Assembler sources which appear in
+directories but which are not referenced in the Makelib are garbage and
+should probably be deleted.  In some cases, e.g., AADD, there may be no
+advantage in having a VMS assembler version since the VMS Fortran compiler
+is better than the UNIX one.
+
+> By the way, we changed the IPC routines on VMS to use shared memory regions
+> instead of mailboxes.  This was due to lots of problems we had with ^C
+> interrupts and the mailbox I/O.  Shared memory regions helped a lot,
+> but are still prone to the problems occasionally.  Your latest changes
+> dealing with interrupts look they will help us a lot too.  In any event,
+> the shared memory IPC is much faster and seems a lot more reliable than
+> mailboxes.
+> 
+> 			Jay and Fred
+
+The bug fixes I made should help a lot but do not yet fully solve the problem.
+Also, in the UNIX IPC driver I had to disable interrupts while writing a record
+to ensure that the data structures would not be corrupted.  You might need to
+do something similar.
+
+What is your schedule for converting to VMS version 4.0?  We are still
+running 3.7, and should coordinate the conversion to 4.0 between the
+observatories.  The 8600 will run 4.0, and should arrive sometime in May.
+We should convert to 4.0 sometime before then.
+
+Do not waste time trying to get the new GIO stuff working yet.  We are still
+actively working on the many pieces of the graphics subsystem and it is not
+yet completely installed nor user tested.  The GIO/NSPP kernel should be
+completed later this week or next and then we will complete the installation.
+I can send you a tape containing only the affected files at that time if you
+wish.
+			Doug
+> From stsci Wed Mar  6 14:00:12 1985
+> Received: by lyra.noao.UUCP (4.12/4.7)
+> 	id AA29984; Wed, 6 Mar 85 13:59:45 mst
+> Date: Wed, 6 Mar 85 13:59:45 mst
+> From: stsci (Space Telescope )
+> Message-Id: <8503062059.AA29984@lyra.noao.UUCP>
+> To: tody
+> Subject: IRAF
+> Status: RO
+> 
+> Doug,
+> 
+> Jay here... IRAF VMS is coming along.  Having some difficulties dealing with
+> 4.0 though, asI'm sure Peter has told you about.  The filename mapping
+> stuff in particlular - we're keeping it as 3.x filenames even though
+> it would be possible to convert to the nice longer ones in 4.0.
+> But then it's not possible to go back very easily.  W    Something we have
+> to think about some more and which Peter may talk with you about.
+ 
+At some point we should reconfigure the system to use the long filenames.
+This requires reloading the system with RTAR, editing the filename parameters
+in the <config.h> file, and recompiling the system.  Any system dependent
+makefiles or VMS .com files you guys have added would also have to be changed.
+I am considering renaming some files in the directories for the core system
+to minimize these sorts of problems, allowing us to get the basic system up
+and running and then use the system to handle the filename mapping required
+for the applications directories.  This does not solve the Make problem unless
+we add an IRAF Make to the SOFTOOLS package, which is probably the thing to do.
+
+> Your ideas on using mapped sections for the VMS static file driver look
+> okay, thou and should work, with some slight mods,
+> but we haven't gotten around
+> to it yet (may be lots of line noise here...).
+> Also some other enhandcements
+> are in the queue for VMS, time allowallowing...
+> 
+> Had a question re Help and Help dtaatabases.
+> In SDAS, we have 2 choices for
+> Help under IRAF - 1) use 1 big Help db with IRAF and SDAS help combined, or
+> 2) have a separate SDAS help db.  I've done some simple tests with 2
+> separate dbs and it doesn't look to good.  If you've run help in IRAF and 
+> then turn around and specify a new db, does  the new database get read
+> in entirely?  One can envision an SDASHELP script that does:
+> 		set helpdb=sdas$sdas.db
+> 		help ...
+> 		set helpdb=dev$help.db
+> But this method can be terribly slow if you go back and forth between IRAF
+> and SDAS help and requires a separater task , SDASHELP, to invoke it.
+> 
+> Maybe I'm not  don't fully understand the details of the
+> helpdb stuff...would it be
+> possible to have a couple of helpdb's loaded in memory at the same time, or
+> a list of helpdb's to search in the event of a 'help'.?  Or, should we
+> just use one huge helpdb for IRAF and SDAS and avoid all these problems??
+
+          Jay
+
+I think the best solution is for each system to have one big help database
+for all packages.  I see no problem with this, but the current help database
+facilities are probably not up to the task and will have to be replaced
+eventually possibly with a DBIO based version.
+
+
+> From stsci Sat Apr  6 07:52:33 1985
+> Received: by lyra.noao.UUCP (4.12/4.7)
+> 	id AA07328; Sat, 6 Apr 85 07:52:27 mst
+> Date: Sat, 6 Apr 85 07:52:27 mst
+> From: stsci (Space Telescope )
+> Message-Id: <8504061452.AA07328@lyra.noao.UUCP>
+> To: tody
+> Subject: Mapped sections on VMS
+> Status: RO
+> 
+> Doug,
+> 
+> Finally got around to implementing a static file driver for VMS using mapped
+> sections.  Your ideas were partially used here, as well as the stuff I threw
+> together for the IPC driver using shared global sections.  However, there
+> are 2 problems which don't want to be solved very easily.
+> 
+> 	1.  When closing a static file (mapped section file), the pages must
+> 	    be unmapped.  Since they are mapped within the IMIO via VMALLOC,
+> 	    I can't unmap them at the Z-routine level because of the way ZMALOC
+> 	    works (puts the count in the longword ahead of the returned buffer
+> 	    address).  So the pages must be unmapped before the call to ZCLSSF.
+> 
+> 	    However, I have not been able to get this to work.  That is, even
+> 	    unmapping the pages and then closing the file doesn't work very well
+> 	    This may be due to some incompatabilities between the $CRMSPC
+>	    ssystem
+> 	    service and the LIB$GET_VM() routine used by ZMALOC to get virtual
+> 	    memory.  Seems that using the $CREVTA (create virt address space)
+> 	    doesn't work too well with the LIB$GET_VM - in fact, DEC warns about
+> 	    using them together, since they don't communicate with each other.
+> 
+> 	    The effect of this is that the image file remains open until your
+> 	    executable image exits - the close doesn't really close...
+> 
+> 	    The only way I see around this is to rewrite ZMALOC/ZRALOC/ZMFREE
+> 	    to use $CREVTA/$DELVTA and then hope for the best, or possibly
+> 	    use another idea you had, of having a special Z-routine for a
+> 	    allocating virtual memory on page boundaries w/out mapping it...
+> 	    maybe that would work, as long as the pixel-file buffers were
+> 	    unmapped before the call to ZCLSSF.
+
+I thought the memory allocation might be a problem, in which case the best
+solution is probably to add two new kernel procedures (sigh) to be used to
+allocate and free pages of virtual memory independently of the ZMALOC allocation
+facilities.  The pages would initially be unmapped and would not get mapped
+until a ZARDSF call was made.  Since we would then be able to package the
+virtual memory allocator and static file driver together in a self contained
+unit, we should be able to do whatever needs to be done to make it all work.
+If this looks reasonable I will have to generate some specifications for the
+kernel procedures and work out the details of the high level code (not a big
+task).
+ 
+> 	2.  If you open an image file w/ READ_WRITE access, any changes made
+> 	    to the buffer will be made in the file, whether or not a call to
+> 	    ZAWRSF is made.  This is the way mapped sections work on VMS and
+> 	    I haven't found a way around it yet.  This could be a potentially
+> 	    major obstacle...
+ 
+I don't see any problem here.  If FIO writes into a buffer opened on a file
+with read write access, the file is expected to be modified.  The only
+difference between this and normal i/o is that the write may occur sooner
+and cannot be cancelled, but there is no software in the system which depends
+upon such subtle semantics.
+
+> Peter probably talked to you a few times about device specifications within
+> IRAF, possibly of the form   set stdimage=(iis,image_unit_2)  or something of
+> the sort.  Support for this is definitely needed at some higher level than
+> the kernel.  For the line printer driver, I had to play all kinds of games to
+> map the printer names without having to recompile the ZFIOLP source and relink
+> the system package.  Basically, I used some VMS means to find out where 
+> iraf$dev/ was and then read a file called "lprtable.vms" which had things like
+> 
+> qms	LCA0
+> printronix  SYS$PRINT
+> 
+> By setting printer=qms for example, 'qms' would be looked up in termcap and
+> satisfy all that stuff, then at the ZFIOLP level, qms would be mapped to
+> the VMS queue LCA0.
+> 
+> For things like this, it would be nice to have some system-dependent device
+> mapping table that is read at a level higher than the kernel, that would
+> map a device-type (for termcap/graphcap/printcap/...)
+> into an OS/system-dependent
+> name or queue_name.  For example:
+> 
+> 		qms    LCA0
+> 		deanza ABC0:	(i.e. some VMS device name)
+> 			...
+> 
+> I know it's easy in UNIX to have these tables built into the kernel, so all
+> you do is a 'make' and IRAF is remade.  In VMS, this is not so easy, and we
+> would like to be able to distribute executables.  Also, our RCSMake hasn't
+> worked since VMS V4.0 came along -- we're using Mklib and DCL command
+> procedures everywhere.
+> 
+> I think this kind of device mapping would not be hard and would make it easy
+> to add devices without remaking part of the system. 
+
+I agree that a runtime table lookup would be nicer in some cases than a
+compiled table.  I suspect however that the structure and contents of the table
+may be too machine dependent to be worth trying to standardize.  The easiest
+solution may be to have the kernel read the table, rather than IRAF.  In that
+case it may be more appropriate to put the table in the OS directory, rather
+than in DEV.  It would not be difficult to call to the ZFIOTX primitives
+directly to read such a table.
+
+Some information can now be included in the device specification in the
+CL environment.  Peter mentioned a syntax such as
+
+	deanza!unit=2
+
+or some such.  Anything can follow the ! and is assumed to be system
+dependent.  The high level code will ignore the ! and all that follows
+in the termcap and graphcap access, but will pass the full string on to
+the kernel to parse as it wishes.
+
+
+> From stsci Thu May  9 05:41:11 1985
+> Received: by lyra.noao.UUCP (4.12/4.7)
+> 	id AA17243; Thu, 9 May 85 05:41:06 mst
+> Date: Thu, 9 May 85 05:41:06 mst
+> From: stsci (Space Telescope)
+> Message-Id: <8505091241.AA17243@lyra.noao.UUCP>
+> To: tody
+> Subject: IRAF
+> Status: RO
+> 
+> Doug,
+> 
+> Jay here;  have had a hell of a time trying to login to your system, though I
+> think it's a problem with our phone system - which means you're probably
+> having trouble getting in to ours as you did before.  
+ 
+I have been having lots of trouble getting modem access, but have not tried
+it for a week or so.  The next test will be trying to send this mail.
+
+> In any event, a few items/questions...
+> 
+> Peter talked to you about the filename mapping and using actual VMS names in
+> the CL.  We initially thought it was a filename mapping problem, but you were
+> right in that it is already handled quite well.  The problem, as we quickly
+> discovered, is that most of the tasks which open files, handle lists of files
+> and templates.  The template matching code is the problem with respect to
+> VMS names, since things like  "[a-zA-Z0-9]*"  can be used as a filename, and
+> using a VMS name like  [iraf.jay.cl]file.dat  is processed as a template.
+> I don't see a real easy way around it - Peter's suggestion about quoting all
+> OS-dependent entities with !'s may be the answer, meaning VMS names would
+> be   ![iraf.jay.cl]file.dat!  on the command line...  Sorry if you went about
+> the filename mapping code looking for this non-existent bug...  If !'s are
+> used, some higher-level decoding must be done, but I'm not sure exactly where,
+> probably in the template stuff and the filename mapping...
+
+I see the problem now and of course you are right, the template expansion code
+is at fault.  It is not out of the question to consider changing the logical
+directory metacharacter to something less troublesome, e.g., one of "!@%^".
+It should be a character which satisifes the following criteria:
+
+	not routinely used in filenames on any of our target systems
+	not an operator character when "lexmodes=yes"
+
+Unfortunately the $ fails criteria number one.  Let me know what you think of
+such a change and I will discuss it with my group in a meeting on Wednesday.
+It is not too late to make such a change if it will make life significantly
+easier on VMS.
+
+> Sometimes (a lot less now than before) we have a situation where a connected
+> subprocess gets astray and is running while we are back at the CL, i.e. doing
+> a 'prcache' shows a state of 'R' for the process.  'Flprcache' can't kill it,
+> and on logout, the CL will hang forever for what is seemingly a running
+> process.  Is there a way we can just kill these guys off, especially on
+> logout?  Seems to
+> me that connected subprocesses should never be asynchronous anyway, so being
+> in this state is really an error, though maybe there are future ideas I'm not
+> aware of.  In any event, sometimes an interrupt at a certain time can put a
+> subprocess in this sort of state and making logging out hang the process, and
+> the user will need to type ^Y to get out on VMS.  Have you seen this type of
+> occurence on Unix, and if so, have you any ideas on how we might combat this
+> portably?  If you don't see it there, we can just do some "#if vms" sections
+> in the CL to make sure subprocesses die on logout, but I'm hoping for a more
+> portable method.
+
+We also sometimes get hung processes with state R (apparently running).  This
+happens rarely but is evidently a bug in the system independent code, which
+I will fix eventually.  I may not be able to prevent processes from getting
+into such a state, but I should be able to make the system detect such a state
+and recover automatically.
+
+	- Doug
+	13 April 85
+> From stsci Thu May 23 06:16:18 1985
+> Received: by lyra.noao.UUCP (4.12/4.7)
+> 	id AA11890; Thu, 23 May 85 06:16:14 mst
+> Date: Thu, 23 May 85 06:16:14 mst
+> From: stsci (Space Telescope)
+> Message-Id: <8505231316.AA11890@lyra.noao.UUCP>
+> To: tody
+> Subject: major portability problem in fortran
+> Status: R
+> 
+> Doug,
+>   We have run into a snag up here. The problem is with fortran integer
+> constants. We currently have iraf moved over to the Sun and I was working
+> at getting it up and running. It seems that all integer constants are
+> passed as I*4. This causes problems for functions that expect I*2 values
+> (xpp character constants). Due to the byte ordering the value which
+> gets to the other end is the high bytes rather than the low bytes of the
+> I*4. This problem would also exist going from I*2 to I*4. Do you know
+> of any easy (portable) way to type cast constants in fortran. The other
+> method I considered was putting he character constants into the string
+> array that gets created by either rpp or xpp (I can't remember which). This
+> would solve the problem for xpp characters, but would not solve any
+> problems for xpp routines expecting short parameters and getting an I*4
+> constant.
+>                                fred.
+> 
+
+1. Discussion
+
+    I knew this would be a problem but could see no easy way to address the
+problem until we had access to a non-DEC machine with the bytes in an integer
+reversed.  It is considered an error in SPP if the programmer declares an
+argument as I*2 and passes an I*2, or vice versa.  Similar problems occur if
+the mismatched types are int and long or int and bool, or if a procedure is
+passed the wrong number of arguments.  Such bugs will go unnoticed on a DEC
+machine because of the architecture (or Fortran implementation).  The first
+port of IRAF to a non-DEC machine will require finding all such bugs.
+
+I had always planned that my group would do this kind of debugging, but have
+no objection if you wish to push ahead and find the bugs for us.  The rule is
+that an integer constant appearing in an argument list must be declared as
+an integer argument in the called procedure.  If a short, char, or long is
+required than an explicit type coercion must be used, e.g., "(a,long(1),b)".
+A character constant, e.g., 'a', is defined as an operand of type char.
+
+It is up to the programmer to use explicit type coercion where necessary to
+match the datatypes of actual and dummy arguments.  In the case of the
+character constant I expected that we would have to add a switch to the
+preprocessor to automatically add a call to a I*2 coercion function when
+a character constant is used as an argument to a procedure.  Of course
+Fortran does not define such a function since I*2 is itself non standard
+Fortran.  The VAX/UNIX Fortran compiler does not provide such a function,
+but then none is required since I*2 and I*4 are interchangeable as arguments
+on the VAX.  Compilers for machines where this is not the case would hopefully
+provide such functions.  The AOS compiler does, but I never checked the
+UNIX implementation on non-Dec machines.  It does not surprise me if the
+SUN/UNIX Fortran compiler omits the INT2 and INT4 (or whatever) intrinsic
+functions.
+
+My plan if the host compiler did not provide INT2 and INT4 intrinsic functions
+was for the compiler to generate a Fortran temporary variable of the necessary
+type.  This will always work but requires care to implement in the current
+preprocessor due to the complications of statement labels, error checking, etc.
+If the time has come then I can do this or perhaps you would like to have a
+go.  An easier, but less attractive solution might be to add the intrinsic
+functions to the Fortran compiler itself and report the extension to SUN.
+If this were done the Fortran generated for 'a' would be 'int2(97)' when the
+paren level is greater than zero, skip the INT2 otherwise.
+
+In retrospect I think it would have been better to define character constants
+as integer rather than char values.  It is not too late to make such a change
+to the language definition but doing so will introduce bugs into existing code.
+Since we have not already debugged such code, this is not a great problem.
+Rather than find such bugs at run time, I would do a pattern search of the
+entire system looking for occurrences of ' within parens, then examine each
+such occurence interactively.  We should really do this ourselves for our
+own code, rather than having you guys do it.
+
+
+2. Conclusions
+
+    Having thought all this through, I think the best course of action is the
+following:
+
+    [1] Change the SPP language definition to define a character constant as an
+	integer, rather than char value, e.g., 'a' would be exactly equivalent
+	to 97 in all contexts.
+
+    [2] Modify XPP to declare and initialize hidden Fortran I*2 and I*4
+	intermediate variables whenever the coercion functions "short", "char",
+	or "long" appear in SPP code within the body of a procedure.
+
+It would be best for NOAO to do this since we are responsible for the code
+which is causing the problem.  There is a big merge coming up with the
+installation of VMS IRAF at NOAO, and that would be an appropriate time to
+address the problem.  If you cannot wait and wish to forge ahead, feel free
+to do so, but please keep notes on the changes required (I would expect there
+will be only a few dozen such occurrences).
+
+
+3. Other
+
+    We are in the process of submitting a request to NSF to purchase a SUN
+system for delivery this fall to Tucson.  I plan to port IRAF to the SUN,
+including special performance enhacements for disk access and an interface
+for the Sky Warrior array processor.  Anything you guys (or JPL) do in the
+interim will of course help make this easier.
+
+The JPL port to the JUPITER running the ISI version of 4.2BSD UNIX has run
+into serious problems with the ISI Fortran compiler, which turns out to be
+untested and quite buggy.  An AOS port has also begun, with Steward doing
+most of the work.  I would like to eliminate this type of bugs from the system
+before these sites really attempt to bring the system up.
+
+By the way, in the process of trying to compile IRAF on the JPL system we
+found two bugs in the SPP compiler, both caused by the wrong number of
+arguments to a procedure.  One was in XPP (xppcode.c) and can be found with
+LINT.  The other was in RPP in the file "rpprat/errchk.r", in the call to the
+procedure GNBTOK.  Presumably you have already found both of these problems
+since you have already succeeded in compiling the system.
+
+Other bugs were found in OSB in the same port.  Some of the ACHT procedures
+had bugs, the Makelib file had a bug.  In OS in the ZCALL file, "pointer to
+function" was being used where "function" was required; the UNIX/C compiler
+does not complain about such usage.  If you have not already found these
+I can supply notes (they will be fixed on the next tape you receive in any
+case).
+> From stsci Thu Jul 11 05:33:23 1985
+> 
+> Doug, a few short notes...
+> 
+> 1. XPP
+> 
+> The 'lexyy.c' file for the new XPP (output of 'xpp.l') causes the VMS C V1.5
+> compiler to bomb of a symbol table overflow, so we're still using the old
+> XPP. I tried the C V2.0 compiler (on our 8600) and it fixes this problem,
+> but spouts out other warnings; I'll have to check them out when it gets
+> installed on our machine.  This is just a warning;  I don't know which
+> version you're running. 
+
+I have had the V2.0 C compiler installed on the 8600 and that is what I will
+be using when I recompile the CL etc., hope it does not give serious problems.
+
+> 2. RPP
+> 
+> The file  '...imdis/cv/load.x'  causes RPP to stop somewhere and say it's
+> got a storage overflow.  I split the file into 2 files (load1.x and load2.x)
+> and things work okay.  Don't know if you have this problem, too.
+ 
+Just want to make sure you know (I already told Peter) that the CV code is
+preliminary and will be changed significantly.  I am not happy with it yet
+and it will be reworked considerably before being installed (ideally the
+display interface subroutines Starlink is working on would come along in time
+to prevent a third major revision).  On the other hand, either the old display
+using the IMIO interface or the new CVL (to eventually replace "display" and
+inherit the same name) are both infinitely faster than the infamous SDAS image
+load code I have been hearing about.  PLEASE SPEED THAT THING UP!!  I have
+been overhearing comments from the astronomical community about how slow "IRAF"
+is, following the recent SDAS/IRAF demo.  People do not understand that IRAF
+and SDAS are quite different things, or that SDAS is not using IRAF yet for
+anything having to do with image display or vector graphics.
+
+The IRAF image load software runs 12 clock seconds on an unloaded 750, and
+should run twice as fast as that on a 780 with its faster cpu and faster,
+asynchronous i/o system (512 square by 16 bit image).  Note that only standard
+hight level IRAF interface software is being used and the DISPLAY program is
+a sophisticated program with lots of fancy options.  This proves that is it
+possible to have features and speed, too.
+
+> 3. VMS Kernel 
+> 
+> I wrote an assembler version of the str*() routines for VMS last year to
+> remove dependencies on the VMS C libraries (str.mar).  There are 2
+> "phantoms" in there that have been known to cause access violations at
+> randomly spaced intervals and disappear when you try to throw in extra
+> code to debug them. The two lines containing the 'DECB' instruction should
+> be changed to 'DECL' instead; subtracting 1 from an address can have strange
+> effects when only the low-order byte is changed!  This is an old phantom
+> which has finally been killed, but as we all know, phantoms have brothers... 
+> 
+> 				Jay
+
+Unless it can be demonstrated that the assembler versions of the string
+routines are a good deal faster than the C versions in LIBC, I do not plan
+to use them.  I will look at the /mach output for the C versions before
+deciding.  If the assembler versions used (already use?) the VMS string
+instructions that would be different.
+