From: iczer@gnu.ai.mit.edu (Ted Uhlemann)
Newsgroups: alt.folklore.computers
Subject: _The Last Mainframe_: The demise of MULTICS at Oakland.edu
Date: 1 Feb 1994 22:36:12 GMT

[ Posting this for the author, who is currently unavailable - iczer@gnu ]

[ I very nearly forgot to post this today.  Only after the phone rang
at 2:00 AM with a call from one of my friends in Northern California
that forgot about the time zone difference, did I realize what we did
today, and I remembered that I wrote this file last week.

Today (1/29/93), at about 3:30 PM, we shut off Multics for the last
time.  The computer room in 220 Dodge Hall is a lot quieter now, the
university is consuming less electricity, and we've got a collection
of hulking blue and black boxes that represent the university's last
mainframe and 14 years of computing history.  The machine will be
physically moved out of the computer room next week, on its way to
become replacement parts for other Multics installations that are
still operating in the world.

-- Jeff ]


	     The Demise of Oakland's Last True Mainframe:
			The Honeywell Multics


			   Jeff Marraccini
		 Sr. Computing Resource Administrator
			  Oakland University
			   January 18, 1993


Near the end of this month, Oakland University's Office of Computer
and Information Services, my employer, plans to remove the Honeywell
Multics system, previously Oakland University's primary academic
computer.  The Multics was 14 years old, one of the oldest
still-operating computers on campus, providing services to thousands
of Oakland University students, faculty, staff, and friends while
it was in use.

The Multics was a true mainframe.  It contained a considerable amount
of processing and I/O resources for a computer designed in the late
1960's, as well as a number of truly unique features that
distinguished (and continue to distinguish) it well apart from the
typical mainframe environment used at other institutions at the time
of its peak utility (the IBM 370 series.)  The Multics featured a
microcode-level protection system that provided the operating system
with the ability to protect user programs from conflicting with each
other, system resources, critical system tasks, and programs that were
assigned higher security levels in the system.  These features made
the Multics popular in the military and in other organizations where
data security was critical.  The Multics was one of the few mainframe
systems that provided such protection at nearly all levels of the
system.

Oakland used its Multics system for a number of purposes.  Computer
programming classes used Multics' wide variety of programming languages
(including FORTRAN, PL/I, Pascal, COBOL, and several others.) Statistical
processing was performed using spssX and spss (even today, many Oakland
users still run spss jobs that were originally developed on the Multics.)
The Multics "forum" software provided group communication, and several
popular forum topics, including politics, sports, and technical
discussions flourished on the system.  Electronic mail was available,
although it was capable of providing communication between Multics users
only (Oakland did not possess the software needed to attach Multics to the
then-embryonic national electronic mail networks.)

The design of Multics made it very tolerant to user mistakes.  Users were
protected from damaging other users' files, and it was possible for them
to allow other individuals access to their work on a file-by-file basis
using access control lists.  Those people (including myself) that heavily
used Multics miss the access control list feature on now current operating
systems such as UNIX (although other operating systems, such as DEC's VMS,
support access control lists.) The access control list feature even
allowed the ability for users to share tapes, since as disk storage on
Multics was at a premium nearly during its entire life, using 9 track
tapes to store work was a commonplace occurrence.  The Computer Center and
the Multics operators maintained a large tape library in a large walk-in
tape vault in Dodge Hall (watching the operators carry in the tapes for
the Multics system backup was quite a sight: dozens of large tape reels
were needed.) Now, we have tape devices that can store the entire contents
of a several-thousand account system such as Oakland University's Vela
system in one tape (specifically, the kind of tape that some people use in
their car or at home to play music: the 4mm DAT audio tape.)

This same tolerance to user mistakes allowed users to write programs that,
ah, didn't QUITE work right.  Instead of trashing a VM partition on a IBM
mainframe (as many IBM programmers continue to do when things go seriously
awry), Multics would simply print an error message, and if you were lucky,
the error message would help you pinpoint where things went wrong.  If
not, you could run the program, then stab at the BREAK key on your Teleray
terminal (yes, Multics users mostly used terminals to communicate with the
mainframe.) When you hit BREAK, the system would save the context of your
process, allowing you to examine it with various tools.  A common new-user
mistake was to press BREAK too many times, or to just hold the key down
too long.  There was a limit to how many process states the system allowed
per user, and you had to release them (with the rl command) periodically. 

Multics, being a mainframe, possessed resource accounting facilities. 
Users were assigned "funny money" (although some users were actually
charged "real" money) for resource use.  You were assigned a specific
dollar amount of "funny money" to your account, which usually renewed
itself monthly.  You could use your "funny money" towards processor time
to run or develop your programs, print out files, or other system
activities that used limited resources, such as what we now commonly call
batch queues.  When you exhausted your "funny money", you had to plead to
one of the system administrators to get more (during my foray on Multics,
Bill Haga probably heard dozens of requests from me alone to get more
"funny money".) Once you ran out of "funny money", you had to cease using
the system.  If you overran your account, the system wouldn't even let you
in.  The meter was running while you used Multics.  Skillful users
realized that the rates of using Multics were lower in the late evening,
so you'd always see users on in the evening and early morning.  The
weekends were a special treat, since the system was in "Unattended
Service" (meaning no human operator was monitoring the system.) Unattended
Service made it 1) cheaper to use Multics since the rates were lowest, and
2) less likely that someone would yell at you if you accidentally ran a
program that slowed the system to an absolute crawl, since no one was
around (except the occasional system or applications programmer that was
working late on a project.)

