In the simplest form of a DECNET connection the hosts file entry for the server node will reference a zero-numbered network object as in the example, e.g., "hostname::0=irafks" (or "hostname::task=irafks"). If "irafks" is not a defined DECNET network object then the user must have a file IRAFKS.COM in their login directory, similar to the following:

$! IRAFKS.COM -- Fire up the iraf kernel server under DECNET. 
$! 
$  if f$mode() .nes. "NETWORK" then exit 
$! 
$! iraf                         ! uncomment if not in login.com 
$  irafks :== "$irafbin:irafks" ! define irafks as a foreign task 
$  irafks dn.irafks             ! start the iraf kernel server 
$  logout

This works, but has the disadvantage that every user account must have an IRAFKS.COM file in the login directory, or IRAF DECNET-based networking will not work. A better approach is to define IRAFKS as a known network object which will execute the file IRAFKS.COM supplied in the IRAFHLIB directory with V2.11 VMS/IRAF. This eliminates the need for each user to have a private copy of the IRAFKS.COM file, and makes proxy logins possible, which can eliminate the need for password prompts.

The following is an example of how to install irafks as a known network object. This must be done on each DECNET host. The device name USR$3: shown in the example should be replaced by the value of IRAFDISK: on the local system.

$ run sys$system:ncp 
ncp> define object irafks -
	number 0 file usr$3:[iraf.vms.hlib]irafks.com 
ncp> set object irafks -     
        number 0 file usr$3:[iraf.vms.hlib]irafks.com 
ncp> exit

In normal operation the NCP configuration is automatically preserved when the system is rebooted. If the local system has a network configuration procedure to redefine the NCP settings in the event of damage to the network database, then an NCP DEFINE command similar to that shown should be added to this file.

An alternative to the above scheme is to define IRAFKS as a numbered system object. This works as above, except that the "number 0" becomes "number n", where n is the network object number, and the dev$hosts file syntax for the server becomes "hostname::n".

The DECNET proxy login capability allows DECNET connections to be made between a set of well-known cooperating systems (e.g., the local cluster) without the need to supply login authentication information every time a network connection is made. The effect is to eliminate password prompts, thereby making networking much more transparent to the user. In some cases eliminating password prompts is necessary to make the software function correctly, for example when using a VMS host as a gateway machine interactive prompting for passwords is not possible, and the gateway cannot function correctly without some way to disable password prompts. In the case of IRAF networking this can be done by having the user put password information in their .irafhosts file, but the use of proxy logins is preferred since it avoids plaintext passwords and avoids the need for the .irafhosts file altogether.

To enable proxy logins for IRAF networking one must first define IRAFKS (the IRAF kernel server) as a known network object, as outlined in the previous section. The VMS authorize utility is then used to enable proxy logins.

For example, assume we have two nodes ROBUR and DRACO.

$ run sys$system:authorize                  ! run on node robur 
authorize> add/proxy draco::* */default 


$ run sys$system:authorize                  ! run on node draco 
authorize> add/proxy robur::* */default 

This would enable proxy logins between nodes draco and robur for all user accounts that have the same user login name on both systems. Alternatively one could do this for only a specified set of user accounts. The authorize utility automatically updates the affected disk files so that the change will be preserved the next time the system is booted.

To eliminate the password prompts during IRAF networking connections one must also edit the user .irafhosts file, or the system irafhosts file (in dev) to disable login authentication. For example, if the dev$irafhosts file contains

# dev$irafhosts
 
draco       :  <user> none 
robur       :  <user> none 
*           :  <user> ? 

then authentication will be disabled for connections made between nodes draco and robur, but a password will be required to connect to any other node. The above irafhosts file would result in a DECNET login request such as

hostname"username"::"0=irafks"

which forces a login as "username" on the remote host. If the user name is omitted, the default proxy login on the remote node is used. The user's .irafhosts file, if present, will be used instead and should be configured similarly.

These changes make IRAF DECNET based networking transparent between cooperating nodes in a local network, without requiring users to place password information in .irafhosts files. This is especially desirable if a routing node is used to route IRAF networking connections between TCP/IP and DECNET networks.

