net.digest March 2004

March 2004

Net.digest summarizes helpful technical discussions on the HP 3000 Internet newsgroup and 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

If the MPE Forum and HP’s virtual 3000 division (vCSY) have our way, by the time you read this voting will be about to conclude on the 2004 System Improvement Ballot (SIB). This year’s SIB (at the Interex Web site at www.interex.org/advocacy/survey/mpesib2004.html) is radically different, as befits the current status of the HP 3000 and MPE/iX. The ballot is split into two, one ballot for strategic items and the other for more traditional tactical items. vCSY has indicated there are HP engineering resources available to address items of benefit to homesteaders and migrators. Results are scheduled to be released by the West Coast Solutions Symposium March 29.

There is another vote scheduled for March, an election for several slots on the Board of Directors for the recently re-organized OpenMPE. If you have any interest in the future of MPE, join OpenMPE (membership is still free) and vote in the election for new board members.

February saw more of the now all-too-familiar off-topic threads about Iraq or religion or politics. However, once I deleted all the chaff, there was a surprisingly large amount of good technical content, some of which we summarize below.

I always like to hear from readers of net.digest and Hidden Value. Even negative comments are welcome. You can reach me at john@burke-consulting.com.

Two for the price of one

Many people may have missed the second part of this thread because the subject never changed from its original “997 and memory.” In answering the original question, Craig Lalley noted he would not recommend the maximum 997 memory because “The problem is the 180MHz 997 processor. At 180MHz, it takes about 80 seconds to scan memory in a fully loaded 997. That could make the XM checkpoints quite painful. During the checkpoint the XM will scan memory for dirty pages to post. This is the notorious pin 11 or 12 that people see periodically on the system (pin 17 for N-Class boxes). Scanning memory creates a lot of system overhead. There is a patch to reduce the effect of semaphore locking (MPEMX34A, though probably superseded).

“The real problem, though, is when the second checkpoint hits, before the first has time to finish, i.e. they collide. To compensate for this, it is possible to increase the size of the XM log file and reduce the time between checkpoints (note this must be contiguous space). The good news is that the XM checkpoint is a serially threaded process; hence, it will only use up one processor (better have a few if you have maximum memory). The problems I am discussing are for very heavy data entry systems. The XM (transaction manager) is a write cache. Generally, more memory will help batch reporting, it does not always help on-line response times.”

Oh, by the way, the 997 supports up to 16Gb of memory, depending upon the OS level.

Run it again for contiguous space

Here’s something that bears repeating, because even an MPE expert was not aware of this workaround. As noted above, the XM log file requires contiguous disk space. Other files also require contiguous disk space; for example, consider the contiguous disk space on LDEV 1 required for an OS update. If you do not have one of the several third-party products that will create contiguous disk space on a drive, you may still be able to get enough free space by using CONTIGVOL. However, occasionally, CONTIGVOL will stop with the following, “*Warning: Contigvol - Inverse Extent Table Full, Internal resource limit.” What can you do? Run it again. HP’s Goetz Neumann provided the following explanation, “It is a warning that an internal table has filled up. It appears CONTIGVOL only handles looking at 40,000 extents at a time. There was an enhancement request (back in 1997) to increase the internal tables, which HP decided not to work on. You can run CONTIGVOL multiple times if the first run does not condense the free space enough because of this limitation.”

Finally, generic device IDs

It appears HP quietly added an enhancement to MPE/iX 7.5 that many of us have been requesting for years, generic device IDs. Every few months, someone posts a question to 3000-L describing a problem they are having configuring (usually) a new disk drive. They will say that it is a Seagate STnnnnnn drive, for example, but STnnnnnn is not listed in IODFAULT.PUB.SYS, so how are they to configure it in SYSGEN? Somebody usually writes back with the advice first offered, I believe, by Denys Beauchemin; i.e., any SE device ID will work for an SE drive and any FW device ID will work for any FW drive, etc. Thanks to Jon Ose for pointing out a 7.5 Communicator article by Larry Nichoalds, of HP’s CSY labs, which I excerpt here.

“Starting with MPE release 7.5, generic device IDs have been added to the IODFAULT file to help facilitate the configuration of IO devices. The generic IDs are particularly useful for configuring disks, since they tend to change every few months and their respective IDs tend to be quite cryptic. Now they need only be identified as the disk type category. For disk there are three different types: LVDDISK, HVDDISK, SEDISK.

