MQSeries Primer
`
`
`MQSeries Enterprise Application Integration Center
`
`Dieter Wackerow
`
`MQ EAI Center
`
`October 1999
`
`HP_1017_0001
`
`

`
`HP_1017_0002
`
`HP_1017_0002
`
`

`
`MQSeries Primer
`
`MQSeries is IBM’s award winning middleware for commercial messaging and queuing. It is used
`by thousands of customers in every major industry in many countries around the world. MQSeries
`speeds implementation of distributed applications by simplifying application development and
`test.
`
`MQSeries runs on a variety of platforms. The MQSeries products enable programs to
`communicate with each other across a network of unlike components, such as processors,
`subsystems, operating systems and communication protocols. MQSeries programs use a
`consistent application program interface (API) across all platforms.
`
`Application
`Program
`
`MQI
`
`Application
`Program
`
`MQI
`
`MQ Objects
`MQSeries
`
`MQ Objects
`MQSeries
`
`NETWORK
`
`Figure 1. MQSeries at Run Time
`
`Figure 1 shows the main parts of an MQSeries application at run time. Programs use MQSeries
`API calls, that is the Message Queue Interface (MQI), to communicate with a queue manager
`(MQM), the run-time program of MQSeries. For the queue manager to do its work, it refers to
`objects, such as queues and channels. The queue manager itself is an object as well.
`
`The following provides a brief overview of MQSeries, including clients and servers.
`
`What is Messaging and Queuing?
`Message queuing is a method of program-to-program communication. Programs within an
`application communicate by writing and retrieving application-specific data (messages) to/from
`queues, without having a private, dedicated, logical connection to link them.
`
`Messaging means that programs communicate with each other by sending data in messages and
`not by calling each other directly.
`
`Queuing means that programs communicate through queues. Programs communicating through
`queues need not be executed concurrently.
`
`October 1999
`
`MQSeries EAI Center
`
`Page 3
`
`HP_1017_0003
`
`

`
`MQSeries Primer
`
`With asynchronous messaging, the sending program proceeds with its own processing without
`waiting for a reply to its message. In contrast, synchronous messaging waits for the reply before it
`resumes processing. For the user, the underlying protocol is transparent. The user is concerned
`with conversational or data-entry type applications.
`
`MQSeries is used in a client/server or distributed environment. Programs belonging to an
`application can run in one workstation or in different machines on different platforms.
`Applications can easily be moved from one system or platform to another. The programs can be
`written in various programming languages, including Java. The same queuing mechanism is valid
`for all platforms, and so are the currently 13 APIs.
`
`Since MQSeries communicates via queues it can be referred to as using indirect program-to-
`program communication. The programmer cannot specify the name of the target application to
`which a message is sent. However, he or she can specify a target queue name; and each queue is
`associated with a program. An application can have one or more “input” queues and may have
`several “output” queues containing information for other servers to be processed, or for responses
`for the client that initiated the transaction.
`
`The programmer does not have to worry about the target program being busy or not available. He
`or she isn’t even concerned about the server being down or having no connection to it. The
`programmer sends messages to a queue that is associated with an application; and the application
`may or may not be available at the time of the request. MQSeries takes care of the transport to the
`target application and even starts it, if necessary.
`
`If the target program is not available, the messages stay in a queue and get processed later. The
`queue is either in the sending machine or in the target machine, depending whether the connection
`between the two systems can be established or not. Applications can be running all day long or
`they can be triggered, that is, automatically started when a message arrives or after a specified
`number of messages have arrived.
`
`BB
`
`e
`
`u
`
`e
`
`Q u
`
`e
`
`u
`
`e
`
`Q u
`
`AA
`
`Figure 2. Messages and Queues
`
`October 1999
`
`MQSeries EAI Center
`
`Page 4
`
`HP_1017_0004
`
`

`
`MQSeries Primer
`
`Figure 2 on page 4 shows how two programs, A and B, communicate with each other. We see two
`queues; one is the “output” queue for A and at the same time the “input” queue for B, while the
`second queue is used for replies flowing from B to A.
`
`The squares between the queues and the programs represent the Message Queuing Interface (API)
`the program uses to communicate with MQSeries’ run-time program, the queue manager. As said
`before, the API is a simple multi platform API consisting of 13 calls. The API will be discussed
`later.
`
`About Messages
`A message consists of two parts:
` 1. Data that is sent from one program to another
` 2. The message descriptor or message header
`
`The message descriptor identifies the message (message ID) and contains control information,
`also called attributes, such as message type, expiry time, correlation ID, priority, and the name of
`the queue for the reply.
`
`A message can be up to 4 MB or 100 MB long, depending on the MQSeries version you use.
`MQSeries Version 5 (for distributed platforms) supports a maximum message length of 100 MB.
`
`Message Segmenting and Grouping
`In MQSeries Version 5, messages can be segmented or grouped. Message segmenting can be
`transparent to the application programmer. If permitted, the queue manager segments a large
`message when it does not fit in a queue. On the receiving end, the application has the option to
`either receive the entire message in one piece or each segment separately. This may depend on the
`buffer size available for the application.
`
`A second method of segmenting leaves the programmer in control so that he or she can split a
`message according to logical boundaries or buffer size available for the program. The
`programmer puts each segment as a separate physical message; thus several physical messages
`build one logical message. The queue manager ensures that the order of the segments is
`maintained.
`
`To reduce traffic over the network, you can also group several small messages together and build
`one larger physical message. This message is then sent to the destination and is there
`disassembled. Message grouping also guarantees that the order the messages are sent in is
`preserved.
`
`Distribution Lists
`Using MQSeries Version 5, you can send a message to more than one destination queue with one
`MQPUT call. This is done with a dynamic distribution list. A distribution list can be a file that is
`read at the time an application starts. It can be modified any time. It contains a list of queue
`names and the queue managers that own them. A message sent to multiple queues belonging to
`the same queue manager is sent over the network only once and so reduces network traffic. The
`
`October 1999
`
`MQSeries EAI Center
`
`Page 5
`
`HP_1017_0005
`
`

`
`MQSeries Primer
`
`receiving queue manager replicates the messages and puts them into the destination queues. This
`function is called late fan-out.
`
`Message Types
`MQSeries knows four types of messages:
`
`Datagram: A message containing information for which no response is expected.
`Request: A message for which a reply is requested.
`Reply: A reply to a request message.
`Report: A message that describes an event such as the occurrence of an error or a
` confirmation on arrival or delivery.
`
`Persistent and Non-Persistent Messages
`Application design determines whether a message must reach its destination under any
`circumstances, or if it can be discarded when it cannot get there in time. MQSeries differentiates
`between persistent and non-persistent messages. Delivery of persistent messages is assured; they
`are written to logs to survive system failures. In an AS/400 these logs are Journal Receivers.
`Non-persistent messages cannot be recovered after a system restart.
`
`The Message Descriptor
`The table below contains some interesting attributes of the message descriptor. We mention them
`here because they explain some of the functions the queue manager provides for you.
`
`9HUVLRQ
`0HVVDJH(cid:3),’(cid:3)(cid:3)(cid:18)(cid:3)(cid:3)&RUUHOODWLRQ(cid:3),’
`3HUVLVWHQW(cid:3)(cid:3)(cid:18)(cid:3)(cid:3)QRQ(cid:16)SHUVLVWHQW
`3ULRULW\
`’DWH(cid:3)DQG(cid:3)WLPH
`/LIHWLPH(cid:3)RI(cid:3)D(cid:3)PHVVDJH
`
`5HWXUQ(cid:3)DGGUHVV
`)RUPDW
`6HQGHU(cid:3)DSSOLFDWLRQ(cid:3)DQG(cid:3)W\SH
`5HSRUW(cid:3)RSWLRQV(cid:3)(cid:3)(cid:18)(cid:3)(cid:3))HHGEDFN(cid:3)(cid:3)(cid:3)(cid:3)(cid:11)&2$(cid:15)(cid:3)&2’(cid:12)
`%DFNRXW(cid:3)FRXQWHU
`6HJPHQWLQJ(cid:3)(cid:18)(cid:3)JURXSLQJ(cid:3)LQIRUPDWLRQ
`
`Figure 3. Some Attributes of the Message Descriptor
`
`• The version of the message descriptor depends on the MQSeries version and platform you
`use. For the functions introduced with Version 5 additional fields were needed to keep
`information about segments and their order and distribution list information, to name a few.
`This enlarged structure carries the version number 2. Other queue managers who don’t
`support these functions (“Version 1 queue managers”) treat the additional information as data.
`
`• Message and/or correlation ID are used to identify a specific request or reply message. The
`programmer can move a value in one or both fields or have MQSeries create a unique ID for
`him or her. Before the programmer puts the request message in the queue he or she can save
`the ID(s) and use them in a subsequent get operation for the reply message. The program that
`receives the request message copies this information into the reply message. This allows the
`originating program (the one that gets the reply) to instruct MQSeries to look for a specific
`message in the queue instead of getting the first one in the queue.
`
`October 1999
`
`MQSeries EAI Center
`
`Page 6
`
`HP_1017_0006
`
`

