Trying to unravel some of this very informative thread.

On Nov 21, 2022, at 2:41 PM, Johnny Billquist <bqt@softjar.se> wrote:

Yeah. NRT is a bit odd. And unless I remember wrong, some variant don't even send anything at the start, so it's even more screwball to identify what you should try and speak.

On 2022-11-21 20:53, Paul Koning wrote:

I haven't seen any NRT servers that fail to send a config saying what flavor they are.  Only the server does; the client expects the server to speak first after connection is made.
On 11/21/22 5:52 PM, Johnny Billquist wrote:

You forget fast. :-)

Here is what I wrote in August this year:

[...]

So basically, the TOPS-20 NRT server is not sending anything when you connect,

Am I understanding you correctly?  Are you sure about that?  May I ask you to send me an example where this happens?  Paul's recollection agrees with my experience.  Also, the monitor code for NRT (in NRTSRV.MAC at NRTRSS) specifically sends a configuration message after accepting the connection (I just checked), an interesting comment being:

CFGLEN==10                      ;BYTES IN CONFIG MESSAGE
CFGMSG: BYTE(8) 1,1,0,0,10,0,10,0
;       Config--' ^ ^ ^  ^ ^  ^ ^
;                 ? ? ?  | ?  | ?
;       System=TOPS20----'    |
;       Protocol=TOPS20-------'

So if you are not seeing that, there is another bug for me to find.

Looking at the TOPS-20 client, there don't seem to be any system checking or init message at all.
That's not my experience nor my understanding of the current code base.  Neither SETHOST or Kermit-20 will display output until they get a configuration message.  However, they will accept input because they are running different forks for input and output.

I have tested this on a number of systems on HECnet.  You can start typing because you are running asynchronously, but eventually you will gronk when SETHOST gets the wrong OS type byte (the wrong way to do it) and Kermit-20 detects an incompatible Protocol (the right way to do it).

It is a true statement that VERY old versions (Phase II, circa 1979) of Tops-20 NRT servers and clients don't do any system checking.  However, they are connecting on port 200 instead of 23.  The Phase II 'protocol' (if you can even call it that) does nothing more than transfer data to and from a PTY.

Linux is after all just another Unix in this sense, and would suite very well into just pretending to be Ultrix.
They certainly sure do smell the same.  However, having programmed both Ultrix and Linux, I can tell you that there are some significant API differences, particularly in the area of shared memory and semaphores.  And the differences in shells and other programs are not always negligible.  However, your point is valid enough.
But by that reasoning, all RSX-11/M variants should use the same code, and likewise RSX-11/D and IAS should share a code.  After all, they are essentially the same OS...
An even better point, IMHO.
In any case, the main point is that OS code 192 is a code with a well defined meaning, so for an NFT to complain about it isn't simply a violation of the "be lenient in what you receive" rule, it's a direct violation of the definitions in the protocol spec.
Agreed.

Indeed, I would go even further: in my opinion it is the hallmark of poorly written code to simply give up and drop dead.  I would say at least half of our efforts at Columbia were spent tracking down and either fixing bugs or writing code to recover from them.  CMU couldn't figure out a DECnet memory leak in the 4.0 timeframe, but had an interesting program that would go through the free list and return the memory so the system didn't crash.  They called it "DECnet Liquid Plumber".  It was a fine hack until the problem was finally tracked down.

Telephones would explode when a large timesharing system went down...  It was the last thing you ever wanted to happen.