Phase One

Tom Van Vleck

We sort of made up project management as we went along at Project MAC. (Corby and Charlie Clingen wrote a great paper on the management challenges of the project.) One technique we used was to define "phases," each of which had quality targets and a functional benchmark for the integrated system. (In retrospect, we should have set tight performance goals too.) Phase One required Multics to bootload on the GE 645, create a full-fledged process, and do terminal I/O. It was preceded by Phase 0.5, which demonstrated a working Multics file system on the 645 simulator: that happened in March 1967.

Phase One was planned to happen a few months later, but it took until December 1967 to reach the milestone. A lot had to be integrated to make Phase One run, and we fell into a mode of serial debugging. Each development run required editing on a heavily loaded CTSS, painfully slow EPL compilation, complete regeneration of the system boot tape, and an attempt to boot the system. (The system tape didn't contain a linked image of the OS, the way other systems did: our design was that every site's system tape would be identical, and that the system would configure and link itself during the boot process. This elegant goal wasn't easy to design.) The boot attempt would eventually crash, and then a programmer would take a core dump on the printer, take it to his or her desk, and debug so that the whole cycle could start again. (John Gintell wrote a slick dump program that booted from the card reader. A full dump in those days was only a side inch of paper or so; as the system grew, dumps did too, till they were over a foot high.)

The phase one team could only get one run a day on first shift, so we worked second and sometimes even third shifts. There was pressure and anxiety, personality conflicts, and stupidity; but we also had teamwork, good times, camaraderie, and pride in working on the biggest challenge in the computer field.

(Fred Brooks wrote about the "second system effect" in The Mythical Man-Month but we didn't know then that we should avoid it; Multics was our first second system. Contrary to some writers' views, the effect isn't one of going crazy adding features to the design of the second system; instead the designers of a second system want to do it really right this time; they want to meet more or less the same requirements, but this time with elegance and completeness. What happens is that features that were added on in a crockish way on the first system get provided for in the basic design of the second one. And inserting all this elegance and flexibility makes it harder to make design decisions, and harder to end up with a simple design that has a chance of performing well and integrating quickly. In other words, the complexity gets moved back from implementation and maintenance, as it was in the first system, into design complexity in the second system.)

The goal of Phase One was to boot the system from tape on a cold machine, with no help from GECOS, initialize the whole supervisor and file system, and execute commands from the operator's console, a Model 37 Teletype in the machine room. Noel Morris and I made the bootload run that finally achieved Phase One. The system typed out

  Multics is the one system to have when you're having more than one.

(This was a parody of a beer commercial of the time; the point was (a) this was our second system -- CTSS already worked and we were using it to build Multics; (b) Multics was designed to run more than one processor. Well, we thought it was funny.) It was late at night, maybe ten or eleven, and we debated whether to call Corby at home or to let it wait till morning. We decided to call him & he was very polite, considering the hour.

See the article on Multics Bootstrap Loading for more information.

(The picture above, of Don and Karolyn debugging, doesn't show the headphones. The 645 was so big, occupied so much floor space, that it was hard to debug. I am pretty sure that Don is looking pensively at one of the CPUs, and the other one is in the background. The cabinets were 7 feet high, 3 feet wide, and about 10 feet deep. But for system bringup debugging, we also had to look at the control panel for the GIOC, a truly huge monster, X-shaped like four CPUs back to back to back to back. And sometimes we needed to station somebody by the controller for the firehose drum as well. Somebody got the bright idea that we should have an intercom system, and installed one inside the various cabinets. There were several sets of earphones with microphone attached, hooked to coil cables with phone plugs at the end. You could put on a headset and plug in at whatever box you were looking at, and talk to a colleague three or four boxes away. There were even two intercom circuits, A and B, selected by a switch on each box, so that two teams could be debugging different hardware groupings at the same time. I think we used the stuff about three times. Being tethered to the machine was a pain; it was easier to walk around a few boxes than to mess with the intercom. The wiring for the intercom was removed a few years later, about 1969, when "bad grounding" was blamed for repeated hardware crashes, and Field Engineering decided to remove the wires that weren't in the prints.)

(Speaking of beer commercials. Sometime in the 70s, there was a big billboard in Kendall square that proclaimed, "Fresh Beer Is Like Fresh Anything." I was never sure how to take this. Was this an obvious remark, or a subtle explanation of how we understand words, or just marketing? Anyway it made me happy.)

05/16/93, updated 7/25/95