COBOL Related Services

COBOL Related Services

Migrating COBOL code can be a lot more complicated than it first seems. There are a number of directions an organization can take when migrating an application while keeping the business rules. Among the choices available are:

COBOL to COBOL

Should COBOL be converted to another COBOL dialect that runs on the target computer?

COBOL to OpenCOBOL

Should COBOL be converted to OpenCOBOL to save on runtime and licensing fees?

COBOL to C or JAVA

Should COBOL be converted to another language that runs on the target computer?

COBOL Data Access Model Changes

Should COBOL be converted to access native data sources instead of TurboIMAGE or KSAM files?

These are all decisions that can have significant implications in terms of the time and money they take to implement. This page provides an overview of how Transformix professional services using Transformix Tools can help companies deal with each of these important issues.

General Issues

Regardless of which of the above identified issues are chosen, there are some common issues that must be accommodated by those responsible for the work.

Transformation Rules

Even though COBOL compilers exist for HP 3000 replacement platforms, moving COBOL code to run on these platforms without the right tools is non-trivial. There are dialect conversion issues to contend with and HP COBOL II has some non-standard language extensions that are typically not supported on replacement compilers. In addition, there are features such as COBOL macros that do not exist outside of HP COBOL and there are calls to MPE intrinsics that are not a part of other operating systems. There are also built-in program behaviors that depend on MPE file systems and error codes. We can call these “MPE’isms”. Some of these differences are simple and some are complicated. Collectively, they can be daunting.

The first step in the conversion, or migration process, is to determine what transformation rules are required to move the code to the new platform. Once this has been determined, the organization must then perform the conversion. Most companies do not have the additional staff time available to take on the amount of work such a conversion entails if done internally.

The Manual Conversion Alternative

Usually a simple examination of a few examples will lead to the conclusion that performing the conversion/transformation job manually is the least desirable alternative and should be avoided.

  • Manual labor is prone to errors, even when executing a formalized set of well-defined rules.
  • Automation of repetitive tasks is a way of increasing productivity and decreasing costs.
  • Automatic conversion can be repeated as often as desired. If the original set of rules are incomplete, developers can adjust the rules and fire up the conversion tool one more time.
  • COBOL programs can be huge — millions of lines of code. Most companies do not have the time or money to transform such programs manually.

Automated Conversion

It is likely that most organizations will decide to do an automated conversion. An automated conversion requires the use of conversion software that will apply the transformation rules needed to accomplish the desired objectives. Writing such conversion programs for one time use is generally not considered cost effective. Most companies either license such software or pay for a service to perform these modifications to their COBOL code.

Here are some of the tasks that must be performed by conversion software.

  • Conversion program needs to “understand” COBOL code. Compiler writers call this process parsing. Parsing COBOL is difficult, but it is a fairly standard procedure that is well defined through COBOL standards.
  • Usually COBOL program is parsed into an Expression Tree which is a standard Internal Representation for programs. It is more easily done by someone who has a library of functions that lets you browse and transform these expression trees.
  • After the program was parsed and transformation rules applied to the Program Tree, the program usually has to be written out as a human-readable and human-maintainable COBOL code. Therefore, one would need a good human-readable COBOL Code Generator as well.
  • Few companies can cost justify the expense and effort required to write their own conversion software for a single use.

COBOL to COBOL

First, there are dialect conversion issues to contend with. HP COBOL II has some non-standard language extensions that are typically not supported on replacement compilers. Secondly, there are features such as COBOL macros that do not exist outside of HP COBOL.

COBOL dialect translation includes differences in syntax and MPE COBOL II has certain unusual features and constructs that must be either removed or converted into things that work in the target dialects. Starting on the HP 3000, this means extracting Copylibs from KSAM files and changing them into directories of related individual files. COBOL II macros are normally not supported in other COBOL. Transformix provides a pre-processor that can be used on any platform that supports JAVA with any known COBOL compiler to overcome this issue. Finally, the COBOL code might rely on RL or XL’s from the HP 3000. These are recreated on the target platform as an appropriate type of shared library or DLL. The TRANSPORT toolset includes tools that automate these processes.

