[HECnet] More NRT

On May 5, 2020, at 1:21 PM, Thomas DeBellis <tommytimesharing at gmail.com> wrote: Thanks Paul, As usual, very informative. What you've verified is Tops-20's monitor based NRT server implementation, which is good. Therefore, for the moment, I think it reasonable to assume that the monitor client implementation is also not suspect. NI1D displayed the same failure mode as Tron: report of a successful connection and then, nothing, viz: % Do not have Control-C capability, proceeding... Escape character(^Y): Host name: NI1D [Connecting to remote host: NI1D] [Remote system is running RSTS/E] [Connected: type ^Y to return to node VENTI2] This shows that the client had a successful connection and handed off to the monitor. This was verified by further investigation (with SYSDPY which showed SETHOST in a WAIT%, pending interrupt from the MTOPR%). Since the NRT client implementation eventually hands off to the monitor for all the data flow, for Initial investigation, I'll have a look at some that pre-MTOPR% post-connection open logic. I'll try to do a little more trouble shooting tonight and see what might be happening.

You mention four 'flavors' (?) of NRT; are these documented anywhere? (I mean, other than in the code...)

From the messages you quoted, it looks like SETHOST knows it's talking to a RSTS system, which should mean it knows to speak that protocol, but apparently something goes wrong in there somewhere. The fact that the RSTS end breaks is of course a bug at that end -- it violates rule 1 of distributed systems, "if your code fails because of a received message, it is always your fault, not the sender's".