DecServer 550 chassis

[Johnny Billquist]

On 2015-10-19 19:42, Paul Koning wrote:
>
>> On Oct 19, 2015, at 12:17 PM, Johnny Billquist <bqt at update.uu.se> wrote:
>>
>> On 2015-10-19 16:32, Paul Koning wrote:
>>>
>>>> On Oct 19, 2015, at 3:42 AM, Pontus Pihlgren <pontus at Update.UU.SE> wrote:
>>>>
>>>> Interesting. I thought Tthe DECserver 550 was merely the big brother in
>>>> the terminal server line. But it looks like it is essentially a
>>>> PDP-11/53 with 1.5MW of ram, you need new boot roms though. Pretty nice.
>>>
>>> It's been a while, but I think it may be a member of the "pluto" family.  The original plan for terminal servers was that they would run CTERM.  But the initial Pluto terminal server was incredibly slow, not surprising given how complex that protocol is.  So an AD project was started which created LAT, originally also in a PDP-11 processor (perhaps even the same one, I forgot).  And that turned out to be so superior in practice that it ended up being the main product instead of the original plan.  But we still have CTERM as a leftover from all this.
>>
>> Yeah, that should be PLUTO.
>> It's based on RSX, and talks LAT. I never knew that they considered using CTERM (a horrible protocol).
>
> Oh yes... and I think the original PLUTO was an 11/23, which would certainly explain why it had performance issues.
>
> CTERM was an attempt to wrap a single protocol around the terribly inconsistent semantics of the terminal drivers in all the DEC operating systems, and to export as much as possible to the server end.  In other words, the goal of the protocol was to be line oriented as much as possible.  That meant, for example, exporting the command line editing machinery to the server.  That doesn't seem so bad until you realize that the server has to be told a whole lot about what is going on at the client in order to do that.  The eventual goal was to have not just command line mode but also other modes, like screen editing mode (think distributed EDT).  That's why there are two layers, with the foundation layer common to all modes, and Cterm the first of the modes to be defined.
>
> Some example of the complexities: the ability to define what characters are line edings; immediate vs. delayed echo; command line completion in TOPS-20; and so on.
>
> When the dust settled, the 36 bit machines were starting to disappear around this time, and management was trying to do similar things to PDP11s in general and non-RSX in particular, so CTerm ended up being really just a ridiculously complex way of doing what the old VMS terminal protocol did just as well.

An interesting way to describe it.
I've always looked at CTERM as an RPC service that essentially have all 
the functions of the VMS terminal driver. Makes it easy to implement in 
VMS, as you have a 1:1 mapping. Makes it horrible for everyone else, 
since other systems do not have the same functionality in the terminal 
driver, and now have to implement all the remote procedure calls of the 
VMS terminal driver, and somehow map that into how the native terminal 
driver works...

	Johnny