Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!iuvax!cica!tut.cis.ohio-state.edu!ucbvax!@rice.edu:IJIM@UMINN1.BITNET
From: @rice.edu:IJIM@UMINN1.BITNET (Jim Colten)
Newsgroups: comp.lang.asm370
Subject: Re: GETFST
Message-ID: <8908282007.AA06563@brazos.rice.edu>
Date: 28 Aug 89 16:15:04 GMT
Reply-To: IBM 370 Assembly Programming Discussion List <@rice.edu:ASM370%UCF1VM.BITNET@icsa.rice.edu>
Distribution: inet
Organization: The Internet
Lines: 74

>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