1748092 Members
5705 Online
108758 Solutions
New Discussion юеВ

Re: DST change in EMEA

 
Joewee
Regular Advisor

DST change in EMEA

Hi,

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
15 REPLIES 15
Joewee
Regular Advisor

Re: DST change in EMEA

Os versions range from 5.5 to 7.3
Steven Schweda
Honored Contributor

Re: DST change in EMEA

> I verified for any batch Jobs, its not
> 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.
Jan van den Ende
Honored Contributor

Re: DST change in EMEA

Joe,

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
Don't rust yours pelled jacker to fine doll missed aches.
Joewee
Regular Advisor

Re: DST change in EMEA

Very sorry for not providing enough information:

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...
Joewee
Regular Advisor

Re: DST change in EMEA

In one node which is in a different site I found this.

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?
Joewee
Regular Advisor

Re: DST change in EMEA

And the full information of that is

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?
Joewee
Regular Advisor

Re: DST change in EMEA

Sorry to pile up this thread with my comments. Im kind of running out of time so lil nervous, since im not prepared for this. I have drilled down to this point.

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

Re: DST change in EMEA

Call in help.

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.
Andy Bustamante
Honored Contributor

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

If you don't have time to do it right, when will you have time to do it over? Reach me at first_name + "." + last_name at sysmanager net