- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: SYS$DST_DELTA_TIME
Categories
Company
Local Language
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
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
Community
Resources
Forums
Blogs
- 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
тАО10-28-2008 03:40 AM
тАО10-28-2008 03:40 AM
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
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-28-2008 03:49 AM
тАО10-28-2008 03:49 AM
Re: SYS$DST_DELTA_TIME
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-28-2008 04:03 AM
тАО10-28-2008 04:03 AM
Re: SYS$DST_DELTA_TIME
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-28-2008 04:27 AM
тАО10-28-2008 04:27 AM
SolutionAre 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".
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-28-2008 06:02 AM
тАО10-28-2008 06:02 AM
Re: SYS$DST_DELTA_TIME
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-28-2008 07:44 AM
тАО10-28-2008 07:44 AM
Re: SYS$DST_DELTA_TIME
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-28-2008 09:07 AM
тАО10-28-2008 09:07 AM
Re: SYS$DST_DELTA_TIME
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-30-2008 07:00 AM
тАО10-30-2008 07:00 AM
Re: SYS$DST_DELTA_TIME
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-30-2008 07:27 AM
тАО10-30-2008 07:27 AM
Re: SYS$DST_DELTA_TIME
From the SYSTEM account:
$ STOP JOB_CONTROL
$ @SYS$SYSTEM:STARTUP JOBCTL