- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- DST Changed Twice
Operating System - OpenVMS
1752355
Members
5363
Online
108787
Solutions
Forums
Categories
Company
Local Language
юдл
back
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
юдл
back
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Blogs
Information
Community
Resources
Community Language
Language
Forums
Blogs
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-01-2009 02:27 AM
тАО11-01-2009 02:27 AM
DST Changed Twice
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
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
3 REPLIES 3
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-01-2009 03:19 AM
тАО11-01-2009 03:19 AM
Re: DST Changed Twice
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
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-01-2009 03:55 AM
тАО11-01-2009 03:55 AM
Re: DST Changed Twice
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.
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-01-2009 05:46 AM
тАО11-01-2009 05:46 AM
Re: DST Changed Twice
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.)
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.)
The opinions expressed above are the personal opinions of the authors, not of Hewlett Packard Enterprise. By using this site, you accept the Terms of Use and Rules of Participation.
News and Events
Support
© Copyright 2024 Hewlett Packard Enterprise Development LP