VMS731_F11X-V0300 and ATR$C_REVDATE: new bug?

[Craig A Berry]

I've attached a small program that changes a file's revision date (ATR$C_REVDATE) by doing an IO$_MODIFY $QIO to the File Information Block (FIB). The code ultimately derives from Joe Meadow's FILE utility and the basic procedure is now pretty ubiquitous. It's been used in Perl's utime() implementation for years -- long before utime() became available from the CRTL.

The program works fine on files residing on ODS-2 volumes on any version of VMS I'm aware of. It used to work fine on files residing on ODS-5 volumes on OpenVMS Alpha 7.3-1 before application of the VMS731_F11X-V0300 ECO, but stopped working after application of the ECO. It appears to also be broken on an OpenVMS Alpha 7.3-2 system with the corresponding ECO.

"Broken" means that the modification request is simply ignored and the revision date stays the same. The program still works fine with files on ODS-5 volumes under OpenVMS Alpha 7.2-1 or OpenVMS I64 8.1. None of the ODS-5 volumes I've tested with on any VMS version has access dates enabled, though I don't know if that's significant.

So, that's a lot of background, but I do have a question or two here. I can't be completely certain the ECO in my subject line is the one at fault since I applied a boatload of other ECOs at the same time and am not in a position to back out the F11 one, but I strongly suspect it's the culprit because of the description in the section, "6.1.3 DIR/DATE=MODIFIED command gives incorrect results." Is anyone in a position to do a before and after run of the attached program where only the VMS731_F11X-V0300 ECO is different? To run the program, just do:

$ create foo.tmp
^Z
$ mcr []setrdt foo.tmp 20-sep-2003

or any other date, then do DIR/FULL on foo.tmp to see if the revision date has changed to the date you specified.

[Hein van den Heuvel]

You may want to check with support on this.
The are some issues reported, but details are not clear to me.

Access dates, and Posix compliance play a role.

Here is an engineering comment from back in september that may (or might not) help.

-----
Prior to V7.3-1, a file open for continuous use would
show the modification date the same as the creation date.
Then the deaccess of the file would update the modification
date to be that of when the file was closed.

With some of the POSIX inclusions of V7.3-1, the modification date
would could be updated with each actual write to the file
(at the $QIO level, not necessarily an RMS $PUT). So the
modification date would move forward arbitrarily and could
be different from node to node within a cluster.

This can cause some confusion. The next V7.3-1 remedial kit (and Opal)
restores the V7.3 behavior for disks that do not have access dates
enabled. Only ODS-5 disks are eligible for enabling access dates
where the POSIX rules apply to this behavior.
------

[Craig A Berry]

Hein, thanks for the reply and the info. Posting here is as close as I can come to "checking with support."

The engineering note does help explain what they were trying to do for volumes with access dates enabled, but it looks to me like they inadvertently changed the default behavior for volumes without access dates enabled.

[Craig A Berry]

I've done a bit more testing and narrowed the problem space a bit. I've also confirmed that the CRTL's utime() has exactly the same problem as my example program that does a QIO to the FIB.

I suspect a lot of other utilities are affected as well. BACKUP, for example, now sets the RDT to the current date and time rather than preserving the RDT of the original file. Ditto if you unzip a ZIP archive that was created with -"V" to preserve VMS attributes; you now get the current date and time as the RDT instead of the value that was saved in the archive.

It turns out that setting an RDT later than the existing RDT always works, but setting an RDT prior to the existing RDT is ignored. Moreover, the "existing RDT" is sometimes a cached value that is not displayed. An example follows.

1.) Note the original RDT:

$ write sys$output f$file("foo.tmp","rdt")
16-APR-2004 17:28:15.23

2.) Now see that setting the RDT to some time prior to that is ignored:

$ mcr []setrdt foo.tmp 1-jan-1970
$ write sys$output f$file("foo.tmp","rdt")
16-APR-2004 17:28:15.23

3.) Now set the RDT to a day later than the existing RDT:

$ mcr []setrdt foo.tmp 17-apr-2004
$ write sys$output f$file("foo.tmp","rdt")
17-APR-2004 15:11:34.38

so far so good, but

4.) Now try to set the RDT to a year earlier than the existing RDT:

$ mcr []setrdt foo.tmp 17-apr-2003
$ write sys$output f$file("foo.tmp","rdt")
16-APR-2004 17:28:15.23

Not only does it not accept the value; it resets it not to the previously reported RDT of 17-APR but to the original RDT of 16-APR from step 1, which it apparently had cached somewhere.

[Carl Karcher]

I've reported a similar problem after applying VMS732_F11X-V0100 with the following symptom:

When using backup to copy files from an ODS-2 to ODS-5 volume, the revision dates are not preserved. Backup from ODS-5 to ODS-5 and they are preserved. Systems without that patch always preserve the revision dates.

Last I heard it's been "elevated to engineering"

[Ian Miller.]

Carl, you could give hp a pointer to this thread for extra information. It does sound like a bug. Its a complicated area that was changed.

[Craig A Berry]

Carl,

Thanks for the reply, and do pass along anything you hear back from engineering that you can share in this forum. The only other related thing I've come across recently is in the utime() implementation that comes with the porting library ("the jackets"):

=== begin quote from utime.c ===
/*
** If the new revision date is earlier than the creation date then we
** have to modify the creation date too, otherwise the setting of the
** modification date will silently fail.
*/
status = lib$sub_times(&revdate, &credate, &tmpdate);
if ((status & 1) == 0)
memcpy(&credate, &revdate, sizeof(revdate));
=== end quote ===

This certainly *sounds* like it's related, but I have not put this code through its paces to see what it actually does. For some reason it does 2 QIOs, an IO$_ACCESS and then a IO$_DEACCESS, instead of a single IO$_MODIFY as the example I attached in my original post does.

[Carl Karcher]

CSC just passed on the response from engineering on this: it's a "feature".

However it can be turn on/off:

$set vol /volume_characteristic=access_date

The default is noaccess_date. The same qualifier exists for INIT as well.

There's mention of this in the 7.3-1 new features manual in section 4.10. However it sure is a long stretch from that mention to the observed behavior (or havoc) that results.

After using the set volume command above to enable "access dates", backup preserved the revision dates. Also, FILE was then able to set the revision dates. I'm betting this is going to take care of the other problems mentioned in this thread too.

[Craig A Berry]

Thanks, Carl, for passing along the depressing news. I think this is the first time I"ve seen VMS have a change in default behavior done in quite this way. Usually you have to enable a new feature in order to change prior behavior, but here you have to enable a new, non-default feature in order to preserve prior behavior. Moreover, the change in default behavior was introduced not by a minor release, nor even a dash release, but by a single ECO, and it is not documented anyhwere I can find (certainly not in the ECO release notes).

The statement that the feature is documented in section 4.10 of the 7.3-1 new features manual is simply not true since the nearest thing that section has is:

'The REVDATE ACP/QIO attribute is the most recent of the MODDATE and ATTDATE timestamps."

but since MODDATE and ATTDATE have no meaning unless access dates are enabled, there is no claim made at all here about how REVDATE will be set when access dates are not enabled. In fact the whole section is devoted to the new features available with the POSIX-compliant access dates and there is no indication that anything would change if I'm not using them. I certainly would feel safe assuming (after reading the 7.3-1 new features) that REVDATE would be set as it has been for decades unless I enabled the new feature, and that assumption was true when 7.3-1 was released and for a couple of years afterwards (until the current F11 ECO).

Ah well, since it's apparently reversible, I guess I will try enabling access dates and see what happens.

[Jan van den Ende]

Craig,

I agree 100%.

NO change, major, minor, or ECO, should EVER change the default behavior!

We are (rightly) proud of VMS, amongst other things, just BECAUSE its behavior has always been to maintain upward compatibility!! (see eg
http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=611715 )

It is really not difficult at all to envision various scenario's where this 'feature' can break existing production systems, and requiring A LOT of unplanned work, if warned in advance.

And by such a VERY obscure and unclear 'announcement' it is quite probable that it will be found too late.

It is NOT a feature, it is at best a nasty bug, and at worst a Micro$oft-style breach of compatibility.
Am _I_ incriminating VMS engeneering with M$ practises? OH my, I must be in a bad temper. How come? Break of long-cultivated trust.

Thanks for your warning, Craig!

Jan