topic Re: DECnet address change leads to SET HOST problem in Operating System - OpenVMS

DECnet address change leads to SET HOST problem

Galen Tackett — Thu, 09 Jun 2005 09:34:05 GMT

Yesterday I changed the DECnet address of a V7.3-1 system and then ran into problems with SET HOST. All other things that use DECnet(FAL, NML, SMISERVER,...) seem to work okay going both in and out to other nodes.

There are three nodes involved, A, B, and G. Before yesterday they were all in area 19. Yesterday I moved G into Area 53. There is a Cisco router with DECnet in between these two areas. A, B, and G are all nonrouting Phase IV.

I had a good bit of difficulty getting SET HOST to work at all, going in our out of G. Even restarting DECnet didn't help. (And yes, I changed G's address in their DECnet permanent and volatile databases.)

Eventually I just rebooted all three. After that, SET HOST worked between all three in both directions EXCEPT from B to G.

Since SET HOST (CTERM) is the only DECnet application that is having problems, and only in one direction between just two nodes, I think we can rule out routing problems or DECnet on G having "SET NODE B ACCESS NONE".

Anything else come to mind?

Re: DECnet address change leads to SET HOST problem

Galen Tackett — Thu, 09 Jun 2005 11:29:35 GMT

Oops. I forgot to mention that the error message I'm getting is "%SYSTEM-F-SHUT."

Of course, G really is accepting SET HOST connections from everyone but B (see o.p.)

Re: DECnet address change leads to SET HOST problem

Ian Miller. — Thu, 09 Jun 2005 14:26:58 GMT

Have you done
$ NCP SHOW REMOTE NODE
to check the access on G? I know you mentioned it but

Re: DECnet address change leads to SET HOST problem

Mobeen_1 — Thu, 09 Jun 2005 14:34:13 GMT

Galen,
I think i faced a similar situation few years back and i faintly remember ....

Probably i got around the situation like yours by deleting and then creating the defintions for the nodes having problem either side using the DECNET CONFIG MENU

regards
Mobeen

Re: DECnet address change leads to SET HOST problem

Galen Tackett — Fri, 10 Jun 2005 06:11:41 GMT

Ian,

Thanks for the reminder about checking NCP's settings on G for incoming access from B.

I may not have looked at it because copying a file over DECnet from B to G worked, and I assumed that ruled out having NODE B ACCESS NONE on G. Still, I should check just to be thorough. I'll e-mail that site and have them take a look. (I'll also be there myself on Monday.)

Mobeen,

I hadn't tried actually doing a purge and clear on the DECnet entries for the nodes involved. It's probably worth a shot, which I'll do on Monday unless the guys on site find something first.

Thanks,

Galen

(Points to follow when problem fixed.)

Re: DECnet address change leads to SET HOST problem

Mobeen_1 — Fri, 10 Jun 2005 06:37:16 GMT

Galen,
Just to give you a heads up, in our case i remember that when we delete and purge and create definitions for the nodes with problem on Decnet database, it used to just work fine the first time....

That is we would be able to "Set h" without any issues for the first time and any subsequent set h would fail. I hope it is not the same in your case :)

Will wait for you to give this a try and let us know how things fare

regards
Mobeen

Re: DECnet address change leads to SET HOST problem

Veli Körkkö — Mon, 13 Jun 2005 13:45:12 GMT

So, do still have A and B in area 19 but G in area 53? And there is a router somewhere?

If there is a router in say area 19, there should also be a router in area 53 and those routers should be handling cross-area stuff!

If there are NO ROUTERS at all, traffic will however work even across areas.

Even if there is just ONE router around, traffic may appear to work since your systems are end nodes and have endnode cache.

I would verify that each node correctly knows each other, i.e.

$ mcr ncp show node X

as well as routing stuff,

$ mcr ncp show known circuits

Obviously nodes in same area should see same router as the designated router and all involved nodes should see some routers

You say there is A CISCO ROUTER. I would read this as "there is a single router box" but the setup classically would require at least two router boxes (one for area 19, another for area 53).

Does the cisco box do some fancy NAT stuff?

_veli

Re: DECnet address change leads to SET HOST problem

Galen Tackett — Tue, 14 Jun 2005 04:43:16 GMT

Veli,

You wrote:

You say there is A CISCO ROUTER. I would read this as "there is a single router box" but the setup classically would require at least two router boxes (one for area 19, another for area 53).

It's been a very long time since I worked with Cisco routers myself--roughly since 1996. My memory is a bit foggy, but isn't it possible for a Cisco router to run one DECnet area on one interface, and another area on a different interface?

I will have to ask the site staff here if they know anything about this...

Also, you understand correctly that we have just one router.

Re: DECnet address change leads to SET HOST problem

Galen Tackett — Tue, 14 Jun 2005 06:05:56 GMT

Ian takes home the prize on this one. Thanks!

On both B and G I did an NCP SHOW NODE other_node CHARACTERISTICS

On G I got back just the node name and address of B.

On B I got back G's node name and address, PLUS "Access = Incoming and Outgoing".

So I looked at the executor characteristics on G and found that its default access was set to NONE.

This told me that I needed to do the following on G:

NCP>SET NODE B ACCESS BOTH

and that fixed it.

I examined the node and executor access settings on these three nodes and found some apparent inconsistencies. I'll have to ask the guys here about that, since I don't know what reasons there may have been for this arrangement. Quite possibly it is just an accident.

If anything else interesting turns up within the next week or so, I'll follow up in this topic.

Re: DECnet address change leads to SET HOST problem

Galen Tackett — Mon, 20 Jun 2005 04:51:42 GMT

As explained by previous discussion in this thread, the problem was caused by G having "DEFAULT ACCESS NONE" in its executor characteristics, and was fixed with a simple

NCP>SET NODE B ACCESS BOTH

on G.

It's a bit embarrassing that as longtime manager of DECnet I didn't spot this right off. :-}