Resolving Problems
The following problems can all be resolved using the REFRESH
CLUSTER command.
Points of Usage of the
command:
a) It is
unlikely that you will need to use this command during normal circumstances.
b) Use it
only if you want your queue manager to make a fresh start in a cluster.
c) 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.
d) The
format of the command is:
REFRESH CLUSTER(clustername)
REPOS(YES/NO)
Effect of
the command:
i)
The queue manager from which you issue this command loses all the
information in its full repository concerning the named cluster.
ii)
It also loses any auto-defined channels that are
not in doubt and which are not attached to a full repository queue manager.
iii)
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.)
Types of
problem could be avoided:
Problem 1
— Out of date information in a restored cluster.
Situation:
An image
backup of QM1, a partial repository in CLUSTER DEMO has been restored and the
cluster information it contains is out of date.
Point of
Using command:
On QM1,
issue the command REFRESH CLUSTER(DEMO)
Note: For
large clusters, use of the REFRESH CLUSTER command can be
disruptive to the cluster while it is in progress, and again at 27 day
intervals thereafter when the cluster objects automatically send status updates
to all interested queue managers.
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.
Problem 2 — cluster DEMO force removed by mistake.
Situation:
RESET
CLUSTER(DEMO) QMNAME(QM1) ACTION(FORCEREMOVE) was issued on a full repository
in cluster DEMO by mistake
Point of
command usage:
On QM1,
issue the command REFRESH CLUSTER(DEMO)
Note: For
large clusters, use of the REFRESH CLUSTER command can be
disruptive to the cluster while it is in progress, and again at 27 day
intervals thereafter when the cluster objects automatically send status updates
to all interested queue managers.
Problem 3 — Possible repository messages deleted.
Situation:
Messages
destined for QM1 were removed from the SYSTEM.CLUSTER.TRANSMIT.QUEUE in other
queue managers and they might have been repository messages
Point of
command usage:
On QM1,
issue the command REFRESH CLUSTER(DEMO)
Note: For
large clusters, use of the REFRESH CLUSTER command can be
disruptive to the cluster while it is in progress, and again at 27 day
intervals thereafter when the cluster objects automatically send status updates
to all interested queue managers.
Problem 4
— 2 full repositories moved at the same time.
Cluster DEMO contains two full repositories, QM1
and QM2. They were both moved to a new location on the network at the same
time.
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).
Note: For
large clusters, use of the REFRESH CLUSTER command can be
disruptive to the cluster while it is in progress, and again at 27 day
intervals thereafter when the cluster objects automatically send status updates
to all interested queue managers.
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.
Comments