PASV and EPSV commands fail because no PASSIVEDATAPORTS are available

If you code the PASSIVEDATAPORTS statement in the server's FTP.DATA, you must code enough ports to accommodate the server workload. Otherwise, EPSV and PASV commands to the server fail. Syslog tracing or CTRACE indicates bind() failed with errno 1116 - address not available, and errno2 of JRBINDNoPort.

To transfer data in passive mode, the FTP server must obtain a port from the PASSIVEDATAPORTS range. Therefore, allow at least one port per simultaneous data transfer. For example, if you expect one hundred users to log in to FTP at once to transfer data, code at least one hundred ports on the PASSIVEDATAPORTS statement.

The PASSIVEDATAPORTS statement does not preclude other applications from obtaining ports in the coded range. To prevent other applications from consuming ports in the PASSIVEDATAPORT range to the exclusion of FTP, code a PORTRANGE statement in PROFILE.TCPIP with the AUTHPORT parameter, specifying some or all ports in the PASSIVEDATAPORTS range. See z/OS Communications Server: IP Configuration Reference for more information about the PORTRANGE statement and PROFILE.TCPIP.

TCP/IP does not release ports that the FTP server has released until the connection associated with the port has exited the TIMEWAIT state. If all the PASSIVEDATAPORTS connections are in TIMEWAIT state, the server is not able to obtain a port to process a PASV or EPSV command. You can verify the connections are in TIMEWAIT state by issuing the netstat -a command from the USS shell. To correct this problem, increase the number of ports coded on the PASSIVEDATAPORTS statement .