I recently hosted a podcast for BMC Software on the subject of mainframes in financial services, and talked about my experiences with mainframe systems at Credit Suisse and Citigroup. 

It got me thinking about my early days in the database and transaction processing industry, and why mainframes are still so good at high volume, reliable transaction processing. 

When I first heard about ACID transactions, I was amazed to hear that they let you just pick up from where you left off after a system failure, automatically recovering the database to the state it was in before the failure. 

I ended up spending the next twenty years or so working on applications, standards, and products in the database and transaction processing area, and eventually had the great honor of co-authoring a book on the subject with Phil Bernstein (with a big assist from Jim Gray). 

Then: At the Start

In 1982, near the start of my career, I designed and built a complete order entry/inventory management application for Salomon Ski’s warehouses on the HP 3000 minicomputer. ACID transactions were not available.  

When the system went down – as it did fairly often – we would call the customer service team upstairs and tell them to hold off entering orders until we could restore the database.

We used HP’s IMAGE/QUERY database utility to crawl through the records until we found the partial updates and manually deleted them, noting the order numbers so that customer service could re-enter them. Once this was done, we’d call and let them know they could start entering orders again. 

ACID transactions were exactly what we needed, although I didn’t know it at the time ... [Read the whole Cortex on Intellyx.com.]