Hubbry Logo
Michigan Terminal SystemMichigan Terminal SystemMain
Open search
Michigan Terminal System
Community hub
Michigan Terminal System
logo
8 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Michigan Terminal System
Michigan Terminal System
Michigan Terminal System
View on Wikipedia
from Wikipedia
Michigan Terminal System (MTS)
The MTS welcome screen as seen through a 3270 terminal emulator.
DeveloperUniversity of Michigan and 7 other universities in the US, Canada, and the UK
Written invarious languages, mostly 360/370 Assembly language
Working stateHistoric
Initial release1967; 59 years ago (1967)
Latest release6.0 (final) / 1988; 38 years ago (1988)
Available inEnglish
Supported platformsIBM S/360-67, IBM S/370 and successors
Default
user interface		Command-line interface
LicenseFree (CC BY 3.0)
Preceded byUniversity of Michigan Executive System
Official websitearchive.org

The Michigan Terminal System (MTS) is one of the first time-sharing computer operating systems.[1] Created in 1967 at the University of Michigan for use on IBM S/360-67, S/370 and compatible mainframe computers, it was developed and used by a consortium of eight universities in the United States, Canada, and the United Kingdom over a period of 33 years (1967 to 1999).[2]

Overview

[edit]

The University of Michigan Multiprogramming Supervisor (UMMPS) was initially developed by the staff of the academic computing center at the University of Michigan for operation of the IBM S/360-67, S/370 and compatible computers. The software may be described as a multiprogramming, multiprocessing, virtual memory, time-sharing supervisor that runs multiple resident, reentrant programs. Among these programs is the Michigan Terminal System (MTS) for command interpretation, execution control, file management, and accounting. End-users interact with the computing resources through MTS using terminal, batch, and server oriented facilities.[2]

The name MTS refers to:

  • The UMMPS Job Program with which most end-users interact;
  • The software system, including UMMPS, the MTS and other Job Programs, Command Language Subsystems (CLSs), public files (programs), and documentation; and
  • The time-sharing service offered at a particular site, including the MTS software system, the hardware used to run MTS, the staff that supported MTS and assisted end-users, and the associated administrative policies and procedures.

MTS was used on a production basis at about 13 sites in the United States, Canada, the United Kingdom, Brazil, and possibly in Yugoslavia and at several more sites on a trial or benchmarking basis. MTS was developed and maintained by a core group of eight universities included in the MTS Consortium.

The University of Michigan announced in 1988 that "Reliable MTS service will be provided as long as there are users requiring it ... MTS may be phased out after alternatives are able to meet users' computing requirements".[3] It ceased operating MTS for end-users on June 30, 1996.[4] By that time, most services had moved to client/server-based computing systems, typically Unix for servers and various Mac, PC, and Unix flavors for clients. The University of Michigan shut down its MTS system for the last time on May 30, 1997.[5]

Rensselaer Polytechnic Institute (RPI) is believed to be the last site to use MTS in a production environment. RPI retired MTS in June 1999.[6]

Today, MTS still runs using IBM S/370 emulators such as Hercules, Sim390,[7] and FLEX-ES.[8]

Origins

[edit]

In the mid-1960s, the University of Michigan was providing batch processing services on IBM 7090 hardware under the control of the University of Michigan Executive System (UMES), but was interested in offering interactive services using time-sharing.[9] At that time the work that computers could perform was limited by their small real memory capacity. When IBM introduced its System/360 family of computers in the mid-1960s, it did not provide a solution for this limitation and within IBM there were conflicting views about the importance of and need to support time-sharing.

