It is a true statement that the format of FIX.T20 file is compatible the NCP sub-mode of Tops-20 OPR, viz:

NCP>set noDE 2.251 namE SCONOS::
NCP>
14:03:47     NCP

Request # 344; Set Node Completed
NCP>shoW noDE 2.251
NCP>
14:03:55     NCP

Request # 345; Show Node Summary Completed

Remote Node = 2.251 (SCONOS)

  State = Unreachable
NCP>

This is by design because the file is actually handled by something else, SETNOD.  SETNOD parses the file, and produces a binary format file which can be directly swallowed by the NODE% JSYS' .NDINT function.  So that's a few JSYi and you're done.  This is really important at boot time when a lot of stuff is cranking up.

Otherwise, using OPR will be very slow.  In addition to parsing the indicated text, an IPCF message has to get built which is then sent to Orion who then hands off to NMLT20 to do the work.  So that's a bunch more JSYi and five context switches for every node.  You really don't want to do this at boot time as there are timing and resource issues you can bump into and it slows down the boot.

Unfortunately, there is undocumented behavior in Tops-20 that, if you redefine a node in another area, everything is fine.  If, instead, you try to do this to a node in the same area, you'll get a cryptic error.  You've got to delete the node first.  However, to find that out, you need to make a lot of changes to the monitor to get the secondary error code back and have SETNOD to display it.

I did all that plus entirely rewrote SETNOD to be aware of the node deletion requirement before putting in the new definitions.

This is all done by a something-weekly batch job that pulls the FIX.T20 file down and then has SETND2 parse it.  If there are no changes, then nothing happens.  If there are changes, then SETND2 does things the right way and only puts in the updates; maybe a handful of nodes.  I would imagine that I could have 'fixed' the monitor to do this itself, but I was unsure as to why the behavior was as it was in the first place and thus I fixed it in user mode.  Such incremental updates are also more efficient for the monitor.

This has all worked uneventfully for well over a year on TOMMYT:: and VENTI::, although I do tinker with the code from time to time when the mood strikes me.  One thing I did was to do a multi-forking JSYS trapping based simulation mode (using TFORK%) to allow me to do testing without choking the monitor.  That enable me to do things with the local executor that Tops-20 only permits once per boot.

This will all get posted as PANDA II when I get out of all the rabbit holes I'm in.

Meanwhile, I'm not aware of any 20 site regularly updating their node database.  I couldn't say about Tops-10.

DATATRIEVE sounds awfully familiar.  Was there a 36 bit version of it?

---

On 9/30/23 8:32 AM, Johnny Billquist wrote:
    .
    .
    .

FIX.T20 - This is a script for TOPS-20.

    .
    .
    .

TOPS-20:

Grab MIM::HECNET:FIX.T20 and run in in the NCP submode of OPR (if I remember the setup correctly).