GSFC is NASA's Goddard Space Flight Center in Greenbelt, Maryland, USA. GSFC used MTS for a year and a half starting in 1984 and ending in the early fall of 1985.
A separate proposal to run MTS to run CONFER at a NASA site on the west coast was not funded.
From: Jordan Alpert
Date: December 1, 2010 5:04:07 PM EST
To: Gavin Eadie, Jordan Alpert
Subject: Re: Historical computer operating systems query ...
It is true. I was an advocate of MTS and saw it as an Operating System that could handle as you say "...problems that weren't being solved anywhere else." As a student at UM in the Department of Atmospheric and Oceanic Science I was able to use MTS in my work, and using it taught me very much about scientific computing. I was not a part of the core "MTS community", although I knew some members, as my day job in atmospheric science took all my time. Introduced to MTS in 1972 at UM was exciting: "MTS let ordinary people do routine things easily" and "MTS provided a venue for sharing information and ideas in such a way that it helped students, faculty, and researchers to achieve their own goals. "
After graduating (Phd) from UM in 1978, I spent two years as a Post Doc and then began work in 1980, at a NASA/Godard Space Flight Center atmospheric modeling group where there was a computing environment of IBM-JCL/TSO, and I became an advocate for improving the operating system with MTS. I wrote a proposal/plan that was funded in 1984 to purchase the MTS license ($10,000.00) and some travel for training (I had the Bodwin's come in for a visit or two) and we launched MTS on an IBM 4341 computer at NASA/GSFC used during the day for an aging satellite project that was ending. My goal was to have MTS run for scientific computing and solve the computing resource problem we (and all scientists) had as well as software tools and was naive enough to think that proof of concept was enough. MTS was allowed to run between the hours of 5PM-5AM. I booted it up myself. The user base was about a dozen scientists who would run VAX/VMS during the day, and the MTS-4341 at night. I included H assembler and Fortran in the software complement.
Beside scientist interest, solutions to data/model manipulation, visualization and command line interface, I made the case that our MTS configuration showed that our computer centers could be more resource/cost efficient, eg., two operators were not necessary to boot the system as required for the IBM-JCL even with "IBM assists", and tape mounts could be done by the scientists themselves after learning to physically mount the tape drive once they were taught to type into the console the "t 4" (I think) to set the mount. That is, the computer could be run unattended! The disk space would be used more efficiently under MTS since without compaction costs, due to unreleased records in IBM-JCL, MTS allocation on disk partitions utilized over 90% of the space, that is, FDR compactor did not have to be run as in IBM-JCL partitions which added to the IBM-JCL system maintenance (down) time and causing only a 1/3 utilization of (the reality of) disk space under IBM-JCL, and MTS brought an almost 3X increase in the available disk storage, all important items for scientific computing.
While MTS was a great success with the scientists who now had an improved "Unix" (was not a word back then) or "VAX/VMS type OS interface, and better resource utilization, software programs and cost effectiveness, it did not sit well with the IBM system administrator staff [contractors who ran NASA's IBM systems, not NASA or IBM staff] who argued that: 1) If they worked with MTS they would not be allowed to work in other IBM shops (They threatened to resign en masse if MTS was adopted by GSFC), thus ending their careers, and the daily error fix bulletins from JCL/TSO would not come from IBM, but what they meant was that MTS was not a viable OS. They also used the argument that MTS was not used in enough places to have a large enough base to carry it out to the future.
Still the MTS project went on for a year and a half [1984 to ~September 1985] at GSFC and was shut down by the IBM systems staff the day I left to start a 25 year, so far, career at the weather service.
. . .
From: Jordan Alpert
Date: December 8, 2010 2:15:04 PM EST
To: Jeff Ogden
Cc: Gavin Eadie
Subject: Re: Historical computer operating systems query ...
Jeff and Gavin;
> I'd like to place some parts of your note into the MTS Archive, but want to check with
> you to be sure that that is OK.
You may use it as you wish.
> It sounds as if MTS was in use at GSFC from sometime in 1984 until sometime in 1985
> or perhaps 1986. Is that correct?
Its use ended (close to) in September 1985.
> There was a rumor that NSAS wanted to run MTS so they could run CONFER, but it sounds
> as if that isn't true or at least not at NASA/GSFC.
CONFER did not figure into the equation at NASA/GSFC. I once spoke with a fellow at Hewlett-Packard who (said he) ran MTS (only) for this (Mail using CONFER) purpose.
> And the IBM systems staff that were so uneasy with and opposed to MTS were GSFC
> staff and not IBM staff. Is that correct?
I believe in this case that the "IBM" staff was under contract, not civil service and did not work for IBM company. That is, GFSC proposed to companies with 3 or 4 letter acronyms, and the companies hire staff in conjunction with a civil service manager defined needs. The arbitrators or administration I needed to convince were civil service.
For a while, when MTS was running at GSFC, I had this notion to improve scientific computing for the center, and although I championed the way MTS set up the disk system and saved dollars, I was most interested in ease of use and control for users: MTS command language with its editor that had decimal line numbering (attached to the line) and full screen mode and (controllable) graphical output terminals, a consistent method of executing code which was consistent across system programs and user programs, with device independence was way ahead of its time and could be found nowhere else. So users could interactively or in batch type "run *ftn ..." on code, and save the executable and place source code in the negative line numbers (not often) and then run myexec 5=control 60=*J* 8=*print*.
Here is some more: I finished my thesis in 1978 and writing it during the previous year I used the editor control file to create a (early) spell check by making a list of each word I spelled wrong changed to right and applied the growing list to each subsequent chapter. I was able to dump the text to the fan fold printer for checking often, saving 8x11 costs, and used the editing program ED and formatting (*format? I forget the name) to have the thesis typed on a Selectric typewriter (had a ball typehead) terminal for the final copy. Lucky for me the ban on digital typed thesis was lifted about a month before I submitted mine and the infamous old lady in Rackham [UM's graduate school], after doing the well known but feared ruler test (on every page) on margins said my typing job was the best she had ever seen. I did not tell her that MTS typed it.
Another important aspect of MTS was that it kept accounting. It made users conserve resources and take care with their runs and management of resources remains a free for all for the clever. We who had soft (meaning hard) money computer resources would set up and test our work in advance on MTS in an environment where we mimicked the National Center for Atmospheric Research (NCAR) environment of large core memory and disk calls from fortran so we could save time on our trips to Boulder to run the "fast" but free CDC7600, including binary calls to the primitive read functions for faster I/O. Jim Sterken had something to do with that. I recall setting disk location pointers in the disk system (6 integers) to later manipulate my own disk to memory data swap with separately controlled read and write pointers (was it also asynchronous) done with a combination of system calls from fortran.
I also should say something about the relationship of the system group at UM and the users. I have not come across the proactive response and cooperation between users and systems that was at MTS in other universities or government since. From compiler problems to new software commands MTS was always responsive.
It has been fun thinking about this. I truly thought that MTS should have been the OS of choice on IBM mainframes and the system that could power personal computing (Then I thought one would need at least a basement to hold such).
On Dec 2, 2010, at 1:58 PM PST, Jim Bodwin wrote (among other things):
I was also involved in the NASA Goddard install. I thought that they were running it for code development purposes. I think that Jordon [Alpert] wound up leaving shortly after the install - before it really got used for anything. One thing I remember is that the operators for the machine were less than friendly. MTS was being run at certain times of the day and the rest of the time the machine was used to crunch data from some beyond-its-expected-lifetime satellite. They were contractors to NASA and if the MTS install was enough of a success that it took over the whole machine then they would loose their jobs.
On Dec 2, 2010, at 8:35 PM, DLBodwin wrote (among other things):
I did go to NASA Goddard and did the install with Jim.
On Nov 17, 2010, at 1:59 PM, Bob Parnes wrote:
I submitted a proposal to have it [MTS and CONFER] installed at NASA (somewhere in California but I can’t remember where now), but it didn’t get funded.