Connection problems

Table 1 lists some problems related to the TCP/IP socket connection. They include problems with establishing the connection, transferring data over the connection, and unexpected loss of the connection.

Table 1. Connection problems
Problem	Cause	Resolution
The client program is experiencing intermittent reject connect responses from TCP/IP	The TCP/IP sockets facility has a connection request backlog queue. While this queue is full, further connection attempts are rejected by TCP/IP. Under load, this queue can temporarily fill, causing some client program requests to be silently ignored.	To reduce the frequency of this problem, increase the size of the backlog queue. The size of the queue is controlled by a parameter in the Listener configuration data set and is limited by the SOMAXCONN statement in the TCPIP PROFILE.
The TCP/IP socket connection to the client program is being broken immediately after the implicit IMS™ transaction is scheduled	The Listener configuration data set might incorrectly define the implicit IMS transaction as explicit. In this case, the Listener does not pass the input data to the IMS transaction through the message queue as expected. The transaction starts, and upon detecting no data, immediately close the TCP/IP socket connection and terminate.	Verify that the TRANSACTION statements in the Listener configuration data set specify the TYPE parameter correctly.
Connection lockup for an implicit IMS transaction A connection lockup occurs when both the implicit IMS transaction and the client program are waiting for data from the other end of the socket connection.	The Listener might be waiting for the end-of-message (EOM) segment from the client program. The client program must send a valid EOM segment before the Listener instructs the IMS transaction manager to schedule the IMS transaction. If the client program does not send a recognized EOM segment, the Listener waits indefinitely for it, while the client program waits for a response.	Use the IP packet trace facility to determine whether the client program is sending a valid EOM segment. See Using IP packet trace for details about the IP packet trace facility. See the information about implicit-mode application data in z/OS Communications Server: IP IMS Sockets Guide for the format of the EOM segment.
Connection lockup for an explicit IMS transaction A connection lockup occurs when both the explicit IMS transaction and the client program are waiting for data from the other end of the socket connection.	Because the explicit IMS transaction protocol is user-defined, programming errors can easily lead to connection deadlocks. That is, the server is waiting for more data while the client is waiting for a response, and both wait indefinitely. The Listener configuration data set might incorrectly define the explicit IMS transaction as implicit. In this case the Listener waits for valid implicit data from the client program, or if valid data is received, the explicit IMS transaction waits for data from the client program because the Listener has already read the data and written it to the message queue.	Use the IP packet trace facility to identify which part of the protocol is failing. See Using IP packet trace for details about the IP packet trace facility. Verify that the TRANSACTION statements in the Listener configuration data set specify the TYPE parameter correctly. Timeouts, especially in the client program, are recommended when issuing socket READs to avoid deadlocks and allow easy diagnosis. See the information about SELECT calls in z/OS Communications Server: IP IMS Sockets Guide for more information about specifying timeouts for READs.
Connection lockup for either an explicit or implicit IMS transaction A connection lockup occurs when both the IMS transaction and the client program are waiting for data from the other end of the socket connection.	If the TRM sent by the client program is incomplete, the Listener waits indefinitely for the rest of the message. If the IMS transaction does not successfully issue the takesocket to gain the connection from the Listener, the Listener waits for this event indefinitely. The takesocket might not be issued successfully due to one of the following reasons: The IMS transaction is defined to run in a message processing region that is not started. In this case, the IMS transaction is never scheduled and, therefore, never issue the takesocket. One of the several TCP/IP socket calls, up to and including the takesocket, might fail and terminate the IMS transaction. An IMS error can stop the transaction from being successfully scheduled, or, especially in the explicit case, can cause the IMS transaction to terminate before the takesocket is issued.	Check the length and format of the TRM by using the IP packet trace facility as described in Using IP packet trace. Check that the IMS transaction is being successfully scheduled by the IMS transaction manager and ensure that any IMS and socket calls issued by the IMS transaction are checked for unsuccessful return codes.
The takesocket call issued by the IMS transaction fails Note: For implicit transactions, the IMS assist module routines issue a takesocket for the first get unique (GU) issued by the transaction. If the takesocket fails, the GU returns ZZ.	IMS can, for recovery reasons, abend a transaction and start it again. If the transaction is abended after it has gained the socket connection (through a takesocket call), the TCP/IP socket connection is lost. Although IMS restores the message queue when it restarts the transaction, the takesocket issued by the transaction fails as the socket connection has already been taken from the Listener. An IMS transaction not defined as multisegment to the IMS transaction manager is scheduled as soon as the TIM is added to the message queue. This gives the IMS transaction an opportunity to issue the takesocket before the givesocket is issued by the Listener. The takesocket fails with an error return code.	Restart the client program. To reduce the frequency of this problem, determine why IMS is restarting the IMS transaction by using the IMS trace facility. See IMS traces. Make certain the IMS transaction is defined as multisegment.
The client program is always receiving reject connect responses from TCP/IP	The maximum number of active sockets might have been reached, with all the currently active socket connections unable to complete. An increasing number of socket connections eventually reduces the available socket connections to zero when the number of socket connections equals the MaxActiveSockets configured for the Listener. When this happens, TRMs are not processed by the Listener, and they are left on the TCP/IP backlog queue. When the backlog queue fills, TCP/IP silently ignores a client program connection attempt.	Identify the client programs causing the problem using the NETSTAT command as specified in Using NETSTAT; then continue diagnosis to determine why these connections are locking up. The Listener must be restarted to clear the active socket list. Because there are active socket connections, the Listener must be forced to terminate using the command specified in z/OS Communications Server: IP IMS Sockets Guide.
Connection lockup or loss when passing a socket connection from one explicit IMS transaction to another A connection lockup is when the socket connection reaches a state where it never completes.	To pass a socket connection from the first IMS transaction to the second, the first IMS transaction must wait after it issues the givesocket until the second IMS transaction issues a takesocket; otherwise, the connection is lost. A connection lockup can occur when the first IMS transaction waits for the takesocket to be issued, but both IMS transactions are defined to run in the same message processing region. In this case, they cannot both be scheduled to run at the same time, and the first IMS transaction waits indefinitely for the takesocket from the second IMS transaction, which is never scheduled.	When passing a socket connection between IMS transactions, make sure the first transaction waits for the second to issue the takesocket and that both IMS transactions can be scheduled to run at the same time.