Troubleshooting Guide

Troubleshooting Tips for DB2 Connect

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

"Initial Questions"
"Cannot Make Initial Connection After Installation"
"Problems Encountered After Initial Connection"
"DB2 Connect Connection Using SNA Does Not Work"
"Changing Number of Connections"
"Authentication Problems"

Initial Questions

The client/server environment involves multiple software, hardware, and communications products, including DB2 Connect. When a problem occurs in host communications, troubleshooting is best approached by asking the following questions:

Can you establish a session with a host?

[ ]: See "Troubleshooting Host Connections".
[ ]: For SNA sessions, see "DB2 Connect Connection Using SNA Does Not Work".

If you can communicate with the host, is the problem with DB2 Connect?

[ ]: Can you get a connection from a standalone client to your DB2 Connect Enterprise Edition gateway? If not, see Chapter 3. "Troubleshooting on the Client".)

Cannot Make Initial Connection After Installation

Initial connection means the first attempt to connect to a host server after installation. If the initial connection fails, review the following questions to ensure that the DB2 Connect installation steps were followed:

Did the installation processing complete successfully?

[ ]

Did you configure APPC on DB2 Connect clients as described in Installing and Configuring DB2 Clients?

[ ]

Were all the prerequisite software products installed?

For example, if it did not already exist on the operating system, was the communications software completely installed without any error conditions?

[ ]

Was DB2 Connect Enterprise Edition installed to enable support for remote clients?

Was a DB2 instance created?

[ ]: To check that an instance was created, get a list of instances with the db2ilist command. If there are no instances, or if you need to make another one, use the db2icrt command. (For information, see the chapter on working with instances in the DB2 Connect Enterprise Edition Quick Beginnings.)

Were the host and workstation communications configured correctly?

[ ]: See "Troubleshooting Host Connections" and, for SNA sessions, "DB2 Connect Connection Using SNA Does Not Work".

Do you have the level of authority required by the host database management system to use the host database?

[ ]: Did you sign on with the correct authority to access tables? (See the DB2 Connect Enterprise Edition Quick Beginnings.)

Problems Encountered After Initial Connection

If you installed a client and could make an initial connection, but then experience a problem with it later, use the following checklist as a starting point to narrow down the scope of the problem.

Can you establish a host session?

[ ]: See "Troubleshooting Host Connections" and, for SNA sessions, "DB2 Connect Connection Using SNA Does Not Work".
[ ]: If you suspect a problem with your communication protocol, see Chapter 3. "Troubleshooting on the Client".

Are there any special or unusual operating circumstances?

[ ]: Is this a new application?
[ ]: Are new procedures being used?
[ ]: Have any of the software products or applications been changed since the application or scenario last ran successfully?
[ ]: For application programs, what application programming interfaces (APIs) are called?
[ ]: Have other applications that use the software or communication APIs been run on the user's system?
[ ]: Are there recent changes that might be affecting the system? For example, has maintenance been applied?

Is there relevant diagnostic information?

[ ]: Were any SQL messages or SQL states returned? To look up an SQL state or SQL code, see the Message Reference.
[ ]: Check the db2diag.log file on the server, particularly for SQLCA information. (See "Understanding First Failure Data Capture".)

DB2 Connect Connection Using SNA Does Not Work

Use the following checklist as a starting point to narrow down the scope of an SNA problem when using DB2 Connect.

Is the SNA session active?

[ ]: Is the SNA software started on the gateway?
[ ]: Is the SNA software started on the host? (For example, is the DDF facility started on DB2 for MVS/ESA?)

Is SNA information correctly configured?

[ ]: Is APPC configured properly? (See "Using the APPC Protocol".)
[ ]: If DB2 Connect Enterprise Edition gateways are used, check the communications configuration (for example, SNA Server for AIX, Communication Server (formerly Communications Manager) for OS/2, IBM Communication Server for Windows NT, or Microsoft SNA Server for Windows NT).
[ ]: Is the host correctly configured? For example, is VTAM configured on MVS and VM systems? For information, see DB2 Connect Enterprise Edition Quick Beginnings.

Is the DB2 Connect information correct?

[ ]: Are the node, system database, and DCS directories configured?
[ ]: Are the DB2INSTANCE and PATH variables correct?

Is the logon information correct? (If not, the SQL30082N message is usually received.)

[ ]: Has the DRDA AS password expired?
[ ]: Have related CDB tables been updated correctly on DB2 for MVS/ESA?

Changing Number of Connections

To change the number of connections that a DB2 Connect Enterprise Edition gateway supports:

Change the session limit within the mode definition.
Define the session limit in the APPLID definition for the DB2 subsystem in VTAM (for DB2 for MVS/ESA and DB2 for VM host sessions).
Change the MAXDBAT parameter in the DSNZPARM dataset for DB2 for MVS/ESA.
Check the maximum number of database manager agents specified with the DB2 database manager configuration parameter maxagents.

VTAM and Communications Server will negotiate how many DRDA connections are allowed (with a minimum of two). DB2 for MVS/ESA will only allow the number of connections defined in the DSNZPARM dataset.

Authentication Problems

Your operating system and communications products may affect the authentication of DB2 Connect sessions. For information, see the Administration Guide.

Note that:

User names and passwords may be case sensitive. In particular:
- For DB2 for MVS/ESA, user names and passwords may be case sensitive depending on which PTFs were applied.
- Passwords on UNIX-based environments are always case sensitive.
- If OS/2 uses User Profile Manager (UPM), user names and passwords are converted to uppercase. This may be an issue if you are using a DB2 Connect Enterprise Edition gateway on a UNIX machine.
For NetBIOS connections, when you set up a connection to a host from any client via a DB2 Connect Enterprise Edition gateway, the user name and password are passed through to the target server for verification. For example, authorization is always forced to DB2 for MVS/ESA.
Because of this behavior, note that DCS authentication does not apply for the NetBIOS protocol: only SERVER authentication should be used.

SQL1403N when issuing a connect to DB2 for MVS/ESA

Symptom: The SQL1403N message occurs when a DB2 Connect client tries to connect to DB2 for MVS/ESA using DCS authentication.
Possible Cause: System tables are not set up correctly in DB2 for MVS/ESA to process the incoming request.
Action: Ensure that entries are correct in the SYSIBM.SYSLUNAMES and SYSIBM.SYSUSERNAMES tables.
For more information, see the MVS Server worksheet in the DB2 Connect Enterprise Edition Quick Beginnings.

SQL1402N and SQL30082N when connecting to DB2 for MVS/ESA

Symptom

The messages SQL1402N and SQL30082N are received when a client tries to connect to DB2 for MVS/ESA using DB2 Connect.

Action

Specify DCS authentication on your DB2 Connect Enterprise Edition gateway.

If you use SERVER authentication with an OS/2 server, ensure that the user name and password are also defined on the OS/2 server.

Note that the Control Center always assumes SERVER authentication, so you must use the command line processor to set other authentication types.

Windows Clients Won't Connect

Symptom

The message SQL30073N is received with reason code X'119C' when a Windows client tries to connect to a host database.

Possible Cause

Your host does not recognize the code pages used by your client because either:

The host cannot support them.
The host was not set up to support them.
The host requires a PTF to be applied.

Action

If possible, enable the necessary code page support on your host.

If you cannot enable this support, a workaround is to use the DB2CODEPAGE keyword in your client's configuration. For more information, see the section on configuring national language support in the DB2 Connect Enterprise Edition Quick Beginnings.

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

[ DB2 List of Books | Search the DB2 Books ]