19 Oct
2015
19 Oct
'15
11:30 a.m.
On 2015-10-19 19:42, Paul Koning wrote:
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
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:
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. 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.