IMS Connectivity in an On Demand Environment: A Practical Guide to IMS Connectivity

258 IMS Connectivity in an On Demand Environment: A Practical Guide to IMS Connectivity

13.1 Asynchronous message processing

We define an asynchronous message as an item of information sent by IMS Connect to a

client asynchronously relative to its normal flow of execution.

In a normal send-receive interaction, the client application expects to read an IMS response

just after it has sent the actual transaction message. An IMS Connector for Java application

does not do anything explicit to get a transaction response. The execute() method of the

Interaction object takes care of:

 Sending the transaction to IMS Connect

 Getting the IMS response

 Sending, if needed, the positive acknowledgement (ACK) to IMS Connect so that the

response is dequeued (for commit mode 0 interactions) or the transaction is committed

(for commit mode 1 interactions)

 Reading the IMS Connect response to the ACK to check whether the process has ended

correctly

This flow of execution is based on the idea that the IMS transactions send messages to their

clients in a synchronous, predictable way. Unfortunately, this is not always the situation in

real applications:

 A transaction can insert a message intended for a third-party terminal or a client different

from the one that sent the original transaction. This is done at the IMS application level by

using an alternate PCB (ALTPCB) and issuing a sequence of Transaction Manager calls

against the alternate IOPCB (ALTPCB): CHNG, ISRT, and PURG. These messages are

asynchronous by their own nature, because the destination terminal or client cannot

predict when such an operation will take place.

 A transaction, or a sequence of transactions chained by means of program-to-program

switches, can insert more than one response to the originating terminal or client.

Excepting the first response, which will be read by the client in its normal flow of execution,

these messages are asynchronous, because the client has no way to know if the IMS

application will send more than one response.

 An interaction can timeout due to an exceptional high response time from IMS, for

example, when the transaction stays in the message queue for a long time before it gets

processed. In this case, when the transaction gets processed, the client will not be waiting

for the response any more.

Refer to 7.4, “Asynchronous output support” on page 100 for the full details about how to

retrieve the asynchronous messages. In this chapter, we take a deeper look in the ways that

those messages can be generated and routed before a client application can get them.

13.2 Messages inserted to ALTPCB

When an application program issues a CHNG call against an ALTPCB, it can use a

transaction code or an LTERM name as new destination. If the destination is a logical

LTERM, IMS lets you determine the real destination using the DFSYPRX0 and DFSYDRU0

exits. Refer to Chapter 9, “IMS Connect user exit support” on page 115 for the details. At this

point, we should just notice that:

 You can send the response to an OTMA client of your choice using the DFSYPRX0 exit.

 You can specify the final Tpipe destination of the message using the DRU0 exit (which can

be different for each OTMA client you use).