<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body>
<p>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.</p>
<p>Is anybody keeping up on this? How? I had a (bi-weekly)
re-occurring batch job which NFT'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>
</p>
<p>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.</p>
<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.<br>
</li>
</ol>
<p>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.</p>
<p>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.</p>
<p>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>
</p>
<p>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.</p>
<p>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 get itself confused.<br>
</p>
<p><font size="+1"><tt>@<b>setnd2</b></tt><tt><br>
</tt><tt>% Insufficient capabilities for INSERT command</tt><tt><br>
</tt><tt><br>
</tt><tt>SETNODE><b>vERBOSITY</b> (level is) <b>vERBOSE </b><br>
Verbosity level is VERBOSE<br>
SETNODE><b>get /sECTION-MAP /nO-ACCESS</b></tt><tt><br>
</tt><tt>[BIN file:
TOMMYT:<SYSTEM>NODE-DATA.BIN.91;RESTRICTED-JFN:13 ]</tt><tt><br>
</tt><tt>Mapped one section (4 pages), 1778 Words, 889 Nodes.</tt><tt><br>
</tt><tt>SETNODE><b>recONSTRUCT /sILENT </b></tt><tt><br>
</tt><tt>[Closed log file: NUL:]</tt><tt><br>
</tt><tt>SETNODE><b>shoW aREA 2 uNCHANGED</b></tt><tt><br>
</tt><tt>[Area 2]</tt><tt><br>
</tt><tt>A2RTR ADAGIO ADVENT ADVNT5 AMAPUR APOLLO AUG11
AUGVAX BASSET BEAGLE BELLS BOINGO BOXER BULDOG CHARON<br>
CODA COLLIE CONDOR CORGI COYOTE CYPHER DALMTN
DIVISI DOGPAK ELIDYR ELITE FOX GLDRTR GLOVER GRUNT<br>
HERMES HUIA HUNTER HUSKY JACKAL JENSEN KELPIE
LABRDR LAPDOG LARGO LEGATO LENTO MASTIF MENTOR MEZZO<br>
MULTIA MUTT NO0K ODST OINGO OSIRIS PAVANE
POCO POODLE PUG PUGGLE PUPPY R2X899 REACH SPARK<br>
TERIER THEARK TOMMYT VENTI WLFHND WOLF ZITI</tt><tt>
</tt><tt><br>
</tt><tt>Total nodes in area 2: 67</tt><tt><br>
</tt><tt>SETNODE><b>shoW </b></tt></font><font size="+1"><b><tt><font
size="+1"><tt>uNCHANGED</tt> </font>boiNGO</tt></b><tt><br>
</tt><tt>BOINGO:: (2.399)<br>
</tt><tt>SETNODE><b>set 2.400 boingo</b></tt><tt><br>
</tt><tt>Set existing node BOINGO:: (2.400)</tt><tt><br>
</tt><tt>Node BOINGO:: (2.400)</tt><tt><br>
</tt><tt>% Removing node BOINGO:: (2.399) from same list to
insert in the delete list</tt><tt><br>
</tt><tt>% Re-using key text for insertion in delete list,
BOINGO (2.399)</tt><tt><br>
</tt><tt>% Removing BOINGO::'s previous address (2.399)</tt><tt><br>
</tt><tt>% Removing node APOLLO:: (2.400) from same list to
insert in the delete list</tt><tt><br>
</tt><tt>% Re-using key text for insertion in delete list,
APOLLO (2.400)</tt><tt><br>
</tt><tt>% Deleting APOLLO:: (2.400) to reassign its address to
BOINGO::</tt><tt><br>
</tt><tt>% Allowing update request for node BOINGO:: (2.400)
because being deleted as (2.399)</tt><tt><br>
</tt><tt>% Removing node BOINGO:: (2.399) from unchanged list
because its address has changed to (2.400)</tt><tt><br>
</tt><tt>% Re-using key text for insertion in update list,
BOINGO (2.400)</tt><tt><br>
</tt><tt>Node change request for BOINGO:: (2.400)</tt><tt><br>
</tt><tt>SETNODE></tt></font><br>
<br>
</p>
</body>
</html>