Making An HP 3000 More Secure
Ordering a Hamburger, HP-Style

Community links in on migration, emulation

A lively discussion of migrating off the HP 3000 is on the LinkedIn HP 3000 Community discussion boards. (We're bearing down on the magic 500+ member count for that group; joining such a group makes your profile on LinkedIn rise up for people seeking IT experts.) Members in the discussion included developers of the MM/3000 MRP application built for MPE/iX -- maintained by HP until it was sold to eXegeSys -- and then revamped as an independent app. Others sharing their experience included consultants from Speedware and MB Foster migration teams, plus some advice about the hardware emulator alternative that might pump more useful years into such an MPE app.

Randy Thon of Cessna Aircraft said that “one of the main reasons we are still on this application and platform is that it is cost effective and solid, and all development and management of the system is within the Maintenance Department. But this year we as a company are looking at moving from the HP 3000 due to supportability, mainly due to hardware.”

Advice below followed a line of study about size of migrations as well as other alternatives.
   
Randy, why not move to the newer A-class hardware? It supports native fibre for high speed fault tolerant arrays. Plus it would run circles around the KS969.
- Craig Lalley

You could also consider using MB Foster to migrate the same application over to Unix.
- Tony Ray

Tony, the eXegeSys team spent years trying to migrate MM/3000 to Unix and ultimately gave up and sold the intellectual property. 11.7 million lines of COBOL, SPL, and Pascal is a big beast to move.
- Jeffrey Lyon

Ah, the COBOL is not a problem, but re-creating the SPL and Pascal would be the problem. I understand. It is quite unfortunate that the HP 3000 had to stop. There will never be a better machine. I have worked on them since 1976 and know that several are still running. I own two myself.
- Tony Ray

The SPL and Pascal can be done; the issues are with the tight integration of the application and the hardware platform. There were many things done in the application that cannot be replicated on other platforms. I am sure with enough time and money these could be overcome or replaced. But the size of the application is daunting.
- Scott T. Petersen

Scott, correct me if I'm wrong, but it wasn't its integration with the e3000 the made the MM/3000 port difficult -- it was its integration with MPE. I seem to remember you explaining to me that there were MPE system calls which were provided specifically for MM/3000.
- Jeffrey Lyon

The 11.7 million is not that big. I did a migration at Speedware; think it was about 4 million lines of COBOL and 300,000 Pascal and SPL in about a year. Our team was 14 members and we started not knowing the app. A bigger team, knowing the app, could get the MM/3000 migration done in under two years.
- Brian Stephens

Jeffrey is correct, the integration with MPE and the features of the platform increased the complexity of the problem. And also having special features built into the compilers just for the application did not simplify the issue, either.
- Scott T. Petersen

Technical possibilities aside, what really happened is that eXegeSys management realized that a fully migrated MM/3000 would not compete for new sales in the then current market and de-funded and, thus, terribly hampered the effort late in its cycle in the hope of developing a new technology ERP. I'm pretty sure that Scott et. al could have gotten it done, but the new sales market was uninterested and the existing MM/3000 base was tired of waiting.

We'll be having this same conversation about SAP 20 years from now.
- Jeffrey Lyon

Any thought of trying the Charon-HPA/3000 product from Stromasys? Seems like your 969 license would qualify for for the emulator. Then hardware would no longer be an issue.
- Tracy Johnson

Comments