[HECnet] Is this the most up to date version of DECnet OS numbers?
Thomas DeBellis
tommytimesharing at gmail.com
Sun Nov 7 15:40:24 PST 2021
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.
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sonic.net/pipermail/hecnet-list/attachments/20211107/692b178b/attachment-0001.htm>
More information about the Hecnet-list
mailing list