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.
midrange.com
