set host node and dir node:: coming up with

[Karen Harte]

Hello,

Has anybody had any experience with VMS V7.3-1 and decnet where you can perform a set host 0 and it works but you cannot do a set host to the actual node itself i.e. the node you are on or do a dir node "username password"::[000000] - you get a "remote node is currently unreachable" message. This is affecting All-in-1 because the File cabinet server cannot start.

You can set host to other systems .

Any help would be much appreciated .
Many Thanks,

Karen Harte

[Ian Miller.]

So SET HOST 0 works but SET HOST thisnode does not?

Could it be that the name translates to the
incorrect address?

DECnet IV or DECnet/Plus?

[Karen Harte]

HI Ian,

I think it's phase IV as it hasn't been upgraded for years and it says Decnet-OSI for OPenVMS when I check in NCP.

Also I have found that I can set host to 2051 , which is the host number 2.3 resolved into hexadecimal .

Any ideas ?

Many Thanks,

Karen Harte

[Marc Van den Broeck]

Karen,

In ncp
ncp> show exec char
What is displayed as executor node? (address and name)

and what does

ncp> show node thisnode

give?

Rgds
Marc

[Joseph Huber_1]

As Ian wrote, it maybe a simple name-to-address error.
If DECNET IV, check if
ncp show node nodename
shows the same address as
ncp show executor

If DECNET V (decnet plus):
use decnet_register to check the nodes address

Which name-services are enabled ?
If DOMAIN is in the list , is the TCPIP service for PWIP driver enabled and started ?
Does it make a difference if You do
set host name::
set host local:.name::
set host name.my.domain:: ?

[Joseph Huber_1]

Our replies crossed ...

DECNET OSI means DECNET V,
so my questions on the naming services used apply !

[Volker Halle]

Karen,

it's DECnet/OSI resp. DECnet-Plus. The problem seems to be with name to address translation.

Try to clear the naming cache (DECnet name to address translation cache)

$ MC NCL flush sess control naming cache entry "*"

Then there's also a possibility that there is a logical name on your system with the actual nodename, whose translation points somewhere else.

Volker.

[Karen Harte]

Hi Marc,

show exec char gives :
Executor node = 2.3 (hugh)
The main items are :
identification = DECNET - OSI for OpenVMS
Management version = v4.0.0
NSP version = V4.1.0
Routing version = V2.0.0
Type = nonrouting IV
Path Split Policy = normal

everything else is set to 0.

and show node hugh in NCP gives
Executor node = 2.3 (hugh)
State = on
identification = Decnet - OSI for OpenVMS


It is very strange as this has been working
for years and then on Monday it stopped. No major work has been carried out on the networks which might have caused this to happen.

Very strange.

Might it be something to do with caches getting filled up and needing flushed as a colleague of mine suggested this from a problem she experienced a few years ago on a similar system but she hasn't got the notes any more ?

This would tie in maybe with something building up over time and then reaching a limit.

Many Thanks,

Karen Harte

Karen

[Joseph Huber_1]

Karen, You seem to still think in Decnet IV only with the NCP command, but with Decnet V , NCL is the network control (NCP only translates, and only some commands).
Volker told You how flush the nameing cache.
If that does not help , then it really is necessary to find out which naming scheme is in use: local Decnet or (TCP/IP) domain.

Use "ncl show session control all" to see which ones, and in which order names are resolved.
Since apparently the set host nodenumber works,
try also to set set protocol preference to decnet IV:
ncl set session control transport precedence = (nsp,tp4)

If the local and decnet IV naming works, then Your problem is on the TCPIP DNS side.

[Karen Harte]

Hello Volker,

Thanks for that as this has fixed the problem !

The All-In-1 File cabinet Server is now running once I did the flush session command.

Many Many Thanks to everybody who has replied.

Karen Harte