A quicker way to mount tapes

To wrap up this series of posts on tapes I will show a quick way to mount them that does not require switching to the operator’s console and responding to the mount request.

Example

Say you wanted to mount the D6.0T1 distribution tape which is on T904. Normally you would issue the $mount command from a user terminal:

$mount mts:tape1 9tp *t* vol=6.0T1 lbltype=vlo

and then switch over to the operator’s console to say

OK TAPE1 T904

Instead you can do this from your MTS session:

$get >t904
$control *afd* volume=6.0T1
$control *afd* lbltype=vlo

You can then run any program that uses the tape by pointing it to pseudodevice *afd*, for example:

$run *fs 0=*afd*

When finished you need to $release *afd* as usual. Once you release it, the tape will not go offline like for normal mounts so you don’t need to devinit it on the Hercules console before using it again.

So although this is much quicker to use than regular $mount, there are a number of drawbacks:

  • You have to be a privileged user to $get a tape device - so with the starter set of users you can sign on as MTS and do this but account ST01 would not work
  • You can only have one FDname open at a time whereas you can $mount multiple tapes and give them different pseudodevice names. If you try to $get a second tape it will release the first one and reassign *afd* to the new tape.
  • You need to remember to issue the $control commands to identify the tape, otherwise you will get errors trying to run programs against *afd*

The $get command

$get is a MTS command but is not mentioned in MTS Volume 1 - you will need to get the System Edition which lists privileged and obsolete commands.

*afd* stands for Active File or Device and is described in the last chapter of the manual. It provides a lower level way of accessing FDnames than regular MTS commands like $edit or $copy.

Once *afd* is activated, lines typed at the terminal which do not start with a $ are interpreted as data lines which are written to *afd*. Assuming the defaults of line files and auto numbering off, if you type a line at the command prompt starting with a number it will be added to *afd* using that line number rather than being interpreted as a MTS command.

An example using a regular file will make this clearer:

$get -gettest
# Ready.
10welcome
20MTS
15to
release
# "*AFD*": ... AFD released.
$list -gettest
 
      10     welcome
      15     to
      20     MTS

Further information

See MTS Volume 1: System Edition for a write-up of $get and *afd*. The D6.0A FAQ also has some examples of using $get.

Making your own tapes

9track A 9 track magnetic tape, from the Museum of Obsolete Media

In this post we’ll look at how to create your own emulated tapes to transfer data between MTS and your host operating system. For an introduction to tapes on MTS take a look back at this earlier article.

The lbltp program

You will need to install the lbltp program on your host OS. This allows reading from and writing to emulated tape files compatible with Hercules.

The version at Bitsavers contains source and executable for Mac and Windows. On Linux, get the latest version from Mike Alexander’s SVN repo and build locally:

$ svn checkout https://svn.msalexander.com/repo/utilities/lbltp/trunk lbltp
$ cd lbltp
$ mkdir build
$ cd build
$ make -f ../Make/makefile
$ sudo cp lbltp /usr/local/bin

Documentation can be found in the Writeup directory. Type lbltp to start the program, give it commands at the Please enter request prompt and type stop to exit.

Set up a spare tape drive

The starter version of D6.0 comes with a number of tape drives defined and loaded with the distribution tapes. You could use these to mount your own tapes but it is easier to set up a new tape drive.

Make sure MTS and Hercules are shut down then edit the Hercules.cfg file. In the tapes section add a line like this:

0C70 3420 * # User tape drive

This defines a 3420 model tape drive at address 0C70 which corresponds to MTS device T920. The * means no tape is loaded when Hercules starts up.

Creating a new tape from MTS

Let’s create a new tape, mount it for writing and use *FS to store a couple of files which we can then read from the host OS.

First you will need to create a blank tape file. You can use the hetinit program that comes with Hercules to do this. Change directory to Tapes and issue the following command from your host OS:

hetinit -d new.aws NEW

This will create a file new.aws with tape volume name NEW.

Next, issue a mount request for this new tape from MTS:

$mount mts:tape1 9tp *t* vol=NEW ring=in

Note the ring=in parameter as we are going to write to the tape. We are using regular labeled tapes so we don’t need the lbltype=vlo parameter used for distribution tapes.

Switch to the Hercules console and issue a devinit command to initialise the tape drive with the file:

devinit 0c70 Tapes/new.aws

Go now to the MTS operator’s console and respond to the mount request:

OK TAPE1 T920

If all goes well your MTS session will respond that the tape was mounted. You can now run *FS to add files to the tape. Note the par=init parameter as this is a new tape:

