Re: Scaning field JSLIBL from QAUDJRN outfile QASYJSJ5

On 22-Jul-2014 14:34 -0500, Steinmetz, Paul wrote:

CRPence on Sunday, July 20, 2014 10:48 AM wrote:
<<SNIP>>
The QAUDJRN is NOT returning CHGLIBL from the T-JS job, but a new
job that was submitted that contained the library used in a previous
CHGLIBL.
The actual interactive job that performed the CHGLIBL was not logged
with the T-JS.

I thought not. Seemed to me, that level of auditing would be too aggressive\onerous to have been allowed so generally.

FWiW the typical /obsolescence/ checking needs to concentrate on the objects in containers, not the containers themselves; the containers often better reveal their /usage/ in change activity or lack thereof. I have not responded to the prior message yet, to offer some of my thoughts along those lines; in part due to Google seeming not to, or to poorly, be indexing the archives. I have had great difficulty of late to find content that is on the gmane shadow, but the equivalent results are not found on midrange; I was trying to find where I had discussed the topic before, to prod me along.

<<SNIP>> is every single library-list modification causing a
T-JS.? Specifically, was the T-JS that found that /usage/, directly
a side effect of the CHGLIBL request, or was the CHGLIBL determined
to be the action only as a side effect of seeing a T-JS generated
for that job, having been generated due to some other job-status
change for which a T-JS is sent? <<SNIP>>

Answer is NO to the above.

select * from qgpl/QASYJSJ5 where locate ('CCPRSP ',JSLIBL ) <> 0

So next question is how do I see the CHGLIBL in the QAUDJRN?

Possibly T-CS [Command String] entries could include the data; the data may not be so easily scanned without false hits however.? I no longer recall if Change Object Audit (CHGOBJAUD) against a command (*CMD) object [for *ALL; to include /read/ access] ensures one of those is logged, or if they transpire only if the user profile is explicitly audited or ??

Otherwise, intercepting any command requests that perform any of the Library List change capabilities within a job might be required. A user journal entry [Send Journal Entry (SNDJRNE) or equivalent API] could track that activity; the change command exit-point could define what is necessary to effect necessary logging with a layout that is conducive to searching the log output.

Of course something other than a form of logging could be used; e.g. The Change Object Description (QLICOBJD) API to update the usage information of an object that correlates to the specific *LIB object [per usage not tracked for that object type, I believe that applies to requests from that API as well, such that a request would fail with msg CPF2131 "Key 15 not allowed with object type *LIB."], or could even be a row of a database file [then probably tracking Create Library (CRTLIB) and Delete Library (DLTLIB) would be required; albeit those are not the only ways that activity can transpire, thus complicating such an attempted solution].