Re: Whyo would Last used date and days used count on PF not be updated?

On 04-Apr-2016 11:00 -0500, Steinmetz, Paul wrote:

On Apr 4, 2016, at 11:17 AM, Steinmetz, Paul wrote:

Why would last used date and days used count on a PF not be
updated? I moved an object out of a production library that we
thought was not being used base on this info being blank/zeros.
Program failed this morning, had to move the object back.

I found our CL where this file was used.
Turns out our code RMVM FILE(XXXXXX) MBR(*ALL)
Later our code creates a new member.

CPYF FROMFILE(AAAAAAA) TOFILE(XXXXXXX) +
TOMBR(&MEMBER) MBROPT(*REPLACE) +
FMTOPT(*NOCHK)

Based on this, usage information must be stored on the file member
and not the file itself.
Looking at file information alone, (in this case) was not accurate.

Indeed the Last Used Date\Count is stored separately in the *MEM (MBR) object. Drilling-down and looking at the individual member attributes is more accurate [i.e. generally better to use DSPFD for *MBR or *MBRLIST vs DSPOBJD for the most relevant and accurate details specific to the members]. However...

IIRC the Last Used Date\Count information for the [database file] *FILE object will get updated [only once per day] when any member is closed with physical I\O changes. The Copy File request would have closed the member (&MEMBER) of the target file (XXXXXXX) if\after some data was copied, upon which the effect of the Modify System Object (MODSOBJ) MI instruction should be seen for the member, and the same effect for the *FILE if a more recent date than the prior MODSOBJ request. If no data was copied, then the CPYF request would have failed [thus what Monitor Message (MONMSG) was (not) in effect for a failed CPYF would be pertinent].

Thus I do not expect that the above conclusion about the incorrect\missing data is accurate; instead, something else about the scenario had the [method used to retrieve] last-used information about the *FILE was problematic.