02 MQ Administration Stud

WebSphere MQ System Administration I for
Distributed Platforms
Contents
Welcome
Unit 1 - A Review of WebSphere MQ
Unit 2 - Installation and Configuration
Exercise 1 - Working with Queues
Unit 3 - The MQI and Triggering
Exercise 2 - Implementing Triggering
Unit 4 - Robust Messaging
Exercise 3 - Recovery
Unit 5 - Distributed Queue Management
Exercise 4 - Distributed Queuing
Exercise 5 - A Simple Cluster
Unit 6 - More on Distributed Queuing
Exercise 6 - Implementing Clients
Unit 1. A Review of WebSphere MQ
What This Unit Is About

This unit provides an introduction to WebSphere MQ and its products. It forms the basis for
the remainder of the course.
What You Should Be Able to Do

After completing this unit, you should be able to:
• Describe the features and benefits of WebSphere MQ
• Identify the level of function in each WebSphere MQ queue manager
• Classify the application models that WebSphere MQ can support
• Find further information on specific aspects of WebSphere MQ
How You Will Check Your Progress

Accountability:
• Checkpoint questions
• Instructor questions
References
SC34-6597 WebSphere MQ Script (MQSC) Command Reference
SC34-6584 WebSphere MQ System Administration Guide
Unit Objectives
• Identify the level of function in each WebSphere MQ queue manager
This unit provides an introduction to WebSphere MQ and its products. It forms the basis for
the remainder of the course.
After completing this unit, the students should be able to:
• Identify the level of function of each WebSphere MQ queue manager
1.1 Facilities and Functions
This topic provides an introduction to the facilities and functions of WebSphere MQ and
discusses the benefits they provide.
WebSphere MQ - Commercial Messaging

• Common application programming interface
• Assured message delivery
• Time-independent processing
• Application parallelism
• Faster application development
Figure 1-1. WebSphere MQ - Commercial Messaging

WebSphere MQ is a means of program-to-program communication using messages
and queues. The communicating applications can be on the same system, or they can be
distributed across a network of IBM and non-IBM systems.
As well as depicting the basic mechanism by which one application communicates with
another, the visual also states five major benefits of WebSphere MQ.
• There is a common application programming interface, the MQI, that is consistent across all
the supported platforms.
• WebSphere MQ can transfer data with assured delivery; messages don't get lost, even in
the event of a system failure. Just as important, there is no duplicate delivery.
• The communicating applications don't have to be active at the same time. For example, a
sending application can still be putting messages on a queue even though the receiving
application is not active.
• Message-driven processing is a style of application design. An application is divided into
discrete functional modules which communicate with each other by means of messages. In
this way, the modules can execute on different systems, be scheduled at different times, or
they can act in parallel.
• Application development is made faster by shielding the developer from the complexities of
the network.
Further Information
• WebSphere MQ publications
− Many are cross-platform
For information that is common
For planning and implementing a WebSphere MQ network
− Some are platform-specific
• http://www.ibm.com/software/integration/wmq/
Latest news
References
Beta code
SupportPacs
The WebSphere MQ publications are listed in the bibliography at the back of these
course notes. Some publications describe function that relates to two or more queue
managers, the so called cross-platform publications. Other publications are platform-specific.
Discover WebSphere MQ on the World Wide Web. The Web address for the
WebSphere MQ home page is:
http://www.ibm.com/software/integration/wmq
Message and Queue

• A message is:
− A unit of information
A request for a service
A reply
A report
An announcement
• A queue is:
− A safe place to store messages
Lined up for servicing
Staged for delivery
A message is any information that one application wishes to communicate to another.
A message can convey a request for a service, or it can be a reply to such a request. It might
also report on the progress of another message; to confirm its arrival or report on an error, for
example. A message can also simply carry information for which no reply is expected.
A queue is a place to store messages until they can be processed. The time a
message has to wait in order to be retrieved and processed could be very short, or it could be
a long time if it has to wait for the receiving application to be started. Either way, the ability to
store a message safely is an important characteristic of a queue.
Applications Enabled by WebSphere MQ
• Program-to-program communication for:
− Message-driven processing
− Client/server implementation
− Distributed processing
• Components of an application can run independently on
• different systems and environments
• Applications with several processing steps
− Some fast
− Some slow
− Some not immediately available
• No loss or duplication of information
Queue Manager
• A queue manager owns and manages queues

• Family of application programming interfaces
− Message Queue Interface (MQI)
− Java Messaging Service (JMS)
Figure 1-2. Queue Manager
• The component of WebSphere MQ software which owns and manages queues is called a
queue manager.
• A queue manager also provides a family of application programming interfaces.
- The Message Queue Interface (MQI) enables an application to access its queues
and the messages they contain. The MQI is a simple application programming
interface which is consistent across all platforms supported by WebSphere MQ. The
MQI effectively protects applications from having to know how a queue manager
physically manages messages and queues. The MQI allows full access to WebSphere
MQ messaging support.
- The Java Message Service (JMS) is a specification of a portable API for
asynchronous messaging. JMS has been developed by Sun Microsystems in
collaboration with IBM and other vendors interested in promoting industry wide
standard frameworks. JMS is an object-oriented Java API with a set of generic
messaging objects for programmers to write event-based messaging applications. JMS
supports both request/reply and publish/subscribe models as separate object models.
• Both of the APIs can interoperate.
MQI Calls
• Send messages
− MQPUT
− MQPUT1
• Receive messages
− MQGET
• Housekeeping calls
− MQCONN, MQCONNX, and MQDISC
− MQOPEN and MQCLOSE
• Look at or change properties
− MQINQ and MQSET
• Perform transactions
− MQBEGIN, MQCMIT, and MQBACK
The most basic calls allow an application to put a message on a queue and get a message
from a queue.
MQPUT and MQPUT1
Put a message on a named queue. Generally, a message is added to the end of a
queue.
MQGET
Get a message from a named queue. Generally, a message is removed from the front
of a queue. The other calls are as follows:
MQCONN, MQCONNX, and MQDISC
Enable an application to connect to a queue manager and disconnect from a queue
manager. An application must connect to a queue manager before it can issue any
further MQI calls.
MQOPEN and MQCLOSE
Enable an application to open a queue for specified operations and close the queue
when access to it is no longer required. An application must open a queue before it can
access it in any way; to put messages on it, or get messages from it, for example.
MQINQ and MQSET
Inquire on and set the attributes of an object. All WebSphere MQ objects, such as a
queue, a process, and the queue manager object, have a set of attributes.
MQBEGIN, MQCMIT, and MQBACK
Enable an application to put and get messages as part of a unit of work.
Message Descriptor
Figure 1-3. Message Descriptor

A message consists of two parts:
• Message descriptor
• Application data
The message descriptor contains information about the message. The sending
application supplies both the message descriptor and the application data when it puts a
message on a queue, and both the message descriptor and the application data are returned
to the application which gets the message from the queue. Some of the fields in the message
descriptor are set by the application which puts the message on a queue; others are set by
the queue manager on behalf of the application.
Asynchronous Model
• Separate process for replies

• No need for communicating programs to be active at the same time
• Time independence
Figure 1-4. Asynchronous Model
• In the asynchronous model, instead of waiting for a reply to its first message, Program A
continues to send further requests to Program B. It is a separate process, Program X, which
receives the replies when they arrive.
• In this model, Program A is not dependent on Program B to be running when the requests
are sent. It can continue to do work even when Program B is stopped.
• Of course the application does expect Program X to receive the replies at some time, but not
necessarily at the same time that Program A or Program B is running. All this illustrates
another of the major benefits of WebSphere MQ, time independence.
Triggering
Triggering allows
− Instantiation as required
− Conservation of system resources
− Automation of flow
Figure 1-5. Triggering
WebSphere MQ provides an enhancement to the implementation of time-independent
processing, triggering. The arrival of a message on an application queue might indicate that it
is an appropriate time for another application to be started in order to process the messages
on the application queue. When the right conditions are detected by the queue manager, it is
the triggering facility which starts the application to service the application queue.
This course revisits triggering in some depth later.
Parallel Processing
− Requests not serialized
− Shorter elapsed time
− Consolidate replies
− Possibly selective MQGET?
− Incomplete set of replies?
− Different process to handle replies?
Figure 1-6. Parallel Processes
• This model allows several requests to be sent by a application without the application having
to wait for a reply to one request before sending the next. All the requests can then be
processed in parallel.
• The application can process the replies when they have all been received, and produce a
consolidated answer. The program logic might also specify what to do when only a partial set
of replies is received within a given period of time.
Client/Server
Figure 1-7. Client/Server
The server application, Insurance quotations, can handle requests from multiple client
applications. The message descriptor identifies the appropriate reply-to queue for each
request.
Assured Delivery
Figure 1-8. Assured Delivery

Assured delivery is another benefit of WebSphere MQ. It is the result of the protocol
used when one queue manager transmits a message to another queue manager. As far as
the applications are concerned, this process of transmitting messages is performed
asynchronously and transparently, and the protocol ensures that no message is lost, or
delivered to its destination queue more than once.
Connectionless Communications
Figure 1-9. Connectionless Communications

• If applications connected to one queue manager are putting messages on multiple queues
owned by another queue manager, only one transmission queue is required to stage the
delivery of these messages, and only one communications connection is required between
the two queue managers.
• Applications are shielded from the complexities of the underlying network. The application
programmer does not have to be concerned with writing programs to interfaces such as
APPC, CPI-C, or sockets, nor with writing code to handle communications errors. Under the
covers of the MQI, WebSphere MQ provides all this for you. Applications, and by implication
their programmers, do not even need to be aware of the locations of queues where they put
messages.
Message Driven Processing
Figure 1-10. Message Driven Processing
This is an example of a message lattice structure made possible by WebSphere MQ.

The components are simple message-driven programs, and might be running on different
systems and at different times. WebSphere MQ enables the rapid development of complex
business transactions like this.
Separate Processes as Units of Work
Figure 1-11. Separate Processes as Units of Work

A complex business transaction might be implemented as a number of separate
asynchronous processes where each process constitutes a unit of work. This type of design
emphasizes the importance of the assured, once and once only delivery property of
WebSphere MQ.
Multiple, Asynchronous Units of Work
Figure 1-12. Multiple, Asynchronous Units of Work

• To implement a business transaction as a single distributed unit of work requires a two-
phase commit protocol.
• WebSphere MQ encourages a different style of implementation which uses multiple units of
work acting asynchronously.
Message Persistence
Figure 1-13. Message Persistence
• A message survives a queue manager restart if that message is defined as persistent. This
applies no matter whether the queue manager was stopped by an operator command or
because of a system failure. This implies that persistent messages must be written out to a
log. If a queue manager is restarted after a failure, it recovers these persistent messages as
necessary from the logged data.
• A message defined as nonpersistent does not survive a queue manager restart. This applies
even if a queue manager finds an intact nonpersistent message on disk during restart; the
queue manager will discard it.
• Both persistent and nonpersistent messages can be stored on the same queue, except for
temporary dynamic queues.
• Whether a message is persistent or nonpersistent is determined by the value of a field in its
message descriptor.
1.2 WebSphere MQ Products and Platforms
This topic reviews the current list of WebSphere MQ queue managers and the
application platforms they support.
WebSphere MQ Queue Managers
Figure 1-14. WebSphere MQ Queue Managers
• The visual depicts the list of WebSphere MQ queue managers and their latest release levels
offered by IBM as of the date of publication of these course notes.
• MQSeries for Apple MacOS, Data General DG/UX, DYNIX/ptx, HP-UX for Itanium 32-bit,
HP-UX for Stratus Continuum/400, HP 3000 MPE/ix, NCR MP-RAS, NUMA-Q, SCO
Openserver, SCO UnixWare, and SGI (Silicon Graphics IRIX) support is available from third-
party vendors. They are not available from IBM and are not supported by IBM. Consult the list
of platforms available on the IBM WebSphere MQ home page for information about the
source of these products.
• All WebSphere MQ queue managers can exchange messages with each other and provide
the major benefits of WebSphere MQ as discussed in the previous topic.
• In the remainder of these course notes, the term UNIX systems will be used to refer to the
following operating systems.
- AIX
- Compaq Tru64 UNIX
- HP-UX
- Linux
- Sun Solaris
• Similarly, the term WebSphere MQ for Windows systems means WebSphere MQ
running on the Windows platforms:
- Windows 2000
- Windows 2003
- Windows XP
WebSphere MQ Framework
• The WebSphere MQ Framework allows users, independent software vendors, and IBM to
extend or replace queue manager function using defined interfaces.
• The components of the WebSphere MQ Framework are as follows:
- Trigger monitor interface (TMI)
- Message channel interface (MCI)
- Name service interface (NSI)
- Security enabling interface (SEI)
- Data conversion interface (DCI)
• There are two parts to the SEI.
- Authorization service
- Channel exits
Figure 1-15. WebSphere MQ Framework
WebSphere MQ Client
• An WebSphere MQ client is a component of WebSphere MQ which allows an application
running on one system to issue MQI calls to a queue manager running on another system.
• The client connection receives the input parameters of an MQI call from the application and
sends them over a communications connection to the server connection on the same system
as the queue manager. The server connection then issues the MQI call to the queue manager
on behalf of the application. After the queue manager has completed the MQI call, the server
connection sends the output parameters of the call back to the client connection, which then
passes them onto the application.
• The combination of a client connection, a server connection, and a communications
connection between them (for example, an SNA LU6.2 conversation or a TCP connection) is
called an MQI channel.
• The full range of MQI calls and options are available to a client application. The application
simply issues an MQCONN call to connect to a queue manager, that is, to start an MQI
channel.
Figure 1-16. WebSphere MQ Client
WebSphere MQ Platforms
Figure 1-17. WebSphere MQ Platforms
• An WebSphere MQ platform is a system environment in which an application may issue

calls to the MQI.
• On the visual, the platforms supported by WebSphere MQ are displayed in three groups.
- Those platforms on which an application may issue MQI calls to a queue manager
running on the same system, or on another system.
- Those platforms on which an application may only issue MQI calls to a queue
manager running on the same system.
- Those platforms on which an application may only issue MQI calls to a queue
manager running on another system, that is, a WebSphere MQ client application.
This is because there is no WebSphere MQ queue manager which runs on any of
these platforms.
- In addition to the queue managers listed earlier available from third party
vendors,there are several clients also available from other vendors. Consult the
platforms listing at the IBM WebSphere MQ home page for an up to date list.
Unit 1 Checkpoint
1. T/ F WebSphere MQ only supports asynchronous messaging.
2. WebSphere MQ assured delivery means that:
a. A report of delivery will always be sent back.
b. Unless the entire system goes down, no messages are lost.
c. Messages may be duplicated but never lost.
d. Messages will be delivered with no loss or duplication.
3. Applications place messages on queues by use of the
a. WebSphere MQ Program to Program Interface.
b. WebSphere MQ Message Queue Interface.
c. WebSphere MQ command processor.
Unit Summary
• Commercial messaging
• Benefits for all platforms
− Common application programming interface
− Assured message delivery
− Time-independent processing
− Application parallelism
− Faster application development
Unit 2. Installation and Configuration

The first unit reviewed the role of WebSphere MQ in commercial messaging and some
of the facilities and functions that WebSphere MQ provides. WebSphere MQ supports a wide
range of platforms and the major benefits of WebSphere MQ apply to all these platforms.
However, the Level 2 queue managers provide some enhancements which, in turn,
deliver additional benefits. It is these queue managers which now become the focus for the
remainder of this course. The only Level 2 queue manager which is excluded is WebSphere
MQ for z/OS which has its own course, MQ20, WebSphere MQ for z/OS System
Administration.
This unit commences by looking at what you need to consider, and what decisions you
need to make, when planning to implement WebSphere MQ. The unit then describes how to
create a basic configuration for a queue manager and provides a practical exercise in doing
this.

• Install WebSphere MQ with reference to the relevant documentation
• Demonstrate the New WebSphere MQ Explorer
• Create and configure a queue manager
• Test a queue manager configuration
• Start and stop a queue manager and perform other simple administration tasks

Accountability:
• Machine exercises
References
Unit Objectives
• List various administration interfaces
• Explain which interfaces are available on various platforms and
• how to use them
• Understand the use of the WebSphere MQ Explorer
• Describe naming rules and recommended conventions
− Queue Managers
− Queues
• Create and start queue managers
• Create queues
• Use sample programs to test new objects
2.1 Planning an WebSphere MQ Implementation
This topic looks at what you need to consider, and what decisions you need to make, when
planning to implement WebSphere MQ. It also contains some hints for getting started.
Naming WebSphere MQ Objects

• Allowable character set
A-Z, a-z, 0-9
./_%
• Maximum of 48 characters for the names of:
− Queue managers
− Queues
− Process definitions
− Namelists
− Clusters
− Listeners
− Services
− Authentication information objects
• Maximum of 20 characters for the names of:
− Channels
• No implied structure in a name
Note: Names in WebSphere MQ are case-sensitive
• The names of channels are limited to 20 characters but otherwise follow the standard rules
for naming WebSphere MQ objects.
• Agree on all names before you start. And remember, names in WebSphere MQ are case-
sensitive.
• Forward slash and percent are special characters. If you use either of these characters in a
name, the name must be enclosed in double quotation marks.
• Leading or embedded blanks are not allowed.
• National language characters are not allowed.
• Names can be enclosed in double quotation marks, but this is essential only if special
characters are included in the name.
Queue Manager
• Generally one per system
• May create additional ones, that is, for a test environment
• Naming Conventions
− Usually short
• TCP/IP host name
• Windows system name
• SNA LU alias
• Node name
− Should be unique within the network
Again, queue manager names are case-sensitive.
After installation, the first WebSphere MQ object to be created is a queue manager.
Typically, you only need to create one queue manager per system, but you can create
others, for testing or development purposes.
Every queue manager has a name which should be unique within a network of queue
managers exchanging messages with each other. The reason for this is that, when generating
a unique message identifier for a message, a queue manager uses the first 12 characters of
its name as part of the identifier.
Queues
• A local queue stores messages
• Other queue types
− Alias queue
− Local definition of a remote queue
− Model queue and dynamic queue
• Queue type is transparent to the application
o Model and dynamic queues are the exception
• Useful naming conventions
o The name of a queue should describe its function, not its type
o or location
o A common prefix for the names of related queues simplifies
o administration
Queue names are case-sensitive. WebSphere MQ Version 6.0 supports queues over
2 GB in size.
There are some useful conventions for naming a queue.
• The name of a queue should not contain an indication of its type or location. In this way, if a
queue changes from being a local queue to being a remote queue for example, you can still
use the same name for the queue and applications referencing the queue require no change,
not even a recompilation.
Instead, the name of a queue should describe its function.
• Using a common prefix for the names of related queues can aid administration, for example,
searching for all queues related to an application.
Special Local Queues

• Dead letter queue
− One per queue manager
− Designated queue for messages that cannot be delivered
− Always set up a dead letter queue
• Initiation queues
− Used for triggering
• Transmission queues
• Command queue
• Event queues
• Default queues
There are some local queues which have special purposes in WebSphere MQ.
• A dead letter queue is a designated queue upon which a queue manager will put messages
that cannot otherwise be delivered. It is not mandatory for a queue manager to have a dead
letter queue, but it is strongly recommended.
• An initiation queue is a queue which is used to implement triggering. You shall be discussing
triggering in more detail later in the course.
• Transmission queues are queues that temporarily store messages that are destined for a
remote queue managers.
• The command queue, SYSTEM.ADMIN.COMMAND.QUEUE, is a local queue to which
suitably authorized applications can send MQSC commands for processing. These
commands are then retrieved by a WebSphere MQ component called the command server.
The command server validates the commands, passes the valid ones on for processing by
the queue manager, and returns any responses to the appropriate reply-to queue.
• The command server validates the commands, passes the valid ones on for processing by
the queue manager, and returns any responses to the appropriate reply-to queue.
• When a queue manager detects an instrumentation event, which can either be a channel,
queue manager or performance, it puts the event message describing the event on an event
queue. An event queue can be monitored by a system management application which a can
get each message put on the queue and take the appropriate action.
• The purpose of the default queues is to identify the default values of the attributes of any
new queue you create. There is one default queue for each of the four types of queues,
namely, 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 when creating a
queue. You can change the default value of an attribute simply by redefining the appropriate
default queue.
Message Channel
Figure 2-1. Message Channel

• Channels are objects that provide a communication path from one queue manager to
another. A message channel is a one way link between two queue managers for the
transmission of messages. It consists of an MCA at the sending end, an MCA at the receiving
end, and a communications connection between the two. The communications connection
may be an SNA LU6.2 conversation, a TCP connection, and so on.
• Each end of a message channel has a separate definition. Both definitions contain the name
of the message channel. Among other things, the definition at each end of a message
channel also indicates:
- Whether it is the sending end or the receiving end of the channel, and
- The communications protocol to be used.
• A transmission queue is required for each message channel.
- A transmission queue is really just a local queue, that has a usage attribute whose
value indicates its special role to transmit.
- A transmission queue is located at the sending end of a message channel. As a
result, only the definition of the message channel at the sending end contains the
name of the transmission queue.
- Any message destined for a remote queue is put by the queue manager onto a
transmission queue. But how does the queue manager know which transmission
queue to use? One way is to give the transmission queue the same name as the name
of the destination queue manager.
Administration Interfaces
• WebSphere MQ Explorer
− Eclipse tooling
− Runs on Linux and Windows
− Can connect to and configure WMQ on all platforms
− Extensible via plug-ins
• WebSphere MQ commands (MQSC)
− Entered by means of a supplied interface
• Programmable Command Format (PCF) commands
− Put on the command queue by an application, and got by the command server
− Escape PCF to encapsulate a WebSphere MQ command
• WebSphere MQ Administration Interface (MQAI)
− Programming interface
− Data bags
− Implement self administering applications
− Administration tools
• WebSphere MQ control commands
− Entered at a command prompt
• Administration application
− Panel application on WebSphere MQ for Tandem NonStop Kernel
• Event messages
− Put on an event queue by the queue manager, and gotten by an application
2.2 New Eclipse Tooling
Old WebSphere MQ Explorer (1 of 2)
Figure 2-2. Old WebSphere MQ Explorer (1 of 2)

Graphical interface for IBM WebSphere MQ V5.3 administration ran on Windows, as a
Microsoft Management Console snap-in.
The old explorer could be configured to administer remote queue managers on distributed
platforms only.
Used a 'treeview + table' UI structure.
Old WebSphere MQ Explorer (2 of 2)
Figure 2-3. Old WebSphere MQ Explorer (2 of 2)

Had separate MQ Services interface in order to maintain and start services such as listeners
and command servers.
IBM WebSphere MQ Version 6
Figure 2-4. IBM WebSphere MQ Version 6

• Supports tasks achievable in previous MQ Explorers.
• Many usability enhancements.
• Advanced filtering via PCF.
• Administer connections: displays and manages application connections
• MQ Services merged into MQ Explorer: one desktop to manage resources and processes
• Can remotely administer z/OS queue managers
• Can be extended
IBM WebSphere MQ Version V6 Desktop
Figure 2-5. IBM WebSphere MQ Version V6 Desktop
WebSphere MQ Explorer is the graphical user interface in which you can administer and
monitor WebSphere MQ objects, whether they are hosted by your local computer or on a
remote system.
WebSphere MQ Explorer is now a perspective in WebSphere Eclipse Platform. The
WebSphere Eclipse Platform is based on Eclipse technology. Eclipse is an award-winning,
open source platform for the construction of powerful software development tools and rich
desktop applications. For more information, see http://www.eclipse.org.
Explorer and Content Perspectives
Figure 2-6. Explorer and Content Perspectives
A perspective defines the initial set and layout of views in the Workbench window. One or
more perspectives can exist in a single Workbench window.
Perspectives can be opened in one of two ways:
• In the same (existing) Workbench window.
• In a new Workbench window.
Perspectives define visible action sets, which can be changed to customize a perspective. A
perspective that is built in this manner can be saved, creating a custom perspective that can
be opened again later.
The Workbench window displays one or more perspectives. Initially one perspective, the
Resource perspective, is displayed. A perspective consists of views such as the Navigator as
well as editors for working with resources. More than one Workbench window can be open at
any given time.
IBM WebSphere MQ V6 Queue Display
Figure 2-7. IBM WebSphere MQ V6 Queue Display
Displays queue control information;

1. Select Queues folder: Navigator queue display.
2. Navigator queue content and attributes which shows queues defined on the selected queue
manager.
By selecting the status of a queue via right-mouse click and selecting status displays the
queue status display which gives information such as applications connected to the selected
queue and process Identification of the application.
Queue Content View
Figure 2-8. Queue Content View
The content view provides action functionality to view, clear, put messages and obtain status
information regarding the queue selected. The action functionality can be accessed by
utilizing a right-mouse click for the desired queue.
Work with Queues – Select the queue folder in the explorer perspective.
Left-click the desired queue to audit.
Right-click while queue is highlighted to view the action functionality pop-up.
Compare, status, delete, clear queue, put test message, browse, and properties can now be
performed.
Queue Status Information
Figure 2-9. Queue Status Information

Status information can describe the following queue attributes:
• Oldest message information
o Number of uncommitted messages
o Last put and get times.
• Queue connection information
• Application usage information
Queue Connection Information
Figure 2-10. Queue Connection Information

