Last month, in Saving a Few Minutes, we learned about G.R.G.'s experience with RUNPROG, one of the earliest examples of The Inner-Platform Effect I've ever seen. RUNPROG lived on an ancient supercomputer with an operating system that lacked the concept of search paths. Instead of a simple, four-line enhancement to "search another directory," RUNPROG was a 100,000-line assembly program that essentially did everything that the operating system did.

Although RUNPROG was entirely unnecessary, cost an incredible amount of time and money to maintain, and caused programs to run and load a magnitude slower, the business did not mind. It saved them money in the long run in that it allowed them to bill out even more CPU-time to their timesharing clients. In fact, after three short months of production use, the business had already forgotten the pain endured to create RUNPROG. That was, until Black Tuesday arrived.

You see, the Star Programmer who had built RUNPROG was an Optimizer. He knew the exact cycle times of each and every CPU instruction. He knew which instructions could overlap the execution of previous instructions. And he knew how to program assembly code to take advantage of every single cycle.

In the scope of his overall solutions, optimizing like this was like turning down the radio in a Hummer to improve gas mileage. And even if that analogy could work back in those pre-Hummer days, the Star Programmer would just shake his head and disagree. To him, every nanosecond was precious and must be saved.

One of the Star Programmer’s favorite “optimization” techniques was to use 18-bit math instead of 60-bit math. Computing all those other bits was a waste of ninety-one perfectly good nanoseconds. So, when it came time to increment the program access after each program was run, the Star Programmer used the 18-bit add instruction instead of the 60-bit one.

In testing and debugging, it worked perfectly well. But when it came time to actual usage, one particular program – the FORTRAN compiler – was used quite a bit. After a few months, the access count on the compiler incremented all the way up to 131,071. Anyone want to guess the number that comes after 131,071 in a ones-complement, 18-bit signed register? Why, Negative Zero of course! And the number after that, -131,071.

One of the many “features” of RUNPROG was that it would automatically move rarely-used programs to magnetic tape. Granted, even back then, there was ample disk space for programs, but the Star Programmer just hated to be wasteful. And what could be more wasteful than letting a rarely used program consume thousands of precious bits.

When RUNPROG saw that the FORTRAN compiler had been accessed -131,071 times, it informed the operator to mount archive tape #241. The operator then went to the tape library, mounted the giant reel, and – like in some 1960’s Doris Day movie – the tape started spinning. And like that, the FORTRAN compiler was no longer on disk.

About thirty seconds later, some poor sod submitted a FORTRAN program to be compiled. Since RUNPROG couldn’t find it in the system directory, it looked inside the tape catalog f and sent a message to the operator to mount archive tape #241. Like they were trained to do, the operator went to the tape library to find #241. It wasn’t there, so he went to the recent tape stack. It wasn’t there, so he looked at the tape drives. BINGO! He typed in “/AT241=4” and eventually the FORTRAN compiler started to run.

Meanwhile, RUNPROG incremented the compiler’s access count to -131,070, and dang, there was another little-used program that had to be sent out to archive tape. The operators of those days were trained to do exactly what the computer told them, so they simply followed the archive/restore cycle time and time again. Their jobs went from mounting a tape or two every hour to mounting a tape or two every minute. They weren’t happy.

The operators’ supervisors had just assumed that the company had gotten really busy and offered little consolation to the constantly busy operators. The operators responded by coming in late, calling in sick, and constantly moaning about their ever increasing work load. They eventually realized that, not only could make as much money per hour at the local Arby’s Restaurant, but that they’d also get free meals there. So they quit en masse. Only then did management realize there might be a technical problem.

The Star Programmer was called in and he immediately realized what was happening. In a Nick Burns-seque manner, he shooed away the operators and fixed the problem with RUNPROG. The operators were thrilled: it was back to their laid-back job of occasionally moving tapes back and forth.

And of course, by “fixed the problem”, I mean that the Star Programmer simply deleted the access count data file. The problem would undoubtedly return in a few months. But that was okay. It would take him about as long to figure out how to fix all the code in RUNPROG where he had saved the ninety-one nanoseconds by using 18-bit arithmetic.

[Advertisement] BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how!