WebSphere MQ queues

Note:

The WebSphere MQ process definition, channel, and namelist objects can be defined in a similar manner.

The commands specify the type of queue and its attributes. For example, a local queue object has attributes that specify what happens when applications reference that queue in MQI calls. Examples of attributes are:

Whether applications can retrieve messages from the queue (GET enabled).
Whether applications can put messages on the queue (PUT enabled).
Whether access to the queue is exclusive to one application or shared between applications.
The maximum number of messages that can be stored on the queue at the same time (maximum queue depth).
The maximum length of messages that can be put on the queue.

For further details about defining queue objects, see the WebSphere MQ Script (MQSC) Command Reference or WebSphere MQ Programmable Command Formats and Administration Interface.

Using queue objects

There are four types of queue object available in WebSphere MQ. Each type of object can be manipulated by the product commands and is associated with real queues in different ways.

Local queue object
A local queue object identifies a local queue belonging to the queue manager to which the application is connected. All queues are local queues in the sense that each queue belongs to a queue manager and, for that queue manager, the queue is a local queue.
A remote queue object
A remote queue object identifies a queue belonging to another queue manager. This queue must be defined as a local queue to that queue manager. The information you specify when you define a remote queue object allows the local queue manager to find the remote queue manager, so that any messages destined for the remote queue go to the correct queue manager.
Before applications can send messages to a queue on another queue manager, have defined a transmission queue and channels between the queue managers, unless you have grouped one or more queue managers together into a cluster. For more information about clusters, see WebSphere MQ Queue Manager Clusters.
An alias queue object
An alias queue allows applications to access a queue by referring to it indirectly in MQI calls. When an alias queue name is used in an MQI call, the name is resolved to the name of either a local or a remote queue at run time. This allows you to change the queues that applications use without changing the application in any way. You just change the alias queue definition to reflect the name of the new queue to which the alias resolves.
An alias queue is not a queue, but an object that we can use to access another queue.
A model queue object
A model queue defines a set of queue attributes that are used as a template for creating a dynamic queue. Dynamic queues are created by the queue manager when an application issues an MQOPEN request specifying a queue name that is the name of a model queue. The dynamic queue that is created in this way is a local queue whose attributes are taken from the model queue definition. The dynamic queue name can be specified by the application or the queue manager can generate the name and return it to the application.
Dynamic queues defined in this way are either temporary queues, which do not survive product restarts, or permanent queues, which do.

Specific local queue types and their uses

WebSphere MQ uses some local queues for specific purposes related to its operation. These are:

Application queues
This is a queue that is used by an application through the MQI. It can be a local queue on the queue manager to which an application is linked, or it can be a remote queue that is owned by another queue manager.
Applications can put messages on local or remote queues. However, they can only get messages from a local queue.
Initiation queues
Initiation queues are queues that are used in triggering. A queue manager puts a trigger message on an initiation queue when a trigger event occurs. A trigger event is a logical combination of conditions that is detected by a queue manager. For example, a trigger event might be generated when the number of messages on a queue reaches a predefined depth. This event causes the queue manager to put a trigger message on a specified initiation queue. This trigger message is retrieved by a trigger monitor, a special application that monitors an initiation queue. The trigger monitor then starts up the application program that was specified in the trigger message.
If a queue manager is to use triggering, at least one initiation queue must be defined for that queue manager.
See Working with triggering For more information about triggering, see the WebSphere MQ Application Programming Guide.
Transmission queues
Transmission queues are queues that temporarily stores messages that are destined for a remote queue manager. You must define at least one transmission queue for each remote queue manager to which the local queue manager is to send messages directly. These queues are also used in remote administration. For information about the use of transmission queues in distributed queuing, see WebSphere MQ Intercommunication.
Cluster transmission queues
Each queue manager within a cluster has a cluster transmission queue called SYSTEM.CLUSTER.TRANSMIT.QUEUE. A definition of this queue is created by default on every queue manager on WebSphere MQ for AIX, iSeries, HP-UX, Solaris, and Windows.
A queue manager that is part of the cluster can send messages on the cluster transmission queue to any other queue manager that is in the same cluster.
Cluster queue managers can communicate with queue managers that are not part of the cluster. To do this, the queue manager must define channels and a transmission queue to the other queue manager in the same way as in a traditional distributed-queuing environment.
For more information on using clusters, see WebSphere MQ Queue Manager Clusters.
Dead-letter queues
A dead-letter queue is a queue that stores messages that cannot be routed to their correct destinations. This occurs when, for example, the destination queue is full. The supplied dead-letter queue is called SYSTEM.DEAD.LETTER.QUEUE. These queues are sometimes referred to as undelivered-message queues.
A dead-letter queue is defined by default when each queue manager is created. However, ensure that the queue manager on which this queue resides points to the dead-letter queue that it is going to use.
The following command creates an undelivered-message queue on queue manager neptune.queue.manager:
```
CRTMQM MQMNAME(neptune.queue.manager) UDLMSGQ(ANOTHERDLQ)
```
Command queues
The command queue, named SYSTEM.ADMIN.COMMAND.QUEUE, is a local queue to which suitably authorized applications can send WebSphere MQ commands for processing. These commands are then retrieved by a WebSphere MQ component called the command server. The command server validates the commands, passes the valid ones on for processing by the queue manager, and returns any responses to the appropriate reply-to queue.
A command queue is created automatically for each queue manager when that queue manager is created.
Reply-to queues
When an application sends a request message, the application that receives the message can send back a reply message to the sending application. This message is put on a queue, called a reply-to queue, which is normally a local queue to the sending application. The name of the reply-to queue is specified by the sending application as part of the message descriptor.
Event queues
WebSphere MQ for iSeries supports instrumentation events, which can be used to monitor queue managers independently of MQI applications. Instrumentation events can be generated in several ways, for example:
- An application attempting to put a message on a queue that is not available or does not exist.
- A queue becoming full.
- A channel being started.
When an instrumentation event occurs, the queue manager puts an event message on an event queue. This message can then be read by a monitoring application, which informs an administrator or initiate some remedial action if the event indicates a problem.
Note:
Trigger events are quite different from instrumentation events in that trigger events are not caused by the same conditions, and do not generate event messages.
For more information about instrumentation events, see Monitoring WebSphere MQ.