On 28-Jan-2016 07:11 -0700, Joe Pluta wrote:
Okay, this is a new one for me. I'm restoring a library from a save
file to a different library name. Lots of logicals and physicals and
getting the messages I expect, except a few files (like three out of
3000) give me this:
CPF7005: Object type *FILE known by another name.
msgCPF7005 F/QJOGENJD T/QDBCRTFI TM/QDBCRTFI TP/ASSIGN_JID
The detailed message goes on to tell me that the object MYFILE in
NEWLIB was previously named MYFILE in OLDLIB. Well, yes, I know that.
Thank you for letting me know, but why does it only tell me about a
few of the files? What is different about these files?
The other files apparently were not both still registered to the
journal and saved-as-journaled for which the file would be
created-as-journaled upon restore.?
I look more carefully at the message and it seems to be related to
journaling, going so far as to say, "If the object is not an
integrated file system object then information in the journal
indicates that object MYFILE in library NEWLIB member *N type *FILE
was previously named object MYFILE in library OLDLIB member *N type
*FILE or had file ID X'00000000000000000000000000000000'."
Perhaps more appropriately: "If the object is not a stream file,
then information in the journal indicates that the object MYFILE in
library NEWLIB of object type *FILE with member *N was previously named
object MYFILE in library OLDLIB member *N type *FILE. Otherwise the
information in the journal indicates that the stream file had file ID
X'00000000000000000000000000000000'."
It goes on to say, "An object with this previous name is either not
currently on the system or is not currently being journaled to the
journal. Journaling was started for object MYFILE in library NEWLIB
member *N type *FILE or for object *N with file ID
X'00000000000000000000000000000000'. If *N or hex zero appears for
any fields, then this information does not apply."
Okay, upon re-reading that section it looks like it doesn't apply.
Where "it" refers only to the /fields/ [object, member, library,
object type, file ID] having those symbolic non-values vs actual values.
Thus the *FILE object type, the file name, and the library names, all
are applicable; whereas of the IFS file ID [as hex zeroes], the IFS file
name [as *N], and the member name [as *N], none are applicable.
And a quick check shows that the new file is indeed not being
journaled
That effect contradicts the messaging. How was the condition of
"journaled" verified for MYFILE in NEWLIB; i.e. how\what was the "quick
check" performed? Display File Description (DSPFD), or Display Object
Description (DSPOBJD), or Work With Journal Attributes (WRKJRNA) +
F19=Display Journaled Objects + 1=Files, or a combination?
(nor, at this point, is the old file and while theoretically it may
have been at the time the library was saved, that's very unlikely -
but not impossible).
Best I recall, the logged condition implies that was the case; that
the file MYFILE was journaled when saved from OLDLIB. No matter, as the
information about the old file was still stored in the journal with a
unique identifier. Yet that same identifier was stored with the file
saved on the media. When the file gets created [for restore] with that
same identifier, thus resulting in the conflict being noted, that the
identifier either must be a duplicate or is for a differently named
[different library] object that no longer is journaled; AFaIK, the
condition would only be detected because the file on media was also
identified as /journaled/ and thus implicit journaling to that same
journal upon create-file processing should occur.
Had the old file both remained and remained journaled, then the
conflict would have been diagnosed as an Information message CPF70CB
rather than the Diagnostic condition CPF7005; the file with the new name
would have been restored, and implicitly journaled, but with a new
Journal Identifier (JID). The effect in the past for that same conflict
could have been to have restored the file yet failing to journal the
file, I do not recall. I am unsure the rationale for choice of Diag vs
Info on the messaging.
So I return to my original query: what does this mean?
FWiW, the following CLP source gives effective re-create script:
dcl &jrnlib *char 10 jrnlib /* or use OLDLIB vs JRNLIB */
dcl &oldlib *char 10 oldlib /* or another name; see &JRNLIB */
dcl &newlib *char 10 newlib /* must be *NE &OLDLIB */
/* Warning! this pgm clears QTEMP/SAVF */
monmsg (cpf2111 cpf7302 cpf7010)
crtlib &jrnlib /* or use oldlib vs jrnlib */
crtjrnrcv &jrnlib/jrnrcv0001
crtjrn &jrnlib/jrnobj &jrnlib/jrnrcv0001
crtlib &oldlib
crtpf &oldlib/myfile mbr(*none) rcdlen(10)
strjrnpf &oldlib/myfile &jrnlib/jrnobj
crtsavf qtemp/savf
clrsavf qtemp/savf
savobj myfile &oldlib *savf *file savf(qtemp/savf) updhst(*no)
/* remove next line to see msg CPF70CB instead of msg CPF7005 */
endjrnpf &oldlib/myfile
rstobj myfile &oldlib *savf *file savf(qtemp/savf) rstlib(&newlib)
dspjoblog /* review the messages from the Restore Object rqs */
dspobjd &oldlib/myfile *file *full
dspfd &oldlib/myfile
dspobjd &newlib/myfile *file *full
dspfd &newlib/myfile
wrkjrna &jrnlib/jrnobj /* f19, then 1=Files */
dltf &newlib/myfile
dltf &oldlib/myfile
dltjrn &jrnlib/jrnobj
dltjrnrcv &jrnlib/jrnrcv0001 dltopt(*igninqmsg)
The message CPF7005 warns that the Journal Identifier (JID) for the
file was already present in the existing journal, and while the conflict
was insufficient to cause the request to fail, the condition is reported
as a /Diagnostic/ message to denote the possible concern for an
undesirable effect [such that perhaps the intention was that the file
should have had journaling ended, before the file had been saved].
midrange.com
