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.
midrange.com
