net.digest – September 2002

 

This issue of the 3000 Newswire is being published at the same time HPWorld 2002 opens in Los Angeles. Some of you may even be reading this at the show. This is, of course, the first HPWorld since Black Wednesday, November 14, 2001. Which makes it the most important HPWorld for the future of the HP 3000 since at least the Boston Tea Party meeting over ten 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 SIGMPE and expect to have a very lively meeting on Thursday, the day after HP reveals its current plans. See below for my wish list.

 

As usual, HP3000-L was home to some wild and wacky threads. But the absolute coolest thread, the one that shows the unique character of HP3000-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 HP3000-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 something from these columns helped you, let me know. If you’ve got an idea for something you think I missed, let me know. If you spot something on HP3000-L and would like someone to elaborate on what was discussed, let me know. Are you seeing a pattern here? 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 homesteaders and others.

 

Let me get this fact on the table, because it drives everything else; HP reneged on a publicly stated promise that was re-stated multiple 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". These requests 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 6 requests (somewhat reworded from published OpenMPE wording to reflect my tastes, sensibilities and understanding - any errors or misrepresentations are solely my responsibility).

 

 

Now for some additions.

 

 

Ok, HP, the gauntlet has been tossed. Just do it.

 

In Case You Missed It – 1

 

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 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 rational 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 – 2

 

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 doing the recommending. 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.

 

In Case You Missed It – 3

 

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, quotemarks 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."