Re: format level different with dds/SQL

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>>