There are two types of socket connections, shareable persistent socket and dedicated persistent socket, that can be used to retrieve asynchronous output. The way to retrieve asynchronous output messages is different depending on the type of socket connection used. The interactionVerb property values that can be used to retrieve asynchronous output are: SYNC_RECEIVE_ASYNCOUTPUT_SINGLE_NOWAIT, and SYNC_RECEIVE_ASYNCOUTPUT_SINGLE_WAIT (along with the older SYNC_RECEIVE_ASYNCOUTPUT).
The difference between SYNC_RECEIVE_ASYNCOUTPUT_SINGLE_NOWAIT and SYNC_RECEIVE_ASYNCOUTPUT_SINGLE_WAIT determines how IMS Connect checks for output on the IMS OTMA Asynchronous Hold Queue. For SYNC_RECEIVE_ASYNCOUTPUT or SYNC_RECEIVE_ASYNCOUTPUT_SINGLE_NOWAIT interactions, if there is no asynchronous output in the IMS OTMA Asynchronous Hold Queue when the retrieve request is made, IMS Connect will return an execution timeout notification as soon as the execution timeout value specified by the client application has passed. For this reason, the shortest possible execution timeout value, 10, is recommended for SYNC_RECEIVE_ASYNCOUTPUT_SINGLE_NOWAIT interactions.
For a SYNC_RECEIVE_ASYNCOUTPUT_SINGLE_WAIT interaction, if there is no asynchronous output in the IMS OTMA Asynchronous Hold Queue when the retrieve request is made, IMS Connect will wait up to the length of time specified in the executionTimeout property of the interaction for OTMA to return a message. If there is still no asynchronous output in the hold queue when the execution timeout has passed, IMS Connect will return an execution timeout error. For a SYNC_RECEIVE_ASYNCOUTPUT_SINGLE_WAIT interaction, you should select an appropriate execution timeout value, rather than the shortest possible value.
All three interactionVerb property values require commit mode 0 and can be used on both shareable persistent socket and dedicated persistent socket connections. In addition, IMSInteractionSpec properties purgeAsycOutput, reRoute and reRouteName do not apply to interactions which use these three interactionVerbs and are ignored by IMS Connector for Java. The way that interactionVerb properties are invoked on dedicated and shareable persistent socket connections is different.
Retrieving asynchronous output on dedicated persistent socket connections
To retrieve the queued output message on a dedicated persistent socket, the client application must execute a commit mode 0 interaction with the interactionVerb property of IMSInteractionSpec set to SYNC_RECEIVE_ASYNCOUTPUT_SINGLE_NOWAIT, or SYNC_RECEIVE_ASYNCOUTPUT_SINGLE_WAIT.
In addition to executing a commit mode 0 interaction on a dedicated persistent socket connection with the appropriate interactionVerb property of IMSInteractionSpec, the client application must also provide a value for the clientID property of IMSConnectionSpec. The clientID is required because it determines the TPIPE from which the asynchronous output will be retrieved. To retrieve output messages from a commit mode 0 interaction on a dedicated persistent socket, the clientID specified on the SYNC_RECEIVE_ASYNCOUTPUT_SINGLE_WAIT/NOWAIT interaction must match the value specified for the original commit mode 0 interaction. To retrieve output messages sent to an alternate PCB, the clientID specified on the SYNC_RECEIVE_ASYNCOUTPUT_SINGLE_WAIT/NOWAIT interaction must match the name of the alternate PCB. To retrieve output messages which were rerouted to a reRouteName destination, the clientID on the SYNC_RECEIVE_ASYNCOUTPUT_SINGLE_WAIT/NOWAIT interaction must be set to that reRouteName property destination.
Retrieving asynchronous output on shareable persistent socket connection
To retrieve an undelivered output message resulting from an interaction on a shareable persistent for which the reRoute flag has not been set to TRUE, the client application must execute a SYNC_RECEIVE_ASYNCOUTPUT_SINGLE_NOWAIT or SYNC_RECEIVE_ASYNCOUTPUT_SINGLE_WAIT interaction on the same shareable persistent socket connection in the same application that invoked the interaction that led to the asynchronous output being queued. The reason that the two interactions must be invoked within the same client application is that the IMS resource adapter automatically generates a client-ID for shareable persistent socket connections. This generated clientID identifies the socket connection as well as the associated OTMA TPIPE to which the asynchronous output is queued. A new client-ID is generated when a new connection is established. On shareable persistent socket connections, the clientID is generated by IMS Connector for Java and is unique for each connection. Therefore, to retrieve asynchronous output for a specific generated clientID, a connection with the same clientID must be used. This means that, for shareable persistent socket connections (which always have unique generated clientIDs) the same connection must be used. The only way to guarantee that the same connection will be used is to execute both interactions (the original interaction as well as the SYNC_RECEIVE_ASYNCOUTPUT_SINGLE_WAIT or SYNC_RECEIVE_ASYNCOUTPUT_SINGLE_NOWAIT interactions) within the same client application.
Do not specify a value for the clientID property of IMSConnectionSpec for interactions on shareable persistent socket connections. On shareable persistent socket connections a user specified clientID is not allowed since IMS Connector for Java automatically generates the clientID.