The following problems can all be resolved using the REFRESH CLUSTER command. It is unlikely that you will need to use this command during normal circumstances. Use it only if you want your queue manager to make a fresh start in a cluster. Issue the REFRESH CLUSTER command from a queue manager to discard all locally held information about a cluster. For example you might use it if you think your full repository is not up-to-date, perhaps because you have accidentally restored an out-of-date backup. The format of the command is:
REFRESH CLUSTER(clustername) REPOS(YES/NO)
The queue manager from which you issue this command loses all the information in its full repository concerning the named cluster. It also loses any auto-defined channels that are not in doubt and which are not attached to a full repository queue manager. The queue manager has to make a cold-start in that cluster. It must reissue all information about itself and renew its requests for updates to other information that it is interested in. (It does this automatically.)
Here are some procedures for recovering clusters.
On QM1, issue the command REFRESH CLUSTER(DEMO)
QM1 will remove all information it has about the cluster DEMO, except that relating to the cluster queue managers which are the full repositories in the cluster. Assuming that this information is still correct, QM1 will contact the full repositories. QM1 will then inform them about itself and its queues and recover the information for queues and queue managers that exist elsewhere in the cluster as they are opened.
On QM1, issue the command REFRESH CLUSTER(DEMO)
See solution to problem Problem 1 -- Out of date information in a restored cluster.
On QM1, issue the command REFRESH CLUSTER(DEMO)
See solution to problem Problem 1 -- Out of date information in a restored cluster.
Alter the CONNAME in the CLUSRCVR's and CLUSSDR's to specify the new network addresses.
Alter one of the queue managers (QM1 or QM2) so it is no longer a full repository for any cluster.
On the altered queue manager, issue the command REFRESH CLUSTER(*) REPOS(YES).
Alter the queue manager so it is acting as a full repository.
This problem could have been avoided if, after moving one of the queue managers (for example QM2) to its new network address it was allowed to start its CLUSRCVR, altered with the new address. Having informed the rest of the cluster and the other full repository queue manager (QM1) of the new address of QM2. The other queue manager (QM1) can then be moved to its new network address, restarted and its CLUSRCVR modified to show its new network address. The manually defined CLUSSDR channels should also be modified for the sake of clarity, even though at this stage they are not needed for the correct operation of the cluster.
This procedure forces QM2 to reuse the information from the correct CLUSSDR to re-establish contact with QM1 and then rebuild its knowledge of the cluster. Additionally, having once again made contact with QM1 it will be given its own correct network address based on the CONNAME in its CLUSRCVR definition.
Carry out the following steps on the other partial repository queue managers:
Under normal conditions the full repositories will exchange information about the queues and queue managers in the cluster. If one full repository is refreshed, the cluster information is recovered from the other. To stop this happening all of the CLUSRCVR channels to full repositories are stopped and the CLUSSDR's should be inactive. When you REFRESH the full repository systems, none of them are able to communicate, so will start from the same cleared state.
As you REFRESH the partial repository systems they rejoin the cluster and rebuild it to the complete set of queue managers and queues.
Notices |
Downloads |
Library |
Support |
Feedback
![]() ![]() |
csq68xb |