On Fri, 3 Nov 2023 17:02:54 -0500, Jon Perryman wrote: > >I think you misunderstand APARs because you question doesn't make sense. > >1. APARs are PTFs that are very rarely created and never required to be >applied. >2. Most product developers will never write an APAR write an actual APAR >because the problem must be so serious that a customer can't wait for the PTF >solving the problem described in the APAR. > <PEDANTRY> Mind the distinction between "APAR" and "APAR Fix". APARs are routinely created; APAR Fixes are not. </PEDANTRY>
>4. The resolving PTF will always SUP the APAR. An SMP/e search for the APAR is >sufficient but you must verify the APAR has been SUP'd. An applied APAR is >considered a very temporary fix that may not completely resolve the problem. > Almost so. By IBM's convention, the APAR Fix SUPs the matching APAR. ++HOLD identifies the APAR as the REASON(). It is also allowed for the APAR Fix to have the same ID as the APAR. IBM doc has repeatedly misstated that and been fixed by my RCF. The ultimate PTF SUPs both. >6. The APAR number choice has no real significance except how a product has >chosen to avoid SMP/e collisions. For instance, you say AHxxxx went to >PHxxxxx, In the past, this told me that IBM probably acquired a vendor >product. Anything beginning with I to Z was reserved for IBM use (e.g. >IEFJRASP, OA12345, UA12345). I suspect that most vendors use the IBM registry >for 3 character codes from A to H. Each product must choose a method that best >fits the company requirements. > Grrr. IBM's registered component prefixes govern program objects, etc., but not SYSMODs. The best we could do was choose an unlikely prefix. The name space is too damned small! Listen, IBM! (I'd like "com.<isv>....".) -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
