MTS system architecture

The University of Michigan Multi-Programming Supervisor (UMMPS), has complete control of the hardware and manages a collection of job programs.[3] One of the job programs is MTS, the job program with which most users interact.[4] MTS operates as a collection of command language subsystems (CLSs). One of the CLSs allows for the execution of user programs. MTS provides a collection of system subroutines that are available to CLSs, user programs, and MTS itself.[5][6] Among other things these system subroutines provide standard access to Device Support Routines (DSRs), the components that perform device dependent input/output.

The system is organized as a set of independent components with well-defined interfaces between them.[3] This idea is, of course, neither new nor unique; but MTS components are generally larger, interfaces between components more rigid, and a component communicates with fewer other components than in many systems. As a result, components are more independent of each other and it is easier to replace one component without affecting others.

The interface with the supervisor is the same for all components and very few special cases are allowed; for example, all input/output operations are done using the same supervisor facilities whether the input/output is for a card reader, a paging device, or any other device. Most access to supervisor services is via system subroutines that issue the necessary Supervisor Call instructions (SVCs) rather than by direct use of SVCs. Control blocks are accessed only indirectly by calls to subroutines within the component that "owns" the control block.

The interfaces used by user programs are the cleanest of all. User programs may never refer directly to any system control block (neither for reference nor change), because the virtual memory segment(s) that contain system control blocks (the system segments) are removed from a job's virtual address space when a user mode program is running. The subroutine interfaces available to user programs are also used by most other parts of the system (system mode programs, CLSs, ...) even through components running in system mode do have access to the "system" virtual memory segment(s). Transitions from user mode to system mode and back are managed by a special protected set of subroutine interfaces known as "the gate" (initially developed at Wayne State University).[2]

The programming effort for MTS is divided vertically rather than horizontally. This means that one or two individuals are assigned responsibility for a component and then follow it from design through implementation and maintenance. The responsible person has considerable freedom to design the internal structure of the component and even extend interfaces, so long as all appropriate existing interfaces are maintained unchanged.

The supervisor, most job programs, large parts of MTS including many DSRs and CLSs are written in 360/370 assembler language. A few job programs and portions of MTS including some DSRs and CLSs are written in higher level languages such as Plus or GOM. User programs are written in a wide range of languages from assembler to any of the higher level languages that are available.

Most components of the system, including user programs, CLSs, and subroutines loaded in shared virtual memory, can be debugged and new versions of many can be installed while the system is running without requiring a system shutdown. It is possible to substitute a private copy of all components except the supervisor and parts of some job programs. A "test" version of the MTS job program (TMTS) is available to allow testing in the regular production environment. SWAT is an interface that allows the Symbolic Debugging System, which is normally used to debug user programs, to be used to debug MTS.[7] $PEEK is a privileged MTS command that uses Program Event Recording (PER) and other facilities to facilitate debugging one job program from another.[7] Components that cannot be debugged in this way can be debugged by running in an MTS virtual machine (a user program).

University of Michigan Multi-Programming Supervisor (UMMPS) is the name of the MTS supervisor.[8] UMMPS is the only portion of the system that runs in S/360 supervisor state. It runs with virtual memory (relocation) turned off and with hardware interrupts disabled. With multi-processor configurations it may be executing on more than one processor concurrently. UMMPS is what today would be called a microkernel, although UMMPS was developed long before that term was in common use.

To jobs UMMPS appears to be an extension of the S/360 or S/370 hardware and is responsible for:

• allocating all hardware resources (processors, real memory, input/output devices),
• scheduling I/O operations,
• processing all hardware interrupts including page-faults and program interrupts due to errors in job programs,
• implementing virtual memory including:
  • the allocation of VM addresses,
  • managing segment and page tables,
  • providing protected or read-only memory by setting storage keys,
  • managing memory reference and change bits,
  • managing named address spaces (NASs),
  • determining when and which pages should be moved between real memory and secondary storage to implement demand paging,
• providing services to job programs that issue Supervisor Call (SVC)[9] and Monitor call (MC) instructions, including:
  • starting and terminating jobs,
  • initiation of input/output operations (channel programs),
  • scheduling timer interrupts,
  • communication with the system operator,
  • providing inter-task communication services,
  • allowing jobs to acquire and release software locks,
  • allowing jobs to enter and leave user and system mode, where user mode programs do not have access to some virtual memory segments and the full range of SVCs,[2]
  • providing services to allow the synchronization of job programs,
  • providing shadow segment and page tables and other services that allow job programs to provide virtual machine services,
