net.digest February 2004

February 2004

net.digest tracks each month’s message traffic on the 3000-L mailing list and comp.sys.hp.mpe Internet newsgroup. Advice offered from the messages here comes without warranty; test before you implement.

Edited by John Burke

January’s traffic on the 3000-L mailing list and newsgroup saw more of the now all-too-familiar off-topic threads, chatter about Iraq or religion, with some commentary Iraq AND religion. However, a somewhat surprisingly large amount of good technical content continued to surface, summarized below and in the Hidden Value column.

While Democratic candidates for US President were slugging it out in Iowa and New Hampshire, some of the best political fighting was taking place on the OpenMPE mailing list. [Editor’s Note: This list has only 361 members subscribed to it, and it’s content is not re-broadcast via a public newsgroup like 3000-L, so these battles might be described as infighting, away from the public eye.] OpenMPE board members were generally defending the group’s approach in negotiating with HP for homesteading help, while interested members generally railed against HP’s intransigence and stalling tactics — as well as the board’s apparent acquiescence to whatever HP says. Whichever side you are on, that OpenMPE list makes for interesting reading. (A full report on the challenges to OpenMPE, including messages from the list, appears on Page 1 of this issue.)

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 3000-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.

You read the patch digests you subscribe to, don’t you?

HP’s Patch Digests (you can subscribe to these reports on the 3000 through the HP ITRC) are usually the only way to find out about problem fixes that have gone in general release (GR). Sometimes these fixes are for a problem you have, but may not be aware you have. By reading the Patch Digests (and installing the patches that might impact you) you may be able to avoid a disaster waiting to happen. A question on the mailing list about why a Patch Digest listed two patches for the same thing gave Gavin Scott the opportunity to point out they described the fix for a potentially disastrous error HP had introduced in a previous STORE patch. STORE does not indicate an error in this case — but in fact creates a tape with some files that are not restorable. Here is what Scott had to say (edited for space):

“I hope everyone is reading these Patch Digests, because the one mentioned describes a bug that was introduced in a previous :STORE patch that can silently create backups which cannot be restored from. If you verify (:VSTORE) your backups then you’d know if you have this problem, but otherwise you’ll only find out if you try to restore files from the backup and then there could be at least one unrecoverable file. If this happens to be a critical dataset and you’re doing an INSTALL/:RESTORE to recover from a drive failure or other disk reconfiguration then this might be a bit of a bother. Apparently you’re most vulnerable to this problem if you use labeled tapes for your backups.

“An excerpt from the patch digest follows. The fix for this problem is in patch MPEMXK1B if you have installed one of the bad patches that introduced the problem. ‘The affected STORE versions are: C.65.23, C.65.24, C.70.15, C.70.16, C.75.03 and C.75.04...MPEMXB6 introduced a problem with STORE’s internal IO buffer handling, intermittently causing stale data to be written to the tape instead of valid file headers or file data. Note that this is a fix to a problem in STORE. Tapes which have been created with the above versions of store and have experienced this problem will continue to see the problem when RESTOREd or VSTOREd once this patch is installed.’”

Patches have hard road to GR

