15 posts

$PERMIT me to talk about $FILESTATUS

The information that MTS stores about files is quite different from today's operating systems and it also has an interesting permissions model. In this post we'll look at this information in more detail using the $FILESTATUS and $PERMIT commands.


$FILESTATUS, which can be abbreviated to $F, displays information about files. It takes three parameters:

  • name
  • format
  • information

Running it without any parameters lists the files owned by the current user:

 # f

Use ? as a wildcard to specify what files to display. Note that this will not include temporary files; to see these you will need to do f -?. To see all files under another ID use f CCID:?; this will only list files you have access to.

The information parameter allows you to see further details about each file. To see all information MTS has, use the TOTAL parameter:

# fi ? total
  ALPHA             Size=1P, MinSaves=0P, TruncSaves=0P, MaxSize=32767P, 
   ExpFac=Def, Type=Line, RPM=0, IdleDays=36525, Lines=1, Holes=1, Avlen=19, 
   MaxLen=19, AvailSpace=2969, MaxHole=2969, Create=Nov15/14, 
   LastRef=Nov15/14, LastCatalog=Nov15/14, LastData=10:30:46 Nov15/14, 
   Volume=MTS600, Owner=ST03, Loc=3380, UseCnt=3, PKey=*EXEC, 
   FullAccess=Unlim Owner, None Others 
  BETA              Size=1P, MinSaves=0P, TruncSaves=0P, MaxSize=32767P, 
   ExpFac=Def, Type=Line, RPM=0, IdleDays=36525, Lines=0, Holes=1, Avlen=0, 
   MaxLen=0, AvailSpace=2990, MaxHole=2990, Create=Nov15/14, LastRef=Nov15/14,
   LastCatalog=Nov15/14, LastData=10:30:59 Nov15/14, Volume=MTS600, 
   Owner=ST03, Loc=3380, UseCnt=1, PKey=*EXEC, Empty, FullAccess=Unlim Owner, 
   None Others 

Let's look at each of these

  • Size and MaxSize give the current and maximum size in pages (4096 bytes)
  • MTS allocates more space to a file than its contents to allow it to grow. ExpFac is the expansion factor each time it needs to grow, here the default 10%. MinSaves shows how much space would be saved if the file was resized to its minimum possible size; TruncSaves shows spaces saved if the $truncate command was run to remove unused space at the end of the file. AvailSpace gives the amount of space in bytes before the file needs to be expanded.
  • Type is the file type, line or sequential
  • RPM is the number of references to the file per month since its creation date and IdleDays the number of days since its last reference. RPM always seems to be zero and Idledays larger than 36,000 whatever the usage of the file, so I suspect something is not working correctly here. Update 14-Apr-2015: this is due to a Y2K bug, see Jeff's comment below.
  • UseCnt gives the number of times the file has been used since its creation; this appears to be set correctly.
  • Lines, Avlen and MaxLen give the number of lines and their average and maximum lengths
  • Holes and MaxHole refer to holes in line file due to line replacement operations that have left spaces
  • Create gives the creation date, LastRef the time the file was last used, LastCatalog the time the catalog was updated for this file and LastData the last time data was changed in the file
  • Volume and Loc gives the disk volume and type of storage the file is on
  • Owner gives the file owner's ID
  • PKey and the remaining information gives details on who can access the file, which we will look at further below.

Instead of showing all this you can specify individual items to display:

# fi ? lines avlen
  ALPHA             Lines=1, Avlen=19 
  BETA              Lines=0, Avlen=0 

Finally, the format parameter determines how the information selected will be displayed. You can choose name=value pairs, columns or packed, with options for headers, spacing and indentation. For example:

# fi ? col spacing=3 create lastref

   File name        Create   DateLast 
                    Date     Referenc 

  ALPHA             Nov15/14 Nov15/14 

  BETA              Nov15/14 Nov15/14 


The $PERMIT command, or just $P, takes three parameters

  • files
  • access level
  • users

You can also selectively clone permissions from one file to another with the syntax $PERMIT files1 LIKE files2 EXCEPT access_level.

There are six basic categories of access level:

  • R - Read
  • WE - Write-expand - can add lines to a file but can't change or delete existing ones
  • WC - Write-change - can change or delete lines from a file but can't add new ones
  • T - Truncate and renumber
  • D - Destroy and rename
  • P - Permit - allow other users to change permissions

These can be combined using various aliases, for example RW allows the first three categories above, N specifies no access and U unlimited access

The users parameter allows you specify a single user ID or even a wildcard user ID (like ST0?) as well as other combinations:

  • ALL - all users
  • OTHERS - all users except those which already have access info specified
  • ME - access for signed in user ID
  • OWNER - file owner
  • PROJECT=xxxx - users under project ID xxxx
  • PKey=xxxx - see the next section

*PERMIT will show the current level of access after each command. Some examples:

# permit alpha r st01, rw st02
  Access to file "ALPHA" is now Read ST01, RW ST02, Unlim Owner, None Others
