The Four Yorkshiremen, punched cards, and other tales of woe

Oh, there's so much stuff out there on the Web. I recently came across The Art of Unix Usability by Eric Raymond and Rob Landley. Talk about "memory lane" ...

Not so much concerning the Unix aspects of this book, but some of the other they describe from the "dark ages" of computing: way back in the dark ages of the 1960s and 1970s. Thoughts of my first ten years at IBM (during the 1970s) came flooding back to me. And the pictures in this free online book that got to me were the Teletype machine with its paper tape input/output, the IBM 029 Card Punch, batch computing.

I hope that you've listened to the classic 1974 Monty Python sketch "Four Yorkshiremen"

Well, I have my own version of this tale to share with you.

- - - - - - - - - - - - -
In the mid-1970s I spent a year or so going out on a limb and working on the IBM System/7 (see The sentinel: the IBM System/7 and IBM System/7 and Plant Automation). At that time, the System/7 was a leading-edge sensor-based, real-time computing machine. These days we'd considered it vastly underpowered and prohibitively expensive, but that was then and this is now.

These days, a few thousands dollars will get you a desktop or notebook PC that is vastly more powerful than systems that cost hundreds of thousands of dollars in the 1970s. And the software (operating systems, developer tools, programming languages, desktop productivity applications) are in many (but not all) ways so much more advanced than what was available way back then in computing "prehistory."

Here's my version of the "Four Yorkshiremen" story, from 1975 or 1976...

1. I volunteered to work on a project that involved a set of IBM field developed programs (FDPs) called "Plastic Injection Molding System" or PIMS for short. This was a set of sensor-based applications for the monitoring and control of plastic injection molding machines. (It was 3 or 4 months into the project before I ever laid eyes upon one of these machines, which didn't help in extending the PIMS software.)
2. The PIMS package detected events happening on the injection molding machines such as the molds opening and closing, and you could get reports on demand by entering various commands into a Teletype console.
3. The IBM customer essentially wanted (a) to get a report automatically generated at the end of each 8-hour shift (rather than just on demand); (b) the machine operator to be able to press a button every time a faulty part was molded, and get the number of faults included in the shift reports; and (c) whenever a molding machine went into maintenance mode, the shift supervisor had to insert and turn a key to indicate this, when it went back into production mode the supervisor had to turn and remove the key. and the total time in maintenance had to be recorded and reported for each shift. This involved making some fairly basic changes to the PIMS package, rather like working on an operating system with very low-level assembler code that had to take into account hardware interrupts of all kinds. It was extremely interesting, but also rather challenging.
4. Once I had learned the System/7 Assembler Language, I got stuck into the real work. The code changes were punched into IBM 80-column punched cards by keypunch operators at the IBM's then office at Sturt Street in South Melbourne (long ago converted into apartments). This card deck got bigger and bigger as the project progressed, eventually filling several card boxes (a pile of cards at least a metre in length, always with the nagging worry that somebody would put them out of sequence).
5. The card deck went into an at-best daily assembly (compilation) run, overnight, at the IBM Data Centre. It usually generated a listing a few itches thick, but one night it went haywire and I found three full boxes of printout waiting for me the next morning!
6. Being rather complex assembler code, it didn't always come back clean the next morning (and that's putting it mildly). This usually meant several days went by before a clean assembly was reached and things could progress to the next stage.
7. I then had to take the punched card out put deck from IBM to the Mobil data centre, so that the deck assembly code could be transferred to paper tape. (IBM didn't have a paper tape punch machine in their own data centre in Melbourne.)
8. The punched-card output deck held a representation of System/7 machine code, not human-readable alphanumeric characters. Some of the cards in a deck were extremely flimsy, because the machine code on them was so dense that more than 50 percent of the card had been punched out as "chads" (see binary punched card). When the cards were read in at the Mobil data centre, sometimes a card or two would be torn up during card reading. I would then go back to their data centre to carefully flatten out and reconstruct each torn card, then painstakingly (on an IBM 029 Card Punch machine) re-create the card, put it back in (hopefully) the correct sop in the card deck, and resubmit it.
9. If the cards all managed to be read in without damage at the Mobil data centre, they would then punch out a paper tape image of the System/7 machine code. Naturally, this step had its problems: for example, the paper tape punch took some time to "warm up" and could generate a faulty image. This happened several times, each time adding an extra day to project duration.
10. I would take the paper tape, then drive (some 15 or more miles southeast of downtown Melbourne) to where there was a System/7 machine installed at another IBM customer site. I would power it up, then carefully feed the paper tape through the Teletype console into the System/7's memory. Only then could I start testing and debugging my modifications to PIMS.
11. If the program didn't cause machine checks, I could then save it in an electronic form. There was no hard disk on that particular System/7, so guess what this was: would you believe onto cassette tapes! (There was no hard disk on that System/7 until right near the very end of the project.)
12. If the program test failed, it meant going back to step 1 again.
13. After a while -- quite a few weeks, I can't remember how many -- I had something that might possibly do what the end customer required.
14. Five or six months after project start (fast for those days) the end customer's System/7 was delivered. It got wired up to the injection molding machines, and at last I was able to start visiting their factory (about ten miles west of downtown Melbourne) and perform testing in the real production environment.
15. After a fair number of repeats of the above steps, my modifications/extensions to PIMS started to do what was expected.

As you might gather, it was all a rather painful experience. A far cry from the things that can be done in the 21st century, and the relative ease with which they can be done. But I don't regret it for a moment, and I certainly learned valuable lessons from it that stood me in good stead later on.