IBM MQ 7.5 was EOS 30th April 2018.Click EOS notice for more details
Restricting the number of channels used
Follow these instructions to restrict the number of active
channels each server runs when a price check application is installed
on various queue managers.
Before you begin
Note: For changes to a cluster to be propagated throughout
the cluster, at least one full repository must always be available.
Ensure that your repositories are available before starting this task.
Scenario:
A price check application is to be installed on various queue
managers. To keep the number of channels being used to a low number,
the number of active channels each server runs is restricted. The
application is driven by the arrival of messages on the PRICEQ queue.
Four server queue managers host the price check application. Two
query queue managers send messages to the PRICEQ to
query a price. Two more queue managers are configured as full repositories.
About this task
Follow these steps to restrict the number of channels
used.
Procedure
Choose two full repositories.
Choose two
queue managers to be the full repositories for your price check cluster.
They are called REPOS1 and REPOS2.
Issue
the following command:
ALTER QMGR REPOS(PRICECHECK)
Define a CLUSRCVR channel on each queue
manager.
At each queue manager in the cluster, define
a cluster-receiver channel and a cluster-sender channel. It does not
matter which is defined first.
Although there are four instances of the PRICEQ queue
available in the PRICECHECK cluster, each querying
queue manager only uses two of two of them. For example, the QUERY1 queue
manager only has active channels to the SERVER1 and SERVER2 queue
managers. If SERVER1 became unavailable, the QUERY1 queue
manager would then begin to use another queue manager, for example SERVER3.
What to do next
Although there are four instances of the PRICEQ queue
available in the PRICECHECK cluster, each querying
queue manager only uses two of two of them. For example, the QUERY1 queue
manager only has active channels to the SERVER1 and SERVER2 queue
managers. If SERVER1 became unavailable, the QUERY1 queue
manager would then begin to use another queue manager, for example SERVER3.