A paper titled Program and Addressing Structure in a Time-Sharing Environment by Bruce Arden, Bernard Galler, Frank Westervelt (all associate directors at UM's academic Computing Center), and Tom O'Brian building upon some basic ideas developed at the Massachusetts Institute of Technology (MIT) was published in January 1966.[10] The paper outlined a virtual memory architecture using dynamic address translation (DAT) that could be used to implement time-sharing.

After a year of negotiations and design studies, IBM agreed to make a one-of-a-kind version of its S/360-65 mainframe computer with dynamic address translation (DAT) features that would support virtual memory and accommodate UM's desire to support time-sharing. The computer was dubbed the Model S/360-65M.[9] The "M" stood for Michigan. But IBM initially decided not to supply a time-sharing operating system for the machine. Meanwhile, a number of other institutions heard about the project, including General Motors, the Massachusetts Institute of Technology's (MIT) Lincoln Laboratory, Princeton University, and Carnegie Institute of Technology (later Carnegie Mellon University). They were all intrigued by the time-sharing idea and expressed interest in ordering the modified IBM S/360 series machines. With this demonstrated interest IBM changed the computer's model number to S/360-67 and made it a supported product.[1] With requests for over 100 new model S/360-67s IBM realized there was a market for time-sharing, and agreed to develop a new time-sharing operating system called TSS/360 (TSS stood for Time-sharing System) for delivery at roughly the same time as the first model S/360-67.

While waiting for the Model 65M to arrive, U of M Computing Center personnel were able to perform early time-sharing experiments using an IBM System/360 Model 50 that was funded by the ARPA CONCOMP (Conversational Use of Computers) Project.[11] The time-sharing experiment began as a "half-page of code written out on a kitchen table" combined with a small multi-programming system, LLMPS from MIT's Lincoln Laboratory,[1] which was modified and became the U of M Multi-Programming Supervisor (UMMPS) which in turn ran the MTS job program. This earliest incarnation of MTS was intended as a throw-away system used to gain experience with the new IBM S/360 hardware and which would be discarded when IBM's TSS/360 operating system became available.

Development of TSS took longer than anticipated, its delivery date was delayed, and it was not yet available when the S/360-67 (serial number 2) arrived at the Computing Center in January 1967.[12] At this time UM had to decide whether to return the Model 67 and select another mainframe or to develop MTS as an interim system for use until TSS was ready. The decision was to continue development of MTS and the staff moved their initial development work from the Model 50 to the Model 67. TSS development was eventually canceled by IBM, then reinstated, and then canceled again. But by this time UM liked the system they had developed, it was no longer considered interim, and MTS would be used at U of M and other sites for 33 years.

MTS Consortium

[edit]

MTS was developed, maintained, and used by a consortium of eight universities in the US, Canada, and the United Kingdom:[2][13]

Several sites ran more than one MTS system: NUMAC ran two (first at Newcastle and later at Durham), Michigan ran three in the mid-1980s (UM for Maize, UB for Blue, and HG at Human Genetics), UBC ran three or four at different times (MTS-G, MTS-L, MTS-A, and MTS-I for general, library, administration, and instruction).

Each of the MTS sites made contributions to the development of MTS, sometimes by taking the lead in the design and implementation of a new feature and at other times by refining, enhancing, and critiquing work done elsewhere. Many MTS components are the work of multiple people at multiple sites.[19]

In the early days collaboration between the MTS sites was accomplished through a combination of face-to-face site visits, phone calls, the exchange of documents and magnetic tapes by snail mail, and informal get-togethers at SHARE or other meetings. Later, e-mail, computer conferencing using CONFER and *Forum, network file transfer, and e-mail attachments supplemented and eventually largely replaced the earlier methods.

The members of the MTS Consortium produced a series of 82 MTS Newsletters between 1971 and 1982 to help coordinate MTS development.[20]

Mugs from MTS Workshop VIII, Ann Arbor, July 1982

Starting at UBC in 1974[21] the MTS Consortium held annual MTS Workshops at one of the member sites. The workshops were informal, but included papers submitted in advance and Proceedings published after-the-fact that included session summaries.[22] In the mid-1980s several Western Workshops were held with participation by a subset of the MTS sites (UBC, SFU, UQV, UM, and possibly RPI).

The annual workshops continued even after MTS development work began to taper off. Called simply the "community workshop", they continued until the mid-1990s to share expertise and common experiences in providing computing services, even though MTS was no longer the primary source for computing on their campuses and some had stopped running MTS entirely.

MTS sites

[edit]

In addition to the eight MTS Consortium sites that were involved in its development, MTS was run at a number of other sites, including:[13]

A copy of MTS was also sent to the University of Sarajevo, Yugoslavia, though whether or not it was ever installed is not known.

INRIA, the French national institute for research in computer science and control in Grenoble, France ran MTS on a trial basis, as did the University of Waterloo in Ontario, Canada, Southern Illinois University, the Naval Postgraduate School, Amdahl Corporation, ST Systems for McGill University Hospitals, Stanford University, and University of Illinois in the United States, and a few other sites.

Hardware

[edit]
Computing Center staff member Mike Alexander sitting at the console of the IBM System 360 Model 67 Duplex at the University of Michigan, 1969
Amdahl 470V/6 P2 at the University of Michigan, 1975

In theory MTS will run on the IBM S/360-67, any of the IBM S/370 series which include virtual memory, and their successors. MTS has been run on the following computers in production, benchmarking, or trial configurations:[2]

The University of Michigan installed and ran MTS on the first IBM S/360-67 outside of IBM (serial number 2) in 1967, the second Amdahl 470V/6 (serial number 2) in 1975,[26][27] the first Amdahl 5860 (serial number 1) in 1982, and the first factory shipped IBM 3090–400 in 1986.[28] NUMAC ran MTS on the first S/360-67 in the UK and very likely the first in Europe.[29] The University of British Columbia (UBC) took the lead in converting MTS to run on the IBM S/370 series (an IBM S/370-168) in 1974. The University of Alberta installed the first Amdahl 470V/6 in Canada (serial number P5) in 1975.[16] By 1978 NUMAC (at University of Newcastle upon Tyne and University of Durham) had moved main MTS activity on to its IBM S/370 series (an IBM S/370-168).

MTS was designed to support up to four processors on the IBM S/360-67, although IBM only produced one (simplex and half-duplex) and two (duplex) processor configurations of the Model 67. In 1984 RPI updated MTS to support up to 32 processors in the IBM S/370-XA (Extended Addressing) hardware series, although 6 processors is likely the largest configuration actually used.[30] MTS supports the IBM Vector Facility,[31] available as an option on the IBM 3090 and ES/9000 systems.

In early 1967 running on the single processor IBM S/360-67 at UM without virtual memory support, MTS was typically supporting 5 simultaneous terminal sessions and one batch job.[2] In November 1967 after virtual memory support was added, MTS running on the same IBM S/360-67 was simultaneously supporting 50 terminal sessions and up to 5 batch jobs.[2] In August 1968 a dual processor IBM S/360-67 replaced the single processor system, supporting roughly 70 terminal and up to 8 batch jobs.[32] By late 1991 MTS at UM was running on an IBM ES/9000-720 supporting over 600 simultaneous terminal sessions and from 3 to 8 batch jobs.[2]

MTS can be IPL-ed under VM/370, and some MTS sites did so, but most ran MTS on native hardware without using a virtual machine.

Features

[edit]

Some of the notable features of MTS include:[33]

Programs developed for MTS

[edit]

The following are some of the notable programs developed for MTS:[46]

Programs that run under MTS

[edit]

The following are some of the notable programs ported to MTS from other systems:[46]

Programming languages available under MTS

[edit]

MTS supports a rich set of programming languages, some developed for MTS and others ported from other systems:[46]

System architecture

[edit]
Main article: MTS system architecture
MTS Architecture[105]
State Mode[37] 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

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

Manuals and documentation

[edit]

The lists that follow are quite University of Michigan centric. Most other MTS sites used some of this material, but they also produced their own manuals, memos, reports, and newsletters tailored to the needs of their site.

End-user documentation

[edit]

The manual series MTS: The Michigan Terminal System, was published from 1967 through 1991, in volumes 1 through 23, which were updated and reissued irregularly.[20] Initial releases of the volumes did not always occur in numeric order and volumes occasionally changed names when they were updated or republished. In general, the higher the number, the more specialized the volume.

The earliest versions of MTS Volume I and II had a different organization and content from the MTS volumes that followed and included some internal as well as end user documentation. The second edition from December 1967 covered:

  • MTS Volume I: Introduction; Concepts and facilities; Calling conventions; Batch, Terminal, Tape, and Data Concentrator user's guides; Description of UMMPS and MTS; Files and devices; Command language; User Programs; Subroutine and macro library descriptions; Public or library file descriptions; and Internal specifications: Dynamic loader (UMLOAD), File and Device Management (DSRI prefix and postfix), Device Support Routines (DSRs), and File routines[106]
  • MTS Volume II: Language processor descriptions: F-level assembler; FORTRAN G; IOH/360; PIL; SNOBOL4; UMIST; WATFOR; and 8ASS (PDP-8 assembler)[103]

The following MTS Volumes were published by the University of Michigan Computing Center[2] and are available as PDFs:[107][108][109][110]

  • MTS Reference Summary, a ~60 page, 3" x 7.5", pocket guide to MTS, Computing Center, University of Michigan
  • The Taxir primer: MTS version, Brill, Robert C., Computing Center, University of Michigan
  • Fundamental Use of the Michigan Terminal System, Thomas J. Schriber, 5th Edition (revised), Ulrich's Books, Inc., Ann Arbor, MI, 1983, 376 pp.
  • Digital computing, FORTRAN IV, WATFIV, and MTS (with *FTN and *WATFIV), Brice Carnahan and James O Wilkes, University of Michigan, Ann Arbor, MI, 1968–1979, 1976 538 p.
  • Documentation for MIDAS, Michigan Interactive Data Analysis System, Statistical Research Laboratory, University of Michigan[111]
  • OSIRIS III MTS Supplement, Center for Political Studies, University of Michigan[112]

Various aspects of MTS at the University of Michigan were documented in a series of Computing Center Memos (CCMemos)[108][113] which were published irregularly from 1967 through 1987, numbered 2 through 924, though not necessarily in chronological order. Numbers 2 through 599 are general memos about various software and hardware; the 600 series are the Consultant's Notes series—short memos for beginning to intermediate users; the 800 series covers issues relating to the Xerox 9700 printer, text processing, and typesetting; and the 900 series covers microcomputers. There was no 700 series. In 1989 this series continued as Reference Memos with less of a focus on MTS.[114][115]

Cover page of the May 1996 issue of University of Michigan IT Digest, May 1996

A long run of newsletters targeted to end-users at the University of Michigan with the titles Computing Center News, Computing Center Newsletter, U-M Computing News, and the Information Technology Digest were published starting in 1971.[108][113]

There was also introductory material presented in the User Guide, MTS User Guide, and Tutorial series, including:[108]

  • Getting connected—Introduction to Terminals and Microcomputers
  • Introduction to the Computing Center
  • Introduction to Computing Center services
  • Introduction to Database Management Systems on MTS
  • Introduction to FORMAT
  • Introduction to Magnetic Tapes
  • Introduction to MTS
  • Introduction to the MTS File Editor
  • Introduction to Programming and Debugging in MTS
  • Introduction to Terminals
  • Introduction to Terminals and Microcomputers

Internals documentation

[edit]

The following materials were not widely distributed, but were included in MTS Distributions:[20][107][109]

  • MTS Operators Manual[116]
  • MTS Message Manual
  • MTS Volume n: Systems Edition[117][118]
  • MTS Volume 99: Internals Documentation[119]
  • Supervisor Call Descriptions[120]
  • Disk Disaster Recovery Procedures[121]
  • A series of lectures describing the architecture and internal organization of the Michigan Terminal System given by Mike Alexander, Don Boettner, Jim Hamilton, and Doug Smith (4 audio tapes, lecture notes, and transcriptions)

Distribution

[edit]

The University of Michigan released MTS on magnetic tape on an irregular basis.[20] There were full and partial distributions, where full distributions (D1.0, D2.0, ...) included all of the MTS components and partial distributions (D1.1, D1.2, D2.1, D2.2, ...) included just the components that had changed since the last full or partial distribution. Distributions 1.0 through 3.1 supported the IBM S/360 Model 67, distribution 3.2 supported both the IBM S/360-67 and the IBM S/370 architecture, and distributions D4.0 through D6.0 supported just the IBM S/370 architecture and its extensions.

MTS distributions included the updates needed to run licensed program products and other proprietary software under MTS, but not the base proprietary software itself, which had to be obtained separately from the owners. Except for IBM's Assembler H, none of the licensed programs were required to run MTS.

The last MTS distribution was D6.0 released in April 1988. It consisted of 10,003 files on six 6250 bpi magnetic tapes. After 1988, distribution of MTS components was done in an ad hoc fashion using network file transfer.

To allow new sites to get started from scratch, two additional magnetic tapes were made available, an IPLable boot tape that contained a minimalist version of MTS plus the DASDI and DISKCOPY utilities that could be used to initialize and restore a one disk pack starter version of MTS from the second magnetic tape. In the earliest days of MTS, the standalone TSS DASDI and DUMP/RESTORE utilities rather than MTS itself were used to create the one-disk starter system.

There were also less formal redistributions where individual sites would send magnetic tapes containing new or updated work to a coordinating site. That site would copy the material to a common magnetic tape (RD1, RD2, ...), and send copies of the tape out to all of the sites. The contents of most of the redistribution tapes seem to have been lost.

Today, complete materials from the six full and the ten partial MTS distributions as well as from two redistributions created between 1968 and 1988 are available from the Bitsavers Software archive[122][123] and from the University of Michigan's Deep Blue digital archive.[124][125]

Working with the D6.0 distribution materials, it is possible to create an IPLable version of MTS. A new D6.0A distribution of MTS makes this easier.[126] D6.0A is based on the D6.0 version of MTS from 1988 with various fixes and updates to make operation under Hercules in 2012 smoother. In the future, an IPLable version of MTS will be made available based upon the version of MTS that was in use at the University of Michigan in 1996 shortly before MTS was shut down.[123]

Licensing

[edit]

As of December 22, 2011, the MTS Distribution materials are freely available under the terms of the Creative Commons Attribution 3.0 Unported License (CC BY 3.0).[127]

In its earliest days MTS was made available for free without the need for a license to sites that were interested in running MTS and which seemed to have the knowledgeable staff required to support it.

In the mid-1980s licensing arrangements were formalized with the University of Michigan acting as agent for and granting licenses on behalf of the MTS Consortium.[128] MTS licenses were available to academic organizations for an annual fee of $5,000, to other non-profit organizations for $10,000, and to commercial organizations for $25,000. The license restricted MTS from being used to provide commercial computing services. The licensees received a copy of the full set of MTS distribution tapes, any incremental distributions prepared during the year, written installation instructions, two copies of the current user documentation, and a very limited amount of assistance.

Only a few organizations licensed MTS. Several licensed MTS in order to run a single program such as CONFER. The fees collected were used to offset some of the common expenses of the MTS Consortium.

See also

[edit]

References

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Michigan Terminal System

View on Grokipedia
from Grokipedia
The Michigan Terminal System (MTS) is a pioneering operating system developed at the for and System/370 mainframe computers, providing multi-user interactive access and from its initial release in 1967 until the late 1990s. Designed to support a growing academic community, MTS enabled up to 100 simultaneous users by the early 1970s, integrating seamlessly into university workflows much like a telephone system and fostering a shared environment through disk files and magnetic tapes. Its development began in 1966 on an 360/50 prototype, becoming operational in January 1967 on the IBM 360/67 hardware, which facilitated time-sharing for an initial group of about five terminal users and one batch stream. A key innovation in MTS was the introduction of virtual memory in November 1967, implemented via paging and high-speed drum storage, which dramatically increased system capacity and allowed efficient resource sharing among users. The system evolved to support starting in August 1968 with a dual-processor 360/67 configuration, and it transitioned to more powerful hardware like the 370/168 in January 1975, alongside Amdahl mainframes such as the 470V series. MTS featured a modular with robust file management, including public and private files, access controls via the PERMIT command, and defensive updating mechanisms to prevent data loss during crashes; it also offered a command-driven interface, an integrated file editor, and support for programming languages like , APL, and . By the , enhancements included network server capabilities for services like FTP and time/date queries, full-screen terminal support, and integration with university networks such as UMnet and Michnet. MTS's longevity—spanning nearly three decades—and its role in academic computing had a profound impact, training generations of users including notable figures like , and influencing the design of subsequent operating systems through its emphasis on accessibility, reliability, and multi-user efficiency. Deployed at universities across the , , and , it ran on emulators like into the modern era, with its and now openly available under a for historical study. The system's , compiled in volumes like MTS Volume 1 published in November 1991, detailed its internal structure as a multiprogramming, supervisor with reentrant programs, underscoring its foundational contributions to time-sharing technology.

Introduction

Overview

The Michigan Terminal System (MTS) is an interactive, multi-user operating system developed for computers at the . Its core purpose is to enable simultaneous access for hundreds of users via remote terminals, facilitating academic and research computing tasks such as program execution, file management, and in a shared environment. MTS supported substantial scale, with individual installations handling over 250 concurrent terminal users on typical days during the late 1970s, alongside thousands of total accounts and jobs processed monthly across university sites. By the late 1980s, peak capacity at the primary site exceeded 600 simultaneous interactive sessions. First becoming operational in 1967, the system remained in primary use through the late 1990s at multiple academic institutions. The system was built primarily in , incorporating components in high-level languages like and for user programs, and operated on modified and System/370 hardware with support.

Historical Significance

The Michigan Terminal System (MTS) emerged as a pioneer in interactive during the mid-1960s, well before the advent of widespread personal computers, by enabling remote access to mainframe resources via terminals for students, faculty, and researchers. Developed at the starting in 1967 on the Model 67, MTS shifted from to real-time, multi-user interaction, allowing thousands of users to share a single machine efficiently. This capability democratized access to computational power, supporting diverse tasks from simple student programs to complex simulations requiring extensive resources. MTS played a key role in advancing paradigms, demonstrating scalable multi-user support that handled up to 13,000 users and 86,000 jobs per month at its primary site. Unlike batch-oriented systems such as OS/360, which prioritized sequential job processing, MTS emphasized immediate responsiveness and segmentation to facilitate concurrent operations. It complemented IBM's TSS/360 by providing a more reliable alternative for academic environments, where TSS/360 struggled with performance and delays. In academic settings, MTS had profound impact, facilitating research projects, theses, and publications across universities by offering robust tools for computational experimentation and . Adopted by the MTS Consortium—comprising eight universities (, , , Queen's University, , , , and ) in the , , and the —and additional sites including the and , it supported installations worldwide, with receiving orders for over 40 compatible systems shortly after its debut. The long-term legacy of MTS underscores the end of an era in mainframe-based , with the retiring its system in 1996 and the final major installation at shutting down in June 1999. This closure marked the transition to distributed and client-server computing models, yet MTS's innovations in interactive access and resource sharing continued to inform operating system design principles.

