Operating systems – Dusty Decks: Preserving historic software

A CAL TSS debugging tool

One of the artifacts preserved from the CAL Timesharing System project is a deck of 14 80-column binary cards labeled “TSS PM DUMP”. This is a program for a CDC 6000 series peripheral processor unit (PPU) to perform a post mortem dump to magnetic tape of the complete state of a (crashed) system: PPU memories, CPU memory, exchange package, and extended core storage. Another system utility program, TSS PP DUMP-TAPE SCANNER, allows selective display of portions of the dump to either the teletype or one of the system console displays. I believe Howard Sturgis wrote the PPU program and Keith Standiford wrote the CPU program.

I suspected this card deck was a version of a PPU program called DMP, for which a listing exists. Carl Claunch very generously offered to read (digitize) the cards. He produced a binary file tss.hex. I queried the ControlFreaks mailing list re a PPU disassembler, and Daiyu Hurst sent me a program ppdis.c that generates a listing with opcodes resolved and addresses, octal, and textual representations of each 12-bit word. After upgrading it to eliminate some K&R C function definitions and changing its input format to match tss.hex, I ran it, captured the output, and then began annotating it. As expected, it matched the DMP listing very closely, so I used those variable names, labels, and comments to update the output of ppdis.c, and added a few additional comments, including slight differences from the DMP listing.

The first card is a loader that loads subsequent cards up until one with a 6-7-8-9 punch in column one is encountered. The first card is loaded via the deadstart panel. Page 14 of the CAL TSS Operator’s Manual explains:

    HOW TO MAKE A DIAGNOSTIC DUMP OF A SICK SYSTEM

       Unfortunately, the dump program requires a different deadstart panel from the system dead start program. Reset the deadstart panel to
CAL TSS I, push the deadstart button, read the deck “TSS POST MORTEM” into the card reader, mount a tape on unit 0, and stand back and
watch it go. After the tape unloads, reset the deadstart panel to CAL TSS II and dead start the system as usual. Record the reel on which
the dump was made along with the other information relevant to the crash.

The Operator’s Manual also contains a set of CAL-TSS FAILURE LOG forms recording crashes and attempts to diagnose them.

The program on the cards is very similar to the DMP listing (which doesn’t include the loader card), with slightly different addresses and one or two small changes in the code.

The general structure of the program is to dump PPU 0 (whose memory is partially overlaid by the DMP program), then use this working space to dump PPUs 1-9, the exchange package (CPU registers), the CPU memory, extended core storage, and finally write a trailer record. The console display is used for operator messages: mounting a tape on drive zero, progress messages indicating which phase is taking place, and several error messages.

This doesn’t sound like a terribly difficult task, but it requires about 1000 instructions on the PPU, which has 12-bit words, one register, no multiply or divide, and an instruction time of 1 to 4 microseconds. There are some additional complications:

A PPU can’t access the memory of another PPU. When the overall system is deadstarted, PPU 0 begins running a 12-instruction program loaded from toggle switches on the deadstart panel, and the other PPUs are each suspended on an input instruction on a different I/O channel. Thus PPU 0 sends a short program to each one instructing it to output its own memory on a channel, which PPU 0 inputs and then outputs to the tape drive.
Similarly, a PPU can’t access extended core storage (ECS). So PPU 0 repeatedly writes a short program to the CPU memory that reads the next block from ECS to CPU memory, then does an “exchange jump” to cause the CPU to execute that program. The PPU then reads the block from CPU memory and writes it to tape.

Here is the annotated listing.

Update 2024/01/18: Linked to the copy of the listing (etc.) at https://caltss.computerhistory.org.

CAL Timesharing System: Before computers were personal

