topic Re: SYS$DST_DELTA_TIME in Operating System - OpenVMS

SYS$DST_DELTA_TIME

Carla P. Pinto — Tue, 28 Oct 2008 10:40:57 GMT

Hi

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
Carla Pinto

Re: SYS$DST_DELTA_TIME

marsh_1 — Tue, 28 Oct 2008 10:49:20 GMT

carla,

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

Re: SYS$DST_DELTA_TIME

Brian Reiter — Tue, 28 Oct 2008 11:03:34 GMT

Hi Carla,

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.

cheers

Brian

Re: SYS$DST_DELTA_TIME

Jim_McKinney — Tue, 28 Oct 2008 11:27:19 GMT

See Volker Halle's posting at http://groups.google.com/group/comp.os.vms/browse_thread/thread/49da4a489c83cb8f/ on 1-Nov-2007 1:06 regarding the SYS$DST_DELTA_TIME logical name. Different values on different cluster members for this logical name merely suggests that either the systems were booted at different times or that SYS$MANAGER:JBC$DST_COMMAND.COM was executed on one (or both at different times). It is expected that the value will differ from system to system.

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".

Re: SYS$DST_DELTA_TIME

Carla P. Pinto — Tue, 28 Oct 2008 13:02:41 GMT

Hi All

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

Re: SYS$DST_DELTA_TIME

Jim_McKinney — Tue, 28 Oct 2008 14:44:58 GMT

> I was worried about sys$dst_delta_time but I think I can deassign it.

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")
24-OCT-2008 12:21:55.00
$ anal/syst
SDA> eval/time fffff9449a55b590
8 13:36:33.43

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.

Re: SYS$DST_DELTA_TIME

Hoff — Tue, 28 Oct 2008 16:07:40 GMT

Here's how to roll your own timezone (TZ) and daylight saving time (DST) changes on OpenVMS:

http://64.223.189.234/node/148
http://64.223.189.234/node/560

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.

Re: SYS$DST_DELTA_TIME

Carla P. Pinto — Thu, 30 Oct 2008 14:00:23 GMT

Hi

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:

FROM:

Rule Brazil 2000 2001 - Oct Sun>=8 0:00 1:00 S
Rule Brazil 2001 2006 - Feb Sun>=15 0:00 0 -

TO:

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$manager:utc$setup_time

(LNM$SYSTEM_TABLE)

"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"

@sys$manager:utc$time_setup show

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")
29-OCT-2008 13:22:55.00

ana/sys

OpenVMS system analyzer

SDA> eval/time ffffaae210c26428
108 07:38:25.62

Thanks for yours attention and support.
Carla

Re: SYS$DST_DELTA_TIME

Jim_McKinney — Thu, 30 Oct 2008 14:27:29 GMT

One last thing - if you don't expect to reboot prior to that next DST change then you'll want to stop and restart the JOB_CONTROL process so that it picks up the new rule and schedules the DST change for the correct time.

From the SYSTEM account:

$ STOP JOB_CONTROL
$ @SYS$SYSTEM:STARTUP JOBCTL