`
`MQSeries Primer
`
`• We discussed persistent and non-persistent messages earlier. Persistent messages always
`arrive at their destination, even when the system fails. They are “hardened”, that is, saved on
`disk. You can make a specific message persistent or all messages on a particular queue.
`
`• You can assign a priority to a message and so control the order in which it is processed.
`
`• The queue manager stores time and date when the MQPUT occurred in the message header.
`The time is in GMT and the year has four digits and so is Y2K compliant.
`
`• You can also specify an expiration date. When this date is reached and an MQGET is issued,
`then the message will be discarded. There is no “daemon” that checks queues for expired
`messages. Expired messages can stay in a queue for weeks, until a program attempts to read it.
`
`• The return address is very important for request/reply messages. You have to tell the server
`program where to send the reply message. Clients and servers have a one-to-many
`relationship and usually the server program cannot find out from the user data where the
`request message came from. Therefore, the client provides the reply-to queue and reply-to
`queue manager in the message header. The server uses this information when it performs the
`MQPUT API call.
`
`•
`
` field, the sender can specify a value that the receiver can use to decide whether
`In the format
`
`data conversion can be done or not. It is also used to indicate that there is an additional
`header (extension) present.
`
`• The message also carries information about the sending application (program name and path)
`and the platform it is running on.
`
`• Report options and feedback code are used to request information, such as confirmation on
`arrival or delivery, from the receiving queue manager. For example, the queue manager can
`send a report message to the sending application when it puts the message in the target queue
`or when the application gets it off the queue.
`
`• Each time a message is backed out, the backout counter is increased. An application can
`check this counter and act on it, for example, send the message to a different queue where the
`reason for the backout is analyzed by an administrator.
`
`• Message segmenting and grouping has been mentioned earlier. The queue manager uses the
`message header to store information about the physical message; for example, if it is a
`message group, the first or last segment, or which one in between.
`
`About the Queue Manager
`The heart of MQSeries is the message queue manager (MQM), MQSeries’ run-time program. Its
`job is to manage queues and messages for applications. It provides the Message Queuing
`Interface (MQI) for communication with applications. Application programs invoke functions of
`the queue manager by issuing API calls. For example, the MQPUT API call puts a message on a
`
`October 1999
`
`MQSeries EAI Center
`
`Page 7
`
`HP_1017_0007
`
`

