January saw more of the now all-too-familiar off topic threads about
Iraq or religion, or Iraq and religion. However, there continues a somewhat
surprisingly large amount of good technical content, which we summarize below
and in Hidden Value.
While the Democratic candidates for President were slugging it out in
Iowa and New Hampshire, some of the best political fighting was taking place on
the OpenMPE list, with Board members generally defending its approach in
negotiating with HP and interested members generally railing against HP’s
intransigence, stalling tactics and the Board’s apparent acquiescence to
whatever HP says. Whichever side you are on it makes for interesting reading.
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.
Patch Digests
(subscribe through the ITRC) are usually the only way to find out about problem
fixes that have gone general release (GR). Sometimes these fixes are for a
problem you have but may not be aware you have. By actually 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 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 introduced in a
previous STORE patch. STORE does not indicate an error 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.'"
Speaking of Patch Digests, it is becoming increasingly difficult to get fixes and enhancements GR
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 HPWORLD 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 (currently you have to have a support contract and call HP to
get a beta patch), perhaps more people would try them even now. However, at
this point in time in the life of the HP 3000, 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,
combined with HP and Interex, prepare to launch a new SIB, I have to wonder
whether it is worth the effort if enhancements that are developed can never get
released.
MPE/iX dates
In response to a
question about dates on a store tape, Stan Sieler presented this interesting
tutorial of 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 won't run out until about 2103-01-10, 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 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 the full
posting, see
http://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% faster than ftp.
·
Ftp of
'typical' 80 byte or 256 byte binary files is 30-45% 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 deveote a large part of net.digest to the Model 20 next month). They 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 Rich Sevcik). As Gilles Schipper notes, "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 suplicens 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 has never been certified on MPE and can cause SA on systems with > 3.75GB memory."
HP claims it will do “something” about the
passworded diagnostics in the 2006 time frame. Until then, you have to have an
HP support contract. However, the prudent IT manager planning to run an HP 3000
after 2006 should be working now lining up third party support and so may be
faced with two contracts for one system just to get the diagnostic password.
Not a very customer friendly approach in my opinion.