MTS system architecture

For broader coverage of this topic, see Michigan Terminal System.

MTS System Architecture describes the software organization of the Michigan Terminal System, a time-sharing computer operating system in use from 1967 to 1999 on IBM S/360-67, IBM System/370, and compatible computers.

Overview

MTS Architecture

	State	Mode	VM	Interrupts
User programs	problem	user	on	on
Command Language Subsystems (CLSs), Device Support Routines (DSRs), System Subroutines		system
Job programs (MTS, PDP, DMGR, RM or HASP, ...)			on or off
Supervisor (UMMPS)	supervisor	n/a	off	off
S/360-67 or S/370 hardware

The University of Michigan Multi-Programming Supervisor (UMMPS), has complete control of the hardware and manages a collection of job programs. One of the job programs is MTS, the job program with which most users interact. 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. Among other things these system subroutines provide standard access to Device Support Routines (DSRs), the components that perform device dependent input/output.

Organization

The system is organized as a set of independent components with well-defined interfaces between them. 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).

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.

Programming languages and system level debugging

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. $PEEK is a privileged MTS command that uses Program Event Recording (PER) and other facilities to facilitate debugging one job program from another. Components that cannot be debugged in this way can be debugged by running in an MTS virtual machine (a user program).

Supervisor

University of Michigan Multi-Programming Supervisor (UMMPS) is the name of the MTS supervisor. 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) 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,
  • 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) 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).

Branch on Program Interrupt (BPI)

The Branch on Program Interrupt (BPI) pseudo instruction provides a simple way for a sequence of code to retain control following a program interrupt. This can be useful to test for valid addresses in a parameter list, to catch overflow, underflow, and other exceptions during calculations, or really any situation where a program interrupt is possible. BPIs can be used at very low cost for the usually more common case where there is no program interrupt.

UMMPS implements the Branch on Program Interrupt (BPI) pseudo instruction using a special type of NOP instruction. The form of the BPI instruction is:

  BPI    M2,D2(B2)        [RX]

or

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

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

Where Mask₁ is always zero, Mask₂ is a name or value as described in the table below, and the base and displacement specify a branch address. Several BPI instructions may be given in succession. The BPI instruction is available for use in problem-state as well as supervisor-state (that is, within UMMPS itself).

When an instruction causes a program interrupt, the following instruction is checked to determine if it is a BPI instruction. If it is, the type of program interrupt that occurred is compared with the type categories specified in the Mask₂ portion of the BPI instruction. If there is a match, the condition code is set to reflect the interrupt that occurred and the branch is taken. Otherwise, the next instruction is checked to determine if it is a BPI instruction, etc. If there is no BPI transfer made (either because there was no BPI instruction or because the program interrupt type did not match the mask of any BPIs that were present), the normal processing of the program interrupt occurs.

When the BPI instruction is executed normally (when there is no program interrupt on the previous instruction), it is a NOP or "branch never" instruction.

BPI interrupt-type categories:

Mask2 Name	Mask2 Value	Interrupt Number	Interrupt Name	Condition Code on Branch
OPCD	8	1	Operation	1
		2	Privileged operation	2
		3	Execute	3
OPND	4	4	Protection	0
		5	Addressing	1
		6	Specification	2
		7	Data	3
OVDIV	2	8	Fixed overflow	0
		9	Fixed divide	1
		10	Decimal overflow	2
		11	Decimal divide	3
FP	1	12	Exponent overflow	0
		13	Exponent underflow	1
		14	Significance	2
		15	Floating-point divide	3

Job programs

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.

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

24-, 31-, and 32-bit addressing

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.

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.

Protection

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.

Virtual memory and paging

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.

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. 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)
• Segments 6 to 12: private virtual memory (user segments, read-write to any program)

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.

Signon and project IDs

Everybody who uses MTS is assigned a signon ID (also called userids or Computing Center IDs, CCIDs). 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, 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.

Terminal, batch, and server sessions

MTS supports terminal, batch, and server sessions. 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).

Command language

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

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

List of MTS commands

Global control

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)

File management

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 ]

File and device management

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)
NUMBER  (old fashioned and obsolete way to enter data into a file)

User program execution and control

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)

Miscellaneous

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

File-name patterns

