A Student of Computer Science and Multics

by Stan Chesnutt

Today, a typical college student might unwittingly carry three to five
powerful computing devices on a daily basis.  A modern cell phone,
compact-disk player, PDA, MP3 player, and laptop computer each likely
contain more data-processing capability than the entire Computer
Science facilities of a medium-size college in the early
nineteen-eightes.

Between 1980 and 1983, I was a student at the University of Southwest
Louisiana.  At USL, the computer-science department shared one
computer with the rest of the college: a multi-processor Honeywell
mainframe on the second floor of Stephens Hall.  This computer ran the
Multics operating system and provided timesharing services for
engineering, mathematics, computer science education as well as
student records and database services for the college administrators.

Multics quite easily and capably provided these services, due to a
robust security model that was advanced for the time and continues to
be a model for effective access control.

From the perspective of a computer science student, Multics was an
intriguing and sometimes frustrating system.  The capabilities and
power of the system were endlessly fascinating, but since many hundred
students shared this common resource, one's opportunities to
experiment with the system were limited, at least at the undergraduate
level.

The following are my reminiscences from my period interacting with
Multics.  My main purpose in writing this is to accent the differences
between computer interaction then and now.  So, if you're reading this
document on a modern computer with a bit-mapped color display, perhaps
having clicked your mouse on a Web link to pull this text into your
computer, you'll soon see how few of those capabilities were present
just a few decades ago.

In the first week of freshman Computer Science, students were given a
quick classroom introduction to Multics.  We were told how to login,
the rudiments of file storage, a quick howto on electronic mail, and
an overview of the text editor.  First assignment: create a text file
in your home directory, and in that file, put your full name and
student identification number.  After creating that file, we were to
print it out on the line-printer and hand-in the results to the
instructor.  Trivially simple.  The introduction was given
lecture-style: no terminals were present in the classrooms.

The terminals were on the first floor of Stephens Hall, in a
well-cooled room that was open around the clock and featured some
thirty-five or so Televideo 912 terminals.  We quickly became close
acquaintances with the Televideos.  These were black-and-white
terminals, with twenty-five lines of eighty-character text.

Few incoming freshmen had ever touched a computer before.  Remember,
these were the days when computing was an eccentric hobby, with maybe
only half a million computers in use across the country.  If you had
used an Apple II or Commodore PET microcomputer, or maybe even used a
timesharing terminal, you were way ahead of the game.

The Televideos were configured for half-duplex, local-echo.  That
means you could merrily type away on the keyboard, and your text would
appear on the screen.  Our usual text editor, "ted", was line-oriented
in a fashion similar to "ed", "ex", and other very simple text-entry
programs.  As freshmen, we heard legends of the mighty Emacs software,
but Emacs was banned from our Multics installation: just one user
running Emacs would monopolize the computer's resources unacceptably.
But, if we were all running "ted", some eighty or so users could
simultaneously use the system.

Student resources were very limited.  We had a home directory, but
only enough space for a few files.  The modern equivalent would be
about twenty-four kilobytes, which is barely enough for two or three
short student assignments.  If you wanted to store a LOT of data, you
had to buy a magnetic tape!

Further, students were given a short amount of CPU time.  Your
duration at the terminal was limited by a daily ration of CPU cycles.
If you were just entering or editing text, the ration would allow you
to keep the login session for an hour or three.  But, when you started
to compile, that CPU ration would go much faster.  And woe to the
student who accidentally puts an infinite loop into the program!  Very
soon, the session would end, and you would have to wait until the next
day.

The per-user CPU limits were reset at midnight.  Many times, you could
walk into Stephens Hall close to midnight, and see people awaiting the
"rollover" to the new day.  If an assignment was due tomorrow, and
your CPU ration ran out at 4:00 in the afternoon, returning after
midnight was often the only way to get the job done.

With only a few dozen terminals, the room got full fast.  And, towards
the end of the semester, with the big assignments coming due, the room
was busy around the clock.  Fortunately, there was an "express
terminal" in one corner that allowed five-minute logins.  You could
get on the express terminal, make a few hasty edits -- maybe a
compile, and then you'd get booted off.  The line for the express
terminal was typically short, but during crunch-times, it was better
than waiting sometimes up to an hour for a regular terminal.  A
(paper) signup sheet allowed you to get in the queue and then run out
for a meal or coffee.

