If you've used MTS for more than a few days you will see 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
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
SPACE: not in use
Afor active, ie the file is being written to
CMDTAPEis copying it to tape
Ffor full: the file needs to be written to tape
Status for tapes is similar:
Afor available but not mounted
Bfor busy, being written to now
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.
*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
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
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
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
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 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.
The Operator's Manual, page 317, has a complete writeup of how the CMDTAPE components fit together and what to do if there are problems.
You can see the contents of
$LISTing them from the MTS command line. Source for
CMDTAPE can be found under component 531 of the MTS D6.0 distribution tapes.