Re: Stranded journal receiver: QRECOVERY/QSQJRN0001 from V6R1M0 install

On 30-May-2010 23:02, PaultinNZ wrote:

The WRKJRNRCV QRECOVERY/QSQJRN0001 and display attributes shows:

Display Journal Receiver Attributes
Receiver . . . : QSQJRN0001 Library . . . : QRECOVERY
Journal . . . : *NONE Library . . . :
Threshold (K) . . : 100000 Size (K) . : 28
Attach date . : 00/00/00
<<SNIP never attached details>>

As far as I can see from the above, not much important has been
set on the receiver.

"WRKJRNA JRN(QSYS2/QSQJRN)" shows the current Receiver as
QSQRRN0248 in Lib QRECOVERY.

As mentioned an inhouse monitor had picked up the state of the
journal andissued the following warning:
AS/400 system id: S6575D1C has a *stale *journal receiver:
QRECOVERY/QSQJRN0001
This could stop system journaling from working!
Please contact AS/400 support person with these details.

The QSQJRN0001 was created in the middle of systems installation.
Created by user . . : QLPINSTALL
I also see the following:
Journaling information:
Currently journaled . . . . : NO

So the question is, "Do I need to worry about this receive
journal?"

Maybe I'll place a call with IBM?


On 28 May 2010 17:43, CRPence wrote:

On 27-May-2010 22:18, PaultinNZ wrote:

We upgraded our i5 to V6R1M0 on Saturday and Sunday 15/16 May.
After the install we see that we have a ‘stranded/stale’ journal
receiver QSQJRN0001 in library QRECOVERY.

DSPOBJD *FULL detail:
Object . : QSQJRN0001 Attribute . . . :
Library . : QRECOVERY Owner . : QSYS
Library ASP device: *SYSBAS Library ASP group: *SYSBAS
Type : *JRNRCV Primary group . . . : *NONE
User-defined information:
Attribute . . . . :
Text . . :
Creation information:
Creation date/time . : 15/05/10 19:06:04
Created by user . . : QLPINSTALL
System created on . : S6575D1C
Object domain . . . : *SYSTEM

Does anyone have any idea why this is hanging around and can we
safely delete it?

From what was the conclusion drawn, that the journal receiver
is "stranded\stale"? If you are mistakenly looking at library
QRECOVERY thinking you are looking at library QRCL, see:
http://archive.midrange.com/midrange-l/200803/msg01307.html

FWiW, the DSPOBJD is not a proper interface to review the
status of a journal receiver; i.e. for possible relationship to
an active journal object. Use instead: WRKJRNRCV
QRECOVERY/QSQJRN0001

The Work with Journal Receiver will presumably will show the
receiver is active to the journal QSYS2/QSQJRN; WRKJRNA
QSYS2/QSQJRN then F17=Receiver-Chain should show the receiver
in QRECOVERY. The library QRECOVERY is used for that journal
receiver object because that library is never backed up;
reconfigure the journal environment to associate the journal to
a receiver in another library, if desired to have the receiver
for QSYS2/QSQJRN to be part of regular backup activity.

Seems probable that someone customized the journal environment to use QSQRRN#### in Lib QRECOVERY; poor choice if so, since Q* naming is reserved for the OS. DSPOBJD QRECOVERY/QSQRRN0248 *FULL [or the current receiver associated with *JRN QSYS2/QSQJRN] should show the creator of the first QSQRRN#### of a system managed chain, or the creator of the current QSQRRN#### of a user managed chain.

The install of the OPTION(01) Extended Base support of the OS I believe will CRTJRNRCV QRECOVERY/QSQJRN0001; as described, having been created by QLPINSTALL [for a batch\auto install]. The install will then issue CRTJRN QSYS2/QSQJRN JRNRCV(QRECOVERY/QSQJRN0001). I have a foggy memory for my rewrite of the install-exit [QSQEXIT1] code for that option, and IIRC those two CRTJRN* actions were conditioned on the missing QSQJRN *JRN object in QSYS2; perhaps only after DLTJRN QSYS2/QSQJRN and DLTJRNRCV QRECOVERY/QSQJRN*.?

The install-exit should probably not be creating the receiver if it can not [re]create the journal attached to that receiver or does not then effect CHGJRN to use that receiver; i.e. ask IBM why the receiver was created but not attached.

Since the journal [receiver] environment is already customized for the QSYS2/QSQJRN, the recovery would be to just delete the so-called /stranded/ receiver. However I would recommend that the custom environment use other than reserved system-naming, and if not established in a user library, then probably best to just leave the environment intended to be established by an install; i.e. that the install would effect QSQJRN0001 in QRECOVERY the first journal receiver for the system-managed journal QSQJRN in QSYS2.

Regards, Chuck