In 2023 computers are all around us: our phones, tablets, laptops, and desktops, and lurking inside our television sets, appliances, automobiles, to say nothing of our workplaces and the internet. It wasn’t always that way: I was born in 1949, just as the first stored-program digital computers were going into operation. Those computers were big, filling a room, and difficult to use. Initially a user would sign up for a block of time to test and run a program that had been written and punched into paper tape or 80-column cards.cThe fact that an expensive computer sat idle while the user was thinking or mounting tapes seemed wasteful, so people designed batch operating systems that would run programs one after the other, with a trained operator mounting tapes just before they were needed. The users submitted their card decks and waited in their offices until their programs had run and the listings had been printed. While this was more efficient, there was a demand for computers that operated in “real time”, interacting with people and other equipment. MIT’s Whirlwind, TX-0, and TX-2 and Wes Clark’s LINC are examples.

The ability to interact directly with a computer via a terminal (especially when a display was available) was compelling, and computers were becoming much faster, which led to the idea of timesharing: making the computer divide its attention among a set of users, each with a terminal. Ideally the computer would have enough memory and speed so each user would get good service. Early timesharing projects included CTSS at MIT, DTSS at Dartmouth, and Project Genie at Berkeley. By 1966, Berkeley (that is, the University of California at Berkeley) decided to replace its IBM batch system with a larger computer that would provide interactive (time-shared) service as well as batch computing. None of the large commercial computers came with a timesharing system, so Berkeley decided they would build their own. The story of that project—from conception, through funding, design, implementation, (brief) usage, to termination—is told here:

Paul McJones and Dave Redell. History of the CAL Timesharing System. IEEE Annals of the History of Computing, Vol. 45, No. 3 (July-September 2023). IEEE Xplore (Open access)

How did I come to write that paper? In the winter of 1968-1969 I was invited to join the timesharing project. At that time I had about 2 years of programming experience gained in classes and on-the-job experience during high school and college (Berkeley). That wasn’t much, but it included one good-sized project—a Snobol4 implementation with Charles Simonyi—so the team welcomed me to the project. For the next three years I helped build the CAL Timesharing System, performed some maintenance on the Snobol4 system, and finished my bachelor’s degree. In December 1971, CAL TSS development was canceled, and I graduated and moved on to the CRMS APL project elsewhere on campus.

Those three years were hectic but immensely enjoyable. The team was small, with under a dozen people, housed first in an old apartment on Channing Way and then in the brand-new Evans Hall. Lifelong friendships were formed. People often worked into the night, when the computer was available, and then trooped over to a nearby hamburger joint for a late meal. Exciting things were going on around us. There were protests, the Vietnam War, and the first moon landings. Rock music seemed fresh and exciting. I had met my future wife in 1968, and we were married in 1970.

As CAL TSS came to an end, we all agreed the experience could never be equalled. But we didn’t realize people in the future would be interested in studying our system, so we weren’t careful about preserving the magnetic tapes. However many of us kept manuals, design documents, and listings, plus a few tapes. In 1980 and again in 1991 we had reunions and I offered to store everything until it became clear what to do for the long run. Around 2003 I started scanning the materials and organizing a web site. In 2022 the Computer History Museum agreed to accept the physical artifacts, and this year they agreed to host the web site:

https://caltss.computerhistory.org/

Xerox Alto file server archive

It’s been almost a year since I posted to this blog, but I haven’t been completely inactive. This week, as part of its Software Gems: The Computer History Museum Historical Source Code Series, the Computer History Museum released a set of files archived in the 1970s and early 1980s from the Xerox Alto file servers at Xerox PARC. The files include source code, executables, documents, fonts, and other files.

This release has been a long time in the making. The files were originally archived to 9-track magnetic tape, but around 1991 they were transferred to 8mm tape cartridges. Around 2003, before he joined the Computer History Museum, Al Kossow, working under a Nondisclosure Agreement with PARC, transferred the 8mm tapes to DVDs, and sifted through the entire archive looking for files specifically related to the Alto — the archive had included files from many other projects over several decades. After many years of discussion, and the involvement of a number of people inside and outside of PARC, an agreement with CHM was finally signed in February 2011, and a CD with the Alto files that Al had located was given to CHM.

