IBM MQ queue managers

An introduction to queue managers and the queuing services that they provide to applications.

A program must have a connection to a queue manager before it can use the services of that queue manager. A program can make this connection explicitly (using the MQCONN or MQCONNX call), or the connection might be made implicitly (this depends on the platform and the environment in which the program is running).

• Object attributes are changed according to the commands received.
• Special events such as trigger events or instrumentation events are generated when the appropriate conditions are met.
• Messages are put on the correct queue, as requested by the application making the MQPUT call. The application is informed if this cannot be done, and an appropriate reason code is given.

Each queue belongs to a single queue manager and is said to be a local queue to that queue manager. The queue manager to which an application is connected is said to be the local queue manager for that application. For the application, the queues that belong to its local queue manager are local queues.

A remote queue is a queue that belongs to another queue manager. A remote queue manager is any queue manager other than the local queue manager. A remote queue manager can exist on a remote machine across the network, or might exist on the same machine as the local queue manager. IBM MQ supports multiple queue managers on the same machine.

A queue manager object can be used in some MQI calls. For example, we can inquire about the attributes of the queue manager object using the MQI call MQINQ.

Attributes of queue managers

Associated with each queue manager is a set of attributes (or properties) that define its characteristics. Some of the attributes of a queue manager are fixed when it is created; we can change others using the IBM MQ commands. We can inquire about the values of all the attributes, except those used for Transport Layer Security (TLS) encryption, using the MQINQ call.

• The name of the queue manager
• The platform on which the queue manager runs (for example, Windows )
• The level of system control commands that the queue manager supports
• The maximum priority that we can assign to messages processed by the queue manager
• The name of the queue to which programs can send IBM MQ commands
• The maximum length of messages the queue manager can process (fixed only in IBM MQ for z/OS® )
• Whether the queue manager supports syncpointing when programs put and get messages

• A text description of the queue manager
• The identifier of the character set the queue manager uses for character strings when it processes MQI calls
• The time interval that the queue manager uses to restrict the number of trigger messages
• The time interval that the queue manager uses to determine how often queues are to be scanned for expired messages ( IBM MQ for z/OS only)
• The name of the queue manager's dead-letter (undelivered message) queue
• The name of the queue manager's default transmission queue
• The maximum number of open handles for any one connection
• The enabling and disabling of various categories of event reporting
• The maximum number of uncommitted messages within a unit of work

Queue managers and workload management

We can set up a cluster of queue managers that has more than one definition for the same queue (for example, the queue managers in the cluster could be clones of each other). Messages for a particular queue can be handled by any queue manager that hosts an instance of the queue. A workload-management algorithm decides which queue manager handles the message and so spreads the workload between your queue managers; see The cluster workload management algorithm for further information.