Speedware Sponsor Message

April 2002

Migration of IMAGE Data

Strategy to consider while examining your Transition plans

By Charles Finley

Second in a series

Last month we looked at a migration strategy away from the HP e3000, one using incremental approaches to re-hosting. 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.

This month we’ll examine a strategy to transfer data from MPE systems, the migration steps involved to move your TurboIMAGE and IMAGE/SQL databases onto another platform.

Tools-based re-hosting is a solution that protects and leverages an organization’s MPE/iX COBOL software investments, while bringing its technology current with newer IT requirements. One example of this is XFORM/Unix from my company, which allows an organization to completely migrate its MPE/iX COBOL applications. Here we will examine strategy that doesn’t demand any specific tool.

Transferring source data

There are differences between how data is stored on MPE systems and how it is normally stored on either Unix or Windows. Transferring data between platforms involves not only physically moving it, but also some amount of translation; and it involves storing it in a usable fashion on the target platform. Actual transfer of data can be accomplished by using a number of standard techniques; these include FTP and NFS.

Translating MPE/iX COBOL source code

COBOL dialect translation is a fairly straightforward process. However, MPE COBOL II has certain unique non-typical features that must be dealt with in order to make compiling on the target platforms possible. This means extracting Copylibs from KSAM files, removing and translating macros, and creating needed subprogram libraries.

TurboIMAGE migration

One reason why the HP e3000 and MPE have been successful is the presence of the IMAGE database management system. It has evolved over the last 30 years into its present form of IMAGE/SQL. Migrating MPE applications generally involves migrating IMAGE databases. There are two principal ways to do this: You can retain the IMAGE calls and use an IMAGE clone database, or replace IMAGE with a relational database (RDBMS).

If you choose the latter, you must retain the IMAGE calls while you use an RDBMS, or replace TurboIMAGE calls with the use of an RDBMS.

Retain the IMAGE calls and use an IMAGE clone database

This is the simplest and least costly strategy. HP Eloquence (www.hp-eloquence.com) is a database management system similar in structure to HP TurboIMAGE that runs on various Unix, Linux, and Windows platforms. It has been extended to include the TurboIMAGE API, its performance is almost identical to TurboIMAGE, and it is a fairly inexpensive database management system.

Replacing IMAGE with an RDBMS

The migration of IMAGE data to an RDBMS, in addition to the support of IMAGE intrinsics on the target platform, can present a major technical challenge.

IMAGE is a network, or a limited hierarchical, database management system. Information is stored on two levels and is accessed by traversing a path from the highest level, or hierarchy, of the network to the desired lower level. The two levels of hierarchy in IMAGE are the master and detail level. At the master level, master datasets keep information about a uniquely identifiable entry. At the detail level, detail datasets keep detailed information related to the unique entries in the top level. Detail datasets are also used to relate the entries in the master level to each other.

In the relational model data is organized into tables. A table is a two-dimensional structure of columns and rows. A row is similar to an entry in an IMAGE dataset and a column is similar to a data item or field. Access to this data is facilitated through Structured Query Language (SQL). Examples of relational database management systems include Oracle, Informix, DB2, and SQL Server.

Carrying out database IO to these relational engines from a procedural language like COBOL can be accomplished through precompilers and call interfaces.

Precompilers work with a standard 3GL language compiler to develop code with embedded SQL statements. A precompiler is then used as a first pass on a source program to identify and translate all embedded SQL statements and generate a modified source program that the 3GL compiler can understand. The 3GL compiler is then used to compile and link the program to its finished executable form, which can then access the database. To aid in the development of portable database applications, some precompilers include options to detect and mark source code statements that do not conform to ANSI-standard SQL syntax.

Call interfaces also let the programmer use a 3GL language and embedded SQL statements to carry out database IO. However, call interfaces also provide low-level, proprietary procedure and function calls that can give the programmer more power and flexibility than precompilers. A program using the call interface can control the actual steps of SQL statement processing (parse, bind, execute, rebind, reexecute, and so on) to achieve optimum application performance.

The ideal call interface to effect a quick and efficient migration is one that allows the existing COBOL program to make IMAGE calls as it has always done and to translate these into the call interface supported by the target RDBMS. The call interface of the target RDBMS gives the most control and highest performance available and is the preferred mechanism when creating a call-compatible library of IMAGE intrinsics. This is done by creating a library of C routines that includes procedures that emulate the functionality of each IMAGE intrinsic and that translate the IMAGE request into a series of native RDBMS database calls. This library can be either an archive or shared library. The library is then linked into the target COBOL run-time module to support the INTRINSIC calls and provide a call-compatible interface.

Properly designing a call-compatible interface library can be challenging. Challenges include support of a backward chained or serial read when the RDBMS does not support FETCH previous. It is also necessary to adapt and enhance the ROWID address to support directed reads. The benefit of an automated migration that uses an IMAGE call-compatible interface is that either no changes need to be made to program sources or, if any are required, they are few.