The Most Epic Computer Glitch and the Magic Behind Mainframe Software
Back in the 1970s, when I was leading a team to install a 2-arm robotic tester for checking the wiring of mainframe computers, we faced one of the most epic glitches in computing history. This event not only tested the limits of the system but also helped me realize the power of programming and the importance of attention to detail in software development.
A Hydraulic Robot Glitch
Our project involved a System 7 computer controlling a hydraulic robot designed to check the wiring in 303X mainframe computers, being manufactured in IBM’s Poughkeepsie factory. The robot was controlled by an operating system and application program that I had written. However, one day, the System/7 computer suddenly stopped with a parity error message, leading to an urgent call to my manager: “Tell Dave to get his ass to Poughkeepsie to fix his damn software.”
But, I knew the message was misleading. There was no command in the System/7 that could create parity errors. The 303X computers sold for three to five million dollars each, and my excuse didn’t matter. Nevertheless, I found myself in Poughkeepsie, trying to solve the issue. After thorough examination, I discovered that the robot’s filter, which kept the hydraulic fluid clean, had gradually become clogged, resulting in static electricity buildup. In the cold and dry ambient air, the static electricity built up until it suddenly discharged, causing the glitch. Replacing the filter resolved the issue, and everyone was happy again.
The MAPPER Software and the Magic Happening
Years later, in the early 1980s, I began using a mainframe software called MAPPER, which was originally created by a Sperry person to help manage factory operations. Despite its simplicity by modern standards, MAPPER was a powerful tool, allowing for the manipulation of 132-column lines to store specific data types and perform mathematical operations. Despite its limitations, it was a game-changer in its time.
Initially, I started using MAPPER for mundane tasks such as checking technical drawings for image quality. However, my true passion blossomed when I began pushing the software to its boundaries. I discovered an interesting transformation function that could handle more than the 24-line limit documented in the manual. Ignoring the instructions, I experimented with the function, going beyond the limit to see how it would respond. To my surprise, it worked perfectly for 30, 40, and even 50 lines, but the moment I pushed it too far, the mainframe crashed.
This glitch was not an isolated incident; other users experienced similar issues. After much troubleshooting, my colleagues and I discovered that a lazy bit of code in the function did not test or restrict the limit on the lines, leading to the crashes. The moral of the story is clear: don’t write a limit in the manual and fail to code for it in the software. This oversight made mainframes unhappy, as they struggled to handle the unexpected behavior.
Conclusion
These stories highlight the importance of meticulous attention to detail in software development. While they were challenging, they also provided invaluable lessons that shaped my programming career. Whether it was solving a hardware issue or pushing the boundaries of a software tool, these experiences taught me to think creatively and solve complex problems.
Today, as a Google SEOer, I strive to bring these lessons to my work, ensuring that our content is detailed, precise, and well-structured to help users and search engines alike. By understanding the history and complexities of computing, we can better serve our audience and contribute to the ever-evolving digital landscape.