Every academic system has to have games or some sort of diversion.  A
collection of Multics games, culled over the years (some written or
improved by Oakland staffers and students) were placed in the demo
account, which didn't require a password.  Multics only allowed access to
the demo account when the system was below a certain number of users, and
clever folks found ways to access the programs within demo from their own
accounts so they could play whenever they wanted, even if it did use up
their "funny money" a bit faster.  Some of us went even so far to beg for
the source code to the programs, compiling our own versions to run when we
were tired of working on that horribly tedious CIS 220 COBOL assignment
(or even worse, writing papers using the EMACS editor, the primary
full-screen text editor/something-like-a-word-processor-that's-
definitely-not-WYSIWYG.) Until you've tried to write a 20 page or larger
paper with EMACS (remember, PC's with word-processing software were not
widely available at Oakland during this era) you've not experienced the
highest level of frustration computing can offer: having to reorganize an
entire paper manually because you forgot a minor paragraph on page one,
throwing off the pagination of the remaining 19 pages.  UGH!  Time to log
into the Demo account and play a nice game of 550 point adventure. 

Some things never change, though: Multics, just like Oakland's current
systems, seemed to frustrate users when they desired to transfer files to
or from it.  The Kermit file transfer program was available, and Paul
Amaranth even wrote a local version of Kermit for Multics that developed
an enthusiastic following.  Many a user waited hours to transfer what we
now consider relatively small files at 300 baud, 1200 baud, or if you were
lucky, 9600 bps (on campus only.) Just like some users do today, we became
proficient at setting up scripts (known as .ec files on Multics) to
automate file transfers.  Hard-core users would set up the system to do
file transfers all night, then they'd wonder what happened when they came
in at 8 AM and saw that only a few kilobytes of their enormous
multisegment file actually made it onto the disk (probably someone sent
them an interactive message with the sm command, fouling up the transfer,
or even worse, the system was so burdened down that Kermit would give up
waiting for Multics to respond and would time out.)

During Multics' heyday at Oakland, it was THE ONLY system that many
students, faculty, and staff could generally use.  Other systems on campus
were either very small (and thus restricted to a few users), weren't
reliable, or were locked up for administrative data processing only. Being
that it was the only system, several people became very proficient with
it.  These Multicians, as they were called, were a great resource to tap
when your own exploits didn't quite work the way you expected. Several
Multicians are still around on Oakland's systems, waiting for the day that
UNIX gets Multics- style ring protection, access control lists, and for
the Korn Shell to understand active functions. They think that today's
operating systems are a step backwards in many ways because of these
lacks.  Indeed, even though UNIX and most of the other contemporary
operating systems drew ideas from Multics, some of the most useful and
interesting features that existed in Multics a dozen years ago are only
now being re implemented.  Multics (or features culled from Multics) still
shows up in today's computer science literature when operating systems are
being discussed. 

Now that Multics is gone, Oakland University is now a mainframe-less
computing environment. The systems that remain at Oakland are all
enormously more powerful than Multics, even though they're much less
physically imposing than Multics.  Even the smallest of our multi-user
workstations has several times more processing power than Multics
(although if you ask these workstations to support 60 users using
EMACS, as Multics was often asked to do, they'll still bog down just
as badly as Multics.) Also, Oakland's computing environment is much
more distributed.  You can easily request one of our machines to
execute a command, perhaps one that takes days to run, then submit the
output from that command to an entirely another machine for
processing--even if that machine is thousands of miles away.  When one
system is too slow because of heavy use, you can log into another
workstation or minicomputer to get your work done.  You don't have to
use EMACS to type papers: the university now has many full-blown word
processing packages, none of which require the resources of the
minicomputers or workstations to operate.

Also, in today's environment, since computing is now more widely
available, there's seldom a "meter running" ("funny money" in the Multics
era.) Only when expensive and/or scarce resources are in use (such as a
remote super computer, time-shared databases, large amounts of disk
storage space, or in some cases, laser printing) do you see many limits or
the exchange of money (either real or "funny") in Oakland's computing
environment. 

Truly, Oakland's computing environment has greatly expanded.  We have
built on the foundation of the Multics.  It provided us with a
reasonably stable system for academic and administrative work for many
years, even though it was widely regarded as obsolete years ago.  Some
think that Multics hampered Oakland's progress, since we relied on a
single system (although we were fortunate in the fact that it was
quite advanced, at least as far as operating system software) for many
years while other institutions bet heavily on distributed systems and
personal computers very early on.  However, at Oakland, we were able
to leapfrog into the distributed environment very quickly.  Today,
it's hard to imagine computing at Oakland without the privilege of 
access to international networks we have today, or the hundreds of
software applications we use, or the sheer availability of computers
(even though we still experience shortages.)

However, only about three years ago, our environment was much
different. The Multics was still being heavily used.  Small UNIX and
VMS systems served a few dozen users at a time, crashing or behaving
antisocially when more than a few people tried to run large jobs on
them.  People struggled converting files from Multics to these small
systems, wondering why it took hours to transfer their work.  PC's
were available, but were constantly broken or didn't have much
application software on them.  Oakland's primary Usenet news and mail
feed came from a small computer in Clarkston, which I'm now using at
this moment to compose this paper (incidentally, I'm now getting my
news and mail for that same computer from Oakland, since Usenet has
grown to the point where over 60MB a day arrives over our high speed
network link.  The days of getting a full news feed via modem at
2400bps are over.)

Today, we exist in the environment where change, variety, and hopefully,
progress towards making computing more accessible are common.  However, we
must not forget the Multics, even though it'll be shortly only a memory
and a collection of some manuals and memorabilia lovingly (or perhaps not
so) kept by those that were able to use, learn, and be a part of the Last
Mainframe at Oakland University.