22 Jun
2021
22 Jun
'21
7:29 p.m.
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