The Migration Dilemma

January 2002

The Migration Dilemma

Moving away from the 3000 involves managing risks, which Posix might mitigate

By Curtis Stordahl

Well, the other shoe has dropped. Hewlett-Packard has given their HP e3000 customer base just five years to migrate to another platform. This is a daunting task that is full of risk.

The biggest migration risk factor is probably that the complexity of the applications on the HP e3000 may have been severely underestimated. These applications can be over 20 years old, and some have had scores of programmers continuously evolving the original application without any supporting documentation. Consequently, it is possible that nobody knows just how big and complex these applications are. Many migration projects are also led by personnel with no experience on the HP e3000 platform, who have a perception of it being something like an old dBase application on an IBM PC.

Many organizations will be lured by the “flavor of the month” technology and want to completely redevelop their HP e3000 applications accordingly. This is also full of hidden risks.

A major redevelopment is going to essentially have three project teams. The first project team is going to be responsible for the development of the new application. This team faces multiple risks: of underestimating the complexity of the legacy application they are replacing; or of completing the development only to find it does not meet the minimum requirements and cannot be implemented without extensive rework. At that point, the team could then find it impossible to obtain the resources needed to complete the project. The technology they choose may not meet your expectations and so will not satisfy the minimum requirements. If you go outside your organization for new application development, the vendor you contract to do the work could go bust.

A second project team needs to migrate the data to the new platform. A radical change in design could make this difficult if not impossible.

A third project team needs to provide ongoing support to the legacy application. A major redevelopment could be years in the making, and you can’t stop the business from evolving during that time. This introduces additional risk into both the development and migration project teams because they must aim at a moving target.

There is an overall risk that a migration project could fail, leaving you with no additional funding or time to recover from the failure.

Packaged app migration

Many organizations will be lured by the promises of packaged software vendors. A package reduces migration risk. But this isn’t like just plugging in a new e-mail package.

The biggest risk factor is going to be implementation. Instead of building an application to conform to your business, you must make now make your business conform to the application. Managers outside the IT organization must buy into this and revise policy and procedures accordingly. So much is needed outside the IT organization to make it work that it must be managed from the executive level. If there is insufficient commitment at the executive level, then the project is destined to fail.

Training users is another risk factor. If you train too early you risk losing them through attrition before you implement. If you train too late, they may not be able to retain and understand what is expected of them.

Replacement vs. Displacement

Faced with these risks, there are going to be some organizations that will put their heads in the sand and do nothing.

HP e3000 users have another option: develop Posix-compliant applications on the HP e3000 that can be easily ported to Unix. The approach is simple. Your Posix-compliant applications on the HP e3000 coexist and gradually displace legacy applications. Once all legacy applications have been displaced, you port your application to Unix. If done right, the port could be as simple as recompiling the code.

This plan offers a tremendous reduction in risk. Think of it as a pay-as-you-go approach. By producing Posix code one piece at a time you shorten your development cycle into tiny, manageable pieces. Everything you invest gets used and proven immediately, instead of hoping that there is a pot of gold at the end of some rainbow. You also get better control of evolving business requirements over the duration of the project. Under the displacement scenario, any evolving business requirements that impact the application will simply prioritize the development of the Posix-compliant code for the affected portion of the application.

IMAGE To Eloquence

Even if you displace our legacy applications with Posix-compliant applications, you still have all of your data in your legacy IMAGE database. That data must also be ported.

The HP e3000 is not going to be the first IMAGE platform Hewlett-Packard has stepped away from. The HP-250 also used IMAGE when it was obsoleted. HP-Germany developed an IMAGE emulator for HP-UX called Eloquence so that HP-250 applications could be ported to HP-UX. Eloquence is now available on Linux and Windows in addition to HP-UX.

It is certainly possible to port the IMAGE data to an RDBMS, but the availability of Eloquence offers the possibility of a much smoother port.

I have found that most of the differences between MPE IMAGE and Eloquence to be very minor. IMAGE puts the Data Base ID (DBID) in the first two bytes of the database name when the database is opened. The Eloquence open intrinsic returns an integer with the DBID. The integer DBID is then used instead of the database name for all other intrinsics. The parameters used in the intrinsics are essentially the same, but Eloquence passes some parameters, like the mode, by value instead of by pointer. The Eloquence intrinsics have a parameter for the item list, but always assume the use of all items “@”. Eloquence has fewer data types. If you are still using packed decimal numbers then you will need to store them in an alpha-numeric field in Eloquence, and you won’t be able to use Query to view or modify them.

The most noticeable differences revolve around features that were added independently to MPE IMAGE and Eloquence after Eloquence was initially created. Implementation of b-trees and dynamic transactions are noticeably different but essentially serve the same purpose. Eloquence does not appear to have ever implemented critical item update.

A new feature recently added to Eloquence is a client-server model. When the application opens a database it establishes a TCP/IP connection to the Eloquence database engine. This makes it possible to segregate the application server from the database server just as many RDBMS models do now.

Next month: Guidelines on using C++ to develop Posix-compliant applications on the HP 3000

Curtis Stordahl has been a developer of HP 3000 applications since 1979. His latest product is iJobSched, a Web-based job scheduler that he has recently ported to HP-UX using Posix and Eloquence.