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