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.

This thread ...


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