[HECnet] Cisco DECnet routers and NML

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. >