On Fri, 3 Oct 2008 07:40:57 -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.
>
Ummmm ...
Linkname: APAR Fixes
URL:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/GIMPKG80/4.1.3
4.1.3 "z/OS Packaging Rules"
__________________________________________________________________________________
4.1.3 APAR Fixes
...
Following are some characteristics of APAR fixes:
* Announcement - APAR fixes are not announced.
* Licensing - APAR fixes are not individually licensed. If an APAR fix is
applicable
to a licensed function, it is covered by the license agreement for that
function.
* Ordering - APAR fixes are neither ordered nor formally distributed.
* Documentation - APAR fixes have no associated documentation other than
comments
that may be included on RETAIN or with an APAR fix package.
Note: APAR fixes are included in a subsequent PTF.
"Neither ordered nor formally distributed" doesn't strike me as an
"intended final fix".
-- gil
----------------------------------------------------------------------
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
