> -----Original Message-----
> From: HP-3000 Systems Discussion [mailto:[log in to unmask]]On
> Behalf Of Michael D. Hensley



> [Note: I appreciate Scott's contribution to the discussion.  I
> hate it when everyone at HP remains silent.  However, I'm going to
> have to respectfully disagree:]
I agree that HP people tend to remain silent more than they
should. The problem, as I see it (just one man's opinion), is that
if I post to this list, and my signature/e-mail address says "HP", then
there is a risk that people will take my posting as HP's "official"
position. I know that I can say things to soften that effect, but the
reality is that engineers from HP have to give it some consideration before
they formulate a reply. I believe this reduces (slightly) direct
participation
by HP engineers that read this list all the time.

> > Scott McClellan posited:
> > * Therefore the MPEJXV9B problem is only a show stopper for a
> >   very specific subset of our users. I am very glad Mark pointed
> >   out the problem, and I agree that it is serious, particularly
> >   for Mark, but many/most customers would not be effected. This
> >   would include many/most customers that use Posix.
>
> ...but I have to disagree here.  Any user who executes any scripts that
> contain "rm -R" will also run into this problem.  Unless you're willing to
> read every line of every script you use (and don't forget any that are
> executed by batch jobs), you could run into this quite easily.
>
> For example, I have no idea which, if any, of the installation
> scripts on the
> FREEWARE tape do an "rm -R".

I don't disagree with your point - it's a good point!

There is no easy way to tell if any job/script is using "rm -R".
Even if you searched (eg: grep'ed) every file on your system for
"rm -R" this would not insure that you would find all occurances
(scripts are sometimes created dynamically for example, the rm
might be built dynaically based on runtime variables, the -R parm
does not have to be first making pattern matching more difficult,
etc).

My point was/is, that I believe (as opposed to "I assure you") that
usage of the shell "rm -R" command is "relatively" rare. It is certainly
not unheard of, so if you did not take any other action to reduce risk,
you would still have 'some risk'.

I can think of some other ideas to reduce risk. For example you could
write a shell script that replaces "rm" that checks for -R parm and
terminates if it is passed. This script would be used "temporarily"
until the issue is resolved. The script could even invoke the MPE purge
command with the ;TREE option so that it did not have to terminate.

I would be willing to bet that a Posix whiz, like Mark Bixby (:-) could
whip up a "rm" script and instrcutions on where to put it that would
eliminate/minimize risk altogether. We could post this on Jazz, on 3000-L,
and give it to the RC so that they could suggest it when customers
call in with questions. Just a thought!

> > * Even if you are a Posix user, you can avoid installing MPEJXV9B
> >   easily by simply "veto"ing it in Patch/iX. If there is a problem
> >   with "veto"ing MPEJXV9B it has not been reported. If someone
> >   knows of a problem, please speak up.
>
> Good advice, but what about those who install the PowerPatch
> before they find out about this problem?
This is always a problem, and one that we in the lab assume that the RC
engineers will apply creativity to figure out. Basically, whenever a
customer
calls the RC with problem "xxx", if "xxx" is a known problem we hope that
the
RC will have some kind of a decent answer. In some cases, it is very
difficult
to come up with an real good answer. The job of an RC engineer is often
quite difficult.

> If there is a way to back out a single patch from a PowerPatch
installation,
> could you post it?
The short answer is that is not a "real easy" way to backout a single patch.

In theory, you could create a staging are with all the patches except the
one you don't want and boot from the staging area. Similarly you could
create
a CSLT tape (minus the patch you don't want). Patch/iX has the veto
facility.

The problem is that, Patch/iX only knows how to patch the "current operating
environment". This means that you have to put the system back into a state
where
the patches are not installed before running Patch/iX. If you uses a CSLT
tape
then this requires a "backdate", which is "painful".

With Stage/iX you could reboot from the "previous" staging area (not as
"painful") and create a new staging area that contains all the patches minus
the one you don't want. The lab is aware of the problem that since some
patches are not stagable, most PP tapes are not stagable. We are working on
a reasonable solution (no committed timeframe at this point -- but it is
under investigation).

> If not, HP should create a patch to reverse the effect of MPEJXV9B
immediately,
> while they work on  solving the underlying problem.
Your general concept is interesting. I is difficult for me to explain
(without
writing 20 paragraphs) why this solution is actually very difficult (in
general)
to implement. In brief, some patches are much easier to 'undo' than others.
In general, patches and patching is more complicated and more of a "tangled
web
of dependencies" than most people would realize.

> > I guess my general take on this issue is that it is not a very
> > good reason for most customers to avoid PP5. I am still glad that
> > Mark Bixby took the time to mention the problem and clarify it.
> > Thanks Mark.
>
> If you plan to use POSIX -- JAVA, SAMBA, APACHE, or anything else -- don't
> install the MPEJXV9B patch.  If you already have, bug the
> response center for a way to de-install it.  And don't buy the "back out
> the entire PowerPatch tape and re-install it without that patch" answer
> unless you have  a *lot* of free time and are *really* bored.

I personally think that the "workaround" I mentioned above (replacing the
rm script with a script that deals with the -R parm using a purge ;tree) is
*MUCH* easier and just as effective for this specific problem.

I don't disagree with your comments that a "back out the entire PP tape
and re-install it" is a pain. It will work. It does require too much
downtime. It is easier if you can use Stage/iX instead of CSLT tapes (much
easier actually). And it is a know problem.

> > NOTE: there have been some other issues mentioned here
> > that warrant consideration (w.r.t Oracle and one problem with
> > HPDATEDIFF). I personally feel like these other issues whould
> > weigh more heavily (on average) in deciding whether or not to
> > install PP5.
>
> I bet more people will be affected by the POSIX problem than the
> Oracle and HPDATEDIFF ones combined -- but I won't bet much.
> There don't seem to be that many Oracle users, and HPDATEDIFF is
> too new to be in  widespread use yet.
You may be right. My main point in mentioning the other problems was
that I did not want to go on record as saying "...if you don't have
a Posix problem, you won't have any problem...". The fact is that I
don't have enough data to make that claim.

If the Oracle and HPDATEDIFF problems are "low risk" for most
customers, AND someone would write the RM script I suggested,
then I am not aware of issues that would suggest caution. Of
course there are *always* issues that I am not aware of!