7 posts

System start-up in more detail

IBM S/360 front panel Front panel of an IBM S/360 mainframe, from License: CC BY 2.0

This post is a more detailed look at what happens at system start-up in MTS - it's useful to know what job is printing what messages in case something goes wrong, and also as a step towards further customisation of your MTS system.

Most of this was put together by reading the job programs and config files referenced by the Operator's manual: if I've omitted or misunderstood anything please let me know in the comments and I'll update this post.


When you start the IPL process by typing ipl 260 on the Hercules console, the system will load IPLBOOT from a special area on the disk drive on device 260, which will in turn load UMLOAD and then IPLREAD.

IPLREAD will give the familiar prompt

Do you wish to run the current system?  (YES or NO).

Typing yes at this point will cause the system to load the file *IPL.0 and then execute it.

Typing no will drop you into the command line for IPLREAD: here you can examine or change memory, or choose a different system to load. RAMROD keeps the last 3 versions of the system in *IPL.1, *IPL.2 etc, so if there was something wrong with your last change to the system you could boot the previous version with the commands



The system will then configure itself and start the INIT job, which will print:

Time and date have been set to ...  

and will start the OPER and DMGR jobs which manage the operator's console and disk respectively.


The system will then run a MTS task as user INIT, running commands from the file INIT:INITCMD. This will print the system name and prompt for the reason for rebooting, which will be written to file INIT:REASON; history of all reboots can be found in INIT:RELOADLOG.

It will then start the PDP (Paging Drum Processor) and a number of operator jobs:

  • *CHK to display a list of offline devices for the operator to check (the distribution comes with a number of disk devices defined, but you only need one on Hercules, so this can be ignored by pressing PA2).
  • *S2L to load shared components into memory, eg the editor; this will invoke the Named Address Loader *NAL. I think this also prints the PEEK initialization messages.
  • *CLN to clean out old system check files
  • *CMD to start writing command statistics to buffers.
  • *FSM which sets things up for file backup jobs
  • *STI to check the statistics file

It will also clean out any temporary files left after an unexpected reboot and start the system status display at the top of the operator's console.

Basic start-up is now complete.


Next, the operator would start up the spooler by running HASP, and the HASP initialisation jobs MTS *HSP. The latter reads commands from STRT:HSP which defines which devices should be started:



The penultimate step is to 'let out the lines' by running MTS *LAS. This reads commands from STRT:LAS. It will start MTS on each of the configured terminal devices with MTS DS02 ... MTS DS05. It will then run the following operator jobs:

  • *CLK to start the job scheduling program
  • *TPR which I believe is part of the tape cataloguing system
  • *MGR which manages email
  • *TCM and *FTP SERV which refer to network services we don't have on Hercules.

Finally, start batch job processing again with the HASP command $release ex.

Further information

The Operator's manual has further information on the start up process and many of the operator jobs.

On the distribution tapes, Component 816 has documentation on Clockwatcher.

Some useful Hercules features

hercules console panel The Hercules console panel, which you can get by pushing Escape while in the Hercules console.

In this post we'll look at the Hercules emulator itself in more detail including some useful features when running MTS.

Which version?

As noted at the MTS archive site, there are two versions of Hercules currently in development, 3.11 and 4.xx. Both run MTS OK, including fixes for printer support not present in older versions. 3.11 has Windows binaries at and source code that can be built on other platforms; 4.xx is just available in source form on Github. Apart from that it's not clear if there are advantages in one version over the other for MTS users.

The below items were tested on both versions of Hercules running on Linux. If you encounter any other differences let me know and I'll update this post.

One word of warning: although you can take an emulated system running on 3.11 and start it using 4.xx, it seems you cannot go the other direction: the 3.11 code will see the disk file written to using 4.xx as corrupt and try to repair it, which makes it unbootable on 3.11.

Suspend and resume

It's possible to suspend a running instance of Hercules to disk and resume it later - useful if you need to reboot your host OS but don't want to shut down and start up MTS again.

From the Hercules console, issue the suspend command. A file called hercules.srf.gz will be created in the same directory as the config file and Hercules will immediately exit.

When you are ready to start again, run Hercules as normal but issue the resume command rather than IPLing. You will also need to reconnect any 3270 terminals connected via socket.

This worked perfectly for me on 4.xx - the MTS clock updated itself and everything kept on running including any logged in sessions. 3.11 could suspend but not resume, at least with my build of the source code.

