5 May
2020
5 May
'20
10:28 p.m.
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.
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.
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.
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?"
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.
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.
------------------------------------------------------------------------
On 5/5/20 9:44 AM, Paul Koning wrote:
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
------------------------------------------------------------------------
On May 4, 2020, at 6:29 PM, Thomas DeBellis <tommytimesharing at gmail.com> 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.