Development History

Origins

The Michigan Terminal System (MTS) originated in 1964 at the University of Michigan's Computing Center, where the need for interactive, computing emerged to overcome the limitations of on early mainframes. This drive stemmed from the desire to enable concurrent access for multiple users in educational and research environments, inspired by pioneering efforts such as MIT's Project MAC and the Dartmouth Time-Sharing System, which demonstrated the feasibility of multi-user systems. This effort was funded by the ARPA-sponsored Project on Concepts of Computer Composition (ConComp). Key figures in the project's inception included Mike Alexander and Don Boettner, who served as principal architects, along with Bernie Galler, Frank Westervelt, and others at the Computing Center, who recognized the potential of emerging hardware for widespread interactive use. The initial goals focused on developing a robust system capable of supporting over 300 terminals connected to the new Model 67, thereby facilitating real-time access for students, faculty, and researchers across diverse disciplines. Early planning encountered significant challenges in adapting IBM's OS/360 for , as it proved inadequate due to its complexity, lack of native terminal support, and incompatibility with the interactive demands of the Model 67's architecture. Consequently, the team decided to construct MTS from scratch, bypassing modifications to the existing OS to achieve greater flexibility and performance tailored to needs. Prototype development commenced in 1966 on an Model 50, initially leveraging elements from MIT's systems to build core components like the UMMPS executive, marking the transition from conceptual planning to practical implementation.

MTS Consortium

The MTS Consortium was formed in 1967 as a non-profit collaboration among universities to share the costs of developing and maintaining the (MTS), enabling broader adoption beyond the . The led the effort, with early participating institutions including the (joining in 1968), the (1969), the (1970), and (1971). Over time, the consortium expanded to a peak of 13 sites across the , , and the , fostering a network of shared expertise in computing. Governance operated through annual workshops and meetings, starting around , where administrators and programmers from member sites exchanged information, coordinated joint bug fixes, and planned enhancements to MTS features. The shared funding model relied on contributions from participants, including fees for distributing magnetic tapes containing MTS software and documentation, which supported ongoing maintenance and updates. The consortium's structure provided key benefits by allowing institutions to implement MTS without bearing full development expenses, including support for compatible hardware from vendors like Amdahl, and promoting standardization of the system across varied and System/370 configurations. This collaboration extended MTS's reach, enabling efficient resource use in academic environments. Among its primary activities were coordinated software releases and collective efforts to produce comprehensive documentation, with the first formal MTS workshop held in at the to align on system improvements. These joint initiatives ensured MTS remained robust and adaptable, supporting operations at multiple sites for decades.

Key Milestones

The Michigan Terminal System (MTS) achieved its first production release in May 1967 on the Model 67 at the , marking the system's initial deployment as a operating system capable of supporting multiple conversational users and batch jobs simultaneously. Initially limited to 3-4 interactive users, the system was enhanced later that year with relocation hardware and a paging , significantly increasing its capacity to handle a broader range of workloads on the virtual memory-enabled hardware. In the early 1970s, MTS expanded to support the IBM System/370 architecture following the University of Michigan's acquisition of a Model 158 in 1972, enabling compatibility with the newer mainframe series and its advanced virtual storage features. Ports to compatible clones, including the Amdahl 470V/6 installed in 1975, further broadened hardware support while maintaining performance advantages over IBM equivalents. By 1978, enhancements aligned with System/370's virtual storage capabilities allowed MTS to manage larger address spaces and improved memory efficiency, as documented in system internals from that period. A notable event was the 1969 MTS Summer Conference, where developers presented on the system's architecture and shared experiences among early adopters. During the 1980s, MTS reached its peak with widespread adoption across university sites, including integration with BITNET for inter-site networking and resource sharing starting in the early part of the decade. By the mid-1980s, the system operated at multiple installations, with the running three concurrent MTS instances and other consortium members like NUMAC supporting dual systems, facilitating collaborative computing among over a dozen institutions. In 1985, MTS enabled hybrid configurations integrating with IBM's Conversational Monitor System (CMS) for enhanced user environments at select sites. The decline of MTS began in the 1990s amid the rise of UNIX-based systems and distributed minicomputers, leading to phased retirements across installations. The ceased MTS operations on May 30, 1997, after three decades of service. The final active site, , shut down its MTS system in 1999, marking the end of the operating system's operational history.

