You are reaching, Mike. How did you keep the dates from being updated?
* For CMS files on a minidisk, the answer is simple - there is no DoLR to worry about. * The same probably applies to your files in the "distant past". It was probably not a factor. * I suspect that PROFS was the only thing, if any, that was aware of any DoLR associated with its files (it never did support SFS while it was called PROFS and at least in the earlier days of OV/VM - I can't speak to any version more recent than 1998), so using some other, non-PROFS, tool probably did not affect it in any way. And if you used PROFS to do the scan you probably had no control over it, you took whatever it gave you. * Backup programs are special. They ought to have a mechanism for preventing update that is not available to any other user(perhahs excepting those in power). Restored files ought to have the same dates as the files that were backed up. * A scan is an application, a much used application around here. The only critical dates we have had to worry about have been either recorded in the files, themselves, or the DoLU, which CMS records for M-disks as well as SFS. Second question, how many times have you really had to worry about DoLR? I have never been asked to do anything that required DoLR in my 46 years in IT, the last 40 as a sysprog. It may be different for you because of the nature of Hewitt's business. Another point - do you really not care about seeing if someone reads the file? How do you distinguish between the good reads and the bad and record only the good? If you can easily keep DoLR from being recorded, so can someone else who may have nefarious purposes. If you are really worried about it, you ought to keep separate records and use a filter to ignore your secret accesses of the files. And these records should be inaccessible to all potential miscreants. (Perhaps via the Audit records produced by your ESM? I know you have one that records everything.) I, personally, do not like to depend on something that is available for only a minor portion of the data. We have a filepool that is comprised of 20 disks (3390-03s) devoted to user data. On the other hand, we have 92 -03s and 10 -09s devoted to CMS minidisks, where there is no record of last refeence. Then there are 516 disks used for TPF test system images (no record) and 251 devoted to VPARS DataBases (VDBs). The VDBs do record DoLR, but far and away the highest percentage (99.8+%) of their use here includes a first act of clearing them of any previous data, so DoLR is really meaningless; it almost always matches the DoLU, also recorded by VPARS. The few who do need to retain data in their VDBs could not care less about DoLR. They only want to be able to restart at specified checkpoints. DoLU may be important to them. Regards, Richard Schuh > -----Original Message----- > From: The IBM z/VM Operating System > [mailto:ib...@listserv.uark.edu] On Behalf Of Mike Walter > Sent: Thursday, July 23, 2009 11:24 AM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: Find command > > 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" <rsc...@visa.com> > > Sent by: "The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU> > 07/23/2009 12:50 PM > Please respond to > "The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU> > > > > To > IBMVM@LISTSERV.UARK.EDU > 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:ib...@listserv.uark.edu] On > Behalf Of Kris Buelens > Sent: Wednesday, July 22, 2009 11:39 PM > To: IBMVM@LISTSERV.UARK.EDU > 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. >
