8 Aug
2022
8 Aug
'22
3:01 p.m.
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
On 2022-08-07 16:47, Paul Koning wrote:
I view "OS type identifier" fields as a
bad practice and likely to lead to unnecessarily broken code. I had that exact discussion
with the DECnet/VMS team back in the 1980s, when their DAP implementation used the OS
identifier to hardcode assumptions about the capabilities of that OS. Those assumptions
break, of course, when the OS in question implements new features.
I argued vociferously that they must make decisions about capabilities from the
capabilities flags of the protocol and from nothing else, and if they encounter a need to
distinguish something not encoded by such a flag, to get the flag added. I think I got
the message through.
Same here. If the other side sends a protocol code that's acceptable, you have a
valid config message. If you want to use the OS code for an informative message like you
did, that's perfectly fine, but in that case the right way to deal with unrecognized
codes it to say something like:
?Operating system code 42 does not support Tops-10/20 NRT communications.
In other words, the message isn't illegal; it merely contains a code you don't
know about.
According to my remote-terminal.txt document, there's another type code not shown in
your table, 18 for Ultrix-32. It wouldn't surprise me if Linux borrowed that code.
paul
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se On Aug 7, 2022, at 12:13 AM, Thomas DeBellis
<tommytimesharing(a)gmail.com> wrote:
In my changes to Kermit-20 and SETHOST, I check the configuration byte to make sure that
I'm communicating with either a Tops-10 or Tops-20 system. If it's not one of
those, then I want to give a nifty, informative error message, such as:
Kermit-20>connect APOLLO::
?VMS type systems do not support Tops-10/20 NRT communications.
Kermit-20>connect MIM::
?RSX-11M type systems do not support Tops-10/20 NRT communications.
Kermit-20>connect TRON::
?RSTS/E type systems do not support Tops-10/20 NRT communications.
Pretty nifty. I do this by doing a lookup into a handy table, indexed by the OS type,
viz:
hsttyp: eascii <RSTS> ;^d0
eascii <RT-11> ;^d1
eascii <RSTS/E> ;^d2
eascii <RSX-11S> ;^d3
eascii <RSX-11M> ;^d4
eascii <RSX-11D> ;^d5
eascii <IAS> ;^d6
eascii <VMS> ;^d7
eascii <TOPS-20> ;^d8 (TOPS20)
eascii <TOPS-10> ;^d9 (TOPS10)
eascii <RTS-8> ;^d10
eascii <OS-8> ;^d11 (!!)
eascii <RSX-11M+> ;^d12
eascii <MCB> ;^d13 (the DN20!!)
hsttyn=.-hsttyp-1 ; Number of defined operating system types
So if the number I get is outside of this range, I give an unknown error, such as:
Kermit-20>connect ZITI::
?Remote system sent an illegal configuration message
ZITI:: shows as a Linux system. Does anyone know what its configuration byte would be?
How about Windows? Ultrix? Any others?
I don't recall whether we used NRT or CTERM to get into our Ultrix machine (it was an
8650, consequently upgraded to an 8700). I think we used TCP/IP TELNET.
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se