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.

• 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.

This listing complements the later 32K 709/7090 FORTRAN II (scroll down a bit from here from 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.

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.

Updated 23 Mar 2006: Leif Harcke’s URL changed.