Troubleshooting Guide

Troubleshooting Host Connections

The error message SQL30081N is the most common error returned when setting up connections. If you are receiving this error message, the following points provide troubleshooting guidance.

Direct Connection

In this case, you are connecting directly from a DRDA requestor to a DRDA server with no DB2 Connect gateway in between.

Note:

A DB2 Client (CAE) cannot make a direct connection to a DRDA server. A DB2 Connect gateway is needed. For more information on troubleshooting in this scenario, see Gateway Connection.

TCP/IP Connection

[  ]

Can you ping the DRDA server?

If you cannot:

• Verify the IP address
• Ensure that TCP/IP is active at both the DRDA requestor and the DRDA server
• Consult your Network Administrator

If you can: Continue to the next question.

[  ]

Are the port number and service name properly defined?

• Did you use the DRDA default port number 446?
• Ensure the services file is updated correctly if you are using the service name instead.

[  ]

Can any DRDA requestor connect to this DRDA server?

If none can:

• Ensure that the server DBMS is active (that the DDF is started).
• Verify the limits.
• Verify the server's zparm MAXDBAT is set to a value greater than zero. The default is zero.
• Verify the startup message appears in the logs.

If at least one can:

• Verify that you are connecting to the right DRDA server.
• If DB2 Connect is the requestor, verify the catalog information. Ensure the database is cataloged with the authentication as DCS; and that the DCS directory and the node directory are cataloged.
• The SQL1403N authentication error is always returned from a distributed environment such as UNIX, OS/2, or Windows operating system. The SQL30082N authentication error is returned from a DRDA Application Server (AS) such as DB2 for OS/390 or DB2 for AS/400. If you see a SQL1403N error when connecting to a DRDA AS and are not trying to authenticate on the gateway, you may not have the database authentication set to DCS.

SNA Connection

[  ]

Can you manually establish a SNA link?

If you cannot:

• Verify the LAN destination address
• Verify the partner node ID and node type
• Ensure the communication controller is working

If you can: Continue to the next question.

[  ]

Can you manually establish a SNA session?

If you cannot:

• Verify the SNA configuration. Ensure all logical unit (LU) and physical unit (PU) names are correct.
• Verify the correlating VTAM definition.
• Check the SNA configuration. It should be one of: SNA Server for AIX, Communications Server (formerly Communications Manager) for OS/2, IBM Communications Server for Windows NT, or Microsoft SNA Server for Windows NT. See Quick Beginnings for information on how to configure SNA.
• Contact your SNA vendor support organization.

If you can: Continue to the next question.

[  ]

Can any DRDA requestor connect to this DRDA server?

If none can:

• Ensure that the server DBMS is active (that the DDF is started).
• Verify the limits.
• Verify the server's zparm MAXDBAT is set to a value greater than zero. The default is zero.
• Verify the startup message appears in the logs.

If at least one can:

• Verify that you are connecting to the right DRDA server.
• If DB2 Connect is the requestor, verify the catalog information. Ensure the database is cataloged with the authentication as DCS; and that the DCS directory and the node directory are cataloged.

Gateway Connection

If you are connecting from DB2 clients to a DRDA server using a DB2 Connect gateway:

[  ]

Can you connect to the DRDA server from the DB2 Connect gateway?

If you cannot, see Direct Connection.

If you can: Continue to the next question.

[  ]

Is the DB2 registry variable DB2COMM set properly at the DB2 Connect gateway?

It should be set to APPC, TCPIP, or both, depending on which protocol you are using.

[  ]

Verify the catalog information on the client.

Please see Chapter 3, Troubleshooting on the Client for additional information.