Troubleshooting Guide

Troubleshooting Tips

This section describes how to deal with some problems users frequently face when they try to connect clients to DB2 servers. It addresses the following topics:

Determining the Scope of a Client Problem
Initial Connection after Installation Fails
Clients Suddenly Experiencing Problems
User Name Not Valid on Windows 95 and Windows 98
TCP/IP Problems
IPX/SPX Problems
NetBIOS Problems
Problems When Using Named Pipes
APPC Problems.

For related information, see:

Chapter 2, Troubleshooting the DB2 Universal Database Server if you suspect the problem is with the DB2 server
Chapter 4, Troubleshooting Host Communications for troubleshooting host communications
Chapter 5, Troubleshooting Applications for troubleshooting applications running on clients, including ODBC applications.

You may also see the Quick Beginnings guide for your platform.

Important: This section represents a small sampling of the information available from DB2 Customer Support. For a complete and up-to-date source of DB2 information, use the DB2 Product and Service Technical Library on the Web, at http://www-4.ibm.com/software/data/db2/library/ (Note that this information is in English only.)

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. 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:

Test connections to the server
Use the db2diag.log file to verify that communications listeners are enabled

Testing Connections on the Server

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

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.
Test a loopback connection. First, catalog a node pointing to the local machine. Second, catalog a database on this new node. Finally, attempt a connection from the server to itself.
Note: For information on cataloging databases, refer to the Administration Guide: Implementation manual.
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:
- The protocol stack on the server is not working
- The listeners for the required communications protocols are not started on the server
- The LAN network is not working

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:

Set the DIAGLEVEL to 4 on the server:

db2 UPDATE DATABASE MANAGER CONFIGURATION USING DIAGLEVEL 4
db2 terminate

Disconnect all applications connected to the server:
```
db2 force application all
```
Restart the server:
```
db2stop
db2start
```
Examine the db2diag.log file on the server.
For each protocol specified in the 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 14, 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:
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 installation logs for unattended installations on OS/2, Windows 95, Windows 98, and Windows NT operating systems. Specify error log and history files with the /l1 and /l2 options respectively. (If you do not include these options with the installation request, the files are not kept.)

[ ]

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 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 recent changes made that could affect the client? (For example, is another product or fix pack installed?)
[ ]: On the client, are resource limits (for example, memory) exceeded?

Are multiple clients experiencing difficulties?

[ ]: Is the LAN available? For example, can you use the ping command when using TCP/IP, or issue the net use command when using NetBIOS?
[ ]: 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.
[ ]: On the server, are resource limits (for example, memory) exceeded?

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 or 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 allow 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

If authentication is set to SERVER in the server's database manager configuration, you must provide a user name and password that are valid on the server. This is the default.
If authentication is set to CLIENT in the server's database manager configuration, you must provide a user name and a password that are valid on the client.

For more information, see the DB2 for Windows Quick Beginnings guide.

TCP/IP Problems

This section outlines some common troubleshooting tips that are 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. (See 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.

The TCP/IP protocol tester, pctt, can be used to verify that the protocol works across the network. The tester can be found in the bin subdirectory of the sqllib directory.

Or, 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. See 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

TCP/IP is not started on the server machine.
Database manager configuration is not correct. (For example, the svcename configuration parameter defined is not correct.)
The TCP/IP services file is not correct. (For example, the svcename configuration parameter in the database manager configuration is not defined in the file.)

Action

View the db2diag.log 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.

For Windows 95, Windows 98, and Windows NT:
Use the KeepAliveTime TCP/IP configuration parameter in the registry. The KEEPALIVE parameter may be created if it does not exist under the Parameters registry subkey. Add this parameter to:
```
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
```
The default value is two hours.
For OS/2:
Use the inetcfg command. (For OS/2 TCP/IP Version 2.0, you must apply the fix CSD UN64092 to use this command.)
For AIX:
Change the values of the network options tcp_keepidle and tcp_keepintvl with the no command (for details, type man no). The default value is two hours.
For HP-UX systems:
Change the values of the network options tcp_keepstart and tcp_keepfreq with the nettune command (for details, type man nettune).
For Solaris systems:
Change the value of the network option tcp_keepalive_interval with the following command:
```
ndd -set /dev/tcp tcp_keepalive_interval value
```
(For details, type man ndd.)
For SINIX systems:
Change the values of the network options TCPTV_KEEP_IDLE_SECS and TCPTV_KEEPINTVL_SECS with the following commands:
```
/etc/conf/bin/idtune TCPTV_KEEP_IDLE_SECS value
/etc/conf/bin/idtune TCPTV_KEEPINTVL_SECS value
```
(For details, type man idtune.) The default value is 2 hours and 10 minutes.
For other platforms:
See your TCP/IP documentation for details on configuring the KEEPALIVE setting. If it is not supported by the TCP/IP stack, then it is not used by DB2.

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 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, see 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.
At that same location, the IPX/SPX protocol tester, pcti, can be used to verify that the protocol works across the network.

SQL30081N on OS/2

Symptom

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

Possible Cause

The NetWare product is not functioning correctly because it was not installed properly, not configured properly, or corrupted.
There are not enough system resources to handle the request.

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.

[ ]

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, Windows, and OS/2 environment, and the DLL files in the OS/2 NETWARE directory are OS/2 DLL files. In some cases, Windows and OS/2 NetWare DLL files have the same name, but DOS and Windows cannot load or run OS/2 DLL files.

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:

128 sockets in the protocol stack ipx subsection
50 sessions in the protocol stack spx subsection

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

The net.cfg file is usually in the root directory. 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 Windows or OS/2 Client

Symptom: The SQL1109N error message is received when trying to connect from a Windows or OS/2 client.
Possible Cause: There are two versions of the NWCALLS.DLL and the 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 file 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 the NWCALLS.DLL file.

SQL5043N Received on Server for IPX/SPX

Symptom

The SQL5043N message is received on the server.

Possible Cause

IPX/SPX is not started on the server machine.
The database manager configuration is not correct. (For example, the fileserver, objectname, or ipx_socket parameters are not correct.)

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 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 changing database or node directories, you must use the TERMINATE command 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 configuration parameter nname in the server's database manager.
If these three names are not the same, you must recatalog the node entry at the client. See the Command Reference manual to find out more about the CATALOG command.

[ ]

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:

Select the Network icon from the Control Panel.
From the Services tab, select the NetBIOS interface.
Select Properties.
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 the DB2 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.

The NetBIOS protocol tester, pctn, can be used to verify that the protocol works across the network. The tester cna be found in the bin subdirectory of the sqllib directory.

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 use the DB2 Product and Service Technical Library on the Web, at http://www-4.ibm.com/software/data/db2/library/ for some suggested fixes. (Note that this information is in English only.)

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 Network Control Blocks (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:

Create the client's user name and password on the remote server.
Enable the Guest account at the remote server
Share the network resource of the remote server. For example, perform net use to access the server's network drive, where you can use a user name and password valid at the remote server.

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 Logical Unit (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?
See 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 ]