Resurrecting DMS

We began work on the IBM 1130 emulator in the fall of 2001, with little hope of ever having a copy of the original operating system to run on it. In March 2002, Douglas Jones sent us copies of the IBM build listings on microfiche. It seemed like a long shot to scan and OCR them, but we began to experiment with the concept. We also knew that there was a binary "system load" card deck in Milpitas, CA, part of the Computer History Association of California (CHAC) collection, but getting a working card reader to load it in was going to be difficult.

Then, in April, 2002, we received a letter through the IBM1130.org guestbook from Oscar E. Wyss in Switzerland who indicated that he just happened to have the entire source code for DMS on his website, available for download. (Oscar emailed the next day, "Thank you for your interest and for filling my access log.") Little real work got done over the next couple of weeks, and our cross assembler got a workout.

DMS is loaded onto a blank disk cartridge through a "system load" procedure. Starting with a single bootstrap card that is followed by a succession of loader programs and system object modules, about two drawers of binary punched cards must be read in to populate the disk. The trick was not only to assemble the system components, but to correctly construct the load deck.

The initial portion of the load deck, illustrated above, is composed of four components:

• A single card bootstrap program in IBM 1130 Initial Load format
• A secondary bootstrap card in IBM 1800 Initial Load format
• An absolute core-image loader also in IBM 1800 Initial Load format
• The System Load program Part 1, in absolute Core Image format

This is followed by text configuration cards, the System Load program Part 2 and the system programs in relocatable format, and finally the library routines interspersed with DUP *SAVE commands. Getting all of this right was quite an adventure. Luckily, we had at hand all three of the crucial components we needed:

• Source code, to provide accurate input to our cross assembler,
• Listings on microfiche from the original IBM distribution, to verify the output of the cross assembler, and
• IBM documentation, most importantly the IBM 1130 Programming and Operator's Guide, which provided invaluable (and almost complete) documentation on the various binary card formats.

Source code readings filled in the missing pieces. There was quite a bit of trial and error involved. Three whole days were lost to a single oversight in reading the documentation: an A or F punched on a certain configuration card mean that the Assembler or Fortran are not to be loaded, while a C punch indicates that Cobol is to be loaded. (You'd think they'd be consistent, wouldn't you? Noooooo.) Without the correct punches, the load process halted.

Finally, on the morning of April 23, 2002, DMS booted up and printed the cold-start job banner we last saw 25 years ago. This is a copy of that first printout:

PAGE   1

// JOB

LOG DRIVE   CART SPEC   CART AVAIL  PHY DRIVE
  0000        1234        1234        0000

V2 M12   ACTUAL 16K  CONFIG 16K

Who Would Have Guessed?

It turns out that DMS could never have been built on the 1130 itself. First, the 1130's macro assembler does not support the crucial SBRK output directive needed to separate the system overlay modules. More surprisingly, there are bugs in the assembler that prevent proper compilation of the interrupt handlers and trigonometric library routines!

For example, consider this source code line from module R2FSIN.ASM (single-precision sin function):

        R2PI  DEC     1.591549430918954E-1B-2  1/2*PI

This is a fixed point real constant. The generated code from the original IBM cross assembler is:

        517C C1B7 = (.0)01010001011111001100000110110111

while the output from the IBM 1130 macro assembler is:

        5187 368F = (.0)01010001100001110011011010001111

Yikes!

We believe that IBM built its DMS distributions with a cross assembler on the System /360 or /370, and the fiche listings were generated by that mechanism.

Preserving Historic Software

Our experience in resurrecting DMS showed us that an historic operating system can indeed be brought back to life. We believe that the experience of using an historic system adds much to one's ability to appreciate its technical and historic significance. It also provides a concrete motivation to preserve not only hardware and software, but also the body of knowledge and experience necessary to support and operate them, much of which never made it to written form.

We also learned several lessons:

• It can be difficult to know what to call an "authentic" or canonical version of a software package. For example, the source code files sent by Oscar Wyss are labeled modification level 12, but our M12 microfiche include some bug fixes not found in the files. We can't trace the ancestry of our code, so we can't exactly claim it as the authentic, original version.
• It's crucial that system documentation be maintained, and it's best if internal developers' documentation can be found.
• A serious effort to preserve software systems should involve interviewing people who used, developed and maintained these systems in order to capture crucial experiential information.