Bogus timestamp for Modified date

[Ken Fairfield]

Wondering if anyone has ever seen something like this (I've tried to wrap the output for
readability):

------------------
RA2PW4::Khfairfi> diree/date=(cre,mod,exp,bac)
WS$HDISK:[PCMON70]RMT_TIMEOUT.LOG

Directory WS$HDISK:[PCMON70]

RMT_TIMEOUT.LOG;3 10-MAY-2003 12:15:39.28
16-OCT-2260 23:43:51.10
29-SEP-2004 16:43:48.96
7-OCT-2004 01:07:41.28
RMT_TIMEOUT.LOG;2 21-NOV-2002 18:51:34.30
5-APR-2004 08:58:10.72
30-APR-2004 10:53:06.05
7-OCT-2004 01:07:41.28
RMT_TIMEOUT.LOG;1 19-DEC-2000 15:49:17.82
12-JAN-2004 16:18:51.38
30-APR-2004 10:53:06.10
7-OCT-2004 01:07:41.28
Total of 3 files.
RA2PW4::Khfairfi>
------------------

Notice the bogus Modified date, 16-OCT-2260,
on the highest version of the file.

We have seen this on various clusters perhaps
as often as twice a year, just often enough to
say, "oh, I remember seeing that a while ago".
We've never been able to understand the source
of the problem.

The current problem is on a 3-node cluster of
ES-40's with 4xEV68/833 CPUs, 8GB memory,
VMS 7.3-1 and TCPIP Services V5.3 ECO 2 as well as DECNET-Plus. We do NOT NFS serve any
disks.

Any ideas? Anyone seen this before?

Thanks, Ken

[Hein van den Heuvel · Accepted solution]

Hey there Ken, fancy meeting you here! :-).
Welcome to the ITRC Forum.

Themost critical/urgent thing you need to do is DUMP/HEAD/BLOC=COUN=0 to find out whether the on-disk, in-header date is right or wrong.
Next, is this file per change semi-permanently open? It looks like it might be, judging by those dates.
If you have such a file, displaying a bad revision date, active, open on the system, then go find a process that has is open (SHOW DEV/FILE), and use ANAL/SYS to drill down to the FCB of that file.
Something like:
SDA> READ SYSDEF
SDA> SHOW PROCESS /CHANNEL ! in process of open file
SDA> ! Find the WCB address from above list
SDA> FORMAT @(wcbaddress+WCB$L_FCB)

It may well have that bad value there. (Use EXA/DATE )

The upshot of this is, that if this behaviour bothers you, you probably need patch VMS731_F11X-V0200.


(Interested HP internal readers (that's you John :-), see VMSnotes topic 6853)


hth,
Hein.

[Kris Clippeleyr]

Ken,

Are you by any chance running Advanced Server? We have seen similar things with files residing in directories that are also shares within Advanced Server. In our case, the revision dates (when using DIREC/FULL) were way off; the dates displayed with DUMP/HEADER were correct. We did log a call with HP, but never received a satisfying answer.
Btw, these phenomena were only seen on VMS 7.3-1.

Greetz,

Kris

[Ian Miller.]

There was some changes to the handling of file dates in V7.3-1 and there where problems in this area which cause some strangness. Try VMS731_F11X-V0200 and see if it fixes it.

Is the disk ODS2 or ODS5?

[Ken Fairfield]

To Kris, no we're not running Advanced Server on this cluster.

To Ian, we're using ODS2 disks. As you
suspect, looks like we're missing
VMS731_F11x-V0200.

Hein, good to hear from you! Haven't had
much time to read, let alone post to, c.o.v

This system has VMS731_UPDATE-V0100 on it.
Being a production system and under tight
revisions control, the system disk configuration was "frozen" about 12 months
ago in terms of ECOs, etc. I'm currently
testing an updated configuration that has,
among others, VMS731_UPDATE-V0400, which
includes the F11X-V0200 fixes.

Several points: Yes, the file has been open
for a long time. It will possibly remain
open until the node crashes/shuts down, or
until there is a need to "recycle" the
processes that have it open.

A Dump/Header/Block=Count=0 lists the file
characteristics and retrieval points, etc.,
but I DON'T SEE ANY DATE FIELDS. On the
previous version of the file, valid date
fields are displayed. Are the date fields
missing because the files is still open for
write?

Two process on each of the three cluster
nodes (six total) have the file open.

I followed you instructions for formatting
the WCB of one of the six processes, and
doing an EXAM/TIME on the FCB$Q_MODDATE
address shows the bogus time stamp. At
least we know it's in there!

Since this is mostly a cosmetic issue, and
there is a know fix, I'll drop worrying
about this any more.

Thanks Guys! -Ken

[Lawrence Czlapinski]

Ken, yes I've occasionally seen bogus dates as well.
Lawrence

[John Gillings]

Ken,
>A Dump/Header/Block=Count=0 lists the file
characteristics and retrieval points, etc.,
but I DON'T SEE ANY DATE FIELDS. On the
previous version of the file, valid date
fields are displayed.

You should be seeing several date fields. Something like this:

Identification area
File name type: ODS-2
File name length: 12
File name: LOGIN.COM;69
Revision number: 1
Creation date: 21-SEP-2004 12:26:41.62
Revision date: 21-SEP-2004 12:26:41.70
Expiration date:
Backup date:
Last access date:
Last attribute change date:
Extended RMS record attributes:

> Are the date fields missing because the files is still open for write?

If by "missing" you mean displayed as "", then yes, that means the value hasn't been written back to disk, or has no meaning. For example, the modified date isn't defined until you close the file. Hein's SDA stuff is looking for the in-memory field. If it's showing the bad date, I'd guess it's not being initialised properly. Since the field isn't defined yet, the issue is purely cosmetic, and has apparently already been fixed.

[Ken Fairfield]

John's response prompted me to go back and do the DUMP/HEADER again. This file has
been open logn enough that it has extension headers, and the extension header was what
I looked at when I failed to see the date
fields. They weren't/aren't present at all.
If I look at the first header, I see VALID
dates:

...
Revision number: 391
Creation date: 10-MAY-2003 12:15:39.28
Revision date: 28-SEP-2004 16:43:48.96
Expiration date: 29-SEP-2004 16:43:48.96
Backup date: 7-OCT-2004 01:07:41.28

So two things I see, first, the on-disk revision date seem sto be correct (from
looking at the contents of the file itself
and comparing to what's shown above), and
second, the in-memory revisions date is still wrong, but not causing any harm.

Thanks to all respondants, especially Hein and John. I'll close this thread now.

-Ken

[Ken Fairfield]

Known problem fixed by VMS731_F11X-V0200.