The announcement by Hewlett Packard of the “end of life” of the HPe3000 created considerable interest in tools to assist customers to migrate to other platforms. SunGard Bi-Tech has a long history with just such a toolset, and this website was designed to give an overview of our product, TRANSPORT™, and links to our current distributors.
In 1988, SunGard Bi-Tech, realizing the growing UNIX marketplace, recognized the need for a product which would migrate applications developed on the HP3000 to the growing range of UNIX machines which were becoming available.
The resultant product, TRANSPORT™, offers the automated translation of Native MPE-based systems to the UNIX equivalent (notably the HP9000 HP-UX, the RS/6000 AIX, and Sun Solaris) with an application environment that mimics MPE. Currently TRANSPORT™ supports Oracle 8+ and Informix 7+, Microsoft SQL Server 2000+, DB2 8+ and Postgresql 8.x+ on the following platforms: HP9000 and ia64 HP-UX, RS/6000 AIX, and Sun Solaris, Linux and Windows 2000+.
The design objectives of TRANSPORT™ and Transformix Tools are as follows:
- Migrate HP 3000 applications -To develop a product which would migrate 100% of complex applications with a minimum of changes to the source application code.
- Maintain a single set of source code and screens – To create a production version of the application being migrated on the resultant UNIX platform which was functionally and cosmetically identical to the MPE-based version.
- Deploy on multiple platforms
- Migrate Databases to an RDBMS
- Deploy on multiple databases
- Position applications for modern development tools
- Replace obsolete programming languages
- Low cost
- Reduce risk
TRANSPORT™ will currently convert and transfer BASIC source code, copylibs, IMAGE schemas, IMAGE data and VPLUS Forms Files. Most MPE intrinsics have also been emulated.
The benefits of using TRANSPORT™ to migrate applications can be summarized as follows:
- The time and cost of redeveloping the application under UNIX accessing a RDB is significantly reduced.
- The resultant production UNIX version of the application simulates the MPE-based environment, hence removing the possibilities of product divergence.
- Additionally, End Users feel more “at home” due to the mimicking of MPE by TRANSPORT™ (thus reducing possible re-training costs).
- The costs of re-writing documentation and associated procedures are reduced as TRANSPORT™ emulates the MPE-based application functionality under UNIX.
Applications which have been migrated using TRANSPORT™ are now successfully installed both across the United States and Europe, with the companies who have taken this step realizing the benefits shown above. TRANSPORT™ has been in continuous use as a replacement for MPE since 1989. It has an installed base of over 500 sites.
Tools-based Porting and Migration
Migration to a different computing environment is often called porting. This process consists of repetitive processes that are best done with software tools. Automated conversion methods include the products and services that on the one hand reproduce the MPE features required by the migrated application on the target platform (emulation) and on the other hand translate sources so that they are compatible with tools available on the target platform (translation).
Examples of translation include the automatic transformation of BASIC II source code to Microfocus or AcuBASIC so that it can be compiled on either UNIX or Windows. Data is also transformed from TurboIMAGE formats to those usable in databases such as Informix, Oracle, and Microsoft SQL/Server. Database meta-information (schemas) must also be translated in order to facilitate the creation of new databases on the target platform. A complete migration solution will also include run-time helper applications such as print spoolers and batch job processors.
A well-implemented migration methodology allows the user to maintain a single set of source code for the application while it runs on both the target platform and MPE/iX. This is particularly helpful for independent software vendors who must continue to maintain the application for both environments. However, it can be useful to an end-user who has multiple computers and/or multiple sites. It means that all sites are running the same version of the application during transition to the target platform.
There are at least two major classes of users for migration tools. The first category wants to perform a complete migration; the second class wants the ability to migrate on demand. Complete migration users are interested in converting to the new platform and discontinuing use of the original platform. Migrate on demand customers want to be able to use one source code pool on either the original or the new system. In the first case, once the migration is completed, the translation tools are no longer needed. In the second case, they may be used for years.
Complete migration customers come in at least two categories: those who are satisfied with compatibility of the MPE run-time environment on the target platform and those who want to run in native-mode in the target environment. The quickest, easiest, and least expensive method of porting involves the use of a simulated environment that is compatible with MPE, hence the name compatibility mode. In most cases, this will provide acceptable performance for the life of the system. Some customers want to convert the software so that it can be optimized to run in the target environment. This native-mode port allows the software to run free of MPE-isms such as VPlus and IMAGE calls.
Tools-based porting works best for all of the above categories and subcategories of users. The most important feature of tools-based porting is that the automated conversion can be performed at any time and also repeated at anytime. Even if the user wants a complete migration, there is a period of parallel operation. What if during this parallel operation or even after the system is in production, it is determined that there is a major pervasive defect in the software. The solution is to fix the toolset to remove the defect and then re-run the migration. In other words, it’s easy and inexpensive to start over! If, on the other hand, the migration were to be done manually, such a change could be frustrating, time-consuming, and very expensive.
If the user wants a complete migration to native mode, tools-based migration is even more desirable. It has all of the benefits mentioned above, as well as the additional benefit that after the system has been ported to compatibility mode, it can be tested and enhanced in a “real-world” environment. Therefore, when the last enhancement is finished, the system is ready for use a short time later.
Re-hosting Approaches and Incremental Enhancement
There are different ways to approach re-hosting applications. We believe that the approach that involves the least amount of risk and takes the least amount of time and money involves preserving the content and structure of the original application. This type of porting consists of two basic techniques and type of tools: translation and emulation.
Emulation facilitates moving the application to the target platform with the minimum number of source code changes. In this case, tools and run-time libraries must exist on the target platform so that after programs are compiled there, they execute as though they were still on the HP e3000. Calls to external resources such as the IMAGE database and VPlus screen handler must work in about the same fashion as they do when the application is still on the HP e3000. Translation tools, at a minimum, allow sources to be moved and used on the target environment. For example, BASIC II programs are “translated” to Microfocus BASIC and then compiled on the target platform so that they can be linked with the run-time libraries on the target platform.
Tools-based Re-hosting and Migration
Tools-based re-hosting is a solution that protects and leverages an organization’s MPE/iX software investments, while bringing its technology current with today’s information processing requirements. TRANSPORT™, from Transformix, allows an organization to completely migrate its MPE/iX BASIC applications quickly, accurately, and cost-effectively.
TRANSPORT™ is an integrated set of utilities that facilitate the complete migration of MPE/iX applications to the open systems world of UNIX and Linux. TRANSPORT gives customers the added flexibility of maintaining source files on the MPE/iX system and migrating them as needed to the target system.
TRANSPORT includes utilities for:
- Transferring source data
- Translating MPE/iX BASIC source code
- TurboIMAGE migration
- Call-compatible subroutines, utilities, and routines to emulate the MPE/iX environment
- Interpreting and converting MPE/iX Job Control Language
- Porting of non-BASIC applications
- Optimizing terminal operation and screen management
Translating MPE/iX BASIC Source Code
HP 3000 BASIC translation is a complicated process. There were perhaps 200 dialects of BASIC in the world of computing and there has never been a standard for the language. Moreover, MPE BASIC V has certain unique non-typical features that must be dealt with in order to make compiling on the target platforms possible. The TRANSPORT™ toolset when used with the Sector7 BASIC to C Transpiler greatly reduces this complexity and therefore reduces the risk of a migration. When combined in a migration these tools go a long way toward automating the migration processes.
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:
- Retain the IMAGE calls and use an IMAGE clone database
- Replace IMAGE with a Relational Database Management System
- Retain the IMAGE calls and use an RDBMS
- Replace TurboIMAGE calls with the use of an RDBMS
Retain the IMAGE Calls and Use an IMAGE Clone Database
On the surface this approach appears to be the 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. However, when one considers the extra costs associated with maintaining the data in this unique and proprietary format, and the need to purchase additional third-party tools to access the data, the savings quickly go away.
Replace IMAGE with a Relational Database Management System
The migration of IMAGE data to relational database management systems (RDBMS) and/or 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 I/O to these relational engines from a procedural language like BASIC can be accomplished through use of a call interface that implements a mapping between existing programs and an RDBMS. The ideal call interface to effect a quick and efficient migration is one that allows the existing BASIC 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 translates 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 BASIC 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.
One of the advantages of migrating data into a RDBMS immediately even while retaining the IMAGE API is that it allows the user to take advantage of new functionality sooner. The flexibility of SQL allows for the ad hoc creation of indices to improve performance and data structures, such as views and synonyms, to mask or massage the data structure without actually changing the table structure itself. The application developer is able to write new applications with the productivity tool sets that are available in the target environment and can then use the power of distributed transaction processing, client-server configurations, and full application portability.
Call-compatible Subroutines and Routines to Emulate the MPE/iX Environment
Various utilities and subroutines help the migrated application run on the target system. Examples include the automated data structure mapping of KSAM files to an indexed file system of the target computer and the export and import of KSAM data.
This is accomplished using either the Informix C-ISAM or bytedesign D-ISAM file system. TRANSPORT™ contains a call-compatible interface of routines written in C linked into the run-time support of the KSAM intrinsics. One extension of KSAM is the use of duplicate primary keys, which is not supported in ANSI 85 compilers.
If the use of KSAM is limited, it may be practical to migrate this data into relational tables to avoid the management of two data sources and to retain the capability of using target RDBMS technology. TRANSPORT™ also supports MPE flat files and message files.
An MPE-compatible print queue manager enhances the limited capability of printer and print job control on UNIX systems. This manager provides an emulation of the MPE spooler in addition to functionality such as:
- Printer management by forms and paper stock
- Operator control and intervention
- Multiple and partial file printing
- Post submission modification of print job characteristics
- Print file review and display
- Physical and virtual printer support
- Dynamic modification of printer characteristics
- Application Program Interface for direct printer control
- Automatic and transparent network operation
A batch job manager provides functionality that otherwise is very limited on a UNIX system. The batch job manager presents a centralized and more powerful point of control over the batch environment and gives capabilities very similar to those on MPE.
Interpreting and Converting MPE/iX Job Control Language
The program batchjob is used to provide MPE-like batch job processing. There is also UDC support. However, command files are not supported. Not only can existing JCL be processed, there are commands to control the runtime execution of jobs.
Porting of Non-BASIC Applications
This article emphasizes BASIC migration. It is also possible to port Fortran, Pascal, C, SPL, RPG, and COBOL third-generation languages. It is also possible to port the leading fourth-generation languages Powerhouse and Speedware.
Fortran 77 and Pascal porting are dependent on the capabilities of the compilers and their runtime libraries on the target platform. Both Fortran and Pascal have some hidden dependencies on the MPE file system that must be addressed prior to porting. C/iX is perhaps the most portable language on the HP e3000.
There are two versions of BASIC on MPE: Business Basic and Basic/3000.
They are both somewhat of a challenge to port because they are unique dialects and also have MPE file system and intrinsic dependencies built in. SPL is surprisingly portable thanks to the SPLASH compiler from Allegro Consultants (www.allegro.com). It is capable of changing SPL to C code. RPG should be translated to either C or BASIC in order to move it to another platform. Finally, products from the fourth-generation language vendors Cognos and Speedware are perhaps among the easiest applications to port. They run on a number of different platforms and their code is quite portable.
It is sometimes desirable to move away from some of the older languages to one that can be more easily enhanced or supported. Translators either exist or can be built to translate many of the third-generation languages to C, C++, Java, or even Visual Basic. Moreover, translators could potentially be built to translate some of the more obscure discontinued languages such as Business Report Writer to C or Java. There has also been some interest expressed to translate Powerhouse or Speedware code to Java or C++.
Optimizing Terminal Operation and Screen Management
The standard migration procedure for VPlus form files is to convert them with the same character-based look and feel. The XPORT program XVIEW is used for decompiling VPlus forms files. It converts the VPlus form to what we call a driver file. When used during run-time, this driver file will produce screens that are essentially identical in behavior and look and feel to the corresponding VPlus file.
Migration of VPlus forms files provides a significant opportunity for application enhancement. The block-mode look and feel of VPlus is an area in which modernization to a GUI and its capabilities can give positive benefits. Several packages are available to accomplish this on the HP e3000.
Migration to UNIX, however, involves:
- Automated translation of the VPlus forms files to a format readable on the target platform
- Preservation of the editing specifications for these forms
- A management utility to maintain and enhance these migrated forms on the target platform
- A call-compatible library of VPlus intrinsics
Since the goal is to achieve as close to a 100-percent automated migration as possible, all possible editing specifications and editing constructs must be supported. The call-compatible library of intrinsics must support all VPlus functionality to avoid any manual changes to the BASIC code.
The Benefits of a TRANSPORT™ Migration
TRANSPORT™ is much more than a simple BASIC bulk conversion process. The tools provide all of the BASIC expertise, JCL, and utilities that an organization’s applications will require to migrate and run in the new environment.
The TRANSPORT™ Toolkit
The TRANSPORT™ toolkit provides a comprehensive set of utilities for a complete, accurate migration. TRANSPORT™’s utilities as shown in Table 1.
TRANSPORT™ Technical Overview
The TRANSPORT™ product has been designed to migrate applications from the HP e3000 9xx (Spectrum) series of machines to either the HP 9000, 8xx, or IBM RS/6000 series of UNIX-based computer systems. TRANSPORT™ converts and transfers BASIC source code, Copylibs, IMAGE schemas, IMAGE data, VPlus forms files, and most flat data files. Various MPE intrinsics have been emulated, and an MPE shell is provided to emulate the HP e3000 environment. TRANSPORT™ MPE to UNIX migration processes are shown in Table 2.
The TRANSPORT™ Methodology
TRANSPORT™ is used either as a “conversion” or “preprocessor” tool.
As a conversion tool, TRANSPORT™ facilitates a complete migration from the HP e3000 platform. TRANSPORT™ is used only once to create a fully translated BASIC source set. After the initial migration, the TRANSPORT™ translator is no longer needed, since all future development will be applied to the new source code. However, during the migration process, maintenance of both source sets is usually required.
As a preprocessor, TRANSPORT™ becomes an integral part of the development cycle. As product enhancements are introduced, changes made to the MPE/iX source are simply re-translated via TRANSPORT™ to produce the new source. This is particularly useful if the migrated application is to be used concurrently on different platforms (e.g., NT and UNIX). Software is prepared for TRANSPORT™ translation only once, after which it can then be seamlessly ported to any TRANSPORT™-Supported platform. An organization’s development staff maintains only the original MPE/iX BASIC. TRANSPORT™’s speed and accuracy make this methodology a popular choice.
In a typical TRANSPORT™ migration, programs are copied from MPE/iX to the target platform. The TRANSPORT™ translator translates the programs, generates the target BASIC, and compiles the object or JAVA code. Next, the runtime environment is set up by configuring files that describe the system and by selecting runtime options. Then, preliminary testing of the migrated software can begin. Data conversion programs are generated by TRANSPORT™ and data files are migrated. After final testing, the converted software is installed and the “cut-over” to the new system is orchestrated.
Tools are available to migrate existing MPE BASIC II applications to UNIX or Windows, and more modern BASIC development environments. The use of these tools presents the best opportunity for a successful migration. The suggested strategy is to migrate using automated tools and utilities. This approach minimizes risk and development and deployment time and costs. If there is a need to enhance the application, it is best to port the entire application using the existing methods of use. This provides for an immediate test environment for the newly changed system and allows for parallelism in testing and future development.
The TRANSPORT Utilities
TRANSPORT™ Translator Utility
The TRANSPORT™ Translator Utility migrates MPE/iX source to the target source by analyzing and changing each statement to ensure proper syntax and semantics; and converts MPE/iX screen definitions appropriate for use in the new environment.
The TRANSPORT™ Library consists of routines that support the running of the converted code. It contains general support routines and routines to emulate the MPE/iX workstations.
The Command Interpreter allows you to run your MPE/iX job control and UDCs with little modification.
TRANSPORT™ analyzes and converts KSAM calls into C-ISAM on the UNIX platform. Source code remains the same.
UNIX Print Queue and Job
UNIX Print Queue and Job Queue, are sophisticated print and job queue systems that were modeled after their HP VS counterparts. The TRANSPORT™ Toolkit is designed to integrate seamlessly with these utilities, matching or exceeding MPE/iX functionality.
Migrated to UNIX with little or no change using either a BASIC Compiler or BASIC/JAVA Translator.
TRANSPORT™ MPE to UNIX Migration Processes
Analyzes all BASIC code and Copy Libraries and makes appropriate syntactical changes for the UNIX Microfocus BASIC
Analyzes and converts IMAGE database(s) into a Relational Database. IMAGE data can also be copied and loaded. All data types currently available under BASIC are supported.
“decompiles” VPlus forms file(s) and uses the screen images and field definitions to create a UNIX “driver” file. This “driver” file is then compiled into a “fast forms” file to provide maximum efficiency when running a migrated application under UNIX.
Analyzes and converts KSAM calls into C-ISAM on the UNIX platform. Source code remains the same.
supports most MPE, VPlus, KSAM, and IMAGE intrinsics. These have been emulated under UNIX to provide similar capabilities to those available under MPE.
Migrated to UNIX with little or no change.
A print spooler similar to the MPE spooler is provided by TRANSPORT™. Commands such as SHOWOUT, OUTFENCE, ALTSPOOLFILE, AND DELETESPOOLFILE are supported.
BATCH JOBS TRANSPORT™
Provides the ability to launch batch jobs in the background using the MPE STREAM command.