On Sat, 4 Nov 2023 07:19:49 -0500, Bruce Hewson <bruce_hew...@hotmail.com> wrote:
>APARs for me are OAxxxxx or PHxxxxx - 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 AAxxxxx, BAxxxxx etc for each new iteration of a fix for >APAR OAxxxxx. 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 OAxxxxx >you can see one or more iterations of the ++APARs. > >The eventual PTF will SUPERCEDE all ++APARs that had been built during testing >of the fix for the APAR problem. > >When searching, say via Google, use the APAR number only, e.g. OAxxxxx > >This is how I was introduced to ++APAR naming conventions. 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
