From fa080de7afc95aa1c19a6e6fc0e0708ced2eadc4 Mon Sep 17 00:00:00 2001
From: Joseph Hunkeler <jhunkeler@gmail.com>
Date: Wed, 8 Jul 2015 20:46:52 -0400
Subject: Initial commit

---
 doc/vmsiraf.hlp | 681 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 681 insertions(+)
 create mode 100644 doc/vmsiraf.hlp

(limited to 'doc/vmsiraf.hlp')

diff --git a/doc/vmsiraf.hlp b/doc/vmsiraf.hlp
new file mode 100644
index 00000000..91530ee5
--- /dev/null
+++ b/doc/vmsiraf.hlp
@@ -0,0 +1,681 @@
+.help install Aug86 "VMS/IRAF Installation Guide"
+.sp 3
+.ce
+\fBVMS/IRAF Installation and Maintenance Guide\fR
+.ce
+(draft)
+
+.ce
+Doug Tody
+.ce
+February 22, 1986
+.ce
+(revised August 17, 1986 for VMS/IRAF V2.3)
+
+.nh
+Introduction
+
+    The initial port of IRAF to VMS was carried out primarily by Fred
+Rommelfanger and Jay Travisano at STScI beginning in the fall of 1984.
+Fred and Jay implemented the VMS/IRAF kernel and are the real experts on the
+functioning of that part of the system, although VMS/IRAF is now supported
+solely by NOAO.  The VMS version of IRAF was installed on the NOAO VAX-8600,
+which runs VAX/VMS, in the fall of 1985.  Much work has been done on both
+the UNIX and VMS versions of the system since that time, and the VAX 8600
+running VMS/IRAF is now the primary data processing facility at NOAO/Tucson.
+All IRAF software development continues to be done on UNIX/IRAF, with new
+software continually moving from UNIX/IRAF to VMS/IRAF at weekly or even
+daily intervals.
+
+The distribution tape is a snapshot of our local VMS/IRAF system.
+The device and system configuration tables come configured for our system,
+hence will have to be modified as part of the installation process.
+These modifications are discussed in detail in this document.  To simplify
+the installation process as well as future upgrades, we have tried to isolate
+the site dependent files to the minimum number of directories, i.e.,
+DEV, HLIB, and LOCAL.
+
+.nh
+System Installation
+
+    Version 2.3 of VMS/IRAF has already been installed at a number of early
+test sites with little trouble.  An installation typically takes about an hour,
+perhaps longer if relinking is necessary.  Interfacing new graphics terminals
+or image displays can take much longer, of course, and we will only touch
+upon such matters in this draft version of the installation guide.
+
+.ls [1] \fBSystem Configuration\fR
+
+Login as SYSTEM and run the AUTHORIZE utility to create an account for
+a user named IRAF.  Select a disk device with sufficient free space for the
+system (see [2] below).  If necessary, the system can be stripped after
+installation to save space, but the full amount of space will be needed
+during installation.  Set the IRAF login directory to [IRAF] for now (we will
+need to change it later).  Do not worry about VMS quotas and
+privileges yet; this is not a concern during installation and is discussed
+in a later section.  In this and all the following examples, names like
+DISK:, TAPE:, etc. denote site dependent device names which you must supply
+values for.
+
+.ks
+.nf
+	$ run sys$system:authorize
+	UAF> (etc)
+.fi
+.ke
+
+Add the following statement to the system SYLOGIN.COM file, making the
+appropriate substitution for DISK.
+
+	$ IRAF :== "@DISK:[IRAF.VMS.HLIB]IRAFUSER.COM"
+
+In pre-V2.3 versions of VMS/IRAF it was necessary to define a system or
+job logical name for each disk an IRAF user might need to access which
+did not contain the $ character, since $ is the logical directory
+meta-character in IRAF virtual filenames.  This step is no longer necessary
+as the $ can be escaped with backslash in IRAF virtual filenames, e.g.,
+"usr\$0:[iraf...]".  The MKIRAF script will automatically insert the escape
+characters when building the LOGIN.CL file; do not escape the $ characters
+in logical name definitions in IRAFUSER.COM.
+.le
+
+.ls [2] \fBRead the BACKUP Tape\fR
+
+Login as IRAF (you will get a LOGIN.COM not found message which you should
+ignore) and run the VMS BACKUP utility to read the BACKUP tape provided.
+The tape contains approximately 6600 files in 240 directories, for a total
+of 41 Mb or 81,200 blocks (including binaries).
+
+.ks
+.nf
+	$ mount/foreign TAPE:
+	$ set default DISK:[iraf]
+	$ backup/rew TAPE:iraf.bck/select=[iraf...] [...]
+.fi
+.ke
+
+It typically takes half an hour or so to read the tape on a lightly loaded
+system.
+.le
+
+.ls [3] \fBEdit the Files that Describe the Host System\fR
+
+As far as possible, we have tried to condense knowledge of the host system
+into a few text files which are read at run time by IRAF.  The following
+files must be edited before the system can be run.
+
+.ls 4 [IRAF.VMS.HLIB]IRAFUSER.COM
+This file defines the VMS logical names and symbols needed to run IRAF.
+The site dependent ones are grouped at the beginning of the file.
+.ls 10 IRAFDISK
+Set to the name of the disk the [IRAF] directory is on.
+.le
+.ls 10 IMDIRDISK
+Set to the name of a public scratch device.  The MKIRAF script will try to
+create the default user image storage directories on this disk, e.g.,
+IMDIRDISK:[USER].  All potential IRAF users should have write permission
+and quota on this device.  If this is not possible on your system, comment
+out the definition and add one instead to the LOGIN.COM file of each IRAF
+user, so that each user can have a private IMDIRDISK, or simply edit the
+entry for IMDIR in the LOGIN.CL file created when MKIRAF is run.
+
+A public scratch device is used because this is where bulk image data
+will be stored by default.  It is often
+desirable for this to be on a different disk than that used for user
+logins, to minimize the amount of disk that has to be backed up on tape,
+and to permit a different quota and file expiration date policy to be used
+for large datafiles than is used for the small, relatively long lived files
+normally kept on the user disk.
+.le
+.ls 10 TEMPDISK
+Set to the name of a public scratch device and create a public directory
+[IRAFTMP] on this device.
+The device may be the same as is used for IMDIRDISK if desired.
+The IRAF logical directory "tmp$" (known as IRAFTMP in the IRAFUSER.COM file)
+is defined as TEMPDISK:[IRAFTMP].
+The IRAF system will create temporary files in this directory at runtime.
+These files are always deleted immediately after use (unless a task aborts),
+hence any files in "tmp$" older than a day or so are garbage and should be
+deleted.  It is best if "tmp$" points to a public directory which is cleaned
+periodically, e.g., whenever the system is booted, so that junk temporary
+files do not accumulate.
+.le
+.ls 10 FAST,BATCH,SLOW
+These are the logical names of the standard IRAF logical batch queues.
+They should be redefined to reference the queues used on your machine,
+e.g., the standard VMS batch queue SYS$BATCH.
+.le
+.le
+
+.ls 4 [IRAF.VMS.HLIB.LIBC]IRAF.H
+This file (often referred to as <iraf.h>) is required to compile any of the
+C source files used in IRAF.  Most sites will not need to recompile the C
+sources and indeed may not even have the DEC C compiler, but the file is
+also used by the runtime system in some cases to resolve logical names,
+hence must be edited and installed.  Change the following directory names
+as required for your system, referencing only system wide logical names in
+the new directory pathnames.
+.ls 10 HOST
+Set to the fully resolved pathname of the directory IRAFDISK:[IRAF.VMS].
+.le
+.ls 10 IRAF
+Set to the fully resolved pathname of the directory IRAFDISK:[IRAF].
+.le
+.ls 10 TMP
+Set to the fully resolved pathname of the directory TEMPDISK:[IRAFTMP].
+.le
+
+These directory definitions are referenced only if logical name translation
+fails for some reason, as often happens on VMS systems for various reasons.
+It is therefore essential that only system wide logical names be used in
+these directory pathnames.  Do not use job or process logicals.  Do not
+change the order in which the entries appear, or otherwise alter the syntax -
+the kernel code which scans <iraf.h> is very strict about the syntax.
+.le
+
+.ls 4 [IRAF.LOCAL]LOGIN.COM
+We recommend that the login directory for the IRAF account be [IRAF.LOCAL],
+rather than the usual [IRAF], to provide a place to keep all the miscellaneous
+files required locally to maintain the system, without cluttering up the
+standard system.  This will simplify the installation of future updates since
+it makes it obvious what is part of the standard system and what has been
+added locally, and having all the local stuff in a separate directory will
+make it easier to ensure that it is not lost when the next version of the
+system is installed.
+
+The default LOGIN.COM will therefore be found in [IRAF.LOCAL].  The LOGIN.COM
+file should contain a call to the newly defined IRAF command to define the
+IRAF logicals at login time (or when a batch job is submitted).  Depending
+on when the distribution tape was made, the LOGIN.COM that comes with the
+system may reference either IRAF or IRAFX.  If the latter is the case, change
+the reference to IRAF.  The remainder of the file mostly consists of site
+dependent stuff used here, and can be changed if desired (it should be
+harmless to leave it in).
+.le
+
+
+The following files should now be edited to define the default terminal,
+printer, editor, and so on for your system.  Any part of this can be left
+until later if desired.
+
+.ls 4 [IRAF.VMS.HLIB]ZZSETENV.DEF
+This file contains the name of the default editor, the default names of all
+the standard devices, and a number of other definitions which are not site
+dependent and which can therefore be ignored.  To be accessible by the IRAF
+system, each local device named must also have an entry in the TERMCAP file
+(terminals and printers) or GRAPHCAP file (graphics terminals and image
+displays) in [IRAF.DEV].  There must also be an "editor.ED" file in
+[IRAF.DEV] for the named editor; EDT, EMACS, and VI are currently supported.
+Edit the string to the right of the equals sign for the following entries.
+Sample values are shown.
+
+.ks
+.nf
+	set editor	= "vi"
+	set printer	= "imagen"
+	set stdgraph	= "vt640"
+	set stdimage	= "iism70l"
+	set stdplot	= "versatec"
+	set terminal	= "vt640"
+.fi
+.ke
+
+For example, you may wish to change the default editor to "edt", the default
+printer to "vmsprint", the default image display to "iism75", and the default
+terminal to "vt100".  Note that only the IIS model 70 and 75 image displays
+are directly supported by the current system.  Display code is also available
+for the DeAnza displays from STScI (NOAO will also support the device in the
+near future).  The complex issues of the graphics and display interfaces are
+discussed more fully in a later section.
+.le
+
+.ls 4 [IRAF.DEV]DEVICES
+This file contains a list of the allocatable devices (primarily tape drives)
+for the local system.  It should be obvious how to change it by reading the
+comments in the file and studying the current values, which are for our system.
+.le
+
+.ls 4 [IRAF.DEV]TERMCAP
+There must be entries in this file for all host local terminal and printer
+devices you wish to access from IRAF.  The printer is easy, since the
+"vmsprint" entry provided should work on any VMS system.  To prepare entries
+for other devices, simply copy the "vmsprint" entry and change the queue name
+from SYS$PRINT to the name of the queue for the new printer.  Any number of
+these entries may be placed in the termcap file.  If you have a new terminal
+which has no entry in the termcap file provided, a new entry will have to be
+added (termcap is widely used, so it is highly likely that someone somewhere
+will already have written it).  A copy of the UNIX manual page documenting
+the termcap database is appended in case you need it.
+.le
+
+.ls 4 [IRAF.DEV]GRAPHCAP
+There must be entries in this file for all graphics terminals, batch plotters,
+and image displays accessed by IRAF programs.  Weird graphics terminals will
+need a new entry.  The IRAF file "sys$gio/doc/gio.hlp" contains docs for
+graphcap.  A printed copy of this document is available upon request, however
+once IRAF is up you may find it easier to generate your own copy using HELP,
+as follows:
+
+.nf
+	cl> cd sys$gio/doc
+	cl> help gio.hlp fi+ | lprint
+.fi
+
+The manual page for the SHOWCAP task should also be printed since this utility
+is useful for generating new graphcap entries.  More focused documentation
+will be available eventually.  Telephone consultation is available for those
+who need it.  We ask that new graphcap entries be sent back to us so that we
+may include them in the master graphcap file for other sites to use.
+.le
+
+The DEV directory also contains a number of files (HOSTS, HOSTLOGIN, and UHOSTS)
+used by the IRAF network software.  We depend upon the networking capabilities
+of IRAF heavily at NOAO to access image displays, printers, files, etc. resident
+upon remote nodes.  We expect that most sites will not need this capability
+initially, hence documentation of the networking software will be left for
+later.  For sites which do have a local TCP/IP based network (we do not yet
+support DECNET) all that is necessary to enable networking is to edit the
+three networking files in the DEV directory, and install IRAF on the other
+nodes.  It does not matter what native operating system runs on the remote
+nodes, so long as it runs IRAF as well.
+.le
+
+.ls 4 [4] \fBComplete the System Configuration\fR
+
+Login again as SYSTEM, run AUTHORIZE, and change the login directory for
+the IRAF account to [IRAF.LOCAL].  Next, copy the IRAF.H file to the system
+library, ensuring that the file has read permission for the world.
+
+.ks
+.nf
+	$ set default sys$library
+	$ copy DISK:[iraf.vms.hlib.libc]iraf.h []
+	$ set prot=(w:r) iraf.h
+.fi
+.ke
+
+This is the last part of the system installation procedure requiring
+SYSTEM privilege, excepting the adjustment of the authorized quotas for
+the IRAF account and any other accounts which will be using IRAF.
+.le
+
+.ls 4 [5] \fBRelink the System (if necessary)\fR
+
+The prelinked executables supplied on the distribution tape should
+execute on most systems without need to relink.  If you run a different
+version of IRAF than we do, however, it may be necessary to relink all
+or part of the system.  If you requested a "you relink" version of the system,
+read on, otherwise you can probably skip to the next section.
+
+There are two different sets of executables in the system, the so-called
+"bootstrap utilities", and the regular system executables.  The bootstrap
+utilities are required to relink the system and hence must be linked first.
+If you received a "you relink" distribution you can skip this step, since the
+bootstrap utilities are included on these tapes as well.  Even if you did
+not receive a you-relink distribution you should be able to skip this step,
+as we were told by DEC that if we linked the bootstrap executables in such
+and such a way (/NOSYSSHR link option), they would run on older versions of
+VMS.  Hopefully this is true, otherwise you must either rebootstrap the
+system yourself, or upgrade to a more recent version of VMS.
+
+The bootstrap utilities are written in C, and the DEC C compiler is required
+to compile or link these utilities.  The C compiler is NOT required to run
+the prelinked binaries.  To recompile and link the bootstrap utilities, i.e.,
+to "bootstrap" IRAF, enter the following commands.
+
+.nf
+	$ set default [iraf.vms]
+	$ set verify
+	$ @rmbin
+	$ @mkpkg
+.fi
+
+The bootstrap should take 30 to 45 minutes on an unloaded 11/780.  Once the
+bootstrap utilities have been relinked and installed in HLIB, the main system
+may be relinked.  We assume that there is nothing wrong with the system
+object libraries and that we only need to relink.  If this assumption is false
+the system (excluding the [IRAF.VMS...] directories) can be stripped of all
+.OLB, .MLB, .OBJ, and .EXE files and the procedure outlined below will
+automatically recompile the libraries as well, but of course this will take
+much longer than a relink.
+
+Once the system has been bootstrapped all system maintenance is done with
+the MKPKG utility.  Documentation for this and the other SOFTOOLS utilities
+may be found in the IRAF User's Guide, and is also available in the online
+system via HELP.  The bootstrap utilities differ from most IRAF software in
+that they can be run either from DCL or from the IRAF CL.  The following DCL
+commands may be entered to relink (or recompile and relink) the main IRAF
+system.  Note that in this case MKPKG is a DCL foreign task, not a .COM file,
+hence there is no @.
+
+.nf
+	$ set default [iraf]
+	$ mkpkg
+.fi
+
+A full system relink will take around 30 minutes.  A full system compile and
+relink takes about 20 hours on our UNIX 11/750 (single user), and probably
+almost as long on a VMS 11/780.  The file [IRAF.VMS.HLIB]MKPKG.INC may be
+edited to disable compilation of any parts of the system that will not be
+used at your site.
+.le
+
+.nh
+Login to IRAF and Run the Test Procedure
+
+    Congratulations!  You should now have a functional IRAF system.
+At this point it would probably be wise to read the CL User's Guide,
+if you have not already done so.  Before starting the CL you should
+probably do what a regular user would do, i.e., run MKIRAF to initialize
+the IRAF environment, and then edit the LOGIN.CL file created by MKIRAF
+as desired.  
+
+.nf
+	$ set default [iraf.local]
+	$ mkiraf
+.fi
+
+Once the IRAF environment is configured one need only enter the CL command
+to start up the CL.  After a bit IRAF should print the message of the day
+and the root menu, and issue the "cl> " prompt.  This assumes that the IRAF
+command is referenced in the LOGIN.COM file; if this is not the case, IRAF
+must be entered first to define CL and the other VMS logical names and
+symbols used by IRAF.
+
+	$ cl
+
+Once in the CL, you will probably have magtape and printer access, are likely
+to have graphics terminal access, and very possibly will not have either
+image display access or graphics plotter access.  If the graphics terminal
+capability is ready the next step is to run the IRAF test procedure to
+verify that all is working well, as well as try out a few of the many tasks
+in the system.  If the graphics terminal is not up yet, there is probably
+not point in running the test procedure.  To run the test procedure, read
+the documentation in volume 1A of the IRAF User's Guide and follow the
+instructions therein.  You may also wish to run some of the benchmarks
+described in the benchmarks paper distributed with V2.3, to make sure that
+your VMS system (or user quotas and working set) is/are configured properly
+for efficient execution of IRAF programs.
+
+.nh
+VMS Quotas and Privileges Required to Run IRAF
+
+    The only special privilege required by IRAF is TMPMBX, which is probably
+already standard on your system.  Systems with DECNET capabilities should
+also give their users NETMBX privilege, although it is not required to run
+IRAF.  No other privileges are required or useful for normal activities.
+
+Although privileges are no problem for VMS/IRAF, it is absolutely essential
+that the IRAF user have sufficient VMS quota, and that the system tuning
+parameters be set correctly, otherwise IRAF will not be able to function
+correctly.  If a quota is exceedd, or if the system runs out of some
+limited resource, the affected VMS system service will return an error code
+to IRAF and the operation will fail (this usually happens when trying to
+spawn a connected subprocess).
+
+We are still trying to determine the best minimum recommended quota values.
+The current recommendations are summarized below.
+
+.nf
+	BYTLM		30000
+	PGFLQUOTA	15000
+	PRCLM		10
+	WSEXTENT	2048
+.fi
+
+Please note that these are MINIMUM values.  Larger values for PGFLQUOTA and
+WSEXTENT may be desirable, depending upon expected usage and system resources.
+
+In addition to sufficient per user authorized quota, the system tuning
+parameters must be set to provide enough dynamically allocatable global
+pages and global sections to handle the expected load.  If these parameters
+are set too small, process connects will fail intermittently, usually when
+the system load is high.  Each subprocess needs about 10 global pages when
+activated.  With IRAF in heavy use (i.e., a dozen simultaneous users) this
+can easily reach a requirement for several hundred additional global pages.
+Each installed image and subprocess also needs at least one, usually two,
+global sections.  The system parameters on our 8600 (which is probably a
+worst case example) are currently set to GBLPAGES = 14000 and GBLSECTIONS
+= 220.  Don't despair, though; our little UNIX 11/750 can handle up to ten
+IRAF users with only 5 Mb of memory, provided they aren't all doing heavy
+image processing. 
+
+.nh
+Tuning Considerations
+
+    There are three things that are commonly done to tune VMS/IRAF for a
+particular host system:
+
+.nf
+	o  Install the executables to permit shared memory
+	o  Precompile selected TERMCAP and GRAPHCAP entries
+	o  Strip the system to reduce disk consumption
+.fi
+
+.nh 2
+Installing Executable Images
+
+    VMS/IRAF does not yet implement shared libraries.  The system manager must
+"install" executable images if the pages comprising the read only PSECT's of
+these images are to be shared amongst all processes currently executing the
+same image.  This is not necessary if only one person will be using IRAF at
+a time, but becomes increasingly important as the number of user increases,
+or if even a single user begins submitting a lot of batch jobs to run
+concurrently.  This problem is, of course, not unique to IRAF (except that
+the images are rather large, e.g., often several hundred Kb).
+
+The procedure for installing images is quite simple, however it will fail
+if there are insufficient global pages available in the system.  The number
+of global pages required to install an image is typically about 60 percent
+of the size of the image in disk blocks.
+
+Only the VMS system manager can install images.  Images installed interactively
+must be reinstalled whenever the system is booted; to permanently install
+images, the system startup file must be edited.  The procedure followed to
+install an image is quite simple, e.g., login as SYSTEM and enter the following
+commands to install the CL.EXE and X_SYSTEM.EXE images, and any others
+expected to be used enough to be worth installing.
+
+.nf
+	$ run sys$system:install
+	INSTALL> DISK:[iraf.bin]cl		/open/header/shared
+	INSTALL> DISK:[iraf.bin]x_system	/open/header/shared
+		(etc.)
+.fi
+
+Alternatively, one can run the INSTALL.COM DCL script in the HLIB directory.
+The main IRAF executables all reside in the [IRAF.BIN] directory.
+
+.nh 2
+Precompiling TERMCAP and GRAPHCAP Entries
+
+    Precompilation of a termcap or graphcap entry is a technique used to
+speed runtime access of the entry for that device.  If the entry is not
+precompiled the termcap or graphcap file must be physically opened and
+scanned at runtime to read the desired entry.  This causes a noticeable
+delay of as much as a second when clearing the terminal screen or plotting
+a graph, hence it is usually worthwhile to cache the entries for commonly
+used video and graphics terminals.  It is not worthwhile for printers,
+plotters, and image displays.
+
+The system comes with selected termcap and graphcap entries already
+precompiled.  To see which devices are precompiled, page the cache data
+files, DEV$CACHET.DAT (for termcap) and DEV$CACHEG.DAT (for graphcap).
+To cache a different set of entries one must regenerate these files with the
+MKTTYDATA task in the SOFTOOLS package, and then do a full sysgen with the
+MKPKG utility.  Detailed instructions are given in the manual page for
+MKTTYDATA.
+
+.nh 2
+Stripping the System to Reduce Disk Consumption
+
+    If the system is to be installed on multiple cpus, or on a particularly
+small host like a MicroVax, it may be necessary or desirable to strip the
+system of all non-runtime files to save disk space.  This equates to deleting
+all the sources and all the reference manuals and other documentation,
+excluding the online manual pages.  A special utility called RMFILES (in the
+SOFTOOLS package, of course) is provided for this purpose.  It is not
+necessary to run RMFILES directly to strip the system.  The preferred
+technique is to enter the commands given below.  The example is for DCL for
+consistency with the rest of this document, but this could be done from
+within the CL as well.
+
+.nf
+	$ set default [iraf]
+	$ mkpkg strip
+.fi
+
+This will preserve all runtime files, permitting use of the standard runtime
+system as well as user software development.  The size of the system is reduced
+from about 41 Mb (megabytes) to around 19 Mb.  One can optionally enter the
+command "mkpkg stripall" to delete the system libraries as well, but this
+saves only another couple of Mb and a full sysgen (20 cpu hours) or a tape
+reload will be required to regain the capability to link user programs with
+the IRAF libraries, or relink the IRAF executables.
+
+.nh
+Interfacing to New Graphics Devices
+
+    There are three types of graphics devices that concern us here.
+These are the graphics terminals, graphics plotters, and image displays.
+The topic of interfacing to these devices has already been discussed in
+the letter which was sent out with the IRAF questionnaire, hence the
+discussion given here will be brief.
+
+.nh 2
+Graphics Terminals
+
+    The IRAF system as distributed is capable of talking to just about any
+conventional graphics terminal, using the STDGRAPH graphics kernel supplied
+with the system.  All one need do to interface to a new graphics terminal
+is add a new graphcap entry for the device.  This can take anywhere from
+a few hours to a few days, depending on one's level of expertise, and the
+perversity of the device in question.  We are willing to help out if
+necessary, as noted in the letter mentioned earlier.
+
+The fancy bit mapped, high resolution graphics displays common on "workstations"
+like the MicroVax and the Sun cannot be driven (acceptably) by the existing
+STDGRAPH graphics kernel.  We are actively developing new graphics kernels
+for these devices, and they should be available later this year.
+
+.nh 2
+Graphics Plotters
+
+    The current IRAF system comes with three graphics kernels usable to drive
+graphics plotters.  The STDGRAPH kernel can in principle be used to make
+plots on many devices by using a Tek graphcap entry, redirecting the Tek
+drawing instructions into a file, and using the Tek emulation software that
+comes with most plotters to generate the plot.  A more streamlined interface
+is possible but is not yet available [V2.3 - see the discussion of the new
+SGI interface in the paper "The IRAF Simple Graphics Interface"].
+
+The supplied STDPLOT kernel is used to generate NCAR metacode and can be
+interfaced to an NCAR metacode translator at the host system level to get
+excellent plots on the Versatec, Printronix, Trilog, and other similar
+devices if NCAR metacode translators are available.  This is the kernel
+we currently depend upon most heavily at NOAO for plotter output.
+Unfortunately, the host level NCAR metacode translators are not included in
+the standard IRAF distribution but are required for a plot.  The necessary
+software is however in the public domain, and will be available at a later
+date.  Sites which already have the Ray Bovet "McVax" package are already
+very close to having plotter output using this kernel.  A little software
+twiddling remains to be done to make the connection for VAX/VMS (we do all
+our plotting on UNIX here), but this is a matter of a few hours and the
+software should be available shortly.  Contact us for more information.
+
+The remaining possibility with the current system is the CALCOMP kernel.
+Many sites will have a Calcomp or Versaplot library (or Calcomp compatible
+library) already available locally.  It should be possible to copy this
+library to the HLIB directory and relink the Calcomp graphics kernel to
+get output using on any devices supported by the library.  The following
+commands should suffice to install the calcomp library, and relink and 
+install the Calcomp graphics kernel:
+
+.nf
+	$ set default [iraf.vms.hlib]
+	$ copy mycalcomplibrary.olb libcalcomp.olb
+	$ set default [iraf.sys.gio.calcomp]
+	$ mkpkg update
+.fi
+
+A graphcap entry may also be required.
+
+[NOTE, August 1986]: A new graphics kernel called the SGI kernel is now
+available.  In many cases this will greatly simply the process of interfacing
+to a new plotter device.  Documentation should have been included with the
+V2.3 distribution kit.  See also [VMS.GDEV.SGIDEV]README).
+
+.nh 2
+Image Displays
+
+    The IRAF system as currently supported directly supports only the
+IIS model 70 and 75 image displays.  Comparable software is available from
+STScI for the DeAnza displays; requests for this software should be
+directed to Sammy Kijilner or Jay Travisano at STScI.  We are expecting
+to take delivery of a MicroVax with bit mapped graphics display and
+DeAnza IP5000 image display any day now, hence these devices will soon
+be supported by NOAO, too.
+
+We cannot do much to help sites with other image displays until the new
+IRAF display interface is completed.  This is scheduled to be worked on
+this spring, and should be available this summer.  The new interface and
+associated TV package software will be a great improvement over what is
+currently available; the current interface is very minimal, and does not
+even support cursor readback, although it is fine for image display.
+
+In the meantime, the best approach is to use the new IMFORT interface
+and whatever non-IRAF display software you currently have to construct
+an interim display program.  The IMFORT library provides host system Fortran
+or C programs with access to IRAF images.  The only documentation
+currently available for IMFORT is the README file in the directory
+[IRAF.SYS.IMIO.IMFORT].  Sample Fortran programs and a VMS .COM file
+showing how to link are given in the same directory.
+
+.nh
+The IRAF Directory Structure
+
+    The current IRAF directory structure (new directories are constantly
+being added) is documented in the Appendix.  The main branches of the tree
+are the following.
+
+.nf
+	bin	- installed executables
+	dev	- device tables (termcap, graphcap, etc.)
+	doc	- assorted IRAF manuals
+	lib	- the system library; object libraries, global files
+	local	- your login directory
+	math	- sources for the mathematical libraries
+	pkg	- the IRAF applications packages
+	sys	- the virtual operating system (VOS)
+	vms	- the VMS system interface (kernel + bootstrap utilities)
+.fi
+
+If you will be working with the system much at the system level, it will be
+well worthwhile to spend some time exploring these directories and gaining
+familiarity with the system.
+
+.nh
+Relinking or Updating IRAF Packages
+
+    Should it be necessary to fix a bug in one of the applications packages,
+it is very easy to recompile and relink the package and install the new
+executable.  After editing the affected files, enter any of the following
+commands (this is normally done from within the CL):
+
+.nf
+	mkpkg		Makes an executable in the package directory
+	mkdebug		Same, but with the debugger linked in
+	mkpkg install	Used after "mkpkg" (but not mkdebug!) to
+			    install the new executable in BIN.
+	mkpkg udpate	Relinks the new executable and installs it in
+			    BIN all in one shot.
+.fi
+
+If extensive revisions are contemplated, a copy of the entire package should
+be made and moved out of the system, and that version of the package modified,
+rather than modifying the standard package, which will only make updating the
+system more difficult.  It will be necessary to delete or replace the installed
+executables in BIN before the revised ones can be used.  The directory name
+in the TASK declaration for the package in HLIB$CLPACKAGE.CL is all one must
+modify to use the local version of the package rather than the standard one.
+.endhelp
-- 
cgit 

