T-SQL Tuesday #046 – Rube Goldberg in order to SQL Server

My first T-SQL Tuesday post and am I excited!  My story is going to vary slightly from the original subject in that I’m going to outline a Goldberg machine that was created in order to CONNECT to SQL Server, showing how much my former employer valued the Microsoft database.  Thanks to Rick Krueger (@DataOgre|B) for a great way to tell some fun IT stories.

MPE – IMAGE/SQL

Flash back to the ’80s where a young man creates a general ledger accounting program for the California state university he’s working for.  The app was created using the MPE programming language, connecting to an IMAGE/SQL database on a then-cutting edge HP3000 server.  The app is so successful that the young man starts a company and begins selling his product.  He recruits students from the college and works in his garage.

COBOL – ORACLE/INFORMIX

As the industry evolved and sales grew, the application needed to scale and outgrow it’s dating hardware: enter the world of UNIX.  Cobol is chosen as the new, state-of-the-art language and Oracle or Informix is now the database.  Customers could choose any flavor of UNIX they liked, as long as the Microfocus Cobol compiler was compatible and Oracle/Informix would install.  But, what to do with the old MPE -> IMAGE/SQL code?

Instead of re-writing, the company chose to create a “transport” layer of code that would allow MPE  to co-exist with Cobol, making calls through that layer to the “shiny new database”.  All new development was done in Cobol, but the MPE code was so fundamental that it still played a HUGE role in the functionality of the application.

THE INTERNET

The industry continued to evolve: enter the brave new world of the internet.  Instead of clunky telnet clients that had to be installed on each desktop, the company decided it needed to create a web application, one where clients only needed an internet browser to access an internally hosted IIS server.  But IIS is a Windows product and although all new development was being done in .NET, the MPE/Cobol code still was the backbone of the product.  For most modules, the .NET code was making calls to the MPE/Cobol code that then interacted with the Oracle/Informix database living on the UNIX server.

Which one of these do you picture as the bath tub filling with water to tip a scale to release a ball bearing that slides down a ramp to…

SQL SERVER, FINALLY

In order to remain current in the industry and reduce costs for clients to purchase necessary hardware to host the app, SQL Server was offered as an alternative database.  But legacy code is legacy code and MPE “transported to” Cobol does not play nicely in Windows.  The solution: emulate UNIX on Windows!  Using MKS (a UNIX emulator app for Windows), the MPE/Cobol code could now be used to “interact” with the SQL Server database.  The interaction was done using SQL Server logins (no sense in leveraging Active Directory at this point) and reporting was done using the proprietary solution offered with the software (SSRS???).

Interestingly enough, the company was successful to the point that it attracted the attention of a corporate giant and was sold for a handsome sum.

In summation, “you can’t tell a book if the title’s covered” (http://www.imdb.com/character/ch0029466/quotes).

Hopefully you never had to support this type of machine.  But, I do look back on those help desk days with fondness, as I had no clue what I was doing but was surrounded by great people.