Re: IBM APAR Names

[Ed Jaffe]

On 11/7/2023 3:52 AM, Radoslaw Skorupka wrote:

W dniu 06.11.2023 o 16:20, Ed Jaffe pisze:

On 11/5/2023 4:03 PM, Shaffer, Terri wrote:
So I am trying to apply maintenance and want to know the actual APAR 
to look up to see if its open closed, or what?


Slide 72 in SHARE New Orleans Bit Bucket X'42' explains the APAR and 
++APAR naming convention used most often with z/OS products and 
components.


The possible APAR prefixes are: OA, PH, PI, PK, PL, PM, PN, IO, PP, 
PQ, IR, OW, OY and OZ. The second letter of the ++APAR is the mapping.




What does it mean "mapping" ?


It means the second letter of the ++APAR tells you which of the above 
prefixes the APAR uses. For example:


1. If your ++APAR is AH23456, then the APAR number is PH23456.

2. If your ++APAR is AR34567, then the APAR number is IR34567.

--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://www.phoenixsoftware.com/



This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IBM APAR Names (APAR fix)

[Radoslaw Skorupka]

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, (AAn 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 DAn. 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(DAn) 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 OAn. 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

Re: IBM APAR Names

[Phil Smith III]

Shmuel wrote:
>Whoops! Somehow I missed the last sentence of the paragraph.

Ah hah! Hence the confusion. Glad we straightened that out.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IBM APAR Names

[Seymour J Metz]

Whoops! Somehow I missed the last sentence of the paragraph.


-- 
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי




From: IBM Mainframe Discussion List  on behalf of 
Phil Smith III 
Sent: Wednesday, November 8, 2023 1:18 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IBM APAR Names

Shmuel wrote:
>SES is a tools that fills the same nicje in the VM ecology as SMP does
>in the MVS ecology.

Right, I said that. Hence my confusion about what point you were making.




--
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

Re: IBM APAR Names

[Phil Smith III]

Shmuel wrote:
>SES is a tools that fills the same nicje in the VM ecology as SMP does
>in the MVS ecology.

Right, I said that. Hence my confusion about what point you were making.




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IBM APAR Names

[Seymour J Metz]

Even before SES, the service methodology using, e.g., AUX files, made life 
easier.


-- 
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי




From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <042bfe9c879d-dmarc-requ...@listserv.ua.edu>
Sent: Tuesday, November 7, 2023 9:05 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IBM APAR Names

On Tue, 7 Nov 2023 23:57:05 +, Seymour J Metz  wrote:

>SES is a tools that fills the same nicje in the VM ecology as SMP does in the 
>MVS ecology.
>
And it has the design advantage of not having an operation analogous to ACCEPT,
thereby supporting progressive restoring of an arbitrary number of PTFs provided
that the predecessors have not been purged from the DELTA disk (analogue of 
SMPPTS).

--
gil

--
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

Re: IBM APAR Names

[Paul Gilmartin]

On Tue, 7 Nov 2023 23:57:05 +, Seymour J Metz  wrote:

>SES is a tools that fills the same nicje in the VM ecology as SMP does in the 
>MVS ecology. 
>
And it has the design advantage of not having an operation analogous to ACCEPT,
thereby supporting progressive restoring of an arbitrary number of PTFs provided
that the predecessors have not been purged from the DELTA disk (analogue of 
SMPPTS).

-- 
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IBM APAR Names

[Seymour J Metz]

SES is a tools that fills the same nicje in the VM ecology as SMP does in the 
MVS ecology. 


-- 
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי




From: IBM Mainframe Discussion List  on behalf of 
Phil Smith III 
Sent: Tuesday, November 7, 2023 5:56 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IBM APAR Names

Shmuel wrote:
>What is VMSES/E, chopped liver. I'd agree if you were talking free VM,
>but by the time z/VM came out SES was old hat.

? Not sure what point you're making, I'm afraid?


--
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

Re: IBM APAR Names

[Phil Smith III]

Shmuel wrote:
>What is VMSES/E, chopped liver. I'd agree if you were talking free VM,
>but by the time z/VM came out SES was old hat.

? Not sure what point you're making, I'm afraid?


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IBM APAR Names

[Tom Brennan]

Before my time with VM!  What was this "RESERVEd" lines thing? 
Something like the lines at the bottom of a z/OS console?


On 11/7/2023 1:42 PM, Mike Schwab wrote:

Heh. Circa, um, 1984? 1985? It was a huge APAR that changed RESERVEd lines to
be per-screen instead of being global to XEDIT (among other things). In
retrospect, pretty clearly done to enable FILELIST et al.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IBM APAR Names

[Seymour J Metz]

What is VMSES/E, chopped liver. I'd agree if you were talking free VM, but by 
the time z/VM came out SES was old hat.


-- 
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי




From: IBM Mainframe Discussion List  on behalf of 
Phil Smith III 
Sent: Tuesday, November 7, 2023 3:55 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IBM APAR Names

This has been interesting. As a long-time VMer, I'd note that in VM-land, there 
is of course no SMP/E and things are a bit different. "APAR" and "PTF" kind of 
get used interchangeably, though there is recognition that they're not the 
same. But typically a VMer will say "I need APAR VM20779", not "I need the PTF 
for z/VM 7.3 that came from APAR VM20779", because it's basically same 
difference without SMP/E. The VM maintenance tools (VMSES/E) work fine but 
aren't as.shall we say theological? as SMP/E.



(Extra credit for anyone who remembers VM20779, at least 40 years ago!)


--
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

Re: IBM APAR Names

[Mike Schwab]

https://www.mail-archive.com/cms-pipelines@vm.marist.edu/msg03814.html

>VM20779?  Wayback Machine?  GIYF?  Not.

Heh. Circa, um, 1984? 1985? It was a huge APAR that changed RESERVEd lines to
be per-screen instead of being global to XEDIT (among other things). In
retrospect, pretty clearly done to enable FILELIST et al.

On Tue, Nov 7, 2023 at 2:56 PM Phil Smith III  wrote:
>
> This has been interesting. As a long-time VMer, I'd note that in VM-land, 
> there is of course no SMP/E and things are a bit different. "APAR" and "PTF" 
> kind of get used interchangeably, though there is recognition that they're 
> not the same. But typically a VMer will say "I need APAR VM20779", not "I 
> need the PTF for z/VM 7.3 that came from APAR VM20779", because it's 
> basically same difference without SMP/E. The VM maintenance tools (VMSES/E) 
> work fine but aren't as.shall we say theological? as SMP/E.
>
>
>
> (Extra credit for anyone who remembers VM20779, at least 40 years ago!)
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IBM APAR Names

[Phil Smith III]

This has been interesting. As a long-time VMer, I'd note that in VM-land, there 
is of course no SMP/E and things are a bit different. "APAR" and "PTF" kind of 
get used interchangeably, though there is recognition that they're not the 
same. But typically a VMer will say "I need APAR VM20779", not "I need the PTF 
for z/VM 7.3 that came from APAR VM20779", because it's basically same 
difference without SMP/E. The VM maintenance tools (VMSES/E) work fine but 
aren't as.shall we say theological? as SMP/E.

 

(Extra credit for anyone who remembers VM20779, at least 40 years ago!)


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IBM APAR Names

[Radoslaw Skorupka]

W dniu 06.11.2023 o 16:20, Ed Jaffe pisze:

On 11/5/2023 4:03 PM, Shaffer, Terri wrote:
So I am trying to apply maintenance and want to know the actual APAR 
to look up to see if its open closed, or what?


Slide 72 in SHARE New Orleans Bit Bucket X'42' explains the APAR and 
++APAR naming convention used most often with z/OS products and 
components.


The possible APAR prefixes are: OA, PH, PI, PK, PL, PM, PN, IO, PP, 
PQ, IR, OW, OY and OZ. The second letter of the ++APAR is the mapping.




What does it mean "mapping" ?

--
Radoslaw Skorupka
Lodz, Poland

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: APAR theology (was: IBM APAR Names)

[Glenn Knickerbocker]

On Sun, 5 Nov 2023 00:20:52 +, Seymour J Metz  wrote:
>IBM used to document how it assigned the prefix in sysmod ids, but its been 
>decades since I've seen documentation that matched practice. What I've never 
>seen violated is that the sysmod ids associated with an APAR all have the same 
>numeric portion.

What *is* documented is the *range* of prefix letters used for ++APARs provided 
by IBM:  A-K and V-Z.
https://www.ibm.com/docs/en/zos/3.1.0?topic=sysmods-ptf-apar-usermod-sysmod-ids

I'd be surprised if specific prefix assignments were ever documented.  At first 
the prefix letter was normally A, and additional prefixes might be used to SUP 
the original ++APAR.  Later, some components started using different prefix 
letters for each release, to make it easier to manage them in the same zone, 
but the letters used different by component.  When we switched build tooling in 
2017, I tried to make it the same by release for as many components as 
possible:  B (to match release 7B0) for z/OS 2.3, C for 2.4, D for 2.5, now E 
for 3.1.  But there are still a lot of exceptions for components that have more 
than one FMID per z/OS release.

It's possible but very unlikely for the second letter and the numeric portion 
to differ from the APAR number.  The tools will never build a ++APAR that way.  
Nothing stops a developer from manually editing it and changing the name, and 
in fact older tools allowed them to change the first letter and enter the 
change in the tool so the PTF would SUP it.  Changing anything beyond the first 
letter requires an admin to enter the new name, though, and I don't recall 
doing that even once in 15 years.  (By odd coincidence, I was just looking into 
the details of doing that last week, when a complicated situation arose with a 
fix that had been canceled in an old release, but then a new APAR was opened 
against that release later.)

--Glenn

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IBM APAR Names

[Michael Babcock]

I’ve always gone to
https://www.ibm.com/support/pages/enhanced-holddata-zos and scrolled down
to “
*REPORT ERRSYSMODS APAR SYSMOD ID to RETAIN APAR Number mapping” to figure
out the mapping.  *



On Mon, Nov 6, 2023 at 9:20 AM Ed Jaffe  wrote:

> On 11/5/2023 4:03 PM, Shaffer, Terri wrote:
> > So I am trying to apply maintenance and want to know the actual APAR to
> look up to see if its open closed, or what?
>
> Slide 72 in SHARE New Orleans Bit Bucket X'42' explains the APAR and
> ++APAR naming convention used most often with z/OS products and components.
>
> The possible APAR prefixes are: OA, PH, PI, PK, PL, PM, PN, IO, PP, PQ,
> IR, OW, OY and OZ. The second letter of the ++APAR is the mapping.
>
> --
> Phoenix Software International
> Edward E. Jaffe
> 831 Parkview Drive North
> El Segundo, CA 90245
> https://www.phoenixsoftware.com/
>
>
>
> 
> This e-mail message, including any attachments, appended messages and the
> information contained therein, is for the sole use of the intended
> recipient(s). If you are not an intended recipient or have otherwise
> received this email message in error, any use, dissemination, distribution,
> review, storage or copying of this e-mail message and the information
> contained therein is strictly prohibited. If you are not an intended
> recipient, please contact the sender by reply e-mail and destroy all copies
> of this email message and do not otherwise utilize or retain this email
> message or any or all of the information contained therein. Although this
> email message and any attachments or appended messages are believed to be
> free of any virus or other defect that might affect any computer system
> into
> which it is received and opened, it is the responsibility of the recipient
> to ensure that it is virus free and no responsibility is accepted by the
> sender for any loss or damage arising in any way from its opening or use.
>
> --
> 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

Re: IBM APAR Names

[Ed Jaffe]

On 11/5/2023 4:03 PM, Shaffer, Terri wrote:

So I am trying to apply maintenance and want to know the actual APAR to look up 
to see if its open closed, or what?


Slide 72 in SHARE New Orleans Bit Bucket X'42' explains the APAR and 
++APAR naming convention used most often with z/OS products and components.


The possible APAR prefixes are: OA, PH, PI, PK, PL, PM, PN, IO, PP, PQ, 
IR, OW, OY and OZ. The second letter of the ++APAR is the mapping.


--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://www.phoenixsoftware.com/



This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IBM APAR Names

[Allan Staller]

Classification: Confidential

In my experience, the 1st letter of the APAR name is a "version" designator.
e.g. JES2 has historically had many variants of a "single product".

So the APAR "documentation" designation would be OAx.
An actual "APAR FIX" (with test code) for the "1st version" would receive an 
actual apar number of AAx (x is the same number).
Due to code changes between the releases, a 2nd version is required. (i.e. same 
problem, different code). The "2nd version" would receive the designation 
BAx.
After the vetting process is completed, A PTF (or several) will be issued with 
UA SUPing the relevant APAR number).
e.g.  ++PTF(UAx) SUP (AAx, BBx).