In August of 2013, I asked Len Shustek what had become of the files, and he suggested I write a blog post about them. So I talked to Al (now CHM software curator), who gave me a copy of the files. It turns out they were images of the tape records written by a Cedar Mesa program called the Archivist. Luckily, when the 9-track tapes were transferred to 8mm tapes, a file called rosetta.tar containing the Archivist source code plus some documentation was included on each tape. Once I obtained a copy of rosetta.tar I was able to write a program that “dearchived” the tape records, recreating a set of file directories. To make the files easier to view over the web, I added code to create a static web site allowing the files to be browsed, including translations from Bravo format to HTML and Press format to PDF. (Bravo was the first WYSIWYG word processor, and Press was a device-independent print-file format.)

There are 14680 files in all, of which 8598 are distinct. They include the Alto operating system; BCPL, Mesa, and (portions of the) Smalltalk programming environments; applications such as Bravo, Draw, and the Laurel email client; fonts and printing software (PARC had the first laser printers); and server software (including the IFS file server and the Grapevine distributed mail and name server).

Although not many people ever used an Alto, it had a huge influence on the hardware and software we use today, so I am very pleased that this software is now available for study.

The blog post Len invited me to write is here. The archive itself is here, but I recommend starting with this walk-through of the archive describing what is there and who wrote the various programs. More detail about the archive (provenance, naming conventions, file types, etc.) is available here.

Update 2023/05/10: Corrected link.

Gordon Bell: “Out of a Closet: The Early Years of The Computer [History] Museum”

Update 1/1/2016: Gordon Bell has made an archive of materials from The Computer Museum available at https://tcm.computerhistory.org.

The institution now known as the Computer History Museum began in 1975 as a closet-sized exhibit in a Digital Equipment Corporation building, grew into The Computer Museum located on Boston’s Museum Wharf, and finally metamorphosed into its current form and location. In a fascinating technical report, Gordon Bell describes this long and interesting history, in which he and his wife Dr. Gwen Bell have played such important roles.

It was only recently, Bell notes, that “Software was finally added to list of things collected, such as the history of FORTRAN including original source code.” The FORTRAN collection to which Gordon refers is here; a catalog search of FORTRAN-related items in the museum’s archives is available here.

Bell gives a list of some two dozen “Mona Lisas” in the collection, all hardware artifacts. He concludes this section by saying “Regrettably, I omit that hard to see, hard to describe, essential software from COBOL, FORTRAN, and LISP, various Operating Systems, and on through Visicalc, and the Relational database.” I strongly agree with Bell about the importance of collecting and displaying such historic software. I’m glad to be able to point the previously-mentioned FORTRAN collection, and to similar collections for LISP, ALGOL, and C++. Others have assembled extensive collections on, for example, the Multics and Unix operating systems, PDP-10 systems and applications, and many more. Two of the earliest relational database management systems, Berkeley Ingres and IBM System R, have been preserved but are not yet easily accessible. For the most part, these collections are aimed at a more scholarly audience; I hope they will serve as source materials for future exhibits for a wider audience.

Update 2024/05/08: Updated various URLs.

A day in the life of an IBM Customer Engineer, circa 1959

I’ve added another important document to the Fortran I/Fortran II collection at the Computer History Museum:

Anonymous. FORTRAN I, II, and 709 : Customer Engineering Manual of Instruction. IBM Corporation, Form R23-9518-0, February 1959, 67 pages. Copy belonging to Mark Halpern. PDF

This document is filled with useful information for anyone interested in digging into the IBM Fortran I/II compiler, and provides fascinating hints about what it was like to be a customer engineer in the late 1950s. It begins with an introduction to the nature of machine language, assembly language, and higher-level languages, starting with an analogy whose exposition would not be considered quite politically correct today: “The problems involved in man’s communications with the complex computer are in many respects similar to those problems involved with his communications with another man who speaks an unfamiliar language.” The next chapter jumps right into the structure of the compiler with summaries of each of the sections (passes). This is followed by a description of the Fortran systems tape, which performed the functions we now associate with an operating system. Section 1.12.00, Service Aids, notes: “To successfully run the Fortran translator the 704 must be in in prime working order. The tape system in particular, and the drum are given a good work-out during the exeuction of the program.” It goes on to list adjustments and engineering changes that were likely to be required to run such a demanding program as the Fortran compiler. Another chapter describes the various tables used to represent the intermediate and final object program.

