Simplifying MPE/iX Patch Management
Living with what's still working in MPE

Migrations Altered to Appear as Emulation

Terms about transition have been fluid and flexible for more than a decade in the 3000 community. People say migration when the solution is actually conversion. Migration has also been called emulation, a status that was the holy grail when HP canceled its 3000 plans. "If only," said the companies dug in on MPE/iX, "there was a way to make something behave like the 3000 value set."

Altered-Carbon-MigrationOpenMPE spent the first four years of its lifespan chasing that ideal. First there was the goal of getting ahold of enough source code that MPE/iX could continue to evolve in labs outside HP. That was shot down right away, and then there was the goal of getting a replacement platform for HP's hardware. The 3000 experience was lashed to PA-RISC and HP wasn't building any more of those servers by 2003.

Enter the first discussions of making a chip that could mimic PA-RISC, a PA-8000 at the least. This emulation was not going to happen in hardware. One plan proposed that HP would continue to make the chips and sell them to a third party vendor. People wanted to believe something.

What people wanted was a way to slip their 3000 computing into a new body, something fresher than HP's old designs. This past weekend, Altered Carbon dropped on Netflix. The story shows how the things that make up our true selves — like the programs custom-built to run a company — can be re-sleeved into a new body. The brain is called a Stack on the show, the body is a Sleeve. Sleeves are disposable for the right price. The Stack is backed up and treasured. You only experience Real Death when your Stack is destroyed.

The magic is moving the Stack into a new Sleeve. The magic was putting MPE/iX stacks onto the disposable sleeves of Intel hardware. After emulation's ideal went into hibernation, Stromasys opened the door back up with software, and true emulation was born. It's been more than five years by now, and the project became a product quickly. Emulation means making one host mimic another. It's got a powerful attraction: limited change and no re-training.

Emulation looks like migration, though, when it walks like it and sounds like it. This kind of emulation ducky takes non-3000 software (Linux, Windows, even Unix) and plants it in place of MPE/iX. The programs will slip across to the new host after revisions and rewrites, work that's usually delivered by the line of code. There are substitutions for surrounding tools (like MPEX, or a job scheduler) that demand retraining. It probably looks different to the users, too, so there's that adjustment.

Migration still has real benefits. It walks and sounds a lot different than a software engine that takes 3000 programs and runs them on Intel hardware. Emulation has no other changes except to learn how to replace the oil in the engine and learn how to start it up. Charon, really. Everything else is migration. If you'll be headed to migration, it's a straighter path acknowledge you'll migrate and find an agent to apply that change. The 3000's had years of camouflage offered as emulation. In place of a real emulator, it was the best way forward.

Real migration doesn't pretend to be emulation. Migration of legacy systems assumes there are better tech solutions that have been established since the 2001 design of MPE/iX and PA-RISC. Genuine migration retains business logic, line by line, with whatever service expertise is needed. You get what you pay for because you need more. It's not the best solution if all you need is non-HP iron.

You get more from real migration than from emulation. More changes, to be sure, so the benefits revolve around extended connectivity (to other software, non-HP) and a broader future (tools not controlled by a system vendor). A bigger ecosystem then beckons.

Emulation, by now, needs to be virtualization. The level of complexity in emulating software has been demonstrated over the last 20 years. MPUX was a part of the ViaNova/3000 solution back at the start of this century. It was a sub-system enabling 3000 sites to run and maintain MPE/iX applications hosted on non-MPE/iX servers. It was not emulation. MPUX gave system administrators the 3000’s command set, as well as supporting MPE/iX intrinsics, on non-3000 environments. The software doesn't isolate applications or users in an emulation environment, but instead provides Unix, Linux or Windows services to the MPE/iX applications.

A migration and an emulation are two different things, a distinction that's important to acknowledge. Emulation gives standard and supportable hardware to MPE/iX with a minimum of change. Migration changes the development of surround code, can involve re-training users, strives to modernize apps, and must deliver adaptability to link with new software.

Migration also gives new, fresher hardware, just like emulation does. It's just about the only benefit the two solutions have in common by 2018. Ask for migration by name. And for emulation, do the same.

Comments