Making the problem go away is not the same thing as fixing it

On Call Welcome once more to On Call, The Register's weekly column featuring readers' turbulent tales of their tech support troubles. This week, meet a reader we'll Regomize as "Mal" whose first job in tech was programming a mainframe at a small mutual financial services outfit.

"I worked on a financial package written in COBOL called 'CLOAS,' which the staff told me stood for a 'Complete Load of Australian … Something'," Mal opened.

The quality of that application became evident when Mal took a call in the early hours of the morning from the on-duty mainframe operator.

"The caller explained the problem, but only about one word in ten made it through to my befuddled brain," Mal admitted. After slowing things down and hearing the story again, Mal was only slightly the wiser.

This story comes from the time before remote access, so there was nothing for it but going to the office – despite the hour.

The situation didn't make much more sense once Mal arrived. But he eventually identified the probable cause. Having done so, he realized that this was not the sort of thing that just fails all at once. There would have been a chain of events. There would have been earlier failures.

He found himself "mystified as to why there had been no warning of the system's impending demise."

Mal asked the operator if he'd seen any advance notice of the problem and was assured no warning had been apparent on that night.

But the year before, the operator recalled, he did see a warning. Many of them. So many, in fact, that the error logs filled up and caused an overnight job to fail.

Mal dug into the situation and learned that his predecessor had been called out when those warnings proliferated. He'd come to the office, charged several hours overtime, and even ordered a pizza at the company's expense.

And then he made the warnings go away – by changing one line of code.

And which single line of code did he change, you may ask? Was it, perchance, the line that was causing the problem?

Of course not, silly. It was the line that generated the warning.

• Workload written by student made millions, ran on unsupported hardware, with zero maintenance
• Police ignored the laws of datacenter climate control
• Techie labelled 'disgusting filth merchant' by disgusting hypocrite
• Techie wasn't being paid, until he taught HR a lesson

"Job done, he went home and forgot all about it, leaving me to fix the actual problem a year later," Mal muttered to On Call.

Mal also reinstated the warning message.

The worst thing about this On Call incident? "As it was 2:00 AM I couldn't even order a pizza," Mal lamented.

Have you been called out to address a problem that should have been fixed by someone else? If so, click here to send On Call an email. We always welcome more stories. Lots of recent submissions have concerned the mainframe age, which leads On Call to challenge to those of you working on more modern kit to share more stories. Anonymity guaranteed – for you and the outfit you worked at enduring the agony of being on call. ®