• simulating a few machine instructions that are present on some, but not all, models of the S/360 or S/370 computers,
• simulating the Branch on Program Interrupt (BPI) pseudo instructions,
• machine check error recovery,
• writing job dumps (making a snapshot of the current execution state of a job by writing out all real memory, all the job's virtual memory, general registers, and program status word to magnetic tape),
• tracking the amount of processor time used and the number of page-ins for jobs,
• maintaining the time of day clock, and
• assisting in the creation of diagnostic trace tapes.

After initialization UMMPS is entirely interrupt driven. The interrupts may be due to supervisor (SVC)[9] or monitor (MC) call instructions issued by job programs to request services, page fault interrupts for virtual memory pages that are not in real memory when referenced by a job program, program interrupts caused by abnormal conditions in job programs, timer interrupts on behalf of job programs or used internally within the supervisor, interrupts from the input/output subsystem, machine check interrupts, external (operator initiated) interrupts, and interrupts from other processors in a multiprocessor configuration.

A program interrupt in supervisor state is a system failure that results in a supervisor dump (a Super Dump, where the machine state and the contents of all real memory is written to magnetic tape) followed by a system restart (re-IPL).

  BPI    M2,D2(B2)        [RX]

  BC     0,D2(M2,B2)      [RX]

   Op Code        Mask1   Mask2   Base    Displacement
  +--------------+-------+-------+-------+------------+
  |    x'47'     |   0   |   M2  |   B2  |    D2       |
  +--------------+-------+-------+-------+------------+
   0              8       12      16      20         31

All job programs run in S/360 problem state, may run with virtual addressing enabled or disabled, and may or may not be reentrant (more than one instance of the job program may or may not be allowed to execute). With multiprocessor configurations a single job will only execute on a single processor at a time, but the supervisor may assign a job to different processors at different times.[8]

The MTS job program is the one with which most users interact and provides command interpretation, execution control, file and device management, and accounting services.[4] Other job programs assist the supervisor (the Paging Device Processor or PDP, the OPERATOR console job, the Disk Manager or DMGR, ...), provide common or shared services (spooled local and remote batch services via HASP and the HASPlings or later the Resource Manager or RM which was developed at the University of British Columbia to replace HASP), or allow the system operators to display status and otherwise control the system (JOBS, UNITS, STOP, BLAST, GOOSE, STARTUP, SHUTDOWN, REW, WTM, ...).

New jobs, other than the very first job, are started by requests to UMMPS from other jobs, most often the OPERATOR job. The very first job, INIT, is started immediately after IPL and supervisor initialization.

From their start and for much of their lifetime UMMPS and MTS operated using 24-bit addressing. UMMPS never used the 32-bit virtual memory addresses that were available on the IBM S/360-67.[11]

In August 1982 the University of Alberta changed UMMPS to operate in 31-bit addressing mode to allow more than 16 MB of real memory to be used, although real memory above 16 MB was only used for to hold virtual memory pages. Job programs and user programs continued to use 24-bit addresses.

In 1985 Rensselaer Polytechnic Institute (RPI) made changes to UMMPS to support S/370-XA which among other things allowed either 24 or 31-bit addressing for job programs and for user programs running under MTS. Changes were made at the University of Michigan in 1990 to allow user programs using 31-bit addresses to work smoothly: object modules could be flagged as supporting 31-bit addressing (or not), compilers and assemblers were changed to supply the correct flags, programs would switch between 24 and 31-bit addressing modes as needed when transitioning between system and user modes.

MTS has a strong protection model that uses the virtual memory hardware and the S/360 and S/370 hardware's supervisor and problem states and via software divides problem state execution into system (privileged or unprotected) and user (protected or unprivileged) modes. Relatively little code runs in supervisor state. For example, Device Support Routines (DSRs, aka device drivers) are not part of the supervisor and run in system mode in problem state rather than in supervisor state.[2][12][13]

Wikisource has original text related to this article:

The Paging Game

Virtual memory (VM) and demand paging support were added to UMMPS in November 1967, making MTS the first operating system to use the Dynamic Address Translation (DAT) features that were added to the IBM S/360-67.[3]

UMMPS uses 4096-byte virtual memory pages and 256-page virtual memory segments. UMMPS could be conditionally assembled to use the small (64 page) segments that were available on S/370 hardware, but job programs were always presented with what appeared to be large (256 page) segments. Both 2K and 4K block storage keys are supported.

There is a three-level storage hierarchy: (1) real memory, (2) high-speed paging devices, and (3) paging disks. High-speed paging devices include the IBM 2301 Drum, IBM 2305 Fixed Head File, and various third party "solid-state" I/O devices such as the STC 4305 and Intel 3805 that simulate spinning disks or more often provide more efficient fixed block architecture (FBA) access to external RAM-based storage.[14] The high-speed paging devices are attached using "two-byte" I/O channels operating at up to 3.0 MB per second whenever possible. The paging disks were separate from the disks used for the file system and were used if the higher speed paging devices became full. Virtual memory pages migrate between real memory and the paging devices. In the early versions of MTS pages did not migrate between individual paging devices. In later versions, less frequently used pages would migrate from the high-speed paging devices to the paging disks, when the high-speed devices were close to being full. Later in its life the system was changed to use IBM S/370-XA Extended Storage as part of the second level of the storage hierarchy and to use the same disks for the file system and for paging.

Virtual memory is managed by UMMPS with assistance from the Paging Device Processor (PDP) job program. UMMPS responds to requests to allocate and free VM from job programs, allocates VM addresses, allocates real memory, manages segment and page tables, sets storage keys, manages reference and change bits, determines which virtual memory pages should be paged in or out, and communicates with the PDP. New virtual memory pages are initialized to a "core constant" value of x'81' on first reference.

The PDP is a real memory job program. It allocates space on the paging devices, initiates all I/O to the paging devices, is responsible for recovery from I/O errors, and communicates with UMMPS.

To reduce the likelihood of thrashing UMMPS uses a "big job mechanism" that identifies jobs with more real pages than a threshold, limits the number of these "big" jobs that are eligible to execute at a given time, and gives the big jobs an extended time slice when they do execute. This allows big jobs to accumulate more real memory pages and to make better use of those pages before they come to time slice end, but big jobs will wait longer between time slices when there are too many big jobs contending for limited real memory pages. The number of pages that a job can have before it is considered big (the big job threshold or BJT) and the number of big jobs (NBJ) that are eligible for execution are external parameters that are reevaluated and set outside of the supervisor every 20 seconds based on the overall system load.

Other than the big job mechanism, UMMPS storage, processor, and I/O scheduling are independent, with each area allowed to "take care of itself".

Virtual memory is divided into regions as follows:

• Segment 0: shared virtual equals real memory (read-only)
• Segments 1 to 4: shared virtual memory (read-only)
• Segment 5: private virtual memory (system segment, only available to system mode (unprotected) programs)[2]
• Segments 6 to 12: private virtual memory (user segments, read-write to any program)[5]

Different numbers of segments were assigned to the various regions over time and with the advent of 31-bit addressing and the ability to use VM segments larger than 16, the regions were expanded as follows:

• Segment 0: shared virtual equals real memory (read-only)
• Segments 1 to 5: shared virtual memory (read-only)
• Segments 6-7: private virtual memory (system segments, only available to system mode (unprotected) programs)
• Segment 8: shared virtual memory for attachment of named address spaces (NASs) (read-only)
• Segments 9-55: private virtual memory (user segments, read-write to any program)
• Segments 56-59: private virtual memory (system segments, only available to system mode (unprotected) programs)
• Segments 60-63: shared virtual memory for attachment of named address spaces (NASs) (read-only)

Some real memory is not addressable using virtual memory addresses and so is only available to UMMPS or real memory job programs. Read-only virtual memory may be changed by privileged programs that turn memory protection off (usually for very limited periods of time).

Named address spaces (NASs) allow the attachment of named segments of virtual memory. They are shared virtual memory spaces that may be attached and detached from a given job's virtual address space and the same addresses may have different contents depending on which named address spaces are attached. NAS support is mostly used by MTS to attach VM segments preloaded with system components as a way to extend shared virtual memory without using VM address space below the magic 16 MB line and thus keeping more of this valuable address space available for use by 24-bit user programs.

Everybody who uses MTS is assigned a signon ID (also called userids or Computing Center IDs, CCIDs).[4] Signon IDs are always 4 characters long. If necessary shorter IDs are automatically padded on the right using the string ".$.". Thus, the IDs "MTS.", "DAB.", "ME$." or "C.$." could be written as "MTS", "DAB", "ME" and "C", respectively.

Signon IDs are protected using passwords which must be given at the start of each session (as part of or more often immediately after the $SIGNON command). Exceptions are jobs submitted via *BATCH* that run under the same ID that submitted the new job, jobs scheduled to run repeatedly at a particular time or on a particular day when the jobs run under the same ID that scheduled them, or jobs initiated from the operator's console. Passwords are from 1 to 12 characters long, lower case letters are converted to uppercase, special characters other than comma and blank are allowed. Passwords can be changed using the $SET PW command. Changing a password from a terminal session requires entering the original password, and the new password must be entered twice for verification.

Entering an incorrect password is counted and reported to the user at the next successful signon. Too many password failures without a successful entry are reported to the system operator and still more password failures without a successful entry will cause the signon ID to be "locked out" until it is reset by business office staff. A short delay is introduced between failed password entry attempts to prevent large numbers of password "guesses" from being made quickly.

Individuals can have multiple sign on IDs for use in different courses, different research projects, or with different funding sources (university, government, non-profit, industry, ...). The sharing of signon IDs by individuals is discouraged, but does occur.

Signon IDs are grouped into projects. Each signon ID is a member of one and only one project. Project IDs, like signon IDs, are 4 characters long. Many projects are controlled by a "Project Leader" signon ID which can allocate resources to the accounts that are members of the project (within the resource limits allocated to the project) using the $ACCOUNTING MANAGEMENT command.

Signon and project IDs are also used to control access to files and to send e-mail.

With one exception there are no signon IDs with "special" privileges by virtue of the ID itself. Instead, flags can be set that allow specific signon IDs to:

• create public files and set public program keys,
• run with a zero or negative account balance,
• perform privileged operations,[2] including:
  • flagging files to run in system (unprotected) rather than user (protected) mode by default,
  • use the PROT=OFF options on the $SET and $RUN commands,
  • use the test command language subsystem ($#CLS),
  • use privileged options of the $SYSTEMSTATUS and other command language subsystems (CLSs).

The exception is the signon ID "MTS.", which can read, but not modify or permit, any file in the system regardless of ownership or permit status. The MTS. ID can also use the $SET FILEREF=OFF option, which prevents the file reference dates on files from being updated (useful when recovering from file system problems or investigating security issues).

There is no ability for a program or user to assume the privileges of a signon ID other than the one that was used to sign on to the current session. Instead, programs and files may be permitted to specific signon IDs, projects, and program keys or to combinations of signon IDs, projects, and program keys.

MTS supports terminal, batch, and server sessions.[4] All three use the same command language.

• Terminal sessions are interactive with the user able to respond to the output produced including error messages and prompts.
• Batch jobs are not interactive and so all input needs to be prepared in advance with little or no opportunity for the user to alter the input (at least not without programming) once the batch job starts to execute.
• Server sessions can support user to MTS or client to MTS interactions and while there may be interaction with the user, MTS commands are usually read from a command file and the user is not likely to have to know or enter MTS commands. Server sessions can be sponsored in which case they will appear to be free to the user, and do not require that the user enter an ID and password. Server sessions can also be charged for and require a valid ID and password. Server sessions can be initiated from the network or from within an MTS session using the $MOUNT command.

The University of Alberta developed a Student Oriented Batch Facility in 1971 to provide quick job turnaround for undergrad students learning to program in FORTRAN, ALGOL, PL/C, and 360 Assembler. It was a dedicated punch card input, printer output system that provided 5 minute turn around and ran several thousands of jobs a week at a fixed cost per job (15 cents).

MTS reads commands from the *SOURCE* pseudo device, which is initially the user's terminal or the batch input stream.[4] Programs may execute MTS commands by calling the CMD, CMDNOE, and COMMAND subroutines.[5]

Leading and trailing blanks as well as null and all blank lines are ignored. Lines that start with an asterisk (* or $*) are treated as comments. Command lines that end with a continuation character (by default the minus-sign) are continued on the next line. Command lines may be up to 255 characters long.

MTS uses keyword oriented commands and command options. The command verb (SIGNON, RUN, EDIT, ...) is the first keyword on the command line. Commands may start with an optional dollar-sign ($SIGNON, $RUN, $EDIT, ...). In batch jobs, following invalid commands and some other errors, MTS looks for the next line that starts with a dollar-sign ($) in column 1 as the next command to execute. All commands and most command options allow initial sub-string abbreviations (C for COPY, R for RUN, DEB for DEBUG, ...). MTS commands and most command options are case-insensitive.

MTS has "one-shot" commands (CREATE, FILESTATUS, SIGNOFF, ...) and commands that have sub-command modes (EDIT, CALC, SYSTEMSTATUS, ...). Most commands with sub-command modes can also be invoked as one-shot commands by giving one or more sub-commands on the command line.

All MTS jobs start with a SIGNON command and most end with a SIGNOFF command. Commands may be stored in files and executed using the SOURCE command. Commands may be stored in signon-files (sigfiles) or project-signon-files (projectsigfiles) that are always executed immediately after the SIGNON command. The execution of sigfiles may be required (SIGFILEATTN=OFF) or optional (SIGFILEATTN=ON, the default).

SIGNON  { ccid | * }  [ option ... ]  [ comment ]
SIGNOFF  [ SHORT | $ | LONG ]  [ RECEIPTS | NORECEIPTS ]
ACCOUNTING  [ option ... ]
ACCOUNTING  MANAGEMENT
COMMENT  [ text ]
DISPLAY  item  [ OUTPUT=FDname ]
SET  option ...
SINK  [ FDname | PREVIOUS ]
SOURCE  [ FDname | PREVIOUS ]
SYSTEMSTATUS [ option ]
#CLS  FDname  [ options ]  (privileged command that runs a test CLS)[7]

CREATE  filename  [ SIZE={ n | nP } ]  [MAXSIZE={n | nP} ]  [TYPE={LINE | SEQ | SEQWL} ]   
DESTROY  filelist  [ OK | ALLOK | PROMPT ]
DUPLICATE  oldname  [ AS | TO ]  newname  [ options ] [ OK | ALLOK | PROMPT ]
EDIT  [ filename ]  [ :edit-command ]
EMPTY [ filelist ]  [ OK | ALLOK | PROMPT ]
TRUNCATE  filelist  [ ALLOK | PROMPT ]
RENAME  oldname  [ AS ]  newname  [ OK | ALLOK | PROMPT ]
RENUMBER  filelist  [ first [ last [ begin [ increment ] ] ] ]  [ ALLOK | PROMPT ]
FILESTATUS  [ filelist ]  [ format ]  [ items ]
FILEMENU  [ filelist ]  [ items ]
FMENU  [ filelist ]  [ items ]
PERMIT filelist  [ access [ accessor ] ]
PERMIT filelist  LIKE  filelist2  [ EXCEPT access [ accessor ] ]
LOCK filename  [ how ]  [ WAIT | NOWAIT ]  [ QUIT | NOQUIT ]
UNLOCK  filename
LOCKSTATUS  [ filename | JOB nnnnnn ]  [ LOCK ]  [ WAIT ]
LSTATUS  [ filename | JOB nnnnnn ]  [ LOCK ]  [ WAIT ]

COPY  [ FROM ]  { FDlist1  | 'string' }  [ [ TO ] [ FDlist2 ] 
CREATE  *pdn*  TYPE={ PRINT | IMPORT | EXPORT | DUMMY }
DESTROY *pdn*  [ OK | ALLOK | PROMPT ]
LIST  FDlist  [ [ ON | TO ]  FDname ]  [ [ WITH ] option ... ]
LIST  FDlist WITH  options [ {ON | TO} FDname ]
LIST
MOUNT  [ request [; request ] ... ]
CANCEL  *...* [ [ JOB ] nnnnnn ]  [ {ID | CCID}=ccid ]
RELEASE  { *PRINT* | *PUNCH* | *BATCH* | *pdn* }
LOCATE  { SYSTEM | LOCAL | FULL | SHORT | HELP }
LOCATE  { jobnumber | jobname }  [ option  ...  ]
VIEW  [ jobnumber [ ; view-command ] ]
LOG  [ FDname1 ]  { [ ON ] FDname2 [ format ]  [ options ] | OFF }
FTP  [ hostname ]
GET  FDname  (old fashioned and obsolete, but sometimes still useful)[7]
NUMBER  (old fashioned and obsolete way to enter data into a file)[7]

RUN  [ FDname ] [ I/Ounits ]  [ option ] ... [ PAR=parameters ]
RERUN  [ ECHO | NOECHO ]  [ I/Ounits ]  [ option ] ...  [ PAR=parameters ]
DEBUG [ FDname ] [ I/Ounits ]  [ option ] ... [ PAR=parameters ]
SDS  [ sds-command ]
LOAD  [ FDname ] [ I/Ounits ]  [ option ] ... [ PAR=parameters ]
START  [ [ AT ]  [ RF={hhhhhh | GRx} ] location ]  [ I/Ounits ]  [ option ] ...
RESTART  [ [ AT ] location ]  [ I/Ounits ]  [ option ] ...
UNLOAD  [ CLS=clsname ]
ALTER  location value ...  ...
DISPLAY  [ format ]  location  [ OUTPUT=FDname ]
DUMP  [ format ]  [ OUTPUT=FDname ]
IF  RUNRC  condition  integer, MTS-command
ERRORDUMP (obsolete command, causes an  automatic dump in batch mode following abnormal termination of a user program)[7]

CALC  [ expression ]
MESSAGESYSTEM  [ message-command ]
FSMESSAGE  [ FSMessage-command ]
NET  [ host | *pdn* ]  [ .network-command ]
HEXADD  [ hexnumber1 ]  [ hexnumber2 ]  (obsolete, replaced by $Calc)[7]
HEXSUB  [ hexnumber1 ]  [ hexnumber2 ]  (obsolete, replaced by $Calc)[7]
PASSWORD  (obsolete, removed, allowed changes to public files 
           before true shared file access was available)

#      MTS command mode
#-     MTS command continuation mode
?      Prompts
>      COPY and LIST commands
.      Program loader
blank  User programs
:      Editor
+      Symbolic Debugging System (SDS)
@      Message System
ftp>   FTP (File-Transfer)

User program refers to a program run by the user and which is not necessarily a program that belongs to or that was created by a user. User programs may be supplied in public files, in files available under the OLD: or NEW: signon IDs, in files belonging to other users and permitted for use by others, or user programs may be developed by the current user in files that they own.

User programs are executed using the $RUN, $RERUN, and $DEBUG commands or less often using the $LOAD and $START commands. The $RESTART command may be used to restart execution of a program following an attention interrupt that was not handled by the program, a program interrupt that was not handled by the program (although restarting after a program interrupt usually does not work well), or following an explicit return to MTS from a call to the MTS subroutine.

MTS loads programs using a dynamic linking loader (UMLOAD) that reads loader records (ESD, TXT, CSI, RDL, LCS, END, ...) from the file or device specified by the user and will selectively include subroutines from libraries supplied by the user, from system subroutine libraries such as *LIBRARY, and from system subroutines pre-loaded in shared virtual memory. MTS uses standard OS/360 loader records which makes it fairly easy for MTS to use compilers developed for use under other IBM operating systems.[3]

When a program starts execution a number of logical I/O units will be set either explicitly on the $RUN or other command or by default. Any text string given following the PAR= keyword is passed to the program as a parameter.

By default user programs execute with the program key *EXEC, but a different program key may be set using the $CONTROL command.[4] Programs may call a system subroutine to shorten the program key they are using or switch to the *EXEC program key thus temporary giving themselves less access to files, devices, and other services controlled using program keys. Programs may also call a system subroutine to lengthen or restore their program key according to some pre-established rules.

MTS uses the standard S-type and, less often, R-type calling sequences used in OS/360.[5]

By default user programs execute in user mode in problem state.[2] User mode programs do not have access to the system virtual memory segment and therefore have no access to system control blocks, may not call privileged system subroutines, and may not issue privileged supervisor calls (SVCs). User mode programs can issue non-privileged SVCs, but few programs do so directly and instead call system subroutines to obtain system services. User mode programs may call system subroutines that switch to system mode after checking that the protected service is allowed for the particular caller, there is a return to user mode when the system subroutine returns.

Selected user programs can be flagged to run in system rather than user mode by staff with privileged signon IDs or staff with privileges can cause a user program to run in system mode using a keyword on the $RUN or $SET command.[7]

All input/output requests, whether by the MTS job program itself or by a program running under MTS, is done using a common set of subroutine calls (GETFD, FREEFD, READ, WRITE, CONTROL, GDINFO, ATTNTRP, ...). The same subroutines are used no matter what program is doing the I/O and no matter what type of file or device is being used (typewriter or graphics terminal, line printer, card punch, disk file, magnetic and paper tape, etc.). No knowledge of the format or contents of system control blocks is required to use these subroutines. Programs may use specific characteristics of a particular device, but such programs will be somewhat less device independent.

MTS input/output is record or line oriented. Programs read lines from a terminal, card reader, disk file, or tape and write lines to a terminal, printer, disk file, or tape. Conversion to and from ASCII/EBCDIC and end-of-line processing is usually done by a front end processor or Device Support Routine (DSR) and so is not a concern of most programs. While it is possible to do character I/O to a terminal by reading or writing single character lines, reading or writing many such very short lines is not very efficient.

Each line read or written consists of from 0 to 32,767 bytes of data and an associated line number (a signed integer number scaled by 1000) giving the line's location. The length of each line read or written is given explicitly, so programs do not need to do their own processing of line ending characters (CR/LF, NL) or other terminators (null). Some devices support zero length lines, while others do not. For many files and devices the line number is simply a sequential count of the lines read, while some file types explicitly associate a specific line number with each line of the file, and in other cases the line number is synthesized from data that appears at the start of an input line or the line number can be prepended to an output line.

 FILE1@-TRIM  (I/O modifier that retains trailing blanks)
 FILE2(1,10)  (line number range that reads lines from 1 to 10 inclusive)
 FILE3+*SOURCE*  (explicit concatenation)
 FILE4(1,10)@-TRIM+*TAPE*@-TRIM (all of the above in a single complex FDname)

$CONTINUE WITH FDname

$CONTINUE WITH FDname RETURN

IBM 2314 disk drives and IBM 2540 card reader/punch at the University of Michigan Computing Center, c. 1968

IBM 2321 data cell at the University of Michigan Computing Center, c. 1968

MTS files are stored as 4096 byte "pages" on one or more public or private disk volumes.[16] Volumes have volume labels, volume numbers, and volume names (usually MTS001, MTS002, ..., MTSnnn). Disk volumes are stored on traditional cylinder-track-record and fixed block architecture (FBA) disk drives or at one time on the IBM 2321 Data Cell.

Individual files do not span disk volumes. The maximum size of a file is limited to the free space available on the disk volume where it resides. By default, files are created one page in size, but a larger size as well as a maximum size may be specified ($CREATE name SIZE=nP MAXSIZE=nP). Files will automatically expand until they reach their maximum size or the disk space limit for the owner's signon ID is exceeded. Users may request that a file be created on a specific disk volume ($CREATE name VOLUME=name).

MTS files fall into one of three categories: public files, user files, and temporary files:

• Public files are files whose names begin, but do not end, with an asterisk (e.g., *LIBRARY, *USERDIRECTORY). Public files, often called 'star files', are publicly available files that contain programs and data that are widely available to all users. For example, *LIBRARY is a library of commonly used system subroutines. In the earliest days of MTS public files were the only files that could be shared and then only as read-only files. Later, public files could be permitted and shared in the same fashion as any other files.
• User files are files whose names do not begin with an asterisk or a minus sign. They must be explicitly created ($CREATE) and destroyed ($DESTROY). They are owned by and initially permitted to just the userID that creates them, but they can be permitted for use by other userIDs using the $PERMIT command. To reference a file belonging to another user, the file name is prefixed with the owner's userID followed by a colon (e.g., W163:MYPROGRAM). There are charges for the amount of disk space used and most signon IDs have a maximum disk space limit.
• Temporary files are files whose names begin with a minus sign (e.g., -TEMP). Their names are unique within a single session. They are created implicitly on first use, are not charged for, do not count against a signon ID's disk space limit, and are automatically destroyed when the terminal or batch session ends.

MTS doesn't implement directories, but there is a de facto two-tier grouping of files owing to the inclusion in a file's name of its owner's four-character MTS user ID.

File names, like all FDnames, are converted to uppercase before use and so are case-insensitive.

    $lock FILE1 RENAME
    $rename FILE1 as FILE2
    $create FILE1

An early computer terminal, the Teletype Model 33 ASR with attached paper tape reader/punch

A DEC VT100 display terminal

PDP-8 Data Concentrator at the University of Michigan, c. 1971

A Tektronix 4014 display terminal

Touch-tone Telephone

Merit PDP-11 based Primary Communications Processor (PCP) at the University of Michigan, c. 1975

IBM 3279 display terminal

At its peak, MTS at the University of Michigan simultaneously supported more than 600 terminal sessions as well as several batch jobs.[4]

Terminals are attached to MTS over dial-in modems, leased or dedicated data circuits, and network connections. The Michigan Communications Protocol (MCP), a simple framing protocol for use with asynchronous connections that provides error detection and retransmission, was developed to improve the reliability of terminal to MTS and computer to MTS connections.[23]

A very wide range of terminals are supported including the 10 character per second (cps) Teletype Model 33, the 30 cps LA-36 and 120 cps LA-120 DECWriter, the 14 cps IBM 2741, and at ever increasing speeds up to 56,000 bits per second, the VT100 display, the Visual 550 display, the Ontel OP-1 and OP-1/R displays, Tektronix 4000 series of graphic displays, and personal computers from Apple (AMIE for the Apple ][), IBM (PCTie for DOS), and others running terminal emulation programs, including some specifically developed for use with MTS. Most terminals that are compatible with any of these models are also supported.

MTS also supports access from 10- or 12-button touch-tone telephones via the IBM 7772 Audio Response Unit[24][25] and later the Votrax Audio Response Unit,[26][27] IBM 1052 consoles, IBM 3066 console displays, and IBM 3270 family of locally attached displays (IBM 3272 and 3274 control units, but not remote 3270 displays).

MTS can and does use communication controllers such as the IBM 2703 and the Memorex 1270 to support dial-in terminals and remote batch stations over dial-in and dedicated data circuits, but these controllers proved to be fairly inflexible and unsatisfactory for connecting large numbers of diverse terminals and later personal computers running terminal emulation software at ever higher data rates. Most MTS sites choose to build their own front-end processors or to use a front-end processor developed by one of the other MTS sites to provide terminal support.

These front-end processors, usually DEC PDP-8, PDP-11, or LSI-11 based with locally developed custom hardware and software, would act as IBM control units attached to the IBM input/output channels on one side and to modems and phone lines on the other. At the University of Michigan the front-end processor was known as the Data Concentrator (DC).[28] The DC was developed as part of the CONCOMP project by Dave Mills and others and was the first non-IBM device developed for attachment to an IBM I/O Channel.[29] Initially a PDP-8 based system, the DC was upgraded to use PDP-11 hardware and a Remote Data Concentrator (RDC) was developed that used LSI-11 hardware that connected back to a DC over a synchronous data circuit. The University of British Columbia (UBC) developed two PDP-11 based systems: the Host Interface Machine (HIM) and the Network Interface Machine (NIM). The University of Alberta used a PDP-11 based Front-end processor.

These front-end systems support their own command language of "device commands", usually lines prefixed with a special character such as a percent-sign (%), to allow the user to configure and control the connections.[30] The $CONTROL command and programs running on MTS can use the CONTROL subroutine to issue device commands to front-end and network control units.

Over time some front-ends evolved to provide true network support rather than just providing support for connections to MTS.

At the University of Michigan (UM) and Wayne State University (WSU) there was a parallel development effort by the Merit Network to develop network support. The Merit nodes were PDP-11 based and used custom hardware and software to provide host to host interactive connections between MTS systems and between MTS and the CDC SCOPE/HUSTLER system at Michigan State University (MSU). The Merit nodes were known as Communication Computers (CCs) and acted as IBM Control Units on the one side while providing links to other CCs on the other side. The initial host to host interactive connections were supplemented a bit later by terminal to host (TL) connections, and later still by host to host batch connections which allowed remote jobs submitted from one system to be executed (EX) on another with printed (PR) and punched card output (PU) returned to the submitting system or to another host on the network. The remote batch jobs could be submitted from a real card reader or via *BATCH* using a #NET "card" at the front of the job.

Merit renamed its Communication Computers to be Primary Communication Processors (PCPs) and created LSI-11 based Secondary Communication Processors (SCPs). PCPs formed the core of the network and were attached to each other over Ethernet and dedicated synchronous data circuits. SCPs were attached to PCPs over synchronous data circuits. PCPs and SCPs would eventually include Ethernet interfaces and support local area network (LAN) attachments. PCPs would also serve as gateways to commercial networks such as GTE's Telenet (later SprintNet), Tymnet, and ADP's Autonet, providing national and international network access to MTS. Later still the PCPs provided gateway services to the TCP/IP networks that became today's Internet.

The Merit PCPs and SCPs eventually replaced the Data Concentrators and Remote Data Concentrators at the University of Michigan. At their peak there were more than 300 Merit PCPs and SCPs installed, supporting more than 10,000 terminal ports.

UMMPS provides facilities that allow the creation of virtual environments, either virtual machines or virtual operating systems. Both are implemented as user programs that run under MTS.

The initial work on the first MTS virtual machine was done at the University of Michigan to simulate the IBM S/360-67 and allow debugging of UMMPS and MTS. Later the University of British Columbia did the initial work to create a S/370 MTS virtual machine. In theory these virtual machines could be used to run any S/360 or S/370 system, but in practice the virtual machines were only used to debug MTS and so there may be subtle features that are not used by MTS that are not completely or correctly implemented. The MTS virtual machine was never updated to support the S/370-XA architecture (instead other tools such as SWAT and PEEK were used to debug MTS and IBM's VM/XA or VM/ESA were used to debug UMMPS).

In the early 1970s work was done at Wayne State University to run a version of OS/MVT in a modified virtual machine (VOS) under MTS as a production service.[31]

"Student" virtual machines in MTS have also been created as teaching tools. Here the OS running in the virtual machine (written by the student) uses simulated devices and has no connection to the "real" outside world at all (except possibly a console).

In addition to virtual machines, MTS provides two programs that implement virtual operating system environments.[32] *FAKEOS, developed at the University of Michigan, allows programs from OS/360 to run as user programs in MTS. *VSS, developed at the University of British Columbia, allows programs from OS/VS1 and MVS/370 to run as user programs in MTS.[33] Neither program actually runs the IBM operating system, instead they simulate enough of the operating environment to allow individual programs developed for those operating systems to run. Both programs can be run directly, but often they are run from driver files that give an end user the impression that they are running a regular MTS user program.

At least three different implementations of e-mail were available under MTS at different times:

• *MAIL from NUMAC, but not available at all MTS sites;
• CONFER, the computer conferencing system written by Robert Parnes at UM; and
• $MESSAGESYSTEM from the University of Michigan Computing Center.[4][34]

CONFER and *MAIL only sent and received mail to and from "local" users.

Available to users in July 1981,[35] $MESSAGESYSTEM is the last of the three systems to be implemented and became the most widely used. Between 1981 and 1993 it was used to send and receive more than 18 million messages at the University of Michigan.[36] It can send:

• local and network e-mail messages,
• dispatches (immediate messages displayed at another user's terminal unless dispatches were blocked by the other user),
• bulletins (messages sent by the system operator to particular users delivered automatically at the beginning of an MTS session), and
• signon messages (messages sent by the system operator to all users delivered automatically before the start of an MTS session).

Some notable features of $MESSAGESYSTEM include the ability:

• to send to individuals by signon ID or name, to groups of individuals by signon ID, project ID, or group name, or to the system operator;
• to send to a list stored in a file;
• to use the program *USERDIRECTORY to create and maintain a database of e-mail names for individuals and for groups including names and groups that include remote or network users;
• to recall/delete messages that hadn't already been read;
• to add or remove recipients to messages after they had been sent;
• to display a history of messages in an e-mail chain without the need to include the text from older messages in each new message;
• to set expiration and hold until dates and times for e-mail messages;
• to display the status of incoming and outgoing messages;
• to retrieve incoming and outgoing messages using a database model (incoming, outgoing, new, old/seen, to recipients, from recipients, message number, date sent, expiration date, ...);
• to permit a mailbox allowing uses by signon IDs other than the mailbox owner's;
• to automatically forward messages from one mailbox to another;
• to archive older messages, and
• send and receive messages using a subroutine interface in addition to commands.

An application for the Apple Macintosh, InfoX (aka MacHost), was developed to provide a modern interface to the MTS Message System and *USERDIRECTORY.

In 1984 MTS could be used to send and receive remote e-mail to and from over 300 sites around the world.[4]

The first ability to send and receive e-mail messages to and from users on remote systems (remote messages or network mail) was implemented in 1982[35] as part of the MAILNET project, a joint effort of 16 universities and EDUCOM (later EDUCAUSE) supported with funding from the Carnegie Corporation. MIT served as a relay hub between the MAILNET sites and as a gateway to CSNET, ARPANET, and BITNET. MTS at the University of Michigan used its connections to the Merit Network and through Merit to GTE's commercial X.25 network, Telenet (later SprintNet), to communicate with MIT. MTS at the University of Michigan served as a relay site for other sites on the UM campus and for other MTS sites that did not have direct access to the MAILNET relay at MIT.

The remote e-mail addresses for an MTS user at the University of Michigan were:

• name@UMich-MTS.Mailnet (from MAILNET and BITNET sites)
• name%UMich-MTS.Mailnet@MIT-MULTICS.ARPA (from CSNET and ARPANET sites)
• name@UM (from other UM or MTS sites)

To send e-mail to a remote site, MTS users at the University of Michigan used addresses of the form:

• name@CARNEGIE (to Carnegie-Mellon University a MAILNET site)
• name@CARNEGIE.MAILNET (the more official, but longer name for CMU)
• name@WSU (to Wayne State University an MTS site)
• name@Wayne-MTS.Mailnet (the more official but longer name for WSU)
• name%brown@CSNET-RELAY.ARPA (to Brown University a CSNET Phonenet site)
• name@cornell.ARPA (to Cornell University a CSNET or ARPANET site)
• name@STANFORD.BITNET (to Stanford University a BITNET site)

Over time as more and more computers had direct connections to the Internet the MAILNET relay approach was replaced with the more direct and more reliable peer to peer e-mail delivery and Internet domain style of e-mail addresses in use today (name@um.cc.umich.edu).

Screenshot of the InfoDisk about window, September 1988

InfoX (pronounced "info-ex", originally InfoDisk) is a program for the Apple Macintosh developed by the Information Technology Division at the University of Michigan.[34] It provides a modern user interface (menus, icons, windows, and buttons) that can be used to check MTS electronic mail, participate in CONFER II conferences, access the MTS User Directory, and create, edit, and manipulate files. InfoX adds Macintosh-style word processing features to the more traditional editing functions available from the MTS, $Message, $Edit, and CONFER command-line interfaces. One can use the standard Cut, Copy, and Paste commands under the Macintosh Edit menu to move text from any Macintosh file.

Each signon ID is allocated resource limits (money, disk space, connect time, ...) which control the amount and types of work that can be done by the ID.[4] IDs can be limited to using just terminal sessions or just batch jobs or restricted to working during times of the day or days of the week when the rates charged are lower. Each signon ID is assigned an expiration date.

Resources that can be charged for include:

• CPU time—charged in seconds of CPU time
• Memory usage—charged as CPU-VM integral ... e.g. 40 pages of virtual memory used for 10 seconds is charged as 400 page-seconds
• Printer usage—charged as pages of paper and lines of output (for line printers) or pages and sheets (for page printers)
• Disk space used—charged in page-months (one page=4096 bytes)
• Terminal or network connect time-charged in minutes
• Cards read and punched-charged by the card
• Paper tape punched-charged by the foot
• Tapes mounted and tape drive usage time-charged by number of tapes mounted and minutes of usage
• Program product surcharges (charged on a program by program basis for certain licensed program products)
• Other resources (e.g. plotters, photo-typesetters, etc.)

Note that while there is a charge for virtual memory used, there is no charge for real memory used. Note too that there is no change for page-in operations, although they are included in the session summary information that is reported at sign off.

Different rates can be changed for different classes of projects (internal, external, commercial, ...) and for different times of the day or days of the week. Depending on the policies and practices at different sites, charges can be for "real money" or "soft money" (soft money is sometimes called "funny money", although just how funny it is usually depends on who is or isn't paying the bills).

Users can display the cost of a session using the $DISPLAY COST command, can display their account balances using the $ACCOUNTING command, and the costs of a session and the account's remaining balance are displayed when the job or session ends. There is also an option ($SET COST=ON) that will cause the incremental and cumulative session cost to be displayed after each MTS command is executed.

To prevent a user from overdrawing their account, the money limit is checked when the user attempts to sign on. If the account balance is zero or negative, the sign on is not allowed. For batch jobs, if the account balance is not sufficient to cover the charges estimated for the job, the job is not run. For terminal sessions, when an account's balance falls below one dollar, a warning "You have run out of money" followed by the current balance is printed. This "out of money" message is repeated at regular intervals until the user signs off. Signon IDs can run a negative balance, but usually not a large one or by accident. Depending on the administrative policies at a particular site, projects often have to pay for resources used even if they are beyond the amount authorized.

To provide additional protection against accidents that might quickly use more resources than desired, users may also set global and local limits on CPU time usage. Global time limits ($SIGNON ccid T=maxtime) apply to an entire job or session. Local time limits apply to running individual programs ($RUN program T=maxtime). Global and local limits on the number of pages to be printed and the number of cards to be punched can also be set ($SIGNON ccid P=maxpages C=maxcards and $RUN program P=maxpages C=maxcards). A default local CPU time limit can be established using the $SET TIME=maxtime command.