Callout requests from IMS application programs

OTMA, together with hold-queue-capable OTMA clients such as IMS Connect, supports callout requests from IMS application programs running in IMS dependent regions to data or service providers that are external to the IMS installation.

The external providers can include:

The request for services or data is referred to as a callout request. When an IMS application program makes a callout request, IMS can be viewed as a client in a client-server relationship where the server is the external application to which IMS is making the callout request.

Callout requests that are routed through OTMA can be processed synchronously or asynchronously.

For synchronous callout requests, an IMS application program running in an IMS dependent region issues the DL/I ICAL call and waits in the dependent region to process the response also. When the ICAL call is issued, IMS generates a correlation token for synchronous callout requests and routes the request to an OTMA destination. The 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.

For asynchronous callout requests, an IMS application program running in an IMS dependent region inserts the callout message to an ALTPCB queue and then terminates to free the dependent region. IMS does not generate a correlation token for asynchronous callout requests; consequently, if a response to the callout request is required, the correlation of any 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.

The configuration requirements for synchronous callout requests differ slightly from the requirements for asynchronous callout requests, but the basic components are the same:
  • An IMS application that calls out to a source external to IMS for data or services. For synchronous callout requests this same application processes the response. For asynchronous callout requests, if a response is needed, the response is processed either by a different instance of the same application program or a different application program altogether.
  • OTMA, which routes the callout request to the appropriate client tpipe queue based on destinations defined by using one of the following methods:
    • OTMA destination descriptor
    • Type-2 commands
    • For asynchronous callout requests, the OTMA Destination Resolution user exit (OTMAYPRX) and the OTMA User Data Formatting exit routine (DFSYDRU0)
  • A hold-queue-capable OTMA client, such as IMS Connect. IMS Connect serves as both a TCP/IP gateway to IMS and an interface with OTMA.
  • If you are using IMS Connect, an IMS Connect TCP/IP client, such as IMS TM Resource Adapter, IMS Enterprise Suite SOAP Gateway, or a user-written IMS Connect client.
  • A data or service provider, such as an EJB application or MDB application in a Java™ Platform, Enterprise Edition (Java EE) environment, or a web service.

Security for both synchronous and asynchronous callout configurations can be implemented by a security product such as RACF®, the OTMA Resume TPIPE Security user exit (OTMARTUX), or both.