Several MTS commands that use file names or lists of file names allow the use of file-name patterns: COPY, DESTROY, DUPLICATE, EMPTY, EDIT, FILESTATUS, FILEMENU, LIST, LOCKSTATUS, PERMIT, RENAME, RENUMBER, and TRUNCATE. A question-mark (?) is the pattern match character. A single question-mark used in a file-name will match zero or more characters. "?" matches all files for the current signon ID, "?.S" matches all files that end with ".S", "A?B" matches all files that begin with "A" and end with "B", "A?B?C" matches all files that start with "A", end with "C", and contain a "B". Two or more consecutive question-marks match "n-1" characters. "???.S" matches all four character file-names that end with ".S", and "????" matches all three character file-names. "W163:?" matches all files under the signon ID "W163" to which the current user has some access.

Command Macros

The MTS command macro processor allows users to define their own MTS commands. It provides a "scripting" language with conditional commands and is available for use with any lines read from *SOURCE* by user programs or command language sub-systems as well with MTS commands. Macro processor lines are usually prefixed with the greater than character (>). The command macro processor is controlled using the $SET command as well as by I/O modifiers on FDnames.

Prefix Characters

To help users keep track of what command, command subsystem, or program they are working with and when input is expected, MTS displays a prefix character or sometimes a prefix string at the front of each input and output line it writes to the user's terminal. The common prefixes are:

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

Command language subsystems

The MTS job program is always executing one of several command language subsystems or CLSs. Many of the MTS commands are built into MTS and execute as part of the MTS CLS. User programs execute as the USER CLS. The USER CLS has a special relationship to the Symbolic Debugging System (SDS CLS) when the debugger is active. Other MTS commands are implemented as separate modules, confusingly also named command language subsystems or CLSs, that may be executed from shared virtual memory or may be loaded from files.

These separate CLSs each have their own four character name and they execute as a separate CLS in the original sense of the term. Many, but not all, of these CLSs provide their own separate sub-command language. There are $SET command options to cause old or new versions of CLSs rather than the current versions to be used. There is an option on the $UNLOAD command to unload a CLS (free the virtual memory it is using, close any FDnames and release any devices or pseudo devices that it has open).

Only one CLS is executing at a time, but one CLS of each type may be active and it is possible to switch from one CLS to another without exiting or unloading the original CLS and then to later return to the original CLS and continue working from where one left off. CLSs that have their own sub-commands usually support a STOP command to exit from the CLS, an MTS and/or a RETURN command to return to the calling CLS or MTS command mode, and commands that begin with a dollar-sign ($) are executed as MTS commands with an immediate return to the original CLS.

All CLSs except for the USER CLS execute in system mode in problem state.

Limited-service state

MTS sessions normally operate in "full-service state", but during times of extreme system overload terminal sessions may be placed into "limited-service state" (LSS). The LSS mechanism is manually enabled by the system operator and is normally only used when the hardware system is operating at reduced capacity due to a malfunction.

A terminal session is placed into LSS if LSS has been enabled by the system operator and the system is overloaded at signon. LSS sessions may only issue MTS commands and run programs with a short local time limit. Rather than giving all users poor performance, LSS limits the size of the tasks that some users may perform to relatively small tasks such as editing of files and reading of messages in order to allow other users to receive reasonable performance on larger tasks. Users may request that their session be changed to full-service state ($SET LSS=OFF) and such requests are granted if the system is not overloaded at the time the request is made.

Command statistics

Each MTS command that is issued is recorded, first to a disk file and later to magnetic tape. This information is only available to staff and is used to investigate software problems, security problems, rebate requests, and to provide statistics about how the command language is used.

User programs

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.

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

By default user programs execute in user mode in problem state. 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.

Device independent input/output

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.

File or device names

Input/output is done directly by referencing a file or device by its name (FDname) or indirectly by referencing a logical I/O unit (SCARDS or INPUT, SPRINT or PRINT, SPUNCH or OBJECT, GUSER, SERCOM, 0 to 99). FDnames are assigned to logical I/O units using keywords in the command language or by default.

FDnames can be a simple file name such as MYFILE, a simple device name prefixed with a greater than sign such as >T901, or a pseudo-device name such as *PRINT*. All FDnames are converted to uppercase before they are used, so like MTS commands, FDnames are case independent.

I/O modifiers, line number ranges, and explicit concatenation can be used to create complex FDnames from simple FDnames. For example:

 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)

Pseudo device names

Pseudo device names (PDNs) begin and end with an asterisk (e.g., *name*). Common pseudo devices include:

• *SOURCE* standard input (normally either a terminal or for batch jobs, the input queue);
• *SINK* standard output (normally a terminal or for batch jobs, a printer);
• *MSOURCE* master source, not re-assignable, usually a terminal or a card reader;
• *MSINK* master sink, not re-assignable, usually a terminal or a printer;
• *BATCH* spooled input to a new batch job;
• *PRINT* spooled output to a printer, same as *MSINK* for batch jobs;
• *PUNCH* spooled output to a card punch (until card punches were retired); and
• *DUMMY* all data written is discarded and all reads return an End-of-File (much like /dev/null for UNIX); and
• *AFD* the active file or device as established using the $GET command.

The $SOURCE and $SINK commands may be used to reassign the FDnames assigned to *SOURCE* and *SINK*. The $MOUNT command assigns pseudo device names (e.g. *T22*, *NET*) to devices such as magnetic and paper tapes and network connections (including server connections). The $CREATE command can be used to create pseudo device names for use with BITNET import and export, for spooled print jobs, and for dummy devices.

I/O modifiers

I/O modifiers, possibly negated, may be associated with an FDname to modify default behaviors.

An I/O modifier is specified by appending an at-sign followed by the modifier's name to an FDname. For example, *SOURCE*@UC would cause lines read from *SOURCE* to be converted to uppercase before they are presented to a program and MYFILE@UC@-TRIM would cause lines read from the file MYFILE to be converted to uppercase and any trailing spaces at the end of the line would be retained. Some commonly used I/O modifiers are: @S (sequential), @I (indexed), @FWD (forward), @BKWD (backward), @EBCD (EBCDIC), @BIN (binary), @UC (uppercase), @CC (logical carriage control), @MCC (machine carriage control), @NOCC (no carriage control), @TRIM (trim all but last training blank). Some I/O modifiers are processed in a device independent fashion by MTS and others are device dependent and processed by the Device Support Routines (DSRs).

Not all files or devices support all I/O modifiers. Different files and devices have different default I/O modifiers and a few I/O modifier defaults can be changed using the $SET command.

Line number ranges

Specific parts of a file or device can be referenced by including starting and ending line numbers and possibly a line number increment in parentheses separated by commas. The line numbers and increment are integers scaled by 1000 and can be positive or negative (±nnnnn.nnn). For example, SIMPLE.F(-35,197.5) would open the file SIMPLE.F, starting at the first line number greater or equal to -35 and return an 'end of file' instead of the first line number greater than 197.5. One can also include line number increments—as an example: SIMPLE.F(2,200,2) would return all (and only) even line numbers between 2 and 200 (inclusive).

The symbolic line numbers FIRST or *F, LAST or *L, MIN, and MAX may refer to the first, last, minimum possible, and maximum possible lines, respectively. For example, SIMPLE.F(*F,0) would refer to the 'negative' lines of the file SIMPLE.F. This is where programmers might place self-documentation for a (often binary) file, actual data in the file would start at line number 1.

One can also do simple addition and subtraction with the symbolic line numbers: FIRST±m, *F±m, LAST±m, *L±m, MIN+m, MAX-m, where m is an integer with or without a decimal point scaled by 1000 (±nnnnn.nnn). So to add new lines to the end of an existing file one could use an FDname of the form SIMPLE.F(LAST+1).

File or device concatenation

Explicit concatenation allows FDnames to be connected using a plus-sign, as NAMEA+NAMEB. In this case MTS transparently returns the contents of NAMEA followed by the contents of NAMEB or writes to NAMEB after writing to NAMEA reaches an end of file or other error condition.

Implicit concatenation occurs when an input line contains the string:

$CONTINUE WITH FDname 

MTS will continue with the FDname given as the new source of data. Or, if a line of the form:

$CONTINUE WITH FDname RETURN

is read, MTS will return the contents of the new FDname until and End-of-File is reached and then return the next line of the original FDname (note that, a file that continues with itself causes an infinite loop, usually a mistake, but sometimes used to good effect).

While the line starts with a dollar-sign, $CONTINUE WITH is not an MTS command, but rather a delimiter.

The @IC I/O modifier and the command $SET IC={ON | OFF} can be used to control implicit concatenation.

$ENDFILE lines

If a line contains the string $ENDFILE, MTS returns a 'soft' end of file.

While the line starts with a dollar-sign, $ENDFILE is not an MTS command, but rather a delimiter.

The @ENDFILE I/O modifier and the command $SET ENDFILE={ALWAYS | SOURCE | NEVER} can be used to control $ENDFILE processing.

$9700 and $9700CONTROL lines