For incoming TCP/IP connections (VMS node acting as server) VMS/IRAF supports two connect protocols, rexec and rexec-callback. The rsh protocol, the default connect protocol for V2.11 UNIX/IRAF systems, is not supported by VMS/IRAF. To act as a TCP/IP server a VMS node must run a host-level networking package (such as Multinet) which supports the rexecd networking daemon.

On the UNIX side the dev$hosts entry for a directly-connected VMS node should be similar to the following example.

robur r                 : -rcb robur!irafks 

This specifies that for logical node robur, alias r, the rexec-callback connect protocol (TCP/IP) should be used to connect to the network node robur. The command to be executed on the remote node is whatever is to the right of the "!", i.e., the command "irafks" in our example.

When the rexecd daemon executing on the remote VMS node responds, the first thing it will do is login using the username and password supplied with the rexec request, and execute the user's LOGIN.COM file. For an IRAF user this must contain the command iraf, which causes the IRAFUSER.COM file in [IRAF.VMS.HLIB] to be interpreted by DCL. This defines all the IRAF logical names and symbols. One of the sybols defined is the irafks command which is subsequently executed to complete the rexec network request. The irafks command is defined in IRAFUSER.COM as follows:

$  irafks       :== $irafbin:irafks     !  IRAF network kernel server 

Hence, as might be expected, the result of the rexec connect is to run the IRAF kernel server irafbin:irafks.exe on the server node. In the case of the rexec-callback connect protocol, the actual command passed to DCL includes command line arguments to the IRAF kernel server telling it how to call the client back on a private network socket. What happens is that the client reserves a port and creates a socket on this port, then issues a rexec call to the VMS system to run the kernel server. The port and host name are passed on the rexec command line. The rexecd daemon on the server runs the irafks.exe process on the VMS node, and irafks calls the client back on the socket reserved by the client. The end result is a high bandwidth direct socket connection between the client and server processes.

One potential consequence of IRAF networking is that, if IRAF networking is not properly configured (either at the system level or at the user level), network connection attempts may fail, and IRAF in its normal operation may repeatedly generate failed connection attempts. Repeated failed connection attempts can trigger network security alarms on a VMS system, even though no real security problem exists. VMS systems managers should be aware of this possibility so that they don't waste time trying to track down a potential network security problem which doesn't exist. Should this circumstance occur, the best solution is to properly configure IRAF networking so that the connection attempts succeed, e.g., by setting up the user's .irafhosts file, or by enabling proxy logins for the user.

Allocation

Explicit allocation of magtape devices is now optional. If the drive is not allocated with the CL allocate command it will be automatically allocated and mounted when the first tape access occurs. Once allocated, it stays allocated even if you log out of the CL and back in, allowing successive IRAF or other processes to access the drive without it being deallocated.

The tape drive can be allocated at the VMS level (e.g., "allocate tu4:") before starting the CL. This reserves the drive but if you run devstatus in the CL it will report that the drive has not been "allocated", because IRAF doesn't consider the drive allocated in the IRAF sense unless it has been both allocated and mounted at the VMS level. One can either allocate the drive in the CL, or run an IRAF magtape task which accesses the drive to cause the drive to be automatically allocated and mounted.

If the drive is allocated in DCL before starting IRAF, then allocated and deallocated in the CL, when you log out of the CL the drive will still be allocated at the VMS level even though it was deallocated in the CL. If the drive is NOT allocated in DCL before starting the CL, allocating and deallocating the drive in the CL and then exiting will result in the drive not being allocated at the VMS level.

When a drive is automounted it is possible to set the density. The V2.11 implementation supports this (you just write to mta1600 or whatever), but this does not work reliably since VMS requires that the first operation following a mount which changes the density be a write. Often the write is preceded by a file positioning operation such as a rewind or seek to end of tape, which prevents the density from being changed.

To reliably change the tape density, do an "init/density=NNN device" at the DCL level and verify the new density with "show magtape" ("!init", "!show" in IRAF). It may be necessary to repeat the operation before it succeeds.

Status output logging is fully implemented in VMS/IRAF, i.e., one can enable status output and direct the messages to a text file, a terminal, or a network socket.

For VMS/IRAF the magtape naming conventions have been extended slightly to allow the different types of status output logging devices to be indicated.

