The thrilling saga of a database gone bad

True Tails

Article from Issue 192/2016

In which our hero relates a "True Tail" where lack of testing almost created a divorce.

Recently, I wrote that programmers typically make some of the worst testers of their own software, based on the logic that if programmers knew enough about the bugs, they would write the program correctly in the first place. Of course, this is a generalization and led to lots of discussion about unit tests, regression tests, and many other types of tests used to validate code.

On the other hand, many people agreed with me, based on experience of sending the code out to end users and hearing a programmer scream, "I never thought someone would use my code that way." To illustrate this last point, I will relate one of maddog's True Tails(TM).

The year was 1975, and I was working for a very large insurance company. We had 500,000 12-inch, nine-track tapes in our on-site tape library, numbered from 000001 to 500xxx, and each of those tapes had an external, human-readable number with the same internal machine-readable number on the tape.

We had large databases that were backed up every night, and it took seven or eight of these tapes to back up the database. If something went wrong, you had to restore the database from those tapes, in the same order that they had been produced.

Sometimes, things did go wrong because the operators (being human) lost the record of which tapes had been used for which database, or put the tapes into the restore program in the wrong order, or a tape was missing in the library, and the restoration would not be correct.

A friend of mine wrote a program that captured the tape numbers from the backups and would store them in a database (yes, that database was also backed up). If you typed in the name of the database and the date to which you wanted to restore it, the program would generate the control software (called Job Control Language, or JCL) to run the restoration.

My friend asked me to test his program. I started his program, and when it asked for the date, I typed in July 5. The program crashed.

"You are not supposed to type in the date like that, you should type in Year, Month, Day in numbers," my friend said. I told him that there was no prompt, so I did not know.

He then changed the program to properly prompt for the date. I tried the program again, and this time when it asked for the date I typed in the word Junk. The program crashed again. My friend said I should have typed in what was asked. I pointed out that when the database is down the operators are under stress, and they might type in something incorrect. Thus, he should test to see if the input is a correct form and that it's a probable date (not later than today, not 300 years ago). He went away again.

He later came back proudly and asked me to test his program once more. This time, I just hit the Enter key without typing in anything. His program crashed again, due to "buffer underflow."

Two days later, he came back with a sneer on his lips. I tested his program again, and it did seem to do proper editing on the input, and it did generate the proper output, so he submitted the program to the pool of operational programs.

A few days later, I had to do some tricky work on the database, so I asked if he would be around in case I needed to restore the database and his program failed. He said that night was his first wedding anniversary and "please do not call me."

Later that night, I encountered problems with the process; the database was corrupted, and I tried to use the program to restore it, but the program failed. It was 2 o'clock in the morning.

I called my friend and heard a small whisper, "Jon, it is my wedding anniversary, do you know what that means?" I said, "It means you will not have a job in the morning if you do not get in here and fix this problem."

He hung up, and I looked at the program again. It did not do proper editing on the tape numbers of the restore tapes. One tape had only five digits, not six, in its internal number, which caused a blank in the JCL (which was not allowed). I punched some cards with the corrected JCL and restored the database. At 3:30am, my friend showed up, still in his robe and slippers.

"What are you doing here?" I asked.

Proper testing may be a life saver (or a marriage saver).

The author

Jon "maddog" Hall is an author, educator, computer scientist, and free software pioneer who has been a passionate advocate for Linux since 1994 when he first met Linus Torvalds and facilitated the port of Linux to a 64-bit system. He serves as president of Linux International®.

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy Linux Magazine

Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

comments powered by Disqus
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters

Support Our Work

Linux Magazine content is made possible with support from readers like you. Please consider contributing when you’ve found an article to be beneficial.

Learn More