Lines that begin with the strings "$9700" or "$9700CONTROL" may be copied or written to *PRINT* to control print options on the Xerox 9700 page printer. $9700 lines take effect at the point where they occur, while $9700CONTROL lines apply to the entire print job in which they occur. While these lines have a form similar to MTS commands, they are really device commands and not true MTS commands.

Files

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

File types

MTS supports three types of file, line files, sequential files, and sequential with line number files, but line files were by far the most common:

Line files

Line files ($CREATE name or $CREATE name TYPE=LINE) are line-oriented files which are indexed (and randomly accessible) by line number. Allowed line numbers are ±2147483.647—essentially a signed integer value divided by 1000, but command line references were limited to ±99999.999. Regular writes to a file increase the line number by 1. Lines are variable length, and a line can be rewritten to any length between 1 and the line length limit (originally 256, but later changed to 32767) without affecting the surrounding lines. Rewriting a pre-existing line to a length of zero deletes that line without affecting surrounding lines.

By default the first line number written to an empty file is 1, and is incremented by 1 with each subsequent write. By default, reading a file starts with the first line number at or above 1 and continues by reading each line in order of increasing line numbers. This means that negative line numbers are 'invisible' parts of a file, which require specific references to read.

There are commands (and system subroutines) to renumber lines. A contiguous set of lines can be renumbered to any combination of start and increment as long as lines of the file are not re-ordered. For example, if a file consists of lines 10, 20, 30, 40 and 50, lines 30–40 can be renumbered as 35,36, but not as 135,136, as that would change the sequence of lines.

The line index and data are stored on separate disk pages except for the smallest (one page) files, where the line index and data are stored together.

The $CREATE command creates line files by default.

A side effect of the line-based file system is that programs can read and write individual lines incrementally. If one edits a file (usually a text file) with the MTS file editor ($EDIT), any changes made to lines are written immediately, as are insertions and deletions of specific lines. This makes it quite different from most (byte-oriented) file systems where a file is usually read into and changed in memory, and then saved to disk in bulk.

Due to hardware or software problems, line files can become corrupt. The program *VALIDATEFILE checks the structure of line files.

Sequential files

Sequential files ($CREATE name TYPE=SEQ) are line-oriented files with the first line number being implicitly 1 and incremented by 1 for each line. Once written the length of a line (other than the last line of a file) can not be changed, although any line can be replaced by a line of the same length. Sequential files are generally only readable sequentially from start to end, or written by appending to the end. One can, however, request a reference for the current line of a sequential file, and use that reference to jump to that specific location again.

Sequential files are somewhat more efficient in terms of space than line files and can be more efficient in terms of CPU time too when compared with large disorganized line files. But the main reason for the existence of SEQ files is that they supported long lines (up to 32,767 characters) before line files did. Sequential files were less common once line files could support long lines. Sequential files are also used to force new lines to be appended to the end of the file without the need to give the line number range (LAST+1).

Sequential with line number files

Sequential With Line Number files ($CREATE name TYPE=SEQWL) are similar to Sequential Files, except that their line numbers were explicitly stored. They have all the restrictions of Sequential Files, except that the line number could be specifically supplied when writing to a file (as long as it is greater than the last line number written to the file). Unlike Line Files, the first read of an SEQWL file returns the first line of the file, even if it was negative.

SEQWL files were rarely used, and were not officially supported or were removed from the documentation by some MTS sites. Because line files did not work well with the Data Cell, SEQWL files were implemented as a way to allow the Data Cell to be used for longer term less expensive storage of files while still preserving line numbers.

Shared files

Over time the sharing of files between MTS users evolved in four stages.

Stage one allowed for limited file sharing, where public or library files (files whose names start with an asterisk) were readable by all users and all other files (user files) could only be accessed by their owners. Public files were owned and maintained by Computing Center staff members, so at this stage only Computing Center files were shared.

Stage two allowed for limited file sharing, where the program *PERMIT could be used to (i) make a file read-only (RO) to the file's owner and all other MTS users, (ii) make a file available for copying by members of the same project as the file's owner using the program *COPY, or (iii) make a file available for copying by all other users using the program *COPY. As for stage one, by default owners had unlimited access to their own files and the files were not accessible to other users.

Stage three allowed for "really shared files", where the $PERMIT command or the PERMIT subroutine can be used to share a file in a variety of ways with lists of other users, projects, all other users, or a combination of these. The types of access that can be allowed are read, write-extend, write-change or empty, renumber or truncate, destroy, and permit. As for stages one and two, by default a user file is permitted with unlimited access for its owner and no access for others. A file's owner's access can also be changed, although an owner always retains permit access. The $FILESTATUS command or FILEINFO and GFINFO subroutines can be used to obtain a file's permit status.

