Puzzled, I went to the data center manager's office and introduced myself. I noticed that my card deck and output listing were sitting on his desk. His first question to me was a strident, "What do you think you are doing?!?!"
I told him I had submitted the uncompress job for my class project and asked him if there was a problem. He told me I had crashed their mainframe -- three times!
I was horrified. But then I thought for a second and asked, "Why three times?"
It turned out they had run my job the first time in a batch with all of the other class projects. The mainframe crashed, but that was somewhat expected, as system stability was not what you'd call "six sigma-ready" by any means.
After restarting, they ran the class project decks a second time -- and the mainframe crashed again. By then, they had a clue that the batch of card decks was the culprit. After restarting yet again, they ran each batch job deck one at a time. When they ran mine, it crashed the mainframe for the third time.
I was as surprised as they were about what happened, and apparently the manager believed me -- but he held on to my card deck while I tried to figure it out. The instructor also gave me time to research what had happened.
It turned out I had inadvertently uncovered a bug in the operating system. GCOS used two-character file codes for input and output file designations. The default value for an input file was
I*, which is what I coded for the uncompress utility. But it turned out that running this utility program with the default file code of
I* caused an immediate system crash. The file code that worked was
I corrected my card deck and convinced the data center manager to rerun my class project. I was proud that it worked correctly on the first compile after the code was uncompressed. The data center manager seemed relieved it was such a simple problem, the instructor accepted my project late, and the company was notified of the bug, which was eventually fixed.
I later found out that the reason the data center manager was so suspicious and upset: This Customs Department mainframe contained highly confidential data, such as locations where seized contraband was located. He thought I might have been trying to access sensitive information.
Hearing this, I was even more relieved that I'd convinced him that what happened was accidental and not a threat. On further reflection, I told myself that while it's necessary to be cautious, I would never first assume malicious intent when someone did something to cause problems in a data center -- a notion that's served me well to remember many times since.
Do you have a tech story to share? Send it to firstname.lastname@example.org. If we publish it, you'll receive a $50 American Express gift cheque.
This story, "Class project: Crash the federal data center," was originally published at InfoWorld.com. Read more crazy-but-true stories in the anonymous Off the Record blog at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.