Callout requests for services or data

IMS™ applications can issue callout requests for services or data, and optionally receive responses back in the same or a different transaction, through IMS Connect and OTMA. The request for services or data is a callout request.

Start of change If the IMS application, after issuing the request, waits for a response in the dependent region, the request is a synchronous callout request. If the IMS application terminates after the request is issued and does not wait for a response in the dependent region, the request is an asynchronous callout request. IMS applications can also issue synchronous callout requests to an IMS transaction with a synchronous program switch request. End of change

Start of change Each type of request is processed as follows: End of change

Synchronous callout request: An IMS application program that runs in an IMS dependent region issues a DL/I ICAL call and waits in the dependent region to process the response. When the DL/I ICAL call is issued, IMS generates a correlation token for synchronous callout requests. This correlation token is included with the callout request and must be returned to IMS with the response to route the response back to the requesting IMS application program.
Asynchronous callout request: An IMS application program that runs in an IMS dependent region inserts the callout request to an ALTPCB queue (the ISRT ALTPCB call) and then terminates to free the dependent region. IMS does not generate a correlation token for asynchronous callout requests. If a response to the callout request is required, the correlation of the response to the callout request must be managed by the IMS application program. When IMS receives a response to an asynchronous callout request, IMS processes the response as a new transaction.
Synchronous program switch request: A synchronous program switch uses the ICAL call, but the request is routed to an IMS transaction rather than an external server. Synchronous program switch requests do not use a correlation token because IMS automatically correlates the response back to the waiting application program.

The following table summarizes the differences among synchronous callout requests, asynchronous callout requests, and synchronous program switch requests.

Table 1. Comparison of synchronous and asynchronous callout requests
Callout process	Synchronous callout request	Asynchronous callout request	Synchronous program switch request
Placing the request in the OTMA hold queue	The requesting IMS application issues an ICAL call.	The requesting IMS application issues an ISRT ALTPCB call.	The requesting IMS application issues an ICAL call.
Status of the IMS application after the request is issued	The application waits in the dependent region for the response. Dependent regions are blocked.	The application terminates.	The application waits in the dependent region for the response. Dependent regions are blocked.
Message processing handling	The message processing is handled by IMS OTMA.	The message processing is handled by the IMS message queue.	The message processing is handled by the IMS message queue.
Response handling	The response is correlated back to the requesting IMS application, based on the correlation token, during the same unit of work.	If there is a response, the requesting or a different IMS application must be coded to handle the response that is returned in a different transaction. The unit of work for the transaction has to commit for the asynchronous output to flow.	The response is returned to the requesting IMS application in the same unit of work. However, the target transaction executes in a separate unit of work, so it is not eligible for two-phase commit and it is not part of the RRS commit scope for the original application.