Re: Looking for Ideas For Processing CSV

[CRPence <CRPbottle@xxxxxxxxx>]

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