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:

"Determining the Scope of a Client Problem"
"Cannot Make Initial Connection After Installation"
"Clients Suddenly Experiencing Problems"
"User Name Not Valid on Windows 95"
"Using the TCP/IP Protocol"
"Using the IPX/SPX Protocol"
"Using the NetBIOS Protocol"
"Using Named Pipes"
"Using the APPC Protocol"

For related information, see:

The Quick Beginnings guide for your platform
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

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

When you have a problem with a client, you must start with the following questions, which will help you determine exactly where a problem is occurring:

[ ]: Were the client and server installed correctly?
[ ]: Are the communication products installed and operational on the client and server?
[ ]: Is the problem on one or many clients?
[ ]: Did the client function correctly in the past?
[ ]: Is the database manager started on the server with appropriate communications listeners?
[ ]: Can you get a connection from the client to another server?
[ ]: Can you get a connection from another client to the server?

This section helps you address these questions by explaining how to test connections to the server and use the db2diag.log file to verify if communications listeners are started.

Testing connections on the server

If you are having problems with a client connection, try testing 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 probably with the server.
Test a loopback connection. That is, try a remote connection on the server using the same protocol as on the client. Catalog a database on the server with a node directory entry that references the server machine, and then try the connection from the server to itself.
- If the connection works, then the problem is with 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 communication protocol or protocols are not started on the server
  - The LAN network is not working

It is recommended that you keep the directory entries you set up on the server so that you can use this technique to diagnose connectivity problems whenever they come up.

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 "Understanding First Failure Data Capture" for details on using this file.

For example, you may receive the SQL5043N message after issuing db2start on the server, indicating that one or more protocols failed to start successfully. The db2diag.log file may provide additional information in this situation.

The following steps provide a procedure for you to follow when looking for the cause of server problems that may be affecting your clients:

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 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 8. "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. Refer to the following sections for checklists:
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.

Cannot Make Initial Connection After Installation

"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, review the following checklist to ensure that the installation steps were followed:

[ ]

Were the client and server 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:

For OS/2, Windows 95, and Windows NT, 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.)
For Windows 3.1, logs are kept in \db2log\db2.log, in the drive where Windows is installed.

[ ]

Were all the prerequisite software products installed?

[ ]

Are the communication products installed and operational?

[ ]

Can you get a connection from another client to the server?

If you can, you know that the server is working. If you cannot, the problem may be with the network or the server.

[ ]

Can you get a connection from the client to another server? If you can, then the client is working.

Clients Suddenly Experiencing Problems

If you suddenly encounter a problem with one or more clients that could previously connect to the server, review the following questions to narrow down the scope of your problem.

Is it just a single client that is experiencing difficulties?

[ ]: Can other network-enabled applications run on this client? If not, the problem is probably 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.
[ ]: Have there been recent changes to the client that might be affecting it? (For example, was another product or fix pack installed?)
[ ]: Have you exceeded resource limits on the client (for example, memory)?

Is more than one client experiencing difficulties?

[ ]: Is the LAN available? For example, can you use World Wide Web browsers, 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.
[ ]: Have you exceeded resource limits on the server (for example, memory)?

User Name Not Valid on Windows 95

Symptom

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

Possible Cause

If you or an application you are using do not specify a user name and password as part of a CONNECT statement, an implicit user name and password are used. (That is, the user name and password that you specified when you logged on to the operating system are passed with the CONNECT statement.) The implicit user name and password may be incorrect, causing the CONNECT statement to fail.

Note that Windows 95 allows you to log on without a user name and password. In this situation, the implicit user name and password are null, and the CONNECT statement will fail.

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 Quick Beginnings for Windows NT guide.

Using the TCP/IP Protocol

This section covers some common troubleshooting tips related to the TCP/IP communication protocol.

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 machines).

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").

[ ]

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 for Windows NT, Windows 95, or OS/2 operating systems
The DB2 Client Setup window on the Windows 3.1 operating system
The CATALOG DATABASE and CATALOG TCPIP NODE commands (see the Command Reference).

[ ]

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.

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 is not correct.)
The TCP/IP services file is not correct. (For example, the svcename in the database manager configuration is not defined in the file.)

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 that the KEEPALIVE settings affect all TCP/IP applications running on the machine.

For Windows NT and Windows 95:
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.

Using the IPX/SPX Protocol

This section covers some common troubleshooting tips related to 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. 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 misc subdirectory of the sqllib directory.

SQL30081N on OS/2 or Windows 3.1

Symptom

For OS/2 and Windows 3.1, the SQL30081N message is received with the function "t_open" 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 where you boot from. Alternatively it may be in the NWCLIENT directory on Windows 3.1.

[ ]

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:

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 where you boot from. Alternatively it may be in the NWCLIENT directory for Windows 3.1 or 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

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

Action

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

Using the NetBIOS Protocol

This section covers some common troubleshooting tips related to the NetBIOS communication protocol. Note that 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 a cause. Note that 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".)

[ ]

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, verify that NetBIOS is a supported protocol. (Use the db2set db2comm command.)
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:

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 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 timeout 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 NT and Windows 95 operating systems, the NetBIOS network control settings
- For DOS or Windows Version 3.1, the config.sys file or the autoexec.bat file
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.

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.

Using the APPC Protocol

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?
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 | Table of Contents | Index ]

[ DB2 List of Books | Search the DB2 Books ]