On 24-Apr-2015 12:04 -0500, Jerry Draper wrote:
We have a journal receiver maintenance routine that deletes journal
receivers that have been saved and are older than nn days.
This has been working fine on V5R4 but on V6R1 and V7R1 we have a
new issue. (I don't have a V5R4 machine to prove this however.)
The CL pgm creates a work file:
DSPOBJD OBJ(&LIB/*ALL) OBJTYPE(*JRNRCV) DETAIL(*FULL)
OUTPUT(*OUTFILE) OUTFILE(wrklib/JRNRCVPF)
It then reads this file and checks to see if the journal receiver
has been saved:
IF COND(&ODSDAT *EQ ' ') THEN(GOTO CMDLBL(LOOP))
So the above basically suggests, if unsaved then skip the object
named (&ODLBNM/&ODOBNM).
&ODSDAT is the date the journal receiver was saved.
That field is populated with the date the SAVxxx operation took
place, *if* the Update History (UPDHST) had been requested [i.e.
UPDHST(*YES)] on that particular SAVLIB [, SAVOBJ, or whatever was the
equivalent invocation].
If it is not blank then the routine deletes the journal receiver:
DLTJRNRCV JRNRCV(&ODLBNM/&ODOBNM)
For some reason when &ODSDAT is NOT BLANK we get this error:
Message ID CPA7025: Receiver xxxx in yyyy never fully saved. (I C)
An attempt was made to delete a receiver that was never fully saved
after the receiver was detached with a CHGJRN command.
The key is [as Glenn alludes and a followup reveals additionally
other origins] that the Journal Receiver (JRNRCV) was not _fully saved_
despite the object was /saved/.
Anyone know what field in the *OUTFILE is getting checked for this
message?
The journal save feature, the underlying component-specific save
processing performed for the save feature [and similarly with the
restore feature], specific to the complex object types for which the
component as /object owner/ performs actions that are not generically
effected by SAVxxx itself, does not look any of the generic object
description details to decide if the msg CPA7025 should be issued.
Effectively what transpires, though not in actual implementation, the
journal-save feature interrogates the last three journal entries
deposited to the journal receiver, to determine if they are the expected
J-NR, J-PR, and J-RS entries; i.e. for the Display Journal (DSPJRN) of
the specific journal to which that receiver had been originally
attached, displayed for the Range Of Journal Receivers (RCVRNG) of that
one receiver, as an indication that the JrnRcv has been fully saved, the
last three entries would tend to be:
Code: J - Journal or receiver operation
• Type: NR - Next journal receivers
• Type: PR - Previous journal receivers
• Type: RS - Journal receiver saved
More accurately, the journal-save feature tags a detached receiver as
fully saved if\when the journal receiver was saved any time *after* that
receiver had been previously detached, and the delete-journal-receiver
feature asks if the receiver is both detached and since-saved, and if
the issuance of the inquiry is not overridden [via the Delete Option
(DLTOPT) of *IGNINQMSG] on the Delete Journal Receiver (DLTJRNRCV)
request, then the feature inquires whether deletion of the receiver
might possibly be unintended whenever the JrnRcv was not previously
/fully saved/.
Note: the lack of the visible manifestation of the inquiry, in my
experience, is often the result of either the Inquiry Message Reply
Handling (INQMSGRPY) established for the job, and possibly additionally
either the Default Reply Value (DFT) established for the Message
Description for the Message Identifier (MSGID) of CPA7025 *or* the
Message Reply (RPY) defined for the Reply List Entry established for
that MsgID. If the system change management failed to establish the
same setup from a prior release, the effect may have been the noted
difference.
midrange.com
