Operating System - OpenVMS
Showing results for 
Search instead for 
Did you mean: 

Cluster/System consolidation and timezones

Go to solution
Art Wiens
Respected Contributor

Cluster/System consolidation and timezones

I've been giving some thought to collapsing two clusters (3 Alpha's, 2 VAX's in one cluster 4 Alpha's, 4 VAX's in the other)into one cluster consisting of fewer "more powerful" members. Charon might play a part which would enable a "pure" Alpha environment. The locations these systems/applications serve are spread over 3 different timezones and the Operations center is in a forth.

The primary goals are to reduce "box count" to allow for a simpler DR strategy and as always to make things go faster.

I remember that mixing timezones between cluster members has been strongly discouraged in the past ... just wondering if this is any different in v7.3-x or v8.x? ie. a "locale" kind of setup.

Anyone have any experience with mixed timezone cluster members? Is it workable albeit probably unsupported?

Robert Gezelter
Honored Contributor

Re: Cluster/System consolidation and timezones


I would recommend adopting a single reference time zone for many reasons, not the least of which is the integrity of TOY timestamps in audit records.

If your applications use, or can be made to use the standard libraries, there are ways in which you can "personalize" the time translation to provide time zone localization (althrough, be careful to provide a way to change things if a user is not in their standard place).

Also, applications need to clearly mark the translated times with the appropriate time zone designator, otherwise mass confusion is a likely result.

I hope that the above is helpful.

- Bob Gezelter, http://www.rlgsc.com
Jan van den Ende
Honored Contributor

Re: Cluster/System consolidation and timezones


I am in a friday night mood, and I noticed from your profile:
"I have assigned points to 113 of 156 responses to my questions. "



some of those are already rather old.

-- maybe you can find some time to fixe up some loose ends? Even if you do think an answer deserves no points, then assigning 0 points will remove the "unassigned" flag.


Have one on me.

Don't rust yours pelled jacker to fine doll missed aches.
John Gillings
Honored Contributor

Re: Cluster/System consolidation and timezones


Different times or timezones within a cluster is not just "strongly discouraged", it's unsupported, and just plain doesn't work! There are numerous things that break when systems within a cluster have even relatively small amounts of clock drift.

Please make sure all nodes agree on the zone and current time.

As Bob suggested, you can use the locale services to deal with timezones at an application level.

Unfortunately time management is a fairly weak area in OpenVMS, and it's so deep in the kernel that it's pretty much impossible to fix. It would have been so much better to have the OS and all internal time stamps deal with pure UTC times, and then have per cluster/node/group/job/process/image imposition of time zones, but it's way too late to make that happen (please send any complaints to Mr Cutler ;-)
A crucible of informative mistakes
Robert Gezelter
Honored Contributor

Re: Cluster/System consolidation and timezones


Actually, you can get a good approximation with using UTC as the underlying time zone and formatting accordingly on input/output (which is not surprising considering the real use of UTC/GMT for international activities that require a lack of confusion about exactly "when is when").

The more complex problem is using a system with UTC as the underlying time standard, and letting users use local time. This is where confusion often enters the picture. One of the problems is: what happens when a user is in a different time zone, do you force him to use the normal zone, or the local zone.

Consider all of the places where cities are near time zone boundaries (e.g. Chicago), where commuters go back and forth across the time zone when they are at work or at home: Which zone is right?

What about when two users are speaking, one in Los Angeles (PST) and one in New York (EST)? The potential for confusion is impressive (which is why international navigation/aviation consistently ignores local time and uses UTC for all interactions).

A non-trivial topic in today's networked world. One can address it, but it does require some care on more than one level.

- Bob Gezelter, http://www.rlgsc.com
Uwe Zessin
Honored Contributor

Re: Cluster/System consolidation and timezones

Even small time differences of a few minutes between cluster memebers can be annoying, at least. Many have seen this when restarting jobs exactly at midnight and found later at the morning that jobs had run multiple times.

Other interesting effects I have seen when editing on one node and running MAKE/MMS on another one.

I'm sure, given sufficient time, we can come up with a lot more examples.