I was able to scan this document courtesy of Mark Halpern, whose first assignment after joining the IBM Programming Research Department in 1957 was to study and document (via flow-charts) the Fortran compiler. Mark’s memoirs were published in three parts in the Annals of Computer History starting in 1991; eprints are available online at Mark’s web site.

Postscript (March 20, 2006): I should have noted a fascinating memoir by John Van Gardner, who was one of the IBM Customer Engineers who installed IBM 704 serial number 13 at Lockheed Aircraft in Marietta, Georgia in May 1956. This memoir describes the resourceful techniques he used in 1957 to debug a hardware problem that resulted in the Fortran compiler behaving in a nondeterministic manner.

[Edited 10 May 2014: community.computerhistory.org/scc => www.softwarepreservation.org; 2 Jan 2016: substituted Internet Archive link for Mark Halpern’s web site.]

704 FORTRAN II listing available

I just posted a scan of the three-volume listing of the IBM 704 FORTRAN II compiler to the History of FORTRAN and FORTRAN II web site at the Computer History Museum. This listing was donated to the Smithsonian National Museum of American History by Peter Z. Ingerman. When I last reported on it, I was hoping that an intermuseum loan between NMAH and CHM could be arranged so we could scan the listing ourselves. As it turned out, David K. Allison helped us find a consultant, Nance Briscoe, who performed the scanning on the east coast. I want to thank them, as well as Kirsten Tashev.

This listing complements the later 32K 709/7090 FORTRAN II (scroll down a bit from her e for the IBSYS distribution on 7-track tape digitized by Paul Pierce. This version runs on the bare IBM 704, whereas the later version, for the IBM 709 with its more sophisticated I/O system included a Fortran Monitor System, which had been adapted to work with IBSYS.

Update: 2014/05/10: community.computerhistory.org/scc => www.softwarepreservation.org; updated URLs for bios of David Allison and Kirsten Tashev.

Update: 2024/05/08: again updated URLs for bios of David Allison (via Wayback Machine) and Kirsten Tashev.

IBM 7094 Emulator now runs Fortran IV compiler

I expect most Dusty Decks readers are aware of alt.folklore.computers, but it’s worth noting Rob Storey’s recent post IBM 7094 Emulator now runs Fortran compiler. As I posted in June, Rob has written a IBM 7094 emulator. Through the work of James Fehlinger, the emulator can load and execute the compiler, and then execute the result, at least for a “hello, world” program.*

Rob suggested others might want to get additional programs running on the emulator, and suggested several that are available. Leif Harcke suggested CTSS (M.I.T.’s Compatible Time Sharing System), using the tapes available from Paul Pierce’s collection. I mentioned this to Tom Van Vleck; he took a look at the tapes and lent his enthusiastic support. Rob is happy to make the necessary “hardware modifications” (known as RPQ’s) to the emulator if someone will supply him with a specification.

* As of 2024/05/07 the latest version of the emulator is here: https://github.com/Bertoid1311/B7094

Updated 2006/03/23: Leif Harcke’s URL changed; 2015/01/07: Rob’s and Tom’s alt.folklore.computer URLs changed; 2024/05/07: Rob’s URL changed to Internet Archive Wayback Machine; footnote added.

Tom Van Vleck

Tom Van Vleck and I met at Tandem in 1981. Tom is the creator and maintainer of multicians.org, which “presents the story of the Multics operating system for people interested in the system’s history”. Since Tom was at MIT in the 1960s, I thought he might have heard of the ‘Tome’, so I sent him an email. He hadn’t heard of it, but he suggested several leads for me to follow: Jean Samme t, Lynn Wheeler , the IBM folks I’d worked with in the 1970s, Doug McIlroy (“Bell Labs probably got a copy and may even know where in the Labs it was”), and Frank da Cruz, who maintains Columbia University Computing History (for example, see John Backus).

Update 2024/05/08: Updated Columbia URL.