SYNC_SEND_RECEIVE programming model

To run a transaction in IMS™, your Java™ application executes a SYNC_SEND_RECEIVE interaction. Your application provides a value of SYNC_SEND_RECEIVE for the interactionVerb property and a value of 0 or 1 for the commitMode property of the IMSInteractionSpec object used by the execute method. However, the SYNC_SEND_RECEIVE interaction processing is different for shareable and dedicated persistent sockets.

Shareable persistent socket processing model

The following scenarios describe the SYNC_SEND_RECEIVE interaction on a shareable persistent socket during normal processing, error processing, and execution timeout. These steps apply for both commit mode 1 and commit mode 0.
  • Normal processing scenario

    The IMS resource adapter, with the application server, obtains either an available connection from the connection pool or creates a new connection. The IMS resource adapter, as part of initalizing a new connection generates a clientID for the connection. The generated clientID identifies the socket connection, and in the case of commit mode 0 interactions, the TPIPE and associated OTMA Asynchronous Hold Queue.

    The IMS resource adapter ensures that a socket is associated with the connection and sends the request with input data to IMS Connect using that socket. IMS Connect then sends the message to IMS, where IMS runs the transaction and returns the output message.

    For commit mode 0 interactions, on receiving the output message, the IMS resource adapter internally sends an ACK message to IMS which signals IMS to discard the output from the IMS queue. When the client application closes the connection or terminates, the connection is returned to the connection pool for reuse by other commit mode 0 or commit mode 1 interactions.

  • Error processing scenario

    All errors result in a resource exception being thrown to the client application. In addition, some errors result in the socket being disconnected by IMS Connect. In the case of commit mode 0 interactions, this means the output message cannot be delivered to the client application. Undelivered output messages for commit mode 0 interactions on shareable persistent sockets are not queued to the TPIPE with the automatically generated clientID. This behavior differs from normal commit mode 0 processing.

    There are a couple of options in handling the undelivered output message. If you want to purge undelivered output messages for commit mode 0 interactions on shareable persistent sockets, you must set the IMSInteractionSpec property, purgeAsyncOutput, to TRUE. This property determines if IMS Connect purges undelivered I/O PCB output and is only valid on shareable persistent socket connections. If purgeAsyncOutput is TRUE, the following output messages are purged:
    • Undelivered output message inserted to the I/O PCB by the primary IMS application program.
    • Output messages inserted to the I/O PBC by secondary IMS application programs invoked by the program to program switch.
    If the purgeAsyncOutput property is not specified on the SYNC_SEND_RECEIVE interaction, the default is TRUE.

    Another way of handling undelivered output messages is to reroute the asynchronous output to another destination. If you want to reroute the undelivered output message, you must set the IMSInteractionSpec property, reRoute, to TRUE. If reRoute is TRUE, the asynchronous output is not queued to the TPIPE of the generated clientID and instead is queued to a named destination provided by the client, which is specified on the reRouteName in IMSInteractionSpec property. This property is only valid for SYNC_SEND_RECEIVE interactions on shareable persistent sockets. Also, if purgeAsyncOutput and reRoute are both set to TRUE, an exception is thrown.

  • ExecutionTimeout scenario

    If an execution timeout occurs, the socket connection remains open. For commit mode 0 interactions, the undelivered output message is queued to the TPIPE with the automatically-generated clientID or queued on a reRoute destination. For commit mode 1 interactions, undelivered output is not recoverable.

    When the client application closes the connection or terminates, the connection is returned to the connection pool so it can be reused by other commit mode 0 or commit mode 1 interactions.

Dedicated persistent socket processing model

Dedicated persistent socket connections can only be used for commit mode 0 interactions. The following scenarios describe the commit mode 0 SYNC_SEND_RECEIVE interaction on a dedicated persistent socket during normal processing, error processing, and execution timeout.
  • Normal processing scenario

    Under normal circumstances, when a commit mode 0 SYNC_SEND_RECEIVE interaction is executed by a client application, the application server returns an existing connection with the user-specified clientID, or creates a new connection with the user-specified clientID. The user-specified clientID identifies the socket connection and the TPIPE and associated OTMA Asynchronous Hold Queue.

    The IMS resource adapter ensures that a socket is associated with the connection and sends the request with input data to IMS Connect using that socket. IMS Connect then sends the message to IMS, where IMS runs the transaction and returns the output message. On receiving the output message, the IMS resource adapter internally sends an ACK to IMS which signals to discard the output from the IMS queue. When the connection is closed or the application terminated, the connection is returned to the connection pool for reuse by another application that is running a commit mode 0 interaction with the same user-specified clientID.

  • Error processing scenario

    All errors result in a resource exception being thrown to the client application. In addition, some errors result in the socket being disconnected by IMS Connect. In the case of commit mode 0 interactions, this means the output message cannot be delivered to the client application. The undelivered output is queued to the TPIPE associated with the user-specified clientID.

    The properties, purgeAsyncOutput and reRoute are not applicable to dedicated persistent sockets. You can not purge or reroute undelivered output messages on a dedicated persistent socket.

  • ExecutionTimeout scenario

    If an execution timeout occurs, the socket remains open and the output of the commit mode 0 interaction is queued to the TPIPE associated with the user-specified clientID for later retrieval. When the connection is closed or the application terminated, the IMSManagedConnection object is returned to the connection pool for reuse by another application that is running a commit mode 0 interaction with the same user-specified clientID.

Related concepts
Overview of commit mode processing
SYNC_SEND programming model
Retrieving asynchronous output
Related tasks
Displaying output message counts
Terms of use | Feedback
(C) Copyright IBM Corporation 2000, 2005. All Rights Reserved.