Removing a cluster queue from a queue manager - Middleware News

Removing a cluster queue from a queue manager - Middleware News



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:

The INVENTORY cluster has been set up as described in Task 3: Adding a new queue manager that hosts a queue. It contains four queue managers. LONDON and NEWYORK both hold full repositories. PARIS and TORONTO hold partial repositories. The inventory application runs on the systems in New York and Toronto and is driven by the arrival of messages on the INVENTQ queue.
Because of reduced workload, you no longer want to run the inventory application in Toronto. You want to disable the INVENTQ queue hosted by the queue manager TORONTO, and have TORONTO feed messages to the INVENTQ queue in NEWYORK.
Network connectivity exists between all four systems.
The network protocol is TCP.

Procedure

Follow these steps to move a full repository to another queue manager.
1. Indicate that the queue is no longer available
To remove a queue from a cluster, remove the cluster name from the local queue definition. Do this from queue manager TORONTO, using the ALTER QLOCAL command and specifying a blank cluster name, like this:

ALTER QLOCAL(INVENTQ) CLUSTER(' ')

2. Check that the queue is no longer available
On a full repository queue manager, either LONDON or NEWYORK , check that the queue is no longer hosted by queue manager TORONTO by issuing the following command:

DIS QCLUSTER (INVENTQ)

You should see only the queue hosted by NEWYORK.
3. Disable the queue
Disable the INVENTQ queue at TORONTO so that no further messages can be written to it:

ALTER QLOCAL(INVENTQ) PUT(DISABLED)

Now messages in transit to this queue using MQOO_BIND_ON_OPEN will go to the dead-letter queue. You need to stop all applications from putting messages explicitly to the queue on this queue manager.
4. Monitor the queue until it is empty

Monitor the queue using the DISPLAY QUEUE command and specifying the attributes IPPROCS, OPPROCS, and CURDEPTH, or use the WRKMQMQSTS command on i5/OS®. When the number of input processes, the number of output processes, and the current depth of the queue are all zero, you can be sure that the queue is empty.
5. Monitor the channel to ensure there are no in-doubt messages
To be sure that there are no in-doubt messages on the channel TO.TORONTO, monitor the cluster-sender channel called TO.TORONTO on each of the other queue managers. To do this, issue the DISPLAY CHSTATUS command specifying the INDOUBT parameter from each queue manager:

DISPLAY CHSTATUS(TO.TORONTO) INDOUBT

If there are any in-doubt messages, you must resolve them before proceeding. For example, you might try issuing the RESOLVE channel command or stopping and restarting the channel.
6. Delete the local queue
When you are satisfied that there are no more messages to be delivered to the inventory application at TORONTO, you can delete the queue:

DELETE QLOCAL(INVENTQ)

The cluster set up by this task is similar to that set up by the previous task, except that the INVENTQ queue is no longer available at queue manager TORONTO.

When you take the queue out of service (step 1), the TORONTO queue manager sends a message to the two full repository queue managers notifying them of the change in status. The full repository queue managers pass on this information to other queue managers in the cluster that have requested updates to information concerning the INVENTQ.

Now when a queue manager has a message to put on the INVENTQ queue, its updated partial repository indicates that the INVENTQ queue is available only at the NEWYORK queue manager, and so the message is sent there.

You can now remove the inventory application from the system in Toronto, to avoid duplication and save space on the system.

In this task description there is only one queue to remove and only one cluster to remove it from.
Suppose that there were many queues referring to a namelist containing many cluster names. For example, the TORONTO queue manager might host not only the INVENTQ, but also the PAYROLLQ, SALESQ, and PURCHASESQ. TORONTO makes these queues available in all the appropriate clusters, INVENTORY, PAYROLL, SALES, and PURCHASES. To do this, TORONTO defines a namelist of the cluster names:

DEFINE NAMELIST(TOROLIST)
DESCR('List of clusters TORONTO is in')
NAMES(INVENTORY, PAYROLL, SALES, PURCHASES)

and specifies this namelist on each queue definition, like this:

DEFINE QLOCAL(INVENTQ) CLUSNL(TOROLIST)
DEFINE QLOCAL(PAYROLLQ) CLUSNL(TOROLIST)
DEFINE QLOCAL(SALESQ) CLUSNL(TOROLIST)
DEFINE QLOCAL(PURCHASESQ) CLUSNL(TOROLIST)

Now suppose that you want to remove all those queues from the SALES cluster, because the SALES operation is to be taken over by the PURCHASES operation. All you need to do is alter the TOROLIST namelist to remove the name of the SALES cluster from it.
If you want to remove a single queue from one of the clusters in the namelist, create a new namelist, containing the remaining list of cluster names, and then alter the queue definition to use the new namelist. To remove the PAYROLLQ from the INVENTORY cluster:

Create a new namelist:

DEFINE NAMELIST(TOROSHORTLIST)
DESCR('List of clusters TORONTO is in other than INVENTORY')
NAMES(PAYROLL, SALES, PURCHASES)

Alter the PAYROLLQ queue definition:

ALTER QLOCAL(PAYROLLQ) CLUSNL(TOROSHORTLIST)