HP Sponsor Message

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.

December, 1999

Edited by John Burke

Okay, Okay. I’m finally getting around to keeping my promise to discuss Mark Bixby’s Patchman script and how it can help you manage reactive patches. Also in this issue, Bill Lancaster discusses the use of HP’s model 12H AutoRAID with MPE/iX.

Of course, in addition to the technical discourse on HP3000-L last month, we were treated to discussions about when the New Millennium really starts, HP’s new garage logo, the IPO for Agilent (HP’s spinoff), what is “dry ice” called in different parts of the world and whether e-services is so much e-nonsense. Oh, and, of course, there was much posturing over the Finding of Fact in the Microsoft vs. the US Government trial. The majority opinion seemed to be in favor of Microsoft, with some even predicting the apocalypse if the government ultimately won. A significant minority supported the government position; though there was a small vocal minority, including yours truly, that felt the whole thing was much ado about nothing. And speaking of the new millennium, I wonder if all the restaurants, hotels, cruise lines, etc. charging exorbitant rates for their end of-the-millennium bashes will “discover” next year that the New Millennium really starts on 1/1/2001 — and try to rake it in all over again.

I would like to hear from readers of net.digest. 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. Are you seeing a pattern here? You can reach me at john.burke@paccoast.com or john_burke@pacbell.net.

AutoRAID. Automatically?

There is a lot of interest in HP’s 12H AutoRAID. But most of us are in the same position as this questioner:

Does anyone have experience using HP’s 12H AutoRAID disk array using RAID level 5? I understand that there is a performance penalty to pay for fault tolerance or high-availability but I was wondering how much. Also, what high-availability disk drives can be used for LDEV 1?

One person, Bill Lancaster, who has experience with AutoRAID in particular and high-availability in general, shared his experiences.

Bill said, “I have been working with the AutoRAID devices on MPE for a number of months now with one particular customer. As with any technology, there is a good side and a bad side. The good side of the 12H is that it will ultimately be the most highly available high-availability choice for the money on MPE. This is taking into account price, performance, RAID technology, etc. The bad side is (as with any high-availability choice) there is a potential performance penalty. Also, though this element will go away with time, “official” support is for 6.0 and not 5.5. The reason for this is that the current AutoRAID Manager (ARM) software runs natively on 6.0. If you run on 5.5 you need to have a separate NT server, with a SCSI connection, to manage those boxes. This is not an ideal situation.

There isn’t a lot of good performance information about AutoRAID on MPE, and probably won’t be for some time. The main reason for this is that the 12H is highly configurable so, unlike Mirrored Disk/iX for example, the 12H performance characteristics will vary widely from site-to-site. It’s likely to be some time before there are a large number of these devices in the community.

That all being said, I’m very happy with how the 12H’s are working at my client’s site. We are running, I think, seven fully populated boxes there, in a variety of environments. We are preparing to move these into the primary production environment in the next several weeks.

As to what drives to use in the 12H, I believe the standard 9.1 Gb drives are 7200-rpm drives. There is an option for 10,000 rpm 9 Gb drives. I highly recommend the 10k drives. You can also get the 18Gb 10,000 drives. Choosing which depends on your environment. If you are running a highly spindle-sensitive application, more spindles (even if the mechs are somewhat slower) is desirable. If you require large amounts of data, with a minimal OLTP performance requirement, larger, denser drives may be the best way to go.

As to what high-availability disk drives can be used for LDEV 1? You can easily obtain used Disk Arrays (Model 10 or Model 20) that work just fine, in RAID 1 only, as the system volume set. However, you can use AutoRAID for the system volume set as well.

Regarding RAID 5, let me say that I strongly oppose having RAID 5 as a production volume set technology in mission critical environments. Not every one agrees with this statement but I’ve see enough serious performance problems to strongly advise people away from RAID 5 in production.”

What do you think of the AutoRAID choices? Is going to RAID storage for the 3000 a bad idea, or inevitable? Drop me a note at john_burke@pacbell.net.

Please Mr. Patchman, find me a patch

Patch management is one of the most difficult tasks for any system manager, regardless of OS. I suspect, though I have no direct evidence to support it, that most MPE system managers, particularly those who grew up with MPE, do not apply reactive patches unless they are doing it to fix a problem they’ve already experienced. In fact, my guess is that most do not even keep up with PowerPatches. And when they do, it is mostly to get new features rather than for the patch fixes.

