April 16, 2012
Migration racks up list of emulated tasks
Some HP 3000s which remain in service are using many MPE nuances to get their jobs accomplished. Each of these tasks needs to be emulated in a migration away from the server. Even as companies embark on migrations to reduce risks, the list of tasks that they hope to replicate from their in-house apps can be surprising.
Such is the case at MM Fab, a fabric manufacturer in LA's South Bay Area. The 3000 shop is now taking its first year of steps off the system, developed and managed by Dave Powell. He shared a list of the things that an emulator must do if it were to succeed at replacing HP's 3000 hardware at his shop. The list also serves as a extensive catalog of the capabilites required of any new operating environment.
"We are thinking about migrating," Powell shared, months before the decision was made. "Which means we have to think about the choice between buying a package vs some form of emulation. Which means I could use some assurance that the [3000 hardware] emulation tools out there would actually work for us."
I can't afford to take this for granted because our system uses some rare features and does unusual things. Lots of them. Example: we do lots of tricky escape-code screen handling (mostly for point-and-shoot, drill down inquiries) that breaks some terminal emulators. Reflection 10.0 works, as does Minisoft WS92 v5.4 and actual terminals from 262x on, but last I checked, Minisoft Secure92 fails big-time. Not trying to make Minisoft look bad, but I need to make the point that software that works elsewhere may not work for us.
"We never cared about portabililty," Powell said, "because we never had any intention of moving to any other platform." From such situations are customers made for the Stromasys virtualization engine. If you're uncertain of whether you're using any MPE nuances in your application, it's a good strategy to get an evaluation of what's in production use today. Even if you're not migrating.Powell said he doesn't think terminal emulation will be a big migration issue. In an emulation, "I think we could just keep on using the two products that work -- I just need to emphasize that we are off the beaten track, feature-wise."
Since there won't be as much room for all the details of MM Fab's custom-code tricks in our printed edition, we thought we'd put them on display here. This list might be useful to let you see if any of this is working inside your in-house apps. For the record, Stromasys says that anything that's working on MPE today will work in its emulator. The only exceptions they've found were HP's internals diagnotics, like SHOWCLOCKS.
A new platform/replacement app would have to embrace the top-level abilities in Powell's custom-code list. It's the kind of situation that makes some 3000 customers a poor fit for a migration, because these nuances were built over more than 20 years of IT budgets. A migration or replacement would address these all at once -- a cost structure that many 3000 shops cannot endure today.
Powell's MPE magic:
Job queues with separate job limits.
Smart :pause command (wait up to 'x' seconds for that job to log off).
MPE functions like finfo and jinfo.
User functions. Some of them are extra date / calendar routines beyond the built-in ones, like "how many days till end-of-month?" or "how many work-days in the next 'n' days?" and "how many months old is this file?"
MPE variables. User variables plus system variables like hpdatetime, hpaccount, hpfile, hpcpusecs, hpjobcount, hpstreamedby.
Message files / circular files / temp files, including temp message files and temp circular files.
Lots of command files, with tricks like with multiple entry points, input or output or both redirected to files, etc. Command files that use :echo to build a job (in a temp file) which they then stream. (I always wanted a way to have UDCs/command-files run offline, or feed parms into a job like UDCs do, so I finally rolled my own).
Jobs that use :echo or :print to build command-file subroutines (also in temp files), which they can then call lots of times with different parms, like running the same program over and over with one cmd-file parm becoming the info that is passed to the program to tell it what to report, another parm becoming part of the file name where it stores the report output, and another parm telling it who to email the report to.
Lots of do-it-yourself logging, with overglorified :echo to circular files, so I don't need to worry about the logs getting too big.
VPlus, with heavy use of vchangefield in newer apps, and family-of-forms in older ones, both to dynamically make some fields inputable and others display-only, changing the display enhancements so users can see which is which.
Creative escape codes in vplus apps to do things that VPlus didn't do as nicely as we wanted, mostly setting function-key labels and screen-printing.
Lots of escape sequences in non-VPlus terminal IO, mostly in character mode.
Extra terminal control features like turning echo on and off, time-out reads, etc. (Hint: escape codes that cause the terminal to send data back to the computer may work most of the time, but don't get solid unless echo is off. Even so, if something goes wrong you don't want the computer to wait forever for an answer).
Lots of env-files for both lasers and old impact printers, mostly changing orientation, print-size and lines per inch so the same report can print on either type of printer. Some reports have a run-time way to tell them how many lines per page, so by coordinating that with env-files I can have a report that normally does 132-column 60 lines do really-small-print portrait mode 124 lines per page on a laser. Also some tray-selection in env-files.
Do-it-yourself fancy laser-printed invoices with legalese in very-tiny print, company name in big print, etc. No special forms package here, just me spending quality time with the PCL documentation.
Converting simple report output to PC-readable format. That's a one-liner on our 3000 with my HP2RTF command file. The new system doesn't have to use RTF, but it does have support a common PC-readable format, has to preserve/translate HP-style line-spacing and page-breaks, and has to support changing print-size and line spacing so the PC file will look normal on screen and printed page. And it has to be easy to invoke in batch.
Email reports. This is also a one-liner here, thanks to a set of command-files I have wrapped around a nifty mail program originally from Telamon. The command files provide logging, improved error-checking, distribution lists, and even automatic retries at gradually-increasing intervals if there is an internet connection problem. I would like to keep that functionality. If possible I'd like to keep the outer layers of my command files, wrapped around whatever mail-sending pgm exists on a new system.
Mass file rename/delete/print/email, with ability to select by date, file age, file size, etc. Some use MPEX, others use my own routines (listf into a file, read it back, maybe call finfo).
IMAGE b-tree dbfinds.
COBOL macros. Intrinsics like command. Any and every HP extension that ever seemed helpful over the last 30 years.
No more trying to figure out what runs on
MPE/iX or where to find it. No more worrying
about availability! www.MPE-OpenSource.org
is all things MPE/iX: Open Source packages,
freeware, scripting, plus loads of tools
and information to keep your 3000 system
alive and thriving!
Actually, we are in the LA area, in the collection of suburbs locally known as "South Bay". I guess that other Bay Area has a "South Bay" too.
Posted by: David Powell | Apr 16, 2012 7:40:36 PM
Thanks for the correction, Dave. I've got the location updated above. And thanks for the list of MPE nuances for features that the next system will have to replicate.
Posted by: Ron Seybold | Apr 17, 2012 9:04:25 AM
The comments to this entry are closed.