Let's do the time warp again ! - End of summer time 2004

[Ian Miller.]

Any reports of things going wrong this time? Are threaded apps, DCPS and JAVA all behaving themselves now? Did the most recent TDF patch stop all known bugs?

Share your experiance here for the benefit of all.

(I will find out on Monday what worked and what did not as I'm not on call this weekend :-)

[David B Sneddon]

I use the old SPRINGFOR/FALLBACK stuff from days
long gone... they provide a gradual time change
No problems here.

Regards
Dave

[John Gillings]

Ian,

No apparent problems on any of our internal systems, and no problems reported to the CSC this year (so far?). Though, down here, we're gone forward, which tends to be less of a problem than turning time backwards.

My personal opinion is that "automatic" daylight savings time adjustements are far more work than just setting the clocks manually! Instead of just setting the clock, you have to make sure the automatic system is correctly set, and check that it worked at the right time.

spring_forward.com
$ SET TIME="+0-1:0"

$ SUBMIT/AFTER="30-OCT-2004 02:00" spring_forward

[DICTU OpenVMS]

This year it almost went ok... Just don't forget to set the auto_dlight_sav parameter ;-) The systems that had the system parameter set, went 1 hour back and untill now everything seems fine. The other systems we had to set by hand...

[Jan van den Ende]

So,

it looks like I am the first to report an issue.

- 1 cluster, 7.3-2, TCP/IP 5.4 ECO-2
2 sites, 2 nodes per site. All 4 NTP running, AUTO_DLIGHT_SAV = 1

At 2:58 MC SYSMAN /ENV=CLUSTER DO SHO TIME:
4 times 2:58

3 minutes later same command:
1 site, bath nodes 2:01, other site both nodes 3:01

Be patient, time to go to sleep long past anyway:

At 2:20
1 site 2:20, other site 3:20.
NTP logfiles show no exception whatsoever.

So, I decided to do it by hand.

On node with correct time
MC SYSMAN /ENV=CLUS
DO CONFIG SET TIME

Everything look OK now.

And now for the real surprises:
The NTP logfiles on the nodes that WENT OVER AUTOMATICALLY report SYNCRONISATION LOST after time change, and thereafter report TIME SLEW 3600 secs (+- few /00 secs);
and still have TIME DIFFERENCE 7200 (summer difference); the nodes that were forced by hand report NOTHING exceptional, and time difference in correct at 3600.

We are completely baffled, and already have decided that next year (again) we will NOT let it go unattended. :-(


Cheers.

Have one on me.

Jan

[Volker Halle]

We had some systems (V7.3-2 running DTSS client) change to normal time (MET) one week too early, because the timezone rule was bad:

"SYS$TIMEZONE_RULE" = "MET-1MET DST-2,M3.4.0/02,M10.4.0/03"

And this year, M10.4.0/03 (= 4th sunday in October) was one week too early. After running @UTC$TIME_SETUP, the correct timezone rule had been set up:

MET-1MET DST-2,M3.4.0/02,M10.5.0/03

and the automatic switch worked fine this weekend (M10.5.0 = LAST sunday in October).

But when looking forward at the switch to DST next March, the rule is still incorrect, as it should say M3.5.0/02 for MET (last sunday in march) - although it won't matter next year (4th sunday = last sunday). Anybody agree ?

Volker.

[Volker Halle]

Jan,

did you check for OPCOM messages ? I've had success with 2 nodes (E8.2 Alpha and Itanium, NTP client, AUTO_DLIGHT_SAV=1)

%%%%%%%%%%% OPCOM 31-OCT-2004 03:00:00.25 %%%%%%%%%%% (from node I64VMS at 31-OCT-2004 02:00:00.25)
Message from user SYSTEM on I64VMS
%TDF-I-TDFSET, Summer time or standard time changeover - new SYS$TIMEZONE_DIFFERENTIAL=3600/old=7200.

Nothing unusual in TCPIP$NTP_RUN.LOG

Volker.

[Antoniov.]

Ian,
like John I use a command file to change time. No problem.
I'd like known better how system manage timezone :-)

Antonio Vigliotti

[Ian Miller.]

Here on pre V7.3 systems not running DECnet/OSI I schedule a batch job which stops NTP and does
$ if f$search("SYS$MANAGER:UTC$CONFIGURE_TDF.COM") .NES. ""
$ THEN
$ @SYS$MANAGER:UTC$CONFIGURE_TDF.COM SET 0 -60
$ ELSE
$ SET TIME="-01:00"
$ ENDIF

then restarts NTP if it was running.

this seems to work for me.

[Dieter Rossbach]

My two DEBIAN systems changes the time correctly. but my MVS systems ....

All my test systems are on VMS 7-3.2, latest patch level, some hat the correct time, some didn't, but that had nothing do do with sys$timezone-differential (one correct system had 3200, the other had 7200) or with auto_dlight_save (on of the correct systems had 0, one with the wrong time had 1)

On my costumer systems, I did all by hand (no: by command procedure)

Regards

Dieter