Re: format level different with dds/SQL

[CRPence <CRPbottle@xxxxxxxxx>]

  Understood.  I was just editorializing with regard to the conclusion 
of the referenced thread(s); i.e. that a private response from an IBMer 
via a PMR is not a public response from IBM, which depends on the APAR 
as the official public means of communicating responses to identified 
defects.

  When IBM closes a PMR without an APAR for an admitted defect, they 
are doing a disservice to their customers.  And although there is no 
obligation to do so, customers could insist on an APAR for an admitted 
defect, for the benefit of others; i.e. such that there would be an 
actual document to which one could point, or to direct another [such as 
their own management perhaps], what was the response from IBM to that 
defect.

  FWiW the same concerns as described were expressed in that "long 
conversation" were overcome in a prior like-incident, by changing the 
Record Format Level Identifier that is generated for the SQL object, to 
match the [incorrect value generated for the] DDS-created object.  That 
was deemed acceptable as a resolution because SQL does not know\care 
about the RcdFmt LvlId and thus will never issue a LvlChk message 
CPF4131.  That resolution however only came after escalating the issue 
*beyond* Level-2 [support\service], to Level-3 [development].  The DB2 
for i "architect" deemed that the intent of the Database was that the 
compatibility of the RcdFmtLvlId between the "same" column attributes 
[not limited by intrinsic differences betwixt, such as requirement for 
*ISO on DATE] was more important than the impacts to some existing SQL 
objects.  Anyone who experiences the issue with VARCHAR trying to match 
VARLEN could just as well try again to push the issue, esp. given there 
is no specific APAR documenting that IBM will do nothing to /correct/ 
the defect.

Regards, Chuck

On 08 Jun 2012 11:49, Anderson, Kurt wrote:
> I opened a PMR to report the issue. IBM did not fix it. As far as I
> know they didn't create an APAR. Most of the information I received
> was during a long phone conversation with an IBM customer service
> person and their manager.
>
> If they created an APAR, I likely didn't get it because the end
> result was either live with the current problem or to have IBM do
> some work to create a scenario that would have to be manually applied
> for every DDS file compile (with VARLEN fields) that would not be
> permanently supported (meaning it may no longer be available past the
> current IBM i version). I settled for working around the issue.
>
> On 08 Jun 2012 11:08, CRPence wrote:
> > For reference specific to that defect [for which an APAR number,
> > being the vehicle to communicate such information, should exist to
> > track the response from IBM; i.e. without which, there was
> > effectively no response from IBM]: <<SNIP>>