Shadow disks

Hercules has the concept of 'shadow disks', where an emulated disk's contents can be started in one file and then continued with updates made to another file. If you take a look at the Disks directory you will see something like this on the 6.0A distribution:

$ ls -l Disks/
-r--r--r-- 1 rupert rupert 68738104 Jan 16  2012 mts600.dsk
-r--r--r-- 1 rupert rupert 13798923 Jan 18  2012 mts600_1.dsk
-rw-r----- 1 rupert rupert  6062763 Oct 28 20:16 mts600_2.dsk

The combination of mts600.dsk and the two shadow files (denoted with a _) make up the MTS600 disk file. The D6.0A distribution has been set up so mts600,dsk contains the base D6, mts600_1.dsk contains patches to bring it up to D6.0A and your updates are in _2. So you can delete the _2 file to restore the system to its initial D6.0A state.

You can use this yourself if you want to make changes to MTS and then have the ability to roll back to previous versions. To do this, shutdown MTS and make mts600_2.dsk read only. When you start up Hercules and IPL again, a new file mts5600_3.dsk will be created. To roll back, stop Hercules and remove the _3 file.


It's possible to define the card reader as a socket device instead of a file. This allows you to submit jobs over the network or from your host OS by connecting to a socket instead of writing to the file Units/RDR1.txt. You can use the netcat utility which is available for most OSs or you could write a program to do this.

First, edit the Hercules config file and replace the line under 'Unit Record Devices' for the 3505 device with something like this:

000C   3505 sockdev ascii eof   # RDR1  

When you start Hercules, this will listen on port 9090 on the loopback interface for incoming connections. You can change the IP and port as needed in the config file.

Once MTS is booted and HASP is started, use netcat like the below:

netcat 9090 < job.txt  

Where job.txt is the batch file you want to submit, including a S8 card on the first line (See the post on using the card reader for more details on this.)

If all worked OK, netcat will not print any output, but you should see the results of the job on the printer device.

It's also possible to define the printer as an output socket device: when something is printed it will connect to the socket defined in the config file and send the output.

Further information

See the Hercules user manual for more details on options available.

Setting the timezone by patching the system with RAMROD and *OBJUTIL

D6.0A uses the US Eastern Standard timezone by default. In this post we will look at how to set the timezone to something different, which will lead us on to how to patch the system using the RAMROD and OBJUTIL utilities.

The TABLES assembly

As MTS was run on a small number of mainframes, the timezone is set inside the resident code of the system rather than by a command. The relevant code is TABLES; you can see the source assembly code in UMPS:UMTABLES#SA

   359              SET   YEAR=87,TIMEZONE=EST

which references a macro in copy:tables*sal

  1500              MACRO
  1501              TIMEZONE &Z
  1517     .L4      AIF   ('&Z' NE 'EST' AND '&Z' NE 'CDT').L5
  1519              AGO   .OUT

Normally you would change the code, assemble it and reboot. But this requires the ASMH assembler, which is a licensed IBM product that cannot be distributed with MTS. The alternative, which we will look at here, is to patch the object code with the desired value.


An overview of the steps we will take

  • Use RAMROD to extract the TABLES deck to a file
  • Use *OBJUTIL to patch the file, adding a new 'card' to change the timezone
  • Use RAMROD again to incorporate the file into the deck
  • Reboot and enjoy the correct time


RAMROD is used to keep track of a set of object decks and combine these into a file suitable for IPL. 'Decks' refers to the older practice of using a deck of punched cards to boot the system; on MTS thankfully this is done using files stored on disk.

A set of object decks is combined into a system. You can see the systems currently defined, and the current system, with the list systems and list current commands in RAMROD. RAMROD can be run as the MTS user as follows; RAMROD commands are given at the ~ prompt:

# $run mts:ramrod
 Using file "RMRD:ROD"
~ list systems
 D6.0A-AN172 created from AN152 23:05:42 01-17-12
 AN152 created from AN062 23:29:05 01-15-12
 AN062 created from AN052 01:13:12 01-06-12
 AN052 created from D6.0SYS.600/MP 19:49:40 01-05-84
~ list current 
 D6.0A-AN172 created from AN152 23:05:42 01-17-12
 Patch the timezone name and timezone offset in TABLES to be EST
 and GMT minus 5 rather than EDT and GMT minus 4. (jco)

