SQL30081N TCPIP communication errors

Technote (FAQ)


Question

This document lists SQL30081N TCP/IP communication protocol errors and recommended action plans associated with them.

Cause

The communication protocol errors depend on the platform you are working on. Each protocol error has its own definition and corresponding action plan.

Answer



For further discussion on this topic, visit this developerWorks forum thread:
https://www.ibm.com/developerworks/community/forums/html/topic?id=cceab3ae-4dd4-425a-af81-0b4e3f965ee2



Problem Details
The SQL30081N error message has the following format:

SQL30081N A communication error has been detected. Communication protocol being used: protocol . Communication API being used: interface . Location where the error was detected: location . Communication function detecting the error: function . Protocol specific error code(s): rc1 , rc2 , rc3 .

For example:
SQL30081N A communication error has been detected. Communication protocol
being used: "TCP/IP". Communication API being used: "SOCKETS". Location
where the error was detected: "". Communication function detecting the error: "connect".
Protocol specific error code(s): "111", "*", "*".

The following table lists protocol specific errors that can occur on different platforms and the corresponding action plans to resolve these errors.

Windows AIX SUN HP Linux Short Name Action Plan
10061 79 146 239 111 ECONNREFUSED

Connection Refused

Client attempts to establish a connection to server using an invalid IP or port.

Check on server side:

DB2 environment variable DB2COMM is set such as: DB2COMM=TCPIP

DBM CFG's SVCENAME is set to the instance's port number or service name. The command to update this parameter is: "db2 update dbm cfg using svcename <port/service name>"

If service name is set by checking 'services' file to see if the name corresponds to an unused port number.

Make sure DB2 server instance is started properly.

Check on client's side:

Node directory's entry:

Service name should show the right port number or service name that corresponds to DB2 server's instance port (svcename setting)

To check if server's port is opened:

telnet <hostname> <port>

If the command fails then the port on server is not opened and the problem is outside of DB2 area.

Additional technote on ECONNREFUSED:
http://www.ibm.com/support/docview.wss?rs=71&uid=swg21328644

Windows AIX SUN HP Linux Short Name Action Plan
10053 SOCECONNABORTED

Software caused a connection abort.

Software closed connection

If error is reported on client application which uses ODBC/CLI to connect to DB2 UDB server:

Disable DB2's CLI timeout:

Add 'QUERYTIMEOUTINTERVAL=0' to the db2cli.ini file on the client's side.

Check if applications have any timeout.

e.g. ADO timeout, VB timeout

If application connects to OS390 server, check idlethreadtimeout parameter (IDTHTOIN) on OS390.

This parameter sets the active thread timeout limit on OS390.

Windows AIX SUN HP Linux Short Name Action Plan
10054 73 131 232 104 ECONNRESET

Connection has been reset by partner

Connected partner has closed the connection.

Check any timeout limit on partner side.

E.g. Firewall, Application, DB2 CLI layer and etc

If error is reported on client application which uses ODBC/CLI to connect to DB2 UDB server:

Disable DB2's CLI timeout:

Add 'QUERYTIMEOUTINTERVAL=0' to the db2cli.ini file on the client's side.

Check if there's any firewall between client and server.

If it has any time limit on open connection

Check if applications have any timeout.

e.g. ADO timeout, VB timeout.


This error can also be caused by the issue described in technote_1395285

When a local database connection is catalogued using a different alias name than the database name, you might get error SQL30081 when you try to connect to that database using a TCPIP connection.

If you get that error when when you try to connect to a database, make sure that on the machine where that database resides the database is not catalogued using a different alias name than the database name.

Windows AIX SUN HP Linux Short Name Action Plan
10060 78 145 238 110 ETIMEDOUT

Connection timeout

Connection has reached the network timeout limit and is terminated by network

Timeout by tcpip layer

TCPIP has its own timeout value, if the open connection stayed too long, TCPIP will force the connection off.

Usually this is network issue

Check TCPIP's KEEPALIVE setting

see note1

Windows AIX SUN HP Linux Short Name Action Plan
10048 67 125 226 98 EADDRINUSE

