OpenVMS 8.3 DST

[Bob Hoadley]

Has anyone had issues with time moving forward 1 hour after booting in the 2 week timeframe before 1st Sat in November? I have a customer where the timezone patches were applied when they were v7.3-2, but have since upgraded to 8.3, and the timezone patches were removed. From what I understand, the timezone changes are in 8.3. Now I am wondering if we need to run the @sys$manager:utc$time_setup.com after upgrading to v8.3 even though it looks correct?

[Hoff]

Are you having an issue, or are you asking whether you should expect an issue.

If the former, please elaborate.

If the latter, you should need do nothing here.

Regardless, there are seemingly always issues here and there with timezone and timezone settings.

If you want to see what is going on with your system, here are details around how to decode the unnecessarily cryptic command displays:

http://64.223.189.234/node/560

And the usual rules apply: apply the current relevant and mandatory ECO kits, don't mess directly with the logical names, and always vote against any elected official that supports any alterations to DST other than its complete and unconditional elimination. :-)

[Bob Hoadley]

Thank you for responding. Yes, we had a problem at one site who booting this morning in the 2 week period before 11/2/08. They're Eastern time, and the time on the system was 1 hour ahead. I had already checked to ensure they were setup correctly:
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 = US / EASTERN -- DAYLIGHT TIME
LOCAL SYSTEM TIME = 27-OCT-2008 10:09:32.83 (EDT)
TIME DIFFERENTIAL FACTOR = -4:00
TIME ZONE RULE = EST5EDT4,M3.2.0/02,M11.1.0/02
Change EST to EDT on the Second Sunday of March (9-Mar-2008) at 02:00
Change EDT to EST on the First Sunday of November (2-Nov-2008) at 02:00
Last year we were told to run the utility @sys$manager:utc$time_setup.com after applying the patches for vms 7.3-2. Now they are at vms 8.3, and we had the boot problem again. Any ideas?

[Hoff]

Is the system on current patches? There is a TZ patch and an update patch available. (I can't tell if the update patch includes the TZ patch right now as the HP ftp server is tossing errors; too many users are reportedly connected.)

And if you're interested in that DCL procedure, well, run it and see if it helps. Worst case, it won't do anything beyond messing up the system time. Best case, it fixes this. But I'd (still) start with the ECO kits.

I believe in entirely avoiding DST in most any OpenVMS-based production environments.

[Bob Hoadley]

We did run it this morning. Thank so much for your input!

[EdgarZamora_1]

This same problem just happened to me 10 minutes ago. I installed latest patches on Alpha OVMS 8.3 and rebooted and the time jumped ahead by an hour. Here's the operator log:

%%%%%%%%%%% OPCOM 27-OCT-2008 15:29:05.38 %%%%%%%%%%%
Message from user SYSTEM on CLCC
TDF-I-SETTDF TDF set new timezone differential

%%%%%%%%%%% OPCOM 27-OCT-2008 16:29:05.42 %%%%%%%%%%%
Message from user SYSTEM on CLCC
%TDF-I-TDFSET, Summer time or standard time changeover - new SYS$TIMEZONE_DIFFERENTIAL=-18000/old=-21600.

I'm looking into it further.

[EdgarZamora_1]

So here's something that I missed in the notes for VMS83A_UPDATE-V0700 (may have been in previous updates too):

7.5 Special Installation Instructions:


o VMS83A_TZ-V0100

The VMS83A_TZ-V0100 daylight savings kit is being removed
permanently from this and future UPDATE kits. This kitting
change is being made given the global variation in timezone
rules, and knowing that some customers have local patch
changes. This change will protect customers from having local
patches overwritten by the UPDATE kit.


I'm wondering if the TZ patch installed in previous update kits is removed by installing the newer update kit. Anyway I will re-apply VMS83A_TZ-V0100 to be sure.

[Bob Hoadley]

The system was booted this morning and the system time moved ahead 1 hour. HP says this is a known corruption issue with the file SYS$SYSTEM:SYS$TIMEZONE.DAT. They do not know what causes the corruption. This is what is known:
â ¢ It can happen on the accounts we applied the DST patches to - OpenVMS v 7.3-2 and v8.3
â ¢ Affects systems anytime meaning it is not related to this 2 week period of the DST change
â ¢ When the system is booted and the system looks in this fie, it thinks the time is before the spring clock change, so it moves forward 1 hour
â ¢ The fix is needed, otherwise every time the system is booted, the clock will move forward 1 hour
â ¢ There is no way of knowing if a system has this corruption until the time is moved forward an hour after a system boot
To fix the problem is to do the following:
1. Copy one of the corrupted files and send it over to be so I can sent it to HP for further investigation.
2. SET DEF SYS$SYSTEM
3. DELE/CONFIRM SYS$TIMEZONE.DAT;*
4. @SYS$MANAGER:UTC$TIME_SETUP.COM - Run the utility for the timezone that customer is in
The next time the system boots it should set the clock correctly.