Tape I/O Routines

A tape I/O package has been written to make tape applications more transportable. The routines return status codes. If an error is encountered, the tape I/O routine may optionally write an error message to the standard output. Each application program must do its own error handling as the tape package will not automatically abort an application program. This allows for better control in case of errors. There is no need for external mounts and dismounts as there are subroutines which perform those functions (c_tpclos() and c_tpopen()).

A program can access these routines by linking in the following object library:

     $LASLIB/tapeio.a

The tape I/O routines allow for a mounted tape to be reopened. This lessens the number of times of operator intervention. The physical tape drivename is required to reopen a tape. The drive name is returned by c_tpopen().

Programmers should note that if a tape I/O application program is aborted with an error (Control C, tape error, etc.) the tape remains mounted on the drive. The programmer is responsible for ensuring the required clean up is done prior to exiting the program.

The tape I/O support routines allow an application program to manipulate a magnetic tape the same way on various UNIX machines. The typical flow of an application program will be to mount the tape (c_tpopen(), perform a combination of skip, read, or write tape commands (c_tpbsf(), c_tpbsr(), c_tpfsf(), c_tpfsr(), c_tpread(), c_tpwrit()), and dismount the tape (c_tpclos()).

The tape I/O was designed for installations that have a staff of operators to mount the appropriate tapes. By default the c_tpopen() call issues a mount request and waits for the operator to respond wih a tape drive number. This method of mounting tapes does not work well when an installation does not have a staff of operators or if there is only one tape drive for a particular computer system. For these two instances two UNIX environment variables named WORTPDRIVE and WORTPMTREQ have been defined. WORTPDRIVE is a global variable which may be assigned to a single tape drive. WORTPMTREQ is a global variable -- which when set to 1 (one) the c_tpopen() call will query the user rather than the operator for a tape drivename.

The following table lists the actions taken when these variables are set:

WORTPDRIVE WORTPMTREQ ACTION

unassigned unassigned Operator is required to enter tape drive name and tape IO. assigned unassigned A request to mount the specific drive is issued to the console. assigned assigned A request to mount the specific drive is issued to the user's terminal if WORTPMTREQ has been set to 1. unassigned assigned A mount request is sent to the user's terminal, and the user is required to enter a tape drive name and tape IO.

NOTE: To reply to a tape request on UNIX machines:

     rp <process-id #> <drive #> tapeio

     where:
             Process ID number is the number displayed
             during the mount process.
             Drive number is only the number and not the 
             full name.

Rp is placed under the $LASTOOLS directory. This directory must be in the path of the rp user.

TAPEIO NOTES

1) Tape I/O routines have been modified to detect software EOT. A software EOT is defined by three tape marks.

If c_tpwrit() detects physical EOT, it writes 3 tape marks to indicate software EOT. The software EOT is more reliable in detecting EOT when the tape is read on a different drive and/or computer system.

The tape I/O structure pointed to by the "unit" parameter consists of fields to indicate current tape length left. This may allow an application program to write a software EOT when the tape length becomes zero. An application program written in C can get access to this structure with the following commands:

#include "tapeio.h"

struct TAPEDSC *drive;

drive = (struct TAPEDESC *) unit;

Structure fields used to determine tape length are:

    drive->tape_len   length of free tape measured in inches
    drive->tape_bpi   density of tape device
    drive->tape_irg   inter record gap of tape device

It is assumed that a tape mark requires 10 times the value of the inter record gap. An application program may set the tape_len field if the tape length is known and different from the default value.

The tape length field is NOT always valid because of the following:

When a tape device is reopened, the tape length field is reset to BOT; however, the tape might not be at BOT.
When the skip functions (bsf, bsr, fsf, fsr) are called the tape length field becomes invalid.
The default tape length, BPI, or IRG may be wrong. These values are set when the tape is opened, reopened, or rewound. The values are defined by the following table:

Device        Length        BPI         IRG            Capacity
9-track       2400          800        .8
9-track       2400         1600        .8
9-track       2400         6250        .4              150 MB
3480          540         38000        .1  ??          200 MB
8mm (low)     300        512000        .05  ??         2.5 GB
8mm (high)    300       1024000        .025  ??        5.0 GB
4mm           270        400000        .1  ??          1.3 GB

