Re: Format Level ID

On 31-Jan-2012 15:13 , Charles Wilt wrote:

A file's "Format Level Identifier" is generated from
Record format name Column _System_ Name, type, position, size, CCSID
and possibly Date format and probably a couple more I'm forgetting
:)

Or including\mis-remembering attributes that do not actually impact the generated RcdFmt level identifier [a hash produced by QDBLVLID for a database file record format] :-) So instead... A doc reference which describes most of what is and what is not included in the hash:
http://publib.boulder.ibm.com/infocenter/iseries/v7r1m0/topic/dbp/rbafoecffd.htm
"
The system assigns a unique level identifier for each record format when the file it is associated with is created. The system uses the information in the record format description to determine the level identifier. This information includes the total length of the record format, the record format name, the number and order of fields defined, the data type, the size of the fields, the field names, the number of decimal positions in the field, and whether the field allows the null value. Changes to this information in a record format cause the level identifier to change.

The following DDS information has no effect on the level identifier and, therefore, can be changed without recompiling the program that uses the file:

* TEXT keyword
* COLHDG keyword
* CHECK keyword
* EDTCDE keyword
* EDTWRD keyword
* REF keyword
* REFFLD keyword
* CMP, RANGE, and VALUES keywords
* TRNTBL keyword
* REFSHIFT keyword
* DFT keyword
* CCSID keyword
* Join specifications and join keywords
* Key fields
* Access path keywords
* Select/omit fields

Keep in mind that even though changing key fields or select/omit fields does not cause a level check, the change might cause unexpected results in programs using the new access path. For example, changing the key field from the customer number to the customer name changes the order in which the records are retrieved, and might cause unexpected problems in the programs processing the file.

...
"

Somewhat overstated is the "uniqueness" of the hash. The documentation fails to clearly state that the onus is on the creator of the file to ensure that a changed RcdFmt does indeed have a different RcdFmtLvlId if the change is consequential to any applications that depend on Level Checking.

Regards, Chuck