<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>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.<br>
</p>
<p>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.</p>
<p>Tops-20 definitely has code (in the <font size="+1"><tt>SCS%</tt></font>
JSYS) to signal other nodes in the cluster that a particular
system's name has changed. However, once DECnet is initialized,
the <font size="+1"><tt>NODE%</tt></font> function to do this, <font
size="+1"><tt>.NDSLN</tt></font>, will be refused by the
Executor with a <font size="+1"><tt>NODX16</tt></font> ("DECnet
is already initialized").<br>
</p>
<p>It would appear that DECnet does <u>not</u> allow aliasing to be
done network-wide. From the 4.0 Network Management Functional
Specification, one finds the following:</p>
<blockquote>
<p>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).<br>
</p>
</blockquote>
<p>The <font size="+1"><tt>SETND2</tt></font> <font size="+1"><tt>NODE%</tt></font>
<font size="+1"><tt>.NDINT</tt></font> simulator is pretty strict
about certain things, depending on the mode. In boot up mode, you
are allowed to set any node to any address you want. Once the
simulated node table is populated (called "Running" mode), you can
not change <i>anything</i> about a node unless you delete it
first. The simulator will reject all cases of this, even if you
are aliasing in an a remote area.</p>
<p>This is as contrasted with Tops-20 current behavior of apparently
only detecting such a clash in the local area. This is done in
the <font size="+1"><tt>SCLINK</tt></font> module; I have yet to
review the out of area code in <font size="+1"><tt>ROUTER</tt></font>.<br>
</p>
<p>All of this allows me to test the <font size="+1"><tt>SETND2</tt></font>
node management routines very extensively without having to worry
about getting the monitor's node data base in a very bad way, the
only cure for that being a reboot.<br>
</p>
<div class="moz-cite-prefix">Of course, I managed to repeatably hang
and crash the system rather spectacularly while implementing the
simulator (all this while not being enabled'), but that is another
story...<br>
</div>
<blockquote type="cite"
cite="mid:163b1d19-83b3-d076-3d84-90837a74b62d@softjar.se">
<hr width="100%" size="2">On 6/1/21 7:01 AM, Johnny Billquist
wrote:<br>
<br>
Changing the name of the executor might be objected to by most
systems...
<br>
Updating it with the same information it already have should (I
hope) be a no-op.
<br>
<br>
With RSX, the nodename of the executor itself is special, and
don't sit together with all to name to number associations for
other nodes. So it don't really hit the executor when doing such a
clear/purge. I think it's similar with VMS.
<br>
<br>
But my comment was mainly because the point brought up from Keith
that other node information, such as various parameters for
DECservers, are also in the database, and you don't want to delete
that.
<br>
<br>
But the commands are "CLEAR NODE * NAME", which means only the
name is deleted, not other type of information/parameters in the
database. So DECserver information should not be touched in the
first place.
<br>
<br>
Johnny
<br>
<blockquote type="cite">
<hr width="100%" size="2">On 2021-06-01 07:02, Thomas DeBellis
wrote:
<br>
<br>
True, but I don't believe you couldn't do that on a Tops-20
cluster. At best, it might not be a good idea.
<br>
<br>
No Tops-20 node on the CI will allow a name (or address)
redefinition for itself once booted. The command would be
rejected by the Executor. You'd have the situation where nodes
would have different definitions of neighbors because each
neighbor's Executor would no longer have the neighbor's
definition. Or something like that...
<br>
<br>
At Columbia, if we had to do something like that, we brought the
entire cluster down. This was *really* frowned on.
<br>
<blockquote type="cite">
<hr width="100%" size="2">On 5/31/21 5:17 PM, Johnny Billquist
wrote:
<br>
<br>
Well, the CLEAR/PURGE is only for the name, not any other
information...
<br>
<br>
Johnny <br>
<blockquote type="cite">
<hr width="100%" size="2">On 2021-05-31 23:04, Steve
Davidson wrote:
<br>
<br>
Unfortunately CLEAR/PURGE is not a good idea in clusters or
nodes that boot DECservers. VMS requires additional
information in the database for those nodes/servers that
would be wiped out. That is why I wrote NETUPDATEV2.COM. It
does the update without touching any nodes in the local
area.
<br>
<br>
-Steve Davidson
<br>
<br>
SF:iP1
<br>
<blockquote type="cite">
<hr width="100%" size="2">On May 31, 2021, at 16:49, Keith
Halewood <a class="moz-txt-link-rfc2396E" href="mailto:Keith.Halewood@pitbulluk.org"><Keith.Halewood@pitbulluk.org></a> wrote:
<br>
<br>
With VMS, it's also permissible to copy
sys$system:netnode_remote.dat to other nodes, mainly
because no executor information is contained within this
file.
<br>
<br>
Dune::netupdatev3.com is a modified form of the update
script which does a purge/clear by individual area, except
for one's own area which is handled on a node by node
basis, including a configurable range within that area
which is ignored. For example, it prevents MIM:: from
overriding 29.100-199 by default.
<br>
<br>
Keith
<br>
<blockquote type="cite">
<hr width="100%" size="2">From:
<a class="moz-txt-link-abbreviated" href="mailto:owner-hecnet@Update.UU.SE">owner-hecnet@Update.UU.SE</a>
[<a class="moz-txt-link-freetext" href="mailto:owner-hecnet@Update.UU.SE">mailto:owner-hecnet@Update.UU.SE</a>] On Behalf Of Johnny
Billquist
<br>
Sent: 31 May 2021 20:48
<br>
To: <a class="moz-txt-link-abbreviated" href="mailto:hecnet@Update.UU.SE">hecnet@Update.UU.SE</a>
<br>
Subject: Re: [HECnet] SETNOD, Part 2
<br>
<br>
If there is some additional commands you'd like for me
to put into FIX.T20, let me know.
<br>
<br>
The VMS commandfile I creates starts like this:
<br>
<blockquote><font size="+1" face="monospace">$ MCR NCP <br>
PURGE NODE * NAME <br>
CLEAR NODE * NAME <br>
def nod 41.28 name 28NH <br>
. <br>
. <br>
. </font><br>
</blockquote>
Which means that any previous definitions are first
cleared out before any definitions go in.
<br>
This is because VMS (and RSX) do not handle if you have
a node name that gets a different address. Clearing
things out first solves that.
<br>
<br>
The alternate thing that can be done in VMS is that you
can copy nodenames from within NCP from another node,
which seems to avoid the problem as well (I think).
<br>
<br>
In RSX, the permanent nodename database in RSX can be
created by a separate tool that does not at all relates
to the current nodename database, so in RSX it's rather
easy. You download a new database, and then you switch
it over to the new db.
<br>
<br>
With other systems I don't know at all.
<br>
<br>
Johnny
<br>
<br>
<tt>-- </tt><tt><br>
</tt><tt>Johnny Billquist || "I'm on a
bus</tt><tt><br>
</tt><tt> || on a
psychedelic trip</tt><tt><br>
</tt><tt>email: <a class="moz-txt-link-abbreviated" href="mailto:bqt@softjar.se">bqt@softjar.se</a> || Reading
murder books</tt><tt><br>
</tt><tt>pdp is alive! || tryin' to
stay hip" - B. Idol </tt><br>
<hr width="100%" size="2">
<blockquote type="cite">On 2021-05-31 20:50, Thomas
DeBellis wrote:
<br>
<br>
I was wondering if anybody would care to explain how
routine node maintenance happens for DECnet on
non-Tops-20 systems. Specifically, Johnny's node list
on <font size="+1"><tt>MIM::</tt></font> changes more
or less about once a month, sometimes more, sometimes
less. <br>
<br>
Is anybody keeping up on this? How? I had a
(bi-weekly) re-occurring batch job which <font
size="+1"><tt>NFT</tt></font>'ed the latest node
file from <font size="+1"><tt>MIM::</tt></font> and
simply used <font size="+1"><tt>SETNOD</tt></font> to
shove the whole thing into the running monitor, on the
assumption that the monitor would figure out what to
do. While slapping in the whole list (with <font
size="+1"><tt>.NDINT</tt></font>) during timesharing
did strike me as somewhat wasteful, I didn't pay much
attention to the matter as it did work. <br>
<br>
This is mistaken. Tops-20 will not 'make it' work,
nor does it
apparently detect certain situations which appear to
be problematic. It does detect and reject two
situations.
<br>
<ol>
<li>You may not change either the name or address of
the host (I.E., the
Executor). These can only be set once at boot
up. Do other
operating systems have this restriction? </li>
<li>You may not change the address of an existing
node in the local area. </li>
</ol>
A node insertion in the local area which usurps an
address of another node deletes that node. Outside of
the local area, you are on your
own. It does whatever you want, which means that you
can have
multiple nodes with the same address. Is that a
problem? On IP4, this would been known as 'aliasing',
but I don't think DECnet allows this.
<br>
<br>
So it would appear that the appropriate behavior is
that a new node
list implies a system reboot. Unless I'm actively
doing monitor
development, I can't stand doing this.
<br>
<br>
However, fixing the problem turned out to be
pernicious. Neither of the two cases above is
reported to the user program; there is no way to
determine what might have gone wrong. There is no way
for the user program to proactively prevent errors
because, while you can ask Tops-20 to translate a
DECnet address to a node name and to verify that a
DECnet node name exists, there is no way to return the
address for a verified DECnet node name. Is this an
oversight? Can a user program get the address of a
DECnet node name on other operating systems? <br>
<br>
I remediated the low level error reporting issue and
implemented a new function for <font size="+1"><tt>NODE%</tt></font>
to return the address of an existing DECnet node (<font
size="+1"><tt>.NDVFX</tt></font> or Verify Node
Extended). Fixing <font size="+1"><tt>SETNOD</tt></font>
proved impossible. I discovered that the actions to
be performed were complex enough when automated that
the dimensions of the solution were wholly beyond its
capabilities. Not that there was anything wrong with
<font size="+1"><tt>SETNOD</tt></font>, it just wasn't
designed for this kind of heavy lift. So I rewrote it
from scratch (cleverly naming it <font size="+1"><tt>SETND2</tt></font>).
I'm converging on completion, but I don't work on it
actively, so this will probably be a few more weeks. <br>
<br>
Here is some sample output; let's suppose that <font
size="+1"><tt>BOINGO</tt></font> needs its address
changed from <font size="+1"><tt>2.399</tt></font> to
<font size="+1"><tt>2.400</tt></font> and that this
conflicts with another node (in this case, <font
size="+1"><tt>APOLLO</tt></font>). To get this to
work right, what you need to do is tell Tops-20 to do
is delete <font size="+1"><tt>BOINGO</tt></font>
first, so that there is no name clash on the
insertion. Then you have to delete <font size="+1"><tt>APOLLO</tt></font>,
so that there is no address conflict. Once you are
done performing both these actions, it's safe to do
the insertion and Tops-20 doesn't reject it or
otherwise gets itself confused. <br>
<br>
<font size="+1"><tt>@*setnd2* </tt><tt><br>
</tt><tt>% Insufficient capabilities for INSERT
command </tt><tt><br>
</tt><tt> </tt><tt><br>
</tt><tt>SETNODE>vERBOSITY (level is) vERBOSE</tt><tt><br>
</tt><tt>Verbosity level is VERBOSE </tt><tt><br>
</tt><tt>SETNODE>get /sECTION-MAP /nO-ACCESS</tt><tt><br>
</tt><tt>[BIN file:
TOMMYT:<SYSTEM>NODE-DATA.BIN.91;RESTRICTED-JFN:13
] <br>
Mapped </tt><tt>one section (4 pages), 1778
Words, 889 Nodes. </tt><tt><br>
</tt><tt>SETNODE>*recONSTRUCT /sILENT </tt><tt><br>
</tt><tt>[Closed log file: NUL:] </tt><tt><br>
</tt><tt>SETNODE>shoW aREA 2 uNCHANGED</tt><tt><br>
</tt><tt>[Area 2] </tt><tt><br>
</tt><tt>A2RTR ADAGIO ADVENT ADVNT5 AMAPUR
APOLLO AUG11 AUGVAX BASSET </tt><tt><br>
</tt><tt>BEAGLE BELLS BOINGO BOXER BULDOG
CHARON CODA COLLIE CONDOR </tt><tt><br>
</tt><tt>CORGI COYOTE CYPHER DALMTN DIVISI
DOGPAK ELIDYR ELITE FOX </tt><tt><br>
</tt><tt>GLDRTR GLOVER GRUNT HERMES HUIA
HUNTER HUSKY JACKAL JENSEN </tt><tt><br>
</tt><tt>KELPIE LABRDR LAPDOG LARGO LEGATO
LENTO MASTIF MENTOR MEZZO </tt><tt><br>
</tt><tt>MULTIA MUTT NO0K ODST OINGO
OSIRIS PAVANE POCO POODLE </tt><tt><br>
</tt><tt>PUG PUGGLE PUPPY R2X899 REACH
SPARK TERIER THEARK TOMMYT </tt><tt><br>
</tt><tt>VENTI WLFHND WOLF ZITI </tt></font><font
size="+1"><tt><font size="+1"><tt><br>
</tt></font>Total nodes in area 2: 67 </tt><tt><br>
</tt><tt>SETNODE>shoW uNCHANGED boiNGO</tt><tt><br>
</tt><tt>BOINGO:: (2.399) </tt><tt><br>
</tt><tt>SETNODE>shoW uNCHANGED boiNGO<br>
BOINGO:: (2.399)<br>
SETNODE>set 2.400 boingo<br>
Set existing node BOINGO:: (2.400)<br>
Node BOINGO:: (2.400)<br>
% Removing node BOINGO:: (2.399) from same list to
insert in the delete list<br>
% Re-using key text for insertion in delete list,
BOINGO (2.399)<br>
% Removing BOINGO::'s previous address (2.399)<br>
% Removing node APOLLO:: (2.400) from same list to
insert in the delete list<br>
% Re-using key text for insertion in delete list,
APOLLO (2.400)<br>
% Deleting APOLLO:: (2.400) to reassign its
address to BOINGO::<br>
% Allowing update request for node BOINGO::
(2.400) because being deleted as (2.399)<br>
% Removing node BOINGO:: (2.399) from unchanged
list because its address has changed to (2.400)<br>
% Re-using key text for insertion in update list,
BOINGO (2.400) Node change request for BOINGO::
(2.400) <br>
</tt><tt>SETNODE> </tt></font></blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</body>
</html>