7 Mar
2020
7 Mar
'20
7:48 p.m.
That's interesting that there is no user visible interface to map
between nodes and area.numbers in RSX, just like Tops-20.? I wonder
why?? As a contrast, we all know that IP4 and IP6 addresses can be
specified both numerically and 'symbolically' via the DNS. However, the
functionality existed in the HOSTS file and predates IP.
Tops-20 does not precisely have a permanent node database. Everything is
configured and loaded either from text files or 'compiled' text files on
boot up.? So initial configuring for DECnet and setting the local node
name and type is done in CONFIG.CMD which is parsed by SETSPD before
Galaxy is initiated. While that is happening, the 'compiled' (I.E.,
binary) node database is inserted into the hash table.? SETNOD does not
have full functionality to add and remove nodes from this table,
although it can tell the monitor to remove a node.
After the insert is done, enough functionality is available for
SYSTEM.CMD to be parsed by OPR and issue the remaining NCP commands to
the local NICE processor (NMTL20).? Strangely enough, CLEAR NODE xx::
ALL didn't have any effect.? It probably should have.? PURGE didn't work
at all.? So, you have to do the (undocumented) SETNOD feature to remove
a node.
!opr
OPR>ent ncp
NCP>push
?PANDA TOPS-20 Command processor 7.1(4454)-5
?End of TOMMYT:<SLOGIN>COMAND.CMD.12
@i dec
?Local DECNET node: VENTI2.? Nodes reachable: 6.
?Accessible DECNET nodes are:??? A2RTR??? APOLLO LEGATO??? TOMMYT???
VENTI2??? ZITI
@pop
NCP>tel ziti:: shoW eXECUTOR
NCP>
13:31:21 ??? NCP
??? ??? Request # 11 Accepted
NCP>
13:31:21 ??? NCP
Request # 11; Show Executor Node Summary Completed
Executor Node = 2.16 (ZITI)
? Circuit = eth1
? State = On
? Identification = DECnet for Linux V4.4.0-148-generic on x86_64
NCP>clEAR noDE ziti:: alL
NCP>
13:31:42 ??? NCP
Request # 12; Clear Node Completed
NCP>telL ziti:: shoW exECUTOR
NCP>
13:31:58 ??? NCP
??? ??? Request # 13 Accepted
NCP>
13:31:59 ??? NCP
Request # 13; Show Executor Node Summary Completed
Executor Node = 2.16 (ZITI)
? Circuit = eth1
? State = On
? Identification = DECnet for Linux V4.4.0-148-generic on x86_64
NCP>push
@i dec
?Local DECNET node: VENTI2.? Nodes reachable: 6.
?Accessible DECNET nodes are:??? A2RTR??? APOLLO LEGATO??? TOMMYT???
VENTI2??? ZITI
@pop
NCP>purGE noDE ziti:: alL
NCP>
13:45:47 ??? NCP
Request # 14; Purge Node Failed, Operation failure
NCP>
------------------------------------------------------------------------
On 3/7/20 12:41 PM, Johnny Billquist wrote:
On 2020-03-04 00:57, Thomas DeBellis wrote:
However, as I've said before (viz., the NFT:
device and FTS), there
are parts of Tops-20 DECnet that strike me as not fully productized.?
One example is that there is no way for /anybody/ to extract the area
and number of a node once it is the monitor.? You can (and should)
verify that the node is 'legitimate' by using .NDVFY function of the
NODE% JSYS, which will also tell you some interesting things about
it. However, it will not divulge the aforementioned numbers.? It
annoyed me enough so that I modified the monitor to do just that with
an additional function, .NDVFX and I use this in DAP (but don't
depend on it) and in the mailer (where I do).
I haven't posted the changes anywhere because I can't make up my mind
whether this was fixing an oversight or breaking a design decision or
indeed, whether that should even matter.
In RSX there is no documented way to map between node names and
addresses, in either direction.
There is an interface for it, but it's not documented. Internally,
DECnet have a separate device and ACP which handles the nodename
database. If you just have the specifications for this device, you can
do lookups yourself, but DEC never intended that anyone should use it,
except DECnet internally does.
Another example is that, once a node is inserted
into the monitor
data base, there is *no* documented way to remove it.? As I was
implementing .NDVFX, I was looking at the in-area hashing code and
noticed that it appears that the monitor will remove a node marked as
-1 (36 bits).? I have yet to test this.? Certainly SETNOD gives no
hint (another reason I'm toying with a rewrite).
Curiouser and curiouser.? Do the above two functionalities exist in
other operating systems?
The ability to remove nodes from the nodename database works fine in
pretty much all OSes I know of, except for the PDP-10 world.
In VMS and RSX, it's NCP CLEAR NODE node ALL, for example, for the
current running system. In VMS you use PURGE in NCP for the permanent
database, while in RSX, you use PURGE, but in CFE, which is the
configuration file editor, for the permanent database.
I think RSTS/E does it all through NCP, like in VMS, but I guess Paul
can tell for sure.
? Johnny