Emulating 3000 Bugs, As Well as Features
January 11, 2010
Creating an emulator is detailed work, development which can be tested in the market for years after release. That lengthy timespan of test was illustrated over the past week, when a discussion surfaced on the Internet about how the MPE Command Interpreter (CI) product behaves for HP 3000 emulation.
The discussion over the past 24 hours has opened a window on how the 3000 works at a essential tech level. JCL, which relies on the CI, can be used for programming on the 3000. But the chat also illustrates an issue of using an emulator for any 3000 system, whether it's hardware emulator like the coming Stromasys product, or a environment emulator like Speedware's AMXW. Customers need to rely upon complete emulation, even of features that work differently than they should.
Unlike the long-awaited product to mimic HP's 3000 hardware, AMXW works to re-create the 3000's operating environment on Unix or Windows. The software sold and updated by Speedware has been essential in getting a massive 3000 site onto Unix, when Expeditors International moved a network of more than 150 3000s using AMXW. This weekend a developer asked the 3000 community for help with an apparent expression evaluation bug in the MPE/iX CI. AMXW drifted into the 24-hour chat near the finish.
The CI in MPE/iX behaves differently than expected by several 3000 experts among the 10 who examined this bug. Some of them called it a bug, conjuring up the redoubtable phrase, "That's not a bug, it's a feature." In this instance, the CI's unique evaluation methods should be mirrored in any emulator environment. Please replicate bugs, said one expert with emulator development experience.
When Walter Murray, Keven Miller, Denys Beauchemin, Roy Brown, Neil Armstrong, Olav Kappert, John Pitman, Ken Robertson and Steve Cooper start talking about MPE/iX behavior, you can be sure you're getting a complete lesson. All of these men have developed commercially for the 3000, many of them for more than three decades.
Murray, who developed in HP's 3000 COBOL labs before he left the company, asked if he'd found a bug in the CI. He's running the latest release of MPE/iX; his employer is making a long-term migration away from the HP 3000.
Am I missing something really obvious, or is this a bug in the MPE/iX Command Interpreter's expression evaluation? Enter the following commands from the CI prompt (or execute them from a command file or in a job stream):
SETVAR A1 1
SETVAR A2 2
SETVAR A3 3
IF A1=999 AND A2=2 OR A3=3
ECHO TEST PASSED
ELSE
ECHO *** TEST FAILED ***
ENDIF
I am running MPE/iX 7.5 PP 3. Interestingly, [Vesoft's] MPEX gets this right. Is this a well-known problem that we just now stumbled upon?
A detailed debate ensued over how IF statements should evaluate expressions. AMXW played its small part when one of the experts on the CI mentioned the formidable emulator. Ken Robertson, who wrote a dandy article on the CI in the NewsWire during 2003, reported on the emulator's binding in IF statements. He even worked in a programmer's joke into his report.
For what it's worth for anyone running AMXW in their shops, it uses left-to-right binding for IF statements. Under AMXW running under HP-UX:
::SETVAR A1 1
::SETVAR A2 2
::SETVAR A3 3
::IF A1=999 AND A2=2 OR A3=3
*** EXPRESSION TRUE
::ECHO TEST PASSED
TEST PASSED
::ELSE
*** COMMANDS IGNORED UNTIL MATCHING ENDIF
::ECHO *** TEST FAILED ***
::ENDIF
*** RESUME EXECUTION OF COMMANDS
::
The original example logic runs as I believe it should, but is not compatible with MPE! Whether this is a good or bad thing, the opinion seems to be divided.I don't believe that we need parentheses to bind the order of our opinions correctly! Let our thoughts multiply or we can add our 0.02. Whoops... integers. That's zero that I'm adding. Hmm...
In addition to Beauchemin's quip about hurrying to submit this bug to HP (where 3000 bug fixes have ceased), Murray wondered if HP's docs describe accurately how the CI works. Parentheses look like a workaround to him. "It never occurred to me to use parentheses to cope with bugs in the expression evaluator," he writes. "I am not convinced that the CI is handling this expression as documented, but it's moot."
Not moot: How an emulator should handle such bugs. Replicate them, said Steve Cooper of Allegro Consultants, which sold an emulator to move the 3000's original SPL language to the new PA-RISC hardware. "If AMXW does not do what MPE does, that's a bug in AMXW, period," he writes. "Emulators have to be bug compatible, if they are to be good emulators. We certainly learned that with the SPLash! compiler, for instance."
Murray added advice for any site that's making a migration at this level, moving Job Control Language as well as program code to a new environment. Keep logic out of JCL. Since the JCL on many 3000s is being rewritten as Unix scripts, it's an option to consider.
This discovery reaffirms my uneasiness about putting too much logic in JCL. Where feasible, I tend to put more logic in executable programs, and less in JCL. I feel that the compilers are more reliable than the CI, and the programming language documentation is more precise than that of the CI.
Meanwhile, Cooper confirmed that HP's documentation does describe the CI behavior, so programmers of old systems may have written code that relies on the feature -- er, bug. "I don't like it either, but it is working as documented," he says. "We have exactly the case in that last paragraph of the documentation: a part evaluates to FALSE and is followed by an AND. Sorry, no bug here, just a weird design that I'm sure people are counting on at this point."
AND that's why a low-risk migration should follow the path of original design whenever possible. "We'd like our bugs migrated, please," ScreenJet's Alan Yeo relayed from a customer last year.