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
