Epic Sponsor Message

September 2002

Net.digest summarizes helpful technical discussions on the comp.sys.hp.mpe Internet newsgroup and 3000-L mailing list. Advice here is offered on a best-effort, Good Samaritan basis. Test these concepts for yourself before applying them to your HP 3000s.

Edited by John Burke

This issue of The 3000 Newswire is being published at the same time HP World opens in Los Angeles. Some of you may even be reading this at the show. This is, of course, the first HP World since Black Wednesday, November 14, 2001. Which makes it the most important HP World for the future of the HP 3000 since at least the Boston Tea Party meeting over 10 years ago.

Why? This is our last chance to influence HP about what the landscape and ecosystem will look like in the 2003 to 2006 period and beyond. I’ll be there as chairman of SIG-MPE and expect to have a very lively meeting on Thursday, the day after HP reveals its current plans. Read on for my wish list.

As usual, 3000-L was home to some wild and wacky threads. But the absolute coolest thread, the one that shows the unique character of 3000-L the best, was the one that started out questioning if anyone knew of someone who had successfully migrated from MANMAN to SAP. By some totally weird logic this eventually morphed into a thread about who was the best drummer of all time. And, of course, this being 3000-L, we “settled” on about a dozen and a half drummers with at least one vote as best ever.

As always, I would like to hear from readers of net.digest and Hidden Value. Even negative comments are welcome. If you think I’m full of it or goofed, or a horse’s behind, let me know. If you spot something on 3000-L and would like someone to elaborate on what was discussed, let me know. You can reach me at john@burke-consulting.com.

HP, it is well past time to stop dallying and do the right thing

Did I say wish list? I meant demands. First off, lest anyone accuse me of favoring one approach over another, let me point out that HP and its Platinum Partners have the migration area already well covered, at least for those who figure to migrate within the next couple of years. For those who plan to migrate, but need more time, the demands below are equally important to you as they are to HP 3000 homesteaders and others.

Let me get this fact on the table, because it drives everything else; HP reneged on a stated promise to stick with the 3000 that was re-stated many times publicly over several years. People and companies made career and business decisions based upon this promise. HP’s decision to renege on this promise has cost, and will cost, its customers hundreds of millions of dollars in expenditures, all with very little payback. Careers have been destroyed. Many third-party vendors have been mortally wounded.

Is it too much to ask HP to do the right thing? I think not. In fact, I think they owe it to us.

First, OpenMPE’s “gang of six” requests. These have been floating around in various forms for many months, some even dating back to shortly after the November 14 announcement. OpenMPE condensed much of the discussion into these six requests (somewhat reworded from published OpenMPE wording to reflect my tastes, sensibilities and understanding — any errors or misrepresentations are my responsibility).

1. “Remove or publish the passwords for MPE-unique utilities (for example, sysdiag) no later than the end of support (EOL) in 2006.” Passwords were usually put on the utilities to protect HP’s intellectual property (and support revenue stream). After EOL, there is no longer any revenue stream to protect. This should be a no-brainer.

2. “Enable MPE license transfers / upgrades and hardware re-configuration (add / upgrade processors, etc.) on PA-RISC hardware to continue after end of HP sales and support; for changing user license levels, acquiring used e3000 systems, etc.” I go somewhat further here: remove all licensing restrictions sometime after EOS. Put MPE/iX binaries in the public domain. Furthermore, license SSCONFIG (possibly for a fee) to individuals or third parties to enable hardware upgrades, maintenance and unfettered commerce in used systems and equipment.

3. “Allow third-party creation and beta testing of an MPE emulator to start in 2002, and commit to allowing users to buy and run a third-party emulator without having to give up existing MPE licenses on PA-RISC hardware. No HP emulator restrictions after 2006.” The key here is the licensing issue. Repeat from above, remove all licensing restrictions and put MPE/iX binaries in the public domain.

4. “Allow non-HP access to, and escrow of, MPE source code.” HP may not be legally required to do this, but it is the ethical thing to do. What possible purpose is there to holding on to this material?

