× 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 :-(


As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.