Diagnosing Client-Server TCPIP Connection Problems


Diagnosing Client-Server TCP/IP Connection Problems

SQL30081N Communication error and SQL1013N Database not found are the most common connection errors. If either of these errors occurs, you need to verify the server and client configurations.

  • On the server, verify that the DB2 instance is properly set up to accept client connections.

  • On the client, verify that the node directory, database directory, and in the case of a host connection, the DCS directory, are set up correctly.

F.0.1. Verifying the Server Configuration

At the database server, follow this procedure to verify its configuration.

1.

Verify that the database exists by issuing one of the following commands at the server:

 list db directory 

or

 list db directory show detail 

Figure F.2 shows the output for the list db directory command.

Figure F.2. Verifying that a database exists on the server


Figure F.2 confirms that the SAMPLE database resides locally on this server since the Directory entry type field has a value of Indirect. If the database resides on a different server, this field would have a value of Remote, which is not what you would want to see.

2.

Check the DB2COMM registry variable to verify that the correct communication protocol is specified by using the db2set all command (see Figure F.3).

Figure F.3. Checking the DB2COMM registry variable on the server


Figure F.3 shows that DB2COMM is set to TCPIP; therefore, the server is ready to listen for TCP/IP requests.

3.

Verify that the appropriate configuration parameters are set in the Database Manager Configuration file. Issue the get dbm cfg command and examine the following.

  • If DB2COMM=TCPIP, then SVCENAME must be set.

  • If DB2COMM=NETBIOS, then NNAME must be set.

In Figure F.4, you can see that the SVCENAME is set to a service name, db2c_DB2.

Figure F.4. Verifying that SVCENAME or NNAME is correctly set on the server


If SVCENAME is set to a service name instead of a port number, confirm that the value listed there is mapped to a unique port number in the operating system's services file. For example:

 db2c_DB2    50000/tcp   # Connection port for DB2 instance db2inst1 

If this line is not already in the services file, use a text editor to add it.

After you have made sure that you can connect locally on the server and that the server is set up correctly to accept client connections, verify the client configuration.

F.0.2. Verifying the Client Configuration

At the client, follow these steps to verify its configuration.

1.

Verify that the server connectivity information has been correctly entered in the node directory by using the list node directory command.

The service name in the client's node directory is a port number that matches the port number referenced by the SVCENAME on the server. For example, the SVCENAME on the server is set to db2c_DB2, as shown in Figure F.4, and as we saw, this mapped to port 50000 in the server's services file. Therefore, the client needs to specify port 50000 in the node directory, as shown in Figure F.5.

Figure F.5. Checking the node directory on a client


Alternatively, the client can specify a service name instead of the port number in the node directory. However, this service name is to be defined at the client services file, not the server services file. For example, the node directory can have the service name db2conn. If this is the case, then in the client's services file, you must set db2conn to 50000:

 db2conn    50000/tcp 

2.

Verify that you can ping the host name exactly as it appears in the node directory. If you cannot, that means there is problem connecting to the server. Try to ping the IP address of the server. If that works, then recatalog the node using the IP address instead of the host name and try again.

To recatalog the node directory, you need to first uncatalog the existing node:

 uncatalog node nodename 

3.

Even if the client can reach the server, it does not necessarily mean that the client can access the port to connect to databases on the server. Sometimes, for security reasons, the server port is not open to client connections, or the port is not enabled at all. To test if a port is accessible, you can telnet to the port as follows:

 telnet hostname or ip address 50000 

If DB2 is listening on that port on the server, you will see the Telnet window open, but it will hang, since DB2 is not configured to respond to the telnet command. This means that you have indeed reached that port on the server.

If you get an immediate error, this means that either:

  • The server is not listening on this port. Refer back to section F.1.1, Verifying the Server Configuration, to resolve this.

  • The port is behind a firewall and is not reachable by clients. Contact your network administrator for assistance.

4.

Confirm that the correct database values appear in the database directory using the list db directory command. The database name in the client's database directory must match the database alias in the server's database directory (see Figure F.6).

Figure F.6. Verifying that the database name in the client database directory matches the database alias on the server


If the database resides on a host server, verify the DCS directory. Using the list dcs directory command, ensure that the database name in the database directory matches the database name in the DCS directory (see Figure F.7). The target database name in the DCS directory must be the Location name if the host server is DB2 for z/OS and OS/390, or the RDB name if the host server is DB2 for iSeries.

Figure F.7. Verifying that the database name in the database directory matches the database name in the DCS directory


Figure F.8 displays a flowchart for diagnosing client-server connectivity problems. It summarizes what we have discussed so far. The client is a DB2 client; the server can be either a DB2 UDB server or a DB2 Connect gateway.

Figure F.8. Diagnostic flowchart for client-server connectivity problems


Figure F.9 displays a flowchart for diagnosing client-host connectivity problems.

Figure F.9. Diagnostic path for client-host connection problems


In Figure F.9, the client has at least DB2 Connect Personal Edition installed (review Scenario 3 in Chapter 6).

For a three-tier configuration where a DB2 Connect gateway works as the middle tier, the diagnosing path splits into two parts. First, you need to make sure the connection is working from the Connect gateway to the host database. For this, use the flowchart in Figure F.9. Second, for the client-gateway connection, use the flowchart in Figure F.8.



Understanding DB2(R. Learning Visually with Examples)
Understanding DB2: Learning Visually with Examples (2nd Edition)
ISBN: 0131580183
EAN: 2147483647
Year: 2004
Pages: 313

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net