On Fri, 3 Nov 2023 23:12:08 -0500, Paul Gilmartin <paulgboul...@aol.com> wrote:
>"Standard"? Cite. Does IBM state that component codes prefix SYSMOD IDs. I never said it was an IBM standard. I said standard vendor practice. Maybe common vendor practice would have been clearer. Vendor PTF's I've seen have 3 characters followed by 4 digits which avoids collisions with IBM 2 characters followed by 5 digits. I assumed that the 3 characters being used were component codes to avoid vendor collisions but that was before my time. Maybe like you, they rolled the dice and risked collisions. >OK. A PTF SUPs an APAR it correcrs. It may suffice for an APAR Fix to match >the APAR ID. You keep saying APAR FIX but SMP/e specifically states ++APAR is a "service sysmod". While they also mention "temporary corrective fix", it's important to realize that fix in this context does not imply it fixes the APAR defect. In this case, it's a temporary fix that will be removed automatically. It temporarily corrects an intolerable situation. Sometimes the ++APAR is the same as the PTF but in my experience, more often it disables functionality until it can be properly fixed. It is required for the PTF to SUP the ++APAR ID otherwise it is not temporary and breaks the PTF prereq chain. >>>++HOLD identifies the APAR as the REASON(). >> >>You don't understand ++HOLD because APAR numbers are not specified in >>REASON(). The correct use is REASON(ERROR) ... >> ><https://www.ibm.com/docs/en/zos/3.1.0?topic=hm-example-2-marking-ptf-that-is-in-error> >Example 2: Marking a PTF that is in error >++HOLD (UZ12345) /* Hold this PTF */ > FMID(FXY1040) /* for this function */ > ERROR /* for APAR fix. */ > REASON(AZ00001) /* APAR is AZ00001. */ > COMMENT(this APAR causes loop) APAR id in the REASON() only has meaning for HOLD ERROR meaning a PTF is in error. This is a completely different APAR process that does not involve ++APAR. This hold will be satisfied when the PTF fixes the APAR using SUP. >IBM chose ++APAR as the MCS to introduce what IBM calls an APAR FIX. The manual you cited for the term "APAR FIX" states "Some APAR fixes or USERMODs might be regressed.". ++APAR is by definition is always regressed. It is "temporary" and no PTF will ever prereq / req it thus breaking the apply chain. A PTF SUP is required to restore the chain and remove it. In this context, "APAR FIXES" refers to PTFs because only ++PTF and ++USERMOD are not always regressed. >>In terms of SMP/e, what does "APAR' refer to that you can now specify and was >>implemented because of your RCF? >Nothing was "implemented" because of my RCF. The RCF simply corrected >description of unchanged behavior. You said "It is also allowed for the APAR Fix to have the same ID as the APAR." which states that APAR FIX and APAR are 2 separate SMP/e things. Your doc change implies both terms have meaning to SMP/e and are not one in the same. What is the SMP/e distinction between these terms? >>><PEDANTRY> Mind the distinction between "APAR" and "APAR Fix". >>>APARs are routinely created; APAR Fixes are not. >>></PEDANTRY> >> >>Actually, APAR is a logical process. You ignore other SMP/e APAR interactions >> such as ++HOLD, ++PTF and more that don't require ++ APAR. And you ignore >> important processes that are outside of SMP/e like the problem database. All >> these >> processes must be coordinated which is where APAR id comes in. >> >They're documented. I needn't quote the entire manual. If as you say, APAR FIX is ++APAR, what is APAR to SMP/e? I'm not understanding how APAR and APAR FIX coexist as separate entities in SMP/e. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
