MIDRANGE dot COM Mailing List Archive



Home » MIDRANGE-L » February 2014

Re: Checking object create dates



fixed

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.

<http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/topic/dbp/rbafochgfile.htm>
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:
http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/topic/dm/rbal3identifier.htm
_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.
..."






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

This mailing list archive is Copyright 1997-2014 by MIDRANGE dot COM and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available here. If you have questions about this, please contact