A WebSphere MQ queue is a named object on which applications can put messages, and from which applications can get messages. Messages are stored on a queue, so if the putting application is expecting a reply to its message, it is free to do other work while waiting for that reply. Applications access a queue by using the Message Queue Interface (MQI), described in Chapter 6, Introducing the Message Queue Interface.
Before a message can be put on a queue, the queue must have already been created. A queue is owned by a queue manager, and that queue manager can own many queues. However, each queue must have a name that is unique within that queue manager.
A queue is maintained through a queue manager. In most cases, each queue is physically managed by its queue manager but this is transparent to an application program. WebSphere MQ for z/OS shared queues can be managed by any queue manager in the queue-sharing group.
To create a queue you can use WebSphere MQ commands (MQSC), PCF commands, or platform-specific interfaces such as the WebSphere MQ for z/OS operations and control panels.
On all platforms except MQSeries for VSE/ESA, you can create local queues for temporary jobs "dynamically" from your application. For example, you can create reply-to queues (which are not needed after an application ends). For more information, see Dynamic queues.
Before using a queue, you must open the queue, specifying what you want to do with it. For example, you can open a queue:
For a complete list of the options you can specify when you open a queue, see the description of the MQOPEN call in WebSphere MQ Application Programming Reference.
The types of queue that WebSphere MQ supports for applications to use are:
The queue definition object, created when you define a local queue, will hold the definition information of the queue as well as the physical messages put on the queue. The queue definition object, created when you 'define' a remote queue, will only hold the information necessary for the local queue manager to be able to locate the queue to which you want your message to go. This object is known as the local definition of a remote queue. All the attributes of the remote queue are held by the queue manager that owns it, because it is a local queue to that queue manager.
A shared queue is a type of local queue whose messages can be accessed by one or more queue managers that are in a queue-sharing group. (This is not the same as a queue being "shared" by more than one application, via the same queue manager.) Shared queues are held by a coupling facility (CF), and are accessible by any queue manager in the queue-sharing group. Each shared queue in a queue-sharing group must have a name that is unique within that group. See WebSphere MQ for z/OS Concepts and Planning Guide for a full discussion of shared queues and queue-sharing groups.
You can create a local queue dynamically from a WebSphere MQ program, naming the model queue you wish to use as the template for the queue attributes. You may now, if you wish, change some attributes of the new queue. However, you cannot change the DefinitionType. If, for example, you require a permanent queue, you must select a model queue with the definition type set to permanent. Some conversational applications could make use of dynamic queues to hold replies to their queries because they probably would not need to maintain these queues after they have processed the replies.
The cluster queue manager makes a local queue definition for the queue specifying the name of the cluster that the queue is to be available in. This definition has the effect of advertising the queue to the other queue managers in the cluster. The other queue managers in the cluster can put messages to a cluster queue without needing a corresponding remote-queue definition. A cluster queue can be advertised in more than one cluster. See What is a cluster? and WebSphere MQ Queue Manager Clusters for further information.
Each queue manager can have some local queues that it uses for special purposes:
These special queues are described in greater detail in the following sections.
Some of the attributes of a queue are specified when the queue is defined, and may not be changed afterwards (for example, the type of the queue). Other attributes of queues can be grouped into those that can be changed:
You can find the values of all the attributes using the MQINQ call.
The attributes that are common to more than one type of queue are:
For a full description of these attributes, see WebSphere MQ Application Programming Reference.
To a program, a queue is remote if it is owned by a different queue manager to the one to which the program is connected. Where a communication link has been established, it is possible for a program to send a message to a remote queue. A program can never get a message from a remote queue.
When opening a remote queue, to identify the queue you must specify either:
To create a local definition of a remote queue use the DEFINE QREMOTE command; in WebSphere MQ for iSeries, alternatively use the CRTMQMQ command; in MQSeries for Compaq NonStop Kernel, you can use the MQM screen-based interface; in MQSeries for VSE/ESA, you can use the MQMT transaction.
From the viewpoint of an application, this is the same as opening a local queue. An application does not need to know if a queue is local or remote.
Local definitions of remote queues have three attributes in addition to the common attributes described in Attributes of queues. These are RemoteQName (the name that the queue's owning queue manager knows it by), RemoteQMgrName (the name of the owning queue manager), and XmitQName (the name of the local transmission queue that is used when forwarding messages to other queue managers). For a fuller description of these attributes, see WebSphere MQ Application Programming Reference.
If you use the MQINQ call against the local definition of a remote queue, the queue manager returns the attributes of the local definition only, that is the remote queue name, the remote queue manager name and the transmission queue name, not the attributes of the matching local queue in the remote system.
See also Transmission queues.
An alias queue is a WebSphere MQ object that you can use to access another queue. The queue resulting from the resolution of an alias name (known as the base queue) can be a local queue, the local definition of a remote queue, or a shared queue (a type of local queue only available on WebSphere MQ for z/OS). It can also be either a predefined queue or a dynamic queue, as supported by the platform.
An example of the use of alias queues is for a system administrator to give different access authorities to the base queue name (that is, the queue to which the alias resolves) and to the alias queue name. This would mean that a program or user could be authorized to use the alias queue, but not the base queue.
Alternatively, authorization can be set to inhibit put operations for the alias name, but allow them for the base queue.
In some applications, the use of alias queues means that system administrators can easily change the definition of an alias queue object without having to get the application changed.
WebSphere MQ makes authorization checks against the alias name when programs try to use that name. It does not check that the program is authorized to access the name to which the alias resolves. A program can therefore be authorized to access an alias queue name, but not the resolved queue name.
In addition to the general queue attributes described in Attributes of queues, alias queues have a BaseQName attribute. This is the name of the base queue to which the alias name resolves. For a fuller description of this attribute, see WebSphere MQ Application Programming Reference.
The InhibitGet and InhibitPut attributes (see Attributes of queues) of alias queues belong to the alias name. For example, if the alias-queue name ALIAS1 resolves to the base-queue name BASE, inhibitions on ALIAS1 affect ALIAS1 only and BASE is not inhibited. However, inhibitions on BASE also affect ALIAS1.
The DefPriority and DefPersistence attributes also belong to the alias name. So, for example, you can assign different default priorities to different aliases of the same base queue. Also, you can change these priorities without having to change the applications that use the aliases.
A model queue is a template of a queue definition that you use when creating a dynamic queue. You specify the name of a model queue in the object descriptor (MQOD) of your MQOPEN call. Using the attributes of the model queue, the queue manager dynamically creates a local queue for you.
You can specify a name (in full) for the dynamic queue, or the stem of a name (for example, ABC) and let the queue manager add a unique part to this, or you can let the queue manager assign a complete unique name for you. If the queue manager assigns the name, it puts it in the MQOD structure.
You can not issue an MQPUT1 call directly to a model queue, but you can issue an MQPUT1 to the dynamic queue that has been created by opening a model queue.
The attributes of a model queue are a subset of those of a local queue. For a fuller description, see WebSphere MQ Application Programming Reference.
On all platforms except for MQSeries for VSE/ESA, 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. Depending on the value of the DefinitionType field of the model queue, the queue manager creates either a temporary or permanent dynamic queue (See Creating dynamic queues).
Temporary dynamic queues have the following properties:
Permanent dynamic queues have the following properties:
You can use dynamic queues for:
The server could then place the reply message on the reply-to queue. Finally, the client could process the reply, and close the reply-to queue with the delete option.
You should consider the following points when using dynamic 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.
A message channel agent (channel program), or intra-group queuing agent when using intra-group queuing on WebSphere MQ for z/OS, will be associated with the transmission queue and the remote queue manager, and this delivers the message. When the message has been delivered, it is deleted from the transmission queue.
The message may have to pass through many queue managers (or nodes) on its journey to its final destination. There must be a transmission queue defined at each queue manager along the route, each holding messages waiting to be transmitted to the next node. (A shared transmission queue is used when using intra-group queuing on WebSphere MQ for z/OS.) There can be several transmission queues defined at a particular queue manager. A given transmission queue holds messages whose next destination is the same queue manager, although the messages may have different eventual destinations. There may also be several transmission queues for the same remote queue manager, with each one being used for a different type of service, for example.
Transmission queues can be used to trigger a message channel agent to send messages onward. For information about this, see Chapter 14, Starting WebSphere MQ applications using triggers. These attributes are defined in the transmission queue definition (for triggered channels) or the process definition object (see Process definitions).
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 (for example, more than 10 messages arriving) that an application designer intends the queue manager to use as a cue, or trigger, to start a program that will process the queue. For more information on how triggering works, see Chapter 14, Starting WebSphere MQ applications using triggers.
A dead-letter (undelivered message) queue is a local queue on which the queue manager puts messages it cannot deliver.
When the queue manager puts a message on the dead-letter queue, it adds a header to the message. This includes such information as the intended destination of the original message, the reason the queue manager put the message on the dead-letter queue, and the date and time it did this.
Applications can also use the queue for messages they cannot deliver. For more information, see Using the dead-letter (undelivered message) queue.
Not supported in MQSeries for VSE/ESA.
These queues receive the PCF, MQSC, and CL commands, as supported on your platform, in readiness for the queue manager to action them. In WebSphere MQ for z/OS the queue is known as the SYSTEM.COMMAND.INPUT.QUEUE and accepts MQSC commands. On other platforms it is known as the SYSTEM.ADMIN.COMMAND.QUEUE and the commands accepted vary by platform. See WebSphere MQ Programmable Command Formats and Administration Interface for details.
The system default queues contain the initial definitions of the queues for your system. When you create a new queue, the queue manager copies the definition from the appropriate system default queue.