Re: PE not Sup'd

2006-11-13 Thread Paul Gilmartin 
In a recent note, "Shmuel Metz (Seymour J.)" said:

> Date: Mon, 13 Nov 2006 11:50:56 -0500
> 
> There is, in general, no reason for the correcting PTF to supersede
> the PTF in error. What it needs to supersede in the sysmod given as
> the reason for the HOLD, normally the APAR for the PE.
> 
Either the resolving PTF may SUPersede the reason ID or its name may
be identical to the reason ID.

-- gil
-- 
StorageTek
INFORMATION made POWERFUL

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PE not Sup'd

2006-11-13 Thread Shmuel Metz (Seymour J.) 
In <[EMAIL PROTECTED]>, on 11/06/2006
   at 11:47 AM, "Joseph W. Beiter" <[EMAIL PROTECTED]> said:

>are there conditions where a pe'd ptf is not sup'd but instead marked
>per by the correting ptf ?

There is, in general, no reason for the correcting PTF to supersede
the PTF in error. What it needs to supersede in the sysmod given as
the reason for the HOLD, normally the APAR for the PE.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PE not Sup'd

2006-11-07 Thread Kurt Quackenbush 

Does SMP/E provide
any warning to the programmer who unwittingly attempts to RESTORE
a HOLDERR corrective SYSMOD while leaving the PE sysmod?


Sorry for leaving the thread hanging.  Perhaps I thought you originally 
answered your own question.  In any case, the answer is no, SMP/E 
RESTORE does not check HOLDERRs before removing a PTF.


Kurt Quackenbush -- IBM, SMP/E Development

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PE not Sup'd

2006-11-06 Thread Paul Gilmartin 
In a recent note, Shane said:

> Date: Tue, 7 Nov 2006 07:24:37 +1000
> 
> On Mon, 2006-11-06 at 11:31 -0700, Paul Gilmartin wrote:
> 
> > ... but received no definitive answer, possibly because Shane asked
> > Kurt not to reply.
> 
> Did I just ???. My post was specific to the wish for a
> "BYPASS(HOLDERROR)".
> One trusts Kurt is sufficiently able to winnow the chaff.
> 
I would have thought likewise.  But the thread ended with your posting,
leaving unanswered the kernel of the question:  Does SMP/E provide
any warning to the programmer who unwittingly attempts to RESTORE
a HOLDERR corrective SYSMOD while leaving the PE sysmod?

What I suggested wasn't a new loophole, but a stricter rule, leaving
a (desirable?) possibility of circumvention.

-- gil
-- 
StorageTek
INFORMATION made POWERFUL

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PE not Sup'd

2006-11-06 Thread Shane 
On Mon, 2006-11-06 at 11:31 -0700, Paul Gilmartin wrote:

> ... but received no definitive answer, possibly because Shane asked
> Kurt not to reply.

Did I just ???. My post was specific to the wish for a
"BYPASS(HOLDERROR)".
One trusts Kurt is sufficiently able to winnow the chaff.

Shane ...

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PE not Sup'd

2006-11-06 Thread Tom Marchant 
On Mon, 6 Nov 2006 13:06:56 -0700, Paul Gilmartin <[EMAIL PROTECTED]> 
wrote:
>
>It would be possible always to SUPersede, but in the case where
>an error in a large SYSMOD can be corrected by a smaller SYSMOD,
>I consider the minimalist approach prudent.

Indeed, sometimes PE chains get very long and the number of
elements involved grows rapidly as they are followed.  If it
were a requirement that a fixing PTF always SUP the fixed PTF,
the PTFs would often become huge.

-- 
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PE not Sup'd

2006-11-06 Thread Tom Marchant 
On Mon, 6 Nov 2006 13:56:17 -0600, Joseph W. Beiter 
<[EMAIL PROTECTED]> wrote:

>"...But the vendor fails to declare the dependency..."
>
>Point right on. This is the vendors responsibility no? Else who/how to
>protect the integrity of the maintenance chain? The customer?

Yes, it is the vendor's responsibility to provide proper SMP,
including all appropriate requisites.

>
>My original post was to try to understand other conditions where this
>would be necessary as a standard way of doing business. It sounds like the
>answer is no. Exceptions not withstanding, we should always expect that a
>pe'd ptf will be removed from the chain or sup'd by the correcting
>maintenance. thanks.

Removed from the chain?  What does that mean?

You should always expect that that PTF that fixes a PE will PRE or
SUP the PTF that it corrects.  Actually, whenever two PTFs provide
the same element, one of them must PRE or SUP the other.  SUP is
only used when the superceding PTF contains everything that the
superceded PTF contains.

-- 
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PE not Sup'd

2006-11-06 Thread Paul Gilmartin 
In a recent note, Joseph W. Beiter said:

> Date: Mon, 6 Nov 2006 13:56:17 -0600
> 
> "...But the vendor fails to declare the dependency..."
> 
> Point right on. This is the vendors responsibility no? Else who/how to
> protect the integrity of the maintenance chain? The customer?
> 
If you're saying that vendors should never make mistakes, well, yes,
but they (we) (even IBM) do.  If vendors never made mistakes, there
would be no use for ++ HOLD ERROR.

