[HECnet] Cisco DECnet routers and NML

[Johnny Billquist]

The potential win with CTERM was that much processing could actually be 
done locally, instead of having to travel back and forth between the 
machines for every key stroke.

Essentially it's like RPC. Or, as Paul put it, basically the whole QIO 
interface mapped to a protocol. And it might be hard to understand what 
this actually means. The terminal driver in RSX and VMS are probably the 
most complicated driver there is. It can do almost anything with a 
single I/O request. Reading? Sure. With promps? Yes. And timeouts? 
Definitely. No echo? Yup. Terminating on arbitrary characters? 
Absolutely. With special processing for escape sequences? Yup. With 
prepopulated input? No problem. All in one QIO... And there is more...
There is a pretty large section in the manual set just dealing with the 
terminal driver in RSX.

All of this then, obviously, needs to be somewhat implemented in any 
other system that talks CTERM. Which absolutely does not map to how 
terminal I/O is done on some other systems.

CTERM was just the absolute wrong abstraction layer to use for a network 
terminal system. Sure, the abstraction and offloading might look 
tempting, but the complexity equally so. And really, in the end, each 
system already know how to deal with a stream of bytes, since that is 
what any physical serial interface controller will give you. That is the 
lowest common denominator. That is pretty much what they should have done.

If DAP is an example, where there is actually a lot of value added by 
the protocol, and where there are things that I can say I sometimes 
really miss when dealing with TCP/IP using FTP, NFS or whatnot, CTERM is 
the perfect example of when DEC really did it wrong, and telnet is a 
dream in comparison.

   Johnny

On 2020-05-05 22:28, Thomas DeBellis wrote:
> 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.
>>


-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt at softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol