On Fri, 3 Nov 2023 20:51:44 -0400, Phil Smith III <[email protected]> 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 [email protected] with the message: INFO IBM-MAIN
