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

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.

Regards, Chuck