`
`MQSeries Primer
`
`queue to be read by another program using the MQGET API call. This scenario is shown in
`Figure 4.
`
`Application
`Program A
`
`PUT to Q1
`
`Messages
`
`Application
`Program B
`
`GET from Q1
`
`Figure 4. Program-to-Program Communication - One System
`
`A program may send messages to another program that runs in the same machine as the queue
`manager (shown above), or to a program that runs in a remote system, such as a server or a host.
`The remote system has its own queue manager with its own queues. This scenario is shown in
`Figure 5.
`
`Application
`Program A
`
`PUT to Q1
`
`Messages
`
`Channel
`
`Application
`Program B
`
`GET from Q1
`
`Remote Queue Q1
`
`Local Queue Q1
`
`Figure 5. Program-to-Program Communication - Two Systems
`
`The queue manager transfers messages to other queue managers via channels using existing
`network facilities, such as TCP/IP, SNA or SPX. Multiple queue managers can reside in the same
`machine. They also need channels to communicate.
`
`Application programmers do not need to know where the program to which they are sending
`messages runs. They put their messages on a queue and let the queue manager worry about the
`destination machine and how to get the messages there. MQSeries knows what to do when the
`remote system is not available or the target program is not running or busy.
`
`For the queue manager to do its work, it refers to objects that are defined by an administrator,
`usually when the queue manager is created or when a new application is added. The objects are
`described in “About Queue Manager Objects” on page 11. The functions of a queue manager can
`be summarized as follows:
`
`•
`
`It manages queues of messages for application programs.
`
`October 1999
`
`MQSeries EAI Center
`
`Page 8
`
`HP_1017_0008
`
`

