Different types of Queue’s in IBM MQ and its usage

A queue is a container for messages. Business applications that are connected to the queue manager that hosts the queue can retrieve messages from the queue or can put messages on the queue.Let see the MQ objects and some theory about it .

Queues:

• Broadly queues can be categorized under 2 names, 

1. Predefined queue
2. Dynamic Queues

Predefined queues: 

• These are created by an administrator using the appropriate WebSphere MQ script (MQSC) commands or GUI tools. 
• Predefined queues are permanent.
• They exist independently of the applications that use them and survive WebSphere MQ restarts. 

Local queue (QLOCAL or QL)

• Local queues are the only type of queue object within a queue manager that can hold messages.
• Messages placed on the local queue, will occupy space on file system specified for it.
• An Application can place messages in local queue and can receive messages from it. 
• Triggering can be enabled for this type of queue.
• Messages in queue local won’t be passed on to another queue manager. So, to move messages from one local queue to another one needs to use other support packs and third party Utilities.

Alias queue object (QALIAS or QA)

• Alias queue objects provide a reference to another queue object with a different name. 
• The target queue object can be a local queue, a remote queue object, or a queue shared within the queue manager cluster.

Notes:

• Alias queue doesn’t store any messages in it. 
• An application can place a message and consume messages from Alias Queue.

Few practical scenarios for using Alias Queues,

Satisfying Naming conventions

• Each company/client will have their own naming standards for identifying objects or coding structures.
• To satisfy different naming standards one can create any number of Alias queues pointing to same base queue.

Providing Different level of access

• Allowing each application to access a base queue via an Alias queue, will facilitate us to restrict any particular application/program from accessing that queue without interrupting others.

Hiding the queue from other clients etc

• Sometimes, internal programs have to exchange information with external parties (clients).
• Keeping security reasons in mind, we can create alias queue pointing to the actual queue and will inform the other end team about Alias Queue only, not the base queue.

Model queue object (QMODEL or QM)

• Model queue object is nothing but a template of queue attributes referring which, application can create dynamic queues as needed. 

Notes:

• The attributes of the model queue object determine the attributes of the dynamic queue created.
• Model queue doesn’t store any messages in it. 

There are 2 types of dynamic queues, 

• Temporary dynamic queues
• Permanent Dynamic queues
• Type of dynamic queue to be created depends on one of model queue attribute value *DefinitionType*

Remote queue object (QREMOTE or QR)

• Remote Queue is local definitions of remote destination queue.
• This will provide destination Queue and Queue manager information to the message placed by Application. 
• Imagine this with the working of postal box operation for ease of understanding.
• A message passing through remote queue will get the address attached to it saying where it has to go.

Syntax of remote queue definition,

Define Qremote(Remote queue name) 
RNAME(destination queue name) 
RQMNAME(Destination Queue manager name) 
Xmitq(transmission queue)

• Remote queue name:
  • It’s the name with which the local queue manager knows it.

• Rname:
  • This attribute value is destination queue name, to which messages should be reached.

• RQMNAME:
  • Remote queue manager name in with Rname queue exists.

Notes:

• Remote queue doesn’t store any messages. 
• An application can’t pull/get a message from remote queue but can put a message in it. 
• Remote queue doesn’t have any curdepth attribute as it doesn’t store anything.

Queue manager Alias:

• Just like, an alias queue is a false name to a actual queue, Queue manager Alias is a false name to represent another queue manager name. its definition can be given as below,
• Define Qremote(QMGR Alias Name) RNAME(‘’) RQMNAME(NAME of the remote queue)
• It is same as a remote queue definition but excluding the RNAME parameter.
• This is used in multi-hopping of messages from one queue manager to another queue manager

Special local queues:

There are some local queues that have special purposes in WebSphere MQ.

 Dead letter queue

