On 13-Feb-2014 14:39 -0800, Mark S Waterbury wrote:
If you save and restore a *FILE to a different library, then the
File Level IDentifier will likely change, but this is not used for
"Level Checks" -- for that, the system uses the Record Format Level
Identifier. If you change anything that would change the record
layout (format), then the record format Level IDentifier will likely
be changed. <<SNIP>>
The file level identifier should never change for save\restore. The
object that is restored is considered to be the /same object/ that was
saved. The primary purpose of save being to enable the restore for
[disaster] recovery, with an immediately secondary purpose to restore
the data to a prior image [typically in preparation for applying
journaled changes]. The design of the database with save\restore and
journal support is dependent on that effect.
A database file created with CRTDUPOBJ was always considered to be a
_new_ *FILE object as an effective copy of the original, but created
anew by the user invoking the request; i.e. a different file. A new
owner, a new created-by, and a new file level identifier. As of v6r1 an
enhancement allows creating the duplicate database file with the same
level identifiers as the FROMOBJ using the Duplicate File Identifiers
(FILEID) specification set to *YES; defaulting to *NO for consistency
with the past effects.
The database restore is implemented as a create and then load of the
data into\overlaying the dataspace(s) [similarly dataspace indexes] that
were created. The File Level Identifier serves as a level-checking
feature, as a comparison between the level identifier on the existing
object and the object on media, for database restore. Instead of an
override for LVLCHK(*NO) for a record format on open, the restore
externalizes a similar level-checking override effect with the Allow
Object Differences (ALWOBJDIF) specification, allowing for the special
value *FILELVL to effect ignore of the mismatch\level-check condition
and allowing the special value *ALL to protect the data in the existing
file by renaming the object on disk before creating the object from the
media.
Given a file is saved and then restored as a different object, a
level-check *should not occur* when the same file is saved again and
then is restored-over again over that same target; i.e. they are
considered "the same" file with respect to restore due to both having
the same file level identifier, regardless they are two distinct
objects. Given a file was duplicated with CRTDUPOBJ as a new file
object, a level-check *should occur* when the FROMOBJ is saved and then
is restored-over the duplicate; i.e. they were considered "different
files" due to their file level identifiers being different. With the
FILEID(*YES), the duplicate can appear effective as if restored; albeit
with possible requirements for ALWOBJDIF(*OWNER) for the aforementioned
restore scenario. And while the level identifiers as effective
timestamps exclude portions of a second, a difference between files is
still typical, but easily enough can be contrived\manipulated to be
identical, or naturally\legitimately be identical; of course the
FILEID() is since one of those contrived means. As with record format
level identifiers, the onus is on the creator to ensure the level
identifiers are different, whenever the protection provided by the
level-checking using these values is pertinent to their operations.
The member level identifier acts effectively identical to the file
level identifier. The *FILELVL [and *ALL] special value for ALWOBJDIF
applies to both level identifiers; i.e. no granularity between members
and files, for the ability to override the level checking for restore.
The FILEID() parameter similarly allows no granularity between member
and file identifiers.
FWiW: Just as the OS can depend on these exposed\externalized level
identifiers, any user applications can do the same. The Record Format
Level Identifier could be used separate from Open as well. That there
is an apparent consistency via the Common Data Management for Open to
effect a CPF4131 for a record format level mismatch, whereas there is no
similar constancy for how the other level identifiers are notified in
level checking, is not an indication that they are not all providing a
level-check. Besides, the level checking for RcdFmt LvlIDs is way more
than just open; at least all of restore, copy, and query features
utilize the RcdFmt LvlId, and the Query/400 uses QRY1058 rather than
CPF4131 to diagnose its level checking on a record format.
midrange.com