5. “Put all MPE documentation in the public domain no later than the end of 2006.” To me this includes all internal documentation as well (perhaps sanitized as necessary though I am not sure I understand why this would be needed). This should be a no-brainer.

6. “Enable third-party e3000 software support after 2006.” I take this to mean make the tools available so that third party software maintainers can actually create and distribute patches as necessary. These tools and documentation are specific to the HP 3000, so why not release them?

Now for some additions to the gang, from my viewpoint.

7. By HP’s end of sales, provide a low-cost method for users to “un-cripple” the CPUs on all A-Class and N-Class systems that have been slowed down compared to their HP 9000 hardware equivalents. The crippling of the MPE/iX systems is probably one of the worst kept secrets in the community, so I don’t think I’m betraying any trusts here. For example, there is no 110-MHz processor. It is actually a 440-MHz processor that has been crippled in such a way as to provide only about one-eighth the overall computing capability. At a premium, no less, to the un-crippled 440-MHz A-Series HP-UX box. Call it an end of sales “gift” to customers who bought into the A-Series in good faith. Whatever, it is the right thing to do.

8. Allow MPE/iX 7.x to boot on 9x7 systems. This was a pure marketing decision made long before the HP 3000 was end of lifed to try and pump up sales. Obviously, it did not work as well as HP had hoped. So why not, as a gesture of good will, roll it back? Again, at this point it does not affect revenue and actually helps not only customers, but also third party software vendors and maintainers (potentially fewer releases to support). As a side benefit for HP, it could probably end the life of MPE/iX 6.5 sooner, thus having fewer OS releases to support in the 2003 to 2006 timeframe.

9. Finally — and this is just a pet peeve of mine — stop with all the insulting, grandfatherly tone of advice. Stop saying, and here I am quoting someone from HP, “I don’t know if the decision to discontinue MPE was right or wrong. But I think the thought process that led to the decision was one in which ‘what’s right for the customer’ was the number one motivation.”

Please do not try to tell me what is best for me. For years we’ve had to beg, plead and cajole to get improvements to MPE/iX and the HP 3000, because HP would not do anything until some undefined critical mass of customers virtually demanded it. The mantra was “customer-focused engineering,” a great concept until taken to the extreme that HP did. “Customer-focused engineering” is the chief reason the HP 3000 was always late and short on new technologies. Perhaps if more people had been paying attention to “what’s right for the customer” years ago, we would not be in the situation we find ourselves.

Okay, HP, the gauntlet has been thrown down. Just do it.

What’s inside a name?

Two of the reasons why the licensing of MPE/iX after October 31, 2003 is such a key issue are HPSUSAN and HPCPUNAME. These variables can currently only be changed by an HP CE using the SSCONFIG program. So what happens after 2003 when you try to buy an extra processor on the used market and try to add it to your system? Unless you pay HP to have a CE install it and change the CPUNAME, MPE/iX will not be able to use the extra processor. What about after 2006 when HP no longer plans to support any HP 3000? What do you do then?

Another example? Suppose your system board dies and you buy another one identical to the first. Again, unless an HP CE installs it and changes the HPSUSAN value to the original, most, if not all, of your third-party software will fail to work.

Wirt Atmar pointed out — in the midst of a thread about Linux, of all things — that nothing like HPSUSAN or HPCPUNAME existed on the Classic HP 3000s. In fact, they were added to the PA-RISC machines, primarily after years of prodding by software vendors who wanted a way to protect their intellectual property.

Some Patch/iX shenanigans

The question posed on 3000-L was something I do not remember ever seeing asked before: “The System Software Maintenance Manual rather strongly states that if you’re adding on a HP software product (SUBSYS tape), you need to run AUTOINST on a ‘quiet’ box. Does the box really have to be quiet just to make the tape?”

A couple of us, myself included, jumped in with some variation on “Why don’t you use Patch/iX instead of AUTOINST?” We then went on to extol all its virtues, such as creating the CSLT/STORE tape (Phase I) online without effecting production. And, of course, by creating the CSLT/STORE tape before taking the system down, you can run CHECKSLT and VSTORE before applying the CSLT/STORE tape late some night, thus saving yourself from the disaster of having a bad CSLT/STORE tape. We felt pretty impressed with ourselves until the original poster pointed out that indeed Patch/iX does not give you the option of applying just a SUBSYS tape.

