"And this is Colossus," Eric said with a dramatic sweep of his hand.
It was an impressive sight. The PDP-11/70 was a beast of a machine: one megabyte of memory, up to 63 concurrent jobs, and a control panel straight out of straight out of Star Trek.
Sadly, Kevin wasn't properly impressed. Kevin was Eric's new boss, whose main qualification was that he and the VP of Finance played squash together. Kevin knew nothing about PDP systems or RSTS/E, the OS it ran. It fell to Eric to train his new boss how to do his job, and the slack-jaw dangling from Kevin's face didn't bode well.
A few days into Kevin's reign, accounting called. Their complaint, the same complaint they had last month, and the month before that, was that the accounts payable job took too long to run.
"Well, what can we do about it?" Kevin asked.
"What? Nothing, really. It's a big job. It takes a long time," Eric said.
"Can't you boost the priority?"
Eric raised an eyebrow at that; "priority" was likely on Kevin's "Tech Word a Day" calendar today. The short answer was, "Yes, but it won't do anything." Eric proceeded to explain, in small words, that the bottleneck in their environment was disk I/O. The large accounting files couldn't be cached in memory, so accounting jobs spent most of their time trying to get data off of the disk. Even at peak load, the CPU was idle 70% of the time. "Changing the priority only gives them more CPU, which they don't need."
Kevin nodded along, like he understood, and then said, "Great, so we'll boost the priority then. Show me how."
Eric did. When he actually timed the process, it took just as long. But Kevin and the VP of Finance agreed that everything was much faster now, so Eric kept his mouth shut.
Happy VPs mean happy budgets, and they found themselves with a significant hardware upgrade. Two shiny 250mb hard disks ($15,000 each), one disk controller ($15,000), and a second megabyte memory upgrade ($10,000).
The new toys were freed of their packing material and installed. In-memory disk caching was enabled and performance… didn't change at all. Eric, a stalwart veteran of 15 months at this time, couldn't accept that. After some research, he found a patch that altered the disk caching behavior. Instead of trying to explain the details of the RSTS/E caching system to Kevin, Eric simply installed it without permission after everyone else went home.
The next day, the system flew. That 2mb of memory was used to store commonly used data, the I/O bottleneck vanished, and the CPU spent most of its time near 100%.
With this change, Kevin's knowledge became dangerous. Now, when he altered the priority of accounting jobs, he swallowed the entire CPU and blocked anything else from running.
Eric explained the technical problem, this time using carefully selected mono-syllables. "So stop adjusting the priority. You don't need to, it's fast enough for everyone."
"Accounting needs their jobs to run faster. If engineering can't make vectors or flipjacks or whatever they do, too bad."
Eric returned to his desk and scowled at RSTS/E's UTILITY.BAS file, which contained the source code for a variety of system commands, like SET QUEUE, which controlled the priority. It took moments to alter SET QUEUE to ignore attempts to change priority. A quick recompile and Kevin was rendered harmless, again.
This lasted for months, until Kevin learned to read the process report, which was roughly like a lemur discovering fire. "What's wrong with the priority settings?" Kevin demanded, red faced. "Accounting needs their data! Fix it now!"
Eric knew there was no point in explaining things. "I'll look into it." As soon as Kevin turned away, Eric opened up UTILITY.BAS, and this time jumped down to the SHOW QUEUE command. In five minutes, he added logic to make all of the accounting jobs to look like they had a higher priority than they actually did.
Anyone who knew their way around RSTS/E would notice something was amiss, which meant Eric never had to worry about Kevin noticing.
RSTS/E command documentation - you now know more about RSTS/E than Kevin.