Class project: Crash the federal data center

Disaster turns into discovery as one techie's homework assignment wreaks havoc on a government mainframe

Page 2 of 2

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 IN.

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 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 Read more crazy-but-true stories in the anonymous Off the Record blog at For the latest business technology news, follow on Twitter.

| 1 2 Page 2
From CIO: 8 Free Online Courses to Grow Your Tech Skills
View Comments
Join the discussion
Be the first to comment on this article. Our Commenting Policies