2) A tape drive on a remote system may be accessed by assigning the drive name with the following syntax: (Note: This capability available only at EROS Data Center.)

     host@drive

where "host" is the name of the remote computer system and "drive" is the drive name.

The tape read/write routines are buffered to enhance throughout. The buffered writes may impose problems in detecting physical EOT (i.e. EOT detected prior to writing all records in the buffer). The network tape write examines the "tape_len" field and if it is negative it writes three tape marks to indicate EOT and returns TAPE_EOT. As noted above the "tape_len" field is not always valid; therefore, there may be times when EOT is not detected properly when using a remote tape drive.

A remote tape drive is accessed by:

The c_tpopen()/ c_tpreop() call opens a network connection to a remote computer system. This requires the "tcp_pserv" process to be running on the remote computer system. After user validation, the "tcp_pserv" process execs the tape server program "tpsrv".
The tape I/O routines check to see if a remote tape drive was specified. If so, the routine sends a network packet to the remote computer system with the appropriate tape command and waits for completion. The tape read/write routines use a 1MB buffer to reduce the amount of start/stop on the tape device. Up to 200 records are stored in this buffer prior to sending to the remote computer system. The drawback to this is that if the buffer consists of 200 records and physical EOT (or parity error) is detected at the 100th record, the application program will think it wrote the 200 records.
The c_tpclos() routine closes the network connection.

3) The SGI SCSI tape devices do not forward skip properly. It seems that if there is a double tape mark, the forward skip record/file skips both tape marks. The tape i/o routines call c_tpread() to forward skip record/file on a SGI SCSI tape drive.

If a SGI SCSI tape device is opened in which the tape is past EOT, all operations fail. Therefore if a tape is at EOT on the open call, the SGI SCSI tape is rewound.

4) The SUN Xylogics tape drive writes tape marks differently from other tape devices. It seems that if the command is to write one tape mark, three tape marks are actually written. If the next command is to write another tape mark, no tape mark is written (still only three tape marks). The c_tpweof() routine takes this into account and if required backspaces the correct number of tape marks. An application program should not call multiple c_tpweof() but rather set the neof parameter.

5) The DG tape drives need to be closed carefully when opened for write access because tape marks are written whenever the tape is closed. If the tape is to be rewound or dismounted you need to use the mt unix command. Otherwise, the tape is rewound, but when the device is closed a double tape mark is written at the beginning of the tape.

The DG tape drives do not physically unload/eject the tape.

1) The sunn exabyte tape drive can only append data at the end of media. It can overwrite files if it starts at BOT, but otherwise it cannot overwrite an existing file. It does not detects EOT (the write may detect EOT, but the read does not).

2) The sung exabyte tape drive does not work well. This tape drive should be avoided until the OS is upgraded to 4.1.

3) IBM exabyte drive notes:

Cannot append files.  In order to write multiple files on
tape, the tape cannot be closed.
The read and write routines cannot be interrupted
including the software SIGARLM signal used for LAS
processing messages.  Signals are blocked until the I/O 
operation has completed.
Unable to sense BOT and EOT.  On file skip functions, if
the status is EIO assume BOT or EOT is encountered.  On 
record skip functions, if the status is EIO assume BOF 
or EOF is encountered.
Unable to unload the tape.

4) The tape i/o support routines do not work well with 1/4" streamer tapes on sun workstations. Require a multiple of 512 byte block sizes, do not support bsr and bsf functions. On read, if number bytes is greater than actual tape record, looks as if it continues to read the next record and the next until the number of bytes is specified is reached.

5) SGI tape drive notes:

Cannot append files after a double tape mark has been
written (SCSI devices).  Fixed in IRIX 4.0.
Cannot backspace first record on 8mm tape if tape is 
written at low density and read in a high density drive.
Cannot backspace first record on 8mm high density 
tape.  The backspace file command seems to work (returns 
BOT status), but the next read returns the correct number
of bytes and data that is actually the second record on 
tape.
The SCSI 9-track and SCSI 3480 cannot read variable
length records.  The data is actually transferred into the
buffer, but the read returns an I/O error.  The tape i/o 
routines for these drives fill the buffer with a fill value,
reread the record and determine the length of the record. 
The previous record size is used as a "good guess" for the 
next record on tape.  This problem has been fixed in IRIX 
4.0.

This is a list of available Tape I/O Routines: