IBM Books

Troubleshooting Guide

Troubleshooting Tips

This section describes how to deal with some frequently encountered problems faced by users when trying to connect clients to DB2 servers. It addresses the following topics:

For related information, see:

You may also refer to the Quick Beginnings guide for your platform.

Important: This section represents a small sampling of the information available from DB2 Customer Service. For a complete and up-to-date source of DB2 information, use the DB2 Product and Service Technical Library at http://www.software.ibm.com/data/db2/library/.

Determining the Scope of a Client Problem

To determine the possible sources of a problem experienced on the client, ensure that:

[  ]
The client and server were installed correctly.

[  ]
The communication products are installed and operational on the client and server.

[  ]
The client functioned correctly in the past.

[  ]
The database manager started on the server with the appropriate communications listeners.

[  ]
You can establish a connection from the client to another server independent of DB2 Universal Database. That is, you can use another command or utility like ping, telnet, or ftp to establish the connection.

[  ]
You can establish a connection from another client to the server.

This section explains how to:

Testing connections on the server

If you are having difficulty establishing a client connection, test a connection from the server's machine:

  1. Try connecting to the database on the server using the local database directory entry (to form an IPC connection). If this connection fails, the problem is likely with the server.
  2. Test a loopback connection. That is, try to establish a remote connection on the server, using the protocol, matching the clients'. Then catalog a database on the server with a node directory entry. Ensure that the node directory entry references the server machine. Attempt a connection from the server to itself.
    Note:For information on cataloging databases, refer to the Administration Guide, Design and Implementation manual.
  3. If the connection is successful, then the problem exists on the client If the connection fails, then the problem may be one of the following:

It is recommended that you keep the directory entries set up on the server. This will enable you to diagnose connectivity problems if they reoccur.

Using the db2diag.log file to diagnose server communication problems

If you determine that a client problem is caused by the server, the db2diag.log file on the server may give more information on what is causing this problem. See First Failure Data Capture for details on using this file.

For example, you may receive the SQL5043N message after issuing the db2start command on the server. This indicates that one or more protocols failed to start successfully. The db2diag.log file may provide additional information to assist you with diagnosing the problem.

When looking for the cause of server problems that may be affecting your clients, perform the following steps:

Step  1.

Set the DIAGLEVEL to 4 on the server: 

db2 UPDATE DATABASE MANAGER CONFIGURATION USING DIAGLEVEL 4
db2 terminate

Step  2.

Disconnect all applications connected to the server: 

db2 force application all

Step  3.

Restart the server: 

db2stop
db2start

Step  4.

Examine the db2diag.log file on the server.

For each protocol specified in DB2COMM registry value there should be either a message indicating that its listener started successfully, or a message indicating why the protocol listener failed. (For an explanation of listeners, see Chapter 13, The DB2 Process Model.)

If you do not see a message for the protocol, DB2 did not detect the protocol in the DB2COMM registry value and did not attempt to start it.

There are many reasons for a listener not starting, including incorrect installation of a communication protocol or incorrect server configuration. See the following sections for more information:

Step  5.

If all of the expected communication protocols were started successfully at the server, try the connection again. Examine the db2diag.log file on the client for clues to diagnosing the problem.

Initial Connection after Installation Fails

"Initial connection" means the first attempt to connect to a remote server after installation of a client.

If the initial connection fails, try to connect to the database locally from the server itself. If this works, the problem is with the connection from the client. If you cannot make the connection, then the problem may be with the database manager on the server.

If there is a problem, perform the following steps:

[  ]
Ensure that the client and server were installed correctly.

During installation, messages appear on the screen if there are problems. You can also keep install logs for unattended installations on Intel platforms:

[  ]
Ensure that all the prerequisite software products were installed.

[  ]
Ensure that the communication products are installed and operational.

[  ]
Confirm a connection from another client to the server.

If there is a connection, then the server is functioning properly; if not, the problem may exist on the network or the server.

[  ]
Ensure that you can get a connection from the client to another server. If so, then the client is working.

Clients Suddenly Experiencing Problems

If you suddenly encounter a problem with one or more clients which previously connected to the server, review the following questions:

Is a single client is experiencing difficulties?

[  ]
Can other network-enabled applications run on this client? If not, the problem is likely with the communications software, rather than with DB2.

[  ]
What is unique about the operating environment for this client? Compare it with other clients that can connect to the server.

