The Michigan Terminal System (MTS) was an IBM mainframe compatible operating system which came out of the University of Michigan in the early 1970s. MTS was developed and maintained by a consortium of universities around the world including (at various times): There was also a member in South America that I can't recall any details about other than that it may not have even been a university.

MTS was a command line oriented system which provided the usual facilities of a 1970's era operating system:

  • user ids and the ability the share files
  • a charge back system for resource allocation and cost recovery
  • a three level file system (i.e. public files, per-user private files and per-session temporary files)
  • compilers for a wide array of programming languages including Algol W, Algol 68, System/370 Assembler Language, FORTRAN, PL/I, PL360, Snobol, Spitbol and dozens more
  • a command line editor (enhanced with a vaguely vi-like capability in the late 70s) and other file manipulation tools
  • a printing and batch job spooling system (called HASP which, I seem to recall, was an acronym for something like "Houston Automatic Spooling Package")
The system's kernel was called UMMPS which was an abbreviation for "University of Michigan MultiProcessing System". It provided separate virtual memory spaces for individual sessions (i.e. each session ran in a private virtual memory space) and supported SMP-style hardware from as early as the mid-1970s.

The system supported both a batch (i.e. punched cards) and an interactive mode and had extensive support for the sorts of i/o devices that one found on a mainframe computer of the era: disks, tapes, card readers and punches, line printers, etc.

Users and user accounts

