<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>I'm not sure that would work. It is easy enough to strip your
own Executor information from the file beforehand and <font
size="+1"><tt>SETND2</tt></font> does this because I do not
allow any updates to the Executor; these are configured in <font
size="+1"><tt>SYSTEM:7-1-CONFIG.CMD</tt></font> in the following
stanzas:</p>
<blockquote>
<p><tt><font size="+1">! DECNET<br>
DECNET BUFFER-SIZE 1476<br>
DECNET MAXIMUM-ADDRESS 1023<br>
NODE VENTI2 2.522<br>
DECNET ROUTER-LEVEL-1<br>
ETHERNET 0 DECNET</font><br>
</tt></p>
</blockquote>
<p><tt></tt>This is processed precisely once at boot time.
Everything else is handled through NICE, viz:</p>
<blockquote>
<p><font size="+1"><tt>;DECNET!!!</tt><tt><br>
</tt><tt>Wait 2</tt><tt><br>
</tt><tt>NCP SET EXECUTOR CPU DECSYSTEM-1020</tt><tt><br>
</tt><tt>NCP SET EXECUTOR SOFTWARE IDENTIFICATION "Tops-20 7.1
PANDA"</tt><tt><br>
</tt><tt>NCP SET EXECUTOR IDENTIFICATION "Venti Due Test
System"</tt><tt><br>
</tt><tt>NCP SET CIRCUIT NI-0-0 SERVICE ENABLED</tt><tt><br>
</tt><tt>NCP SET CIRCUIT NI-0-0 STATE ON</tt></font><br>
</p>
</blockquote>
<div class="moz-cite-prefix">
<p>However, if I copy <font size="+1"><tt>VENTI2</tt><tt>'s .BIN</tt></font>
file to <font size="+1"><tt>TOMMYT</tt></font>, then on the
next reboot, <font size="+1"><tt>TOMMYT</tt></font> won't know
about <font size="+1"><tt>VENTI2</tt></font> because that
information will have been removed. And the <font size="+1"><tt>.BIN</tt></font>
file will have a definition for <font size="+1"><tt>TOMMYT</tt></font>,
which may not be a good idea. Hmm...</p>
</div>
<div class="moz-cite-prefix">
<p>I grabbed a copy of your <font size="+1"><tt>Dune::SYS$SPECIFIC:[DECNET]NETUPDATEV3.COM</tt></font>
script and had a look; pretty nifty! (although it's been
several decades that I haven't really used DCL...) I notice
that for every node, you <font size="+1"><tt>CLEAR</tt></font>,
<font size="+1"><tt>PURGE</tt></font> and then <font size="+1"><tt>DEFINE</tt></font>.
How well do you think that would scale to thousands of nodes?</p>
<p>I had given some thought to such scaling and felt that hitting
the monitor with that many requests might not be an optimal
approach. <font size="+1"><tt>SETND2</tt></font> figures out
the minimum to do and does it. In the example below, this is 6
operations instead of 889. If you assume that changes are
gradual (say only a few nodes a month), then it doesn't matter
how big the nodes file gets; you're going to be doing the same
amount of operations on the running monitor.<br>
</p>
</div>
<div class="moz-cite-prefix"><font size="+1"><tt>@setnd2</tt><tt><br>
</tt><tt>% Insufficient capabilities for INSERT command</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 (binary node definition file)
/SECTION-MAP /nO-ACCESS </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>reconSTRUCT (node keyword tables from binary
table) /siLENT </tt><tt><br>
</tt><tt>[Closed log file: NUL:]</tt><tt><br>
</tt><tt>SETNODE>SHOW (node table) toTAL (nodes defined in
node tables) </tt><tt><br>
</tt><tt> Total Unchanged nodes: 885</tt><tt><br>
</tt><tt> Total updates to perform: 3</tt><tt><br>
</tt><tt> Total nodes to delete: 3</tt><tt><br>
</tt><tt> Total words, shared text: 1606</tt><tt><br>
</tt><tt> Total nodes mapped: 889</tt><tt><br>
</tt><tt>Section mapped input file:
TOMMYT:<SYSTEM>NODE-DATA.BIN.91;RESTRICTED-JFN:13 </tt><tt><br>
</tt><tt> Total file pages mapped: 4</tt><tt><br>
</tt><tt>SETNODE>buiLD (binary list) inCREMENTAL (list to
insert in running monitor) </tt><tt><br>
</tt><tt>% Putting node deletions into the incremental list</tt><tt><br>
</tt><tt>BANDEV (1.771)</tt><tt><br>
</tt><tt>ORAV23 (1.301)</tt><tt><br>
</tt><tt>RSX134 (1.303)</tt><tt><br>
</tt><tt>Nodes processed: 3</tt><tt><br>
</tt><tt>% Putting node updates into the incremental list</tt><tt><br>
</tt><tt>BANX25 (1.771)</tt><tt><br>
</tt><tt>MACARO (1.303)</tt><tt><br>
</tt><tt>ORACLE (1.301)</tt><tt><br>
</tt><tt>Nodes processed: 3</tt><tt><br>
</tt><tt>Total nodes inserted: 6</tt><tt><br>
</tt><tt>SETNODE></tt></font><br>
<br>
</div>
<blockquote type="cite"
cite="mid:215c6e65917644a69004a303750fc7f7@MERLIN.pitbulluk.local">
<hr width="100%" size="2">
<p>On 5/31/21 4:49 PM, Keith Halewood wrote:<br>
</p>
<pre class="moz-quote-pre" wrap="">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.
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.
Keith
</pre>
<hr width="100%" size="2">
<pre class="moz-quote-pre" wrap="">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
Sent: 31 May 2021 20:48
To: <a class="moz-txt-link-abbreviated" href="mailto:hecnet@Update.UU.SE">hecnet@Update.UU.SE</a>
Subject: Re: [HECnet] SETNOD, Part 2
If there is some additional commands you'd like for me to put into FIX.T20, let me know.
The VMS commandfile I creates starts like this:
$ MCR NCP
PURGE NODE * NAME
CLEAR NODE * NAME
def nod 41.28 name 28NH
.
.
.
Which means that any previous definitions are first cleared out before any definitions go in.
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.
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).
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.
With other systems I don't know at all.
Johnny
On 2021-05-31 20:50, Thomas DeBellis wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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 MIM:: changes more or less about once a month,
sometimes more, sometimes less.
Is anybody keeping up on this? How? I had a (bi-weekly) re-occurring
batch job which NFT'ed the latest node file from MIM:: and simply used
SETNOD 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 .NDINT) during timesharing did strike
me as somewhat wasteful, I didn't pay much attention to the matter as it did work.
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.
1. 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?
2. You may not change the address of an existing node in the local area.
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.
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.
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?
I remediated the low level error reporting issue and implemented a new
function for NODE% to return the address of an existing DECnet node
(.NDVFX or Verify Node Extended). Fixing SETNOD 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 SETNOD, it just
wasn't designed for this kind of heavy lift. So I rewrote it from
scratch (cleverly naming it SETND2). I'm converging on completion, but
I don't work on it actively, so this will probably be a few more weeks.
Here is some sample output; let's suppose that BOINGO needs its
address changed from 2.399 to 2.400 and that this conflicts with
another node (in this case, APOLLO). To get this to work right, what
you need to do is tell Tops-20 to do is delete BOINGO first, so that
there is no name clash on the insertion. Then you have to delete
APOLLO, 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.
@*setnd2*
% Insufficient capabilities for INSERT command
SETNODE>*vERBOSITY* (level is) *vERBOSE *
Verbosity level is VERBOSE
SETNODE>*get /sECTION-MAP /nO-ACCESS*
[BIN file: TOMMYT:<SYSTEM>NODE-DATA.BIN.91;RESTRICTED-JFN:13 ] Mapped
one section (4 pages), 1778 Words, 889 Nodes.
SETNODE>*recONSTRUCT /sILENT *
[Closed log file: NUL:]
SETNODE>*shoW aREA 2 uNCHANGED*
[Area 2]
A2RTR ADAGIO ADVENT ADVNT5 AMAPUR APOLLO AUG11 AUGVAX BASSET
BEAGLE BELLS BOINGO BOXER BULDOG CHARON CODA COLLIE CONDOR
CORGI COYOTE CYPHER DALMTN DIVISI DOGPAK ELIDYR ELITE FOX
GLDRTR GLOVER GRUNT HERMES HUIA HUNTER HUSKY JACKAL JENSEN
KELPIE LABRDR LAPDOG LARGO LEGATO LENTO MASTIF MENTOR MEZZO
MULTIA MUTT NO0K ODST OINGO OSIRIS PAVANE POCO POODLE
PUG PUGGLE PUPPY R2X899 REACH SPARK TERIER THEARK TOMMYT
VENTI WLFHND WOLF ZITI Total nodes in area 2: 67
SETNODE>*shoW **uNCHANGED boiNGO*
BOINGO:: (2.399)
SETNODE>*set 2.400 boingo*
Set existing node BOINGO:: (2.400)
Node BOINGO:: (2.400)
% Removing node BOINGO:: (2.399) from same list to insert in the
delete list % Re-using key text for insertion in delete list, BOINGO
(2.399) % Removing BOINGO::'s previous address (2.399) % Removing node
APOLLO:: (2.400) from same list to insert in the delete list %
Re-using key text for insertion in delete list, APOLLO (2.400) %
Deleting APOLLO:: (2.400) to reassign its address to BOINGO::
% Allowing update request for node BOINGO:: (2.400) because being
deleted as (2.399) % Removing node BOINGO:: (2.399) from unchanged
list because its address has changed to (2.400) % Re-using key text
for insertion in update list, BOINGO (2.400) Node change request for
BOINGO:: (2.400)
SETNODE>
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
</pre>
</blockquote>
</body>
</html>