Professional Documents
Culture Documents
MQSeries is IBMs 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.
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.
Messaging means that programs communicate with each other by sending data in
messages and not by calling each other directly.
The control information is defined in a message descriptor structure (MQMD) and
contains such things as:
The type of the message
An identifier for the message
The priority for delivery of the message
The structure and content of the application data is determined by the participating
programs, not by MQSeries.
Application data
The application data in a message is defined and supplied by the
application which sends the message. There are no constraints on the
nature of the data in the message; for example, it could consist of one or
more of the following types:
Character strings
Bit strings
Binary integers
Packed-decimal integers
Floating-point numbers.
It is possible for a message to contain no application data. A message
with no data might not seem very useful, but sometimes that is all that is
needed to signal to the receiver that some particular event has occurred.
Control information
The control information in a message is data whose meaning is defined by
the message-queuing service, but whose value is specified by the sending
application. The data defines various properties of the message, and is
used by the message-queuing service to decide how the message should be
processed.
The control information is contained in a data structure called the
message descriptor, which the sending application passes to the queue
manager on the MQPUT or MQPUT1 call. The queue manager returns this
information to the receiving application on the MQGET call. The message
descriptor (MQMD) is defined in detail in topic 7.2.3; the following
sections introduce the more important properties of the message.
Since MQSeries communicates via queues it can be referred to as using indirect programtoprogram 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.
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.
o 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.
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)
application can use
two modes of communication:
Conversational
If the application uses this mode of communication with the server program, it waits for
the
message to arrive before it continues processing. This means, the reply queue is open and
an
True asynchronous
When using this mode, the client does not care when the request message arrives.
Usually, the user clicks a push button in a menu window to activate a program that
checks the reply queue for messages. If a message is present, this or another program can
process the reply.
The Message Queuing Interface (MQI)
A program talks directly to its local queue manager. It resides in the same processor or
domain (for clients) as the program itself. The program uses the Message Queuing
Interface (MQI). The MQI is a set of API calls that request services from the queue
manager.
Note: When the connection between a client and its server is broken, no API calls can be
executed, since all objects reside in the server.
An initiation queue into which the queue manager puts a trigger message when a request
for queue QS1 arrives. You can use the default initiation queue.
A process definition that contains the name of the program to be started when the trigger
event occurs (S1).
Persistence
Sometimes the sender of a message wants to be assured that a message will
not be lost if there is a system or network failure; this property of a
message is called persistence.
A persistent message is protected against system failures, and survives
| either until it is retrieved by the receiving application, or until its
| expiry time is exceeded (at which point the queue manager will discard
| it).
The message persistence is defined by the Persistence field in the message
descriptor;
Local Queue
A local queue is a queue that belongs to the queue manager to which the
application has connected using the MQCONN call. A queue of this type can
be opened for input (for use with the MQGET call), or for output (for use
The message waits on the transmission queue until a message channel agent
transmits it successfully to the next queue manager in the network. The
message is then deleted from the transmission queue.
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 powerfultool to design and write asynchronous
applications.
MQM-COMPCODE
MQM-REASON.
The application specifies information about the message to be put
(MsgDesc), options that control the action of the call (PutMsgOpts), the
length of the message data (BufferLength), and the message data itself
(Buffer).
The MQPUT call can be used repeatedly to put many messages on the same
queue, without intervening use of the MQOPEN and MQCLOSE calls.
The handle of the queue manager (from MQCONN)
The handle of the queue (from MQOPEN)
The message descriptor
A structure containing options for the put (refer to the Application Programming
Reference)
The message length
The buffer containing the data
Syntax for Closing a Message Queue
When the application has finished putting messages on a queue, or getting
messages from a queue, it must close the queue by means of the MQCLOSE
call:
CALL MQCLOSE (Hconn, Hobj, Options, CompCode, Reason)
The application specifies the handle of the queue to be closed (Hobj), and
some options that control the action of the call (Options). After the
call, the queue handle (Hobj) is no longer valid, and messages cannot be
put on the queue or removed from the queue by the application unless it
performs another MQOPEN call.
An application that is reading from a queue does not have to empty the
queue before closing it. Messages left on a permanent queue are retained
by the queue manager, and may be accessed later by the same or another
application. Messages left on a temporary queue are discarded by the
queue manager when the queue is closed by the application which created
it.
When the application has finished all interaction with the queue manager,
the application must sever the connection by means of the MQDISC call:
CALL MQDISC (Hconn, CompCode, Reason)
After the call, the connection handle (Hconn) is no longer valid, and
message-queuing calls cannot be issued by the application unless it
performs another MQCONN call.
Minor calls
CALL MQCMIT (Hconn, CompCode, Reason)
Note: This call commits only MQ resources; it does not affect resources
belonging to other resource managers (such as a database manager).
If the application encounters an error during a series of puts and/or gets
that are part of a unit of work, the application can backout the
operations performed on the queue(s) as part of that unit of work by using
the appropriate environment-specific call. In those environments where
there is no suitable unit-of-work manager, the application can use the
MQBACK call to backout the unit of work:
CALL MQBACK (Hconn, CompCode, Reason)
Note: This call backs out only MQ resources; it does not affect resources
belonging to other resource managers (such as a database manager).
Sometimes an application needs to determine one or more of the properties
of a queue, in order to take appropriate action. For example, a
load-balancing application might want to determine the current depth of
the queue (that is, the number of messages on the queue), so that it could
start another server if messages were arriving more quickly than the
current number of servers could handle.
The attributes of a queue can be determined by means of the MQINQ call:
Triggering
generated. From the point of view of the queue manager, there is nothing
special about the trigger-monitor application--it is simply another
application that reads messages from a queue (the initiation queue).
If triggering is enabled for a queue, that queue must have associated with
it a process-definition object. This object contains information about
the application that is to be started to process the message which caused
the trigger event. When the queue manager generates the trigger message,
it extracts this information from the relevant process definition and
places it in the trigger message, for use by the trigger-monitor
application. The name of the process definition associated with a queue
is given by the ProcessName local-queue attribute. Each queue can specify
a different process definition, or several queues can share the same
process definition.
Triggering involves:
Application queue
An application queue is a local queue, which, when it has triggering
set on and when the conditions are met, requires that trigger messages
are written.
Process Definition
Each application queue has a process definition object associated with
it that holds details of the application that will get messages from
the application queue. (For more information see "Process definition
objects" in topic 1.4.4.)
Trigger event
A trigger event is an event that causes a trigger message to be
generated by the queue manager. This is usually a message arriving on
an application queue, but it can also occur at other times (see
"Conditions for a trigger event" in topic 2.8.3). MQSeries has a range
of options to allow you to control the conditions that cause a trigger
event (see "Controlling trigger events" in topic 2.8.4).
Trigger message
The queue manager creates a trigger message when it recognizes a
trigger event (see "Conditions for a trigger event" in topic 2.8.3).
It copies into the trigger message information about the application to
be started. This information comes from the application queue and the
process definition object associated with the application queue.
Trigger messages have a fixed format (see "Format of trigger messages"
in topic 2.8.7.4).
Initiation queue
An initiation queue is a local queue on which the queue manager puts
trigger messages. A queue manager can own more than one initiation
queue, and each one is associated with one or more application queues.
Trigger monitor
A trigger monitor is a continuously-running program that serves one or
more initiation queues. When a trigger message arrives on an
initiation queue, the trigger monitor retrieves the message. The
trigger monitor uses the information in the trigger message. It issues
a command to start the application that is to retrieve the messages
arriving on the application queue, passing it information contained in
the trigger message header, which includes the name of the application
queue. (For more information, see "Trigger monitors" in topic 2.8.6.)
Logical units of work (LUWs): The processing between sync points can be
called a recoverable unit of work, a unit of recovery, or a logical unit
of work (LUW). In this book, we use the term LUW. If any of the data
changes in an LUW has not been successful, then all are reversed (backed
out). Locks are released at the end of an LUW.
Many transaction processing systems automatically take sync points at the
start and end of a transaction. If the system provides the facility for
application programs to explicitly request sync points, programs can be
designed into several LUWs. Figure 1 shows how LUWs end at sync points.
Transaction A has one LUW, and transaction B is a multiple-LUW transaction.