Post by email@example.com
I've not logged onto OpenVMS in about a decade so please bear with me.
We have a Itanium based OpenVMS where the time is approx 2 minutes
behind the actual time. Can anyone give advice on how to check where
this time is being sync'ed from and how to modify it it's wrong.
I can run SYS$SYSTEM:NCP but I'm not sure what to look at in this utility?
This whole thread is a wonderful example of where the OpenVMS
documentation and the system management user interface and the
implementation needs work.
Timekeeping is a common source of sometimes-subtle bugs and fodder for
broken assumptions and odd and often entirely unexpected — but correct
— behaviors, even when it all works right. But OpenVMS time
synchronization has to work better, has to be better integrated, and
has to require much less administrative overhead to get an OpenVMS
server configured and working and synchronized.
The documentation for a basic operating system function — timekeeping
and synchronization with a local or Internet time-base — is scattered
all over the place, between the base doc and the
still-inexplicably-unintegrated IP networking and the
why-are-these-products-still-around DECnet documentation, and related
bits around timezones and timekeeping and proper use of same are
scattered further afield between patch notes and the C Utilities Manual
— yes, there's a separate manual for utilities for C, though those same
utilities are now used for most of OpenVMS, and the DECdtss API
documentation that's now part of the OpenVMS doc set.
This ignores discussions around software updates and timezone updates
and any discussions of security or integrity in these areas. There
are more than a few NTP CVEs, after all. And it's not like proper
timekeeping isn't security-relevant, and isn't fundamentally part of
This also ignores the obvious discussions around the need for
simplification of this morass; of having reasonable defaults for the
NTP servers, around integration and simplification of IP in OpenVMS,
and of not having to find and manually edit text-based configuration
files to establish what is an absolutely fundamental operating system
There are always trade-offs inherent in the various design approaches
available, of course. Trade-offs around compatibility versus design
simplicity and ease of use versus design and coding effort versus user
effort versus risks of making changes, too. TANSTAAFL.
Maybe now some of you might better understand why other folks might not
share the same opinion of OpenVMS that's common among many folks here
in the comp.os.vms newsgroup?
Pure Personal Opinion | HoffmanLabs LLC