On Nov 4, 2018, at 11:37, Johnny Billquist <bqt at
softjar.se> wrote:
Ok. A bit what I suspected, but annoying that a copy of information will overwrite
information that is not carried in the update from MIM. Oh well, not much we can do about
that detail.
Anyway, sounds like your script would be useful for others...
Johnny
On 2018-11-04 17:21, Steve Davidson wrote:
If a node is defined in both places (like a cluster member) the copy will overwrite key
information that the boot node needs. This can also happen with decservers that are
defined in both places. Netupdate does NOT modify nodes in the local area to prevent such
problems. In fact it notifies the user that it is skipping the local area. It presumes
that the local user has made their own definitions for their area.
This issue has burned me bad in the past thus NETUPDATE was created. Also this can be
submitted to batch. In my case it is run whenever my systems get your notification email.
Pretty much automatic!
-Steve Davidson
Sent from my iPhone
> On Nov 4, 2018, at 10:32, Johnny Billquist <bqt at softjar.se> wrote:
>
> Do you know in which way, and why they would be corrupted? As far as I understood
things, this should only copy over node definitions from MIM, but not change anything that
is not touched by the node information from MIM. So other node names should not get any
troubles.
> Not entirely sure about what happens to existing nodes, but I would have hoped they
would still have the additional information that might have been there untouched as well.
>
> I do create a
FIX.COM command file as well, and in the past that script was doing too
much. It might still get you into trouble if you have other type of information in your
local database, so I would be careful with that script. But I'm also open to
suggestions for improvements for it.
>
> Johnny
>
>> On 2018-11-04 16:05, Steve Davidson wrote:
>> Be careful of "ncp copy known nodes". Cluster nodes and DECserver
nodes can become corrupted with this command. That is why I wrote
netupdate.com
>> -Steve
>>>> On Nov 4, 2018, at 09:54, Johnny Billquist <bqt at softjar.se>
wrote:
>>>>
>>>> On 2018-11-04 14:59, supratim sanyal wrote:
>>>> Hi Douglas,
>>>> Great, I will mark port 60004 as allocated to you.
>>>> One reason for TCP is it does not require Johnny to go change the IP
address on his end every time a residential ISP IP address changes.
>>>
>>> Which is not maybe that relevant in a link between you two... The VMS
Multinet do not appear to be as flexible in configuring peers, so you might need to
restart if addresses change anyway. But yes, for the RSX Multinet-compatible links, the
active end can change IP address without me having to do anything on my side. TCP also
have the advantage to better handle if packets might be dropped, which can be an issue
over long haul links, as well as better match what these Multinet links pretend to be to
DECnet, which are DDCMP links. But the VMS implementation seems to be cheating in several
ways, making it look funny at times, so it might not matter much from that point.
>>>
>>> Also, TCP is easier if you have firewalls or NAT. UDP can also be made to
work, but is usually a little more complicated here.
>>>
>>>> Does ?MCR NCP COPY KNOWN NODES FROM MIM TO BOTH? not work to copy over
node db from MIM?
>>>
>>> It should work for him, once he have MIM defined.
>>>
>>>> I also run a neat command file by Steve Davidson that I found somewhere
(maybe on MIM or STRGTE) which I am attaching ? it runs on SYS$BATCH and updates local
node db automatically. The .XCOMX extension should be .COM, psilobyte rejects .COM file
attachments.
>>>
>>> I could also mention that I have an automated system that sends mails when I
update the nodename database, in case anyone would want such a thing. If you are creative,
you set things up so that script is run automatically when such a mail is received.
>>>
>>> Johnny
>>>
>>>> Best,
>>>> Supratim
>>>> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for
Windows 10
>>>> *From: *Douglas Hall <mailto:dhall.hecnet at dhcl.co.uk>
>>>> *Sent: *Sunday, November 4, 2018 07:57
>>>> *To: *hecnet at Update.UU.SE <mailto:hecnet at Update.UU.SE>
>>>> *Subject: *Re: [HECnet] Multinet connection in UK
>>>> On Sun, 4 Nov 2018, at 11:19, supratim sanyal wrote:
>>>> If you wish you can run an experiment with IMPVAX (VA, USA); I have
>>>> heard trans-Atlantic loop latencies are not as bad as one might
>>>> think. TCP only, Something like this in
DECNET-CIRCUITS.COM should
work:
>>>> $ multinet set /decnet /remote=52.23.221.223 /port=60000
>>>> /device=tcpa0: /connect /tcp=connect /buffers=24
>>>> That looks to be working OK. It's very bursty to some locations, e.g.
BOPOHA, but connectivity is connectivity. Thanks! Out of interest, what is reason for
using TCP as the underlying transport protocol instead of the default? I've
configured the link with a reasonably high cost in case I make another connection
somewhere more local.
>>>> This is my first experience with DECnet over more than a few local nodes,
is there an easy way to get a full node list onto my systems?
>>>> This all takes me back a while. Last commercial VMS/DECnet systems I used
were back in 1994. I actually stumbled across hecnet whilst trying to find out if anyone
still used uucp for anything. I was the last sysadmin of the UKNET uucp setup, then
managed by PSINet before we finally dismantled all that infrastructure in 1999.
>>>> Douglas
>>>
>>> --
>>> Johnny Billquist || "I'm on a bus
>>> || on a psychedelic trip
>>> email: bqt at softjar.se || Reading murder books
>>> pdp is alive! || tryin' to stay hip" - B. Idol
>
> --
> Johnny Billquist || "I'm on a bus
> || on a psychedelic trip
> email: bqt at softjar.se || Reading murder books
> pdp is alive! || tryin' to stay hip" - B. Idol
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol