EDC8128I Connection refused (ECONNREFUSED, errno 1128)

The client reached the remote host, but nothing accepted the connection on that port. Check the server is up and listening on the address and port you used.

What happened

A program on z/OS — a batch job, an FTP client, a z/OS UNIX tool, a Java or C application — tried to open a TCP connection and the connect failed at once with EDC8128I Connection refused. On z/OS this is errno ECONNREFUSED, decimal 1128 (X'0468').

Batch job output (illustrative)Illustrative example

MPSEND01 CONNECT TO 10.1.20.45 PORT 8443
MPSEND01 connect() failed: errno=1128 (EDC8128I Connection refused.)
MPSEND01 ENDING RC=12

What it means

IBM's errno table describes ECONNREFUSED as: the attempt to connect was rejected. In plain TCP terms, the packet reached a host, but no program was accepting connections on that address and port, so the host refused it. It differs from:

EDC8127I Connection timed out (ETIMEDOUT, 1127) — no answer at all within the timeout.
EDC8130I Host cannot be reached (EHOSTUNREACH, 1130) — no route to the remote node.

Some messages add an errno2 reason code; keep it, as IBM support uses it to pinpoint the exact path that failed.

Typical causes

The server program or started task is down or still starting.
Wrong port or address in the client configuration.
The server is listening only on a different IP address (for example a VIPA or only localhost).
On a busy system, the client tried before a slow-starting server was listening (IBM documents this pattern for an HTTP server plug-in).

Symptoms

The failure is immediate — no waiting, unlike a time-out.
Every connection attempt fails the same way until the server is back.
Other ports on the same host may work.

Where to look

The client's message for the exact address and port used.
On the server side, whether the listener is active. On z/OS, Netstat shows it: TSO NETSTAT ALLCONN or NETSTAT SOCKETS, z/OS UNIX netstat -a, or the console D TCPIP,,NETSTAT,ALLCONN. A listener shows state Listen with a remote address of zeros.
The server's job log in SDSF for start-up errors.
The configuration for the port (client properties, PROFILE.TCPIP PORT reservations).

How to diagnose

Confirm the address and port the client really used.
On the server, check that the program is running and that Netstat shows it in Listen state on that port and address.
If it listens on a specific IP, check that the client connects to that one.
If the listener is present, try from another client to rule out a filter in between.

How to fix

Start or restart the server, or correct the port/address in the client configuration. If the server binds to the wrong address, fix its configuration. Then retry the client; the error clears as soon as something accepts on that port.