net.digest – March 2004

 

If we (MPE Forum and vCSY) have our way, by the time you read this, voting will have concluded, or will be about to conclude, on the 2004 System Improvement Ballot (SIB). This year’s SIB is radically different, as befits the current status of the HP e3000 and MPE/iX. The ballot is split into two, one a ballot on strategic items and the other the more traditional tactical items. Hopefully you voted (or will vote if voting is still open). vCSY has indicated there are engineering resources available to address items of benefit to homesteaders and/or migrators. Results are scheduled to be release by the West Coast Solutions Symposium.

There is another vote scheduled for March, a vote 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, or Iraq and religion and 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. 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.

 

Two for the price of one.

 

Many people may have missed the second part of this thread because the subject never changed from the original “997 and memory.” In answering the original question, Craig Lalley noted he would not recommend the maximum memory because “The problem is the 180 MHz 997 processor. At 180 MHz, 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 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.

 

Something that bears repeating,

 

because even an MPE expert was not aware of the 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. 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 HP3000-L describing a problem they are having configuring (usually) a new disk drive(s). 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 CSY Labs, which we excerpt here.

“Starting with MPE release 7.5, generic device ids have been added to the IODFAULT file to help facilitate the configuration of I/O 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 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 device(s)

“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, compilers etc, 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.” Conspicuously absent was any comment from HP or OpenMPE. 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 post 2006. The sooner these questions are answered, the better people will be able to plan.

 

For all the conspiracy theorists out there – 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, the same date as the 7.0 and 7.5 releases of MPE/iX.” HP has been publicly considering the move since at least as far back as HPWorld 2003 when it floated the possibility before several groups. Third party vendors were generally not in favor since it would force them to continue to support and validate their software releases on three different OS releases. HP had realized, however, that over half its HP e3000 installations on HP support were still on MPE/iX 6.5 and either did not want to move to MPE/iX 7.0 or MPE/iX 7.5 or could not move because they were running one or more 9x7 systems, were using HP-IB peripherals, etc. 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. It also means that, although existing MPE/iX release 6.5 patches will continue to be available, new patches will be limited only to critical defects, and in specific situations HP's resolution to a particular problem may require the customer to upgrade to MPE/iX release 7.0 or 7.5."

Users wanting to keep running an HP-supported version of MPE/iX 6.5 for whatever reason through 2006 should be happy. HP is certainly happy because, first, it does not risk losing even more support customers to third party support or self-support. And, 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 and interested parties who should be unhappy about this development, those who have been campaigning for HP to remove the prohibition against MPE/iX 7.0 and MPE/iX 7.5 booting on 9x7 hardware. Remember, this prohibition was put in strictly for marketing reasons, to get a bump in new system sales when the A- and N-class systems were introduced and not for technical reasons. Unfortunately for HP, many customers felt there was insufficient 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 (probably) recently concluded 2004 SIB voting, I expect this to score at least as high. However, this announcement (of continued MPE/iX 6.5 “support”) effectively gives HP’s answer to those wanting it to unleash MPE/iX 7.x, “no way in Hell” while at the same time being able to claim it is supporting what users want.