Re: Journaling?

On 05-Oct-2016 12:07 -0500, CRPence wrote:

On 05-Oct-2016 07:34 -0500, Boyle, Doreen wrote:

How can I tell who changed authority on a library?

If the library had been journaled with the Start Journal Library
(STRJRNLIB) command, then the journal would have a Change Authority
(ZA) entry for the Library Operation (Y) journal code; review that
journal for a Y-ZA entry.

I forgot to mention, if the library is effectively /static/, and the issue was only recently noticed, then having ASAP taken [or possibly still valid to take] a DSPOBJD The_Lib *FULL OUTPUT(*PRINT), might be able to reveal\establish when that change took place. That is, if no objects are being created-in or deleted-from that library, such that essentially the objects are only ever being read, then the Last Change Date/Timestamp value may reveal when the GRTOBJAUT or RVKOBJAUT was actually issued; for lack of other activity that would have /changed/ the *LIB object. That timestamp, if presumed likely to be the change-request of interest, could be used to try to infer from a list of jobs starting and ending as presented in Display Log (DSPLOG) output of the History Log (QHST), which might have made the request; if joblogs are kept available, then scanning those joblogs for case-insensitive searches of 'AUT' might be helpful -- I recall a SCNJOBLOG that might be helpful in that regard, and perhaps less specifically directed could be even more useful.

With general object auditing in effect [QAUDCTL includes *AUDLVL and
QAUDLVL includes *OBJMGT, *OBJCRT, *OBJDLT],

That should have noted: QAUDLVL includes *OBJMGT, *CREATE, *DELETE

an Object Management Change (OM) entry would be logged for
non-authority change activity, but ¿may also be logged? for a Grant
or Revoke operation [although if so, may be dependent on object
type]; review QAUDJRN for T-OM entries.
The Change Of Authority (CA) entry may be logged for general object
auditing, but probably is logged only for when QAUDLVL included
Security Run-Time (*SECRUN) auditing is in effect; review for the
T-CA entries.

If the System Value (SYSVAL) [or (SVAL)] QAUDCTL had included *OBJAUD, then I expect; noting: I have no systems on which I can [err, on which my user profile is directly allowed to] validate any results, and too long since I have had, so I can only surmise or depend on recollections:

The T-CA would also be logged if the Library (LIB) object had been marked for auditing per Change Object Auditing (CHGOBJAUD), for Object Auditing Value (OBJAUD) of *CHANGE or *ALL. The Display Object Description (DSPOBJD) of the *LIB object, with the option requesting full Detail [i.e. DETAIL(*FULL)], will reveal that audit attribute; well, to a user authorized to see, else *NOTAVL shows, meaning Not Available to be viewed by the requesting user. FWiW: Although the Display Library Description (DSPLIBD) presents the Create Object Auditing (CRTOBJAUD) value, the actual auditing in effect for the library object itself is not presented there; i.e. do not confuse the two.

Or, if the User Profile (USRPRF) had been marked for the appropriate level of auditing per Change User Auditing (CHGUSRAUD) [perhaps just *SECRUN; though again, ¿some object types might show the effect of a changed authority for the *OBJMGT event?], but the Library object had been marked for the Object Auditing Value of *USRPRF. And if Command String (*CMD) User Action Auditing (AUDLVL) were active for the user requesting the change, then the change to the authority might be available in a T-CD entry.