As the HP 3000 patching process gets more complex, customers and developers posting to the Internet newsgroup are trading notes about moving to the latest version of MPE/iX. HP makes a blanket recommendation that customers should be on the latest version of the operating system. But more pragmatic approaches are easier to find on the Internet — basically, systems that aren’t in need of the patches don’t get them applied.

It may well have been such an approach that led Joe Geiser to ask if he should install the patch that he’d ordered and received for his development system. “I’ve seen some horror stories here, and heard them elsewhere,” he posted in late September. “I’ve also heard good things. Should I, or shouldn’t I, update the 918DX to PP5?”

Such a question can spark two kinds of replies: blanket endorsements and corner cases for problems. Both surfaced in the Internet traffic, along with a reminder that the release’s Year 2000 intrinsic problem was still unfixed at presstime. “I’ve installed it at more than a dozen customers without a single significant problem,” reported system administration veteran Gilles Schipper. And Mike Berkowitz reported that he’d installed it on a Series 995 and had three weeks of no problems.

Developers and some customers making regular use of Posix — or scripts that rely on Posix — pointed out a PowerPatch 5 patch that causes trouble. “If you install PP5, skip MPEJXV9B or else your Posix directory purges will be seriously broken,” said porting king Mark Bixby. “I fell victim to MPEJXV9B long before PP5 was released.”

Bixby went on to explain, “There’s no fix yet for MPEJXV9B. If you install MPEJXV9B onto your system, recursive directory purges (i.e. rm -R) fail and leave non-zero user counts on your Posix directories than can only be cleared with a system reboot. A workaround that avoids the problem is to use the MPE :PURGEDIR ;TREE command. So if you do much work with Posix or HFS directories, do not install MPEJXV9B.”

The faulty patch can be skipped over by using the Patch/iX software to install the PowerPatch, something that led Patch/iX engineer Scott McClellan to argue for installing PowerPatch 5, sans MPEJXV9B. “This means, ‘veto the patch,’ not ‘avoid installing PP5’,” McClellan said.

Writing from a chair in the HP MPE lab, he added his own perspective on the worthiness of the PowerPatch. “The MPEJXV9B problem (as I understand it) is limited to the Posix shell rm -R (recursive) command. MPE purges, with or without the ;TREE option and shell rm commands without the -R option are NOT effected. Therefore the MPEJXV9B problem is only a show stopper for a very specific subset of our users. I am very glad Mark pointed out the problem, and I agree that it is serious, particularly for Mark, but many/most customers would not be effected. This would include many/most customers that use Posix. I guess my general take on this issue is that it is not a very good reason for most customers to avoid PP5.”

A few developers then pointed out that the Posix directory problem could well affect more users than McClellan identified. Michael Hensley, whose continuing work has created the FREEWARE tape of MPE utilities, said “I have to disagree here. Any user who executes any scripts that contain “rm -R” will also run into this problem. Unless you’re willing to read every line of every script you use (and don’t forget any that are executed by batch jobs), you could run into this quite easily. For example, I have no idea which, if any, of the installation scripts on the FREEWARE tape do an “rm -R.”

Hensley, never bashful about advice for 3000 customers, gave his guideline for the PowerPatch. “If you plan to use POSIX— Java, Samba, Apache [web server], or anything else — don’t install the MPEJXV9B patch. If you already have, bug the response center for a way to de-install it. And don’t buy the ‘back out the entire PowerPatch tape and re-install it without that patch’ answer unless you have a lot of free time and are really bored.”

The PowerPatch has also been reported to cause problems for Oracle users who rely on the Oracle Gateway software. While this is a smaller set of customers than those using Posix, the problem caused one customer to return to PowerPatch 4. “I have already had to back out this patch after suffering Oracle Gateway issues and a few system aborts on a very stable machine,” said Jeff Mikoli.

Problems for an even smaller group of sites are occurring with a combination of PowerPatch 5 and use of the HPDATEDIFF intrinsic. HP hadn’t posted a fix for the problem yet, one where HPDATEDIFF is only returning 16 bits of the status parameter, and the wrong 16 bits at that — the ‘.subsys’ member. It does not appear to be returning a misaligned 32 bits, since none of the guard values were changed. HPDATEDIFF is also apparently mis-reading input, since a change in the ‘.info’ member of the output-status parameter on input causes a change in the returned status value. The problems are occurring for a smaller group because HPDATEDIFF is relatively new and not in wide use yet.

