COBOL II Applications to Unix
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, its 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.
estimates, some 70 to 80 percent of todays 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 Acucorps Acucobol-GT,
Microfocuss NetExpress, or LegacyJs PerCobol to see a
whole new genre of COBOL. These offerings are capable of creating
applications that todays users demand.
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
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
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.
Copyright The 3000 NewsWire. All rights reserved.