Troubleshooting
Problem
The FTP daemon appears to hang. The "EZY2702I Server-FTP: Initialization completed at
Cause
During the initialization process, the FTP daemon makes a gethostbyname() or getaddrinfo() call to obtain IP address information needed by the daemon. If, for any reason, these calls do not complete in a timely manner, the hanging scenario described above will occur. Additionally, this gethostbyname() or getaddrinfo() call must complete before the FTP daemon can bind to a port. As such, if the daemon has been AUTOLOGged, the hang will prevent the daemon from establishing a listen before AUTOLOG cancels the daemon and restarts it. The following events might prevent the gethostbyname() or getaddrinfo() call from completing:
1. A resolver configuration that specifies a combination of domain name servers, timeout values, and retries that could potentially result in a very large overall timeout period. For example, consider the following resolver configuration statements (which could be specified in either the TCPIP.DATA data set, or in the resolv.conf HFS file):
NSINTERADDR 1.2.3.4
NSINTERADDR 5.6.7.8
NSINTERADDR 9.10.11.12
RESOLVERTIMEOUT 60
RESOLVERUDPRETRIES 3
In this example, if anything were to occur that would prevent UDP requests from being delivered to the three defined nameservers, twelve minutes would pass before the gethostbyname() or getaddrinfo() call completed. Each round of failures would consume three minutes; one for each nameserver. There would be four rounds of attempts made; the initial round plus three retries.
2. The use of a resolver configuration file other than the one intended could also cause a similar problem. It could be possible that the unintended files point to obsolete or invalid nameservers. Again, given the combination of the other statements in the file, this could lead to a large timeout period.
Resolving The Problem
As there can be numerous causes of such a problem, there are many possible solutions as well. The following checklist can help you narrow down the issue, and at the least enable you to work around the problem.
1. Ensure that the correct resolver configuration file is used by the FTP daemon. Each TCPIP application uses the following search order to locate a resolver configuration file:
GLOBALTCPIPDATA
RESOLVER_CONFIG environment variable
/etc/resolv.conf
SYSTCPD DD-name
userid.TCPIP.DATA
jobname.TCPIP.DATA
SYS1.TCPPARMS(TCPDATA)
DEFAULTTCPIPDATA
TCPIP.TCPIP.DATA
As such, any TCPIP.DATA which precedes the file intended for use by FTP will be used. To change this, either remove the erroneous TCPIP.DATA, or rename FTP's TCPIP.DATA such that it precedes the erroneous one in the search order. The easiest way to do this is to set the RESOLVER_CONFIG environment variable in the JCL used to start the FTP daemon. Two examples of doing this (one using an MVS data set, and one using an HFS file) are as follows:
ENVAR("RESOLVER_CONFIG=//"TCPIP.TCPPARMS(TCPDATA)"")
ENVAR("RESOLVER_CONFIG=/tmp/resolv.conf")
2. If the correct TCPIP.DATA file is being used, ensure that the nameservers pointed to by the NSINTERADDR or NAMESERVER statements are correct. It is also important to PING these servers to ensure that they are responding. If they are responding, then a resolver trace should be obtained to better understand why the FTP gethostbyname() or getaddrinfo() call is failing. If the hosts do not respond, then further investigation needs to be done on the nameservers and possibly within the network to determine why the queries are failing.
3. If you find the problem to exist somewhere outside of the mainframe, then a temporary workaround is to remove the NSINTERADDR statements from the configuration. You can code a local hosts table (/etc/hosts HFS file or HOSTS.SITEINFO/HOSTS.ADDRINFO MVS data sets) to prevent the need of a domain name server.
Was this topic helpful?
Document Information
Modified date:
15 June 2018
UID
swg21111951