• LVDDISK low-voltage differential disks. These are used on A- and N-Class machines associated with the A5149A and A5150A adaptor cards.

• HVDDISK high-voltage differential disks. These are used primarily on Hawk [9x9] platforms, but are also available on A- and N-Class machines using an HVD card; e.g., A4800A or A5159A.

• SEDISK single-ended disks. These are used mainly by Hawk platforms, but could be used on an A- and N-Class machine using an LVD bus. However, if SE disks are used on an LVD bus and other LVD devices exist on the same bus, the performance of the LVD devices is limited by the SE devices.

“For all disk arrays, use HPDARRAY. Products, such as DVD, CDROM, and UPS, can be configured by simply using the appropriate generic name. Tape devices fall into one of two categories; i.e., DDS or DLT (non-DDS) tape products.”

Three important questions for HP and OpenMPE

Alan Yeo posed the following: “A customer has a 64-user 9x9 HP e3000, running MPE/iX 6.5 and a bunch of correctly-licensed HP subsystems and compilers. It is all on support with HP and they keep it on support through the end of 2006. In 2007, they purchase a secondhand N-Class box with MPE/iX 7.0 or MPE/iX 7.5 on it.

1. After 2006, do they have to ensure that the box comes with an MPE/iX license, and do they still have to arrange the transfer of the license via HP to legally use the system?

2. If the box came without some of the subsystem software that they had on the 9x9, can they just transfer the software, or if different versions are required for 7.0 or 7.5, can they obtain these freely from any source they like?

3. After 2006, if you have an HP e3000, will you be able to obtain and load any version of MPE/iX and any subsystem software, such as compilers, without any licensing or cost issues?”

Several people offered opinions about what they thought was right, but ultimately, Stan Sieler had the final word. “Lawyers trump morals,” he said. Conspicuously absent from the list was any comment from HP or OpenMPE’s directors. All HP has said to date is that it plans to keep the license transfer mechanism functioning past 2006 and that it is “investigating” subsystem issues for post-2006. The sooner these questions are answered, the better people will be able to plan.

For conspiracy theorists — and you know who you are

On February 17, with appropriately modest fanfare, HP announced it would continue support for MPE/iX 6.5 through December 31, 2006. HP has been considering the move since at least as far back as HP World 2003. Third-party vendors were generally not in favor, since it would force them to continue to continue to support and validate their software releases on three different MPE/iX releases

HP had realized, however, that over half its HP e3000 installations on HP support were still on MPE/iX 6.5 and older releases. They either did not want to move to MPE/iX 7.0 or MPE/iX 7.5, or could not, because they were running one or more 9x7 systems or were using HP-IB peripherals. HP came up with what I am sure it thinks is a brilliant solution. “Support customers electing to stay on MPE/iX release 6.5 can expect no new enhancements and no new peripheral support to be offered.”

Users running an HP-supported version of MPE/iX 6.5 should be happy. HP is certainly happy. First, it does not risk losing even more support customers to third-party support or self-support. Second, since it is limiting new patches to “critical defects” only, it costs HP next to nothing to continue “support” (sarcasm intended). Third-party ISVs are reasonably happy, because they know no changes are likely to be made to MPE/iX 6.5 that will affect their software.

This is not why I alerted conspiracy theorists, however. There is another group of users who should be unhappy about this development — those who have been campaigning for HP to remove the prohibition against 7.0 and 7.5 booting on 9x7 hardware. Remember, this prohibition was put in strictly for marketing reasons, to give HP a bump in new system sales when the A- and N-Class systems were introduced — not for technical reasons. Unfortunately for HP, many customers felt there was not enough added functionality in MPE/iX 7.x to drive them to trash their perfectly functional 9x7s for the new A- and N-Class boxes.

The number six vote getter on last year’s SIB was “Enable MPE/iX 7.x to boot on 9x7s post 10/31/2003.” In the 2004 SIB voting, I expect this to score at least as high. However, the announcement of continued MPE/iX 6.5 “support” effectively gives HP’s answer to those who want it to unleash MPE/iX 7.x: “No way in hell.” At the same time, HP is able to claim it is supporting what users want.