[  ]
Were there recent changes made to the client that could be affecting it? (For example, is another product or Fix Pak installed?)

[  ]
Are resource limits, on the client, exceeded (for example, memory)?

Are multiple clients experiencing difficulties?

[  ]
Is the LAN available? For example, can you use the ping command to servers, or issue the net use command to drives or devices on the network?

[  ]
Is the server operational? Test a connection at the server machine.

[  ]
Are the required communication listeners present on the server? See Using the db2diag.log file to diagnose server communication problems for details.

[  ]
Are resource limits, on the server, exceeded? (for example, memory)?

User Name Not Valid on Windows 95 and Windows 98

Symptom
A message is received that the user name is invalid when trying to access DB2 from a Windows 95 and Windows 98 client. (Typically, the SQL1403N message is received.)

Possible Cause
If you, or an application you are using, does not specify a user name and password as part of a CONNECT statement, an implicit user name and password is used instead. The user name and password you used, when you logged on to the operating system, are passed with the CONNECT statement. However, the implicit user name and password may be incorrect, causing the CONNECT statement to fail.
Note:Windows 95 and Windows 98 allows you to log on without a user name and password. In this case, the implicit user name and password are null resulting in a failed CONNECT statement.

Action
For a connect request, you or any applications you create should provide a user name and password as part of the CONNECT statement: 
CONNECT TO database USER userid USING password

For more information, refer to the DB2 for Windows NT Quick Beginnings guide.

TCP/IP Problems

This section outlines some common troubleshooting tips, related to TCP/IP.

SQL30081N received

Symptom
When trying to connect to a database from a client using TCP/IP and the connection fails, the message SQL30081N is often received with a protocol-specific error code ECONNREFUSED (often "10061" on Intel-based machines or "79" on UNIX-based environments).

Possible Cause
This error code indicates that the client connection was refused. (Refer to the Message Reference for information on the other error codes of SQL30081N.)

Action
Ensure that:

[  ]
DB2START was issued and the TCP/IP listener was started on the server. See Using the db2diag.log file to diagnose server communication problems, for more information.

[  ]
The TCP/IP stack is functional on both the client and the server.

From the client, try using the ping command with the server's host name.

[  ]
The directories are cataloged correctly. In particular, ensure that:
  • The database directory entry points to the correct node directory entry.
  • The service or port name in the svcename field in the node directory maps to the same port number as the svcename in the server's database manager configuration.

    Try cataloging the node by specifying the svcename as an available port number rather than as a service name.

  • The IP address or host name that is specified in the hostname field of the node directory is correct. (To verify the entry, use the ping command to test the host name or IP address.)

To verify and change directory entries, use:

  • The Client Configuration Assistant
  • The CATALOG DATABASE and CATALOG TCPIP NODE commands. Refer to the Command Reference for more information.

[  ]
The TCP/IP services file is not corrupted, especially if you used a text editor to update it.

If you added the port settings line to the end the file, it must be followed by a blank line.

[  ]
The port number used is the same in the TCP/IP services files of the client and the server instance. The port number is uniquely defined within the TCP/IP services file.

SQL5043N received on server for TCP/IP

Symptom
The SQL5043N message is received on the server.

Possible Cause

Action
View the db2diag.log file on the server. Look for messages that may provide more information.

Client Application or Query Appears Suspended

Symptom
A client application accessing a remote DB2 server appears to be suspended.

Possible Cause
The client was not notified that the server is down.

Due to the characteristics of the TCP/IP protocol, the TCP/IP subsystem on one host may not be notified of the failure of its partner on another host.

DB2 uses TCP/IP's connection KEEPALIVE option to detect if there is a connection failure. This option transmits a message periodically to determine if the partner is still alive. If the partner fails to respond to this message, the connection is considered to be broken, and an error is returned.

A client may appear to be suspended if the KEEPALIVE settings on the client have been set to check TCP/IP connections infrequently and the server has gone down.

Action
To remove an agent process that is suspended at the server, use the FORCE APPLICATION command.

If the problem persists, change the value of the KEEPALIVE settings to change the time interval at which messages are transmitted to detect a connection failure.
Note:KEEPALIVE settings affect all TCP/IP applications running on the machine.

IPX/SPX Problems

This section provides troubleshooting tips for the IPX/SPX communication protocol.

SQL30081N received

Symptom
The SQL30081N message is received when trying to connect to a DB2 server.