> My original post was to try to understand other conditions where this
> would be necessary as a standard way of doing business. It sounds like the
> answer is no. Exceptions not withstanding, we should always expect that a
> pe'd ptf will be removed from the chain or sup'd by the correcting
> maintenance. thanks.
> 
"Exceptions not withstanding".  Well, of course.  Except for the
exceptions everything is unexceptional.  I agree with Tom Marchant
in observing that it may be quite routine, not even exceptional
for a corrective SYSMOD not to SUPersede another SYSMOD in which
it resolves an error.

It would be possible always to SUPersede, but in the case where
an error in a large SYSMOD can be corrected by a smaller SYSMOD,
I consider the minimalist approach prudent.

-- gil
-- 
StorageTek
INFORMATION made POWERFUL

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PE not Sup'd

2006-11-06 Thread Joseph W. Beiter 
"...But the vendor fails to declare the dependency..."

Point right on. This is the vendors responsibility no? Else who/how to 
protect the integrity of the maintenance chain? The customer? 

My original post was to try to understand other conditions where this 
would be necessary as a standard way of doing business. It sounds like the 
answer is no. Exceptions not withstanding, we should always expect that a 
pe'd ptf will be removed from the chain or sup'd by the correcting 
maintenance. thanks.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PE not Sup'd

2006-11-06 Thread Birger Heede 
As the customer would still have PTF X installed I assume the outcome 
depends on how the exploitation in PTF X is implemented - a hard 
dependency would probably cause another problem to show up?


Birger Heede
IBM


Paul Gilmartin wrote:

In a recent note, Tom Marchant said:


Date: Mon, 6 Nov 2006 12:07:15 -0600

Suppose PTF X includes modules A and B.  It becomes PE.  The code
in B is ok, but the code in A needs to be replaced.  The vendor
then has two choices.  Either SUP X with a PTF Y containing A and
B or provide a PTF containing just A with a PRE to pick up B.


Suppose a more extreme case.  The vendor has previously issued
PTF W, which added new function in module C.  Subsequently, the
vendor issues PTF X, containing updated modules A and B, which
newly exploit the function introduced by PTF W.  But the vendor
fails to declare the dependency on W, and a customer who APPLYs
X but not W reports a problem.  The vendor can repair this
simply by issuing "++ HOLD (X) ERROR REASON(W) ...

There is no commonality of elements.  Can a customer then cause
a malign regression by RESTOREing W but not X?  TFM appears not
to prohibit this, despite the ++HOLD.  I asked about this in:

   http://bama.ua.edu/cgi-bin/wa?A2=ind0610&L=ibm-main&P=150582

but received no definitive answer, possibly because Shane asked
Kurt not to reply.

-- gil


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PE not Sup'd

2006-11-06 Thread Paul Gilmartin 
In a recent note, Tom Marchant said:

> Date: Mon, 6 Nov 2006 12:07:15 -0600
> 
> Suppose PTF X includes modules A and B.  It becomes PE.  The code
> in B is ok, but the code in A needs to be replaced.  The vendor
> then has two choices.  Either SUP X with a PTF Y containing A and
> B or provide a PTF containing just A with a PRE to pick up B.
> 
Suppose a more extreme case.  The vendor has previously issued
PTF W, which added new function in module C.  Subsequently, the
vendor issues PTF X, containing updated modules A and B, which
newly exploit the function introduced by PTF W.  But the vendor
fails to declare the dependency on W, and a customer who APPLYs
X but not W reports a problem.  The vendor can repair this
simply by issuing "++ HOLD (X) ERROR REASON(W) ...

There is no commonality of elements.  Can a customer then cause
a malign regression by RESTOREing W but not X?  TFM appears not
to prohibit this, despite the ++HOLD.  I asked about this in:

   http://bama.ua.edu/cgi-bin/wa?A2=ind0610&L=ibm-main&P=150582

but received no definitive answer, possibly because Shane asked
Kurt not to reply.

-- gil
-- 
StorageTek
INFORMATION made POWERFUL

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PE not Sup'd

2006-11-06 Thread Tom Marchant 
On Mon, 6 Nov 2006 11:47:58 -0600, Joseph W. Beiter 
<[EMAIL PROTECTED]> wrote:

>are there conditions where a pe'd ptf is not sup'd but instead marked per
>by the correting ptf ?  a 3rd party software vendor is attempting to make
>this business as usual and I'd rather they stuck to convention. What's to
>prevent regression of the fixing sysmod without regressing the pe'd ptf?
>thanks.
>

Do you mean PRE?

Suppose PTF X includes modules A and B.  It becomes PE.  The code
in B is ok, but the code in A needs to be replaced.  The vendor
then has two choices.  Either SUP X with a PTF Y containing A and
B or provide a PTF containing just A with a PRE to pick up B.

Do you mean regressing or restoring?

If you're talking about regression, I have to ask what causes
the regression.  If BYPASS(ID) or a poorly constructed PTF thar
re-introduces the error of PTF X, all bets are off.

In the case of RESTORE, if you have already ACCEPTed PTF X but
not Y, you can certainly restore PTF Y.  Indeed, there might be
a case to do exactly that, if PTF Y introduced another problem
that was worse in your shop than the error introduced by PTF X.

-- 
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

PE not Sup'd

2006-11-06 Thread Joseph W. Beiter 
are there conditions where a pe'd ptf is not sup'd but instead marked per 
by the correting ptf ?  a 3rd party software vendor is attempting to make 
this business as usual and I'd rather they stuck to convention. What's to 
prevent regression of the fixing sysmod without regressing the pe'd ptf? 
thanks. 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html