COBOL to OpenCOBOL

OpenCOBOL is an open-source COBOL compiler. OpenCOBOL implements a substantial part of the COBOL 85 and COBOL 2002 standards, as well as many extensions of the existent COBOL compilers.

OpenCOBOL translates COBOL into C and compiles the translated code using the native C compiler. You can build your COBOL programs on various platforms, including Unix/Linux, Mac OS X, and Microsoft Windows.

Using extensions available from Transformix and our Transport runtime environment, OpenCOBOL has been found to be a suitable replacement for HP COBOL II. Transformix extensions include a callable file system interface used in combination with Transport to provide transparent access to MPE-like KSAM, Message Files, flat files and Circular files. Also included are MPE intrinsics to allow access to TurboIMAGE data migrated to RDBMS’s, and a COBOL II macro preprocessor to allow MPE macros usage on the target platform.

COBOL to JAVA or C

Several vendors offer COBOL to JAVA translation products. In some cases the reasoning is that companies who have COBOL can, in many cases, be better off translating the code to maintainable JAVA because the population of JAVA programmers is growing whereas the population of COBOL programmers is shrinking. Another school of thought, advanced by at least two vendors, is that one can continue to code in COBOL but use the JAVA runtime saving licensing costs. A third justification is to have the ability to extend the application with J2EE.

Transformix has found that perhaps as few as 1 or 2 percent of the migrated COBOL programs perform unacceptably slowly when the COBOL is migrated and data access is cursor based. TurboIMAGE access on the HP 3000 is most easily replaced by cursor based row at a time access on RDBMS’s. If intrinsics such as DBGET, DBPUT, etc. are reimplemented with what are wrappers around SQL cursor row at time access that simulate DBGET, DBPUT, etc., migrated COBOL usually requires no logic changes. However, the small number of programs that do not function well with this type of migration can usually be converted to JAVA using Transformix tools and the database SQL access can be changed to pure SQL SELECT to achieve acceptable performance.

COBOL Data Access model changes

The HP 3000 MPE/iX environment uses a number of proprietary data store types. The most commonly used types are TurboIMAGE, KSAM, flat files and MPE Message Files. Transformix provides solutions that allow TurboIMAGE, and KSAM to be stored in the RDBMS. MPE Message Files can be stored inside of the database as well if the RDBMS is Oracle. With other RDBMS types, Message Files are implemented as either flat files (low volume) or using a message oriented middleware system such as IBM’s Websphere MQ or Sonic MQ. Flat files can be stored either as MPE-like files or without labels as native files.

The fact that Transformix tools convert the leading MPE data store types to native file types introduces the possibility of making changes to the programs that bypass MPE dependent behaviors. While Transformix does not advocate this type of approach as a first migration step, our tools do support this type of migration.

It is important to note that once the data has been migrated as described above, it is accessible to existing programs using the MPE type API’s and it is available to new programs using SQL and other native API’s. Commercially available off the shelf (COTS) standard tools can access, exchange and share data easily from the database. Changing existing programs does nothing to improve this situation.

Still, if users want to change some or all of the existing programs to perform “native” access it can be done using tools.

The steps to achieve this are:

  • Build a container that can accommodate the same data as the existing system.
  • Load the existing data into it.
  • Create COBOL definitions of the new data sources.
  • Convert the existing programs to access the new data sources without using MPE API’s.

The first two steps have already been done which leaves only converting existing programs. Doing this manually is a huge amount of work and any tools that can help are welcome.

Step 3 – This is where Transformix Tools help.

The modified programs must read the existing files and write the new tables. This requires embedded SQL, and Transformix Tools can provide the data declarations easily and quickly. (It is a laborious job to code them up by hand.) Host variables for each of the new database tables can be generated by tools provided by Transformix and saved to a central library for COPYing into COBOL that accesses the database.

Step 4 – This is by far the most difficult and it is probably impossible to completely automate.

Transformix provides tools that do much to automate this process by analyzing source code can detecting all places where files are being accessed. We also provide code to get and put data by means of calls to standard access modules based on our TurboIMAGE, KSAM and Message File emulation layers.