DST change in EMEA

[Joewee]

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

[Joewee]

Os versions range from 5.5 to 7.3

[Steven Schweda]

> 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]

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

[Joewee]

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]

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]

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]

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]

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]

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

[Hoff]

I suspect Andy was aiming at the AUTO_DLIGHT_SAV system parameter with that reference to DAYLIGHT_TIME_SAVE.

[tsgdavid]

I do not believe that there is any automatic daylight saving time change in the stated VMS versions (v5.5-2 through V7.2-1). The SYSGEN paramter AUTO_DLIGHT_SAV will not exist.

You should look for SYS$EXAMPLES:DAYLIGHT_SAVINGS.COM or some other procedure that has been used on the systems in the past to manually make this change. This command procedure invokes SYS$MANAGER:UTC$CONFIGURE_TDF.COM which I don't think will work on VMS 5.5.

As far as I know, you have to set the correct offset from GMT for most if not all of the previously mentioned facilities to set the correct time. If you simply set the system time NTP (for example) will reset the time back to the previous offset.

Dave Williams

[The Brit]

Given the amount of variation in your systems, and Network software, I would suggest that you do the following.

1. Shutdown your Primary applications ~15 minutes before the time change is scheduled to occur.

2. If any of your systems are running NTP, then stop the service.

3. Wait until ~30 minutes after the time change was due to take place and then just check your systems to see what actually happened (in most if not all cases I would expect the answer to be nothing.) Now set the time to the correct (new) time.

4. Execute

@SYS$MANAGER:UTC$TIME_SETUP "" "RULE"

on all nodes where the time was changed. This will reset the TimeZone Logicals and time differentials.

(I cant guarantee that this procedure exists on the older versions of OpenVMS. (My hair is grey, my eyes are dim, etc. etc.)

5. When you are satisfied that the system times are correct, restart your apps.

Dave.

[Jan van den Ende]

Dave & Dave:

As the Dutch say: "That is serving mustard after the meal has been eaten".

It was needed in the night from 30 to 31 october....

Proost.

Have one on me.

jpe

[tsgdavid]

> As far as I know, you have to set the
> correct offset from GMT for most if not
> all of the previously mentioned facilities
> to set the correct time. If you simply set
> the system time NTP (for example) will
> reset the time back to the previous offset.

Assuming that your VMS 5.5 system does not have NTP or DTSS running or anything else that cares what the TDF (offset from GMT) is it might be safe to just use the SET TIME= command to set the current system time on that one system. If you have a way to set the TDF, you should do so in case anything cares. For example, C language RTL routines may return the wrong local time if the TDF is incorrect even when the system time is correct.

Dave

[Joewee]

Thanks everyone for your time and input on this.

Every server in this environment was configured with NTP. Except one which had DTSS

I assumed that NTP would do the time adjustments by syncing with the time server and I waited for few minutes but it did not happen.

Then I went through some documents from HP which clearly mentioned that NTP will not take care of DTS time change, and it should be done manually by running the script " sys$examples:DAYLIGHT_SAVINGS.COM;1".

I ran this script which did the work for me and also it mentioned that I need to restart NTP service after doing that, coz if the time difference is more than few seconds the sync will be lost with the time server it seems, so I restarted NTP. Everything was fine.

Only in version 5.5 this procedure was missing "sys$examples:DAYLIGHT_SAVINGS.COM;1"
I had to go in to the sysman and set cluster environment and in sysman> configuration set time "-01:00".

Today morning the business started and everything went on perfectly normal.

Thanks again for all your inputs.