So we can see the current system is D6.0A-AN172, the comment made when creating the system (which was to set the timezone to EST) and the history of previous systems.

You can see a list of decks that make up the system with list decknames; a snippet is below:

 SEG0.NCA (SEP17-81)
 TABLES.MP (AN172) patched

TABLES.MP is the deck we want. We can see a list of the patches already applied in the below:

~ list sys cur deck patches
 TABLES.MP (AN172) patched changed
 REP  004088  0400030001,00000240,00000030,000002A0,00000180 Rearrange OPERDEVS 01:26:36 01-06-12 MTS.
 REP  000180  01F1F0F5F2 CON1 IS A 1052 01:26:51 01-06-12 MTS.
 REP  003F8A  04,FED4 Make the timezone offset -300 (GMT minus 300 minutes or 5 hours)
 REP  003F8C  04,C5E2E340 Make the timezone name "EST"

What we want to do is extract the TABLES.MP deck to a file, so we can edit it outside the system using *OBJUTIL. Use the copy command to do this; let's store this to the temporary file -tables:

~ copy current -tables

Exit RAMROD for now with stop.


*OBJUTIL is used to edit a deck. Pass the file to be edited as unit 0:

# $run *objutil 0=-tables
 OBJUTIL VERSION(PR137) 08:22:26 10-21-14

*OBJUTIL accepts commands at the * prompt. First, let's get a listing of the values in the deck using the map command:

* map

  Symbol Type Esid Address Length AF

   Module: TABLES    Size = 0041C8
  TABLES   SD 0001 000000 003E0E     $HSPMNDV LD      0040FC 0004
  TIMEZONE LD      003F8A 0004       TIMZONTB LD      003F94 0004

The timezone is encoded as a half-word (16 bit) offset in minutes from GMT followed by a 8 character string giving the timezone name. We can use the display command to see the current values, using the type and length modifiers:

* display@type=h timezone
  TIMEZONE  'H'  -300
* display@type=c@len=8 timezone+2
  TIMEZONE+2  'C'  "EST     "

We've confirmed the current setting is GMT minus five hours, name "EST" padded with blanks. Let's now set it to the value we want; I'm going to use plain GMT which is zero offset but you could use any positive or negative value. Use the modify command with the @repgen modifier to create a REP card to set each part of the value

* modify@repgen timezone H'0'
  TIMEZONE WAS 'H'  -300 NOW 'H'  +0
  Enter comment for REP card:
? Set timezone to GMT

* modify@repgen timezone+2 C'GMT     '
  TIMEZONE+2 WAS 'C'  "EST     " NOW 'C'  "GMT     "
  Enter comment for REP card:
? Set timezone name to GMT

A REP cards means we are adding a line to change the object file rather than changing the existing contents of the file. Note that it prompts for a comment after each change; terminate this with a blank line.

To be sure, we can now display the new values;

* display@type=h timezone
  TIMEZONE  'H'  +0
* display@type=c@len=8 timezone+2
  TIMEZONE+2  'C'  "GMT     "

Use stop to get out of *OBJUTIL.

Back to RAMROD

Run RAMROD again and create a new system from the current system to incorporate your changes:

# $run mts:ramrod
  Using file "RMRD:ROD"
~ create D6.0A-CT214
  ** Fromsystem = "D6.0A-AN172"
  & OK
? ok
  Enter comments:
? 2014-10-21 Modify timezone

The new system name D6.0A-CT214 needs some explanation. The D6.0A is obvious; the CT214 comes from a convention for naming releases that is described in the distribution driver file:

            1.   The name of the system installed is changed to the "model
                 number" of the date it is installed, e.g. "AY108" for May 10,
                 1978. [2nd and 3rd letters of the month name, two digit day
                  of the month and one digit year.]

So this system I am creating was made on October 21, 2014.

Next, replace the TABLES deck with the one you just edited; supply a comment and leave the version code blank:

~ replace from -tables
  Enter comments:
? 2014-10-21 Modify timezone to GMT
  Enter version code:
  ** REPLACE deck "TABLES.MP" from file "-TABLES" :
  & OK
? ok

You can list the patches again, to be sure:

~ list deck patches
 TABLES.MP (OCT21-14) patched changed
 REP  004088  0400030001,00000240,00000030,000002A0,00000180 Rearrange OPERDEVS 01:26:36 01-06-12 MTS.
 REP  000180  01F1F0F5F2 CON1 IS A 1052 01:26:51 01-06-12 MTS.
 REP  003F8A  04,FED4 Make the timezone offset -300 (GMT minus 300 minutes or 5 hours)
 REP  003F8C  04,C5E2E340 Make the timezone name "EST"
 REP  003F8A  04,0000 Set timezone to GMT
 REP  003F8C  04,C7D4E34040404040 Set timezone name to GMT

Finally, use the current command. This will check the system and write to the IPL files:

~ current
 There are 4 IPL files with prefix "*IPL.   "
 Loading system D6.0A-CT214 using the UMLOAD deck it contains.
 LOAD: Resident: 2000-5DFC8 UMLOAD Psect: B0000 Pageable: DD000-191A70 End: 1DCFFF
 Contents of IPL file "*IPL.3":
 AN052 ENTRY=56D18 PSECT=100008 VIRTUAL=B0000...191A70 VIRTUAL_START=100000 UMLOADTV=2000
 COM 18:50 Jan 05 - Replace RSF to fix the halfword date problem.
 ** Write system "D6.0A-CT214" to IPL file "*IPL.3":
 & OK
? ok
 System "D6.0A-CT214" has been written to  IPL file "*IPL.3"
 IPL file stacked has been pushed.
 System "D6.0A-CT214" is now the current system.
 "D6.0A-CT214" : Released.
 System "D6.0A-CT214" has been Frozen.

The moment of truth

Get out of RAMROD with stop and then reboot the system as normal. When it comes up you should get a warning that the timezone has changed, which you can just ok.

 00000   ** UMMPS/XA ** assembled 04/19/88
 00000 CONFIG CPU 0000 online
 00000 CONFIG CPU 0001 online
 00001 INIT Time and date have been set to  14:45:22 on 10-21-14.
 00002 OPERATOR   Started at 14:45:22 on 10-21-14  Model 3090 Serial 000611
 00002 OPERATOR   Using display DS01 & printer CON1 (1052)
 00004 MTS  Timezone "GMT" is different from timezone during last IPL ("EST").
 00004 MTS  If you are sure the time is set correctly, enter "OK" to proceed wit
 00004 MTS   IPL; otherwise re-IPL now.

Later on in the boot sequence you can see the new system:

00004 MTS  Reload at 14:45:56 on 10-21-14.  Model: IBM 3090/FF  Serial: 611  
00004 MTS  System: D6.0A-CT214 written at 08:34:51 on TUE OCT 21/14.  

And that's it! The operator's console will now show the correct time for your timezone, as should the display time command from MTS.

Further information

There's a summary of this process in the D6.0A FAQ and I also found the conversation between Ron Frederick and Jeff Ogden on the H390-MTS Yahoo list useful to understand the steps required.

Original instructions to new sites on patching the system deck can be found in the D6.0-NOTES.txt file in the distribution archive.

RAMROD has a writeup in file RMRD:RAMROD*PF, with the wonderful introduction:

         Cards were made for salesmen and bridge players and in that
    domain they should have undoubtedly remained. Their passing will
    not be mourned by those enlightened programmers  who  have  seen
    fit to rise above the hardcopy world and to place their faith in
    the wonderous MAGNETIC MEDIUM.

*OBJUTIL is described in Volume 5 of the MTS documentation. You can bypass *OBJUTIL and use the patch command in RAMROD, but *OBJUTIL has much better facilities to enter number and character patches, and to check your work. Using patch you have to find the address of TIMEZONE, the ESDID where it located, and convert the offset and the timezone description (in EBCDIC, not ASCII!) to a sequence of hex characters, eg

  Address Esdid Text <comments> :
? 3F8A 4 0000C7D4E34040404040

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 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

  • SPACE: not in use
  • A for active, ie the file is being written to
  • B for busy: CMDTAPE is copying it to tape
  • F for full: the file needs to be written to tape

Status for tapes is similar:

  • A for available but not mounted
  • B for 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.

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 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/ 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


Create a new tape from your host OS command line:

hetinit -d Tapes/ CMD002  

and at the Hercules console do

devinit 018a Tapes/ 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 Also remember to update the line in hercules.cfg for the tape to add the maxsizem parameter:

018A 3420 Tapes/ 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 writeup 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.

Users and projects

Rather than be limited by the set of user IDs in the starter system, you can create one or more user IDs for yourself. This post will look in more detail how user IDs are created and used in MTS.

User and project IDs

