Re: File Last Changed

[Jerry Adams <jerry@xxxxxxxxxxxxxxx>]

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
>