ODS-5 weirdness

[Kris Clippeleyr]

Hi guys,
Cryptic title, isn't it.
We observed some weird things regarding the various dates for a file (creation, revision, etc.).
On an ODS-5 volume, a file (test.c) exists with creation date 27-JUL-2006 12:38:38.38, revision date 27-JUL-2006 12:38:38.43, last access date 27-JUL-2006 12:42:21.22, last attribute change date 27-JUL-2006 12:44:47.62.
According to DIRECTORY/DATE=MODIFIED, the corresponding executable images for Alpha and VAX, have a last modification date of 27-JUL-2006 12:42:42.59, and 27-JUL-2006 12:41:18.49.
So one expects MMS to rebuild the executable, and so it does on Alpha, but not on VAX.
On Alpha apparently the "last attribute change date" is taken into account, on VAX (or on an ODS-2 disk) the real "revision date" (lacking the former).
The lexical function F$FILE_ATTRIBUTES reports on the ODS-5 volume the "last attribute change date" if asked for the item RDT, on ODS-2 of course it reports the real "revision date/time".

Is this intended behaviour, or merely a glitch?

I've attached the output of a SET HOST/LOG to illustrate what happens.
Any comments greatly appreciated.
Points will have to wait until after the weekend.

Regards,
Kris (aka Qkcl)

Any comments appreciated.

[Richard Whalen]

I don't work in VMS development, but I would say that the behavior you are seeing is reasonable. The ODS-5 volume may be reporting the latest of the revision date and the last attribute change date.

[John Gillings]

Kris,

OpenVMS has recently acquired a few more dates associated with files. You've noticed, "last attribute change date". Depending on your version, there's also a "last accessed date", and maybe a few others.

The modification date (RDT) used to be bumped when either the data or the attributes changed. Now that the fields are independent, it's a toss up for the upward compatible choice. It's a good bet that if you change the data, there is some attribute change as well (for one thing you change the modification date, which is an attribute, yes?). Therefore, the attribute change date is probably the best approximation of the "old" modification date, so, arguably the best choice for upwards compatibility. Sounds like that's what F$FILE has chosen, and whatever code MMS is using.

For the purposes of MMS, the "new" modification date is probably a better fit for what they're trying to achieve, but unless MMS has been updated to explicitly ask for the new field, it will operate in "compatibility mode". What is the date of your version of MMS? Likely to be up to ODS-5?

In your case, copying the file from ODS-5 to ODS-2, the BACKUP command is obviously copying only the date/time fields it has a place to store in the target. There's an argument that this is a bug in regards to the modification date. Perhaps it should be taking the later of modification date and attribute change date to store in the ODS-2 modification date field?

Maybe it's worth logging a case and requesting an enhancement, either to MMS to use the more "appropriate" date, or to BACKUP to merge the two dates. Either of these changes would make both platforms behave the same (which I assume to be your goal)

[Craig A Berry]

In a quick glance at your attachment, it looks like you may have a case for a feature request for the BACKUP utility. Specifically, it seems that when you restore a backup created on an ODS-5 disk to an ODS-2 disk, you want to have the revision date concocted from the attribute change date. It doesn't sound too off-base at first blush, but it would take more serious thought than I feel capable of at the moment to see if that's really the right thing to do.

By the way, you don't say whether access dates are enabled on your ODS-5 volume. IIRC they are off by default.

The note in the middle of the following page may be of interest for background, though it's unlikely the BACKUP utility would use the C library to update file timestamps:

http://h71000.www7.hp.com/doc/82FINAL/5763/5763pro_056.html

It looks to me like the Guide to File Applications has not been updated since v7.3 (it says, for example, you can't have an ODS-5 system disk), so I'm not sure where best to read up on how all the POSIXish dates are handled by standard utilities.

[Ian Miller.]

I have been searching for a good description of the new date handling and so far have not found one.

I think what you are seeing is intended.

I agree with the BACKUP suggestion about dates.