My USD $0.02 worth,

::DISCLAIMER::

The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only. E-mail transmission is not guaranteed to be 
secure or error-free as information could be intercepted, corrupted, lost, 
destroyed, arrive late or incomplete, or may contain viruses in transmission. 
The e mail and its contents (with or without referred errors) shall therefore 
not attach any liability on the originator or HCL or its affiliates. Views or 
opinions, if any, presented in this email are solely those of the author and 
may not necessarily reflect the views or opinions of HCL or its affiliates. Any 
form of reproduction, dissemination, copying, disclosure, modification, 
distribution and / or publication of this message without the prior written 
consent of authorized representative of HCL is strictly prohibited. If you have 
received this email in error please delete it and notify the sender 
immediately. Before opening any email and/or attachments, please check them for 
viruses and other defects.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IBM APAR Names

[Seymour J Metz]

Try looking up OA62016, OA63853, OA64112, A63853.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי




From: IBM Mainframe Discussion List  on behalf of 
Shaffer, Terri <017d5f778222-dmarc-requ...@listserv.ua.edu>
Sent: Sunday, November 5, 2023 7:03 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IBM APAR Names

So in looking at the causer report and below.

The ones with an identified fixing APAR, can go after and pull, However

UJ08845  HBB77C0  GIM35901I 21   ERROR HOLD CA64112 WAS NOT RESOLVED.

UJ09109  HCPT440  GIM35901I 22   ERROR HOLD EA63853 WAS NOT RESOLVED.

UJ09110  JCPT441  GIM35901I 22   ERROR HOLD FA63853 WAS NOT RESOLVED.

HOLD MISSING  HELD RESOLVING  RESOLVER
TYPEFMID CLASSAPAR SYSMOD   SYSMOD STATUS
--  ---  ---  ---  ---  -  
ERROR   HBB77C0  PE  CA62016  UJ90013  UJ07269NOGO(E)
 CA63421  UJ90024  UJ08912NOGO(E)
 CA64112  UJ08845  UJ09743MISSING
 CA65388  UJ07918


++HOLD(UJ07918) FMID(HJE77C0) REASON(CA65388) ERROR DATE(23228)
 COMMENT(SMRTDATA(CHGDT(230816))) CLASS(PE).

So I am trying to apply maintenance and want to know the actual APAR to look up 
to see if its open closed, or what?


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Radoslaw Skorupka
Sent: Sunday, November 5, 2023 5:16 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IBM APAR Names

EXTERNAL EMAIL: Do not click links or open attachments unless you know the 
content is safe.


YMMV
In my 25 years career I have seen a lot of PTFs, web deliverables, but only one 
APAR fix.
AFAIR I have read in some SMP/E course, the APAR fixes are not widely available 
and cannot be downloaded from ShopzSeries. APAR fixes are available directly to 
the customer who claimed the error in the software. And this is my case.
However in some other cases we submitted PMR and APAR was created, but we got 
information about PTF available in (near) future, no mention about APAR fix.

Of course it is only my humble experience, others can have different one.

--
Radoslaw Skorupka
Lodz, Poland



W dniu 05.11.2023 o 05:10, Bruce Hewson pisze:
> Hello Jon,
>
> As a customer I currently have 638 ++APARs installed across my product base. 
> We regularly get test fixes, as in ++APAR,  provided by vendors.
>
> I wouldn't really call them RARE.
>
> On Sat, 4 Nov 2023 13:31:17 -0500, Jon Perryman  wrote:
>
>> On Sat, 4 Nov 2023 07:19:49 -0500, Bruce Hewson  
>> wrote:
>>
>>> APARs for me are OAx or PHx - these are the entries describing a 
>>> problem, and may be associates as Error Holds to existing  PTFs.
>> The broader point that needs to be addressed is the purpose of an APAR. 
>> Since ++APAR are rarely seen by vendor staff and customers, there must be a 
>> much bigger use for vendors otherwise why do they bother with describe the 
>> problem in the APAR.
>>
> Regards
> Bruce

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

 [https://go.aciworldwide.com/rs/030-ROK-804/images/aci-footer.jpg] 
<http://www.aciworldwide.com/>
This email message and any attachments may contain confidential, proprietary or 
non-public information. The information is intended solely for the designated 
recipient(s). If an addressing or transmission error has misdirected this 
email, please notify the sender immediately and destroy this email. Any review, 
dissemination, use or reliance upon this information by unintended recipients 
is prohibited. Any opinions expressed in this email are those of the author 
personally.

--
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

Re: IBM APAR Names

[Shaffer, Terri]

So in looking at the causer report and below.

The ones with an identified fixing APAR, can go after and pull, However

UJ08845  HBB77C0  GIM35901I 21   ERROR HOLD CA64112 WAS NOT RESOLVED.

UJ09109  HCPT440  GIM35901I 22   ERROR HOLD EA63853 WAS NOT RESOLVED.

UJ09110  JCPT441  GIM35901I 22   ERROR HOLD FA63853 WAS NOT RESOLVED.

HOLD MISSING  HELD RESOLVING  RESOLVER
TYPEFMID CLASSAPAR SYSMOD   SYSMOD STATUS
--  ---  ---  ---  ---  -  
ERROR   HBB77C0  PE  CA62016  UJ90013  UJ07269NOGO(E)
 CA63421  UJ90024  UJ08912NOGO(E)
 CA64112  UJ08845  UJ09743MISSING
 CA65388  UJ07918


++HOLD(UJ07918) FMID(HJE77C0) REASON(CA65388) ERROR DATE(23228)
 COMMENT(SMRTDATA(CHGDT(230816))) CLASS(PE).

So I am trying to apply maintenance and want to know the actual APAR to look up 
to see if its open closed, or what?


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Radoslaw Skorupka
Sent: Sunday, November 5, 2023 5:16 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IBM APAR Names

EXTERNAL EMAIL: Do not click links or open attachments unless you know the 
content is safe.


YMMV
In my 25 years career I have seen a lot of PTFs, web deliverables, but only one 
APAR fix.
AFAIR I have read in some SMP/E course, the APAR fixes are not widely available 
and cannot be downloaded from ShopzSeries. APAR fixes are available directly to 
the customer who claimed the error in the software. And this is my case.
However in some other cases we submitted PMR and APAR was created, but we got 
information about PTF available in (near) future, no mention about APAR fix.

Of course it is only my humble experience, others can have different one.

--
Radoslaw Skorupka
Lodz, Poland



W dniu 05.11.2023 o 05:10, Bruce Hewson pisze:
> Hello Jon,
>
> As a customer I currently have 638 ++APARs installed across my product base. 
> We regularly get test fixes, as in ++APAR,  provided by vendors.
>
> I wouldn't really call them RARE.
>
> On Sat, 4 Nov 2023 13:31:17 -0500, Jon Perryman  wrote:
>
>> On Sat, 4 Nov 2023 07:19:49 -0500, Bruce Hewson  
>> wrote:
>>
>>> APARs for me are OAx or PHx - these are the entries describing a 
>>> problem, and may be associates as Error Holds to existing  PTFs.
>> The broader point that needs to be addressed is the purpose of an APAR. 
>> Since ++APAR are rarely seen by vendor staff and customers, there must be a 
>> much bigger use for vendors otherwise why do they bother with describe the 
>> problem in the APAR.
>>
> Regards
> Bruce

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

 [https://go.aciworldwide.com/rs/030-ROK-804/images/aci-footer.jpg] 
<http://www.aciworldwide.com>
This email message and any attachments may contain confidential, proprietary or 
non-public information. The information is intended solely for the designated 
recipient(s). If an addressing or transmission error has misdirected this 
email, please notify the sender immediately and destroy this email. Any review, 
dissemination, use or reliance upon this information by unintended recipients 
is prohibited. Any opinions expressed in this email are those of the author 
personally.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IBM APAR Names

[Jay Maynard]

Interesting. I'd always understood it to be Program Temporary Fix, or, more
snarkily and unofficially, Permanent Temporary Fix.

On Sun, Nov 5, 2023 at 10:14 AM Seymour J Metz  wrote:

> 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  on behalf
> of Eric D Rossman 
> 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, (AAn 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 DAn. 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(DAn) 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 OAn. 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  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., documentat

Re: IBM APAR Names

[Eric D Rossman]

So, VERY old.  Interesting. I started with OS/390.

Eric Rossman

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Seymour J Metz
Sent: Sunday, November 5, 2023 11:15 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: IBM APAR Names

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);"

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IBM APAR Names

[Eric D Rossman]

I'll admit that we have some alternate expansions of SPE internally. I've heard 
"significant" or "staggering." I've also heard "Surprise! PE" (PTF in error)


From: IBM Mainframe Discussion List  on behalf of 
Phil Smith III 
Sent: Sunday, November 5, 2023 12:48:57 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: [EXTERNAL] Re: IBM APAR Names

An aside re SPEs: back in the early 80s, IBM released an SPE for a CMS utility. 
The original code was on the order of 500 lines; the SPE was something like 
3500. Melinda Varian (whom some of you may recall) posted to VMSHARE-the 
VM-oriented BBS of the era-a review of the change, which had a number of 
significant problems, concluding:
"This is small? This is programming?? This is an enhancement???"



I was just starting out, but it solidly cemented the meaning of "SPE" for me!

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IBM APAR Names

[Phil Smith III]

An aside re SPEs: back in the early 80s, IBM released an SPE for a CMS utility. 
The original code was on the order of 500 lines; the SPE was something like 
3500. Melinda Varian (whom some of you may recall) posted to VMSHARE-the 
VM-oriented BBS of the era-a review of the change, which had a number of 
significant problems, concluding:
"This is small? This is programming?? This is an enhancement???"

 

I was just starting out, but it solidly cemented the meaning of "SPE" for me!


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IBM APAR Names

[Seymour J Metz]

L2 was more likely to be familiar with IBM nomenclature andd less likely to ask 
you whether you were running an OS that didn't contain the component you were 
reporting the problem against. That issue disappeared with IBMLink.



--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי




From: IBM Mainframe Discussion List  on behalf of Tom 
Brennan 
Sent: Sunday, November 5, 2023 11:11 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IBM APAR Names

Great notes Eric, thanks!  And some newer folks might wonder why the
first person to look at a problem is called Level 2.  When I started in
the 1980's you made a phone call to IBM support and got a Level 1
person.  That person (as far as I could tell) basically tried to match
your symptoms up with an existing issue in the IBM problem database,
that customers had no direct access to.  Often they would find a match
and set you up with a PTF, but if that didn't happen, they sent you to
Level 2.

Maybe it was the late 1980's where the IBMLink system (3270) became
available to customers, and we would use that to search the database
ourselves.  I hope all the Level 1 people went on to be Level 2, because
we never needed them again.

On 11/5/2023 6:54 AM, Eric D Rossman wrote:
> 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, (AAn 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 
> DAn. 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(DAn) 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 OAn. 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  On Behalf Of 
> Seymou

Re: IBM APAR Names

[Seymour J Metz]

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  on behalf of 
Eric D Rossman 
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, 
(AAn 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 
DAn. 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(DAn) 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 OAn. 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  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  on behalf of 
Anthony Fletcher 
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 Prob

Re: IBM APAR Names

[Tom Brennan]

Great notes Eric, thanks!  And some newer folks might wonder why the 
first person to look at a problem is called Level 2.  When I started in 
the 1980's you made a phone call to IBM support and got a Level 1 
person.  That person (as far as I could tell) basically tried to match 
your symptoms up with an existing issue in the IBM problem database, 
that customers had no direct access to.  Often they would find a match 
and set you up with a PTF, but if that didn't happen, they sent you to 
Level 2.


Maybe it was the late 1980's where the IBMLink system (3270) became 
available to customers, and we would use that to search the database 
ourselves.  I hope all the Level 1 people went on to be Level 2, because 
we never needed them again.


On 11/5/2023 6:54 AM, Eric D Rossman wrote:

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, (AAn 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 DAn. 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(DAn) 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 OAn. 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  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  on behalf of Anthony 
Fletcher 
Sent: Saturday, November 4, 2023 7:38 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IBM APAR Names

This chain has an interesti

Re: IBM APAR Names

[Eric D Rossman]

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, 
(AAn 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 
DAn. 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(DAn) 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 OAn. 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  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  on behalf of 
Anthony Fletcher 
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 

Re: IBM APAR Names

[Radoslaw Skorupka]

YMMV
In my 25 years career I have seen a lot of PTFs, web deliverables, but 
only one APAR fix.
AFAIR I have read in some SMP/E course, the APAR fixes are not widely 
available and cannot be downloaded from ShopzSeries. APAR fixes are 
available directly to the customer who claimed the error in the 
software. And this is my case.
However in some other cases we submitted PMR and APAR was created, but 
we got information about PTF available in (near) future, no mention 
about APAR fix.


Of course it is only my humble experience, others can have different one.

--
Radoslaw Skorupka
Lodz, Poland



W dniu 05.11.2023 o 05:10, Bruce Hewson pisze:

Hello Jon,

As a customer I currently have 638 ++APARs installed across my product base. We 
regularly get test fixes, as in ++APAR,  provided by vendors.

I wouldn't really call them RARE.

On Sat, 4 Nov 2023 13:31:17 -0500, Jon Perryman  wrote:


On Sat, 4 Nov 2023 07:19:49 -0500, Bruce Hewson  
wrote:


APARs for me are OAx or PHx - these are the entries describing a 
problem, and may be associates as Error Holds to existing  PTFs.

The broader point that needs to be addressed is the purpose of an APAR. Since 
++APAR are rarely seen by vendor staff and customers, there must be a much 
bigger use for vendors otherwise why do they bother with describe the problem 
in the APAR.


Regards
Bruce


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IBM APAR Names

[Bruce Hewson]

Hello Jon,

As a customer I currently have 638 ++APARs installed across my product base. We 
regularly get test fixes, as in ++APAR,  provided by vendors.

I wouldn't really call them RARE.

On Sat, 4 Nov 2023 13:31:17 -0500, Jon Perryman  wrote:

>On Sat, 4 Nov 2023 07:19:49 -0500, Bruce Hewson  
>wrote:
>
>>APARs for me are OAx or PHx - these are the entries describing a 
>>problem, and may be associates as Error Holds to existing  PTFs.
>
>The broader point that needs to be addressed is the purpose of an APAR. Since 
>++APAR are rarely seen by vendor staff and customers, there must be a much 
>bigger use for vendors otherwise why do they bother with describe the problem 
>in the APAR.
>

Regards
Bruce

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: APAR theology (was: IBM APAR Names)

[Seymour J Metz]

IBM used to document how it assigned the prefix in sysmod ids, but its been 
decades since I've seen documentation that matched practice. What I've never 
seen violated is that the sysmod ids associated with an APAR all have the same 
numeric portion.

The simplest situation is when the error only exists in one sysmod, only one 
sysmod id is needed in the error hold and a single PTF supercedes. the error 
sysmod. When the error exists in multiple PTFs, IBM may need to clone the error 
sysmod, in order to provide ++APAR fixes for each PTF.


-- 
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי




From: IBM Mainframe Discussion List  on behalf of 
Phil Smith III 
Sent: Friday, November 3, 2023 8:51 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: APAR theology (was: IBM APAR Names)

Without wanting to start a war, I’m interested in how this works. I’ve worked 
with IBM stuff for over four decades, but mostly with VM until the last 15 or 
so years.



My understanding is:

*   PMR: represents a customer issue, which may end there.
*   APAR: represents a customer issue that at least seems to indicate a 
code problem. Existence of an APAR does not guarantee a fix will ever be 
created; it’s more a recognition that there’s more to it than just “customer 
needs an existing fix”, “is doing something dumb”, etc. One APAR might thus map 
to multiple PMRs, if multiple customers have the same problem.
*   PTF: An actual fix



Now y’all are talking about “APAR fixes”, which I’ve never heard of. And I know 
there’s more to APARs than I wrote, just can’t remember it. Having worked for 
vendors for the last 37 years means I’ve been out of the normal flow of such 
things, too—when I was at UofWaterloo, we had a backlog of a couple of hundred 
things that we’d fixed in IBM code; we had an agreement with our PSR—the sort 
of “level 1 ½” that customers have [had, then, anyway] that we’d only have 5 
open at once. That was always fun: call IBM, “I want to open five problems.” 
“FIVE PROBLEMS???!” “Well, I have a couple of hundred, but I’m only opening 
five today.” “Oh, ok.”



ISTR that if a problem appears in multiple supported releases, one APAR might 
result in multiple PTFs, one per release.



I’m also interested in a definitive list of APAR closings. I’ve never seen one, 
and the lists I’ve seen have been conflicting and often included different 
interpretations of the same closing.



None of this matters a ton, of course, but it *works* when done right, which is 
more than I can say for many customer problem workflows!



I don’t see this as particularly sensitive info, but perhaps IBM will disagree, 
in which case I’ll STFU.


--
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

Re: IBM APAR Names

[Seymour J Metz]

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  on behalf of 
Anthony Fletcher 
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  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  
wrote:

>HI,
>
>APARs for me are OAx or PHx - 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 AAx, BAx etc for each new iteration of a fix for 
>APAR OAx.
>
>So depending on how many attempts have been made to get the corrective
>fix for the problem described in APAR OAx 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. OAx
>
>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

Re: IBM APAR Names

[Seymour J Metz]

I'll try to clarify things. An APAR is a report used for tracking things, most 
often reported errors. Associated with the APAR are identifiers with the same 
numeric parts, used as sysmod ids in SMP. A common situation is that the error 
exists in multiple releases. There used to be a documented pattern in how the 
prefixes are  assigned; I''m not sure whether that is still true. Also, 3rd 
party vendors may have their own conventions. Technically those associated 
sysmod ids are not APAR numbers, but some people use the term regardless.

A typical scenario is that IBM flags PTFS as PTF in ERROR (PE), assigning 
holddata to the PTFS with reasons containing sysmod ids associated ith the APAR 
numbers. IBM may provide ++ APAR sysmods to correct the errors, but normally 
will eventually provide PTF or FUNCTION sysmods that supercede them.



--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי




From: IBM Mainframe Discussion List  on behalf of 
Shaffer, Terri <017d5f778222-dmarc-requ...@listserv.ua.edu>
Sent: Friday, November 3, 2023 12:32 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: IBM APAR Names

Hi,
  So I should know this but apparently I missed the memo along the way, Can 
anyone give me the secret decoder

I know AHx went to PHx

But what do I search for CA and EA  APARs?



 [https://go.aciworldwide.com/rs/030-ROK-804/images/aci-footer.jpg] 
<http://www.aciworldwide.com/>
This email message and any attachments may contain confidential, proprietary or 
non-public information. The information is intended solely for the designated 
recipient(s). If an addressing or transmission error has misdirected this 
email, please notify the sender immediately and destroy this email. Any review, 
dissemination, use or reliance upon this information by unintended recipients 
is prohibited. Any opinions expressed in this email are those of the author 
personally.

--
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

Re: IBM APAR Names

[Anthony Fletcher]

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  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  
wrote:

>HI,
>
>APARs for me are OAx or PHx - 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 AAx, BAx etc for each new iteration of a fix for 
>APAR OAx.
>
>So depending on how many attempts have been made to get the corrective 
>fix for the problem described in APAR OAx 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. OAx
> 
>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

Re: IBM APAR Names

[Mark Zelden]

On Sat, 4 Nov 2023 07:19:49 -0500, Bruce Hewson  
wrote:

>HI,
>
>APARs for me are OAx or PHx - 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 AAx, BAx etc for each new iteration of a fix for 
>APAR OAx.
>
>So depending on how many attempts have been made to get the corrective fix for 
>the problem described in APAR OAx
>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. OAx
> 
>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

Re: IBM APAR Names

[Lennie Dymoke-Bradshaw]

In my experience back in the 1980s and 1990s IBM were far more likely to 
provide ++APAR type fixes for source-maintained products than for others. So at 
the time that mainly applied to JES2, JES3 and IMS I think. However, I have 
been the instigator for a few ++APAR fixes which were zaps.

Lennie Dymoke-Bradshaw
https://rsclweb.com 
‘Dance like no one is watching. Encrypt like everyone is.’

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Jon 
Perryman
Sent: 04 November 2023 18:31
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IBM APAR Names

On Sat, 4 Nov 2023 07:19:49 -0500, Bruce Hewson  
wrote:

>APARs for me are OAx or PHx - these are the entries describing a 
>problem, and may be associates as Error Holds to existing  PTFs.

The broader point that needs to be addressed is the purpose of an APAR. Since 
++APAR are rarely seen by vendor staff and customers, there must be a much 
bigger use for vendors otherwise why do they bother with describe the problem 
in the APAR.

As I said before, documentation is the main purpose for APARs and that 
documentation is presented in problem searches. ++APAR is only 1 of the APAR 
processes available to a vendor but the documentation processes are far more 
important.

For most vendors, APARs document much more than the defect (e.g. resolving 
PTF's, circumventions, holds and anything else that is useful for customers to 
solve that problem). Once a PTF is closed, it will never be updated but APARs 
can be modified as more useful information is found. 

>Before a PTF is issued, the vendor may issue a ++APAR for you to test. A 
>++APAR fix is not fully tested.

I'm skeptical that using ++APAR for testing is common practice. Unlike the well 
established bullet proof PTF processes, ++APAR can cause serious problems and 
grief. The vendors I worked for required management approval and it required 
important justification. 

I suspect that products that are not vital may be using this technique but I 
worked on products that could be destroyer of worlds. There's nothing like 
being on the phone with 35 screaming managers in a room because they think your 
product crashed their computer. It turned out not to be our product but it was 
critical to their environment.  

>++APAR names aill be AAx, BAx etc for each new iteration of a fix for 
>APAR OAx.

It sounds like ++APAR processes are a common practice for you, Each vendor has 
different ++APAR processes and it can vary within a vendor. It sounds like you 
know how to avoid the ++APAR gotchas. The vendor has chosen to a accept the 
consequences if something goes wrong and the rewards outweigh the risk. There 
are times I wish I had open access to ++APAR.   

>So depending on how many attempts have been made to get the corrective 
>fix for the problem described in APAR OAx 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. OAx
> 
>This is how I was introduced to ++APAR naming conventions.

You didn't mention the risks of REWORK, REDO and more. Nor did you mention 
modules must never be removed from an APAR and the superceding PTF must include 
all modules touched by the APARs. 

Searching APARs is the most up to date information about PTFs and it eliminates 
duplications that a PTF search would return.

At the end of the day, you do what's best for you. Problem resolution is about 
getting the best results and there is a lot of flexibility built into the 
processes.  It is process driven with different tools available to automate the 
processes.

--
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

Re: IBM APAR Names

[Mike Schwab]

How about browsing the Holddata explanation page at
 https://public.dhe.ibm.com/390holddata/390holddata.html
and retrieving the file to view the contents?

On Fri, Nov 3, 2023 at 11:02 PM Tony Harminc  wrote:
>
> On Fri, 3 Nov 2023 at 18:03, Jon Perryman  wrote:
> [...]
>
> > 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.
> >
>
> Backwards. A-I is IBM; J-Z (minus Q, which is reserved for IBM i) and
> numerics is for everyone else. This applies to component IDs, and function
> sysmods (FMIDs) are expected to take the form tcccrrr, where t values of
> A-J are IBM's and everything else is user/vendor land, and ccc is the
> component ID and rrr the version/release. But I don't think these have ever
> applied to fix names like OA12345.
>
> IBM seems to have abandoned the Standard Packaging Rules for z/OS-Based
> Products book, in favour of a tiny section on naming in the SMP/E
> Reference. Gone is the offer to register component IDs with
> elem...@us.ibm.com .
>
> Tony H.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IBM APAR Names

[Jon Perryman]

On Sat, 4 Nov 2023 07:19:49 -0500, Bruce Hewson  
wrote:

>APARs for me are OAx or PHx - these are the entries describing a 
>problem, and may be associates as Error Holds to existing  PTFs.

The broader point that needs to be addressed is the purpose of an APAR. Since 
++APAR are rarely seen by vendor staff and customers, there must be a much 
bigger use for vendors otherwise why do they bother with describe the problem 
in the APAR.

As I said before, documentation is the main purpose for APARs and that 
documentation is presented in problem searches. ++APAR is only 1 of the APAR 
processes available to a vendor but the documentation processes are far more 
important.

For most vendors, APARs document much more than the defect (e.g. resolving 
PTF's, circumventions, holds and anything else that is useful for customers to 
solve that problem). Once a PTF is closed, it will never be updated but APARs 
can be modified as more useful information is found. 

>Before a PTF is issued, the vendor may issue a ++APAR for you to test. A 
>++APAR fix is not fully tested.

I'm skeptical that using ++APAR for testing is common practice. Unlike the well 
established bullet proof PTF processes, ++APAR can cause serious problems and 
grief. The vendors I worked for required management approval and it required 
important justification. 

I suspect that products that are not vital may be using this technique but I 
worked on products that could be destroyer of worlds. There's nothing like 
being on the phone with 35 screaming managers in a room because they think your 
product crashed their computer. It turned out not to be our product but it was 
critical to their environment.  

>++APAR names aill be AAx, BAx etc for each new iteration of a fix for 
>APAR OAx.

It sounds like ++APAR processes are a common practice for you, Each vendor has 
different ++APAR processes and it can vary within a vendor. It sounds like you 
know how to avoid the ++APAR gotchas. The vendor has chosen to a accept the 
consequences if something goes wrong and the rewards outweigh the risk. There 
are times I wish I had open access to ++APAR.   

>So depending on how many attempts have been made to get the corrective fix for 
>the problem described in APAR OAx
>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. OAx
> 
>This is how I was introduced to ++APAR naming conventions.

You didn't mention the risks of REWORK, REDO and more. Nor did you mention 
modules must never be removed from an APAR and the superceding PTF must include 
all modules touched by the APARs. 

Searching APARs is the most up to date information about PTFs and it eliminates 
duplications that a PTF search would return.

At the end of the day, you do what's best for you. Problem resolution is about 
getting the best results and there is a lot of flexibility built into the 
processes.  It is process driven with different tools available to automate the 
processes.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IBM APAR Names

[Bruce Hewson]

HI,

APARs for me are OAx or PHx - 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 AAx, BAx etc for each new iteration of a fix for 
APAR OAx.

So depending on how many attempts have been made to get the corrective fix for 
the problem described in APAR OAx
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. OAx
 
This is how I was introduced to ++APAR naming conventions.

Regards
Bruce Hewson

On Fri, 3 Nov 2023 17:24:30 +, Keith Gooding  wrote:

>Should be OAx. I missed the memo too.
>
>> On 3 Nov 2023, at 16:33, Shaffer, Terri 
>> <017d5f778222-dmarc-requ...@listserv.ua.edu> wrote:
>> 
>> Hi,
>>  So I should know this but apparently I missed the memo along the way, Can 
>> anyone give me the secret decoder
>> 
>> I know AHx went to PHx
>> 
>> But what do I search for CA and EA  APARs?
>> 
>> 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IBM APAR Names

[Jon Perryman]

On Fri, 3 Nov 2023 23:12:08 -0500, Paul Gilmartin  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) ...  
>>
>
>Example 2: Marking a PTF that is in error
>++HOLD (UZ12345)/* Hold this PTF*/
>   FMID(FXY1040)/* for this function*/
>   ERROR/* for APAR fix.*/
>   REASON(AZ1)  /* APAR is AZ1. */
>   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?

>>> Mind the distinction between "APAR" and "APAR Fix".
>>>APARs are routinely created; APAR Fixes are not.
>>>
>>
>>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

Re: APAR theology (was: IBM APAR Names)

[Jon Perryman]

On Fri, 3 Nov 2023 22:24:02 -0400, Doug  wrote:

> SMPE claims to be the all knowing wizard but won’t do the resolution.

SMP/e is not (nor ever claimed) to be the all knowing wizard. It is a tool used 
by IBM and vendors for keeping your z/OS problem free.

It does not resolve problems. It simply does what vendors tell it to do through 
SMP/e statements. If a ++HOLD was forgotten, then you may not be aware of an 
action, doc change and much more that you must take after the PTF is applied. A 
tool is only as good as those who use it.

>The problem is I have to find and read every PTF / APAR one by one..

I'm not sure what you mean. Your processes for installing PTF's may be tedious 
but you could also take the UNIX approach where you don't get the choice and 
simply install bundled fixes call releases.

>Determine if the fix does what I need (maybe all the causes are documented But 
>hardly ever).

Processes are not the problem. APARs document the defect and it's resolution. 
Some causes may not be known.  Some people are more meticulous than others. The 
failure comes down to us being human.

Also remember that z/OS is becoming more like UNIX. Skills are being lost and 
diluted.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: APAR theology (was: IBM APAR Names)

[Jon Perryman]

On Fri, 3 Nov 2023 20:51:44 -0400, Phil Smith III  wrote:

> I�m interested in how this works.

This must be discussed in the bigger picture of problem management and the 
processes involved. Think about problems your child experiences. Your problem 
resolution processes for your child will be very different than their school 
principal and teachers.

For the z/OS world, the only consistent process is the tool SMP/e but even 
SMP/e has some flexibility. Understand that no 2 vendors (including IBM) will 
use the same process to go from having a problem to having a solved problem. 
This is a general description of the processes that is taken which will be 
missing a lot of detail.

>*  PMR: represents a customer issue, which may end there.

PMR (Problem Management Record) is IBM's tool used for working a problem. All 
vendors have a similar tool but with a different name and different 
functionality.

This tool allows us to efficiently work YOUR problem and access the processes 
needed to solve your problem. You send in a dump and we are notified. You call 
back, the operators know where to forward your call. The person working your 
problem is out and someone can see what they've done. The list of processes is 
simply to long to be discussed.

>*  APAR: represents a customer issue that at least seems to indicate a 
>code problem. 

An APAR is the public documentation of a product defect that has (or will be) 
fixed. PMR's contain confidential information and multiple PMR's may discuss 
the same problem, thus are not usable to document the fix to a product defect.

The definition of FIX is different between vendors (including IBM). All vendors 
agree that a PTF is a fix but some vendors include doc changes, faqs and more 
as product defect fixes. In other words, for some vendors, an APAR always fixes 
an actual product defect while other vendors muddy the waters by including any 
form of addressing a product defect.

SMP/e further muddies the definition of APAR by how it uses the word APAR. 
++APAR is one of several APAR processes that SMP/e provides. ++APAR is not an 
APAR nor is it a fix to the APAR. It's a process provided by SMP/e that allows 
us to circumvent problems so severe that you can't wait for the PTF. For 
instance, your system repeatedly crashes. I can create a ++APAR that stops the 
crashes but does not solve the defect. People ignore that removing the ++APAR 
is a critical part of the process.
 
>*  Existence of an APAR does not guarantee a fix will ever be created; 

As discussed above, an APAR will always be fixed. The definition of fixed is 
fuzzy.

>*  PTF: An actual fix

Yes and more to the point, a PTF fixes the APAR for a specific product release.

>Now y�all are talking about �APAR fixes�, which I�ve never heard of. 

Only PTF's fix a product defect. An APAR is the documentation for a product 
defect. As part of that documentation, It will contain a list of one or more 
PTF's that fix this APAR. These are the APAR fixes. 

> And I know there�s more to APARs than I wrote

I've only mentioned the APAR processes that are easily understood.

> Having worked for vendors for the last 37 years means I�ve been out of the 
> normal flow of such things

APARs are vendor processes that customers won't see. 

>ISTR that if a problem appears in multiple supported releases, one APAR might 
>result in multiple PTFs, one per release.

In the past, IBM releases were more frequent. It was not unusual to see 
multiple PTF. Today, with longer release cycles, I would expect one PTF per 
apar.

>I�m also interested in a definitive list of APAR closings.

With each vendor having different APAR processes, there isn't a common method 
of retrieving a list of APARs. With IBM selling off products but still 
marketing those products, it's unlikely you will find this list for IBM 
marketed products. With APAR processes differing by vendor, closed APAR could 
have muddy definition of closed.

>None of this matters a ton, of course, but it *works* when done right,
>which is more than I can say for many customer problem workflows!

This is more about the tools that implement the processes. Each vendor has 
their own tools and more important, those tools can be different within a 
vendor.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IBM APAR Names

[Paul Gilmartin]

On Fri, 3 Nov 2023 22:05:41 -0500, Jon Perryman wrote:
>
>>Grrr.  IBM's registered component prefixes govern program objects, etc., but
>>not SYSMODs.  The best we could do was choose an unlikely prefix.
>
>What were you thinking! All IBM PTF's & APARs begin with XX#. Unless you 
>unwisely chose a component prefix with a number, your component code will 
>never conflict with IBM standards. As for distinguishing APARs from PTFs, 
>there's nothing stopping you from registering a second component code solely 
>for APARS. As for choosing an unlikely prefix, hopefully you didn't use a 
>registered component code because I think this is a standard vendor practice 
>(at least where I've been).
>
"Standard"?  Cite.  Does IBM state that component codes prefix SYSMOD IDs.

>>Almost so.  By IBM's convention, the APAR Fix SUPs the matching APAR.
>
>This makes no sense. You never SUP yourself. What you are calling APAR FIX 
>here refers to a PTF. Only resolving PTFs SUP the APAR. In fact, APARs will 
>never contain a SUP unless absolutely necessary. An incorrect used SUP can 
>cause a new APAR just to fix SMP/e.
>
OK.  A PTF SUPs an APAR it correcrs.  It may suffice for an APAR Fix to match 
the
APAR ID.

>>++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) ...  
>

Example 2: Marking a PTF that is in error
++HOLD (UZ12345)/* Hold this PTF*/
   FMID(FXY1040)/* for this function*/
   ERROR/* for APAR fix.*/
   REASON(AZ1)  /* APAR is AZ1. */
   COMMENT(this APAR causes loop) 

>>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.
>
>What you are saying makes no sense. In terms of SMP/e, ++APAR is what you call 
>APAR FIX. 
>
IBM chose ++APAR as the MCS to introduce what IBM calls an APAR FIX. 

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.

>> Mind the distinction between "APAR" and "APAR Fix".
>>APARs are routinely created; APAR Fixes are not.
>>
>
>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.

>What you call "APAR FIX" refers to ++APAR 
>
What IBM calls an APAR Fix.

>which is just one optional piece of the APAR. To use it correctly, the APAR ID 
>must be specified in the PTF as a SUP. As part of the process, it provides a 
>convenient method to temporarily solve a critical customer problem where they 
>require the use of SMP/e.
>
I agree.

>>The name space is too damned small!  Listen, IBM!  (I'd like "com.".)
>
>As for name space, I'm not sure about the relevance to SMP/e. What is the 
>SMP/e statement / option to which you are referring?
>
Working for an ISV, I would have liked to embed a registered trademark in our 
SYSMOD IDs.

--  
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IBM APAR Names

[Tony Harminc]

On Fri, 3 Nov 2023 at 18:03, Jon Perryman  wrote:
[...]

> 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.
>

Backwards. A-I is IBM; J-Z (minus Q, which is reserved for IBM i) and
numerics is for everyone else. This applies to component IDs, and function
sysmods (FMIDs) are expected to take the form tcccrrr, where t values of
A-J are IBM's and everything else is user/vendor land, and ccc is the
component ID and rrr the version/release. But I don't think these have ever
applied to fix names like OA12345.

IBM seems to have abandoned the Standard Packaging Rules for z/OS-Based
Products book, in favour of a tiny section on naming in the SMP/E
Reference. Gone is the offer to register component IDs with
elem...@us.ibm.com .

Tony H.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IBM APAR Names

[Jon Perryman]

On Fri, 3 Nov 2023 17:35:10 -0500, Paul Gilmartin  wrote:

>Grrr.  IBM's registered component prefixes govern program objects, etc., but
>not SYSMODs.  The best we could do was choose an unlikely prefix.

What were you thinking! All IBM PTF's & APARs begin with XX#. Unless you 
unwisely chose a component prefix with a number, your component code will never 
conflict with IBM standards. As for distinguishing APARs from PTFs, there's 
nothing stopping you from registering a second component code solely for APARS. 
As for choosing an unlikely prefix, hopefully you didn't use a registered 
component code because I think this is a standard vendor practice (at least 
where I've been).

>Almost so.  By IBM's convention, the APAR Fix SUPs the matching APAR.

This makes no sense. You never SUP yourself. What you are calling APAR FIX here 
refers to a PTF. Only resolving PTFs SUP the APAR. In fact, APARs will never 
contain a SUP unless absolutely necessary. An incorrect used SUP can cause a 
new APAR just to fix SMP/e.

>++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) and specify the resolving APAR. The fixing PTF 
SUPs the APAR thus releasing the ++HOLD ERROR.  

>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.

What you are saying makes no sense. In terms of SMP/e, ++APAR is what you call 
APAR FIX. In terms of SMP/e, what does "APAR' refer to that you can now specify 
and was implemented because of your RCF?

> Mind the distinction between "APAR" and "APAR Fix".
>APARs are routinely created; APAR Fixes are not.
>

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. 

What you call "APAR FIX" refers to ++APAR which is just one optional piece of 
the APAR. To use it correctly, the APAR ID must be specified in the PTF as a 
SUP. As part of the process, it provides a convenient method to temporarily 
solve a critical customer problem where they require the use of SMP/e.

>The name space is too damned small!  Listen, IBM!  (I'd like "com.".)

As for name space, I'm not sure about the relevance to SMP/e. What is the SMP/e 
statement / option to which you are referring?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: APAR theology (was: IBM APAR Names)

[Paul Gilmartin]

On Fri, 3 Nov 2023 20:51:44 -0400, Phil Smith III wrote:
>
>I�m also interested in a definitive list of APAR closings. I�ve never seen 
>one, and the lists I�ve seen have been conflicting and often included 
>different interpretations of the same closing.
>


-- 
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: APAR theology (was: IBM APAR Names)

[Doug]

The problem is I have to find and read every PTF / APAR one by one..
Determine if the fix does what I need (maybe all the causes are documented But 
hardly ever). 
Why ? SMPE claims to be the all knowing wizard but won’t do the resolution.

I’m with Phil on this issue.

Just my 2 cents 

.

On Nov 3, 2023, at 22:10, Paul Gilmartin 
<042bfe9c879d-dmarc-requ...@listserv.ua.edu> wrote:

On Fri, 3 Nov 2023 20:51:44 -0400, Phil Smith III  wrote:
> 
> My understanding is:
> 
> *PMR: represents a customer issue, which may end there.
> 
This generally embeds tie ID of the reporting customer.

> *APAR: represents a customer issue that at least seems to indicate a code 
> problem. Existence 
> 
Importantly, the APAR ID may appear as the REASON() of Error HOLDDATA.

> *PTF: An actual fix

> Now y�all are talking about �APAR fixes�, which I�ve never heard of.
> 
The term appears at least here:


(The PTF keyword/phrase index was my friend.)


-- 
gil

--
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

Re: APAR theology (was: IBM APAR Names)

[Paul Gilmartin]

On Fri, 3 Nov 2023 20:51:44 -0400, Phil Smith III  wrote:
>
>My understanding is:
>
>*  PMR: represents a customer issue, which may end there.
>
This generally embeds tie ID of the reporting customer.

>*  APAR: represents a customer issue that at least seems to indicate a 
>code problem. Existence 
>
Importantly, the APAR ID may appear as the REASON() of Error HOLDDATA.

>*  PTF: An actual fix

>Now y�all are talking about �APAR fixes�, which I�ve never heard of.
>
The term appears at least here:


(The PTF keyword/phrase index was my friend.)


-- 
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

APAR theology (was: IBM APAR Names)

[Phil Smith III]

Without wanting to start a war, I’m interested in how this works. I’ve worked 
with IBM stuff for over four decades, but mostly with VM until the last 15 or 
so years.

 

My understanding is:

*   PMR: represents a customer issue, which may end there.
*   APAR: represents a customer issue that at least seems to indicate a 
code problem. Existence of an APAR does not guarantee a fix will ever be 
created; it’s more a recognition that there’s more to it than just “customer 
needs an existing fix”, “is doing something dumb”, etc. One APAR might thus map 
to multiple PMRs, if multiple customers have the same problem.
*   PTF: An actual fix

 

Now y’all are talking about “APAR fixes”, which I’ve never heard of. And I know 
there’s more to APARs than I wrote, just can’t remember it. Having worked for 
vendors for the last 37 years means I’ve been out of the normal flow of such 
things, too—when I was at UofWaterloo, we had a backlog of a couple of hundred 
things that we’d fixed in IBM code; we had an agreement with our PSR—the sort 
of “level 1 ½” that customers have [had, then, anyway] that we’d only have 5 
open at once. That was always fun: call IBM, “I want to open five problems.” 
“FIVE PROBLEMS???!” “Well, I have a couple of hundred, but I’m only opening 
five today.” “Oh, ok.”

 

ISTR that if a problem appears in multiple supported releases, one APAR might 
result in multiple PTFs, one per release.

 

I’m also interested in a definitive list of APAR closings. I’ve never seen one, 
and the lists I’ve seen have been conflicting and often included different 
interpretations of the same closing.

 

None of this matters a ton, of course, but it *works* when done right, which is 
more than I can say for many customer problem workflows!

 

I don’t see this as particularly sensitive info, but perhaps IBM will disagree, 
in which case I’ll STFU.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IBM APAR Names

[Paul Gilmartin]

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.
>
 Mind the distinction between "APAR" and "APAR Fix".
APARs are routinely created; APAR Fixes are not.


>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 AH went to 
>PHx, 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.".)

-- 
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IBM APAR Names

[Jon Perryman]

On Fri, 3 Nov 2023 19:44:32 +0100, Radoslaw Skorupka  
wrote:
>>W dniu 03.11.2023 o 17:32, Shaffer, Terri pisze:ry
>> Can anyone give me the secret decoder
>> I know AHx went to PHx

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.
3. Unlike PTF's, most vendors use the same APAR number tailoring the APAR fix 
specific to each customer that needs it. For example, problem spans multiple 
versions of the product or maybe tailored specific to the customers 
environment. In contrast, a PTF is specific to a release and is the same for 
all customers using that release.
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. 
5. Choosing an APAR number is completely flexible. The only requirement is to 
avoid SMP/e collisions. The same APAR number cannot occur multiple times in an 
SMP/e zone (global, target or dist).
6. The APAR number choice has no real significance except how a product has 
chosen to avoid SMP/e collisions. For instance, you say AH went to PHx, 
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. 

>> But what do I search for CA and EA  APARs?
>
>IMHO there is no consistent rule, although majority conform the habit.

What are you "searching for"? In general, APAR numbering schemes does not have 
anything to do with a search. Either you have a specific APAR number or you are 
searching for an APAR number. In the past, APAR numbering had no meaning except 
for internal use. 

In the past, CA and EA would have been non-IBM APARs. Only the company 
producing these apars can tell you what they mean. For instance, a company 
could choose to use CA apars for multiple products.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IBM APAR Names

[Radoslaw Skorupka]

W dniu 03.11.2023 o 17:32, Shaffer, Terri pisze:

Hi,
   So I should know this but apparently I missed the memo along the way, Can 
anyone give me the secret decoder

I know AHx went to PHx

But what do I search for CA and EA  APARs?


IMHO there is no consistent rule, although majority conform the habit. 
However... what's you goal? I guess it is not the rule or secret table 
itself. You know the apar ID and you want to check you SMP/E. In that 
case things can be simpler. First - check APAR description in IBM 
internet portal. You will see PTF which is cure for the problem (apar). 
Then check you SMP/E database against the PTF. In theory you could have 
APAR fix implemented, but this is rare IMHO and the delivery is 
different - fixes are not available in Shopzseries and are not delivered 
as a part of ServerPac or CBPDO. Of course you can quickly start from 
checking Aan when reading about Oan. HTH


--
Radoslaw Skorupka
Lodz, Poland

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IBM APAR Names

[Keith Gooding]

Should be OAx. I missed the memo too.

> On 3 Nov 2023, at 16:33, Shaffer, Terri 
> <017d5f778222-dmarc-requ...@listserv.ua.edu> wrote:
> 
> Hi,
>  So I should know this but apparently I missed the memo along the way, Can 
> anyone give me the secret decoder
> 
> I know AHx went to PHx
> 
> But what do I search for CA and EA  APARs?
> 
> 
> 
> [https://go.aciworldwide.com/rs/030-ROK-804/images/aci-footer.jpg] 
> 
> This email message and any attachments may contain confidential, proprietary 
> or non-public information. The information is intended solely for the 
> designated recipient(s). If an addressing or transmission error has 
> misdirected this email, please notify the sender immediately and destroy this 
> email. Any review, dissemination, use or reliance upon this information by 
> unintended recipients is prohibited. Any opinions expressed in this email are 
> those of the author personally.
> 
> --
> 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

IBM APAR Names

[Shaffer, Terri]

Hi,
  So I should know this but apparently I missed the memo along the way, Can 
anyone give me the secret decoder

I know AHx went to PHx

But what do I search for CA and EA  APARs?



 [https://go.aciworldwide.com/rs/030-ROK-804/images/aci-footer.jpg] 

This email message and any attachments may contain confidential, proprietary or 
non-public information. The information is intended solely for the designated 
recipient(s). If an addressing or transmission error has misdirected this 
email, please notify the sender immediately and destroy this email. Any review, 
dissemination, use or reliance upon this information by unintended recipients 
is prohibited. Any opinions expressed in this email are those of the author 
personally.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN