One of the threads is about APAR fix vel ++APAR.
Well, I used to teach SMP/E, IBM course ES26.
Here is exempt from Instructor Guide:
"APAR fixes are used to update an element. SMP/E invokes a superzap
utility to update the module in place. Relinking the load module is
usually not necessary. APAR fixes are referred to as corrective service."
And the APAR fix is named "emergency service". And the distinction
between APAR and APAR fix is clearly described.
The material is copyrighted, so I won't put more, but the chapter
explains the difference between PTF, APAR fix and usermod.
The name "APAR fix" is used many times and it is indeed the fix for the
problem described in APAR.
BTW: Actually I'm not sure whether APAR fix has to be tied/linked to
APAR or can be created without it. AFAIK this is only procedural, not
"hardcoded" in any SMP/E logic. However I believe, despite of above
every APAR fix is for some APAR.
BTW: Every element has a version. But it is more complex: there is a
FMID "basic" version ID. Then the element can be updated (replaced) and
get RMID, which is PTF number (last PTF which replaced the element).
Then the element can be modified using APAR fix and gets UMID, which is
APAR fix number. A usermod also modifies the element and element gets
another UMID.
As a result, an element can have one FMID, zero to one RMID and zero to
multiple UMIDs.
--
Radoslaw Skorupka
Lodz, Poland
W dniu 05.11.2023 o 15:54, Eric D Rossman pisze:
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
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
