Discussions‎ > ‎

MTS Conversations on e-mail, discussion lists, and blogs

E-mail list and discussion threads

  • Archive of e-mail sent to the list of "old MTS hands" (now mts-interest@umich.edu).
    • Announcements, news items, and updates related to MTS are sent to the group a few times a year.
    • If you would like to be added to or removed from the MTS-Interest e-mail group, send a note to mts-comments@umich.edu.
  • E-mail group: H390-MTS a Yahoo! Group to discuss MTS under Hercules, 2 January 2012 ...
  • E-mail group: Hercules-390 a Yahoo! Group to discuss the Hercules S/370 emulator on which some early MTS discussions took place.

October 2010: MTS Conversation on Hercules list

From: jeffsavit <jsavit@mail.com>

Date: October 19, 2010 11:26:59 AM EDT

To: hercules-390@yahoogroups.com

Subject: [hercules-390] Current status of MTS ?

Nostalgic war stories are a much more fun topic, IMO, so...

In my early years I ported the LISP/MTS interpreter from CP/67 to VM/370 (so it was MTS -> CP/67 -> VM/370) and I had to do things like substitute the named segment support it exploited (I eventually did an Evil Thing and loaded the VSE/VSAM shared segments read/write for the LISP call stack). Anyway, the interpreter was completely written in assembler, and the developer not only would use things like "OI *+5,X'00'" to change a branch, he would replace multiple instructions in a row on the fly... Was a devil to debug this code when the listing had only a partial resemblance to the code that was being executed!

cheers, Jeff


From: Mike Alexander <mta@umich.edu>

Date: October 19, 2010 12:32:01 PM EDT

To: hercules-390@yahoogroups.com

I'm curious which LISP interpreter that was. I'm sure it wasn't
UTILISP since I worked on that a lot and it didn't do anything like
that. Nor was it the Reduce LISP interpreter. This must have been
another one I've forgotten about. If I had seen any code like you
describe I would have had an unpleasant discussion with the author.
Maybe I did and it was so unpleasant I've repressed it. :-)

I also wonder if you've gotten two stories intertwined. Named address
spaces in MTS were read only and shared so it wouldn't work to put self
modifying code in them. Putting a stack in a shared segment doesn't
sound like a very good idea either.

Mike Alexander mta@umich.edu
Ann Arbor, MI PGP key ID: BEA343A6


From: rhtatum <rhtatum@windstream.net>

Date: October 19, 2010 2:45:07 PM EDT

To: hercules-390@yahoogroups.com

As a matter of historical interest, when was MTS doing these things (different storage keys for monitor, user code, data)? Mike wrote something called the elpar Moniter/OS circa 1970 that did just that - if you tried to write and execute self-modifying code or scribble o9n the monitor, you got got kicked off the machine immediately with a memory protect violation. About reentrant code - that's simple enough; why are folks so afraid of writing recursive routines? The old example of writing factorial n (N!) iteratively or recursively turns out to show just how badly IBM did things in PL/1 when one wanted to do recursion. I implemented Ackerman's function as an exercise just to see how simply things could be done. id a getmain for an unreakl amount of memory, used that for a stack. The computation part was 18 instructions, 48 (decimal) bytes; tried it on a 360/65 in IBM's South Road aba with a 3 minute run-time limit. Got the thing back with an indicated time of 8 minutes and desperate indications of the operators trying to stop the fool thing after big oz got its knickers in a knot. I've forgotten how far it got on A(5,5), somewhere on 3,5); did a little induction on what was the simplest purely recursive function known at the time (1968), saw that writing A(5,5) would have taken many, many reels of 2400ft/1600bpi tapes written as gapless stuff. Learned then to consider the consequences of supposedly bright ideas ...


From: Mike Alexander <mta@umich.edu>

Date: October 19, 2010 5:47:09 PM EDT

To: hercules-390@yahoogroups.com

--On October 19, 2010 1:45:07 PM -0500 <rhtatum@windstream.net>

