Re: Scaning field JSLIBL from QAUDJRN outfile QASYJSJ5

On 18-Jul-2014 12:39 -0500, Steinmetz, Paul wrote:

<<SNIP>>
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) ..." <http://www.ibm.com/support/knowledgecenter/ssw_ibm_i_71/rbam6/detob.htm>

The change date is from the nightly save, the library itself is was
not changed.

<ed: the following quoted DSPOBJD info was relocated here>

Change/Usage information:
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 <http://archive.midrange.com/midrange-l/201301/msg01469.html> [which 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.?