A Bad Way to Start Your Programming Career

 

Do you remember fifty years ago? Were you even alive fifty years ago?

I suspect that for most of you, dear readers, that the answer to both of those questions is NO.

But I remember early summer 1966 quite well. I had just started my first job as a computer programmer at the Federal Deposit Insurance Corporation (FDIC).  I was writing my second professional program and I was about to destroy my boss’s computer program.  And because this was 1966, there was no electronic backup of his program code.

In 1966 things were very primitive by today’s standards. FDIC had recently acquired its first computer, an IBM S/360.  It was the newest, most advanced business computer that IBM made.  But as you will see, that didn’t make it powerful or full functioned.

Our new computer had 128 KB of memory. By way of comparison, the 5 year-old desktop computer that I use to write this blog has 2 GB of memory.  That is more than 15,000 times as much memory as my first computer at FDIC.

But more important to this story, the FDIC computer had no permanent data storage. Again, for comparison, my smartphone came with 16GB of data storage built into it.  If you need to store something on your phone, it’s a no-brainer.  You just do it.  But in the summer of 1966 our computer had no permanent storage.  If you needed to store something after a program had completed, you wrote the data to a reel of magnetic tape.  Every programmer had at least one magnetic tape reel to use for storage between program runs.

There was one other option for storing data. You could create punched cards.

In those days, programs and most data were entered into a computer using punched cards. These stiff, heavy paper cards were standardized at 3¹⁄₄ by 7³⁄₈ inches.  They were eighty columns wide and twelve rows high.  A keypunch machine was used to punch the computer coding for letters, numbers and special characters onto these cards using a standard QWERTY keyboard.  To facilitate keypunching, programs were hand coded onto to coding sheets which contained eighty boxes per line corresponding to the eighty columns on a punched card.

Computers also had a card punch function so programs could create data on punched cards. Don’t ask me why you would want to do this, just accept that you could do it.  All computers had a card reader/card punch device attached to them.  Some devices had two areas to load cards, one for already punched cards that were to be read and one for blank cards to be punched.  Some devices only had one area to load cards.  If you were going to create punched cards in your program, you stacked blank cards after your program deck.  We had the second type of device attached to our computer.  Our programs didn’t create punched cards.  So all we needed was a card reader.

In order to run a program in those days several steps were required. The first was to compile the program.  This step changed the COBOL code, that we used to write programs, into code that the computer could process.  This was followed by a step called Link Editing.  Never mind what this was, just be aware that it took a long time to do.  Since you could sometimes run more than one test without changing your program, it was common practice to write the ready-to-run program to your magnetic tape.

Interestingly enough the default output device for our computer was the card punch machine. The computer would only write to your tape if you included a special card in your deck of punched cards that contained an instruction to the computer overriding its default.

Did I remove this card by mistake? Did I forget to add it to my deck?  It doesn’t matter, it was missing.  And as you have probably figured out by now, the computer cheerfully did what it was told to do.  It punched my ready-to-run program into the cards stacked behind mine in the card reader.  And, of course, since this shouldn’t happen, they weren’t blank cards; they were cards containing my boss’s program.

I did survive to join in the later joking about stupid things done by rookie programmers. And since there was an almost current listing of my boss’s program, all it took was keypunch time and recalling the recent changes he had made to have his program up and running again.  Still there was no way to make an electronic back for recovery if someone else made the same mistake.

The programs we wrote may not have been very sophisticated by today’s standards but it was much easier for us to destroy things.

 

This is the first of a series of posts that I will be writing on the history of business computing as I lived it. If you have any suggestions for what to include please leave me a comment.

If you enjoyed this article, please share it with others using the buttons below.