SYS$EXAMPLES:DAYLIGHT_SAVINGS.COM

[The Brit]

Hi Guys,
Does this command file care which TCPIP product you are running???

[NOTE: I have a three node cluster with 2 nodes running TCPWare and 1 node running TCPIP Services.]

OpenVMS version is 7.3-2 (fully patched up to ~1 month ago)
TCPWare is version 5.7-2.

All systems have NTP service running with 1 TCPWare node synching to external time server, and other two synching to node 1.

I would really like to be able to use the above script (via sysman) to do the EST -> DST transition on all three nodes simultaneously.

Thanks

Dave.

[Jim_McKinney]

I find that NTP does not appreciate some other changing the clock on it while it thinks that it needs to handle a DST change. To wit, I opt for disabling NTP prior to a time change and then enabling it once again a couple of hours (or more) later after I have permitted VMS to change the time. (You could substitute "SYS$EXAMPLES:DAYLIGHT_SAVINGS.COM" for "VMS" in my previous sentence.)

Later, you might investigate the SYSGEN parameter AUTO_DLIGHT_SAV as well.

[Volker Halle]

Dave,

you should consider using the OpenVMS mechanism for DST change available since V7.3 by setting the system parameter AUTO_DLIGHT_SAV = 1.

This works fine with NTP. NTP exchanges the date/time in UTC time, which does not jump and as long as you change the local time and the timezone DST attribute, this should provide no problem for NTP.

Volker.

[Jim_McKinney]

My experiences are with Process Software's IP stacks - I have not used NTP with HP TCP/IP and don't know if that NTP port differs.

That out of the way, what Volker says about NTP using UTC is correct - and his conclusion seems logical too. In fact it's that the same one I had until experience taught me otherwise. There are a few subtleties in the NTP code that deal with the time in the hour adjacent to the time change that are there to prevent multiple time changes (primarily when "falling back"), handle slewing the clock rather than stepping it, and to deal with the case where the system crashes during this time. Some call this hour the "twilight zone". Those interested can read a discussion in the google archives - http://209.85.165.104/search?q=cache:nl3zu4eKhCIJ:lists.ntp.isc.org/pipermail/questions/2006-June/010516.html+&hl=en&ct=clnk&cd=2&gl=us .

[Jim_McKinney]

My experiences are with Process Software's IP stacks - I have not used NTP with HP TCP/IP and don't know if that NTP port differs.

That out of the way, what Volker says about NTP using UTC is correct - and his conclusion seems logical too. In fact it's that the same one I had until experience taught me otherwise. There are a few subtleties in the NTP code that deal with the time in the hour adjacent to the time change that are there to prevent multiple time changes (primarily when "falling back"), handle slewing the clock rather than stepping it, and to deal with the case where the system crashes during this time. Some call this hour the "twilight zone". Those interested can read a discussion in the google archives - http://209.85.165.104/search?q=cache:VAut7-oBrjcJ:lists.ntp.isc.org/pipermail/questions/2006-June/010533.html+%3F&hl=en&ct=clnk&cd=2&gl=us .

[Hoff]

If you're not set AUTO_DLIGHT_SAV (which is the easiest), you'll have to run the DAYLIGHT_SAVINGS.COM procedure or an analogous manual change.

Here is some background on time and timekeeping on OpenVMS:

http://64.223.189.234/node/72
http://64.223.189.234/node/560

Packages that are compliant with the OpenVMS V7.3 APIs defer TZ management to OpenVMS and its TZ definitions. Current DECnet-Plus and TCP/IP Services work with this, and (very likely, given the caliber of the guys working over there) Process IP stacks all have this.

[The Brit]

Thanks