On Call It's another tale from the world of telephony where everything goes wrong in this week's [1]On Call .

Today's story comes from a Register reader Regomised as "Greg." Greg was the applications manager for a now-defunct telco, and was the throat to choke for all the applications in the customer-facing side of the business. The network side, where telephone calls were actually connected, was a whole other ball game for which he was most definitely not responsible.

"On my side of the world," he told us, not at all highlighting a worryingly siloed side to the business, "we had a customer service application, which is where the sales clerks entered the details of new customers.

[2]

"The clerk would type up the new customer's details, the application would save them and tell the network side to set up the customer on the telephone exchanges. When done, the network side would tell the customer front end that this was all complete."

[3]

[4]

The system hadn't been so much designed as "evolved" over time, the dependencies likely lost in the mists of poorly commented code and unhelpful documentation that had accumulated over the years like crud in a cutlery drawer.

"It worked, most of the time," he said, "but that was all you could say."

[5]

And as much as one might hope for.

However, there came a time when a total power-down was needed. Everything in the building had to be turned off – computers, servers, everything. There was to be no UPS, no battery backup. All kit was to be shut down.

This shouldn't have presented a problem in itself. The remote telephone switches would deal with network calls, but customer service was to be totally offline.

[6]

"It took weeks of planning," said Greg. "We had never tested a total power down before, because we had redundant systems, so a total outage was unthinkable."

And so all manner of engineers were put on standby. On Call? Well, best get on-site. Just in case. Although everything had been planned. Nothing could go wrong. Right?

Everything was carefully shut down.

All OK.

The procedure to bring the systems back up was started ...

... and didn't work.

It transpired that the team had missed a dependency: "The customer front end system couldn't boot if it couldn't find the network system. And vice versa, the network system wouldn't play ball unless it could talk to the customer front end system."

Deadlock.

[7]How do you call support when the telephones go TITSUP*?

[8]Swooping in to claim the glory while the On Call engineer stands baffled

[9]A lightbulb moment comes too late to save a mainframe engineer's blushes

[10]The Ministry of Silly Printing: But I don't want my golf club correspondence to say 'UNCLASSIFIED' at the bottom

As is so often the case, management began the headless chicken dance, seeking someone to blame for why all this expensive hardware was unresponsive despite all those weeks of preparation.

Greg, however, donned his thinking cap and began to work through the problem. It transpired that the network system didn't need to see much more than a glorified heartbeat to confirm the customer service system was active. A bit of C and some shell scripts would be enough to spoof things.

The spoofing worked, and the network side of the business was brought up successfully.

Then Greg's bodge was carefully unpicked and the proper customer system was brought online. "Happy days! Everything worked!" he recalled gleefully. The hero of the hour.

Or maybe not.

"I never let it be known that I might just have missed this during some of our technical meetings," until now, that is.

"But I didn't fail to take credit for the solution!"

What's your most creative solution when called on to sort out that thing that could never happen? Or, considering the time of year, tell us your festive call-out moments. All it takes is an email to [11]On Call . ®

Get our [12]Tech Resources



[1] https://www.theregister.com/Tag/on-call

[2] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_onprem/networks&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2YbMzZNUpSizgHJYghJvMGwAAAJg&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0

[3] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_onprem/networks&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44YbMzZNUpSizgHJYghJvMGwAAAJg&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0

[4] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_onprem/networks&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33YbMzZNUpSizgHJYghJvMGwAAAJg&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0

[5] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_onprem/networks&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44YbMzZNUpSizgHJYghJvMGwAAAJg&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0

[6] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_onprem/networks&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33YbMzZNUpSizgHJYghJvMGwAAAJg&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0

[7] https://www.theregister.com/2021/12/03/on_call/

[8] https://www.theregister.com/2021/11/26/on_call/

[9] https://www.theregister.com/2021/11/19/on_call/

[10] https://www.theregister.com/2021/11/12/on_call/

[11] mailto:oncall@theregister.com

[12] https://whitepapers.theregister.com/