×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
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.
..."
midrange.com
