Multics > People > Stories
18 Aug 1996

THVV Multics Bio

Tom Van Vleck

In almost 15 years on Multics, I worked on many parts of the system, including system boot, login, administration and accounting, operations, BOS, system console management, documentation tools, tape, backup, transaction processing, error handling, development process, and the file system. I wrote many commands and subroutines and added features to many more, from mail and help to print and use.

I joined MIT Project MAC in 1965 to work on CTSS and moved on to Multics boot and system administration. In 1969, I went to MIT IPC to manage CP/67, CTSS, and Multics programming. I joined Honeywell Cambridge Information System Laboratory (CISL) in 1974, transferred to Honeywell Phoenix to manage Multics developers in 1978, moved back to CISL in 1980, and finally left Multics in 1981.

I am especially proud of my contribution to the Multics New Storage System (NSS), which replaced the system's disk organization to improve system scalability, capacity, and reliability. I coordinated the work of up to 25 colleagues, wrote major design documents, programmed some key pieces, and served as librarian and build coordinator. About 75% of the hardcore supervisor was modified by this project.

I also represented Multics on the Honeywell LISD Palyn report evaluation committee, which prepared an Engineering evaluation of Honeywell's operating system future plans.

I wrote and presented talks and conference papers about Multics to internal and external audiences.

When I left CISL in 1981, I was the second highest submitter of Multics Change Requests (MCRs). Steve Herbst was first; he specialized in bug fixes, and most of mine were feature introductions.

I was lucky to work with and learn from some of the smartest and kindest people in the business, on a system that had ambitious goals and time to accomplish many of them. When I think back about Multics, I remember the wonderful people first, then the good times we had, and then the neat things we built.

We used to speak of building things "the Multics way." To me this meant trying to solve the general problem as well as the immediate one; open discussion of every technical point; continuous evolution of our product and our process; and attention to consistency, elegance, and evolution. Doing it right rather than doing just enough. When the Multics hardware is obsolete and the code lost, I'll still prefer to develop software the Multics way.

Dick Gabriel wrote a lovely essay titled "Worse is Better," in which he contrasts the "MIT Approach" versus the "New Jersey Approach." These are intentional caricatures, but roughly contrast putting perfect design first, versus putting simple implementation first. Many mistaken articles about Multics have identified its approach as equivalent to Gabriel's "MIT approach." In fact, I think this is not true, and that the approach we took when building Multics is somewhere between Gabriel's poles. (There's a moving-target problem here: the approach practiced at CISL in the 70s and 80s was not necessarily the same as used by Project MAC, GE, and Bell Labs in the 60s.) Nevertheless, the MIT/BTL/GE focus on getting a system up as quickly as possible, with adequate performance, led us to postpone or eliminate unnecessary features ruthlessly. We often applied the "80-20" rule, trying to get 80% of the function accomplished with 20% of the code, leaving evolution towards 100% for later. We spent time discussing what 100% of a feature was, and often implemented first-draft versions that we learned from when implementing later versions, so "100%" evolved based on experience.

All the good parts of Multics were good because they improved on earlier versions. Corby and Charlie's paper on management of Multics captures some of this philosophy.

Programs I Wrote

All Multics software was a team effort, and my colleagues had substantial influence on things I did and vice versa. Here are some programs I began, or took over and made my own for a period of time. Others subsequently rewrote and greatly improved some of them, learning from my mistakes.

PERT charts

(In "A Managerial View of the Multics System Development", Clingen and Corbató wrote "PERT charts were attempted in early stages of the project but with very mixed results." That was me, about 1968. (When I was an undergraduate, I had taken a course in optimization methods, and one topic was PERT charts, fairly new then.) I wrote PERT chart generation software, I think in MAD, and collected info on tasks, and generated diagrams on the line printer. Talking to everyone to get the dependency information was a laborious task, and getting up-to-date status information required even more labor. Getting the team to think about dependencies and subtasks was useful, but the resulting charts magnified any inaccuracies in the estimated input data. We decided it wasn't worth the effort to try to maintain the charts.)

Documents I Wrote

One way for me to remember what I did is to look at the list of documents I wrote while on the project.

CTSS Memos

Initially we used CTSS to build Multics. My first jobs at Project MAC focused on improving and maintaining CTSS.

Multics System Programmer's Manual sections

(* indicates co-author)

Multics Design Memos (Partial List)

Multics Storage System Memos

See the references in "The New Storage System."

Manuals

Honeywell Large Systems Users Association (HLSUA) Presentations

11/11/94, updated 08/18/96, 11/29/02

Next story | Tom Van Vleck home page