Printer jams are an unavoidable circumstance. Paper might not seem sticky, but static electricity and humidity can to horrible things, and all the protections in the world can't stop them. Printers are also objectively terrible, and always have been.

Years ago, when Coyne T was a fresh-faced youth, he supported an aging COBOL-based warehouse system. Their reports went to a noisy continuous feed line printer. The printer was a finicky beast, and no matter what sacrifices were made before printing, it had a tendency to devour pages, or have the gears slip and misprint lines. Because the report data came straight from a COBOL job, there was no cached output to reprint- the entire reporting process would need to be re-run every time the printer got angry.

About thirty pages of a report got chewed up a few days after Coyne joined the team. As the new kid, re-running the report fell to him. "But, before you go and re-run the report," the team lead, Herschel, said, "there's a few things you should know."

Herschel laid out the key facts. The report generating program didn't just generate the report. It also could clear the monthly totals and update the day's inventory as part of running the report. Doing either of those in the middle of the day was absolutely wrong, and would create a lot of manual work to fix it. Even worse, doing both of those during the same run would stomp all over the data files and absolutely corrupt the entire mainframe.

"Fortunately, I added two flags- CLEAR-SWITCH and UPDATE-SWITCH. Just make sure they're both set to 'N', and you should be fine."

Coyne checked and double checked the instructions, ensured that the flags were definitely set to 'N', and then ran the report.

After the mainframe team had restored from backup and recovered as much of the data that they could (losing only the past three days worth of inventory), Coyne was called out on the carpet to explain how he'd destroyed the database. Despite being a newbie, Coyne had been cautious from the start, and reviewed the instructions which Herschel had given him, as well as how he'd verified that he'd followed the instructions. But Coyne had also gone the extra step, to look up the code block which checked those flags. He came to the meeting prepared.

    IF NOT CLEAR-SWITCH = 'Y'
        SET RUN-UPDATE TO TRUE
    END-IF
    IF NOT UPDATE-SWITCH = 'Y'
        SET RUN-CLEAR TO TRUE
    END-IF

Now, first off, one might hope that if two flags should never be used at the same time lest they destroy all the data, there might be some logic to make them mutually exclusive. There is no such logic, but if you look closely, you can see some illogic that I suspect was meant to accomplish that goal.

If the CLEAR-SWITCH variable is not 'Y', then the code sets… RUN-UPDATE. And RUN-CLEAR is controlled by UPDATE-SWITCH. The result is an odd block of code: if either one of the switches is disabled, by being set to anything that isn't 'Y', this code works. If both of the switches are enabled, by being set to 'Y', then this code won't run either step. In the case where both switches are explicitly disabled, then both steps will be run (and the data will be destroyed).

Herschel warned Coyne that "only an idiot would run a job without reading the code first, you should have been more careful," but since Coyne was only a junior, and had followed the instructions, nothing more came from that meeting.

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