<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: Time Change - Cluster alias in Operating System - OpenVMS</title>
    <link>https://community.hpe.com/t5/operating-system-openvms/time-change-cluster-alias/m-p/4770565#M60560</link>
    <description>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.&lt;BR /&gt;&lt;BR /&gt;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.&lt;BR /&gt;&lt;BR /&gt;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.&lt;BR /&gt;&lt;BR /&gt;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.)&lt;BR /&gt;&lt;BR /&gt;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.)</description>
    <pubDate>Sun, 27 Mar 2011 11:51:12 GMT</pubDate>
    <dc:creator>Hoff</dc:creator>
    <dc:date>2011-03-27T11:51:12Z</dc:date>
    <item>
      <title>Time Change - Cluster alias</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/time-change-cluster-alias/m-p/4770564#M60559</link>
      <description>Hi &lt;BR /&gt;&lt;BR /&gt;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. &lt;BR /&gt;&lt;BR /&gt;In the past have never shutdown any TCPIP service &lt;BR /&gt;&lt;BR /&gt;There is cluster alias  defined and time change  will happen automatically AUTO_DLIGH_SAV=1 &lt;BR /&gt;&lt;BR /&gt;Thanks in advance</description>
      <pubDate>Sun, 27 Mar 2011 07:47:32 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/time-change-cluster-alias/m-p/4770564#M60559</guid>
      <dc:creator>Mallkeet</dc:creator>
      <dc:date>2011-03-27T07:47:32Z</dc:date>
    </item>
    <item>
      <title>Re: Time Change - Cluster alias</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/time-change-cluster-alias/m-p/4770565#M60560</link>
      <description>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.&lt;BR /&gt;&lt;BR /&gt;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.&lt;BR /&gt;&lt;BR /&gt;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.&lt;BR /&gt;&lt;BR /&gt;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.)&lt;BR /&gt;&lt;BR /&gt;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.)</description>
      <pubDate>Sun, 27 Mar 2011 11:51:12 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/time-change-cluster-alias/m-p/4770565#M60560</guid>
      <dc:creator>Hoff</dc:creator>
      <dc:date>2011-03-27T11:51:12Z</dc:date>
    </item>
    <item>
      <title>Re: Time Change - Cluster alias</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/time-change-cluster-alias/m-p/4770566#M60561</link>
      <description>There was once a time when all you had to do was adjust your clock twice a year. Then it got "automated"! ;-)</description>
      <pubDate>Sun, 27 Mar 2011 20:01:10 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/time-change-cluster-alias/m-p/4770566#M60561</guid>
      <dc:creator>John Gillings</dc:creator>
      <dc:date>2011-03-27T20:01:10Z</dc:date>
    </item>
    <item>
      <title>Re: Time Change - Cluster alias</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/time-change-cluster-alias/m-p/4770567#M60562</link>
      <description>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?&lt;BR /&gt;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.&lt;BR /&gt;&lt;BR /&gt;Thanks in advance</description>
      <pubDate>Fri, 01 Apr 2011 13:16:38 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/time-change-cluster-alias/m-p/4770567#M60562</guid>
      <dc:creator>Steve Reece_3</dc:creator>
      <dc:date>2011-04-01T13:16:38Z</dc:date>
    </item>
    <item>
      <title>Re: Time Change - Cluster alias</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/time-change-cluster-alias/m-p/4770568#M60563</link>
      <description>This semi-annual debacle is easily avoided, given that the VMS timekeeping implementation will remain somewhere between problematic and flawed.&lt;BR /&gt;&lt;BR /&gt;Don't use DST. and do use UTC.&lt;BR /&gt;&lt;BR /&gt;Done.&lt;BR /&gt;&lt;BR /&gt;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.  &lt;BR /&gt;&lt;BR /&gt;Or it could be the usual caution that vendors involved with critical functions have around the debacle that is DST.&lt;BR /&gt;&lt;BR /&gt;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.&lt;BR /&gt;&lt;BR /&gt;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.</description>
      <pubDate>Fri, 01 Apr 2011 13:37:14 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/time-change-cluster-alias/m-p/4770568#M60563</guid>
      <dc:creator>Hoff</dc:creator>
      <dc:date>2011-04-01T13:37:14Z</dc:date>
    </item>
  </channel>
</rss>

