Keeping stuff: How to preserve course papers despite technological change

Punched cards

In 1972, I took my first course in computer science. For this course, we were allowed to use key punches, which were hot, noisy, desk-sized machines with keyboards, for creating punched cards. We prepared our programs on these machines, one card for each line of the source code. One key caused the mechanism to pick up a blank card from a hopper at the right and wrap it around a drum facing the typist; each letter and number key caused one or two rectangular holes to be punched through the card stock, in a vertical column, and advanced the card to the next column; another key released the card, allowing the mechanism to rotate the drum and feed the card into another hopper at the left. The card punch also printed the letters and numbers across the top of the card, so as to make them human-readable.

The room in which I operated the key punch also contained three other special-purpose business machines: a lister, which took a pile of punched cards and copied their contents onto fanfold paper; a card sorter, which took a pile of punched cards and sorted them into groups, according to the holes punched in some particular column; and a card reader, which took a pile of punched cards and communicated their contents to a computer. I still never got to see the actual computer, but at least this time it was in the same building, and occasionally I caught a glimpse of one of the operators who extracted the machine's printouts, wrapped rubber bands around them, and placed them in an alphabetical rack under the initial of the user's last name.

There still was no way for me to save any of my programs on line. To run a program again, I had to dig out the pile of punched cards and feed it into the card reader again.

Here is a listing of the first program that I wrote for that course, submitted on January 5, 1972. It's in the FORTRAN programming language. Here is the output, as it appeared then. Our instructor had not yet shown us how to write FORTRAN programs that terminated properly, so this one crashes when it reaches the end of its input data. It was translated by a program called WATFIV, a product of a group at the University of Waterloo, and it occupied the attention of an IBM System/360 for about fourteen hundredths of a second.

I didn't keep the punched cards containing the program as input. I have seen other key punches and card readers since 1972, but not in the last twenty years. It's been some time since I even saw an eighty-column punched card in actual use.

I did, however, keep the source-code listing and the output from the program. The original is on 132-column fanfold paper and was produced, I think, by a line-at-a-time band printer. The printing is rather light, but still legible. By 1972, the designers of fonts for computer printing had already realized the importance of distinguishing commas from periods. You'll notice that the commas are raised so that their tails will not be cut off and that the periods are rendered as small open circles for contrast.

While preparing for this talk in 2001, I typed this program in again, and a couple of days ago I asked the FORTRAN compiler that I currently use -- not, of course, WATFIV, which is long gone -- to translate it, and ran it. Here is the result. The error messages that are produced when the program crashes are quite different, but I am more interested by the appearance of the digit 0 at the beginning of some of the lines. It did not appear in the 1972 output.

The explanation is that, in 1972, FORTRAN programs were expected to output a character at the beginning of each line of output to control the vertical positioning of the printing head: a space simply advanced the head to the next line, the digit 0 skipped a line, some other character caused the new line to be printed on top of the preceding one, yet another caused a break to a new page, and so on. My program generates all those printer controls. In 2001, however, they are no longer needed or even understood. Instead, they show up in the printed output. The spaces are easy to miss, but the 0s are visible, and in addition it's clear that no lines are being skipped in the new output.

Thus technology has defeated me again. Although the source code is readable, the program no longer has the same behavior when executed. To make the 1972 FORTRAN program work correctly, we'd have to change the lines that include the printer controls.