[HECnet] SETNOD, Part 2

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. -Steve Davidson SF:iP1 > On May 31, 2021, at 16:49, Keith Halewood > <Keith.Halewood at pitbulluk.org> 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 > > -----Original Message----- > 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> >> > > -- > Johnny Billquist????????????????? || "I'm on a bus > ?????????????????????????????????? ||? on a psychedelic trip > email: bqt at softjar.se???????????? ||? Reading murder books > pdp is alive!???????????????????? ||? tryin' to stay hip" - B. Idol