Richard Gambrell wrote:
>
> Mark Bixby wrote:
> > It's my opinion that MPE represents the best of both worlds --
> > refrigerator-like reliability coupled with the best of today's
> > technology.

> I'll leave it to Jeff to fill in the gory details, if anyone is
> interested and he is willing, but it is summed up well by this great
> quote from an HP staffer (name withheld to protect the innocent):
>
> "As you can see, HPUX is not an easy upgrade/install process (or at
> least not a [as] kind as MPE)."  (unsolicited, I might add)

I'll take a brief shot, since Richard doesn't begin to do justice to our
pain :-(

> After 1 [20-hour day] by four *experienced* staff (2 HP and 2 UTC
> [sysadmins] for 1 day), three staff another day (1 HP and 2 UTC) and
> the 2 UTC staff two more days [not just 8-hour ones either] (plus
> remote help from one of the HPers, and help from the RC and from the
> ITRC), just to update a typical, single application hpux K box from
> 10.20 with Oracle 7.3.4[.3] to hpux 11 and Oracle 7.3.4[.5], you're
> darn right about that "not an easy ... process" stuff!

No joke.  246 patches, 535 filesets, 800+ patch filesets.  And this was
a full reinstall of HPUX (updating 10.20 to 11.0 leaves too much
"ballast" in the sytem filesystems [I think that was their
terminology]), so no interaction issues with old 10.20 system code.  We
moved all of our data to "private volumes".

> AND, the RC had an SR filed back in Jan. 2000 that, if acted upon,
> would have saved up many hours and attack of worry yesterday and
> today (we were *very* lucky we didn't get an unbootable kernel).

Ah yes, patch PHKL_18543, a new patch type called a "Line In The Sand"
because it patches multiple filesets (it's a cumulative patch of several
things at once, while typical patches are more targeted).  I grew to
call it the "Head In The Sand" patch. If you use the new patch integrity
tool "check_patches" it tells you that all your checksums on the
affected files are bad, and you should reinstall it "forcibly".  If you
do that, it marks both it and all subsequent kernel patches as having
bad checksums.  "But it isn't an error" says HP.  To make a long story
short, check_patches doesn't understand "Line In The Sand" patches at
all.

> (I guess we were right not to include moving to Oracle 8 at the
> same time.:-))

No joke.  Since Richard's posting, he's found 3-4 additional Oracle
quirks in our update.

Most of my fun came from installing Automatic Port Aggregation network
software, where you take a dual-port 100TX card, connect it to a
suitable HP or Cisco switch, and bind the ports together to get an
effective 200Mb/sec link.  This was a bear to configure, and has to be
manually hard-coded on both ends of the link for aggregation or else the
link bounces every 60 secs.

The rest came from getting Legato Networker software to work with our
DLT autochanger (again).  It worked fine on 10.20 through a special
device file using the SCSI Pass-Through driver (SPT).  It was using
major number 142 (an index into the kernel driver table).  The 11.0
install created a new device file with major number 235.  This didn't
work, nor did 142.  To make another long story short, the major number
changed to 237.  Nothing like an invisibly moving ldev number.

And that's just the highlights :-)

Jeff Kell <[log in to unmask]>