Question
This document lists some SQL30081N TCP/IP communication protocol errors and recommended action plans associated with them.
Cause
The protocol error is dependent on the platform. Each protocol error has its own definition and corresponding action plan.
Answer
Problem Details
The SQL30081N error 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 platform and their action plan to resolve the problem.
cf) db2diag.log (HP)
2011-10-11-15.17.32.470470+540 E8945037A747 LEVEL: Error
PID : 17111 TID : 1 PROC : db2sysc
INSTANCE: *** NODE : 000 DB : ******
FUNCTION: DB2 UDB, XA DTP Support, sqlxaConnect, probe:4666
MESSAGE : XA Interface SQLCA
DATA #1 : SQLCA, PD_DB2_TYPE_SQLCA, 136 bytes
sqlcaid : SQLCA sqlcabc: 136 sqlcode: -30081 sqlerrml: 45
sqlerrmc: 239 * * TCP/IP SOCKETS 172.16.250.42 connect
sqlerrp : SQLJCMN
sqlerrd : (1) 0x81360012 (2) 0x00000012 (3) 0x00000000
(4) 0x00000000 (5) 0x00000000 (6) 0x00000000
sqlwarn : (1) (2) (3) (4) (5) (6)
(7) (8) (9) (10) (11)
sqlstate:
| Windows | AIX | SUN | HP | Linux | Short Name | Action Plan |
| 10061 | 79 | 146 | 239 | 111 | ECONNREFUSED
Connection Refused | Client attempts to make connection to server using an invalid IP/port
Check server side: DB2 environment variable DB2COMM is set: 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, please check 'services' file see if the name corresponds to an unused port number Make sure db2 server instance is started properly Check client's side: Node directory's entry: Service name should show the right port number/service name corresponds to db2 server's instance port (svcename setting) To check if server's port is opened: telnet <hostname> <port> If fails then the port on server is not opened and the problem is outside of DB2 area. Additional technote on ECONNREFUSED: |
| 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. Please disable DB2's CLI timeout: Add 'QUERYTIMEOUTINTERVAL=0' on client's side's db2cli.ini file Check application if they have any timeout. e.g. ADO timeout, VB timeout If application connects to OS390 server, please 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. Please disable DB2's CLI timeout: Add 'QUERYTIMEOUTINTERVAL=0' on client's side's db2cli.ini file Check if there's any firewall between client and server. If it has any time limit on open connection Check application if they have any timeout. e.g. ADO timeout, VB timeout.
|
| 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 their 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 happen 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 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 (don't disconnect then reconnect every time a statement completes) 4. Implement client side connection pooling so that the application logic internally doesn't 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. |
| |
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:
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 nettunecommand (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