The Televideos ran at 2400 baud, I believe.  Very slow, especially by
modern standards.  But since they only displayed 25x80, it seemed
adequate.  A few "dialup" lines were available, at 300 baud, if you
were fortunate enough to own a terminal and modem, and could avoid the
busy signal on the few incoming modem ports, you could login from your
home.

These conditions probably sound inhumane, if you're a modern
programmer with several Emacs windows open, a source-browser handy,
and a multi-megabyte build going on in the background.  But the style
of program development was much different then.  No, we weren't forced
to flowchart, but usually one would write out much of the program in
longhand first, then type it into the computer.  You'd run the
compiler, make a printout of the program text and the inevitable
compiler errors, then go to the dorm, or a coffee-shop, or the library
and work through the errors.  Return to Stephens Hall, edit the
program, and recompile.  Hopefully, clear sailing and you could start
to debug.

Two massive line printers were almost constantly running, printing
various jobs for students and staff.  From the terminal, you could
"dprint" a file, and typically fifteen minutes later, you could pick
it up at the service window.  The printer attendants typically
demanded your student ID, unless you were a "frequent shopper" and
known to the staff.

Electronic mail was available, but it did not serve as the ubiquitous
communication mechanism that we are familiar with today.  Students
were often "offline" for hours or days at a time.  The web of social
life was still woven from face-to-face or telephone contact.  Further,
people did not email files around: each user's mailbox would consume
precious disk space.  If you wanted to share a file with another user,
you could set specific "read" access for that user -- that person (and
only that person) could then read or copy it out of your home
directory.

Games?  Of course we had games.  There was a special, no-password
login called "demo".  When you logged into the demo project, you could
play Adventure or any of the several dozen text-based game programs.
But "demo" was load-limited.  If more than a certain number of users
were online, the demo account was disabled and any demo users were
booted.  But early in the semester, it wasn't unusual to see a dozen
or so folks exploring the Colossal Caverns.  Some very elegant
multiuser programs were written for the demo project: Andre Guirard
contributed a nice tank-battle program (using very simple ASCII
graphics), and Jeffrey Stout was deeply immersed in the development of
a multi-user dungeon-search program that was probably the ancestor of
the modern MUD.

Multics itself was studied at the graduate level.  As undergraduates,
we used the system for coursework: everything from simple programs at
the freshman level to compilers and architecture simulators for mroe
senior-level classes.  The system truly served as a processing
utility, meeting the goals of Project MAC.

Multics was used by the University's administration department as
well.  Class schedules, many student records, and various databases
were online.  The strict access-control capabilities of the operating
system protected the confidentiality of all information.

Microcomputers were practially unknown on campus.  There were a few
hobbyists around, but all undergraduate assignments were done on
Multics.  And most of the programming was done in PL/1 (the native
language of Multics).  There was a simple facility to compile and run
Pascal (written at the Multics installation in Grenoble, France), and
a Multics flavor of Fortran was available.  In 1983 or so, the
Computer Science department purchased a few graphics computers from a
local manufacturer, Phoenix Computer Graphics.  These devices ran
Digital Research DOS, and each sported a huge RGB monitor that could
display 1024x1024 graphics with a 256-entry color palette.  The main
processor was a six-megahertz 8086, so only fairly simple images could
be rendered and displayed.  Still, it seemed like a great advance for
the students taking the Computer Graphics class who were able to use
these machines.

USL also purchased two DEC VAX 11/780 computers: both running VMS but
one was reserved for microcode programming.  Very few undergraduates
got to use anything other than Multics, though.  After four years of
using Multics, many graduates went on to development positions at Ford
Motor Company and the Department of Defense.

In 1984, the "beginnning of the end" was becoming obvious.  IBM had
introduced the IBM PC, Apple unveiled the Macintosh, and these systems
were beginning to get useful development environments (Turbo Pascal on
the IBM PC was evaluated as a possible teaching tool).  But Multics
continued to serve the Computer Science department, although its
influence was clearly waning.

$Id: student_multics.txt,v 1.1 2006/03/06 05:02:14 chesnutt Exp $