- Integrated Systems
- About Us
- Integrated Systems
- About Us
Dec 15, 4:00 am to 10:00 am UTC
Dec 14, 10:00 pm CST to Dec 15, 4:00 am CST
Dec 14, 8:00 pm PST to Dec 15, 2:00 am PST
10-28-2008 03:40 AM
Does anyone know about SYS$DST_DELTA_TIME logical name? What is the product/service create this logical name? I could find nothing about it.
The customer has a cluster but the servers have different values for this logical and he has problem with NTP synchronization after daylight_saving has been changed to 1.
The system is an I64 with OpenVMS v8.3-1h1 and TCP/IP for OpenVMS v5.6 Eco 2.
thanks in advance & regards
Solved! Go to Solution.
10-28-2008 03:49 AM
if the time has been changed has ntp been restarted on each of the servers as ntp won't synch with time differences over 1000 secs
10-28-2008 04:03 AM
Can't comment too much on the logical name. We had a similar problem with NTP synchronisation after a DST time change. We ended up having to restart and start the NTP client (our NTP client startup calls NTPDATE) to force the time to synchronise. NTP is very unhappy if the time changes too much in one go (about 10 mins).
We used the $SET_SYSTEM_EVENT to fire an AST when the TDF changed. I've attached a simplified Pascal version of what was implemented.
10-28-2008 04:27 AMSolution
Are these systems using NTP and expecting VMS to handle the DST change via SYSGEN's AUTO_DLIGHT_SAV trigger?
Please describe the "problem with NTP synchronization".
10-28-2008 06:02 AM
I did not expect a quick answers. Forum is great!
Unfortunately, Brazil no has a permanent DST rule, ie, each year the President determines a new date for DST. Some customers have peferred set time manually. They forget that some products/applications using Sys$posixrules, sys$timezone_daylight_saving and sys$timezone_differential. Servers have 3600sec of time differences. I'm going to correct timezone configuration.
I was worried about sys$dst_delta_time but I think I can deassign it.
Thanks for all & cheer
10-28-2008 07:44 AM
Why not just leave it alone? The JOB_CONTROL process may be upset if it goes to use it and finds it gone. I suspect that you've got SYSGEN's AUTO_DLIGHT_SAV set to 1 (else I doubt that it would be defined)? If so, then the JOB_CONTROL process will want to reset this value on January 1 and use and reset it on when you timezone rule says that DST change should occur. Since your DST rule change periodically, you may want to look into using the ZIC (zone info compiler) and building your own rule.
That logical is just defining an offset from the time that the JOB_CONTROL process last dealt with time change logic and the time of the actual change. You can examine the value using SDA
$ sh log SYS$DST_DELTA_TIME
"SYS$DST_DELTA_TIME" = "fffff9449a55b590" (LNM$SYSTEM_TABLE)
$ write sys$output f$getsyi("boottime")
SDA> eval/time fffff9449a55b590
That 8 days and 13 hours is the amount of time since the JOB_CONTROL process started during the last boot and our next DST change on 2-Nov @ 2:00.
On systems where I run NTP to manage the clock, I find that it works best all-around if I set AUTO_DLIGHT_SAV to 1 and let VMS manage the time changes but make sure that NTP is shutdown for (at least) the few hours surrounding the DST change.
10-28-2008 09:07 AM
There's a rule of thumb around that OpenVMS products and packages that overtly require management through logical names will probably have management interfaces somewhere between confusing and broken. (No, I'm not a proponent of management through logical names.) Few would council directly accessing nor altering these particular logical names other than with the @SYS$MANAGER:UTC$TIME_SETUP tool, FWIW.
10-30-2008 07:00 AM
I edited Southamerica. It was not easy task! I had included two lines but it did not work:
Rule Brazil 2008 max - Oct Sun>=15 0:00 1:00 S
Rule Brazil 2009 max - Feb Sun>=15 0:00 0 -
Then I changed two lines:
Rule Brazil 2000 2001 - Oct Sun>=8 0:00 1:00 S
Rule Brazil 2001 2006 - Feb Sun>=15 0:00 0 -
Rule Brazil 2000 max - Oct Sun>=15 0:00 1:00 S
Rule Brazil 2001 max - Feb Sun>=15 0:00 0 -
zic -v -d sys$common:[sys$zoneinfo.system] southamerica.
"SYS$DST_DELTA_TIME" = "ffffaae210c26428"
"SYS$LOCALTIME" = "SYS$SYSROOT:[SYS$ZONEINFO.SYSTEM.AMERICA]SAO_PAULO."
"SYS$TIMEZONE_DAYLIGHT_SAVING" = "1"
"SYS$TIMEZONE_DIFFERENTIAL" = "-7200"
"SYS$TIMEZONE_NAME" = "BRST"
"SYS$TIMEZONE_RULE" = "BRT3BRST2,M10.3.0/00,M2.3.0/00"
AUTO_DLIGHT_SAV is set to "1".
OpenVMS will automatically change to/from Daylight Saving Time.
(in time zones that use Daylight Saving Time)
LOCAL TIME ZONE = AMERICA / SAO_PAULO -- DAYLIGHT TIME
LOCAL SYSTEM TIME = 29-OCT-2008 17:05:25.49 (BRST)
TIME DIFFERENTIAL FACTOR = -2:00
TIME ZONE RULE = BRT3BRST2,M10.3.0/00,M2.3.0/00
Change BRT to BRST on the Third Sunday of October (19-Oct-2008) at 00:00
Change BRST to BRT on the Third Sunday of February (17-Feb-2008) at 00:00
"utc$time_setup show" only shows the current year. It's a problem, I need to explain to the customer that he will read the correct time (change BRST to BRT - 15-Feb-2009) in January 2009.
write sys$output f$getsyi("boottime")
OpenVMS system analyzer
SDA> eval/time ffffaae210c26428
Thanks for yours attention and support.
10-30-2008 07:27 AM
From the SYSTEM account:
$ STOP JOB_CONTROL
$ @SYS$SYSTEM:STARTUP JOBCTL