There was nothing unusual about an unusual ticket. Matt worked helldesk at an assembly plant, and not a week went by without some confusing brain-bender from his users. He didn’t blink when he received this ticket:

We’re having an issue with our check-printer. Every time a user logs on, it prints out an inventory of electrical parts dated from 1984. On our checks. This is causing some accounting issues.

The ticket provided plenty of other details. Matt called the user and ran through the standard questions and answers. No, it wasn’t specific to any particular user. No, there was no job stuck in the local queue. Yes, it really was printing out an inventory from 1984, and yes, all over their checks, and no, those checks couldn’t be used after that.

Thinking it might be an issue with the printer’s memory, Matt checked on the printer itself. It was an ancient dot-matrix printer with about as much memory as a goldfish. It couldn’t remember its last job, let alone a zombie job from 1984. He also checked the computer’s network settings, and noticed something unusual.

“Why is this computer in the DMZ? Does it need a public IP?”

The user had no idea, but Matt’s co-workers did. This computer printed out accounting data based on information that existed in the central mainframe back at the corporate headquarters. It was one of the few computers at the facility that could access the mainframe directly. In order to “secure” the mainframe from external attackers, it was programmed to only accept inbound connections from certain, specially blessed, IP addresses.

A little lightbulb flickered to life in Matt’s head. If the computer could open connections to the mainframe, it stood to reason the mainframe might be able to talk to the computer. The mainframe had data stretching back to the time of Caesar Augustus, let alone 1984. He tested his theory by sniffing the packets that arrived at the computer. Sure enough, every time someone logged in, a bunch of packets came from the mainframe, kicking off the print job.

Matt passed the ticket along to the mainframe team, figuring they could take it the rest of the way. It came back a short time later.

Program SC24P is working as designed. The reason print-jobs are only arriving when a user logs in is probably related to some inability of Windows to receive print-jobs without a user present. Close this ticket.

Matt sent his own reply back, explaining that the issue wasn’t the jobs not coming in. It was that the same job came in every time a user logged in.

Program SC24P is set to retry failed jobs. This behavior is by design. Close this ticket.

Matt tried again, explaining that this computer shouldn’t be receiving any jobs at all, retries or otherwise.

Program SC24P is set to use IP 74.50.110.120 as a secondary printer, in case the primary printer fails. This is by design. If you don’t want this computer to receive these jobs, you’ll need to file a change request. At a high-level, it’s roughly 10–20 days, possibly more. These IP addresses are hard-coded into our custom print-queue manager. And before you ask, no, our custom print-queue manager doesn’t have any functionality for removing a job from the queue. The only way to clear the queue is to reboot the mainframe.

If the mainframe team couldn’t change the IPs they print to, maybe Matt could change the IP the computer used. Unfortunately, whatever IP he used needed to either be in or be added to the mainframe’s whitelist. It didn’t take long for the mainframe team to estimate figuring that out as a 10–20 day effort. Matt went back to the user with the bad news.

Oh, that’s no problem. We fixed it on our end. I hung instructions next to the computer. Before anybody logs on, they need to unplug the printer, wait five minutes, and then plug it back in.
You can close this ticket, thanks!

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