7 Aug
2022
7 Aug
'22
6:13 a.m.
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.
7 Aug
7 Aug
4:47 p.m.
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
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
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 
11:46 p.m.
On 2022-08-07 17:04, John Forecast wrote:
The funny/weird thing is that mostly the same list of OSes are used by
multiple protocols, but the list is not always identical.
And with CTERM I don't think it really matters. But for NRT it does.
And with FAL, at least RSX can even tell what the remote side is.
Nothing breaks for unknown system types, but it's nice to see.
.ncp tell fedach sho exec
Node summary as of 7-AUG-22 23:45:36
Executor node = 31.13 (FEDACH)
Circuit = eth1, State = On
Identification = DECnet for Linux V3.13.0-170-generic on i686
.nft fedach::/id
NFT -- Version V9.0
Local NFARs V8 DAP V7.1 Buffer size= 2064. OS=RSX-11M+ FS=FCS-11
DC=Yes
Remote FAL V5 DAP V7.2 Buffer size= 65535. OS=VAX/VMS FS=RMS-32
DC=No
I guess somewhat old DECnet/Linux there...
Johnny
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.
--
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
paul
_______________________________________________
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
8 Aug
8 Aug
2:37 a.m.
On Aug 7, 2022, at 5:46 PM, Johnny Billquist
<bqt(a)softjar.se> wrote:
On 2022-08-07 17:04, John Forecast wrote:
The funny/weird thing is that mostly the same list of OSes are used by multiple
protocols, but the list is not always identical.
And with CTERM I don't think it really matters. But for NRT it does.
And with FAL, at least RSX can even tell what the remote side is. Nothing breaks for
unknown system types, but it's nice to see.
.ncp tell fedach sho exec
Node summary as of 7-AUG-22 23:45:36
Executor node = 31.13 (FEDACH)
Circuit = eth1, State = On
Identification = DECnet for Linux V3.13.0-170-generic on i686
.nft fedach::/id
NFT -- Version V9.0
Local NFARs V8 DAP V7.1 Buffer size= 2064. OS=RSX-11M+ FS=FCS-11 DC=Yes
Remote FAL V5 DAP V7.2 Buffer size= 65535. OS=VAX/VMS FS=RMS-32 DC=No
I guess somewhat old DECnet/Linux there...
That’s still the default. I wrote an alternative FAL which responds with the
user-specified code and doesn’t try to
emulate any RMS features (indexed files etc). Unfortunately, it only implements DAP 5.6.0
since that’s the latest
version of the spec I could find.
John.
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.
Johnny
John.
--
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 paul
_______________________________________________
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
11:19 a.m.
On 2022-08-08 02:37, John Forecast wrote:
Ah. I thought you meant you changed it in the existing code.
Anyway, why not reuse Ultrix? Would make some sense, since it's another
Unix-style system that would have the same semantics and capacities. If
anything cares, it would hopefully make good guesses with that.
Johnny
--
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
On Aug 7, 2022, at 5:46 PM, Johnny Billquist
<bqt(a)softjar.se> wrote:
On 2022-08-07 17:04, John Forecast wrote:
The funny/weird thing is that mostly the same list of OSes are used by multiple
protocols, but the list is not always identical.
And with CTERM I don't think it really matters. But for NRT it does.
And with FAL, at least RSX can even tell what the remote side is. Nothing breaks for
unknown system types, but it's nice to see.
.ncp tell fedach sho exec
Node summary as of 7-AUG-22 23:45:36
Executor node = 31.13 (FEDACH)
Circuit = eth1, State = On
Identification = DECnet for Linux V3.13.0-170-generic on i686
.nft fedach::/id
NFT -- Version V9.0
Local NFARs V8 DAP V7.1 Buffer size= 2064. OS=RSX-11M+ FS=FCS-11 DC=Yes
Remote FAL V5 DAP V7.2 Buffer size= 65535. OS=VAX/VMS FS=RMS-32 DC=No
I guess somewhat old DECnet/Linux there...
That’s still the default. I wrote an alternative FAL which responds with the
user-specified code and doesn’t try to
emulate any RMS features (indexed files etc). Unfortunately, it only implements DAP
5.6.0 since that’s the latest
version of the spec I could find. On Aug 7,
2022, at 10:47 AM, Paul Koning <paulkoning(a)comcast.net> wrote:
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.
7 Aug
7 Aug
11:37 p.m.
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
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
8 Aug
8 Aug
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
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
7:11 p.m.
I need to look at the sources in RSX to recall exactly how it's done.
And I can't do that until I'm back from vacation in two weeks.
But I didn't write any of the code. That much I can say. I've fixed a
couple of bugs in that code in RSX, and looked at it for/with Thomas,
but that's it.
But let me get back to the details of the implementations I have access to.
But trying to use HOST (for connection to TOPS) or RRS (for connection
to RSTS/E) on MIM towards MIM gives this:
.host mim
RSX-11M-Plus"RSX system at Stupi, Sweden"MIM
HOS -- Target system has disconnected
.rrs mim
MIM::RRS -- Failed to receive configuration message
MIM::RRS -- Control returned to node MIM::
.
So - various "funny" behavior.
And examples of successful connections:
.host rbdash
Rainbow Dash, TOPS-20 Monitor 7(21017)
@LOGO
Killed Job 10, TTY 146,
at 8-Aug-2022 19:09:03, Used 0:00:00 in 0:00:03
HOS -- Target system has disconnected
.rrs pirsts
MIM::RRS -- Connection established to node PIRSTS::
RSTS V10.1-L 08-Aug-22 19:09
User: ^Z
MIM::RRS -- Remote disconnect
MIM::RRS -- Control returned to node MIM::
.
And with RMT, which is used for RSX:
.rmt mim
Connected to "MIM ", System type = RSX-11M-Plus
System ID: "RSX system at Stupi, Sweden"
Johnny
On 2022-08-08 15:01, Paul Koning 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
--
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
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:
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se 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 
7 Aug
7 Aug
5:36 p.m.
Thomas DeBellis <tommytimesharing(a)gmail.com>
wrote:
ZITI:: shows as a Linux system. Does anyone know what its configuration byte would be?
ZITI is indeed a Linux machine, Ubuntu 16.04 (support for DECnet on later distros begins
to become a bit problematic). You could just connect to it and see what it returns. It
won't let you log in (hopefully it won't let you log in!) but you shouldn't
need that to find your answer.
Bob
11:47 p.m.
On 2022-08-07 17:36, Robert Armstrong wrote:
.nft ziti::/id
NFT -- Version V9.0
Local NFARs V8 DAP V7.1 Buffer size= 2064. OS=RSX-11M+ FS=FCS-11
DC=Yes
Remote FAL V5 DAP V7.2 Buffer size= 65535. OS=VAX/VMS FS=RMS-32
DC=No
Johnny
--
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
Thomas
DeBellis <tommytimesharing(a)gmail.com> wrote:
ZITI:: shows as a Linux system. Does anyone know what its configuration byte would be?
ZITI is indeed a Linux machine, Ubuntu 16.04 (support for DECnet on later distros
begins to become a bit problematic). You could just connect to it and see what it
returns. It won't let you log in (hopefully it won't let you log in!) but you
shouldn't need that to find your answer.
837
days inactive
838
days old
11 comments
5 participants
participants (5)
-
John Forecast -
Johnny Billquist -
Paul Koning -
Robert Armstrong -
Thomas DeBellis