6. Program abends
While studying computers at the State University of New York at Binghamton, one of my classmates had a cat name Abend. Some other people I met had a cat name Cat and a dog named Dog, which probably didn’t take much thought. I thought Abend was an appropriate name since we were studying computers. The word abend is a contraction of the phrase abnormal end, which many programs and systems do and with which not many people are happy. It means working overtime and on the weekend. If you read my book, Tick Tock, Don’t Stop: A Manual For Workaholics, you probably know that working more than thirty five hours a week doesn’t thrill me too much. My second book on work, This Page Intentionally Left Blank – Just Like The Paychecks Of The Workers, advocates a thirty-hour workweek, which I think is a better idea. You may have heard of Timothy Ferriss’s, The 4-Hour Workweek, but that may be a bit drastic and cause a few headaches. I doubt that management would approve.
In information technology there are quite a few ways for abends to occur. A program could encounter bad data when it is looking for a numeric field and instead finds letters of the alphabet. The result is the program terminates. A system could run into a space problem and the result is an abend. There could be an I/O problem in that a program is reading a file on magnetic tape when the read fails. The cause may be something as simple as the fact that the tape drive missed its normal maintenance cleaning, but it could be something else.
There could be a disk crash or you could run into bad sectors on the disk and the results could be really annoying. I had the hard drive on my personal computer replaced a few summers ago and it wasn’t much fun. The word crash seems to be another way of saying that we had an abend because they are one and the same. I was editing a page of this book on my word processor when I tried to save what I had added and couldn’t. The only way out was shutting down and restarting, which resulted in my recent changes being lost. And I thought computers were supposed to make our life easier.
Each of these possible scenarios has to be controlled. If not, there is no sense in having a system because reliability is compromised. You might be spending more time with your computer than if you had a manual system. Obviously there will be difficulties from time to time and you will have to put up with the problems, but you need to do everything possible to limit these troubles.
To avoid space problems you have to maintain files, eliminating those that are out of date or redundant. It may be as simple as backing up these questionable files to a tape so that if they are needed, they can be retrieved. This leads to valuable space being saved. Another kind of maintenance has to do with backing up a file and then redefining it and restoring it from the backup. What this does is eliminate fragmentation, which happens to files when they happen to have gaps in the data or be on multiple disk packs. One of the maintenance tasks on PCs is checking for fragmentation on the disk from time to time and taking action if necessary. Another way of helping alleviate the space problem is eliminating duplicate data on a file, which I will get into later. There’s much that can be done and it will depend on your environment.
Avoiding system crashes is almost impossible but if you have some kind of recovery technique that can minimize the damage, you will be one step ahead of the game. You won’t be able to tell how reliable a specific disk from some manufacturer is until you use it. However, talking to other corporations can give you some insight as to whom to avoid and who may have a worthwhile product for you to use. You’ll have to do a great deal of homework but it will eventually pay off.
Power failures could cause nightmares so you need some way to handle them. The solution may be as simple as backup systems on temporary generators so you won’t even feel the effects. Unfortunately it may not be that simple. You could be blessed with so few outages that it won’t even be a concern. Consider yourself fortunate.
You won’t be able to live without backup of your files and systems. If you have programs that update files, backups at the appropriate time will save you from a great many headaches. You may need to restore files to some point in time but you won’t be able to do that without the right backup. If you use the one from the weekend, you could lose a great deal of data and time even though some files have been restored. Once again planning your system should reduce problems to a minimum.
Despite all precautions, even the best intentions can result in major screw-ups. In the early 1980s, I worked full time for a computer company in the software department. My assignment was that of a consultant without commensurate pay. I quit the company after about a year and a half when I saw that there seemed to be no future in this specific business. While I was in their employ, I was asked to create a purchase order system and I was given two options: modify an existing system that the company had or write one from scratch. I was specifically directed to determine my approach with some analysis, so I set forth and discovered that using what was there would have required more time and effort. Nonetheless, my boss insisted that I write the purchase order system using the program in the software package at our office – that wasn’t a good idea.
I should have wrote the system my way and not told a soul about it but instead I foolishly did as told. The result was that my boss complained when it took longer than he wanted me to spend. When I was done though, the effort was top-notch and the clients were pleased as punch – whatever that means. They used what I produced and couldn’t have been happier with my creation.
Unfortunately, Murphy showed up one day. You’ve all heard of Murphy’s Law, so you know what I’m talking about. What happened was that the client ran into a problem one day and had to resort to the backup of their system. Their practice had been to do a daily backup of the system in case of any problems. When they tried to restore the system from the backup, it turned out that it wasn’t worth spit. They went back a few backups but even those were as worthless as Tom Delay being in charge of the ethics committee. Going back like they were doing meant that they would have lost a few days activities, but at least they had a system.
The problem was that the tape drive backup wasn’t working and it hadn’t been for some time, even though it appeared to be fine. I’m sure you’ve seen numerous examples of technological processes that seemed to be working when in actuality nothing was happening. That was just what was taking place with the purchase order system daily backup and there was no suitable backup. Fortunately, the office where I worked – at the time – had the purchase order system still on their computer. Well, had is the operative word because one of my co-workers deleted it there. He didn’t do a backup first but simply eradicated it. As you can guess, that wasn’t very intelligent.
By this time I had left the company but was contacted about the fiasco at home. I mentioned that on the desk where I spent my days at the office was a tape with the purchase order system. Restoring it meant that the client would have to start data entry from the beginning, but at least they had their system back. You probably guessed the ending of this tale, but if not, I need only mention Murphy. Sure enough, someone had used the tape by writing over it and the system was lost forever. I didn’t return to the company to redo the system and I am not sure of the relationship between the company where I had worked and the client. I do know that within a few months this computer company bit the dust.
Returning to our discussion from my digression, I/O problems may be reduced by consistent hardware maintenance but bad data will require considerably more effort. You should never have a program that abends because of bad data caused by a field generated by the system. Any program that accepts input to be used as fields in a file should guarantee that this field will never result in an abend due to bad data. If the field is numeric, the program should never accept any other type of data into this field nor should it ever write out this field to the file if it is not numeric. This may take a bit more programming but it will result in evenings and weekends with virtually no calls from the computer room. That will make your time at home more enjoyable.
Problems will occur no matter what you do and no matter how careful you are designing systems. The steps you take will differ from system to system but you need to minimize the effects of crashes and software failures. As we get into further sample programs, I will offer some suggestions to help reduce the frustration without leaving your place of employment or jumping off a twenty-story building.