Richard, There have been times in the distant past when CP or CMS command syntax changed, and rather than make all the users search for EXECs that needed changes, as a sysprog performing the system upgrade, I searched them all to see which few actually needed to be changed. I would not want a sysprog-inspired search to affect the last-referenced date.
Sometimes, I've had to scan user control files for specific strings (in the long past, sometimes PROFS notelogs). Again, the files were not being used by an application, and should not have the DoLR updated. Can you imagine if backup products caused the DoLR to be updated every time a file was backed up or restored? Might as well just remove the file date/timestamps altogether! ;-) There were a *LOT* of file searches performed in preparation for Y2K; again, the user/application was not affecting those files and the DoLR should not be updated. Sysprogs often have a different role to perform and should do their level best to ensure that their work does not affect other details. Mike Walter Hewitt Associates Any opinions expressed herein are mine alone and do not necessarily represent the opinions or policies of Hewitt Associates. "Schuh, Richard" <[email protected]> Sent by: "The IBM z/VM Operating System" <[email protected]> 07/23/2009 12:50 PM Please respond to "The IBM z/VM Operating System" <[email protected]> To [email protected] cc Subject Re: Find command I thought you were talking about real files, not programs :-) Besides, there is no such date for files stored on minidisks, so it is essentially useless in that regard. For EXEC usage, I tend to look at the statistics created by my Global REXX Exit, rather than a reference date. How would one differentiate between scanning a file in a Pipeline and performing the same scan by opening it in XEDIT and using the LOCATE command? How about copying the file to another location? What constitutes a "real" use from one that does not count? It could be argued that any OPEN of the file is a reference. Is not that the difference between a Last Reference timestamp and one for Last Update. Perhaps if the date were maintained for all files and a line could be drawn separating the real uses from the casual ones, don't forget that is is possible for the reading of the file to be a real use, I might agree with you; however, I think that drawing that line will be very difficult. Perhaps you can get a parameter added to FSOPEN and all other macros and routines that open files (OS Simulation comes to mind) to indicate that your opening of the file is casual and should not count. (That or you could maintain a registry associating programs with files ala Windoze. ;-) ) I am content with letting the scan be counted as a reference. After all, the file is being read for some purpose. You are trying to differentiate between purposes, and that is something that cannot be determined by the system. It only knows that the file has been opened. Regards, Richard Schuh From: The IBM z/VM Operating System [mailto:[email protected]] On Behalf Of Kris Buelens Sent: Wednesday, July 22, 2009 11:39 PM To: [email protected] Subject: Re: Find command >What is the harm in updating the reference date when one peruses a file to see if it contains specific data strings? If one uses the last reference date to see if a file (e.g. a program, REXX exec) is still being used, such a scanning process should not update it. It never is a "real" use. At the other hand, we had a discussion with SAS several years ago: they used OLDDATEREF, and running SAS programs surely is "real" usage. GETFILES will not use OLDDATEREF, it has no parameters, and OLDDATEREF would never be a good default. Kris Buelens IBM Belgium, VM customer support The information contained in this e-mail and any accompanying documents may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message, including any attachments. Any dissemination, distribution or other use of the contents of this message by anyone other than the intended recipient is strictly prohibited. All messages sent to and from this e-mail address may be monitored as permitted by applicable law and regulations to ensure compliance with our internal policies and to protect our business. E-mails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by e-mail.