Hardware Support

Compatible Platforms

The Michigan Terminal System (MTS) was originally designed for the Model 67 mainframe, which debuted in 1967 and provided the foundational hardware platform for its time-sharing capabilities. This model supported through dynamic address translation hardware, enabling MTS to manage multiple users efficiently on a single processor configuration. MTS was subsequently adapted for the series, with support for Models 158 and 168, announced in 1972 to leverage improved performance and expanded addressing. These models allowed MTS installations to scale for larger user bases, with the System/370 architecture providing compatibility for 24- and 32-bit addressing modes essential to the system's operation. Later extensions included the System/370 Model 168 in January 1975, further enhancing reliability for academic and research environments, along with support for the IBM 3033 in the 1980s, 3090-400 (October 1986), 3090-600E (July 1988), and ES/9000-720 (June 1991). Third-party compatible systems expanded MTS's reach in the late and , including the Amdahl V/370 series starting with the 470V/6 model in July 1975, followed by the 470V/7 in 1979 and 470V/8 in 1980. Support for HITAC and mainframes emerged in the , with the Hitachi H-65 (equivalent to 3033) installed in 1982 and the Fujitsu M-200 (equivalent to 3081) in 1983, requiring specific modifications to ensure compatibility with MTS's and I/O requirements. These adaptations allowed non-IBM hardware to run MTS without major software changes, though detailed hardware tweaks are covered in related documentation. MTS installations required channel-attached disk storage such as IBM 3330 units for file systems and paging. Terminal access relied on multiplexers like the IBM 2701 or 3705 to connect multiple 3270-compatible devices, supporting up to hundreds of concurrent users. The system did not natively support or later architectures without emulation, remaining focused on 24/32-bit addressing environments. Primarily at universities and research institutions, MTS sites included the original consortium members and additional academic installations worldwide. The University of Michigan's primary installation featured dual CPUs for redundancy, ensuring continuous operation during maintenance or failures on its and subsequent upgrades.

Hardware Modifications

The Michigan Terminal System (MTS) required specific hardware adaptations to the to enable efficient , particularly through the integration of dynamic relocation hardware that supported without imposing significant software overhead. This hardware facilitated address translation for problem programs, allowing dynamic loading into and resolution of external symbols, which contributed to a tenfold increase in the number of tasks serviced compared to earlier configurations. A high-speed was incorporated for paging operations, enhancing the system's ability to manage multiple users concurrently. To handle high terminal throughput essential for , MTS installations incorporated channel extensions and custom I/O interfaces, including support for polled multiplexors that connected numerous terminals to the system. These modifications centralized I/O management through device support routines, enabling efficient handling of high-speed devices and supporting up to hundreds of simultaneous users across various terminal types. On the series, MTS benefited from memory upgrades that extended capacity to 64 MB via paging mechanisms, dividing the into 64 segments of 1,048,576 bytes each (256 pages of 4,096 bytes). Additional hardware, such as extended control storage, was added to accommodate larger workloads and more users, building on the base platforms like the 370 series. Third-party hardware modifications, particularly from Amdahl, were adapted for MTS at sites like the University of Michigan, including the Amdahl 470V/6 (installed July 1975), 470V/7 (March 1979), 470V/8 (September 1980), and 5860 (November 1982). These faster processors required compatibility adjustments to MTS, including tweaks to the kernel for timing and enhanced to leverage the increased cycle speeds. For reliability at large installations, MTS supported dual-processor configurations, such as the upgrade to a dual 360/67 in , which enabled and capabilities. This setup allowed switching between processors and resources like core boxes and channels to maintain operations during failures, ensuring for environments.

System Architecture

Core Design Principles

The Michigan Terminal System (MTS) was designed around a modular resident monitor to enhance maintainability and flexibility in a time-sharing environment. The core is implemented by the UMMPS supervisor, a multiprogramming executive managing resident reentrant programs for system services. This monitor is structured into key components, including the swapper for managing program movement between main memory and secondary storage, the scheduler for allocating CPU time among active processes, and device handlers known as Device Support Routines (DSRs) for each supported hardware type. These elements interact through a centralized interface for input/output operations, allowing independent development and updates without disrupting the overall system. This modularity facilitated the system's evolution over decades while supporting diverse hardware configurations on IBM System/360 and System/370 computers. Central to MTS's operation is its time-sharing model, which employs priority-based scheduling with FIFO dispatching within priority classes (1-10 levels) to ensure responsive access for interactive users while handling batch loads. Jobs are dispatched according to priority, with higher-priority tasks receiving preferential treatment to minimize response times for interactive sessions. This approach supports concurrent terminal, batch, and server workloads using a unified command language, enabling seamless integration of interactive and non-interactive computing. The design prioritized low-latency user interaction on limited hardware resources, distinguishing MTS from purely batch-oriented systems of the era. Backward compatibility with OS/360 was a foundational principle, allowing MTS to execute unmodified batch jobs and applications from IBM's earlier operating system alongside time-shared sessions. Programs written in languages like or could typically run without changes, leveraging OS/360-like services for file handling and job control. This compatibility eased migration for institutions adopting , preserving investments in legacy software while introducing interactive capabilities. MTS's security model emphasizes user isolation through virtual address spaces, where each task operates in a protected environment inaccessible to others. Private segments for are safeguarded by dynamic translation, preventing unauthorized access, while shared system segments rely on hardware protection mechanisms. Absent a role akin to those in later operating systems, privileged operations occur in a dedicated system mode accessible only to trusted routines, reducing the risk of escalation vulnerabilities. This design provided robust separation for multi-user environments without centralized administrative overrides. Scalability was achieved through dynamic , enabling MTS to support from dozens to over 600 simultaneous terminal users on appropriately configured hardware, with total registered accounts reaching thousands at major installations like the . The modular architecture and efficient scheduling allowed the system to handle up to 86,000 jobs per month by adapting to varying loads without requiring hardware overprovisioning. This flexibility made MTS suitable for academic and research settings with fluctuating demand.

Memory Management

The Michigan Terminal System (MTS) utilized to support multi-user on and System/370 hardware, allocating up to a 16 MB per user on 24-bit hardware (expandable to larger effective spaces on later configurations) through demand paging with a fixed page size of 4 KB. MTS employs segmented , dividing the into 64 segments of 1 MB each (256 pages of 4 KB), with paging for demand loading and protection. This approach allowed programs to exceed the physical memory limits of the host machine by transferring pages between main memory and secondary storage as needed, enabling efficient resource sharing among concurrent users. The system automatically manages page faults and transfers without user intervention. Swapping complemented paging by handling entire user contexts—comprising the active program's core image and associated data—when memory demand exceeded available real pages. Swapping moves entire user contexts to secondary storage when memory is constrained, complementing paging for efficient multi-user support, with system-managed page transfers. Virtual memory was introduced in November 1967 on the IBM 360/67, with further enhancements for System/370 hardware in subsequent releases around 1973, marking a significant evolution from earlier swapping-only mechanisms and leveraging System/370 hardware modifications for dynamic address relocation. Performance metrics from this era highlighted the system's scalability, with paging activity enabling a tenfold increase in concurrent tasks compared to non-virtualized predecessors, while maintaining low overhead through optimized page-in rates tracked via system monitors.

Features

User Interaction

