CORBA 2.6.1 Administration Guide

ManualsBrandsHP ManualsServerHP NonStop G-Series

100

SCF - T9082G02 - (26JUN00) (20MAR00) - 07/11/0000 10:30:20 System \ARNOLD

TCPIP Info SUBNET \ARNOLD.$ZTC0.*

Name Devicename *IPADDRESS TYPE *SUBNETMASK SuName QIO *R

#LOOP0 \NOSYS.$NOIOP 127.0.0.1 LOOP-BACK %HFF000000 OFF N

#SN1 \ARNOLD.LAN01 172.17.202.44 ETHERNET %HFFFFFF00 N N

...

Total Errors = 0 Total Warnings = 0

Look for the subnet with the device whose IP address matches the IP address for the system you are using. For that device, find out the IP

process name, which is the last entry on the line beginning with “TCPIP Info SUBNET." In the example above, the process name is

\ARNOLD.$ZTC0.

Use the TCP/IP process name in the following command, at an OSS window, to verify that the CORBA server is listening on the correct port

number:

/home/ecrm/stack: gtacl -c "scf status process \$ZTC0"

gtacl[9]: warning: unable to propagate all environment variables

SCF - T9082G02 - (26JUN00) (20MAR00) - 07/11/0000 10:36:36 System \ARNOLD

TCPIP Status PROCESS \ARNOLD.$ZTC0

Status: STARTED

PPID............ ( 0,329) BPID................... ( 1,317)

ProtoState Laddr Lport Faddr Fport SendQ RecvQ

TCP ESTAB 172.17.202.44 telnet 155.186.75.77 1163 0 0

TCP ESTAB 172.17.202.44 telnet 155.186.75.21 4251 0 0

TCP ESTAB 172.17.202.44 telnet 155.186.75.21 4533 52 0

TCP ESTAB 172.17.202.44 ftp 155.186.75.77 1246 0 0

TCP ESTAB 172.17.202.44 telnet 155.186.75.21 3639 0 0

TCP ESTAB 172.17.202.44 telnet 155.186.75.77 2339 0 0

TCP LISTEN 172.17.202.44 1033 0.0.0.0 * 0 0

TCP LISTEN 172.17.202.44 4000 0.0.0.0 * 0 0

TCP LISTEN 172.17.202.44 2240 0.0.0.0 * 0 0

TCP LISTEN 172.17.202.44 4001 0.0.0.0 * 0 0

TCP LISTEN 0.0.0.0 telnet 0.0.0.0 * 0 0

TCP LISTEN 0.0.0.0 ftp 0.0.0.0 * 0 0

TCP LISTEN 0.0.0.0 finger 0.0.0.0 * 0 0

TCP LISTEN 0.0.0.0 echo 0.0.0.0 * 0 0

TCP LISTEN 0.0.0.0 1089 0.0.0.0 * 0 0

UDP 0.0.0.0 69 0.0.0.0 * 0 0

Total Errors = 0 Total Warnings = 0

One of the example IORs displayed in Cannot Run Client showed that the server was configured to listen on port 2240. The scf status

process \$ZTC0 command output shows that the server is, indeed, running and listening for client connections on that port.

If the

scf status process \$ZTC0 command does not show the port number that the server was configured to listen on, then see NonStop

CORBA Listening on the Wrong Socket.

Explanation: The TCP configuration is the simplest configuration to use. Even if it is not the final configuration that is used in production, it

allows the user to quickly test a CORBA server. However, there are some problems with it.

The first is that the port number must be a unique port number, not used by any other process. When the server starts with the TCP

configuration, it will open a socket and wait for connections on that port. The user needs to verify that each TCP server is assigned a

new, unique port number.

The second problem is the use of preallocated port numbers can create object reference collision. That means that if a stack server is

started with a TCP configuration, then a second stack server cannot be executed with the same TCP configuration. That is because the

second server will use the same IP address and port number as the first server; therefore, all the clients will connect only to the second

server, and the first server’s object reference will become invalid. That is, if a client will try to use the object reference of the first server, it

will fail with the

org.omg.CORBA.COMM_FAILURE error message.

To ensure that each TCP server uses a unique port number, configure the entity tcp_server@ORB as follows:

port_number 0

tcp_server true

host_name localhost

Assigning a port number of 0 causes NonStop CORBA to assign an available port to each new server.

NonStop CORBA Listening on the Wrong Socket

Problem: The CORBA server process is running, but the scf show status command shows that the server is not listening on the correct

socket. The client program gets the COMM_FAILURE error message.

Solution: To ensure that the CORBA server is using the correct TCP/IP process for communication with the client, add a DEFINE to your

environment with the following command, specifying the correct TCP/IP process name in place of $ZTC0:

add_define =TCPIP^PROCESS^NAME class=map file=\$ZTC0

To determine the correct TCP/IP process name for the system and IP address you use, see the example of scf info subnet in Verifying

TCP/IP Configuration.

If the server is running under TS/MP, add the following defines to the TS/MP configuration:

SET SERVER DEFINE =TCPIP^PROCESS^NAME, CLASS MAP, FILE $ZTC0