[Info-vax] removing a node completely

[Phillip Helbig---undress to reply]

In article <kek1af$kdd$1 at online.de>, helbig at astro.multiCLOTHESvax.de
(Phillip Helbig---undress to reply) writes: 

> Due to some typos etc (not related to satellite questions in another 
> thread) I removed a newly created node with CLUSTER_CONFIG_LAN.COM on 
> all 3 nodes in the cluster.  I then re-created it, on only one node, but
> with another name.  When booting, the MOP download was successful but 
> the console hangs.  On another node (the one that served the MOP 
> download and also, presumably coincidentally, the boot server), there is 
> a console message saying "Remote System Conflicts with Known System".  
> So, presumably, using CLUSTER_CONFIG_LAN.COM with the "remove node" 
> option doesn't actually remove everything.  Interestingly, after running 
> it on one node I got "The configuration procedure has completed 
> successfully" but on others I got:
> 
>     The following error occurred when accessing the LANCP boot server database:
> 
>    %LANCP-E-NODENFND, Node not found in LAN node database, node !AC
> 
>    Please correct the error and reinvoke this procedure.
> 
> My guess is that running it on the first node removed it from the LANCP 
> database hence the error on the other two nodes.  On the other hand, I 
> didn't set up any cluster-wise LANCP database (is this even possible) so 
> am a bit puzzled by this.
> 
> How can I see what addresses are known to LANCP?  How can I remove them?

Just to be clear, neither LANCP> LIST NODE nor SHOW NODE shows the old
node.  As expected, the new node shows up in SHOW NODE on the one node
configured as a boot server for it.  What surprises me is that LIST NODE
shows the new node on all nodes.  Where is the permanent LAN database
and how did it become cluster-wide? 

The only place I see the old node in LANCP is SHOW DLL, in the two nodes 
which are not configured as boot servers for the old node.  I understand 
what the message is saying:

   The configuration poller discovered a remote computer with
   SCSSYSTEMID and/or SCSNODE equal to that of another computer to which
   a virtual circuit is already open. 

It is clear that this is not a good thing.  So I suppose the question 
is whether it is possible to close this virtual circuit without a 
reboot.