Migration plan needs tweaking at times
February 2, 2006
No matter how diligent your research, you may have to change your migration plans in mid-stream. When Computer and Software Enterprises (CASE) set out on its migration project in the wake of HP's departure from the 3000 market, the company thought it had the right COBOL compiler chosen for its banking and lending customers. In matters of finance, however, the bottom line turned out to be something customers watched closely.
CASE planned to take its application suite to MicroFocus COBOL from HP's COBOL II on the 3000. "We believed they had the most comprehensive solution," said Senior Software Specialist Rick Gilligan. "We also liked their support for upcoming COBOL standards for Object-Oriented COBOL." But after working alongside MicroFocus to develop a pre-processor to handle the HP COBOL II macros, CASE selected HP-UX on PA-RISC as its target platform.
That's when the cost of their COBOL choice tossed up a roadblock.
In addition to evaluating AcuCOBOL and the MicroFocus'product, CASE had also looked at Fujitsu's COBOL. "We were going to completely re-write the data maintenance user interface screens in MicroFocus," Gilligan said, "and had prototyped some browser-based forms representing some of the more complex screens.
"When we finally had selected the platform, we did research on run-time licenses for MicroFocus COBOL. Their prices, in my opinion, were far too high, especially since we had been spoiled by free HP COBOL run-times on MPE.
"We were not looking forward to breaking the news to our customers about the fees they were likely to have to pay. That forced us to re-evaluate the three COBOL tool vendors."
Eighteen months had passed by now, and Gilligan reported that the time had delivered two important changes. "The first was that the AcuCOBOL tools had matured — many early defects had been fixed," he said. "The second was that ScreenJet had a VPlus to AcuCOBOL/AcuBench convertor. This makes migration much faster with less re-writing and re-testing than the other two COBOL vendors. For those reasons, we selected AcuCOBOL and abandoned our investment in MicroFocus tools."
Meanwhile, CASE's choice of a database had gotten even more useful to the project. Eloquence beat out IBM's DB2 database, Gilligan said. "DB2 would have required a complete re-write of the database access portion of our application to convert to SQL-based access, or some sort of TurboIMAGE emulation layer on top of it," he said. "It was not going to be a good use of resources to migrate to DB2."
"Performance is excellent with Eloquence on HP-UX on Itanium, and little time was spent re-writing application code. What changes were made were usually done to take advantage of Eloquence-specific features, such as read-only locks."
Gilligan said that CASE broke down the advantages it gained by moving from IMAGE/SQL to Eloquence:
• Eloquence is less expensive than IMAGE/SQL
• No need to repurchase Eloquence licenses when replacing an existing server with a new server vs. IMAGE/SQL, where a new license was always required (future replacement and growth savings vs. IMAGE/SQL)
• There is a minor server license transfer fee for Eloquence, but no additional charge for platform changes (such as from HP-UX to Linux or Windows)
• Eloquence licenses for additional servers are less expensive than IMAGE/SQL for additional test/development/disaster recovery systems (current and future savings vs. IMAGE/SQL)
• Eloquence will include database shadowing (replaces NetBase Shadowing) at no additional cost to purchase or support (current and future savings vs. IMAGE/SQL)
• Lower annual support costs for Eloquence vs. bundled IMAGE/SQL
The advantages illustrated a truism about selecting software: smaller providers tend to be more flexible than larger software vendors. While Gilligan had praise for both MicroFocus and Acucorp technical staffs, Acucorp could provide a better business environment for CASE's licensing needs.
"From a business relationship point of view, we were much more impressed with the team from Acucorp," he said. "Their run-time prices were better, they were easier to work with, they were willing to meet with us to understand licensing issues and develop new pricing models for hot disaster recovery systems."
Challenges, and meeting them
CASE ran up against challenges both technical and business-related. The first major challenge was moving away from a system where all reports and processing functions were selected from VPlus-based forms and run as MPE batch jobs — which produced HP PCL5-formatted reports solely for HP LaserJet printers. ABLE was using the MPE spooler and network printing features.
The new reporting and processing function selection in the ABLE application suite is completely Web browser-based. "It is much friendlier," Gilligan said. "For example, it has pull-downs which are populated with only the data a user is allowed to access."
All reports are now produced in PDF format, in addition to the HTML format ABLE has supported for a subset since 1997. They can now be saved, e-mailed and faxed, "and not just to LaserJet printers attached to the network."
Gilligan said the migration has been a very large undertaking. "One goal we had was that, where possible, if we had to re-engineer a major part of our application, we also would provide an improved user experience by improving the usability of our migrated application."
The other major challenge was that CASE had embarked on a five-year project which had to parallel major enhancements to our existing application on MPE. More on that aspect tomorrow.