On Mon, 1 Aug 2016 17:20:23 -0400, Peter Relson wrote: >The supersede that you see in a PTF for the "A" has a >largely historical basis.
Perhaps, but it is also necessary in the case of a PTF that resolves an Error Hold. The ++HOLD specifies REASON(Axxxxxx) and if the PTF with the error is a PRE of the resolving PTF, the resolving PTF must SUP that reason in order to resolve the error. It could PRE that reason, but only if the APAR fix with a SYSMOD ID matching that reason is provided, and is applicable to the FMID that the PTF is for. >I don't think that the point about "must SUPersede" is true or follows. We >very frequently PRE APAR fixes (including PTFs that went PE). Are you confusing an APAR fix ( a ++APAR) with a PTF that fixes an APAR? I don't remember ever seeing a PTF with a PRE on an APAR fix, that is a ++APAR. That would mean that the APAR fix would have to be distributed to everyone, not just to the customers who need the APAR fix to resolve the problem before a PTF is available. ><snip> >If, OTOH, it is discovered that the "C" APAR fix did not resolve the issue >for z/OS 1.13, and if a PTF had not yet been created, and if a new APAR >fix "D" was created for z/OS 1.13, it would SUP "A" and "C". The PTF for >z/OS 1.13 would SUP "A", "C", and "D". ><e-snip> >Long ago it perhaps used to be that a "fix" had to supersede the prior >attempt. That is no longer true. The fix might supersede the previous but >it might just PRE-req the previous. Agreed. If an APAR fix needed a second APAR fix to correct the problem, the second can PRE or SUP the first. -- Tom Marchant ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
