RE: 6.1 Create Index - Format Level Identifier

Chuck,

The SQL TABLE PF was created on V5R4 within the last 4 weeks, and I'm pretty
sure that that PTF's were on the machine. That said, I will check tomorrow
and recreate everything from scratch.

The original SQL TABLE PF was created using the QSQGNDDL API to get the DDL
from a DDS PF. The SQL TABLE PF and the DDS PF both had the same Level Id.

The LF that I was trying to replace was a DDS LF with a new Record Format,
and all of the fields in the PF defined again (rather than having the same
Record Format as the PF). It ran QSQGNDDL against the LF, took the generated
DDL and added a RCDFMT clause, so that the SQL INDEX had the same record
format as the original DDS LF (I think this is the correct approach).

Removing the Date (DDS Field Type L) from the DDS and subsequent DDL removed
the difference in Level Identifier (and obviously any level checks that
would occur).

Given that the V5R4 PTF's dealt with TABLE and INDEX (DDL) do you think it's
possible that the RCDFMT addition at 6.1 was not taken into account?

Thanks,

Crispin.

Was the based-on SQL TABLE PF of the SQL INDEX LF created new in
this scenario, or was it created on a prior release? If the SQL
TABLE was created in the past [before the PTF was applied] but has
never been re-created from source or modified by ALTER TABLE to
effect the new\corrected FmtLvlId for the RcdFmt, then the DATE,
TIME, or TIMESTAMP field definition still reflects a RcdFmtLvlID
with the separator being incorrectly included in the hash. If so,
then the scenario would seem to be an example of a side-effect for
the fix having been implemented as "least impact" as described in my
archived post and one of the APARs which intended to provide a fix:
http://archive.midrange.com/midrange-l/200706/msg01191.html

SE22099 - OSP-DB FMTLVLID GENERATED INCORRECTLY FOR TIMESTAMP FIELD
http://www->01.ibm.com/support/docview.wss?uid=nas2ede7e016599ca1268625707e

003c87e4

The corrective actions need to be performed for any columns with
those data types, which were created prior to the corrective PTF
having been applied, as described in the informational APAR:
II14134 - RECORD FORMAT LEVEL IDENTIFIER CHANGING FOR SQL TABLES
http://www->01.ibm.com/support/docview.wss?uid=nas221529fcce2f4b07086257101

0041fe11

Regards, Chuck