Using shared queues with OTMA
This topic describes general information about using IMS shared queues with OTMA.
To ensure delivery of alternate PCB processing, enable OTMA on all IMS systems; assign each IMS system in the shared queue group a unique z/OS® cross-system coupling facility member name.
Use the /DISPLAY TRANS ALL QCNT to view all the OTMA transactions currently in the shared queue group waiting to be processed. Use /DISPLAY QCNT OTMA MSGAGE 0 to view all the OTMA outbound messages on the shared queues.
For OTMA hold-queue capable clients, such as IMS Connect, using the OTMA super member function can ensure that outbound messages do not become stranded on a shared queue and can be delivered to the client.
As the result of a temporary shortage in the HIOP
storage pool, you might receive message DFS1269E,
which notifies you of an internal IMS failure
to register a shared queue resource. To re-register the shared queue
resource for OTMA, issue the IMS commands /STOP
OTMA and /START OTMA.
In a shared queues environment, IMS removes idle, non-queued, non-synchronized transaction pipes after three system checkpoints.
If you send OTMA ALTPCB messages to a remote IMS system via an IMS-to-IMS TCP/IP connection from the shared-queues environment, the transaction messages can be sent to the remote IMS system only from the IMS system that is directly connected to the IMS Connect instance that is managing the TCP/IP connection.
For OTMA commit-then-send messages in a shared queues
environment, a new ITASK under a new OID TCB is created to process the messages, separately from the
main ITASK under OIC TCB that is used for other jobs.