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