MIDRANGE dot COM Mailing List Archive



Home » MIDRANGE-L » August 2014

RE: Scaning field JSLIBL from QAUDJRN outfile QASYJSJ5



fixed

Chuck,

1) I turned on object auditing for CHGLIBL, ADDLIBLE, RMVLIBLE, EDTLIBL.
Using the below commands, I now can confirm if any library is being used, whether in a jobd and/or added/removed to/from a job.
Libraries from EDTLIBL do not get logged in the QAUDJRN, confirmed from your previous post.
We have a list of almost 200 libraries, eligible for deletion.
Am I missing anything, or is this a near 100% confirmation that a library is not used, prior to deletion.
I can't rely on IBM's object library usage dates, not accurate.

2) CPYAUDJRNE ENTTYP(CD) OUTFILE(QGPL/QAUDITCD) JRNRCV(*CURCHAIN)
3) CPYAUDJRNE ENTTYP(JS) OUTFILE(QGPL/QAUDITJS) JRNRCV(*CURCHAIN)
4) SELECT * FROM qgpl/QAUDITCDCD WHERE locate ('DBULIB',CDCMDS ) <> 0
5) SELECT * FROM qgpl/QAUDITJSJS WHERE locate ('DBULIB',JSLIBL ) <> 0

Paul


-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Tuesday, July 22, 2014 5:18 PM
To: midrange-l@xxxxxxxxxxxx
Subject: 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].

--
Regards, Chuck
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l.






Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2014 by MIDRANGE dot COM and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available here. If you have questions about this, please contact