The specified address already in use

A: 2 instances are starting on the same machine listening on the same port (usually would trap on db2start)

B: A client application or agent is making an outgoing connection attempt and is using a socket that is already being used by another connection to the database or is in the wait state (2MSL state).

Usually only happens to Windows client:

This is a Microsoft error. Winsock has given a port that is already in use (winsock defect) or is closed but still waiting in the wait state.

Workaround for Windows:

1. Adjust the time so that a socket sits in wait state after being closed (default is 2 minutes)

TcpTimedWaitDelay

see Note 3

2. Adjust the number of ports available (default is 5000)

MaxUserPort

see Note 4

3. Adjust the use of connect / disconnect so that it doesn't cycle so rapidly in the program (best solution). 10048 is most often caused by rapid connection / disconnection logic in the application, which puts too many ports in the time_wait state (2MSL). Re-using the connection handle when an application is issuing multiple statements is the best way of handling this (do not disconnect then reconnect every time a statement completes)

4. Implement client side connection pooling so that the application logic internally does not have to change. Make sure the pool is large enough to handle 80% of the connections. Make sure the pool has some form of re-connect logic in the case of a disconnect while idle.

Windows AIX SUN HP Linux Short Name Action Plan
10055 74 132 233 105 ENOBUFS

No buffer space available

System running out of resource to complete the TCPIP call

For Windows:

The problem is caused by running out of Windows desktop heap or system page table entries. It is not DB2 related.

Increase the Windows SystemPages registry entry.

Windows Short Name Action Plan
10065 WSAEHOSTUNREACH No route to host

For Windows client, Linux server:

Unset firewall on Linux server to allow connections to go through from clients.
Note 1: From DB2 manual explained more what KEEPALIVE does and how we use it.

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.

Note 2:

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 the following:

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

Note 3:

This parameter determines the length of time that a connection stays in the TIME_WAIT state when being closed. While a connection is in the TIME_WAIT state, the socket pair cannot be reused. This is also known as the 2MSL state because the value should be twice the maximum segment lifetime on the network. See RFC 793 for further details.

Note 4:

This parameter controls the maximum port number used when an application requests any available user port from the system. Normally, short-lived ports are allocated in the range from 1024 through 5000. Setting this parameter to a value outside of the valid range causes the nearest valid value to be used (5000 or 65534).

Note 5:

For other TCPIP messages.
V8.2: http://publib.boulder.ibm.com/infocenter/db2luw/v8//topic/com.ibm.db2.udb.doc/core/rcommsec.htm
V9.1: http://publib.boulder.ibm.com/infocenter/db2luw/v9/topic/com.ibm.db2.udb.msg.doc/doc/rcommsec.htm
V9.5: http://publib.boulder.ibm.com/infocenter/db2luw/v9r5/topic/com.ibm.db2.luw.messages.doc/doc/r0052008.html
V9.7:
http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/topic/com.ibm.db2.luw.messages.doc/doc/r0052008.html
V9.8:
http://publib.boulder.ibm.com/infocenter/db2luw/v9r8/topic/com.ibm.db2.luw.messages.sql.doc/doc/msql30081n.html
V10.1:
http://publib.boulder.ibm.com/infocenter/db2luw/v10r1/topic/com.ibm.db2.luw.messages.sql.doc/doc/msql30081n.html



For further discussion on this topic, visit this developerWorks forum thread:
https://www.ibm.com/developerworks/community/forums/html/topic?id=cceab3ae-4dd4-425a-af81-0b4e3f965ee2

Rate this page:

(0 users)Average rating

Add comments

Document information


More support for:

DB2 for Linux, UNIX and Windows
Connectivity - TCP/IP Protocol

Software version:

9.5, 9.7, 10.1, 10.5

Operating system(s):

AIX, HP-UX, Linux, Solaris, Windows

Software edition:

DB2 UDB Express, Enterprise, Personal, Workgroup

Reference #:

1164785

Modified date:

2010-01-14

Translate my page

Machine Translation

Content navigation