home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.os.vms
- Path: sparky!uunet!charon.amdahl.com!pacbell.com!ames!sun-barr!cs.utexas.edu!sdd.hp.com!decwrl!pa.dec.com!engage.pko.dec.com!nntpd.lkg.dec.com!ryn.mro4.dec.com!star.enet.dec.com!parris
- From: parris@star.enet.dec.com (Keith B. Parris)
- Subject: Re: Remotely rebooting vms
- Message-ID: <1993Jan26.150157.25369@ryn.mro4.dec.com>
- Sender: news@ryn.mro4.dec.com (USENET News System)
- Organization: Digital Equipment Corporation
- References: <1993Jan14.114547.279@vulcan.resmel.bhp.com.au>,<13JAN199323382525@spades.aces.com> <1993Jan14.113448.22476@slcs.slb.com> <15JAN199309491266@spades.aces.com>
- Date: 26 JAN 93 09:59:24 EST
- Lines: 19
-
-
- In article <15JAN199309491266@spades.aces.com>, gavron@spades.aces.com (Ehud
- Gavron 602-570-2000 x. 2546) writes...
- >If you don't define OPC$REMOVE_NODE then at V5.3 and higher
- >the node will NOT send a last-gasp datagram to its cluster members,
- >and they will have to go through the HELL of reconfiguring.
-
- Actually, the last-gasp datagram will normally always get sent out, unless you
- do a Control-P/Halt or there's a power failure.
-
- REMOVE_NODE indicates that the cluster should try to adjust Expected_Votes
- downward if possible, in hopes the cluster won't hang for lack of quorum when
- this node leaves.
- __________---_---_-_-_-_-_____-_----____---__-__-_-_-----_-_--_--___-_-__---__-_
- Keith B. Parris, Digital Equipment Corporation, Alpha VMS Clusters & I/O Group
- ----_-____-_--_-__-_---_-___-_-_-_--__-_-__---__-_---_-___-_-_-_-_____--_--___-_
- Anything blatantly opinionated or which is later found to be inaccurate was
- mine, of course. Digital gets the credit for any actual facts which appear.
- -_-_--__-_-__----___---__-__-_-_-_-_____-__--_____---_-___-_-_-_--__-_--_--___-_
-