Transmission queues and triggering

Before a channel (other than a requester channel) can be started, the transmission queue must be defined as described in this chapter, and must be included in the message channel definition.

In addition, where needed, the triggering arrangement must be prepared with the definition of the necessary processes and queues.

 

Creating a transmission queue

Define a local queue with the USAGE attribute set to XMITQ for each sending message channel. If you want to make use of a specific transmission queue in your remote queue definitions, create a remote queue as shown below.

To create a transmission queue, use the WebSphere MQ Commands (MQSC), as shown in the following examples:

Create transmission queue example
DEFINE QLOCAL(LONDON) DESCR('Transmission queue to LONDON') USAGE(XMITQ)

Create remote queue example
DEFINE QREMOTE(PAYROLL) DESCR('Remote queue for LONDON') +
XMITQ(LONDON) RNAME(PAYROLL) RQMNAME(LONDON)

The recommended name for the transmission queue is the queue manager name on the remote system, as shown in the examples above.

 

Triggering channels

An overview of triggering is given in Triggering channels, while it is described in depth in the WebSphere MQ Application Programming Guide. This description provides you with information specific to WebSphere MQ for UNIX and Windows systems, and MQSeries for OS/2 Warp, Compaq OpenVMS Alpha, and Compaq NonStop Kernel.

You can create a process definition in WebSphere MQ, defining processes to be triggered. Use the MQSC command DEFINE PROCESS to create a process definition naming the process to be triggered when messages arrive on a transmission queue. The USERDATA attribute of the process definition should contain the name of the channel being served by the transmission queue.

Alternatively, you can eliminate the need for a process definition by specifying the channel name in the TRIGDATA attribute of the transmission queue.

If you do not specify a channel name, the channel initiator searches the channel definition files until it finds a channel that is associated with the named transmission queue.

 

Example definitions for triggering

Define the local queue (Q3), specifying that trigger messages are to be written to the default initiation queue SYSTEM.CHANNEL.INITQ, to trigger the application (process P1) that starts channel (AMSTERDAM.TO.QM4): 

DEFINE QLOCAL(QM4) TRIGGER INITQ(SYSTEM.CHANNEL.INITQ) PROCESS(P1) USAGE (XMITQ)

Define the application (process P1) to be started: 

DEFINE PROCESS(P1) USERDATA(AMSTERDAM.TO.QM4)

 

Examples

Define the local queue (Q3), specifying that trigger messages are to be written to the initiation queue (IQ) to trigger the application that starts channel (AMSTERDAM.TO.QM4): 

DEFINE QLOCAL(QM4) TRIGGER INITQ(SYSTEM.CHANNEL.INITQ) +
USAGE (XMITQ) TRIGDATA(AMSTERDAM.TO.QM4)

 

Starting the channel initiator

Triggering is implemented using the channel initiator process. On MQSeries for AT&T GIS UNIX, Compaq OpenVMS Alpha, SINIX and DC/OSx, and Compaq NonStop Kernel, this process is started with the run channel initiator command, runmqchi, or (on distributed platforms except Compaq NonStop Kernel) with the MQSC command START CHINIT. For example, to use the runmqchi command to start the default initiation queue for the default queue manager, enter: 

runmqchi

Whichever command you use, specify the name of the initiation queue on the command, unless you are using the default initiation queue. For example, to use the runmqchi command to start queue IQ for the default queue manager, enter: 

runmqchi -q IQ

To use the START CHINIT command (not on Compaq NonStop Kernel), enter: 

START CHINIT INITQ(IQ)

Note:
Compaq NonStop Kernel also allows control of the channel initiator from the PATHWAY environment. This is the recommended method. For more information about this, see the MQSeries for Compaq NonStop Kernel System Administration.

A channel initiator is started automatically and the number of channel initiators that you can start is limited. The default limit is 3. You can change this using MAXINITIATORS in the qm.ini file for AIX, HP-UX, OS/2 Warp, and Solaris, and in the registry for Windows systems.

 

Stopping the channel initiator

The default channel initiator is started automatically when you start a queue manager. Similarly, it is stopped automatically when a queue manager is stopped.

However, if you need to stop a channel initiator but not the queue manager, inhibit the queue that the initiator queue is reading from. To do this, you disable the GET attribute of the initiation queue. To restart the channel initiator, simply use the runmqchi command.

The consequences of stopping a channel initiator are:

  • If you stop the only channel initiator running, no channels that you have attempted to start will be retried.

  • If you have more than one channel initiator running, channels that have a transmission queue configured with this initiation queue are not automatically started. However, those channels configured for connection retries will continue to be retried.

 

WebSphere is a trademark of the IBM Corporation in the United States, other countries, or both.

 

IBM is a trademark of the IBM Corporation in the United States, other countries, or both.