IBM MQ 7.5 was EOS 30th April 2018.Click EOS notice for more details
Adding a cluster and a cluster transmit queue to isolate cluster
message traffic sent from a gateway queue manager
Modify the configuration of overlapping clusters
that use a gateway queue manager. After the modification messages
are transferred to an application from the gateway queue manager without
using the same transmission queue or channels as other cluster messages. The
solution uses an additional cluster to isolate the messages to a particular
cluster queue.
Before you begin
The steps in the task are written to modify the configuration
illustrated in Figure 1.
The gateway queue manager must be on Version 7.5, or later, and on a platform other
than z/OS®.
The solution to isolating message traffic to a single
application in Adding a cluster transmit queue to isolate cluster message traffic sent from a gateway queue manager works if the target
cluster queue is the only cluster queue on a queue manager. If it
is not, you have two choices. Either move the queue to a different
queue manager, or create a cluster that isolates the queue from other
cluster queues on the queue manager.
This task takes you through
the steps to add a cluster to isolate the target queue. The cluster
is added just for that purpose. In practice, approach the task of
isolating certain applications systematically when you are in the
process of designing clusters and cluster naming schemes. Adding a
cluster each time a queue requires isolation might end up with many
clusters to manage. In this task, you change the configuration in Adding a cluster transmit queue to isolate cluster message traffic sent from a gateway queue manager by adding a cluster CL3 to
isolate Q1 on QM3. Applications
continue to run throughout the change.
The new and changed definitions
are highlighted in Figure 1. The summary
of the changes is as follows: Create a cluster, which means you must
also create a new full cluster repository. In the example, QM3 is
made one of the full repositories for CL3. Create
cluster-sender and cluster-receiver channels for QM1to
add the gateway queue manager to the new cluster. Change the definition
of Q1 to switch it to CL3. Modify
the cluster namelist on the gateway queue manager, and add a cluster
transmission queue to use the new cluster channel. Finally, switch
the queue alias Q1A to the new cluster namelist.
IBM®WebSphere® MQ cannot transfer messages from
the transmission queue XMITQ.CL2.QM3 that you added
in Adding a cluster transmit queue to isolate cluster message traffic sent from a gateway queue manager to the new transmission queue XMITQ.CL3.QM3,
automatically. It can transfer messages automatically only if both
transmission queues are served by the same cluster-sender channel.
Instead, the task describes one way to perform the switch manually,
which might be appropriate to you. When the transfer is completed,
you have the option of reverting to using the default cluster transmission
queue for other CL2 cluster queues on QM3.
Or you can continue to use XMITQ.CL2.QM3. If you
decide to revert to a default cluster transmission queue, the gateway
queue manager manages the switch for you automatically.
Procedure
Alter the queue managers QM3 and QM5 to
make them repositories for both CL2 and CL3.
To make a queue manager a member of multiple clusters, it
must use a cluster name list to identify the clusters it is a member
of.
*... On QM3 and QM5
DEFINE NAMELIST(CL23) NAMES(CL2, CL3) REPLACE
ALTER QMGR REPOS(' ') REPOSNL(CL23)
Define the channels between the queue managers QM3 and QM5 for CL3.
Add the gateway queue manager by adding QM1 to CL3 as
a partial repository. Create a partial repository by adding cluster-sender
and cluster-receiver channels to QM1.
Also,
add CL3 to the name list of all clusters connected
to the gateway queue manager.
*... On QM1
DEFINE CHANNEL(CL3.QM3) CHLTYPE(CLUSSDR) CONNAME('localhost(1413)') CLUSTER(CL3) REPLACE
DEFINE CHANNEL(CL3.QM1) CHLTYPE(CLUSRCVR) CONNAME('localhost(1411)') CLUSTER(CL3) REPLACE
ALTER NAMELIST(ALL) NAMES(CL1, CL2, CL3)
Add a cluster transmission queue to the gateway queue manager, QM1,
for messages going to CL3 on QM3.
Initially, stop the cluster-sender channel transferring messages
from the transmission queue until you are ready to switch transmission
queues.
*... On QM1
DEFINE QLOCAL(XMITQ.CL3.QM3) USAGE(XMITQ) CLCHNAME(CL3.QM3) GET(DISABLED) REPLACE
Drain messages from the existing cluster transmission queue XMITQ.CL2.QM3.
This subprocedure is intended to preserve the order of messages
in Q1 to match the order they arrived at the gateway
queue manager. With clusters, message ordering is not fully guaranteed,
but is likely. If guaranteed message ordering is required, applications
must define the order of messages; see The order in which messages are retrieved from a queue.
Change the target queue Q1 on QM3 from CL2 to CL3.
*... On QM3
ALTER QLOCAL(Q1) CLUSTER(CL3)
Monitor XMITQ.CL3.QM3 until messages
start to be delivered to it.
Messages start to be delivered
to XMITQ.CL3.QM3 when the switch of Q1 to CL3 is
propagated to the gateway queue manager.
*... On QM1
DISPLAY QUEUE(XMITQ.CL3.QM3) CURDEPTH
Monitor XMITQ.CL2.QM3 until it has
no messages waiting to be delivered to Q1 on QM3.
Note:XMITQ.CL2.QM3 might be storing messages
for other queues on QM3 that are members of CL2,
in which case the depth might not go to zero.
*... On QM1
DISPLAY QUEUE(XMITQ.CL2.QM3) CURDEPTH
Enable get from the new cluster transmission queue, XMITQ.CL3.QM3
*... On QM1
ALTER QLOCAL(XMITQ.CL3.QM3) GET(ENABLED)
Remove the old cluster transmission queue, XMITQ.CL2.QM3,
if it is no longer required.
Messages for cluster queues
in CL2 on QM3 revert to using the
default cluster transmission queue on the gateway queue manager, QM1.
The default cluster transmission queue is either SYSTEM.CLUSTER.TRANSMIT.QUEUE,
or SYSTEM.CLUSTER.TRANSMIT.CL2.QM3. Which one depends
on whether the value of the queue manager attribute DEFCLXQ on QM1 is SCTQ or CHANNEL.
The queue manager transfers messages from XMITQ.CL2.QM3 automatically
when the cluster-sender channel CL2.QM3 next starts.
Change the transmission queue, XMITQ.CL2.QM3,
from being a cluster transmission queue to being a normal transmission
queue.
This breaks the association of the transmission
queue with any cluster-sender channels. In response, IBMWebSphere MQ automatically transfers messages
from XMITQ.CL2.QM3 to the default cluster transmission
queue when the cluster-sender channel is next started. Until then,
messages for CL2 on QM3 continue
to be placed on XMITQ.CL2.QM3.
*... On QM1
ALTER QLOCAL(XMITQ.CL2.QM3) CLCHNAME(' ')
Stop the cluster-sender channel CL2.QM3.
Stopping and restarting the cluster-sender channel initiates
the transfer of messages from XMITQ.CL2.QM3 to the
default cluster transmission queue. Typically you would stop and start
the channel manually to start the transfer. The transfer starts automatically
if the channel restarts after shutting down on the expiry of its disconnect
interval.
*... On QM1
STOP CHANNEL(CL2.QM3)
The response
is that the command is accepted:
AMQ8019: Stop WebSphere MQ channel accepted.
Check that the channel CL2.QM3 is stopped
If the channel does not stop, you can run the STOP
CHANNEL command again with the FORCE option.
An example of setting the FORCE option would be if
the channel does not stop, and you cannot restart the other queue
manager to synchronize the channel.
*... On QM1
DISPLAY CHSTATUS(CL2.QM3)
The
response is a summary of the channel status
AMQ8417: Display Channel Status details.
CHANNEL(CL2.QM3) CHLTYPE(CLUSSDR)
CONNAME(127.0.0.1(1413)) CURRENT
RQMNAME(QM3) STATUS(STOPPED)
SUBSTATE(MQGET) XMITQ(XMITQ.CL2.QM3)
Start the channel, CL2.QM3.
*... On QM1
START CHANNEL(CL2.QM3)
The response
is that the command is accepted:
AMQ8018: Start WebSphere MQ channel accepted.
Check the channel started.
*... On QM1
DISPLAY CHSTATUS(CL2.QM3)
The
response is a summary of the channel status:
AMQ8417: Display Channel Status details.
CHANNEL(CL2.QM3) CHLTYPE(CLUSSDR)
CONNAME(127.0.0.1(1413)) CURRENT
RQMNAME(QM3) STATUS(RUNNING)
SUBSTATE(MQGET) XMITQ(SYSTEM.CLUSTER.TRANSMIT.QUEUE|CL2.QM3)
Monitor the gateway queue manager error log for the
message AMQ7341The transmission queue
for channel CL2.QM3 is SYSTEM.CLUSTER.TRANSMIT.QUEUE|CL2.QM3.
Delete the cluster transmission queue, XMITQ.CL2.QM3.
*... On QM1
DELETE QLOCAL(XMITQ.CL2.QM3)
What to do next
Test the separately clustered queue by sending a message
from QM2 to Q1 on QM3 using
the queue alias definition Q1A
Run the sample program amqsput on QM2 to
put a message.
C:\IBM\MQ>amqsput Q1A QM2
Sample AMQSPUT0 start
target queue is Q1A
Sample request message from QM2 to Q1 using Q1A
Sample AMQSPUT0 end
Run the sample program amqsget to get the message
from Q1 on QM3
C:\IBM\MQ>amqsget Q1 QM3
Sample AMQSGET0 start
message <Sample request message from QM2 to Q1 using Q1A>
no more messages
Sample AMQSGET0 end