7 Nov
2021
7 Nov
'21
11:23 a.m.
Since its inception, Kermit-20 (one the first three Kermit
implementations) has had the 'limitation' that it will only talk to a
remote Kermit via a physical terminal line (I.E., something like
TTY6:).? It doesn't do network terminals in part because it has no code
to handle the out-of-band or meta-data that one finds on TVT's (like
IAC's) or CTERM's.
This doesn't exist for the early NRT terminals which were implemented
for Tops-10 and Tops-20.? Once you've read the initial configuration
message and decided what to do, you basically never have to bother with
meta-data.? Because I'm trying to look at an NFT issue between Tops-10
and Tops-20, I needed another transport mechanism and modifying
Kermit-20 to do DECnet 36 NRT's seemed like an easy hack.? Since Tops-10
Kermit isn't making an outgoing connection, it is none the wiser.
Thus far, it has been fairly straightforward.? Right now I'm just
catching the few cases where certain operations don't make sense or
otherwise wouldn't work (like setting the terminal speed). Another thing
I'd like to prevent is Kermit-20 bothering non-36 bit systems.? This is
easily enough done by checking some 'magic' bits in the initial
configuration message and restricting by OS type.? This raises two
questions:
First, is the list below complete?? What about Ultrix and ... what else?
?1??? RSTS ?2??? RT-11 ?3??? RSTS/E ?4??? RSX-11S ?5??? RSX-11M
?6??? RSX-11D ?7??? IAS ?8??? VMS ?9??? TOPS-20 10??? TOPS-10 11???
RTS-8 12??? OS-8 13??? RSX-11M+ 14??? MCB
Second, the configuration isn't well documented.? Actually, I'm not sure
if it's documented, period.? All I have is are some notes that Johnny
wrote up in the process of reverse-engineering it and very kindly gave
me.? They are certainly fine for this particular implementation, but I
was just wondering what else there might be. Plenty for LAT and CTERM,
but I don't think I've stumbled over NRT.
7 Nov
7 Nov
12:17 p.m.
Thomas, I'm not sure where you got that list from.
It seems slightly mismatching what I can find. Looking at the NRT code
in RSX (which uses object 23, and is shared by code in RSX for
connecting to both RSTS/E, VMS and Tops-20), I find this:
1 RT-11
2 RSTS/E
3 RSX-11S
4 RSX-11M
5 RSX-11D
6 IAS
7 VMS
Those are the documented values for the configuration message that I can
find.
However, extrapolating from this, in NFT/FAL, there is a much more
extensive list, which seems to align with this list, which contains:
8 TOPS-20
9 Tops-10
10 RTS-8
11 OS/8
12 RSX-11M-PLUS
13 COPOS/11 (TOPS-20 frontend)
14 P/OS
15 VAXELN
16 CP/M
17 MS-DOS
18 Ultrix-32
19 Ultrix-11
20 DTF/MVS
25 Windows NT
26 Linux
Now, Linux is a value I believe I added just based on observation, so
it's much less official. But I think all the other ones are ones DEC did
assign. Unfortunately, I think Windows NT was also added by me, based on
observation of Pathworks. So I do not know what the values between 20
and 25 could/should be.
But maybe this helps some anyway?
Johnny
On 2021-11-07 11:23, Thomas DeBellis wrote:
Since its inception, Kermit-20 (one the first three
Kermit
implementations) has had the 'limitation' that it will only talk to a
remote Kermit via a physical terminal line (I.E., something like
TTY6:).? It doesn't do network terminals in part because it has no code
to handle the out-of-band or meta-data that one finds on TVT's (like
IAC's) or CTERM's.
This doesn't exist for the early NRT terminals which were implemented
for Tops-10 and Tops-20.? Once you've read the initial configuration
message and decided what to do, you basically never have to bother with
meta-data.? Because I'm trying to look at an NFT issue between Tops-10
and Tops-20, I needed another transport mechanism and modifying
Kermit-20 to do DECnet 36 NRT's seemed like an easy hack.? Since Tops-10
Kermit isn't making an outgoing connection, it is none the wiser.
Thus far, it has been fairly straightforward.? Right now I'm just
catching the few cases where certain operations don't make sense or
otherwise wouldn't work (like setting the terminal speed). Another thing
I'd like to prevent is Kermit-20 bothering non-36 bit systems.? This is
easily enough done by checking some 'magic' bits in the initial
configuration message and restricting by OS type.? This raises two
questions:
First, is the list below complete?? What about Ultrix and ... what else?
?1??? RSTS ?2??? RT-11 ?3??? RSTS/E ?4??? RSX-11S ?5??? RSX-11M
?6??? RSX-11D ?7??? IAS ?8??? VMS ?9??? TOPS-20 10??? TOPS-10 11
RTS-8 12??? OS-8 13??? RSX-11M+ 14??? MCB
Second, the configuration isn't well documented.? Actually, I'm not sure
if it's documented, period.? All I have is are some notes that Johnny
wrote up in the process of reverse-engineering it and very kindly gave
me.? They are certainly fine for this particular implementation, but I
was just wondering what else there might be. Plenty for LAT and CTERM,
but I don't think I've stumbled over NRT.
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
3:55 p.m.
I never heard of an attempt in DECnet to keep a single list of OS code numbers, but
interestingly enough the ones I can find are MOSTLY the same. There's one in the old
remote terminal protocol, another one in the foundation layer of Cterm, yet another in
DAP. Mostly they match, although interestingly enough one of them has OS/8 and RTS/8
swapped around. Not that this matters much...
paul
On Nov 7, 2021, at 6:17 AM, Johnny Billquist <bqt
at softjar.se> wrote:
Thomas, I'm not sure where you got that list from.
It seems slightly mismatching what I can find. Looking at the NRT code in RSX (which uses
object 23, and is shared by code in RSX for connecting to both RSTS/E, VMS and Tops-20), I
find this:
1 RT-11
2 RSTS/E
3 RSX-11S
4 RSX-11M
5 RSX-11D
6 IAS
7 VMS
Those are the documented values for the configuration message that I can find.
However, extrapolating from this, in NFT/FAL, there is a much more extensive list, which
seems to align with this list, which contains:
8 TOPS-20
9 Tops-10
10 RTS-8
11 OS/8
12 RSX-11M-PLUS
13 COPOS/11 (TOPS-20 frontend)
14 P/OS
15 VAXELN
16 CP/M
17 MS-DOS
18 Ultrix-32
19 Ultrix-11
20 DTF/MVS
25 Windows NT
26 Linux
Now, Linux is a value I believe I added just based on observation, so it's much less
official. But I think all the other ones are ones DEC did assign. Unfortunately, I think
Windows NT was also added by me, based on observation of Pathworks. So I do not know what
the values between 20 and 25 could/should be.
But maybe this helps some anyway?
Johnny
On 2021-11-07 11:23, Thomas DeBellis wrote:
Since its inception, Kermit-20 (one the first
three Kermit implementations) has had the 'limitation' that it will only talk to a
remote Kermit via a physical terminal line (I.E., something like TTY6:). It doesn't
do network terminals in part because it has no code to handle the out-of-band or meta-data
that one finds on TVT's (like IAC's) or CTERM's.
This doesn't exist for the early NRT terminals which were implemented for Tops-10 and
Tops-20. Once you've read the initial configuration message and decided what to do,
you basically never have to bother with meta-data. Because I'm trying to look at an
NFT issue between Tops-10 and Tops-20, I needed another transport mechanism and modifying
Kermit-20 to do DECnet 36 NRT's seemed like an easy hack. Since Tops-10 Kermit
isn't making an outgoing connection, it is none the wiser.
Thus far, it has been fairly straightforward. Right now I'm just catching the few
cases where certain operations don't make sense or otherwise wouldn't work (like
setting the terminal speed). Another thing I'd like to prevent is Kermit-20 bothering
non-36 bit systems. This is easily enough done by checking some 'magic' bits in
the initial configuration message and restricting by OS type. This raises two questions:
First, is the list below complete? What about Ultrix and ... what else?
1 RSTS 2 RT-11 3 RSTS/E 4 RSX-11S 5 RSX-11M
6 RSX-11D 7 IAS 8 VMS 9 TOPS-20 10 TOPS-10 11 RTS-8 12
OS-8 13 RSX-11M+ 14 MCB
Second, the configuration isn't well documented. Actually, I'm not sure if
it's documented, period. All I have is are some notes that Johnny wrote up in the
process of reverse-engineering it and very kindly gave me. They are certainly fine for
this particular implementation, but I was just wondering what else there might be. Plenty
for LAT and CTERM, but I don't think I've stumbled over NRT.
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
9:22 p.m.
On 2021-11-07 15:55, Paul Koning wrote:
I never heard of an attempt in DECnet to keep a single
list of OS code numbers, but interestingly enough the ones I can find are MOSTLY the same.
There's one in the old remote terminal protocol, another one in the foundation layer
of Cterm, yet another in DAP. Mostly they match, although interestingly enough one of
them has OS/8 and RTS/8 swapped around. Not that this matters much...
I've never seen an official list, but the fact that pretty much the same
list appears in several protocols/tools suggest that there was some kind
of agreed on list.
And yes, I found one where RTS-8 and OS/8 were swapped as well. But
since I think neither every had any implementation that was relevant
here, I suspect it ended up more as a token value to have a complete
list, but no implementation ever claimed them.
Johnny
paul
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On Nov 7, 2021, at 6:17 AM, Johnny Billquist
<bqt at softjar.se> wrote:
Thomas, I'm not sure where you got that list from.
It seems slightly mismatching what I can find. Looking at the NRT code in RSX (which uses
object 23, and is shared by code in RSX for connecting to both RSTS/E, VMS and Tops-20), I
find this:
1 RT-11
2 RSTS/E
3 RSX-11S
4 RSX-11M
5 RSX-11D
6 IAS
7 VMS
Those are the documented values for the configuration message that I can find.
However, extrapolating from this, in NFT/FAL, there is a much more extensive list, which
seems to align with this list, which contains:
8 TOPS-20
9 Tops-10
10 RTS-8
11 OS/8
12 RSX-11M-PLUS
13 COPOS/11 (TOPS-20 frontend)
14 P/OS
15 VAXELN
16 CP/M
17 MS-DOS
18 Ultrix-32
19 Ultrix-11
20 DTF/MVS
25 Windows NT
26 Linux
Now, Linux is a value I believe I added just based on observation, so it's much less
official. But I think all the other ones are ones DEC did assign. Unfortunately, I think
Windows NT was also added by me, based on observation of Pathworks. So I do not know what
the values between 20 and 25 could/should be.
But maybe this helps some anyway?
Johnny
On 2021-11-07 11:23, Thomas DeBellis wrote:
Since its inception, Kermit-20 (one the first
three Kermit implementations) has had the 'limitation' that it will only talk to a
remote Kermit via a physical terminal line (I.E., something like TTY6:). It doesn't
do network terminals in part because it has no code to handle the out-of-band or meta-data
that one finds on TVT's (like IAC's) or CTERM's.
This doesn't exist for the early NRT terminals which were implemented for Tops-10 and
Tops-20. Once you've read the initial configuration message and decided what to do,
you basically never have to bother with meta-data. Because I'm trying to look at an
NFT issue between Tops-10 and Tops-20, I needed another transport mechanism and modifying
Kermit-20 to do DECnet 36 NRT's seemed like an easy hack. Since Tops-10 Kermit
isn't making an outgoing connection, it is none the wiser.
Thus far, it has been fairly straightforward. Right now I'm just catching the few
cases where certain operations don't make sense or otherwise wouldn't work (like
setting the terminal speed). Another thing I'd like to prevent is Kermit-20 bothering
non-36 bit systems. This is easily enough done by checking some 'magic' bits in
the initial configuration message and restricting by OS type. This raises two questions:
First, is the list below complete? What about Ultrix and ... what else?
1 RSTS 2 RT-11 3 RSTS/E 4 RSX-11S 5 RSX-11M
6 RSX-11D 7 IAS 8 VMS 9 TOPS-20 10 TOPS-10 11 RTS-8 12
OS-8 13 RSX-11M+ 14 MCB
Second, the configuration isn't well documented. Actually, I'm not sure if
it's documented, period. All I have is are some notes that Johnny wrote up in the
process of reverse-engineering it and very kindly gave me. They are certainly fine for
this particular implementation, but I was just wondering what else there might be. Plenty
for LAT and CTERM, but I don't think I've stumbled over NRT.
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol 
4:04 p.m.
On 11/7/21 6:17 AM, Johnny Billquist wrote:
However, extrapolating from this, in NFT/FAL, there is
a much more
extensive list, which seems to align with this list, which contains:
...
16 CP/M
Wait, what? There was a DECnet implementation for CP/M?
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
4:08 p.m.
On Nov 7, 2021, at 10:04 AM, Dave McGuire <mcguire
at neurotica.com> wrote:
On 11/7/21 6:17 AM, Johnny Billquist wrote:
Not necessarily. Code points were at times assigned to things that never happened.
Consider the Cterm foundation layer which lists RSTS and RT-11, neither of which ever
implemented Cterm. Or OS-8 and RTS-8 in several of those lists; I think DECnet/8 is for
RTS-8, but there never was one for OS-8. (Or is it the other way around?)
paul
However, extrapolating from this, in NFT/FAL,
there is a much more extensive list, which seems to align with this list, which contains:
...
16 CP/M
Wait, what? There was a DECnet implementation for CP/M? 
6:06 p.m.
I think DECnet/8 is for RTS-8, but there never was one
for OS-8.
Yes, the DECnet-8 was for RTS although you could run OS/8 as a task under
RTS (so maybe those two count as the same). In any case AFAIK there was
never any NFT or FAL or remote terminal or NCP/NML or anything else like
that implemented for DECnet/8. It was more of a toolkit kind of thing where
you could write your own RTS program to make a DECnet connection to another
node. What you sent over that connection was your problem.
Never heard of DECnet for CP/M although there certainly was one for MSDOS.
Linux is interesting, although I doubt that was put there by DEC. Probably
somebody added it later.
And what the heck is COPOS/11?? I see that is says TOPS-20 front end, but
I thought TOPS20 used the same RSX20F as TOPS10.
And DTF/MVS? Is that the IBM OS MVS?
Bob
6:29 p.m.
I thought TOPS20 used the same RSX20F as TOPS10.
The PDP11 that "controls" the KL-CPU runs RSX20F
attached to a DTE.
Additional PDP11:s either run the DN87/DN20 front end
code or the MCB (that was RSX based).
KA/KI had PDP11s attached to the DL10 and they run DN87x.
There is a PDP8 version think it was called dn91, that talks
to a DS10 IO-bus sync interface on the 10 to.
-P
7:50 p.m.
On November 7, 2021 12:06:50 PM "Robert Armstrong" <bob at jfcl.com>
wrote:
I used DECnet/DOS for many years both at home and at work. It worked well.
There's also a DECnet implementation for IRIX, which I ran at work long ago. It was
called 4DDN.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
I think
DECnet/8 is for RTS-8, but there never was one for OS-8.
Yes, the DECnet-8 was for RTS although you could run OS/8 as a task under
RTS (so maybe those two count as the same). In any case AFAIK there was
never any NFT or FAL or remote terminal or NCP/NML or anything else like
that implemented for DECnet/8. It was more of a toolkit kind of thing where
you could write your own RTS program to make a DECnet connection to another
node. What you sent over that connection was your problem.
Never heard of DECnet for CP/M although there certainly was one for MSDOS. 
8 Nov
8 Nov
3:12 a.m.
On Nov 7, 2021, at 1:50 PM, Dave McGuire <mcguire
at neurotica.com> wrote:
On November 7, 2021 12:06:50 PM "Robert Armstrong" <bob at jfcl.com>
wrote:
I used DECnet/DOS for many years both at home and at work. It worked well.
There's also a DECnet implementation for IRIX, which I ran at work long ago. It was
called 4DDN.
-Dave
There was a company called Technology Concepts in Sudbury MA, which was founded by Stu
Wecker the original architect of DDCMP. They provided a core implementation of DECnet for
Unix systems (I know they had an implementation for early Sun systems).
John.
I think
DECnet/8 is for RTS-8, but there never was one for OS-8.
Yes, the DECnet-8 was for RTS although you could run OS/8 as a task under
RTS (so maybe those two count as the same). In any case AFAIK there was
never any NFT or FAL or remote terminal or NCP/NML or anything else like
that implemented for DECnet/8. It was more of a toolkit kind of thing where
you could write your own RTS program to make a DECnet connection to another
node. What you sent over that connection was your problem.
Never heard of DECnet for CP/M although there certainly was one for MSDOS. --
Dave McGuire, AK4HZ
New Kensington, PA
3:24 a.m.
On 11/7/21 9:12 PM, John Forecast wrote:
There was a company called Technology Concepts in
Sudbury MA, which was founded by Stu Wecker the original architect of DDCMP. They provided
a core implementation of DECnet for Unix systems (I know they had an implementation for
early Sun systems).
I'd heard that there was a DECnet implementation for SunOS, but I'm
pretty sure I was never able to find it.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
3:31 a.m.
It was called DNI if my memory serves?. Google turns up
https://docs.oracle.com/cd/E19504-01/802-5826/6i9iclf9p/index.html
Tony
On Mon, 8 Nov 2021 at 13:24, Dave McGuire <mcguire at neurotica.com> wrote:
On 11/7/21 9:12 PM, John Forecast wrote:
--
Tony Nicholson <tony.nicholson at computer.org>
There was a company called Technology Concepts in
Sudbury MA, which was
founded by Stu Wecker the original architect of DDCMP. They
provided a core
implementation of DECnet for Unix systems (I know they had an
implementation for early Sun systems).
I'd heard that there was a DECnet implementation for SunOS, but I'm
pretty sure I was never able to find it.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
3:33 a.m.
Excellent, but does anyone have the software?
-Dave
On 11/7/21 9:31 PM, Tony Nicholson wrote:
It was called DNI if my memory serves?.? Google turns
up
https://docs.oracle.com/cd/E19504-01/802-5826/6i9iclf9p/index.html
<https://docs.oracle.com/cd/E19504-01/802-5826/6i9iclf9p/index.html>
Tony
On Mon, 8 Nov 2021 at 13:24, Dave McGuire <mcguire at neurotica.com
<mailto:mcguire at neurotica.com>> wrote:
On 11/7/21 9:12 PM, John Forecast wrote:
--
Dave McGuire, AK4HZ
New Kensington, PA
There was a company called Technology Concepts in
Sudbury MA,
which was founded by Stu Wecker the original architect of DDCMP.
They provided a core implementation of DECnet for Unix systems (I
know they had an implementation for early Sun systems).
? ?I'd heard that there was a DECnet implementation for SunOS, but I'm
pretty sure I was never able to find it.
? ? ? ? ? ? -Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
--
Tony Nicholson <tony.nicholson at computer.org
<mailto:tony.nicholson at computer.org>> 
12:49 p.m.
There was a company called Technology Concepts in Sudbury MA, which was founded by Stu
Wecker the original architect of DDCMP. They provided a core implementation of DECnet for
Unix systems (I know they had an implementation for early Sun systems).
Yes I have heard of this DECnet for Solaris thing too. Having just restored a
SparcStation-20 it would be awesome if it could be located.
John.
--
Dave McGuire, AK4HZ
New Kensington, PA
7 Nov
7 Nov
9:37 p.m.
On 2021-11-07 18:06, Robert Armstrong wrote:
Right. It was/is slightly more than a toolkit. It does have a couple of
processes which deals with circuits and executor management. And I think
there is TLK/LSN so you can communicate. But beyond that, you were on
your own.
And no, OS/8 under RTS-8 don't allow them to be counted as one. :-)
I think
DECnet/8 is for RTS-8, but there never was one for OS-8.
Yes, the DECnet-8 was for RTS although you could run OS/8 as a task under
RTS (so maybe those two count as the same). In any case AFAIK there was
never any NFT or FAL or remote terminal or NCP/NML or anything else like
that implemented for DECnet/8. It was more of a toolkit kind of thing where
you could write your own RTS program to make a DECnet connection to another
node. What you sent over that connection was your problem. Never heard of DECnet for CP/M although there
certainly was one for MSDOS.
Linux is interesting, although I doubt that was put there by DEC. Probably
somebody added it later.
Linux was definitely defined post-DEC. I simply just talked with a Linux
FAL from RSX and checked what value it put in the OS field, and added
that to my list from there.
And what the heck is COPOS/11?? I see that is says
TOPS-20 front end, but
I thought TOPS20 used the same RSX20F as TOPS10.
I don't think it's the same as the RSX20F frontend. I have no idea what
it is, but it's in the source files for the RSX DECnet code. Sounds like
some oddball thing that existed somewhere. CSS thing maybe?
And DTF/MVS? Is that the IBM OS MVS?
I almost suspect it might be, but again, no real clue. All I can say is
that this is what is in the RSX sources.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
8 Nov
8 Nov
3:25 a.m.
On Nov 7, 2021, at 3:37 PM, Johnny Billquist <bqt
at softjar.se> wrote:
On 2021-11-07 18:06, Robert Armstrong wrote:
Right. It was/is slightly more than a toolkit. It does have a couple of processes which
deals with circuits and executor management. And I think there is TLK/LSN so you can
communicate. But beyond that, you were on your own.
And no, OS/8 under RTS-8 don't allow them to be counted as one. :-)
One of the field service offices in New Jersey (Murray Hill perhaps) did a custom
implementation of DECnet for Unix System V for the Bell system. When we started working on
DECnet-SCO, we tried to get access to the code but was told it was considered proprietary
code owned by the Bell system.
John.
I think
DECnet/8 is for RTS-8, but there never was one for OS-8.
Yes, the DECnet-8 was
for RTS although you could run OS/8 as a task under
RTS (so maybe those two count as the same). In any case AFAIK there was
never any NFT or FAL or remote terminal or NCP/NML or anything else like
that implemented for DECnet/8. It was more of a toolkit kind of thing where
you could write your own RTS program to make a DECnet connection to another
node. What you sent over that connection was your problem. Never heard of DECnet for CP/M although there
certainly was one for MSDOS.
Linux is interesting, although I doubt that was put there by DEC. Probably
somebody added it later.
Linux was definitely defined post-DEC. I simply just talked with a Linux FAL from RSX and
checked what value it put in the OS field, and added that to my list from there.
And what the heck is COPOS/11?? I see that is
says TOPS-20 front end, but
I thought TOPS20 used the same RSX20F as TOPS10.
I don't think it's the same as the RSX20F frontend. I have no idea what it is,
but it's in the source files for the RSX DECnet code. Sounds like some oddball thing
that existed somewhere. CSS thing maybe?
And DTF/MVS? Is that the IBM OS MVS?
I almost suspect it might be, but again, no real clue. All I can say is that this is what
is in the RSX sources.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
3:32 a.m.
The "Bell System" is now owned by Nokia. Do you have a better pointer to the
code/project?
-P
----- Original Message -----
From: "John Forecast" <john at
forecast.name>
To: "hecnet" <hecnet at Update.UU.SE>
Sent: Sunday, November 7, 2021 9:25:19 PM
Subject: Re: [HECnet] Is this the most up to date version of DECnet OS numbers?
One of the field service offices in New Jersey (Murray
Hill perhaps) did a
custom implementation of DECnet for Unix System V for the Bell system. When we
started working on DECnet-SCO, we tried to get access to the code but was told
it was considered proprietary code owned by the Bell system.
John.
3:48 a.m.
No, sorry. We got shutdown pretty early in the game.
John.
On Nov 7, 2021, at 9:32 PM, Peter Lothberg <roll at
stupi.com> wrote:
The "Bell System" is now owned by Nokia. Do you have a better pointer to the
code/project?
-P
----- Original Message -----
From: "John Forecast" <john at
forecast.name>
To: "hecnet" <hecnet at Update.UU.SE>
Sent: Sunday, November 7, 2021 9:25:19 PM
Subject: Re: [HECnet] Is this the most up to date version of DECnet OS numbers?
> One of the field service offices in New Jersey (Murray Hill perhaps) did a
> custom implementation of DECnet for Unix System V for the Bell system. When we
> started working on DECnet-SCO, we tried to get access to the code but was told
> it was considered proprietary code owned by the Bell system.
>
> John. 
6:21 p.m.
Well, that was an interesting compilation of the raspbian kernel.
I cloned https://github.com/JohnForecast/RaspbianDECnet and got busy. I had to remove the
--help-- stanzas from the Kconfig file. They were tripping something up.
I had to move the MAC address change to the bridge (I use /etc/network/interfaces with
bridges and taps etc..)
DECnet is all working on a 32bit raspbian on a pi3b+, HECnet node name 29.115 - I'll
christen it at some point :)
Thank you John Forecast for doing all the hard work.
Keith
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of
Johnny Billquist
Sent: 07 November 2021 20:37
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] Is this the most up to date version of DECnet OS numbers?
On 2021-11-07 18:06, Robert Armstrong wrote:
Right. It was/is slightly more than a toolkit. It does have a couple of processes which
deals with circuits and executor management. And I think there is TLK/LSN so you can
communicate. But beyond that, you were on your own.
And no, OS/8 under RTS-8 don't allow them to be counted as one. :-)
I think
DECnet/8 is for RTS-8, but there never was one for OS-8.
Yes, the DECnet-8 was for RTS although you could run OS/8 as a task
under RTS (so maybe those two count as the same). In any case AFAIK
there was never any NFT or FAL or remote terminal or NCP/NML or
anything else like that implemented for DECnet/8. It was more of a
toolkit kind of thing where you could write your own RTS program to
make a DECnet connection to another node. What you sent over that connection was your
problem. Never heard of DECnet for CP/M although there
certainly was one for MSDOS.
Linux is interesting, although I doubt that was put there by DEC.
Probably somebody added it later.
Linux was definitely defined post-DEC. I simply just talked with a Linux FAL from RSX and
checked what value it put in the OS field, and added that to my list from there.
And what the heck is COPOS/11?? I see that is says
TOPS-20 front
end, but I thought TOPS20 used the same RSX20F as TOPS10.
I don't think it's the same as the RSX20F frontend. I have no idea what it is, but
it's in the source files for the RSX DECnet code. Sounds like some oddball thing that
existed somewhere. CSS thing maybe?
And DTF/MVS? Is that the IBM OS MVS?
I almost suspect it might be, but again, no real clue. All I can say is that this is what
is in the RSX sources.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
6:55 p.m.
On Nov 8, 2021, at 9:21 AM, Keith Halewood
<Keith.Halewood at pitbulluk.org> wrote:
Well, that was an interesting compilation of the raspbian kernel.
I cloned https://github.com/JohnForecast/RaspbianDECnet and got busy. I had to remove the
--help-- stanzas from the Kconfig file. They were tripping something up.
I had to move the MAC address change to the bridge (I use /etc/network/interfaces with
bridges and taps etc..)
DECnet is all working on a 32bit raspbian on a pi3b+, HECnet node name 29.115 - I'll
christen it at some point :)
Thank you John Forecast for doing all the hard work.
Keith
This is great news! I will dust off an old Pi and try this!
Ian
8:01 p.m.
On 11/8/21 12:55 PM, Ian McLaughlin wrote:
My sentiments exactly; I'll be doing the same later this week.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
Well, that was
an interesting compilation of the raspbian kernel.
I cloned https://github.com/JohnForecast/RaspbianDECnet and got busy. I had to remove the
--help-- stanzas from the Kconfig file. They were tripping something up.
I had to move the MAC address change to the bridge (I use /etc/network/interfaces with
bridges and taps etc..)
DECnet is all working on a 32bit raspbian on a pi3b+, HECnet node name 29.115 - I'll
christen it at some point :)
Thank you John Forecast for doing all the hard work.
Keith
This is great news! I will dust off an old Pi and try this! 
8:12 p.m.
On Nov 8, 2021, at 9:21 AM, Keith Halewood <Keith.Halewood at pitbulluk.org> wrote:
Well, that was an interesting compilation of the raspbian kernel.
I cloned https://github.com/JohnForecast/RaspbianDECnet and got busy. I had to remove the
--help-- stanzas from the Kconfig file. They were tripping something up.
I had to move the MAC address change to the bridge (I use /etc/network/interfaces with
bridges and taps etc..)
DECnet is all working on a 32bit raspbian on a pi3b+, HECnet node name 29.115 - I'll
christen it at some point :)
Thank you John Forecast for doing all the hard work.
Keith
I?ve been meaning to give this a try. Does this include LAT support? In my non-existant
free time, I?d like to see what it would take to turn a Raspberry Pi into a DECserver
replacement.
Zane
8:32 p.m.
No, It?s purely a DECnet implementation.
John.
On Nov 8, 2021, at 2:12 PM, Zane Healy <healyzh at
avanthar.com> wrote:
On Nov 8, 2021, at 9:21 AM, Keith Halewood <Keith.Halewood at pitbulluk.org>
wrote:
Well, that was an interesting compilation of the raspbian kernel.
I cloned https://github.com/JohnForecast/RaspbianDECnet and got busy. I had to remove the
--help-- stanzas from the Kconfig file. They were tripping something up.
I had to move the MAC address change to the bridge (I use /etc/network/interfaces with
bridges and taps etc..)
DECnet is all working on a 32bit raspbian on a pi3b+, HECnet node name 29.115 - I'll
christen it at some point :)
Thank you John Forecast for doing all the hard work.
Keith
I?ve been meaning to give this a try. Does this include LAT support? In my non-existant
free time, I?d like to see what it would take to turn a Raspberry Pi into a DECserver
replacement.
Zane
8:34 p.m.
For LAT, I have no difficulty (other than hitting occasional bugs)
running the regular LAT stack and programs in the current Linux
distributions. I use it all the time.
-Dave
On 11/8/21 2:32 PM, John Forecast wrote:
No, It?s purely a DECnet implementation.
John.
--
Dave McGuire, AK4HZ
New Kensington, PA
On Nov 8, 2021, at 2:12 PM, Zane Healy
<healyzh at avanthar.com> wrote:
On Nov 8, 2021, at 9:21 AM, Keith Halewood <Keith.Halewood at pitbulluk.org>
wrote:
Well, that was an interesting compilation of the raspbian kernel.
I cloned https://github.com/JohnForecast/RaspbianDECnet and got busy. I had to remove the
--help-- stanzas from the Kconfig file. They were tripping something up.
I had to move the MAC address change to the bridge (I use /etc/network/interfaces with
bridges and taps etc..)
DECnet is all working on a 32bit raspbian on a pi3b+, HECnet node name 29.115 - I'll
christen it at some point :)
Thank you John Forecast for doing all the hard work.
Keith
I?ve been meaning to give this a try. Does this include LAT support? In my non-existant
free time, I?d like to see what it would take to turn a Raspberry Pi into a DECserver
replacement.
Zane
8:26 p.m.
Glad it?s working for you. Is this running the latest Raspbian release? What kernel
version is it running?
John.
On Nov 8, 2021, at 12:21 PM, Keith Halewood
<Keith.Halewood at pitbulluk.org> wrote:
Well, that was an interesting compilation of the raspbian kernel.
I cloned https://github.com/JohnForecast/RaspbianDECnet and got busy. I had to remove the
--help-- stanzas from the Kconfig file. They were tripping something up.
I had to move the MAC address change to the bridge (I use /etc/network/interfaces with
bridges and taps etc..)
DECnet is all working on a 32bit raspbian on a pi3b+, HECnet node name 29.115 - I'll
christen it at some point :)
Thank you John Forecast for doing all the hard work.
Keith
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of
Johnny Billquist
Sent: 07 November 2021 20:37
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] Is this the most up to date version of DECnet OS numbers?
On 2021-11-07 18:06, Robert Armstrong wrote:
Right. It was/is slightly more than a toolkit. It does have a couple of processes which
deals with circuits and executor management. And I think there is TLK/LSN so you can
communicate. But beyond that, you were on your own.
And no, OS/8 under RTS-8 don't allow them to be counted as one. :-)
I think
DECnet/8 is for RTS-8, but there never was one for OS-8.
Yes, the DECnet-8 was for RTS although you could run OS/8 as a task
under RTS (so maybe those two count as the same). In any case AFAIK
there was never any NFT or FAL or remote terminal or NCP/NML or
anything else like that implemented for DECnet/8. It was more of a
toolkit kind of thing where you could write your own RTS program to
make a DECnet connection to another node. What you sent over that connection was your
problem. Never heard of DECnet for CP/M although there
certainly was one for MSDOS.
Linux is interesting, although I doubt that was put there by DEC.
Probably somebody added it later.
Linux was definitely defined post-DEC. I simply just talked with a Linux FAL from RSX and
checked what value it put in the OS field, and added that to my list from there.
And what the heck is COPOS/11?? I see that is
says TOPS-20 front
end, but I thought TOPS20 used the same RSX20F as TOPS10.
I don't think it's the same as the RSX20F frontend. I have no idea what it is,
but it's in the source files for the RSX DECnet code. Sounds like some oddball thing
that existed somewhere. CSS thing maybe?
And DTF/MVS? Is that the IBM OS MVS?
I almost suspect it might be, but again, no real clue. All I can say is that this is what
is in the RSX sources.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
10 p.m.
It's apparently 5.10.77-v7+.
It eventually goes a bit wrong responding to NICE requests with VMS complaining
'invalid management response' but the output showing a '...such file or
directory' but I'll try some troubleshooting tomorrow.
I installed 'latd' (apt install latd), started up with latcp -s and it's
picked up all the LAT services on the LAN, including itself, the RX4640, the KLH10
instance of Panda TOPS-20... looks fine too. Identifies its connections as the hostname
and tty, such as "PI3B3//dev/ttyAMA0"
Keith
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of John
Forecast
Sent: 08 November 2021 19:26
To: hecnet at update.uu.se
Subject: Re: [HECnet] Is this the most up to date version of DECnet OS numbers?
Glad it?s working for you. Is this running the latest Raspbian release? What kernel
version is it running?
John.
On Nov 8, 2021, at 12:21 PM, Keith Halewood
<Keith.Halewood at pitbulluk.org> wrote:
Well, that was an interesting compilation of the raspbian kernel.
I cloned https://github.com/JohnForecast/RaspbianDECnet and got busy. I had to remove the
--help-- stanzas from the Kconfig file. They were tripping something up.
I had to move the MAC address change to the bridge (I use
/etc/network/interfaces with bridges and taps etc..)
DECnet is all working on a 32bit raspbian on a pi3b+, HECnet node name
29.115 - I'll christen it at some point :) Thank you John Forecast for doing all the
hard work.
Keith
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On
Behalf Of Johnny Billquist
Sent: 07 November 2021 20:37
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] Is this the most up to date version of DECnet OS numbers?
On 2021-11-07 18:06, Robert Armstrong wrote:
Right. It was/is slightly more than a toolkit. It does have a couple of processes which
deals with circuits and executor management. And I think there is TLK/LSN so you can
communicate. But beyond that, you were on your own.
And no, OS/8 under RTS-8 don't allow them to be counted as one. :-)
I think
DECnet/8 is for RTS-8, but there never was one for OS-8.
Yes, the DECnet-8 was for RTS although you could run OS/8 as a task
under RTS (so maybe those two count as the same). In any case AFAIK
there was never any NFT or FAL or remote terminal or NCP/NML or
anything else like that implemented for DECnet/8. It was more of a
toolkit kind of thing where you could write your own RTS program to
make a DECnet connection to another node. What you sent over that connection was your
problem. Never heard of DECnet for CP/M although there
certainly was one for MSDOS.
Linux is interesting, although I doubt that was put there by DEC.
Probably somebody added it later.
Linux was definitely defined post-DEC. I simply just talked with a Linux FAL from RSX and
checked what value it put in the OS field, and added that to my list from there.
And what the heck is COPOS/11?? I see that is
says TOPS-20 front
end, but I thought TOPS20 used the same RSX20F as TOPS10.
I don't think it's the same as the RSX20F frontend. I have no idea what it is,
but it's in the source files for the RSX DECnet code. Sounds like some oddball thing
that existed somewhere. CSS thing maybe?
And DTF/MVS? Is that the IBM OS MVS?
I almost suspect it might be, but again, no real clue. All I can say is that this is what
is in the RSX sources.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
10:08 p.m.
Thanks. Can you try using NML2 - README.Raspbian has instructions. That?s a newer version
I wrote last year which includes support for some of the newer features I added.
John.
On Nov 8, 2021, at 4:00 PM, Keith Halewood
<Keith.Halewood at pitbulluk.org> wrote:
It's apparently 5.10.77-v7+.
It eventually goes a bit wrong responding to NICE requests with VMS complaining
'invalid management response' but the output showing a '...such file or
directory' but I'll try some troubleshooting tomorrow.
I installed 'latd' (apt install latd), started up with latcp -s and it's
picked up all the LAT services on the LAN, including itself, the RX4640, the KLH10
instance of Panda TOPS-20... looks fine too. Identifies its connections as the hostname
and tty, such as "PI3B3//dev/ttyAMA0"
Keith
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of
John Forecast
Sent: 08 November 2021 19:26
To: hecnet at update.uu.se
Subject: Re: [HECnet] Is this the most up to date version of DECnet OS numbers?
Glad it?s working for you. Is this running the latest Raspbian release? What kernel
version is it running?
John.
On Nov 8, 2021, at 12:21 PM, Keith Halewood
<Keith.Halewood at pitbulluk.org> wrote:
Well, that was an interesting compilation of the raspbian kernel.
I cloned https://github.com/JohnForecast/RaspbianDECnet and got busy. I had to remove the
--help-- stanzas from the Kconfig file. They were tripping something up.
I had to move the MAC address change to the bridge (I use
/etc/network/interfaces with bridges and taps etc..)
DECnet is all working on a 32bit raspbian on a pi3b+, HECnet node name
29.115 - I'll christen it at some point :) Thank you John Forecast for doing all the
hard work.
Keith
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On
Behalf Of Johnny Billquist
Sent: 07 November 2021 20:37
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] Is this the most up to date version of DECnet OS numbers?
On 2021-11-07 18:06, Robert Armstrong wrote:
Right. It was/is slightly more than a toolkit. It does have a couple of processes which
deals with circuits and executor management. And I think there is TLK/LSN so you can
communicate. But beyond that, you were on your own.
And no, OS/8 under RTS-8 don't allow them to be counted as one. :-)
I think
DECnet/8 is for RTS-8, but there never was one for OS-8.
Yes, the DECnet-8 was for RTS although you could run OS/8 as a task
under RTS (so maybe those two count as the same). In any case AFAIK
there was never any NFT or FAL or remote terminal or NCP/NML or
anything else like that implemented for DECnet/8. It was more of a
toolkit kind of thing where you could write your own RTS program to
make a DECnet connection to another node. What you sent over that connection was your
problem. Never heard of DECnet for CP/M although there
certainly was one for MSDOS.
Linux is interesting, although I doubt that was put there by DEC.
Probably somebody added it later.
Linux was definitely defined post-DEC. I simply just talked with a Linux FAL from RSX and
checked what value it put in the OS field, and added that to my list from there.
And what the heck is COPOS/11?? I see that is
says TOPS-20 front
end, but I thought TOPS20 used the same RSX20F as TOPS10.
I don't think it's the same as the RSX20F frontend. I have no idea what it is,
but it's in the source files for the RSX DECnet code. Sounds like some oddball thing
that existed somewhere. CSS thing maybe?
And DTF/MVS? Is that the IBM OS MVS?
I almost suspect it might be, but again, no real clue. All I can say is that this is what
is in the RSX sources.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
10:27 p.m.
Thanks John. I compiled/installed fal2 as well. I'm see, from nml:
Node Volatile Characteristics as of 8-NOV-2021 21:25:21
Executor node = 29.115 (PI3B3)
Identification = DECnet for Linux V5.10.77-v7+ on armv7l
Management version = V4.0.0
NSP version = V4.0.0
Routing version = V2.0.0
Type = nonrouting IV
Maximum circuits = 1
Segment buffer size = 576
Keith
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of John
Forecast
Sent: 08 November 2021 21:08
To: hecnet at update.uu.se
Subject: Re: [HECnet] Is this the most up to date version of DECnet OS numbers?
Thanks. Can you try using NML2 - README.Raspbian has instructions. That?s a newer version
I wrote last year which includes support for some of the newer features I added.
John.
On Nov 8, 2021, at 4:00 PM, Keith Halewood
<Keith.Halewood at pitbulluk.org> wrote:
It's apparently 5.10.77-v7+.
It eventually goes a bit wrong responding to NICE requests with VMS complaining
'invalid management response' but the output showing a '...such file or
directory' but I'll try some troubleshooting tomorrow.
I installed 'latd' (apt install latd), started up with latcp -s and it's
picked up all the LAT services on the LAN, including itself, the RX4640, the KLH10
instance of Panda TOPS-20... looks fine too. Identifies its connections as the hostname
and tty, such as "PI3B3//dev/ttyAMA0"
Keith
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On
Behalf Of John Forecast
Sent: 08 November 2021 19:26
To: hecnet at update.uu.se
Subject: Re: [HECnet] Is this the most up to date version of DECnet OS numbers?
Glad it?s working for you. Is this running the latest Raspbian release? What kernel
version is it running?
John.
On Nov 8, 2021, at 12:21 PM, Keith Halewood
<Keith.Halewood at pitbulluk.org> wrote:
Well, that was an interesting compilation of the raspbian kernel.
I cloned https://github.com/JohnForecast/RaspbianDECnet and got busy. I had to remove the
--help-- stanzas from the Kconfig file. They were tripping something up.
I had to move the MAC address change to the bridge (I use
/etc/network/interfaces with bridges and taps etc..)
DECnet is all working on a 32bit raspbian on a pi3b+, HECnet node
name
29.115 - I'll christen it at some point :) Thank you John Forecast for doing all the
hard work.
Keith
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On
Behalf Of Johnny Billquist
Sent: 07 November 2021 20:37
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] Is this the most up to date version of DECnet OS numbers?
On 2021-11-07 18:06, Robert Armstrong wrote:
Right. It was/is slightly more than a toolkit. It does have a couple of processes which
deals with circuits and executor management. And I think there is TLK/LSN so you can
communicate. But beyond that, you were on your own.
And no, OS/8 under RTS-8 don't allow them to be counted as one. :-)
I think
DECnet/8 is for RTS-8, but there never was one for OS-8.
Yes, the DECnet-8 was for RTS although you could run OS/8 as a task
under RTS (so maybe those two count as the same). In any case AFAIK
there was never any NFT or FAL or remote terminal or NCP/NML or
anything else like that implemented for DECnet/8. It was more of a
toolkit kind of thing where you could write your own RTS program to
make a DECnet connection to another node. What you sent over that connection was your
problem. Never heard of DECnet for CP/M although there
certainly was one for MSDOS.
Linux is interesting, although I doubt that was put there by DEC.
Probably somebody added it later.
Linux was definitely defined post-DEC. I simply just talked with a Linux FAL from RSX and
checked what value it put in the OS field, and added that to my list from there.
And what the heck is COPOS/11?? I see that is
says TOPS-20 front
end, but I thought TOPS20 used the same RSX20F as TOPS10.
I don't think it's the same as the RSX20F frontend. I have no idea what it is,
but it's in the source files for the RSX DECnet code. Sounds like some oddball thing
that existed somewhere. CSS thing maybe?
And DTF/MVS? Is that the IBM OS MVS?
I almost suspect it might be, but again, no real clue. All I can say is that this is what
is in the RSX sources.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
11:01 p.m.
That looks good. ?Segment Buffer Size? was one of the additions for NML2. FAL2 provides a
traditional Unix stream I/O interface rather than trying to emulate RMS which what the
original FAL did.
John.
On Nov 8, 2021, at 4:27 PM, Keith Halewood
<Keith.Halewood at pitbulluk.org> wrote:
Thanks John. I compiled/installed fal2 as well. I'm see, from nml:
Node Volatile Characteristics as of 8-NOV-2021 21:25:21
Executor node = 29.115 (PI3B3)
Identification = DECnet for Linux V5.10.77-v7+ on armv7l
Management version = V4.0.0
NSP version = V4.0.0
Routing version = V2.0.0
Type = nonrouting IV
Maximum circuits = 1
Segment buffer size = 576
Keith
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of
John Forecast
Sent: 08 November 2021 21:08
To: hecnet at update.uu.se
Subject: Re: [HECnet] Is this the most up to date version of DECnet OS numbers?
Thanks. Can you try using NML2 - README.Raspbian has instructions. That?s a newer version
I wrote last year which includes support for some of the newer features I added.
John.
On Nov 8, 2021, at 4:00 PM, Keith Halewood
<Keith.Halewood at pitbulluk.org> wrote:
It's apparently 5.10.77-v7+.
It eventually goes a bit wrong responding to NICE requests with VMS complaining
'invalid management response' but the output showing a '...such file or
directory' but I'll try some troubleshooting tomorrow.
I installed 'latd' (apt install latd), started up with latcp -s and it's
picked up all the LAT services on the LAN, including itself, the RX4640, the KLH10
instance of Panda TOPS-20... looks fine too. Identifies its connections as the hostname
and tty, such as "PI3B3//dev/ttyAMA0"
Keith
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On
Behalf Of John Forecast
Sent: 08 November 2021 19:26
To: hecnet at update.uu.se
Subject: Re: [HECnet] Is this the most up to date version of DECnet OS numbers?
Glad it?s working for you. Is this running the latest Raspbian release? What kernel
version is it running?
John.
On Nov 8, 2021, at 12:21 PM, Keith Halewood
<Keith.Halewood at pitbulluk.org> wrote:
Well, that was an interesting compilation of the raspbian kernel.
I cloned https://github.com/JohnForecast/RaspbianDECnet and got busy. I had to remove the
--help-- stanzas from the Kconfig file. They were tripping something up.
I had to move the MAC address change to the bridge (I use
/etc/network/interfaces with bridges and taps etc..)
DECnet is all working on a 32bit raspbian on a pi3b+, HECnet node
name
29.115 - I'll christen it at some point :) Thank you John Forecast for doing all the
hard work.
Keith
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On
Behalf Of Johnny Billquist
Sent: 07 November 2021 20:37
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] Is this the most up to date version of DECnet OS numbers?
On 2021-11-07 18:06, Robert Armstrong wrote:
> I think DECnet/8 is for RTS-8, but there
never was one for OS-8.
Yes, the DECnet-8 was for RTS although you could run OS/8 as a task
under RTS (so maybe those two count as the same). In any case AFAIK
there was never any NFT or FAL or remote terminal or NCP/NML or
anything else like that implemented for DECnet/8. It was more of a
toolkit kind of thing where you could write your own RTS program to
make a DECnet connection to another node. What you sent over that connection was your
problem.
Right. It was/is slightly more than a toolkit. It does have a couple of processes which
deals with circuits and executor management. And I think there is TLK/LSN so you can
communicate. But beyond that, you were on your own.
And no, OS/8 under RTS-8 don't allow them to be counted as one. :-)
Never heard of DECnet for CP/M although there
certainly was one for MSDOS.
Linux is interesting, although I doubt that was put there by DEC.
Probably somebody added it later.
Linux was definitely defined post-DEC. I simply just talked with a Linux FAL from RSX and
checked what value it put in the OS field, and added that to my list from there.
And what the heck is COPOS/11?? I see that is
says TOPS-20 front
end, but I thought TOPS20 used the same RSX20F as TOPS10.
I don't think it's the same as the RSX20F frontend. I have no idea what it is,
but it's in the source files for the RSX DECnet code. Sounds like some oddball thing
that existed somewhere. CSS thing maybe?
And DTF/MVS? Is that the IBM OS MVS?
I almost suspect it might be, but again, no real clue. All I can say is that this is what
is in the RSX sources.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
10:23 p.m.
On Nov 8, 2021, at 1:00 PM, Keith Halewood <Keith.Halewood at pitbulluk.org> wrote:
I installed 'latd' (apt install latd), started up with latcp -s and it's
picked up all the LAT services on the LAN, including itself, the RX4640, the KLH10
instance of Panda TOPS-20... looks fine too. Identifies its connections as the hostname
and tty, such as "PI3B3//dev/ttyAMA0"
Oh, VERY nice! Thank you for this info! I?ve a RPi4 sitting unused on my network, since
I?m no longer using it for some basic Minio testing. I might give it a try for this.
Zane
10:31 p.m.
I installed 'latd' (apt install latd), started up with latcp -s and it's
picked up all the LAT services on the LAN, including itself, the RX4640,*the KLH10
instance of Panda TOPS-20*... looks fine too. Identifies its connections as the hostname
and tty, such as "PI3B3//dev/ttyAMA0"
I used the Windows 95 version of Kermit on Windows 2000 for many years
because of the LAT support.? It functioned _flawlessly_ to a KLH10
instance of PANDA Tops-20, always.
Really wish I could find the CD-ROM with the LAT drivers for Windows...
On 11/8/21 4:00 PM, Keith Halewood wrote:
It's apparently 5.10.77-v7+.
It eventually goes a bit wrong responding to NICE requests with VMS complaining
'invalid management response' but the output showing a '...such file or
directory' but I'll try some troubleshooting tomorrow.
I installed 'latd' (apt install latd), started up with latcp -s and it's
picked up all the LAT services on the LAN, including itself, the RX4640, the KLH10
instance of Panda TOPS-20... looks fine too. Identifies its connections as the hostname
and tty, such as "PI3B3//dev/ttyAMA0"
Keith
-----Original Message-----
From:owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of
John Forecast
Sent: 08 November 2021 19:26
To:hecnet at update.uu.se
Subject: Re: [HECnet] Is this the most up to date version of DECnet OS numbers?
Glad it?s working for you. Is this running the latest Raspbian release? What kernel
version is it running?
John.
> On Nov 8, 2021, at 12:21 PM, Keith Halewood<Keith.Halewood at pitbulluk.org>
wrote:
>
> Well, that was an interesting compilation of the raspbian kernel.
> I clonedhttps://github.com/JohnForecast/RaspbianDECnet and got busy. I had to remove
the --help-- stanzas from the Kconfig file. They were tripping something up.
> I had to move the MAC address change to the bridge (I use
> /etc/network/interfaces with bridges and taps etc..)
>
> DECnet is all working on a 32bit raspbian on a pi3b+, HECnet node name
> 29.115 - I'll christen it at some point :) Thank you John Forecast for doing all
the hard work.
>
> Keith
>
> -----Original Message-----
> From:owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On
> Behalf Of Johnny Billquist
> Sent: 07 November 2021 20:37
> To:hecnet at Update.UU.SE
> Subject: Re: [HECnet] Is this the most up to date version of DECnet OS numbers?
>
> On 2021-11-07 18:06, Robert Armstrong wrote:
>>> I think DECnet/8 is for RTS-8, but there never was one for OS-8.
>> Yes, the DECnet-8 was for RTS although you could run OS/8 as a task
>> under RTS (so maybe those two count as the same). In any case AFAIK
>> there was never any NFT or FAL or remote terminal or NCP/NML or
>> anything else like that implemented for DECnet/8. It was more of a
>> toolkit kind of thing where you could write your own RTS program to
>> make a DECnet connection to another node. What you sent over that connection was
your problem.
> Right. It was/is slightly more than a toolkit. It does have a couple of processes
which deals with circuits and executor management. And I think there is TLK/LSN so you can
communicate. But beyond that, you were on your own.
>
> And no, OS/8 under RTS-8 don't allow them to be counted as one. :-)
>
>> Never heard of DECnet for CP/M although there certainly was one for MSDOS.
>> Linux is interesting, although I doubt that was put there by DEC.
>> Probably somebody added it later.
> Linux was definitely defined post-DEC. I simply just talked with a Linux FAL from RSX
and checked what value it put in the OS field, and added that to my list from there.
>
>> And what the heck is COPOS/11?? I see that is says TOPS-20 front
>> end, but I thought TOPS20 used the same RSX20F as TOPS10.
> I don't think it's the same as the RSX20F frontend. I have no idea what it
is, but it's in the source files for the RSX DECnet code. Sounds like some oddball
thing that existed somewhere. CSS thing maybe?
>
>> And DTF/MVS? Is that the IBM OS MVS?
> I almost suspect it might be, but again, no real clue. All I can say is that this is
what is in the RSX sources.
>
> Johnny
>
> --
> Johnny Billquist || "I'm on a bus
> || on a psychedelic trip
> email:bqt at softjar.se || Reading murder books
> pdp is alive! || tryin' to stay hip" - B. Idol
11:34 p.m.
Hello!
I believe there's a Windows grade CD-ROM image sitting on the Bit
Savers repositories.
-----
Gregg C Levine gregg.drwho8 at gmail.com
"This signature fought the Time Wars, time and again."
On Mon, Nov 8, 2021 at 4:31 PM Thomas DeBellis
<tommytimesharing at gmail.com> wrote:
I installed 'latd' (apt install latd), started up with latcp -s and it's
picked up all the LAT services on the LAN, including itself, the RX4640, the KLH10
instance of Panda TOPS-20... looks fine too. Identifies its connections as the hostname
and tty, such as "PI3B3//dev/ttyAMA0"
I used the Windows 95 version of Kermit on Windows 2000 for many years because of the LAT
support. It functioned flawlessly to a KLH10 instance of PANDA Tops-20, always.
Really wish I could find the CD-ROM with the LAT drivers for Windows...
On 11/8/21 4:00 PM, Keith Halewood wrote:
It's apparently 5.10.77-v7+.
It eventually goes a bit wrong responding to NICE requests with VMS complaining
'invalid management response' but the output showing a '...such file or
directory' but I'll try some troubleshooting tomorrow.
I installed 'latd' (apt install latd), started up with latcp -s and it's
picked up all the LAT services on the LAN, including itself, the RX4640, the KLH10
instance of Panda TOPS-20... looks fine too. Identifies its connections as the hostname
and tty, such as "PI3B3//dev/ttyAMA0"
Keith
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of
John Forecast
Sent: 08 November 2021 19:26
To: hecnet at update.uu.se
Subject: Re: [HECnet] Is this the most up to date version of DECnet OS numbers?
Glad it?s working for you. Is this running the latest Raspbian release? What kernel
version is it running?
John.
On Nov 8, 2021, at 12:21 PM, Keith Halewood <Keith.Halewood at pitbulluk.org>
wrote:
Well, that was an interesting compilation of the raspbian kernel.
I cloned https://github.com/JohnForecast/RaspbianDECnet and got busy. I had to remove the
--help-- stanzas from the Kconfig file. They were tripping something up.
I had to move the MAC address change to the bridge (I use
/etc/network/interfaces with bridges and taps etc..)
DECnet is all working on a 32bit raspbian on a pi3b+, HECnet node name
29.115 - I'll christen it at some point :) Thank you John Forecast for doing all the
hard work.
Keith
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On
Behalf Of Johnny Billquist
Sent: 07 November 2021 20:37
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] Is this the most up to date version of DECnet OS numbers?
On 2021-11-07 18:06, Robert Armstrong wrote:
I think DECnet/8 is for RTS-8, but there never was one for OS-8.
Yes, the DECnet-8 was for RTS although you could run OS/8 as a task
under RTS (so maybe those two count as the same). In any case AFAIK
there was never any NFT or FAL or remote terminal or NCP/NML or
anything else like that implemented for DECnet/8. It was more of a
toolkit kind of thing where you could write your own RTS program to
make a DECnet connection to another node. What you sent over that connection was your
problem.
Right. It was/is slightly more than a toolkit. It does have a couple of processes which
deals with circuits and executor management. And I think there is TLK/LSN so you can
communicate. But beyond that, you were on your own.
And no, OS/8 under RTS-8 don't allow them to be counted as one. :-)
Never heard of DECnet for CP/M although there certainly was one for MSDOS.
Linux is interesting, although I doubt that was put there by DEC.
Probably somebody added it later.
Linux was definitely defined post-DEC. I simply just talked with a Linux FAL from RSX and
checked what value it put in the OS field, and added that to my list from there.
And what the heck is COPOS/11?? I see that is says TOPS-20 front
end, but I thought TOPS20 used the same RSX20F as TOPS10.
I don't think it's the same as the RSX20F frontend. I have no idea what it is,
but it's in the source files for the RSX DECnet code. Sounds like some oddball thing
that existed somewhere. CSS thing maybe?
And DTF/MVS? Is that the IBM OS MVS?
I almost suspect it might be, but again, no real clue. All I can say is that this is what
is in the RSX sources.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
10:49 p.m.
Just as a warning, the lat implementation have some bugs. I've never
spent the time to figure it out, but at least when talking to RSX hosts,
it triggers some bug in RSX which cause it to leak memory, and
eventually RSX becomes catatonic. But it only happens rarely, so you
might run for quite a while before observing the problem.
The problem is that that lat implementation was done by just reverse
engineering traffic between a DECserver and a VMS host.
Not sure what issues it might have with other types of hosts. I think it
is fairly well behaved talking to VMS or DECservers.
I also used to observe issues with the Linux DECnet when talking to RSX
hosts. Both with cterm, fal and phone. It might have improved since I
last tried, but if someone is running it, feel free to test talking to
MIM and please report your observations.
Johnny
On 2021-11-08 22:00, Keith Halewood wrote:
It's apparently 5.10.77-v7+.
It eventually goes a bit wrong responding to NICE requests with VMS complaining
'invalid management response' but the output showing a '...such file or
directory' but I'll try some troubleshooting tomorrow.
I installed 'latd' (apt install latd), started up with latcp -s and it's
picked up all the LAT services on the LAN, including itself, the RX4640, the KLH10
instance of Panda TOPS-20... looks fine too. Identifies its connections as the hostname
and tty, such as "PI3B3//dev/ttyAMA0"
Keith
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of
John Forecast
Sent: 08 November 2021 19:26
To: hecnet at update.uu.se
Subject: Re: [HECnet] Is this the most up to date version of DECnet OS numbers?
Glad it?s working for you. Is this running the latest Raspbian release? What kernel
version is it running?
John.
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On Nov 8, 2021, at 12:21 PM, Keith Halewood
<Keith.Halewood at pitbulluk.org> wrote:
Well, that was an interesting compilation of the raspbian kernel.
I cloned https://github.com/JohnForecast/RaspbianDECnet and got busy. I had to remove the
--help-- stanzas from the Kconfig file. They were tripping something up.
I had to move the MAC address change to the bridge (I use
/etc/network/interfaces with bridges and taps etc..)
DECnet is all working on a 32bit raspbian on a pi3b+, HECnet node name
29.115 - I'll christen it at some point :) Thank you John Forecast for doing all the
hard work.
Keith
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On
Behalf Of Johnny Billquist
Sent: 07 November 2021 20:37
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] Is this the most up to date version of DECnet OS numbers?
On 2021-11-07 18:06, Robert Armstrong wrote:
Right. It was/is slightly more than a toolkit. It does have a couple of processes which
deals with circuits and executor management. And I think there is TLK/LSN so you can
communicate. But beyond that, you were on your own.
And no, OS/8 under RTS-8 don't allow them to be counted as one. :-)
I think
DECnet/8 is for RTS-8, but there never was one for OS-8.
Yes, the DECnet-8 was for RTS although you could run OS/8 as a task
under RTS (so maybe those two count as the same). In any case AFAIK
there was never any NFT or FAL or remote terminal or NCP/NML or
anything else like that implemented for DECnet/8. It was more of a
toolkit kind of thing where you could write your own RTS program to
make a DECnet connection to another node. What you sent over that connection was your
problem. Never heard of DECnet for CP/M although there
certainly was one for MSDOS.
Linux is interesting, although I doubt that was put there by DEC.
Probably somebody added it later.
Linux was definitely defined post-DEC. I simply just talked with a Linux FAL from RSX and
checked what value it put in the OS field, and added that to my list from there.
And what the heck is COPOS/11?? I see that is
says TOPS-20 front
end, but I thought TOPS20 used the same RSX20F as TOPS10.
I don't think it's the same as the RSX20F frontend. I have no idea what it is,
but it's in the source files for the RSX DECnet code. Sounds like some oddball thing
that existed somewhere. CSS thing maybe?
And DTF/MVS? Is that the IBM OS MVS?
I almost suspect it might be, but again, no real clue. All I can say is that this is what
is in the RSX sources.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
11:15 p.m.
On Nov 8, 2021, at 4:49 PM, Johnny Billquist <bqt
at softjar.se> wrote:
Just as a warning, the lat implementation have some bugs. I've never spent the time
to figure it out, but at least when talking to RSX hosts, it triggers some bug in RSX
which cause it to leak memory, and eventually RSX becomes catatonic. But it only happens
rarely, so you might run for quite a while before observing the problem.
The problem is that that lat implementation was done by just reverse engineering traffic
between a DECserver and a VMS host.
Not sure what issues it might have with other types of hosts. I think it is fairly well
behaved talking to VMS or DECservers.
I also used to observe issues with the Linux DECnet when talking to RSX hosts. Both with
cterm, fal and phone. It might have improved since I last tried, but if someone is running
it, feel free to test talking to MIM and please report your observations.
Depending on when you last tested Linux DECnet, I made a number of changes to
cterm and DAP (both client and server).
John.
Johnny
On 2021-11-08 22:00, Keith Halewood wrote:
It's apparently 5.10.77-v7+.
It eventually goes a bit wrong responding to NICE requests with VMS complaining
'invalid management response' but the output showing a '...such file or
directory' but I'll try some troubleshooting tomorrow.
I installed 'latd' (apt install latd), started up with latcp -s and it's
picked up all the LAT services on the LAN, including itself, the RX4640, the KLH10
instance of Panda TOPS-20... looks fine too. Identifies its connections as the hostname
and tty, such as "PI3B3//dev/ttyAMA0"
Keith
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of
John Forecast
Sent: 08 November 2021 19:26
To: hecnet at update.uu.se
Subject: Re: [HECnet] Is this the most up to date version of DECnet OS numbers?
Glad it?s working for you. Is this running the latest Raspbian release? What kernel
version is it running?
John.
> On Nov 8, 2021, at 12:21 PM, Keith Halewood <Keith.Halewood at pitbulluk.org>
wrote:
>
> Well, that was an interesting compilation of the raspbian kernel.
> I cloned https://github.com/JohnForecast/RaspbianDECnet and got busy. I had to remove
the --help-- stanzas from the Kconfig file. They were tripping something up.
> I had to move the MAC address change to the bridge (I use
> /etc/network/interfaces with bridges and taps etc..)
>
> DECnet is all working on a 32bit raspbian on a pi3b+, HECnet node name
> 29.115 - I'll christen it at some point :) Thank you John Forecast for doing all
the hard work.
>
> Keith
>
> -----Original Message-----
> From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On
> Behalf Of Johnny Billquist
> Sent: 07 November 2021 20:37
> To: hecnet at Update.UU.SE
> Subject: Re: [HECnet] Is this the most up to date version of DECnet OS numbers?
>
> On 2021-11-07 18:06, Robert Armstrong wrote:
>>> I think DECnet/8 is for RTS-8, but there never was one for OS-8.
>>
>> Yes, the DECnet-8 was for RTS although you could run OS/8 as a task
>> under RTS (so maybe those two count as the same). In any case AFAIK
>> there was never any NFT or FAL or remote terminal or NCP/NML or
>> anything else like that implemented for DECnet/8. It was more of a
>> toolkit kind of thing where you could write your own RTS program to
>> make a DECnet connection to another node. What you sent over that connection was
your problem.
>
> Right. It was/is slightly more than a toolkit. It does have a couple of processes
which deals with circuits and executor management. And I think there is TLK/LSN so you can
communicate. But beyond that, you were on your own.
>
> And no, OS/8 under RTS-8 don't allow them to be counted as one. :-)
>
>> Never heard of DECnet for CP/M although there certainly was one for MSDOS.
>> Linux is interesting, although I doubt that was put there by DEC.
>> Probably somebody added it later.
>
> Linux was definitely defined post-DEC. I simply just talked with a Linux FAL from RSX
and checked what value it put in the OS field, and added that to my list from there.
>
>> And what the heck is COPOS/11?? I see that is says TOPS-20 front
>> end, but I thought TOPS20 used the same RSX20F as TOPS10.
>
> I don't think it's the same as the RSX20F frontend. I have no idea what it
is, but it's in the source files for the RSX DECnet code. Sounds like some oddball
thing that existed somewhere. CSS thing maybe?
>
>> And DTF/MVS? Is that the IBM OS MVS?
>
> I almost suspect it might be, but again, no real clue. All I can say is that this is
what is in the RSX sources.
>
> Johnny
>
> --
> Johnny Billquist || "I'm on a bus
> || on a psychedelic trip
> email: bqt at softjar.se || Reading murder books
> pdp is alive! || tryin' to stay hip" - B. Idol
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
11:38 p.m.
On 2021-11-08 23:15, John Forecast wrote:
Many years since I tested. So anything you might have done is post my
testing. So it would be interesting to hear how it works now.
Johnny
On Nov 8, 2021, at 4:49 PM, Johnny Billquist
<bqt at softjar.se> wrote:
Just as a warning, the lat implementation have some bugs. I've never spent the time
to figure it out, but at least when talking to RSX hosts, it triggers some bug in RSX
which cause it to leak memory, and eventually RSX becomes catatonic. But it only happens
rarely, so you might run for quite a while before observing the problem.
The problem is that that lat implementation was done by just reverse engineering traffic
between a DECserver and a VMS host.
Not sure what issues it might have with other types of hosts. I think it is fairly well
behaved talking to VMS or DECservers.
I also used to observe issues with the Linux DECnet when talking to RSX hosts. Both with
cterm, fal and phone. It might have improved since I last tried, but if someone is running
it, feel free to test talking to MIM and please report your observations.
Depending on when you last tested Linux DECnet, I made a number of changes to
cterm and DAP (both client and server).
John.
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
Johnny
On 2021-11-08 22:00, Keith Halewood wrote:
It's apparently 5.10.77-v7+.
It eventually goes a bit wrong responding to NICE requests with VMS complaining
'invalid management response' but the output showing a '...such file or
directory' but I'll try some troubleshooting tomorrow.
I installed 'latd' (apt install latd), started up with latcp -s and it's
picked up all the LAT services on the LAN, including itself, the RX4640, the KLH10
instance of Panda TOPS-20... looks fine too. Identifies its connections as the hostname
and tty, such as "PI3B3//dev/ttyAMA0"
Keith
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of
John Forecast
Sent: 08 November 2021 19:26
To: hecnet at update.uu.se
Subject: Re: [HECnet] Is this the most up to date version of DECnet OS numbers?
Glad it?s working for you. Is this running the latest Raspbian release? What kernel
version is it running?
John.
> On Nov 8, 2021, at 12:21 PM, Keith Halewood <Keith.Halewood at pitbulluk.org>
wrote:
>
> Well, that was an interesting compilation of the raspbian kernel.
> I cloned https://github.com/JohnForecast/RaspbianDECnet and got busy. I had to remove
the --help-- stanzas from the Kconfig file. They were tripping something up.
> I had to move the MAC address change to the bridge (I use
> /etc/network/interfaces with bridges and taps etc..)
>
> DECnet is all working on a 32bit raspbian on a pi3b+, HECnet node name
> 29.115 - I'll christen it at some point :) Thank you John Forecast for doing all
the hard work.
>
> Keith
>
> -----Original Message-----
> From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On
> Behalf Of Johnny Billquist
> Sent: 07 November 2021 20:37
> To: hecnet at Update.UU.SE
> Subject: Re: [HECnet] Is this the most up to date version of DECnet OS numbers?
>
> On 2021-11-07 18:06, Robert Armstrong wrote:
>>> I think DECnet/8 is for RTS-8, but there never was one for OS-8.
>>
>> Yes, the DECnet-8 was for RTS although you could run OS/8 as a task
>> under RTS (so maybe those two count as the same). In any case AFAIK
>> there was never any NFT or FAL or remote terminal or NCP/NML or
>> anything else like that implemented for DECnet/8. It was more of a
>> toolkit kind of thing where you could write your own RTS program to
>> make a DECnet connection to another node. What you sent over that connection was
your problem.
>
> Right. It was/is slightly more than a toolkit. It does have a couple of processes
which deals with circuits and executor management. And I think there is TLK/LSN so you can
communicate. But beyond that, you were on your own.
>
> And no, OS/8 under RTS-8 don't allow them to be counted as one. :-)
>
>> Never heard of DECnet for CP/M although there certainly was one for MSDOS.
>> Linux is interesting, although I doubt that was put there by DEC.
>> Probably somebody added it later.
>
> Linux was definitely defined post-DEC. I simply just talked with a Linux FAL from RSX
and checked what value it put in the OS field, and added that to my list from there.
>
>> And what the heck is COPOS/11?? I see that is says TOPS-20 front
>> end, but I thought TOPS20 used the same RSX20F as TOPS10.
>
> I don't think it's the same as the RSX20F frontend. I have no idea what it
is, but it's in the source files for the RSX DECnet code. Sounds like some oddball
thing that existed somewhere. CSS thing maybe?
>
>> And DTF/MVS? Is that the IBM OS MVS?
>
> I almost suspect it might be, but again, no real clue. All I can say is that this is
what is in the RSX sources.
>
> Johnny
>
> --
> Johnny Billquist || "I'm on a bus
> || on a psychedelic trip
> email: bqt at softjar.se || Reading murder books
> pdp is alive! || tryin' to stay hip" - B. Idol
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
11:20 p.m.
On 11/8/21 4:49 PM, Johnny Billquist wrote:
Just as a warning, the lat implementation have some
bugs. I've never
spent the time to figure it out, but at least when talking to RSX hosts,
it triggers some bug in RSX which cause it to leak memory, and
eventually RSX becomes catatonic.
I think most reasonable people would consider that a bug in RSX, not
a bug in the Linux LAT implementation. ;)
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
11:26 p.m.
On Nov 8, 2021, at 5:20 PM, Dave McGuire <mcguire
at neurotica.com> wrote:
On 11/8/21 4:49 PM, Johnny Billquist wrote:
Of course. Rule #1 of reliable programming: if your program malfunctions due to input
from outside the system, it's always your fault. It may be true that "the input
was invalid" but that doesn't excuse the malfunction.
Normally "invalid input" includes maliciously constructed input. To pick a
random example, some of the unit test scripts in PyDECnet send random garbage as packet
data to various components, to see if they break. If yes, I fix things.
paul
Just as a warning, the lat implementation have
some bugs. I've never spent the time to figure it out, but at least when talking to
RSX hosts, it triggers some bug in RSX which cause it to leak memory, and eventually RSX
becomes catatonic.
I think most reasonable people would consider that a bug in RSX, not a bug in the Linux
LAT implementation. ;)
11:40 p.m.
On 2021-11-08 23:20, Dave McGuire wrote:
On 11/8/21 4:49 PM, Johnny Billquist wrote:
There are two bugs.
Yes, there is definitely a bug in RSX here.
However, the fact that the Linux LAT triggers it, and nothing else I've
ever seen/used does, suggests that the Linux LAT is actually violating
the LAT protocol.
The effects in RSX is a bug triggered by a protocol violation. How other
OSes react to that I have no idea...
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
Just as a warning, the lat implementation have
some bugs. I've never
spent the time to figure it out, but at least when talking to RSX
hosts, it triggers some bug in RSX which cause it to leak memory, and
eventually RSX becomes catatonic.
? I think most reasonable people would consider that a bug in RSX, not
a bug in the Linux LAT implementation. ;)
10 Nov
10 Nov
6:10 p.m.
Heh...? I wouldn't consider it a bug; I'd say it's more of a misfeature:
RSX is flagging an occasional malformed LAT packet by running out of memory.
Oh, /OK/; perhaps the reporting paradigm (going catatonic) could be
enhanced...
Of course, that begs the question of whether I'm being like most
reasonable people, being reasonable at all, or just plain being silly...? ?
On 11/8/21 5:20 PM, Dave McGuire wrote:
On 11/8/21 4:49 PM, Johnny Billquist wrote:
Just as a warning, the lat implementation have
some bugs. I've never
spent the time to figure it out, but at least when talking to RSX
hosts, it triggers some bug in RSX which cause it to leak memory, and
eventually RSX becomes catatonic.
? I think most reasonable people would consider that a bug in RSX, not
a bug in the Linux LAT implementation. ;)
???????????? -Dave
6:20 p.m.
It's a very obscure form of flagging... :-)
Well, occasionally, the session itself also is borked and lost, which
could be a hint as well. (Actually, I think it goes hand in hand every
time. When the session is borked, some memory is also lost.)
So yeah. I consider it a bug that RSX isn't handling this better.
But I definitely also claim that latd is buggy and not following the
protocol. Sure, it's understandable that it might not since they didn't
have the protocol spec, but no matter what, it is a problem that the
implementation isn't doing things right.
Johnny
On 2021-11-10 18:10, Thomas DeBellis wrote:
Heh...? I wouldn't consider it a bug; I'd say
it's more of a misfeature:
RSX is flagging an occasional malformed LAT packet by running out of memory.
Oh, /OK/; perhaps the reporting paradigm (going catatonic) could be
enhanced...
Of course, that begs the question of whether I'm being like most
reasonable people, being reasonable at all, or just plain being silly...? ?
On 11/8/21 5:20 PM, Dave McGuire wrote:
> On 11/8/21 4:49 PM, Johnny Billquist wrote:
>> Just as a warning, the lat implementation have some bugs. I've never
>> spent the time to figure it out, but at least when talking to RSX
>> hosts, it triggers some bug in RSX which cause it to leak memory, and
>> eventually RSX becomes catatonic.
>
> ? I think most reasonable people would consider that a bug in RSX, not
> a bug in the Linux LAT implementation. ;)
>
> ???????????? -Dave
>
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
8 Nov
8 Nov
10:31 p.m.
I've been running latd on my Raspberry Pi 4 for a while (the default
install starts up using the hostname as a service name).
From OpenVMS LATCP it shows up as -
LATCP> show service pi5
LAT Control Program
Service Name: PI5
Service Status: Available
Service Ident: Linux 5.10.63-v7l+
Node Name Status Rating Identification
PI5 Reachable 10 Linux 5.10.63-v7l+
Would you care to share your RaspbianDECnet mods Keith? I'd like to try
this too.
The other question to me is - should I pioneer this using the just released
Raspberry Pi OS Debian Bullseye? I think I might!
Tony
On Tue, Nov 9, 2021 at 4:22 AM Keith Halewood <Keith.Halewood at pitbulluk.org>
wrote:
Well, that was an interesting compilation of the
raspbian kernel.
I cloned https://github.com/JohnForecast/RaspbianDECnet and got busy. I
had to remove the --help-- stanzas from the Kconfig file. They were
tripping something up.
I had to move the MAC address change to the bridge (I use
/etc/network/interfaces with bridges and taps etc..)
DECnet is all working on a 32bit raspbian on a pi3b+, HECnet node name
29.115 - I'll christen it at some point :)
Thank you John Forecast for doing all the hard work.
Keith
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On
Behalf Of Johnny Billquist
Sent: 07 November 2021 20:37
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] Is this the most up to date version of DECnet OS
numbers?
On 2021-11-07 18:06, Robert Armstrong wrote:
connection was
your problem.
Right. It was/is slightly more than a toolkit. It does have a couple of
processes which deals with circuits and executor management. And I think
there is TLK/LSN so you can communicate. But beyond that, you were on your
own.
And no, OS/8 under RTS-8 don't allow them to be counted as one. :-)
--
Tony Nicholson <tony.nicholson at computer.org>
I think
DECnet/8 is for RTS-8, but there never was one for OS-8.
Yes, the DECnet-8 was for RTS although you could run OS/8 as a task
under RTS (so maybe those two count as the same). In any case AFAIK
there was never any NFT or FAL or remote terminal or NCP/NML or
anything else like that implemented for DECnet/8. It was more of a
toolkit kind of thing where you could write your own RTS program to
make a DECnet connection to another node. What you sent over that Never heard of DECnet for CP/M although there
certainly was one for
MSDOS.
Linux is interesting, although I doubt that was
put there by DEC.
Probably somebody added it later.
Linux was definitely defined post-DEC. I simply just talked with a Linux
FAL from RSX and checked what value it put in the OS field, and added that
to my list from there.
And what the heck is COPOS/11?? I see that is
says TOPS-20 front
end, but I thought TOPS20 used the same RSX20F as TOPS10.
I don't think it's the same as the RSX20F frontend. I have no idea what it
is, but it's in the source files for the RSX DECnet code. Sounds like some
oddball thing that existed somewhere. CSS thing maybe?
And DTF/MVS? Is that the IBM OS MVS?
I almost suspect it might be, but again, no real clue. All I can say is
that this is what is in the RSX sources.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
10:42 p.m.
Most of today?s experimentation is due to the mention of linux around DECnet and LAT?
It?ll give the VT510 I have a little bit of freedom with a serial console to a tiny little
Pi and then on, via DECnet or LAT to the rest of the kit, simulated and real. Now all I
have to do is stop pronouncing ?llogin? (set host/lat) in the Welsh fashion, ll being a
voiceless L sound.
Tony ? it?s all there in John?s git repo, see below:
Keith
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Tony
Nicholson
Sent: 08 November 2021 21:31
To: HECnet Mailing-list <hecnet at update.uu.se>
Subject: Re: [HECnet] Is this the most up to date version of DECnet OS numbers?
I've been running latd on my Raspberry Pi 4 for a while (the default install starts up
using the hostname as a service name).
Right. It was/is slightly more than a toolkit. It does have a couple of processes which
deals with circuits and executor management. And I think there is TLK/LSN so you can
communicate. But beyond that, you were on your own.
And no, OS/8 under RTS-8 don't allow them to be counted as one. :-)
From OpenVMS LATCP it shows up as -
LATCP> show service pi5
LAT Control Program
Service Name: PI5
Service Status: Available
Service Ident: Linux 5.10.63-v7l+
Node Name Status Rating Identification
PI5 Reachable 10 Linux 5.10.63-v7l+
Would you care to share your RaspbianDECnet mods Keith? I'd like to try this too.
The other question to me is - should I pioneer this using the just released Raspberry Pi
OS Debian Bullseye? I think I might!
Tony
On Tue, Nov 9, 2021 at 4:22 AM Keith Halewood <Keith.Halewood at
pitbulluk.org<mailto:Keith.Halewood at pitbulluk.org>> wrote:
Well, that was an interesting compilation of the raspbian kernel.
I cloned https://github.com/JohnForecast/RaspbianDECnet and got busy. I had to remove the
--help-- stanzas from the Kconfig file. They were tripping something up.
I had to move the MAC address change to the bridge (I use /etc/network/interfaces with
bridges and taps etc..)
DECnet is all working on a 32bit raspbian on a pi3b+, HECnet node name 29.115 - I'll
christen it at some point :)
Thank you John Forecast for doing all the hard work.
Keith
-----Original Message-----
From: owner-hecnet at Update.UU.SE<mailto:owner-hecnet at Update.UU.SE>
[mailto:owner-hecnet at Update.UU.SE<mailto:owner-hecnet at Update.UU.SE>] On Behalf
Of Johnny Billquist
Sent: 07 November 2021 20:37
To: hecnet at Update.UU.SE<mailto:hecnet at Update.UU.SE>
Subject: Re: [HECnet] Is this the most up to date version of DECnet OS numbers?
On 2021-11-07 18:06, Robert Armstrong wrote:
I think
DECnet/8 is for RTS-8, but there never was one for OS-8.
Yes, the DECnet-8 was for RTS although you could run OS/8 as a task
under RTS (so maybe those two count as the same). In any case AFAIK
there was never any NFT or FAL or remote terminal or NCP/NML or
anything else like that implemented for DECnet/8. It was more of a
toolkit kind of thing where you could write your own RTS program to
make a DECnet connection to another node. What you sent over that connection was your
problem. Never heard of DECnet for CP/M although there
certainly was one for MSDOS.
Linux is interesting, although I doubt that was put there by DEC.
Probably somebody added it later.
Linux was definitely defined post-DEC. I simply just talked with a Linux FAL from RSX and
checked what value it put in the OS field, and added that to my list from there.
And what the heck is COPOS/11?? I see that is says
TOPS-20 front
end, but I thought TOPS20 used the same RSX20F as TOPS10.
I don't think it's the same as the RSX20F frontend. I have no idea what it is, but
it's in the source files for the RSX DECnet code. Sounds like some oddball thing that
existed somewhere. CSS thing maybe?
And DTF/MVS? Is that the IBM OS MVS?
I almost suspect it might be, but again, no real clue. All I can say is that this is what
is in the RSX sources.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se<mailto:bqt at softjar.se> || Reading murder
books
pdp is alive! || tryin' to stay hip" - B. Idol
--
Tony Nicholson <tony.nicholson at computer.org<mailto:tony.nicholson at
computer.org>>
12:55 a.m.
I have heard of three 'standard' (I.E., DEC supported) front ends for
the 20,
1. RSX-20F for the terminals and KL management,
2. MCB for DECnet and
3. DN60 for IBM RJE workstations (which I maintained at Columbia.
I do know of some hacked front ends:
1. Case Western had a second front end running terminals (that's right
two front ends with DH11's).? How they got that many users signed on
without the system melting into a puddle of bits is beyond me.
2. MIT Chaos on a KL uses a DN20 for the Ethernet communications (an NI
not being available at the time)
I never heard of COPOS/11, either but I don't get out much... Anybody else?
------------------------------------------------------------------------
On 11/7/21 12:06 PM, Robert Armstrong wrote:
And what the heck is COPOS/11?? I see that is says TOPS-20 front end, but
I thought TOPS20 used the same RSX20F as TOPS10.
And DTF/MVS? Is that the IBM OS MVS?
Bob
1:02 a.m.
>MIT Chaos on a KL uses a DN20 for the Ethernet
communications (an NI not being
>available at the time)
For Chaosnet on tops20, for example OZ was runing "Minits" on the front end and
the chaos interface is a
MIT-Special Unibus device. 1822 was spoken with a LH-DH interface.
(For those who don't knew, Chaos was a LAN technology using 75 ohm cable and 3 Mbit
and it had
16 bit addresses, 8 bit for network and host each.)
Chaos over Ethernet came way later..
-
Sorry for leaving out DN60, thought it was irrelevant for most users...
1:13 a.m.
I was in touch with Lars recently, talking with him about putting
Chaosnet back into the PANDA distribution as a number of programs (such
as the mailer and FTP) know how to use it.? I also wanted to put the VTS
(SUPDUP) service back in, too.
I've spent some looking at the code and I believe there were two
different Tops-20 implementations, one for the KL which ran on XX and
EECS and /maybe/ another that ran on the 2020.? ITS uses that hardware
configuration.? I don't remember anything about OZ, I don't think it was
on the 9th floor, at least not when I was hanging out there.
I'm not sure if the IBMSPL software had extensive usage.? Earlier
versions of it were /very/ cantankerous, but it improved.? I knew one of
the authors at Marlboro (K. Reti) who I thought was one of the more
brightest bulbs I had come across.? Columbia used IBMSPL extensively,
but not for the reasons you'd think.
In addition to routing CCnet (DECnet) email to the ARPAnet, we also
routed the _entirety_ of BITnet, which was a 'network' of IBM mainframes
that sent email to each other.? It wasn't SNA, they all looked like RJE
workstations and 'punched' card decks of email to each other.? I think
our news feed may have come through IBMSPL too.
In other words, that particular software was beat on day and night and
eventually functioned quite competently.? I keep thinking about putting
that up, too, although I don't know how I'd get the PDP-11 code working
(or what it might talk to)
------------------------------------------------------------------------
On 11/7/21 7:02 PM, Peter Lothberg wrote:
MIT Chaos on a KL uses a DN20 for the Ethernet
communications (an
NI not being available at the time)
For Chaosnet on tops20, for example OZ was runing "Minits" on the
front end and the chaos interface is a
MIT-Special Unibus device.? 1822 was spoken with a LH-DH interface.
(For those who don't knew, Chaos was a LAN technology using 75 ohm
cable and 3 Mbit and it had
?16 bit addresses, 8 bit for network and host each.)
Chaos over Ethernet came way later..
Sorry for leaving out DN60, thought it was irrelevant for most users...
1:18 a.m.
I don't think it was on the 9th floor, at least
not when I was hanging out there.
It was on the 9'th floor. There where "footsteps" glued to the floor,
"the way to OZ".
Rob Austin was sys$manager, and it was used to develop "Chives" the domain
resolver,
but it belonged to the folks on 4:th floor not 7:th floor.
The 2020's showed up much later and was only used to run ITS.
-P
From: "tommytimesharing"
<tommytimesharing at gmail.com>
To: "hecnet" <hecnet at Update.UU.SE>
Sent: Sunday, November 7, 2021 7:13:00 PM
Subject: Re: [HECnet] Is this the most up to date version of DECnet OS numbers?
I was in touch with Lars recently, talking with him
about putting Chaosnet back
into the PANDA distribution as a number of programs (such as the mailer and
FTP) know how to use it. I also wanted to put the VTS (SUPDUP) service back in,
too.
I've spent some looking at the code and I believe
there were two different
Tops-20 implementations, one for the KL which ran on XX and EECS and maybe
another that ran on the 2020. ITS uses that hardware configuration. I don't
remember anything about OZ, I don't think it was on the 9th floor, at least not
when I was hanging out there.
I'm not sure if the IBMSPL software had extensive
usage. Earlier versions of it
were very cantankerous, but it improved. I knew one of the authors at Marlboro
(K. Reti) who I thought was one of the more brightest bulbs I had come across.
Columbia used IBMSPL extensively, but not for the reasons you'd think.
In addition to routing CCnet (DECnet) email to the
ARPAnet, we also routed the
entirety of BITnet, which was a 'network' of IBM mainframes that sent email to
each other. It wasn't SNA, they all looked like RJE workstations and
'punched'
card decks of email to each other. I think our news feed may have come through
IBMSPL too.
In other words, that particular software was beat on
day and night and
eventually functioned quite competently. I keep thinking about putting that up,
too, although I don't know how I'd get the PDP-11 code working (or what it
might talk to)
On 11/7/21 7:02 PM, Peter Lothberg wrote:
>>>MIT Chaos on a KL uses a DN20 for the
Ethernet communications (an NI not being
>> >available at the time)
> For Chaosnet on tops20, for example OZ was runing
"Minits" on the front end and
> the chaos interface is a
> MIT-Special Unibus device. 1822 was spoken with a LH-DH interface.
> (For those who don't knew, Chaos was a LAN
technology using 75 ohm cable and 3
> Mbit and it had
> 16 bit addresses, 8 bit for network and host each.)
> Chaos over Ethernet came way later..
> Sorry for leaving out DN60, thought it was
irrelevant for most users...
1:17 a.m.
I sortof doubt COPOS/11 is a regular TOPS-20 terminal frontend. Too bad
I have no further information.
Johnny
On 2021-11-08 00:55, Thomas DeBellis wrote:
I have heard of three 'standard' (I.E., DEC
supported) front ends for
the 20,
1. RSX-20F for the terminals and KL management,
2. MCB for DECnet and
3. DN60 for IBM RJE workstations (which I maintained at Columbia.
I do know of some hacked front ends:
1. Case Western had a second front end running terminals (that's right
two front ends with DH11's).? How they got that many users signed on
without the system melting into a puddle of bits is beyond me.
2. MIT Chaos on a KL uses a DN20 for the Ethernet communications (an NI
not being available at the time)
I never heard of COPOS/11, either but I don't get out much... Anybody else?
> ------------------------------------------------------------------------
> On 11/7/21 12:06 PM, Robert Armstrong wrote:
>
>
> And what the heck is COPOS/11?? I see that is says TOPS-20 front end, but
> I thought TOPS20 used the same RSX20F as TOPS10.
>
> And DTF/MVS? Is that the IBM OS MVS?
>
> Bob
>
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
7 Nov
7 Nov
9:27 p.m.
On 2021-11-07 16:08, Paul Koning wrote:
Right. And yes, it's RTS-8 that have DECNET-8. OS/8 would be very
unlikely to ever have anything.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On Nov 7, 2021, at 10:04 AM, Dave McGuire
<mcguire at neurotica.com> wrote:
On 11/7/21 6:17 AM, Johnny Billquist wrote:
Not necessarily. Code points were at times assigned to things that never happened.
Consider the Cterm foundation layer which lists RSTS and RT-11, neither of which ever
implemented Cterm. Or OS-8 and RTS-8 in several of those lists; I think DECnet/8 is for
RTS-8, but there never was one for OS-8. (Or is it the other way around?) However, extrapolating from this, in NFT/FAL,
there is a much more extensive list, which seems to align with this list, which contains:
...
16 CP/M
Wait, what? There was a DECnet implementation for CP/M?
8 Nov
8 Nov
4:38 a.m.
On 11/7/21 10:08 AM, Paul Koning wrote:
Not necessarily. Code points were at times assigned to things that never happened.
Consider the Cterm foundation layer which lists RSTS and RT-11, neither of which ever
implemented Cterm. Or OS-8 and RTS-8 in several of those lists; I think DECnet/8 is for
RTS-8, but there never was one for OS-8. (Or is it the other way around?)
Well, it sure was nice to think about for a moment. I've always
loved CP/M. It warms my cockles just knowing that someone once
considered it a possibility.
-Dave, a.k.a. "H.J. Hotcockles"
--
Dave McGuire, AK4HZ
New Kensington, PA
However, extrapolating from this, in NFT/FAL, there is
a much more extensive list, which seems to align with this list, which contains:
...
16 CP/M
Wait, what? There was a DECnet implementation for CP/M?
12:40 a.m.
Hi Johnny,
I got the list from the SETNOD that came with PANDA, the DEC version
being _UPD ID= 479, SNARK:<6.UTILITIES>SETHOS.MAC.4,? 10-Feb-84 14:39:12
by EVANS_.? I should note that this list /conflicts/ with what is in
DAPSYM. Since my DAPSYM is from 1980, I thought that SETNOD might take
precedence or otherwise be more 'accurate'.? At least, I didn't remember
the SETNOD one being wrong from the last time I was hacking it.? Just in
case, I double checked and It seems OK; take a look at following tests:
Kermit-20>set line *VENTI2*::
[Remote system is running /TOPS-20/]
Kermit-20>set line *VENTI*::
[Remote system is running /TOPS-10/]
Kermit-20>set line *MIM*::
?/RSX-11M/ type systems do not support Tops-10/20 NRT communications.
Kermit-20>set line *APOLLO*::
?/VMS/ type systems do not support Tops-10/20 NRT communications.
Kermit-20>set line *BITXOT*::
?/RSTS/E/type systems do not support Tops-10/20 NRT communications.
Kermit-20>
Since I've signed on to every system via CTERM except the last, I know
those messages are correct.? I have no id for BITXOT::, but it is
documented to be RSTS/E, so the value 1 there appears correct.? I was
unable to test with the two RT systems that are documented in MIM:: and
am not sure what the reject reason means.
Kermit-20>set line *SEADOG*::
?Connection failure, Reject or Disconnect by Object
Kermit-20>set line *SNOTRA*::
?Connection failure, Reject or Disconnect by Object
Kermit-20>
On the other hand, I don't remember my FAL/NFT/DAP blowing up on the
wrong system, either (they blow up on plenty of other stuff...)? It
would appear that there are _two_ (2) separate lists of system type
bytes, one for NRT and the other for DAP, viz:
? NRT??????????????? DAPSYM
?1??? RSTS????? .OSRT==1??????? ;RT-11
?2??? RT-11???? .OSRST==2?????? ;RSTS/E
?3??? RSTS/E??? .OSRXS==3?????? ;RSX-11S
?4??? RSX-11S?? .OSRXM==4?????? ;RSX-11M
?5??? RSX-11M?? .OSRXD==5?????? ;RSX-11D
?6??? RSX-11D?? .OSIAS==6?????? ;IAS
?7??? IAS?????? .OSVAX==7?????? ;VAX/VMS
?8??? VMS?????? .OSTP20==10???? ;TOPS-20 (^D8)
?9??? TOPS-20?? .OSTP10==11???? ;TOPS-10 (^D9)
10??? TOPS-10?? .OSOS8==12????? ;OS-8 (^D10)
11??? RTS-8???? .OSRXP==13????? ;RSX11-M PLUS (^D11)
12??? OS-8
13??? RSX-11M+
14??? MCB
Does anybody know what the CTERM list would be?? This disparity is
unfortunate.? Any speculations as to how it happened?? I'm thinking
somebody not talking to somebody else, but I really wouldn't have any idea.
------------------------------------------------------------------------
On 11/7/21 6:17 AM, Johnny Billquist wrote:
Thomas, I'm not sure where you got that list from.
It seems slightly mismatching what I can find. Looking at the NRT code
in RSX (which uses object 23, and is shared by code in RSX for
connecting to both RSTS/E, VMS and Tops-20), I find this:
1? RT-11
2? RSTS/E
3? RSX-11S
4? RSX-11M
5? RSX-11D
6? IAS
7? VMS
Those are the documented values for the configuration message that I
can find.
However, extrapolating from this, in NFT/FAL, there is a much more
extensive list, which seems to align with this list, which contains:
8? TOPS-20
9? Tops-10
10 RTS-8
11 OS/8
12 RSX-11M-PLUS
13 COPOS/11 (TOPS-20 frontend)
14 P/OS
15 VAXELN
16 CP/M
17 MS-DOS
18 Ultrix-32
19 Ultrix-11
20 DTF/MVS
25 Windows NT
26 Linux
Now, Linux is a value I believe I added just based on observation, so
it's much less official. But I think all the other ones are ones DEC
did assign. Unfortunately, I think Windows NT was also added by me,
based on observation of Pathworks. So I do not know what the values
between 20 and 25 could/should be.
But maybe this helps some anyway?
? Johnny
On 2021-11-07 11:23, Thomas DeBellis wrote:
Since its inception, Kermit-20 (one the first
three Kermit
implementations) has had the 'limitation' that it will only talk to a
remote Kermit via a physical terminal line (I.E., something like
TTY6:).? It doesn't do network terminals in part because it has no
code to handle the out-of-band or meta-data that one finds on TVT's
(like IAC's) or CTERM's.
This doesn't exist for the early NRT terminals which were implemented
for Tops-10 and Tops-20.? Once you've read the initial configuration
message and decided what to do, you basically never have to bother
with meta-data.? Because I'm trying to look at an NFT issue between
Tops-10 and Tops-20, I needed another transport mechanism and
modifying Kermit-20 to do DECnet 36 NRT's seemed like an easy hack.?
Since Tops-10 Kermit isn't making an outgoing connection, it is none
the wiser.
Thus far, it has been fairly straightforward.? Right now I'm just
catching the few cases where certain operations don't make sense or
otherwise wouldn't work (like setting the terminal speed). Another
thing I'd like to prevent is Kermit-20 bothering non-36 bit systems.?
This is easily enough done by checking some 'magic' bits in the
initial configuration message and restricting by OS type.? This
raises two questions:
First, is the list below complete?? What about Ultrix and ... what else?
???? ?1??? RSTS ?2??? RT-11 ?3??? RSTS/E ?4??? RSX-11S ?5 RSX-11M
???? ?6??? RSX-11D ?7??? IAS ?8??? VMS ?9??? TOPS-20 10 TOPS-10 11??
??? RTS-8 12??? OS-8 13??? RSX-11M+ 14??? MCB
Second, the configuration isn't well documented.? Actually, I'm not
sure if it's documented, period.? All I have is are some notes that
Johnny wrote up in the process of reverse-engineering it and very
kindly gave me.? They are certainly fine for this particular
implementation, but I was just wondering what else there might be.
Plenty for LAT and CTERM, but I don't think I've stumbled over NRT.
1:15 a.m.
I looked at the code in RSX, which have specific versions of the client
software for connecting to TOPS, RSTS/E and VMS. Funnily, only the
RSTS/E client is explicitly checking the OS field value. Neither the VMS
client, nor the TOPS client is checking that. The TOPS client happily
connects me to whatever, but with non-TOPS hosts, I get disconnected as
soon as I actually type anything.
But the RSTS/E variant is checking that the OS field have the value 2.
So I'm really wondering if the field is modified before processing when
you receive then. We could of course run some dumps and see exactly what
is going over the circuit...
And I verified that BITXOT is indeed RSTS/E, and responding with what I
see as a 2 in the OS field:
.rrs bitxot
JOCKE::RRS -- Connection established to node BITXOT::
RSTS V10.1-L 08-Nov-21 02:27
User:
With RT-11, I don't think there are actually any systems online on
HECnet. Some people have reserved names for RT-11 systems, but as far as
I know, noone have actually located DECnet/RT yet.
.ncp tell seadog sho exec
NCP -- Show failed, Listener connect failed, node unreachable
The list of OSes and values for CTERM are in the documentation, which is
online:
http://linux-decnet.sourceforge.net/docs/found.txt
The list in there matches what I posted as well. See page 65 for example.
Johnny
On 2021-11-08 00:40, Thomas DeBellis wrote:
Hi Johnny,
I got the list from the SETNOD that came with PANDA, the DEC version
being _UPD ID= 479, SNARK:<6.UTILITIES>SETHOS.MAC.4,? 10-Feb-84 14:39:12
by EVANS_.? I should note that this list /conflicts/ with what is in
DAPSYM. Since my DAPSYM is from 1980, I thought that SETNOD might take
precedence or otherwise be more 'accurate'.? At least, I didn't remember
the SETNOD one being wrong from the last time I was hacking it.? Just in
case, I double checked and It seems OK; take a look at following tests:
Kermit-20>set line *VENTI2*::
[Remote system is running /TOPS-20/]
Kermit-20>set line *VENTI*::
[Remote system is running /TOPS-10/]
Kermit-20>set line *MIM*::
?/RSX-11M/ type systems do not support Tops-10/20 NRT communications.
Kermit-20>set line *APOLLO*::
?/VMS/ type systems do not support Tops-10/20 NRT communications.
Kermit-20>set line *BITXOT*::
?/RSTS/E/type systems do not support Tops-10/20 NRT communications.
Kermit-20>
Since I've signed on to every system via CTERM except the last, I know
those messages are correct.? I have no id for BITXOT::, but it is
documented to be RSTS/E, so the value 1 there appears correct.? I was
unable to test with the two RT systems that are documented in MIM:: and
am not sure what the reject reason means.
Kermit-20>set line *SEADOG*::
?Connection failure, Reject or Disconnect by Object
Kermit-20>set line *SNOTRA*::
?Connection failure, Reject or Disconnect by Object
Kermit-20>
On the other hand, I don't remember my FAL/NFT/DAP blowing up on the
wrong system, either (they blow up on plenty of other stuff...)? It
would appear that there are _two_ (2) separate lists of system type
bytes, one for NRT and the other for DAP, viz:
? NRT??????????????? DAPSYM
?1??? RSTS????? .OSRT==1??????? ;RT-11
?2??? RT-11???? .OSRST==2?????? ;RSTS/E
?3??? RSTS/E??? .OSRXS==3?????? ;RSX-11S
?4??? RSX-11S?? .OSRXM==4?????? ;RSX-11M
?5??? RSX-11M?? .OSRXD==5?????? ;RSX-11D
?6??? RSX-11D?? .OSIAS==6?????? ;IAS
?7??? IAS?????? .OSVAX==7?????? ;VAX/VMS
?8??? VMS?????? .OSTP20==10???? ;TOPS-20 (^D8)
?9??? TOPS-20?? .OSTP10==11???? ;TOPS-10 (^D9)
10??? TOPS-10?? .OSOS8==12????? ;OS-8 (^D10)
11??? RTS-8???? .OSRXP==13????? ;RSX11-M PLUS (^D11)
12??? OS-8
13??? RSX-11M+
14??? MCB
Does anybody know what the CTERM list would be?? This disparity is
unfortunate.? Any speculations as to how it happened?? I'm thinking
somebody not talking to somebody else, but I really wouldn't have any idea.
> ------------------------------------------------------------------------
> On 11/7/21 6:17 AM, Johnny Billquist wrote:
>
> Thomas, I'm not sure where you got that list from.
>
> It seems slightly mismatching what I can find. Looking at the NRT code
> in RSX (which uses object 23, and is shared by code in RSX for
> connecting to both RSTS/E, VMS and Tops-20), I find this:
>
> 1? RT-11
> 2? RSTS/E
> 3? RSX-11S
> 4? RSX-11M
> 5? RSX-11D
> 6? IAS
> 7? VMS
>
>
> Those are the documented values for the configuration message that I
> can find.
>
> However, extrapolating from this, in NFT/FAL, there is a much more
> extensive list, which seems to align with this list, which contains:
>
> 8? TOPS-20
> 9? Tops-10
> 10 RTS-8
> 11 OS/8
> 12 RSX-11M-PLUS
> 13 COPOS/11 (TOPS-20 frontend)
> 14 P/OS
> 15 VAXELN
> 16 CP/M
> 17 MS-DOS
> 18 Ultrix-32
> 19 Ultrix-11
> 20 DTF/MVS
> 25 Windows NT
> 26 Linux
>
>
> Now, Linux is a value I believe I added just based on observation, so
> it's much less official. But I think all the other ones are ones DEC
> did assign. Unfortunately, I think Windows NT was also added by me,
> based on observation of Pathworks. So I do not know what the values
> between 20 and 25 could/should be.
>
> But maybe this helps some anyway?
>
> ? Johnny
>
>
> On 2021-11-07 11:23, Thomas DeBellis wrote:
>> Since its inception, Kermit-20 (one the first three Kermit
>> implementations) has had the 'limitation' that it will only talk to a
>> remote Kermit via a physical terminal line (I.E., something like
>> TTY6:).? It doesn't do network terminals in part because it has no
>> code to handle the out-of-band or meta-data that one finds on TVT's
>> (like IAC's) or CTERM's.
>>
>> This doesn't exist for the early NRT terminals which were implemented
>> for Tops-10 and Tops-20.? Once you've read the initial configuration
>> message and decided what to do, you basically never have to bother
>> with meta-data.? Because I'm trying to look at an NFT issue between
>> Tops-10 and Tops-20, I needed another transport mechanism and
>> modifying Kermit-20 to do DECnet 36 NRT's seemed like an easy hack.
>> Since Tops-10 Kermit isn't making an outgoing connection, it is none
>> the wiser.
>>
>> Thus far, it has been fairly straightforward.? Right now I'm just
>> catching the few cases where certain operations don't make sense or
>> otherwise wouldn't work (like setting the terminal speed). Another
>> thing I'd like to prevent is Kermit-20 bothering non-36 bit systems.
>> This is easily enough done by checking some 'magic' bits in the
>> initial configuration message and restricting by OS type.? This
>> raises two questions:
>>
>> First, is the list below complete?? What about Ultrix and ... what else?
>>
>> ???? ?1??? RSTS ?2??? RT-11 ?3??? RSTS/E ?4??? RSX-11S ?5 RSX-11M
>> ???? ?6??? RSX-11D ?7??? IAS ?8??? VMS ?9??? TOPS-20 10 TOPS-10 11
>> ??? RTS-8 12??? OS-8 13??? RSX-11M+ 14??? MCB
>>
>> Second, the configuration isn't well documented.? Actually, I'm not
>> sure if it's documented, period.? All I have is are some notes that
>> Johnny wrote up in the process of reverse-engineering it and very
>> kindly gave me.? They are certainly fine for this particular
>> implementation, but I was just wondering what else there might be.
>> Plenty for LAT and CTERM, but I don't think I've stumbled over NRT.
>>
>>
>
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
1:43 a.m.
Actually, we might be looking at different things.
So, here is what I'm looking at.
In RSX, the clients are connecting to object 23. After connection, the
two sides are supposed to exchange configuration messages.
Packets have the following format:
TYPE(8)
1 = Configuration message
2 = Control message
3 = Unsupported message
4 = Continue message
5 = Data message
Length(16)
[rest of packet depends on type]
[Configuration packet continues with]
OS(8)
Values as mentioned before
Versions(5x8)
Session mode(8)
Menu for config(8)
Not bothering showing the format of the other types of messages right
now. I can dig out some more on that later if needed.
Does this in any way match what you are looking at, Thomas?
Johnny
On 2021-11-08 01:15, Johnny Billquist wrote:
I looked at the code in RSX, which have specific
versions of the client
software for connecting to TOPS, RSTS/E and VMS. Funnily, only the
RSTS/E client is explicitly checking the OS field value. Neither the VMS
client, nor the TOPS client is checking that. The TOPS client happily
connects me to whatever, but with non-TOPS hosts, I get disconnected as
soon as I actually type anything.
But the RSTS/E variant is checking that the OS field have the value 2.
So I'm really wondering if the field is modified before processing when
you receive then. We could of course run some dumps and see exactly what
is going over the circuit...
And I verified that BITXOT is indeed RSTS/E, and responding with what I
see as a 2 in the OS field:
.rrs bitxot
JOCKE::RRS -- Connection established to node BITXOT::
RSTS V10.1-L 08-Nov-21 02:27
User:
With RT-11, I don't think there are actually any systems online on
HECnet. Some people have reserved names for RT-11 systems, but as far as
I know, noone have actually located DECnet/RT yet.
.ncp tell seadog sho exec
NCP -- Show failed, Listener connect failed, node unreachable
The list of OSes and values for CTERM are in the documentation, which is
online:
http://linux-decnet.sourceforge.net/docs/found.txt
The list in there matches what I posted as well. See page 65 for example.
? Johnny
On 2021-11-08 00:40, Thomas DeBellis wrote:
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
Hi Johnny,
I got the list from the SETNOD that came with PANDA, the DEC version
being _UPD ID= 479, SNARK:<6.UTILITIES>SETHOS.MAC.4,? 10-Feb-84
14:39:12 by EVANS_.? I should note that this list /conflicts/ with
what is in DAPSYM. Since my DAPSYM is from 1980, I thought that SETNOD
might take precedence or otherwise be more 'accurate'.? At least, I
didn't remember the SETNOD one being wrong from the last time I was
hacking it.? Just in case, I double checked and It seems OK; take a
look at following tests:
??? Kermit-20>set line *VENTI2*::
??? [Remote system is running /TOPS-20/]
??? Kermit-20>set line *VENTI*::
??? [Remote system is running /TOPS-10/]
??? Kermit-20>set line *MIM*::
??? ?/RSX-11M/ type systems do not support Tops-10/20 NRT communications.
??? Kermit-20>set line *APOLLO*::
??? ?/VMS/ type systems do not support Tops-10/20 NRT communications.
??? Kermit-20>set line *BITXOT*::
??? ?/RSTS/E/type systems do not support Tops-10/20 NRT communications.
??? Kermit-20>
Since I've signed on to every system via CTERM except the last, I know
those messages are correct.? I have no id for BITXOT::, but it is
documented to be RSTS/E, so the value 1 there appears correct.? I was
unable to test with the two RT systems that are documented in MIM::
and am not sure what the reject reason means.
??? Kermit-20>set line *SEADOG*::
??? ?Connection failure, Reject or Disconnect by Object
??? Kermit-20>set line *SNOTRA*::
??? ?Connection failure, Reject or Disconnect by Object
??? Kermit-20>
On the other hand, I don't remember my FAL/NFT/DAP blowing up on the
wrong system, either (they blow up on plenty of other stuff...)? It
would appear that there are _two_ (2) separate lists of system type
bytes, one for NRT and the other for DAP, viz:
???? ? NRT??????????????? DAPSYM
???? ?1??? RSTS????? .OSRT==1??????? ;RT-11
???? ?2??? RT-11???? .OSRST==2?????? ;RSTS/E
???? ?3??? RSTS/E??? .OSRXS==3?????? ;RSX-11S
???? ?4??? RSX-11S?? .OSRXM==4?????? ;RSX-11M
???? ?5??? RSX-11M?? .OSRXD==5?????? ;RSX-11D
???? ?6??? RSX-11D?? .OSIAS==6?????? ;IAS
???? ?7??? IAS?????? .OSVAX==7?????? ;VAX/VMS
???? ?8??? VMS?????? .OSTP20==10???? ;TOPS-20 (^D8)
???? ?9??? TOPS-20?? .OSTP10==11???? ;TOPS-10 (^D9)
??? 10??? TOPS-10?? .OSOS8==12????? ;OS-8 (^D10)
??? 11??? RTS-8???? .OSRXP==13????? ;RSX11-M PLUS (^D11)
??? 12??? OS-8
??? 13??? RSX-11M+
??? 14??? MCB
Does anybody know what the CTERM list would be?? This disparity is
unfortunate.? Any speculations as to how it happened?? I'm thinking
somebody not talking to somebody else, but I really wouldn't have any
idea.
> ------------------------------------------------------------------------
> On 11/7/21 6:17 AM, Johnny Billquist wrote:
>
> Thomas, I'm not sure where you got that list from.
>
> It seems slightly mismatching what I can find. Looking at the NRT
> code in RSX (which uses object 23, and is shared by code in RSX for
> connecting to both RSTS/E, VMS and Tops-20), I find this:
>
> 1? RT-11
> 2? RSTS/E
> 3? RSX-11S
> 4? RSX-11M
> 5? RSX-11D
> 6? IAS
> 7? VMS
>
>
> Those are the documented values for the configuration message that I
> can find.
>
> However, extrapolating from this, in NFT/FAL, there is a much more
> extensive list, which seems to align with this list, which contains:
>
> 8? TOPS-20
> 9? Tops-10
> 10 RTS-8
> 11 OS/8
> 12 RSX-11M-PLUS
> 13 COPOS/11 (TOPS-20 frontend)
> 14 P/OS
> 15 VAXELN
> 16 CP/M
> 17 MS-DOS
> 18 Ultrix-32
> 19 Ultrix-11
> 20 DTF/MVS
> 25 Windows NT
> 26 Linux
>
>
> Now, Linux is a value I believe I added just based on observation, so
> it's much less official. But I think all the other ones are ones DEC
> did assign. Unfortunately, I think Windows NT was also added by me,
> based on observation of Pathworks. So I do not know what the values
> between 20 and 25 could/should be.
>
> But maybe this helps some anyway?
>
> ? Johnny
>
>
> On 2021-11-07 11:23, Thomas DeBellis wrote:
>> Since its inception, Kermit-20 (one the first three Kermit
>> implementations) has had the 'limitation' that it will only talk to
>> a remote Kermit via a physical terminal line (I.E., something like
>> TTY6:).? It doesn't do network terminals in part because it has no
>> code to handle the out-of-band or meta-data that one finds on TVT's
>> (like IAC's) or CTERM's.
>>
>> This doesn't exist for the early NRT terminals which were
>> implemented for Tops-10 and Tops-20.? Once you've read the initial
>> configuration message and decided what to do, you basically never
>> have to bother with meta-data.? Because I'm trying to look at an NFT
>> issue between Tops-10 and Tops-20, I needed another transport
>> mechanism and modifying Kermit-20 to do DECnet 36 NRT's seemed like
>> an easy hack. Since Tops-10 Kermit isn't making an outgoing
>> connection, it is none the wiser.
>>
>> Thus far, it has been fairly straightforward.? Right now I'm just
>> catching the few cases where certain operations don't make sense or
>> otherwise wouldn't work (like setting the terminal speed). Another
>> thing I'd like to prevent is Kermit-20 bothering non-36 bit systems.
>> This is easily enough done by checking some 'magic' bits in the
>> initial configuration message and restricting by OS type.? This
>> raises two questions:
>>
>> First, is the list below complete?? What about Ultrix and ... what
>> else?
>>
>> ???? ?1??? RSTS ?2??? RT-11 ?3??? RSTS/E ?4??? RSX-11S ?5 RSX-11M
>> ???? ?6??? RSX-11D ?7??? IAS ?8??? VMS ?9??? TOPS-20 10 TOPS-10 11
>> ??? RTS-8 12??? OS-8 13??? RSX-11M+ 14??? MCB
>>
>> Second, the configuration isn't well documented.? Actually, I'm not
>> sure if it's documented, period.? All I have is are some notes that
>> Johnny wrote up in the process of reverse-engineering it and very
>> kindly gave me.? They are certainly fine for this particular
>> implementation, but I was just wondering what else there might be.
>> Plenty for LAT and CTERM, but I don't think I've stumbled over NRT.
>>
>>
>
3:57 p.m.
On Nov 7, 2021, at 6:40 PM, Thomas DeBellis
<tommytimesharing at gmail.com> wrote:
...
On the other hand, I don't remember my FAL/NFT/DAP blowing up on the wrong system,
either (they blow up on plenty of other stuff...) It would appear that there are two (2)
separate lists of system type bytes, one for NRT and the other for DAP, viz:
...
I don't know why DAP includes an OS type code at all. When I was working on DECnet
architecture I repeatedly argued that DAP implementations that do OS type checks are
broken, because they are assuming that they can correctly deduce the properties of some
remote system from its OS code. The correct way -- which is supported, in detail, by DAP
-- is to look at the feature flags to determine what the OS can and cannot do. And if
those flags are insufficient for a particular case, the solution is to extend the protocol
to add the missing information.
In other words, a client should conclude "the server can do X because it told me it
supports X" and not "the server can do X because it is running OS Y".
paul
4:16 p.m.
On 2021-11-08 15:57, Paul Koning wrote:
Absolutely agree. And I wonder if any software really do make use of the
OS codes in DAP. But it is nice that I can check what other systems
report from RSX. :-)
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On Nov 7, 2021, at 6:40 PM, Thomas DeBellis
<tommytimesharing at gmail.com> wrote:
...
On the other hand, I don't remember my FAL/NFT/DAP blowing up on the wrong system,
either (they blow up on plenty of other stuff...) It would appear that there are two (2)
separate lists of system type bytes, one for NRT and the other for DAP, viz:
...
I don't know why DAP includes an OS type code at all. When I was working on DECnet
architecture I repeatedly argued that DAP implementations that do OS type checks are
broken, because they are assuming that they can correctly deduce the properties of some
remote system from its OS code. The correct way -- which is supported, in detail, by DAP
-- is to look at the feature flags to determine what the OS can and cannot do. And if
those flags are insufficient for a particular case, the solution is to extend the protocol
to add the missing information.
In other words, a client should conclude "the server can do X because it told me it
supports X" and not "the server can do X because it is running OS Y".
4:33 p.m.
On Nov 8, 2021, at 10:16 AM, Johnny Billquist <bqt
at softjar.se> wrote:
On 2021-11-08 15:57, Paul Koning wrote:
Absolutely agree. And I wonder if any software really do make use of the OS codes in DAP.
But it is nice that I can check what other systems report from RSX. :-)
I know VMS did, that's what prompted my complaint at the time. Specifically, I think
that VMS was assuming RSTS couldn't do some X because it was RSTS. So when RSTS DAP
implemented X and reported so in the flags, VMS wasn't using it.
paul
On Nov 7,
2021, at 6:40 PM, Thomas DeBellis <tommytimesharing at gmail.com> wrote:
...
On the other hand, I don't remember my FAL/NFT/DAP blowing up on the wrong system,
either (they blow up on plenty of other stuff...) It would appear that there are two (2)
separate lists of system type bytes, one for NRT and the other for DAP, viz:
...
I don't know why DAP includes an OS type code at all. When I was working
on DECnet architecture I repeatedly argued that DAP implementations that do OS type checks
are broken, because they are assuming that they can correctly deduce the properties of
some remote system from its OS code. The correct way -- which is supported, in detail, by
DAP -- is to look at the feature flags to determine what the OS can and cannot do. And if
those flags are insufficient for a particular case, the solution is to extend the protocol
to add the missing information.
In other words, a client should conclude "the server can do X because it told me it
supports X" and not "the server can do X because it is running OS Y".
4:41 p.m.
On Nov 8, 2021, at 10:33 AM, Paul Koning
<paulkoning at comcast.net> wrote:
I think the X in question was RMS transparent access (as opposed to whole-file transfer).
RSTS implemented that as part of the Phase III work, but if I remember correctly at first
VMS wouldn't use it because it ignored the capability flags. That was one of the
biggest enhancements in that DECnet/E version, so having it not supproted correctly was
quite a big deal and very annoying.
paul
On Nov 8, 2021, at 10:16 AM, Johnny Billquist
<bqt at softjar.se> wrote:
On 2021-11-08 15:57, Paul Koning wrote:
Absolutely agree. And I wonder if any software really do make use of the OS codes in DAP.
But it is nice that I can check what other systems report from RSX. :-)
I know VMS did, that's what prompted my complaint at the time. Specifically, I think
that VMS was assuming RSTS couldn't do some X because it was RSTS. So when RSTS DAP
implemented X and reported so in the flags, VMS wasn't using it. On Nov 7,
2021, at 6:40 PM, Thomas DeBellis <tommytimesharing at gmail.com> wrote:
...
On the other hand, I don't remember my FAL/NFT/DAP blowing up on the wrong system,
either (they blow up on plenty of other stuff...) It would appear that there are two (2)
separate lists of system type bytes, one for NRT and the other for DAP, viz:
...
I don't know why DAP includes an OS type code at all. When I was working
on DECnet architecture I repeatedly argued that DAP implementations that do OS type checks
are broken, because they are assuming that they can correctly deduce the properties of
some remote system from its OS code. The correct way -- which is supported, in detail, by
DAP -- is to look at the feature flags to determine what the OS can and cannot do. And if
those flags are insufficient for a particular case, the solution is to extend the protocol
to add the missing information.
In other words, a client should conclude "the server can do X because it told me it
supports X" and not "the server can do X because it is running OS Y".
7:42 p.m.
On Nov 8, 2021, at 10:16 AM, Johnny Billquist <bqt
at softjar.se> wrote:
On 2021-11-08 15:57, Paul Koning wrote:
Absolutely agree. And I wonder if any software really do make use of the OS codes in DAP.
But it is nice that I can check what other systems report from RSX. :-)
I believe TOPS-10 may look at the OS field to determine how to format directory output. I
see a comment in the FAL version I wrote for Linux to this effect and it did not like the
user-reserved value (192) I had assigned for Linux. The current fix is to claim to be
Ultrix-32 if the remote system is TOPS-10.
John.
On Nov 7,
2021, at 6:40 PM, Thomas DeBellis <tommytimesharing at gmail.com> wrote:
...
On the other hand, I don't remember my FAL/NFT/DAP blowing up on the wrong system,
either (they blow up on plenty of other stuff...) It would appear that there are two (2)
separate lists of system type bytes, one for NRT and the other for DAP, viz:
...
I don't know why DAP includes an OS type code at all. When I was working
on DECnet architecture I repeatedly argued that DAP implementations that do OS type checks
are broken, because they are assuming that they can correctly deduce the properties of
some remote system from its OS code. The correct way -- which is supported, in detail, by
DAP -- is to look at the feature flags to determine what the OS can and cannot do. And if
those flags are insufficient for a particular case, the solution is to extend the protocol
to add the missing information.
In other words, a client should conclude "the server can do X because it told me it
supports X" and not "the server can do X because it is running OS Y".
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
4:44 p.m.
That's an excellent argument.? I was thinking that knowing the OS type
might help the user not issue commands that the remote system couldn't
do.? Tops-10 file names were what came to mind.
However, feature flags clearly could handle this.
The only thing I can imagine is a 'what if' scenario where somebody
dreams up something that the feature flag doesn't /currently/ cover; the
OS Type could be used as a heuristic until the feature flag was defined
and the implementations caught up.
That would only be a stopgap measure.? Special casing by OS type can get
you into trouble if you then have to start worrying about versions of
OS's...
------------------------------------------------------------------------
On 11/8/21 9:57 AM, Paul Koning wrote:
I don't know why DAP includes an OS type code at all. When I was working on DECnet
architecture I repeatedly argued that DAP implementations that do OS type checks are
broken, because they are assuming that they can correctly deduce the properties of some
remote system from its OS code. The correct way -- which is supported, in detail, by DAP
-- is to look at the feature flags to determine what the OS can and cannot do. And if
those flags are insufficient for a particular case, the solution is to extend the protocol
to add the missing information.
In other words, a client should conclude "the server can do X because it told me it
supports X" and not "the server can do X because it is running OS Y".
paul
------------------------------------------------------------------------
On Nov 7, 2021, at 6:40 PM, Thomas DeBellis<tommytimesharing at gmail.com> wrote:
...
On the other hand, I don't remember my FAL/NFT/DAP blowing up on the wrong system,
either (they blow up on plenty of other stuff...) It would appear that there are two (2)
separate lists of system type bytes, one for NRT and the other for DAP, viz:
...
3:04 a.m.
On Nov 7, 2021, at 6:17 AM, Johnny Billquist <bqt
at softjar.se> wrote:
Thomas, I'm not sure where you got that list from.
It seems slightly mismatching what I can find. Looking at the NRT code in RSX (which uses
object 23, and is shared by code in RSX for connecting to both RSTS/E, VMS and Tops-20), I
find this:
1 RT-11
2 RSTS/E
3 RSX-11S
4 RSX-11M
5 RSX-11D
6 IAS
7 VMS
Those are the documented values for the configuration message that I can find.
However, extrapolating from this, in NFT/FAL, there is a much more extensive list, which
seems to align with this list, which contains:
8 TOPS-20
9 Tops-10
10 RTS-8
11 OS/8
12 RSX-11M-PLUS
13 COPOS/11 (TOPS-20 frontend)
14 P/OS
15 VAXELN
16 CP/M
17 MS-DOS
18 Ultrix-32
19 Ultrix-11
20 DTF/MVS
25 Windows NT
26 Linux
Now, Linux is a value I believe I added just based on observation, so it's much less
official. But I think all the other ones are ones DEC did assign. Unfortunately, I think
Windows NT was also added by me, based on observation of Pathworks. So I do not know what
the values between 20 and 25 could/should be.
The current version of DECnet for Linux I maintain on github uses 192 for Linux
which comes from the user-defined space so I could completely avoid any conflicts with
standard implementations. 22 was for MacOS (the original O/S for the 68K and PowerPC)
where DEC resold a third party implementation (Thursby I think). I don?t remember what we
used for DECnet-SCO but that was another official implementation.
John.
But maybe this helps some anyway?
Johnny
On 2021-11-07 11:23, Thomas DeBellis wrote:
Since its inception, Kermit-20 (one the first
three Kermit implementations) has had the 'limitation' that it will only talk to a
remote Kermit via a physical terminal line (I.E., something like TTY6:). It doesn't
do network terminals in part because it has no code to handle the out-of-band or meta-data
that one finds on TVT's (like IAC's) or CTERM's.
This doesn't exist for the early NRT terminals which were implemented for Tops-10 and
Tops-20. Once you've read the initial configuration message and decided what to do,
you basically never have to bother with meta-data. Because I'm trying to look at an
NFT issue between Tops-10 and Tops-20, I needed another transport mechanism and modifying
Kermit-20 to do DECnet 36 NRT's seemed like an easy hack. Since Tops-10 Kermit
isn't making an outgoing connection, it is none the wiser.
Thus far, it has been fairly straightforward. Right now I'm just catching the few
cases where certain operations don't make sense or otherwise wouldn't work (like
setting the terminal speed). Another thing I'd like to prevent is Kermit-20 bothering
non-36 bit systems. This is easily enough done by checking some 'magic' bits in
the initial configuration message and restricting by OS type. This raises two questions:
First, is the list below complete? What about Ultrix and ... what else?
1 RSTS 2 RT-11 3 RSTS/E 4 RSX-11S 5 RSX-11M
6 RSX-11D 7 IAS 8 VMS 9 TOPS-20 10 TOPS-10 11 RTS-8 12
OS-8 13 RSX-11M+ 14 MCB
Second, the configuration isn't well documented. Actually, I'm not sure if
it's documented, period. All I have is are some notes that Johnny wrote up in the
process of reverse-engineering it and very kindly gave me. They are certainly fine for
this particular implementation, but I was just wondering what else there might be. Plenty
for LAT and CTERM, but I don't think I've stumbled over NRT.
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
3:14 a.m.
Hey. Thanks for those additions. Any machines on HECnet I can check against?
NFT under RSX have this wonderful functionality that seems to be missing
in all other implementations:
.nft venti2::/id
NFT -- Version V9.0
Local NFARs V8 DAP V7.1 Buffer size= 2064. OS=RSX-11M+ FS=FCS-11
DC=Yes
Remote FAL V2 DAP V5.6 Buffer size= 4096. OS=TOPS-20 FS=TOPS-20
DC=Yes
Johnny
On 2021-11-08 03:04, John Forecast wrote:
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On Nov 7, 2021, at 6:17 AM, Johnny Billquist
<bqt at softjar.se> wrote:
Thomas, I'm not sure where you got that list from.
It seems slightly mismatching what I can find. Looking at the NRT code in RSX (which uses
object 23, and is shared by code in RSX for connecting to both RSTS/E, VMS and Tops-20), I
find this:
1 RT-11
2 RSTS/E
3 RSX-11S
4 RSX-11M
5 RSX-11D
6 IAS
7 VMS
Those are the documented values for the configuration message that I can find.
However, extrapolating from this, in NFT/FAL, there is a much more extensive list, which
seems to align with this list, which contains:
8 TOPS-20
9 Tops-10
10 RTS-8
11 OS/8
12 RSX-11M-PLUS
13 COPOS/11 (TOPS-20 frontend)
14 P/OS
15 VAXELN
16 CP/M
17 MS-DOS
18 Ultrix-32
19 Ultrix-11
20 DTF/MVS
25 Windows NT
26 Linux
Now, Linux is a value I believe I added just based on observation, so it's much less
official. But I think all the other ones are ones DEC did assign. Unfortunately, I think
Windows NT was also added by me, based on observation of Pathworks. So I do not know what
the values between 20 and 25 could/should be.
The current version of DECnet for Linux I maintain on github uses 192 for Linux
which comes from the user-defined space so I could completely avoid any conflicts with
standard implementations. 22 was for MacOS (the original O/S for the 68K and PowerPC)
where DEC resold a third party implementation (Thursby I think). I don?t remember what we
used for DECnet-SCO but that was another official implementation.
John.
But maybe this helps some anyway?
Johnny
On 2021-11-07 11:23, Thomas DeBellis wrote:
Since its inception, Kermit-20 (one the first
three Kermit implementations) has had the 'limitation' that it will only talk to a
remote Kermit via a physical terminal line (I.E., something like TTY6:). It doesn't
do network terminals in part because it has no code to handle the out-of-band or meta-data
that one finds on TVT's (like IAC's) or CTERM's.
This doesn't exist for the early NRT terminals which were implemented for Tops-10 and
Tops-20. Once you've read the initial configuration message and decided what to do,
you basically never have to bother with meta-data. Because I'm trying to look at an
NFT issue between Tops-10 and Tops-20, I needed another transport mechanism and modifying
Kermit-20 to do DECnet 36 NRT's seemed like an easy hack. Since Tops-10 Kermit
isn't making an outgoing connection, it is none the wiser.
Thus far, it has been fairly straightforward. Right now I'm just catching the few
cases where certain operations don't make sense or otherwise wouldn't work (like
setting the terminal speed). Another thing I'd like to prevent is Kermit-20 bothering
non-36 bit systems. This is easily enough done by checking some 'magic' bits in
the initial configuration message and restricting by OS type. This raises two questions:
First, is the list below complete? What about Ultrix and ... what else?
1 RSTS 2 RT-11 3 RSTS/E 4 RSX-11S 5 RSX-11M
6 RSX-11D 7 IAS 8 VMS 9 TOPS-20 10 TOPS-10 11 RTS-8 12
OS-8 13 RSX-11M+ 14 MCB
Second, the configuration isn't well documented. Actually, I'm not sure if
it's documented, period. All I have is are some notes that Johnny wrote up in the
process of reverse-engineering it and very kindly gave me. They are certainly fine for
this particular implementation, but I was just wondering what else there might be. Plenty
for LAT and CTERM, but I don't think I've stumbled over NRT.
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
3:27 a.m.
There are a lot of features that I'd to lift from other NFT's and FAL's.
The problem is trying to do the modifications within the existing
architecture.? They've needed a number of modifications to fix bugs,
even to get them up to the point of stability, let alone have the
functionality that I've admired in the other implementations.? The FAL
source went from 25K to 44K of source for stability and debugging fixes,
but also required an additional module of about 98K for the enhancements
(such as ANONYMOUS).
NFT is in fact what I'm in the middle of trying to fix, but that source
is more difficult to work with, largely because it has a parser whereas
FAL didn't have one until I wrote it.
But I don't really like criticizing any of this, even when it does get
me peeved.? Development looks like it was stopped quite abruptly.? It's
almost as if the programmers were yanked away from their keyboards,
which I'm sure at least a few did not appreciate.
On 11/7/21 9:14 PM, Johnny Billquist wrote:
Hey. Thanks for those additions. Any machines on
HECnet I can check
against?
NFT under RSX have this wonderful functionality that seems to be
missing in all other implementations:
.nft venti2::/id
NFT -- Version V9.0
Local NFARs V8?? DAP V7.1 Buffer size=? 2064. OS=RSX-11M+ FS=FCS-11
DC=Yes
Remote FAL? V2?? DAP V5.6 Buffer size=? 4096. OS=TOPS-20 FS=TOPS-20
DC=Yes
? Johnny
On 2021-11-08 03:04, John Forecast wrote:
On Nov 7, 2021, at 6:17 AM, Johnny Billquist
<bqt at softjar.se> wrote:
Thomas, I'm not sure where you got that list from.
It seems slightly mismatching what I can find. Looking at the NRT
code in RSX (which uses object 23, and is shared by code in RSX for
connecting to both RSTS/E, VMS and Tops-20), I find this:
1? RT-11
2? RSTS/E
3? RSX-11S
4? RSX-11M
5? RSX-11D
6? IAS
7? VMS
Those are the documented values for the configuration message that I
can find.
However, extrapolating from this, in NFT/FAL, there is a much more
extensive list, which seems to align with this list, which contains:
8? TOPS-20
9? Tops-10
10 RTS-8
11 OS/8
12 RSX-11M-PLUS
13 COPOS/11 (TOPS-20 frontend)
14 P/OS
15 VAXELN
16 CP/M
17 MS-DOS
18 Ultrix-32
19 Ultrix-11
20 DTF/MVS
25 Windows NT
26 Linux
Now, Linux is a value I believe I added just based on observation,
so it's much less official. But I think all the other ones are ones
DEC did assign. Unfortunately, I think Windows NT was also added by
me, based on observation of Pathworks. So I do not know what the
values between 20 and 25 could/should be.
The current version of DECnet for Linux I maintain on github uses 192
for Linux which comes from the user-defined space so I could
completely avoid any conflicts with standard implementations. 22 was
for MacOS (the original O/S for the 68K and PowerPC) where DEC resold
a third party implementation (Thursby I think). I don?t remember what
we used for DECnet-SCO but that was another official implementation.
?? John.
But maybe this helps some anyway?
? Johnny
On 2021-11-07 11:23, Thomas DeBellis wrote:
Since its inception, Kermit-20 (one the first
three Kermit
implementations) has had the 'limitation' that it will only talk to
a remote Kermit via a physical terminal line (I.E., something like
TTY6:).? It doesn't do network terminals in part because it has no
code to handle the out-of-band or meta-data that one finds on TVT's
(like IAC's) or CTERM's.
This doesn't exist for the early NRT terminals which were
implemented for Tops-10 and Tops-20.? Once you've read the initial
configuration message and decided what to do, you basically never
have to bother with meta-data.? Because I'm trying to look at an
NFT issue between Tops-10 and Tops-20, I needed another transport
mechanism and modifying Kermit-20 to do DECnet 36 NRT's seemed like
an easy hack.? Since Tops-10 Kermit isn't making an outgoing
connection, it is none the wiser.
Thus far, it has been fairly straightforward.? Right now I'm just
catching the few cases where certain operations don't make sense or
otherwise wouldn't work (like setting the terminal speed). Another
thing I'd like to prevent is Kermit-20 bothering non-36 bit
systems.? This is easily enough done by checking some 'magic' bits
in the initial configuration message and restricting by OS type.?
This raises two questions:
First, is the list below complete?? What about Ultrix and ... what
else?
????? 1??? RSTS? 2??? RT-11? 3??? RSTS/E? 4??? RSX-11S? 5 RSX-11M
????? 6??? RSX-11D? 7??? IAS? 8??? VMS? 9??? TOPS-20 10 TOPS-10
11?????? RTS-8 12??? OS-8 13??? RSX-11M+ 14??? MCB
Second, the configuration isn't well documented.? Actually, I'm not
sure if it's documented, period.? All I have is are some notes that
Johnny wrote up in the process of reverse-engineering it and very
kindly gave me.? They are certainly fine for this particular
implementation, but I was just wondering what else there might be.
Plenty for LAT and CTERM, but I don't think I've stumbled over NRT.
--
Johnny Billquist????????????????? || "I'm on a bus
????????????????????????????????? ||? on a psychedelic trip
email: bqt at softjar.se???????????? ||? Reading murder books
pdp is alive!???????????????????? ||? tryin' to stay hip" - B. Idol
3:40 a.m.
On Nov 7, 2021, at 9:27 PM, Thomas DeBellis
<tommytimesharing at gmail.com> wrote:
There are a lot of features that I'd to lift from other NFT's and FAL's.
The problem is trying to do the modifications within the existing architecture.
They've needed a number of modifications to fix bugs, even to get them up to the point
of stability, let alone have the functionality that I've admired in the other
implementations. The FAL source went from 25K to 44K of source for stability and
debugging fixes, but also required an additional module of about 98K for the enhancements
(such as ANONYMOUS).
NFT is in fact what I'm in the middle of trying to fix, but that source is more
difficult to work with, largely because it has a parser whereas FAL didn't have one
until I wrote it.
But I don't really like criticizing any of this, even when it does get me peeved.
Development looks like it was stopped quite abruptly. It's almost as if the
programmers were yanked away from their keyboards, which I'm sure at least a few did
not appreciate.
After phase IV was completed most of the DECnet-Ultrix group was redirected to work on
DECnet-OSI (Phase V) which was a huge development - basically a reimplementation of
everything. The DECnet-RSX mostly moved on to other groups, thereb was no way to squeeze
Phase V onto a PDP-11.
John.
On 11/7/21 9:14 PM, Johnny Billquist wrote:
> Hey. Thanks for those additions. Any machines on HECnet I can check against?
>
> NFT under RSX have this wonderful functionality that seems to be missing in all other
implementations:
>
> .nft venti2::/id
> NFT -- Version V9.0
> Local NFARs V8 DAP V7.1 Buffer size= 2064. OS=RSX-11M+ FS=FCS-11 DC=Yes
> Remote FAL V2 DAP V5.6 Buffer size= 4096. OS=TOPS-20 FS=TOPS-20 DC=Yes
>
> Johnny
>
> On 2021-11-08 03:04, John Forecast wrote:
>>
>>> On Nov 7, 2021, at 6:17 AM, Johnny Billquist <bqt at softjar.se>
wrote:
>>>
>>> Thomas, I'm not sure where you got that list from.
>>>
>>> It seems slightly mismatching what I can find. Looking at the NRT code in RSX
(which uses object 23, and is shared by code in RSX for connecting to both RSTS/E, VMS and
Tops-20), I find this:
>>>
>>> 1 RT-11
>>> 2 RSTS/E
>>> 3 RSX-11S
>>> 4 RSX-11M
>>> 5 RSX-11D
>>> 6 IAS
>>> 7 VMS
>>>
>>>
>>> Those are the documented values for the configuration message that I can
find.
>>>
>>> However, extrapolating from this, in NFT/FAL, there is a much more extensive
list, which seems to align with this list, which contains:
>>>
>>> 8 TOPS-20
>>> 9 Tops-10
>>> 10 RTS-8
>>> 11 OS/8
>>> 12 RSX-11M-PLUS
>>> 13 COPOS/11 (TOPS-20 frontend)
>>> 14 P/OS
>>> 15 VAXELN
>>> 16 CP/M
>>> 17 MS-DOS
>>> 18 Ultrix-32
>>> 19 Ultrix-11
>>> 20 DTF/MVS
>>> 25 Windows NT
>>> 26 Linux
>>>
>>>
>>> Now, Linux is a value I believe I added just based on observation, so
it's much less official. But I think all the other ones are ones DEC did assign.
Unfortunately, I think Windows NT was also added by me, based on observation of Pathworks.
So I do not know what the values between 20 and 25 could/should be.
>>>
>> The current version of DECnet for Linux I maintain on github uses 192 for Linux
which comes from the user-defined space so I could completely avoid any conflicts with
standard implementations. 22 was for MacOS (the original O/S for the 68K and PowerPC)
where DEC resold a third party implementation (Thursby I think). I don?t remember what we
used for DECnet-SCO but that was another official implementation.
>>
>> John.
>>
>>> But maybe this helps some anyway?
>>>
>>> Johnny
>>>
>>>
>>> On 2021-11-07 11:23, Thomas DeBellis wrote:
>>>> Since its inception, Kermit-20 (one the first three Kermit
implementations) has had the 'limitation' that it will only talk to a remote
Kermit via a physical terminal line (I.E., something like TTY6:). It doesn't do
network terminals in part because it has no code to handle the out-of-band or meta-data
that one finds on TVT's (like IAC's) or CTERM's.
>>>> This doesn't exist for the early NRT terminals which were implemented
for Tops-10 and Tops-20. Once you've read the initial configuration message and
decided what to do, you basically never have to bother with meta-data. Because I'm
trying to look at an NFT issue between Tops-10 and Tops-20, I needed another transport
mechanism and modifying Kermit-20 to do DECnet 36 NRT's seemed like an easy hack.
Since Tops-10 Kermit isn't making an outgoing connection, it is none the wiser.
>>>> Thus far, it has been fairly straightforward. Right now I'm just
catching the few cases where certain operations don't make sense or otherwise
wouldn't work (like setting the terminal speed). Another thing I'd like to prevent
is Kermit-20 bothering non-36 bit systems. This is easily enough done by checking some
'magic' bits in the initial configuration message and restricting by OS type.
This raises two questions:
>>>> First, is the list below complete? What about Ultrix and ... what else?
>>>> 1 RSTS 2 RT-11 3 RSTS/E 4 RSX-11S 5 RSX-11M
>>>> 6 RSX-11D 7 IAS 8 VMS 9 TOPS-20 10 TOPS-10 11
RTS-8 12 OS-8 13 RSX-11M+ 14 MCB
>>>> Second, the configuration isn't well documented. Actually, I'm
not sure if it's documented, period. All I have is are some notes that Johnny wrote
up in the process of reverse-engineering it and very kindly gave me. They are certainly
fine for this particular implementation, but I was just wondering what else there might
be. Plenty for LAT and CTERM, but I don't think I've stumbled over NRT.
>>>
>>> --
>>> Johnny Billquist || "I'm on a bus
>>> || on a psychedelic trip
>>> email: bqt at softjar.se || Reading murder books
>>> pdp is alive! || tryin' to stay hip" - B. Idol
>>
>
3:32 a.m.
On Nov 7, 2021, at 9:14 PM, Johnny Billquist <bqt
at softjar.se> wrote:
Hey. Thanks for those additions. Any machines on HECnet I can check against?
Not that I know of at the moment. I?m just in the process of downsizing and moving. Once
that?s done I?ll be looking for access to HECnet.
John.
NFT under RSX have this wonderful functionality that
seems to be missing in all other implementations:
.nft venti2::/id
NFT -- Version V9.0
Local NFARs V8 DAP V7.1 Buffer size= 2064. OS=RSX-11M+ FS=FCS-11 DC=Yes
Remote FAL V2 DAP V5.6 Buffer size= 4096. OS=TOPS-20 FS=TOPS-20 DC=Yes
Johnny
On 2021-11-08 03:04, John Forecast wrote:
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On Nov 7,
2021, at 6:17 AM, Johnny Billquist <bqt at softjar.se> wrote:
Thomas, I'm not sure where you got that list from.
It seems slightly mismatching what I can find. Looking at the NRT code in RSX (which uses
object 23, and is shared by code in RSX for connecting to both RSTS/E, VMS and Tops-20), I
find this:
1 RT-11
2 RSTS/E
3 RSX-11S
4 RSX-11M
5 RSX-11D
6 IAS
7 VMS
Those are the documented values for the configuration message that I can find.
However, extrapolating from this, in NFT/FAL, there is a much more extensive list, which
seems to align with this list, which contains:
8 TOPS-20
9 Tops-10
10 RTS-8
11 OS/8
12 RSX-11M-PLUS
13 COPOS/11 (TOPS-20 frontend)
14 P/OS
15 VAXELN
16 CP/M
17 MS-DOS
18 Ultrix-32
19 Ultrix-11
20 DTF/MVS
25 Windows NT
26 Linux
Now, Linux is a value I believe I added just based on observation, so it's much less
official. But I think all the other ones are ones DEC did assign. Unfortunately, I think
Windows NT was also added by me, based on observation of Pathworks. So I do not know what
the values between 20 and 25 could/should be.
The current version of DECnet for Linux I maintain on github uses 192 for Linux
which comes from the user-defined space so I could completely avoid any conflicts with
standard implementations. 22 was for MacOS (the original O/S for the 68K and PowerPC)
where DEC resold a third party implementation (Thursby I think). I don?t remember what we
used for DECnet-SCO but that was another official implementation.
John.
> But maybe this helps some anyway?
>
> Johnny
>
>
> On 2021-11-07 11:23, Thomas DeBellis wrote:
>> Since its inception, Kermit-20 (one the first three Kermit implementations) has
had the 'limitation' that it will only talk to a remote Kermit via a physical
terminal line (I.E., something like TTY6:). It doesn't do network terminals in part
because it has no code to handle the out-of-band or meta-data that one finds on TVT's
(like IAC's) or CTERM's.
>> This doesn't exist for the early NRT terminals which were implemented for
Tops-10 and Tops-20. Once you've read the initial configuration message and decided
what to do, you basically never have to bother with meta-data. Because I'm trying to
look at an NFT issue between Tops-10 and Tops-20, I needed another transport mechanism and
modifying Kermit-20 to do DECnet 36 NRT's seemed like an easy hack. Since Tops-10
Kermit isn't making an outgoing connection, it is none the wiser.
>> Thus far, it has been fairly straightforward. Right now I'm just catching
the few cases where certain operations don't make sense or otherwise wouldn't work
(like setting the terminal speed). Another thing I'd like to prevent is Kermit-20
bothering non-36 bit systems. This is easily enough done by checking some 'magic'
bits in the initial configuration message and restricting by OS type. This raises two
questions:
>> First, is the list below complete? What about Ultrix and ... what else?
>> 1 RSTS 2 RT-11 3 RSTS/E 4 RSX-11S 5 RSX-11M
>> 6 RSX-11D 7 IAS 8 VMS 9 TOPS-20 10 TOPS-10 11 RTS-8
12 OS-8 13 RSX-11M+ 14 MCB
>> Second, the configuration isn't well documented. Actually, I'm not sure
if it's documented, period. All I have is are some notes that Johnny wrote up in the
process of reverse-engineering it and very kindly gave me. They are certainly fine for
this particular implementation, but I was just wondering what else there might be. Plenty
for LAT and CTERM, but I don't think I've stumbled over NRT.
>
> --
> Johnny Billquist || "I'm on a bus
> || on a psychedelic trip
> email: bqt at softjar.se || Reading murder books
> pdp is alive! || tryin' to stay hip" - B. Idol
3:28 a.m.
On 11/7/21 9:04 PM, John Forecast wrote:
The current version of DECnet for Linux I maintain on
github uses 192 for Linux which comes from the user-defined space so I could completely
avoid any conflicts with standard implementations.
About that, can you send a pointer? And is there a blurb in there
about how to get started? I'm currently maintaining an Ubuntu 12.04 VM
just as a bridge into and out of DECnet.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
3:47 a.m.
Look for JohnForecast/RaspbianDECnet on github.com <http://github.com/>.
README.Raspbian should tell you what to download and install. The BuildAndInstall script
will do everything for you but is explicitly targeted to the Raspberry Pi (Raspbian for
32-bit and PiOS for 64-bit systems). Due to family medical issues I?ve been unable to work
on this for the past year so no guarantee that it will work but I hope to get back to
working on it by the end of the year.
John.
On Nov 7, 2021, at 9:28 PM, Dave McGuire <mcguire
at neurotica.com> wrote:
On 11/7/21 9:04 PM, John Forecast wrote:
The current version of DECnet for Linux I
maintain on github uses 192 for Linux which comes from the user-defined space so I could
completely avoid any conflicts with standard implementations.
About that, can you send a pointer? And is there a blurb in there about how to get
started? I'm currently maintaining an Ubuntu 12.04 VM just as a bridge into and out
of DECnet.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
1108
days inactive
1111
days old
64 comments
13 participants
participants (13)
-
bob＠jfcl.com -
bqt＠softjar.se -
gregg.drwho8＠gmail.com -
healyzh＠avanthar.com -
ian＠platinum.net -
john＠forecast.name -
Keith.Halewood＠pitbulluk.org -
mcguire＠neurotica.com -
paulkoning＠comcast.net -
roll＠stupi.com -
supratim＠riseup.net -
tommytimesharing＠gmail.com -
tony.nicholson＠computer.org