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].
midrange.com
