SQLCODE -30081: Communication error detected

What it means

Most people see this code as SQL30081N from a Db2 client, Db2 Connect or an ODBC, CLI or .NET application. Db2 for z/OS returns -30081 too, when it acts as a requester over DDF. In every case Db2 is passing on an error from TCP/IP.

The client form reads roughly like this. A communication error was detected, then the protocol (TCP/IP), the API (SOCKETS), the location (the partner's IP address), the function that failed, and up to three error codes. The first code is the errno from the socket call. On Windows it's a WSA error number. The function and the first code together tell the story.

• connect, ECONNREFUSED (10061 on Windows, 111 on Linux, 79 on AIX). Nothing accepted the connection on that host and port.
• connect, ETIMEDOUT (10060 on Windows, 110 on Linux, 78 on AIX). No answer before the timeout. Often a wrong address or a firewall that drops packets.
• recv, ECONNRESET (10054 on Windows, 104 on Linux, 73 on AIX). The other side or something in between broke an existing connection.
• recv, ETIMEDOUT. An existing connection stopped answering. A client query timeout can also cause this.
• rc1 and rc2 of *, rc3 of 0. The remote side closed the connection.

On Db2 for z/OS the message shows the TCP/IP return code in decimal and the reason code in hex. The z/OS UNIX values differ from other systems. ECONNRESET is 1121, ETIMEDOUT 1127 and ECONNREFUSED 1128. Db2 for z/OS usually writes a DSNL511I message with the same codes on the console. Db2 for i reports this as SQ30081. Java programs using the IBM Data Server Driver for JDBC and SQLJ usually get ERRORCODE=-4499 instead.

Common causes

• The host name, IP address or port in the client's catalog or connection string is wrong.
• The Db2 server or DDF isn't started, or isn't listening on the expected port.
• A firewall blocks the port or drops idle connections.
• A connection pool hands out a connection that the server, a firewall or a load balancer closed while it sat idle.
• Db2 for z/OS cancelled the server thread, for example through CANCEL THREAD or an idle thread timeout, which resets the client's connection.
• The server is overloaded or the network is slow, so connect or receive calls time out.

How to find the problem

1. Read the function and the first error code. A connect failure points at addressing or the listener. A recv failure points at a connection that dropped later.
2. Check the catalog entry or connection string. On a Db2 client, db2 list node directory shows the host and port for each node.
3. Test the path from the client with a simple TCP check to the host and port, and ask the network team about firewalls.
4. On Db2 for z/OS, check that DDF is up with -DISPLAY DDF, which shows the TCP/IP port, and look on the console for DSNL511I around the time of the error.
5. For recv resets, check the z/OS console for idle thread timeouts and cancelled threads, and check the timeout settings of any firewall or load balancer.

How to fix it

• Correct the host, IP address or port in the client catalog or connection string.
• Start the Db2 server or DDF, and make sure the port the client uses is the one the server listens on.
• Open the port in the firewall, or raise its idle timeout above how long connections sit unused.
• Have the connection pool validate connections before use and retry once on a communication error.
• Close cursors and connections promptly so idle thread timeouts on z/OS don't cut off active work.

Technical reviewer: Albert Joseph, WND Software.

Last reviewed 2026-10-18 by the WND Software team. Written in our own words. For the full reference, check IBM’s Db2 for z/OS documentation for your release.