On Fri, 2008-10-03 at 07:40 -0400, Peter Relson wrote: > While each case may have to be evaluated separately,in Poughkeepsie at > least, it is typically not the case that the ++APAR is a temporary fix. > That might be more likely for a sev 1 APAR than an other, since it's even > more important then to get the customer temporary relief from the problem > being encountered. But in most cases in the areas in which I work, the > ++APAR is the intended final fix.
Speaking from a (customer) support perspective, APARs are not routinely applied. If I raise an issue and an APAR is offered as a resolution, I will make every effort to install and test it. In production if the impact is sufficiently pervasive. However, I have never considered them a "final fix" - even if the final resolution is programatically identical, I expect a PTF that SUPs any and all APARs that may have been cut. Some ISVs (one in particular) have poisoned this particular well - offering a large proportion of (almost all) fixes as APARs; many as ZAPs. I find customers are, unsurprisingly, very "gun-shy" of APARs on running systems. Shane ... ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
