The Transport™ Migration Toolset
IMAGE
Overview
IMAGE Schema files are transferred from the HP3000 to the target UNIX machine, translated and used to create the resultant DDL for Oracle or Informix. In addition, metadata (effectively like the ROOT file) is also maintained in the database to provide proper translations between the native RDBMS types and what the applicaiton is expecting.
The IMAGE data itself is simply unloaded with DB2DISK, transfered to the target machine, and reloaded with our tool XDBLOAD, which simply reads the file and calls DBPUT.
Multiple IMAGE database will reside in one Oracle instance or Informix database. TRANSPORT™ supports the situation of duplicate table names in this scenario. By providing a RDBMS backend to your application, a wide variety of third-party tools (e.g., Crystal Reports, BRIO, etc) may now be used to easily extract data for reports.
Schema Translation
Codes, embedded within the comment section of the original IMAGE schema indicate special processing to occur during the translation to SQL. These include:
- De-concatination of composite fields
- Type conversion (J2 to NUMERIC(9,2) or X8 to DATE)
- Don't automatically expand array fields (the default is to auto-expand)
All IMAGE datatypes are supported and converted to the appropriate native type.
VARCHAR support is also available.
Indexes (Unique or non-unique, as appropriate) are created for search and sort items. Primary and Foreign Key relationships are also indicated.
The DDL statements use appropriate EXTENT/STORAGE qualifiers based on the CAPACITY statement.
Scripts for routine maintenance are also created (UPDATE STATISICS and COMPUTE STATISTICS).
Configuration files can indicate fragmentation policy for large tables.
To the degree possible, any differences between the existing table structure and that dictated by the IMAGE schema are output as ALTER TABLE statements. This greatly eases the update process.
Automatic masters can be removed from the database and simulated in the DBFIND/DBGET calls. This solves issues with using third-party tools that aren't aware of Automatic masters.
Intrinsics
The following IMAGE intrinsics are supported:
| Intrinsic | Comments |
| DBBEGIN | Maps to BEGIN WORK |
| DBCLOSE | |
| DBCONTROL | Only for special TRANSPORT™ modes |
| DBDELETE | |
| DBEND | Maps to COMMIT WORK |
| DBERROR | |
| DBEXPLAIN | |
| DBFIND | |
| DBGET | Mode 8 is deprecated to Mode 7. Item lists are supported. |
| DBINFO | Common modes supported |
| DBLOCK | |
| DBMEMO | Only as a placebo |
| DBOPEN | Modes other than 1, 3, and 5 are mapped to 1. Passwords and file equates are not supported. |
| DBPUT | |
| DBUNLOCK | |
| DBUPDATE |
DBGET mode 4 is supported, including the case when the application chain reads down Path #1, save the direct address and then does a DBFIND on Path #2, issues a DBGET Mode 4 with the saved direct address, and continues reading.
DBGET also allows additional modes that permit a WHERE and ORDER BY clause to be added to the SELECT statement.
DBGET employes extensive optimization to prevent repreparing of SQL statements.
Locking
IMAGE locking at the database, set, and item/value level are supported.
TRANSPORT™ issues all database calls with an isolation level of "COMMITTED READ". This allows non-Transport applications that modify the database within a transaction will co-exist without harm. In the other direction, DBBEGIN and DBEND are mapped to BEGIN WORK/COMMIT respectively.