Troubleshooting FTP Return Code = 10000 Error Code = 00008
Article ID: 416253
Updated On:
Products
Issue/Introduction
When running an FTP batch job to send or receive files with Broadcom support servers, such as supportsomeFTPserver.example.com or someFTPserver.example.com, one error that comes from a user configuration error is seen in the following messages. For this article, the server name will be someFTPserver.example.com, and the IP address of that server will be 192.168.169.170 in the messages.
EZA1456I Connect to ?
EZA1736I someFTPserver.example.com 21
EZA1554I Connecting to: someFTPserver.example.com 192.168.169.170 port: 21.
EZA2590E connect error from initIPv4Connection - EDC8127I Connection timed out.
EZA1735I Std Return Code = 10000, Error Code = 00008
This article will explain the problem and provide some ways to help identify the error.
Environment
z/OS, FTP
Cause
The root cause for these messages lies within the customer environment or access path to the Broadcom servers.
Resolution
These messages indicate that your initial connection never took place. Here is an analogy to explain what is supposed to happen.
Imagine two people: Client and Server. They live in different houses somewhere down the street (their IP addresses). The Client wants to start a conversation with the Server. Here is how it starts:
- Client knocks on the door and says, “Hi, I’d like to talk!” (This is the SYN packet — synchronize request)
- Server opens the door and replies, “Hi! I heard you. I’m ready to talk. Can you hear me?” (This is the SYN-ACK packet — acknowledge + synchronize)
- Client responds, “Yes, I hear you. Let’s talk!” (This is the ACK packet — final acknowledge)
- Then, the conversation officially begins, and they can now begin to exchange information (data packets).
In this case, you tried to connect to someFTPserver.example.com, but no one opened the door. There could be several reasons for this:
- The server never opened the door, or
- The knock never reached the house, or
- There’s a firewall guard in the yard blocking people from knocking.
Before going further, I would try to run the job again, in case there was some sort of connectivity or timing issue. In some cases, running the job a second time is successful.
If not, then here is how you can identify the problem area:
1. From your TSO session, you can try to issue command: TSO PING someFTPserver.example.com<enter>. This will work, and you will see a response like this:
CS 3.1: Pinging host SOMEFTPSERVER.EXAMPLE.COM (192.168.169.170)
Ping #1 response took 0.058 seconds. (58.252 milliseconds)
2. If you can't issue the TSO command, you can run the Ping in a batch job like this:
//PING EXEC PGM=IKJEFT01,REGION=0M
//SYSTSPRT DD SYSOUT=*
//SYSTSIN DD *
ping someFTPserver.example.com (Verbose Timeout 5
/*
This will give a response like #1, above, with 3 PING responses.
If you get only a TIMEOUT, and no responses, then you need to contact your network team to help unblock this server in your firewall product. If it works and you get timing responses, then continue on.
3. Now, you can try TSO tracerte someFTPserver.example.com<enter> (or tracerte 192.168.169.170). If this works, you will see a list of "hops" that your request makes as it passes from your mainframe to various routing servers, until it finally winds up at the destination. You will see a bunch of lines as shown in this example with simulated IP addresses:
CS 3.1: Traceroute to someFTPserver.example.com (192.168.169.170):
1 172.16.17.18 (172.16.17.18) 1 ms 0 ms 0 ms <-- this is your local IP address
2 192.18.19.20 (192.18.19.20) 2 ms 1 ms 1 ms
. . .
12 192.168.169.170 (192.168.169.170) 58 ms 55 ms 58 ms
If your last line is not 192.168.169.170 (or the address of the server you want to reach), then the connection is broken somewhere along the way. You will need to contact your network team with the Ping and the Tracerte output so they can see where the problem might be.
4. One other thing you can check is that your system has the correct IP address for the server. You would need to lookup your DNS cache entry using the TSO command TSO nslookup someFTPserver.example.com<enter>. You might get several lines of information, but the last pair should show:
EZB3170I Name: someFTPserver.example.com
EZB3172I Address: 192.168.169.170
In a majority of the cases we have addressed, the problem has been with missing or incorrect configuration details in the customer firewall product.
Additional Information
For further assistance with this FTP error or other mainframe FTP problems, please email the Mainframe FTP Support team, or contact your product support team.
Feedback
