Different Types Queues in Websphere MQ

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.

1. 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.
2. 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, you must 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.

3. 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 you can use to access another queue.

4. 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(R), iSeries, HP-UX, Solaris, and Windows(R).

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, you
must 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:

o An application attempting to put a message on a queue that is not available or does

not exist.
o A queue becoming full.
o 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.