`
`MQSeries Primer
`
`•
`
`•
`
`•
`
`•
`
`•
`
`•
`
`It provides an application programming interface, the Message Queue Interface (MQI).
`Note: The Networking Blueprint identifies three communication styles:
` 1. Common Programming Interface - Communications (CPI-C)
` 2. Remote Procedure Call (RPC)
` 3. Message Queue Interface (MQI)
`
`It uses existing networking facilities to transfer messages to other queue managers when
`necessary.
`
`It coordinates updates to databases and queues using a two-phase commit. Gets and puts from/
`to queues are committed together with SQL updates, or backed out if necessary.
`
`It segments messages (if necessary) and assembles them. It also can group messages and send
`them as one physical message to their destination where they are automatically disassembled.
`
`It can send one message to more than one destination with one API call using a user-defined
`dynamic distribution list, thus reducing network traffic.
`
`It provides additional functions that allow administrators to create and delete queues, alter the
`properties of existing queues, and control the operation of the queue manager. MQSeries for
`Windows NT Version 5.1 provides graphical user interfaces; other platforms use the command
`line interface or panels.
`
`MQSeries clients do not have a queue manager in their machines. Client machines connect to a
`queue manager in a server. The queue manager manages the queues for all clients attached to it.
`
`In contrast to MQSeries clients, each workstation that runs MQSeries for Windows (Version 2)
`has its own queue manager and queues. MQSeries for Windows is a single-user queue manager
`and is not intended to function as a queue manager for other MQSeries clients. This product is
`designed for a mobile environment.
`
`Note: MQSeries for Windows and MQSeries for Windows NT are two different products.
`
`About Queue Manager Clusters
`With MQSeries for MVS/ESA and Version 5.1 for distributed platforms, you can join queue
`managers together in clusters. Queue managers that form a cluster can run in the same machine or
`in different machines on different platforms. Usually, two of those “cluster queue managers”
`maintain a repository that contains information about all queue managers and queues in the
`cluster. This is called a full repository. The other queue managers maintain only a repository of
`objects they are interested in, a partial repository. The repository allows any queue manager in
`the cluster to find out about any cluster queue and who owns it. The queue managers use special
`cluster channels to exchange information.
`
`Clustering also permits multiple instances of a queue (with the same name) on different queue
`managers. This allows for workload distribution, that is, the queue manager can send messages to
`different instances of an application.
`
`October 1999
`
`MQSeries EAI Center
`
`Page 9
`
`HP_1017_0009
`
`

`
`MQSeries Primer
`
`In normal distributed processing, we send messages to a specific queue owned by a specific queue
`manager. All messages destined for that queue manager are placed in a transmission queue on the
`sender’s side. This transmission queue has the same name as the destination queue manager. The
`message channel agents move the messages across the network and place them into the
`destination queues. Figure 6 shows the relationship between a transmission (Xmit) queue and the
`target queue manager.
`
`MQPUT
`
`Remote
`Queue
`
` Xmit
`Queue
`
`Target
`Queue
`
`Qmgr
`
`Figure 6. MQPUT to a Remote Queue
`
`With clustering, you send a message to a queue with a specific name somewhere in the cluster, in
`Figure 7 represented by a cloud. You specify the name of a target queue, not the name of a remote
`queue definition. Clustering does not require remote queue definitions. They are only useful
`when you send a message to a queue manager that is not a member of the cluster. You can also
`specify a queue manager and direct the message to a specific queue, but very often it is left to the
`queue manager to determine where the queue is (or the queues are) and to which one to send the
`message.
`
`MQPUT
`
`Target
`Queue
`
`Cluster
` Xmit
`Queue
`
`Figure 7. MQPUT to a Cluster Queue
`
`The vision of an MQSeries cluster is as the place where multiple instances of a queue can exist.
`They come and go as an administrator requires in order to satisfy changing availability and
`throughput requirements. This has to be achieved completely dynamically and without placing
`the administrator under a great burden to configure and control. In addition, the programmer does
`not have to think about multiple queues; he or she just treats them as if writing to a single queue.
`
`This is not to say that there is no burden on the programmer or administrator. Enhanced levels of
`availability and exploitation of parallelism do require some planning. The administrator or
`system designer must ensure that there is enough redundancy in the configuration to meet their
`needs. The application designer must ensure that messages are capable of being processed in
`multiple places.
`
`You create multiple instances of a queue by defining a queue with the same name on multiple
`queue managers that belong to the cluster. You must also name the cluster when you define the
`queue. Without this attribute the queue would only be known locally. When the application
`specifies only the queue name, where is the message sent?
`
`October 1999
`
`MQSeries EAI Center
`
`Page 10
`
`HP_1017_0010
`
`

`
`MQSeries Primer
`
`BA
`
`A
`
`B
`
`2
`
`A
`
`1
`
`3
`
`MQPUT
`
`Figure 8. Accessing Cluster Queues
`
`Figure 8 gives you an idea. MQSeries distributes the messages round-robin. You can, however,
`change this default action by writing your own workload balancing exit routine.
`
`Figure 8 shows messages put in one of the three cluster queues named A. Each of the three queue
`managers on the right owns a queue with this name. By default, the first message is placed in
`queue A on queue manager 1, the next in queue A on queue manager 2, the third goes to queue
`manager 3 and the fourth message to the queue on queue manager 1 again.
`
`In another scenario involving queue B, we notice that the third queue manager is down and the
`third instance of queue B is not available. The sending queue manager becomes aware of this
`problem because it subscribed to information about all queue manager and queues it is interested
`in, that is, where it sends messages. As soon as it finds out that there is a problem with the third
`instance of B, it distributes messages to the first two instances only. Special messages about
`changes of the status of cluster objects are instantly published to all queue managers that
`subscribed to that object.
`
`About Queue Manager Objects
`This section introduces you to queue manager objects, such as queues and channels. The queue
`manager itself is an object, too. Usually, an administrator creates one or more queue managers
`and their objects. A queue manager can use objects of the following types:
`
` 1. Queues
` 2. Process definitions
` 3. Channels
`
`The objects are common across different MQSeries platforms. There are other objects that apply
`to MVS systems only, such as the buffer pool, PSID, and storage class. AS/400 MQ objects are
`known to the OS/400 operating system as object type *USRSPC (user space) in the QMQMDATA
`library.
`
`October 1999
`
`MQSeries EAI Center
`
`Page 11
`
`HP_1017_0011
`
`

`
`MQSeries Primer
`
`Queues
`Message queues are used to store messages sent by programs. There are local queues that are
`owned by the local queue manager, and remote queues that belong to a different queue manager.
`Queues are described in more detail in the section “About Message Queues” on page 13.
`
`Channels
`A channel is a logical communication link. In MQSeries, there are two different kinds of
`channels:
`
`1. Message channels
`A message channel connects two queue managers via message channel agents (MCAs). Such
`a channel is unidirectional. It comprises two message channel agents, a sender and a receiver,
`and a communication protocol. An MCA is a program that transfers messages from a trans-
`mission queue to a communication link, and from a communication link into the target queue.
`For bidirectional communication you have to define two channel pairs consisting of a sender
`and a receiver. Message channel agents are also referred to as movers.
`
`2. MQI channels
`A Message Queue Interface (MQI) channel connects an MQSeries client to a queue manager
`in its server machine. Clients don’t have a queue manager of their own. An MQI channel is
`bidirectional.
`
`Figure 9 shows both channels types. You see four machines, two clients connected to their server
`machine via MQI channels, and the server connected to another server or a host via two
`unidirectional message channels. Some channels can be defined automatically by MQSeries.
`There are different types of message channels, depending on how the session between the queue
`managers is initiated and for what purpose they are used.
`
`MQ
`Client
`
`MQ
`Client
`
`MQI Channels
`
`MQM
`
`Message Channels
`
`MQM
`
`Figure 9. MQSeries Channels
`
`To transmit non-persistent messages, a message channel can run at two speeds: fast and normal.
`Fast channels improve performance, but (non-persistent) messages can be lost in case of a channel
`failure.
`
`A channel can use the following transport types: SNA LU 6.2, TCP/IP, NetBIOS, SPX and DEC
`Net. Not all are supported on all platforms.
`
`October 1999
`
`MQSeries EAI Center
`
`Page 12
`
`HP_1017_0012
`
`