Speaking of Patch Digests, it is becoming increasingly difficult to get fixes and enhancements into GR status. In posting a list of 22 FTP patches that had not gone General Release (GR) in the previous six months because of insufficient beta testers, James Hofmeister commented, “Fewer problems are being fixed due to fewer customers placing calls to the HP-Response Centers and fixes being built are not reaching general release status due to the lack of customer beta test. For example, the FTP patches announced at HP World Atlanta (Item #7 on the Interex 2003 MPE System Improvement Ballot) are not included in the list of General Release patches do to a lack of customer beta test. My feedback is if you identify a problem fixed in a beta test patch and you are waiting for some one else to perform the customer beta test for you, please don’t hold your breath. Be part of the solution and install beta test patches for the problems you see. A second bit of feedback is almost all of the customer beta test I am seeing is on MPE/iX 7.5. If you are holding your breath for some one else to customer beta test your fixes, your best chance is to install MPE/iX 7.5.”

Unfortunately, this is something that is only going to get worse, especially with regard to fixes that are more in the realm of enhancements. Getting enough people to try beta patches has always been a problem. It is worse now because people are hunkering down for the long run, emphasizing stability over new features (or fixes to problems they do not have). If it is not broken, don’t try to fix it. Stability is the watchword at most shops I’ve talked to.

If beta patches were downloadable (today you have to have a support contract and call HP to get a beta patch), perhaps more people would try them, even in an era with fewer customers making changes to their systems. However, I think at this point in time in the life of the HP 3000 that trying to make this happen is probably a waste of effort. Another problem that continues to amaze me is that many people still do not know about, or know how to use, Stage/iX. Stage/iX reduces patch-related downtime to the time it takes to reboot and makes it extremely easy (another reboot) to back out a patch, something that is especially relevant when testing beta patches. Most, but not all, patches can be staged.

As the MPE Forum, HP and Interex prepare to launch a new Systems Improvement Ballot for MPE/iX, I have to wonder whether this SIB is worth the effort — especially if the enhancements that HP develops for us can never get general released.

MPE/iX dates

In response to a question about dates on a store tape, Stan Sieler presented this interesting tutorial on MPE file dates:

Files dates are 64-bit values stored in microseconds, “system time” (not GMT), since 1970. MPE/iX is much more advanced than many operating systems in this area. Most Unix’s, for example, have:

• Fewer timestamps; e.g., usually just “accessed” and “modified,” compared to MPE/iX’s accessed, modified, allocated, created (which can differ if a file was RESTOREd), and “state change.”

• They’re in units of 32-bit signed seconds since 1970, something that runs out of time in January, 2038. MPE/iX’s timestamp won’t run out until about January, 2103, and it provides greater resolution (microsecond), which is useful now that computers can create more than one file a second.

On the other hand, the Unix decision to keep file timestamps in GMT is much better than MPE’s use of “system time” to keep file timestamps.

DSCOPY vs. FTP

There has been a lot of discussion on the mailing list recently about the relative performance of DSCOPY and FTP. James Hofmeister of HP’s WTEC did a number of tests and presented his results in early January. (For his full posting, see the Web page at raven.utc.edu/cgi-bin/WA.EXE?A2=ind0401A&L=hp3000-l&P=R467.) I have summarized the key results below:

• DSCOPY does not support ‘byte stream’ file transfers. Error reported is: SOURCE FILE CANNOT BE BYTE STREAM RECORD TYPE(NFT/3000 ERR 115).

• With current patches FTPHD66/FTPHD67/FTPHD68 FTP ‘byte stream’ file transfer is as fast or faster than binary transfers.

• DSCOPY of ‘typical’ 80 byte or 256 byte ASCII files is 30-35 percent faster than FTP.

• FTP of ‘typical’ 80 byte or 256 byte binary files is 30-45 percent faster than DSCOPY with current patches FTPHD66/FTPHD67/FTPHD68 installed.

• FTP performance drops significantly as the file record length decreases for both ASCII and binary file transfers.

Is firmware an oxymoron?

The Model 20 arrays are becoming very popular for people looking to replace their JBOD on 9x7s, 9x8s and 9x9s for the long haul (I’ll devote a large part of net.digest to the Model 20 next month). The storage devices are plentiful on the used market and very cost-effective. However, there is a Catch-22. The firmware on the HP 3000’s FWSCSI card must be at a certain level to connect to the Model 20. And even determining the firmware level, not to mention actually updating the firmware, requires a suplicense code (fie on you, Rich Sevcik). As Gilles Schipper noted, “The minimum firmware level you want is 3636. 3728 is best (according to notes I have), but 3944, I believe, is the latest for the HP28696 FWSCSI card and may also be satisfactory. Unfortunately, MAPPER will not show you the firmware revision level of the FWSCSI card. The version of MPE you’re running will dictate how to go about determining the firmware level. You need to use SYSDIAG for 6.0 and earlier — CSTM for 6.5 and later. In either case, you will need a suplicense code to unlock the appropriate diagnostic within SYSDAIG or CSTM. You can also use SYDIAG or CSTM to actually upgrade the firmware on your card. Of course, upgrading the firmware will also require the same suplicense code.” Guy Paul noted, “There is a 3944 version available, but that has never been certified on MPE and can cause system aborts on systems with more than 3.75Gb memory.”

HP claims it will do “something” about the passworded diagnostics in the 2006 timeframe. Until then, you have to have an HP support contract to use a diagnostic. However, the prudent IT manager planning to run an HP 3000 after 2006 should be working now to line up third party support, and so may be faced with two contracts for one system just to get a diagnostic password. Not a very customer-friendly approach, in my opinion.