[HECnet] Configuring py-decnet --> patches

Wed Aug 26 13:50:14 PDT 2020

Only some of them don't show up?  Boy, that sure would drive me nutz!

I have a batch job which fires up weekly and pulls down FIX.T20 from 
MIM.  If a connection can't be made, then it whines and tries again 
after a while.  The file is downloaded and changes are documented with a 
file comparison (FILCOM).  It is then converted into an internal format 
by SETNOD and loaded into the monitor

A planned future enhancement is to compute the set difference; that is, 
remove nodes from the monitor database which are no longer defined.  I 
had stumbled over what appears to be undocumented way to do this while 
implementing other functionality; but it needs application logic to do 
the set difference.

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.
>
> 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.
>
> A workaround for the time being is that you can grab 
> MIM::HECNET:FIX.COM or FIX.CMD (or FIX.T20) to just get a script to 
> apply to get the proper definitions into your machine. I can create 
> more files with other details/syntax/fluff as needed as well, if 
> people just let me know.
>
> (For RSX, feed FIX.CMD into CFE.)
>
>   Johnny
>
> On 2020-08-26 22:14, R. Voorhorst wrote:
>> L.S.
>>
>> You a true altruistic wonder these days to have around :)
>>
>> A king, sitting on his coffers chockfull of goodies, waiting to 
>> dispense them lavishly among the lesser endowed fellow users ....
>> Usually with kings it is the other way around as can be seen so often 
>> today.
>> Are the other set host varieties on MIM also endowed with workable 
>> patches?
>>
>> We'll play copycat then, ... until better times will arrive.
>>
>> Thanks ever so much,
>>
>> Reindert
>>
>> -----Original Message-----
>> From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On 
>> Behalf Of Johnny Billquist
>> Sent: Wednesday, 26 August, 2020 22:02
>> To: hecnet at Update.UU.SE
>> Subject: Re: [HECnet] Configuring py-decnet.
>>
>> Aw, shit! (Excuse my language.)
>>
>> I had more or less forgotten. Yes, as distributed, it has a bug. I 
>> have fixed it, but of course, noone else have that.
>>
>> For now, the simple solution, pick MIM::DU:[5,54]RRS.TSK, and you'll 
>> be good.
>>
>> Sigh! I really hope the whole DEC/Mentec/HP ownership mess can be 
>> sorted one day. I have about 100 fixes or improvements to RSX sitting...
>>
>>     Johnny
>>
>> On 2020-08-26 21:57, R. Voorhorst wrote:
>>> L.S.
>>>
>>>
>>> Is there something different with patch levels or otherwise?
>>>
>>> After successful login on Rsts 10.1:
>>>
>>> $ logout
>>> SAVED ALL DISK FILES ON SY: 6784 BLOCKS IN USE JOB 7 USER 1,2 LOGGED
>>> OFF KB24: AT 26-AUG-20 21:53
>>> 6 OTHER USERS STILL LOGGED IN UNDER THIS ACCOUNT SYSTEM RSTS V10.1-L
>>> RSTS/E V10.1 RUN TIME WAS .2 SECONDS ELAPSED TIME WAS 1 MINUTE GOOD
>>> EVENING
>>>
>>>
>>>
>>>
>>>
>>>
>>> SWBU01::RRS -- Remote disconnect
>>>
>>> SWBU01::RRS -- Control returned to node SWBU01::
>>>           MOV     #20,R0
>>> EM:065126
>>> XDT>
>>>
>>>
>>> Best regards,
>>>
>>> Reindert
>>>
>>> -----Original Message-----
>>> From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On
>>> Behalf Of Johnny Billquist
>>> Sent: Wednesday, 26 August, 2020 15:09
>>> To: hecnet at Update.UU.SE
>>> Cc: Thord Nilson <thordn at gmail.com>
>>> Subject: Re: [HECnet] Configuring py-decnet.
>>>
>>> And to complement the picture a little more. On RSX, you need a 
>>> program called RRS, which is provided among the "unsupported 
>>> utilities" in the DECnet distribution.
>>>
>>> .rrs elvira
>>> MIM::RRS -- Connection established to node ELVIRA::
>>>
>>> RSTS V10.1-L 26-Aug-20 14:41
>>> User: 99,99
>>> PASSWORD:
>>>
>>> LAST INTERACTIVE LOGIN ON 26-AUG-20, 02:36    AT KB21:
>>>
>>>
>>> $
>>>
>>>
>>>      Johnny
>>>
>>> On 2020-08-26 02:19, Thomas DeBellis wrote:
>>>> 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.
>>>
>>
>