Can someone please explain the circumstances under which the “Date/Time of Last Update” information (seen in AOS and ADAREP), held against a file, is changed?
Or, possibly more informatively, which “update-type” processes specifically do not change this information, if any?
It probably sounds like a basic question but the manuals aren’t very explicit and I’d just like to make sure I’m reading the information correctly.
here is some really internal information, which can be subject to any change in any future version withouth announcing this change :!:
There are two related fields in the FCB. These two file fields hold ‘date/time of last update’ and ‘number of updates’. For performance reasons these two fields are not updated with each update to the file.
An FCB update cycle occurs after (approximately) every 10,000 update commands (including add/delete) are executed by the nucleus. During the FCB update cycle these two fields are modified. The date/time field is set to the date/time of the FCB update cycle.
The internal count gets incremented when the command executing meets
a) The command is an ‘update type’ command. And
b) The command relates to a specific file.
The internal count gets incremented for A1/E1/N1 commands because these
commands meet both criteria.
The internal count does not get incremented for a L4 because it does not
meet criteria a).
The internal count does not get incremented for an ET because it does not
meet criteria b).
This entire logic is used by the nucleus because
- It eventually updates the FCB with an approximate date/time of the last
- It is better for performance than updating the FCB for every file update
I hope this helps
Thanks Uschi, that’s very informative.
The situation I was trying to understand was where I have a number of files on the same database (one of which I knew to be unused) that all have exactly the same update date and time.
After some investigation I believe this to be the outcome of performing an ADASAV RESTORE of all these files, and the files then not being updated since. I didn’t know that this utility function would change the update date/time and will have to remember that in the future when monitoring file usage in this way.
Thanks again for your prompt and very helpful reply, Garry.