On Fri, 29 Jul 2016 18:16:50 -0500, Paul Gilmartin wrote: >On Fri, 29 Jul 2016 16:22:08 -0500, Tom Marchant wrote: >> >>> SMP/E for z/OS Commands >>> The ACCEPT command >>> o The SYSMOD named as the reason ID for the exception ... >>> >That might merit a RCF. By IBM's convention, the reason ID names not >an APAR fix (which is a SYSMOD) but the generating APAR (which is not >a SYSMOD).
IIRC, IBM's convention is for the APAR number, such as you might look up using the SIS function of IBMLINK starts with an "O" (for MVS APARs) and the reason-ID used in a ++HOLD starts with an "A". Program products use different letters. >>I believe that there is some confusion because APAR has more than one meaning. >> ... >Clearly. > >>I still don't understand what you meant by the question you asked above, >>>>>Is this true even if RRRRRRR is an APAR ID rather than a SYSMOD ID? >> >>If it is still an open question for you, can you clarify it? >> >I hope I'm less confused than I appear to be. REASON(RRRRRRR) may >name an APAR rather than an APAR fix. An APAR fix with a different name >might SUP(RRRRRRR) (not itself). Would this be unusual? In any case >I'd expect the final PTF to SUP both RRRRRRR and any ephemeral APAR >fix IDs. Ok, let me try again. The documentation for ++HOLD and ++RELEASE make no mention of SYSMOD ID. However, in order for a PTF to resolve the Error Hold, it has to SUP the REASON ID. IIRC, the SUP operand of ++VER makes no mention of REASON ID, but only says that SUP lists the SYSMOD that is superseded. Perhaps some clarification in the manual about this would be appropriate. 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. The "A" APAR fix does not SUP the REASON ID because that would mean that the APAR fix superseded itself, and that is not allowed or meaningful. Instead, the "A" APAR fix automatically resolves the Error Hold, per the passage that you quoted earlier. So, if I can offer an alternate version of your question, it would be, "Is this true even if there is no APAR fix that matches the REASON ID in the Error Hold?" The answer to that is "Yes". If that is not what you meant, feel free to ask again. In fact, for the Error Hold that I showed in my original reply to this thread, there is no APAR fix by the same name as the hold REASON ID in our environment. There may very well be one that we do not have. In fact, I would expect that IBM created an APAR fix for the customer who reported the original problem, but it would normally have been distributed to few if any other customers. However, as Kurt pointed out, it is more complicated than the static information that we can see after the fact. The PTF that has the Error Hold may have been applied without BYPASS(ERROR) and without the resolving PTF, if the Error Hold had not yet been received, or even issued, when the PTF was applied. If you really want to know what was done to apply the Error PTF, your best option is the SMPLOG for the target zone. -- Tom Marchant ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
