Re: File Last Changed

The condition of /changed/ must be understood, for save of database files, to be generally distinct from the /last changed date-time/. When the object is changed, whether only the data or the objects themselves [*FILE or *MEM] have been changed, the file object becomes eligible for /save changed object/ processing, to include any changed members or all members when the file was changed. Whether the database *FILE object is updated with a new[er] changed date-time is moot, with regard to the feature of "save changed"; i.e. the object is still eligible for "save changed" processing, irrespective of any newer recorded as last changed date-time.

When a library is saved using the the SAVLIB UPDHST(*YES), the list of /changed [since last full-saved]/ objects for that library, is then discarded. Given a file.mbr with data changed three separate times, with three separate open & close even, the *FILE may _validly_ reflect only the first data change peformed since that last save library request [with updhst(*yes)]. The way to infer the member.data was changed since that date-time recorded in the *FILE, is to defer to the *MEM objects themselves.

For database files with changed data, since [effectively] it is the *MEM object that contains the data, that is the object tracking the data changes and thus is the object that is saved. However to enable the restore, both conceptually and literally, a copy of the *FILE is saved along with the list of any changed members; i.e. even if only one member changes, a copy of the *FILE must saved as well.

So.... The role of last changed date-time for the database *FILE object, for changes to data, need only be indicative of the first change for which it became eligible for the function of save changed objects. That is really done only because it is helpful to visualize that the object will be saved -- for lack of any other interface to show that. Again, the *FILE object is merely a container, a directory, of the members which actually hold the data. If every row insert, update, or delete was tracked across every member of any one file, the "changed date-time" of the *FILE would not only be updated way more often than necessary, those few bytes of storage would become a single point of contention such that for some high volume activity against only the data, would have the *FILE object remain in memory as well as the data. The database *FILE as a mere container need not remain in memory for database I/O, but constantly updating to indicate that the *FILE was /changed/, would require that. The /dataspace/ is of course in memory when data is changing, and it is where the tracking of /last changed/ information is performed -- that dataspace information is manifest via the member object, via an interface like DSPFD for *MBR information [thus previously, /effectively/, alluding to the member as doing that].

Although for source members there is a distinct 'last source change date-time', there is no similar distinct tracking of member data change, separate from any other member changes. That is, a change to the *FILE that must impact all members [versus one member like rnmm, chgpfm], will manifest the /same/ date-time for that change of both the file and its members. As was already noted, restore, chgobjown, grt/rvk, move, chgxxx, et al. will all effect a consistent change date-time, but one can not infer the data was last changed then. That granularity for data changes, is within the realm of journaling.

Regards, Chuck