> As a matter of historical interest, when was MTS doing these things …

MTS started using storage keys for protecting shared memory around 1966
or 1967. As time went on much more sophisticated protection mechanisms
were developed to guard against accidentally or intentional damage to
the system and storage keys became much less relevant. There is a
paper [1] that describes the state of the world circa 1977. This
predates Named Address Spaces and a number of other protection related
changes. There's a lot of information about MTS on Wikipedia ([2] and
[3]). There's even a 41 year old picture of me there!

> […] why are folks so afraid of writing recursive routines?

Reentrant and recursive are not all that closely related. Code can be
one without being the other. Writing reentrant code isn't difficult if
you start that way from the beginning. Retrofitting code to be
reentrant after the fact is often much more difficult.


[1] Pirkola, Gary C., and Sanguinetti, John, "The Protection of
Information in a General Purpose Time-Sharing Environment", In IEEE
Symposium, Trends and Applications 1977: Computer Security and
Integrity, Proceedings, pp. 106-114. Available at

[2] <http://en.wikipedia.org/wiki/Michigan_Terminal_System>

[3] <http://en.wikipedia.org/wiki/MTS_system_architecture>


From: Robert Hodge <quatras.design@yahoo.com>

Date: October 19, 2010 7:40:34 PM EDT

To: hercules-390@yahoogroups.com

With all this talk about MTS, is there any way someone could get a copy of MTS
and run it under Hercules? I read the wiki's you mention below and it brings
back a lot of memories.  I used to use MTS at Wayne State University for a
number of years.  It wasn't perfect, but it did a lot of things right, and many
external companies paid the universities for accounts to run MTS thru dial-up
modems.  It was mostly a lot of fun, for those days.


From: rhtatum <rhtatum@windstream.net>

Date: October 19, 2010 10:33:40 PM EDT

To: hercules-390@yahoogroups.com

No, MTS probably won't run under Hercules - I looked up MTS using a google search, and it seems that there was an additional operation code that the folks that created MTS either did themselves or had IBM implement for switching between pieces of MTS, user programs, etc. Someone would have to write the simulation code for that op-code for MTS to run under Hercules-390. Other than that, machine operation codes are machine operation codes, and if a program/operating system/whatever runs on the "real iron", it will run under Hercules.

The history of TSS/360 and MTS is interesting - first IBM would support them, then they wouldn't, then they would, then they wouldn't. When they figured/found out that there were folks that were paying money to use the stuff, they decided it was a good idea.

I still wonder just how much money it cost IBM to make their floating-point stuff on the original S/360 work properly - any applied mathematician could have told them that one first normalizes all the results in a computation, then truncates the final result, not the other way around. The very idea of adding two positive, non-zero numbers and having the sum be less than either summand was bizarre, as a bunch of folks of Stanford pointed out, rather vigorously, back around 1966/67. I've heard anywhere from a few mil to around $25M, since they not only had to mod machines being built, but also all those out in the field.

I don't think IBM internally was all that coordinated - I was on contract to IBM in Poughkeepsie in 1969 and had to use a 360/40 for some weird MIS (Manufacturing Information System) they wanted a bunch of coders to build, and just out of curiosity, I tried out the floating-point instructions the machine had. Son-of-a-gun! The hardware hadn't been fixed. I asked the Customer Engineer assigned to keep the machine running about that, and he replied that he didn't even know that the machine had floating-point hardware on it! Wonderful, amazing, fantastic, ...


From: Mike Alexander <mta@umich.edu>

Date: October 19, 2010 10:50:44 PM EDT

To: hercules-390@yahoogroups.com

--On October 19, 2010 9:33:40 PM -0500 rhtatum <rhtatum@windstream.net>

> No, MTS probably won't run under Hercules […]

MTS runs fine under Hercules. I run it that way frequently and it
works quite well. I had some problems with printer support which were
discussed on this list, but they have been fixed. I don't know what
opcode you're thinking of, but there's nothing MTS requires that isn't
part of the standard implementation of XA architecture. There were a
few extra opcodes on the 360/67, but that's ancient history and none of
them were required. Do you have a URL for the page that made you think
it required non-standard opcodes?

