The HP 3000 has journeyed on the migration path for more than 16 years. The journey's length hasn't kept the community from gaining new resources give an MPE/iX datacenter a fresh home, though. VerraDyne takes a bow this year with an offer of skills and service rooted in 3000 transitions. The Transition Era isn't over yet, and Windows remains the most likely destination for the remaining journeys.
In-house application suites make up the biggest part of the homesteading HP 3000s. Business Development VP Bruce McRitchie said his MPE experience began in an era before MPE/XL ran the servers at McCloud-Bishop while other partners worked at System House during the 1980s.
In those days the transitions came off of Wang and DEC systems, he said, as well as making changes for HP 3000 customers. The work in those days was called a conversion more often than a migration. In the years since, replacing an in-house solution with a package was a common choice for migrations. Package replacements have their challenges, though. McRitchie reminds us that custom modifications can make replacement a weak choice, and often a business must change its operations to meet the capabilities of a package. There's sometimes data conversions, too.
In contrast, the VerraDyne migration solution is a native implementation to a target environment with no emulation, middleware, or any black box approach. ADO or ODBC enables database access when a VerraDyne project is complete, usually anywhere from three months to a year from code turnover to return to client. Microsoft's .NET platform is a solution that's worked at prior migrations. But there's also been projects where COBOL II has been moved to Fujitsu or AcuCobol.
Projects for 3000 migrations are bid by lines of code to be moved. Screens in VPlus are converted to WebForms or WinForms for Windows-bound migrations. For systems headed to a Linux or Unix platform, the forms are converted to screen sections or JavaServer pages.
The typically knotty problem of replacing HP intrinsics is handled by rewrites into COBOL or a language the migrating site chooses. MPE JCL is converted to Windows or Unix command scripts. If there's a scripting language a site prefers, VerraDyne can target that as well.
"Every site has some of that specialized MPE/iX functionality," McRitchie said. He added that a migrated system, whether landing on a Windows VB.NET or C# program base, or in software converted to Java for Unix, is delivered completely compatible. "Bug for bug compatible," he quipped, following the fundamental best practices for every migration: what's running successfully on a 3000 will run on the new migrated platform.
IMAGE migration practices move data to SQL Server, Oracle, or other databases selected by a site. Any third party indexes used, such as Omnidex, are converted to database indexes or views. All relations between tables like automatic or manual masters are preserved. Conversion programs are included to convert IMAGE data from the HP 3000 to a selected database. VerraDyne provides source to migration all IMAGE intrinsics such as DBOPEN, DBUPDATE, or DBPUT.
In-house code that's migrated, as it always has been, lets a site retain the heavy investment made in highly customized systems applications. Preservation of resources has been what's kept HP 3000s running well into their second decade of post-HP manufacture.
Migrations of 3000 in-house systems are likely to come from sites that have been running applications since before the 1990s. McRitchie and his consulting partners Tony Blinco and Masoud Entezari have experience that runs back to the days when 3000 disks were large enough to vibrate when they were busiest. "They'd rub the paint off each other," he said with a wistful chuckle, sounding very much like an expert seasoned in servers which are several decades older than when first booted.