Re: CPF7005 during a restore

On 1/31/2016 7:47 PM, CRPence wrote:

On 28-Jan-2016 07:11 -0700, Joe Pluta wrote:

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?

And thus my confusion. I don't normally get confused by CPF messages, and even when I do I can usually find enough information online to alleviate that confusion. In this case, however, the section says my file is being journaled but yet DSPFD says it is not. I went back in and verified that the same holds for DSPOBJD - the file is not being journaled.

I was unable to use WRKJRNA since I have no idea what the name is of the journal that is supposedly journaling this file, since the file is not being journaled either in OLDLIB or NEWLIB. However, I did check the journal that was identified as the most recent journal for one of the files and of the three files which received the CPF7005 error, each had a different circumstance:

1. One had no entries in the CURCHAIN for that journal
2. One had a JM followed by an EJ entry, indicating journaling had been ended prior to the save and restore
3. One had a JM followed by several saves and then ultimately an MD when the file was deleted

So to recap:

1. A library was saved on one machine and restored on another.
2. That library was subsequently saved on the second machine and restored to a different name.
3. Three of the files (out of thousands) received CPF7005
4. None of the restored files are journaled
5. According to the most recent journal, none were at the time of the save

(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.

What has me stymied is the fact that the file in NEWLIB is most definitely NOT journaled.

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].

Since neither the saved file nor the restored file are currently journaled, and indeed the restored file has never been journaled, I'm still at a loss as to what this is telling me.

I may try to save and restore just one of the files that produced the message and see what happened. It should be noted that the message did not stop the file from being restored, it's simply at this point an annoyance.