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.

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.

Each type of request is processed as follows:

Synchronous callout request
Start of changeAn 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. The application program can use the optional control data area of the DL/I ICAL call to pass routing, security, or other data to IMS Connect and its clients. 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.End of change
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 Start of changeThe requesting IMS application issues an ICAL call with or without control data.End of change 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.