On z/OS® systems, an application server can connect to a queue manager that is a member of a WebSphere® MQ for z/OS queue-sharing group. You can configure the connection so that it selects a specific named queue manager, or you can configure it to accept any queue manager in the queue-sharing group.
If you configure a connection to select a specific named queue manager, your options for providing high availability are like those for connecting to WebSphere MQ on other platforms. However, you can improve availability if you configure the connection to accept any queue manager in the queue-sharing group. In this situation, when the application server reconnects following a WebSphere MQ queue manager failure, the application server can accept connection to a different queue manager that has not failed.
A connection that you configure to accept any queue manager must only be used to access shared queues. A shared queue is a single queue that all queue managers in the queue-sharing group can access. It does not matter which queue manager an application uses to access a shared queue. Even if the same application instance uses different queue managers to access the same shared queue, this always produces consistent results.
The following figure shows a bindings mode connection from WebSphere Application Server to WebSphere MQ for z/OS. The figure shows the following configuration:
This networking topology can benefit from "pull" workload balancing if several application instances, including instances running in different LPARs, are processing messages from the same shared queue.
You can improve availability for this topology by using the z/OS Automatic Restart Manager (ARM) to restart failed application servers or queue managers. If a queue manager in an LPAR fails, ARM can restart an application server in a different LPAR, where the application server can connect to a running queue manager, instead of waiting for a restart of the queue manager that it was using previously. In the example used here, ARM can restart WebSphere Application Server application server 1 in LPAR 2, where it can connect to WebSphere MQ queue manager 2, instead of waiting for queue manager 1 to restart.
The following figure shows a client mode connection from WebSphere Application Server to WebSphere MQ for z/OS. The figure shows the following configuration:
As with the bindings mode connection example, this networking topology can benefit from "pull" workload balancing if several application instances running in the same or different application servers are processing messages from the same shared queue.
The use of the z/OS sysplex distributor improves availability for this networking topology. If one of the queue managers fails, the z/OS sysplex distributor can connect applications running in the application servers to the other queue manager, without waiting for the failed queue manager to restart. In the example used here, if queue manager 1 fails, the z/OS sysplex distributor can select queue manager 2 for every connection request, until queue manager 1 restarts.