The *nix and MPE dance
July 14, 2008
In a world that invites experiments and mergers, a few developers in the 3000 community have asked if Linux could deliver MPE/iX services on more advanced hardware. This concept is, in theory, a place to run the 3000's environment without any reliance on HP's branded hardware.
It's been done in the past, by Ordina-Denkart. Called MPUX, the solution delivers MPE services while an HP-UX server controls the hardware. MPUX gives HP 3000 applications a place to live other than an HP 3000. It does not pull Linux into the equation, however — so that vendor lock-in of HP's Unix remains in the picture.
But over at K-12 developer QSS, which HP's Jeff Vance and Mark Bixby of 3000 fame have gone to work, there's a great push toward putting Linux on the front line of choices for operating environments.
What services could MPE bring to the Linux experience? Former 3000 NewsWire columnist and current Linux app purveyor Shawn Gordon says
Linux could really benefit from MPE's batch and spool environment. There's virtually nothing other than cron and regular disk files. It's a real pain in the butt and I'm really surprised no one has done something yet.
QSS has done just that with its Linux work, reports founder Duane Percox.
The work at QSS, which continues to serve an education community including some members using HP 3000s, makes a good start at bringing MPE/3000 elegance to the rough-edged Linux environments. Percox says
At QSS we have an expectation that we can monitor and track all jobs that our customers run when using our QSS/OASIS software. This has been particularly easy with MPE since those features are built-in.
We have ported our systems to HP-UX and Linux (Red Hat and SuSE) and needed the same functionality on those platforms.
This is what I can report:
1. We contracted with an organization to create the basics of a job scheduling system that would run on HP-UX/Linux that would support basic job scheduling as we use it on MPE:
-- job queues, stdlists, scheduling, job management, programmatic interface for launching jobs
-- ability to have input parms in the script (think JCL) as we did on MPE
2. Took that system and have been refining it (and fixing issues that arise) and using it with our first deployed hp-ux/linux systems.
3. Continue to evaluate the opportunities for productizing this resultant job management system, but currently cannot afford the distraction.
4. We have always had our own print environment so we are not disadvantated by the lack of a built-in spooler for our applications. However, we do use CUPS on our Linux systems and find it to work quite nicely.
Job management was always one of the 3000's enterprise advantages, even as third parties extended the capabilities in offerings like Unispool and Maestro. Putting these services into a Linux setting makes that open source, no-vendor-lock-in solution an even smoother migration destination.
And if you're not migrating from your 3000, take a few moments to appreciate the built-in job management capabilities of MPE/iX.