Action
Ensure that:

[  ]
Your Novell Netware TLI*.DLL files are at the correct level. (Use the DB2 or Novell World Wide Web sites to find out about the latest Novell Netware fixes.)

[  ]
If file server addressing mode is being used, the file server and object names in the client's node directory entry match the values of fileserver and objectname in the database manager configuration file on the server. These names must be the same, and both should be in uppercase.

[  ]
If file server addressing mode is being used, the database server was registered on the file server sometime after DB2 was installed and configured. For more information on the REGISTER command, refer to the Command Reference.

[  ]
If the server machine was moved on the network and its IPX/SPX internetwork address was changed, the DB2 server's internetwork address was deregistered before any change, and reregistered after the change.

[  ]
If file server addressing mode is being used to connect to the database, the object name that represents the DB2 server instance (that is, stores the IP address of the server instance) is in the bindery of the file server.

[  ]
If direct addressing mode is being used, the following values are in the client's node directory:
  • The file server entry is specified as an asterisk (*)
  • The value of objectname is the server's IPX/SPX internetwork address.

    Issue db2ipxad on the server to get the server's IPX/SPX internetwork address. This command is in the bin subdirectory of the sqllib directory.

SQL30081N on OS/2

Symptom
For OS/2 , the SQL30081N message is received with the function "t_open" and a reason code of "8".

Possible Cause

Action

Ensure that:

[  ]
For DOS and Windows, the first two lines of the net.cfg file on the client are: 
ECB COUNT=50
DATA ECB COUNT=89

The net.cfg file is in the root directory where you boot from.

[  ]
The FILES parameter in the OS/2 CONFIG.SYS file is set to an appropriate level. This parameter determines the maximum number of files that can be used by all programs running in DOS and Win-OS/2 sessions.

[  ]
For OS/2, the AUTOEXEC.BAT file does not contain a PATH to the OS/2 NETWARE directory. This path is for the DOS and Win-OS/2 environment, and the DLLs in the OS/2 NETWARE directory are OS/2 DLLs. In some cases, Windows and OS/2 NetWare DLLs have the same name, but DOS and Windows cannot load or run OS/2 DLLs.

Connection to OS/2 server hangs unexpectedly

Symptom
An IPX/SPX connection to a DB2 for OS/2 server hangs, even though the connection was previously successful.

Possible Cause
There may be NetWare resource problems.

Action
To ensure that you have provided yourself an adequate number of connection resources, verify that the net.cfg file provides:

See your IPX/SPX documentation for details about these configuration parameters.

The net.cfg file is usually in the root directory where you boot from. Alternatively it may be in the NETWARE directory for OS/2. Check the system boot-up screen to determine which net.cfg file is being used.

SQL1109N when connecting from a Win-OS/2 client

Symptom
The SQL1109N message is received when trying to connect from a Win-OS2 client.

Possible Cause
There are two versions of the NWCALLS.DLL and TLI_SPX.DLL files: one for OS/2 and one for Windows. These files may not be in the correct location.

Action
The NWCALLS.DLL from Novell's NWDLL2.exe package should be in the WINDOWS\SYSTEM directory. Ensure that Windows is not trying to load the OS/2 version of NWCALLS.DLL.

SQL5043N received on server for IPX/SPX

Symptom
The SQL5043N message is received on the server.

Possible Cause

Action
View the db2diag.log file on the server. Look for messages that provide more information.

NetBIOS Problems

This section provides troubleshooting tips related to the NetBIOS communication protocol. NetBIOS is not used in UNIX-based environments.

SQL30081N received

Symptom
If you cannot connect to the server from a client, you will typically receive the SQL30081N message with return code of "0x14".

Action
Use the following checklist to diagnose the problem. If you are using directory caching and change database or node directories, you must perform db2 terminate at the client for your changes to come into effect.

[  ]
Is the NetBIOS listener started on the server? Check the NetBIOS resources in the db2diag.log file to see if there are problems. See SQL5043N received on server for NetBIOS, for more information.

[  ]
Are your client and server set to start NetBIOS support?

NetBIOS must be included in both the server's and the client's configurations:

  • On the server, use the db2set db2comm command to verify that NetBIOS is a supported protocol.
  • The node name in the client's database directory must match the alias name of a NetBIOS node entry in the client's node directory. The nname that corresponds to this alias name in the client's node directory must match the value of the server's database manager configuration parameter nname.

    If these three names are not the same, you must recatalog the node entry at the client.