# permit alpha d st0?, read others
  Access to file "ALPHA" is now Read ST01, RW ST02, Unlim Owner, Destroy ST0?,
   Read Others

Program keys

You may want a file to be only accessible when run by a certain program. In Unix the solution is setuid, where when a program is run your user ID temporarily becomes the user ID of the program so it can access files owned by that user ID. This can lead to security issues though, eg if a buffer overrun in the program can be exploited to allow access to other files.

MTS has a better solution: each program can have a key, and access to a file can be granted to that key. You can then run a privileged program under your normal ID.

One example is the *CKID program that runs at sign on for certain shared IDs and checks which secondary IDs can use that ID. The config file, CKID:ACCESS should only be accessible to that program, so it is permitted to the pkey for *CKID:

# fi ckid:access access
  CKID:ACCESS       FullAccess=None Others, Read Pkey=*CKID 

You can set this up for your own programs by setting a pkey for the executable and then permitting access. Say you have a database program MYDB which is the only way a user should access the database file DBFILE. First set a program key:


and then permit access:


Further information

See the online help for $FILESTATUS and $PERMIT, and a detailed write up in MTS Volume 1.

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.


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.
# "*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 executables for Mac and Windows. On Linux, get the latest version from Mike Alexander's SVN repo and build locally:

$ svn checkout 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  

This will create a file 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 labelled 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/  

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 input or output tape?  

Please Enter Request  
         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  

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 labelled 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 volume=SEND

Please Enter Request  
filename delta

Please Enter Request  
copy input=delta output  
Copying file delta to 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 file 2 EPSILON.  
             4 records 29 bytes   1 blocks 4 records 29 bytes 

Please Enter Request  

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/ 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/   ro  # T904, *FS D6.0 distribution tapes #1
    0185   3420   Tapes/   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/ 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:


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.


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.


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

Submitting batch jobs from the reader

punch The IBM 29 card punch, from a film at the Deep Blue collection at the University of Michigan

In the previous post we looked at submitting batch jobs from the terminal; this time we will submit jobs from outside MTS using the emulated card reader. Using this method you can create jobs using a text editor on your host OS, submit to MTS and collect output without having to sign on interactively.

On Hercules, the emulated card reader accepts ASCII format text files, with each line representing one card. On MTS, the HASP batch scheduler reads cards from the reader and sets up batch jobs, with any output going to the printer.

Compared to submitting jobs from the terminal, you will need two additional items: a S8 card and full signon details.

S8 cards

For the first card in your job you will need a S8 card. This acts a header for batch jobs submitted to the reader and includes the number that will be used as the batch sequence ID.

According to the FAQ, these were handed out to users at the computer centre in UM for users to attach to their jobs and were then returned as a receipt when the job had finished.

You can create S8 cards by running the operator job *RCP and directing output to the card punch.

Switch to the MTS operator's console. Enter $DRAIN PCH1 to get HASP to let go of the punch then MTS *RCP. Enter >PCH1, NO and two six digit numbers to select the range of IDs. Then $START PCH1 to give control of the punch back to HASP. The console should look like the below.

00053..MTS *RCP  

If you take a look at the punch file Units/PCH1.txt, the first three lines should look like the below:

\                 100000               DECK                             100000 .
\                 100001               DECK                             100001 .
\                 100002               DECK                             100002 .

You can now cut lines from this file and paste into your batch job file at the top. It is possible to reuse cards/IDs once the job using an ID has finished, but it's best to use a new S8 card for each job.

Signon details

For interactive submission you could use $signon * as MTS knew what user ID submitted the request. For card reader submission you need to supply the user name, eg $signon st01, and in the next card supply the password.

Putting it together

So as an example let's do the simple calculation job again.

Create a file on your host operating system. For the first line, cut the first S8 card from the punch file. For the second and third line provide the signon ID and password. The rest of the job is as before.

The file should look something like this:

\                 100000               DECK                             100000 .
$signon st01
a = 10  
b = 13  
c = 7  
n = (a * b) / c  

Submitting the job and collecting output

Copy your batch file to Units/RDR.txt, overwriting the current contents.

Switch to the Hercules operator's console and type devinit c to bring the reader online.

HASP will read the job, execute it and print output to the printer file. Look in Units/PTR2.txt and you will see output like the below, surrounded by the usual header and footer:

No Charges  
Last signon was at 21:55:55, Sun Aug 23/14  
User ST01 signed on at 22:38:11, Sun Aug 23/14

A        = 10  
B        = 13  
C        = 7  
N        = 18.5714285714285694  

Copying files into MTS

You can use this batch job submission technique to send files into MTS. Say you want to send this file

Hello world  
Welcome to MTS!  

to the file DELTA owned by ST01. You could create a batch job similar to the below:

\                 100001               DECK                             100001 .
$signon ST01
$create delta
$copy *source* delta
Hello world  
Welcome to MTS!  

Further information

See the Operator's manual for details of the *RCP job.

To see how physical cards were punched by users before submitting them to MTS take a look at the film Basic Operation of the IBM 29 Card Punch from 1967 at UM.