MIDRANGE dot COM Mailing List Archive



Home » MIDRANGE-L » February 2014

Re: Checking object create dates



fixed

On 13-Feb-2014 15:20 -0800, Steinmetz, Paul wrote:
Steinmetz, Paul on Thursday, February 13, 2014 6:06 PM wrote:

Good point. PRTF identifiers could be the same, but the prtf have
different attributes.

I just did some tests.
1) CRTDUPOBJ of prtf creates a new file level identifier.

Correct; by default. Refer to the FILEID() parameter.

2) Restore of a prtf from a different system keeps the same file
level identifier.

Correct. Set\established for any new file. A restored file is considered _the_ file that was saved; i.e. even if restored as new into the same or a different library, the restored object is still considered to be the original... as a side effect of the intention of save\restore to implement recovery [for DR].

3) Changing the attribute of a prtf does NOT change the file level
identifier.

Correct. The file was not created anew; merely had attributes changed.

I'm not seeing a solution.

I did one more test.
Save prtf to savf
Restore object from savf to another library
File level identifiers are the same.

Maybe under the covers this is what CRTDUPOBJ should do.

An "if I ruled the world" statement ;-) Or from another perspective... If the effect of save\restore is desired and not achieved with another interface, then the obvious resolution is to use the save\restore, not to change the other interface which already has a designed\defined effect :-) Anyhow, once again, see the FILEID() parameter of the CL command CRTDUPOBJ.

Then you truly have a duplicate object, everything remains equal,
create date, created by, etc

The definition of /duplicate/ is in the "eye of" the designers, and...

The design of Create Duplicate Object was always to *create* a *new* object, effectively as a fast-path to whatever was the standard create interface. While an apparent /duplicate/ in some sense, not with regard to its creation information as a new object. The effects were also most likely geared towards reflecting what IBM wanted for its own install processing; thus why things like "Licensed program", "Object Control Level" and the "Product..." and "Component" values are maintained [although some object handlers implementing the dup function may not, due to lack of shared code to effect consistent results]. Thus the object gets a new creation date and created-by-user [and loses usage info and very appropriately also loses the save\restore info]. Until IBM i 6.1 this "new" object also was assigned a new File Level Identifier, but new support was added to carry the value [similarly member level identifiers] from the From Object (OBJ) to the New Object (NEWOBJ). As well, as noted in an earlier reply, if the object descriptive attributes as effected by the CRTDUPOBJ are not desirable, refer to the Change Object Description (QLICOBJD) API for changing some.

If the File Level Identifiers of non-database *FILE objects are not properly reflecting the chosen effect for the "Duplicate File Identifiers (FILEID)" parameter, then the object handlers were not properly updated or added, or the Librarian component is not invoking shared code to effect the update. Given the support was almost surely added solely for database files, that feature is no doubt functioning as documented for a duplicated DBF.






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