SFS has an option to log who accessed a file (not which program): you'd need to turn auditing ON (what requires an SFS restart). We ran a while with this auditing active (maybe at the initial SFS days when a DLOR was not yet maintained by SFS).
The only way I know to read a file without changing its DLOR is by a CSL call. And John supports it in <SFS too. So, our PIEK EXEC uses <SFS and the BROWSE stage. Changing the BROWSE MODULE would mean replacing the FSOPEN/FSREAD by CSL calls DMSOPEN and DMSREAD. I have been looking at fixing SHOW too, but I gave it up. My LOOK package (that used XEDIT to search) was changed to use PIPE LOCATE for simple searches. For complex searches we XEDIT a work file and then use PIPE or CSL to pump the data of the file to scan into the work file. I'll send you both tools. 2007/6/15, Mike Walter <[EMAIL PROTECTED]>:
90% an exercise to clean out obsolete garbage. 10% an exercise in becoming more familiar with SFS, something we've neglected far too long and which could make multi-VM system support easier in the future. Now, if only SFS had an option to log who, and. what accessed a file we could really clean house. But that breaks "the last 10% rule": the last 10% takes 90% of the effort and cost, making it a poor ROI. Some small changes to our COPY2 EXEC will make keeping the shadow copy on SFS (and it's HEWITT PARTCAT) transparent. But we will need to automate detection and reporting of any changes that might occur (maybe VMFCOPY from a product install or service, or a manual COPYFILE or ERASE) outside of COPY2. That should not be very difficult, either. Once the old garbage is cleaned out we may revert to the 019E disk again. We'll see how it goes. Mike Walter
-- Kris Buelens, IBM Belgium, VM customer support