$run *fs 0=*t* par=init
# Execution begins   11:24:36 
= save alpha
= File 1 "ALPHA(1)" ... has been saved
= save gamma
= File 2 "GAMMA(1)" ... has been saved
= stop
= Do you want *FS to dismount the tapes it used?
? yes
= "*T*": (MTS.:TAPE1) T920 released.
# Execution terminated   11:24:46  T=0.058

Reading the tape from your host OS

You can now use lbltp to open the tape file and extract files to your host OS. Below is a sample session showing how to do this:

ITD Tape Utility version 1.3

Please Enter Request
open new.aws
Open input or output tape?
input

Please Enter Request
list
         Listing for IBM labeled *FS tape NEW 
FS file     1  ALPHA                            blks=1 recs=2 bytes=78
FS file     2  GAMMA                            blks=1 recs=13 bytes=366
Logical End of Tape reached.

Please Enter Request
copy file=1-2
Copying FS file 1 ALPHA to alpha.
   1 blocks 2 records 78 bytes             2 records 80 bytes
Copying FS file 2 GAMMA to gamma.
   1 blocks 13 records 366 bytes             13 records 379 bytes

Please Enter Request
stop

Note that lbltp takes care of EBCDIC to ASCII conversion, but line numbers from MTS are not preserved.

Creating a tape from your host OS

Now let’s try to do it the other way, creating a tape with some files from your host OS and transferring these into MTS.

One problem is that lbltp only supports reading *FS formatted tapes, not writing to them. So we will have to write a regular labeled tape and use lower level tape positioning commands on MTS to extract files.

(I think it should be technically possible to extend lbltp to support writing *FS tapes; could be an interesting project.)

The below lbltp session shows how to create a new tape and add two files. Note that you have to give an explicit filename command before adding each file to the tape.

ITD Tape Utility version 1.3

Please Enter Request
initialize send.aws volume=SEND

Please Enter Request
filename delta

Please Enter Request
copy input=delta output
Copying file delta to send.aws file 1 DELTA.
             3 records 37 bytes   1 blocks 3 records 37 bytes 

Please Enter Request
filename epsilon

Please Enter Request
copy input=epsilon output
Copying file epsilon to send.aws file 2 EPSILON.
             4 records 29 bytes   1 blocks 4 records 29 bytes 

Please Enter Request
stop

Reading the tape from MTS

Now we need to mount the tape on MTS. On the Hercules console (note the ro parameter):

devinit 0c70 Tapes/send.aws ro

From MTS:

$mount mts:tape1 9tp *t* vol=SEND

On the MTS operator’s console:

OK TAPE1 T920

The tape is now mounted on pseudodevice *T*. To get a listing of files, there’s a useful MTS program called *LABELSNIFF we can run, giving the tape pseudodevice as parameter 0:

# run *labelsniff 0=*t*
# Execution begins   10:50:15 


  Tape = *t* User ID REL. 10:50:15 19 Sept 1914

  Tape name=MTS.:TAPE1
  IBM labeled  6250-bpi 9TP Volume=SEND 
  LP=on BLK=on RING=out DTCHK=on RETRY=10

  File                    Block Record  Tapelen  Record 
     # Data set name      count  count   (feet)  format 

     1 DELTA                  1       3    1.10 VBS(32760,32767) 
     2 EPSILON                1       4    1.08 VBS(32760,32767) 
 
  Total tape length = 2.18 feet.
 
  <*><*><*>  End of tape  <*><*><*> 
# Execution terminated   10:50:23  T=0.029

(For those of us who have never used real tapes it’s interesting to visualise files having a length in feet!)

Now to extract the files. For each file we will need to use a $control command to position the tape and then use the MTS $copy command to read from the tape and write to a file. We will also need to create the files we want to write to. For example:

$control *t* posn=epsilon
$create epsilon
$copy *t* epsilon

You don’t have to copy to a file; if you just wanted to display the file you could do $list *t*.

When finished, you will need to release the tape:

$release *t*
# "*T*": (MTS.:TAPE1) T920 released.

Further information

MTS Volume 19 has extensive information on using tapes. I also found the tutorial guide made by the UM Computer Centre Introduction to Magnetic Tapes - Getting It on Tape useful.

There’s a program on MTS called *UNIXTAR that looks like it can read and write tar format files, so one alternative that I have not tested is to create a tar file on the host OS, add this as the single file on a tape and use *UNIXTAR to extract all the files in one step.

Finding MTS components from the driver file

