<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>You are correct; the Tops-20 Executor will allow you to do
precisely two (2) things after initialization:</p>
<ol>
<li>Set the Executor to the exact same name</li>
<li>Set the Executor to the exact same address</li>
</ol>
<p>So, yes, this is a no-op, like on other systems.</p>
<p>When writing all the defensive code to not do something that the
running monitor would disapprove of, it was easier for me to just
chuck anything to do with either the Executor node or name as
opposed to 'allowing' them to not change.<br>
</p>
<div class="moz-cite-prefix">
<p>I may have to rethink what the right thing to do is. At the
surface, not allowing anything to do with the Executor in the
incremental update list may be all that is necessary. <br>
</p>
<p>The full <font size="+1"><tt>.BIN</tt></font> file is another
matter. If the host is being legitimately renumbered and the
hobbyist is not paying attention, then you will pull the update,
put it into the <font size="+1"><tt>.BIN</tt></font> file, yet
never update <font size="+1"><tt>SYSTEM:7-1-CONFIG.CMD</tt></font>,
where that kind of change has to go. At the next reboot, the <font
size="+1"><tt>.NDINT</tt></font> will fail and you'll have a
subset of nodes, depending on where the Executor change is in
the <tt><font size="+1">.BIN</font></tt> file.</p>
<p>I could certainly auto-magically update the <font size="+1"><tt>NODE</tt></font>
verb in <font size="+1"><tt>SYSTEM:7-1-CONFIG.CMD</tt></font>
file, schedule a reboot and send a message. I guess it would
depend on the kind of behavior the system administrator wanted
and the trust relationships.<br>
</p>
</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>
<p>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.
</p>
<p>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.
</p>
<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 could 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 <b>*really* </b>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>
<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>
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>
<br>
<hr width="100%" size="2"><b>From</b>:
<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>
<b>Sent</b>: 31 May 2021 20:48
<br>
<b>To</b>: <a class="moz-txt-link-abbreviated" href="mailto:hecnet@Update.UU.SE">hecnet@Update.UU.SE</a>
<br>
<b>Subject</b>: 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>
<br>
$ MCR NCP
<br>
PURGE NODE * NAME
<br>
CLEAR NODE * NAME
<br>
def nod 41.28 name 28NH
<br>
<blockquote>.
<br>
.
<br>
.
<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>
<blockquote type="cite">
<hr width="100%" size="2">On 2021-05-31 20:50, Thomas
DeBellis wrote:
<br>
<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>
<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>
<br>
</blockquote>
<br>
-- <br>
Johnny Billquist || "I'm on a bus
<br>
|| on a psychedelic
trip
<br>
email: <a class="moz-txt-link-abbreviated" href="mailto:bqt@softjar.se">bqt@softjar.se</a> || Reading murder books
<br>
pdp is alive! || tryin' to stay hip"
- B. Idol
<br>
</blockquote>
</blockquote>
<br>
</blockquote>
</blockquote>
<br>
</blockquote>
</body>
</html>