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

[Radoslaw Skorupka]

~10+ years ago I would give you three FEPs for free.
However they went to junk.
AFAIK they were model 170.

--
Radoslaw Skorupka
Lodz, Poland



W dniu 05.11.2023 o 00:22, Ben Huntsman pisze:

Hi guys-
I apologize for the off the wall request.  Not sure this is the best place 
to start but it's somewhere.

Does anyone out there have an old 3745 model 130, 150, or 170 that's not in 
use that they'd be willing to sell at a reasonable price?  I know they're 
awfully rare these days.

Thank you so much, and again sorry for the extra noise.

-Ben


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

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

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

3745

[Ben Huntsman]

Hi guys-
   I apologize for the off the wall request.  Not sure this is the best place 
to start but it's somewhere.

   Does anyone out there have an old 3745 model 130, 150, or 170 that's not in 
use that they'd be willing to sell at a reasonable price?  I know they're 
awfully rare these days.

   Thank you so much, and again sorry for the extra noise.

-Ben


--
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: AMODE was: Why do all entry points have to be in the same class?

[Ed Jaffe]

On 10/23/2023 10:52 PM, John Dravnieks wrote:

And the binder has support to create  program objects with two code sections in 
different RMODEs  -  take a look at RMODE(SPLIT) and RMODEX.
If your code sections are RMODE24 and RMODE31, you should also take a look at 
the binder HOBSET option - this will set the high order bit of each V-type 
address according to the AMODE of the called entry point.  This then makes it 
easy to switch to and from different sections using BASSM and BSM


I created a requirement years ago for HOBSET to set the low-order bit 
for 64-bit EPAs (which these days are quite common).


They didn't want to do that, so then I asked for a LOBSET option. Never 
got that either... :-(


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

[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