Orphaned IMS conversation

When a conversation is not ended explicitly, it continues to exist in the system as an orphaned conversation, and the associated IMS storage continues to be allocated to that conversation.

An IMS conversation is usually ended explicitly in one of two ways:
  • The IMS application inserts blanks to the SPA before returning a response to the client.
  • The client application program submits a SYNC_END_CONVERSATION request.
If the browser was closed before the conversation ends properly, for example, the IMS conversation is not ended explicitly and continues to exist in the system. When an IMS conversation becomes orphaned, you have no way of programmatically continuing or ending that conversation. One measure that you can take to avoid orphaned conversations would be to use timeouts, such as the EJB session timeout, to force the end of a conversation that does not complete in a reasonable amount of time by submitting a SYNC_END_CONVERSATION request in the EJB session timeout cleanup code.

If a client application is terminated and a conversation becomes orphaned, the orphaned IMS conversation can be ended only by an IMS restart. You can check for orphaned IMS conversations in the system by issuing an IMS /DISPLAY CONV command through an IMS_REQUEST_TYPE_IMS_COMMAND interaction. For a list of IMS commands supported by OTMA, see the Commands Supported from LU 6.2 Devices and OTMA section in IMS Version 14 Commands, Volume 2 or in "IMS Commands using OTMA" in IMS Version 14 Communications and Connections.