DAYLIGHT_SAVINGS.COM not working?

[Clark Powell]

I ran sys$examples:DAYLIGHT_SAVINGS.COM to create DST$CHANGE.COM which was supposed to set the system to Pacific Standard Time. I have been tesing this on a spare system (set to Nov 1 2am, and I notice that the logicals are not being set. Should I expect this? If not what might fix it? The unchanged logicals are below:

"SYS$TIMEZONE_DAYLIGHT_SAVING" = "1"
"SYS$TIMEZONE_DIFFERENTIAL" = "-25200"
"SYS$TIMEZONE_NAME" = "PDT"
"SYS$TIMEZONE_RULE" = "PST8PDT7,M3.2.0/02,M11.1.0/02"

thanks
Clark Powell

[Hoff · Accepted solution]

So what exactly did you do here? Did you set the system time to 2am directly, or did you roll through that time?

What is the OpenVMS platform and the OpenVMS version?

Is the test box current on its ECO kits? There are ECOs out for DAYLIGHT_SAVINGS.COM and DST (and other) stuff.

Did you reboot with the new time set or did you try resetting the time "hot"? (The former is strongly encouraged. The latter tends to cause problems.)


Remember that UTC$TIME_SETUP.COM is your best friend here; direct modifications to the logical names or knobs or files or anything else are generally best avoided.

The AUTO_DLIGHT_SAV system parameter and its underlying mechanisms can and does work, if you're on a sufficiently recent OpenVMS release or patched to current.

Reading:

http://labs.hoffmanlabs.com/node/72
http://labs.hoffmanlabs.com/node/560

[Clark Powell]

OpenVMS 8.3
update 8

In my test I am setting the time ahead to after 2am Nov 1 pdt and then running daylight_savings.com and then running dst$change.com. I am expecting the logicals and the time to change but sometimes only the time changes and sometimes half the logicals change. In the real event I will reboot after I follow the above steps.


You suggested that I set the time and reboot and that it made a difference when I set the time back. Should I reboot after 2am standard? or after 1am standard?

thanks
Clark Powell

[Hoff]

Boot OpenVMS with a time set prior to the transition window, and let the box sequence itself through the change-over.

The use of the system parameter SETTIME can be useful in this and similar contexts.

Setting the running time forward or backward by even an hour "hot" has caused various issues over the years. This matter was at the core of the HP recommendations around rebooting as part of Y2K testing, for instance.

Do look to use SETTIME and AUTO_DLIGHT_SAV here, too.

And try not to use manual processes.

[Volker Halle]

Clark,

all the OpenVMS systems I'm taking care of are using AUTO_DLIGHT_SAV=1 and managed the time change fine last weekend (CEST -> CET) over here.

I'm only using DAYLIGHT_SAVINGS.COM on older systems (mostly VAXes), where this new system parameter is not available.

Volker.

[Clark Powell]

I am getting more appropriate results now if I reboot. Thanks.

As for AUTO_DLIGHT_SAV I am using DAYLIGHT_SAVINGS.COM because I had such bad results with AUTO_DLIGHT_SAV last year. If one reboots after the change one might see the hour set back TWICE and then have to set manually to the correct setting. If I have to be awake and I have to reboot, (I do,) I might as well do it manually rather than take a chance on the automatic software that fails during reboots.

Anyway, I've got the DAYLIGHT_SAVINGS.COM working now so I'll go with that.
thanks
Clark Powell

[Richard W Hunt]

I have the AUTO_DLIGHT_SAV set to 0 on four systems. I verified before the weekend that the logicals were set up correctly by running the @SYS$MANAGER:UTC$TIME_SETUP command to SHOW the logicals. All were correctly setup.

However, the two systems that actually changed time settings were running DTSS$CLERK whereas the systems that needed manual intervention were not. Had NOTHING at all to do with AUTO_DLIGHT_SAV SYSGEN settings.