The driver listing file contains details of all MTS components that are available on the distribution tapes. It can be found in the file doc/D6.0-LIST.txt on your host operating system after unzipping the distribution.

Each component has one or more sub-components which represent individual files. For example, 528 is the component for the Algol-W compiler and it has 66 sub-components; 548 is the component for the *FS program and it has 9 sub-components. Individual items are identified as component/sub-component, eg 548/9.

The driver listing has 2 or 3 lines per sub-component giving details like file type, location and size followed by a more detailed description.

Unpacking the file

To make browsing the driver file easier I’ve converted the file to a tab-separated format, one line per sub-component, which you can download here. This can then easily be loaded into a spreadsheet or database for viewing.

The Perl code I wrote to do this can be found at this Github gist - it could be adapted to produce output in a different format if needed.

Example: the *FS program

Let’s look at component 548, the *FS program itself, in more detail. The subname field gives a brief description of each file, with a longer write-up in description. type indicates the type of file: the first letter is the class, eg S for source code, O for object files; further letters give more details, so type SA is assembler source code, type SF is Fortran source code etc.

If the sub-component is on the disk already, its filename will be given in the disk_name column; if it has to be restored from tape this will be blank. So for component 548 we can see the Makefile (548/1), compiled program (548/8) and helpfile (548/9) are on the disk already; the other components, which are source or object files, are not.

The tape_6250 and file_6250 show where to find these files in the distribution tape. So for these items they can be found on 6.0T2 files 478-486, and could be restored by mounting the 6.0T2 tape, running *FS and executing the command restore (478) (486).

The location column shows what file names each sub-component had when it was saved to tape; note that *FS does not use this when restoring the file so you will have to sign on to the correct user and rename files to get them to match their original location.

For example, sub-component 548/2 has location W930:FS#SA so you would need to sign on as user W930, restore the file (*FS gave it the name FS.BASE_S002 when I tried this) and then run the MTS command $rename FS.BASE_S002 FS#SA.

Further information

See the file D6.0-NOTES.txt in the MTS distribution documentation for further information on the driver file list format.

Restoring files from tapes

tape drive From “Introduction to Magnetic Tapes” by the UM Computer Centre, 1986, archived at the Hathi Trust Digital Library

On the mainframe, tapes were a cheap, high capacity solution to store files that were not always in use. An example from 1993 at UM - a tape costing $7 could store 165MB of data; storing the same amount on disk would cost $168 per month. Tapes are also portable and could be used to exchange data between different computers. The downside was tapes are slow - they had to be mounted manually and as access was sequential it could take several minutes to find a piece of data towards the end of the tape.

Running under Hercules, the main use for tapes is to restore files from the MTS distribution and to transfer files to and from your host OS. Hercules emulates tapes using files on your local disk in AWS format.

In this post we’ll look at how to mount a MTS distribution tape and restore a file. First off we need to know some of the terminology used to describe tapes and tape operations.

Background and terminology

Tape formats and parameters

Tapes come with a number of different lengths, tracks and densities, which together determine their size. Typically MTS at the time of the D6 release was using 9 track tapes with 6250 BPI density. length varying from 100 to 2400 feet. On Hercules these parameters are not important as the tape capacity can be as much as the free disk space you have available, but you will find references to them if you read the original documentation.

Tapes had a snap-in ring which if set in would allow writing to the tape; you will see references to RING IN and RING OUT on MTS tape commands and prompts which translates to read/write and read/only access. It is possible to specify an emulated tape drive as read only on Hercules, which means the tape can only be mounted as RING OUT.

Typically a tape would have a physical label (ie written on the tape case) and a rack ID (used to find the tape from storage). These are not present on Hercules. The volume label, which is written electronically in the header of the tape data, is available on Hercules.

At a low level, blocks of data can be written to tape in various formats depending on the type of data and what other non-MTS system would use the tape. We will restrict ourselves for now to looking at tapes written in a format understandable by *FS, the file save and restore program on MTS.

Tape drives and the mounting process

A mainframe has multiple tape drives. When a user requests a tape, an operator would locate the tape (eg from a rack) and load it into a suitable free drive. The operator would then indicate to the user’s program which device the tape was mounted on, or if any other condition (no free drives, tape could not be found etc). If mounted the user’s program would then read from the assigned tape device.

After the user’s program had finished with the tape it would release it, which would signal to the operator that the tape could be dismounted and stored back in the rack, or physically delivered to the user.

Emulated tapes on Hercules

