Today as I was pondering some modern architectural paradigms, I got to thinking about my procedural programming roots, which led me down memory lane to my early computing days.

Basement Computing

Back at university, my computer science classes taught me about bubble sorts and data structures like linked lists and b-trees. We learned to write a structured FORTRAN program when the compiler didn’t enforce the structure. We learned Pascal, which did enforce the structure. We did a little assembler on PDP 8s and PDP 11s, pressing a toggle switch and watching the registers change. To use the bigger CDC computer, we descended to the basement of the Technical Institute to submit our programming lessons as batches of card. We waited impatiently until the traction-fed output was wrapped around the card deck and stuffed in pigeon-hole style mail slots. One of the student employees placed a sign above the window that promised, “A $5 bill behind the job card reduces turnaround time.” Eventually we progressed to a room full of data terminals.

Once I got into the real world in 1979, this all proved pretty much useless; I was asked instead to use COBOL to read in magnetic tapes full of historical accounting data and print various reports.

That company used a water-cooled IBM 370/168 that looked a lot like the one pictured above. What is not shown in the picture is the raised floor required for all the cables, nor the the garage-sized room full of backup batteries. Of course mere mortals were not allowed to touch the computer; the computer room, with its arctic air conditioning, was secured behind keycard-locked doors and took up a goodly portion of the building’s basement. Unescorted programmers could get as far as an outer lobby and peer through the glass at the humming blue monster. The machine’s operations manual lined the side of this outer vestibule in a five-foot-wide binder rack.

Punch Drunk

Actually, we programmers didn’t have to go down to the basement that often. A team of half a dozen key punch operators sat in a small room adjacent to the computer room. We could write our programs out on wide coding pads with a small block for each letter, then send them via inter-office mail for keying. They would then take these pads and create stacks of punch cards for us.

I don’t think many people today fully appreciate how a key punch machine works. Every time you press a key, it punches a hole in the card. Well actually by this time, the IBM 129 Card Data Recorder was in use, which held an entire card (80 characters) in a buffer so that it was possible to back space if one made an error. When you finished the card, you pressed a Release key to punch the entire card. To ensure accuracy, each coding pad (or data entry sheet, as this is also how customer data got into the system) was keyed in twice, by different operators. The first operator punched from blank cards. The second operator re-entered the same data but with the already-punched cards in the hopper; if a discrepancy was found, the operator rejected that card and created a new one.

Even with turnaround of only a few hours, this process of dropping off coding pads for punching was rather laborious, especially when the only change required was to add one of those pesky periods that COBOL was always complaining about. So we also got a card punch machine for the programmers to make minor modifications. I remember how excited I was that we got one with an LED display that actually allowed looking at the text before punching it.

Winds of Change

By the time I left that company in 1984, we had advanced to IBM 3270 display terminals connected directly to the mainframe. Although some “old school” programmers didn’t like the thought of having to type in their own programs, I thought it was great. I loved the powerful editor (XEDIT) on those terminals that could do things like display only the lines containing a certain string.

Also by 1984, we had started getting into a revolutionary relational database from Germany called Adabas. The concepts I learned then about database normalization still apply today. We were starting to plan for interactive programs that would actually allow end users to look up and enter data on demand. We were reading Tom De Marco’s Structured Analysis and System Specification. There was even a PC or two knocking around, mostly used for word processing. I remember one of my colleagues who was convinced that the PC was going to revolutionize computing. He planned to buy one, quit his job, and start his own computing company. I thought he was a little crazy.