Re: 6.1 Create Index - Format Level Identifier

For the Archives.

I ended up opening up a PMR for this, as I was able to reproduce it by adding a RCDFMT clause to a CREATE INDEX that matched the TABLE RCDFMT (and therefore is the same RCDFMT that was being used when the RCDFMT clause was not used on the CREATE INDEX), AND get a different Record Format Level Identifier (that was a big clue as to it being a problem).

An Apar has been raised, and a fix is in the works. As soon as I get the info for the Apar, I will add another post to the list for future reference.

Chuck, thanks for the details, it certainly helped as I went through the PMR process.

Crispin.


----- Original Message ----- From: "CRPence" <CRPbottle@xxxxxxxxx>
Newsgroups: midrange.midrange-l
To: <midrange-l@xxxxxxxxxxxx>
Sent: Wednesday, June 09, 2010 8:16 PM
Subject: Re: 6.1 Create Index - Format Level Identifier

On 09-Jun-2010 18:08, Crispin wrote:

<<SNIP>>

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

From the described, though without actual sources, I would infer
there is probably a defect versus a usage problem.

In prior releases there was no possibility for the SQL INDEX to
have anything other than a shared record format; i.e. the record
format for an SQL INDEX always would be defined as a redirection to
the PF over which it was created. Having excluded the SQL INDEX
from any corrective actions on the Level Identifier for that type of
database *FILE would not have been an issue.

It is possible that the QDBCRTFI changes in prior releases to
/correct/ the specific condition for the improper inclusion of the
DATE, TIME, and TIMESTAMP separator in the calculation of the
FmtLvlID hash, accidentally excludes the SQL INDEX file attribute
even after the enhancement to describe a new record format for the
INDEX with the RCDFMT clause. That supposes the various QSQCRTxx
interfaces also were never updated to specify the /correct/ [i.e.
consistent with the DDS] separator definition for those data
types... although perhaps memory does not serve me correctly, and it
was the DDS which had the defect but the SQL was changed to match
because SQL does not care about the RcdFmtLvlID.

Regards, Chuck
--