[HECnet] Re: Tops-20 NFT limited parse types for RSX systems?

Trying to unravel some of this very informative thread. 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. 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. 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. An even better point, IMHO. 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.