As we learned last week, G.R.G. has had a whole lot of experience in the IT industry. He’s even had the opportunity to work on a bona fide supercomputer. In fact, that’s where he got his start: he was one of twenty-five programmers that worked on one of the world’s most powerful computing machines. This supercomputer was capable of processing – brace yourselves, readers – several million instructions per second. Each and every second.

Of course, that kind of power did not come cheap. Not only did the supercomputer cost several million dollars, it required a round-the-clock staff of dozens to maintain and consumed enough electricity to power a small neighborhood. You might very well be wondering, what could anyone possibly need such incredible computing power for? The answer is simple: it was partitioned off and resold for $2 per CPU second. Or in today’s dollars, $10/second.

Because computing time was so expensive, the operating system needed to be very lean and economical. It lacked most things that we take for granted nowadays: no subdirectories, seven characters per filename, one process per user, no networking, and, most certainly, no visual text editing. Although this allowed for speedy compilers and run times, the way it achieved some of the most basic tasks – such as finding the request program to load – was rather asinine.

The supercomputer’s operating system lacked the concept of a "search path." When the supercomputer was booted up, a big ole’ tape reel containing the Boot Tape would start spinning. And spin. And spin. The bootstrap code would read the entire Boot Tape and write it out to a special system disk about the size of a dishwasher. The system directory could only be written to at boot-time and had to contain every system command, file, and utility program.

When a user typed in a command, the operating system would first look in the giant system directory. If it wasn’t there, it’d look in the user’s home directory. That was it. There were no other possibilities.

Though that may not sound too bad, it became a big problem after a while. In order to add a command or utility to the system, a programmer would have to mount a blank tape reel and then run a cryptic program from the system console that would copy the entire Boot Tape, along with the new program, to the blank tape. That tape would then become the new Boot Tape, and the supercomputer would need to be shutdown and rebooted.

As more compilers, databases, and utilities were added to the Boot Tape, the boot process took longer and longer. With each minute of downtime amounting to $600 (after inflation), a twenty-five minute (and growing) boot process was getting a bit costly. Something had to be done.

The supercomputer’s manufacturer was in the middle of developing some revolutionary new process called "boot from disk," Not only did it promise to shorten the boot-up time, but it would allow the system directory to be written to after boot, thereby allowing tools to be added without requiring a reboot. Of course, no one was actually sure if a technology could ever work and, even if it could, it was more than a year away from being production ready. Something else had to be done.

The neophyte that he was, G.R.G. suggested a simple approach: add a few lines of code to the command finder that would look for the program in another directory if it couldn’t be found in the system or user directory. At most, it’d take at a day or two to implement. The star programmer, however, had a different idea: he’d write a special program, RUNPROG, that would do the job.

This proposal had the system staff up in arms: the operating system was very limited and it was nearly impossible for the command finder to spin off another program like RUNPROG. And with the limited and expensive memory of that era, running an extra program just to run another program was incredibly high overhead. Naturally, sanity did not win out and the star programmer was given RUNPROG project.

The concept behind RUNPROG was simple: it would abstract command finding and running into a single program that would, therefore, allow for easy, future expansion and extra features. The first "extra feature" idea was to have RUNPROG read through a special "alias file" that would allow sysops, for example, to have a command named "XBCALC" to run the file "GLPROC." Seems fairly reasonable, but it came at quite a cost.

Since there was no easy and low-overhead way for RUNPROG to ask the system to execute a certain program, RUNPROG would have to implement its own program loader. This meant reading programs from disk, loading library code, loading program code, executing it, and all sorts of other things normally done by the operating system.

The program loader module within RUNPROG ended up taking a lot of much-needed memory, which meant that RUNPROG needed to become an own overlay loader as well. Another fairly complex task, overlay loading involves swapping executable blocks of code in an out of system memory so that the overall memory footprint of a program is much smaller. It’s more or less a program-level implementation of virtual memory.

In addition, RUNPROG needed to be able to load "archived" programs from tape. Typically done by the operating system, RUNPROG would have to determine if a particular file was archived or not, and then find which tape it was archived on, request it from the tape library, wait for the tape to be mounted, read it from disk, etc. And this of course meant that RUNPROG would need to run with the highest-level privileges, meaning that it was very risky to modify.

And it just kept going and going. RUNPROG grew to an enormous size (nearly 100,000 lines of complex assembly code), took months to debug, and cost thousands to rebuild (it sat on the Boot Tape). Eventually, it worked. Although the same effect could have just as easily been accomplished with a simple modification to the command finder, most quickly forgot that fact. After all, RUNPROG more than made up for its development costs in that it allowed for programs to be added to the system without requiring a new Boot Tape to be written. That is, until Black Tuesday. But I’ll save that story for another day …

Fortunately, we’ve all learned from the mistakes of early programmers. I’m happy to say that, since that day, there has never been an overinflated piece of software that won out over a much simpler solution, and the phrase Scope Creep is deader than UNIVAC.

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