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.