> The history of TSS/360 and MTS is interesting […]

This is a bit misleading. What you say of TSS is more or less correct.
However IBM never supported MTS in any way whatsoever. In fact they
tried to kill it off but didn't manage to do so. Given IBM's attitude
toward MTS it's surprising so many places ran it.

... snip ...

> From: Robert Hodge
> With all this talk about MTS, is there any way someone could get a
> copy of MTS and run it under Hercules?

Right now it's not generally available, but we're working on that.
We'd really like to make it available but there are some issues to be
worked out.

Wayne State, in particular, sold a lot of MTS services externally.
Michigan did some of this also. For example, for many years all the
EPA auto emission test data were processed on MTS (the lab that does
that work is in Ann Arbor).

Mike Alexander mta@umich.edu
Ann Arbor, MI PGP key ID: BEA343A6


From: rhtatum <rhtatum@windstream.net>

Date: October 19, 2010 11:14:20 PM EDT

To: hercules-390@yahoogroups.com

No URL pops into my mind, I just did a Google search for MTS and found it - according to the thing I found, there was a shortcoming for such systems as TSS and MTS, an instruction was added and the resulting S/360 with the additional op-code became the S/360 Model 67 (and a bunch of other stuff happened) and the capability gained was incorporated in S/370, so naturally one would find that X has it.


From: Mike Schwab <Mike.A.Schwab@gmail.com>

Date: October 20, 2010 1:56:48 AM EDT

To: hercules-390@yahoogroups.com

Probably virtual storage (loading the translations tables)? Wasn't on
the first S/370s but quickly became standard and addable to prior

Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?


From: Dave <dave.g4ugm@gmail.com>

Date: October 20, 2010 2:48:43 AM EDT

To: hercules-390@yahoogroups.com

MTS has used Virtual Memory since the start and therefore originally in only
ran on the 360/67 (and possibly the 47) with the Virtual Memory feature.
Later versions were modified to run on 370 DAT. I remember when the S/370
arrived at NUMAC (Newcastle Universities Multiple Access Computers), which I
used from Newcastle Polys 1130 as an RJE box the newsletter said some thing
like "only a few instructions were altered".

As you correctly surmise Hercules does not emulate the 360/67 so the
original MTS won't run on Herc but as others have said later versions should
run fine. Now all I need to do is figure out what sort of Educational
Instate I need to found to get a copy....

Dave Wade


From: Peter <peter_flass@yahoo.com>

Date: October 20, 2010 8:28:35 AM EDT

To: hercules-390@yahoogroups.com

How about a foundation whose aim is to educate people about MTS?


From: Gavin Eadie <gavineadie@mac.com>

Date: October 20, 2010 8:39:21 AM EDT

To: hercules-390@yahoogroups.com

On Oct 20, 2010, at 2:48 AM, Dave wrote:

> I remember when the S/370 arrived at NUMAC […]

... I arrived at Durham University to support MTS in the same timeframe as the S/370 arrived in Newcastle (in fact my salary was, at least in part, paid from the "NUMAC money"). Small world!!

I'd forgotten the Newcastle Poly connection; we should make a note in the new MTS Wikipedia entry.

> As you correctly surmise Hercules does not emulate the 360/67 […]

... There are impediments to making MTS available. They are not insurmountable and there are at least three of us (retired MTS systems programmers) working on clearing them. (1) we want to be certain that the University of Michigan has no claims to intellectual property -- since MTS was originally distributed with little palaver this is not a concern, though we would like the university to be as active in their support of this as MIT was of doing the same for Multics. (2) while we could distribute a 'turn-key' CD (boot and run), we'd like to distribute MTS in the same spirit as we used to (everything needed to re-compile/assemble everything), and that capability is dependent on some licensed third party products we would like permission to include. (3) the latest (and most functional) version of MTS that we could ship is a DVD image that contains some personal information in those old files -- we need to sanitize those. (4) the access MTS had to the Internet was dependent on hardware developed at UBC and we would like to emulate that interface in Hercules sufficiently well to allow anything we ship to also have Internet access. There may be a few other lesser concerns but of the above (3) is the only 'show-stopper' today, (1) is important, (2) is a strong preference, and (4) is highly desirable.

