On 04-Aug-2014 16:43 -0500, Steinmetz, Paul wrote:
CRPence on Tuesday, July 22, 2014 5:18 PM wrote:
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
1) I turned on object auditing for CHGLIBL, ADDLIBLE, RMVLIBLE,
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.
Could be /confirmed/ only when *LIBL changes are effected with one of
the first three commands above in (1). That is IMO however, a rather
limited perspective. Notably the CHGSYSLIBL is omitted from that list
of audited commands. But there are many other ways that a library can
be /used/; even if\when the library being included in the Library List
(LIBL) of a job is is the *only* criteria to be considered in defining
/used/, there are still numerous other ways the library list can be
modified, beyond just some\that set of CL commands.
Libraries from EDTLIBL do not get logged in the QAUDJRN, confirmed
from your previous post.
For which an alternate to the T-CD audit entry would need to be
implemented, if the the effects of that command were also of interest.
We have a list of almost 200 libraries, eligible for deletion.
Even on a production system, the expression about seeking forgiveness
versus seeking permission might be apropos; presumably the libraries are
already empty from obsolescence processing for the objects within.?
On a production system I would probably choose foremost to rely on
the results of searching for library object references within sources
and other objects, and then results from review for any change activity
to the library objects since some past date; the review of audit entries
since that same date, of what already exist or are easily available
[e.g. the T-JS and those few T-CD], but probably not doing anything that
requires (much) more work [such as command exits or intercepting API
calls]. And probably that, only after first deleting all obsolete
objects in the set of libraries; i.e. the set of libraries is a side
effect of those libraries emptied by that prior work.
Am I missing anything, or is this a near 100% confirmation that a
library is not used, prior to deletion.
Far from 100%, but could skew that way, given there is a tendency for
the use of the first three commands over other interfaces that might
adjust the library list and therefore /use/ the library in that manner.
But IMO an assumption that /usage/ of a library can be defined purely
as a _library list issue_ is fraught with peril, if that is the only
criteria for the /use/ of the *LIB object. Again, I refer [back] to my
reference on how decisions might best be made for the obsolescence of a
[*LIB object as] container. But specifically, every _library qualified_
reference to an object is in effect a /usage/ of that library, but the
library never need have been in any library of any job.
I can't rely on IBM's object library usage dates, not accurate.
Rather than being inaccurate, the Last Used Date and Days Used Count
values are _nonexistent_ for any Library object; i.e. any request made
to DSPOBJD OBJTYPE(*LIB) DETAIL(*FULL) will show "Usage Data Collected =
No", because the decision is that the /use/ of the container object
is\would-be excessive, such that usage inquiries instead should be
directed to the objects within the container.
2) CPYAUDJRNE ENTTYP(CD) OUTFILE(QGPL/QAUDITCD) JRNRCV(*CURCHAIN)
3) CPYAUDJRNE ENTTYP(JS) OUTFILE(QGPL/QAUDITJS) JRNRCV(*CURCHAIN)
4) SELECT * FROM qgpl/QAUDITCD WHERE locate ('DBULIB',CDCMDS )<>0
5) SELECT * FROM qgpl/QAUDITJS WHERE locate ('DBULIB',JSLIBL )<>0
So again, perhaps tending towards finding most /uses/, but improbably
tending as far towards _all references to a library_ [for which the
deletion of the library might cause problems later] as might be hoped
would be found in such a limited search. That for review of an object
that is a container, [and specifically for a *LIB for which no usage
data is collected] I would defer to references [use or change activity]
of the object(s) within, and for any change activity for the container
for which some add\remove activity is implied. Note: given /restore/
activity is likely also reflected in change date\time both for the
object and the container, that usage-data may be able to be ignored
somewhat generally given the change-date info is reviewed.
There are many potential references that could be overlooked when
depending only on that information; some thoughts in that regard:
The User Profile (USRPRF) has at least the CURLIB() specification as
a place to name a library. A Subsystem Description (SBSD) also has at
least the SYSLIBL() specification to name a library. The command
definition [Create Command (CRTCMD)] has the CURLIB() and PRDLIB(). And
then there is the Change Library List (QLICHGLL) API for which changes
can be made to the current library (CUR), the two product libraries
(PRD), and the other entries in the user (USR) portion of the current
thread's library list. The T-JS will not find any Job Description
(JOBD) object that names the library, except if used to start a job,
though other job status changes would reveal the snapshot of the LIBL;
and note that not every *JOBD would necessarily be used directly to
start a job, perhaps only indirectly from use of Retrieve Job
Description Information (QWDRJOBD) API [though of course a desired LIBL
could have been stored elsewhere, other than in a *JOBD, perhaps
obtained from data retrieved via QUSRJOBI or RTVJOBI USRLIBL()] and then
that info is passed to QLICHGLL. And then pretty much every command or
any other means of explicitly qualifying a library name for any object;
e.g. OVRDBF TOFILE(the_lib/the_file) wherein the file named the_file is
temporal for which not even object existence checking the file is any
assistance, whereby instead the /usage/ of the library would be
reflected only it the /change date\time/ for when the object was first
inserted and then deleted.