- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: DST change in EMEA
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-30-2010 05:31 AM
тАО10-30-2010 05:31 AM
DST change in EMEA
We are supporting few OpenVMS servers in EMEA region, they are following CET. Tomorrow morning the DST change is happening there. Im not sure whether the time change will happen automatically or not. Can you please list out all the ways in which they would have configured this to happen automatically?
I verified for any batch Jobs, its not there.
I verified for logical DTSS, that is also not there. I just want to be sure of things before we do it.
Also if we have to manually change it, I have planned to use the command $ set time = -1:00 Please correct me if im wrong.
Thanks,
Joe
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-30-2010 05:35 AM
тАО10-30-2010 05:35 AM
Re: DST change in EMEA
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-30-2010 06:01 AM
тАО10-30-2010 06:01 AM
Re: DST change in EMEA
> there.
You verified what, exactly, how, exactly?
> I verified for logical DTSS, that is also
> not there
You verified what, exactly, how, exactly?
As usual, showing actual commands with their
actual output can be more helpful than vague
description or interpretations. Around here,
for example:
ALP $ show logical dtss
%SHOW-S-NOTRAN, no translation for logical name DTSS
but:
ALP $ show logical dtss*
[...]
(LNM$SYSTEM_TABLE)
"DTSS$_SERVICE_ACTIVE" = "DECdts V2.0"
"DTSS$_TPTS_MBX" = "MBA31:"
[...]
> Os versions range from 5.5 to 7.3
Over a range like that, many things are
possible, and the details might depend on
many things, such as which IP software
product is used, whether DTSS is in use,
whether NTP is in use, and so on.
> [...] Please correct me if im wrong.
That also depends on many (unknown) things.
That SET TIME command looks legal, but it may
or may not be needed, and, if it is needed,
it may or may not be the only thing which is
needed.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-30-2010 06:53 AM
тАО10-30-2010 06:53 AM
Re: DST change in EMEA
for 5.x, 6.x, 7.0 and 7.1 most likely you WILL need SET TIME, UNLESS it is running DECnet WITH a DTSS time server.
The same MIGHT be true for 7.2 and 7.3, but those are also not unlikely to have NTP.
For 7.x without NTP, you will need to look at the SYSGEN param DAYLIGHT_TIME_SAVE (look at HELP to see how it does what for each version).
Extra care is needed when some database is running. Most of those do not like the ime to move backward, so shutting that down for the duplicate hour might be wise. Perhaps it is a little late now to check each one separately...
Good luck!
Proost.
Have one on me.
jpe
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-30-2010 08:38 AM
тАО10-30-2010 08:38 AM
Re: DST change in EMEA
For DTSS, this is the output on all of them
$ sho logi dtss*
(LNM$PROCESS_TABLE)
(LNM$JOB_80D81200)
(LNM$GROUP_000760)
(LNM$SYSTEM_TABLE)
(LNM$SYSCLUSTER_TABLE)
(DECW$LOGICAL_NAMES)
%SHOW-S-NOTRAN, no translation for logical name DTSS*
For Network product info please find below.
Compaq TCP/IP Services for OpenVMS Alpha Version V5.1 - ECO 3
on a AlphaServer DS10 466 MHz running OpenVMS V7.2-1
Digital TCP/IP Services for OpenVMS VAX Version V4.2 - ECO 5
on a VAX 6000-630 running OpenVMS V5.5-2
Digital TCP/IP Services for OpenVMS VAX Version V4.2 - ECO 5
on a VAX 6000-630 running OpenVMS V5.5-2
Digital TCP/IP Services for OpenVMS Alpha Version V4.2 - ECO 2
on a AlphaServer DS20 500 MHz running OpenVMS V7.1-2
And the sysgen Param, I cant find one..
SYSGEN> SHO DA
%SYSGEN-E-NOPARAM, no such parameter
SYSGEN> Exit
$ sho sys/noproc
OpenVMS V7.2-1
Please let me know, what else has to be verified...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-30-2010 08:55 AM
тАО10-30-2010 08:55 AM
Re: DST change in EMEA
sho logi dtss*
(LNM$PROCESS_TABLE)
(LNM$JOB_81AC5A00)
(LNM$GROUP_000001)
(LNM$SYSTEM_TABLE)
"DTSS$_SERVICE_ACTIVE" = "DECdts V2.0"
(LNM$SYSCLUSTER_TABLE)
So in this case what should I do?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-30-2010 09:05 AM
тАО10-30-2010 09:05 AM
Re: DST change in EMEA
NCL>show dtss all
Node 0 DTSS
at 2010-10-30-18:51:33.019+02:00Iinf
Status
Local Time Differential Factor = +0-02:00:00.000Iinf
Next TDF Change = 2010-10-31-02:59:59.999+02:00I0.000
Current Time = 2010-10-30-18:51:33.019+02:00Iinf
Uid = CFD57807-89C0-11DF-860C-AA0004000FAC
Last Synchronization = 2010-10-30-18:36:24.464+02:00Iinf
State = On
Characteristics
Error Tolerance = +0-00:10:00.000Iinf
Maximum Inaccuracy = +0-00:00:00.200Iinf
Servers Required = 1
Query Attempts = 3
LAN Timeout = +0-00:00:05.000Iinf
WAN Timeout = +0-00:00:15.000Iinf
Synchronization Hold Down = +0-00:10:00.000Iinf
Type = Clerk
Clock Adjustment Rate = 10000000
Maximum Clock Drift Rate = 100000
DNA Version = V1.0.0
DTSS Version = V2.0.0
Time Representation Version = V1.0.0
Global Directory = LOCAL:.DTSS_GlobalTimeServers
Automatic TDF Change = True
Clock Resolution = 976500
Counters
Creation Time = 2010-07-07-12:11:45.719+02:00Iinf
Local Times Not Intersecting = 0
Too Few Servers Detected = 17416
Too Many Servers Detected = 0
Protocol Mismatches Detected = 0
Time Representation Mismatches Detected = 0
Invalid Messages Detected = 0
Clock Settings = 0
Time Differential Factor Settings = 0
System Errors Detected = 0
Synchronizations Completed = 0
Enable Directives Completed = 1
Disable Directives Completed = 0
Insufficient Resources Detected = 0
NCL>
So no need to do anything in this server I believe.. Am I correct?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-30-2010 10:24 AM
тАО10-30-2010 10:24 AM
Re: DST change in EMEA
All the version 7.* are configured with NTP and I have verified the SYS$SYSDEVICE:[SYS0.UCX$NTP]UCX$NTP.CONF; or SYS$SPECIFIC:[TCPIP$NTP]TCPIP$NTP.CONF file, in that file the line
server xxxx.timeserv.com
is updated and this server is reachable from all the VMS servers. So I guess this should do the change automatically for me right?
The leftouts were 3 servers, 2 are version 5.5 (Charon VAX) they are in cluster and one is version 6.2. Im looking in to these servers now to find any clues..
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-30-2010 11:15 AM
тАО10-30-2010 11:15 AM
Re: DST change in EMEA
Or run Google, given this same thread arises every year.
Or read the OpenVMS FAQ, as there are some details there.
http://labs.hoffmanlabs.com/node/1
Or read the following article and then follow the Timekeeping topics around the site, given I've posted a number of topics on this timekeeping stuff:
http://labs.hoffmanlabs.com/node/72
http://labs.hoffmanlabs.com/taxonomy/term/57
I usually suggest tossing this timekeeping stuff out the airlock, and run with the system time set to UTC, and eliminate this mess. That also means you can get confused users, but the rest of the timekeeping mess goes away. (And I usually just tell them the server is located in another timezone, which is technically true.)
Do get rid of these VAX boxes. They're old, badly down-revision, and clearly somebody is foolishly looking to save some money by spending far more money saving that money. You've been tussling with this mess for a very long time. Get rid of it.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-30-2010 11:50 AM
тАО10-30-2010 11:50 AM
Re: DST change in EMEA
Joewee,
In addition to the responses already posted, for the 7.x systems where DAYLIGHT_TIME_SAVE exists, you'll need to verify the patch level and that the time zone is correctly set. If there have been any recent changes, where recent ranges from the operating system release to this year, in DST rules they may not be available on your system.
Second, do your applications support a dynamic time change? In some cases a vendor will specifically request a database be closed, especially for a backward time change.
Assuming your systems are on a local network, review the options for using SYSMAN to manage the time change on all nodes where a manual change is required. You can configure each system to allow for remote management and selecting groups of systems. See the System Management Utilities Reference Manual, http://h71000.www7.hp.com/doc/732final/6048/6048pro_005.html#sysman_part