Channel initiators and listeners
A channel initiator acts as a trigger monitor for sender channels, because a transmission queue may be defined as a triggered queue. When a message arrives on a transmission queue that satisfies the triggering criteria for that queue, a message is sent to the initiation queue, triggering the channel initiator to start the appropriate sender channel. We can also start server channels in this way if you specified the connection name of the partner in the channel definition. This means that channels can be started automatically, based upon messages arriving on the appropriate transmission queue.
You need a channel listener program to start receiving (responder) MCAs. Responder MCAs are started in response to a startup request from the caller MCA; the channel listener detects incoming network requests and starts the associated channel.
Figure 1 shows how channel initiators and channel listeners are used.
Figure 1. Channel initiators and listeners
The implementation of channel initiators is platform specific.
- In z/OS, there is one channel initiator for each queue manager and it runs as a separate address space. You start it using the WebSphere MQ command START CHINIT, which you would normally issue as part of your queue manager startup. It monitors the system-defined queue SYSTEM.CHANNEL.INITQ, which is the initiation queue that is recommended for all the transmission queues.
- On other platforms, we can start as many channel initiators as you like, specifying a name for the initiation queue for each one. Normally we need only one initiator. WebSphere MQ for AIX, iSeries, HP-UX, Solaris, and Windows systems allow you to start up to three channel initiators (the default value), but we can change this value. The default behavior is to start a channel initiator when a queue manager is automatically started. We can change this by setting the SCHINIT attribute of the queue manager to MANUAL.
The channel initiator is also required for other functions. These are discussed later in this book.
The implementation of channel listeners is platform specific.
- Use the channel listener programs provided by WebSphere MQ if you are using z/OS.
On z/OS, The TCP/IP listener can be started many times with different combinations of port number and address to listen on. For more information, see Listeners .
- On i5/OS, use the channel listener program provided by WebSphere MQ if you are using TCP/IP. If you are using SNA, you do not need a listener program. SNA starts the channel by invoking the receiver program on the remote system.
- On Windows systems, we can use either the channel listener program provided by WebSphere MQ, or the facilities provided by the operating system. If performance is important in your environment and if the environment is stable, we can choose to run the WebSphere MQ listener as a trusted application as described in Running channels and listeners as trusted applications. See the WebSphere MQ Application Programming Guide for information about trusted applications.
- On UNIX systems, use the channel listener program provided by WebSphere MQ or the facilities provided by the ‘operating system’ (for example, inetd for TCP/IP communications).
By default, threaded channels started by the channel initiator or a listener do not run under that process but under a process called AMQRMPPA, otherwise known as a pool process. To revert to the MQSeries V5.2 behavior and have channels run under the originating process we can define an environment variable MQNOREMPOOL. The existence of this variable, set to any value, will cause the channel threads to run as part of the listener or channel initiator process. This can be useful when trying to isolate one or more channels from the rest of the configuration, for example when testing channel exits.
Parent topic:
Distributed queuing components
ic10400_
Home