Queue connection usage information
This panel reflects active application which are utilizing the queue.
It will show the process ID, number of threads, open options (input (mq get) or output (mqput).
It also reflects what open options were requested and the userid the process is running
under. This information can be instrumental in assisting application area testing.
Example shows:
Amqsput application with process # 2444 utilizing 1 thread with Fail if quiescing open option
running under userid davidth.
Viewing Filters
Figure 2-11. Viewing Filters

Filters are a way of viewing queues that meet certain criteria such as queue with queue
depth. A filter allows the display of queues that meet the filter criteria and hide queues that do
not conform to the selection criteria.
Advanced Filters (1 of 4)
Figure 2-12. Advanced Filters (1 of 4)


Filters can be set even based on z/OS Coupling Facility Name.

New Queue Compare Functionality (1 of 3)
• Can compare two like resources
• Can compare resources across queue managers
Figure 2-16. New Queue Compare Functionality (1 of 3)

Figure 2-17. New Queue Compare Functionality (2 of 3)

Figure 2-18. New Queue Compare Functionality (3 or 3)

Result of show all compare between two queues across QM1 and QM2 queue manager. This
tool can be useful in migrating queue to different queue managers.
Eclipse Icons
Figure 2-19. Eclipse Icons
Workbench Mode (1 of 2)
Figure 2-20. Workbench Mode (1 of 2)

Workbench mode is recommended for advanced users. It allows Explorer to be used
with other products and perspectives in the same Eclipse Workbench. Developers can also
source code utilizing the Workbench mode.
Workbench Mode (2 of 2)
Option Description
Always run in background If this option is turned on, then the
Workbench will perform certain actions in the
background without disturbing the user.
Build automatically If this option is turned on, then the
Workbench will perform an automatic build
whenever a modified resource is saved.
Refresh workspace automatically If this option is turned on then the workspace
resources will be synchronized with their
corresponding resources in the file system
automatically. Note: This can potentially be a
lengthy operation depending on the number
of resources you have in your workspace
Save automatically before build If this option is turned on, then whenever you
perform a manual build (from the menu bar,
select Project for available options), the
Workbench will automatically save all
resources that have been modified since the
last build was performed.
Keep next/previous part dialog open If this option is turned on then the editor and
view cycle dialogs will remain open when
their activation key is let go.
Normally the dialog closes as soon as the key
combination is release.
Workspace save interval (in minutes) This number indicates how often the state of
the workspace is automatically saved to disk.
Open mode... You can select one of the following methods

for opening resources:
Double click - Single clicking on a resource
will select it and double clicking on it will open
it in an editor.
Single click (Select on hover) - Hovering the
mouse cursor over the resource will select it
and clicking on it once will open it in an editor.
Single click (Open when using arrow keys) -
Selecting a resource with the arrow keys will
open it in an editor.
Note: Depending on which view has focus,
selecting and opening a resource may have
different behavior.
The Preferences dialog is the dialog used to set user preferences.
It can be found from the main workbench Window menu under Window > Preferences.
Preference pages contributed by plug-ins will be found in this dialog.
Icons in Workbench Mode (Plug-in Development)
Figure 2-21. Icons in Workbench Mode

Icons in workbench mode appear when selecting plug-in Development or Java perspective.
Stand-alone Mode
Stand-alone mode is for newer users of IBM WebSphere MQ V6. This mode is much the
same as the old version of the administrative tool.
Figure 2-22. Stand-alone Mode

Stand-alone mode is good for administrator and new users of IBM WebSphere MQ V6.
Add Remote Queue Manager

WebSphere MQ Explorer automatically discovers all of the queue managers on the omputer
on which WebSphere MQ Explorer is installed. However, WebSphere MQ Explorer does not
automatically discover queue managers on other computers.
To administer remote queue managers, you must manually connect WebSphere MQ Explorer
to the remote queue manager and show the queue manager in the Queue Managers folder
in WebSphere MQ Explorer.
To remotely administer a queue manager, the queue manager must be running and it must
have the following objects:
• A running command server
• A running listener
• A server connection channel
Add Queue Manager (1 of 5)

Navigation to add queue manager:
• Right-click Queue Managers
• Select New -> Queue Manager
Figure 2-23. Add Queue Manager (1 of 5)

The following screen outlines adding a queue manager to the server. The process has
the same look and feel of the previous release of IBM WebSphere MQ explorer.

In distributed-queuing management, if the message is too big for the DLQ, the DLQ is
full, or the DLQ is not available, the channel stops and the message remains on the
transmission queue. Ensure your DLQ is defined, available, and sized for the largest
messages you handle.

The log data is held in a series of files called log files. The log file size is specified in units of 4
KB pages.
In WebSphere MQ for UNIX systems, the default number of log file pages is 1024, giving a
log file size of 4 MB. The minimum number of log file pages is 64 and the maximum is 65 535.
In WebSphere MQ for Windows, the default number of log file pages is 256, giving a
log file size of 1 MB. The minimum number of log file pages is 32 and the maximum is 65 535.

Check Allow to allow this queue manager on this computer to be administered by a
user on a remote WebSphere MQ computer. This is independent of whether or not this queue
manager is joined to a cluster, but you would normally enable remote administration to enjoy
the full benefits of single-point administration that clustering provides.

Notice the error indicator in the top left portion of the screen. IBM WebSphere MQ V6 detects
if the TCP/IP port number has been used previously.
Hover Help
Figure 2-28. Hover Help

Help hover can be instituted by depressing F1 on your keyboard while having the cursor over
the field in question.
Plug-in Support
Figure 2-29. Plug-in Support

2.3 Configuring a Queue Manager
After a brief look at what you need to consider when installing WebSphere MQ, the topic
continues by describing the tasks of creating, configuring, and controlling a queue manager.
Installation
• The general rules are as follows:

- Installing WebSphere MQ is like installing any other software on the same platform.
- Always follow the instructions in:
• The appropriate Quick Beginnings Guide for the WebSphere MQ queue manager.
• The appropriate System Management Guide for each of the remaining queue managers.
• WebSphere MQ V6.0 has a Typical, Compact, and a Custom installation option. To ensure
the install will be complete chose Custom so you can chose all the features. Remember there
are new features for example, WebSphere MQ Client File Transfer Application and Server
File Transfer Application that you could easily miss if you just chose a Typical install.
• Pay particular attention to instructions about what to do before installation. For example:
- For WebSphere MQ on UNIX systems, you must create a user ID with the name
mqm whose primary group is mqm.
- For MQSeries for Tandem NonStop Kernel, you must create a user ID in the group
MQM and log on as that user in order to install the product.
• Pay particular attention to instructions about what to do before using WebSphere MQ. For
example, on some UNIX systems, you are advised to change the values of certain kernel
parameters if they are not sufficient to support WebSphere MQ.
• You may install WebSphere MQ for AIX using SMIT, or you may choose the easy
installation. The easy installation only places a minimal typical set of components on your
system. It excludes, for example, the online documentation and the application development
support. Further details can be found in WebSphere MQ for AIX, V6.0 Quick Beginnings
GC34-6476.
• During the installation of MQSeries for Tandem NonStop Kernel, you are prompted to enter
the name of the volume to be used for the installation. If you do not enter a name, the default
installation volume, $SYSTEM, is used instead. The name $SYSTEM is used in the examples
throughout these course notes. If your installation volume is different, you will need to replace
the name $SYSTEM with the name of your installation volume wherever appropriate.
• For WebSphere MQ V6.0, 64-bit queue managers are now supported on AIX, HP-UX, Linux
PPC, and Sun Solaris systems. All WebSphere MQ commands are 64-bit and have a built in
path to the WebSphere MQ 64-bit libraries, however, this can be overridden by the use of
LIBPATH and thus can cause WebSphere MQ commands to fail to run. Please check the
appropriate manual for the implications of 64-bit queue managers.
Migration Considerations for V5.3 and V5.3.1
Create Queue Manager
Figure 2-30. Create Queue Manager

• crtmqm, create queue manager, and dltmqm, delete queue manager, are examples of
control commands. The name of the queue manager is a required parameter on both of these
commands.
• Some of the following optional parameters of the crtmqm command may be useful in the
practical exercises.
-q Specifies that this queue manager is to be made the default queue manager.
-lc Circular logging is to be used. This is the default logging method.
-ll Linear logging is to be used. Linear logging is needed for recovery from media failures.
-lf LogFileSize
The size of each of the log files expressed as a multiple of 4 KB.
-ld LogPath
The directory to be used to hold the log files.
• On MQSeries for Tandem NonStop Kernel, the crtmqm command has two additional
required parameters besides the name of the queue manager.
-n PATHMONProcessName.
The name of the TS/MP PATHMON process for the queue manager.
-o HomeTerminalName
The home terminal device name.
• The control commands are described in WebSphere MQ System Administration Guide for a
Version 5 or 6 queue manager and in the relevant System Management Guide for each of the
remaining queue managers which support control commands.
Start Queue Manager
Figure 2-31. Start Queue Manager

• strmqm, start queue manager, and runmqsc, run WebSphere MQ commands, are further
examples of control commands.
• The supplied file amqscoma.tst contains a sequence of WebSphere MQ commands to
create the system and default objects. The precise format of the runmqsc command to
create the system and default objects depends on the system in use and your current position
within the file system. You may need to use a fully qualified file name, for example.
MQSeries for Compaq OpenVMS
runmqsc QMgrName < MQS_EXAMPLES:AMQSCOMA.TST
MQSeries for Tandem NonStop Kernel
runmqsc /IN $SYSTEM.ZMQSSMPL.AMQSCOMA/ QMgrName
Websphere MQ on UNIX systems
runmqsc QMgrName < mqmtop/samp/amqscoma.tst
where mqmtop is:
/opt/mqmon AT&T GIS UNIX, DC/OSx, and SINIX.
/usr/mqmon SunOS.
• Note that, on a Version 5 or later queue managers, there is no need to issue a command to
create the system and default objects. These objects are created automatically when you
create a queue manager.
WebSphere MQ MQSC Commands
Figure 2-32. WebSphere MQ MQSC Commands

• The more important syntax rules for writing WebSphere MQ commands are as follows.
- Each command starts on a new line.
- The names of the commands and their keywords are not case sensitive.
- A blank line, and a line starting with an asterisk (*), are ignored.
- A line may contain up to 80 characters but, on a Version 5 queue manager, a line
may be of any length up to the maximum allowed by the system.
- If the last non-blank character on a line is:
• A minus sign (-), the command is continued from the start of the next line.
• A plus sign (+), the command is continued from the first non-blank character in the next line.
- On a Version 5 or later queue managers, you can optionally use a semicolon (;) to
terminate a command.
- An WebSphere MQ command may contain a string of characters. The more important
rules for using strings are as follows:
• A string containing blanks, lower case characters, or special characters other than those
valid in the name of an WebSphere MQ object, must be enclosed in single quotation marks.
Lower case characters not enclosed in single quotation marks are folded to upper case.
• A string containing no characters is not valid.
• The WebSphere MQ commands are described in the WebSphere MQ Script (MQSC)
Command Reference V6.0.
• On AIX, HP-UX, Linux, Solaris, and Windows, each line can be of any length up to a
maximum of 2048 characters.
• On other UNIX systems, and HP OpenVMS, each line can be of any length up to and
including 80 characters.
• On Compaq NSK each line can be of any length up to and including 72 characters.
Run WebSphere MQ Commands
Figure 2-33. Run WebSphere MQ Commands
• On MQSeries for Compaq OpenVMS, the runmqsc command reads from the system input
device, SYS$INPUT, and writes to the system output device, SYS$OUTPUT.
• On MQSeries for Tandem NonStop Kernel, the runmqsc command reads from the standard
IN file and writes to the standard OUT file. In order to redirect input and output when using the
runmqsc command, you may either use the TACL redirection operators IN and OUT or the
command's own parameters for this purpose, -i and -o. For example:
runmqsc /IN MQSCIN, OUT MQSCOUT/
or
runmqsc -i MQSCIN -o MQSCOUT
• To end interactive input of WebSphere MQ commands, you enter the EOF character for the
system you are using. Specifically, you need to do enter the following.
Digital OpenVMS
CTRL+Z
OS/2 Warp and Windows
Ctrl+Z, and then press Enter (END command on V5)
Tandem NonStop Kernel
CTRL+Y
UNIX systems
CTRL+D (END command on V5 or later)
Alternatively, on a Version 5 or later queue manager, you can enter the WebSphere MQ
command END and, on MQSeries for Tandem NonStop Kernel, you may type exit or quit and
press Enter.
• On a Version 5 or later queue manager, when issuing WebSphere MQ commands
interactively, you can get help by entering command?, where command is the name of the
command you are interested in.
• On UNIX systems, man pages are provided for all the WebSphere MQ commands.
Creating a Local Queue
Figure 2-34. Creating a Local Queue
• The visual depicts two examples of the WebSphere MQ MQSC (Script) command DEFINE
QLOCAL which is used to create a local queue. Note that the second example uses the
synonym DEF QL.
• The keywords and their values are used to specify the values of attributes of the local queue
being created. The values of those attributes which are not explicitly provided by keywords
are taken instead from the values of the corresponding attributes of the default local queue
whose name is SYSTEM.DEFAULT.LOCAL.QUEUE.
• The new attribute NPMCLASS allows the survival of nonpersistent messages. The allowed
settings are HIGH and NORMAL. The NPMCLASS can be defined or altered on local and
model
• The keywords REPLACE and LIKE have the following meanings.
REPLACE
If the queue already exists, replace its definition with the new one. Note that any messages
on an existing queue are retained.
LIKE
Use the named queue for the default values of attributes rather than the default local queue.
Displaying Attributes
Figure 2-35. Displaying Attributes
• The WebSphere MQ command to display the attributes of a queue is DISPLAY QUEUE.

The synonym is DIS Q.
• DISPLAY QUEUE applies to all types of queue: local, alias, remote, and model.
• A generic queue name can be specified by the use of a trailing asterisk (*). An asterisk on its
own specifies all queues.
• On a Version 5 or later queue manager, there is a DISPLAY QLOCAL command, but it only
applies to a local queue.
• The keyword ALL causes all the attributes be displayed. On a Version 5 or later queue
manager, this is the default if you do not specify a generic queue name and do not request
any specific attributes.
• You can request the display of selected attributes by using the appropriate keywords.
• If no attributes are requested on the DISPLAY QUEUE command, and the ALL keyword is
not specified or defaulted, only the queue name and queue type are displayed.
• The WebSphere MQ command to display the attributes of the queue manager object is
DISPLAY QMGR. Note that the name of the queue manager does not appear in the
command.
• On a Version 5 or later queue manager, if you do not request any specific attributes on the
DISPLAY QMGR command, the default action is to display all the attributes.
• If no attributes are requested on the DISPLAY QMGR command, and the ALL keyword is
not specified or defaulted, only the queue manager name is displayed.
• On AIX, HP OpenVMS, HP-UX, Linux, Solaris, Windows, you can use the following
commands (or their synonyms) as an alternative way to display these attributes.
- DISPLAY QALIAS
- DISPLAY QLOCAL
- DISPLAY QMODEL
- DISPLAY QREMOTE
• On the DISPLAY QMGR command, you can now choose to display different sets of queue
manager parameters. The parameters are CHINIT, CLUSTER, EVENT, and SYSTEM.
Other Queue Types
Figure 2-36. Other Queue Types

• An alias queue is a WebSphere MQ object that is used to refer indirectly to another queue.
The WebSphere MQ command to create an alias queue is DEFINE QALIAS.
The TARGQ keyword specifies the name of the queue to which the alias queue resolves. This
queue might either be:
- A local queue, or
- A local definition of a remote queue.
• A local definition of a remote queue, or more simply a remote queue definition, is a
WebSphere MQ object owned by one queue manager that refers to a queue owned by
another queue manager. The WebSphere MQ command to create a local definition of a
remote queue is DEFINE QREMOTE. The keyword RNAME specifies the name of the queue
as it is known on the remote queue manager, and the keyword RQMNAME specifies the
name of the remote queue manager.
• A model queue is an WebSphere MQ object whose attributes are used as a template for
creating a dynamic queue. When an application opens a model queue, the queue manager
creates a dynamic queue. The WebSphere MQ command to create a model queue is
DEFINE QMODEL. The DEFTYPE keyword is used to specify whether a dynamic queue
created from the model queue is:
- A temporary dynamic queue, which is deleted when it is closed and does not survive a
queue manager restart, or
- A permanent dynamic queue, whose deletion on the MQCLOSE call is optional and which
does survive a queue manager restart.
• The QMODEL queue has a new attribute NPMCLASS that allow nonpersistent messages to
survive on a restart of queue manager.
More WebSphere MQ Commands
Figure 2-37. More WebSphere MQ Commands
Sample Programs
Figure 2-38. Sample Programs
• The sample programs may report some conditions as reason codes. A full list of reason
codes can be found in Appendix A, “Selected WebSphere MQ Constants”, on page A-1.
• By default, the executable versions of the sample programs can be found in the following
locations.
MQSeries for Compaq OpenVMS
[.BIN]
under MQS_EXAMPLES
MQSeries for OS/2 Warp
\MQM\TOOLS\C\SAMPLES\BIN
MQSeries for Tandem NonStop Kernel
$SYSTEM.ZMQSSMPL
WebSphere MQ on UNIX systems
mqmtop/samp/bin
Where mqmtop is:
/usr/lpp/mqmon AIX.
/usr/mqmon SunOS.
/opt/mqmon the remaining UNIX systems.
WebSphere MQ for Windows
\Program Files\IBM\WebSphere MQ\tools\C\samples\bin
End Queue Manager
Figure 2-39. End Queue Manager

• The control command to end the operation of a queue manager is endmqm. The command
stops the queue manager in one of three modes.
Controlled (or quiesced) shutdown
The queue manager stops only after all applications have disconnected. All new requests to
connect to the queue manager fail. This is the default mode.
Immediate shutdown
The queue manager stops after it has completed all the MQI calls currently being processed.
Any MQI calls issued after this command has been entered fail. Any incomplete units of work
are rolled back when the queue manager is next started.
Controlled Shutdown with Wait
End Programs in the same manner as the *CNTRLD option. However, the command prompt
does not return until the queue manager has ended.
Preemptive shutdown
The queue manager stops without waiting for applications to disconnect or for MQI calls to
complete. The use of this mode can lead to unpredictable results.
Unit 2 Checkpoint
1. T/F Queue manager names can be made up of any printable ASCII characters.
2. Alias queues can point to what other queue types?
a. Another alias queue
b. Local queues
c. Model queues
3. Any local queue can be a dead letter queue as long as it is manager.
a. Is identified as the dead letter queue to the queue manager.
b. Has put enabled.
c. Is not being used by any other application.
4. T/F Altering queue attributes can be done while the queue manager is running and the
changes take effect immediately.
5. The NPMCLASS attribute is valid for which of these queues?
a. Local
b. remote
c. model
d. alias
e. cluster queue
6. The command CRTMQM -q -u DLQ CHIWINSVR was executed. What was created?
a. queue manager named DLQ
b. a default queue manager named CHIWINSVR with queue DLQ
assigned to the queue manager as the dead letter queue.
c. a queue manager named CHIWINSVR
d. a queue manager named CHIWINSVR with a default transmission queue DLQ
assigned to the queue manager
7. The command endmqm -c DALHOST was issued. What type of shutdown will be
performed?
a. normal
b. preemptive
c. controlled
d. immediate
Unit Summary
• Implementation planning
• Configuring a queue manager
Exercise 1
Unit 3. The MQI and Triggering

This unit commences with an introduction to some of the more important features of the MQI
and is followed by a description of triggering in some detail.
Finally, WebSphere MQ Publish/Subscribe, which requires application involvement, is
covered from the administrative viewpoint. There is a practical exercise on configuring
WebSphere MQ for triggering and reply-to queues.

• Describe some of the more important features of the MQI
• Configure WebSphere MQ to enable triggering
• Determine the cause if triggering fails to occur
• Explain WebSphere MQ Publish/Subscribe and know the major administrative requirements

Accountability:
• Classroom discussion
References
Unit Objectives
− Provide an overview of the Message Queueing Interface
− Describe the triggering process
− Enable triggering for a local queue
− Explain conditions that cause triggering to fail
− Examine publish/subscribe and know where it is supported
On completion, you should be familiar with the MQI, the Message Queue Interface, used
by applications to manipulate messages and affect their delivery.
One of the most common functions used in WebSphere MQ is triggering. It enables
message-driven, or event-driven, processing to occur. During this topic, the requirements for
triggering will be discussed and you will gain a clear understanding of the advantages, as well
as some of the more common pitfalls, associated with triggering.
Finally, WebSphere MQ Publish/Subscribe, which requires administration before use by
applications is reviewed from the aspect of the installation, setup and operational
requirements.
3.1 The MQI
This topic provides an introduction to some of the more important features of the MQI.
Notation
Figure 3-1. Notation
Common Parameters
• Hconn, connection handle
− Returned by the MQCONN and MQCONNX calls
− Input parameter on all other MQI calls
• CompCode, completion code
− MQCC_OK
− MQCC_WARNING
− MQCC_FAILED
• Reason, reason code
− MQRC_. . .
− MQRC_NONE
A listing of all the reason codes is contained in Appendix B of this student guide.
Object Descriptor
• ObjectType
− MQOT_Q - queue
− MQOT_PROCESS - process
− MQOT_Q_MGR - queue manager
• ObjectName
− Must be blank if ObjectType is MQOT_Q_MGR
− Every object defined to a queue manager has a unique name within its type
• ObjectQMgrName
− Blank denotes the local queue manager
− DynamicQName
• Specifies the name of the dynamic queue to be created
− AlternateUserId
− Alternative user identifier for checking the authorization to open the object
The object descriptor is used by an application to identify an WebSphere MQ object that it
wishes to open. It is one of the parameters on the MQOPEN call and MQPUT1 call, where it
is referred to as ObjDesc.
Three fields in the object descriptor are needed to identify an object uniquely:
• The object type, ObjType, because the name of an object is only unique within its type.
• The name of the object, ObjectName.
• The name of the queue manager which owns the object, ObjectQMgrName.
Connecting and Disconnecting
Figure 3-2. Connecting and Disconnecting
• An application normally needs authority to connect to a queue manager.

• Options on the MQCONNX call now allows you to create a connection that can be shared by
all the threads in a process.
• In the normal MQI environment the default value is MQCNO_HANDLE_SHARE_NONE.
Opening and Closing an Object
Figure 3-3. Opening and Closing an Object
• The Options parameter on the MQOPEN call is used by the application to specify which
operations it wishes to perform on the object being opened, for example,
MQOO_INPUT_SHARED, or to control the action of MQOPEN, for example,
MQOO_FAIL_IF_QUIESCING.
• An application normally needs authority to open an object for each of the requested
operations. These authorities are checked at the time the object is opened.
• For getting messages from a queue, an application may request either
MQOO_INPUT_SHARED or MQOO_INPUT_EXCLUSIVE. Alternatively, it may request
MQOO_INPUT_AS_Q_DEF. In the latter case, the queue is opened in the manner specified
by the DefInputOpenOption attribute of the local or model queue being opened. The value of
this attribute may be MQOO_INPUT_SHARED or MQOO_INPUT_EXCLUSIVE.
• Another attribute of a local or model queue is Shareability. The value of this attribute may be
MQQA_SHAREABLE or MQQA_NOT_SHAREABLE. The latter value takes precedence over
any input options specified on the MQOPEN call.
• The MQOO_INPUT_ options are for removing messages from the queue. There is a
separate option, MQOO_BROWSE, for reading messages on a queue and leaving them
there.
Dynamic Queue
• Created when a model queue is opened
− Following fields in the object descriptor are set before the MQOPEN call
ObjectName identifies the model queue
DynamicQName specifies the name of the dynamic queue to be created
− After the MQOPEN call
ObjectName contains the name of the dynamic queue
• Temporary dynamic queue
Deleted when the queue is closed
Does not survive a queue manager restart
Can store nonpersistent messages only
• Permanent dynamic queue
Can be deleted by an option on the MQCLOSE call
Survives a queue manager restart
Can store persistent messages
A permanent dynamic queue might also be deleted by using the WebSphere MQ
command DELETE QLOCAL.
Put Message
Figure 3-4. Put Message

The MQPUT call puts a message on a queue. In addition to CompCode and Reason, the
parameters of the MQPUT call are as follows.
Hconn The connection handle.
Hobj The object handle returned from a successful MQOPEN call with the
option MQOO_OUTPUT specified.
MsgDesc The message descriptor structure, MQMD. Some of its fields are input
fields to the MQPUT call, some are output, and some are both input and
output. The message descriptor which actually accompanies a message
on a queue has some fields which have been supplied by the application
and some which have been supplied by the queue manager.
PutMsgOpts The put message options structure, MQPMO. One of the fields in this
structure, Options, is used by the application to specify options that
control the action of MQPUT.
BufferLength The length of the message in the Buffer.
Buffer The message data.
Priority
• Priority
− Field in the message descriptor, set by an application to one of the following
A value in the range 0 (lowest) to 9 (highest)
MQPRI_PRIORITY_AS_Q_DEF
• MsgDeliverySequence
− Attribute of a local or model queue with values
MQMDS_PRIORITY - messages returned by MQGET in priority order
MQMDS_FIFO - messages returned by MQGET in FIFO order
• DefPriority
− Attribute of a queue specifying the default message priority
− Used when an application sets Priority to MQPRI_PRIORITY_AS_Q_DEF
• Conventions
− In general, use the default priority
− Use the same priority as the original message for a reply or a report
Get Message
Figure 3-5. Get Message

The MQGET call gets a message from a queue. In addition to CompCode and Reason, the
parameters of the MQGET call are as follows.
Hconn The connection handle.

Hobj The object handle returned from a successful MQOPEN call with either of the
options MQOO_INPUT_ or MQOO_BROWSE specified.
MsgDesc The message descriptor structure, MQMD. Some of its fields are input fields to
the MQGET call, some are output, and some are both input and output.
Essentially, the message descriptor structure returned to the application by an
MQGET call is the same as that which accompanied the message on the
queue.
GetMsgOpts The get message options structure, MQGMO. One of the fields in this
structure, Options, is used by the application to specify options that control the
action of MQGET. The option MQGMO_WAIT indicates that the application is
to wait until a suitable message arrives if one is not already on the queue. The
maximum time the application waits is specified in the
field The application may specify an unlimited wait.
WaitInterval.
BufferLength The length of the Buffer area.

Buffer The area to contain the message data.
DataLength The length of the message returned.
Reply-to Queue
Figure 3-6. Reply-to Queue

More Fields in the Message Descriptor
Figure 3-7. More Fields in the Message Descriptor
Message and Correlation Identifiers

• Two fields in the message descriptor
• MsgId, message identifier
− If an application specifies MQMI_NONE on an MQPUT call, the queue manager
generates a unique message identifier
• CorrelId, correlation identifier
− In a reply or report message, it is normally copied from the MsgId of the original
message
• Both fields are treated as bit strings by the queue manager
− Not subject to any data conversion therefore
• Both the MsgId and CorrelId fields are treated as bit strings, not character strings, by the
queue manager. The implication of this is that neither field is ever subject to data conversion
when a message flows from one system to another.
• On an MQPUT call, an application might either specify a particular value for the message
identifier or it may specify the value MQMI_NONE. In the latter case, the queue manager
generates a unique message identifier and places it the message descriptor which
accompanies the message. The queue manager also returns the generated message
identifier to the application as an output field in the message descriptor. It is important
therefore that the application resets the MsgId field to MQMI_NONE prior to each MQPUT call
if it wishes the queue manager to generate a unique message identifier.
• On a Version 5 or Version 6 queue manager, an application can use the put message option
MQPMO_NEW_MSG_ID to request the generation of a unique message identifier. The use of
this option relieves the application of the need to reset the MsgId field to MQMI_NONE prior
to each MQPUT call.
• The correlation identifier is normally used to provide an application with a means of
matching a reply or report message with the original message. In a reply or report message
therefore, the value of the CorrelId field is normally copied from the MsgId field of the original
message. There is a report option to vary this rule, however.
Retrieving Messages
• With selection criteria
− Set MsgId and/or CorrelId prior to an MQGET call
− Also ensure that MatchOptions in get message options is set to
MQMO_MATCH_MSG_ID + MQMO_MATCH_CORREL_ID
• Without selection criteria
− Reset MsgId and CorrelId to MQMI_NONE and MQCI_NONE respectively before each
MQGET call
− Or, set MatchOptions in get message options to MQMO_NONE
• On return from an MQGET call, MsgId and CorrelId are set to the values for the message
retrieved
Order of Retrieving Messages

• Messages on a queue can be retrieved by an application in the same order they were put
by another application, provided:
− The messages all have the same priority
− The messages were all put within the same unit of work, or all put outside of a unit of
work
− No other application is getting messages from the queue
− The queue is local to the putting application
− But they may be interspersed with messages put by other applications
• If the queue is not local to the putting application, the order of retrieval is still preserved
provided:
− The first three conditions above still apply
− Only a single path is configured for the messages
− No message is put on a dead letter queue
− No nonpersistent messages are transmitted over a fast message channel
Message Group
Figure 3-8. Message Group
The function described on this visual is supported by Version 5 or 6 queue managers only.
A message group is a group of one or more logical messages.
A logical message is a physical message, unless it is split into segments. We shall be looking
at message segmentation on a later visual. For the moment therefore, we shall assume that a
logical message is a physical message.
A logical message within a group is identified by two fields in the message descriptor,
GroupId and MsgSeqNumber. All logical messages belonging to the same group have the
same value for the GroupId field. The MsgSeqNumber field has the value 1 for the first logical
message, 2 for the second, and so on. There is, therefore, an implied ordering of the logical
messages within a group.
A physical message which does not belong to any group has the value MQGI_NONE in the
GroupId field, and the value 1 in the MsgSeqNumber field.
There are two main uses of a message group.
• To ensure ordering on retrieval in circumstances where this is not already guaranteed. An
application is able to put a sequence of messages constituting a message group on a queue
by specifying the put message option MQPMO_LOGICAL_ORDER. The queue manager
generates a unique group identifier and assigns a message sequence number to each
message as it is put on the queue.
Another application is then able to get the messages constituting the group from the queue, in
the same order they were put, by specifying the get message option
MQGMO_LOGICAL_ORDER.
• To allow an application to group together related messages.
This may be useful, for example, if it is important for a group of related messages to be
processed by the same server instance, or by a particular server instance. By setting the
value MQMO_MATCH_GROUP_ID in the MatchOptions field in get message options, an
application can retrieve only those messages with a specified group Identifier.
Message Segmentation
Figure 3-9. Message Segmentation

A logical message may consist of two or more physical messages, each of which is
called a segment. A segment of a logical message is identified by three fields in the message
descriptor, GroupId, MsgSeqNumber, and Offset. All segments of the same logical message
have the same values for the GroupId and MsgSeqNumber fields, but the value of the Offset
field is different for each segment. The segment offset is the offset of the data in the physical
message from the start of the logical message. The offset of the first segment is 0.
Message segmentation is needed when a message is too large for an application, a
queue, or a queue manager. Thus, a logical message is essentially the unit of information that
needs to be handled by an application, but its size may mean that it has to be split into more
than one physical message.
Provided a message is not too large for an application to handle in a single buffer,
segmentation and reassembly of a message can be performed by the queue manager.
This is the simplest scenario.
To ask the queue manager to segment a message if necessary, the putting application
simply sets the value MQMF_SEGMENTATION_ALLOWED in the MsgFlags field of the
message descriptor and issues one MQPUT call. Similarly, the getting application simply
specifies the get message option MQGMO_COMPLETE_MSG in order to request the queue
manager only to return a complete logical message on an MQGET call. And if the logical
message is segmented, the queue manager reassembles it before returning it to the
application.
If a message is too large for an application to handle in a single buffer, the application may
perform the segmentation itself by issuing an MQPUT call for each segment. Similarly, an
application may issue an MQGET call for each segment of a logical message.
Distribution List
Figure 3-10. Distribution List

A distribution list may contain the name of an alias queue or the name of a local definition of a
remote queue. In the example of a distribution list shown on the visual, the following are
assumed.
• MAIL_IN_HURSLEY is an alias queue which resolves to the local queue MAIL_IN on queue
manager HURSLEY.
• MAIL_IN_PARIS is a remote queue definition which resolves to the queue MAIL_IN on
queue manager PARIS using transmission queue PARIS.
• MAIL_IN_DALLAS is a remote queue definition which resolves to the queue MAIL_IN on
queue manager DALLAS using transmission queue DALLAS.
• MAIL_IN_SEATTLE is a remote queue definition which resolves to the queue MAIL_IN on
queue manager SEATTLE using transmission queue DALLAS.
As a result, ObjectQMgrName is to blank for each object record.
Once a distribution list has been opened, the application can call MQPUT to put a
message on the queues in the list. As a response to the call, the queue manager puts one
copy of the message on each local queue, including the transmission queues. Thus, only one
copy of the message is put on the transmission queue DALLAS even though the message is
ultimately destined for two queues.
On the transmission queue, the application data is prefixed by a distribution header, as
well as a transmission queue header. Appended to the distribution header are object records
for MAIL_IN at DALLAS and MAIL_IN at SEATTLE. Thus, the message that is transmitted
between HURSLEY and DALLAS effectively contains a distribution list for the two
destinations. Therefore, when the message is received by the receiving MCA at DALLAS, the
MCA has sufficient information to open a distribution list and put the message to it. The queue
manager will put one copy of the message on the local queue MAIL_IN and another copy on
the transmission queue SEATTLE. And so on.
You can see therefore that an important property of the implementation is that a
message destined for multiple queues is only replicated at the last possible point at each
stage of its journey. In this way, network traffic is minimized.
3.2 Triggering
This topic describes how triggering works and how to configure a queue manager for
triggering.
Components of Triggering
Figure 3-11. Components of Triggering
The sequence of actions depicted on the visual are as follows:

1. Program A puts a message on an application queue which is enabled for triggering.
2. If the conditions for triggering are met, a trigger event occurs, and the queue manager
examines the process object referenced by the application queue. The process object
identifies the application to be started, Program B.
3. The queue manager creates a trigger message whose fields contain information copied
from certain attributes of the process object and the application queue. The queue manager
puts the trigger message on an initiation queue.
4. A long running program called a trigger monitor gets the trigger message, examines its
contents, and ...
5. ... starts Program B, passing the entire trigger message as a parameter.
6. Program B opens the application queue and gets messages from it.
Queue Attributes Controlling Triggering
Figure 3-12. Queue Attributes Controlling Triggering
The parameters of the WebSphere MQ command DEFINE QLOCAL which control triggering
are as follows.
TRIGGER or NOTRIGGER
Triggering is active or not active respectively.
TRIGMPRI(integer)
The threshold message priority for triggers. The queue manager gnores
messages with a priority lower than this when deciding whether a trigger event
should occur.
TRIGTYPE The trigger type.
FIRST
A trigger event occurs when the queue changes from being empty to having one
message on it.
DEPTH
A trigger event occurs when the number of messages on the queue reaches the
value indicated by the TRIGDPTH parameter.
Note that, when triggering by depth, the queue manager disables triggering by setting the
application queue to NOTRIGGER after it has created a trigger message. It is the
responsibility of the application to reenable triggering by using the MQSET call.
EVERY A trigger event occurs for every message put on the application queue.
TRIGDPTH(integer)
The number of messages that must be on the queue before a trigger event
occurs for TRIGTYPE(DEPTH).
TRIGDATA(string)
Data that is copied into the trigger message.
Process Attributes
Figure 3-13. Process Attributes
• A process and a queue are allowed to have the same name. The name of an object only has
to be unique within an object type.
• Other WebSphere MQ commands for processes are as follows:
- ALTER PROCESS
- DELETE PROCESS
- DISPLAY PROCESS
Triggering Conditions
Figure 3-14. Triggering Conditions

• All of the conditions shown on the visual must be satisfied for a trigger event to occur.
• If a trigger event does not occur when it is expected, check this list.
A full statement of all of these conditions can be found in the WebSphere MQ Application
Programming Guide.
Fields in the Trigger Message

• Copied from the corresponding attributes of the application queue
− QName
− TriggerData
− ProcessName
• Copied from the corresponding attributes of the process object
− ApplType
− ApplId
− EnvData
− UserData
• QMgrName
The trigger message, structure MQTMC2, contains the following fields:
QName The name of the application queue.

TriggerData The trigger data. This is for use by the started application.
WebSphere MQ Versions 5 and 6 allow this field to be used to
specify the name of the channel to be triggered.
ProcessName The name of the process object identifying the application that can
service the application queue.
ApplType The application type. Examples are MQAT_CICS, MQAT_UNIX, and
MQAT_WINDOWS.
ApplId The application identifier. This is a character string that identifies the
application to be started.
EnvData The environment data. This is for use by the trigger monitor.
UserData The user data. This is for use by the trigger monitor or by the started
application.
QMgrName The name of the queue manager that owns the application queue.
Trigger Monitor
Figure 3-15. Trigger Monitor
• A number of trigger monitors are supplied with WebSphere MQ. The trigger monitor
runmqtrm is supplied with all queue managers except WebSphere MQ for iSeries.
• If the name of an initiation queue is not explicitly specified on the control command
runmqtrm, the queue SYSTEM.DEFAULT.INITIATION.QUEUE is used by default.
• The command which runmqtrm uses to start the application contains the structure
MQTMC2 as a parameter. The MQTMC2 structure supplies the started application with the
name of the queue that caused the trigger event and the name of the queue manager which
owns it. The started application is therefore able to connect to the queue manager and open
the queue.
• Other trigger monitors are supplied by WebSphere MQ.
- On Compaq Open VMS Alpha, Compaq NonStop Kernel, UNIX systems, and
Windows systems, there is a trigger monitor runmqtmc provided for WebSphere MQ
clients. It links with the WebSphere MQ client libraries.
- On Compaq OpenVMS Alpha, Compaq NonStop Kernel, Unix systems, and Windows
use the standard trigger monitor, runmqtrm. The standard trigger monitor can be used
for CICS transactions also.
• It is possible to write your own trigger monitor to work in different ways to the ones supplied
or to handle different application types.
Trigger Monitor Errors
• Messages are produced by the following
− Normal activities, for example,
Trigger monitor started
Waiting for a trigger message
Trigger monitor ended
− Abnormal conditions, for example,
Initiation queue could not be opened
Use of trigger monitor not authorized
Error starting triggered application
• A message may be written to:
− The standard output device
− An error log
• A trigger message is written to the dead letter queue if, for example:
− The trigger message structure is not valid
− The trigger message specifies an unsupported application type
− The trigger monitor is unable to start the specified application
3.3 WebSphere MQ Publish/Subscribe
This topic explains how WebSphere MQ Publish/Subscribe can be implemented and
managed.
WebSphere MQ Publish/Subscribe is supported on WebSphere MQ for AIX, HP-UX,
iSeries™, Linux, Windows, and Solaris, at Version 6.
WebSphere MQ Publish/Subscribe
Figure 3-16. WebSphere MQ Publish/Subscribe
WebSphere MQ Publish/Subscribe releases applications from having to know anything

about target applications. Essentially, a sending application sends information (publish) to a
standard destination that is managed by WebSphere MQ Publish/Subscribe. The distribution
is handled by Publish/Subscribe.
The receiving application also need only subscribe to a standard location, registering
interest and then await the delivery of the information.
WebSphere MQ messages are the vehicle used to transport the information between
publishers and subscribers. The subject of that information is called a topic. A publishing
application would specify a topic when it sends a message. The subscriber application
identifies the topics it is interested in. Only information that matches the subscriber's topics
will be sent.
Obviously, there is a requirement for a middleman to handle the proper routing of
information. This is handled by a broker.
Topics that are related can be grouped into streams; allowing for fewer total items that
the broker needs to manage. It also makes access control simpler. If topic does not belong to
a particular stream, the broker has a default stream.
An example such as the one above is fairly simple. In this basic configuration, depicting
a news service, a single stream can be made up of several kinds of information:
• Publisher 1 is publishing data about sports results (Topic:Sport)
• Publisher 2 is publishing data about stock prices (Topic:Stock)
• Publisher 3 is publishing data about film reviews (Topic:Films)
At the bottom, three subscribers have indicated their interest in different topics:
• Subscriber 1 will get information about sports results and stock prices
• Subscriber 2 will get film review information
• Subscriber 3 will receive the sports results
Broker configurations can become very complex with many brokers in a network.
However - only one broker is allowed per queue manager.
A broker network must be arranged as a hierarchy with the top broker being the root
broker. It will have one or more child brokers and is known as a parent broker. The child
brokers may also have child brokers forming the hierarchy. This eases the number of
channels required in the network.
Brokers can exchange subscription registrations and deregistrations, publications and
requests to delete publications as well as information about themselves. The broker is known
by the same name as the local queue manager.
Publishers and subscribers can reside anywhere in an WebSphere MQ network as
long as there is a route from their queue manager to the broker.
Setting Up the Broker

• Brokers run on WebSphere MQ for AIX, HP-UX, iSeries, Linux, Windows, and Solaris, at
Version 6
• Queues for each broker automatically defined when broker starts if they do not exist
− SYSTEM.BROKER.CONTROL.QUEUE
− SYSTEM.BROKER.DEFAULT.STREAM
− SYSTEM.BROKER.ADMIN.STREAM
− SYSTEM.BROKER.MODEL.STREAM
− SYSTEM.BROKER...
Created by the broker for internal use
• Authorize applications to use these queues
• Update configuration information
• In qm.ini or broker page of queue manager properties in MQ Explorer, depending on
platform
Streams offer a way to consolidate the various topics to make them more manageable.
Streams are implemented as sets of queues, one at each broker that supports the
particular stream. The queue at each broker for a specific stream will have the same name.
All brokers will have a default stream, using a queue called
SYSTEM.BROKER.DEFAULT.STREAM. This queue receives all publication messages for
the default stream. Administrators can create streams by setting up a series of local queues
(one on each broker) with the same name. However, streams beginning with
SYSTEM.BROKER. are reserved for WebSphere MQ use.
Each broker also has a control queue (SYSTEM.BROKER.CONTROL.QUEUE) where
all command messages are sent (everything except publications and requests to delete
publications). It is a predefined queue that takes its properties from the
SYSTEM.DEFAULT.LOCAL.QUEUE.
The SYSTEM.BROKER.ADMIN.STREAM queue is used by the broker to publish its
own configuration information. It is possible to write an administration application that can use
the information published on this stream.
Normal WebSphere MQ access control techniques apply to applications and brokers
opening queues for Publish/Subscribe messages. There is no topic based security; the
access check is for the stream.
Updates must be made to the queue manager configuration to enable Publish/Subscribe.
The User's Guide outlines the defaults and what each of the entries mean.
Controlling the Broker
Although the broker exists once the WebSphere MQ Publish/Subscribe is installed on a

queue manager and the configuration work is done, it needs to be started, displayed,
stopped, and so forth, using control commands.
The format of each control command is described in detail in the WebSphere MQ
Publish/Subscribe User's Guide. It is important to remember that the brokers run within the
realm of a queue manager so you must specify the queue manager it is associated with,
unless it is the default queue manager.
The endmqbrk command allows for controlled or immediate shutdown. There is no
preemptive shutdown as exists for queue managers. All control information is retained and
registrations for publishers and subscribers remain in force. Messages are simply queued for
the broker until it is restarted.
Displaying the broker allows you to see its status. The following are the potential
values that will be returned:
• Starting
• Running
• Stopping (immediate shutdown)
• Quiescing (controlled shutdown)
• Not active
• Ended abnormally
To delete a broker, it must be stopped and the queue manager must be active. In a
complex structure of brokers, it would be dangerous to delete a broker as it may be higher up
in the hierarchy than others. Therefore, the delete will fail with an error message if this is the
case.
If a delete is issued, the broker:
• Put-inhibits its input queues (SYSTEM.BROKER.CONTROL.QUEUE and all stream
queues)
• Deregisters all of its subscribers and publishers
• Sends DELETE PUBLICATION commands to its parent for any metatopics
• Deregisters all of its subscriptions with the parent
• Processes any messages on its input queues according to the MQMD Report Options
• Deletes internal queues (purging any messages)
• Deletes any empty input queues that were created by the broker
• Terminates
The clear command (clrmqbrk) clears the broker's memory of a neighboring target
broker. It will cancel all subscriptions from the target broker. This can only be done when the
broker is stopped. This operation would be required on both sides in order to stop messages
from flowing.
The final command (migmqbrk) is used to migrate WebSphere MQ Publish/Subscribe
broker to an WebSphere MQ Integrator broker. This command is only supported on platforms
that supported WebSphere MQ Integrator V2.0 and above. Migration exports the following
state to a replacement WebSphere MQ Integrator broker. The broker must reside on the
same queue managers the Publish/Subscribe broker. Please read about planning for
migration and integration before deciding to migrate.
Message Broker Exits

• Allow customization of publications at broker
− Can alter publication and MQMD
• Configured in qm.ini or broker page of queue manager properties in MQ Explorer
• Sample exit provided
− Changes destination queue or queue manager
The message broker exit permits customization of a publication at the broker; for instance,
causing traffic for different streams to be sent across different channels.
The exit is invoked after the broker determines that it sends a publication to a specific
broker or subscriber. The exit can change MQMD values as well as the publication
information itself.
The exit must be set up as part of the queue manager configuration.
A parameter block is used for input/output. It contains information related to the
invocation of the exit as well as results of its invocation. It is possible to issue MQI calls in the
exit with some restrictions (for example, never use MQDISC).
One of the sample programs provided with the WebSphere MQ Publish/Subscribe is a
routing exit program. It might be useful to understand its operation before attempting to
develop other exits.
Unit 3 Checkpoint
1. T/F The name of the application to be started in triggering is contained in the TRIGDATA
property of the application queue.
2. A temporary dynamic queue can store:
a. Nonpersistent messages only.
b. Both persistent and non-persistent messages.
c. Reply messages only.
d. Report messages only.
3. When an application issues an MQPUT of a message and explicitly sets priority to a 9,
which of the following best describes the results?
a. The message will be always be delivered before any lower priority messages.
b. The sequence of delivery for messages is always FIFO so it will be delivered in that
order, regardless of priority.
c. It is possible that this message may be delivered after other messages of lower
priority.
4. T/F If a problem is encountered while using the WebSphere MQ Publish/Subscribe
function, it is eligible for support even though it was downloaded and not shipped with the
product.
5. Which of the following are valid control commands for controlling a broker? (Choose 2)
a. rcrmqbrk
b. dspmqbrk
c. crtmqbrk
d. strmqbrk
Unit Summary
• The MQI
− The major calls
MQCONN and MQDISC
MQOPEN and MQCLOSE
MQPUT and MQGET
− Some of the more common parameters, fields, and options
− Message group and message segmentation
− Distribution list
• Triggering
− Focus on administration tasks
• Publish/subscribe enables applications to get at data without knowing the source or
destination of it
Practical session 2
The message queue interface (MQI) is the API used in applications to call on the
queue manager and its resources to perform work (putting messages on queues, getting
messages from queues, changing queue attributes).
Use of message-driven processing enables the starting of applications as they are
needed, alleviating the requirement to manually start them. This is accomplished through the
use of triggering.
The WebSphere MQ Publish/Subscribe function allows decoupling of information
providers from information recipients. The delivery of any information is handled by a network
of brokers.
Unit 4. Robust Messaging

This unit contains an overview of how WebSphere MQ is structured and describes how this
knowledge can be used to solve several types of problems. The steps to ensure the recovery
of messages are also described.

• Determine the state of a queue manager and demonstrate how to recover from a problem
• Design procedures to recover messages in the event of a failure
• Describe where to look for error messages and other information which may help to identify
the cause of a problem
• Start and stop WebSphere MQ tracing function

Accountability:
References
Unit Objectives
• Explain WebSphere MQ architecture and framework at a high level
• Describe problem determination aids and how to use them
• Define message persistence
• Detail logging options on various queue managers
• Explain the purpose of transactional processing
• Contrast local and global units of work
• List external transaction managers and where supported
After completing this unit, you should have the ability to describe how to determine the state
of a queue manager as well as how to recover from problems by using the logs.
Determining what type of logging is most beneficial will be covered.
Error messages are an important part of problem determination. You can learn how to find
error messages as well as what other debug facilities are available (such as trace).
Syncpoint control has an impact on logging; its use should be reviewed as well as looking at
the additional functional abilities of Version 6 queue managers with respect to global units of
work.
4.1 Architecture
This topic contains an outline of the WebSphere MQ reference architecture which
forms the basis of the implementation of the Version 5 and Version 6 queue managers. It is
included in order to help you understand certain aspects of problem determination.
Functional View
Figure 4-1. Functional View
• The visual depicts the functional architecture which applies to Version 5 and Version 6
queue managers. There are three main areas:
- A local queue manager (LQM) that manages the physical queues. Its main interface
is the MQI.
- Some components that are applications that use the local queue manager.
- Some underlying services.
• MQSeries for Compaq NonStop Kernel uses substantially the same code as the remaining
Version 5 queue managers, but there are some internal architectural differences in order to
integrate well with the NonStop Kernel operating system. Use is made of TS/MP
(PATHWAY), for example.
Physical View
On MQSeries for Compaq NonStop Kernel, the internal structure is different in some
ways to that depicted on the visual. Each queue manager runs under its own TS/MP
(PATHWAY) configuration. Execution controller and local queue manager (LQM) agent
processes exist, but there is no logger or checkpoint processor. Instead, logging and recovery
function is provided by TM/MP (TMF).
The NonStop Kernel operating system does not support the use of shared memory,
and so the queue manager uses hard disk where necessary.
Figure 4-2. Physical View
Processes
Figure 4-3. Processes
• There is one local queue manager agent for each connected application. However, on
WebSphere MQ for Windows which uses threads internally, a local queue manager agent can
typically support tens of applications.
• WebSphere MQ for Windows also have shared memory server processes. There are two
processes per queue manager and one per system. The name of the executable on
WebSphere MQ for Windows it is AMQXSSVN.EXE.
• There may also be a trace process on WebSphere MQ for Windows. The name of the
executable is AMQZTRCN.EXE.
Directory Structure
Figure 4-4. Directory Structure
• The path to the queue manager directory is formed as follows.

Prefix The default prefix for each queue manager is as follows.
- /var/mqm/ on WebSphere MQ on UNIX systems.
- \ProgramFiles\IBM\WebSphere MQ on WebSphere MQ for Windows Systems
Literal qmgrs
Queue manager name
The queue manager name or, if necessary, the queue manager name transformed to a
valid directory name.
• There is no simple relationship between the name of a queue or a process object and a
name in the file system. You can use the control command dspmqfls to determine the
mapping between the name of an WebSphere MQ object and a name in the file system.
• MQSeries for Compaq NonStop Kernel does not use this directory structure. Files for
MQSeries for Compaq NSK are distributed over several subvolumes. The volume in which
these subvolumes reside is selected when you create the queue manager: it is either taken
from the default volume value in MQSINI or specified on the –p DefaultPrefix parameter of the
crtmqm command.
There are five subvolumes per queue manager. The contents of the subvolumes are
determined by the final character of the subvolume name. For example, for a queue manager
called QMGR resident on a volume $DATA, the following subvolumes would be present:
$DATA.QMGR FFST subvolume
$DATA.QMGRD Queue manager data files subvolume
$DATA.QMGRL Queue manager error logs subvolume
$DATA.QMGRM Message queue subvolume
$DATA.QMGRS Channel synchronization subvolume
If necessary, the queue manager name is transformed or shortened in order to form a
valid subvolume name.
Configuration Files
• Purpose
− To define values for individual queue managers and for WebSphere MQ as a whole
− To tailor a specific queue manager
• Mechanism
− Configuration files containing human readable information
• Creation
− During installation and queue manager creation
• Modification
− By commands
− For specific purposes, by editing
• Recommendation
− Back up after significant changes
Notes:
• The WebSphere MQ configuration file is used to find a queue manager, to specify system
wide default values, and to identify the default queue manager on a system. It is created
during the installation of WebSphere MQ.
• A queue manager configuration file specifies values used by an individual queue manager. It
is created when the queue manager is created.
• WebSphere MQ for Windows is different from the other V6 queue managers in that the
configuration information is in the Windows Registry. However, changes are made to that
information through the MQ Explorer or by using the amqmdain command.
• More information about the contents of the configuration files can be found in the following
publications.
- WebSphere MQ System Administration Guide for a Version 6 queue manager.
- The appropriate System Management Guide for each of the remaining queue
managers.
- WebSphere MQ Intercommunication.
WebSphere MQ Configuration File
Figure 4-4. WebSphere MQ Configuration File
The WebSphere MQ configuration file is created when WebSphere MQ is installed. It

has the name mqs.ini on all non-Windows platforms except on Compaq NonStopKernel
where its name is MQSINI.
By default, the WebSphere MQ configuration file is located as follows.
• In the $SYSTEM.ZMQSSYS subvolume on Compaq NonStopKernell.
• In the /var/mqm/ directory on UNIX systems.
The information in WebSphere MQ Windows is contained in the Windows Registry.
MQS.INI Configuration File
Figure 4-5. MQS.INI Configuration File
Queue Manager Configuration File
Figure 4-6. Queue Manager Configuration File

• On WebSphere MQ for Windows the queue manager configuration information is stored in
the Windows Registry
• On MQSeries for Compaq NonStop Kernel, the queue manager configuration file is called
QMINI and is located in the queue manager data files subvolume, that is, the subvolume
whose name has the suffix 'D'. For example, if the queue manager name is QMGR and the
name of its home volume is $DATA, QMINI would be located in the subvolume
$DATA.QMGRD.
• The Service and ServiceComponent stanzas indicate that the queue manager has an
authorization service component installed and provide certain details about it.
• The Log stanza specifies the log configuration for the queue manager. A queue manager
configuration file may also contain the following stanzas.
Channels This stanza specifies values relating to the operation of channels such as the
maximum number of channels that can be active at any one time.
LU62, NETBIOS, TCP, SPX
These stanzas contain configuration parameters relating to their respective communications
protocols.
On MQSeries for Compaq NonStop Kernel, QMINI has a stanza called
TCPConfig containing similar information relating to TCP/IP. There is no equivalent stanza
for SNA LU6.2.
XAResourceManager
This stanza identifies an XA compliant resource manager, such as a data base manager, for
which the queue manager can act as a syncpoint coordinator. This function is only supported
by a Version 5 queue manager.
MQSeries for Compaq NonStop Kernel has many more stanzas which are unique to
MQSeries on this platform. These are mainly concerned with the internal configuration and
process structure of the queue manager. Refer to MQSeries for Compaq NonStop Kernel
System Administration for full details.
QM.INI Configuration File

WebSphere MQ configuration file, qm.ini, contains information relevant to all the specific
queue managers. There is one queue manager configuration file for each queue manager.
The qm.ini file is automatically created when the queue manager with which it is associated is
created.
A qm.ini file is held in the root of the directory tree occupied by the queue manager. For
example, the path and the name for a configuration file for a queue manager called QMNAME
is:
/var/mqm/qmgrs/QMNAME/qm.ini
The queue manager name can be up to 48 characters in length. However, this does not
guarantee that the name is valid or unique. Therefore, a directory name is generated based
on the queue manager name. This process is known as name transformation.
Figure 4-7. QM.INI Configuration File
Installable Services
• Formal interfaces, more than exits
• Multiple entry points
− For example:
Name Service
Initialize
Terminate
Insert
Delete
Lookup
• Service components can be chained
• WebSphere MQ System Administration
Notes:
• Service components can be chained. If one component cannot perform a requested
operation, the queue manager tries the next one.
• Installable services are described in WebSphere MQ System Administration Guide.
Installable Services and Supplied Components
Figure 4-8. Installable Services and Supplied Components
• The Name Service allows multiple queue managers to share specified queue definitions.
Given the name of a queue, the name service returns the name of the queue manager which
owns the queue. The name service is enabled by manually adding a service stanza to the
queue manager configuration file.
• The Authorization Service provides access control to queue manager resources. On
MQSeries for Compaq NonStop Kernel, WebSphere MQ on UNIX systems, and WebSphere
MQ for Windows, the supplied authorization service component is Object Authority Manager
(OAM).
When you create a queue manager, the service stanza to enable the authorization
service, and the service component stanza to identify the OAM to the queue manager, are
automatically added to the queue manager configuration file.
• By default, the OAM is enabled. It can be disabled by setting the environment variable
MQSNOAUT before the queue manager is created.
For MQSeries for Compaq NonStop Kernel, you set MQSNOAUT as follows.
PARAM MQSNOAUT 1
For WebSphere MQ on UNIX systems, you set MQSNOAUT as follows.
export MQSNOAUT=yes
For WebSphere MQ for Windows, you set MQSNOAUT as follows.
SET MQSNOAUT=yes
However, if you do set MQSNOAUT, you cannot in general reenable the OAM later.
You can also disable the OAM for testing purposes by removing the relevant service
component stanza from the queue manager configuration file.
Stopping a Queue Manager Manually
Figure 4-9. Stopping a Queue Manager Manually

If you ever need to stop a queue manager manually as a last resort, stop any residual
processes in the following order. The names of the executables depicted are typical of a UNIX
implementation.
amqzmuc0 Critical process manager
amqzxma0 Execution controller
amqfuma OAM process
amqzlaa0 LQM agents
amqzlsa0 LQM agents
amqzmur0 Restartable process manager
amqrmppa Process pooling process
amqrrmfa The repository process (for clusters)
amqzdmaa Deferred message processor
amqpcsea The command server
• On WebSphere MQ for Windows any residual shared memory processes, executables

AMQXSSV2.EXE and AMQXSSVN.EXE, respectively, should be stopped after the execution
controller has been stopped.
• On MQSeries for Compaq NonStop Kernel, the procedure is slightly different because of the
different internal process structure of the queue manager. Details can be found in MQSeries
for Compaq NonStop Kernel System Administration.
• On WebSphere MQ for Windows, if there is a residual trace process, executable
AMQZTRCN.EXE, it should be stopped after the local queue manager agents have been
stopped and before attempting to stop the execution controller.
Stopping a queue manager in WebSphere MQ for Windows
AMQZMUC0 Critical process manager
AMQZXMA0 Execution controller
AMQFUMA OAM process
AMQZLAA0 LQM agents
AMQZLSA0 LQM agents
AMQZMUR0 Restartable process manager
AMQRMPPA Process pooling process
AMQRRMFA The repository process (for clusters)
AMQZDMAA Deferred message processor
AMQPCSEA The command server
AMQXSSVN Shared memory servers
AMQZTRCN Trace
Removing a Queue Manager Manually
Figure 4-10. Removing a Queue Manager Manually
• If there are problems, perhaps related to errors on a test system, follow the steps given.
- Find the queue manager directory from the WebSphere MQ configuration file.
- Find the queue manager log directory from the queue manager configuration file.
- Delete the queue manager directory, all subdirectories, and files.
- Delete the queue manager log directory, all subdirectories and files
- Remove its stanza from the WebSphere MQ configuration file
- Remove or change the DefaultQueueManager stanza if the queue manager being
deleted is the default queue manager.
• The procedure is similar for all the queue managers, but there are minor differences.
The full procedure for each queue manager is documented in WebSphere MQ System
Administration Guide for a Version 5 or 6 queue manager and in the relevant System
Management Guide for each of the remaining queue managers.
4.2 Problem Determination
This topic describes aspects of problem determination.
Configuration Files and Problem

Determination
• Errors can stop a queue manager being found
− QUEUE MANAGER UNAVAILABLE
• What to check
− The configuration files exist
− They have the appropriate permissions
− The WebSphere MQ configuration file (or Windows Registry)
− references the queue manager with the correct information for
− locating its files
Error Messages
• "Normal" errors, including some by users
− Incorrect parameter on a control command
− NLS enabled
− Written to the associated terminal, if any, and to an error log file
• Error log file
− AMQERR01.LOG
− One in each of three error directories
− Two previous error log files are also kept
AMQERR02.LOG
AMQERR03.LOG
Notes:
• Error messages are written to the associated terminal, if any, and are written to an error log
file with additional information.
• Error messages are only written to an error log file called AMQERR01.LOG. There is an
separate error log file with this name in each of three error directories. Which of these
directories is used for a specific error message depends on the information available to
WebSphere MQ at the time the error occurs.
• When the error log file AMQERR01.LOG fills up, its contents are copied to
AMQERR02.LOG and AMQERR01.LOG is then reused. Before the copy, AMQERR02.LOG
is copied to AMQERR03.LOG. The previous contents of AMQERR03.LOG, if any, are
discarded. In this way, AMQERR02.LOG and AMQERR03.LOG are used to maintain a
history of error messages.
• On MQSeries for Compaq NonStop Kernel, the corresponding error log files are called
MQERRLG1, MQERRLG2, and MQERRLG3.
First Failure Support Technology (FFST)
• "Unexpected" errors
− Internal queue manager failure
But not automatically an APAR
− May have associated storage dumps
− Data to help analyze software events
• If an error occurs:
− Note a description of the problem
− Look for any related error log entries
− Identify any FFST reports
• WebSphere MQ uses FFST as follows:

- To detect and report software events, for example, internal queue manager failures.
- To collect information about software events, for example, dumps of storage.
- To generate data to help analyze software events, for example, probe IDs.
• Each FFST report contains various items of useful information.
- A probe ID which identifies where in the code the error was detected.
- The date and time the error occurred.
- Any associated error message.
- A variable number of dumps including the function stack and trace history.
• If you experience frequent FFST reports related to shared memory on a UNIX system, it
may mean that you need to change the values of certain kernel parameters in order to
support WebSphere MQ. For more details on which kernel parameters may need changing,
refer to WebSphere MQ for HP-UX, Sun Solaris, or AIX Quick Beginnings, or the relevant
System Management Guide for each of the remaining queue managers on UNIX systems.
Trace
• Extra information may be needed to find a problem
− Files can be very large
− Can be limited by time or component
• Can also trace the MQI
− Useful aid to application debugging
• For details on how to produce a trace:
− WebSphere MQ System Administration for a Version 5 or 6 queue manager
− The relevant System Management Guide for each of the remaining queue managers
strmqtrc - start a trace
endmqtrc - end a trace
Trace on WebSphere MQ for Solaris
Figure 4-11. Trace on WebSphere MQ for Solaris
Trace output is unformatted on UNIX systems; use the dspmqtrc control command to
format trace output before viewing. For example, to format all trace files in the current
directory use the following command:
dspmqtrc *.TRC
4.3 Transactions and Recovery
This topic describes logging in WebSphere MQ and how messages and WebSphere
MQ objects can be recovered in the event of a failure. It also describes the transactional
support within WebSphere MQ.
Message Persistence
Figure 4-12. Message Persistence
• Persistent messages are never lost as a result of a system failure, or as a result of a

communications failure when they are being transmitted from one queue manager to another.
In order to achieve this, persistent messages are written out to a log. When a queue manager
is restarted following a system failure, it recovers persistent messages as necessary from the
logged data.
• Nonpersistent messages can be used for better performance when it is not critical for
messages to be able to survive a queue manager restart.
• Both persistent and nonpersistent messages may be stored on the same queue. The only
exception to this is a temporary dynamic queue which can only store nonpersistent
messages.
Types of Log
Figure 4-13. Types of Log
• WebSphere MQ records all significant changes to the data controlled by the queue manager
in a recovery log. This includes creating and deleting objects, persistent message updates,
transaction states, changes to object attributes, and channel activities. The log contains the
information you need to recover all updates to message queues by:
- Keeping records of queue manager changes
- Keeping records of queue updates for use by the restart process
- Enabling you to restore data after a hardware or software failure
• Unless you request linear logging when you create a queue manager, circular logging is
provided by default.
• Circular logging is able to recover messages following a system failure but is unable to
recover following a media failure. It has the advantage that the amount of disk space required
for the log does not increase with time.
• A linear log can recover from a media failure but it requires inactive log files to be archived
on a regular basis.
• Periodically, the queue manager performs a log checkpoint. Information about the last
checkpoint, including its location in the log, is held in the checkpoint file, amqalchk.fil.
Recovering Persistent Messages
• If necessary, persistent messages are recovered automatically when the queue manager
is restarted
• A damaged local queue may only be detected later
− Reported as "object damaged"
− Normally needs to be recovered manually
• In order to restart, a queue manager only requires:
− Log records written since the last checkpoint
− Log records written by transactions that were still active at the time the queue
manager stopped
The queue manager recovers any damaged object that would prevent it from starting,
but this would not normally include a local queue which is damaged. Such a queue may only
be detected later when an attempt is made to access it.
In order to restart, a queue manager only requires the following:
• Log records written since the last checkpoint.
• Log records written by transactions which were still active at the time the queue manager
stopped. Uncommitted persistent messages, put or got inside these transactions, are rolled
back during restart. Hence, recovery can be quite quick.
Damaged Objects and Media Recovery

• WebSphere MQ objects can be marked as damaged
− Corrupt data in the queue file
− Missing queue file
− Disk failure
• Damaged objects can be deleted
• A damaged object can be re-created from a LINEAR log
− Known as media recovery
− Media images of some objects are recorded automatically by the queue manager at
certain times
− Record the media image of a local queue on a regular basis using the control
command rcdmqimg
• Media recovery
− Automatic if a damaged object is detected during restart
− For a local queue, it is normally done by using the control command rcrmqobj
Notes:
• The control command to record a media image is rcdmqimg. For example, the following
command will record a media image of a local queue.
rcdmqimg -m QMgrName -t qlocal QName
• A damaged object can be re-created by using the rcrmqobj control command. For example,
the following command will recreate a local queue.
rcrmqobj -m QMgrName -t qlocal QName
Dumping the Log
• Use dmpmqlog to dump a formatted version of the log
• Queue manager must not be running
• By default, the dump commences from the head of the log.
Optionally, the dump can commence from:
− The base of the log
− A log record identified by a specified log sequence number (LSN)
− A log file identified by a specified extent number (linear logs only)
• Log records formatted include:
− Put and get of persistent messages
− Transaction events
− Creation, alteration, and deletion of WebSphere MQ objects
• Version 5 or 6 queue managers only
Notes:
• The head of the log is the checkpoint that commences the active portion of the log.
Normally, this would be the most recent checkpoint. However, the head of the log may be
positioned at an earlier checkpoint if there were transactions that were still active when the
queue manager stopped and there are uncommitted persistent messages that were put or got
inside these transactions prior to the most recent checkpoint.
• The base of the log is the first log record in the log file containing the head of the log.
• Each log record is identified by a unique log sequence number (LSN).
• Each log file has a file name of the form Snnnnnnn.LOG, where nnnnnnn is the extent
number.
• Full details, including a sample dump with notes, can be found in WebSphere MQ System
Administration Guide.
• The dmpmqlog control command is only supported on a Version 5 or 6 queue manager.
Syncpoint Control
Figure 4-14. Syncpoint Control

Notes:
• An application can specify whether an MQPUT call or an MQGET call is within, or outside of,
syncpoint control or leave it as the default. But take care, the default is platform-dependent.
• Note a special case. An application can get a message it has just put in the same unit of
work.
Compensating Transactions
Figure 4-15. Compensating Transactions

Local syncpoint coordinates messages with data base updates on that system. But the actual
processing of the message may take place on a different system, or at a later time.
When a message is processed later, the application may find an error, in the database, that
prevents the message from being processed. It is too late to roll back the original unit of work.
The answer is to include compensating transactions which send messages to reverse the
original request. Some examples are illustrated.
Coordinating Local Units of Work

• The calls MQCMIT and MQBACK are supported on all Version 5 and 6 queue managers
except MQSeries for Compaq NonStop Kernel.
• On MQSeries for Compaq NonStop Kernel, TM/MP (TMF) is used to coordinate local units
of work. Instead of using the calls MQCMIT and MQBACK, an application making changes to
WebSphere MQ resources within syncpoint control uses the calls BEGINTRANSACTION,
ENDTRANSACTION, and ABORTTRANSACTION.
• A WebSphere MQ client application might also use the MQCMIT and MQBACK calls.
Figure 4-16. Coordinating Local Units of Work
Internal Coordination of Global Units of Work

Internal coordination of global units of work is only supported by certain Version 5 or 6
queue managers. Using the X/Open XA interface, with a two-phase commit protocol, a
Version 5 or 6 queue manager is able to coordinate changes to its own resources and to
those of other resource managers within a unit of work. An external syncpoint coordinator is
not required under these circumstances.
Figure 4-17. Internal Coordination of Global Units of Work

Database Coordination
Figure 4-18. Database Coordination
The visual depicts the XA-compliant database managers that are supported by the
Version 6 queue managers. These database managers may participate in a global unit of
work coordinated by WebSphere MQ.
The visual also lists some restrictions regarding the internal coordination of global units of
work.
• A WebSphere MQ client application cannot participate in a global unit of work and cannot
therefore issue the MQBEGIN call.
• Although a queue manager may be XA-compliant, both as a syncpoint coordinator and as a
resource manager, it is not possible to configure two or more queue managers as participants
in a global unit of work. This is because an application may only be connected to one queue
manager at a time.
• Normally, updates to WebSphere MQ resources and to those of a data base manager must
be made on the same system. WebSphere MQ does not have the capability to coordinate a
distributed unit of work.
• However, a database manager may reside on a different system to the queue manager
provided it can supply an XA compliant client feature which resides on the same system as
the queue manager.
External Coordination of Global Units of Work
Figure 4-19. External Coordination of Global Units of Work

• The external syncpoint coordinators listed on the visual use the X/Open XA interface for
coordinating changes to WebSphere MQ resources and to those of other resource managers.
• An WebSphere MQ client application can only participate in a global unit of work using the
WebSphere MQ extended transactional client and an external syncpoint coordinator. The
extended transactional client is supported on AIX, HP-UX, Linux (on x86 and zSeries
platforms), Solaris and Windows.
• There are no supported external syncpoint coordinators for MQSeries for Compaq
OpenVMS.
• WebSphere Application Server is supported on WebSphere MQ V5.2 and later release. As
this list occasionally changes, you should check the following url for the latest information:
http://www.ibm.com/software/integration/wmq/support/
CICS Transactions
• A CICS transaction may issue MQI calls
• A CICS trigger monitor can start a CICS transaction when a message arrives on a queue
− AIX, HP-UX, Solaris and Windows
• Only one queue manager can be accessed at a time from a single CICS region
− Using CICS with a two-phase commit protocol
On AIX, HP-UX, Solaris, and Windows, there is a supplied trigger monitor which runs
as a CICS transaction. The process object specifies which transaction to start.
APPLTYPE CICS
APPLICID Transaction ID
The trigger monitor performs EXEC CICS START and passes MQTMC2 as CICS data.
If the trigger monitor is started without data, it gets the trigger messages from
SYSTEM.CICS.INITIATION.QUEUE.
Unit 4 Checkpoint
1. The two types of logging supported on HP-UX are:

a. journaling
b. linear
c. circular
d. checkpointing
2. A queue manager has just failed. The most recent errors within the queue manager's
directory are contained in a file called:
a. QMGRERR
b. ERRORS
c. AMQERR01.LOG
d. AMQERR.001
3. T/F Non-persistent messages will only be recovered if they were part of a unit of work when
the queue manager failed.
4. What type of log can a damaged object be re-created from?
a. circular
b. journal receiver
c. linear
d. queue manager log
Unit Summary
• Architecture
• Problem determination
• Message persistence, logging, and recovery
• Transactional support
Exercise 3
WebSphere MQ has some robust recovery and logging facilities. It is very important to
plan ahead and decide what type of logging suits your needs where a choice is involved. As
the administrator, you may be called upon to explain the impact of syncpointing and using
non-persistent messages may have.
Unit 5. Distributed Queue Management

This unit describes various aspects of distributed queue management.
• Configuring WebSphere MQ for distributed queuing
• Application data conversion
• Remote administration
• Handling exceptions

• Given a WebSphere MQ network, demonstrate how to create the required WebSphere MQ
objects
• Given network design goals, select the appropriate channel configuration
• Given a scenario containing alias queues, local definitions of remote queues, reply-to queue
aliases, and queue manager aliases, predict the final destination of a message
• Configure TCP/IP to enable its use by WebSphere MQ and identify where the configuration
of other communications protocols is described
• Distinguish between the various ways of starting and stopping a message channel
• Describe how to start and stop a message channel
• Determine the state of a message channel
• Given an error on a message channel, determine the possible cause
• Give examples of the steps that can be taken to find a message that has not arrived on its
intended destination queue
• List the considerations when writing a data conversion exit
• Explain how a remote queue manager's resources can be monitored and changed using the
administration features of WebSphere MQ
• Describe queue manager clusters
• Configure a simple cluster of queue managers

Accountability:
References
SC34-6587 WebSphere MQ Intercommunication
SC34-6061 WebSphere MQ Queue Manager Clusters
Unit Objectives
• Learn how to configure WebSphere MQ channels
• Define other required objects for distributed queuing
• Explain how to start and stop channels
• Describe steps necessary to determine source of channel problems
• List considerations for data conversion
• Describe instrumentation events and their use
• Explain dead letter queues and their use
• Implement a configuration that uses dynamic workload
• management - CLUSTERS
This unit is, perhaps, one of the most important in the entire course. Channel
configuration and operations can be confusing. Once you have completed this unit and the
practical exercise, you will have a better idea of what is involved.
With additional practice and use when you return to your job, you can find that they are
not as difficult as they appear.
5.1 Configuration for Distributed Queuing
This topic describes how to configure WebSphere MQ in order to enable one queue manager
to exchange messages with another.
Identifying a Queue in the MQI

• A queue is identified by:
− The name of the queue
− The name of the queue manager which owns the queue
• A queue may be referenced in two places
− Object descriptor, on an MQOPEN or MQPUT1 call
o ObjectName
o ObjectQMgrName
− Message descriptor, to specify a reply-to queue
o ReplyToQ
o ReplyToQMgr
• In an object descriptor, if ObjectQMgrName is blank, the queue with the name specified in
ObjectName must be defined in one of the following places
− The local queue manager
− The name service
Assured Delivery
Figure 5-1. Assured Delivery

Whether an application is putting a message on a local queue or to a remote queue is
transparent to the application. However, an application always gets a message from a local
queue.
Queue Definitions for Distributed Queuing
Figure 5-2. Queue Definitions for Distributed Queuing

As a general rule, give a transmission queue the same name as the remote queue manager.
Message Channel Combinations
Figure 5-3. Message Channel Combinations
• WebSphere MQ Intercommunication explains the possible combinations in more detail.

• A sender can initiate a communications connection with a receiver and then send messages
to it. This is the most common combination. A fully defined server may also perform the same
role as a sender in this combination.
• A requester can initiate a communications connection with a server which then sends
messages to the same requester.
• A requester can initiate a communications connection with a sender which promptly
terminates the connection. The sender then starts a communications connection according to
the information in its channel definition and sends messages to the partner it has started. This
combination is known as callback.
Attributes of a Message Channel
Figure 5-4. Attributes of a Message Channel

• The WebSphere MQ command to define a message channel at one end is DEFINE
CHANNEL. Related commands are ALTER CHANNEL, DISPLAY CHANNEL, and DELETE
CHANNEL.
• Attributes not supplied on the DEFINE CHANNEL command are taken from the appropriate
default channel object.
- SYSTEM.DEF.SENDER
- SYSTEM.DEF.RECEIVER
- SYSTEM.DEF.SERVER
- SYSTEM.DEF.REQUESTER
• CHLTYPE must be included as the first parameter on both the DEFINE CHANNEL and
ALTER CHANNEL commands.
• TRPTYPE is a required parameter on the DEFINE CHANNEL command on all queue
managers prior to Version 5. On a Version 5 or 6 queue manager, if TRPTYPE is not
specified, the value is taken from the appropriate default channel object.
Example
Figure 5-5. Example

• Each message channel has a two channel definitions, one at each end.
• In the example, the sending end of each channel has a transmission queue with the same
name as the queue manager at the other end of the channel.
Choosing a Transmission Queue
Figure 5-6. Choosing a Transmission Queue
Configuring TCP/IP for WebSphere MQ
Figure 5-7. Configuring TCP/IP for WebSphere MQ
• The inet daemon, inetd, is available for TCP/IP on UNIX and on Linux. It has to be
configured for WebSphere MQ.
- Change the two files as shown, adjusting path names as appropriate.
- The inet daemon then has to be refreshed. On AIX, issue:
refresh -s inetd
• On the remaining UNIX systems, the procedure to configure TCP/IP is very similar to that on
AIX with only minor differences.
• On Windows, no inet daemon is supplied and so the WebSphere MQ listener must be used
nstead.
• The WebSphere MQ listener, runmqlsr, is available on other queue managers. On
WebSphere MQ for Windows, you can use the listener for all the supported communications
protocols. For NetBIOS, IPX/SPX, and TCP/IP, it is the only option available. On the
WebSphere MQ UNIX platforms, runmqlsr is also available.
On MQSeries for Compaq OpenVMS, it is available for use with SNA LU6.2 only and, on
MQSeries for Compaq NonStop Kernel, it is available for use with TCP/IP only.
• On MQSeries for Compaq NonStop Kernel, as an alternative to using the WebSphere MQ
listener, you may configure a TCP/IP listener in its own TS/MP server class and start it by
using the PATHCOM commands THAW SERVER and START SERVER. By default, one
listener is configured in server class MQS-TCPLIS00. If you need an additional listener, you
can configure it in its own server class using MQS-TCPLIS00 as a template. Full details of
this option can be found in the MQSeries for Compaq NonStop Kernel System Management
Guide.
• The WebSphere MQ command START LISTENER can also be used to start the
WebSphere MQ listener. On iSeries, UNIX Systems and Windows, this command is valid for
channels for which the TRPTYPE is TCP.
• WebSphere MQ Intercommunication contains full details on how to configure TCP/IP for
WebSphere MQ on all platforms except Compaq NonStop Kernel. For Compaq NonStop
Kernel consult the System Management Guide.
Starting a Message Channel
Figure 5-8. Starting a Message Channel

• Check the network first, for example, issue a TCP/IP ping.
• Use the WebSphere MQ command PING CHANNEL to test a message channel
configuration. It can only be used at the sender or server end of a channel, and only when the
channel is not started.
Channel Initiator
Figure 5-9. Channel Initiator
• The channel initiator is a special trigger monitor for starting a message channel. It also
contains retry logic for use in case of difficulty in starting a channel or after an error on a
channel. Neither the WebSphere MQ command START CHANNEL, nor the control command
runmqchl, contain any retry logic. Thus, you must use the channel initiator if you require this
function.
- For triggering a channel, the attributes ApplType and ApplId of a process object are
not required. Instead, the attribute UserData specifies the name of the channel to be
started.
- On a Version 5 or 6 queue manager, you do not need to define a process in order to
trigger a channel. Instead, the attribute TriggerData of the transmission queue
specifies the name of the channel to be started.
- If you do not specify a channel name at all, the channel initiator searches the channel
definitions until it finds a channel whose definition contains the name of the
transmission queue that has just caused the trigger event.
• On MQSeries for Compaq NonStop Kernel, as an alternative to using the control command
runmqchi, you may use the default channel initiator which is configured in the TS/MP server
class MQS-CHANINIT00 and start it by using the PATHCOM commands THAW SERVER
and START SERVER. Full details of this option can be found in the MQSeries for Compaq
NonStop Kernel System Management Guide. The WebSphere MQ command START CHINIT
is not supported on this queue manager.
• The channel control parameters shown on the visual can be specified on the DEFINE
CHANNEL command.
DISCINT (SDR and SVR)
Maximum time to wait for a message on the transmission queue if it is empty. If no message
arrives within this time, the channel closes down.
SHORTRTY, SHORTTMR(SDR and SVR)
Short retry count and short retry time interval to control repeated attempts to establish a
communications connection.
LONGRTY, LONGTMR(SDR and SVR)
Long retry count and long retry time interval to control further repeated attempts to establish a
communications connection.
MRRTY, MRTMR(RCVR and RQSTR)
Message-retry count and message-retry interval when attempting to put a message on a
destination queue. If every attempt fails, the MCA decides that it cannot deliver the message.
MCATYPE (SDR, SVR, and RQSTR)
The value of this parameter may be THREAD or PROCESS. If THREAD is specified, each
channel runs as a thread within the channel initiator process. If PROCESS is specified, each
channel runs as a separate process.
This parameter is only supported on AIX, HP OpenVMS, HP-UX, Linux, i5/OS, Solaris, and
Windows.
BATCHINT (SDR and SVR)
The period of time during which a channel will keep a batch open if there are no messages on
the transmission queue. This should be set to a value considerably less than the value of
DISCINT.
This parameter is only valid on AIX, HP OpenVMS, HP-UX, Linux, i5/OS, Solaris, Windows,
and z/OS.
Of the parameters listed, only the SHORTRTY, SHORTTMR, LONGRTY, LONGTMR, and
MCATYPE parameters are used by the channel initiator.
Channel States
Figure 5-10. Channel States
• The current state of a channel can be determined by using the WebSphere MQ command
DISPLAY CHSTATUS.
• The visual shows the possible states of a channel and the possible flows from one state to
the next.
When a channel is in one of the six highlighted states, it is consuming resource and is said to
be active.
START is not really a state. It simply indicates a start point for when the START CHANNEL
command has been issued, or when a transmission queue has been triggered, or when a
channel initiator has decided it is time for another retry attempt, or when there has been an
incoming request to start a channel.
INITIALISING
A channel initiator is attempting to start a channel. This state only occurs on a Version 5 or 6
queue manager, such as Sun Solaris.
STARTING
A channel waits in this state if there is no active slot available. If there is an active slot
immediately available, it remains in this state a very short time.
BINDING
Establishing a communications connection and performing the initial data exchange.
REQUESTING
A requester is waiting for callback from a sender.
RUNNING
Transferring messages, or waiting for messages to arrive on the transmission queue.
PAUSED
Waiting for the message-retry interval to complete before attempting to put a message on its
destination queue.
STOPPING
An error has occurred, or the STOP CHANNEL command has been issued, or the disconnect
interval has expired.
RETRYING
Waiting until it is time for the channel initiator to make the next attempt to start the channel.
STOPPED
In this state, the channel is disabled and needs manual intervention to start it again.
INACTIVE
An inactive channel is one that has never been started or has disconnected normally.
Queue Manager Alias
Figure 5-11. Queue Manager Alias

• The WebSphere MQ command DEFINE QREMOTE is used to define a queue manager
alias. The value of the RNAME parameter must be blank, which is the default value in any
case.
Separating Message Flows
Figure 5-12. Separating Message Flows
• On each queue manager, the normal transmission queue has the same name as the partner
queue manager.
• On queue manager QM1, a local definition of a remote queue specifies a alternative
transmission queue which can be used for sending messages to queue manager QM2.
• A reply-to queue alias is used to set the value of reply-to queue manager QM1A.
• There is also a queue manager alias definition which specifies QM1A as an alias of QM1.
These three definitions enable request messages to be separated into two flows between
queue managers QM1 and QM2, and enable the reply messages to be separated into two
flows in the reverse direction.
5.2 Administration in a Mixed Environment
This topic describes aspects of administering WebSphere MQ relating to its use in a
mixed network of queue managers.
• Application data conversion.
• Administration, with a particular emphasis on the concept of a "single point of control" in a
larger network.
• Detecting and reporting exceptions that require administrator attention.
Data Representation
• Messages in a heterogeneous network
− Character fields may need translation
− Numeric fields may need transformation
• Message descriptor accompanies every message
− Delivered to the receiving application
− Always converted by WebSphere MQ
• Application data
− Fields in the message descriptor describe the format and representation
− Data conversion support is available
Three Fields in the Message Descriptor
Requesting Application Data Conversion

• Request data conversion on the MQGET call
− MQGMO_CONVERT
− Encoding and CodedCharSetId
On input, requested representation of the message
On output, what the application actually receives
− Conversion performed, if necessary, on the basis of what is contained in the
Format field
− A warning, and the message returned in its original form, if the conversion
cannot be done
• Otherwise, request data conversion at the sending end of a message channel
− CONVERT(YES)
− Unconverted messages are put on the dead letter queue at the sending end
Notes:
• No application data conversion is performed by default; it must be requested. It may be
requested as follows.
- By using the MQGMO_CONVERT option on the MQGET call. This is the preferred
approach on a queue manager that supports application data conversion.
- By specifying the parameter CONVERT(YES) on the channel definition at the sending
end of a message channel. This is a useful option if the remote queue manager does
not support application data conversion.
• The preferred approach can be described as receiver makes good. The optimal situation is
for the application data in a message to be converted only once.
What Application Data Conversion Can Be Done?

• Some formats are built-in, and the data conversion is performed by a built-in conversion
routine
− A message consisting entirely of characters
− A message structure defined by WebSphere MQ
• A user written data conversion exit is required when:
− The format of a message is defined by the application, not by WebSphere MQ
− A message with a built-in format fails to convert
• There is a WebSphere MQ utility to help write a data conversion exit
Note: crtmqcvx is the utility to help write a conversion exit.
What Applications Should Do

• Put messages with the following values in the Encoding and CodedCharSetId fields
− MQENC_NATIVE - for native encoding
− MQCCSI_Q_MGR - for the same CCSID as the queue manager
• Put all messages with a format name
− MQFMT_STRING - for a message consisting entirely of characters
• Use the MQGMO_CONVERT option on the MQGET call
− Check what is delivered by the call
• If necessary, use CONVERT(YES) at the sending end of a message channel
Command Server
Figure 5-13. Command Server

Notes:
• Related control commands are as follows.
endmqcsv Ends the command server.
dspmqcsv Displays the status of the command server.
• On MQSeries for Compaq NonStop Kernel, as an alternative to using the control command
strmqcsv, you may use the command server which is configured in the TS/MP server class
MQS-CMDSERV00 and start it by using the PATHCOM commands THAW SERVER and
START SERVER. Full details of this option can be found in the MQSeries for Compaq
NonStop Kernel System Management Guide.
• WebSphere MQ for z/OS has a system-command input queue which is monitored by a
command server. However, the command server in WebSphere MQ for z/OS Version 5 only
accepts messages containing WebSphere MQ commands. PCF commands are now
supported by WebSphere MQ for z/OS Version 6.
Support for PCF Commands

• All queue managers have a command server which accepts PCF commands, except:
− WebSphere MQ for z/OS Version 5
• Administration utilities which issue PCF commands
− SupportPacs for WebSphere MQ for UNIX, Linux, and Windows
− Vendor products
− runmqsc -w (indirect mode)
• Applications using the WebSphere MQ Administration Interface
The Message Queuing Administration Interface is a programming interface to WebSphere

MQ that gives you an alternative to the MQI, for sending and receiving PCFs. The MQAI uses
data bags which allow you to handle properties (or parameters) of objects more easily than
using PCF messages.
The WebSphere MQ Programmable Command Formats and Administration Interface
describes these functions and their implementation in detail. MQAI is supported on all Version
6 queue managers, as well as MQSeries for Compaq NonStopKernel and WebSphere MQ for
HP OpenVMS Version 5.3.
Program Example
Figure 5-14. Program Example
The visual describes a utility to purge any queues that have existed beyond their retention
interval. A summary of the logic is as follows.
1. Put the MQCMD_INQUIRE_Q command on the command queue.
- The command may either specify the name of a queue or specify a generic queue
name in order to inquire about multiple queues.
- The command server responds for each queue that matches the request.
2. Get the response for each queue found. Each response contains the values of the following
attributes.
Qname
RetentionInterval
CreationDate
CreationTime
3. For each expired queue, put an MQCMD_DELETE_Q command on the command queue.
-The command server deletes the "expired" queues
Indirect Mode
Figure 5-15. Indirect Mode

Notes:
• The parameter -w WaitTime specifies the indirect mode of using runmqsc. The value of
WaitTime is the time in seconds that runmqsc should wait for replies.
• Using the indirect mode, you can send a WebSphere MQ command to any queue manager
with a command server which accepts PCF commands.
You can also send WebSphere MQ commands to a z/OS queue manager by using the
-x parameter in conjunction with the -w parameter.
Instrumentation Events
• Have a queue manager report a problem condition immediately
− Number of messages on a queue is increasing
− Get requests are inhibited for a queue
− Message channel has stopped
• Enabled events are reported as event messages on event queues
SYSTEM.ADMIN.QMGR.EVENT
SYSTEM.ADMIN.PERFM.EVENT
SYSTEM.ADMIN.CHANNEL.EVENT
SYSTEM.ADMIN.CONFIG.EVENT (z/OS only)
SYSTEM.ADMIN.COMMAND.EVENT (z/OS only)
SYSTEM.ADMIN.LOGGER.EVENT (not z/OS)
Notes:
• Instrumentation events are enabled by attributes. Threshold queue depths, like QDEPTHHI,
are specified as a percentage of MAXDEPTH.
DEFINE QLOCAL(X) MAXDEPTH(2000) QDEPTHHI(90) QDPHIEV(ENABLED) ALTER
QMGR PERFMEV(ENABLED)
• On MQSeries for Compaq NonStop Kernel, a queue manager may generate Event
Management Service (EMS) event messages that correspond to instrumentation events,
entries in the error logs, and FFST reports. The value of the PARAM MQEMSEVENTS
determines which EMS event messages are generated. By default, no EMS event messages
are generated. For more details, consult the MQSeries for Compaq NonStop Kernel System
Management Guide.
• Configuration and command events are available only on WebSphere MQ for z/OS. Logger
events are only available on the distributed Version 6 queue managers that support linear
logging.
Responding to an Instrumentation Event

• Queue manager events
− Enable a queue for put or get requests if it is not intentionally disabled
− Correct the authorizations for a queue, or stop unauthorized users trying to put
messages on the queue
• Performance events
− Start a process to clear the backlog of messages
− Suspend a process that is putting too many messages on a queue
• Channel events
− Restart a channel
− Process the dead letter queue
• Logger events
− Archive unneeded log files
Dead Letter Queue
Figure 5-16. Dead Letter Queue

• When a problem relating to a message is detected asynchronously, an exception report is
generated if one has been requested and the report is sent to the specified reply-to queue.
The Feedback field in the message descriptor of the report message indicates the reason for
the report. The original message is put on the dead letter queue unless
MQRO_DISCARD_MSG is requested as a report option.
• If a message cannot be delivered, it is put on the dead letter queue at the receiving end of a
message channel, if one is defined. Message-retry at the receiving end of a channel may be
useful if the problem is only temporary.
• If CONVERT(YES) is specified in the channel definition at the sending end of a message
channel and a message cannot be converted, the message is put on the dead letter queue at
the sending end.
If a message cannot be put on the dead letter queue, the channel is stopped and the
message remains on the transmission queue. A fast nonpersistent message, however, is just
discarded in these circumstances and the channel remains open.
If a message cannot be put on the dead letter queue, the channel is stopped and the
message remains on the transmission queue. A fast nonpersistent message, however, is just
discarded in these circumstances and the channel remains open.
Dead Letter Queue Handler
Figure 5-17. Dead Letter Queue Handler

The implementation of the dead letter handler is covered in detail in the WebSphere MQ
Advanced System Administration course (MQ30).
Using Dead Letter Queues
• Create a dead letter queue on all queue managers
− Use message-retry on message channels for transient conditions
− Consider "return to sender"
• Use a dead letter queue handler
− Trigger when a message arrives on the dead letter queue
− Possibly attempt further retries
− If unsuccessful, forward to an application dead letter queue associated with:
o The destination queue
o The application specified by the PutApplName field in the message descriptor
• Don't allow an application dead letter queue to become full
Remember that creating means to define the queue and to tell the queue manager the name
of its dead letter queue.
5.3 WebSphere MQ Clusters
What Is a Cluster?
Figure 5-18. What Is a Cluster?

• A cluster is a collection of queue managers that may be on different platforms, but typically
serve a common application.
• Every queue manager can make the queues that they host available to every other queue
manager in the cluster, without the need for (remote) queue definitions.
• Cluster specific objects remove the need for explicit channel definitions and transmission
queues for each destination queue manager.
• The queue managers in a cluster will often take on the role of a client or a server. The
servers will host the queues that are available to the members of the cluster, also running
applications that process these messages and generate responses. The clients PUT
messages to the servers queues and may receive back response messages.
• Queue managers in a cluster will normally communicate directly with each other, although
typically, many of the client systems will never have a need to communicate with other client
systems.
Cluster Support Objects

• Cluster Repository (Queue)
- A collection of information about the queue managers that are members of a cluster,
including queue manager names, their channels, the queues they host and so forth.
- This repository information is exchanged through messages sent to a queue called
SYSTEM.CLUSTER.COMMAND.QUEUE and stored on a queue with the fixed name
SYSTEM.CLUSTER.REPOSITORY.QUEUE.
- Repositories may be full or partial - more about this on the next visual. Each cluster queue
manager must have at least one connection to another queue manager that owns a full
repository.
• Cluster-sender channel
- A channel definition of the TYPE(CLUSSDR) on which a cluster queue manager can send
messages to another queue manager in the cluster that holds a full repository.
This channel is used to notify the repository of any changes of the queue manager's status,
for example the addition or removal of a queue. It is only used for the initial contact with the
first full repository queue manager. From this one the local queue manager learns whatever it
needs to know.
- Note: Application messages will be sent by auto-defined sender channels that are created
during operation based on repository information from other cluster queue managers.
Figure 5-19. Cluster Support Objects

• Cluster-receiver channel
- A channel definition of the TYPE(CLUSRCVR) on which a cluster queue manager can
receive messages from within the cluster. Through the definition of this object a queue
manager is advertised to the other queue managers in the cluster, thus enabling them to
auto-define their appropriate CLUSSDR channels for this queue manager.
You need at least one cluster-receiver channel for each cluster queue manager.
• Cluster transmission queue
- All the messages from the queue manager to any other queue manager in the cluster are
locally put to this queue named SYSTEM.CLUSTER.TRANSMIT.QUEUE.
It must exist in each cluster queue manager.
• Cluster Queue
- A cluster queue is a queue that is hosted by a cluster queue manager and made available to
other queue managers in the cluster. The local queue is either preexisting or created on the
local queue manager and to play a role in the cluster the local queue definition specifies the
cluster name of the definition. The other queue managers can see this queue and use it to put
messages to it without the use of remote queue definition. The cluster queue can be
advertised in more than one cluster.
More About Repositories
Figure 5-20. More About Repositories

• Each cluster queue manager has to have a local queue called
SYSTEM.CLUSTER.REPOSITORY.QUEUE where all cluster related information is stored.
• At least one (but for availability reasons preferably two or more) cluster queue managers
have to hold full repositories; that means a complete set of information about every queue
manager in the cluster.
• For each cluster queue manager, a cluster-sender channel has to be predefined that
connects to one of the repository queue managers.
• Repository queue managers (sometimes simply called repositories) must be fully
interconnected with each other and positioned in the network so as to give a high level of
availability.
• Normal queue managers build up and maintain a partial repository that contains information
about those queue managers and queues that are of interest to it. This information may be
updated and extended during operation through inquiries of a full repository.
Setting Up a Cluster
Figure 5-21. Setting Up a Cluster

The above example is for definitions required on QM1.
• The definitions of the cluster transmission and command queues are not shown; they are
not associated to a specific cluster by definition.
• QM1 is made a full repository queue manager for the cluster named EDUC by the ALTER
QMGR REPOS(clustername) command.
• A queue manager may be associated to more than one cluster at time. The same is true for
queues and channels.
- In this case a NAMELIST object has to be created with multiple cluster names as single
entries.
- Then with all DEFINE commands, the name of this namelist has to be referenced instead of
the cluster name, and the REPOS attribute of the ALTER QMGR command changes to
REPOSNL.
• Note that this full repository is pointing to another repository associated with the cluster
EDUC.
Workload Balancing
Figure 5-22. Workload Balancing

• Cluster support allows more than one queue manager to host an occurrence of the same
queue. Thus, two or more queue managers may be clones of each other, capable of running
the same applications and having local definitions of the same queues.
There may be two reasons for doing this:
- To increase the capacity available to process messages.
- To introduce an ability to failover work from one server to another and improve availability of
the service.
• This can be used to spread the workload between queue managers, if applications allow it to
do so.
• A built-in workload management algorithm determines the remote queue manager if there
are multiple choices, based on availability and channel priorities. A local occurrence always
takes precedence.
• You may supply your own cluster workload exit and activate it by use of the ALTER QMGR
command, as shown above.
Workload Balancing Attributes

• Queue attributes
− CLWLPRTY - priority
− CLWLUSEQ - use local queue
• Queue manager attributes
− CLWLUSEQ - use local queue
• Channel attributes
− CLWLPRTY - priority
− CLWLWGHT - weight
− NETPRTY - network priority
CLWLPRTY, the cluster workload priority attribute, determines the priority of the queue.
Use this attribute to ensure that WebSphere MQ selects some destination queue managers in
preference to others with a lower priority. WebSphere MQ selects the destinations with the
highest priority before selecting destinations with the lowest cluster destination sequence
number (or the most recently used one). Where there are two possible destinations, you can
use this attribute to allow one queue manager to act as a failover, if the other queue manager
becomes unavailable. In this situation, messages go to the highest priority queue manager
until it becomes unavailable, they then go to the next priority queue manager.
CLWLUSEQ specifies the behavior of an MQPUT operation if there is a local instance of a
queue and at least one remote cluster instance. If you specify QMGR, the behavior is as
specified by the CLWLUSEQ parameter of the queue manager definition. If you specify ANY,
the queue manager treats the local queue as another instance of the cluster queue for the
purposes of workload distribution. If you specify LOCAL, the local queue is the only target of
the MQPUT operation.
CLWLWGHT applies weight to a channel, so that the proportion of messages sent down
the channel can be controlled. Use this attribute to ensure that machines with more
processing power are sent more messages. The higher the channel weight, the more
messages are sent over that channel. The value must be in the range of 1 to 99, where 1 is
the lowest rank and 99 is the highest.
NETPRTY sets the priority for the network connection. If there are two possible routes to a
queue manager within the cluster, the highest priority channel available will be used first. Use
this attribute to make one network a primary and another one the backup.
Continuous Operations
Figure 5-23. Continuous Operations
• The cluster workload exit (built-in or user supplied) is called

- either when a cluster queue is opened by an MQOPEN or MQPUT1 call
- or when a message is put to a queue using MQPUT.
• If the target queue manager chosen at the time of an MQPUT call is unavailable, or fails
while the message is still on the transmission queue, the exit is called again to select a new
target queue manager.
• The queue attribute DEFBIND determines whether or not rerouting will be performed while a
queue is opened:
DEFBIND(NOTFIXED)
behaves as shown above, with a round-robin distribution of messages to all available
TARGET.Qs in the cluster.
DEFBIND(OPEN)
the destination queue is selected at MQOPEN time and will not be changed until
MQCLOSE. This attribute may be overwritten by the application using appropriate
Open Options.
• Make sure that all of the instances of the queue have the same priority, default persistence
and defbind values.
Cluster Related Queue Manager Attributes

• REPOS (ClusterName)
• REPOSNL (NamelistName)
• CLWLDATA (32 char max string)
• CLWLEXIT (Cluster workload exit name)
• CLWLLEN (max # of bytes of message data passed to cluster workload exit)
Notes:
• The list shows the attributes of a queue manager that can be altered to change some cluster
management options. You can:
- In the repository management section, specify the name of a single cluster or of a cluster
namelist for which this queue manager is to provide repository manager services.
- Determine the name of an optional user exit program that customizes auto-definition of
cluster sender channels.
- Determine the name of the cluster workload exit program that will be called whenever a
message is put to a cluster queue.
- Specify a 32-character data string and/or the maximum bytes of message data that can be
passed to the workload exit.
Controlling Clusters - Cluster Commands

• SUSPEND QMGR
• RESUME QMGR
• REFRESH CLUSTER(clustername)
• RESET CLUSTER(clustername)
QMNAME(qmname)ACTION(FORCEREMOVE)
Notes:
SUSPEND QMGR
Removes a queue manager from a cluster temporarily, which means that the workload
management exit will not route any messages to this queue manager. All information
about a suspended queue manager and its objects are preserved in the repositories,
but the queue manager is marked suspended. This function may be used if a queue
manager has to be taken down for maintenance.
RESUME QMGR
Reinstates a suspended queue manager.
REFRESH CLUSTER
Discards all locally held information about a cluster (including auto-installed channels
that are in-doubt) and thus enforces a cold start of this queue manager in that cluster.
This command should not be used for regular operation.
RESET CLUSTER
Can only be issued by a repository queue manager and forces a named queue
manager off the cluster in the way that all (other) queue managers in the cluster are
informed that this queue manager is no longer a part of the cluster.
RESET CLUSTER (clustername)
QMNAME(qmname) ACTION(FORCEREMOVE) QUEUES(NO)
or the command:
RESET CLUSTER (clustername)
QMID(qmid) ACTION(FORCEREMOVE) QUEUES(NO)
You cannot specify both QMNAME and QMID.
Controlling Clusters - DISPLAY CLUSQMGR
Figure 5-24. Controlling Clusters - DISPLAY CLUSQMGR
The DISPLAY CLUSMGR command returns cluster information about queue managers in a
cluster which is stored in the local SYSTEM.CLUSTER.REPOSITORY.QUEUE.
Definition Type may be:
CLUSSDR as a cluster-sender channel from an explicit definition
CLUSSDRA as a cluster-sender by auto-definition
CLUSSDRB as a cluster-sender channel, both from an explicit definition and by auto-
definition
CLUSRCVR as a cluster-receiver channel.
Cluster Related Queue Considerations

• Special Display option
DISPLAY QUEUE CLUSINFO
• Cluster Alias Queues
DEF QA(PUBLIC) TARGET(LOCAL.Q) + CLUSTER(ITALY)
• Cluster Queue Manager Aliases
DEF QR(ROME) RNAME() RQMNAME(PISA) + XMITQ(XQ) CLUSTER(ITALY)
Notes:
• The CLUSINFO option of the DISPLAY QUEUE command identifies the queue hosting
queue manager.
• Most types of queues may be defined as cluster queues, and as a consequence, be
advertised to all queue managers in the cluster, just as for local queues.
- Alias Queues may be made available to the cluster simply by adding the CLUSTER
keyword to the definition.
- Queue Manager Aliases advertised to the cluster may be of the same value as for
traditional distributed queueing.
- Remote Queues are not intended to be advertised to a cluster - because one of the
benefits of clusters is that Remote Queue definitions are no longer required. Remote
Queues, however, can have a cluster attribute. They can be used to attach a queue
manager that does not support clustering.
- Model Queues (and hence temporary dynamic queues) cannot have a cluster
attribute.
• Effect of altering queue definitions:
- ALTER QUEUE(XXX) PUT(INHIBITED) will stop messages being put to that instance
of a queue and also mark it as being put inhibited throughout the cluster. If applicable,
this will cause messages to be sent to other instances of the queue.
- ALTER QUEUE(XXX) CLUSTER(' ') will take a queue out of its clusters and stop
other queue managers from sending messages to it but still allow messages to be put
to it from the local queue manager.
Unit 5 Checkpoint
1. T/F NPMSPEED(FAST) is a parameter on a channel that causes
the message channel agent to use
MQGMO_SYNCPOINT_IF_PERSISTENT.
2. If the SEQWRAP value on a SENDER channel is different from the
value on the RECEIVER, what will happen?
a. They negotiate to the lower value at channel startup time.
b. The channel will not start.
c. They negotiate to the higher value at channel startup time.
d. Nothing - this is controlled at the SENDER; RECEIVER can not specify SEQWRAP.
e. The value from the SENDER definition takes precedence.
3. A sender channel is defined in a script file with REPLACE. The runmqsc control command
is run using this script while the channel is active.
a. The channel will fail and won't restart without intervention.
b. The active channel won’t be affected by this.
c. Because the channel is active, this command won’t be executed.
d. The channel will fail and any in-transmit messages will be lost.
4. T/F A queue manager can become part of a cluster and messages will flow to its queues as
soon as it is altered to show the name of the cluster it belongs to.
Unit Summary
• Configuration for distributed queuing
• The MQI in the network
• Application data conversion
• Remote administration
• Instrumentation events
• Dead letter queue
• Cluster support
Exercises 4 and 5
This unit described how to configure WebSphere MQ for distributed queuing and there
was a practical exercise in getting messages to flow between queue managers.
We also discussed other aspects of WebSphere MQ administration in a network,
application data conversion, remote administration, instrumentation events, reports, and the
dead letter queue.
Finally, for WebSphere MQ Version 5 and 6 queue managers, you were able to
complete an exercise that set up a simple cluster and observe the capabilities of this function.
Unit 6. More on Distributed Queuing

This unit describes further aspects of distributed queuing.
• WebSphere MQ Family SupportPacs
• WebSphere MQ clients
• Security

• Describe WebSphere MQ SupportPacs and know where to find them
• Describe how to install and configure an WebSphere MQ client
• Identify the security features of WebSphere MQ
• Describe how message context fields and options can be used as a component of
application security
• Describe how Secure Sockets Layer works
• Distinguish one channel exit from another

Accountability:
• Classroom discussions
References
Unit Objectives
• Describe SupportPacs and how to get them
• Explain WebSphere MQ clients
• Set up a simple WebSphere MQ client configuration
• Describe the access control features available on various WebSphere MQ queue
managers
• Describe how Secure Sockets Layer (SSL) works
• List channel exits and define their use
• Know where to find information on writing security exits
You now learn where WebSphere MQ clients are supported, how to install and
configure them, and where they are best used.
WebSphere MQ offers security features that make the product robust enough for use in
a complex production system. In addition, extensions are provided where additional
capabilities are desired (for example, SSL, exits and installable services). You should learn
about the various capabilities and how they are implemented.
6.1 WebSphere MQ Family SupportPacs
This topic describes the WebSphere MQ Family SupportPacs which contain material
that can enhance the usage of the WebSphere MQ.
Overview of SupportPacs
• Transaction Processing SupportPacs
− Specific functions or services
− Contributors throughout IBM
− Available world wide
− Enhance CICS and WebSphere MQ products
• Available in four categories
− Fee-based services
Not available for download
− Freeware
Provided AS-IS with no warranty or defect correction
− Product extensions
Fully supported
− Third Party Contributions
Provided AS-IS with no warranty or defect correction
WebSphere MQ Family SupportPacs can be found at the following Web address:

www.ibm.com/software/integration/support/supportpacs
Example: MO01
• WebSphere MQ for AIX and MQSeries for OS/2 Warp Utilities
• Three sample utilities
− Event queue monitor
− Dead letter queue monitor
− Program to remove expired messages
• Useful sample source code:
− To parse an event message
− To read a dead letter header
− To obtain information from the command server
This SupportPac contains three utilities, an event queue monitor, a dead letter queue
monitor, and a program to remove expired messages. The SupportPac only contains
executable code for the AIX and OS/2 Warp platforms. However, it also provides sample
source code which could be ported to a variety of other platforms.
Event queue monitor
This waits on an event queue and alerts the user when an event message has arrived
on the queue. It writes the contents of the message to the standard output device in a
readable form. The source code is a useful example of how to parse event messages whose
format is based on that of PCF commands.
Dead letter queue monitor
This waits on the dead letter queue and alerts the user when a message has arrived on
the queue. It writes the dead letter header to the standard output device in a readable form.
The source code is a useful example of how to read a dead letter header.
Expired message remover
This browses every message that exists within a queue manager so that any message
whose expiration time has elapsed is removed. This is useful for keeping queue storage
under control and the source code is a good example of how to obtain information from the
command server.
Example: MS03
• WebSphere MQ saves Queue Manager object definitions using PCFs
• Interrogates the attributes of all the objects defined to a queue manager (either local or
remote) and saves them to a file
− Suitable for use with RUNMQSC
− Can be used with any of the WebSphere MQ family that supports PCFs
Notes:
• This SupportPac provides a utility that allows you to save current queue manager and object
definitions in a file, which can be used to recreate the objects.
• All objects (queue manager, queue, process, and channel) are supported.
6.2 WebSphere MQ Clients
Some platforms, without having a queue manager configured on them, can operate as
an WebSphere MQ client. This topic describes the configuration and operation of
WebSphere MQ clients.
WebSphere MQ Client
Figure 6-1. WebSphere MQ Client
WebSphere MQ Clients Explained
Figure 6-2. WebSphere MQ Clients Explained

• The full range of MQI calls and options is available to a WebSphere MQ client application,
including the following.
- The use of the MQGMO_CONVERT option on the MQGET call. This causes the
application data of the message to be converted into the numeric and character
representation in use on the client system. The server queue manager provides the
usual level of support to do this.
- A client application may be connected to more than one queue manager
simultaneously. Each MQCONN call to a different queue manager returns a different
connection handle. This does not apply if the application is not running as a
WebSphere MQ client.
• The MQI stub which is linked with an application when running as a client is different from
that used when the application is not running as a client. An application will receive the
reason code MQRC_Q_MGR_NOT_AVAILABLE on an MQCONN call if it is linked with the
wrong MQI stub.
Syncpoint Control on a Base Client
Figure 6-3. Syncpoint Control on a Base Client

A WebSphere MQ client application may participate in a local unit of work involving the
resources of the queue manager it is connected to. To do this, it uses the MQCMIT and
MQBACK calls in the normal way.
A WebSphere MQ client application cannot however participate in a global unit of work.
Such an application may issue calls to another resource manager or syncpoint
coordinator, on the same system as the application or on another system, and may participate
in a unit of work associated with that resource manager or syncpoint coordinator. At the same
time, it may also be participating in a local unit of work involving the resources of the queue
manager it is connected to. In which case, the two units of work are completely independent
of each other.
Extended Transactional Client
Figure 6-4. Extended Transactional Client

A WebSphere MQ extended transactional client is a WebSphere MQ client with some
additional function. This function allows a client application, within the same unit of work:
• To put messages to, and get messages from, queues that are owned by the queue manager
to which it is connected
• To update the resources of a resource manager other than a WebSphere MQ queue
manager
This unit of work must be managed by an external transaction manager that is running
on the same system as the client application. The unit of work cannot be managed by the
queue manager to which the client application is connected. This means that the queue
manager can act only as a resource manager, not as a transaction manager. It also means
that the client application can commit or back out the unit of work using only the application
programming interface (API) provided by the external transaction manager. The client
application cannot, therefore, use the MQI calls, MQBEGIN, MQCMIT, and MQBACK.
Installation
• Method 1 (Version 5 or 6 only)
− Install from the WebSphere MQ Client CD-ROM supplied with the product
• Method 2
− For a client platform which is the same as the server platform
− Select the required client component during the standard install
• Method 3
− Install the client component on the server system
− Copy the files of the client component to the client system
− Modify CONFIG.SYS, AUTOEXEC.BAT, and so forth
• Method 4
− Install from a SupportPac
Notes:
• Each Version 5 and 6 product supplies a WebSphere MQ Client CD-ROM which contains
the software, including an easy installation feature, for clients on the following platforms.
• These platforms also include Java client except the Linux platform.
- AIX
- HP-UX
- Linux
- Solaris
- Windows
• MQSeries for Compaq OpenVMS and WebSphere MQ on UNIX systems other than AIX,
HP-UX, and Sun Solaris include the files for the desktop clients and for a client on the same
platform as the server platform. The desktop clients are for DOS, OS/2 Warp, and Windows
3.1.
• Most WebSphere MQ products supply files for clients on the same platform as the server
and for clients on other platforms. WebSphere MQ for iSeries, z/OS and MQSeries for
Compaq Tru64 UNIX and VSE/ESA can supply files for clients on other platforms only.
Defining an MQI Channel

• Use the DEFINE CHANNEL command with parameters:
− CHLTYPE
CLNTCONN or SVRCONN
− TRPTYPE
DECNET, LU62, NETBIOS, SPX, or TCP
− CONNAME(string)
For a client connection only
− QMNAME(string)
For a client connection only
• No operational involvement on an MQI channel
− An MQI channel starts when a client application issues MQCONN (or MQCONNX)
− An MQI channel stops when a client application issues MQDISC
Notes:
• MQI channels do not have to be started. Just run the client application which calls a
MQCONN or MQCONNX.
• A MQI channel can be used to connect a client to a single queue manager, or to a queue
manager that is part of a queue-sharing group.
• Do not forget to configure and refresh the inet daemon, or to start the WebSphere MQ
listener, on the server system.
Two Ways of Configuring an MQI Channel

• Method 1
− On the server system, define a server connection
− On the client system, set the environment variable
− MQSERVER=ChannelName/TransportType/ConnectionName
• Method 2
− On the server system, define a client connection and a server connection
− If not on a file server, copy the client channel definition table from the server system to
the client system
− On the client system, set the environment variables:
− MQCHLLIB= Path to the directory containing the client channel definition table
− MQCHLTAB= Name of the file containing the client channel definition table
Notes:
• Method 1 is the easier of the two methods setting up a client. On the server, you use the
DEFINE CHANNEL command to define a server connection. On the client system, you define
a simple client connection by setting the environment variable MQSERVER to the following
value:
ChannelName/TransportType/ConnectionName
For example, on DOS, OS/2 Warp, or Windows:
SET MQSERVER=VENUS.SVR/TCP/9.20.4.56
For example, on a UNIX system:
export MQSERVER=VENUS.SVR/TCP/'9.20.4.56'
• Method 2 is a more complex method which involves a definition of a client connection and a
server connection on the server system.
The client connection definition is stored in the client channel definition table, file name
AMQCLCHL.TAB. This table must either be accessible from the client system by residing on
a file server, or it must be copied to the client system.
On the client system, the environment variables MQCHLLIB and MQCHLTAB are then
set in order to specify the location and the name of the client channel definition table.
For example, on DOS, OS/2 Warp, or Windows:
SET MQCHLLIB=C:\MQM
SET MQCHLTAB=AMQCLCHL.TAB
For example, you can set the environment variables on a UNIX system:
export MQCHLLIB=/mqmtop/qmgrs/QUEUEMANAGERNAME/@ipcc
export MQCHLTAB=AMQCLCHL.TAB
• WebSphere MQ z/OS platform is the only platform that can not store the client channel
definition table associated with the queue manager running on the server. They are stored
with WebSphere MQ objects in page set zero.
• On MQSeries for Compaq NonStop Kernel, the client channel definition table is in the file
CCHDEFS which is located in the queue manager data files subvolume, that is, the
subvolume whose name has the suffix 'D'. Before using the file, it must first be converted into
a form which is acceptable to an WebSphere MQ client. This is accomplished by means of
the cnvclchl control command. This command is unique to MQSeries for Compaq NonStop
Kernel and is described in the MQSeries for Compaq NonStop Kernel System Management
Guide.
• A third method is available for Version 5.1 and later clients only. An application can control
the definition of the client connection channel by providing an MQCD channel definition
structure that contains the values required. This is then passed using an MQCONNX call
instead of MQCONN.
• With this option available, the client application can specify the ChannelName,
TransportType, and ConnectionName attributes of a channel at run time and this enables the
client application to connect to multiple server queue managers simultaneously. If MQServer
environment variable is used this is not possible.
• A client application can specify other attributes such as MaxMsgLength and SecurityExit
allowing non-default values to be used and called at the client end of the MQI channel. Lastly
if a channel uses Secure Sockets Layer (SSL) a client application can also provide
information relating to SSL in the MQCD structure.
Channel Instances
Figure 6-5. Channel Instances

• Each of the four MQI channels shown on the visual is an instance of the same MQI channel.
The main points to note are as follows.
- The environment variable MQSERVER has an identical value on each of the client systems
with host names IO, EUROPA, GANYMEDE, and CALLISTO.
- On the server system, host name JUPITER, the queue manager requires just one server
connection definition for the MQI channel JUPITER.SVR.
- Each client application is using a different instance of the MQI channel JUPITER.SVR.
Auto-definition of Channels
• Applies only to the end of a channel with type:
− Receiver
− Server connection
• Function invoked when an incoming request is received to start a channel but there is no
channel definition
• Channel definition is created automatically using the model:
− SYSTEM.AUTO.RECEIVER
− SYSTEM.AUTO.SVRCONN
• Partner's values are used for:
− Channel name
− Sequence number wrap value
• WebSphere MQ and MQSeries Version 5.1 or later
Notes:
• The auto-definition of channels is supported on all WebSphere MQ platforms except for
z/OS.
• To enable the automatic definition of channels, the attribute ChannelAutoDef of the queue
manager object must be set to MQCHAD_ENABLED. The corresponding parameter on the
ALTER QMGR command is CHAD(ENABLED).
• Once a channel definition has been created in this way and stored, the definition may be
used subsequently as though it had always existed.
• Channel auto-definition events can be enabled by setting the attribute ChannelAutoDefEvent
of the queue manager object to MQEVR_ENABLED. The corresponding parameter on the
ALTER QMGR command is CHADEV(ENABLED).
• The partner may be any queue manager or client; it does not have to be at Version 6 level.
6.3 Security
This topic describes the security features of WebSphere MQ.
WebSphere MQ Security Implementations

• Object Authority Manager (OAM) facility
• Channel Security using Secure Sockets Layer (SSL)
Security is one of the most important aspects for a distributed system and WebSphere MQ
provides a flexible security framework that allows the appropriate security architecture to be
implemented to meet your specific requirements.
Authorization for using MQI calls, commands and access to objects is provided by the
Object Authority Manager (OAM), which by default is enabled. Access to WebSphere MQ
entities is controlled through WebSphere MQ user groups and the OAM. We provide a
command interface to enable administrations to grant or revoke authorizations as required.
The Secure Sockets Layer (SSL) protocol provides industry-standard channel security,
with protection against eavesdropping, tampering, and impersonation.
WebSphere MQ Access Control Overview

• Granular access control facilities
− Provided via WebSphere MQ Installable Services
− Which user? Which resource? What types of access?
• WebSphere MQ access control at user and/ or group level
− UNIX use groups only
− Username must exist, everyone is in nobody
− Windows uses userids and/or groups
− System-level userids only are supported
No support for DCE principals, TXSeries userids, and so forth
• Alternate userids may be specified
− When suitably authorized
• First level name only is controlled:
− Alias Queues, Remote Queues
− Resolved name is not significant
The primary security component provided by WebSphere MQ is access control. This
allows WebSphere MQ to control which users are granted which types of access to which
WebSphere MQ resources. The resources which may be controlled in this way are the queue
manager, queues and processes.
All distributed queue managers provide access control facilities to control which users
have access to which WebSphere MQ resources. The distributed queue managers use the
Installable Services component of WebSphere MQ - the Authorization Service - to provide
access control for WebSphere MQ resources.
WebSphere MQ supplies an Object Authority Manager (OAM) as an authorization
service which conforms to the Installable Services interface. The OAM provides a full set of
access control facilities for WebSphere MQ including both the access control checking and
commands to set, change and inquire on WebSphere MQ access control information. The
OAM, like all Installable Services components, is replaceable by any component - user or
vendor supplied - that conforms to the Authorization Service interface.
WebSphere MQ captures the userid associated with an application at MQCONN. This
userid is used for the above access control checks. It is possible for suitably authorized users
to use an alternate userid instead of the logged on userid. When WebSphere MQ checks to
see if a user is permitted to access a particular resource, it is the name specified in the MQ
API command which is used for the check.
For the case of an Alias or Remote queue definition, it is still the name of the queue
specified in the MQ API command and not the resolved- to name. Thus, a user needs access
to the first named resource and not the resolved- to resource. For model queues, there may
be instances where WebSphere MQ will generate the name of the dynamic queue. Because
of this, the userid creating a dynamic queue is automatically given full access rights to the
queue.
Object Authority Manager: Installable Service
Figure 6-6. Object Authority Manager: Installable Service
The Object Authority Manager (OAM) component conforms to the WebSphere MQ

Installable Services interface.
This provides an open, documented interface (documented in the WebSphere MQ
System Administration Guide).
The OAM is, therefore, user-replaceable, meaning that any component which conforms
to the documented interface, may replace the existing OAM.
Further, the OAM (or any component replacing it) may be augmented - having more
than one component simultaneously (actually - sequentially) running at the Installable Service
Interface.
Object Authority Manager: Installable Services

• Access control lists are WebSphere MQ specific
− Not integrated with system-level security
Changes to user's OS authority isn't recognized until QMgr restart
New REFRESH SECURITY command
− One ACL set per queue manager
Not shared between queue managers
• Access control for WebSphere MQ objects
Queue manager
Queues
Processes
Namelists
Channels
Authentication information objects
Listeners
Services
• OAM can be disabled
− Remove entry from mqs.ini or Windows Registry
− Not recommended
− Very difficult to reestablish uniform authority checking
The implementation of the OAM has a set of associated access control lists.
There is a set of access control lists per queue manager, meaning that the ACLs cannot
be (automatically) shared across multiple queue managers.
The OAM provides access control facilities only for WebSphere MQ objects. These are the
queue manager itself, all queues, processes, namelists, channels, authentication information
objects, listeners, and services.
It is possible to disable access control checking. This is done by setting the appropriate
environment variable or deleting the authorization service stanza in the queue manager
configuration file qm.ini (or Registry on Windows systems).
This is not recommended;
If the OAM is disabled, then access permissions which are normally automatically set
when objects are created are no longer created. If the OAM is enabled at some later time,
these permissions will not exist and will have to be created manually.
Object Authority Manager:
Access Control Lists
• One authority file per object
− Plus global permissions files
• Each file has one stanza per principal
− Principal:
− Authority='bit pattern'
• Windows OAM bypasses auth files for certain classes of principal
− SYSTEM, local Administrators group, local mqm group
• MQ object permissions
− 22 permissions
− Global permissions, for example, connect, altusr, setall, setid
− Object permissions, for example, browse, put, get ... and allmqi
− Administration permissions, for example, crt, dsp, chg, dlt ... and alladm
• Used mostly for PCF commands
− Plus all and none
• Command amqoamd dumps the ACLs in readable format
Each file contains a set of access control stanzas. There is one stanza per principal for
which access is to be controlled, where a principal is either a userid or a group.
The principals (userids and/ or groups) which have access to the appropriate object are
listed in this file, along with a bit string (in hex) which represents the access rights associated
with that entity.
For each principal which is granted access to an object, there is a permission bit pattern,
where each bit corresponds to a particular permission. These permissions are documented in
the WebSphere MQ System Administration.
Security Management: setmqaut

• Change the authorizations
queue manager
queues
processes
namelists
authinfo (SSL channel security)
channels
listeners
services
• Principal or group level control
• Granular control of access
− No generic functions
− Supports generic profiles
setmqaut -m QMgr -t Objtype -n Profile [-p principalname | -g
groupname] permissions
setmqaut -m JUPITER -t queue -n MOON.* -g VOYAGER +browse +get

There are three control commands which provide control of the security environment
for WebSphere MQ, setmqaut, dspmqaut, dmpmqaut.
These programs require a connection to the authorization service and so may only be
used when the target queue manager is active and the OAM is enabled. All of the responses
to these commands are displayed on the screen. These commands are documented in the
WebSphere MQ System Administration Guide.
Setmqaut is used to set the access that a principal or group has to a particular
resource. This can be used to add or remove privileges.
Note that there are certain principals/ groups which are granted automatic access to
resources. These are:
• mqm (user/group)
• For Windows:
- Administrator (user/local group)
- SYSTEM (userid)
• The user (or principal group) which creates a resource
All other principals and groups must be granted access to a resource using the utility.
Setmqaut can utilize generic profiles. In the example above, the setmqaut control command
allows members of the group VOYAGER to get and browse messages on the queue whose
name commences with the characters MOON. That is owned by the queue manager
JUPITER. MOON.* is the generic profile.
The PCF equivalent command is Set Authority Record.
Security Management: dspmqaut

• Display current authorizations
qmgr
queues
processes
namelists
authinfo ( SSL channel security)
channels
listeners
services
dspmqaut -m QMgr -t ObjType -n ObjName [- p Principal | -g Group ]
dspmqaut -m SATURN -t q -n APPL.Q1 -p mquser
Entity mquser has the following authorizations for object APPL.Q1:
get
browse
put
...
Dspmqaut does support of generic profiles. If a user ID is a member of one or more
groups, this command displays the combined authorizations of all the groups. Only one group
or principal can be specified.
On WebSphere MQ for Windows you can specify a local group. The PCF equivalent
command is Inquire Entity Authority.
Security Management: dmpmqaut

• Dump current authorizations
qmgr
queues
processes
namelists
authinfo (SSL channel security)
channels
listeners
services
dmpmqaut -m Qmgr -t Objtype -n Profile [-p principalname | -g groupname]

dmpmqaut -m qm1 -n a.b.c -t q -p user1
The resulting dump would display:

profile: a.b.*
object type: queue
entity: user1
type: principal
authority: get, browse, put ,inq
The WebSphere MQ control command enables you to dump the current authorizations
associated with a specified profile. The WebSphere MQ System Administration Guide
provides documentation on this command.
Dmpmqaut can be used to dump authority records for a generic profile.
The -l parameter allows you to dump only the profile name and the type. The listing will
be a terse list of all profiles names and types.
Group names must exist and you can only specify one group name on the dmpmqaut
command. WebSphere MQ for Windows allows the use of local groups only.
The PCF equivalent command is Inquire Authority Record.
Access Control for WebSphere MQ Control Programs

• Most WebSphere MQ control programs
o For example, crtmqm, strmqm, runmqsc, setmqaut
• Have restricted access
o UNIX restricts users to the mqm group
Configuration as a part of WebSphere MQ installation
Control imposed by the operating system, not OAM
o OpenVMS restricts users to those granted the MQM identifier
o Compaq NSK allows:
MQM group
SUPER.SUPER ID
o Windows allows
mqm group
Administrators group
System userid
Authority Checking in the MQI

• MQI calls with security checking
o MQCONN / MQCONNX
o MQOPEN
o MQPUT1 (implicit MQOPEN)
o MQCLOSE
For Dynamic queues
• WebSphere MQ events as audit records
o Events written to SYSTEM.ADMIN.QMGR.EVENT queue
o Documented in Monitoring WebSphere MQ manual
• Reason code MQRC_NOT_AUTHORIZED returned if not authorized
Notes:
• When attempting to access an alias queue, authority checking occurs at the level of the alias
queue, not at the level of the queue to which it resolves. The same is true for a local definition
of a remote queue. It is therefore possible to grant no access to a local queue and only grant
access to an alias queue which resolves to it.
• Limit the ability to define queues to privileged users. Otherwise, normal access control could
be bypassed simply by creating an alias queue.
The MQCLOSE is generally not checked because the close options are usually none.
However, if the close options are set to MQCO_DELETE or MQCO_DELETE_PURGE (this is
only valid for permanent dynamic queues) then, unless the queue was created using the
current handle, there is a check to determine if the user is authorized to delete the queue.
Security and Distributed Queuing

• Put authority
o Option for the receiving end of a message channel
Default user identifier is used
Context user identifier is used
• Transmission queue
o Messages destined for a remote queue manager are put on a transmission queue by
the local queue manager
An application should not normally need to put messages directly on a
transmission queue, or need authority to do so
o Only special system programs should put messages directly on a transmission queue
and should have the authority to do so
When defining the receiving end of a message channel, there is an option which allows
you to specify which user identifier is to be used for checking the authority of the receiving
MCA to open a destination queue in order to put a message on it. You can choose one of the
following.
Default user identifier
The receiving MCA's default user identifier is used. This user identifier may be changed
by a security exit, or by setting the MCAUSER parameter in the channel definition at the
receiving end of the message channel.
Context user identifier
The user identifier in the context of the message is used. You should only allow special
system programs to put messages directly on a transmission queue.
Message Context
Figure 6-7. Message Context

Message context information allows for the application that retrieves a message to find
out about the originator of the message. The retrieving application may want to:
Check that the sending application has the correct level of authority.
Keep an audit trail of all the messages it has worked with.
The information is held in two fields: identity context and origin context.
The Context Fields
Figure 6-8. The Context Fields
An application can request the queue manager to set the context fields of a message
by using the put message option MQPMO_DEFAULT_CONTEXT on an MQPUT or MQPUT1
call. This is the default action if no context option is specified.
The visual lists the context fields and provides some examples of what the queue
manager sets them to when it generates the information.
Identity context
• User that originated the message.
UserIdentifier is 12 characters long. Longer user IDs are generally not permitted. For
Windows, the queue manager uses the first 12 characters of the logged-on user name.
For UNIX systems, the queue manager uses the application's logon name, the effective
user identifier of the process if no logon is available, or the user identifier associated
with the transaction, if the application is a CICS transaction.
• Accounting token
The queue manager treats the information in this field as binary information, not
character information. When the queue manager generates this information, it sets the
first byte to the length of the accounting information. The length of the first byte is in the
range zero through 30. The second and subsequent bytes are set to the accounting
information based on the environment.
On Windows, the accounting information is set to a Windows security identifier (SID) in
a compressed format.
On Compaq OpenVMS Alpha, Compaq NonStop Kernel, and UNIX systems, the
accounting information is set to the numeric user identifier, in ASCII characters. The
last byte is set to the accounting-token type.
• Application data relating to identity.
Origin context
• Type of the application that put the message.
• Name of the application that put the message.
On Windows systems, the queue manager uses:
For a CICS application, the CICS transaction name
For a non-CICS application, the rightmost 28 characters of the fully qualified name of
the executable
On Compaq OpenVMS Alpha and Compaq NonStop Kernel, the rightmost 28
characters, if available otherwise blanks.
On UNIX systems, it uses the same as for CICS applications just like Windows, but for
non-CICS applications, the rightmost 14 characters.
• Date when the message was put.
The format of the date, when it is generated by the queue manager, is YYYYMMDD
and the date itself is in GMT.
• Time when the message was put.
The format of the time, when it is generated by the queue manager, is HHMMSSTH
and the time itself is in GMT.
• Application data relating to the origin.
No Context
• Requested by a put message option
o MQPMO_NO_CONTEXT
o Queue manager clears all the context fields, specifically
o PutApplType is set to MQAT_NO_CONTEXT
• To request default context or no context requires no more authority than that required to
put the message on the queue
An application may elect to put a message with no context by specifying the put message
option MQPMO_NO_CONTEXT. In which case, the queue manager clears all the context
fields. Specifically, it sets the field PutApplType to MQAT_NO_CONTEXT so that the
receiving application can test for this value. Setting no context can be slightly faster provided,
of course, the information is not required.
• The receiver of a message can test the PutApplType field to determine whether the
message has no context.
Passing Context
Figure 6-9. Passing Context

Programs should generally pass the identity context information from message to
message around an application until the data reaches its final destination.
Alternate User Authority
Figure 6-10. Alternate User Authority

The alternate user authority option allows an application to open a queue, or any other
WebSphere MQ object, by providing the queue manager with a user identifier other than the
one it is currently running under. The queue manager uses this alternate user identifier in
order to check whether it is authorized to open the queue.
Setting Context
• Two open options that require authority to use
o MQOO_SET_IDENTITY_CONTEXT
o MQOO_SET_ALL_CONTEXT
• Two corresponding put message options
o MQPMO_SET_IDENTITY_CONTEXT
o MQPMO_SET_ALL_CONTEXT
• Normally used by special programs only
o Message channel agents
o System utilities
The visual depicts the two remaining context options for use when opening a queue. An
application requires authority to use these options. The corresponding put message options
are for use when putting a message on a queue once it has been opened.
Channel Exit Programs
Figure 6-11. Channel Exit Programs

The uses of channel exit programs are:
Auto-definition exit
can be used to modify the channel definition derived from the model
SYSTEM.AUTO.RECEIVER.
Security exit
is primarily used by the MCA at each end of a message channel to authenticate its
partner.
Send and receive exits
can be used for purposes such as data compression/decompression and data
encryption/decryption.
Message exit
can be used for any purpose which makes sense at the message level.
The following are some examples.
- Application data conversion
- Encryption/decryption
- Journaling
- Additional security checks such as validating an incoming user identifier
- Substitution of one user identifier for another as a message enters a new security
domain
- Reference message handling
Message-retry exit
is called when an attempt to open a destination queue, or put a message on a
destination queue, has been unsuccessful. The exit can be used to determine under
what circumstances the MCA should continue to retry, how many times it should retry,
and how frequently.
• The auto-definition exit is only supported on WebSphere MQ for AIX, HP-UX, iSeries,
Solaris, and Windows, and MQSeries for Compaq Tru64 UNIX and OS/2 Warp V5.1.
• Full details on how to write channel exit programs can be found in WebSphere MQ
Intercommunication manual.
Channel Exit Programs on MQI Channels
Figure 6-12. Channel Exit Programs on MQI Channels

Notes:
• No channel exit programs can be called on a client system if the MQSERVER environment
variable is used to define a simple client connection.
• The auto-definition exit can be used to modify the channel definition derived from the model
SYSTEM.AUTO.SVRCONN.
• The auto-definition exit is only supported on a Version 5 or 6 queue manager.
Secure Sockets Layer

• Protocol to allow transmission of secure data over an insecure network
• Combines these techniques
o Symmetric / Secret Key encryption
o Asymmetric / Public Key encryption
o Digital Signature
o Digital Certificates
• Protection
o Client/Server
o Qmgr/QMgr channels
• To combat Security Problems
o Eavesdropping
Encryption techniques
o Tampering
Digital Signature
o Impersonation
Digital Certificates
Secure Sockets Layer (SSL) is common across all the Version 5.3 and later platforms -
z/OS, UNIX, Windows, iSeries.
SSL is an industry-standard protocol for secure communications, involving encryption,
authentication, and integrity of data. SSL is supported in both client/server and qmgr/qmgr
channels (including clusters). There are many flexible capabilities built-in, including the ability
to select who are prepared to accept communications from based on their fully-authenticated
identity. This removes, for many people, the need to set up channel exits, where they were
used for security purposes.
SSL, is widely accepted in the Internet community, has been subjected to significant
testing by the hacker community.
SSL Handshake
QMGR Attributes for SSL
• ALTER QMGR command
o SSLKEYR
Sets the SSLKeyRepository
o SSLCRLNL
Sets the SSLCRLNamelist
o SSLCRYP
Sets the SSLCryptoHardware
o SSLTASKS
Sets the SSLTasks
o SSLEV
Enables or disables SSL event messages
o SSLFIPS
Specifies if only FIPS-certified algorithms can be used
QMGR Authentication Object
• ALTER AUTHINFO
• DEFINE AUTHINFO
• DELETE AUTHINFO
• DISPLAY AUTHINFO
You can either alter, define, delete or display the authentication information objects. These
objects contain the definitions required to perform Certificate Revocation Lists (CRL) checking
using LDAP servers.
The AUTHINFO queue manager attribute is supported on UNIX, Windows, i5/OS,
Compaq NSK, and HP OpenVMS.
Channel Attributes for SSL

• DEFINE or ALTER CHANNEL
o SSLCIPH
o SSLPEER
o SSLCAUTH
SSLCIPH - Specifies the encryption strength and function (CipherSpec), for example
NULL_MD5 or RC4_MD5_US. The CipherSPec must match at both ends of the channel.
SSLPEER - Specifies the distinguished name (unique identifier) of allowed partners.
SSLCAUTH - defines whether WebSphere MQ requires and validates a certificate from the
SSL client.
Access Control for a WebSphere MQ Client

• Access control is based on a user ID used by the server connection process
o Value of MCAUserIdentifier in MQCD determines this user ID
• Security exits at both ends of the MQI channel
o Client security exit can flow a user ID and password
o Server security exit can authenticate the user ID and set MCAUserIdentifier
• No security exit at the client end of the MQI channel
o Value of logged_in USERID flows to the server system
o Server security exit can authenticate the user ID and set MCAUserIdentifier
• No security exit at either end of the MQI channel
o MCAUserIdentifier has the value of MCAUSER if it is nonblank
o MCAUserIdentifier has the value of flowed user ID otherwise
When an WebSphere MQ client application wishes to access a WebSphere MQ object on

the server queue manager (for example, connect to the queue manager, or open a queue),
access control is based on a user ID used by the server connection process. The reason for
this is that it is the server connection which actually issues the MQI calls. This user ID is
determined by the value of the MCAUserIdentifier field in the active channel definition at the
server end of the MQI channel instance. The active channel definition is defined by the
structure MQCD and is documented in WebSphere MQ Intercommunication manual.
Remote Queuing and Clients

• Channel Exits
o A number of channel exits are available in the product and as SupportPacs
o Several vendors in this market too
• MCAUSER
o The default setting is wide open, especially for client attach
o May want to set this to restrict who can access your queue manager
• MQ_ USER_ ID environment variable
o This was removed for WindowsNT and UNIX in the 5.1 release client environments
o The logged-in username is now automatically used
o But this is not authenticated at the server; you may still need security exits
Unit 6 Checkpoint
1. T/F All SupportPacs are AS-IS code.

2. T/F A client channel does not require a START CHANNEL command.
3. On a Version 6 client, what method will not work to find the server connection desired?
a. Use SET MQSERVER environment variable
b. Use the MQCONNX call
c. Use a client channel table
d. If a SVRCONN is defined, the client will find it.
4. T/F A message exit can be used to control security when running from an WebSphere MQ
client.
Unit Summary
• WebSphere MQ SupportPacs
• WebSphere MQ clients
• Security
Exercise 5
We looked at other aspects of distributed queuing and there was a practical exercise in
using more of its features.
• We described the WebSphere MQ Family SupportPacs and how to obtain them.
• WebSphere MQ clients were explained.
• The WebSphere MQ approach to security was discussed including the Secure Sockets
Layer.
• There was a practical exercise to extend the WebSphere MQ network established in the
previous practical session.
- It may have included the configuration of an WebSphere MQ client.
- It may have resulted in the connection of multiple queue managers.
- Security may have been a necessary consideration.
Appendix A. Checkpoint Solutions
Unit 1
1. T/ F WebSphere MQ only supports asynchronous messaging.
Correct Answer: False
2. WebSphere MQ assured delivery means that:
a. A report of delivery will always be sent back.
b. Unless the entire system goes down, no messages are lost.
c. Messages may be duplicated but never lost.
d. Messages will be delivered with no loss or duplication.
Correct Answer: d
3. Applications place messages on queues by use of the
a. WebSphere MQ Program to Program Interface.
b. WebSphere MQ Message Queue Interface.
c. WebSphere MQ command processor.
Correct Answer: b
Unit 2
1. T/F Queue manager names can be made up of any printable ASCII characters.
2. Alias queues can point to what other queue types?
a. Another alias queue
b. Local queues
c. Model queues
Correct Answer: b
3. Any local queue can be a dead letter queue as long as it is manager.
a. Is identified as the dead letter queue to the queue manager.
b. Has put enabled.
c. Is not being used by any other application.
Correct Answer: a
4. T/F Altering queue attributes can be done while the queue manager is running and the
changes take effect immediately.
Correct Answer: True
5. The NPMCLASS attribute is valid for which of these queues?
a. Local
b. remote
c. model
d. alias
e. cluster queue
Correct Answers: a, c
6. The command CRTMQM -q -u DLQ CHIWINSVR was executed. What was created?
a. queue manager named DLQ
b. a default queue manager named CHIWINSVR with queue DLQ
assigned to the queue manager as the dead letter queue.
c. a queue manager named CHIWINSVR
d. a queue manager named CHIWINSVR with a default
transmission queue DLQ assigned to the queue manager
Correct Answer: b
7. The command endmqm -c DALHOST was issued. What type of shutdown will be
performed?
a. normal
b. preemptive
c. controlled
d. immediate
Correct Answer: c
Unit 3
1. T/F The name of the application to be started in triggering is contained in the TRIGDATA
property of the application queue.
2. A temporary dynamic queue can store:
a. Nonpersistent messages only.
b. Both persistent and non-persistent messages.
c. Reply messages only.
d. Report messages only.
Correct Answer: a
3. When an application issues an MQPUT of a message and explicitly sets priority to a 9,
which of the following best describes the results?
a. The message will be always be delivered before any lower priority messages.
b. The sequence of delivery for messages is always FIFO so it will be delivered in that
order, regardless of priority.
c. It is possible that this message may be delivered after other messages of lower
priority.
Correct Answer: c
4. T/F If a problem is encountered while using the WebSphere MQ Publish/Subscribe
function, it is eligible for support even though it was downloaded and not shipped with the
product.
5. Which of the following are valid control commands for controlling a broker? (Choose 2)
a. rcrmqbrk
b. dspmqbrk
c. crtmqbrk
d. strmqbrk
Correct Answer: b, d
Unit 4
1. The two types of logging supported on HP-UX are:
a. journaling
b. linear
c. circular
d. checkpointing
Correct Answer: b, c
2. A queue manager has just failed. The most recent errors within the queue manager's
directory are contained in a file called:
a. QMGRERR
b. ERRORS
c. AMQERR01.LOG
d. AMQERR.001
Correct Answer: c
3. T/F Non-persistent messages will only be recovered if they were part of a unit of work when
the queue manager failed.
4. What type of log can a damaged object be re-created from?
a. circular
b. journal receiver
c. linear
d. queue manager log
Correct Answer: c
Unit 5
1. T/F NPMSPEED(FAST) is a parameter on a channel that causes the message channel
agent to use MQGMO_SYNCPOINT_IF_PERSISTENT.
2. If the SEQWRAP value on a SENDER channel is different from the value on the
RECEIVER, what will happen?
a. They negotiate to the lower value at channel startup time.
b. The channel will not start.
c. They negotiate to the higher value at channel startup time.
d. Nothing - this is controlled at the SENDER; RECEIVER can not specify SEQWRAP.
e. The value from the SENDER definition takes precedence.
Correct Answer: b
3. A sender channel is defined in a script file with REPLACE. The runmqsc control command
is run using this script while the channel is active.
a. The channel will fail and won't restart without intervention.
b. The active channel won’t be affected by this.
c. Because the channel is active, this command won’t be executed.
d. The channel will fail and any in-transmit messages will be lost.
Correct Answer: a
4. T/F A queue manager can become part of a cluster and messages will flow to its queues as
soon as it is altered to show the name of the cluster it belongs to.
Unit 6
1. T/F All SupportPacs are AS-IS code.
2. T/F A client channel does not require a START CHANNEL command.
3. On a Version 6 client, what method will not work to find the server connection desired?
a. Use SET MQSERVER environment variable
b. Use the MQCONNX call
c. Use a client channel table
d. If a SVRCONN is defined, the client will find it.
Correct Answer: d
4. T/F A message exit can be used to control security when running from an WebSphere MQ
client.
Appendix B. Selected WebSphere MQ Constants
This appendix specifies the values of selected WebSphere MQ constants. For other
WebSphere MQ constants, refer to the MQSeries Application Programming Reference, the
MQSeries Programming Interface Reference Summary, MQSeries Intercommunication, and
MQSeries Programmable System Management.
The constants are grouped according to the parameter or field to which they relate. All
of the names of the constants in a group begin with a common prefix of the form "MQxxxx_”.
where xxxx represents a string of 0 through 4 characters that indicates the nature of the
values defined in that group. The constants are ordered alphabetically by the prefix.
Notes:
1. For constants with numeric values, the values are shown in both decimal and hexadecimal
forms.
2. Hexadecimal values are represented using the notation X'hhhhhhhh', where each "h
"denotes a single hexadecimal digit.
MQCC_ (Completion code)
MQFB_ (Feedback)
Appendix C. Bibliography
This bibliography lists the documentation available for all current WebSphere MQ products.
For more detailed descriptions, check WebSphere MQ Bibliography and Glossary, SC34-
6603, or look at the Library on the WebSphere MQ homepage, as listed at the end of the
appendix.
WebSphere MQ cross-platform publications

These cross-platform publications apply to the following WebSphere MQ products, unless
otherwise stated in the book:
• WebSphere MQ for AIX®
• WebSphere MQ for HP-UX
• WebSphere MQ for iSeries™
• WebSphere MQ for Linux for Intel®
• WebSphere MQ for Linux for zSeries®
• WebSphere MQ for Solaris
• WebSphere MQ for Windows
• WebSphere MQ for z/OS®
An Introduction to Messaging and Queuing, GC33-0805

WebSphere MQ Application Programming Guide, SC34-6595
WebSphere MQ Application Programming Reference, SC34-6596
WebSphere MQ Clients, GC34-6590
WebSphere MQ Constants, SC34-6607
Monitoring WebSphere MQ, SC34-6593
WebSphere MQ Intercommunication, SC34-6587
WebSphere MQ Messages, GC34-6601
WebSphere MQ Migration Information, SC34-6604
WebSphere MQ Programmable Command Formats and Administration Interface, SC34-6598
WebSphere MQ Publish/Subscribe User' Guide, SC34-6606
WebSphere MQ Queue Manager Clusters, SC34-6589
WebSphere MQ Script (MQSC) Command Reference, SC34-6597
WebSphere MQ Security, SC34-6588
WebSphere MQ System Administration Guide, SC34-6584
WebSphere MQ Using C++, SC34-6592
WebSphere MQ Using Java, SC34-6591
WebSphere MQ platform-specific publications
Each WebSphere MQ product is documented in at least one platform-specific publication, in
addition to the WebSphere MQ family books. This section lists those publications, organized
by platform.
WebSphere MQ for AIX
WebSphere MQ for AIX, V6.0 Quick Beginnings, GC34-6478
WebSphere MQ for HP-UX
WebSphere MQ for HP-UX, V6.0 Quick Beginnings, GC34-6479
WebSphere MQ for iSeries
WebSphere MQ for iSeries V6 Quick Beginnings, GC34-6481
WebSphere MQ for iSeries V6 System Administration Guide, SC34-6070
WebSphere MQ for iSeries V6 Application Programming Reference (ILE RPG), SC34-6599
WebSphere MQ for Linux
WebSphere MQ for Linux, V6.0 Quick Beginnings, GC34-6480
WebSphere MQ for Solaris
WebSphere MQ for Solaris, V6.0 Quick Beginnings, GC34-6477
WebSphere MQ for Windows
WebSphere MQ for Windows, V6.0 Quick Beginnings, GC34-6476
WebSphere MQ Using .NET, GC34-6605
IBM WebSphere MQ for Windows, Version 6.0 Using the Component Object Model
Interface, SC34-6594
WebSphere MQ for z/OS
WebSphere MQ for z/OS Concepts and Planning Guide, GC34-6582
WebSphere MQ for z/OS Licensed Program Specifications, GC33-1350
WebSphere MQ for z/OS Problem Determination Guide, GC34-6600
WebSphere MQ for z/OS Program Directory, GI10-2584
WebSphere MQ for z/OS System Administration Guide, SC34-6585
WebSphere MQ for z/OS System Setup Guide, SC34-6583
Softcopy books
The WebSphere MQ books are supplied in two softcopy formats. These are supplied with the
WebSphere MQ product on all platforms.
IBM Eclipse Help System
You can view all of the books in the library through the help system in WebSphere MQ
Explorer. They are also available as a stand-alone IBM Eclipse Help System which you can
install separately from the WebSphere MQ Explorer.
Portable Document Format (PDF)
You can view and print PDF files using the Adobe Acrobat Reader. If you need to obtain the
Adobe Acrobat Reader, or would like up-to-date information about the platforms on which the
Acrobat Reader is supported, visit the Adobe Systems Inc. Web site at:
http://www.adobe.com
Product family Web site

The WebSphere MQ books are also available from the product family Web site at:
http://www.ibm.com/software/integration/mqfamily/
By following links from this Web site you can:

• Obtain latest information about the product family.
• Access the books in HTML and PDF formats.
• Download a WebSphere MQ SupportPac.
Appendix D. Glossary of terms and abbreviations
This glossary defines WebSphere MQ terms and abbreviations used in this book. If you
do not find the term you are looking for, refer to the Index or the IBM Dictionary of Computing,
New York: McGraw-Hill, 1994.
This glossary includes terms and definitions from the American National Dictionary for
Information Systems, ANSI X3.172-1990, copyright 1990 by the American National Standards
Institute (ANSI). Copies may be purchased from the American National Standards Institute,
11 West 42 Street, New York, New York 10036. Definitions are identified by the symbol (A)
after the definition.
• The ANSI/EIA Standard— 440-A: Fiber Optic Terminology. Copies may be purchased
from the Electronic Industries Association, 2001 Pennsylvania Avenue, N.W., Washington DC
20006. Definitions are identified by the symbol (E) after the definition.
• The Information Technology Vocabulary, developed by Subcommittee 1, Joint
Technical Committee 1, of the International Organization for Standardization and the
International Electrotechnical Commission (ISO/IEC JTC1/SC1). Definitions of published parts
of this vocabulary are identified by the symbol (I) after the definition; definitions from draft
international standards, committee drafts, and working papers being developed by ISO/IEC
JTC1/SC1 are identified by the symbol (T) after the definition, indicating that final agreement
has not yet been reached among the participating National Bodies of SC1.
A
abend reason code. A 4-byte hexadecimal code that uniquely identifies a problem with
WebSphere MQ for z/OS. A complete list of WebSphere MQ for z/OS abend reason codes
and their explanations is contained in the WebSphere MQ for z/OS Messages and Codes
manual.
abstract class. A class that can only be instantiated as a derivation.
active log. See recovery log.
adapter. An interface between WebSphere MQ for z/OS and TSO, IMS, CICS, or batch
address spaces. An adapter is an attachment facility that enables applications to access
WebSphere MQ services.
address space. The area of virtual storage available for a particular job.
address space identifier (ASID). A unique, system-assigned identifier for an address space.
administration bag. In the MQAI, a type of data bag that is created for administering
WebSphere MQ by implying that it can change the order of data items, create lists, and check
selectors within a message.
administrator commands. WebSphere MQ commands used to manage WebSphere MQ
objects, such as queues, processes, and namelist.
Advanced Program-to-Program Communication (APPC). The general facility
characterizing the LU 6.2 architecture and its various implementations in products.
affinity. An association between objects that have some relationship or dependency upon
each other.
alert. A message sent to a management services focal point in a network to identify a
problem or an impending problem.
alert monitor. In WebSphere MQ for z/OS, a component of the CICS adapter that handles
unscheduled events occurring as a result of connection requests to WebSphere MQ for z/OS.
alias queue object. An WebSphere MQ object, the name of which is an alias for a base
queue defined to the local queue manager. When an applicator or a queue manager uses an
alias queue, the alias name is resolved and the requested operation is performed on the
associated base queue.
allied address space. See ally.
ally. An OS/390 address space that is connected to WebSphere MQ for z/OS.
alternate user security. A security feature in which the authority of one user ID can be used
by another user ID; for example, to open an WebSphere MQ object.
APAR. Authorized program analysis report.
APC. Advanced Program Communication.
APPC. Advanced Program-to-Program Communication.
application-defined format. In message queuing, application data in a message, which has
a meaning defined by the user application. Contrast with built-in format.
application environment. The software facilities that are accessible by an application
program. On the z/OS platform, CICS and IMS are examples of application environments.
application log. In Windows, a log that records significant application events.
application queue. A queue used by an application.
archive log. See recovery log.
ARM. Automatic Restart Management
ASID. Address space identifier.
asynchronous messaging. A method of communication between programs in which
programs place messages on message queues. With asynchronous messaging, the sending
program proceeds with its own processing without waiting for a reply to its message. Contrast
with synchronous messaging.
attribute. One of a set of properties that defines the characteristics of an WebSphere MQ
object.
attribute. A property of an object or class, which can be distinguished distinctly from any
other properties. Attributes often describe state information.
authorization checks. Security checks that are performed when a user tries to issue
administration commands against an object, for example to open a queue or connect to a
queue manager.
authorization file. In WebSphere MQ on UNIX systems, a file that provides security
definitions for an object, a class of objects, or all classes of objects.
authorization service. In WebSphere MQ on UNIX systems, MQSeries for OS/2 Warp, and
WebSphere MQ for Windows, a service that provides authority checking of commands and
MQI calls for the user identifier associated with the command or call.
authorized program analysis report (APAR). A report of a problem caused by a suspected
defect in a current, unaltered release of a program.
Automatic Restart Management (ARM). An recovery function that can improve the
availability of specific batch jobs or started tasks, and therefore result in faster resumption of
productive work.
B
backout. An operation that reverses all the changes made during the current unit of recovery
or unit of work. After the operation is complete, a new unit of recovery or unit of work begins.
Contrast with commit.
bag. See data bag.
basic mapping support (BMS). An interface between CICS and application programs that
formats input and output display data and routes multiple-page output messages without
regard for control characters used by various terminals.
behavior. The functionality embodied within a method.
BMS. Basic mapping support.
bootstrap data set (BSDS). A VSAM data set that contains:
• An inventory of all active and archived log data sets known to WebSphere MQ for z/OS
• A wrap-around inventory of all recent WebSphere MQ for z/OS activity
The BSDS is required if the WebSphere MQ for z/OS subsystem has to be restarted.
browse. In message queuing, to use the MQGET call to copy a message without removing it
from the queue. See also get.
browse cursor. In message queuing, an indicator used when browsing a queue to identify
the message that is next in sequence.
BSDS. Bootstrap data set.
buffer pool. An area of main storage used for WebSphere MQ for z/OS queues, messages,
and object definitions. See also page set.
built-in format. In message queuing, application data in a message, which has a meaning
defined by the queue manager. Synonymous with in-built format. Contrast with application-
defined format.
C
call back. In WebSphere MQ, a requester message channel initiates a transfer from a sender
channel by first calling the sender, then closing down and awaiting a call back.
CCF. Channel control function.
CCSID. Coded character set identifier.
CDF. Channel definition file.
channel. See message channel.
channel control function (CCF). In WebSphere MQ, a program to move messages from a
transmission queue to a communication link, and from a communication like to a local queue,
together with an operator panel interface to allow the setup and control of channels.
channel definition file (CDF). In WebSphere MQ, a file containing communication channel
definitions that associate transmission queues with communication links.
channel event. An event indicating that a channel instance has become available or
unavailable. Channel events are generated on the queue managers at both ends of the
channel.
channel exit program. A user-written program that can be entered from one of a defined
number of places during channel operation.
channel initiator. A component of WebSphere MQ distributed queuing, which monitors the
initiation queue to see when triggering criteria have been met and then starts the sender
channel.
channel listener. A component of WebSphere MQ distributed queuing, which monitors the
network for a startup request and then starts the receiving channel.
checkpoint. (1) A time when significant information is written on the log. Contrast with
syncpoint. (2) In WebSphere MQ on UNIX systems, the point in time when a data record
described in the log is the same as the data record in the queue. Checkpoints are generated
automatically and are used during the system restart process.
CI. Control interval.
CICS transaction. In CICS, a unit of application processing, usually comprising one or more
units of work.
circular logging. In WebSphere MQ on UNIX systems, MQSeries for OS/2 Warp, and
WebSphere MQ for Windows, the process of keeping all restart data in a ring of log files.
Logging fills the first file in the ring and then moves on to the next, until all the files are full. At
this point, logging goes back to the first file in the ring and starts again, if the space has been
freed or is no longer needed. Circular logging is used during restart recovery, using the log to
roll back transactions that were in progress when the system stopped. Contrast with linear
logging.
CL. Control Language.
class. An abstract model of behavior; a collection of methods. A class typically provides some
unique behavior, in addition to other, common, behavior. The distinction between unique and
common behavior is effected using either inheritance, or multiple interfaces.
class hierarchy. Classes related by inheritance.
class library. A bundled collection of classes, usually related.
client. A run-time component that provides access to queuing services on a server for local
user applications. The queues used by the applications reside on the server. See also
WebSphere MQ client.
client application. An application, running on a workstation and linked to a client, that gives
the application access to queuing services on a server.
client connection channel type. The type of MQI channel definition associated with an
WebSphere MQ client. See also server connection channel type.
CLUSRCVR. Cluster-receiver channel definition.
CLUSSDR. Cluster-sender channel definition.
cluster. A network of queue managers that are logically associated in some way.
cluster queue. A queue that is hosted by a cluster queue manager and made available to
other queue managers in the cluster.
cluster queue manager. A queue manager that is a member of a cluster. A queue manager
may be a member of more than one cluster.
cluster-receiver channel (CLUSRCVR). A channel on which a cluster queue manager can
receive messages from other queue managers in the cluster and cluster information from the
repository queue managers.
cluster-sender channel (CLUSSDR). A channel on which a cluster queue manager can
send messages to other queue managers in the cluster and cluster information to the
repository queue managers.
cluster transmission queue. A transmission queue that transmits all messages from a
queue manager to any other queue manager that is in the same cluster. The queue is called
SYSTEM.CLUSTER.TRANSMIT.QUEUE.
coded character set identifier (CCSID). The name of a coded set of characters and their
code point assignments.
command. In WebSphere MQ, an administration instruction that can be carried out by the
queue manager.
command bag. In the MQAI, a type of bag that is created for administering WebSphere MQ
objects, but cannot change the order of data items nor create lists within a message.
command prefix (CPF). In WebSphere MQ for z/OS, a character string that identifies the
queue manager to which WebSphere MQ for z/OS commands are directed, and from which
WebSphere MQ for z/OS operator messages are received.
command processor. The WebSphere MQ component that processes commands.
command server. The WebSphere MQ component that reads commands from the system-
command input queue, verifies them, and passes valid commands to the command
processor.
commit. An operation that applies all the changes made during the current unit of recovery or
unit of work. After the operation is complete, a new unit of recovery or unit of work begins.
Contrast with backout.
Common Run-Time Environment (CRE). A set of services that enable system and
application programmers to write mixed-language programs. These shared, run-time services
can be used by C, COBOL85, FORTRAN, Pascal, and TAL programs.
completion code. A return code indicating how an MQI call has ended.
configuration file. In WebSphere MQ on UNIX systems, MQSeries for OS/2 Warp, and
WebSphere MQ for Windows, a file that contains configuration information related to, for
example, logs, communications or installable services. Synonymous with .ini file. See also
stanza.
connect. To provide a queue manager connection handle, which an application uses on
subsequent MQI calls. The connection is made either by the MQCONN call, or automatically
by the MQOPEN call.
connection handle. The identifier or token by which a program accesses the queue manager
to which it is connected.
constructor. A special method used to initialize an object.
context. Information about the origin of a message.
context security. In WebSphere MQ, a method of allowing security to be handled such that
messages are obliged to carry details of their origins in the message descriptor.
control command. In WebSphere MQ on UNIX systems, MQSeries for OS/2 Warp, and
WebSphere MQ for Windows, a command that can be entered interactively from the
operating system command line. Such a command requires only that the WebSphere MQ
product be installed; it does not require a special utility or program to run it.
control interval (CI). A fixed-length area of direct access storage in which VSAM stores
records and creates distributed free spaces. The control interval is the unit of information that
VSAM transmits to or from direct access storage.
Control Language (CL). In WebSphere MQ for iSeries, UNIX, Windows, and MQSeries for
OS/2 Warp, a language that can be used to issue commands, either at the command line or
by writing a CL program.
controlled shutdown. See quiesced shutdown.
CPF. Command prefix.
CRE. Common Run-Time Environment.
Cross Systems Coupling Facility (XCF). Provides the coupling services that allow
authorized programs in a multisystem environment to communicate with programs on the
same or different systems.
D
DAE. Dump analysis and elimination.
daemon. In UNIX systems, a program that runs unattended to perform a standard service.
Some daemons are triggered automatically to perform their tasks; others operate periodically.
data bag. In the MQAI, a bag that allows you to handle properties (or parameters) of objects.
data item. In the MQAI, an item contained within a data bag. This can be an integer item or a
character-string item, and a user item or a system item.
data conversion interface (DCI). The WebSphere MQ interface to which customer-or
vendor-written programs that convert application data between different machine encodings
and CCSIDs must conform. A part of the WebSphere MQ Framework.
datagram. The simplest message that WebSphere MQ Supports. This type of message does
not require a reply.
DCE. Distributed Computing Environment.
DCE principal. A user ID that uses the distributed computing environment.
DCI. Data conversion interface.
data-conversion service. A service that converts application data to the character set and
encoding that are required by applications on other platforms.
dead-letter queue (DLQ). A queue to which a queue manager or application sends
messages that it cannot deliver to their correct destination.
dead-letter queue handler. A WebSphere MQ-supplied utility that monitors a dead-letter
queue (DLQ) and processes messages on the queue in accordance with a user-written rules
table.
default object. A definition of an object (for example, a queue) with all attributes defined. If a
user defines an object but does not specify all possible attributes for that object, the queue
manager uses default attributes in place of any that were not specified.
deferred connection. A pending event that is activated when a CICS subsystem tries to
connect to WebSphere MQ for z/OS before WebSphere MQ for z/OS has been started.
dequeue. To remove a message from a queue. Contrast with enqueue.
derivation. The refinement or extension of one class from another.
desktop clients. A group of WebSphere MQ clients that run on the smaller platforms such as
DOS and Windows 3.1. Desktop clients are supplied with most of the WebSphere MQ
products; the members of the group may be different for the different products.
distributed application. In message queuing, a set of application programs that can each be
connected to a different queue manager, but that collectively constitute a single application.
Distributed Computing Environment (DCE). Middleware that provides some basic services,
making the development of distributed applications easier. DCE is defined by the Open
Software Foundation (OSF).
distributed queue management (DQM). In message queuing, the setup and control of
message channels to queue managers on other systems.
distribution list. A list of queues to which a message can be put using a single MQPUT or
MQPUT1 statement.
DLQ. Dead-letter queue.
DQM. Distributed queue management.
dual logging. A method of recording WebSphere MQ for z/OS activity, where each change is
recorded on two data sets, that if a restart is necessary and one data set is unreadable, the
other can be used. Contrast with single logging.
dual mode. See dual logging.
dump analysis and elimination (DAE). An service that enables an installation to suppress
SVC dumps and ABEND SYSUDUMP dumps that are not needed because they duplicate
previously written dumps.
dynamic queue. A local queue created when a program opens a model queue object. See
also permanent dynamic queue and temporary dynamic queue.
E
encapsulation. The restriction whereby class behavior may only be observed using the
methods of that class.
enqueue. To put a message on a queue. Contrast with dequeue.
environment. See application environment.
environment variable. One of a series of variables that control the way your operating
system runs and what external devices it will recognize. You can define these variables in
your system profile or override them temporarily with command-line commands.
ESM. External security manager.
ESTAE. Extended specify task abnormal exit.
event. See channel event, instrumentation event, performance event, and queue manager
event.
event data. In an event message, the part of the message data that contains information
about the event (such as the queue manager name, and the application that gave rise to the
event). See also event header.
event header. In an event message, the part of the message data that identifies the event
type of the reason code for the event.
event log. See application log.
event message. Contains information (such as the category of event, the name of the
application that caused the event, and queue manager statistics) relating to the origin of an
instrumentation event in a network of WebSphere MQ system.
event queue. The queue onto which the queue manager puts an event message after it
detects an event. Each category of event (queue manager, performance, or channel event)
has its own event queue.
Event Viewer. A tool provided by Windows to examine and manage log files.
exclusive method. A method that is not intended to exhibit polymorphism; one with specific
effect.
extended specify task abnormal exit (ESTAE). A z/OS macro that provides recovery
capability and gives control to the specified exit routine for processing, diagnosing an abend,
or specifying a retry address.
external security manager (ESM). A security product that is invoked by the z/OS system
Authorization Facility. RACF is an example of an ESM.
F
FAP. Formats and Protocols.
FFST. First Failure Support Technology.
FIFO. First-in-first-out.
First Failure Support Technology (FFST). Used by WebSphere MQ for iSeries, UNIX,
Windows, and MQSeries for OS/2 Warp to detect and report software problems.
first-in-first-out (FIFO). A queuing technique in which the next item to be retrieved is the item
that has been in the queue for the longest time. (A)
forced shutdown. A type of shutdown of the CICS adapter where the adapter immediately
disconnects from WebSphere MQ for z/OS, regardless of the state of any currently active
tasks. Contrast with quiesced shutdown.
format. In message queuing, a term used to identify the nature of application data in a
message. See also built-in format and application-defined format.
Formats and Protocols (FAP). The WebSphere MQ FAPs define how queue managers
communicate with one another, and also how WebSphere MQ clients communicate with
server queue managers.
Framework. In WebSphere MQ, a collection of programming interfaces that allow customers
or vendors to write programs that extend or replace certain functions provided in WebSphere
MQ products. The interfaces are:
• WebSphere MQ data conversion interface (DCI)
• WebSphere MQ message channel interface (MCI)
• WebSphere MQ name service interface (NSI)
• WebSphere MQ security enabling interface (SEI)
• WebSphere MQ trigger monitor interface (TMI)
friend class. A class that is regarded as being derived from another, while this is not the
case, for the purpose of accessing protected methods and instance data.
FRR. Functional recovery routine.
full repository. A complete set of information about every queue manager in a cluster. This
set of information is called the repository or sometimes the full repository and is held usually
by two of the queue managers in the cluster. Contrast with partial repository.
function. A classic function call such as is supported by the C programming language.
functional recovery routine (FRR). A z/OS recovery/termination manager facility that
enables a recovery routine to gain control in the event of a program interrupt.
G
GCPC. Generalized command preprocessor.
generalized command preprocessor (GCPC). An WebSphere MQ for z/OS component that
processes WebSphere MQ commands and runs them.
Generalized Trace Facility (GTF). A z/OS service program that records significant system
events, such as supervisor calls and start I/O operations, for the purpose of problem
determination.
get. In message queuing, to use the MQGET call to remove a message from a queue. See
also browse.
global trace. An WebSphere MQ for z/OS trace option where the trace data comes from the
entire WebSphere MQ for z/OS subsystem GTF. Generalized Trace Facility.
H
handle. See connection handle and object handle.
hardened message. A message that is written to auxiliary (disk) storage so that the message
will not be lost in the event of a system failure. See also persistent message.
heartbeat flow. A pulse that is passed from a sending MCA to a receiving MCA when there
are no messages to send. The pulse unblocks the receiving MCA, which otherwise, would
remain in a wait state until a message arrived or the disconnect interval expired.
heartbeat interval. The time, in seconds, that is to elapse between heartbeat flows.
I
ICE. Intersystem Communications Environment is a family of Tandem-based software
products that enables you to access a variety of applications on Tandem computers.
IFCID. A trace event number.
immediate shutdown. In WebSphere MQ, a shutdown of a queue manager that does not
wait for applications to disconnect. Current MQI calls are allowed to complete, but new MQI
calls fail after an immediate shutdown has been requested. Contrast with quiesced shutdown
and preemptive shutdown.
in-built format. See built-in format.
index. In the MQAI, a means of referencing data items.
in-doubt unit of recovery. In WebSphere MQ, the status of a unity of recovery for which a
syncpoint has been requested but not yet confirmed.
inheritance. The ability of a class to include the behavior of another through refinement and
extension; only refined and extended methods are defined in the derived class, thereby
preserving encapsulation.
.ini file. See configuration file.
initialization file. In MQSeries for AS/400, a file that contains two parameters; the TCP/IP
listener port number and the maximum number of channels that can be current at a time. The
file is called QMINI.
initialization input data sets. Data sets used by WebSphere MQ for z/OS when it starts up.
initiation queue. A local queue on which the queue manager puts trigger messages.
input/output parameter. A parameter of an MQI call in which you supply information when
you make the call, and in which the queue manager changes the information when the call
completes or fails.
input parameter. A parameter of an MQI call in which you supply information when you make
the call.
insertion order. In the MQAI, the order that data items are placed into a data bag.
installable services. In WebSphere MQ on UNIX systems, MQSeries for OS/2 Warp, and
WebSphere MQ for Windows, additional functionality provides as independent components.
The installation of each component is optional: in-house or third-party components can be
used instead. See also authorization service, name service, and user Jennifer service.
instance. An object.
instance data. State information associated with an object.
instrumentation event. A facility that can be used to monitor the operation of queue
managers in a network of WebSphere MQ systems. WebSphere MQ provides instrumentation
events for monitoring queue manager resource definitions, performance conditions, and
channel conditions. Instrumentation events can be used by a user-written reporting
mechanism in an administration application that displays the events to a system operator.
They also allow applications acting as agents for other administration networks to monitor
reports and create the appropriate alerts.
Interactive Problem Control System (IPCS). A component of z/OS that permits online
problem management, interactive problem diagnosis, online debugging for disk-resident
abend dumps, problem tracking, and problem reporting.
Interactive System Productivity Facility (ISPF). An IBM licensed program that serves as a
full-screen editor and dialog manager. It is used for writing application programs, and provides
a means of generating standard screen panels and interactive dialogues between the
application programmer and terminal user.
interface. An abstract model of behavior; a collection of functions or methods.
Internet Protocol (IP). A protocol used to route data from its source to its destination in an
Internet environment. This is the base layer, on which other protocol layers, such as TCP and
UDP are built.
Intersystem communication. In CICS, communication between separate systems by means
of SNA networking facilities or by means of the application-to-application facilities of an SNA
access method.
IP. Internet Protocol.
IPCS. Interactive Problem Control System.
ISC. Intersystem communication.
ISPF. Interactive System Productivity Facility.
L
linear logging. In WebSphere MQ on UNIX systems, MQSeries for OS2 Warp, and
WebSphere MQ for Windows, the process of keeping restart data in a sequence of files. New
files are added to the sequence as necessary. The space in which the data is written is not
reused until the queue manager is restarted. Contrast with circular logging.
listener. In WebSphere MQ distributed queuing, a program that monitors for incoming
network connections.
local definition. A WebSphere MQ object belonging to a local queue manager.
local definition of a remote queue. A WebSphere MQ object belonging to a local queue
manager. This object defines the attributes of a queue that is owned by another queue
manager. In addition, it is used for queue-manager aliasing and reply-to-queue aliasing.
locale. On UNIX systems, a subset of a user's environment that defines conventions for a
specific culture (such as time, numeric, or monetary formatting and character classification,
collation, or conversion). The queue manager CCSID is derived from the locale of the user ID
that created the queue manager.
local queue. A queue that belongs to the local queue manager. A local queue can contain a
list of messages waiting to be processed. Contrast with remote queue.
local queue manager. The queue manager to which a program is connected and that
provides message queuing services to the program. Queue managers to which a program is
not connected are called remote queue managers, even if they are running on the same
system as the program.
log. In WebSphere MQ, a file recording the work done by queue managers while they
receive, transmit, and deliver messages, to enable them to recover in the event of failure.
log control file. In WebSphere MQ on UNIX systems, MQSeries for OS/2 Warp, and
WebSphere MQ for Windows, the file containing information needed to monitor the use of log
files (for example, their size and location, and the name of the next available file).
log file. In WebSphere MQ on UNIX systems, MQSeries for OS/2 Warp, and WebSphere MQ
for Windows, a file in which all significant changes to the data controlled by a queue manager
are recorded. If the primary log files become full, WebSphere MQ allocates secondary log
files.
logical unit of work (LUW). See unit of work.
luname. The name of the logical unit on your workstation, that is the name of the software
that interfaces between your applications and the network.
LUWID. Logical unit of work identifier.
LU 6.2. A type of logical unit (LU) that supports general communication between programs in
a distributed processing environment.
M
machine check interrupt. An interruption that occurs as a result of an equipment malfunction
or error. A machine check interrupt can be either hardware recoverable, software recoverable,
or nonrecoverable.
marshalling. The serialization of data.
MCA. Message channel agent.
MCI. Message channel interface.
media image. In WebSphere MQ on UNIX systems, MQSeries for OS/2 Warp, and
WebSphere MQ for Windows, the sequence of log records that contain an image of an object.
The object can be re-created from this image.
message. In message queuing applications, a communication sent between programs. See
also persistent message and nonpersistent message.
message. In system programming, information intended for the terminal operator or system
administrator.
message channel. In distributed message queuing, a mechanism for moving messages from
one queue manager to another. A message channel comprises two message channel agents
(a sender at one end and a receiver at the other end) and a communication link. Contrast with
MQI channel.
message channel agent (MCA). A program that transmits prepared messages from a
transmission queue to a communication link, or from a communication link to a destination
queue. See also message queue interface.
message channel interface (MCI). The WebSphere MQ interface to which customer- or
vendor-written programs that transmit messages between an WebSphere MQ queue
manager and another messaging system must conform. A part of the WebSphere MQ
Framework.
message descriptor. Control information describing the message format and presentation
that is carried as part of an WebSphere MQ message. The format of the message descriptor
is defined by the MQMD structure.
message flow control. A distributed queue management task that involves setting up and
maintaining message routes between queue managers.
message format service (MFS). In IMS, and editing facility that allows application programs
to deal with simple logical messages, instead of device-dependent data, thus simplifying the
application development process. See message input descriptor and message output
descriptor.
message group. A group of logical messages. Logical grouping of messages allows
applications to group messages that are similar and to ensure the sequence of the messages.
message input descriptor (MID). In IMS, the MFS control block that describes the format of
the data presented to the application program. Contrast with message output descriptor.
message output descriptor (MOD). In IMS, the MFS control block that describes the format
of the output data produced by the application program. Contrast with message input
descriptor.
message priority. In WebSphere MQ, an attribute of a message that can affect the order in
which messages on a queue are retrieved, and whether a trigger event is generated.
message queue. Synonym for queue.
message queue interface (MQI). The programming interface provided by the WebSphere
MQ queue managers. This programming interface allows application programs to access
message queuing services.
message queue management. The Message Queue Management (MQM) facility in
MQSeries for Tandem NSK V2.2 uses PCF command formats and control commands.
MQM runs as a PATHWAY SCOBOL requester under the Terminal Control Process (TCP)
and uses an MQM SERVERCLASS server, which invokes the C language API to perform
PCF commands. There is a separate instance of MQM for each queue manager configured
on a system, since each queue manager is controlled under its own PATHWAY configuration.
Consequently, an MQM is limited to the management of the queue manager to which it
belongs.
message queuing. A programming technique in which each program within an application
communicates with the other programs by putting messages on queues.
message-retry. An option available to an MCA that is unable to deliver a message. The MCA
can wait for a predefined amount of time and then try to send the message again.
message segment. One of a number of segments of a message that is too large either for
the application or for the queue manager to handle.
message sequence numbering. A programming technique in which messages are given
unique numbers during transmission over a communication link. This enables the receiving
process to check whether all messages are received, to place them in a queue in the original
order, and to discard duplicate messages.
messaging. See synchronous messaging and asynchronous messaging.
method. A means of invoking a particular behavior in an object or class.
MFS. Message format service.
model queue object. A set of queue attributes that act as a template when a program
creates a dynamic queue.
MQAI. MQSeries Administration Interface.
MQI. Message queue interface.
MQI channel. Connects an WebSphere MQ client to a queue manager on a server system,
and transfers only MQI calls and responses in a bidirectional manner. Contrast with message
channel.
MQSC. MQSeries commands.
WebSphere MQ. A family of IBM licensed programs that provides message queuing services.
MQSeries Administration Interface (MQAI). A programming interface to WebSphere MQ.
WebSphere MQ client. Part of an WebSphere MQ product that can be installed on a system
without installing the full queue manager. The WebSphere MQ client accepts MQI calls from
applications and communicates with a queue manager on a server system.
WebSphere MQ commands (MQSC). Human-readable commands, uniform across all
platforms, that are used to manipulate WebSphere MQ objects. Contrast with programmable
command format (PCF). Contrast with programmable command format (PCF).
WebSphere MQ server. An WebSphere MQ server is a queue manager that provides
queuing services to one or more clients. All the WebSphere MQ objects, for example queues,
exist only on the queue manager system, that is, on the MQI server machine. A server can
support normal local MQI applications as well.
multi-hop. To pass through one or more intermediate queue managers when there is no
direct communication link between a source queue manager and the target queue manager.
N
namelist. An WebSphere MQ object that contains a list of names, for example, queue
names.
name service. In WebSphere MQ on UNIX systems, MQSeries for OS/2 Warp, and
WebSphere MQ for Windows, the facility that determines which queue manager owns a
specified queue.
name service interface (NSI). The WebSphere MQ interface to which customer- or vendor-
written programs that resolve queue-name ownership must conform. A part of the WebSphere
MQ Framework.
name transformation. In WebSphere MQ on UNIX systems, WebSphere MQ for OS/2 Warp,
and WebSphere MQ for Windows, an internal process that changes a queue manager name
so that it is unique and valid for the system being used. Externally, the queue manager name
remains unchanged.
nested bag. In the MQAI, a system bag that is inserted into another data bag
nesting. In the MQAI, a means of grouping information returned from WebSphere MQ.
NetBIOS. Network Basic Input/Output System. An operating system interface for application
programs used on IBM personal computers that are attached to the IBM Token-Ring Network.
New Technology File System (NTFS). A Windows recoverable file system that provides
security for files.
nonpersistent message. A message that does not survive a restart of the queue manager.
Contrast with persistent message.
NSI. Name service interface.
NTFS. New Technology File System.
null character. The character that is represented byX’00.
O
OAM. Object authority manager.
object. In WebSphere MQ, an object is a queue manager, a queue, a process definition, a
channel, a namelist, or a storage class (z/OS only).
object. In C an object is an instance of a class.
object authority manager (OAM). In WebSphere MQ on UNIX systems and WebSphere MQ
for Windows, the default authorization service for command and object management. The
OAM can be replaced by, or run in combination with, a customer-supplied security service.
object descriptor. A data structure that identifies a particular WebSphere MQ object.
Included in the descriptor are the name of the object and the object type.
object handle. The identifier or token by which a program accesses the WebSphere MQ
object with which it is working.
off-loading. In WebSphere MQ for z/OS, an automatic process whereby a queue manager's
active log is transferred to its archive log.
Open Transaction Manager Access (OTMA). A transaction-based, connectionless
client/server protocol. It functions as an interface for host-based communications servers
accessing IMS TM applications through the Cross Systems Coupling Facility (XCF).
OTMA is implemented in an sysplex environment. Therefore, the domain of OTMA is
restricted to the domain of XCF.
OTMA. Open Transaction Manager Access.
output log-buffer. In WebSphere MQ for z/OS, a buffer that holds recovery log records
before they are written to the archive log.
output parameter. A parameter of an MQI call in which the queue manager returns
information when the call completes or fails.
overloading. The existence of more than one flavor of method with the same name or
operator, but with different signatures, within a class; while the name or operator remains the
same, the method parameters differ, each signature requiring a separate implementation.
Such methods usually exhibit the same behavior, despite differences in signature.
P
page set. A VSAM data set used when WebSphere MQ for z/OS moves data (for example,
queues and messages) from buffers in main storage to permanent backing storage (DASD).
parent class. A class from which another is derived.
partial repository. A partial set of information about queue managers in a cluster. A partial
repository is maintained by all cluster queue managers that do not host a full repository.
PCF. Programmable command format.
PCF command. See programmable command format.
pending event. An unscheduled event that occurs as a result of a connect request from a
CICS adapter.
percolation. In error recovery, the passing along a preestablished path of control from a
recovery routine to a higher-level recovery routine.
performance event. A category of event indicating that a limit condition has occurred.
performance trace. An WebSphere MQ trace option where the trace data is to be used for
performance analysis and tuning.
permanent dynamic queue. A dynamic queue that is deleted when it is closed only if
deletion is explicitly requested. Permanent dynamic queues are recovered if the queue
manager fails, so they can contain persistent messages. Contrast with temporary dynamic
queue.
persistent message. A message that survives a restart of the queue manager. Contrast with
nonpersistent message.
ping. In distributed queuing, a diagnostic aid that uses the exchange of a test message to
confirm that a message channel or a TCP/IP connection is functioning.
platform. In WebSphere MQ, the operating system under which a queue manager is running.
point of recovery. In WebSphere MQ for z/OS, the term used to describe a set of backup
copies of WebSphere MQ for z/OS page sets and the corresponding log data sets required to
recover these page sets. These backup copies provide a potential restart point in the event of
page set loss (for example, page set I/O error).
polymorphism. The characteristic whereby a method can be applied to a variety of classes,
with consequent various effects: for example, an open method could be applied equally to
book and door class objects.
preemptive shutdown. In WebSphere MQ, a shutdown of a queue manager that does not
wait for connected applications to disconnect, nor for current MQI calls to complete. Contrast
with immediate shutdown and quiesced shutdown.
principal. In WebSphere MQ on UNIX systems, MQSeries for OS/2 Warp, and WebSphere
MQ for Windows, a term used for a user identifier. Used by the object authority manager for
checking authorizations to system resources.
private methods and instance data. Methods and instance data that are only accessible to
the implementation of the same class.
process definition object. A WebSphere MQ object that contains the definition of an
WebSphere MQ application. For example, a queue manager uses the definition when it works
with trigger messages.
programmable command format (PCF). A type of WebSphere MQ message used by:
• User administration applications, to put PCF commands onto the system command input
queue of a specified queue manager
• User administration applications, to get the results of a PCF command from a specified
queue manager
• A queue manager, as a notification that an event has occurred
Contrast with MQSC.
program temporary fix (PTF). A solution or by-pass of a problem diagnosed by IBM field
engineering as the result of a defect in a current, unaltered release of a program.
protected methods and instance data. Methods and instance data that are only accessible
to the implementations of the same or derived classes, or from friend classes.
PTF. Program temporary fix.
public methods and instance data. Methods and instance data that are accessible to all
classes.
Q
queue. An WebSphere MQ object. Message queuing applications can put messages on, and
get messages from, a queue. A queue is owned and maintained by a queue manager. Local
queues can contain a list of messages waiting to be processed. Queues of other types cannot
contain messages— they point to other queues, or can be used as models for dynamic
queues.
queue manager. (1) A system program that provides queuing services to applications. It
provides an application programming interface so that programs can access messages on the
queues that the queue manager owns. See also local queue manager and remote queue
manager. (2) An WebSphere MQ object that defines the attributes of a particular queue
manager.
queue manager event. An event that indicates:
• An error condition has occurred in relation to the resources used by a queue manager.
For example, a queue is unavailable.
• A significant change has occurred in the queue manager. For example, a queue
manager has stopped or started.
queuing. See message queuing.
quiesced shutdown. (1) In WebSphere MQ, a shutdown of a queue manager that allows all
connected applications to disconnect. Contrast with immediate shutdown and preemptive
shutdown. (2) A type of shutdown of the CICS adapter where the adapter disconnects from
WebSphere MQ, but only after all the currently active tasks have been completed. Contrast
with forced shutdown.
quiescing. In WebSphere MQ, the state of a queue manager prior to it being stopped. In this
state, programs are allowed to finish processing, but no new programs are allowed to start.
R
RBA. Relative byte address.
reason code. A return code that describes the reason for the failure or partial success of an
MQI call.
receiver channel. In message queuing, a channel that responds to a sender channel, takes
messages from a communication link, and puts them on a local queue.
recovery log. In WebSphere MQ for z/OS, data sets containing information needed to
recover messages, queues, and the WebSphere MQ subsystem. WebSphere MQ for z/OS
writes each record to a data set called the active log. When the active log is full, its contents
are off loaded to a DASD or tape data set called the archive log. Synonymous with log.
recovery termination manager (RTM). A program that handles all normal and abnormal
termination of tasks by passing control to a recovery routine associated with the terminating
function.
reference message. A message that refers to a piece of data that is to be transmitted. The
reference message is handled by message exit programs, which attach and detach the data
from the message so allowing the data to be transmitted without having to be stored on any
queues.
Registry. In Windows, a secure database that provides a single source for system and
application configuration data.
Registry Editor. In Windows, the program item that allows the user to edit the Registry.
Registry Hive. In Windows, the structure of the data stored in the Registry.
relative byte address (RBA). The displacement in bytes of a stored record or control interval
from the beginning of the storage space allocated to the data set to which it belongs.
remote queue. A queue belonging to a remote queue manager. Programs can put messages
on remote queues, but they cannot get messages from remote queues. Contrast with local
queue.
remote queue manager. To a program, a queue manager that is not the one to which the
program is connected.
remote queue object. See local definition of a remote queue.
remote queuing. In message queuing, the provision of services to enable applications to put
messages on queues belonging to other queue managers.
reply message. A type of message used for replies to request messages. Contrast with
request message and report message.
reply-to queue. The name of a queue to which the program that issued an MQPUT call
wants a reply message or report message sent.
report message. A type of message that gives information about another message. A report
message can indicate that a message has been delivered, has arrived at its destination, has
expired, or could not be processed for some reason. Contrast with reply message and
request message.
repository. A collection of information about the queue managers that are members of a
cluster. This information includes queue manager names, their locations, their channels, what
queues they host, and so on. See also full repository and partial repository.
repository queue manager. A queue manager that hosts the full repository of information
about a cluster.
requester channel. In message queuing, a channel that may be started remotely by a sender
channel. The requester channel accepts messages from the sender channel over a
communication link and puts the messages on the local queue designated in the message.
See also server channel.
request message. A type of message used to request a reply from another program.
Contrast with reply message and report message.
RESLEVEL. In WebSphere MQ for z/OS, an option that controls the number of CICS user
IDs checked for API-resource security in WebSphere MQ for z/OS.
resolution path. The set of queues that are opened when an application specifies an alias or
a remote queue on input to an MQOPEN call.
resource. Any facility of the computing system or operating system required by a job or task.
In WebSphere MQ for z/OS, examples of resources are buffer pools, page sets, log data sets,
queues, and messages.
resource manager. An application, program, or transaction that manages and controls
access to shared resources such as memory buffers and data sets. WebSphere MQ, CICS,
and IMS are resource managers.
Resource Recovery Services (RRS). An z/OS facility that provides 2-phase syncpoint
support across participating resource managers.
responder. In distributed queuing, a program that replies to network connection requests
from another system.
resynch. In WebSphere MQ, an option to direct a channel to start up and resolve any in-
doubt status messages, but without restarting message transfer.
return codes. The collective name for completion codes and reason codes.
return-to-sender. An option available to an MCA that is unable to deliver a message. The
MCA can send the message back to the originator.
rollback. Synonym for back out.
RRS. Resource Recovery Services.
RTM. Recovery termination manager.
rules table. A control file containing one or more rules that the dead-letter queue handler
applies to messages on the DLQ.
S
SAF. System Authorization Facility.
Scalable Parallel 2 (SP2). IBM's parallel UNIX system — effectively parallel AIX systems on
a high-speed network.
SDWA. System diagnostic work area.
security enabling interface (SEI). The WebSphere MQ interface to which customer- or
vendor-written programs that check authorization, supply a user identifier, or perform
authentication must conform. A part of the WebSphere MQ Framework.
SEI. Security enabling interface.
selector. Used to identify a data item. In the MQAI there are two types of selector: a user
selector and a system selector.
sender channel. In message queuing, a channel that initiates transfers, removes messages
from a transmission queue, and moves them over a communication link to a receiver or
requester channel.
sequential delivery. In WebSphere MQ, a method of transmitting messages with a sequence
number so that the receiving channel can reestablish the message sequence when storing
the messages. This is required where messages must be delivered only once, and in the
correct order.
sequential number wrap value. In WebSphere MQ, a method of ensuring that both ends of
a communication link reset their current message sequence numbers at the same time.
Transmitting messages with a sequence number ensures that the receiving channel can
reestablish the message sequence when storing the messages.
serialization. The writing of data in sequential fashion to a communications medium from
program memory.
server. (1) In WebSphere MQ, a queue manager that provides queue services to client
applications running on a remote workstation. (2) The program that responds to requests for
information in the particular two-program, information-flow model of client/server. See also
client.
server channel. In message queuing, a channel that responds to a requester channel,
removes messages from a transmission queue, and moves them over a communication link
to the requester channel.
server connection channel type. The type of MQI channel definition associated with the
server that runs a queue manager. See also client connection channel type.
service interval. A time interval, against which the elapsed time between a put or a get and a
subsequent get is compared by the queue manager in deciding whether the conditions for a
service interval event have been met. The service interval for a queue is specified by a queue
attribute.
service interval event. An event related to the service interval.
session ID. In WebSphere MQ for z/OS, the CICS-unique identifier that defines the
communication link to be used by a message channel agent when moving messages from a
transmission queue to a link.
shutdown. See immediate shutdown, preemptive shutdown, and quiesced shutdown.
signaling. In WebSphere MQ for z/OS and WebSphere MQ for Windows 2.1, a feature that
allows the operating system to notify a program when an expected message arrives on a
queue.
signature. A distinct combination of method name or operator, and parameters.
single logging. A method of recording WebSphere MQ for z/OS activity where each change
is recorded on one data set only. Contrast with dual logging.
single-phase backout. A method in which an action in progress must not be allowed to
finish, and all changes that are part of that action must be undone.
single-phase commit. A method in which a program can commit updates to a queue without
coordinating those updates with updates the program has made to resources controlled by
another resource manager. Contrast with two-phase commit.
SIT. System initialization table.
SNA. Systems Network Architecture.
source queue manager. See local queue manager.
SPX. Sequenced Packet Exchange transmission protocol.
SP2. Scalable Parallel 2
stanza. A group of lines in a configuration file that assigns a value to a parameter modifying
the behavior of a queue manager, client, or channel. In WebSphere MQ on UNIX systems,
MQSeries for OS/2, and WebSphere MQ for Windows, a configuration (.ini) file may contain a
number of stanzas.
star-connected communications network. A network in which all nodes are connected to a
central node.
storage class. In WebSphere MQ for z/OS, a storage class defines the page set that is to
hold the messages for a particular queue. The storage class is specified when the queue is
defined.
store and forward. The temporary storing of packets, messages, or frames in a data network
before they are retransmitted toward their destination.
streaming. The marshalling of class information and object instance data.
subsystem. In z/OS, a group of modules that provides function that is dependent on z/OS.
For example, WebSphere MQ for z/OS is an z/OS subsystem.
supervisor call (SVC). An instruction that interrupts a running program and passes control to
the supervisor so that it can perform the specific service indicated by the instruction.
SVC. Supervisor call.
switch profile. In WebSphere MQ for z/OS, a RACF profile used when WebSphere MQ
starts up or when a refresh security command is issued. Each switch profile that WebSphere
MQ detects turns off checking for the specified resource.
symptom string. Diagnostic information displayed in a structured format designed for
searching the IBM software support database.
synchronous messaging. A method of communication between programs in which
programs place messages on message queues. With synchronous messaging, the sending
program waits for a reply to its message before resuming its own processing. Contrast with
asynchronous messaging.
syncpoint. An intermediate or end point during processing of a transaction at which the
transaction's protected resources are consistent. At a syncpoint, changes to the resources
can safely be committed, or they can be backed out to the previous syncpoint.
sysplex. A multiple -system environment that allows multiple-console support (MCS)
consoles to receive console messages and send operator commands across systems.
System Authorization Facility (SAF). An z/OS facility through which WebSphere MQ for
z/OS communicates with an external security manager such as RACF.
system bag. A type of data bag that is created by the MQAI.
system.command.input queue. A local queue on which application programs can put
WebSphere MQ commands. The commands are retrieved from the queue by the command
server, which validates them and passes them to the command processor to be run.
system control commands. Commands used to manipulate platform-specific entities such
as buffer pools, storage classes, and page sets.
system diagnostic work area (SDWA). Data recorded in a SYS1.LOGREC entry, which
describes a program or hardware error.
system initialization table (SIT). A table containing parameters used by CICS on start up.
system item. A type of data item that is created by the MQAI.
system selector. In the MQAI, used to identify a system item. A system selector is included
in the data bag when it is created.
Systems Network Architecture (SNA). The description of the logical structure, formats,
protocols, and operational sequences for transmitting information units through, and
controlling the configuration and operation of, networks.
SYS1.LOGREC. A service aid containing information about program and hardware errors.
T
TACL. Tandem Advanced Command Language.
target library high-level qualifier (thlqual). High-level qualifier for z/OS target data set
names.
target queue manager. See remote queue manager.
task control block (TCB). An z/OS control block used to communicate information about
tasks within an address space that are connected to an z/OS subsystem such as WebSphere
MQ for z/OS or CICS.
task switching. The overlapping of I/O operations and processing between several tasks. In
WebSphere MQ for z/OS, the task switcher optimizes performance by allowing some MQI
calls to be executed under subtasks rather than under the main CICS TCB.
TCB. Task control block.
TCP. Transmission Control Protocol.
TCP/IP. Transmission Control Protocol/Internet Protocol.
temporary dynamic queue. A dynamic queue that is deleted when it is closed. Temporary
dynamic queues are not recovered if the queue manager fails, so they can contain
nonpersistent messages only. Contrast with permanent dynamic queue.
termination notification. A pending event that is activated when a CICS subsystem
successfully connects to WebSphere MQ for z/OS.
this. The reserved word that represents a pointer to the current object.
thlqual. Target library high-level qualifier.
thread. In WebSphere MQ, the lowest level of parallel execution available on an operating
system platform.
time-independent messaging. See asynchronous messaging.
TMF. Transaction Management Facility.
TMI. Trigger monitor interface.
TM/MP. NonStop Transaction Manager/MP.
trace. In WebSphere MQ, a facility for recording WebSphere MQ activity. The destinations for
trace entries can include GTF and the system management facility (SMF). See also global
trace and performance trace.
tranid. See transaction identifier.
transaction. See unit of work and CICS transaction.
transaction identifier. In CICS, a name that is specified when the transaction is defined, and
that is used to invoke the transaction.
transaction manager. A software unit that coordinates the activities of resource managers by
managing global transactions and coordinating the decision to commit them or roll them back
is a transaction manager.
Transmission Control Protocol (TCP). Part of the TCP/IP protocol suite. A host-to-host
protocol between hosts in packet-switched communications networks. TCP provides
connection-oriented data stream delivery. Delivery is reliable and orderly.
Transmission Control Protocol/Internet Protocol (TCP/IP). A suite of communication
protocols that support peer-to-peer connectivity functions for both local and wide area
networks.
transmission program. See message channel agent.
transmission queue. A local queue on which prepared messages destined for a remote
queue manager are temporarily stored.
trigger event. An event (such as a message arriving on a queue) that causes a queue
manager to create a trigger message on an initiation queue.
triggering. In WebSphere MQ, a facility allowing a queue manager to start an application
automatically when predetermined conditions on a queue are satisfied.
trigger message. A message containing information about the program that a trigger monitor
is to start.
trigger monitor. A continuously-running application serving one or more initiation queues.
When a trigger message arrives on an initiation queue, the trigger monitor retrieves the
message. It uses the information in the trigger message to start a process that serves the
queue on which a trigger event occurred.
trigger monitor interface (TMI). The WebSphere MQ interface to which customer- or
vendor-written trigger monitor programs must conform. A part of the WebSphere MQ
Framework.
two-phase commit. A protocol for the coordination of changes to recoverable resources
when more than one resource manager is used by a single transaction. Contrast with single-
phase commit.
type. A fundamental data type of computer architecture, including for example character
string and integer.
U
User Datagram Protocol.
UIS. User identifier service.
undelivered-message queue. See dead-letter queue.
undo/redo record. A log record used in recovery. The redo part of the record describes a
change to be made to an WebSphere MQ object. The undo part describes how to back out
the change if the work is not committed.
unit of recovery. A recoverable sequence of operations within a single resource manager.
Contrast with unit of work.
unit of work. A recoverable sequence of operations performed by an application between
two points of consistency. A unit of work begins when a transaction starts or after a user-
requested syncpoint. It ends either at a user-requested syncpoint or at the end of a
transaction. Contrast with unit of recovery.
user bag. In the MQAI, a type of data bag that is created by the user.
User Datagram Protocol (). Part of the TCP/IP protocol suite. A packet-level protocol built
directly on the Internet Protocol layer. UDP is a connectionless and less reliable alternative to
TCP. It is used for application-to-application programs between TCP/IP host systems.
user identifier service (UIS). In MQSeries for OS/2 Warp, the facility that allows MQI
applications to associate a user ID, other than the default user ID, with WebSphere MQ
messages.
user item. In the MQAI, a type of data item that is created by the user.
user selector. In the MQAI, used to identify a user item. For the administration of objects,
valid user selectors are already defined.
utility. In WebSphere MQ, a supplied set of programs that provide the system operator or
system administrator with facilities in addition to those provided by the WebSphere MQ
commands. Some utilities invoke more than one function.
V
value. Value of a data item. This can be an integer, a string, or a handle of another bag.
virtual method. A method that exhibits polymorphism.
X
X/Open XA. The X/Open Distributed Transaction Processing XA interface. A proposed
standard for distributed transaction communication. The standard specifies a bidirectional
interface between resource managers that provide access to shared resources within
transactions, and between a transaction service that monitors and resolves transactions.
XCF. Cross Systems Coupling Facility.

02 MQ Administration Stud

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

02 MQ Administration Stud

Caricato da

Copyright:

Formati disponibili

WebSphere MQ System Administration I for

What This Unit Is About

What You Should Be Able to Do

How You Will Check Your Progress

WebSphere MQ - Commercial Messaging

Figure 1-1. WebSphere MQ - Commercial Messaging

Message and Queue

• A queue manager owns and manages queues

Figure 1-3. Message Descriptor

• Separate process for replies

Figure 1-7. Client/Server

Figure 1-8. Assured Delivery

Figure 1-9. Connectionless Communications

Message Driven Processing

Figure 1-10. Message Driven Processing

This is an example of a message lattice structure made possible by WebSphere MQ.

Figure 1-11. Separate Processes as Units of Work

Multiple, Asynchronous Units of Work

Figure 1-12. Multiple, Asynchronous Units of Work

Figure 1-13. Message Persistence

WebSphere MQ Queue Managers

Figure 1-14. WebSphere MQ Queue Managers

Figure 1-15. WebSphere MQ Framework

Figure 1-16. WebSphere MQ Client

Figure 1-17. WebSphere MQ Platforms

• An WebSphere MQ platform is a system environment in which an application may issue

What This Unit Is About

What You Should Be Able to Do

How You Will Check Your Progress

Naming WebSphere MQ Objects

Special Local Queues

Figure 2-1. Message Channel

Old WebSphere MQ Explorer (1 of 2)

Figure 2-2. Old WebSphere MQ Explorer (1 of 2)

Figure 2-3. Old WebSphere MQ Explorer (2 of 2)

Figure 2-4. IBM WebSphere MQ Version 6

Figure 2-5. IBM WebSphere MQ Version V6 Desktop

Figure 2-6. Explorer and Content Perspectives

Figure 2-7. IBM WebSphere MQ V6 Queue Display

Displays queue control information;

Figure 2-8. Queue Content View

Figure 2-9. Queue Status Information

Queue Connection Information

Figure 2-10. Queue Connection Information

Figure 2-11. Viewing Filters

Figure 2-12. Advanced Filters (1 of 4)

Figure 2-13. Advanced Filters (2 of 4)

Figure 2-14. Advanced Filters (3 of 4)

Figure 2-15. Advanced Filters (4 of 4)

Figure 2-16. New Queue Compare Functionality (1 of 3)

Figure 2-17. New Queue Compare Functionality (2 of 3)

Figure 2-18. New Queue Compare Functionality (3 or 3)

Figure 2-19. Eclipse Icons

Figure 2-20. Workbench Mode (1 of 2)

Open mode... You can select one of the following methods

Figure 2-21. Icons in Workbench Mode

Figure 2-22. Stand-alone Mode

Add Remote Queue Manager

Add Queue Manager (1 of 5)

Figure 2-23. Add Queue Manager (1 of 5)

Figure 2-24. Add Queue Manager (2 of 5)

Add Queue Manager (3 of 5)

Figure 2-25. Add Queue Manager (3 of 5)

Figure 2-26. Add Queue Manager (4 of 5)