On 01-Aug-2014 09:23 -0500, Steinmetz, Paul wrote:
I just did something similar with CHGLIBL, ADDLIBLE, EDTLIBL.
I used CHGOBJAUD to turn on auditing for these commands.
And RMVLIBLE, probably also CHGSYSLIBL; i.e. all commands that appear
on GO CMDLIBL.
For reference only: the thread
"Scaning field JSLIBL from QAUDJRN outfile QASYJSJ5"; /scanning/ of
course, originally about trying to find the /used/ libraries in T-JS
audit entries. In a post in that thread
> I had
mentioned command-string audit log entries; though I had referred to
them incorrectly as T-CS rather than T-CD audit log entries.
However, note that a T-CD audit entry is of no use for the Edit
Library List (EDTLIBL) command. That command is implemented as an
interactive utility; the library name specifications do not appear on
the command-string, so the effects are not visible in a T-CD.
What is different by using:
The QIBM_QCA_RTV_COMMAND exit point can utilize both a /before/ and
an /after/ exit-program to enable obtaining a snapshot of the current
user portion of the library list and thus to determine the difference.
That could be useful for a command like EDTLIBL, for which the
command-string in a T-CD will be of no assistance to log what library
names were /used/ by the [invocation of] that command.
The QIBM_QCA_CHG_COMMAND exit point can utilize the Replace Command
Exit Program (QCARPLCM) API to direct the use of one command to another.
By redirecting the EDTLIBL command request to a command CPP that first
performs obtaining a snapshot of the current UsrLibl, then issues an
alternate version of the actual EDTLIBL feature [that is not intercepted
by the exit] thus allowing the user to effect their *LIBL changes [while
not having to design one's own Edit LibL feature], and then obtains a
new snapshot of the UsrLib, could finally with the obtained snapshots
determine and log the changes to the library list.
Note: In either use of command-string auditing or use of intercepting
the commands with registered exit points, if there exists any other
interface(s) [e.g. an API] to do the same work as the command, then
dependence solely on only the command interface for tracking [the
effects of those commands] is going to be insufficient for tracking the
effects more generally. For an example of what might be an unlikely
case but subtle enough to be missed, even while still possibly worth
tracking, the /command/ interface itself allows for adjusting the user
portion of the library list; both the Production library (PRDLIB) and
the Current Library (CURLIB) [see Create Command (CRTCMD)] may be
modified. Already known\discussed was the data in T-JS entries, beyond
the additionally tracked T-CD entries. Similarly for any other method
that allows a Job Queue Entry to be change, for which the Change Job
Queue Entry (CHGJOBQE) is not the means to implement, logging the T-CD
for CHGJOBQE requests would not suffice; not to imply there is any other
available, esp. one that is of consequence for a desired level of tracking.