Users would apply to an appropriate authority to obtain a user id or user account. User ids were always four letters long although there was a convention which provided the illusion of shorter user ids - i.e. a ., a $. or a .$. at the end of a user id was optional in all contexts requiring a user id. This allowed the super-user account MTS. to be abbreviated as MTS and the (hypothetical) account DB$. to be abbreviated as DB. Passwords were twelve characters long and were stored using a one-way encryption (i.e. it was possible for a system administrator to change your password but it wasn't possible for them to discover your password).

Each user id belonged to exactly one group. This provided an administrative mechanism for managing accounts (i.e. each group had a group leader account which could perform certain administrative actions on an account) as well as providing a way to associate file access rights to groups of users.

User ids could own an arbitrary number of files although the total amount of disk space consumed by all files owned by a user id was settable by the id's group's group leader. Users could allow other users to access their files by changing their files' permission rights.

Users accessed the system via batch jobs (i.e. decks of punched cards) or interactive terminals. One would start a session by providing their user name (via a signon command) followed by their password. The session would be terminated by a signoff command or a physical or logical end-of-session (e.g. no more punch cards in the deck or the dropping of the terminal session's modem line). Each session could be used to run a single program at any given time (i.e. no background processes or pipelines or the like). With fairly minor exceptions, anything which was possible via a terminal session could also be done via a batch session with the obvious limitation that commands or programs requiring unpredictable input were impractical in batch sessions.

Although not apparent to most users, there were two quite special attributes which could be associated with a user id. A user id could be made "privileged" which gave it certain rights including the right to create public files and the right to create privileged programs (i.e. programs which didn't suffer from certain key limitations imposed on mere-mortal programs). A user id could also be made "rich" which meant that the id could never run out of computer dollars (i.e. it was allowed to sustain an arbitrarily large negative balance). A "rich" account was, by definition, also a "privileged" account.

In addition, there was one very special account called MTS. which was "rich" and had the ability to read or destroy any file on the system and the ability to change the file access rights on any file on the system. As I recall, MTS. didn't have the automatic ability to modify any file on the system although granting itself such rights was a very trivial operation.

The charging system

Users were charged for the resources that they used. In the early days, all resources were "paid for" from a single "fund" associated with each user id. The "money" used to pay for resources was little more than an allocation mechanism used to ensure that individual users didn't consume more than their fair share of resources (don't be fooled by the terms - when you ran out of "money", you weren't allowed to start new sessions with the result that the "money" felt very "real" to most users). Later on, certain consumable resources like pages of paper printed and such were "paid for" by a separate "hard funds" account. This allowed the institution running the system to have better control over the consumption of these "hard" resources while still allowing reasonably free access to "soft" resources like CPU time (again, "reasonably free access" was a VERY relative term).

As I recall, the resources which were charged for were:

  • CPU time (I recall a rate of $2,400 per CPU hour for Amdahl 470/V6 time in early 1976 at the University of Alberta)
  • CPU memory integral which was the amount of memory allocated by a program multiplied by the amount of CPU time used while the memory was allocated. i.e. a program which used ten seconds of CPU time while holding one megabyte of memory would pay the same as a program which used five seconds of CPU time while holding two megabytes of memory and would pay ten times as much as a program which used one second of CPU time while holding one megabyte of memory (my recollection was that a program using about one megabyte of memory would spend roughly the same amount of "money" on CPU time as it spent on memory).
  • file storage space (I seem to recall a rate of 4 cents per 4096 bytes of disk space per month)
  • pages printed (modified by the kind of paper and the quality of printer ribbon requested)
The rates depended upon what category of user one was (e.g. academic users paid about one tenth the amount that the, relatively rare, commercial users paid) and, except for file storage, depended upon when the session was started (e.g. daytime sessions were about 40% higher than evening sessions) or, in the case of batch jobs, the priority of the job (the priority of the job determined where the job landed in the queue of outstanding batch jobs).

Each user id had a maximum amount of computer dollars (i.e. "money") which it could spend and maintained an ongoing tally of the amount of "money" which had been used. Although one was allowed to stay signed on (the MTS equivalent to the Unix logged-on concept) to an interactive session if one ran out of money, batch sessions were terminated when the "money" ran out and one was not allowed to sign on (i.e. start a new session) if one was broke. The maximum "money" and file storage space available to a user id could be changed by the user's group's group leader account (which had a certain amount of "money" and file storage space available for allocation within the group).

When a session was terminated, various fields in the user id's account record showing the total resources used to date were updated and a session termination record was generated which recorded the amount of "money" spent during the session as well as other statistics (e.g. amount of CPU time, duration of the session, etc). At the end of each month, the entity responsible for the user id would receive a bill for the sum of the amounts in all the session termination records generated during that month.

The "money" amount which mattered in ultimate terms was the sum of the amounts in all session termination records whereas the "money" amount which mattered in the short term was the difference between the "used" field and the "maximum" field in the user id's account record. It was possible although rather unlikely that the sum of the amounts in the session termination records would be different than the amount in the user id's acount record's "used" field (this could happen as the result of an unfortunately timed system crash). In addition, since it was possible for someone to continue to spend "money" by remaining signed on after they'd run out of "money", it was theoretically possible for a user to commit their financial authority to pay a bill which was in excess of the amount that had been allocated to them.

One easter egg of sorts was that a session was totally free if the system crashed while you were still logged in. The probability of a system crash during any given day was quite low although one almost never sign off voluntarily if the system started to behave strangely as a crash might be imminent.

The MTS file system

From the user's perspective, the MTS file system was a simple three-level hierarchy with public files, private files and temporary files:
  • public files had names which started with an asterisk (e.g. *LIBRARY) and were, subject to the file permission mechanism, visible and accessible to all users
  • temporary files were associated with a particular signon session (i.e. login session in Unix terminology) and had names starting with a minus sign (e.g. -TMP)
  • private files were associated with a particular user and had names that didn't start with either an asterisk or a minus sign (e.g. MYPROG.F). Subject to file access rights (see below), one user could access another user's private files by pre-pending the other user's id followed by a colon to the file name (e.g. user FRED could access user ANNE's MYPROG.F file by referring to ANNE:MYPROG.F).
There was nothing even remotely similar to a Unix directory.

All files were line (i.e. record) oriented in the sense that data was read and/or written to a file in units of entire lines (compare this to the Unix file system which allows arbitrary bytes to be modified and doesn't really have the concept of a line at the kernel level). There were three kinds of files - sequential (SEQ), sequential with line number (SEQWL) and line (LINE) files. File space was allocated in pages of 4096 bytes. I seem to recall that the maximum size of a file was 32,767 pages for a maximum file size of about 134 million bytes. The largest file that I can recall working with was a sequential file which contained about 700,000 records (each record happened to be the same length - about 60 bytes as I recall).

A sequential file was just an ordered sequence of lines of variable length. One could append new lines on to the end of a sequential file, replace an existing line with another line of exactly the same length (if I recall correctly) or effectively empty the file and start over. In addition, one could ask the operating system for a marker for the current file location. This marker was a four byte integer which could be provided to the operating system later to "seek" back to the location that the marker was obtained for.

A sequential with line numbers file was equivalent to a sequential file except that each line had a line number associated with it. Frankly, I don't recall exactly why this file type existed and, if I recall correctly, it wasn't even supported by all institutions who ran MTS as it was never accepted back into the official releases maintained by the University of Michigan.

The most common type of file was a line file. A line file contained an ordered series of variable length lines or records. Existing lines could be replaced (with replacement lines of any length) and/or deleted and new lines of any length could be inserted anywhere in the file (subject to the constraint that every line must have a unique line number and line numbers had exactly three digits after the decimal - i.e. a line could be inserted between lines 10.122 and 10.124 but a line could not be inserted between lines 10.122 and 10.123). It was also possible to "renumber" a line file, a process which set the file's first line to be line number 1.000 and set the line number of every successive line to be 1.000 higher than the previous line. In the early days, the maximum length of a line or record in a line file was 255 bytes although this was later increased to 32767 bytes.

The line file structure allowed for a style of file editor which is simply unheard of today - the MTS file editor operated on (i.e. modified) the editted file in real time. If you changed a line in a file using the editor then the change was (almost?) immediately made to the actual file. It was not necessary or even possible to "open" a file and then later decide to either "save" or "discard" the changes (one could, of course, make a copy of the file and edit the copy if one wanted to make "experimental" changes to a file).

The kernel managed a mandatory file locking mechanism which operated at the file level (this is quite different from the advisory file locking mechanism found in Unix which operates at the byte or range of bytes level). One could lock a file for reading, for modification or for destruction. The system also distinguished between whether a file was open or not. The file locking mechanism was mandatory in the sense that it was simply not possible to:

  • read the contents of a file which one didn't have locked for reading
  • change the contents of a file which one didn't have locked for modification
  • change the permissions of a file which one didn't have locked for destruction
  • rename or destroy a file which was open by anyone else and which one didn't have locked for destruction
An attempt to access and/or manipulate a file in a way which required a more stringent lock than was already held would automatically result in a request for the appropriate lock. The operation would then proceed once (and if) the request succeeded.

The system provided complete deadlock detection within this file locking mechanism including using Warshall's algorithm when faster heuristic algorithms provided inconclusive results. A locking request which would result in a deadlock was simply refused.

Files had permissions or access rights associated with them. The categories of access rights were:

  • read (R) - the right to read the contents of the file
  • write-expand (WE) - the right to add data to the file but not to modify the existing contents of the file (i.e. add new records but not replace or delete existing records)
  • write-change (WC) - the right to change or delete existing data in the file but not to add new data to the file (i.e. delete or replace existing records but not add new records)
  • truncate (T) - the ability to remove unused space from the end of the file or to renumber the lines in the file
  • destroy (D) - the right to destroy or rename the file
  • permit (P) - the right to change the file's permissions or access rights
Commands which manipulated file permissions generally provided a few combination permissions like U (all rights), W (WC plus WE), RW (R plus W) and N (no rights). Newly created files were owned by the user who created them and had initial permissions of U for the owner and N for others.

A personal perspective

My first exposure to MTS was as a first year student at the University of Alberta in the fall of 1975 (using information provided in this writeup to compute my age might be a violation of the Official Secrets Act (grin)). At the time, the UofA was running MTS on an IBM System/360 model 67 with 256K of memory. I seem to recall that it was capable of supporting about 30 or so simultaneous users. As a mere first year student, I was only allowed to use the system via a student oriented batch facility called, strangely enough, SOBF. This facility allowed each batch run to use a maximum of 10 seconds of CPU time and 25 pages of paper and the charging was done on the basis of the number of jobs run (i.e. no CPU charging and such). SOBF users weren't allowed to create permanent files.

I can clearly recall writing programs using the IBM keypunches and then submitting the jobs into the SOBF queue by handing them to a human operator who would put a special white card on the front of the deck called an S-8 card (the longest job that I can recall writing as a first term student was about 1,000 cards including the input data). The job would eventually run and I would pickup the printout later. If the system was idle then "later" was "a minute or two". If the system was busy then "later" might be "a few hours". If the system was swamped, as it was towards the end of the term, then "later" was "tomorrow" or maybe "very late tonight" if "now" was "early morning"!

They took the system down on the first weekend in December, 1975 to replace the IBM 360/67 with a brand new IBM System/370 compatible Amdahl 470/V6 (the UofA got serial number 4 which was the second or third machine ever installed by Amdahl Corporation - NASA got the first machine as they were willing to pay full price whereas the University of Alberta was getting a discount for being a very early customer). The new Amdahl 470/V6 was up and running on the following Monday. It had two megabytes of memory (EIGHT times the size of the old 360/67) and had a CPU which was something like four or so times faster than the 360/67. Within a few days, the input/output room used for SOBF jobs had been re-organized. The printer had been moved so that print jobs landed directly on a table about ten feet from the card reader. It was simply not possible to submit a SOBF job (with the new limit of 2 seconds of CPU time) and then get to the printer table before your job was done printing!

Think about that for a moment - job turn around time had dropped from about twelve to fifteen hours down to a couple of SECONDS! It was, needless to say, a truly astounding experience which I've never had the pleasure of repeating.

In time, the 470/V6 became overloaded and was replaced by a 470/V7 and later a 470/V8 (there were also memory and i/o upgrades along the way). By the time that I graduated four years later, the University's MTS system was running on a 470/V8 with twelve megabytes of memory (compare this to the minimum memory requirements of many software tools or toys today). This system could support something like 300 simultaneous users.

After graduating from university and spending about 18 months in "industry", I returned to the University as a systems programmer for the MTS system working on the UMMPS kernel and other fairly low level bits (i.e. I was actually being PAID real money to do kernel hacking!!!!). While working as an MTS systems programmer, a "dream job" if there ever was one, I implemented a few of the changes required to make UMMPS support 16 megabytes of memory and then later more than 16 megabytes of memory (the University of Alberta's MTS system was, as far as I know, the first IBM-compatible mainframe in the world with 16MB and later the first with more than 16MB of main memory).

I later moved to the academic side of things as a lecturer but continued to use the MTS system until the mid-1980s.

Although "ancient" from today's perspective, it was a serious operating system which provided an excellent platform for students and others to do some very "real" things. It wasn't as capable or complex as IBM's operating systems (both a limitation and a feature in very real terms) but I certainly didn't find it to be particularily limiting in any substantial way.

In time, the advent of departmental minicomputers running Unix started to take users away from the MTS system and it simply couldn't compete in a world of Unix servers and personal computers on the desktop. As far as I know, the last MTS system was shutdown in the early to mid 1990s.

It was a strange feeling years later to buy an Apple Powerbook 540 with 12MB of memory (i.e. I now owned a personal computer with as much memory as the UofA's 300+ user mainframe had when I graduated). I had a similar strange feeling in 2008 when I upgraded my Mac Pro to 12G of memory and recalled that the UofA's mainframe had 12M of memory and roughly 12G of disk storage when I graduated roughly 25 years earlier!


References

This writeup is entirely based on personal recollections as a very intensive MTS user and sometimes UMMPS kernel hacker over a period of about ten years (1975 through to about 1985 or so).

Log in or registerto write something here or to contact authors.