`
`MQSeries Primer
`
`MQSeries for Windows Version 2 uses message channels to connect to other machines. Since this
`product is designed as a single user system, it does not support MQI channels. This product
`supports only TCP/IP.
`
`Process Definitions
`A process definition object defines an application to a queue manager. For example, it contains
`the name of the program (and its path) to be triggered when a message arrives for it.
`
`About Message Queues
`Queues are defined as objects belonging to a queue manager. MQSeries knows a number of
`different queue types, each with a specific purpose. The queues you use are located either in your
`machine and belong to the queue manager to which you are connected, or in your server (if you
`are a client). Figure 10 lists different queue types and their purposes. More detailed information
`is below.
`
`Local queue
`
`Remote queue
`
`is a real queue
`
`structure describing a queue
`
`Transmission queue (xmitq)
`
`local queue with special purpose
`
`Initiation queue
`
`Dynamic queue
`
`Alias queue
`
`local queue with special purpose
`
`local queue created "on the fly"
`
`if you don’t like the name
`
`Dead-letter queue
`
`one for each queue manager
`
`Reply-to-queue
`
`Model queue
`
`Repository queue
`Figure 10. Queue Types
`
`specified in request message
`
`model for local queues
`
`holds cluster information
`
`Local Queue
`A queue is local if it is owned by the queue manager to which the application program is
`connected. It is used to store messages for programs that use the same queue manager. For
`example, program A and program B each has a queue for incoming messages and another queue
`for outgoing messages. Since the queue manager serves both programs, all four queues are local.
`
`Note: Both programs do not have to run in the same workstation. Client workstations usually use
`a queue manager in a server machine.
`
`Cluster Queue
`A cluster queue is a local queue that is known throughout a cluster of queue managers, that is, any
`queue manager that belongs to the cluster can send messages to it without the need of a remote
`definition or defining channels to the queue manager that owns it.
`
`October 1999
`
`MQSeries EAI Center
`
`Page 13
`
`HP_1017_0013
`
`

