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
lack thereof.<<SNIP>>

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.


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.

This thread ...

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