Much improved Wikipedia entry: http://en.wikipedia.org/wiki/Michigan_Terminal_System

I wrote the brief: http://archive.michigan-terminal-system.org/discussions/mts-today/mtsandhercules

January 2012: An account of how MTS became publicly available, posted to the H390-MTS e-mail group

On Jan 8, 2012, at 11:44 AM, Jeff Ogden wrote:
. . . If you are interested, there is an account of what UBC went through back in 1968 when they became the first site after Michigan to install MTS.  See:  http://archive.michigan-terminal-system.org/discussions/how-did-sites-learn-about-and-make-the-decision-to-use-mts/2ubc. . . .


On Jan 8, 2012, at 8:12 PM, Tom Jacobsen wrote:
Reading this made me curious about the history of events behind  the decision to release MTS to the Hercules community. Most organizations these days are not very interested in releasing their intellectual property in this way.   It would be interesting to hear the story of the person(s) who convinced upper administration to allow for this to be released. (whoever it was, thank you!).  Perhaps this story can be added to the discussion section of the archive site where the UBC article is.


From: Jeff Ogden
Subject: Re: [H390-MTS] I am missing something [or an account of how MTS became publicly available, posted to the H390-MTS e-mail group]
Date: January 25, 2012 5:08:28 PM EST
To: H390-MTS@yahoogroups.com

I'm not sure how much of a story there is to tell. It took a bit of time, but making MTS available was remarkably uncontroversial.

The University of Michigan stopped offering its MTS service to end users at the end of June 1996. Some of the other MTS sites had stopped earlier and some later. RPI was the last and stopped in 1999, but had been phasing MTS out for several years prior to that. See:

* RPI MTS Termination memo, June 1998 at http://archive.michigan-terminal-system.org/documentation/documents/MTSShutdownAtRPI-June1998.pdf

* "Dropping the Mainframe Without Crushing the Users: Mainframe to Distributed UNIX in Nine Months", Paper presented at LISA VI: 6th Large Installation Systems Administration Conference, Long Beach, California, USA, October 1992 at   http://citeseerx.ist.psu.edu/viewdoc/download?doi=

MTS continued to run occasionally on the IBM mainframe at U-M for internal use for a time, about a year I think, but that was over by mid-year 1997.  Some U-M units ran MTS on emulators such as FLEX-ES and possibly others, mostly to get access to archived materials on magnetic tape. This use was pretty informal from the start and became more informal as time passed.  Mike Alexander was instrumental in taking steps to preserve the MTS  distribution tapes and Tom Valerio did much/most/all of the work to preserve the 1996 version of the system and to get it running on emulators. Steve Burling was involved in some of this too, but I'm not clear on exactly who did what or when.

I'm not sure who was the first to run MTS under Hercules.  Probably Mike or Tom. I know I got a copy to run from Gavin Eadie early in 2005. Most everyone still had day jobs at this point.

I noticed that there was quite a lot of information about MTS available online, but that the information was incomplete and some of it was at least slightly wrong.  The MTS Wikipedia article in 2009 included this plea toward the end of the article:
     This operating system-related article is a stub. You can help Wikipedia by expanding it.

So I started to update the MTS article, which lead to writing a couple of new and updating other Wikipedia articles. I was asking Mike, Tom, and others for help remembering what was done when.  I ended up renewing contact with folks from several other MTS sites in the U.S., Canada, and the UK that I hadn't been in touch with for 15 or 20 years, which was fun.

As time passed some of us retired.

