What Made the 3000 Great?
Federal program helps 3000 IT pro re-train

A 3000's Efficiency vs. Unix's Soft Bedrock

FlintstonesWhile the HP 3000 was still a going concern at HP (meaning HP concerned itself with the 3000 going away) customers were replacing it with HP-UX servers. The question came up often: how much Unix you'd need to replace MPE. HP's lab engineer Kevin Cooper even wrote a paper about it, presented at user conferences. The simple answer to the question was, "twice as many, if you're not using Oracle." The Oracle users had to buy even more hardware.

That multiplier emerged out of HP-aided tests at some big customers. Cooper says that "IMAGE was highly optimized for the way 3000 applications used it, and it consumed a lot fewer CPU cycles per transaction compared to relational DBs -- on the order of a 1:2 ratio. And this just happens to be where a lot of applications burn a big percentage of their CPU cycles."

MPE/iX managed memory well, especially in the caching of database writes combined with the IMAGE Transaction Manager. The migrated apps which HP studied tended to need about four times the memory on their new platforms, which meant a lot more memory management overhead.

This 3000 advantage emerged because MPE has a database in IMAGE and a programming model that had to perform acceptably on a 2 MHz system with just 1MB of memory. Although the OS bloated up over 30-plus years of redesigns, MPE runs well under 200 times as much CPU power and 8,000 times as much memory. Oracle, well, it's got a lot softer bedrock for app software. It's going to need more system resource to do the same thing.

But MPE was not cheap compared to the investment in Unix. Not in capital costs, until you added all the Unix software that was built upon an OS not designed initially as a business tool. This will become an issue to consider as the homesteader community looks over their in-house apps. When they prepare to move their own code they must play architect, or hire consultants to do this. Mark Ranft, who runs the Pro3K consultancy, has said this architecting relies on knowing both strengths and weaknesses of an enterprise target.

An operating system provides a platform upon which to write your enterprise applications. The enterprise architect must understand the strengths and the weaknesses of the platform and design the application around them. Sometimes this may mean you have large pools of mid-tier systems/application servers to make up for the lack of resiliency in the operating system. This could be compared to using the RAID concept for disk arrays.

Several years ago the trading of single 3000s for multiple servers was in full throat. The costs for this many-from-one calculation are not obvious at first. "I fear that most enterprises will find the licenses, care and feeding of these needed numerous mid-term systems are far from being inexpensive," Ranft summed up in a message on the LinkedIn 3000 Community group.

Your MPE advantages continue to flow from record-level integration with data. It has a shared, re-entrant code, and a unique data division. That's different than the Unix single-threaded kernel shared data model. So the 3000's architecture has more parallelism baked in.

IMAGE remains the keystone of the 3000's advantages. Some engineers say that it forced developers to think about data relationships ahead of time -- a process which therefore uses less resource than SQL's ad hoc indexing. This is why a school district or a gas pump maker gets along fine with a Series 969 or a Series 989 -- hardware whose horsepower is horse-and-buggy, versus the CPU available to modern products like the Stromasys HPA/3000 virtualization engine.