Path: utzoo!utgpu!water!watmath!clyde!bellcore!decvax!ucbvax!INDYVAX.BITNET!IJAH400
From: IJAH400@INDYVAX.BITNET
Newsgroups: comp.os.vms
Subject: Re: file dates.
Message-ID: <8802121945.AA01413@ucbvax.Berkeley.EDU>
Date: 8 Feb 88 18:52:00 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 47

<   I am not very familiar with VAXen to say if it is possible to set the
< date stored with each file.  Oh, if I am not mistaken, when you do a
< dir /date=some date, it is not necessarily the creation date, but rather
< the date it was last modified.
<
<   In any case, it doesn't make much sense to want to change a file's dates.
< Why would anyone want to do such a thing?

Well, the dates are just stored in the file header (try DUMP/HEADER/BLOCK=
COUNT=0 filespec) so I suppose one could change them to anything he/she
pleases by rewriting that.  This of course presupposes that one (1) knows
where the file header is (2) knows what it looks like (3) can write a
program to rewrite it and (4) has the <deleted> to try it out.

The civilized method would be to make a copy of the file using RMS, and
set the dates to be what you want when you call the RMS $CREATE service.
You can override the default dates when you do a $CREATE by using the
Date and Time XAB (XABDAT).  See section 9 of your RMS manual for details.
The XABDAT control block is only used as *input* to the $CREATE service,
so it *appears* that there is no civilized way of doing it to an existing
file without making a copy of it.

Why change dates (or supply non-default dates on a create)?  Well, aside
from non-serious applications (like logging in on April 1 and finding a
disk copy of the Gettysburg address dated 1863) the most important use for
it I have seen is with BACKUP restores (BACKUP preserves the original
file dates when restoring).  From time to time, DEC will provide you with
other reasons you might want to dink with dates; like, when last September,
we updated our console software.  An innocuous line in the release notes
warned that we'd have to reset the system date/time after we rebooted.
They didn't mention that it was going to come up with a date two weeks in
the future.  Our nightly batch job went off and wreaked some date havoc.
Moral: Set everything in the queues on hold before going down for a
software update.

I just got a hat stuck on my head last June to play VAX systems programmer,
all my previous experience was with -10s and -20s.  So please let me know
if I say something that is (1) dumb (2) incorrect (3) etc.  On TOPS-20 we
had a little utility called REV for doing things like date-dinking.  Anyone
know of any such utility for VMS?

James A. Harvey                         Bitnet: IJAH400@INDYVAX
DEC Systems Group
IUPUI Academic Computing Services
Engineering & Technology 1023
799 W. Michigan St.
Indianapolis, IN.  46220