7 Aug
2022
7 Aug
'22
5:04 p.m.
On Aug 7, 2022, at 10:47 AM, Paul Koning
<paulkoning(a)comcast.net> 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.
The original Linux DECnet code tries to pretend that it’s VMS, so it uses code 7.
When I started to clean up the code (I just noticed that Cterm still uses code 7 when the
client accepts the bind request), I changed FAL to use one of the user-specified values
(192 I think). Most everything works OK except TOPS-10 refuses to connect and I had to
special case returning the Ultrix-32 code.
John.
paul
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