1 Jun
2021
1 Jun
'21
12:54 p.m.
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