IBM System/360 Operating System: Concepts and Facilities, GC28-6535-7, Section 2: Program Design, Service Aids, p. 25: "To aid in the diagnosis of problems, seven service aid programs are provided with the operating system: IMAPTFLE (used to create job control statements for applying a Product Temporary Fix -- PTF -- to a system library);"
-- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי ________________________________________ From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of Eric D Rossman <edros...@us.ibm.com> Sent: Sunday, November 5, 2023 9:54 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: IBM APAR Names I'm not going to claim that I know the whole history of IBM Service (specifically in z), but I will say that Anthony and Seymour are the closest to accurate. I can say that I have 20+ years of experience in ICSF Level 2 (the main debuggers near the start of my career) and Level 3 (the ones who write the fix) and was (for a time) the Level 3 lead. We no longer have PMRs (now Cases) but the concept is the same. A customer reports a problem. L2 looks it over, trying to see if this is (usually in this order): 1. usage question (how do I use ...?) 2. customer mistake (crypto [ICSF, System SSL, etc.] and security [SAF, RACF, etc.], in particular, are very complicated and easy to "oopsie") 3. known problem (customers failing to apply service in a timely happens more than we would like to see) 4. a new problem If it looks like a new problem, L2 works with L3 to decide and open an APAR (Authorized Problem Analysis Report) ["Authorised" if you are not in the US 😊] Honestly, until today, I had never heard the phrase "APAR Fix". We always call them ++APARs and they are how we (internally) test our fixes. Back when ICSF was a web deliverable, our naming was all over the place for ++APARs. Now, we have a system that we stick to. I cannot guarantee that all z/OS components use the same system, but there is never a chance of a collision in naming. At some point in the past, I know that each rebuild would assign the next letter, (AAnnnnn for the first ++APAR, regardless of release) which would lead to collisions in naming. Nowadays, at least in my experiences, any ++APARs that we build replace the O with another letter (usually in the range A-J, but occasionally Z [at least for ICSF]) and that letter will be used for ALL ++APARs at a given release. For example, all ICSF HCR77D1 ++APARs will be DAnnnnn. Then, if we rebuild a ++APAR, the name stays the same but it acquires a REWORK() date. For example, a recent fix I shipped for HCR77D1 had its last ++APAR as: ++APAR(DAnnnnn) REWORK(2023271). ++APARs are not commonly given out, as we do it only if we want feedback on the fix from reporting customers. This is most common when the problem is really hard to reproduce EXACTLY (such as storage leaks that depend on some interactions of different workloads where we can get close but not exactly the same results as reported). It can also happen when we want confirmation that there is no side effect from a fix (very uncommon but sometimes we want the extra comfort when providing very complicated fixes). I've never seen PTF stand for anything other than "Program Temporary Fix." Our tooling always makes a PTF SUP its corresponding ++APAR, even if we never shipped the ++APAR to customers, just in case. An APAR doesn't fix anything. It's just the "wrapper" for the fixes. For what it's worth, ++APARs are built using the same tooling as PTFs in order for our internal testing to be as close as possible to the PTFs that we ship. As for "current practice," what specifically are you referring to? The vast majority of z/OS-related APARs would be OAnnnnn. Most vendor products that I've seen just use a different first letter. I cannot speak to how they name ++APARs or PTFs. Eric Rossman -----Original Message----- From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of Seymour J Metz Sent: Saturday, November 4, 2023 7:47 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: IBM APAR Names Like "SPF", what "PTF" stands for depends on the year, but whether problem, product or program temporary fix, its role remains the same. Both an APAR and any resolving PTFs may exist for reasons other than defects, e.g., documentation, Small Program Enhancement (SPE). Is there an edition of the packaging guide that reflects IBMs current practice? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי ________________________________________ From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of Anthony Fletcher <fletc...@xtra.co.nz> Sent: Saturday, November 4, 2023 7:38 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: IBM APAR Names This chain has an interesting range of opinions that I am not going to comment on specifically, other than to point out that APAR started out being the acronym for Authorised Problem Analysis Report which would be outcome of a verified problem, NOT yet a fix. Likewise PTF stands for Problem Temporary Fix. The final fix goes into the next release. The use of ++APAR is really a mechanism to relate an early bypass before the formal fix comes out as a ++PTF. But the bottom line is that any vendor that is using SMP/E has to follow the rules of SMP/E but their naming conventions are theirs as long as they don't conflict with other vendors rules and generate chaos in the SMP/E database,. Vendors don't have to use SMP/E but in my experience the knowledgebase covering problems and solutions is better using SMP/E than any other method. Anthony -----Original Message----- From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of Mark Zelden Sent: Sunday, November 5, 2023 9:36 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: IBM APAR Names On Sat, 4 Nov 2023 07:19:49 -0500, Bruce Hewson <bruce_hew...@hotmail.com> wrote: >HI, > >APARs for me are OAxxxxx or PHxxxxx - these are the entries describing a >problem, and may be associates as Error Holds to existing PTFs. > >Before a PTF is issued, the vendor may issue a ++APAR for you to test. A >++APAR fix is not fully tested. > >++APAR names aill be AAxxxxx, BAxxxxx etc for each new iteration of a fix for >APAR OAxxxxx. > >So depending on how many attempts have been made to get the corrective >fix for the problem described in APAR OAxxxxx you can see one or more >iterations of the ++APARs. > >The eventual PTF will SUPERCEDE all ++APARs that had been built during testing >of the fix for the APAR problem. > >When searching, say via Google, use the APAR number only, e.g. OAxxxxx > >This is how I was introduced to ++APAR naming conventions. > Exactly... I was going through the thread to see if someone explained this correctly and found your post. The APAR number is different than what is seen in a ++APAR fix and then eventually in ++PTF. fix. Not many people seem to understand this - at least people I have worked with. I also work with people that don't relationship between the APAR number and the ++PTF that is show for "REL" when looking at IBMLINK or seeing what is in the public domain from an APAR search in google. Regards, Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS ITIL v3 Foundation Certified mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
