I'm working on identifying and possibly cleaning up old and apparently 
unused objects.  I created a table of library system objects using the 
QSYLOBJA API.  Among the attributes I retrieved are the object change 
date and the object last-used date.  For some database table and 
physical files, when I combine the object attribute data with data from 
the SYSTABLESTAT catalog view, I am seeing some things that don't make 
sense.  All of the oddities involve objects with a last-used date that 
is null.

Some database file objects that have an object change date prior to the 
last system IPL (and a null last-used date) show database activity from 
SYSTABLESTAT, e.g. open, close, logical and physical reads.  How can 
there be database activity on the file without that changing the 
last-used date for the object?

Some other database file objects have a change date subsequent to the 
last IPL, but no database activity (opens, closes, inserts, deletes, 
updates, logical and physical reads are all zero.)  Again, last-used 
date is null.  What could change the file object that doesn't update the 
last-used date?

On 16-Sep-2016 19:03 -0600, Jonathan Ball wrote:
> <<SNIP>>
> Some other database file objects have a change date subsequent to
> the last IPL, but no database activity (opens, closes, inserts,
> deletes, updates, logical and physical reads are all zero.) Again,
> last-used date is null. What could change the file object that
> doesn't update the last-used date?

   Not all "change" operations are related to I\O.  For example, if the 
authority of a database file (*FILE) object is changed, then all members 
and the file object are all /changed/ and the last-change-date is 
updated; similarly, any /generic/ database file activity such as rename, 
move, alter, change-owner, et al.  IIRC, only an open with a successful 
close will update the last-used date for a member, and some limited 
amount of reflection of the usage information is reflected in the file 
for each member; i.e. for specific details, the drill-down to the 
members is required, because the file-level details are not maintained 
or calculated as a cumulative of the information from all members.

-- 
Regards, Chuck