This article is more than 1 year old
Things I learned from Y2K (pt 87): How to swap a mainframe for Microsoft Access
The customers will never know what we did. Until now
Y2K As the IT world continues to suffer the after-effects of 20-year-old botched Y2K fixes, please take a moment to enjoy a bonus Y2K tale of Microsoft Access 97 taking the place of a mainframe at a particularly paranoid financial institution.
Register reader "Jim" was employed in that time-limited role of "Y2K developer" for a now defunct financial institution whose name we shan't mention for reasons that will become all too clear.
"Their IT," Jim told us, "was outsourced to a large American corporation for whom I was contracting."
During the six months leading up to the fateful day, "the team was asked to date shift test 56,000 spreadsheets (retiring what was defunct) along with all 30 of their many other programs and systems."
Y2K quick-fix crick? 1920s come roaring back after mystery blip at UK's vehicle licensing agencyREAD MORE
It all sounds like a proper bundle of laughs. However, paranoia still stalked the halls, and a decision was taken that it would be too risky to keep the mainframe up as the century clicked over, and so the IBM System 38 running the institution's COBOL code would be turned off during the rollover.
But what to do if somebody called in, wanting to know their balance? There was a telephone banking service with 30 operatives, who would be faced with blank screens and potentially angry customers.
"I was tasked with 'recreating' their main customer account balance screens," explained Jim, "including the password verification system to confirm who the customer was."
The plan was that a copy of every single account balance, along with the last 10 transactions, would be downloaded from the mainframe into an Access 97-based approximation. It wasn't as barking mad as it sounds – "Writing the access screens, getting the data and importing it was no issue," remembered Jim. "The dry runs beforehand all went well."
A slight wrinkle was that verification system. It transpired that the IT team had "lost" the algorithm used for password encryption, which meant the whole "give me the second, fifth and eighth character" challenge wasn't going to fly.
"Without this," Jim told us, the game would be up: "The pretence to the customer that all was well with their accounts, and the bank still had their money when the whole system was turned off, was not going to work."
As it turned out, and rather alarmingly (infosec boffins should look away now), Jim was able to reverse-engineer the algorithm and recreate the thing as a compiled library function within Access. It, he said, "turned out to be far simpler than they or I expected."
With that, a simulacrum of the mainframe (the screens at least) was ready to go.
The last day of 1999 arrived, and Jim slurped the latest data from the mainframe and imported it into the Access database. He then burnt 30 CDs with the precious .mdb file, numbered them, signed them and then trotted around the 30 customer service operators to distribute his payload. Again, a signature was acquired for each before finally, at midday on the 31st, "the mainframe was turned off".
Jim's Access 97 system was now running the show, at least as far as that part of the business was concerned.
"I then spent the whole night, with the rest of the team, ensuring that all the work we had done, including my database, did not fall over – which of course none of it did."
At around lunchtime on the 1st, Jim returned to the operators and collected up those CDs again. Under close supervision, he destroyed each one, "which really hurt my hands after the first few," he recalled.
"No one actually asked to prove that I deleted the database off my PC or the data therein. Good job I am an honest person!"
Ever used Microsoft Access 97 in an ambitious way that actually worked? Got some Y2K stories you wish you'd got off your chest? You can email us here – our Y2K column is back for a limited time and ready to hear your tales of the time 1 became 2. ®