The files listed below must be edited before IRAF can be used with the video terminals, graphics terminals, plotters, printers, magtape devices, and so on in use at the local site.
Beginning with V2.10, IRAF magtape devices are described by the tapecap file, dev$tapecap. This replaces the old "devices" file for all runtime access to tape devices (the "devices" file is still used however in a lesser role; see below). The tapecap file describes each local magtape device and controls all i/o to the device, as well as device allocation.
The tapecap file included in the distributed system includes some generic device entries such as "9t-6250" (9track 1/2 inch tape drive at 6250 bpi), "vms-exabyte" (exabyte EXB-8200 8mm tape drive on VMS), and so on which you may be able to use as-is to access your local magtape devices. For example, by default, the device known to the CL as "mta" is a TA78 9tk drive known as device TU0:, which is locally defined at the system level as a specific tape drive (actually, in our cluster, $1$MUA0:). Notice how related entries are chained together in the tapecap file with the tc= field:
mta|mtahi|mta6250|TA78 9tk tape drive| :tc=mttu0-6250:
mttu0-6250|mttu0|TA78 half inch reel tape drive (VMS):\ :al=tu0:dv=tu0:lk=tu0:mr#64512:or#64512:se:tc=9tk-6250:
9tk-6250|9track 1/2 inch tape drive at 6250 bpi:\ :dt=9 track at 6250 bpi:tt=2400 foot:ts#140000:\ :dn#6250:bs#0:mr#65535:or#65535:fb#10:
Most likely you will want to add some device aliases, and you may need to prepare custom device entries for local devices. There must be an entry in the tapecap file for a magtape device in order to be able to access the device from within IRAF.
Instructions for adding devices to the tapecap file are given in the IRAF V2.10 Revisions Summary. Notes on the VMS specific implementation of the new magtape facilities are found in Tape driver of this document.
This file is used to associate IRAF logical device names with VMS device names. This file is no longer used by the IRAF magtape i/o system which is now all tapecap based, but is used by host level utilities like devstatus which need a simple way to translate IRAF device names to host device names. The file is optional and need not be configured to run IRAF.
All physical devices that the user might need to access by name should be documented in the file dev$devices.hlp. Typing
in the CL will format and output the contents of this file. It is the IRAF name of the device, as given in files such as termcap, graphcap, and tapecap, which should appear in this help file.
There must be entries in this file for all video terminal, graphics 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(1).
Any number of these entries may be placed in the termcap file, and there can be multiple entries or aliases for each device. 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 a termcap entry for your terminal. If the terminal in question is a graphics terminal with a device entry in the graphcap file, you should add a `:gd' capability to the termcap entry. If the graphcap entry has a different name from the termcap entry, make it `:gd=gname'. Local additions should be placed at the top of the file to make it easier to merge the changes into a future IRAF release.
(1)If the printer or plotter device is on a remote node which is not clustered with the local node but which is accessible remotely, IRAF networking must be used to access the remote device. IRAF networking is also frequently used to access devices on non-VMS (e.g., UNIX) nodes.
There must be entries in the graphcap file for all graphics terminals, batch plotters, and image displays accessed by IRAF programs. New graphics terminals will need a new entry. The IRAF file gio$doc/gio.hlp contains documentation describing how to prepare graphcap device entries. A printed copy of this [60 page] document is available from the iraf/docs directory in the IRAF network archive. However, once IRAF is up you may find it easier to generate your own copy using help, as follows:
which will print the document on the default IRAF printer device (use the "device=" hidden parameter to specify a different device). Alternatively, to view the file on the terminal,
The help pages for the IRAF tasks showcap and stty should also be reviewed as these utilities are useful for generating new graphcap entries. The i/o logging feature of stty is useful for determining exactly what characters your graphcap device entry is generating. The gdevices task is useful for printing summary information about the available graphics devices.
Help preparing new graphcap device entries is available if needed. We ask that new graphcap entries be sent back to us so that we may include them in the master graphcap file for all to benefit.
The dev directory contains several files (hosts, irafhosts, and uhosts) used by the IRAF network interface. IRAF networking is used to access remote image displays, printers, magtape devices, files, images, etc., via the network. IRAF network nodes do not have to have the same architecture, or even run the same operating system, i.e., one can access a UNIX/IRAF node from VMS/IRAF and vice versa. Editing changes to the networking related files in [IRAF.DEV] are illustrated here. Further documentation on the networking interface can be found in the IRAF Version 2.10 Revisions Notes and ( Network Driver ) of this manual.
The dev$hosts file is used to configure IRAF networking on the local system. This file tells IRAF what network nodes are defined and how to connect to them, including the protocol to be used. Initially IRAF networking is disabled. To enable networking there must be an entry in the hosts file for the host IRAF is running on. To do anything useful with networking there must also be entries for the nodes you wish to connect to. Often a single VMS/IRAF installation and a single copy of dev$hosts are shared by several nodes in a VMS cluster.
To connect to a local VMS node via DECNET requires an entry in the hosts file like the following (these and the following examples are taken from the NOAO VMS/IRAF hosts file).
robur r : robur::0=irafks draco : draco::0=irafks
Here, nodes "robur" and "draco" are defined as DECNET-connected nodes with the IRAF kernel server (IRAFKS) installed as a "zero numbered" object in DECNET. IRAFKS can also be installed as a numbered DECNET service, in which case the hosts file entry should appears as follows.
robur r : robur::242 draco : draco::242
In this example the IRAFKS service is installed locally as object number 242 in DECNET.
To connect to a node on a remote UNIX host via TCP/IP requires an entry using "!" to indicate the TCP/IP protocol, followed by the UNIX command to be executed to start up the IRAF kernel server, as in the following examples (note the different machine types).
cephus : cephus!/usr/iraf/bin.ddec/irafks.e columba : columba!/usr1/iraf/iraf/bin.mips/irafks.e felis : felis!/u1/iraf/iraf/bin.rs6000/irafks.e lepus : lepus!/usr/iraf/bin.f2c/irafks.e noctua : noctua!/usr/iraf/iraf/bin.irix/irafks.e ursa u : ursa!/local/iraf/bin.sparc/irafks.e vega : vega!/iraf/iraf/bin.hp700/irafks.e
Finally, the hosts file may contain logical node entries. These are not real network nodes, but hosts file entries which point to some other entry in the same host table. These are most commonly used to designate logical nodes for disposing of output to different classes of devices such as printers and plotters, hosted by some node elsewhere on the network, but can be used for other purposes such as gateways.
# Logical nodes (lpnode = line printer output, plnode = plotter output). lpnode : @ursa plnode : @ursa
In the example above node ursa is a Sun server; the hosts file entry for this node is given in an earlier example above.
The other files required to configure IRAF networking are the uhosts and irafhosts files. The uhosts file is a standard internet host table containing hostnames and internet numbers. It is used for TCP/IP networking unless the logical name IRAFUHNT is defined to point to an alternate file (e.g., Multinet uses a hosts file which IRAF networking can access directly). The uhosts file, if used, should be replaced by a host listing for your local site. One way to do this is to copy the /etc/hosts file from a local UNIX host. Note that V2.11 VMS/IRAF TCP/IP networking does not support runtime lookup of hostnames via a name service, hence an internet host must have an entry in the uhosts or IRAFUHNT file for VMS/IRAF to be able to connect to the host.
The irafhosts file supplies login information used by IRAF networking when a connection is made. When a network login is attempted the networking system will use the user's .irafhosts file if there is one, otherwise it defaults to the irafhosts file in dev. The system version of irafhosts should not need to be modified unless proxy logins are enabled on the local host. Proxy logins are used to eliminate password prompts when making network connections between cooperating machines in the local VMS cluster. This is a desirable but optional feature in all but one case, network gateways. When IRAF network connections are routed through a local VMS machine serving as a gateway machine password prompts are not possible, and one must either enable proxy logins or supply each user with a .irafhosts file containing their password. Proxy logins are probably the least objectionable of these two options.
Thus far we have discussed the IRAF networking configuration only as it appears from the VMS side of the network, i.e., what one sees when configuring the dev$hosts and other files on a VMS host. This is sufficient to allow one VMS/IRAF host to network to another, or to allow a VMS/IRAF host to connect to an external host machine running UNIX. The remaining case occurs when IRAF running on a UNIX host connects to VMS/IRAF. To enable such "incoming" TCP/IP network connections one must make an entry for each VMS host in the dev$hosts file on the UNIX/IRAF (client side) host, as in the following example.
# VMS (decnet) nodes, via internet gateway robur. robur r : -rcb robur!irafks draco : @robur!draco grian : @robur!grian lenore : @robur!lenore vela : @robur!vela
In this example all incoming (TCP/IP) connections are routed via the VMS gateway machine robur. The "irafks" is a DCL symbol defined on the server node in hlib$irafuser.com which runs the IRAF kernel server, irafbin:irafks.exe. The "@robur!nodename" syntax for the VMS nodes other than robur tells IRAF running on the UNIX host to use node robur as the gateway. The connection to node robur is made via the rexec-callback IRAF networking connect protocol (see Network Driver and also the V2.10 IRAF system notes file). The connection from the gateway machine to the target VMS node is controlled by the dev$hosts file on the gateway (VMS) node, and will often be a DECNET connection, hence the gateway can serve to connect the TCP/IP and DECNET domains.
Once again, for gateway connects to succeed either proxy logins must be enabled on the gateway machine, or each user must have a .irafhosts file on the gateway machine containing password information. For incoming TCP/IP network connections to work the VMS node must support the rexec network service, which is only available via third party networking packages such as Multinet. However, since IRAF networking supports gateways only the gateway host need run this software. When properly configured, gateways are transparent to the user.
To fully configure IRAF networking some VMS-level configuration is necessary in addition to editing the hosts, uhosts, and irafhosts files (for example IRAFKS should be defined as a known DECNET service). This is discussed further in Network Driver.