[HECnet] SETNOD, Part 2

Mon May 31 21:49:50 PDT 2021

I'm not sure that would work.  It is easy enough to strip your own 
Executor information from the file beforehand and SETND2 does this 
because I do not allow any updates to the Executor; these are configured 
in SYSTEM:7-1-CONFIG.CMD in the following stanzas:

    ! DECNET
    DECNET BUFFER-SIZE 1476
    DECNET MAXIMUM-ADDRESS 1023
    NODE VENTI2 2.522
    DECNET ROUTER-LEVEL-1
    ETHERNET 0 DECNET

This is processed precisely once at boot time. Everything else is 
handled through NICE, viz:

    ;DECNET!!!
    Wait 2
    NCP SET EXECUTOR CPU DECSYSTEM-1020
    NCP SET EXECUTOR SOFTWARE IDENTIFICATION "Tops-20 7.1 PANDA"
    NCP SET EXECUTOR IDENTIFICATION "Venti Due Test System"
    NCP SET CIRCUIT NI-0-0 SERVICE ENABLED
    NCP SET CIRCUIT NI-0-0 STATE ON

However, if I copy VENTI2's .BIN file to TOMMYT, then on the next 
reboot, TOMMYT won't know about VENTI2 because that information will 
have been removed.  And the .BIN file will have a definition for TOMMYT, 
which may not be a good idea.  Hmm...

I grabbed a copy of your Dune::SYS$SPECIFIC:[DECNET]NETUPDATEV3.COM 
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 CLEAR, PURGE and then DEFINE. How well do you think that would 
scale to thousands of nodes?

I had given some thought to such scaling and felt that hitting the 
monitor with that many requests might not be an optimal approach. SETND2 
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.

@setnd2
% Insufficient capabilities for INSERT command
SETNODE>vERBOSITY (level is) vERBOSE
Verbosity level is VERBOSE
SETNODE>GET (binary node definition file) /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 (node keyword tables from binary table) /siLENT
[Closed log file: NUL:]
SETNODE>SHOW (node table) toTAL (nodes defined in node tables)
     Total Unchanged nodes:    885
  Total updates to perform:      3
     Total nodes to delete:      3
  Total words, shared text:   1606
        Total nodes mapped:    889
Section mapped input file: 
TOMMYT:<SYSTEM>NODE-DATA.BIN.91;RESTRICTED-JFN:13
   Total file pages mapped:      4
SETNODE>buiLD (binary list) inCREMENTAL (list to insert in running monitor)
% Putting node deletions into the incremental list
BANDEV (1.771)
ORAV23 (1.301)
RSX134 (1.303)
Nodes processed: 3
% Putting node updates into the incremental list
BANX25 (1.771)
MACARO (1.303)
ORACLE (1.301)
Nodes processed: 3
Total nodes inserted: 6
SETNODE>

> ------------------------------------------------------------------------
>
> On 5/31/21 4:49 PM, Keith Halewood wrote:
>
> 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
> ------------------------------------------------------------------------
> From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Johnny Billquist
> Sent: 31 May 2021 20:48
> To: hecnet at Update.UU.SE
> 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:
>> 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>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sonic.net/pipermail/hecnet-list/attachments/20210601/6ffeba20/attachment.htm>