I was coming across more and more material that for one reason or another wasn't appropriate for Wikipedia. And so in the fall of 2010 after consulting with Mike and Gavin, I registered the domain name, created the MTS Archive web site at archive.michigan-terminal-system.org, and began using the site as a place to gather this information. The hope/plan was and remains to find other more institutional homes for the materials so they are more likely to have a longer term future than an individual or group of individuals can guarantee.

In June 2010 Mike, Tom, Gavin, and I got in contact with the staff of the University of Michigan's Bentley Historical Library here in Ann Arbor. The Bentley already had on deposit materials related to computing and connectivity including materials on MTS that they had received from many sources (from Aaron Finerman the 2nd Director of U-M's academic Computing Center, Bernie Galler a professor of Computer Science and a long time Associate Director at the CC, Mike Alexander, and many others). Pretty much all of this material consisted of physical objects stored in bankers boxes on shelves in the stacks at the Bentley. Very little or none of it was online.  When we met with the folks at the Bentley we were interested in making more MTS materials available and, if possible, at least some of them online. The Bentley staff were very receptive and offered to make the materials available via the U-M's Deep Blue digital archive. Mike converted many of the MTS manuals into the PDF/A format that archivists like and this and other material was given to the Bentley on DVDs.

We also worked with Al at Bitsavers.org. Bitsavers already had some materials related to MTS, but in January 2011 Al was kind enough to accept many more PDF documents. And by March 2011 the Bentley had deposited the PDFs in Deep Blue.

I also worked with the staff at the U-M Library to have over 250 MTS related documents that had been scanned by Google and were available in the Hathi Trust Digital Library switched from "limited search only" to "full view" access. The Associate Director of the Library was kind enough to authorize me to request the switch for materials that had been produced by the U-M's Computing Center, where I had been Senior Associate Director.

