EDC8127I timed out / EDC8130I host cannot be reached

The client got no answer (timed out) or had no route to the host. Unlike 'connection refused', these point to the path between the systems.

What happened

A TCP connect or socket operation from z/OS failed after a delay with EDC8127I Connection timed out (errno ETIMEDOUT, 1127), or quickly with EDC8130I Host cannot be reached (EHOSTUNREACH, 1130). In both cases the request failed but the application kept running, so what happens next depends on its error handling.

Application log (illustrative)Illustrative example

MPFTPX01 CONNECTING TO PARTNER.EXAMPLE.COM (192.0.2.17) PORT 21
MPFTPX01 connect() failed: errno=1127 EDC8127I Connection timed out.
MPFTPX01 RETRY 1 OF 3 ...
MPFTPX01 connect() failed: errno=1130 EDC8130I Host cannot be reached.

What it means

EDC8127I — the remote side did not respond within the timeout set by the socket's protocol. Nothing came back: not an accept, not a refusal.
EDC8130I — there was no route to the remote node. IBM gives an incorrect address, a wrong routing table or a network hardware problem as possible causes.

Compare with EDC8128I Connection refused, where the host did answer but nothing was listening on the port.

Typical causes

The remote host is down or the address is wrong.
A firewall that silently drops the traffic (gives a time-out rather than a refusal).
A missing or wrong route in the TCP/IP stack routing table, or an interface that is inactive.
Name resolution returning an old or wrong address.

Symptoms

Time-outs take noticeable time per attempt, because the client waits for the protocol timeout.
Several applications going to the same destination fail together.
Other destinations from the same LPAR may work fine.

Where to look

The application message for the exact address and port.
Netstat on z/OS: TSO NETSTAT ROUTE or z/OS UNIX netstat -r for the routing table; NETSTAT DEVLINKS / netstat -d for interface status; NETSTAT HOME / netstat -h for local addresses.
The stack's job log and console messages for interfaces going inactive.
Firewall and network team change records.

How to diagnose

Confirm the target address — resolve the name again and compare.
Check that z/OS has a route to that network and that the interface is active.
Test reachability with the tools your site approves for this.
If the route is fine, ask the network team to check firewalls between the systems for that port.

How to fix

Correct the address or name resolution, restore the interface or route, or get the firewall rule opened through change control. Then rerun or let the application retry. If the remote host is down, coordinate with its owners rather than retrying in a tight loop.