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

[KENDALL MCCARTHY_1]

Is this possible without a reboot?

[Steven Schweda]

> Is this possible without a reboot?

Unlikely. The SCS stuff is pretty
fundamental. Also, note the (generally)
empty "Dynamic" column for:

mcr sysgen show scs*

[Bill Hall]

Kendall,

Neither of the SYSGEN parameters are dynamic. If SCSSYSTEMID isn't correct, (DECnet address isn't supposed to be 13.3) you will have to reboot to change SCSSYSTEMID. The changes made by NETCONFIG (NCP) should not directly require a reboot. An Executor address change will require changing the MAC address of the Ethernet adapter. I would expect to have to shutdown and restart the other network protocols running on the server in the case of a MAC address change.

Bill

[Andy Bustamante]

If you're cleaning up this situation, another item on your checklist should be to verify the second system has it's own licenses properly loaded.

It's a quick and easy way to get from here to there, but you should pay attention and touch all the bases.

Andy

[Hoff]

If you change SCSNODE, you'll want to follow the rename sequence in the OpenVMS FAQ; the value in SCSNODE gets saved all over the place, and mechanisms such as the queue manager can require some work to restart after the value is changed. SCSNODE can be in device names, startup procedures, LAT, databases, etc. You're basically starting down the path of a nodename change, so you'll want to know what you're in for.

The OpenVMS FAQ is at:
http://64.223.189.234/node/1

This sequence should be easier, but it's not.

Within a cluster, you can change both SCSNODE and SCSSYSTEMID without rebooting the whole cluster, but you can't change only one of these two values; these two values operate as a pair within a cluster. The remaining nodes within a cluster will reject attempts to change one of the two, but will recognize changing both values as the arrival of a wholly new node.

Changing SCSNODE and/or SCSSYSTEMID requires that the local node be rebooted.

Stephen Hoffman
HoffmanLabs LLC

[p.balamurugan]

You may not register the node on decnet_register.exe. So verify the decnet id registed on that file.

[p.balamurugan]

you may not register the node name in Decnet_register.exe. So verify that

[Hoff]

p.balamurugan: the original poster is running DECnet Phase IV, as shown in one of the replies.

The DECnet_register tool is a component of the DECnet-Plus (aka DECnet Phase V, or as DECnet/OSI) network environment.

I've certainly never seen nor used this tool on a DECnet Phase IV box; the NCP tool is the primary management interface for Phase IV, and where you register the host and address values.

[KENDALL MCCARTHY_1]

The scsnode seems to be correct. (output below.

Let me step back for a second. Here is how this all started. I tried to go into CDO and do a directory. I couldnt complaining thet TP_server was not running. I tried to start DTM and it failed due to the fact that the executor is defined as LOTTO1 in NCP. We dont use DECnet here for anything. My goal is to get DTM started so people can use CDD. I ran netconfig and it didnt seem to take .The define statements seemed to run successfully (i didn't get an error)
Do I need to stop and start decnet?



LOTTOA: mcr sysgen
SYSGEN> SHOW SCS
Parameter Name Current Default Min. Max. Unit Dynamic
-------------- ------- ------- ------- ------- ---- -------
SCSBUFFCNT 4000 50 0 32767 Entries
SCSCONNCNT 40 40 2 32767 Entries
SCSRESPCNT 2000 300 0 32767 Entries
SCSMAXDG 576 576 28 985 Bytes
SCSMAXMSG 216 216 60 985 Bytes
SCSFLOWCUSH 1 1 0 16 Credits D
SCSSYSTEMID 13315 0 -1 -1 Pure-numbe
SCSSYSTEMIDH 0 0 -1 -1 Pure-numbe
SCSNODE "LOTTOA " " " " " "ZZZZ" Ascii
SCSICLUSTER_P1 " " " " " " "zzzz" Ascii
SCSICLUSTER_P2 " " " " " " "zzzz" Ascii
SCSICLUSTER_P3 " " " " " " "zzzz" Ascii
SCSICLUSTER_P4 " " " " " " "zzzz" Ascii
SYSGEN>

[KENDALL MCCARTHY_1]

I ran netconfig with lottoa and 13.3 as parameters . DTM now starts . But when I go and look at executor , it still show lotto1 and 15.1.

[KENDALL MCCARTHY_1]

Ok ,
DTM is running, but it looks like I have another issue. when I go to CDD I get this:

LOTTOA: mcr cdo
> Welcome to CDO V6.1
> The CDD/Repository V6.1 User Interface
> Type HELP for help
> CDO> dir
> %CDO-E-ERRDIRE, error displaying a directory
> -CDO-E-ERRSTARTSESS, error starting a session
> -CDD-F-STARTSESS, error starting session
> -SYSTEM-F-NOLOG, transaction log not found
> CDO>

Soooo I create the log file :


LMCP> create logfile/size=5000 SYS$COMMON:[SYSMGR]SYSTEM$LOTTOA.LM$JOURNAL

Transaction log SYS$COMMON:[SYSMGR]SYSTEM$LOTTOA.LM$JOURNAL;1 created.

%LMCP-W-NOT_USABLE, this transaction log will not be used as it is currently named


Any Ideas?

[KENDALL MCCARTHY_1]

All set Guys. I have alot of cleaning up to do on this system. All I had to do was create the file in the directory pointed to by sys$journal.

thanks for all your help