Migrating HP 3000 Applications

Migrating HP 3000 Data Sources

Migrating Programming Languages

Migrating Ecometry Surround Code

Migrating Suprtool  

back to
Solutions

...Technical Solutions

Migrating HP 3000 Data Sources

RDBMS Centric Migrations

Have your COTS and IMAGE Too!

Wouldn't it be nice to be able to migrate a TurboIMAGE database to an RDBMS and then immediately use Commercially available Off the Shelf (COTS) programs that rely on SQL access while at the same time use programs written for MPE intrinsics?  Such a solution is already available from Transformix. Our Adaptive Database Access Level™ adapts the leading RDBMS of your choice to suit customer access needs.  Many companies are already enjoying the benefits of this approach.

RDBMS's versus TurboIMAGE and Eloquence

Most TurboIMAGE databases, flat files and MPE Message Files can be converted to a relational database management system such as Oracle, Microsoft SQL Server, IBM DB2 or PostgresSQL in as little as one day.  Using the Transformix provided Sungard Bi-tech Transport Migration Toolset and runtime environment, existing programs in third-generation languages such as COBOL, PASCAL, C, FORTRAN and SPL can be automatically converted to run on UNIX, Linux and Windows in a fairly short time  as well usually with no manual modifications.  That is, these programs retain the same TurboIMAGE or other MPE-intrinsic calls that are used on the HP 3000.  Even more remarkable is that without any additional work, these same converted data sources that are used by migrated programs can be accessed by off the shelf products that use SQL and other database provided programming interfaces to access the data sources.

Debunking the Myths

It is a common belief in the HP 3000 community that it is easier to go from TurboIMAGE to Eloquence and the corollary is that it is somehow more difficult and or costly, in terms of labor and time, to go from the TurboIMAGE to an RDBMS.  Nothing could be further from the truth.  Yet companies are following this path only to be faced with an immediate need to convert from Eloquence to an RDBMS on a daily basis in some cases in order to give other applications access to the data.  In the long run, these companies,  sometimes willingly, are faced with the possibility of a second migration to RDBMS. It is also believed by some that "native" access to RDBMS's is somehow faster than using the TurboIMAGE API.  This can be true if the data is accessed by changing the logic of the program to use a single SQL statement instead of the logic associated with accessing the data one row at a time.  It is usually true that the only way to achieve significant performance improvements in a migration is to rewrite the program.  Rewriting programs is a process that takes more time, cost more money and is more risky than simply migrating it with its current logic. Therefore, these so called native solutions quite often substitute DBGET's, DBPUT's, etc. with something like ESQL statements that do the same thing as the DBGET and DBPUT.

A Better Solution for Files and Databases

The figure below shows how TurboIMAGE data, KSAM files and MPE Message files are actually stored inside for RDBMS' with the Transport solution for Oracle and Microsoft SQL Server.

TurboIMAGE Details

The next figure shows how once the databases are migrated, it can be access by existing programs using either the TurboIMAGE API or by any program using the RDBMS native SQL API. With this solution there are several advantages: Existing programs do not have to be changed at all during migration.  This saves both time and money. Users and programs have  the option to use SQL to access migrated data immediately upon migration. Any slow performing programs, usually the ones that use massive amount of data at one time, can be rewritten to use SQL on a selective basis.