OpenVMS File timestamps upto 100 nanoseconds

[Almond Desailly]

Hi,

I need to get the timestamps related to files (on openVMS) upto 100 nano-seconds.

While, I was working on unix, I could get the timestamp information using the
"stat" system call and st_mtime/st_ctime.
When I use a similar approach here, I do not get the timestamp upto 100 nano-seconds.

What should I use to get the file time stampsupto 100 nano seconds?

Please note, I am trying all these in C.

Regards,
Almond

[Joseph Huber_1]

Could You please explain what You are looking for ? example code ?

in stat.h:
time_t st_mtime;

is a C time_t value, i.e. seconds since Unix epoch.
How can it contain something in a 100 nsec period, since what epoch ?

[Dennis Handly]

>What should I use to get the file time stamps up to 100 nanoseconds?

You would be hard pressed to get this precision for timing CPU cycles. This is 10 microseconds. By the time you wrote this info to the disk, it would be way out of date.

And as Joseph said, a time_t is only in seconds.

[Steven Schweda]

[...] unix [...]

Not a very detailed description of anything.

uname -a


And, if you use a more VMS-specific
interface than stat(), I believe that you'll
find that the file system date-time values
are maintained to a precision of 0.01s, as
might be suggested by applying a command
like, say:
DIRECTORY /DATE = ALL
to a file or two.

[Hoff]

Your design is going to have issues. VMS tends to use and store in centiseconds. On a good day.

You can get high-precision from various interfaces.

But high-accuracy is only available in specific system interfaces.

You're also going to watch for issues with daylight saving time (DST), as VMS uses localtime and not UTC. But that's another discussion and another pitfall.

Rather than seeking assistance with a proposed and problematic solution involving reading high-precision times (as potentially differentiated from high-accuracy time values) off of files, please provide some background on the problem you're looking to resolve.

Why are you looking to read these times, and what issue(s) are you planning to solve with this approach?

[Robert Gezelter]

Almond,

Regarding timekeeping, I would suggest that you start by reading the relevant chapters in "OpenVMS Internals and Data Structures".

The time values stored in the actual FILES-11 file headers are precisely the 64-bit binary values from the standard time service (with a representational precision of 100 nanoseconds).

However, as Hoff has previously noted, the current time value is only updated far less frequently. Thus, the actual precision of the time value is somewhat less than what can be represented in the standard format.

Since the physics of CPUs are essentially constant (e.g., a CPU updating the time value every 100 nanoseconds would accomplish little more than updating its clock), I suspect that the other (unspecified) systems are doing the same thing as OpenVMS, reporting only some values for time, not the complete set that can be represented in the data structure.

File system dates are informational, there is never sufficient precision to do something like queuing based on creation date. That needs to be implemented with other tools, methods, and approaches.

- Bob Gezelter,

[Hoff]

>File system dates are informational, there is never sufficient precision to do something like queuing based on creation date. That needs to be implemented with other tools, methods, and approaches.

Sure there is. That's the basis for many of the best broken designs. It's an excellent choice for systems that need to tip over at the daylight savings switch-over. It's also a good choice for schemes that must fail when the clocks are skewed within a cluster, or for cases where you need DECnet FAL, Microsoft FAT formats or other such to strip off the precision, or when COPY or BACKUP change the timestamps.

It's exactly how a programmer can build a sufficient number of obscure failures into a design to create a career-long application, too. Time-related bugs are one of the better "I'm going to code myself a minivan" designs, to paraphrase the classic Dilbert cartoon.

Ok... More seriously...

Please rethink this design.

Yes, it's possible to get it to work, but the results will almost certainly have bugs. If you're aiming for "good enough", you might get this to work, but if you really need the high-resolution values, you're in for a world of hurt with this stuff.

Most folks do not understand time. I've been at this time stuff a while within VMS, and have personally either made or have debugged a number of mistakes here, and I don't trust me when it comes to the details of this stuff.

The end results of these designs, of course, are messes such as those that exist within VMS itself. Yes, VMS timekeeping itself is arguably fundamentally broken. It should not be localtime but rather UTC, and (in the current computing era) the timekeeping accuracy on these various interfaces should now match the available precision. And it doesn't.

And application designs looking for high-resolution timestamps on files? Those are almost certainly going to be somewhere between weird transients and broken, particularly when you roll clustering into the equation.

As for the existing Unix C design here, that's actually likely also broken, too. (Unix timekeeping doesn't work the way many folks think it does. ) The ctime value is the inode change time and not the file creation time. That inode change time value may or may not be the creation time, and it's trivial to cause it to change. If you're working with a BSD-flavored Unix, then the ATTR_CMN_CRTIME itemcode of the getattrlist() call is a far better choice when you're looking for the file creation time.

[GuentherF]

Attached a SMOP to show how to get the creation date of a file using the RMS API.

The date in internal VMS format (64-bits, 100ns units) is translated to a string. And as mentioned before the smallest significant time unit that can be displayed is 10ms.

/Guenther