A few years back, David Shideler worked at a company that built car dealership systems and was a bit reluctant to jump on the new technology bandwagon. In fact, to say that this company moved slowly is not just an understatement, it's an affront to the word "slow". 1200 baud: that's slow. Mail-in-rebates: really slow. Glacier movement: really, really slow. This company: about as fast as fossilization.

The company built the first version of their product in 1973 using COBOL and a specially-manufactured IBM System/3. It was an overnight success: hundreds of dealerships across the country bought their product and tens of millions of dollars in sales poured into the company. They discovered a formula that worked and didn't want to change it.

Despite numerous technological advancements over the following decade, they stayed the course and continued to improve and optimize their product for the System/3 platform. It got the point where buying an antiquated System/3 was significantly more expensive than buying a brand-new, much-faster computer. But that didn't matter; their system worked and there was no need to change it.

And then it happened: IBM announced that the System/3 would be discontinued. The company was outraged and begged and pleaded for IBM to continue supporting it. Being that they were one of the last System/3 customers, IBM offered to send a team of consultants to help them transition and compile their code on the new x86 platform.

The company refused. Instead, they hired a small team of computer-science whizzes to develop a low-level emulator that would allow them to run System/3 binaries on the x86. After all, their application ran perfectly on the System/3 and there was no need to change it.

The emulation worked fairly well for the next several years and they continued to develop their product in COBOL for the System/3 and run it on an x86. That is, until the manufacturer of their COBOL compiler went out of business.

Now, some might have seen that as a sign to switch to a new language and a new hardware platform. Not these guys. Their solution was, again, to hire a small team of computer-science whizzes to develop a COBOL "compiler" that would translate all of their System/3 COBOL code to C and then compile it as an x86 binary. Their application ran perfectly in COBOL and there was no need to change it.

Of course, one of the big problems with their COBOL-to-C translation program was that it produced completely unreadable C code that none of the COBOL programmers could understand, let alone debug. The computer-science whizzes were brought back in to create a COBOL development environment that allowed for the COBOL developers to step-through and debug their code. Amazingly, it worked and they were able to continue developing in System/3 COBOL for the next decade or so.

Fast forward to 2001 and the company is in need of yet another team of computer-science whizzes. And this is where David comes into the story. You see, the company wanted to extend their reach into Europe, but the European market was all into this fancy new technology called "Windows." Since the terminal emulator on top of Windows just wouldn't cut it, they brought in David and several others to help them embrace the "new" Windows technology.

Obviously, their advice to switch to C/C++ or an actual Windows development environment fell on deaf ears. David and the rest of his team needed to figure out a way to bring their System/3-COBOL-translated-into-C application into the world of Windows.

One of David's first challenges was COBOL's event model, or, more accurately, its lack of one. In standard Windows programming, when the user clicks on a button or does just about anything else, Windows raises an event to tell the application what happened. In COBOL programming, the application periodically asks if the user did an action. They were able to work around this by creating an "action queue" that allowed COBOL to see what happened and respond accordingly.

The next challenge was in creating the Windows Forms themselves, or, more accurately, creating a form generator that would translate the terminal screens into Windows forms that don't look too "terminaly" but still maintained a terminal feel. They actually managed to do this, too.

Amazingly, once the "Windows conversion" project was over, their software actually worked in Windows. It looked terrible and ran incredibly slow, but it worked. The company was able to keep its entire floor of COBOL programmers working on the System/3-COBOL-translated-to-C-rendered-in-Windows application and things have remained the same ever since. After all, they found a formula that worked and there was no need to change it.

[Advertisement] BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how!