WyBlog, the best thing about New Jersey since the invention of the 24 hour diner.
Chris Wysocki
Caldwell, NJ
The nine most terrifying words in the English language are "I'm from the government and I'm here to help." - Ronald Reagan
Linkiest
CH 2.0 Info Center
The Jersey Report
Labor Union Report
Memeorandum
Net Right Nation
The Patriot Post Newsletter
Pajamas Media
PJTV
Victor Davis Hanson
J! E! T! S! Jets! Jets! Jets!
OpenVMS.org Portal
AVS Forum
NJ.com Caldwell Forum
The Caldwells Patch
The Jersey Tomato Press
"This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. It is being made available in an effort to advance the understanding of environmental, political, human rights, economic, democracy, scientific, social issues, etc. It is believed that this constitutes a 'fair use' of any such copyrighted material as provided for in section 107 of the US Copyright Law. In accordance with Title 17 U.S.C. Section 107, the material on this site is distributed without profit for research and educational purposes."
I've been chasing a nuisance problem for the past two days. I have an application that accesses files in a directory depending on their modification date. Sometimes I need to update one of these files, but I don't want the application to reprocess it. For many years (starting with Vax/VMS) I've used the "FILE" utility (submitted to Decus by Joe Meadows) to reset this date.
I recently ported part of this application to OpenVMS 8.3 on an Alpha DS20.
This Alpha is part of a cluster that shares disks with my Vaxstation. I
moved the files over, and reset the modification dates on the Vax. But,
when I logged in to the Alpha, the files showed today as the modification
date (using $DIR/DATE=MODIFIED
on both system produced different
results).
I started pulling my hair out! I checked file caching parameters, I checked
the firmware rev on the MSA1000 SAN, everything seemed OK. The HP ITRC web
site wasn't very helpful either. Finally a Google search brought up the
VMS 8.2 New Features Manual. In it, under a section describing changes made
for Posix compliance, HP mentions that the modification date displayed by
the $DIRECTORY
command is actually generated on the fly
based on a new set of dates stored in an extended file header. In previous
versions of VMS, the modification date was a part of the file's directory
entry. Now there are 4 dates (revision date, accessed date, attributes date,
and data modification date). The date displayed in a directory listing is the
latest of these 4 dates.
But wait, it gets better. You can only see and modify these new dates if
you also set the disk volume parameter
/VOLUME_CHARACTERISTICS=ACCESS_DATES
and this parameter is not
set by default. If this parameter is not set, a $DIR/FULL
shows
the 4 new dates as blank! I modified the volume attributes, and saw that
$FILE/REVISION_DATE
was setting the data modification date, but
then OpenVMS set the attributes date to today (which makes sense since the
utility had indeed modified the file attributes).
Fortunately, there is a DCL command to override and set these dates (only on
OpenVMS Alpha though, it's not implemented on the Vax). The command is
$SET FILE/ATTRIBUTES=(ATTDATE=date,MODDATE=date)
. Using it
I was able to see the same results for $DIR/DATE=MODIFIED
on both the Vax and Alpha systems. Hooray!
Posted at 18:56 by Chris Wysocki
[/vms]
Comments | Perm Link |
|
Tweet
Previous: Morons harassing Marines | Next: The Stimulus Bill stalls |
Main |