:so=.foo	log to file "foo"
:so=>foo	log to terminal "foo:"
:so=foo	log to socket on node "foo"

For example, "mtexamine mta[:so=orion]" would examine the files on drive mta, optionally sending status output messages to a tape status daemon running on network node orion. Logging to a named terminal device will usually fail due to permission problems, but logging to ">tt" will direct status output to the current terminal window.

The VMS version of the driver will print a device type string such as

$2$MUA1: (ROBUR) - 9 track at 6250 bpi 

where the first part of the message comes from VMS and the " - ..." is from tapecap. The density field can be either the tapecap value or the runtime GETDVI value. For example, if the density is shown as "6250" this is the value from the tapecap entry. If the density is shown as "(6250)", i.e., in parentheses, this is the actual device value as determined by a GETDVI call to VMS. Note that it is possible for the density given in the tapecap entry to differ from the actual device density setting. In this case the tape will be written correctly, but the "Device Type", "Capacity" and "Tape Used (%)" status fields will be incorrect. To avoid this problem be sure the density of the tapecap entry you are using to access the drive matches the density value of the physical device.

To enable status output logging to a socket a network magtape status display server such as xtapemon must be started on the remote node before accessing the tape drive. To permanently direct status output to a node a statement such as 'set tapecap = ":so=hostname"' may be added to the login.cl or loginuser.cl file.

Changes in the VMS/IRAF V2.10 magtape and networking interfaces make it possible to remotely use VMS tape drives from Internet (UNIX) or DECNET hosts. In practice this is straightforward, but there are two caveats to keep in mind: 1) do not explicitly allocate the device, 2) if you run IRAF tasks in different packages that access the same tape drive, type flpr before running a task in a different package. Aside from these two items, everything should work as when accessing a magtape device directly on a UNIX or VMS system. Both problems arise from the way VMS handles device allocation.

Explicitly allocating a device does not work in VMS/IRAF when remotely accessing a tape drive because the effect is to allocate the drive to the kernel server process for the client CL, thereby preventing other client IRAF processes from accessing the drive. In practice this is not a problem since it is not necessary to explicitly allocate the device; the VMS/IRAF kernel server will automatically allocate and mount the device when it is accessed over the network.

An example of the problem of trying to access a remote VMS drive from two different IRAF packages occurs when the rewind task, which is in the SYSTEM package, is used in conjunction with DATAIO tasks such as rfits, wfits, or mtexamine. You can run tasks in a given package at will, but if you try to access the drive with a task in a different package there will be a conflict. Again, the problem is that when remotely accessing a device, the VMS device allocation facilities cause the device to be allocated to the kernel server process, rather than to the user. There is a one-to-one correspondence between client-side IRAF processes and kernel server processes. In IRAF each package has its own executable, and hence its own kernel server, leading to the allocate conflict.

For example if you have been using rfits (DATAIO) and you want to do a rewind (SYSTEM), type "flpr rfits" and wait 5-10 seconds, then you should be able to do the rewind. To run another DATAIO task, type "flpr rewind" and again wait 5-10 seconds before running the DATAIO task. The delay is necessary to wait for VMS to shutdown the kernel server for the package which previously had the device allocated.

