<html>
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
</head>
<body>
<p>Paul,<br>
</p>
<p>Thanks for the doc; I'll be giving it a careful look through.
Where might I pick up a copy of DNTERM?<br>
</p>
<div class="moz-cite-prefix">It is a true statement that the Tops-20
NRT server is little more than a character stream. Like I said,
it's very close to Telnet without the IAC's and option
negotiations. For my future purposes (handling a security concern
with the Tops-20 FAL architecture), it is perfect.</div>
<div class="moz-cite-prefix">
<p>I remembered some more about CTERM; it appears to implement a
concept called break masks. Under Tops-20, if you are doing
something that needs to handle characters specially, one
alternative is to turn off echo, swallow a character and then
determine what to do. This was used in some Tops-10 video based
'SYSTAT'ing programs that I am aware of.</p>
<p>However, this means you're doing a context switch on every
blessed character. And so are 90 other people, which is Bad.
It's way too much overhead. A break mask means that you can
have the monitor swallow and echo characters and determine when
to return control to the user program. This was worked on
enough so that TEXTI% actually had something called an 'EMACS'
mode, specifically to support this.</p>
<p>I don't recall whether this was pushed out to the front end;
hard to say. The VT100 really handed it to the front end.</p>
<p>There were some early attempts towards break masks in some
Telnet options; host controlled local echoing and some such. I
don't remember the RFC, but it is quite old.</p>
<p>I don't remember whether LAT will handle a break mask; if it
could, then that's great--the LAT host worries about gobbling
characters and when to send a packet to the host. That's far
more efficient.</p>
<p><br>
</p>
<p>I modified SETHOST to have an additional entry point to force
4.2 behavior; meaning using two separate forks for input and
output instead of handing the whole thing off to the monitor
with MTOPR%. This was so I could use SYSDPY to see the actual
scheduler tests that the forks were waiting for; that's not as
easy when the whole thing is in the monitor.</p>
<p>So RSX and VMS accept the connection and both the client (me)
and the remote wind up waiting. As soon as I type a character,
I get thrown off, so I would imagine that there is some
additional negotiations to be done. I'm hesitant to try this on
RSTS as somebody is going to need to restart the NRT server.</p>
<p>NRT is pretty simple; on connection, it reads a configuration
message, but only looks at the first byte to see what the remote
system is. That's enough for it to blat about it not being to
either Tops-10 or Tops-20. The other stuff is completely
ignored; I don't see evidence of any configuration being sent.
I guess those other bytes are what I should be looking at.
Maybe they'll be in your doc?</p>
<p>What was interesting was the multi-forking behavior versus
handing everything off to the monitor. I remember this code
back in the 1980's and we thought it was the greatest thing
ever. We modified our EXEC to do the call itself and not even
bother forking SETHOST.</p>
<p>The multi-fork code performance is incredible; stuff blinks
right on to the screen. The monitor-only code is far slower.
I'm at a loss to explain that and wonder if it has anything to
do with KLH10's NI implementation.<br>
</p>
</div>
<blockquote type="cite"
cite="mid:A78F336A-3D9E-4541-A3FE-B9A4E286BD48@comcast.net">
<hr width="100%" size="2">
<pre class="moz-quote-pre" wrap="">On 5/5/20 5:06 PM, Paul Koning wrote:
I was pretty sure I had done a short writeup a while ago. Just found it. It was done in 2000, as part of an effort on my part to improve "dnterm", the Linux remote terminal client. I'm fairly sure I created it by reverse engineering the source code of the RSTS client. Take it with some grains of salt, but I'm fairly sure it was sufficiently accurate to allow dnterm to talk all four protocols.
BTW, Linux uses TOPS-20 mode, I think. That's basically a raw character (character at a time) transport. RSTS has a choice of line mode or character mode. RSX and VMS, as Johnny explained, try to offload the entire terminal driver semantics onto the other end, which makes the client a nice challenge on a system like RSTS that is entirely different.
paul
</pre>
<blockquote type="cite">
<hr width="100%" size="2">
<pre class="moz-quote-pre" wrap="">On May 5, 2020, at 4:08 PM, Thomas DeBellis <a class="moz-txt-link-rfc2396E" href="mailto:tommytimesharing@gmail.com"><tommytimesharing@gmail.com></a> wrote:
Johnny,
Thanks for the screen shots! It figures RSX gets it right with everybody... One wonders whether the group didn't have sufficient 'weight' to throw around to get others groups to see their point of view, as it were. At a certain point, there appears to have been a significant amount of NIH going on, particularly after the VMS/BLISS corporate direction/mandates came down.
So RRS and HOST are different NRT client applications, then? Can you comment on the protocols spoken? Or would you have source available?
</pre>
</blockquote>
</blockquote>
</body>
</html>