[HECnet] SETNOD, Part 2

[Johnny Billquist]

On 2021-06-01 06:19, Thomas DeBellis wrote:
> 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.

Good. But anyway, I like to remind people that changing/updating/adding 
such scripts are really easy. So just let me know whenever something 
should be done.

[...]

> 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).

Ah. Interesting that a bunch of functionality in other versions are 
missing in TOPS-20. I guess it might be because when much of this came, 
TOPS-20 was already getting into maintenance mode, so DEC didn't really 
do more than they absolutely had to.

I should point out that the most common way in VMS (and RSX) would not 
be to actually whack the existing information, but to just copy over 
information from another node with existing tools.

In VMS that would be (from NCP):
COPY KNOWN NODES FROM MIM TO BOTH

no need for any clearing of old information beforehand. This command is 
clever enough to deal with nodes that change information without getting 
into conflicts. And it immediately takes effect after the command have 
been completed.

In RSX, a similar thing is accomplished by a task called NNC (Node Name 
Collector), which can go over DECnet and pull down the definitions from 
another node.
Once you have the node database copied over, you restart NNS (Node Name 
Server), and you're all done.

My script files are mostly for those situations where direct copying 
from a live system is not an option.

> 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.

You could also copy the binary nodename file over, but that is not 
normally what you would do, and of course, it only would work if you 
copied from another RSX node. With NNC, you can copy from any node.

But I think you're a bit on your own at the TOPS-20 side, unless some 
other T20 hacker steps up...

   Johnny

-- 
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