Planning how you use multiple cluster transmission queues

You can explicitly define transmission queues, or have the system generate the transmission queues for you. If you define the transmission queues yourself, you have more control over the queue definitions. [z/OS]On z/OS®, you also have more control over the page set where the messages are held.

Defining the transmission queues

There are two methods of defining transmission queues:
  • Automatically, using the queue manager attribute DEFCLXQ, as follows: 
    
ALTER QMGR DEFCLXQ(SCTQ | CHANNEL)

    DEFCLXQ(SCTQ) indicates that the default transmission queue for all cluster-sender channels is SYSTEM.CLUSTER.TRANSMIT.QUEUE. This is the default value.

    DEFCLXQ(CHANNEL) indicates that by default each cluster-sender channel uses a separate transmission queue named SYSTEM.CLUSTER.TRANSMIT.<channel name>. Each transmission queue is automatically defined by the queue manager. See Automatically-defined cluster transmission queues for more information.

  • Manually, by defining a transmission queue with a value specified for the CLCHNAME attribute. The CLCHNAME attribute indicates which cluster-sender channels should use the transmission queue. See Planning for manually-defined cluster transmission queues for more information.

What security do I need?

To initiate a switch, either automatically or manually, you need authority to start a channel.

To define the queue used as a transmission queue, you need standard IBM® MQ authority to define the queue.

When is a suitable time to implement the change?

When changing the transmission queue used by cluster-sender channels, you need to allocate a time in which to make the update, considering the following points:
  • The time required for a channel to switch transmission queue depends on the total number of messages on the old transmission queue, how many messages need to be moved, and the size of the messages.
  • Applications can continue to put messages to the transmission queue while the change is happening. This might lead to an increase in the transition time.
  • You can change the CLCHNAME parameter of any transmission queue or DEFCLXQ at any time, preferably when the workload is low.

    Note that nothing happens immediately.

  • Changes occur only when a channel starts or restarts. When a channel starts it checks the current configuration and switches to a new transmission queue if required.
  • There are several changes that might alter the association of a cluster-sender channel with a transmission queue:
    • Altering the value of a transmission queue's CLCHNAME attribute, making CLCHNAME less specific or blank.
    • Altering the value of a transmission queue's CLCHNAME attribute, making CLCHNAME more specific.
    • Deleting a queue with CLCHNAME specified.
    • Altering the queue manager attribute DEFCLXQ.

How long will the switch take?

During the transition period, any messages for the channel are moved from one transmission queue to another. The time required for a channel to switch transmission queue depends on the total number of messages on the old transmission queue, and how many messages need to be moved.

For queues containing a few thousand messages, it should take under a second to move the messages. The actual time depends on the number and size of the messages. Your queue manager should be able to move messages at many megabytes each second.

Applications can continue to put messages to the transmission queue while the change is happening. This might lead to an increase in the transition time.

Each affected cluster-sender channel must be restarted for the change to take effect. Therefore, it is best to change the transmission queue configuration when the queue manager is not busy, and few messages are stored on the cluster transmission queues.

The runswchl command, [z/OS]or the SWITCH CHANNEL(*) STATUS command in CSQUTIL on z/OS, can be used to query the status of cluster-sender channels and what pending changes are outstanding to their transmission queue configuration.

How to implement the change

See Implementing the system using multiple cluster transmission queues for details on how you make the change to multiple cluster transmission queues, either automatically or manually.

Undoing the change

See Undoing a change for details on how you back out changes if you encounter problems.