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.