| OBB appears to pass node names back and forth. For example, I recently
had a customer who had a client node with both DECnet and TCP/IP
enabled as the transports. On their server, the only had DECnet
enabled.
They had configured their client so that TCP/IP would be the first
protocol OBB would try to use (this is not the default, but can be
done) when connecting to a remote implementation server.
We were having some problems getting them to talk (understatement) so I
was running traces on both sides...I would see the client try to make
the outbound connection via TCP/IP and failover to DECnet. So far so
good. On the server side, we would not get by the DEC/EDI
authentication until we added an entry for the fully specified IP node
name. Once we did this, we got server errors. Looking in the TRACE of
the IMF, I saw that when the server was trying to place its callback to
the client, it was using the IP nodename (fully specified in lower
case) to try to make the DECnet connection.
The nodename as it appeared in the log was not defined anywhere on the
server except in DEC/EDI (where we had been forced to add it to get
past authentication)...so I started casting about and eventually
noticed that the nodename being used was the same node name listed when
we did a SHOW AGENT on the client side.
We were able to correct the problem by having the customer change their
OBB configuration to the default...IE, try DECnet first. Once we did
this a SHOW AGENT on the client would display the DECnet node name, not
the full IP node name. Another trick I have found that works when
trying to figure out what node name the server will use to validate a
(VMS) client is to do a SHOW LOGICAL UCX$INET* on the client system
and concatenate the UCX$INET_HOST and UCX$INET_DOMAIN strings to get
the full nodename.
After going through this fiasco, I would recommend enabling both
transports only if you need both transports. Otherwise, if you want to
use DECnet as the transport, use the DECnet only OBB configuration. If you
want to use TCP/IP as the transport, use the TCP/IP only OBB configuration.
If you have to use both, take some pain killers first...preferrably with
alcohol.
For my customer this was not an option (they were using OBB via TCP/IP
for other applications on the client but were unable to use TCP/IP on
the server node due to difficulties with the protocol stack there) so
we had to spend some time playing around with it.
regards,
-Robert
|