I read this throwaway reference in the latest comp.risks digest
This reminds me of Doug McIlroy and Bob Morris patching the live
object code of their EPL compiler (early PL/I, starkly subset for
Multics) at the same time Molly Wagner was compiling Multics
memory-management code in 1967. What a mess.
and went looking for a full telling of the story. I haven’t found it yet, but I have read some interesting and amusing things in the Multicians histories.
In 1969, Multics was supporting 20 users on the GE-645 with an average of 5 hours between failures… and took\ 55 minutes to boot.
Here’s more on booting, where we read
I remember the first time we got as far as calling
init_core_control. The CPU lights had been blinking away and suddenly seemed to freeze. It appeared that Multics was in a hard loop. We waited a few minutes to make sure, and then crashed the system and took a dump. We sent the dump to the programmer in Murray Hill, who called on the phone and said “Why’d you kill it? It was only half done.” It turned out that the program was initializing a structure that had an array of 37-bit elements, and that the EPL compiler generated a page and a half of code for each store. The compiler was modified to annotate the assembly code it produced for array accesses: arrays were “good”, “synchronous”, or “idiotic.” When the “idiotic” table declaration was changed,init_core_controlbecame very fast.
In 1967 one could work from home…
I remember when my home terminal was installed at my apartment at 140 Huron Avenue in Cambridge. The 2741 weighed over 300 pounds and took four people to get it up four flights of narrow stairs. Then I had three IBM CEs and two phone men in the apartment, and the phone guys were talking to a chain of colleagues at the various switching centers across Cambridge to MIT, setting up the leased line and “conditioning” it so that it would be free enough of noise to transmit data. The 2741 transmitted at 134.5 baud, somewhat faster than the 110 baud speed of the Teletypes…
It took a little effort to maintain an idle login session:
Often, I would log in to the mainframe from home as soon as I got there, and leave the terminal logged in until I went to bed. If your process was inactive for an hour, the operating system logged you out, so I wrote a tiny program that typed the time every half hour, like a high-tech cuckoo clock. If the time stopped typing, I knew the system had crashed, and could call the operators (if they didn’t call me).
In The GE-635s at Project MAC and BTL we learn about intentionally breaking magtapes, under software control:
The tape drives used for IMCV on the GE-635 were some of the first self-threading drives. As a result they needed an extremely long tape leader, 150 feet, before the “reflector spot” and this was a pain for MIT operators when loading the tapes onto the 7094 running CTSS. Lee Varian wrote some tricky code, and we put two load point reflectors on the tapes we shuttled between the 7094 and the 635. The 635 would only sense the farther-in load point; the 7094 would load to the early load point and then Lee’s code would space it way out and rewind back to the 635 load point. If we didn’t find the right label, his code tried three times and then deliberately broke the tape so the operator would have to put on new load points at the correct places. (You could break a tape on the 94 by putting it into high speed rewind and then doing a reset data channel command.)
About the drum which was actually a fixed-head disk:
The design of the original GE-645 system included a paging drum , a device much faster than the disks of the day. This wasn’t new: CTSS used IBM 1301 drums for swapping core images. The Multics drum, though, like everything else in the system, was to be bigger, faster, and better. GE chose a device we called the “firehose” drum. It was made by Singer Librafile, and was actually a big head-per-track disk. The disk and controller were in a box seven feet high and about 20 feet long and 3 feet wide. This was long and narrow compared to the other 645 cabinets; rumor had it that the Librafile device was also used on Polaris guided missile submarines. (The floor on the 9th floor of 545 Tech Square wasn’t strong enough for the drum’s weight: they had to bring in a huge I-beam to spread the load before installing it.)
Very significantly we made a number of modifications to the PL/I compiler so that commonly used constructs would generate good code. We carefully defined a subset of the language called REPL (restricted EPL) that included only these language constructs and then modified most of the system to only use REPL. We built two tools to be used at software submission time – source_submission_test, and object_submission_test that looked for known-to-be-bad things so as to prevent the installation of potentially poor performing programs.
…
The EPL compiler was a memory hog so we created the epl daemon and people submitted their compilations to it so that there would only be one going on at a time. With all these changes we never had to abandon any important design principles while achieving incredible progress
From the Multics history overview:
IBM’s proposed PL/I language was chosen as the programming language for Multics in 1964.
In 1965, Bell Labs contracted with Digitek, a software house with experience in compilers, to produce a PL/I compiler for Multics. When it became clear that this project was going to fail, Doug McIlroy and Bob Morris of Bell Labs produced a ‘quick and dirty’ TMG-based compiler for EPL (Early PL/I), a subset of the full PL/I language. This compiler was written using Prof. Bob McClure’s TMG language framework. It ran on CTSS and also under GECOS on the 635.
Developing this compiler and learning to use it contributed to further delay.
The EPL compiler was very slow, and produced inefficient code for some statements: programs had to be restricted to a a subset, REPL, of the language. In 1968, the GE team began work on a PL/I compiler written in PL/I, “version 1 PL/I”.
And, just in case you think you know something, check out the Myths page.
See also a previous discussion at Unix vs Multics