Managing APPC and OTMA messages in a sysplex environment

Asynchronous APPC and OTMA messages

To ensure delivery of APPC and OTMA messages in a sysplex environment, enable APPC and OTMA on every back-end IMS in the shared-queues group. If a back-end IMS does not have APPC or OTMA enabled, any asynchronous APPC or OTMA output that is inserted to an alternate PCB is queued and not delivered until the operator issues a /STA APPC or /STA OTMA command.

Asynchronous APPC and OTMA messages created by a program-to-program switch can run on any IMS in the shared-queue environment.

Synchronous APPC and OTMA messages

Synchronous APPC and OTMA (send-then-commit) messages can run on any IMS in the shared-queues environment to distribute the transaction workload. Synchronous APPC or OTMA output inserted into the I/O PCB must be delivered by the front-end IMS. Therefore, APPC or OTMA route the synchronous output back to the front-end IMS, regardless of which IMS is running the transaction. Non-conversational I/O PCB reply messages (less than 61 KB) are sent to the front-end IMS using z/OS® cross-system coupling facility services. Conversational I/O PCB reply messages or any synchronous output messages greater than 61 KB are sent to the front-end IMS using shared queues and a special NOTIFY message that is sent using XCF. The IMSplex supports synchronous APPC and OTMA messages when the following conditions are true:

• If AOS=Y or AOS=B, z/OS Resource Recovery Services is active.
• If AOS=Y or AOS=B, the IMS control region parameter RRS=Y is defined for all the IMS systems in the IMSplex.
• AOS=Y, AOS=F, AOS=B, AOS=S, or AOS=X is specified in the DFSDCxxx PROCLIB member data set.

If a synchronous APPC or OTMA transaction running in a back-end IMS results in asynchronous APPC or OTMA output that is inserted to an alternate PCB, APPC or OTMA must be enabled on the back-end IMS. Also, the asynchronous output is delivered to the APPC or OTMA client directly from the back-end IMS.

Synchronous APPC and OTMA transactions initiated by a non-conversational program-to-program switch to local transactions always run on the same IMS system as the transaction that initiated them. For example, if synchronous TRAN A, which can run on any front-end or back-end IMS system in the sysplex, creates synchronous TRAN B and asynchronous TRAN C, both TRAN B and TRAN C will run on the same IMS system as TRAN A.

In a shared-queues environment with APPC/OTMA SMQ enablement active, a transaction coming into IMS through APPC/OTMA can be executed by any member in the IMSplex. But when the transaction issues a program-to-program switch, the switch to transaction must be processed by the same IMS member where the switch occurred unless the control region parameters APPCASY=S or OTMAASY=S is specified.

In the APPC/OTMA shared queues environment when a transaction is processed at the back-end IMS system and performs multiple program to program switches, whether a switch to transaction can be scheduled synchronously is determined at the GU IOPCB time. However, if the control region parameter APPCASY=S or OTMAASY=S is specified, the decision as to which transaction is scheduled synchronously get made at ISRT ALTPCB time.