The dread sound of the squeaking caster in the humming data centre

All for the want of a drop of lubricant

On Call Distract yourself from the come-hither finger of a Friday trip to the pub ahead of the weekend with a trolley-based tale from the On Call vaults.

This week's story was related to us by a reader we will refer to as "Stan", who insisted to us that today's protagonist wasn't him. Oh no. It was a "colleague who will remain nameless."

Ok then. We'll call the colleague "Sid".

We are back in the 1980s, in an anonymous financial institution for this story, and Sid "was called to a bank's data centre during a night shift for a problem on an IBM 3203 line printer."

The 3203, explained Stan, "was a channel attached chain printer – high speed (relative) on continuous forms". A bit of a beast, but a common sight in data centres of the era. And this one had a problem.

Back in the day, hardware required actual printed manuals, which were usually kept in double height book trolleys left against a handy wall.

Stan went on: "Anyone who remembers these trolleys will recall that the casters were not the highest quality and frequently stuck."

A weary Sid, needing to consult the documentation, was pushing the baulky trolley over to the afflicted printer, past the IBM 3705 Comms Controller, when the caster stuck and the trolley "veered left."

"This is when he discovered that the top corner of the trolley happened to be at exactly the same height as the Load button on the panel of the 3705."

For those unfamiliar, the 3705 Communication Controller was a simple, but critical, beast used to connect communication lines to the mainframe. It was "the box that ran ALL comms out of the data centre to all users and remote offices."

Hitting that Load button would make it reload the Network Control Programme…

"The load button was neatly depressed by the trolley.

"Oops."

By reloading what was effectively the 3705's operating system, Sid had inadvertently taken out the bank's entire network.

"So pretty major," understated Stan.

Sid naturally did the honourable thing and... scarpered. When the operators turned up to find out why the seemingly random reload had happened and the network gone down, Sid couldn't help.

He was, after all, by the printer and "studiously studying the manuals."

Naturally, he was only too pleased to assist the operators, but ultimately "they never did find the reason for the outage and put it down to experience."

Ever been called out to fix one thing, only to make something else much, much worse? Share your memories of accidental trolley-initiated failure with On Call. ®