×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
On 07-Feb-2015 07:54 -0600, Smith, Mike wrote:
I'm trying to display a journal receiver, but not having any luck.
Journal OCJRN
Currently attached Receiver is JR10555
I restored a journal receiver from Tuesday night receiver JR10554.
Status shows partial.
Receivers on tapes for Wed, Thurs, Fri all say JR10555
When I try to display journal I've tried the following:
DSPJRN JRN(Prodfile/OCCISJRN) FILE((UFXD)) RCVRNG(*CURAVLCHN)
DSPJRN JRN(Prodfile/OCCISJRN) FILE((UFXD)) RCVRNG(*CURchain)
The above 2 show entries from JR10555, but not JR10554
DSPJRN JRN(Prodfile/OCCISJRN) FILE((UFXD))
RCVRNG(Prodfile/CISJR10554)
Gives me CPF7053 reason code 2.
Is there a way for me to view receiver JR10554?
To rid of the partial condition, Delete Journal Receiver (DLTJRNRCV)
the partial *JRNRCV named CISJR10554 [shortened\obfuscated apparently as
just JR10554] and then restore a copy of that same receiver from save
media whence the save was taken of the _detached_ receiver vs the save
of the attached receiver; restore from a save where the msg CPF7080
"Receiver &1 in &2 saved while attached." was *not* logged to warn in
the Cause-text that the "Journal receiver &1 in library &2 was saved
while it was attached to the journal. However, this saved copy of
journal receiver &1 is not complete because journal entries continue to
be placed in the receiver after it is saved. To restore a complete
version of journal receiver &1, it should be saved again after it is
detached from the journal."
IIRC the corresponding msg CPF7040 "Journal receiver &1 in &2 is
partial receiver." would have transpired on the restore, warning in the
Cause-text that the "journal receiver was restored on the system from a
version that was saved while the receiver was attached to the journal.
The version on the system may be missing journal entries. If the
operation is to apply journaled changes (APYJRNCHG command), this
receiver can be used only if it is the ending receiver specified for the
receiver range (RCVRNG parameter)."
That message implies then, that the logged entries may be available
[to the DSPJRN request] by having requested instead [of what failed with
the msg CPF7053 RC2], the following revised DSPJRN request:
DSPJRN JRN(Prodfile/OCCISJRN) FILE((UFXD))
RCVRNG(PRODFILE/CISJR10554 PRODFILE/CISJR10554)
I suppose that should be consistent with what the RC2 of msg CPF7053
alludes by noting as one possibly, that "the ending receiver was
encountered on the receiver chain and it is not the same as the ending
receiver that was specified". Albeit the Recovery-text suggesting to
"use the Work With Journal Attributes (WRKJRNA) command to identify the
correct values for the receiver range" is not so conspicuous in helping
to identify what might be _correct_ in that situation :-(
midrange.com
