TCPIP host issues

[KENDALL MCCARTHY_1]

I have two nodes . lottoa and lotto1. It seems like ther is something wrong with the host names . This happens on lottoa:

"LOTTOA: tcpip
TCPIP> show host lottoa

LOCAL database

Host address Host name

164.51.145.75 LOTTOA, lottoa, lott0a
TCPIP> sho host lotto1

LOCAL database

Host address Host name

192.149.205.1 lotto1, LOTTO1
TCPIP> exit
LOTTOA: set ho lottoa
%SYSTEM-F-UNREACHABLE, remote node is not currently reachable
"

When I set ho to lotto1 from lottoa I actually log into lottoa.

"
LOTTOA: set ho lottoa
%SYSTEM-F-UNREACHABLE, remote node is not currently reachable

LOTTOA: set ho lotto1

OpenVMS Alpha (TM) Operating System, Version V7.2

Username:-----------
Password:


Information Resource Management


Last interactive login on Wednesday, 25-JUL-2007 11:50:02.06
Last non-interactive login on Tuesday, 19-JUN-2007 16:18:13.25
%Login: Executing Login
LOTTOA:
"
So in summary:

From lottoa

set ho lottoa =node not reacable
set ho lotto1 = actually logs into lottoa
set ho 0 = logs into lottoa

????

[Andy Bustamante]

You're mixing two networking protocols. The default for "set host" is DECnet. Depending on your network configuration DECnet may or may not be routed between the two systems. Which version of DECnet you're running will also determine whether or not you can pass DECnet traffic over TCPIP. Telnet or SSH (in later versions of TCPIP or third tcp/ip versions) will allow you create a remote terminal session, if your network is configured to allow this traffic. DECnet is managed with the NCP or NCL commands depending on version.

Try $ show system /proc=net*

If you see NETACP, you are running Phase IV. If NET$ACP, Phase V

Andy

[Peter Zeiszler]

What about Telnet to Lottoa and Lotto1?
Does that get you to the right machines?

Do you run decnet phase IV or osi? I am familiar with phase IV but never got osi working properly to migrate to it. (Its the issues of migrating with no impact that killed that implemention)

[Bill Hall]

Kendall,

SET HOST by default uses the DECnet network stack not TCP/IP. At this point show TCPIP host name/address translations doesn't help. Your "set ho" results probably tell more. I assume you don't have defined a symbol for ho ? ho :== host/telnet.

It appears your DECnet name resolution is incorrect. You really haven't given enough information to do more than guess. Determine which version of DECnet you are running by looking at the product database:

$product show product decnet*

If you are running DECnet Phase IV, the fix should be relatively straight forward. DECnet PHase V has a lot more flexibility in configuring name/address resolution.

Bill

[KENDALL MCCARTHY_1]

NCP>show known nodes


Known Node Volatile Summary as of 25-JUL-2007 12:35:05

Executor node = 13.1 (LOTTO1)

State = on
Identification = DECnet for OpenVMS AXP V7.2
Active links = 4


Node State Active Delay Circuit Next node
Links

13.2 (LOTTO2) unreachable
13.18 (ALPHAS) unreachable
13.100 (TLH) reachable 13.1 (LOTTO1)
13.102 (IRM2) unreachable
13.415 (PENRTR) unreachable
13.465 (GAIRTR) unreachable
13.495 (ORLRTR) unreachable
13.615 (TAMRTR) unreachable
13.901 (WPBRTR) unreachable
13.931 (FTMRTR) unreachable
15.1 (LOTTOA) unreachable
15.10 (ODCRTR) unreachable
NCP>exit
LOTTOA: product show product decnet*
----------------------------------- ----------- ------------
PRODUCT KIT TYPE STATE
----------------------------------- ----------- ------------
DEC AXPVMS DECNET_PHASE_IV V7.2 Full LP Installed
----------------------------------- ----------- ------------

1 item found
LOTTOA:

[Andy Bustamante]

So you're running DECnet Phase IV. That means you don't have the option for DECnet over IP. Looking at the two addresses, 164.51.145.75 and 192.149.205.1, I would assume these are in different networks. That may or may not mean different locations.

Based on that assumption, the question for your networking team is "are you routing DECnet between the two subnets?" If they say no, you won't be able to use the "set host" or decnet copy between the two nodes. Telnet and ftp make reasonable replacements.

Andy

[Bill Hall · Accepted solution]

Kendall,

The output from NCP you show is from LOTTO1.
Did you execute the PRODUCT SHOW from the same node?

Bill

[KENDALL MCCARTHY_1]

Bill ,

I think you hit it . This node was "cloned" form lotto1 (before I got here) in that backup and restore was done from lotto1 to lottoa. That being said , is the decnet stuff using config files from lotto1? How do I fix this?
I guess that it would also explain this:

"LOTTOA: @SYS$COMMON:[SYS$STARTUP]DECDTM$STARTUP.COM
%DECdtm-W-NAMENEQ, DECnet nodename (LOTTO1) is not equal to SCSNODE (LOTTOA)
%DECdtm-W-ADDRNEQ, DECnet address (13313) is not equal to SCSSYSTEMID (13315)
%DECdtm-F-NOSTART, DECdtm facility not started
LOTTOA:
"



Kendall

[Andy Bustamante]

This thread covers name change and what needs to happen. http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=1102304

You can also see the VMS faq http://h71000.www7.hp.com/faq/vmsfaq_007.html


Andy

[Bill Hall]

kendall,

Straightening out the DECNET name/address and SYSGEN parameters SCSNAME and SCSSYSTEMID will also "fix" the DTM startup error.

The links Andy should help guide you. But, you should review all of the steps in renaming and re-addressing a node. The SCSSYSTEMID 13315 listed in the DTM startup error is DECnet address 13.3. That does not match the DECnet address of 15.1 as shown in the NCP show known nodes output for LOTTOA.

I don't think we can tell you what the correct name and address pairs should be. Only you and your network support folks can do that.

Bill