User accounts should be loosely modeled after the IRAF account. All that is required for a user to run IRAF is that they run mkiraf in their desired IRAF login directory before starting up the CL. Each user should review the resulting login.cl file and make any changes they wish. Any user wanting to run batch jobs, including printer access, must execute the `iraf' command in their LOGIN.COM file, making sure it is executed for non-interactive jobs. Individual process quotas for IRAF users should be set as described in the next section.

The only 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 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 well or may not function at all. If a quota is exceeded, 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 frequently happens when trying to spawn a connected subprocess). The current recommended ranges of per-user quotas are summarized below. Users running DECwindows/Motif may already have, and may definitely need, larger numbers for these quotas, so don't reduce them to these values.

quota	    minimum	recommended

BYTLM	    20480	30720
PGFLQUOTA   75000	75000      (100000 recommended for AXP)
PRCLM	    5	        10
WSDEFAULT   512	        512
WSEXTENT    4096	WSMAX
JTQUOTA	    2048	2048
FILLM	    30	        60

The significance of most of these quotas is no different for IRAF than for any other VMS program, hence we will not discuss them further here. The PRCLM quota is especially significant for IRAF since an IRAF job typically executes as several concurrent processes. The PRCLM quota determines the maximum number of subprocesses a root process (user) may have. Once the quota has been reached process spawns will fail causing the IRAF job or operation to abort.

The minimum number of subprocesses a CL process can have is 1 (x_system.e). As soon as a DCL command is executed via OS escape a DCL subprocess is spawned, and we have 2 subprocesses. The typical process cache limit is 3, one slot in the cache being used by x_system.e, hence with a full cache we have 4 subprocesses (the user can increase the process cache size if sufficient quota is available to avoid excessive process spawning when running complex scripts). It is common to have one graphics kernel connected, hence in normal use the typical maximum subprocess count is 5. However, it is conceivable to have up to 3 graphics kernel processes connected at any one time, and whenever a background job is submitted to run as a subprocess a whole new subprocess tree is created. Hence, it is possible to run IRAF with a PRCLM of 5, but occasional process spawn failures can be expected. Process spawn failures are possible even with a PRCLM of 10 if subprocess type batch jobs are used (the default), but in practice such failures are rare. If all batch jobs are run in batch queues it should be possible to work comfortably with a PRCLM of 5-6, but in practice users seem to prefer to avoid the use of batch queues, except for very large jobs.

Since IRAF uses memory efficiently the working set parameters do not seem critical to IRAF, provided the values are not set unrealistically low, and provided WSEXTENT is set large enough to permit automatic growth of a process working set when needed. Configuring VMS to steal pages from inactive processes is not recommended as it partially cancels the effect of the process cache, causing process pagein whenever a task is executed. It is better to allow at least a minimum size working set to each process. However, this is not a hard and fast rule, being dependent on individual system configurations and workloads.

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 8 global pages when activated (IRAF uses global pages and shared memory for interprocess communications, due to the relatively low bandwidth achievable with the VMS mailbox facilities).

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. Note that the size of the executable found by doing a DIR/SIZE=ALL on [IRAF.BIN_ALPHA]*.EXE can be considered an upper bound to the number of pages needed to install it (if anyone wants to play it safe: typically, it's about 50-70 percent of this size). Currently, for 2.11, we have CL=640, S_IRAF=2730, IRAFKS=54, X_SYSTEM=431, X_PLOT=312, and X_IMAGES=2865. The system parameters on our DEC 3000/300 (AXP) are currently set to GBLPAGES = 205538 and GBLSECTIONS = 610. For every increment of 512 in GBLPAGES, GBLSECTIONS must be increased by 4. After making any of these changes, we recommend running AUTOGEN to ensure correct relationships among the many sysgen parameters.

There are three types of graphics devices that concern us here. These are the graphics terminals, graphics plotters, and image displays.

The current IRAF system comes with several graphics kernels used to drive graphics plotters. The standard plotter interface is the SGI graphics kernel, which is interfaced as the tasks sgikern and stdplot in the PLOT package. Further information on the SGI plotter interface is given in the paper The IRAF Simple Graphics Interface, a copy of which is available from the network archive.

SGI device interfaces for most plotter devices already exist, and adding support for new devices is straightforward. Sources for the SGI device translators supplied with the distributed system are maintained in the directory iraf$vms/gdev/sgidev. NOAO serves as a clearinghouse for new SGI plotter device interfaces; contact us if you do not find support for a local plotter device in the distributed system, and if you plan to implement a new device interface let us know so that we may help other sites with the same device.

The older NCAR kernel is used to generate NCAR metacode and can be interfaced to an NCAR metacode translator at the host system level to get plots on devices supported by host-level NCAR metacode translators. The host level NCAR metacode translators are not included in the standard IRAF distribution, but public domain versions of the NCAR implementation for VMS systems are widely available. A site which already has the NCAR software may wish to go this route, but the SGI interface will provide a more efficient and simpler solution in most cases.

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. To make use of such a library to get plotter output on any devices supported by the interface, one may copy the library to the hlib directory and relink the Calcomp graphics kernel.

A graphcap entry for each new device will also be required. Information on preparing graphcap entries for graphics devices is given in the GIO design document, and many actual working examples will be found in the graphcap file. The best approach is usually to copy one of these and modify it.