CMDSTAT, or why does DWB keep asking me for tapes?

DWB prompt

If you’ve used MTS for more than a few days you will see the above message on the MTS operator’s console. In this post we will look at what to do when you get this message and what is going on behind the scenes.

The quick answer

*DWB wants to store accumulated logs and command statistics on tape as statistics files fill up. The D6.0A distribution comes with a suitable tape on drive T90A, so at the MTS operator’s console answer the tape mount request with:

OK M001 T90A

The complete session will look like this:

00050 MTS  *DWB: The CMDSTAT file to tape program has been started. ********
00050 MTS  *DWB has been started to dump the CMDSTAT file(s), if any, to tape.
00050 MTS  A tape, labeled as indicated, should be mounted when requested.
00050 MTS  See component 531 for a description of CMDSTAT.
00050 MTS SYS.:  F (1 9TP) M001 on 9TP, ring IN, 'CMDSTAT' ********************
OK M001 T90A
00050 MTS Mount check OK.Mount M001 on T90A Ring In
00050 MTS SYS., M001:Accepted on T90A
00050 MTS **** Remove tape M001 from T90A (6250 BPI)

Once it has written the statistics, the tape will go offline so the next time *DWB fires up you will also need to do a

devinit 018a

on the Hercules console before responding to the tape mount request.

The longer answer

During system startup, MTS job *CMD is run automatically. This invokes the CMDPIKUP program which runs continuously, writing statistics from memory buffers into files.

Once a file becomes full, CMDPIKUP will start MTS job *DWB. This will run the CMDTAPE program to ask for a tape to be mounted, write the file to tape, empty the file and then exit.

What files and tapes to use is determined by the file SYS:CMDDIR. This is only permitted to be read by SYS so you will have to sign on to SYS to view it. A typical file looks like this:

# list cmddir
 
       1     TA MCMD034001 ???4??t?19:46:2405-20-85
       2     FACMDSTAT1
       3     F CMDSTAT2

The first character of each line is T for tape or F for file. The second character is the status: for files

Status for tapes is similar:

The rest of the file line gives the filename being used to store statistics; the rest of the tape line specifies the tape name, next file and creation date.

So at this point, file CMDSTAT1 is being written to and no tape is in use.

When *DWB is running, the CMDDIR file would look something like:

# list cmddir

     1     TB MCMD033001 ???4??t?19:46:2405-20-85
     2     FBCMDSTAT1
     3     FACMDSTAT2

ie the tape is in use and will write out the contents of CMDSTAT1; meanwhile, CMDSTAT2 is continuing to receive new statistics.

If the mount request is not attended to and both files fill up, CMDPIKUP will create a new temporary file CMDSTATx where x is some character; this will be deleted after it is written to tape.

On Hercules using D6.0A, this all runs well; the distribution comes with an empty tape file Tapes/cmd001.awd that is attached to drive T90A ready for use. The frequency that *DWB needs to run will of course be a lot less than on a real mainframe: a note in the driver listing file says that at busy times the files would fill up in an hour and the tape would fill up in about a week.

Clearing the tape

As tapes can have unlimited size on Hercules. the tape file will get bigger and bigger as more statistics are written to it; after running MTS for 4 months my file was over 65 megabytes. I wanted a way to get that space back.

One solution would appear to be replacing the tape file with an empty tape file (eg by replacing it with the copy of cmd001.aws that came with the D6.0A distribution). However, CMDTAPE does not like the tape contents changing from underneath it and gives an error when you try to mount it.

A better solution is to set a maximum length on the tape in Hercules and use the facility in CMDTAPE to create new tapes when the existing one is full.

At the Hercules console, change the tape length with:

devinit 018a Tapes/cmd001.aws maxsizem=50

(or whatever maximum size in MB you want).

Then, when you mount the tape responding to *DWB’s request, CMDTAPE will notice it is full and say

00049 MTS  *DWB: MOUNT NEW CMDSTAT TAPE RING IN WITH RACK  M002 FOR INITIALIZAT

Create a new tape from your host OS command line:

hetinit -d Tapes/cmd002.aws CMD002

and at the Hercules console do

devinit 018a Tapes/cmd002.aws maxsizem=50

Back on the MTS operator’s console, answer *DWB’s request for a new tape with just the tape drive name

T90A

CMDTAPE will mount the tape, label with the next sequence number (so M002 in this case) and initialise it and umount it.

It will then ask for the tape to be mounted again so it can write statistics to it; devinit it again at the Hercules console and answer the mount request with the new tape name:

00049 MTS SYS.:  F (1 9TP) M002 on 9TP, ring IN, 'CMDSTAT' ********************
OK M002 T90A

You can now safely delete the old tape file cmd001.aws. Also remember to update the line in hercules.cfg for the tape to add the maxsizem parameter:

018A 3420 Tapes/cmd002.aws maxsizem=50 # T90A, a CMDSTAT tape for use by *DWB

Turning off CMDSTAT?

Most Hercules users of MTS are not using the command statistics tapes that are being produced so it would nice to turn it off altogether.

There does not seem to be an easy way to do this (we can hardly blame the MTS designers for this as they were not expecting people to run personal copies of MTS!) One potential solution mentioned on the Yahoo list H390-MTS would seem to be to rewrite CMDTAPE to only empty the CMDSTAT files and update CMDDIR, not actually write data to tape. CMDTAPE is in 360 assembly language and (I think) requires the IBM copyrighted product ASMH to assemble, so this would not be a trivial task. In the meantime, feeding tapes occasionally to *DWB is not a big deal.

Why is the job called *DWB?

DWB is the initials of system programmer Donald W. Boettner. There’s a note in the driver file for the CMDSTAT component 00531/015:

It would seem that Don could have thought of some name more original than his initials. Don's response: "Since no one would name an SVC after me, I was forced ... "

And that’s why I like MTS so much - you’d never see that on a commercial operating system.

Further information

The Operator’s Manual, page 317, has a complete write-up of how the CMDTAPE components fit together and what to do if there are problems.

You can see the contents of *CMD and *DWB by $LISTing them from the MTS command line. Source for CMDPIKUP and CMDTAPE can be found under component 531 of the MTS D6.0 distribution tapes.

Comments

comments powered by Disqus