We had this question from a customer with the following scenario. MQ on Linux going to a QSG.
Sunday night they re-ipled MVSA, and the shared channel connected to QMB on MVSB. This was fine till peak hour during the day. MVSB was processing most of the work, and they wanted the MQ work to go to QMA on MVSA.
When this is a shared channel, you have to stop and restart it, and hope the VIPA support connects it to QMA.
If this was a cluster channel, and not a shared channel….
The Linux Queue manager can start a channel to both queue managers QMA and QMB. You can configure that channels so 60% of the work goes to QMB – if it is active.
When MVSA is re-ipled and QMA is started, the channel will start to it. So now you have two channels running. You can now stop the channel to QMA, and so all of the work goes to QMB. If this is a bit drastic you can configure 90% of the messages go to QMA.
After much discussion we said that perhaps a cluster channel was the best way.
- You do not have to set up the VIPA configuration (less change control and work for other departments)
- You can adjust where the work goes to
- If one queue manager is shut down the work should seamlessly flow to the other queue managers
- There is no “outage” when the channel is stopped and restarted – even if the “outage” is a few seconds
The costs should be similar. With a shared channel you may achieve higher batching – but there is some DB2 updates at the end of batch.