User IDs (or ccIDs) in MTS are four characters long, optionally right padded with . if shorter (eg ACC.).

Each user ID is a member of one project, which also has a four character ID. A project can have zero or more user IDs in it. Project IDs allowed funds for students on a course or a research team to be grouped together; it also allows sharing of files within a group.

Note that unlike groups on Unix a user ID can only be a member of one project. One upshot of this on the mainframe is that a person may have several different user IDs, for example one for each course they are on. Thee is no concept of root or Administrator on MTS, but an ID can have extra privileged, eg the ability to access devices directly.

Creating a new user ID

User and project records are stored in file *ACCOUNTING and sub files matching *ACCOUNTING?. Rather than edit these directly you should use the ACCMAINT program.

Signon as user ACC using password aardvarks and then a secondary ID like ST01. $run ACCMAINT to start the program, setting unit 0 to be where you want output, eg *print* or *sink*.

You can now use commands like CREATE and DESTROY. Here's a sample session where we CREate a privileged ID ABC.

# $run accmaint 0=*sink*
# Execution begins   02:55:29 


  ABC. password is SECRET1          Name:
  ABC.             SECRET1 
  ABC.             SECRET1 
       (Hexadecimal representations:  ID=X'C1C2C34B' PW=X'E2C5C3D9C5E3F1')

Looking at the parameters:

  • 0 is the university account number
  • 10000 is the maximum disk space in pages
  • The project name is WABC: this must start with a W to provide system level privileges.
  • LIBRARY - can create a public file, eg one starting with *
  • PRIV - bypass checks on funds
  • PROTECT - run privileged commands, eg get tape devices directly with GET
  • Other blank fields are to control resource use and can be blank as shown.

It should also be possible to create non-privileged IDs this way but I have not worked out how to set up funds: if I enter the command

CRE BA01,0,,,,,10000,,,,BABA,PASSWORD=secret1  

and then sign on as ba01 I get The funds allotted this user ID have been depleted. - if you know how to do this let me know in the comments.

Update 14-Apr-2015: see Jeff's comment below on how to do this.

Removing a user ID

$run ACCMAINT as user ACC as before but use the DESTROY command with the user ID and the account number. For example, to remove user ABC.:

# $run accmaint 0=*sink*
# Execution begins   03:06:37 


Getting user and project information

There are other programs under ID ACC that may be useful; some examples:

  • ACCDISPLAY prompts for a user ID and prints out detailed information for the ID
  • ACCLISTING lists out info on all user IDs
  • PROJECTDISP prompts for a project ID and provides details
  • PROJECTIDS prompts for a project ID and lists all users in the project
  • PROJECTLIST shows details on all projects in the system

Run $filestatus when signed on as ACC to see the list.

Changing password

To change the password of the currently signed-on MTS ID, do SET PW. It will ask for the old password first then the new password twice for confirmation.

To change the password for an account you don't know the password for, sign on as the user WPSW, enter a secondary signon ID/password and then $run program1. If you type a user ID it will reset the password to something new. An example for our new account ST03:

# $run program1
# Execution begins   03:17:16 
  Password previously set at 04/19/88 17:19:01 EDT has been reset to YLU6GM 
  end of file
# Execution terminated   03:17:26  T=0.011 

CKID and secondary signon

Some privileged IDs, such as MTS, are protected by requiring a secondary sign on. Access is controlled by the file CKID:ACCESS with lines of the form

priv_id secondary_id1 [secondary_id2...]  

To change this file you will need to sign on as CKID. In the starter system the password for this account is not supplied, so first change its password using the instructions in the previous section.

Edit the file ACCESS using $edit (it's wise to take a backup first). A typical line for ID MTS looks like this so you can add secondary IDs at the end or remove secondary IDs you don't need.

MTS. ALWB DLB. DRH. DWB. KLB. MTA. SRB. WSG. W013 W030 W05Q W070 W170 ST00 ST01 ST02 ST03 ST04 ST05 ST06 ST07 ST08 ST09 AB01

You could also add new privileged IDs and who can access them by adding lines to this file. To ensure the secondary signon is checked at signon, set the sigfile (the command file run at signon) for the account being protected to CKID:CKID.SIG with set sigfile=CKID:CKID.SIG.

Further information

A writeup on the accounting system can be found in component 104/172 on the MTS tapes. See restoring components for details on how to do this and the FAQ question 31 on how to print the guide.