Early in 2009, Shine Technologies performed a conversion of the COBOL source code used in FlyBuys systems to replace the use of the MicroFocus compiler with the Fujitsu COBOL compiler and related runtime libraries.

Read on for a high level overview of the activities involved in this project, and how it ultimately turned out.

Are your software systems written using MicroFocus COBOL?
Are you finding COBOL compiler licensing costs exorbitant?
Want to find out what's involved in converting your software from using MicroFocus COBOL to Fujitsu COBOL compilers?

Then this article is for you!

Primary Aim

Our primary aim was clear from the beginning – remove all traces of MicroFocus COBOL compiler and runtime library packages, and replace with the equivalent Fujitsu COBOL offering.

Or to put in another way:

Convert production FlyBuys systems to use Fujitsu software for compilation in as short a time as possible, and ensure that they work correctly.

Why Would You Want To Do This?

When speaking about this project with peers, I'm invariably asked: “Why migrate from COBOL to COBOL? Why not rewrite the system using (say) Java?”

An excellent question. The answer is a tale of “time and money”.

To explain further, the client was in a difficult position. For particular business reasons the client needed fast migration.

The fastest way to achieve this would be to “simply” use another COBOL compiler, which did not have the same restrictions.

As much as personally I'd love to convert the whole FlyBuys COBOL system to Java in one big bang, we had to remain true to our philosophy of delivering business benefit over applying new technology (See the Shine Philosophy).

And so, our “For a Few (a Lot of?) Dollars Less” our adventures began...

Some Secondary Aims

At the start of this project, we took a step back and had a long think about what we were about to embark upon.

We would be changing every single COBOL source file, as well as many of the other software that was closely related or integrated with COBOL executables (such as C programs and libraries, perl, shell and even SQL scripts).

As we were going to be changing “everything”, we decided to add a few very quick and easy enhancements around the fringes to make the system better, in various ways:

1. We added source code identification into every source code file. This enabled us to uniquely identify the source code and versions that comprise of any single executable or script. Easy to do, and invaluable for software release and bug tracking activities.
2. We recognised that we would have a need to rapidly promote large numbers of executables through our build, system test and UAT environments at a moments notice. So we heavily reworked our build scripts, and used the Hudson extensible continuous integration server to harness our software builds and promotions to different environments. This worked like a charm. To quote one young developer “Hey, I just clicked a button and deployed only the 28 executables that I needed to.” 'Nuff said!