Hi Ken:
I read with much interest your recent posting about the Patch/iX-Stage/iX
issue you ran into recently. Before I continue I want to make sure everyone
understands that Patch/iX is indeed designed to use an active (booted)
staging area as a starting point for applying additional patches - whether
these additional patches are applied via a staging area or a CSLT, the
result should be cumulative. This means that what you expected to happen and
what Patch/iX originally told you (about building off of your "IMAGE-DBPUT"
staging area) is consistent.
That leaves us with the issue of how two or more components of your original
TIXKXX8A patch got regressed after updating to a new set of patches. To my
knowledge we have never run into this issue before. I'm going to try to see
if I can quickly reproduce the problem on my side, and also see what I can
do to follow up on this with the support people you placed a call to. I'll
plan on posting another response here when we get a better answer.
Thanks,
Michael Dovano
MPE/iX OS Patch and Installation
Commercial Systems Division, Hewlett-Packard
19447 Pruneridge Avenue
Cupertino, CA 95014
E-mail: [log in to unmask]
> -----Original Message-----
> From: Sletten Kenneth W KPWA [mailto:[log in to unmask]]
> Sent: Sunday, February 13, 2000 9:19 PM
> To: [log in to unmask]
> Subject: PATCHIX, Lies, and Update Tape
>
>
> Shorter title could be: PATCHIX LIED !!!!
>
> ... BUT: If you do not use or expect to use PATCHIX to
> update your system in the near future, you can stop reading
> here (but try PATCHIX: you may like it (for most things) ).
>
> ... AND: If you use PATCHIX, but never expect to try to install
> additional patches with PATCHIX while you are still booted on a
> STAGING AREA instead of BASE, again you can *probably*
> stop reading.
>
> HOWEVER: If you might get into a situation where you are
> still running on a staging area (have not done COMMIT yet) and
> then want to apply additional patches, this may be of more than
> passing interest. This could be a potentially serious problem;
> but investigation by the HP RC has just started (key details were
> only discovered a couple days ago). Whether this potentially
> applies to *any* PATCHIX patch install actions while you are
> booted on a staging area or just to cutting a new SLT for a TAPE
> ONLY update while you are booted on a stage is still TBD.
>
> ANYWAY, for those who might care here's the story:
>
> Ken Sletten
> ============================================
>
>
> Our site appears to have lucked out, but it's not hard to imagine
> other circumstances where this one could be ugly. Synopsis:
>
> (1) On 23 Dec 99 I did a PATCHIX - STAGEMAN install of
> TurboIMAGE Patch TIXKXX8 A (IMAGE Version C.07.25).
> Created staging group IMAGE-DBPUT (we always runs on a
> new staging group for a week or two whenever possible before
> COMMIT to BASE; "just in case"). All went well.
>
> (2) Subsequently, on 18 Jan 00 I installed PRED and DIAG
> patches ODIKXK3 A and OSPKXP0 A (yes, I know: 18 days
> late... but let's not get into that now). These two patches are
> NOT stageable; cut SLT and UPDATE from tape required.
>
> (3) I run PATCHIX to create the SLT with above two patches.
> Early in the process a message pops up (don't recall exact
> wording; not going to take time to check now; this is close):
>
> "You are currently BOOTED on Staging group IMAGE-DBPUT.
> Installation of new patches will be cumulative with all staged
> changes."
>
> well, sez I: That's good: PATCHIX confirms what I hoped and
> expected: It is smart enough to use what is in the STAGING
> GROUP as the BASE for cutting the SLT with the new patches.
>
> (4) I cut the SLT.... Usual BOOT from ALTERNATE. UPDATE.
> Uneventful. Everything appears to be fine after system comes up.
> But being an untrusting and skeptical soul on stuff like this, I do
> a QUERY VERS to confirm my IMAGE version is still C.07.25:
> Yup. Looks like all is still well.... we go about our business for a
> couple weeks; all appears to be routine...
>
> (5) In preparing to lead SIGIMAGE meeting at SIG3000 I am
> reminded: I think "DBUTIL: No more stealth flags and options"
> should have been done a couple IMAGE vers ago.... well, since
> I've got C.07.25 now, methinks I'll just verify that on our own 959:
> RUN DBUTIL.
>
> (6) oops: HELP SET, HELP SHOW, and HELP DROPI show
> nothing about LOCKSIZELEVEL and the [FORCED] option on
> DROPI. but... but...: I can remember seeing these options
> somewhere... thought I had 'em after TIXKXX8... but maybe
> that was when I was on a remote sys ?? (first serious feelings of
> "something's wrong here" start to build up right about then)....
>
> (7) I put in a call to HP RC. They check one of their C.07.25
> systems.... "gee", they say: "LOCKSIZELEVEL and FORCED
> come up fine for us".... and DBUTIL on their system comes up
> with same vers C.07.10 as on my 959.... huh ?!?!?.... Now I'm
> *REALLY* starting to wonder what in the world is going on....
>
> (8) < Interlude: Back and forth with HP RC. They recommend
> re-install TIXKXX8. I am totally confused... >
>
> (9) Just before seriously thinking of doing TIXKXX8 again, I
> have my 15 minutes of fame by remembering one good thing:
> Even though I updated from tape, I did NOT purge my IMAGE-
> DBPUT staging area yet. All I need to do is dig DBUTIL out
> from down in the HFS staging area directory; run *that* vers;
> and see if LOCKSIZELEVEL and FORCED appear. With a
> helpful reminder from my RC SE that my staged files can be
> found in: /SYS/hpstage/IMAGE-DBPUT@/,2 (darned
> upper and lower case again), I get my hands on the DBUTIL I
> was running before last PATCHIX SLT evolution.
>
> SIDEBAR CAUTION: If you do something like the above, do
> NOT forget (like I initially did) that files under an HFS directory
> are going to have ACD's: You need to REMOVE ACD's with
> MPEX or whatever before all users can access programs like
> DBUTIL.PUB.SYS, if you copy from HFS [log in to unmask]
>
> (10) Sure enough: LOCKSIZELEVEL and FORCED come up
> just fine in the DBUTIL that was staged.... arrggghhhh.....
>
>
> NOW..:
>
> PATCHIX said "all changes will be cumulative".... And the
> IMAGE intrinsics in XL.PUB.SYS certainly appear to be (most
> have version numbers greater than what we were running prior
> install of TIXKXX8).... BUT:
>
> PATCHIX LIED !!..: It did NOT get the staged version of DBUTIL
> out of /SYS/hpstage/IMAGE-DBPUT/ ... hmmm..: better check
> version and EOF on *all* of [log in to unmask] and compare to
> same in IMAGE-DBPUT staging area.... result: YIKES !!...:
>
> Staged DBUTIL: EOF = 1636, version = C.07.10
> DBUTIL.PUB.SYS: EOF = 1619, version = C.07.10
>
> Staged DBSCHEMA: EOF = 863, version = C.07.18
> DBSCHEMA.PUB.SYS: EOF = 830, version = C.07.13
>
> EOF on all other [log in to unmask] and staging area DB@ are
> the same.....
>
> .... of course the above leads immediately to the wider question:
> If PATCHIX didn't get latest staged DBUTIL and DBSCHEMA like
> it told me it was going to, what else didn't it get ??.. or might it
> not get, if a site stages a lot of complex patches and then
> subsequently does another major cut SLT - UPDATE from tape
> before COMMIT to BASE ??...
>
> .... like I said: PATCHIX, LIES, .... and update tape...
>
> .... oh, yeah: I can clear up one small part of above mystery:
> Why is DBUTIL version the same for two different EOF's ??...
> well, that at least is easy: HP inadvertently forgot to change
> the version number when putting in the "no more stealth flags"
> mod.... but please don't anyone beat up on our friends at the
> Database Lab for this small oversight: We have too many other
> good things we want them to do..... :-)
>
> If anyone cares, my HP RC call ID on this is: 3100139239
> (no SR yet).
>
> Anybody else ever do an additional PATCHIX run while booted
> on a staging group ??... if you have, you might want to pay
> attention to whatever patch of PATCHIX comes out to fix this....
> =============================================
>
|
