IMS database problems

Table 1 lists some problems related to unexpected IMS™ database actions or failures. They include changes not made or requests for changes that fail.

Table 1. IMS database problems
Problem	Cause	Resolution
The IMS transaction is terminating without performing the required function and without issuing any error messages	The IMS transaction might not be checking for interface errors.	It is the responsibility of the IMS transaction programmer to identify and issue error messages if the IMS database manager, IMS transaction manager, or TCP/IP socket interfaces fail.
The client program is not receiving any data from the implicit IMS transaction, but is receiving a successful CSM	The IMS transaction might be issuing an IMS database rollback (ROLB) call. If the IMS transaction issues a ROLB call, all output accumulated by the IMS assist module is discarded as part of the ROLB function. Depending on how the IMS transaction is coded, it might complete without further output (ISRT calls).	Use caution in issuing ROLB calls in implicit IMS transactions using the IMS assist module. Make certain you understand the details about implicit-mode support for ROLB processing in z/OS Communications Server: IP IMS Sockets Guide.
Local IMS transaction manager ISRT/GU/GN calls are failing when issued in IMS transactions	Local calls assume a terminal has requested the IMS transaction. The input and output of data, however, is sent across the socket connection for IMS transactions started by the Listener. The following is a list of specific causes of the problem: The ISRT call has no terminal associated with the IMS transaction for the output. There is no data on the message queue for explicit IMS transactions to get with the GU or GN calls. An implicit IMS transaction receives an unexpected TIM in response to a GU call.	Do not issue local IMS transaction manager calls from transactions started by the Listener. An implicit IMS transaction must use the IMS assist module calls, which accesses either a terminal or socket connection, as required. An explicit IMS transaction must interface directly to the socket connection.
The ISRT call fails for an implicit IMS transaction if a large amount of data is output	The IMS assist module restricts the total output for a single IMS transaction execution to 32KB.	Limit the output for an implicit IMS transaction using the IMS assist module to a total of 32KB.
The IMS database manager commits the changes made by an IMS transaction, but the client program receives an error	The implicit IMS transaction does not issue a second GU. The IMS database commits the changes either when the IMS transaction ends or when another GU is issued. For implicit IMS transactions, the IMS assist module routines sends the output data and CSM to the client program and closes the socket connection when the second GU is issued. If the implicit IMS transaction does not issue another GU, the changes are committed when the transaction ends, but the client program assumes failure when the CSM is not received. The socket connection might have been broken after the changes were committed but before the CSM was sent. In this case, the client program assumes failure, but the changes have been committed.	Implicit IMS transactions that are started by the Listener must issue GU calls to get the next transaction request until the GU call returns with no requests to process. Where possible, the client program should be coded to automatically restart the IMS transaction and handle the condition where the IMS transaction is duplicated. For explicit IMS transactions, a more rigorous protocol can be implemented. Guideline: This should be considered as an uncommon case.
The client program does not receive a valid CSM from an implicit IMS transaction	The client program might not have completed the response protocol correctly. The client program must read the response data until it reads an EOM segment. The CSM immediately follows the EOM.	Use the IP packet trace facility to determine whether the IMS transaction is sending a valid EOM segment followed by a valid CSM segment. See Using IP packet trace for details about the IP packet trace facility. If the correct message segments are being sent, correct the client program to receive the response data. See z/OS Communications Server: IP IMS Sockets Guide for the format of the EOM and CSM segments.