[HECnet] SETNOD, Part 2
Thomas DeBellis
tommytimesharing at gmail.com
Mon May 31 21:19:19 PDT 2021
Thanks; I don't believe it will be necessary to add an additional
command to the FIX.T20 file. In fact, once I'm done, I should need one
command /less/ as I've fixed the bug where a TAKE file not ended by a
RETURN statement causes a failure. EOF is now handled like an implied
RETURN.
Part of the point of the rewrite was to bring Tops-20 DECnet
administration more into line with the philosophy of rest of the
operating system as we understood it at Columbia. This may be briefly
stated as,
1. Take care of things yourself (Tops-20) and don't bother me (the
systems programmer) unless you really can't figure it out.
2. Keep me (the systems programmer or OPERATOR) from doing something
that will screw things up. Protect me from myself.
3. Do /not/ reboot unless there is a new version of the monitor to be
brought up.
Another benefit that I was hoping for was to make the system easier to
operate for a beginning (or any kind of) hobbyist. Anecdotally, I think
most systems on HECnet could use this. Right now, of the (pitifully
few) 17 Tops-20 nodes defined on MIM::, one sees that, of the six that
are online, three are up to date and three are not. The break down is
as follows:
JOSHUA 20.4 Offline PAMINA 1.18 Offline TINA 1.14 Offline
MINDY 9.2 Offline BITXT2 7.78 Offline KLIO 1.451 Offline
FALLON 18.104 Offline OLAF 22.14 Offline ATHENA 1.620 Offline
BIZET 1.800 Offline
BITXT0 7.79 Out of Date GLGMSH 61.150 Out of Date TWENEX 31.29
Out of Date
WALACH 29.108 Out of Date
SOL 59.10 Up to Date TOMMYT 2.520 Up to Date VENTI2 2.520
Up to date
Note, TWENEX is offline, but was out of date the last time I checked.
TOMMYT and VENTI2 are mine.
I think that what you are doing with VMS (whack everything before
update) is probably what Tops-20 did, the difference being that Tops-20
required a reboot. However, the (equivalent) commands that you are
using are not supported in Tops-20, viz:
NCP>cleAR kNOWN nODES nAME
23:20:42 --Illegally formatted command message--
NCP>purgE kNOWN nODES nAME
23:21:01 --Illegally formatted command message--
These error messages may be misleading: Tops-20 contains _no_ code to
whack the entire internal node table. There is nothing in the NODE%
JSYS or its related support code to do this. You have to specifically
know what you're whacking. This information can not be gotten from a
(standard DEC or PANDA) running monitor without .NDVFX, although
reasonable deductions could probably be made from a previously saved
.BIN file (think of this like a 'compiled' FIX.T20).
You can copy .BIN files around on Tops-20 like on RSX. I would need to
accommodate that because I strip the local executor node when doing the
'compile'. Obviously, this would do the wrong thing with shared .BIN's
because the executor changes from system to system. Even still, you
could not blithely do an insert--you have to do the detection and
corrections, below or you'll be risking a failure.
I have made steps to do this, I can de-compile a .BIN file and create
maintenance steps. In fact, this is what the GET/RECONSTRUCT sequence
does, below--you'll see that I was not TAKE'ing from FIX.T20. I
initially only did this for prototyping; in other words, I didn't have
to write the keyword parser until much later in development until after
I had gotten a good part of the decision logic working.
> ------------------------------------------------------------------------
> On 5/31/21 3:47 PM, Johnny Billquist wrote:
>
> 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/072eb801/attachment-0001.htm>
More information about the Hecnet-list
mailing list