The Michigan Terminal System (MTS) provided users with a text-based, characterized by a distinctive ()prompt,whichfacilitatedline−orientedinputforexecutingsystemcommands.Usersenteredcommandssuchas) prompt, which facilitated line-oriented input for executing system commands. Users entered commands such as run to initiate program execution (e.g., run∗TAPESUBMIT),run *TAPESUBMIT), edit to invoke the file editor, and $systemstatus to query system resources, with each command line limited to 255 characters and continuable using a (-) or a custom continuation character set via the SET CONTCHAR command. This processor acted as the primary interface between the user and the operating system, processing inputs asynchronously and supporting batch-like operations within interactive sessions. MTS supported a range of terminal types through dedicated facilities for both asynchronous and synchronous communication modes. Asynchronous terminals, such as the IBM 2741, handled character-by-character transmission, while synchronous terminals like the IBM 3270 enabled block-mode operations for more efficient data exchange. Editing capabilities were enhanced on display terminals via escape sequences, allowing visual-mode or full-screen interactions, such as those in the FILEMENU editor using program function (PF) keys for navigation and modification. The system lacked any graphical user interface, relying entirely on text-based input and output, often with prefix characters like '#' or ':' to denote system responses. User sessions in MTS began with a login procedure at the "Which Host?" prompt, where individuals entered SIGNONfollowedbytheiruserIDandoptionalpassword(e.g.,SIGNON followed by their user ID and optional password (e.g., SIGNON userid password). Upon authentication, users could specify a job class to determine execution priority, with predefined options like NORMAL or LOW, or numeric values ranging from 1 to 10 for computation and 0 to 15 for printing; these could also be adjusted mid-session using SET CLASS. Sessions concluded with the $SIGNOFF command, which terminated the connection and displayed a summary of resource usage and costs incurred. Error handling in MTS emphasized interactive diagnostics to assist users in resolving issues promptly. The $STATUS command, for instance, retrieved detailed information on job queues, system load, and pending operations, enabling users to monitor and troubleshoot their activities. When errors occurred, such as exceeding global resource limits (e.g., "GLOBAL item LIMIT EXCEEDED"), the system often prompted interactively for corrections, like requesting a new file or device name, thereby minimizing disruptions in the user . To enhance usability, MTS incorporated scripting capabilities through macros and command files, allowing users to automate repetitive tasks without a graphical environment. Macros were defined using a structured , such as >MACRO name followed by commands and concluded with >ENDMACRO, and could be enabled system-wide via SET MACROS=ON. Command files, often called signature files (sigfiles), were invoked with SET SIGFILE=filename or executed via $SOURCE, supporting input/output redirection modifiers like SOURCE and SINK for streamlined operations. These features promoted efficient, customizable interactions tailored to both novice and advanced users.

File and Device Management

The file system in the Michigan Terminal System (MTS) organizes data using a flat structure based on userID:filename conventions, without traditional hierarchical directories. Private files are associated with a specific user identifier followed by a filename up to 12 characters long (e.g., 1ABC:MYLOG), while public files use an asterisk prefix (e.g., *NEWS) and temporary files a hyphen prefix. Files are stored in 4096-byte pages on direct-access disk volumes, supporting types such as LINE files for fixed-length records with line numbers and SEQ files for variable-length sequential records without line numbers. Maximum file size is 32,767 pages, equivalent to approximately 128 MB. Access to files is controlled through the PERMIT command, which assigns permissions like READ, WRITE-APPEND, TRUNCATE, or UNLIMITED to specific users, projects, or program keys (e.g., PERMIT MYFILE READ OTHERS). By default, users have full access to their own files but none to others, with sharing enabled explicitly via PERMIT and checked using FILESTATUS. Locking mechanisms via LOCK and UNLOCK commands prevent concurrent modifications, supporting options like WAIT or NOWAIT for contention resolution. Disk space quotas are enforced per user through accounting records, limiting total storage allocation and monitored during operations like file creation or renaming; defaults vary by installation but are adjustable at sign-on. Device management in MTS utilizes centralized Device Support Routines (DSRs) for unified I/O operations across peripherals, abstracting hardware differences through pseudodevices and modifiers like SEQUENTIAL or EBCDIC encoding. Supported disks include IBM 2311 and 3330 models, providing on-line storage with automatic expansion (default 10% overhead) and buffer management for efficient access. Tapes, primarily 9-track at densities of 800, 1600, or 6250 BPI, are user-mounted via MOUNT and controlled with commands like REWIND, FORWARD SPACE RECORD, or POSITION TO END-OF-TAPE. Printers are handled via spooled output to the *PRINT pseudodevice, with the COPY command directing files (e.g., COPY FILENAME TO *PRINT), supporting carriage control, formatting options like LANDSCAPE or PORTRAIT, and routing to specific stations. Backup and restore processes emphasize incremental and full dumps to tape, with no native journaling filesystem; recovery relies on periodic snapshots generated by utilities. Daily backups of changed files occur automatically using *SAV on 9-track tapes (retained for about six weeks), while weekly full saves via *SVW cover all files over multiple tape sets. Users invoke restores with *RESTORE, specifying files from backup volumes, or manually copy to tapes for personal archiving using CONTROL commands. practices, such as explicit buffer flushing with CLOSEFIL, minimize data loss between snapshots. Special devices facilitate batch and peripheral I/O, including 2501 card readers for input via the *SOURCE pseudodevice in sequential or modes, enabling job submission from punched cards. Line printers, such as the 1403 (up to 1100 lines per minute at 132 characters wide and 6 lines per inch), output to *SINK for conversational mode or *PRINT for batch, with 66 lines per page on 11-inch paper and support for character sets like TN or PN via CONTROL options.

Resource Allocation

The Michigan Terminal System (MTS) implemented resource allocation through a combination of priority-based scheduling and enforced limits to balance interactive and batch workloads across multiple users. Central to this was a priority-based round-robin CPU scheduling featuring 16 priority classes, which ensured fair distribution of processing time while favoring responsive interactive sessions. Interactive jobs received higher priority execution, typically in classes 1 through 10, determined by estimated requirements, allowing them to run immediately under low system load conditions. Batch jobs, in contrast, operated at lower priorities and were deferred until interactive demand subsided, preventing contention for resources during peak user activity. Print priorities ranged from 0 to 15, scaled by estimated output pages, further optimizing usage without disrupting core computation. The scheduler dynamically adjusted these classes to maintain system responsiveness, with users able to query their current class via the CLASS command. Resource limits were strictly imposed to prevent monopolization, including per-job CPU time caps set globally via the $SIGNON command (up to a maximum of 27,000 seconds) or locally via the RUN command, with a default of 3 seconds for short tasks. Connect time was managed through a funds-based system, where usage depleted allocated "money" units—defaulting to 50 pages equivalent—and jobs terminated upon exhaustion, adjustable via parameters like PAGES=400. Additional constraints covered output pages, input cards, and plot time, all configurable to align with site policies and prevent resource exhaustion. Batch and interactive processing utilized separate queues to isolate workloads: interactive sessions executed in real-time with precedence, while batch jobs were submitted using the $SUBMIT command (or variants like $COPY *SOURCE* *BATCH*) and held in dedicated queues until interactive load permitted processing. The EXQ command displayed waiting batch jobs, and flags like BP indicated batch-preferred execution modes during off-peak periods, ensuring efficient throughput without compromising user interactivity. Accounting mechanisms tracked resource consumption via integrated meters for , I/O operations, virtual storage integrals, terminal connect time, printed pages, and punched cards, enabling precise billing at installations. Usage data appeared on job tail sheets (e.g., computing costs of $0.64) and could be monitored in real-time with commands like COST={ON | OFF}, which displayed accumulated charges, remaining funds, and disk quotas. Post-job adjustments refined billing accuracy, supporting equitable cost recovery across shared systems. In multi-processor configurations, MTS optimized allocation through load balancing across available CPUs, distributing jobs to idle processors while maintaining priority hierarchies to enhance overall system efficiency. This approach, inherent to MTS's multiprocessing support, minimized bottlenecks in environments like the University of Michigan's installations.

Software Ecosystem

Programming Languages

The Michigan Terminal System (MTS) natively supported a variety of programming languages tailored for its environment on and System/370 mainframes, emphasizing interactive development, educational use, and system-level programming. These languages included enhancements for file I/O, integration, and , reflecting MTS's focus on multi-user accessibility and computational efficiency. Key implementations ranged from high-level languages like SNOBOL4 and to low-level assembly tools, with support for over 40 languages by the late . SNOBOL4 served as the primary string-processing language in MTS, designed for and symbolic manipulation. It featured four processors: the standard SNOBOL4 interpreter, SNOBOL4B for enhanced block operations and 2D/3D output (including overstriking for graphs and flowcharts), SPITBOL as a achieving up to 10 times the speed of the interpreter with object module saving, and SNOSTORM as a adding structured constructs like IF, LOOP, and CASE for improved readability and . MTS-specific enhancements included robust file I/O extensions, such as support for logical units (e.g., SCARDS for input, SPRINT for output), variable-record-length processing without padding, and format-free I/O via functions, enabling seamless integration with MTS's file management subsystem. These features made SNOBOL4 ideal for text analysis and report generation in a multi-user setting. BASIC in MTS, often invoked as an interactive system via $RUN *BASIC, was developed for educational purposes, providing an accessible entry point for students and novice programmers. Known as MTS BASIC or Simple MTS BASIC, it supported matrix operations, basic , and immediate execution modes, with features like built-in functions for mathematical computations and simple program editing. This implementation emphasized conversational programming, allowing users to test code snippets interactively while leveraging MTS's terminal-oriented interface for quick feedback and error handling. FORTRAN implementations in MTS centered on the FTN compiler family, including FORTRAN-G (standard FORTRAN IV) and FORTRAN-H (optimizing variant offering 25-50% faster execution), alongside VS FORTRAN for full ANSI compliance. These supported versions up to FORTRAN 77, incorporating block IF statements, PARAMETER declarations, and free-format I/O. A key MTS-specific feature was virtual array support through subroutines like ARINIT, , and EXTEND, enabling dynamic dimensioning and subscript checking (via SUBCHK) without fixed memory allocation, which aligned with MTS's model for efficient resource sharing among users. Additional tools like the OVERDRIVE preprocessor added structured elements (e.g., , loops), while interactive modes in systems like *IF77 facilitated and compilation in a context. For system programming, MTS provided BAL (Basic Assembly Language), a low-level assembler based on and 370 instructions, invoked via *ASMH for efficient code generation close to the hardware. BAL supported features like literal pooling, labeled USINGS for base register management, and extensions for Amdahl-specific opcodes (e.g., DXR for ). Complementing BAL was the MACRO assembler, which expanded capabilities through libraries like SYSMAC for nested macros, structured control (e.g., IF-ENDIF, DO-ENDDO), and I/O operations via routines like IOH and READ/WRITE. These tools were essential for developing MTS command extensions, device drivers, and subroutines, with options for symbolic debugging and flag management (e.g., SET ATTN,ON) to handle interrupts and errors in a multi-user environment. The ASSIST subset further simplified BAL for educational system programming, restricting intermixing of control sections while adding execution-time services like GETSPACE. Other natively supported languages included a subset via the PL/C compiler, a teaching-oriented implementation of PL/I(F) that omitted advanced optimizing features but retained core elements like block structure and for portability and simplicity in academic settings. LISP implementations encompassed the full LISP processor for list processing and symbolic computation, alongside UTILISP as a utility variant optimized for MTS's storage management, supporting dynamic garbage collection and interactive evaluation. Native C support was absent until late ports in the 1990s, as MTS prioritized established mainframe languages over emerging Unix-derived ones.

MTS-Specific Software

The Michigan Terminal System (MTS) featured several original software tools developed specifically for its environment, enhancing user productivity in text editing, document preparation, data visualization, statistical analysis, and system management. These programs were integral to the system's ecosystem, leveraging MTS's capabilities to support interactive and batch processing on and System/370 hardware. The EDIT editor provided a powerful line-oriented interface for manipulating text files, invoked via the command $EDIT filename. It supported essential operations such as inserting, deleting, moving, and copying lines within specified ranges, using line numbers from -2147483.648 to +2147483.647 or symbolic references like *F for the first line and *L for the last. Global search and replace functions were facilitated through commands like SCAN for and ALTER or CHANGE for substitutions, employing SNOBOL4-inspired algorithms that allowed , alternation, and case-insensitive options (e.g., @AC modifier). Additional features included justification for text alignment, checkpointing to track changes with or RESTORE capabilities, and edit procedures for reusable command sequences with looping via . A visual mode enabled screen-based cursor navigation and insertions on display terminals, customizable through Visual Program Functions (VPFs). These capabilities made EDIT a foundational tool for academic and research editing tasks, influencing subsequent line-oriented editors in university environments. RUNOFF served as a dedicated text formatter for producing formatted output suitable for manuals and reports, processing input files with embedded commands to control , spacing, and carriage returns. Invoked via $RUN *RUNOFF, it handled both terminal display and printer output, integrating with MTS's I/O devices like the SPRINT unit for high-quality rendering. Key directives allowed users to define margins, headers, footers, and font styles, making it effective for technical documentation. As an early interactive formatter in a system, RUNOFF laid groundwork for later tools like by emphasizing markup-based text processing in multi-user settings. The subsystem, detailed in the Integrated Graphics System, offered a suite of plotting tools for visualizing on terminals and printers, supporting device-independent output across hardware like the 4010/4114 and CalComp plotters. Core components included PLOTSYS for FORTRAN-callable subroutines that generated plot files (PDS) from arrays, enabling line graphs, scatter plots, and contour maps with scaling and labeling options. Complementary utilities like PLOTSEE allowed previewing and of PDS files interactively, with features for , combination of multiple plots, and direct queuing to remote plotters via CCQUEUE, which managed costs and priorities (e.g., ASAP mode with ballpoint pens). TELLAGRAF provided conversational 2D graphics for bar charts, histograms, and pie charts, incorporating fonts and enhancements for professional output. These tools facilitated -driven by allowing real-time visualization in MTS sessions. MTS incorporated statistical packages tailored for interactive analysis, prominently featuring the Biomedical Computer Programs (BMD) suite originally developed at UCLA but adapted and distributed within MTS for widespread use. BMD enabled biomedical and social science researchers to perform analyses such as regression, ANOVA, factor analysis, and discriminant functions on datasets via conversational or batch modes, with programs like BMDX72 for factor analysis processing card-punched or direct input. Integrated with MTS's file system, it supported data transformation and output to printers or graphics devices, contributing to thousands of studies in fields like epidemiology and psychology due to its accessibility in time-sharing environments. Other built-in options, such as TAXIR for n-way tabulations and subtotals in data banks, complemented BMD by allowing ad-hoc queries and reports. System utilities included $diskuse for monitoring and managing disk space allocation, displaying metrics like total virtual storage used (in pages) and associated for user files (e.g., "Total virtual storage used = 3 pages. = 0.055343 seconds"). This tool aided administrators and users in optimizing resource usage under MTS's segmented file structure. Custom loaders supported overlay programs by enabling efficient module linking and optimization; for instance, LINKEDIT combined object modules into loadable formats via SPUNCH output, while OBJUTIL edited object files to add, replace, or delete modules, generating compact files for overlay hierarchies. These loaders reduced overhead in large applications by prioritizing symbol searches and removing unnecessary records with tools like ENDJUNK, essential for running complex programs in MTS's constraints.

Third-Party Compatibility

The Michigan Terminal System (MTS) offered significant compatibility with IBM's OS/360 operating system, primarily through emulation of OS/360 services and support for standard IBM file formats. This allowed many OS/360 batch jobs to run under MTS after conversion, facilitated by tools like the Houston Automatic Spooling Priority (HASP) system for and direct compatibility with OS/360 magnetic tapes and disks in IBM-labeled formats. Shared libraries from OS/360 environments could be integrated via MTS's public , which provided flexible access and protection mechanisms superior to those in OS/360 for user-shared resources. Additionally, runtime libraries for languages like and were converted from OS/360 versions, enabling unmodified execution of corresponding programs without full recompilation in many cases. Several third-party applications from other ecosystems were ported to MTS during the , enhancing its utility for academic and research tasks. A prominent example is the Statistical Package for the Social Sciences (), originally developed for systems, which was adapted as a subsystem on MTS to support statistical analysis in social sciences and related fields. Early functionality was also integrated via consortium networks connecting MTS installations across universities, allowing inter-site messaging that built on protocols from broader developments. Academic simulators for domains like physics and chemistry, such as the Structurally Oriented Simulation System (SOSS) for molecular modeling, were ported or adapted to leverage MTS's interactive environment. MTS included limited emulation layers for with CP/CMS, providing command equivalents that allowed basic file access and operations across systems on shared hardware, though full file compatibility required manual intervention due to differing formats. Some installations operated hybrid MTS/CMS configurations to combine with capabilities, enabling limited cross-system file handling. Porting third-party software to MTS faced challenges, particularly during migrations from System/360 to System/370 hardware, where architectural enhancements like dynamic address translation necessitated recompilation of many components to maintain and compatibility. There was no binary compatibility with UNIX systems, as MTS targeted mainframes while UNIX ran on disparate architectures, requiring full source-level ports for any cross-adoption. These hurdles were mitigated through MTS's modular design, but they underscored the effort needed for integrating external legacies.

Documentation

User Documentation

The primary user documentation for the Michigan Terminal System (MTS) is provided in MTS Volume 1: The Michigan Terminal System, first published in 1967 and regularly updated through subsequent editions, such as the November 1991 version corresponding to Release 6.0A. This manual serves as the foundational guide for end-users, offering a comprehensive overview of the system's , which operates in a conversational mode with a "#" prompt for entering MTS commands prefixed by "",suchas‘", such as `SIGNONto initiate a session.[](http://www.bitsavers.org/pdf/univOfMichigan/mts/volumes/MTSVol01-TheMichiganTerminalSystem-Nov1991.pdf) It details session management, including sign-on procedures (e.g.,SIGNON userID ), mode transitions between command, edit, and execution states, and handling of pseudodevices like SOURCE` for input redirection, all illustrated with practical examples to facilitate interactive terminal use. Introductory tutorials within the manual and related guides emphasize accessibility for novice users, particularly students, by providing step-by-step examples of basic operations. For instance, a typical "getting started" sequence might involve signing on, creating a simple file with CREATE filename, editing it via the edit mode prompt ":", and listing contents with LIST filename, as demonstrated in the manual's command prototypes and sample sessions. These tutorials cover essential workflows, such as running programs with RUN programname or submitting batch jobs via *BATCH*, with explanations tailored to non-expert users unfamiliar with systems. Appendices further support beginners by including setup instructions for terminals, such as configuring I/O modifiers for devices like the 3278 or 9700 printer. Reference materials in the manual include detailed command summaries and error code explanations, updated across releases to reflect new features like the FTP command for file transfers in later editions. Command references list syntax prototypes (e.g., COPY [FROM] {FDlist1} [[TO] FDlist2]) and options, while error handling sections describe common messages such as "FDname does not exist" or interrupt codes (e.g., Privileged operation = 1), enabling users to troubleshoot issues like invalid sign-ons or resource limits. For quick reference during sessions, MTS provides an integrated online help system accessible via the $HELP command (or HELP topic), which delivers context-specific guidance on commands and facilities directly from the terminal, drawing from the same documentation corpus. Distribution of user documentation occurred through printed volumes shared among the MTS consortium institutions, with updates disseminated via the University of Michigan's computing services to reflect system releases. Online access via $HELP ensured immediate availability without physical copies, supporting remote users across networked terminals. As of the 2020s, the full series of MTS user documentation (Volumes 1–23) is digitized and freely available online through archives such as Bitsavers and the University of Michigan's Deep Blue repository. The materials were designed for broad accessibility, prioritizing clear language and examples over technical depth to accommodate users without prior programming experience, while consortium-shared revisions kept content aligned with evolving hardware and software capabilities.

System Internals Documentation

The system internals documentation for the (MTS) primarily consists of technical manuals targeted at system administrators, programmers, and maintainers, providing detailed specifications for core operating system components and maintenance procedures. These documents evolved alongside MTS releases, with early versions tailored to specific hardware like the Model 67 in 1967 and later adaptations for the System/370 architecture introduced in 1972. The documentation was produced and edited by the Computing Center, later involving contributions from the MTS Consortium formed among licensed institutions to facilitate shared development and updates. A key resource is MTS Volume 3: System Subroutine Descriptions, which details kernel-level calls and system services, including interfaces for process management, memory allocation, and . This volume describes subroutine parameters, return codes, and usage examples for over 570 system routines, enabling programmers to interact directly with MTS internals such as paging and operations. For hardware-specific implementations and ports, dedicated guides outline adaptations for platforms like the System/370, covering modifications to the resident supervisor and device handling to leverage new virtual storage features. These implementation guides include architectural overviews, such as the of the Multiple Programming Executive (MPE) in coordinating batch and interactive workloads. Internals details in these manuals emphasize conceptual and operational aspects. Device driver specifications focus on Device Support Routines (DSRs), user-level modules that abstract hardware access for peripherals like terminals and tapes, with protocols for handling and trapping to ensure system stability. Flowcharts and diagrams illustrate process lifecycle states—from initiation via the command language interpreter to termination—highlighting transitions in the and routines for efficient multiprogramming. Maintenance documentation provides step-by-step procedures for system recovery and administration, such as diagnosing hardware faults through console diagnostics and restarting the resident supervisor after abends. The MTS Operators' Manual covers error recovery protocols, including dump analysis for core images and reconfiguration of the swap file to restore service. For installations, guides detail tape creation processes using the TAPEMK to generate distribution reels containing relocatable modules and initialization scripts, ensuring compatibility across mainframes. Access to these internals documents was restricted to licensed MTS sites, typically universities and research institutions under consortium agreements, with physical copies distributed via magnetic tapes alongside the . In some cases, volumes included partial listings for critical components like the assembler and linker, allowing maintainers to customize or debug low-level routines without full disclosure of proprietary elements. As of the , the full series of MTS internals documentation (Volumes 1–23) is digitized and freely available online through archives such as Bitsavers and the University of Michigan's Deep Blue repository.

Distribution and Licensing

Distribution Mechanisms

The Michigan Terminal System (MTS) was distributed to consortium members and licensed sites primarily via physical magnetic tapes, which were shipped directly to recipients such as universities including the and the University of New England. Full system distributions, designated D1.0 through D6.0, spanned from October 1968 to April 1988 and contained the complete operating system, while partial distributions (e.g., D2.1, D3.1) focused on incremental changes. The number of tapes per full distribution varied by version; for instance, D1.0 required 2 tapes, D3.0 used 5 filesave tapes plus 1 dump/restore tape, and D6.0 comprised 6 filesave tapes, 3 dump/restore tapes, and 1 utility tape. These were typically 9-track tapes, with later releases like D4.1 and D6.0 recorded at 6250 BPI for higher density storage. Installation of MTS began with a bootstrap loader process, often initiated by reading a card deck into the computer via a job program to establish initial control, followed by restoring the from the distribution tapes. This was succeeded by applying site-specific configurations, such as adjusting console addresses, volume reservations with commands like *RSV, and tailoring network tasks via *MNS for UMnet integration. New installations used dedicated instructions in files like xxxNEWSYS, while updates to existing systems followed procedures in xxxOLDSYS to integrate changes without full reinstallation. Updates were managed through patch tapes addressing bugs and partial distributions incorporating enhancements or site-contributed modifications, with redistributions (e.g., D4.2A) merging inputs periodically. Major version upgrades occurred irregularly but aligned with collaboration, often annually in later years, ensuring synchronized advancements across installations. After MTS's retirement in 1996, the original magnetic tapes were converted to digital formats, including 3480 cartridge images in 1996 and later simulated AWS tapes, enabling preservation and access via emulators without . These digital archives, including EBCDIC-to-ASCII translations and extraction tools like lbltp, were made publicly available through the University of Michigan's Deep Blue repository.

Licensing Terms

The Michigan Terminal System (MTS) was initially developed and released in 1967 under terms, enabling free exchange and non-commercial use by academic and institutions without formal restrictions or licensing fees. This open model facilitated widespread adoption among universities, with distributed via magnetic tapes to members and affiliates for educational and purposes. Access to MTS required membership in the MTS Consortium or a formal agreement with the , which managed distribution and provided updates, installation instructions, and as part of the arrangement. While was supplied to licensees, any modifications were expected to be shared back with the to support collective improvements, though this was governed by honor-based collaboration rather than strict mandates. Key restrictions prohibited commercial exploitation, including the use of MTS to offer paid computing services or integrate it into for-profit operations, ensuring its focus remained on academic and non-commercial applications. License agreements included clauses maintaining compatibility with and System/370 hardware, reflecting MTS's origins on platforms. Licensees held perpetual rights to installed versions of MTS, allowing indefinite use post-installation without ongoing fees, though official support and updates ceased after 1998 following the system's decommissioning at remaining sites. Enforcement relied on contractual honor systems, with the overseeing compliance through agreements rather than legal litigation. Over time, MTS licensing evolved from its open 1967 origins to more structured terms in the 1980s, driven by the rise of commercial mainframe computing and the need to fund ongoing development and distribution amid shifting industry dynamics. By 1987, annual fees were introduced—$5,000 for academic institutions, $10,000 for non-profits, and $25,000 for limited commercial access—to cover tape distributions (one full set plus 1–2 incremental updates yearly) and two copies of user documentation, while upholding non-commercial core restrictions.

Legacy

Influence and Impact

The Michigan Terminal System (MTS) significantly influenced operating system design, particularly in the areas of and . Developed in 1967, MTS was one of the first operational systems, alongside , enabling efficient resource sharing on mainframes through segmentation and paging techniques that provided user isolation via disjoint address spaces. These concepts contributed to the evolution of commercial systems, including IBM's VM/370 (derived from CP/67), which adopted similar principles for enhanced interactivity and multi-user support. Additionally, MTS's advancements in and indirectly shaped early UNIX development by promoting interactive computing paradigms on minicomputers, bridging the gap from mainframe to more accessible user environments. In academia, MTS left a profound legacy by training generations of programmers and researchers through its widespread adoption. Exported to over a dozen universities, it established the as a leader in and , fostering hands-on education in system programming and performance analysis. The system's support for tools like (Michigan Interactive Data Analysis System) enabled early computational work in fields such as and data-intensive research, laying groundwork for disciplines including by providing interactive analysis capabilities on shared resources. Research conducted on MTS, including studies on scheduling and , influenced subsequent OS performance modeling and continues to inform academic curricula in . Culturally, MTS contributed to the hacker ethic prevalent in university communities by emphasizing collaborative, interactive access to powerful hardware, which encouraged experimentation and resource sharing among students and faculty. It pioneered early systems, serving as a precursor to networked communication and facilitating the development of BITNET protocols on MTS, which connected academic institutions for file and message exchange starting in the early . This environment influenced applications, as the University of Michigan's MTS installation became an early node, supporting remote resource sharing that advanced networked experiments. Compared to contemporaries like Multics, MTS prioritized interactivity and simplicity, offering faster response times for terminal users on similar hardware, though it implemented less rigorous security mechanisms than Multics's hardware-enforced protections. As a bridge between batch-oriented systems and the era of personal computing, MTS's terminal-based multi-user model democratized access to mainframes, paving the way for the distributed, user-centric paradigms seen in later OSes.

Modern Preservation Efforts

Following the retirement of the last production MTS installation at Rensselaer Polytechnic Institute in June 1999, preservation efforts shifted to digital archiving and emulation to maintain access to the system for historical study. In 1999, as part of the shutdown process, digital tapes containing MTS , and data were created from the final operational environment, forming the basis for subsequent archives. These materials, including and binaries, were deposited at the University of Michigan's Deep Blue repository, where they remain accessible as scanned PDFs and digital files derived from original distribution tapes and late-1990s dumps. The Michigan Terminal System Archive, hosted at archive.michigan-terminal-system.org (now mirrored on archive.org), provides comprehensive mirrors of these resources, including full system distributions like MTS D6.0A, enabling researchers to download and restore the environment. Emulation has been central to revival initiatives since the early 2000s, with the open-source Hercules emulator emerging as the primary tool for running MTS on modern x86 PCs by simulating IBM System/360 and System/370 hardware, including peripherals like 3270 terminals and tape drives. Hercules, first supporting MTS in versions around 2000, allows full system operation without original mainframe hardware, and community ports have extended compatibility to platforms like Linux, Windows, and macOS. Variants based on the SIMH framework have also been adapted for partial MTS simulation, though Hercules remains the most complete for production-like demos. Post-2010 projects, such as the Try MTS initiative launched in 2014, provide online access via web-based 3270 terminals connected to emulated instances, allowing remote interaction without local setup. Source code for key components, including compilers like PL360 and utilities, is hosted on GitHub under Creative Commons Attribution 3.0, facilitating modifications and educational ports. In educational contexts, preserved MTS environments support courses on operating system history and concepts, with emulated instances used for hands-on demonstrations of practices. Preservation faces challenges from obsolete tape formats, such as the proprietary *FS (File System) structure on 9-track magnetic tapes, which require specialized decoding tools to extract data for modern storage. Ongoing development in emulators like involves bug fixes to improve accuracy, particularly for rare hardware interactions and behaviors unique to MTS. These efforts ensure that MTS's innovations in multi-programming and user interfaces remain verifiable through runnable artifacts.

References

  1. https://cse.engin.umich.edu/stories/cool-computing-midac-to-mts-to-caen
  2. http://www.bitsavers.org/pdf/univOfMichigan/mts/volumes/MTSVol01-TheMichiganTerminalSystem-Nov1991.pdf
  3. https://dl.acm.org/doi/abs/10.1145/1232909.1232910
  4. https://try-mts.com/why-try-mts/
  5. https://ieeexplore.ieee.org/document/1451785
  6. https://deepblue.lib.umich.edu/handle/2027.42/79598
  7. https://www.clock.org/~jss/work/mts/30years.html
  8. https://www.rose-hulman.edu/Class/se/csse442/200920/Lectures/Michigan-terminal-system.pdf
  9. https://deepblue.lib.umich.edu/bitstream/handle/2027.42/79598/MTSVol01-TheMichiganTerminalSystem-Nov1991.pdf?sequence=1&isAllowed=y
  10. https://timeline.it.umich.edu/accessible
  11. https://cse.engin.umich.edu/about/history/
  12. https://dl.acm.org/doi/10.1145/1478873.1478951
  13. https://multicians.org/thvv/360-67.html
  14. https://findingaids.lib.umich.edu/catalog/umich-bhl-9551
  15. https://www.eecis.udel.edu/~mills/gallery/gallery8.html
  16. https://dl.acm.org/doi/pdf/10.1145/1478873.1478951
  17. https://www.clock.org/~jss/work/mts/summary.html
  18. https://www.clock.org/~jss/work/mts/timeline.html
  19. https://ece.engin.umich.edu/wp-content/uploads/sites/4/2019/10/computing-history-converted.pdf
  20. http://bitsavers.org/pdf/univOfMichigan/mts/volumes/MTSVol01-TheMichiganTerminalSystem-Nov1991.pdf
  21. https://deepblue.lib.umich.edu/bitstream/handle/2027.42/79586/MTSBibliography-9Jan2011.pdf?sequence=1&isAllowed=y
  22. https://core.ac.uk/download/pdf/36708853.pdf
  23. https://deepblue.lib.umich.edu/bitstream/handle/2027.42/79628/MTSOperatorsManual-Feb1995.pdf?sequence=1&isAllowed=y
  24. https://archive.org/stream/computerworld1434unse/computerworld1434unse_djvu.txt
  25. https://dl.acm.org/doi/10.1145/850693.850694
  26. https://try-mts.com/programming-languages-in-mts/
  27. http://deepblue.lib.umich.edu/bitstream/handle/2027.42/79574/MTSVol09-SNOBOLInMTS-May1984.pdf
  28. https://try-mts.com/basic-introduction/
  29. https://catalog.hathitrust.org/Record/000184528
  30. https://bitsavers.org/pdf/univOfMichigan/mts/volumes/MTSVol06-FortranInMTS-Feb1988.pdf
  31. https://deepblue.lib.umich.edu/bitstream/handle/2027.42/79622/MTSVol14-360370AssemblersInMTS-Sep1986.pdf
  32. https://deepblue.lib.umich.edu/bitstream/handle/2027.42/79580/MTSVol07-PL1InMTS-Sep1985.pdf
  33. https://deepblue.lib.umich.edu/bitstream/handle/2027.42/79613/MTSVol18-TheMTSFileEditor-Feb1988.pdf?sequence=1&isAllowed=y
  34. https://deepblue.lib.umich.edu/bitstream/handle/2027.42/79612/MTSVol02-PublicFileDescriptions-May1990.pdf?sequence=1&isAllowed=y
  35. http://www.bitsavers.org/pdf/univOfMichigan/mts/volumes/MTSVol17-IntegratedGraphicsSystem-Dec1980.pdf
  36. http://bitsavers.informatik.uni-stuttgart.de/pdf/sdc/Rosenthal_-_Multi-Access_Computing_Modern_Research_and_Requirements_1974.pdf
  37. https://nvlpubs.nist.gov/nistpubs/Legacy/TN/nbstechnicalnote916.pdf
  38. https://ece.engin.umich.edu/stories/how-the-net-was-won-michigan-built-the-budding-internet
  39. https://ntrs.nasa.gov/api/citations/19740005767/downloads/19740005767.pdf
  40. http://homepages.cs.ncl.ac.uk/troy.astarte/res/pdf/360-MTS-handout-final.pdf
  41. https://deepblue.lib.umich.edu/bitstream/handle/2027.42/89588/README.txt?sequence=1&isAllowed=y
  42. https://www.nokia.com/bell-labs/about/dennis-m-ritchie/otherports/ibm.html
  43. http://www.ldx.ca/notes/mts-notes.html
  44. http://www.bitsavers.org/pdf/univOfMichigan/mts/volumes/
  45. https://deepblue.lib.umich.edu/bitstream/handle/2027.42/79575/MTSVol03-SystemSubroutineDescriptions-Sep1989.pdf?sequence=1&isAllowed=y
  46. https://deepblue.lib.umich.edu/bitstream/handle/2027.42/79582/MTSVol19-MagneticTapes-Oct1993.pdf?sequence=1&isAllowed=y
  47. https://deepblue.lib.umich.edu/handle/2027.42/89588
  48. https://timeline.it.umich.edu/node/1
  49. https://conservancy.umn.edu/bitstreams/15702b11-bf5e-409f-b647-77e5c7f092ed/download
  50. http://bitsavers.informatik.uni-stuttgart.de/bits/univOfMichigan/mts/mtsDistDoc/d6.0/D6.0-MTS-DOC.txt
  51. https://multicians.org/myths.html
  52. http://jklp.org/profession/papers/osdirect/paper.html
  53. https://ece.engin.umich.edu/wp-content/uploads/sites/4/2019/10/EECSNewsSS05.pdf
  54. https://babel.hathitrust.org/cgi/mb?a=listis%3Bc=937729558
  55. https://heritage.umich.edu/stories/how-the-net-was-won/
  56. https://deepblue.lib.umich.edu/bitstream/handle/2027.42/79579/r1039-BitnetOnMTS-Sep1990.pdf?sequence=1&isAllowed=y
  57. https://archive.org/details/michigan-terminal-system-distribution-documentation-and-files
  58. http://www.hercules-390.eu/hercfaq.html
  59. https://try-mts.com/get-up-and-running-with-mts/
  60. https://github.com/rupertl/mts-languages
Add your contribution
Related Hubs
User Avatar
No comments yet.