8 Aug
2022
8 Aug
'22
3:19 p.m.
On Aug 8, 2022, at 9:01 AM, Paul Koning
<paulkoning(a)comcast.net> wrote:
Johnny,
The different variants of which you speak are distinguished by the protocol code.
Clearly if you see an unrecognized value there you cannot proceed. But the OS type value
is unrelated and is just random information that really serves no good purpose. If you
have an RMterm implementation that makes operational decisions based on the OS code,
that's a mistake.
paul
> On Aug 7, 2022, at 5:37 PM, Johnny Billquist <bqt(a)softjar.se> wrote:
>
> While I agree in principle, the thing really is that the different variants are not
interoperable, and there is no other way to tell them apart.
>
> The RSX clients do exactly what Thomas describes. And as I mentioned, there are
multiple RSX clients, for connecting to the different type of systems.
>
> Johnny
To make it specific: (quoting from remote-terminal.txt):
Config message format -- daemon to initiator:
Offset Length Contents
0 1 Message type (1)
1 1 Version (1)
2 1 DEC ECO (1)
3 1 Customer ECO (0)
4 2 System type
6 2 Protocol type
Note that there is NO LENGTH FIELD in this message.
System type codes:
1 RT-11
2 RSTS/E
3 RSX-11S
4 RSX-11M
5 RSX-11D
6 IAS
7 VAX/VMS
8 TOPS-20
9 TOPS-10
10 OS8
11 RTS-8
12 RSX-11M+
13..17 reserved
18 Ultrix-32
Protocol type codes (apparently encoded as a bitmap!):
1 RSTS/E
2 RSX
4 VMS
8 TOPS-20
The field at offset 6 (protocol type, the last list, 4 code points) is how you know what
protocol to speak. The field at offset 4 (system type code, the long list of values) is
irrelevant for protocol operation. It's perfectly legal for a system to send system
tpye code 2 and protocol code 8. For that matter (the case under discussion) it's
fine for a system to send protocol code 8 and system type 73; if so a correctly operating
client would go to the TOPS-20 (raw byte streams) protocol mode. The fact that it has no
clue what OS is represented by code 73 is beside the point.
paul