Alpha Open VMS 7.3-1 Daylight Savings Time Change Patch

[Russ Miller Jr]

Is a Daylight Savings Time Change patch available for the HP Alpha Open VMS 7.3-1 system?

Specifics:

We have HP Alpha Open VMS 7.3-1 systems installed since early 2003 (and not patched up to date after initial HP installation).

Changes to and from DST and EST are successfully accomplished using the Alpha Open VMS SYSGEN Parameter AUTO_DLIGHT_SAV (set to a value of 1); the related logical SYS$TIMEZONE_NAME to trigger our applications.

We use an internal time network server and employ TGV Multinet RDATE to synchronize the clocks daily.

We have DECNET (DVNETEND); and employ the TGV Multinet IP stack (rather than UCX).

If no V7.3-1 patch, what do you recommend for getting our Alpha Open VMS system to trigger using the new time change dates in the USA?

Thanks.


Russ Miller Jr

[Dave Gudewicz]

There will not be a v7.3-1 DST patch.

I hear that Process Software is soon to make DST patches available for their MultiNet products. Perhaps that will work for your configuration.

Dave...

[Andy Bustamante]

You can create your own timezone definitions, see the VMS FAQ for more details, http://h71000.www7.hp.com/faq/vmsfaq_006.html
Depending on your business requirements, you may be able to justify upgrading to 7.3-2 at least since it will be under prior version support.

Andy

[Hoff · Accepted solution]

Hello! Welcome to the forums!

Management of the daylight saving time switch-over?

OpenVMS is very likely managing the DST switch-over here, and probably not the Process (TGV) Multinet. The TCP/IP Services and DECnet packages both depend on OpenVMS to manage the time and the DST switch-over, as of V7.3. Most NTP systems synch (only) the time based on a UTC time base, the daylight saving time and local time stuff is typically handled on the local system. (I don't know that the Multinet stuff to confirm this behavior and that Multinet uses the OpenVMS TDF and DST bits, but I do suspect it.)

The most obvious approach here is to get to V7.3-2, and apply current ECOs. If you don't use that approach, yes, you'll be rolling your own TDF updates per the FAQ, and running whatever testing you deem appropriate.

Other approaches include shutting off the automatic DST entirely, and using DAYLIGHT_SAVINGS.COM or other such for a traditional manual switch-over; using classic DST handling. Submit the change-over to batch, for instance.

Here are the official HP OpenVMS DST sites:
http://h71000.www7.hp.com/dst.html
http://h18012.www1.hp.com/java/alpha/DST-US.html

Here are some of the various threads from comp.os.vms:
http://groups-beta.google.com/group/comp.os.vms/search?q=dst
http://groups-beta.google.com/group/comp.os.vms/browse_thread/thread/7988ba3a8d815891

Here are some recent URLs from here in ITRC that might be helpful in your investigation:

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=1089399
http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=1089740
http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=1087761

And FWIW, the OpenVMS FAQ is now mastered at www.HoffmanLabs.com/vmsfaq/ -- what's posted at the HP site was two or three editions back when I last looked. There have been TDF and DST updates in the subsequent editions of the FAQ.

Whatever approach you choose here, you'll want to test it -- particularly if there are production uptime requirements involved.

Stephen Hoffman
HoffmanLabs

[Sebastian Bazley]

Ignoring DST is fine for current time, but unless the TZ files are correct, future (or past) times may not be properly interpreted.

[Russ Miller Jr]

Thankyou to all whom responded.

Every answer was useful in determining our actions regarding DST. I will let you all know our success!


Regards,


Russ Miller Jr

[Sebastian Bazley]

Last time I checked, the VMS 7.3-2 patch VMS732_TZ-V0300 was the only TZ patch so far released - for any version of VMS - to cover all the latest TZ changes.

Although it cannot be installed on 7.3-1, you might find some of the files in it useful...

[Hoff]

The off-by-an-hour issue is a good point. Reason enough to run a few tests, certainly.

As for the definitions and the ECO kits, the "official" TZ definitions can and will change regularly. While many sites in the US have not needed to alter local time, changes to time and timezones are quite common and have caused local sites to change local DST definitions. This is the first time that I can recall OpenVMS engineering having released a TZ-related ECO kit. OpenVMS has regularly uploaded new TZ definitions for incorporation in new releases, and various HP customer support centers have managed these TZ matters locally. (The HP Sydney CSC has gotten good at it, given the numbers of changes made to the "official" TZ rules specifically for Australia.)

C and C++ applications that use timezones and that look backward across time and that are using C-format timekeeping values can be off by an hour in what is reported. Many folks probably wouldn't even notice that. Unix manages its values as values since the epoch, and this C converts upon display. (This can be related to the classic off by an hour discussion; see the FAQ and elsewhere for details on that.)

AFAIK the OpenVMS system service applications do not make use of historical definitions for older values, save for UTC-related conversions that applications might call. OpenVMS stores native time as local time, and displays same as local time. This implementation difference is why the C problem reports will regularly cite the one-hour difference. C has its epoch and its time conversions and time management, and OpenVMS has its own mechanisms.

The central OpenVMS use of the timezone definitions is to manage the switch-over itself, based on a little hackery underneath JOBCTL, and to generate the DST event available on newer releases. This to help out C and other clients, and applications that use C or other conversions between UTC and local. But the core of OpenVMS time and timekeeping hasn't really changed since its inception circa 1977.

If you've got the opportunity in the code, I'd tend to avoid both the C epoch notation and the OpenVMS quadword, and use the UTC notation, or the opaque UTC format. And in any case, run a few tests. Things can and do occasionally go seriously weird.

[Geoff Bryant.]

Since you specify MultiNet, there are ecos that will be released soon.

[Russ Miller Jr]

Just to let all know results of TZ rule update and testing on our Alpha open VMS7.3-1 systems.

Our objective was to have automatic time change continue to work and the appropriate system time logicals correctly defined indicating EST or EDT, etc.

This objective was achieved as indicated by our testing.

As someone had suggested, I extracted some of the pertinent,updated US time rules and source (US_EASTERN.; US_CENTRAL, US etc., NORTHAMERICA.;) from the VMS732_TZ_300 patch kit. Placed these files into the appropriate sys$common:[sys$zoneinfo.system.us] or [...system.sources]

Configured and installed the new US_EASTERN time rule (in our eastern US case) using sys$manager:UTC$TIME_SETUP. Tested for automatic EST<->EDT change over on second Sunday in Mar and first Sun in Nov without sign of any problems. Also tested to be sure no problems after one hour, or on the previous old dates.

NOTE: We do not use DECNET PLUS or DTSS functionality. We will eventually upgrade our VMS to a supported version. This was a "STOP GAP" measure as we persue our VMS upgrade options.

We wanted to have the VMS automatic time change continue to work on our alpha 7.3-1 systems, along with the correctly defined system time logicals indicating EST or EDT, etc.

Thanks to all for your assistance.


Regards,


Russ Miller

[Dave Gudewicz]

Russ,

Thanks for posting your test results.

Dave...

[Ian Miller.]

HP have now made the TZ files available

http://www.openvms.org/stories.php?story=07/02/08/6646402