Proactive patching is just not part of the MPE mindset; probably due to the HP 3000’s legendary reliability. Most patches occur to fix problems in new functionality or to fix corner case problems that do not affect the majority of systems. Also, the patch process for most people still implies the always-slow, sometimes-unreliable tape update and thus is to be avoided. In other words, “if it ain’t broke, don’t fix it” is the mantra for many MPE system managers.

For example, I know of one site that has been running a 918 on the base release of MPE/iX 5.5 for over three years with virtually no downtime. If you cut your teeth on Unix, proactive patching seems much more common. And my NT administrators seem determined to patch our servers as soon as they learn an NT service pack is released by Microsoft, whether we need it or not.

For those interested in proactively patching their systems, Mark Bixby (the HP employee of Apache/iX, Syslog/iX, Bind/iX, Sendmail/iX, etc. fame) created the shell script Patchman, currently in release 2.1. Patchman can be downloaded from ftp.bixby.org/pub/mpe/patchman-2.1 or www.bixby.org/ftp/pub/mpe/patchman-2.1.

Transfer it to your HP3000, enter the shell and execute the script with the –h switch to get a display of all possible options.

What does Patchman do? Patchman is a patch management tool that analyzes the patches previously installed on your system (HPSWINFO.PUB.SYS) against information downloaded from HP (us ffs.external.hp.com – ideally directly from your HP 3000, though you can manually download the files to a PC, transfer them to your HP 3000 and still analyze them with Patchman), looking for:

• patches that have been marked bad

• patches that have been superseded by downloadable patches

• patches that have been superseded by non-downloadable patches

• patches that are unrecognized (generally alpha or beta patches)

Patchman then suggests which new patches you might want to download and install:

• new patches superseding any of your previously installed patches

• new patches for FOS or HPSWINFO-patched subsystems

• new patches for other subsystems

Patchman can optionally download and unpack any recommended patches (assuming your HP 3000 can FTP directly from HP’s FTP site). As of version 2.0, Patchman supports the new store-to-disk format for patches.

I ran Patchman on one of my MPE/iX 5.5 systems shortly after applying to PP7. I was thoroughly depressed at the number of patches qualified by Patchman. Then I realized that many of them were patches that failed to qualify when I applied PP7 because, for example, we did not have the product. Even still, there were a surprising number of patches that Patchman qualified. What is one to do?

Patchman comes with a very important warning: “This tool is not a substitute for exercising your own good judgement or talking to the Response Center!” Also, “No attempt is made to analyze dependency information. That’s a job for Patch/iX anyway. (You are using Patch/iX, aren’t you?).”

Patchman is freeware and officially unsupported. Patchman can greatly simplify the process of proactive patch management as a tool and aid, but it does not replace your own good common sense, knowledge and experience.

One caveat: I ran Patchman on three systems, one on MPE/iX 6.0 Express 1 and two on MPE/iX 5.5 PowerPatch 7. On one of the 5.5 machines, the script would hang, creating a hung session that could only be cleared by hard halting the machine. Not a nice thing. Patchman initiates several forks, and for some reason on only one machine of the three, a deadly embrace occurs. Repeatably. A memory dump was taken and sent to HP. At least one other user has experienced the same problem. It is rare, but a very bad thing nevertheless. Therefore, much like with HP’s SYSINFO, try Patchman only in a situation where you can afford downtime in case you get a hung session. If and when a solution is found, I will use the 3000-L Internet list and the 3000 NewsWire to announce it.

Stage/iX promises to eliminate the tape update step and greatly reduce the time required applying patches. Unfortunately many patches are not stageable. For example, 5.5 PowerPatch 7 and 6.0 Express 1 were not stageable on any of my systems, because they contained patches that were not stageable. But help may be on the way.

According to Michael Dovano (MPE/iX OS Patch and Installation group of CSY): “Actually, we’re currently looking into removing the barriers that limit the staging of all MPE/iX patches. If we are able to accomplish this, you will easily be able to stage a PowerPatch release. Right now, a patch is rejected by Stage/iX (in the patch qualification code of Patch/iX) if it contains 1) an installation job (‘IHF’ file) that does post patch application processing or 2) the file MMSAVE.MPEXL.SYS (the disk IPL). A PowerPatch bundle invariably contains several of these types of patches, and hence is not ‘stageable’ without doing a lot of vetoing of individual patches (not something I recommend doing).”

What about you? Do you patch proactively, or only when something breaks? How do you justify your strategy to management? Let me know at john.burke@paccoast.com.