Over the years there had been talk of and speculation about what it would take to make a run-able version of MTS more widely available. Some of those discussions were private, but some took place on the Hercules-390 e-mail list. On July 1, 2010 Gavin and I had lunch with Marvin Parnes, U-M's Associate Vice President for Research (the Computing Center reported to the VP for Research until the U-M created the Information technology Division in the 1980s). Gavin and I have known Marvin for a long time and had worked with him to make network connected personal computers available in U-M's student housing (they don't like to call them dorms) in the days before Marvin moved to the VP for Research's Office. At our first meeting, Marvin was very supportive of helping to make MTS, including a runnable version, more widely available. He asked me to write down what we wanted to do. 

It took me longer to get that done than it should have, but I got something written and over to Marvin in early 2011.  Marvin got Jack Bernard, U-M's Associate General Counsel involved. Jack had a history with the Information Technology Division from the time before he went to law school.  He, like pretty much everyone else we've approached, was very supportive. It was Jack who suggested using the Creative Commons Attribution License (CC-BY) and referred me to an expert on the CC licenses at the U-M Library who encouraged us to avoid the NonCommercial (NC) and ShareAlike (SA) provisions of the license, which we did and Jack approved. Marvin also checked with the U-M's CIO, Laura Patterson, and with the U-M's Associate Vice President for Research CyberInfrastructure, Dan Atkins, and they were both supportive. It took until July 2011 for Marvin and Jack to write a joint letter making this an official project of the Office of the Vice President for Research in association with the Office of the General Counsel and giving permission to make MTS available. There was never any problem along the way, but Marvin and Jack are busy people and it was hard to argue that resurrecting a time-sharing operating system that the University hadn't been using for 15 years should be a high priority.

Once we had official permission, it took us until November 2011 to send several .tar.gz archives to Al at Bitsavers. Al made the MTS distribution materials available on December 22, 2011.  The MTS distribution materials were added to U-M's Deep Blue digital archive on January 8, 2012.  And the rest, as they say, is history.

While it took a long time to make the MTS materials available, there was never any opposition to doing so. In fact there was often enthusiastic support. I'm not sure why this was so. Perhaps because the University of Michigan and the other sites that developed and used MTS are all academic rather than for-profit commercial organizations. Perhaps because these sites stopped using MTS many years ago. Perhaps because U-M used MTS for 29 years and people were proud of what had been accomplished and were happy to see that history preserved. Perhaps because many of the people involved in making the decisions knew one another and were friends. Or perhaps some combination of all of this.

I would encourage others who were involved to add their views and to make corrections to my account.  As Tom Jacobsen suggested, I will eventually make this or an edited version of this available on the MTS Archive site.



On Jan 25, 2012, at 6:26 PM, Dave wrote:

You and Mike endured much nagging from myself, and mild encouragement from others. Did this help or hinder


On Jan 25, 2012, at 7:05 PM, Jeff Ogden wrote:

I wasn't on the Hercules list until very recently, so you weren't nagging me directly.  I suspect that it was Mike and Gavin and perhaps Tom you are thinking of.  They should answer for themselves.

I do remember that before we had approached anyone at U-M and we were still uncertain what sort of reaction we might receive, we wanted to keep things somewhat lower profile. We didn't feel comfortable describing our hopes in detail on a public list since we didn't want to promise more than we could deliver. And we certainly didn't want word getting back to anyone at U-M that we were talking about giving their property away without checking with them first. At the same time there was some discomfort with being less than completely forthcoming about what we hoped to do.

When we did start talking with "officials" at U-M, we were able to say that we knew that there was at least some "hobbyist" interest in running a version of MTS. So that was helpful.


The World Is Not Flat, posted by Platypus Reloaded, 29 December 2013 on the Gluster Community blog

from http://www.gluster.org/2013/12/the-world-is-not-flat/

Way back when I was a young pup, either in college or after that but before I started my career, I got to use an operating system called MTS. That stands for Michigan Terminal System. It was created to run on IBM (and later Amdahl) mainframes, when U of M got tired of waiting for IBM to deliver a multi-user operating system. Like most code that old, it was an interesting combination of ideas that have since been abandoned because they were stupid, ideas that were ahead of their time, and ideas that were somewhere in between. Here are some of the more interesting ideas.

  • The filesystem had a feature to include the entire contents of one file at a specific point within another. Who needs symbolic links when you can just create a file containing a single %include directive? Why would programming languages have to synthesize this behavior in a bazillion subtly different ways if the basic functionality existed natively in the OS? Yeah, I know, record-oriented filesystems (basically a prerequisite for this) lost out to simple byte-streams for many good reasons, but every victory comes at a cost.

  • MTS had a very robust ACL system, which allowed you to control access by user, group, or "pkey" (i.e. what program was running). Much better than set-uid in my opinion.

While I was still using MTS, they added a macro system - what we would now think of as a shell scripting language. One of the very first uses of this macro system was to sythesize a hierarchical directory structure on top of the flat one native to MTS. I really wish I could remember the name of the author, to give credit. He was a Computing Center consultant, and this would have been in 1985 or so, if anybody wants to help me out. It was a pretty slick combination of naming conventions and macros, and I think it made many users' lives easier.

The reason I started thinking about MTS is that I see people doing the exact same things now - nearly thirty years later - to simulate a hierarchical namespace on top of the flat one provided by most object stores. Let me repeat something I've said many times before, in many ways: flat namespaces weren't just crap in DOS, they were crap in MTS even before that and they're still crap today. Crap, I say. Anybody who implements a supposedly modern file/object store with a flat namespace is simply screwing their users to suit their own convenience. The scalability arguments don't hold water, because the scalability issues mostly have to do with the operations that you have to support (e.g. atomic rename) than with whether or not you have nested directories. This is something that has to be built into the data store, with the necessary recursive name resolution done one place one time by people who understand that data store, instead of being done ten incompatible ways by ten different outsiders. Even quite smart people can trip when they try to bolt on a hierarchical structure after the fact.

Users have shown over and over again that they want flexibility to organize and reorganize their data, in ways richer than a flat or even single-level hierarchy will allow. Maybe there's an even better way, but so far none of the attempts to replace nested directories with tags or links or database-like queries seem to have gained much traction. Until someone comes up with something better, the nested-directory structure should be considered a minimum standard for anything that's supposed to replace the traditional filesystem.


A comment posted by dlambrig on 1 January 2014:

My school used MTS. The mainframes hosting MTS were housed under a church. The school had refurbished the church into a computer lab. Those mainframes generated enough heat to keep the entire building warm in the winter. MTS lasted roughly from 1976-1995. In the beginning it was hailed as a timesharing system superior to rivals (TSO etc.). Apparently IBM was very upset MTS was chosen and warned administrators that graduates would “not have the right skills”. By the late 80s the computer science department was in open rebellion with IT to replace it with UNIX.

April 2015: Michigan Terminal System Archive item on Hacker News

from https://news.ycombinator.com/item?id=9401124 on 19 April 2015

JeffOgden 16 minutes ago

You can run MTS yourself today using Hercules under Windows, Mac OS X, or Unix. See: http://archive.michigan-terminal-system.org/

notacoward 31 minutes ago

I have fond memories of MTS. While it was clunky in many ways, it was generally adequate and occasionally turned out to have features more advanced than contemporaries. For example, the ability to limit access to a file by "program key" (PKEY) as well as by user/project was a far superior alternative to setuid. (I learned about this in 1985 or so; not sure when the feature appeared.)

Ah, the good old days. Perusing the previous user's history on an Ontel terminal, chatting through MERIT concentrators, and good old MTS. I don't miss the punch cards of my first year, though.

I spent 3/4 of my Undergraduate life on MTS, and Forum was basic the social hub of a large chunk of nerdy students (myself included). The fact that that MTS VT100 and IBM terminals were all over the place (Literally Terminals - great, big 20 pound CRT monstrosities that had been in place for 10+ years) - meant you could login for just a few minutes anywhere on campus - kind of a precursor to todays mobility (as long as you were on campus).

Being able to print your big 500 page print job on the Central Laser Printer, and having it wait for you in your output box (I was XGEC), was also pretty awesome - and it provided 24x7 jobs for the people working in the Computing Center.

It's kind of a shame that I never really used/learned the system the same way I did with Unix - I really treated it like a large BBS environment, that I could also do some programming homework on.

But, time moved on, and by 1992/1993, MTS was starting to show it's age, and our researchers and faculty were becoming increasingly annoyed at the "IT Managers" who literally refused to take direction - as though the system was run for their* benefit, instead of the campus benefit.

So, in a day remembered as Bloody Tuesday at SFU - the entire Sr. Management team was publicly terminated, and the remaining employees were told they had exactly one year to replace all of the MTS (and IBM 3090 (3081?) system with Unix systems and NFS file storage.

One year later, we entered the brave world of Unix - which, while I have fond memories of MTS, was a far, far better system to prepare undergraduates for the world that awaited them.

I used the MTS system at the University of Alberta as an Engineering undergraduate in the 1980s. At the beginning of the year, you were budgeted a certain number of CPU seconds which you couldn't exceed. We were VERY careful about not accidentally coding infinite loops. There was a room full of VT100 terminals that we used, but if you needed hard copy, you had to trudge across campus to the building where the burst printer lived.

MTS is historically very important. The original version, for the IBM 360/67, was the first OS to support virtual machines. The 360/67 was the first machine with protection hardware to support a hypervisor. All IBM S/370s and later got that hardware because MTS proved its usefulness.

IBM got hypervisors right. You could run another copy of the OS under itself. The virtual machine looks just like the real machine to a program. And yes, it nests; VM under VM under VM... is possible.

Pretty legendary system at the University of Michigan. The old timers still talk about all the time.

Hmm, as I recall, about half of my programming classes required me to write programs to run on MTS. 'Course, we studied IBM mainframe assembly language in one class...

In my time there, I knew sysadmins who retrocomputed MTS in VMs for fun.