There’s not an easy way to back out only the single MPEKXB5 or MPEJXV9B [HPDATEDIFF] patches if you’ve already installed PowerPatch 5. McClellan, certainly the expert on using Patch/iX to manipulate portions of PowerPatches, said “In theory, you could create a staging area with all the patches except the one you don’t want and boot from the staging area. Similarly you could create a CSLT tape (minus the patch you don’t want). Patch/iX has the veto facility.”

“The problem is that Patch/iX only knows how to patch the ‘current operating environment.’ This means that you have to put the system back into a state where the patches are not installed before running Patch/iX. If you uses a CSLT tape then this requires a “backdate,” which is “painful.”

“With Stage/iX you could reboot from the “previous” staging area (not as “painful”) and create a new staging area that contains all the patches minus the one you don’t want. The lab is aware of the problem that since some patches are not stagable, most PowerPatch tapes are not stagable. We are working on a reasonable solution.”

Old intrinsics never die

A programmer wondered aloud if there was a likely finale for older command intrinsics on HP 3000s like FOPEN, more difficult to use than its newer HPFOPEN counterpart. “A lot of programmers are still using the older intrinsics when there are native mode equivalents available. These newer intrinsics have been around for years, and I expect the older ones to disappear sometime — maybe with the new 64-bit CPUs?”

While HP didn’t weigh in on the discussion, a few messages indicated that killing off such older intrinsics in favor of newer counterparts was un-3000-like. “If these older intrinsics should ever disappear, an HP 3000 won’t be an HP 3000 anymore,” said Wirt Atmar, “and a billion software packages (most likely including MPE itself) won’t run anymore. (A billion may be a stretch, but the general idea’s in there somewhere.)

“The first rule of writing any software package — and most especially an operating system— is: If you put something into the package, you can never take it out, so be very, very careful about what you put in.”

John Zoltak added, “As far as FOPEN going away, I don’t think so. Even parts of MPE/iX use FOPEN. And as long as we have compatibility mode there’s no way these older intrinsics are leaving.”

As to why the older intrinsics still get used in new programming, Doug Werth offered the “if it’s not broke, don’t fix it” theory: “I believe the main reason that people still program using the older intrinsics is because much of the programming is maintenance programming on existing applications. There is no strategic advantage to re-coding an existing FOPEN to be an HPFOPEN. To do so would require decoding the bit masks and translating the results into the new parameters, potentially breaking the code.”

A 3000 performance speedometer

On a system without a performance management tool, one user wanted to know how to find the process number of the memory manager, “so that by looking at two showproc listings one can estimate the load of the memory manager on a system.” Stan Sieler confirmed that you can’t find such a process number, but answered the likely question about performance.

“On the chance that you aren’t really interested in the memory manager so much as in overall performance... If you’re concerned that you don’t have enough memory, then you can do a relatively simple test. When your throughput isn’t as good as you want (i.e., during a period when you think there might not be enough memory), check the CPU “speedometer.” On the hardware console, press control-B, and then observe the hex number in the lower left of the status line. It should alternate between FFFF and FxFF. That “x”, multiplied by 10, is the percentage busy of the CPU. Thus, F8FF is 80 percent CPU busy. FAFF is 100 percent CPU busy. F0FF is idle. (Enter: CO <return> to turn off the display)

“What’s the value? My rule of thumb is that if the value is about 70 percent or so, you can benefit from a faster CPU. If it’s below 70 percent, then you might benefit from more memory. Why the doubt? Well, we started with the proposition that the machine was busy ... so why isn’t it fully utilizing the CPU? Because processes are waiting for some things.

“There are three basic things processes wait for:

• Time (e.g., PAUSE intrinsic)

• Disk I/O (e.g., random disk reads, or memory manager handling a page fault)

• Locks (e.g., DBLOCK, FLOCK, or internal locks done by the operating system and/or subsystems and/or applications).

“From the speedometer, we can’t tell what kind of waits are being done.

“Of the above three classes, only some of the disk I/Os can be alleviated by adding extra memory. Paradoxically, in some cases, extra memory can increase the costs of some locking operations (e.g., FLOCK).

“Bottom line: if you’re asking because you think more memory might help... do some tests, borrow the memory, do some tests. If it helped, buy the memory.”