[  ]
Was the correct adapter number specified when the node was cataloged on the client?

Check the adapter specified in the client's node directory. This adapter number must match the adapter configured for NetBIOS communications at the client.

Usually, the adapter number is 0. However, if more than one adapter is configured, you must ensure that the adapter being used by the client is for a LAN that can reach the server.

With native NetBIOS on Windows NT, the adapter number is called the logical LAN adapter number (Lana number). To check its value perform the following steps:

  1. Select the Network icon from the Control Panel.
  2. From the Services tab, select the NetBIOS interface.
  3. Select Properties.
  4. The Lana number associated with the network route Nbf must match how you have cataloged your nodes.

[  ]
Is there a physical LAN layer problem with the gateway, bridge, router, or LAN cables?

[  ]
Is name filtering occurring on the bridge or router that connects the server's LAN to the client's LAN?

A LAN bridge or router may be preventing client requests from reaching a server on a different LAN because it is ignoring names with DB2's name structure. Discuss this possibility with your LAN administrator.

[  ]
Are the server and client using compatible NetBIOS stacks?

Ensure that the server and its clients are using native NetBIOS or identical NetBIOS emulation.

Connection ends suddenly

Symptom
You can successfully connect a client to a server, but the connection ends suddenly, usually with the SQL30081N message with a return code of "0x08" or "0x18" logged in the db2diag.log file.

Possible Cause
The NetBIOS protocol is reporting a time-out to the DB2 server, possibly because of a physical LAN problem. This happens occasionally on OS/2 systems.

Action
Report the situation to your NetBIOS service organization, and check the DB2 Product and Service Technical Library at http://www.software.ibm.com/data/db2/library/ for some suggested fixes.

SQL5043N received on server for NetBIOS

Symptom
The SQL5043N message is received on the server.

Possible Cause
The NetBIOS listener is not started.

Action
View the db2diag.log file on the server. Look for the following entries:

[  ]
DIA3426C:
  • Update the database manager configuration with a valid nname, and stop and start the instance.

[  ]
DIA3409I or DIA3420C:
  • Increase the number of NCBs, sessions, or names by the difference between the number requested and the number that could be allocated.

    These values are kept in:

    • For OS/2, the protocol.ini file
    • For the Windows 95 and Windows 98 operating systems, the NetBIOS network control settings
  • Reduce the NetBIOS resources used by other NetBIOS applications. These resources may be restricting the DB2 NetBIOS resource request.
  • If not enough NCBs can be allocated, find out the values of the environment variables DB2NBSENDNCBS and DB2NBRECVNCBS. If their values are greater than their defaults, you may want to reduce them.

    The number of NCBs that the DIA3420C message said could be allocated must be greater than the sum of these values plus the values for DB2NBINTRLISTENS and DB2NBXTRANCBS.

  • If not enough sessions can be allocated, you might try setting the environment variable DB2NBSESSIONS to the value that the DIA3420C message said could be allocated.
  • Increase the NetBIOS resource pool limit values in the protocol.ini file to satisfy all of the resource requests made by NetBIOS applications and drivers on the workstation adapter.

Problems When Using Named Pipes

SQL30082 received

Symptom
In a workgroup environment, a user trying to access the database server using named pipe receives the SQL30082N message with a reason code of "18" ("named pipe access denied").

Possible Cause
Before a named pipe can be accessed at a remote server, there must be an open session at the system level. In this case, the user authentication failed at the server. Therefore, the session is a null session that does not have the credentials to access the named pipe.

Action
Do one of the following:

APPC Problems

Review the following checklist when experiencing problems with APPC connections:

[  ]
Did you follow the instructions in the Quick Beginnings guides for installing clients or servers? These guides give step-by-step instructions for APPC configuration.

[  ]
If VTAM is used, are the correct LU names defined for the server and client?

[  ]
Is the correct TP name defined?

[  ]
If SNA is used, are the correct SNA node IDs defined?

[  ]
Are you using appropriate APPC security in the DB2 node directory, and appropriate DB2 authentication in the DB2 database directory?

Refer to your Quick Beginnings guide for details on which types of authentication and security can be used together. Note that the security setting in the DB2 node directory overrides any SNA security configuration.

[ Top of Page | Previous Page | Next Page | Table of Contents | Index ]

[ DB2 List of Books | Search the DB2 Books ]