Configuration errors are commonly the cause if your communication problem has the following characteristics:

•  It is not an intermittent error;
• The connection has either never worked, or has changed recently;
• You can connect successfully locally;
• You tried creating a loopback connection on the server and it failed. (In this situation, you should continue to debug the problem within the loopback connection on the server. Once you have resolved the issue there, you will know what changes need to be made on the client (if any)).
  

Verifying the TCP/IP setup on the server

The steps to confirm the setup on the server are as follows:

1. Verify the existence of the database by issuing one of the following commands:

db2 list db directory

 db2 list db directory show detail

If this is a multi-tier environment, you may see the database cataloged as a
remote database.

Database X entry:

Database alias = SAMPLE
Database name = SAMPLE
Database drive = C:\DB2
Database release level = a.00
Comment =
Directory entry type = Indirect
Catalog node number = 0
Alternate server hostname =
Alternate server port number =

2. Verify that the instance is configured to start listening on the appropriate
protocol, via the command db2set -all. Look for the parameter DB2COMM.

C:\>db2set -all

[e] DB2PATH=D:\IBM\SQLLIB
[i] DB2INSTOWNER=DB2INST1
[i] DB2PORTRANGE=60000:60003
[i] DB2INSTPROF=D:\IBM\SQLLIB
[i] DB2COMM=TCPIP
[g] DB2_EXTSECURITY=YES
[g] DB2SYSTEM=LISAC02
[g] DB2PATH=D:\IBM\SQLLIB
[g] DB2INSTDEF=DB2
[g] DB2ADMINSERVER=DB2DAS00

3. Verify that the appropriate protocol-specific parameters are set in the database
manager configuration settings, so that DB2 knows what values to listen on.
For example, issue db2 get dbm cfg and look in the following section:

db2 get dbm cfg

...
NetBIOS Workstation name (NNAME) =
TCP/IP Service name (SVCENAME) = db2cDB2
...

4. If the previous step resulted in a service name instead of a port number for the
SVCENAME field in your environment, then confirm that the value listed there
is mapped to a unique port number in the operating system’s /etc/services file.
For example:

DB2_DB2 60000/tcp #These ports are reserved for the DB2 Fast Communications Manager
DB2_DB2_1 60001/tcp
DB2_DB2_2 60002/tcp
DB2_DB2_END 60003/tcp
db2c_DB2 50000/tcp #This is the connection port for instance DB2

Starting DB2 communication listeners on the server

1. Create a backup copy of the db2diag.log, then clear the contents of the original
db2diag.log file. Raise the diagnostic level to 4, then stop and restart this DB2
instance, via the following commands:

db2 update dbm cfg using diaglevel 4

Note: You must refer to the db2diag.log instead of the notification log in this
situation, because the notification log does not contain this level of detail
even when using notification level 4.

2. Verify that the db2diag.log shows that the listeners for the specific protocol
which we are interested have been started successfully.

2005-02-11-15.59.58.828000-480 I2036155H322 LEVEL: Info
PID : 2536 TID : 2632 PROC : db2syscs.exe
INSTANCE: DB2 NODE : 000
FUNCTION: DB2 UDB, common communication, sqlcctcp_start_listen, probe:80
MESSAGE : DIA3000I "TCPIP" protocol support was successfully started.

3. If you had not performed one of the necessary setup steps, you would receive
the following error when you performed the db2start command:

db2start

SQL5043N Support for one or more communications protocols
failed to start successfully. However, core database manager
functionality started successfully.

4. This would be accompanied by specific error messages in the db2diag.log file if
DIAGLEVEL was set to 4 at the time. For example, if you I had not set the
SVCENAME parameter in the database manager configuration settings, you
would receive the following error in the db2diag.log:

2005-02-11-16.14.05.843000-480 E2206H457 LEVEL: Error
PID : 2516 TID : 2204 PROC : db2syscs.exe
INSTANCE: DB2 NODE : 000
FUNCTION: DB2 UDB, common communication, sqlcctcpconnmgr, probe:50
MESSAGE : ADM7006E The SVCENAME DBM configuration parameter was not
configured. Update the SVCENAME configuration parameter using the
service name defined in the TCP/IP services file.

5. Once you have confirmed that the DB2 protocol-specific listeners are started
successfully for the instance, don’t forget to downgrade the diagnostic level, so
that you do not suffer performance problems. Returning it to the default
diagnostic level of 3 is done as follows:

db2 update dbm cfg using diaglevel 3

Verifying the TCP/IP setup on the client

The steps to confirm the setup on the client are as follows:

1. Confirm the values that you used in your cataloging of the remote server’s
instance by issuing one of the following commands:

db2 list node directory

db2 list node directory show detail

...
Node 1 entry:
Node name = MYNODE
Comment =
Directory entry type = LOCAL
Protocol = TCPIP
Hostname = myserver
Service name = 50000
Remote instance name =
System =
Operating system type = None

...

The Service name value in this output should match the port number defined
in the server instance’s database manager configuration SVCENAME setting. If
a service name is used instead of a port number, it is important that the port
number to which the service name on the client maps (in the client’s
etc/services file) should match the port number used on the server.

2. Verify that you can ping the Hostname value exactly as it appears in the results
from step (1).

3. Another test that you can perform is to use the telnet command to check
whether there is something (in this case, hopefully a DB2 instance) listening on
a particular port number on a particular server. For example: telnet
myserver.ibm.com 50000. Telnet does not have to be enabled on the server. If
there is indeed something listening on that port then you should see that the
telnet window will open, but then hang. This means that you have indeed
reached the server, and that something is indeed listening on that port. If, on
the other hand, you receive an immediate error, then either:

a. You have used the wrong hostname or IP address values. If you used a
hostname here, try using the IP address, in case it is a hostname resolution
problem;

b. You have used the wrong service name or port number. If you used a
service name, try using the port number instead, in case the service name
was not mapped correctly in the /etc/services file on this client;

c. There is a firewall between the client and server, and it is not allowing
communication on this port. Verify with your network administrator
whether or not this is the case;

d. DB2 on the server is not listening on this port. Refer back Verification of
the setup on the server in order to confirm the setup of the server.

4. If the telnet and ping tests worked, confirm that the proper database values
appear in the database and DCS catalogs, as appropriate. Errors in these
catalogs do not usually result in communication errors, however.

At this point you have confirmed that the configuration of both the client and the
server are correct from the DB2 point of view. If you continue to receive a
communication error, these are situations where you should pursue obtaining
diagnostics like db2 traces.