[HECnet] SETNOD, Part 2

[Paul Koning]

> On Jun 22, 2021, at 1:15 PM, Thomas DeBellis <tommytimesharing at gmail.com> wrote:
> 
> Now that I am thinking about it, perhaps one reason that a DECnet executor will refuse to change its running address is because that would involve changing the MAC address of the Ethernet adapter?  Tops-20 DECnet does not appear to want to do after boot-up is complete, although I don't know why nor if the IP stack would care.

Assuming you have a NIC that only handles a single local address, IP would be affected in that any ARP cache entry with that address is now obsolete.  Most DEC NICs handle multiple addresses (I think LANCE and UNA are the exceptions) though perhaps not all OS drivers take advantage of that.

Changing a running DECnet node's address would of course also break any open connections, the same as would be true for a TCP/IP node if you changed the IP address on the fly.  It wouldn't surprise me if designers were to look at all the internal state that would have to be updated and say "not worth the trouble".

> Multi-net on Tops-20 also includes CI communications.  As I recall, it is not programmatically possible to change your CI address because that depends on where you are physically plugged into the STAR adapter (or concentrator or whatever it was).  Maybe things wouldn't croak in that case, but you would need to use low level communications to notify the other nodes of the address change.

What does DECnet over CI look like?  That's not familiar.

> Tops-20 definitely has code (in the SCS% JSYS) to signal other nodes in the cluster that a particular system's name has changed.  However, once DECnet is initialized, the NODE% function to do this,  .NDSLN, will be refused by the Executor with a NODX16 ("DECnet is already initialized").
> 
> It would appear that DECnet does not allow aliasing to be done network-wide.  From the 4.0 Network Management Functional Specification, one finds the following:
> 
> DNA allows one node name  for  each  node.  The network manager should make sure that each node name and address in the network is  unique.   (An  implementation may also provide the ability to assign additional node names to nodes, but these names can be known to the local node  only).

In DECnet Phase IV and before, names are a purely local item, they get mapped to addresses in the session layer and everything else deals with addresses.  Think of it as analogous to /etc/hosts in Unix.

Phase V adds DecDNS which is like the IP DNS, except that from the start it had synchronization of all the name databases among all the servers.

I wonder if I'll ever get around to Phase V support in PyDECnet...  stuff like DecDNS would be a pretty significant challenge, it's a large body of work and not easy to understand.  I did at one time -- back in 1985 or so... :-)

	paul