26 Aug
2020
26 Aug
'20
10:50 p.m.
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.