Stage four added program keys (PKeys) to the list of things to which a file can be permitted. Thus files can be permitted to users, projects, all other users, program keys, or a combination of these. Program keys were associated with MTS commands and files, which allowed files to be permitted to specific programs or to specific MTS commands. Among other things this allowed the creation of execute-only or run-only programs in MTS.

Files can also be permitted to the initial sub-string of a userID, projectID, or program key. As a result, it may happen that a single userID, projectID, and program key may potentially have more than one type of access. In such cases, the actual access is resolved according to the following rules: (i) userIDs, alone or in combination with program keys, take precedence over projectIDs and program keys, ii) projectIDs, alone or in combination with program keys, take precedence over program keys, (iii) longer sub-string matches take precedence over shorter sub-string matches, and (iv) if there is no specific userID, projectID, or program key match then the access specified for "others" is used.

The PKEY subroutine can be used to shorten the program key of the currently running program or switch the program key of the currently running program to *EXEC and later restore the program key, allowing a program to voluntarily limit the access it has to files by virtue of its program key.

File locking

As part of "really shared files" (stage three above), file locking was introduced to control simultaneous access to shared files between active MTS sessions (that is, between separate running tasks or processes). File locking does not limit or block access to files within a single MTS session (between command language subsystems or user programs running as part of the same MTS session). File locking in MTS is mandatory rather than advisory. Files are locked implicitly on first use of a particular type of access or explicitly using the $LOCK command or the LOCK subroutine. Files are unlocked implicitly when the last use of a file within a task is closed or explicitly using the $UNLOCK command or the UNLK subroutine. The $LOCKSTATUS command or LSFILE and LSTASK subroutines can be used to obtain a file's or a task's current lock status.

A file may be "open", "not open", or "waiting for open" and "not locked", "locked for read", "locked for modify", "locked for destroy", "waiting for read", "waiting for modify", or "waiting for destroy". A file's open status is independent of its lock status. Locking a file for modification also locks the file for reading and locking a file for destroying also locks the file for modification and reading. Any number of tasks can have a file locked for reading at any given time, but only one task can have a file locked for modification at any given time and then only if no task has the file locked for reading, or locked for destroying. Only one task can have a file locked for destroying at any given time, and then only if no task has the file open, locked for reading, or locked for modification.

When an attempt to lock a file cannot be satisfied, the calling task will wait either indefinitely or for a specific period for another task to unlock the file, or until an attention interrupt is received. If the file cannot be locked, an error indicating this is returned. The file locking software detects deadlocks between tasks using Warshall's algorithm and returns an error indication without locking the file and without waiting.

Locking a file is in effect locking the name of that file. For example, the following sequence of commands can be executed while leaving FILE1 locked even though a file with the name FILE1 does not always exist:

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

At a later date this capability to lock names allowed the "file" locking routines to be used to implement record level locking between tasks accessing the centrally managed file *MESSAGES that was used by the MTS $Messagesystem to hold mailboxes and messages for individual users.

The addition of file locking allowed removal of the restriction that a single userID could only be signed on once. Instead, the number of simultaneous sign ons was controlled by a maximum that could be set in the user's accounting record by the project manager or a site's business office.

File save and restore

Files are regularly backed up to tape unless they have been marked as NOSAVE. The file save process includes full and partial backups. Full saves are typically done once a week with no users signed on to the system. Partial saves save just the files that have changed since the last full or partial save and are typically done once each day in the late evening or early morning during normal operation with users signed on to the system.

At the University of Michigan two copies of the full save tapes were made and one copy was stored "off-site". Save tapes were kept for six weeks and then reused. The tapes from every sixth full save were kept "forever".

Files are saved to allow recovery from "disk disasters" in which the file system becomes damaged or corrupt, usually due to a hardware failure. But users could restore individual files as well using the program *RESTORE.

Terminal support

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.

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.

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 and later the Votrax Audio Response Unit, 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).

Front-end communication processors

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). 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. 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. The $CONTROL command and programs running on MTS can use the CONTROL subroutine to issue device commands to front-end and network control units.

Network support

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.

Virtual environments

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.

"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. *FAKEOS, developed at the University of Alberta, 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. 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.

Electronic mail

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.

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

Available to users in July 1981, $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. 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.

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

InfoX

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

Accounting and charging

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