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 ArchitectureMTS Lecture 1, a transcription of the first in a series of lectures on the internals of the Michigan Terminal System given by Mike Alexander, Don Boettner, Jim Hamilton, and Doug Smith, c. 1972 StateMode"The Protection of Information in a General Purpose Time-Sharing Environment", Gary C. Pirkola and John Sanguinetti, Proceedings of the IEEE Symposium on Trends and Applications 1977: Computer Security and Integrity, vol. 10 no. 4, pp. 106–114VMInterruptsUser programsproblemuseralign="center" rowspan=2 align="center" rowspan=3 Command Language Subsystems (CLSs),Device Support Routines (DSRs),System SubroutinessystemJob programs (MTS, PDP, DMGR, RM or HASP, ...)align="center" Supervisor (UMMPS)supervisoralign="center" align="center" align="center" 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."Organization and features of the Michigan Terminal System", M. T. Alexander, p. 586, Proceedings of the May 1972 AFIPS Spring Joint Computer Conference One of the job programs is MTS, the job program with which most users interact.MTS Volume 1: The Michigan Terminal System, pages 9,13–14, Nov. 1991, University of Michigan Computing Center, Ann Arbor, Michigan 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.MTS Volume 3: System Subroutine Descriptions, University of Michigan Computing Center, Ann Arbor, MichiganMichigan Terminal System (MTS) subseries, Computing Center publications, 1965–1999, Bentley Historical Library, University of Michigan 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.MTS Volume 1: Systems Edition, Obsolete and Internal MTS Commands, November 1991, University of Michigan, 60pp. $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."Time Sharing Supervisor Programs", notes comparing the supervisor programs of CP-67, TSS/360, MTS, and Multics by Michael T. Alexander, Advanced Topics in Systems Programming (1970, revised 1971), University of Michigan Engineering Summer Conference 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)UMMPS D6.0 Supervisor Call Descriptions, November 1987, University of Michigan, 156p. 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.MTS Volume 14: 360/370 Assemblers in MTS, University of Michigan Computing Center, Ann Arbor, Michigan 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 Mask1 is always zero, Mask2 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 Mask2 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.

{| class="wikitable" |+ BPI interrupt-type categories !Mask2Name !Mask2Value !InterruptNumber !InterruptName !Condition Codeon Branch

|- align="center" |OPCD |8 |1 |Operation |1 |- align="center"

|2 |Privileged operation |2 |- align="center"

|3 |Execute |3

|- align="center" |OPND |4 |4 |Protection |0