Migration of IMAGE Data
This month well 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 organizations 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
doesnt demand any specific tool.
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.
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.
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.
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.