Chuck,

Thanks for links and info.
I'm seeing conflicting results which appear to be an issue, or will IBM state WAD.
Library CCPRSF currently has 31 objects, 5 PF, 25 LF, 1 dtaara.
All objects within the library, CCPRSF, show same last use/change info, see below. (05/06/12 is date of P5 to P7 migration)

Change/Usage information:
Change date/time . . . . . . . . . . : 05/06/12 04:51:19
Usage data collected . . . . . . . . : YES
Last used date . . . . . . . . . . . :
Days used count . . . . . . . . . . : 0
Reset date . . . . . . . . . . . . :

WRKOBJ of the library - shows library was changed 07/20/14 (last BRMS save)
Library 1 of 1
Object . . . . . . . : CCPRSF Attribute . . . . . : PROD
Library . . . . . : QSYS Owner . . . . . . . : COMMSOFT
Library ASP device . : *SYSBAS Library ASP group . : *SYSBAS
Type . . . . . . . . : *LIB Primary group . . . : *NONE

Change/Usage information:
Change date/time . . . . . . . . . . : 07/20/14 22:54:46
Usage data collected . . . . . . . . : NO
Last used date . . . . . . . . . . . :
Days used count . . . . . . . . . . : 0
Reset date . . . . . . . . . . . . :

Reviewing the link http://www-01.ibm.com/support/knowledgecenter/ssw_ibm_i_71/rbam6/detob.htm

Media definition The SAVLIB, SAVOBJ, RSTLIB, RSTOBJ, SAVCHGOBJ commands; as well as, the BRMS and QSRSAVO API.
Object usage information is not updated for the following object types: Library (*LIB)
The above two are conflicting.

I've always used 4. Disk space tasks 1. Collect disk space information 2. Print disk space information as a starting point of identifying unused objects, but now I question its validity. It shows library has not been used, last changed 05/06/12 (this was date of P5 to P7 migration)

Library Information
% of Size in Last Last
Library Owner Disk 1000 bytes Change Use Description
CCPRSF COMMSOFT .00 2039.8 05/06/12 **CommSoft BASE Continuing Property Records-file

Are there possibly 2 different Last Change dates for the library object, since IBM is reporting back two different dates? 05/06/12 and 07/20/14

The QAUDJRN is returning CHGLIBL from the T-JS job.
select * from qgpl/QASYJSJ5 where locate ('CCPRSP ',JSLIBL ) <> 0

Data width . . . . . . : 3999
Position to line . . . . . Shift to column . . . . . .
....+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8....+....9....+...10....+...11....+...12....+...13.
Entry Sequence Code Type Timestamp Job User Job Program Program Pr
length number name name number name library AS
de
3,726 00000000000104470775 T JS 2014-05-21-11.05.39.308576 SPYPRINT FPACLITW 636,398 QWTPIIPP QSYS *S
3,726 00000000000104470933 T JS 2014-05-21-11.06.12.482720 SPYPRINT FPACLITW 636,402 QWTPIIPP QSYS *S
3,726 00000000000104471068 T JS 2014-05-21-11.06.36.635248 SPYPRINT FPACLITW 636,403 QWTPIIPP QSYS *S
******** End of data ********

Bottom line, where and how should one look for if an object is last used?
I'm no longer comfortable with the methods I've used for years for this process.

Paul




-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Sunday, July 20, 2014 10:48 AM
To: midrange-l@xxxxxxxxxxxx
Subject: 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.?

--
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-2015 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