Re: QUADJRN receivers have saved date and time = ZEROS

On 10-Jun-2014 13:18 -0500, Charles Wilt wrote:

Interestingly, I can't move the existing audit receivers.
Though I've moved my production receivers before.

Almost surely a false recollection. Journal and Journal Receiver objects have never had general support for move, or rename; i.e. with only one exception, the OS Journal component prevents those operations. That restriction includes the implicit prevention of renaming either, via rename of the library [kwd RNMLIB]; i.e. that request would fail with msg CPF2136 indicating that the *LIB can not be renamed because it contains one of the following object types: ... JRNRCV, JRN, ...".

CPF7014 - Object QFD1A10296 cannot be moved to library #SYSJRNRCV.
Cause . . . . . : Object QFD1A10296 in library QSYS type *JRNRCV
could not be moved to library #SYSJRNRCV, because journal objects can
be moved only to the library where they were originally created.
Object QFD1A10296 was originally created in library QSYS.

The msg CPF7014 properly diagnoses a restriction. Only a Journal or Journal Receiver that had the addressability recovered by a Reclaim Storage (RCLSTG) [or perhaps via a recovery option in WRKJRN; or perhaps Reclaim Objects by Owner (RCLOBJOWN)], due to the object being lost from its context [i.e. Library (*LIB)], is the *only* supported way to effect a Move Object (MOVOBJ) of either object type.

I notice that the receivers themselves are journaled to the QAUDJRN...
I don't recalling doing that. Is it automatic?

The effect is implicit, just like any save of a receiver that was ever previously attached to a journal is logged as a J-RS; i.e. the entry in the journal is that specific "receiver chain" entity. However I honestly do not recall what interface, other than Dump Object (DMPOBJ) command, that conspicuously divulges that effect; i.e. the receiver appears in the .JOURNALED OBJECTS- section of the dump output.