Socket data protocol problems

Table 1 lists problems related to data transfer over the socket connection. They include incorrect data sent, not enough or too much data sent, and data corruption.

Table 1. Socket data protocol problems
Problem	Cause	Resolution
The Listener is not responding to the client program	If the TRM sent by the client program is incomplete, the Listener waits indefinitely for the rest of the message. If the port specified by the client program is not the port that is attached to the Listener, and the socket connection is established, the other end of the connection does not communicate with the client program as required.	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 Listener is attached to the port used by the client program to establish the socket connection. Use the command specified in Using NETSTAT.
All the input data sent from the client program is not being passed to the implicit IMS™ transaction from the Listener	Any input data written after the first EOM segment is ignored by the Listener.	Check for EOM segments being sent by the client program by using the IP packet trace facility described in Using IP packet trace. See the information about the implicit-mode application data in z/OS Communications Server: IP IMS Sockets Guide for the format of the EOM segment.
Explicit IMS transaction is receiving garbled data from or sending garbled data to the client program	The data might need translation when the client program does not exist on an EBCDIC host. For explicit data transfer, the client program, or the IMS transaction, or both, must provide ASCII to EBCDIC translation and byte-order translation of fixed-point binary integers, if required. The Listener automatically translates the TRM when creating the TIM.	Code the client program or the IMS transaction or both to provide the necessary translation when the client program is not on an EBCDIC host.
Implicit IMS transaction is receiving garbled data from or sending garbled data to the client program	The automatic data translation when the client program does not exist on an EBCDIC host can be causing the problem. For implicit data transfer, the Listener automatically translates input data from ASCII to EBCDIC, based on the TRM contents. The IMS assist module also automatically translates output data from EBCDIC to ASCII when sending to an ASCII client program, as determined by the TRM. If the TRM sent by the client program is not either ASCII or EBCDIC as required, then the automatic translations fail. The client program is also responsible for any required byte-order translation of fixed-point binary integers. Notes: If the data translated between ASCII and EBCDIC contains any nonprintable data, such as integers, flags, or reserved fields, the data is corrupted. In this case, the client program must provide EBCDIC data (including the TRM) for the IMS transaction and expect EBCDIC data from the IMS transaction. If the data is translated between ASCII and EBCDIC and contains characters that are not common to both the ASCII and EBCDIC tables, the nontranslatable characters are translated to spaces.	Code the client program to provide the necessary translation when the client program is not on an EBCDIC host and the automatic data translation cannot be used.
The security exit does not validate user data from the client program	The security exit might not be successfully linked into the Listener. The exit must be compiled and assembled and then linked into the Listener for it to be called.	Check that the security exit has been coded and built correctly as specified in z/OS Communications Server: IP IMS Sockets Guide.
Data is corrupted after an implicit IMS transaction issues a GU	The I/O area declared might be too small. When using the IMS assist module, the I/O area provided for the GU call must be large enough to hold the TIM, even though the data eventually returned in the I/O area can be smaller.	Make certain the implicit IMS transaction has enough storage declared to hold the TIM. The size of this message is specified in z/OS Communications Server: IP IMS Sockets Guide.
The PL/I IMS transaction is receiving or sending message segments that are not valid	The message segments might be declared incorrectly. The PL/I API interface to the IMS transaction manager defines the message segments with a four-byte length field, but the length value must include only two of those bytes plus the rest of the segment.	Use the following rules to avoid problems: The IMS assist module PL/I API routines mimic the interface used by the PL/I API routines. Code PL/I implicit transaction message segments in exactly the same manner as for this interface. Code the client program in exactly the same manner as for all the IMS transaction API interfaces. The IMS assist module routines automatically converts the message segments from the PL/I API to the standard format. Explicit transactions do not use the IMS assist module. The message segment format, if required, must match on both the client program and the IMS transaction sides. It is recommended that the standard message segment format be used. See the information about programming considerations for the implicit-mode server and the explicit-mode server in z/OS Communications Server: IP IMS Sockets Guide for more details about the PL/I API issues.