On Sat, 30 Jul 2016 15:32:41 -0500, Paul Gilmartin wrote: >On Fri, 29 Jul 2016 23:28:27 -0500, Tom Marchant wrote: >> >>When an APAR fix is created for the APAR problem description, it starts with >>"A". If a >>second APAR fix is created, perhaps for another release, it starts with "B". >>A third >>APAR fix would start with "C", and so on. I don't have one to look at, but >>I'm pretty >>sure that the "B", "C", etc APAR fixes sup the "A" REASON ID. I suspect, but >>am not >>certain, that this is true for all APARs, not just those for which there is >>an Error Hold. >> >"C" must SUPersede "A" and "B"; and the final PTF must SUPersede "A", "B", >"C", ... >else a MODID check is almost inevitable. (Well, PRE would work, but you don't >want to PRE APAR fixes.)
Not necessarily. If the "A" APAR is for z/OS 2.1, the "B" APAR for z/OS 2.2 and the"C" APAR is for z/OS 1.13, "C" need only SUP "A". And "C" needs to SUP "A" only to allow the PTF for z/OS 1.13 that has the error hold with reason "A" to be applied with the "C" APAR fix. There would be no MODID issues because the different APAR fixes do not apply to the same FMID. It would not work for "C" to PRE "A" because they are for different FMIDs 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". That's a lot of "ifs" and I don't know if this is ever done, but I think I have seen it in the distant past. -- Tom Marchant ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
