<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Well, yeah, but 'better' can be a very loaded word... The NRT
protocol certainly appears simpler than CTERM, which struck we
Tops-20 developers as very VMS-centric, too.</p>
<p>The Tops-10 and Tops-20 groups operated in a realm where a lot of
money was getting spent on costly systems that were nearly always
saturated with too many users. Tops-10 SMP alleviated certain
cases of this. That functionality could have been more fully
leveraged in Tops-20, which supports a richer process model, but
the hardware didn't support multi-ported memory. Multi-processor
TENEX did exist. I recall a dual KI TENX on the ARPAnet; it may
have been SUMEX-AIM. Tops-20's CI implementation was nice, but it
didn't solve all the problems that SMP (or the KC) would have.</p>
<p>Given the above, there was an emphasis on simplicity of design
and code efficiency unless hair was absolutely necessary. This
isn't to say that some pretty complex code wasn't written, but
this was typically to wring as much as possible out of the
processor.<br>
</p>
<p>VMS and RSX seemed to have poked their heads up in other areas of
DECnet. Tops-10's (pre-level D) file system is basically block
structured. The blocks are larger in Tops-20, I/O is more
efficient, the files can have holes, a character (byte) interface
exists and the lexical interface is richer. We were aware of the
richness of the MVS file formats, but had never seen any
particular use for the complexity. When we bumped into DAP, the
first response was, "Gee, what do you need all this MVS stuff
for?"</p>
<p>DAP certainly does more than FTP can by far, but all the file
formats were lost on (the few) developers who knew both MVS and
Tops-20.</p>
<p>The question for CTERM is what is the additional hair really
getting you? What can it do that NRT doesn't. From the user
mode, you can't tell the difference (modulo certain shortcomings
in the Tops-20 implementation that I don't know if they are being
caused by the protocol). I have only a passing familiarity with
CTERM, some with LAT and little with NRT; so I can't really
comment on what the CTERM value add is/was.<br>
</p>
<div class="moz-cite-prefix">
</div>
<blockquote type="cite"
cite="mid:6050A895-29FF-4A57-94E9-D28B8333032E@comcast.net">
<hr width="100%" size="2">
<pre class="moz-quote-pre" wrap="">On 5/5/20 9:44 AM, Paul Koning wrote:
</pre>
<pre class="moz-quote-pre" wrap="">
FWIW: it makes sense that NRT works better than CTERM for TOPS-20. The same would be true for RSTS if it implemented CTERM at all, which it doesn't. (Two reasons for that: (1) the vast complexity of CTERM, (2) the fact that RSTS was told not to by management who didn't particularly care for RSTS's existence.)
While CTERM claims to be a general protocol, it's obvious by inspection that it is really a generalization of the RSX/VMS style of terminal I/O, which is rather different from that of RSTS, TOPS-10, or TOPS-20. So implementing CTERM on those amounts to an exercise in forcing the native OS terminal semantics through what amounts to a VMS terminal QIO API.
paul
<blockquote type="cite"><hr width="100%" size="2"><pre class="moz-quote-pre" wrap="">On May 4, 2020, at 6:29 PM, Thomas DeBellis <a class="moz-txt-link-rfc2396E" href="mailto:tommytimesharing@gmail.com"><tommytimesharing@gmail.com></a> wrote:
...
Right now, I'm working on SETHOST, which is a client for the earlier NRT protocol (Network Remote Terminal) that predates CTERM on the 36 bit platform. It's more efficient than CTERM (I have yet to compare it with LAT) and will do certain things that I like that the Tops-20 implementation of CTERM doesn't.</pre></blockquote>
</pre>
</blockquote>
</body>
</html>