[HECnet] SETNOD, Part 2

[Thomas DeBellis]

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/20210531/ae128e94/attachment.htm>