Mellon Bank had bought themselves a future. The initial development site was Number One, Broadgate — the Shearson Lehman building. A glass‑and‑steel statement of late‑80s confidence, sitting just above Liverpool Street Station. We worked in a corner of it that smelled faintly of new carpet tiles and warm mainframe manuals. It was the kind of place where you felt the City humming beneath your feet, even when all you were doing was aligning database definitions.
The system we were cloning — IBM, PL/I, IMS — had already proved itself in production at a UK financial institution. Our task was to reproduce it faithfully on a new IBM installation in the City of London. During one of the early meetings I made the remark that followed me for years afterwards: “The unique thing about this new system will be the fact that there’s a copy of it running somewhere else.” It was meant as a joke. It became a prophecy.
The implementation went smoothly. The migration scripts behaved. The database definitions aligned. The IMS regions came up clean. When the system went live, it did so with the kind of quiet confidence that makes engineers superstitious. Key team members were retained for six months of on‑call support — a precaution, not an expectation.
I wasn’t on call that night. My colleague was — the one who drew the short straw for that particular rotation. But when the console lit up and the messages began to spill like a distress signal, he phoned me. His voice carried that unmistakable mixture of urgency and disbelief: “We’ve got a B371 on the IMS log file.”
Not an IMS error. Not an application error. A pure MVS storage allocation failure. End‑of‑extent. No more space. The log had reached the edge of its universe. It was the kind of problem that shouldn’t happen on a freshly cloned system. Except, of course, it could — because the one thing we had copied perfectly was the original institution’s assumptions: their dataset sizes, their extents, their quiet, unspoken limits.
Standing in the machine room at 3:40am, watching the console messages scroll like a beacon, I realised something that has stayed with me ever since: cloning a system is not the same as understanding it. Copying a universe does not guarantee you know where its edges are.
We cleared the fault. We resized the datasets. We brought the region back. But the truth is more interesting. I consulted the IBM manual — RTFM being the acronym of the day — and there it was: a documented, fully sanctioned procedure for precisely this failure. IBM had anticipated the moment when an IMS log would simply run out of universe.
The ritual went like this. First, copy the log dataset to a new one that’s bigger — not extend it, not patch it, simply copy it cleanly. Then run the IBM utility that closes the new dataset properly, writing the correct end‑of‑log markers and tidying the block headers. After that, run the Log Backout utility, walking the log backwards and unwinding incomplete transactions. Finally, run the Forward Recovery utility, replaying the committed updates and rebuilding the database to the exact state it should have been in.
Only after all that — the copy, the closure, the backout, the forward recovery — could we bring the region back with a straight face. By the time the operators arrived for the morning shift, IMS was sitting there as serene as a cat pretending it hadn’t knocked over the vase.
Modern systems fail differently — noisier, faster, often catastrophically — but they rarely fail with that same sense of ceremony. The old failures had shape. They had dignity. They taught you something about the structure of the world you were working in.
And sometimes, early in the morning, they taught you something about yourself.