[HECnet] Cisco DECnet routers and NML

[Thomas DeBellis]

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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sonic.net/pipermail/hecnet-list/attachments/20200505/80f8fdf4/attachment.html>