Re: File Last Changed

Chuck,

Thanks for the explanation. I forgot to mention that, first, all of these files are single member, and, second, that I did run DSPFD with the *MBR option. The members did show the same dates are the file.

I haven't used the SAVCHGOBJ command in several years, but wouldn't a SAVE 21 affect the "Last Changed Date" for the save eligibility? I always do a SAVE 21 both before and after applying PTF's, but I have some *File objects with a Change Date going back to 2006.
I understand the "Last Used Date" difference; simply running a query over the file affects that date.
As always, your explanations are very thorough. And extremely useful.

Thanks.

* Jerry C. Adams
*IBM System i Programmer/Analyst
B&W Wholesale Distributors, Inc.* *
voice
615.995.7024
fax
615.995.1201
email
jerry@xxxxxxxxxxxxxxx <mailto:jerry@xxxxxxxxxxxxxxx>



CRPence wrote:

Using DFU to change a row is both a /change/ and a /use/. The /use/ is from the Open, and the /change/ is from the Update record operation.

Database *FILE objects are merely a container for *MEM [member; noted sometimes instead, as *MBR] objects. They are even presented as a directory when viewed from the IFS. To know the usage information of the data, drilling down to the members is required. A 'change' is not a 'use' of an object. A 'use' is defined by action(s) which define the existence of the object; i.e. define its purpose in life. For the database file object, its existence is defined by access to the member data; its purpose is to allow the storage, retrieval, removal, and update of the data within its members. Without data, a database file has little value [except as a reference file; Hmmm, I wonder if that is being manifest as a 'use' -- probably should be]. Thus, unless the data is referenced by an operation, that operation is not considered to have /used/ the member. An object-level change for any object type that encapsulates data is not limited to being [identified as] /changed/ solely due to changes to its data. Moving or restoring the object, changing its authority, owner, text, attributes, etc. are all changes. As such, there is not any solid relationship to /use/ and /change/ date-time; the use could easily & validly be two years prior.

The /change/ of the database file, from the perspective of changing data in any one member, is [effectively; it may be updated more] limited to its first change since the last save; i.e. whatever adds the object to the list of objects eligible for /save-changed/ processing. This is really only a convenience for the DSPOBJD, as the arbiter of change and usage is really the members; again, the file as /container/ -- just as changing a file in a library does not signify a change to its library. For changes to the data, there are both 'source change date' and 'change date' information to consider, if the *FILE is a database _source_ file.

Any decision about the use and change of database files really needs to decide for any individual member first, and then if the only/last member is eligible for removal, then so too the *FILE may be eligible.

Regards, Chuck