Conversational programs

An IMS™ program will support both a transaction composed of one step and a transaction composed of several steps, the latter of which is referred to as a conversational transaction.

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.

With IMS Connector for Java™ conversational support, a client interacting with the IMS conversation transaction is usually using one of the following two applications: With Web applications, the user uses the same browser to conduct a series of requests that iterate through different interactions of an IMS Conversation. IMS Connect requires that all iterations of a conversation use the same connection. A Java servlet receives an input request from the browser and utilizes IMS Connector for Java classes to send a conversational transaction request to IMS Connect via a TCP/IP communication. IMS Connect then forwards the transaction request to both OTMA and IMS and schedules the IMS conversational transaction to run; this process creates a new IMS conversation. The IMS application processes the request and sends the output back to the Java servlet via IMS Connect and IMS Connector for Java Conversational Support. The Java servlet loads the appropriate JavaServer Page to display the output to the user in the browser.

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.


Feedback