Troubleshooting
Problem
This information is provided to assist in avoiding recurring socket application problems.
Resolving The Problem
PREVENTING LOOPING APPLICATION
When an application issues a READ/RECV call and the return code is zero, this is an indication that the remote partner has closed it's side of the connection.
To avoid a looping application, the application should close it's socket instead of repeatedly issuing a READ/RECV call after receiving the retcode zero.
PREVENTING HUNG APPLICATION
When an application issues the SEND call but the receiving application does not read the data in a timely manner, the sending application may appear to be hung. This could be an indication that the remote host has sent a TCP window update to notify the sending application that no more data should be sent because the remote application buffer is full.
Socket option so_rcvbuf and so_sndbuf can be used to set the receive and send buffer sizes for each application. This can help eliminate sending more data than the receiving side can handle. However, this will not help if the receiving application is not responding.
TCPRCVBufrsize and TCPSENDBufrsize keywords must be specified in the TCPCONFIG statement in the PROFILE.TCPIP dataset to enable the application to change the send and receive buffer sizes.
READ/RECV is a blocking socket call which means the application will wait until data is available to satisfy the READ/RECV request. If you do not want the application to block on a READ/RECV call, following are suggested ways around it:
- Code a SELECT socket call with the read mask set for the socket that you want to monitor, and a timer indicating the amount of time to wait before SELECT returns if no data is available. If the SELECT call returns with return code=0, the SELECT call has timed out and there is no available data. If the SELECT call returns with return code > 0, the return code indicates the number of sockets that have activity. If SELECT returns with return code = -1, there is an error with the SELECT call and the errno should be checked.
- Make the socket non-blocking. This will cause the application to get control immediately after the READ/RECV call has been issued. Use the FCNTL or FIONBIO IOCTL to set the socket to non-blocking. If there is no data when the READ/RECV call returns the return code will reflect a -1 and the errno will equal EWOULDBLOCK. EWOULDBLOCK indicates that there is no data available and if the socket was a blocking socket it would have blocked. Once READ/RECV returns with EWOULDBLOCK you can either code a SELECT to monitor the socket for data or issue READ periodically. Coding SELECT is the preferred method.
A SELECT call can hang until timer expires. If the READ, WRITE or EXCEPTION flags are set to 0 or MAXSOC <=0, SELECT will act as a timer and will not return until the timer expires.
Was this topic helpful?
Document Information
More support for:
z/OS Communications Server
Software version:
1.13, 2.1, 2.2, 2.3
Operating system(s):
z/OS
Document number:
336913
Modified date:
15 June 2018
UID
swg21161315