Tape drives and the tapes initially loaded on them are defined in the Hercules configuration file hercules.cfg. For example, here are two drives from the default config:

	0184   3420   Tapes/d6.0t1.aws   ro  # T904, *FS D6.0 distribution tapes #1
	0185   3420   Tapes/d6.0t2.aws   ro  # T905,  " #2

The first line shows that a model 3420 emulated tape drive is at address 0184. Its name will be T904 on MTS. The initial tape loaded on the drive is Tapes/d6.0t1.aws which is mounted read only (ring out).

It is possible to get Hercules to change the tape loaded in a drive by using the devinit command on the Hercules console, which we will look at in a future post.

Mounting a tape - user request

So after that introduction let’s mount a tape and extract a file. The tape we want is the D6.0T1 tape. From the MTS command line enter the following:

$MOUNT MTS:TAPE1 9TP *T* LBLTYPE=VLO VOL=6.0T1

Let’s go through the parameters:

  • MTS:TAPE1 is a dummy name; on a real mainframe you would enter the rack ID where the tape would be found. You can use TAPE1 to TAPE9 here if you are mounting multiple tapes at the same time.

  • 9TP is the type of tape drive, which will always be 9 track.

  • *T* is the pseudodevice that you want the tape to be made available on. You can use any name not already defined here (eg *MYTAPE* would be OK but not *SOURCE*).

  • LBLTYPE=VLO indicates the format of the tape, which is Volume Label Only for this particular tape.

  • VOL=6.0T1 is the electronic volume label.

Note that you don’t specify what tape drive will be used; this is the job of the operator to provide in the next step.

After entering this command MTS will print your tape request and change the prompt to % to indicate it is waiting for the tape to be mounted by the operator.

# MTS:TAPE1 9TP *T* LBLTYPE=VLO VOL=6.0T1
%

Mounting a tape - operator action

Switch over to the MTS operator’s console. You will see a new prompt similar to the below:

 00040 MTS ST01:  T (1 9TP) (TAPE1) on 9TP, (6250), ring OUT, '' ***************

Respond as follows

OK TAPE1 T904

This tells MTS that the request for TAPE1 can be fulfilled by using device T904, which from the Hercules config file you know is the correct device for the 6.0T1 tape. You can also type other commands to reject or defer the request - see the Operator’s Manual for more detail.

Once you type the OK response, MTS will check that there is a tape in the drive, the ring is set correctly and the volume label matches the request. If all checks out you will see the following:

00040 MTS Mount check OK.Mount (TAPE1) TAPE1 on T904 Ring Out
00040 MTS ST01, TAPE1:Accepted on T904

If instead you got a ’not ready’ message then you will need to bring the tape device back online - from the Hercules config file this is device 0184 so on the Hercules console type devinit 0184.

Once the tape is mounted, back on the user MTS session you will see

*T* (TAPE1): Mounted on T904

Now pseudodevice *T* can be used to access the tape’s contents.

Using *FS

On the user session, start the *FS program with *T* as its parameter:

$RUN *fs 0=*T*

The prompt will change to =. You can use help to see the commands available. Let’s look for the ASMG user guide: type

= list ASMG.USER?

The response you will get is:

= FS list for tape MTS.:TAPE1 on T904. Density= 6250 Volume=6.0T1 Lbltype=VLO O


= File D             File Name           Ver# Type  Lrecl  Size   Dev    Date a
=
=  230   ASMG.USER'S_GUIDE.P.093            1 Seq      80    41  Page  JULY 03,

So this is file 230 on the tape. To restore a copy to your current user’s file area, type restore (230) (the brackets are needed) and then stop to execute the restore. When done, *FS will ask you if you want to release (unmount) the tape and will then return to the command line prompt.

= File 230 "ASMG.USER'S_GUIDE.P.093(1)" ... has been restored to ASMG.USER093

You can now print or view the file ASMG.USER093.

Unmounting

If you didn’t release the tape in the *FS session, you can do it from the command line by typing $release *T*. A message will be printed on the operator’s console telling you to remove the tape, which you can ignore.

If you want to mount the same tape again, remember to devinit the device from the Hercules console.

Further information

Commands to mount and use tapes can be found using online help (eg HELP MOUNT) or MTS volume 1.

A more detailed look at how tapes are formatted and used can be found in MTS volume 19.

Commands that the operator can use to accept or reject tape mount requests can be found in the Operator’s Manual.

In future posts I will look at how to find and restore files from the distribution tapes in more detail and how to create your own tapes.

Updated 14-Apr-2015: corrected LBLTYPE note

← Previous  Next →