× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



On 05 Feb 2013 04:39, rob@xxxxxxxxx wrote:
http://www.ibm.com/support/docview.wss?uid=nas2d84567de3459d20a862579f3003c9ab4
(ps: What is V9R9M9 at this link?)

I believe it is safe to just ignore the V9R9M9 value. However if submitting a comment about that specific example, that the issue is probably more pervasive should probably be pointed out; i.e. unlikely this is specific to that APAR, although maybe specific to those APARs with a UR1 closing code. FWiW...

Surely that value side effect of the APAR tooling within IBM. SWAG: v9r9m9 had been used to indicate the release in which an APAR will have a fix provided in the base release, when initially [or later decided] there is no [longer a] commitment to provide a fix via a PTF; probably a required field [for tracking of commitments], but rendered almost meaningless with that effectively bogus value [of "if\when we get time for that"]. When a fix is provided there is a legitimate fixed-in release value for which all prior releases would appear as either having a PTF or not. As a bogus release value, that v9r9m9 may not be getting properly scrubbed from the APAR when the information is copied from the internal APAR tracking into the externally visible APAR documents. Or the value is meant to show that the fix is [implicitly or explicitly] in the base release of the next but as-yet unannounced release, and that release might appear as this value v9r9m9 to avoid divulging unannounced release information.

FWiW here is an old example of an APAR SE25338 which was initially reported against v5r1 and initially answered as UR1 [fixed in a future release]. This very old APAR has the same v9r9m9 value. Eventually a v5r2 and v5r3 PTF were provided with that APAR even though the UR1 closing code does not require any PTFs, and its target fixed-in release may be set to v9r9m9 either because that bogus value was not purged in copying between internal APAR tracking to the publicly available APAR, or the release into which its fix was included in a base release was not announced at the time. For the latter case one might expect that post-announce a utility would run to update any v9r9m9 values to the proper value according to the release in which the code changes for the APAR were claimed to have been included. Until purged that APAR is the Doc reference# 86257156003CA​08A found at:
http://www.ibm.com/support/docview.wss?uid=nas23cf2275b7b6a234b86257156003ca08a


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.