Using SYSMAN in a DCL program to change the time...

[Matt Donlan]

...is ths possible?

On a cluster as well as a standalone node....

[Thomas Ritter]

Just use
$ set time/cluster

SET

TIME

/CLUSTER

Requires OPER and LOG_IO privilege, and in an OpenVMS Cluster
environment, SYSLCK privilege.

Sets the time on all nodes in a cluster to the same system time.
The format of the SET TIME /CLUSTER command is the following:

Format

SET TIME[=time] [/CLUSTER]

[Dave Gudewicz]

From Help on v7.3-2:

SET

TIME

/CLUSTER

This command is obsolete and is no longer documented. See the
online help for the CONFIGURATION SET TIME command in the System Management utility.

[Dave Gudewicz]

Forget my previous reply, it was incorrect.

Dave...

[Thomas Ritter]

Matt, your first post ? Are the replies worth any points ?

[Matt Donlan]

Sorry, still new to this, I'll submit the points...Thanks for the advice...what if I want to set time on two standalone nodes...something like set time XX:XX:XX /node= yyy, yyy...this syntax doesn't work, but is there something similar I can use to set the time on two standalone nodes using a DCL program?

Thnaks again!!!
Matt

[Hoff]

If you want to roll your own version of NTP or DECnet-Plus DTSS, have at. Just don't assume it's going to be nearly as easy as you might want.

The simplest is SET TIME/CLUSTER [time]

This command is fully supported (again), and documented in the manuals:

http://h71000.www7.hp.com/doc/83FINAL/9996/9996pro_223.html#brass_90

More involved home-grown solutions can involve locally-developed task-to-task DCL:

http://h71000.www7.hp.com/wizard/wiz_0159.html

If you develop your own time synchronization tools, you'll either have to decide to use the approach of resetting the time to the local value of "current" which can result in duplicate time values or time gaps, or you'll have to set up your own implementation of the mechanisms within OpenVMS used for drifting the time.

SET TIME and SET TIME/CLUSTER slam the time; these commands do not drift the values. Slamming the value forward or back can cause various problems. Usually minor. But once in a while, an application or a system component gets cranky -- during Y2K testing, the recommendation was to reboot with the new time. CMS gets cranky at 30 seconds skewage IIRC, and there are other change-sensitive components that were identified back during Y2K.

NTP and DECnet-Plus DTSS provide this synchronization, and various of the available time synchronization tools can drift the time, either slowing it down to drift it backwards, or increasing the speed to drift the time forward.

The OpenVMS APIs for drifting the time are documented, if decide to use that.

Then there are the usual herds of degenerate (error) cases, when you get a wacky value back from a time server, can't connect, or a corrupt message. What do you do for the error cases? Do you drift, do you use statistics to compare the differing clocks?

What would I do? I use NTP. (Every IP stack for OpenVMS I am aware of has NTP.) You can use it locally, or you can synchronize remotely. And there exist NTP daemons that can synchronize to GPS or WWV or other time-bases. If you choose DECnet-Plus DTSS, you can use the provided tools and can use an available API to write your own time-base connector. NTP works sufficiently well to meet my local needs, and I don't have to support the code when it doesn't. (But if you want to maintain your own NTP, source code is available over at U Del.)

If you need a time-base and are not network-connected, there are various options. Most will involve some sort of outside (and usually telephone or radio) connection, or you could go the cesium clock route.

There's a whole section on this topic in the OpenVMS FAQ -- there's a whole chapter on time and timekeeping on OpenVMS in that document. The master copy of the FAQ is over at the http://www.HoffmanLabs.com/vmsfaq/ site. And given the recent barrage of "fun" with US daylight saving time (DST) changes, I'm preparing the next Ye Olde FAQ update.