It's a good question to ask when a customer is considering where to migrate 3000 applications. Common sense advice from migration service suppliers says "It's all about the apps," meaning that target choices are determined by which applications a migrator must choose. But often in the 3000 marketplace, the applications remain the same during a migration, as companies execute a lift-and-shift move of code.
When the app remains the same, then choosing via architecture and environment is the fork in the road away from the 3000. Towards the x86/Xeon world of Windows, or into the land of Unix and HP's IA-64 Itanium designs? (HP-UX and IA-64 are a matched set of solutions, since Itanium is the only host for HP's Unix.) An analyst said recently that only three architectures will survive the consolidation of solutions, and Itanium isn't one of them. Joe Clabby has promoted IBM's solutions before his latest report, which claims the z architecture of IBM mainframes and IBM's POWER architecture will be survivors, along with Xeon.
But the reasons Clabby dismisses any survival for Itanium don't fit the technical view of one of the 3000 community's best IA-64 experts. Gavin Scott, a VP at support and development house Allegro Consultants, says that Clabby's wrong about x86 emulation being the fatal flaw in the Itanium fabric.
Clabby, who once advised his clients that Itanium was a good investment of development dollars, now faces away from HP, if not Intel. x86 compatibility is so important that it keeps IT planners away because their 32-bit apps aren't welcome on Itanium.
“From a dropped features perspective," Clabby said, "one of the most important features dropped in Itanium design was the chip’s ability to handle 32-bit computing. During the course of its development, 32-bit emulation mode was removed from the Itanium feature set, making it impossible for IT buyers to run their existing 32-bit applications on the Itanium 64-bit processor.”
Scott says 32 bits are a small matter in choosing IA-64, which he calls by its HP/Intel name, Itanium Processor Family.
In reality, virtually nobody cares about running x86 on IPF. The only possible users would be Linux, where software is typically portable and recompiled anyway, so Linux users probably don’t see it as a huge issue either way, and a Microsoft Windows Server Ludicrous IPF Version user who wants to run old programs along with Oracle or SQL Server or whatever other limited excuse there is for the existence of Windows for IPF. I would think that the software emulation probably got added to Windows too, making it a non-issue.
I suspect the Intel software translation/emulation is maybe even better than the old native hardware feature was.
The first few implementations of Itanium ran IA-32 (standard x86) code natively in the hardware, Scott explained, the dropped the feature in preference of "a software translation/emulation module that I believe Intel developed and made available for use with Linux, so just as Aries makes PA-RISC work, the Intel software lets you run 32-bit x86 code whether or not your IPF chip has the old native x86 support or not."
Scott is referring to the Aries emulator in HP-UX, software which permits apps written for PA-RISC to operate on an Itanium processor. HP says it has no plans to drop Aries support in HP-UX, something that app developers who don't want to rewrite HP-UX apps for native Itanium count upon. But serious computing gets re-coded for new architectures, not emulated, Scott says.
"Generally people seem to find that for important, CPU-intense programs, Aries is not fast enough," he said, "and they really need to recompile into native code."
There are better reasons that ermulation to show why Itanium choices cut across the tide of movement toward Intel Xeon solutions. The architecture hasn't developed a large critical mass of customers compared to what HP calls its Industry Standard Servers. That lack of mass makes development choices harder to fund at Intel as well as within HP -- although Hewlett-Packard shows a great deal more faith in Itanium's capabilities.
The truth is that every solution has a migration in its future. But if the major effort of moving away is years away, a company can do well with a niche solution if the architecuture is elegant, efficient and stable. That's what's given the 3000 such an afterlife, a design beyond HP's plans for the system's demise.