• It is considered to be a backup queue for a queue manager.
• If queue manager fails to place a message on destination queue then a message will be placed in dead letter queue with reason for failure. 
• A dead letter queue is special type of local queue. 
• MQ administrators may analyze the messages available in dead letter queue, and take a decision on to weather to move the messages to application or discard.
• It is not mandatory for a queue manager to have a dead letter queue, but it is strongly recommended.
• One can assign a dead letter queue to queue manager by, runmqsc command. Alter qmgr deadq(Name of dead letter queue)

 Initiation queue

• It holds the trigger messages generated during triggering process .
• Trigger monitor, which continuously monitors this queue will consume the trigger message and takes appropriate action.

Transmission queue

• Transmission queue is related to remote queue defined in that queue manager.

• A message placed in remote will pass on to transmission queue before guided to destination queue manager.
  • The Usage attribute indicates that a local queue is used as a transmission queue.
  • Transmission Queue is generally used for channel triggering.
  • A transmission queue works with message channels to enable queue manager-to-queue manager communication. 

Command queue

• It receives WebSphere MQ commands from an MQ administration tool (MQ explorer & other tools or commands) running locally or remotely.
• If this queue is PUT disabled (not available for placing messages), then no Administration tool can work with that queue manager.

Event queue

• When a queue manager detects an instrumentation event (which is nothing but some significant occurrence in a queue manager such as an error or a warning), it puts an event message describing the event on an event queue. 
• An event queue can be monitored by a system management application that can get the event message and take appropriate action.
  • For example:
    • SYSTEM.ADMIN.PERFM.EVENT
    • SYSTEM.ADMIN.CHANNEL.EVENT

Default queues

• Identify the default values of attributes of any new queue that is created. 
• There is one default queue for each of the four types of queues: local, alias, remote, and model. 
• Thus, you only need to include in the definition of a queue those attributes whose values are different from the default values.
• We can alter the default attribute values 
  • For example, 
  • SYSTEM.DEFAULT.LOCAL.QUEUE: holds the default attribute values for any new local queue created.
  • SYSTEM.DEFAULT.REMOTE.QUEUE: holds the default attribute values for any remote queue created.
• Try looking for default attribute by typing
  • Dis q(SYSTEM*) in runmqsc mode and will show all the object queues.

Dynamic Queues:

• When an application program issues an MQOPEN call to open a model queue, the queue manager dynamically creates an instance of a local queue with the same attributes as the model queue. This is called a Dynamic Queue.
• Use a dynamic queue when you do not need the queue after your application ends.

An intro about both types of Dynamic Queues,

• Temporary Dynamic Queues:
  • They hold non-persistent messages only. 
  • They are non-recoverable. 
  • They are deleted when the queue manager is started. 
  • They are deleted when the application that issued the MQOPEN call that created the queue closes the queue or terminates. 
• Permanent Dynamic Queues:
  • They hold persistent or non-persistent messages. 
  • They are recoverable in the event of system failures. 
  • They are deleted when an application (not necessarily the one that issued the MQOPEN call that created the queue) successfully closes the queue using the MQCO_DELETE or MQCO_DELETE_PURGE option. 
  • They can be deleted in the same way as a normal queue. 

Listeners:

• Listener objects are used to accept incoming network requests from remote queue managers, or client applications
• It’s a continuously running process at a particular port of the machine.
• It listens to the incoming messages and informs the receiving MCA or server MCA about the network requests.
• Listener can be controlled by queue manager automatically, i.e, It can start automatically with queue manager startup. For this ensure, the control attribute of listener should be as “QMGR”

Namelists:

• A namelist is a WebSphere MQ object that contains a list of other WebSphere MQ objects. 
• Namelists are used by applications such as trigger monitors, where they are used to identify a group of queues. 
• The advantage of using a namelist is that it is maintained independently of applications; i.e, it can be updated without stopping any of the applications that use it. Also, if one application fails, the namelist is not affected and other applications can continue using it.
• Namelists are also used with queue manager clusters so that you can maintain a list of clusters referenced by more than one WebSphere MQ object.