@rice.edu:SAAAA04@BLEKUL11.BITNET (Ton Hospel) (08/28/89)
I once wrote a VM version of the unix TOUCH program, changing a files
timestamp to the current date and time. To do this I used the GETFST function.
I have two problems with this:
1. The FST entry only gets changed in memory. Normally no problem, but
when you reaccess the disk the disk version is read and replaces the
memory version -> no change is done. So how do I tell CMS to change the
disk version of the FST too ?
2. The directory of our system disks is loaded in the shared segments. Is
there a simple way to detect wether a given disk is in unalterable
storage or not ?
Ton@rice.edu:IJIM@UMINN1.BITNET (Jim Colten) (08/28/89)
>I once wrote a VM version of the unix TOUCH program, changing a files >timestamp to the current date and time. To do this I used the GETFST function. >I have two problems with this: >1. The FST entry only gets changed in memory. Normally no problem, but > when you reaccess the disk the disk version is read and replaces the > memory version -> no change is done. So how do I tell CMS to change the > disk version of the FST too ? >2. The directory of our system disks is loaded in the shared segments. Is > there a simple way to detect wether a given disk is in unalterable > storage or not ? > > > Ton > 1) You could RELEASE and ACCESS the mdisk again to cause CMS to update the directory. This is straight forward for R/W mdisks. Not so straight forward for mdisks ACCESSed as in ACC 193 B/B * * B2 but those are R/O anyway so I don't think you would be able to change the timestamp of a file on such a disk. 2) In the mdisk's ADT (active disk table?), ADTFLG1 contains a bit named ADTFRO which indicates that the disk is READ/ONLY. I THINK that if you look at that bit, you will avoid lots of problems, including trying to update a file's FST in a shared segment (sorry for the speculative response, just take this as a suggestion of where to look). Also, in the ADT macro there is a mapping of the LABEL record on a CMS formatted mdisk. In that mapping is ADTSFNAM, which is described as the NAME OF SHARED SEGMENT. Perhaps that might lead somewhere. Now, for the real purpose of this response. (THIS IS NOT A FLAME, I am only interested in discouraging a practice that has caused me pain OR giving others the chance to show me where I am wrong). I have had several close encounters with 'touch' programs in the MS-DOS world. I have yet to discover any redeeming social value in this program. A file's timestamp is valuable information. Why change it? Why change it? DON'T change it! One reason people have chosen to 'touch' files is to cause MAKE to re-compile all of or large portions of the source files that make up a program. AARRRRGH! So, I am asked to work on a program that I originally developed, and it appears that EVERY one of the fifty source files has been changed (and all at once! plus or minus a second or two. Would that ALL programmers were so productive!) In truth, there are two new source files, three that really changed and one or two INCLUDE (or MACRO or COPY or whatever your favorite language calls them) files that were really changed. But I will never know, short of locating an old backup and doing a lot of compare operations. With a little care, one can almost always keep one's MAKE control file up to date and complete, so you don't need those 'mega-compiles' so often. When you do, most MAKE programs that I have seen provide features that allow one to recompile an entire system without altering the timestamps of individual files. If your MAKE doesn't, then get one that does. If that can't be done then 'just' discard all of the TEXT (or .obj, or whatever) files and let MAKE do its thing. Ouch! This sure got warm for a non-flame. As advertised above, I am willing to be persuaded that TOUCH is a necessary tool. Any takers? In the meantime: ******** * * * * * * * * * * TO*CH * !!!!! * * * * * * * * ***** Jim Colten University of Minnesota
@rice.edu:AOCFJ@ASUACAD.BITNET (Charles Johnson) (09/08/89)
Jim, I disagree with you. I just recently wrote a program to change the date/time stamp on CMS files. I come from a large Engineering shop where the NC data on PC's are uploaded to the mainframe but due to the nature of the upload facility the original dates are not retained. In order to keep the data matched on both sides we make sure that the dates are correct on the PC as well as the mainframe.
@rice.edu:IJIM@UMINN1.BITNET (Jim Colten) (09/09/89)
>Jim, I disagree with you. I just recently wrote a program to change >the date/time stamp on CMS files. I come from a large Engineering shop >where the NC data on PC's are uploaded to the mainframe but due to the >nature of the upload facility the original dates are not retained. In order >to keep the data matched on both sides we make sure that the dates are >correct on the PC as well as the mainframe. > Well, I asked for it, didn't I. I will, with some reluctance, agree that your requirement for changing a file's timestamp is reasonable and valid. Actually I have no quarrel with your requirement. After all, its purpose is to allow you to preserve the file's 'real' timestamp. The reluctance comes from the fact that the tool is present and available for uses where the timestamp ought not be changed. Perhaps you could convince your file transfer software vendor to add the timestamp preservation feature to the product?
AOCFJ@ASUACAD.BITNET (Charles Johnson) (09/21/89)
Jim, I did neglect to say that on the mainframe the date/time stamp is changed by a disconnected vm. Users are not permitted to change their own files.
IJIM@UMINN1.BITNET (Jim Colten) (09/21/89)
>Jim, > >I did neglect to say that on the mainframe the date/time stamp is >changed by a disconnected vm. Users are not permitted to change their >own files. > That is marginally better. A file has a timestamp and I feel that the one and only valid timestamp is the one that indicates when the data in the file was last changed. Besides, when viewed from a low enough level, the DVM is indeed a user :-) The previous posting on this topic suggested a valid use for correcting the timestamp of a file that had been transfered from another machine without the timestamp being preserved. That seems ok as a cure. Apply the cure and continue to press for prevention (the file xfer software could preserve the timestamp). cheers, Jim