<snip> >>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.) <e-snip>
These days, the "letters" (at least for the MVS element) are typically for "++APARs". There is one letter per release. "K" happens to be the letter for z/OS 2.2. The supersede that you see in a PTF for the "A" has a largely historical basis. 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). <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. Peter Relson z/OS Core Technology Design390 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
