DST Changed Twice

[Jack Trachtman]

OpenVMS V8.3
V5.6 - ECO 3

A few minutes after DST changed back from 02:00 to 01:00, we shut down our system to let HP replace a bad component. We rebooted the system and it was back up before 02:00 Standard time. At 02:00 Standard Time, the system put out the msg:

%%%%%%%%%%% OPCOM 1-NOV-2009 01:00:00.10 %%%%%%%%%%%
Message from user SYSTEM on ALPHAI
%TDF-I-TDFSET, Summer time or standard time changeover - new
SYS$TIMEZONE_DIFFER

and reset the time back an hour! I had to scramble to manually correct it.

I know that VMS has an internal que entry to change the time, but I expected that after it changes the time the que entry would be deleted, which is why I waited for the original time change before shutting down. I didn't look at the que entries after I booted because I wasn't expecting a problem.

Can someone explain what happened?

TIA

[Richard Whalen]

In the MultiNet and TCPware code we refer to the extra hour in the day when DST ends as "the twilight zone" and create a file on disk to signify that the system is in this state so that if there is a reboot in that hour the clock doesn't get set back again.

I don't know what mechanism TCP/IP Services uses, but you seem to have run across a hole in their logic.

If the time change occurred due to the SYSGEN variable being set, then maybe you ran across a problem that is fixed in a recent patch:

VMS83A_PTHREAD-V0200
Pthreads Application Hangs During Seasonal Time Change

VMS83A_SYS-V1300
Add A New Data Cell To Maintain The System Time In UTC

VMS83A_TDF-V0100
Call The Appropriate System Service To Update The Time Differential Factor (TDF) During Seasonal Time Change

[Volker Halle]

Jack,

DST time change handling seems to be the most complicated problem in computer history ;-) And you only get 2 chances per year for testing, if you got it right !

If you are current on patches, log a call with HP, to give them a chance to find out what went wrong and FIX IT !

In general, don't try to do any major system work in that 'twilight hour', just let the systems run through it unchanged.

My attempt of an explanation is:

The TDF got changed the first time through the DST change and got stored correctly in a new version of SYS$SYSTEM:SYS$TIMEZONE.DAT. But during the 2nd boot, OpenVMS apparently did not recognize, that it was already running in standard time and did another DST time change.

The 'queue' entry you refered to is a TQE (Timer Queue Element) in the JOB_CONTROL process and does NOT survive a reboot. It will be re-created during startup and in that logic, something seems to have gone wrong.

Volker.

[Hoff]

That's clearly a nasty bug.

OpenVMS clearly doesn't know whether the switchover has been made or not. The box boots up in the window, and (without some outside indication, either a file or a bit in the clock/NVRAM or otherwise) doesn't know if the clock has been changed.

Approaches toward a solution?

Log a bug report with HP, or run the system set to UTC.

Or both.

And don't shut down during that hour, pending a fix.

OpenVMS Engineering was and is working within the constraints of the original mostly 30 year old design, and within the requirements for application compatibility, and (at least as far as V8.3-1H1) has not sufficiently overhauled the timekeeping code; with the ability to run the OpenVMS system clock (TOY/BB_WATCH) set to UTC, and to have the individual processes running with local time. (That's technically a fairly simple change, but the whole implementation can get hairy. And testing is really hairy, with all the different systems and with clustering and such.)