Operating System - OpenVMS
1748023 Members
4105 Online
108757 Solutions
New Discussion юеВ

Re: Time Change - Cluster alias

 
Mallkeet
Occasional Contributor

Time Change - Cluster alias

Hi

Have a 3 node(gs1280) VMS 38.3 cluster with TCPIP service 5.6 ECO3 running TCPIP failsafe. The apps running on the cluster needs to shutdown during time change on 3rd April and advise from the app vendor is to also shutdown tcpip failsafe as ""thereтАЩs a risk at the moment of time change that the heartbeat sent will trigger a cluster alias ip move"" -- which seems a bit odd but can this happen at a VMS/TCPIP/FAILSAFE level.

In the past have never shutdown any TCPIP service

There is cluster alias defined and time change will happen automatically AUTO_DLIGH_SAV=1

Thanks in advance
4 REPLIES 4
Hoff
Honored Contributor

Re: Time Change - Cluster alias

You can stop trying to understand this and do what the vendor tells you to do, or you can ask the vendor for additional information, or you can ignore the vendor's advice.

If you ignore the vendor, you get to deal with whatever the vendor has encountered here, should the case the vendor is concerned over crop up, or should there be some other switch-over error arising here.

I don't (usually) see a big issue with the cluster alias moving, but then there could be an odd and application-specific issue with the cluster operating in a degraded mode, or with the application restarting with a different configuration than what was present when the application shut down. That's what you pay the vendor to know.

Or you can shut down the whole of the cluster (local applications and IP and VMS), switch the whole environment over to UTC, and configure to ignore this particular governmental stupidity. (UTC is usually the best solution from an operational perspective. Do not use local time for anything.)

Yes, the IP alias can move. The application would need to deal with that. It appear that your vendor either knows something about the application handling of the cluster alias, or they're getting confused. (But in either case, it's easy enough to shut down IP, this assuming you have remote console access via serial line or MP or whatever, or you have a DECnet or LAT path into the cluster.)
John Gillings
Honored Contributor

Re: Time Change - Cluster alias

There was once a time when all you had to do was adjust your clock twice a year. Then it got "automated"! ;-)
A crucible of informative mistakes
Steve Reece_3
Trusted Contributor

Re: Time Change - Cluster alias

What kind of application was this that was highlighted as causing a problem? Is there really an issue with FailSAFE IP or is it a scaremongering issue?
I've used FailSAFE IP before without any issue, but my colleagues and I are a little jittery that someone has suggested that it would have a problem at daylight savings switch time.

Thanks in advance
Hoff
Honored Contributor

Re: Time Change - Cluster alias

This semi-annual debacle is easily avoided, given that the VMS timekeeping implementation will remain somewhere between problematic and flawed.

Don't use DST. and do use UTC.

Done.

As for the OP, this looks no more hazardous than the usual hazard of moving the cluster alias or the IP address around, and the usual hazard that application (mis)coding in the presence of the stupidity that is DST. It's probably either vendor confusion (possibly with older connectivity errors around networking and DST), or this could well be some broken vendor code. This could be that something within the vendor code has gotten the hand-off during the shutdown sequence and goes live, and then gets hit with the DST switch, and fails.

Or it could be the usual caution that vendors involved with critical functions have around the debacle that is DST.

If you're concerned about DST, then do something about it. Well, technically, do something about it once, and then do nothing from then on. Switch to UTC, disable DST, prepare your FAQ that "the computers have all been moved to London", and back away from the system time settings.

DST serves as something that no government can resist messing with in order to distract themselves or others from whatever else it is that the government should be working on. So yes, expect further DST changes.