`
`MQSeries Primer
`
`Remote Queue
`A queue is “remote” if it is owned by a different queue manager. A remote queue definition is the
`local definition of a remote queue. A remote queue is not a real queue. It is a structure that
`contains some of the characteristics of a queue hosted by a different queue manager.
`
`The application programmer can use the name of a remote queue just as he or she can use the
`name of a local queue. The MQSeries administrator defines where the queue actually is. Remote
`queues are associated with a transmission queue.
`
`Notes: - A program cannot read messages from a remote queue.
`- You don’t need a remote queue definition for a cluster queue.
`
`Transmission Queue
`This is a local queue with a special purpose. A remote queue is associated with a transmission
`queue. Transmission queues are used as an intermediate step when sending messages to queues
`that are owned by a different queue manager.
`
`Typically, there is only one transmission queue for each remote queue manager (or machine). All
`messages written to queues owned by a remote queue manager are actually written to the
`transmission queue for this remote queue manager. The messages will then be read from the
`transmission queue and sent to the remote queue manager.
`
`Using MQSeries clusters, there is only one transmission queue for all messages sent to all other
`queue managers in the cluster.
`
`Transmission queues are transparent to the application. They are used internally by the queue
`manager. When a program opens a remote queue, the attributes of the queue are obtained from
`the transmission queue. Therefore, the results of a program writing messages to a queue will
`be affected by the transmission queue characteristics.
`
`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.
`
`October 1999
`
`MQSeries EAI Center
`
`Page 14
`
`HP_1017_0014
`
`

`
`MQSeries Primer
`
`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 which starts applications and the channel initiator which starts the
`transmission between queue managers.
`
`Note: 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.
`
`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.
`
`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.
`
`October 1999
`
`MQSeries EAI Center
`
`Page 15
`
`HP_1017_0015
`
`

`
`MQSeries Primer
`
`Creating a Queue Manager
`You may create as many queue managers as you like and have them running at the same time.
`You create a queue manager with the command crtmqm; to make it the default, specify the
`parameter /q.
`The following command creates the default queue manager MYQMGR (in a Windows NT
`environment):
`
`crtmqm /q MYQMGR
`
`Note: Queue manager names are case-sensitive.
`
`There are default definitions for objects every queue manager needs, such as model queues. These
`objects are created automatically. Most certainly, you will have to create other objects that pertain
`to the applications you run. Usually, those application specific objects are kept in a script file,
`such as mydefs.in. You apply them to a newly created queue manager with the command:
`
`runmqsc < mydefs.in
`
`MQSeries for Windows NT Version 5.1 provides a graphical user interface to create and
`manipulate queue managers and their objects.
`
`A dead-letter queue is not automatically created. To create one when you create the queue
`manager, specify it as shown in the following example:
`
`crtmqm /q /u system.dead.letter.queue MYQMGR
`
`To start the queue manager issue the command:
`
`strmqm
`
`Manipulating Queue Manager Objects
`MQSeries for distributed platforms provides the utility RUNMQSC to create and delete queue
`manager objects and to manipulate them. The queue manager must be running when you use the
`utility. RUNMQSC works in two ways:
`
`• You can type the commands.
`• You c