VMS/IRAF Installation and Site Manager's Guide
VMS/IRAF Installation and Site Manager's Guide
The files listed below must be edited before the system can be run.
The principal change required is to change the pathnames of the major IRAF
logical directories for the local machine. If any of these files are edited
while logged in as SYSTEM, be sure to do a set file/owner=iraf to
restore ownership of the edited file to IRAF.
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. The
top of the distributed file looks like this:
$! IRAFUSER.COM -- VMS symbols and logicals for using IRAF.
$!
$! The following logical names are system-dependent. IMDIRDISK and
$! TEMPDISK should be public devices and may be the same device.
$!
$ define/job IRAFDISK USR$3: ! Disk IRAF resides on
$ define/job IMDIRDISK SCR$4: ! User image subdirectories go here
$ define/job TEMPDISK SCR$2: ! Runtime (scratch) files go here
$ define/job IRAFGMTOFF -7 ! Offset from GMT in hours
$! define/job IRAFUHNT (file) ! Use (file) instead of dev$uhosts
$!
IRAFDISK
- Set to the name of the disk the [IRAF] directory is on; this may
be another logical name but not a "rooted logical".
IMDIRDISK
- Set to the name of a public scratch device, if available. The mkiraf
script will try to create the default user image storage directories on this
disk, e.g., IMDIRDISK:[username]. All potential IRAF users should
have write permission and quota on this device.
A public scratch device is desirable because this is where bulk image data
will be stored by default. It is often best 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.
Note for sites that use "rooted logicals": the VMS/IRAF kernel does not
support rooted logicals. If you use one, e.g., for IMDIRDISK,
batch jobs that need to access it will fail. To avoid problems, you must
either choose IMDIRDISK to be truly just a disk specification, or inform all
users to edit their IRAF login.cl files after a mkiraf.
For example, if you define IMDIRDISK to be "DATA_DISK:", where DATA_DISK is
a logical name for dub4:[data.], user ICHABOD's login.cl would have "set
imdir = DATA_DISK:[ICHABOD]", but this would not work for batch jobs. The
user should edit login.cl after a mkiraf to use an expanded directory
specification, in this case "set imdir = dub4:[data.ichabod]".
TEMPDISK
- Set to the name of a public scratch device on which you have created a
public directory named [IRAFTMP]. 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 IRAFTMP older than a day or so are garbage and
should be deleted. It is best if IRAFTMP points to a public directory
which is cleaned periodically by the system, e.g., whenever the system is
booted, so that junk temporary files do not accumulate. This is a good
reason for using a single public directory for this purpose rather than
per-user private directories. The files created in IRAFTMP are rarely
very large.
See note under IMDIRDISK concerning rooted logicals, if you plan to
locate TEMPDISK at a rooted logical.
IRAFGMTOFF
- The value of IRAFGMTOFF is the offset in hours to convert Greenwich mean
time (GMT) to local standard time. It is used by the VMS/IRAF versions of
rtar and wtar to restore file dates properly when moving files
between UNIX and VMS systems. For example, Tucson is 7 hours west of
Greenwich so IRAFGMTOFF is defined as -7.
IRAFUHNT
- Define IRAFUHNT to be the name of the internet host table for the local
system, if this exists and is in the correct format for use by IRAF (i.e.,
the same format as the file dev$uhosts). On VMS systems there is no
standard internet host table comparable to the /etc/hosts file used on unix
systems. The VMS/IRAF implementation of TCP/IP networking therefore uses
its own host table, dev$uhosts, which is what is used if IRAFUHNT is not
defined. Some VMS networking implementations (e.g., Multinet) have their
own host tables. If this is the case then IRAF can make use of the system
host table by uncommenting and defining the logical name IRAFUHNT to point
to the file.
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 (all three names
may point to the same batch queue if desired). The fast queue is intended
for small jobs to be executed at interactive priorities, the batch queue
is for medium sized jobs, and the slow queue is for large jobs that need
a lot of system resources and are expected to run a long time.
*If local system management or accounting policies
require that private
tmp and imdir directories be defined for each user, rather than the public
ones we recommend, see Appendix A.
This command procedure is run by the system manager, or by the system at
boot time, to install the IRAF shared library and selected executable
images.**
Installing images in system memory is necessary to permit memory sharing in
VMS, and can greatly reduce physical memory usage and paging on a busy
system, while speeding process startup. Installing images also consumes
system global pages, however, of which there is a limited supply. Hence,
one should only install those images which will be used enough to make it
worthwhile. See §8.2
for more information.
The install.com procedure both installs the IRAF executables and
replaces them after any have been changed. It works from a separate list of
files, so you should not edit install.com itself. Instead, edit install.lst
to select files by commenting out only those which are not to be
installed (the comment character is a "!" at the beginning of the line).
The IRAF shared library s_iraf.exe should always be installed if
IRAF is going to be used at all, or the system will execute very
inefficiently (the IRAF shared library is used by all executing IRAF
processes). Normally the executables cl.exe and x_system.exe should also be
installed, since these are used by anyone using IRAF, as well as by all
batch IRAF jobs. If IRAF is heavily used and sufficient global pages are
available it is also desirable to install x_images.exe and x_plot.exe, since
virtually everyone uses these executable images frequently when using IRAF.
It is probably not worthwhile to install any other executables, unless usage
at the local site involves heavy use of specific additional executable
images.
**In VMS terminology, image, as in "executable image" refers
to the executable program, and has nothing to do with IRAF image data.
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 in the VMS system library. Change the
following disk names as required for your system, referencing only system
wide logical names in the new directory pathnames (e.g. usr1:[IRAF.VMS],
where usr1 is a system logical name; do not leave the IRAF logicals like
irafdisk in the definition).
IRAF Logical Directory VMS directory
HOST irafdisk:[IRAF.VMS]
IRAF irafdisk:[IRAF]
TMP tempdisk:[IRAFTMP] (may vary***)
- These directory definitions are referenced only if logical name translation
fails, as sometimes 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.
***If local system restrictions forbid a public IRAFTMP directory,
set this entry to the pathname of a suitable directory in IRAF, e.g.,
[IRAF.LOCAL.UPARM]. This should work in most circumstances, since it is
most likely to be the IRAF system manager who runs a program that accesses
these pathnames. This is separate from the user-level private IRAFTMP
directory discussed in Appendix A.