Operating System - OpenVMS
cancel
Showing results for 
Search instead for 
Did you mean: 

DAYLIGHT_SAVINGS.COM not working?

 
SOLVED
Go to solution
Clark Powell
Frequent Advisor

DAYLIGHT_SAVINGS.COM not working?

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
6 REPLIES 6
Hoff
Honored Contributor
Solution

Re: DAYLIGHT_SAVINGS.COM not working?

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
Frequent Advisor

Re: DAYLIGHT_SAVINGS.COM not working?

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
Honored Contributor

Re: DAYLIGHT_SAVINGS.COM not working?

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
Honored Contributor

Re: DAYLIGHT_SAVINGS.COM not working?

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.
Highlighted
Clark Powell
Frequent Advisor

Re: DAYLIGHT_SAVINGS.COM not working?

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
Valued Contributor

Re: DAYLIGHT_SAVINGS.COM not working?

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.
Sr. Systems Janitor