Oops. But we recovered quickly by suggesting the use of the most recent PowerPatch tape with the SUBSYS tape. The rationale is that Patch/iX will disqualify all the patches because either the patch was already installed or a superceding patch was installed. Of course, even if this doesn’t work, there is nothing lost and you can go ahead with AUTOINST.

In case you missed it

The original thread was titled “c89 and permissions (more newbie stuff)” so you might have missed this little nugget. Do you know whether a user needs to have “PH” capability to run a program that calls intrinsics requiring PH capability? It turns out a lot of people don’t know the answer. Denys Beauchemin pointed us to the relevant passage at docs.hp.com:

“In order for a program containing PH intrinsics to execute successfully, the following criteria must be met:

“You must assign the PH capability to the program file at link time (using the caplist parameter of the :LINK command). The user who links the program does not need to be assigned the PH capability in order to assign it to the program file.

“The System Manager (SM) or Account Manager (AM) must assign the PH capability to the group where the program is to execute; however, if the program file is a temporary file, PH must be assigned to the user who executes the program.”

Think twice before you START NORECOVERY

Even if it is HP recommending you do the starting. More than likely, if your idea for avoiding it does not work, you can still START NORECOVERY later. If it does work, then you’ve saved yourself some downtime, not to mention some sleep. So think it through first.

What brought this on? Someone posted a problem they were having with a DTC printer. It had the wrong profile. Apparently, they tried changing the profile in NMMGR and doing the dynamic re-configuration after validation, but NMMGR was not smart enough to recognize that a change in profile name from one printer profile to another should trigger a re-configuration of the device. Incredibly, HP supposedly told the user to do a START NORECOVERY! Another user posted a follow-up saying they had a similar problem, though this time the only thing that changed was the device class.

Aargh! There may have been something else going on at these sites that they were not telling us, but could it have hurt to do the following? First delete the printer from the DTC, making the port a terminal. Now do the dynamic configuration part. No printer on that port. Go back into NMMGR (actually you never leave it) and now add the printer back in with the correct profile and do the dynamic configuration. Should work every time. If it still does not work, then power cycle the DTC (assuming host-based DTC management). If for some other reason this does not work, you can still do a START NORECOVERY and you have not lost anything. But you have tried everything in your arsenal.

Eliminate the end

Tired of the “END OF PROGRAM” in a job stream initiating a page eject and, in the case of multiple programs running one after the other, pages with “END OF PROGRAM” at the top and the rest blank? Buried in a seemingly unrelated thread was the reminder that either the “implied run” (just mention the program name) or replacing “RUN” with “XEQ” eliminates the “END OF PROGRAM” and thus the page eject. The only qualifier is that “implied run” and “XEQ” only support the “PARM” and “INFO” parameters.

…And speaking of implied run

Several threads suggested there was a surprising lack of understanding of “implied run.” I have to admit I was not aware of a couple of features, so from the MPE/iX Commands Reference Manual:

“The RUN command is parsed by the Compatibility Mode parser unless it is implied, in which case the Native Mode parser is used. To use the implied version of RUN simply omit the word run and enter the name of the program along with either the INFO or PARM parameters.

“Because the Native Mode parser is used with implied run you can use quotes (“ or ‘) with the program file name and/or the ;INFO= parameter. Also, quotes are not required if the parameter contains no delimiter characters such as a blank, comma, semicolon, quote marks or equal sign. In addition, the ;INFO string can be up to 280 characters long and the ;PARM= value can be any signed 31 bit number. Without implied RUN the ;INFO limit is 255 characters and the ;PARM= value is limited to a signed 15 bit decimal or unsigned 16 bit octal or hex value.”

John Burke is the editor of the NewsWire’s HiddenValue and net.digest columns and has more than 20 years’ experience managing HP 3000s.