VMS/IRAF Installation and Site Manager's Guide

7.2. New magtape driver

This section contains notes on the new V2.10 IRAF magtape driver as implemented for VMS. The reader is assumed to be familiar with the basics of magtape access in IRAF, including remote access to a drive via IRAF networking. Further information can be found in §5.1 of this manual, in the IRAF Version 2.10 Revisions Summary, and in the VMS/IRAF system notes file, iraf$local/notes.vms.

7.2.1. 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.

7.2.2. Density

When a drive is automounted it is possible to set the density. The V2.10 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.

7.2.3. Status output logging

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.

7.2.4. Using tape drives over the network

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.