Network Object Unknown at Remote node

[EEnhcw]

I have two systems, one I will call PRI, and the second AUX.

PRI is running OpenVMS Alpha V8.3 while AUX is running OpenVMS Alpha V7.2-2. They are both running DECnet Phase V.

On both PRI and AUX I have send and receive processes.

If I start the Send process on PRI, it correctly starts the receive process on AUX. PRI connects to AUX and uses "DECNET_RECV" as the object to start. If I run NCL and do this:

NCL>sho session control application decnet_recv all

This is the output:

Node 0 Session Control Application DECNET_RECV
at 2010-01-06-11:46:39.689-08:00Iinf

Identifiers

Name = DECNET_RECV

Status

Process Identifiers =
{
}
UID = A54C72D8-E332-11DE-83DC-AA0004006306

Characteristics

Client =
Addresses =
{
name = DECNET_RECV
}
Outgoing Proxy = True
Incoming Proxy = True
Outgoing Alias = False
Incoming Alias = True
Node Synonym = True
Image Name = DSA1:[AUX.FURN.LINK.PRI]DECNET_RECV.EXE
User Name =
Incoming OSI TSEL =
OutgoingAlias Name =
Network Priority = 0

Counters

Creation Time = 2009-12-07-12:15:52.881-08:00Iinf

However, when I start the send process on AUX it does not start the receive process on PRI. The name from AUX to PRI is L2AXRECV. Doing this:

NCL>sho session control application l2axrecv all

Returns:

Node 0 Session Control Application L2AXRECV
at 2010-01-06-11:54:14.829-08:00Iinf

Identifiers

Name = L2AXRECV

Status

Process Identifiers =
{
}
UID = 71AD41D1-FABC-11DE-AE2D-0062B0158E0

Characteristics

Client =
Addresses =
{
name = L2AXRECV
}
Outgoing Proxy = True
Incoming Proxy = True
Outgoing Alias = False
Incoming Alias = True
Node Synonym = True
Image Name = DSA1:[ATM_LV2.lnk]L2AXRECV.exe
User Name =
Incoming OSI TSEL =
OutgoingAlias Name =
Network Priority = 0

Counters

Creation Time = 2010-01-04-12:13:12.767-08:00Iinf


When the send process dies on AUX this is the error that is generated:
%SYSTEM-F-NOSUCHOBJ, network object is unknown at remote node

On PRI, the net$server.log prints out:

--------------------------------------------------------

Connect request received at 6-JAN-2010 12:18:19.23
from remote process AUX::"0=UPI_VAX"
for object "L2AXRECV"

--------------------------------------------------------

The difference in the printout for net$server.log on AUX is that it has the resolved object name for "DECNET_RECV" as shown below:

--------------------------------------------------------

Connect request received at 6-JAN-2010 12:15:14.39
from remote process PRI::"0=UPI_VAX"
for object "DSA1:[AUX.FURN.LINK.PRI]DECNET_RECV.EXE"

--------------------------------------------------------


An important note that I haven't mentioned is that PRI was just recently upgraded from Alpha V7.2-2 to V8.3 and this process hasn't worked since the upgrade.

[Volker Halle]

EEnhcw,

welcome to the OpenVMS ITRC forum.

the object name im NET$SERVER.LOG should be the image name.

Is the image name specification correct ? Does the account, under which the DECnet object L2AXRECV is supposed to run, able to access the image file ?

Try REPLY/ENABLE and repeat the test. Any further DECnet or SECURITY related OPCOM messages ?

Does a DIR PRI:: correctly work from AUX ?

Volker.

[EEnhcw]

Volker,

Thanks for the response.

REPLY/ENABLE came up with the same result.

The image name specification in NCL is correct:

Image Name = DSA1:[ATM_LV2.lnk]L2AXRECV.exe

The connection is attempted as seen by the NET$SERVER.LOG. I think the key is that the name is not being resolved correctly. "L2AXRECV" should be resolved to the above image name and is not.

DIR PRI:: does correctly work from AUX.

[Jan van den Ende]

EEnhcw,

well, to me it has all the of the DECNET_REC logical name not being seen by your network process.

My brute-force test for this would be (at the failing remote node!)

DEFINE/SYSTEM/EXEC/NOALIAS L2AXRECV DSA1:[AUX.FURN.LINK.PRI]DECNET_RECV.EXE

Do a DIR L2AXRECV to verify correct spelling and presence of the file!

/NOALIAS will prevent any potential redefine to not function.

If remote access DOES function now, remove the /NOALIAS and try again.
If no longer functioning, check WHERE in the network login procedures it gets mis-defined.

If it continues functioning, remove the systemwide define, and add a
SHOW LOG L2AXRECV to the beginning of SYS$SYLOGIN and also to the end of the LOGIN.COM for the account that does the network side of the connection.
I bet this will clarify a lot!

Good hunting.

Proost.

Have one on me.

jpe

[EEnhcw]

Thanks for the response.

L2AXRECV is the Session Control Application on PRI which points to the image name

Image Name = DSA1:[ATM_LV2.lnk]L2AXRECV.exe

DECNET_RECV is the Session Control Application on AUX which points to the image name

Image Name = DSA1:[AUX.FURN.LINK.PRI]DECNET_RECV.EXE


Is setting up a logical for L2AXRECV necessary? I thought that the definition of L2AXRECV as a Session Control Application in NCL is what was needed.

For example if I do a SHOW LOGICAL DECNET_RECV on AUX it returns:

%SHOW-S-NOTRAN, no translation for logical name DECNET_RECV

However, the name is resolved correctly and the process starts as it should on AUX.

[Volker Halle]

It is not necessary to define a logical pointing to the image to be activated.

You could still give it a try by defining a logical L2AXRECV to point to the correct image on PRI.

Are you current on patches (DECnet-OSI V8.3 ECO 3) - although there is nothing in the release notes, which sounds similar.

Which account is being used on the network receive side on PRI ? Same account as with DIR PRI:: from AUX ?

Volker.

[EEnhcw]

Defining the logical still produces the same result.

I am not up to date on the current patches.

The same account is being used on both sides, same as with the DIR PRI:: from AUX.

[Volker Halle]

Most DECnet objects (= session control applications) are being connected to by using the object number. Check all your objects on PRI and try to connect to any other objects which are specified by name - does it work ?

Try to create a small test session control application and try to connect to it by using it's name.

As a first step, consider to install the most recent DECnet-OSI ECO.

Volker.

[Volker Halle]

Look at all our session control applications on node PRI. Is there any unusual object ?

NET$ACP needs to examine the incoming NCB (Network Connect Block) and find the named object (aka session control application).

Consider to use the TRACE (CTF) utility to capture the incoming connect and look at the contents of the NCB for the object name.

Volker.

[EEnhcw]

Thanks for the responses.

I haven't tried these suggestions yet but here's a little update. I noticed that PRI is attempting to execute L2AXRECV.COM in the root directory from the unresolved object "L2AXRECV". I created a L2AXRECV.COM in the root directory that starts the correct executable.

This works to start the process. The process name that gets started is TASK_14010021. I was expecting to see something more like this "L2AX_14010021".

Like with AUX, DECNET_RECV corresponds to DECNET_140600C3.

This works to start the process but is not desired. Does this point to anything in particular that could be wrong?