On 13-Feb-2014 13:32 -0800, Jim Wiant wrote:
DSPFD, and near the bottom:

Record Format Level
Format Fields Length Identifier
XXXXXXX 16 169 38E9B2B3E4B71 <---

My understanding is that if anything changes in the record layout,
this will get a different identifier. I read somewhere how it's
determined but I don't have that reference anymore.

IBM i 7.1 Information Center > Database > Programming > Database programming > Managing database files > Changing database file descriptions and attributes
_Effects of changing fields in a file description_
"The system uses the information in the record format description to determine the level identifier. Changes to the fields in a file description <ed: may> cause the <ed: Record Format> level identifier to change. ..."

This btw is the value that causes level checks in programs because
the program object stores the file record identifier values when
compiled. Changing the *file* identifier (e.g. CPYF will do that)
doesn't bother the program, but the record level identifier does.

The record format level identifier is a hash. Even if whatever attributes that are hashed are changed, the hash always has the potential to be the same as before those changes. The mechanism is merely a fast-path for exclusion, to determine if a change has occurred. The identifier can not be used to determine if there is a match, because equivalence in the hash merely implies that a deeper inspection [e.g. at the field-level] is required for any measurement of compatibility or equality.

The onus is on the programmer [the creator of the RcdFmt of the object] to ensure that the changed record format [i.e. modifications to the source] effects a new\different level identifier. To ensure the fast-path is operative [for exclusion], requires that the hash from one iteration to the next is different.

Any feature depending solely on the hash to detect differences might incorrectly also infer that the unchanged hash indicates an unchanged record format; i.e. [improperly, or as documented as an effective restriction] has used the hash to detect the capability for the application to infer equivalence\inclusion rather than only for inferring difference\exclusion. The OS database restore feature depends on the comparison for inclusion, and defers to the LIC database load feature to perform the deeper inspection; due to the more negative effects of the latter detecting the differene versus the former, ensuring a difference in the RcdFmtLvlId is reflected with database file source changes that change the actual format is encouraged.

The Copy File (CPYF) utility documents its restriction for dependence on an inclusive vs purely exclusive test:
_Checking record format level identifiers_
Record format level identifiers of the two files should be different if the files have different attributes. If they are not different, field and column-level checking does not perform, resulting in improper data conversions or none at all.

This thread ...


Return to Archive home page | Return to MIDRANGE.COM home page