[HECnet] Re: Nodename updating

------------------------------------------------------------------------ On 9/30/23 7:01 PM, Johnny Billquist wrote: Thomas, if you could write up how to use SETNOD, I'd be happy to put that into my documentation. It's been a long time since I did anything in T20, and this is one of the things I played very little with... Doc have been placed at http://mim.stupi.net/hecdb.htm   Johnny > ------------------------------------------------------------------------ > > On 2023-09-30 20:37, Thomas DeBellis wrote: > > 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 > thelocal 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 ofit? >> ------------------------------------------------------------------------ >> >> 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).