Using the 3000 as a migration platform
February 3, 2006
While migration projects grind away in the 3000 community, IT still needs to respond to user needs from existing MPE applications. The balancing act is on display all over the world, as thousands of customers try to satisfy today's demands while building a better — well, at least different — tomorrow.
Among the banks and lenders served by CASE software, customers kept needing enhancements and features to the ABLE assets suite at the same time a migration to HP-UX was underway. Rick Gilligan, the Senior Software Specialist at CASE, said the company had to walk the line between needs and wishes for tomorrow during its five-year migration project.
“We could not postpone most of the enhancements our customers wanted or needed," Gilligan said. "Many were driven by government regulation and law changes, by mergers and by other changes in our client’s businesses. We had to accomplish all of the normal and necessary improvements to our application for MPE while also migrating and making the same changes to our application for HP-UX."
These demands are commonplace in the world of 3000 enterprise solutions, a place where mission-critical services must maintain their place alongside an IT project more complex than Y2K. CASE resolved their conflict by slowing its clock on leaving the platform. HP's 1990s re-engineering of MPE/iX helped, too.
“We solved this by delaying the actual move to HP-UX of the 'migrating' product," Gilligan reported. "We did so by using the Posix features of MPE that were nearly identical to the same features on HP-UX. We did our migration to PDF on MPE, though we never made the same changes to the actual product we shipped for MPE. We also migrated from batch jobs to CGI scripts using Apache on MPE.
When it came time to migrate the VPlus forms and do testing with Eloquence, Gilligan said CASE developed scripts on MPE that would migrate and build the ABLE application on HP-UX every night. The scripts let CASE test on HP-UX during the day at the same time they kept working on migration of MPE source code to the HP-UX target. "We did this for more than a year, focusing almost exclusively on replacing the MPE-specific features of our application with Posix-specific features, before making a final cut-over to migration directly on HP-UX."
The 3000 became the development bed for the HP-UX version of the application. The developers who were working on the MPE product, during this long overlap between the two projects, were able to use their familiar tools on MPE to make similar enhancements to the migrating product — while the other team was migrating it. "This was possible primarily because the source code was still on the MPE system," Gilligan said, "as were most of the development tools. This scheme reduced our training costs, especially since we were breaking new ground. We didn't see training others on tools you are just learning to use effectively as an effective approach."
He added, "We basically limited most of the research and initial learning to a small subset of the migration team whose task it was to do the build and test on HP-UX."
As for surprises on things that were easier to accomplish than expected, Gilligan said choosing the right tool vendors helped keep most of the ABLE business logic intact.
“I had a vision that the tools we chose would allow us to keep the majority of our business logic and presentation logic unchanged, while completely changing the foundation that was underneath our application," he reported. “This vision was developed before all of the tool vendors had completed the necessary tools, and before we had anything other than a firm belief that we would be successful. Our major tool vendors — Marxmeier, ScreenJet, and Acucorp — all did a great job at making this possible.”