Yeah, that's what I found out, too. On Tops-20, the CTERM client is called CTERM-SERVER (don't ask) whereas the NRT client is called SETHOST.? SETHOST is /quite/ old and I had been hacking it for efficiency and fixing a few bugs. It now has an alternate debugging entry to try to force Tops-20 NRT (which will also work on Tops-10) and ignore the remote node type until it can't proceed any further.? Here are the results from my own tests; they indicate that a CTERM (server) object does not exist on ELVIRA. I'm not sure, but I had thought that CTERM had not been done on RSTS/E. !cterm-sERVER.EXE.2 elvira [Attempting a connection, _CTERM Connect failed - Destination process does not exist_ !g ds:sethost !ree Escape character(^Y): Host name: ELVIRA:: [Connecting to remote host: ELVIRA] _?RSTS/E type systems do not support Tops-20 NRT communications._ On 8/25/20 8:09 PM, Paul Koning wrote: > John, > > Some systems, like VMS, will use CTERM by default, and there isn't > a CTERM listener on RSTS.? So you have to tell it to use the "old > protocol", whatever that involves on your OS. > > ????paul > >> On Aug 25, 2020, at 7:24 PM,jy at xtra.co.nz? wrote: >> >> Hi Thord, >> >> Congratulations, I can see you're up at: >> >> http://akdesign.dyndns.org:8080/map/data >> >> I just tried a set host elvira and set hsot 59.53 but I'm getting >> "network object unknown at remote node". >> >> Cheers, John >> >> >> >>> On 26 August 2020 at 11:14 Thord Nilson<thordn at gmail.com>? wrote: >>> >>> Hi all! >>> Update! >>> Basic connections are now working,? so for a limited time you can: >>> set host elvira:: >>> login as 99,99 psw: testing >>> Nothing much to see though. >>> Thanks to all for your help! >>> >>> /Thord.

On 8/26/20 4:40 PM, Johnny Billquist wrote: > Let me put it this way. If any tool causes you any problems, first > check if there is something newer on MIM, and if so - grab and test > that. > If not, let me know, and I can probably fix it. ?? I'm sure I speak for all of us here when I say THANK YOU for this.

> And while I'm on it. At the moment there is a long standing bug in > NICE on RSX, which have been annoying me slightly for a long time, > but which is now starting to become serious enough that I need to > look deeper into it. If you do a "NCP TELL MIM SHOW KNOWN NODES" > the list is incomplete. If you look carefully, some nodes are > missing, which will be there, if you explicitly ask for them. > > This becomes a larger problem because if someone on a VMS system > does an "NCP COPY KNOWN NODES FROM MIM ..." they will not be > getting the full list either. And the same goes for RSX users using > NNC to copy the known nodes from MIM. ?? Ah-HA!!? I have seen exactly this.? I thought I was losing my mind.

Happy to announce that I have found and fixed the bug in the DECnet code in RSX that could cause operations like "SHOW KNOWN NODES" to skip some nodes under some circumstances. So anyone getting node definitions from MIM can now safely do that using NCP (in VMS), or NNS (in RSX) and be sure they do get the complete list. For anyone using RSX, this is another component you want to update. The file in question is [5,54]NMVACP.TSK, and you can copy it from MIM:: Place it in that directory, and you're good after the next reboot. If you want it fixed on your running system, then after copying the file over, do the following two lines: REM NMVACP INS LB:[5,54]NMVACP and then you are good. If anyone wants to know itty gritty details on the bug, let me know and I can explain it. But suffice to say for now, that this bug was introduced with the nodename server in RSX, which I think only came in M+ V4.6. ?? Johnny On 2020-08-27 02:16, Johnny Billquist wrote: > On 2020-08-27 01:47, Dave McGuire wrote: >> On 8/26/20 4:40 PM, Johnny Billquist wrote: >>> Let me put it this way. If any tool causes you any problems, >>> first check if there is something newer on MIM, and if so - grab >>> and test that. >>> If not, let me know, and I can probably fix it. >> >> ?? I'm sure I speak for all of us here when I say THANK YOU for >> this. > > The thing is - some of the bugs and issues I've worked on are > rather obscure. You might occasionally observe there is something > funny going on, but understanding where the problem is, and > finding the fixed file on MIM is not always so easy, nor how to > apply it. > > Take MCR, for example. There are multiple things I've fixed. Both > in MCR... and ...MCR (they are two different things). And applying > them needs that you update things through VMR. Can't be done on a > running system. (Well, ...MCR can, but MCR... cannot.) > > My TCP/IP package already does that patch for you however, so you > should be good. > > Hey, here is something for people to look at, to make you aware of > things you might be interested in: MIM::US:[BQT]FIX.TXT contains > all the work I've been doing for a possible future V5.0 release of > RSX-11M-PLUS. > A lot of those fixes apply just fine also for V4.6, but don't ask > about the subdirectory stuff. That is just too complex to patch > up, and there are still a couple of corners I'm not done with. > >>> And while I'm on it. At the moment there is a long standing bug >>> in NICE on RSX, which have been annoying me slightly for a long >>> time, but which is now starting to become serious enough that I >>> need to look deeper into it. If you do a "NCP TELL MIM SHOW >>> KNOWN NODES" the list is incomplete. If you look carefully, some >>> nodes are missing, which will be there, if you explicitly ask >>> for them. >>> >>> This becomes a larger problem because if someone on a VMS system >>> does an "NCP COPY KNOWN NODES FROM MIM ..." they will not be >>> getting the full list either. And the same goes for RSX users >>> using NNC to copy the known nodes from MIM. >> >> ?? Ah-HA!!? I have seen exactly this.? I thought I was losing my >> mind. > > Well, now you know you aren't. :-) > > ?? Johnny >