Moving COBOL II Applications to Unix

March 2002

Moving COBOL II Applications to Unix

Embracing the transition of applications can be accomplished without rewrites

By Charles Finley

First in a series

Hewlett-Packard recently announced the end of its involvement with the HP 3000 computing platform, effective at the end of 2006. This announcement has added further motivation for those companies and organizations who still value their application software investments — and have decided to retain that value by moving application sources to another computing environment.

There has always been a need for continual renewal, modification, and updating of software systems in order to keep them in line with changing business needs and mainstream developments in IT technology. While the need to renew business legacy systems like the HP 3000 is clear, the fact remains that, for the most part, they perform satisfactorily and continue to meet the functional requirements for which they were originally developed. The main reason for this is that the functional requirements, which embody the rules and methods of business transactions for the domain of interest, have not changed appreciably.

Consequently, a unique attribute of business legacy systems is that they contain a vast amount of valuable business knowledge and procedures. These are elements that should be retained in the new systems that will replace them. My company believes that migration of these systems is the way to retain this value.

Tools-based porting and migration

Migration to a different computing environment is often called porting. This process consists of repetitive processes that are best done with software tools. Automated conversion methods include the products and services that on the one hand reproduce the MPE features required by the migrated application on the target platform (emulation) and on the other hand translate sources so that they are compatible with tools available on the target platform (translation).

Examples of translation include the automatic transformation of COBOL II source code to Microfocus or Acucobol so that it can be compiled on either Unix or Windows. Data is also transformed from TurboIMAGE formats to those usable in databases such as Informix, Oracle, and Microsoft SQL/Server. Database meta-information (schemas) must also be translated in order to facilitate the creation of new databases on the target platform. A complete migration solution will also include run-time helper applications such as print spoolers and batch job processors.

A well-implemented migration methodology allows the user to maintain a single set of source code for the application while it runs on both the target platform and MPE/iX. This is particularly helpful for independent software vendors who must continue to maintain the application for both environments. However, it can be useful to an end-user who has multiple computers or multiple sites. It means that all sites are running the same version of the application during transition to the target platform.

There are at least two major classes of users for migration tools. The first category wants to perform a complete migration; the second class wants the ability to migrate on demand. Complete migration users are interested in converting to the new platform and discontinuing use of the original platform. Migrate-on-demand customers want to be able to use one source code pool on either the original or the new system. In the first case, once the migration is completed, the translation tools are no longer needed. In the second case, they may be used for years.

Complete-migration customers come in at least two categories: Those who are satisfied with compatibility of the MPE run-time environment on the target platform and those who want to run in native-mode in the target environment. The quickest, easiest, and least expensive method of porting involves the use of a simulated environment that is compatible with MPE, hence the name compatibility mode. In most cases, this will provide acceptable performance for the life of the system. Some customers want to convert the software so that it can be optimized to run in the target environment. This native-mode port allows the software to run free of MPE-isms such as VPlus and IMAGE calls.

Tools-based porting works best for all of the above categories and subcategories of users. The most important feature of tools-based porting is that the automated conversion can be performed at any time and also repeated at anytime. Even if the user wants a complete migration, there is a period of parallel operation. What if during this parallel operation or even after the system is in production, it is determined that there is a major pervasive defect in the software? The solution is to fix the toolset to remove the defect and then re-run the migration. In other words, it’s easy and inexpensive to start over! If, on the other hand, the migration were to be done manually, such a change could be frustrating, time-consuming, and very expensive.

If the user wants a complete migration to native mode, tools-based migration is even more desirable. It has all of the benefits mentioned above, as well as the additional benefit that after the system has been ported to compatibility mode, it can be tested and enhanced in a “real-world” environment. Therefore, when the last enhancement is finished, the system is ready for use a short time later.

COBOL

By some estimates, some 70 to 80 percent of today’s commercial applications are written in COBOL. COBOL is doing a fine job of providing data processing services in corporate data processing environments. Moreover, COBOL has changed along with the IT industry. One only has to look at the offerings of Acucorp’s Acucobol-GT, Microfocus’s NetExpress, or LegacyJ’s PerCobol to see a whole new genre of COBOL. These offerings are capable of creating applications that today’s users demand.

Changing computing platforms

There are a number of reasons people have to change computing platforms. The platforms companies are usually migrating to these days typically include Unix, NT or Windows 2000, and Linux. When organizations leave the HP e3000 and MPE, they change from IMAGE to some Relational Database Management System (RDBMS), although this is not required. There is an excellent replacement for the IMAGE database called HP Eloquence. Moreover, migrating to these new platforms provides the opportunity to take fuller advantage of the more modern COBOL implementations mentioned above.

Time and money

Migrating existing COBOL applications to Unix or NT can make sense for a number of reasons: the shortage of new applications that fully meet business needs, discontinuance of the HP e3000 product line and MPE, fewer hardware platform choices, the high cost of software licenses, the high cost of maintenance, stagnation in software features that are available on other operating systems, and the decreasing quality of support for the HP e3000. Moving these applications without rewriting them not only saves time and money but can also shorten the time to enhancement. Not having to rewrite business rules that already work provides an obvious benefit.

Moreover, the above factors are coupled with the reality that, given the current features available with HP MPE COBOL II versus other more platform-independent COBOL implementations, it can be more difficult for a COBOL II application to be upgraded or enhanced. Desired enhancements include graphical user interfaces, and Web, client-server, and relational database technologies.

Re-hosting approaches and incremental enhancement

There are different ways to approach re-hosting applications. We believe that the approach that involves the least amount of risk and takes the least amount of time and money involves preserving the content and structure of the original application. This type of porting consists of two basic techniques and type of tools: translation and emulation.

Emulation facilitates move the application to the target platform with the minimum number of source code changes. In this case, tools and run-time libraries must exist on the target platform so that after programs are compiled there, they execute as though they were still on the HP e3000. Calls to external resources such as the IMAGE database and VPlus screen handler must work in about the same fashion as they do when the application is still on the HP e3000. Translation tools, at a minimum, allow sources to be moved and used on the target environment. For example, COBOL II programs are “translated” to Microfocus COBOL and then compiled on the target platform so that they can be linked with the run-time libraries on the target platform.

Some users may not wish to emulate MPE system calls in the target environment. For example, it might be desirable to have the existing programs make calls to a target RDBMS using SQL instead of IMAGE calls. In this case, more translation is needed. Instead of emulating IMAGE calls, the IMAGE calls are translated to SQL statements before the program is compiled on the target platform. Still, porting while preserving existing sources involves varying degrees of translation and migration.

When a migration does not involve emulation, it is considered to be a native migration. That is, it uses the native system calls and facilities of the target platform and no emulation is used. Even if the eventual goal is a complete native migration, it can be helpful to start with emulation.

Emulation is by far the quickest way to get up and running in the target environment. By porting the application quickly, one gains the benefit of having a usable application for such things as testing, initial deployment and/or incremental enhancement of the application. For example, after the emulation version of the application is up and running, two separate teams can each work on the graphical user interface and the RDBMS interface. As each team progresses, a third team can perform quality control testing on the final application.

Next time: Issues to consider in TurboIMAGE migrations.

Charles Finley (cfinley@xformix.com) is president of Transformix Computer Corporation , a company that specializes in the migration and enhancement of MPE applications to Unix and Windows.