HP 3000 managers who are still looking at migrations might be sizing up replacement hardware. It's getting a little old-school to think of installing a standalone server to replace something in the 3000's ultimate generation like an A-Class. Using a cloud-based server, or just a partition on an HP-UX or a Windows Server, is a more nouveau choice. Eventually, HP-UX will have that desert island feel to it. You can survive, but getting off it will take quite a swim.
Clouds and partitions aside, smaller companies might want to keep their architecture rather than transforming it during a migration. Their planning includes trying to calculate how much box needed to replace an HP 3000. There's good news. Moving out of the HP-hamstrung MPE/iX environment opens up performance room. It's a widely-recognized fact that the A-Class 3000 systems, and just about all of the N-Class servers, aren't running as fast as they could.
In the past -- at least 10 years ago -- HP actually told 3000 customers this hobbling was a benefit. Something about "preserving the customer's investment" by hobbling the PCI-based systems, so the customers using older and more costly systems wouldn't feel so left out. It was never logical to think anything could be preserved through hobbling except the status quo.
Back in 2005 when the president of a 3000 app vendor gave a migrating A-Class user tips on how to size up a new box. During that year at QSS -- where the vendor has been replacing HP 3000s with Linux installs of a new Oasis app for its K-12 and education sector customers -- Duane Percox offered a migrating user advice on sizing up a replacement. His answers back then compared a 3000 to HP's Unix servers, but the notes on the 3000's shortcomings are still valid. The advice began with a warning: You might not have as much HP 3000 power to replace as you think you do.
Even 10 years ago, these things about system sizing were obvious to Percox, just from testing of COBOL code on non-3000 systems. Some of his advice follows.
• An A500-140 is not running at 140MHz as advertised by HP. You are actually looking at closer to 72MHz for that A-Class
• Throttled A-Class boxes also exhibit interesting IO timing issues as demonstrated by some very astute folks who would know, given their intimate knowledge of everything MPE. Here again, you might not have as big a box as you think you have.
• Make sure you are getting a 2-way server. I would never recommend running a relational database server with less than a 2-way. And you might even need a 4-way depending on the number of connects.
• Disk subsystems have a big impact on database performance. The number of database connects also has an impact.
• I find that moving from TurboIMAGE to relational is about a 10-12x CPU hit for the parts of the app that are managing the database. Since your app also spends time doing other things, you don’t necessarily have to have 10-12x the CPU, but it might be a reasonable starting point.
• The MPE TCP/IP stack is performance-challenged, so you will see networking improvements when migrating.
• TurboIMAGE/ODBCLink isn’t a performance screamer, so you might be in for some pleasant surprises in the positive direction.