On 18-Jul-2014 12:39 -0500, Steinmetz, Paul wrote:
The QAUDJRN did its job, it prevented us from deleting a library
that is still being used.
It revealed a library was being used in a library list, even though
library last used date says never used.
FWiW: The *LIB object does not have Last Used tracking per "Object
usage information is not updated for the following object types: ... •
Library (*LIB) ..."
The change date is from the nightly save, the library itself is was
<ed: the following quoted DSPOBJD info was relocated here>
Change date/time . . . . . . . . . . : 07/17/14 23:00:25
Usage data collected . . . . . . . . : NO
Last used date . . . . . . . . . . . :
Days used count . . . . . . . . . . : 0
Reset date . . . . . . . . . . . . :
While that /change/ may seem suspect for merely the /save/ activity,
IIRC the effect is [almost surely in this case, and typically] per
/insert/ [and remove] activity performed against the context [library]
object; a side effect of /database recovery/ processing for the database
save feature. Libraries without any database file objects, likely would
not exhibit the change activity due to SAVLIB. I am confident I have
described that effect in at least one past discussion; i.e. I probably
have another reply, likely also to this list, thus on the midrange
archives that, also describe this outcome, and possibly in greater
detail. I could find only
oddly seems improperly indexed by Google; maybe the same issue is origin
for my inability to find any other past topic that I am confident
exists] wherein I discuss the *DBRCV objects being created, but that
particular post did not also discuss the library change date\time
effect. Or\and if the effect is confirmed to be only when database
*FILE objects are present, then I could describe further upon request.
An initial program is doing a CHGLIBL.
While usage is not logged [for the library object per use of that
command], if a library named in that command were audited, would the
object auditing log a *READ entry for the *LIB object? I can not test
do to only *PEON access to any system.
Using the QAUDJRN data, I was able to identify the job, user, etc.
I remain unsure if the T-JS appears for any LIBL activity outside of
what might be more obviously classified as a Job Status action; i.e. 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?
Or asking from another perspective, if the change had been backed-out
by having issued another CHGLIBL request prior to whatever effected the
T-JS from being sent, I am wondering if perhaps a review of the data in
the JSLIBL would not have identified this job.?