Other things to consider for distributed queue management
Other topics to consider when preparing IBM MQ for distributed queue management. This topic covers Undelivered-message queue, Queues in use, System extensions and user-exit programs, and Running channels and listeners as trusted applications.
Undelivered-message queue
To ensure that messages arriving on the undelivered-message queue (also known as the dead-letter queue or DLQ) are processed, create a program that can be triggered or run at regular intervals to handle these messages.
A DLQ handler is provided with IBM MQ on UNIX and Linux systems; for more information, see The sample DLQ handler, amqsdlq.
For more information on IBM MQ for IBM i, see The IBM MQ for IBM i dead-letter queue handler.
Queues in use
MCAs for receiver channels can keep the destination queues open even when messages are not being transmitted. This results in the queues appearing to be in use
.
Maximum number of channels
On IBM MQ for IBM i we can specify the maximum number of channels allowed in the system and the maximum number that can be active at one time. You specify these numbers in the qm.ini file in directory QIBM/UserData/mqm/qmgrs/queue_manager_name. See Configuration file stanzas for distributed queuing.
System extensions and user-exit programs
A facility is provided in the channel definition to enable extra programs to be run at defined times during the processing of messages. These programs are not supplied with IBM MQ, but can be provided by each installation according to local requirements.
In order to run, these user-exit programs must have predefined names and be available on call to the channel programs. The names of the user-exit programs are included in the message channel definitions.
There is a defined control block interface for handing over control to these programs, and for handling the return of control from these programs.
The precise places where these programs are called, and details of control blocks and names, are to be found in Channel-exit programs for messaging channels.
Running channels and listeners as trusted applications
If performance is an important consideration in the environment and the environment is stable, we can run your channels and listeners as trusted, using the FASTPATH binding. There are two factors that influence whether channels and listeners run as trusted:- The environment variable MQ_CONNECT_TYPE=FASTPATH or MQ_CONNECT_TYPE=STANDARD. This is case-sensitive. If you specify a value that is not valid it is ignored.
- MQIBindType in the Channels stanza of the qm.ini or registry file. We can set this to FASTPATH or STANDARD and it is not case-sensitive. The default is STANDARD.
We can use MQIBindType in association with the environment variable to achieve the required effect as follows:
| MQIBindType | Environment variable | Result |
|---|---|---|
| STANDARD | UNDEFINED | STANDARD |
| FASTPATH | UNDEFINED | FASTPATH |
| STANDARD | STANDARD | STANDARD |
| FASTPATH | STANDARD | STANDARD |
| STANDARD | FASTPATH | STANDARD |
| FASTPATH | FASTPATH | FASTPATH |
| STANDARD | CLIENT | CLIENT |
| FASTPATH | CLIENT | STANDARD |
| STANDARD | LOCAL | STANDARD |
| FASTPATH | LOCAL | STANDARD |
- By specifying MQIBindType=FASTPATH in qm.ini or registry and not specifying the environment variable.
- By specifying MQIBindType=FASTPATH in qm.ini or registry and setting the environment variable to FASTPATH.
Consider running listeners as trusted, because listeners are stable processes. Consider running channels as trusted, unless we are using unstable channel exits or the command STOP CHANNEL MODE(TERMINATE).
Parent topic: Introduction to distributed queue management