MQSeries Tutorial for Mainframe Programmers (5 of 5)

A  queue manager is that part of an MQSeries product that provides the messaging and queuing services to application programs, through the Message Queue Interface (MQI) program calls.  It controls access to queues and serves as transaction (syncpoint) coordinator for all queue operations. You can read Part-1 tutorial here.

  • Dynamic Queue- Such a queue is defined “on the fly” when the application needs it. Dynamic queues may be retained by the queue manager or automatically deleted when the application program ends. Dynamic queues are local queues. They are often used in conversational applications, to store intermediate results. Dynamic queues can be:
    • Temporary queues that do not survive queue manager restarts
    • Permanent queues that do survive queue manager restarts
  • Alias Queue- Alias queues are not real queues but definitions. They are used to assign different names to the same physical queue. This allows multiple programs to work with the same queue, accessing it under different names and with different attributes.
  • Model Queue- A model queue is not a real queue. It is a collection of attributes that are used when a dynamic queue is created.
  • Initiation Queue- An initiation queue is a local queue to which the queue manager writes a trigger message when certain conditions are met on another local queue, for example, when a message is put into an empty message queue or in a transmission queue. Such a trigger message is transparent to the programmer. Two MQSeries applications monitor initiation queues and read trigger messages, the trigger monitor that starts applications and the channel initiator, which starts the transmission between queue managers.
    •  Applications do not need to be aware of initiation queues, but the triggering mechanism implemented through them is a powerful tool to design and write asynchronous applications.
  • Reply-to-Queue- A request message must contain the name of the queue into which the responding program must put the reply message. This can be considered the “return address”. The name of this queue together with the name of the queue manager that owns it is stored in the message header. This is the responsibility of the application program.
  • Repository Queue- Repository queues have existed since Version 5.1 and Version 2.1 for OS/390. They are used in conjunction with clustering and hold either a full or a partial repository of queue managers and queue manager objects in a cluster (or group) of queue managers.
  • Dead-Letter Queue – A queue manager must be able to handle situations when it cannot deliver a message. Here are some examples:
    • The destination queue is full.
    • The destination queue does not exist.
    • Message puts have been inhibited on the destination queue.
    • The sender is not authorized to use the destination queue.
    • The message is too large.
    • The message contains a duplicate message sequence number.
    • When the above conditions are met, the messages are written to the dead-letter queue. Such a queue is defined when the queue manager is created. It will be used as a repository for all messages that cannot be delivered.

Synchronous and Asynchronous Messaging:

In synchronous messaging, the sending application waits for the reply before it resumes whereas in asynchronous messaging, the sending application proceeds with its own processing without waiting for its reply.

Read more…


Author: Srini

Experienced software developer. Skills in Development, Coding, Testing and Debugging. Good Data analytic skills (Data Warehousing and BI). Also skills in Mainframe.