Return to Stories

by Keith Falkner

In the documentation of some 1401 programs, we see a list of halts, probably numbered by the B-Register contents, and the notation "Should not happen". That is shabby documentation, because in fact these halts sometimes occur, and a programmer has to find the program's listing, dig through it to find the halt in question, and decipher the code to find what can cause the halt. This is not an easy task for a programmer unfamiliar with the code, and many programs have far too few comments to be readily understood. It's true, I once had to repair a program that had only one comment in its 2800 cards, specifically IF WOODEN SHOE. I never figured out what the programmer meant by that, and indeed much of that program remained a mystery to me, yet somehow I effected the required changes.

I made it a practice to have only one halt apart from the end-of-job halt, and that halt was always preceded by a printed sentence describing the cause of the halt in English. And I programmed lots of reasons to halt. An update program should check the sequence of its input master file; an error in the sequence of data is a serious logic error, and will cause no end of grief to all users of that file. What could be more important than checking the input master file's sequence? I will tell you what is more important: checking the sequence of the OUTPUT master file as it is being written. This is the same tape file that will be read and updated on the next cycle, so it is better to learn about a serious program error when it happens than a month later!

A lot of programs deal with money. That certainly makes sense; what better machine to compute finances than a computer? When I dealt with money, I ensured that I didn't create or destroy any money. When the program commenced dealing with any account, it read in a starting balance-owing and remembered that. When a payment came in, the program reduced that balance; when the program effected a sale, it augmented the balance, keeping all these figures separate from any counters in the master records it was updating. When the program wrote out a new balance-owing, it subtracted that amount from the internal counter, and made sure the result was zero; otherwise, it admitted its error and halted. I found that few of my colleagues bothered to do such self-auditing, but I considered monetary safeguards to be a necessary part of any program that dealt with money.