Local queues

Transmission, initiation, dead-letter, command, default, channel, and event queues are types of local queue.

A queue is known to a program as local if it is owned by the queue manager to which the program is connected. We can get messages from, and put messages on, local queues.

The queue definition object holds the definition information of the queue as well as the physical messages put on the queue.

Each queue manager can have some local queues that it uses for special purposes:

    Transmission queues

    When an application sends a message to a remote queue, the local queue manager stores the message in a special local queue, called a transmission queue. Applications can put messages directly on a transmission queue, or indirectly through a remote queue definition.

    When a queue manager sends messages to a remote queue manager, it identifies the transmission queue using the following sequence:
    1. The transmission queue named on the XMITQ attribute of the local definition of a remote queue.
    2. A transmission queue with the same name as the remote queue manager. This value is the default value on XMITQ of the local definition of a remote queue.
    3. The transmission queue named on the DEFXMITQ attribute of the local queue manager.

    A message channel agent is a channel program is associated with the transmission queue and it delivers the message to its next destination. The next destination is the queue manager to which the message channel is connected. It is not necessarily the same queue manager as the final destination of the message. When the message is delivered to its next destination, it is deleted from the transmission queue. The message might have to pass through many queue managers on its journey to its final destination. We must define a transmission queue at each queue manager along the route, each holding messages waiting to be transmitted to the next destination. A normal transmission queue holds messages for the next destination, although the messages might have different eventual destinations. A cluster transmission queue holds messages for multiple destinations. The correlID of each message identifies the channel that the message is placed on to transfer it to its next destination.

    We can define several transmission queues at a queue manager. We might define several transmission queues for the same destination, with each one being used for a different class of service. For example, you might want to create different transmission queues for small messages and large messages going to the same destination. We can then transfer the messages using different messages channels, so that the large messages do not hold up the smaller messages. All messages to cluster queues or cluster topics are placed on the single cluster transmission queue SYSTEM.CLUSTER.TRANSMIT.QUEUE, by default. As an option, we can change the default, and separate the message traffic going to different cluster queue managers onto different cluster transmission queues. If you set the queue manager attribute DEFCLXQ to CHANNEL, each cluster-sender channel creates a separate cluster transmission queue. As an alternative, we can manually define cluster transmission queues for cluster-sender channels to use.

    Transmission queues can trigger a message channel agent to send messages onward; see Starting IBM MQ applications using triggers.

    On IBM MQ for z/OS, if we are using intra-group queuing, the transmission queue is serviced by an intra-group queuing agent. A shared transmission queue is used when using intra-group queuing on IBM MQ for z/OS.

    Initiation queues

    An initiation queue is a local queue on which the queue manager puts a trigger message when a trigger event occurs on an application queue.

    A trigger event is an event that is intended to cause a program to start processing a queue. For example, an event might be more than 10 messages arriving. For more information about how triggering works, see Starting IBM MQ applications using triggers.

    Dead-letter (undelivered message) queue

    A dead-letter (undelivered message) queue is a local queue on which the queue manager puts messages that it cannot deliver.

    When the queue manager puts a message on the dead-letter queue, it adds a header to the message. The header information includes the reason that the queue manager put the message on the dead-letter queue. It also contains the destination of the original message, the date, and the time that the queue manager put the message on the dead-letter queue.

    Applications can also use the queue for messages that they cannot deliver. For more information, see Use the dead-letter (undelivered message) queue.

    System command queue

    The system command queue is a queue to which suitably authorized applications can send IBM MQ commands. These queues receive the PCF, MQSC, and CL commands, as supported on the platform, in readiness for the queue manager to action them.

    On IBM MQ for z/OS the queue is called SYSTEM.COMMAND.INPUT ; on other platforms it is called SYSTEM.ADMIN.COMMAND.QUEUE. The commands accepted vary by platform. See Programmable command formats reference for details.

    System default queues

    The system default queues contain the initial definitions of the queues for the system. When creating a queue definition, the queue manager copies the definition from the appropriate system default queue. Creating a queue definition is different from creating a dynamic queue. The definition of the dynamic queue is based upon the model queue you choose as the template for the dynamic queue.

    Event queues
    Event queues hold event messages. These messages are reported by the queue manager or a channel.

Parent topic: Queues