<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>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.</p>
    <p>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.</p>
    <p>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.<br>
    </p>
    <p><font size="+1"><tt>!opr</tt><tt><br>
        </tt><tt>OPR>ent ncp</tt><tt><br>
        </tt><tt>NCP>push</tt><tt><br>
        </tt><tt><br>
        </tt><tt> PANDA TOPS-20 Command processor 7.1(4454)-5</tt><tt><br>
        </tt><tt> End of TOMMYT:<SLOGIN>COMAND.CMD.12</tt><tt><br>
        </tt><tt>@i dec</tt><tt><br>
        </tt><tt> Local DECNET node: VENTI2.  Nodes reachable: 6.</tt><tt><br>
        </tt><tt> Accessible DECNET nodes are:    A2RTR    APOLLO   
          LEGATO    TOMMYT    VENTI2    ZITI</tt><tt><br>
        </tt><tt>@pop</tt><tt><br>
        </tt><tt>NCP>tel ziti:: shoW eXECUTOR </tt><tt><br>
        </tt><tt>NCP></tt><tt><br>
        </tt><tt>13:31:21     NCP</tt><tt><br>
        </tt><tt>        Request # 11 Accepted</tt><tt><br>
        </tt><tt>NCP></tt><tt><br>
        </tt><tt>13:31:21     NCP</tt><tt><br>
        </tt><tt><br>
        </tt><tt>Request # 11; Show Executor Node Summary Completed</tt><tt><br>
        </tt><tt><br>
        </tt><tt>Executor Node = 2.16 (ZITI)</tt><tt><br>
        </tt><tt><br>
        </tt><tt><br>
        </tt><tt>  Circuit = eth1</tt><tt><br>
        </tt><tt>  State = On</tt><tt><br>
        </tt><tt>  Identification = DECnet for Linux V4.4.0-148-generic
          on x86_64</tt><tt><br>
        </tt><tt>NCP>clEAR noDE ziti:: alL </tt><tt><br>
        </tt><tt>NCP></tt><tt><br>
        </tt><tt>13:31:42     NCP</tt><tt><br>
        </tt><tt><br>
        </tt><tt>Request # 12; Clear Node Completed</tt><tt><br>
        </tt><tt>NCP>telL ziti:: shoW exECUTOR </tt><tt><br>
        </tt><tt>NCP></tt><tt><br>
        </tt><tt>13:31:58     NCP</tt><tt><br>
        </tt><tt>        Request # 13 Accepted</tt><tt><br>
        </tt><tt>NCP></tt><tt><br>
        </tt><tt>13:31:59     NCP</tt><tt><br>
        </tt><tt><br>
        </tt><tt>Request # 13; Show Executor Node Summary Completed</tt><tt><br>
        </tt><tt><br>
        </tt><tt>Executor Node = 2.16 (ZITI)</tt><tt><br>
        </tt><tt><br>
        </tt><tt><br>
        </tt><tt>  Circuit = eth1</tt><tt><br>
        </tt><tt>  State = On</tt><tt><br>
        </tt><tt>  Identification = DECnet for Linux V4.4.0-148-generic
          on x86_64</tt><tt><br>
        </tt><tt>NCP>push</tt><tt><br>
        </tt><tt>@i dec</tt><tt><br>
        </tt><tt> Local DECNET node: VENTI2.  Nodes reachable: 6.</tt><tt><br>
        </tt><tt> Accessible DECNET nodes are:    A2RTR    APOLLO   
          LEGATO    TOMMYT    VENTI2    ZITI</tt><tt><br>
        </tt><tt>@pop</tt></font></p>
    <p><font size="+1"><tt>NCP>purGE noDE ziti:: alL <br>
          NCP><br>
          13:45:47     NCP<br>
          <br>
          Request # 14; Purge Node Failed, Operation failure<br>
          <br>
          NCP><br>
        </tt><tt><br>
        </tt></font></p>
    <hr width="100%" size="2">
    <div class="moz-cite-prefix">On 3/7/20 12:41 PM, Johnny Billquist
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:d4a4d464-6a90-b660-e22e-aacc02882c94@softjar.se">On
      2020-03-04 00:57, Thomas DeBellis wrote:
      <br>
      <blockquote type="cite">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).
        <br>
        <br>
        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.
        <br>
      </blockquote>
      <br>
      In RSX there is no documented way to map between node names and
      addresses, in either direction.
      <br>
      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.
      <br>
      <br>
      <blockquote type="cite">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).
        <br>
        <br>
        Curiouser and curiouser.  Do the above two functionalities exist
        in other operating systems?
        <br>
      </blockquote>
      <br>
      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.
      <br>
      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.
      <br>
      <br>
      I think RSTS/E does it all through NCP, like in VMS, but I guess
      Paul can tell for sure.
      <br>
      <br>
        Johnny
      <br>
      <br>
    </blockquote>
  </body>
</html>