Most sections of this documentation, when talking about IMS transactions, are referring to nonconversational transactions, which take one step to complete. In contrast, an IMS conversational program processes transactions made up of several steps. The IMS TM Resource Adapter supports both, and this section is dedicated to this latter, special type of IMS transaction.
An IMS conversational program divides processing into a connected series of client-to-program-to-client interactions. The IMS conversational program receives messages from the client, processes the requests and replies to the client. The program also saves the intermediate data from the transaction in the scratch pad area (SPA). The user can enter more data from the client, and using the data from the last message in the SPA, the IMS conversational program will continue processing the request.
If the conversation is not ended at the last iteration, or your application program does not initiate the end conversation request (perhaps because the browser has been closed before the conversation was ended), then the IMS conversation and the associated IMS storage will exist in the system for a long time. This orphaned IMS conversation could prevent the system from completing the online change. You can issue the /DISPLAY CONV command to see whether you have any orphaned IMS conversations in the system. This orphaned IMS conversation can only be ended by an IMS restart. For a list of IMS commands supported by OTMA, see the Commands Supported from LU 6.2 Devices and OTMA not currently supported section of Chapter 1. IMS Command Language in the IMS V9 Command Reference. Note that some IMS commands such as the /EXIT, /HOLD and /RELEASE commands used with IMS-conversational transactions, are not supported by OTMA. It is recommended to use timeouts (like EJB session timeout) to prevent this situation.
The IMS Connector for Java documentation and samples apply to IMS nonconversational transactions and programs (applications) unless otherwise specified.