IBM WebSphere MQ Introduction

© 2013 IBM Corporation
WebSphere
WebSphere MQ v7.5
Enablement Training

WebSphere MQ in a nutshell

What is Websphere MQ
 Software that enables programs to communicate across a network using a simple and
consistent application programming interface.
 A messaging and queuing middleware, with publish/subscribe
Messaging: programs communicate by sending each other data in messages rather
than by calling each other directly.
Queuing: the messages are placed on queues in storage, so that programs can run
independently of each other, at different speeds and times, in different locations, and
without having a logical connection between them.
Publish/subscribe: a program can send (publish) data to a single destination, and let
WebSphere MQ deal with the distribution of that data to other programs (subscribers).
The publisher defines a topic for the information, and the subscriber specifies what
topics it wants to receive.

What it can do for me?
 Sends and receives data between your applications, and over networks.
 Message delivery is assured and decoupled from the application.
 Your application programmers do not need to have communications programming
knowledge.

How do I use it
 Use its associated tools to create your initial configuration.
– WebSphere MQ Explorer workbench
– WebSphere MQ Script commands (MQSC)
– Programmable Command Format (PCF)
 Use the MQ API (MQI) in your application to connect to a queue manager, open queues
and topics, and put and get messages.

6
MQ Client MQ Server
How does WebSphere MQ work?
 Messaging services are based on Queues
that store and forward data based on simple
programming commands
 Uses the proven database technique of two-
phase commit transactions to ensure
messages are not lost or duplicated
 Uses publish/subscribe to route messages
dynamically based on keywords or “topics”
 Uses multi-processor threading and
clustering to accelerate throughput of
messages
Message
Queue
Application ZApplication A

INSTALLING WebSphere MQ

Installation
 Read the documentation/manual
– Main resource: IBM WMQ Infocenter
– Take a look at the specific target platform chapter
 Know what you are going to install (server or client?)
 Find out the system requirement
 Prepare your installation
– Write your non-functional requirement
– Design and draw the topology (architecture)
– Design and document the configuration
 Verify the installation
– Test

Preparation of WMQ Server Installation
 Separate the volume for product code & working data or even more
– Product code: /opt/mqm or C:Program FilesIBMWebSphere MQ
– Working data: /var/mqm or anywhere
– Recovery log data: /var/mqm/log
– Error files: error files (/var/mqm/errors)
 Prepare/check the disk space for product code & working data
– Product data min ~350MB (Linux/Unix)
– Working data disk size consideration:
• The maximum number of messages in the system at one time
• Contingency for message buildups, if there is a system problem
• The average size of the message data, plus 500 bytes for the message header
• The number of queues
• The size of log files and error messages
– Log data disk size calculation

Software components (Linux)
Linux/Windows only

WebSphere MQ Server Installation
 Linux
– ./mqlicense.sh –accept
– rpm -ivh MQSeriesRuntime-7.0.1-0.i386.rpm MQSeriesServer-7.0.1-0.i386.rpm
 AIX
– installp -axgXYd. All
 Solaris
– ./mqlicense.sh -text-only
– pkgadd -d.
 HP-UX
– ./mqlicense.sh –accept
– swinstall -s $PWD/hp-Uxxxxx.v11 MQSERIES
 Windows
– Run Setup.exe

IBM GSKit
 IBM WebSphere Eclipse Platform
 IBM Global Security Kit (GSKit)
 Subcomponent that provides support for SSL and TLS for Windows, Linux/Unix

User ID
WebSphere MQ utilize user authentication of the system operation.
Prerequisite for installation (Linux/Unix):
user ID: mqm, with a primary group of mqm
To configure multi-instance queue managers, use the same UID & GID
To run administration commands e.g. crtmqm, you need to be a member of mqm group

LAB 1: Install WebSphere MQ
 In the First Lab you will:
– Find WebSphere MQ system requirements information
– Find WebSphere MQ documentation (Information center)
– Read installation requirements
– Download & Install offline WMQ infocenter
– Download WMQ Trial
– Install WMQ in Windows
– Loking around at WebSphere MQ installation directory
– View mqs.ini file

MQ Installation Directory
 Sample mqs.ini file

WebSphere MQ

Message
 A collection of data sent by one program and intended for another program
 A message is built by an application
 A message is consumed by a different application
 Message can contain any kind of data
 Type of message:
 Type of message is identified by an MQMT_* value
 We can also define our own types of message
• Datagram A simple message for which no reply is expected
• Request A message for which a reply is expected
• Reply A reply to a request message
• Report A message that describes an event such as the occurrence of an error

Message Composition
 WMQ message are made up of two parts:
 Both are supplied by the sending application
 Some fields in the message descriptor are set by the queue manager on behalf of the
application
Message properties Application data

The structure of an MQ Message
Message Headers
 A Set of Message Attributes
understood and augmented
by the Queue Manager
–Unique Message Id
–Correlation Id
–Routing Information
–Reply Routing
Information
–Message Priority
–Message Persistence
•Persistent
•Non-persistent
–Message Codepage
–Message Format
–Etc…
Message Data
 Any sequence of bytes
–Defined by the sending program
–Understood by the receiving program
–NOT meaningful to the Queue Manager
 Can contain any data
–Structured
• XML, Tagged, Tagged Delimited, C
or Cobol defined, etc.
–Unstructured
• Binary
A video, a picture, etc.
• Any content
Message Headers Message DataMessage Properties
Message Properties
• Arbitrary values
associated with the
message but not part of
the body
• Properties can be integers,
strings, boolean, etc.
• Receiving apps do not see
them unless they want
• Permits explicit statement
of relationships between
messages
• e.g. Message X is a
REPLY to Message Y

Some fields in the message descriptor
Message descriptor fields Publication/subscription message descriptor fields
• SubName
• SubUserData
• SubCorrelId
• PubPriority
• PubAccountingToken
• PubAppIdentityData
SubLevel
• ResObjString

Message Properties
 Can be used to include business data or state information without having to store it in the
application data
 Used by message selectors
– to filter publications to topics
– to selectively get messages from queues
 Queue manager has MaxPropertiesLength to control the size of the properties
 Property name is a case-sensitive character string, limited to +4095 characters
 Property data type:
– boolean
– byte string
– character string
– floating-point
– integer number
 Accessible by JMS as JMS message properties if prefixed by “usr.”
– message.getStringProperty('myproperty')

Message Length & Segmentation
 The length of data ≤ MaxMsgLength attribute of both the queue and queue manager
 The default maximum message length is 4 MB but can be changed up to max 100 MB
 Message segmentation
– message is too large to be handled by queue or queue manager

23
Message persistence
Queue
Manager
Queue
CC/R
C
Queue
Application
Program
MQPU
T
MQPU
T
Queue
Files
Non-
Persistent
message
Persistent
message
 The persistence of a message is determined
by the value of the Persistence field in its
message descriptor.
 Both persistent and non-persistent messages
can be stored on the same queue.
 Persistence is accomplished via message
logging
 Persistent Messages are always recoverable
 Non-persistent Messages have 2 classes of
service:
Messages are retained for the life of the Queue
Manager
Messages can survive a normal shutdown and
restart of the Queue Manager
 Logging has implication on performanceLogs
CC/R
C

Message Priority
 Priority field of the MQMD structure can be set
 MsgDeliverySequence attribute of the queue determines whether
– stored in FIFO (first in, first out) sequence
– in FIFO within priority sequence
 DefPriority attribute of a queue sets the default priority value
 MaxPriority attribute of the queue manager is the maximum priority we can assign

Application Data Conversion
 Application data of a message can be converted at the sending queue manager, or at the
receiving queue manager
 Messages with MQFMT_NONE specified are not converted

MESSAGE QUEUING

27
What is a Queue ?
 Messages are delivered asynchronously to a Queue
 A Place to hold messages
 Queue creation
– Pre-defined
– Dynamic definition
 Message Access
– FIFO (first in first out)
– Priority (FIFO within Priority)
– Direct
– Destructive & non-destructive access
 Parallel access by applications
– Managed by the queue manager

Message Queuing – Main Features
 There are no direct connections between programs (decoupled)
 Communication between programs can be time-independent.
 Work can be carried out by small, self-contained programs.
 Communication can be driven by events.
 Applications can assign a priority to a message.
 Security.
 Data integrity.
 Recovery support.

Queues can be Local or Remote
MQ
I
System 1 System
2
Messagin
g
and
Queuing
Messagin
g
and
Queuing
TCP/IP is primary protocol
Q1
Q2
Put Q2 Put Q1 Get Q1 Get Q2
XmitQ
MQ
I
Get Q2
Program
A
Program
B
Program
C
Sender
Channel
Receiver
Channel

© 2010 IBM Corporation30
Queue
The types of queue that WebSphere MQ supports for applications to use are

Queue definition and independence

WebSphere MQ – Queue
 Alias Queue
– Is not real queues but definitions.
– Used to assign different names to the same physical queue.
– The other queue can be:
• A local queue
• A local definition of a remote queue
• A topic.
 Cluster Queue
– A local queue that is known throughout a cluster of queue managers, that is, any
queue manager that belongs to the cluster can send messages to it without the
need of a remote definition or defining channels to the queue manager that owns
it.
 Remote Queue
– is a definition (not a real queue), owned by a different queue manager.
– A remote queue definition is the local definition of a remote queue.
– Application can access a remote queue just as use the name of a local queue.
– A program cannot read messages from a remote queue.

 Model/Dynamic Queue
– Such a queue is defined "on the fly" when the application needs it.
– Retained by the queue manager or automatically deleted when the application program
ends.
– Dynamic queues are local queues.
– They are often used in conversational applications, to store intermediate results.
– Dynamic queues can be:
Temporary queues that do not survive when queue manager restarts
Permanent queues that do survive when queue manager restarts
 Local Queue
– A queue is local if it is owned by the queue manager to which the application program is
connected.
– For example, program A and program B each has a queue for incoming messages and
another queue for outgoing messages. Since the queue manager serves both programs,
all four queues are local.

 Transmission Queue
– A remote queue is associated with a transmission queue.
– Transmission queues are used as an intermediate step when sending messages to
queues that are owned by a different queue manager.
– Typically, there is only one transmission queue for each remote queue manager (or
machine).
– Transmission queues are transparent to the application. They are used internally by
the queue manager
– All messages written to queues owned by a remote queue manager are actually written
to the transmission queue for this remote queue manager.
– The messages will then be read from the transmission queue and sent to the remote
queue manager using MQ Series clusters
– There is only one transmission queue for all messages sent to all other queue managers
in the cluster.

 Initiation Queue
– A local queue to which the queue manager writes a trigger message when certain
conditions are met on another local queue
– Example:
• when a message is put into an empty message queue or in a transmission queue, a
trigger message is written to the corresponding initiation Queue. Such a trigger
message is transparent to the programmer.
– Two of MQ applications monitor initiation queues and read trigger messages
• The trigger monitor which starts applications
• The channel initiator which starts the transmission between queue managers.
– Applications do not need to be aware of initiation queues.
See Triggering topic

 Dead-letter Queue
– A queue manager must be able to handle situations when it cannot deliver a message.
Examples:
• The destination queue is full.
• The destination queue does not exist.
• Message puts have been inhibited on the destination queue.
• The sender is not authorized to use the destination queue.
• The message is too large.
– Used as a repository for all messages that cannot be delivered.
– Defined when the queue manager is created.
– Messages can be put on the DLQ by
• queue managers
• message channel agents (MCAs)
• Applications
• All messages must be prefixed with a dead-letter header structure, MQDLH
• The Reason field of the MQDLH structure contains a reason code that identifies why
the message is on the DLQ

LOG
PUT GET
Messaging
& Queuing
Operating
System
& Storage
Communications
Utilities
Listener
Command Server
Trigger monitor
Channel Initiator
Windows Explorer
Applications
Operating System
• Timers
• Semaphores
• ECBs
• Memory
• …
What is a Queue Manager?

38
Elements of Messaging and Queuing
 Programs communicate by putting messages in message queues
“A building block for
distributed processing”

39
Communication can be one way or two way

40
Either program can be busy or unavailable

41
One to many . . .

42
Or many to one . . .

Triggering
 Triggering start when the right conditions are detected by the queue manager
 A trigger message send to a queue called an initiation queue

Trigger
 Tigger is internally used for starting the channel to transfer the message

LAB 2A: Verifying Installation
 In this Lab you will verifying the MQ Server installation by
– Using command line to check installed WebSphere MQ version
– Using command line to create a Queue Manager and starting it
– Using MQSC to create a queue
– Using sample program to put text message into the queue (amqsput)
– Using sample program to get text message from the queue (amqsget)
MQ_INSTALLATION_PATHbinsetmqenv –s
dspmqver
crtmqm QMA
strmqm QMA
runmqsc QMA
DEFINE QLOCAL (QUEUE1)
end
amqsput QUEUE1
amqsget QUEUE1

LAB 2B: Verifying Server-to-Server Installation
 In this Lab you will verifying the MQ Server to MQ Server installation & communication by
– Using command line to create a Queue Manager and starting it
– Using MQSC to create local queue, remote queue, create & start listener, create channel
– Using sample program to put text message into the queue (amqsput)
– Using sample program to get text message from the queue (amqsget)

LAB 3: Exploring WMQ Explorer
Administration Using the WebSphere MQ Explorer
 In this Lab you will:
– Create a Queue Manager
– Work with Queues (create,
test, browse, delete)
– Create a Queue Manager
Group (or Set)
– Administer a Group of
Queue Managers
Collectively
– Use Filters
MQ Explorer is included with an MQ server installation and is also available for download as
SupportPac MS0T.
Since MQ Explorer V7.1 it can be installed as an Eclipse Plug-in via Eclipse Marketplace

INTERCOMMUNICATION

Intercommunication
• Sending messages from one queue manager to another
• Could be on the same machine or another
• Could be running on the same platform at local or different platform
(distributed environment)
• Systems Network Architecture Advanced Program-to
Program Communication (SNA APPC)
• TCP/IP
• Network Basic Input/Output System (NetBIOS)
• Sequenced Packet Exchange (SPX)

Components handles intercommunication
 Queue Manager has a definition of
• Its queue
• Remote queue definitions
 Transmission queue
– a special type of local queue on which messages are stored until they can be
successfully transmitted and stored at the remote queue manager
– the messages are destined for a remote queue manager is stored in here first
– one transmission queue need to be defined for each sending MCA unless we use cluster
 Message Channel Agent (MCA)
– handles the sending and receiving of messages
– takes messages from the transmission queue and puts them on the communication link
– receives messages and delivers them onto a queue
 Channel
– a one-way communication link between two queue managers
– carry messages destined for any number of queues at the remote queue manager
 Listener
– processes that accept network requests

What is Channel?
 Queue Manager to Queue Manager
(Message channel)
– Uni-directional
– Usually defined in pairs for example:
• One Sender
• One Receiver
– Asynchronous
 Client to Queue Manager (MQI channel)
– Bi-directional
– Defined as a single channel
– Synchronous
 A building block for a reliable Enterprise Service Bus (ESB)
* Note: Client to Client communication must go via a Queue Manager

Components needed to send a message
 A simple channel consist of
– a sender channel definition at the local queue manager
– a receiver channel definition at the remote queue manager
 These two definitions must have the same name
 Dead-letter queue (undelivered message queue)
– if messages cannot be delivered to their destination, they are put on this queue
– Each queue manager should have this queue

Components needed to return a message
 To run in the opposite direction between the queue managers, you need to define another
channel

Message Channels
 Uni-directional QM to QM
 Types of end point of a message channel
1. Sender
2. Receiver
3. Server
4. Requester
5. Cluster sender
6. Cluster receiver
 Combination of connecting two end points
of message channels
1. Sender-receiver
2. Requester-server
3. Requester-sender (callback)
4. Server-receiver
5. Cluster sender-cluster receiver
1 & 4
2
3
5

Channel Initiator & Listener
 A channel initiator acts as a trigger monitor for sender channels.
 Implementation channel initiators & listeners is platform specific (read the doc).
 The default behavior is to start a channel initiator when a queue manager is automatically
started. This can be changed by setting SCHINIT attribute of the queue manager to
MANUAL

Cluster
An alternative to the traditional WebSphere MQ network
 A network of queue managers that are logically associated in some way
 Queues in a queue manager is available to every other queue manager in the cluster
 Any queue manager can send a message to any other queue manager in the same cluster
without the need for explicit channel definitions, remote-queue definitions, or
transmission queues for each destination
Every queue manager in a cluster:
 has a single transmission queue
 needs to define only one cluster-receiver
channel and one cluster-sender channel

Channel-exit programs
 To do some additional processing
 Types of channel exit:
1. Security exit
2. Message exit
3. Send and receive exits
4. Message-retry exit
5. Channel auto-definition exit

Dead-letters Queues (DLQ)
 Used if they cannot be routed to their correct destination.
 If no DLQ and message is left on the transmission queue or discarded (non-persistent) and
the channel is stopped.
 It can affect the sequence in which messages are delivered.
 Used if data-conversion errors occurs at the sending end of a channel

How to get to the remote queue manager
 Multi-hopping
– to pass through one or more intermediate queue managers on the way to the target
queue manager
 Sharing channel
– messages from multiple applications to multiple remote queues can use the same
channel
 Using different channels
– Define another channel and another transmission queue and create a remote queue
definition specifying the location and the transmission queue name
 Using clustering
– Queue managers in a cluster can make the queues that they host available to every
other queue manager in the cluster.

Multi-hopping
 Using other MQ server(s) in the middle

Sharing channels
 Using same channels for the multiple remote queues

Using different channels
 The use of channels is transparent to the application
Using remote queue definition, your applications must not specify the location (that is, the
destination queue manager) themselves

Using Clustering
 Send to any other queue manager

Dead-letter queue handler
 A routine to process messages on the DLQ regularly
 Invoke using the runmqdlq command
 Instructions for processing messages is using a user-written rules table
runmqdlq DLQ QMGR1 < qrule.rul

What happens when a message cannot be delivered?
 MCA can process it in several ways:
– try again
Channel have following parameter to retry .
• Message retry count (MRRTY)
* Message retry interval (MRTMR)
– return-to-sender,
– put it on the dead-letter queue.

LAB4: Explore distributed queuing
1. Create Queue Manager QM1
2. Create Local Queue Q1
3. Create Receiver Channel QM2.TO.QM1
4. Create Queue Manager QM2
5. Create Transmission Queue QM2.TO.QM1
6. Create Sender Channel QM2.TO.QM1 (the name
should be the same as receiver channel in QM1)
and specify the transmission queue name as you
created earlier
7. Create Remote Queue Q2, specify the remote
queue manager to QM1 and transmission queue as
you created earlier
QM2
Q2
QM2.TO.QM
1
Message
Channel
Agent
QM1
Q2
Message
Channel
Agent
QM2.TO.QM
1
Remote Queue
Defiition
Transmition
Queue
Sender Channel Receiver Channel
Local Queue
Connect queue managers using Sender-receiver channel pair

WebSPHERE MQ ADMINISTRATION

Category of Control Commands
Category Description
Queue manager
commands
commands for creating, starting, stopping, and deleting queue managers
and command servers
Channel commands commands for starting and ending channels and channel initiators
Utility commands • Utility commands include commands associated with: Running MQSC
commands
• Conversion exits
• Authority management
• Recording and recovering media images of queue manager resources
• Displaying and resolving transactions
• Trigger monitors
• Displaying the file names of WebSphere® MQ objects
• The File Transfer Application
Example:
crtmqm -u SYSTEM.DEAD.LETTER.QUEUE JKT1QM

Using MQ Script (MQSC)
 to manage queue manager objects (queue manager itself, queues, process definitions,
channels, client connection channels, listeners, services, namelists, clusters, and
authentication information objects)
 The runmqsc command is used for issue MQSC commands to a queue manager
– Verify a command without running it
– Run a command on a local queue manager
– Run a command on a remote queue manager
 Running MQSC commands interactively
– MQSC commands are processed by the default queue manager: runmqsc
– MQSC commands are processed by specified queue manager: runmqsc QM1
– terminate command input explicitly by entering a semicolon (;)
 Running MQSC commands from text files, example:
– runmqsc < myprog.in
– runmqsc QM1 < myprog.in > myprog.out

Using MQSC
 continuation characters
– A minus sign (-) indicates that the command is to be continued from the start of the following line.
– A plus sign (+) indicates that the command is to be continued from the first nonblank character on
the following line.

MQSC Examples
 Displaying queue manager attributes
– DISPLAY QMGR
 Altering queue manager attributes
– ALTER QMGR DEADQ (ANOTHERDLQ) INHIBTEV (ENABLED)
 Defining a local queue
– DEFINE QLOCAL (ORANGE.LOCAL.QUEUE) +
DESCR('Queue for messages from other systems') +
PUT (ENABLED) + GET (ENABLED) + NOTRIGGER +
MSGDLVSQ (PRIORITY) +
MAXDEPTH (5000) +
MAXMSGL (4194304) + USAGE (NORMAL);
 Copying a local queue definition
– DEFINE QLOCAL (MAGENTA.QUEUE) LIKE (ORANGE.LOCAL.QUEUE)
 Changing local queue attributes
– Change single attribute: ALTER QLOCAL (ORANGE.LOCAL.QUEUE) MAXMSGL(10000)
– DEFINE QLOCAL (ORANGE.LOCAL.QUEUE) MAXMSGL(10000) REPLACE
 Clearing a local queue
– CLEAR QLOCAL (MAGENTA.QUEUE)
 Deleting a local queue
– DELETE QLOCAL (PINK.QUEUE) PURGE

LAB 5 : Using Control Commands & MQSC Command
In this Lab, you will
Show list queue manager and its status
start, stop a queue manager (immediate shutdown,
preemtive shutdown)
Working with queue and queue alias
Use the control commands interactively
Use the control commands with a command file
Use the sample programs

MQ Client

 A component of the WMQ product that can be installed on a system on which no queue
manager runs.
 Available for platform:
– UNIX systems (AIX, HP-UX, Linux, Solaris)
– Windows
 Available as SupportPac and free under the standard terms and conditions
What is WebSphere MQ client
MQI Channel
(bi-directional)

Why using MQ Client
 When to use MQ Client?
– There is no need for a full WebSphere MQ implementation on the client machine.
– Hardware requirements on the client system are reduced.
– System administration requirements are reduced.
– a WebSphere MQ application running on a client can connect to multiple queue
managers on different systems.
– Alternative channels using different transmission protocols can be used.

Extended Transactional Client
a WebSphere MQ base client with the addition of the extended transactional function
 Allow a client application within the same unit of work to:
– 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 WMQ queue manager, the
table of a database, for example.
 Client application then can commit (MQCMIT) or back out (MQBACK) the unit of work
 Queue manager act as transaction manager

MQ Server vs Client
Feature Servers
Extended Transactional
Client
Standard Client
Provides Queue Manager? Yes No No
Enables Asynchronous Messaging? Yes No (1) No (1)
Queue operations within single Unit of
Work (UOW)?
Yes Yes (2) No
Manages Units of Work? Yes No (3) No
Workload management (Clustering
support)?
Yes No No
Runs on z/OS? Yes (4) No No
Licensing Server license required Server license required Free. Terms and
conditions apply
Availability Buy Installation option when installing
Server
CD or SupportPac
download
Free since V7.5

MQI Channel
 MQI channel is bi-directional in term of flow of information
 2 types of MQI channel:
– CLNTCONN
– SVRCONN
 Started automatically by client application by issuing MQCONN or MQCONNX call
Stopped automatically by an MQDISC call
 There can be multiple instances of an MQI channel.
 Several clients can use the same SVRCONN channel.

How to connect a client to a server
 The client must be able to identify which channel it should use to communicate with the
queue manager
 How to specify the client's connection to a queue manager:
– Explicitly on the MQCONNX verb
– MQSERVER variable
– Client channel tables (CCDT)
 Java client programs use either the MQEnvironment Java class or JNDI (using JMS)

Defining MQI Channel (1)
Two methods of manually creating channel definition:
1. Create one channel definition on the client and the other on the server
 Define a server connection on the server, after creating & starting queue manager
DEFINE CHANNEL(CHANNEL1) CHLTYPE(SVRCONN) TRPTYPE(TCP) +
DESCR('Server-connection to Client_1')
 On the client system, there are two ways to specify channel:
• Set the environment variable MQSERVER with value
ChannelName/TransportType/ConnectionName(Port)
Example for Windows:
SET MQSERVER=CHANNEL1/TCP/9.20.4.56(1414)
• Define the definition of a client-connection channel in MQCD structure in MQCNO structure
on an MQCONNX call by MQ application
1
2

Defining MQI Channel (2)
2. Define both the server connection and the client connection on the server system
 The client connection is stored in the client channel definition table (CCDT) on the server
system
 CCDT file name is AMQCLCHL.TAB
 CCDT file must be accessible by client or can be copied to client system
DEFINE CHANNEL(CHANNEL2) CHLTYPE(SVRCONN) TRPTYPE(TCP) +
DESCR('Server-connection to Client_2')
DEFINE CHANNEL(CHANNEL2) CHLTYPE(CLNTCONN) TRPTYPE(TCP) +
CONNAME(9.20.4.26) QMNAME(QM2) DESCR('Client-connection to Server_2')
 On the client system, set the environment variable as follow (example for Windows):
SET MQCHLLIB="C:IBMWebSphere MQ“
SET MQCHLTAB=AMQCLCHL.TAB
Note: MQSERVER environment variable should not be set, otherwise application will use
MQSERVER definition instead

Auto-definition of channels
 Channel definition can be automatically created if there is an incoming request to start a
message channel or MQI channel, but no channel definition exists for the specific channel.
 The channel definition created automatically using system object as a model:
– SYSTEM.AUTO.RECEIVER for RCVR channels,
– SYSTEM.AUTO.SVRCONN for SVRCONN channels.
 The attribute ChannelAutoDef of the queue manager must be set to MQCHAD_ENABLED
– Updating the queue manager object using the ALTER QMGR command with the
parameter CHAD(ENABLED)
– Call PCF command Change Queue Manager with parameter ChannelAutoDef

Precedence for connecting to a QMgr
 This is the precedence of the features provided by the MQ client for an application to
connect to a queue manager.
1.Pre-connect exit (introduced in MQ 7.1)
2.MQCONN API call
3.MQSERVER environment variable
4.mqclient.ini file (introduced in MQ 7.0)
5.CCDT file

1. Pre-connect exit (7.1)
 Pre-connect exit (introduced in MQ 7.1)
 Can be used for MQ MQI clients to look up a repository to obtain connection definitions
 Allows to store the client definitions in a global repository like an LDAP directory
 This is the highest precedence.
– If it is available, then it will be used, superseding all other methods.

2. MQCONN API call
 The MQCONN or MQCONNX call connects an application program to a queue
manager.
 It provides a queue manager connection handle, which the application uses on
subsequent message queuing calls.
 If the name of the queue manager is hardcoded in the application that uses a
Client transport type, then it supersedes the other methods: MQSERVER,
mqclient.ini and CCDT.

2. MQCONN API call
 Example from the sample “amqsbcg0.c” which is used to browse messages from a
queue.
 The name of the queue manager is provided at runtime: amqsbcg Q1 QMGR1
/* variables for MQCONN */
MQCHAR QMgrName[MQ_Q_MGR_NAME_LENGTH];
MQHCONN Hconn = MQHC_UNUSABLE_HCONN;
MQLONG CompCode = MQCC_OK, Reason = MQRC_NONE;
…
QMgrName[0] = '0'; /* set to null default QM */
if (argc > 2) strncpy(QMgrName, argv[2], MQ_Q_MGR_NAME_LENGTH);
…
MQCONN(QMgrName,&Hconn,&CompCode,&Reason);

2. MQCONN API Put/Get using Bindings
 Scenario: There are 2 client applications:
– one for putting a message into a queue, and
– another for getting a message
 The applications are located in the same host as the queue manager: HOST1
 Connect using a transport type of: BINDINGS
– local shared memory, no network is used

Channel Exits
 NOT available to your application if MQSERVER environment variable is set.
 Available at both the client and the server end of the channel
 Channel Exits:
– Send exit
– Receive exit
– Security exit
 client-connection send and receive exits cannot make MQI calls
 A default path for location of the channel exits on the client is defined in a configuration file
 When a channel is initialized, after an MQCONN or MQCONNX call, ClientExitPath is read in
the config file and any channel exits that are specified in the channel definition are loaded.

Client Channel Definition Tables (CCDT)
 Channel Definition Tables are used in all but the simplest of cases
 Can be used for connection to multiple queue managers
– Queue managers are specified in a "queue manager group"
 A channel definition table (CCDT) is:
• A binary file (not editable by a user)
• Created by an administrator when client channels are defined
• Allows connect options to be specified administratively
• Alternative is to use MQSERVER variable and MQCONNX options
• Somewhat analogous to Connection Factories with JMS or XMS
• In fact, a JMS Connection Factory can reference a CCDT
• Located in directory (by default):
• <mq root>qmgrsQMGRNAME@ipcc (Windows)
• <mq root/qmgrs/QMGRNAME/@ipcc (UNIX)
89 Using WebSphere MQ Clients

 You have many MQ client applications in different hosts and you want to connect these
applications to different queue managers.
 If one of those queue managers is not available, then you want the application to try to
connect to another queue manager.
 You do not want to hardcode the connection data (queue manager name, channel, port) in
the application and you want a flexible way to provide the connection data to the
applications.

Using Channel Definition Tables: Example 1
How is the QMNAME client channel attribute used?
def chl(chl1) chltype(clntconn) trptype(tcp) conname(host1) qmname(mars)
def chl(chl2) chltype(clntconn) trptype(tcp) conname(host2) qmname(venus)
mars
venus
MQCONN ("venus",hConn,cc,rc );
chl2
connected via channel chl2 to “venus"
MQ ClientAMQCLCHL.TAB

Multiple routes to the same Queue Manager
def chl(chl1) ….trptype(tcp) conname(host1) qmname(mars)
def chl(chl2) ….trptype(tcp) conname(tokenring) qmname(venus)
def chl(chl3) ….trptype(tcp) conname(ethernet) qmname(venus)
def chl(chl4) ….trptype(tcp) conname(dialup) qmname(venus)
mars
venus
MQCONN ("venus",hConn,cc,rc );
chl2
connected via channel chl3 to “venus"
chl3

How do we have back-up Queue Managers ?
def chl(chl1) ….trptype(tcp) conname(ip.mars) qmname(planet)
def chl(chl2) ….trptype(tcp) conname(ip.venus) qmname(planet)
…..
def chl(chl5) ….trptype(tcp) conname(ip.pluto) qmname(planet)
mars
venus
MQCONN (“*planet",hConn,cc,rc );
Notice the ‘*’ preceding the Queue Manager name
pluto

How do I create and deploy a channel table ?
RUNMQSC
def chl(...) chltype(clntconn) ….
copy
c:mqmqmgrsQMGRNAME@ipcc
AMQCLCHL.TAB
to
z:mytable.tbl

95 Using WebSphere MQ Clients10/10/15
Name CHLTYPE TRPTYPE CONNAME QMNAME CLNTWGHT AFFINITY
chl1 CLNTCONN TCP ip.mars planet 4 PREFERRED
chl2 CLNTCONN TCP ip.venus planet 4 PREFERRED
chl3 CLNTCONN TCP ip.pluto planet 2 PREFERRED
MQCONN(*planet)
40%
40%
20%
mars
venus
pluto

Limiting client connections
Starting MQSC for queue manager TEST1.
DEFINE CHANNEL(SALES.CONNECT) CHLTYPE(SVRCON
N) MAXINST(4) MAXINSTC(2)
Queue ManagerQueue Manager
SVRCONN
MAXINST(4)
MAXINSTC(2)
• MAXINST
• restricts the number of instances in total for
the specific channel name.
• MAXINSTC
• restricts the number of instances from a
specific IP address for that channel name.

Client conversation (connection) sharing
 Client channels have three modes of operation:
– No multiplexing, no conversation sharing
• Separate socket for each MQ client conversation
• No multiplexing benefits
– Multiplexing, no conversation sharing
• Still a separate socket for each MQ client
conversation, but benefits of multiplexed channels
available
– Multiplexing AND conversation sharing
• MQ client conversations share a socket connection,
and can utilize benefits of multiplexed channels
Starting MQSC for queue manager TEST1.
DEFINE CHANNEL(SALES.CONNECT) CHLTYPE(SVRCONN)
SHARECNV(10)
DIS CHS(SALES.CONNECT)
AMQ8417: Display Channel Status details.
CHANNEL(SALES.CONNECT) CHLTYPE(SVRCONN)
CONNAME(127.0.0.1) CURRENT
MCAUSER(hughson) STATUS(RUNNING)
SUBSTATE(RECEIVE) CURSHCNV(3)
MAXSHCNV(10)
Queue ManagerQueue Manager

Performance option - Client Read-Ahead
MQ Client/Server flows without Read-ahead of messages
Using WebSphere MQ Clients
ClientClient
MQCONN
MQOPEN
MQGET
MQGET
MQGET
ServerServer
●Each API request flows over the network
●The client blocks waiting for a reply
●For MQGet, each message is returned
over the network and passed to the
application
●Messages are never queued on the
client end

Performance option - Client Read-Ahead
MQ Client/Server flows with Read-ahead of messages
ClientClient
MQCONN
MQOPEN
MQGET
MQGET
MQGET
ServerServer
Request
for ‘n’
messages
●Some API requests flow over the
network synchronously
●For MQGet, a batch of messages are
requested
●Messages are buffered on the client end
●Messages are passed to the application
individually from the client-side buffer
●Can result in significant
throughput improvement for
certain types of applications
In particular, applications that
stream messages to clients

Performance option - Client Asynchronous Put
MQ Client/Server flows without Asynchronous Put
ClientClient
MQCONN
MQOPEN
MQOPEN
MQPUT
MQPUT
MQPUT
MQPUT
MQCMIT
ServerServer
●Each API request flows over the network
●The client blocks waiting for a reply
●For MQPut, each message is sent over
network to the queue manager
There it must be written to the queue
May also need to be logged
Then control returns to the application

Performance option - Client Asynchronous Put
MQ Client/Server flows with Asynchronous Put
ClientClient
MQCONN
MQOPEN
MQOPEN
MQPUT
MQPUT
MQPUT
MQPUT
MQCMIT
ServerServer
● Some API requests flow over the network synchronously
● For MQPut, control is returned immediately to the application
Messages are buffered on the client end and forwarded to the
queue manager asynchronous to the client application
Status of each MQPut is
maintained on client end
● At commit, put requests are
reconciled with responses; if any
failed, unit-of-work is rolled back
Client app can optionally request
status of put messages
● Async Put can result in significant
throughput improvement for
certain types of applications
In particular, applications that
stream messages from clients

MQ Client Security
 Two aspects to consider
– Authentication
• Since V7.1 introduced Channel Authentication Records (CHLAUTH)
• CHLAUTH will be enabled by default and has are three rules provided with a queue
manager
– DISPLAY QMGR CHLAUTH
– ALTER QMGR CHLAUTH(DISABLED)
• Blocked by CHLAUTH will result error message like AMQ9777: Channel was blocked
– Access control.

MQ Client Security: Authentication
 3 Level Security
– Transport level
– Channel security exits
– Identification passed to a channel security exit

Client Security - SSL
Client Server
DEF CHANNEL ('SYSTEM.DEF.SVRCONN')
CHLTYPE(SVRCONN)
SSLCAUTH(REQUIRED)
SSLCIPH('RC4_MD5_US')
SSLPEER('CN="*", O="IBM", C="US"')
Authentication,
Encryption, Integrity
DEF CHANNEL('SYSTEM.DEF.CLNTCONN')
CHLTYPE(CLNTCONN)
SSLCIPH('RC4_MD5_US')
SSLPEER('CN=“user", O="IBM",C="US"')
SSL facility
• key repository
• MQSSLKEYR
environment variable
SSL facility
• key repository

Access Control
 Access control is based upon user IDs
 Access denied
– MQCC_FAILED
– MQRC_NOT_AUTHORIZED
 No connection handle is returned
ConnectionUser ID check.
Connection might be denied
Local Queue
Manager

LAB 6 – WebSphere MQ Client Installation & Verification
In this Lab, you will
Find out how to get WebSphere MQ Client V7.5 (MQC75) from IBM site
Install WebSphere MQ Client installation on Windows
Verifying the installation by testing communication between a client and a server
– Setting up MQ Server for client connection
– Using sample program (amqsputc, amqsgetc)

PUBLISH/SUBSCRIBE

Point to Point Examples
108 Overview of Publish / Subscribe
●Message Queuing
If I put a single message it will go to a
single consumer
●eMail
Might go to lots of people but I get to
choose exactly who gets it
●Post Card
Goes to just the person I send it to

Publish / Subscribe Examples
 Magazine Publishing
– In the US, over 10,000 titles published
 Airline Departure Boards
– Boards might display (subscribe to)
• All departures
• Departures from this terminal
• Departures by this airline
● RSS News Feeds

Loose coupling with Pub/Sub
Publisher
Subscriber
Topic
Provider
Subscriber
Subscriber
Subscriber
Publisher Publisher
Publisher
Subscriber
Topic
Topic
Publisher
Publisher
Subscriber
Subscriber
Topic
1:1 1:many many:1 many:many

WebSphere MQ Implementation of Publish/Subscribe
 Central concept is the TOPIC STRING
 Messages are “published” to a Topic string
– Each act of publishing is to a single Topic string
 Subscribers are delivered messages that were published to the Topic
string(s) they registered an interest in (subscribed to)
– Subscribers may register interest in multiple topics
– Wildcards can be used to filter topic names
– Selectors can be used to filter message properties
 Topic strings can be created and secured administratively, or dynamically
by simply being referenced by publishers and subscribers

Publish/Subscribe applications
 Applications connect to local queue managers
 They can be different queue managers connected by a network.
 Can use JMS as well as any MQ API
 They are “connected” through a topic string
QM
QM
QM
Publishing
Application
Subscribing
Application
Subscribing
Application
QM
Subscribing
Application
Publish/Subscribe NetworkPublish/Subscribe Network

Concepts – Topic String
 A Topic string is an unlimited length string
 A topic string “connects” publishers and subscribers
 Has a “structure” and a semantics in it
– The structure is supplied by the “/” slash character
– Similar to directory structure on UNIX®
or Windows®
• e.g. ”/news/sports/football/teams/minnesota”
 The semantics are implied by the use of wildcards in subscriptions
– “#” and ‘+’ are used as wildcard characters in subscriptions
• e.g. ”/news/+/football/#”

Concepts – Topic Tree
 A topic tree is an internal
representation of the topic
hierarchy
 It has a root node at the very top
 It is implied from the complete set
of topic strings in use - defined,
published to, subscribed to.
 There is not necessarily a one-to-
one mapping between topic
objects and nodes in the tree
footballfinance
…
…
football/teams
football/teams/minnesota
“” (root)

Concepts – Topic Object
 A Topic Object is a WebSphere MQ object that can be administered
 A Topic Object has a name following the same rules as other WebSphere
MQ objects (Queues etc)
 The Topic String is one of the properties of a Topic Object
– Topic Objects can have other properties set
 Security can be applied to Topic Objects
 Application programs using the MQI can use the topic object as a full or
partial alternative to topic string when publishing or subscribing
– JMS programs would use the Destination object, which maps to a
Topic or Queue object in WebSphere MQ

 Nodes which have topic objects
defined for them can be thought
of as administered nodes
 They are permanent parts of the
hierarchy
 They can have properties
specified for them
 They have topic object names,
which need not reflect the topic
strings
DEFINE TOPIC(FOOTBALL) TOPICSTR(‘football’)
football
finance
…
…
football/teams
“” (root)
SYSTEM.BASE.TOPIC
FOOTBALL
MINN_TEAM

 The Topic Tree can be
dynamically extended by a
publisher and/or subscriber
– Any missing parts of the tree
hierarchy will be “filled in” when
administered nodes are defined
 Dynamically added nodes in the
Topic Tree inherit all properties
from their parent, i.e. from an
administered node above them
Admin node
Non-admin node
Admin node
Non-admin node
footballfinance
…
…
football/teams
“” (root)
SYSTEM.BASE.TOPIC
FOOTBALL
MINN_TEAM
Node “football/teams”
automatically added.

 Publishing or subscribing to a
topic string that is not yet in the
tree causes the tree to be
extended
 They are temporary parts of the
hierarchy and will be removed
when no remaining publishers or
subscribers exist
 These nodes inherit all
properties from their parent, and
so from an administered node
above them
MQSUB(‘/football/teams/greenbay/transfers’)
Admin node
Non-admin node
Admin node
Non-admin node
footballfinance
…
…
football/teams
football/teams/derby
“” (root)
SYSTEM.BASE.TOPIC
FOOTBALL
MINN_TEAMfootball/teams/greenbay
football/teams/greenbay/transfers

Concept - Subscriptions
 A subscription is to a topic string
– Wildcards can be used to set them up, but in essence they are to a topic string
– Corresponds to a node in the topic tree
 Subscriptions can be durable, or not
– Non-durable subscriptions mean messages are delivered to you only while you are connected
– Messages for durable subscriptions are delivered even when disconnected, and can be retrieved
when you next connect
 Subscription destinations can be managed, or not
– With a managed destination a subscription queue is automatically created when you create a
subscription, and is tidied up automatically in accordance with the durability of the subscription
– With an unmanaged destination, you specify your own queue at the time the subscription is opened
 Subscriptions can be registered programmatically or administratively

Concept - Retained Publications
 Most recent message published on a given topic
– Each node on the topic tree can have at most one Retained Publication
 Whether a publication is “retained” is determined at publish time by the
application program
 A subscriber can request, at anytime, the current retained publication for
a given topic
 Example StockPrice.CurrentPrice is a retained publication
– I can be notified whenever it changes – ticker tape
– Or I can request it at any time
120

Administered Subscription
 Has a name conforming to usual MQ rules
– Sample attributes
• TOPICSTR – Topic string, basically
unlimited length
TOPICSTR( ‘/football/teams/#’)
• DEST – Name of object to which
messages for this subscription will
be forwarded
DEST(MY.QUEUE)
• DESTQMGR – Remote queue
manager to which messages are
forwarded
DESTQMGR(REMOTE.QMGR)

Distributed Pub/Sub Topologies
 Two types of distributed Pub/Sub topologies are supported
–Publish/Subscribe Clusters
• Queue managers are connected using a “network” or “mesh” connectivity model
• MQ Clustering technology is used to provide connectivity between participating
queue managers
• Publications from any queue manager in the cluster may be subscribed to by any
other
• Enables multiple paths for publications, can eliminate single points of failure
–Publish/Subscribe Hierarchies
• Queue managers are arranged in a Parent/Child Hierarchy
• Each Queue manager may have only one Parent
• Queue managers may exchange Pub/Sub information directly between only their
parent or children
• This approach may require multiple hops and/or create single points of failure
 A Publish/Subscribe network can be created that combines both of these
topologies

Example of a Publish/Subscribe Cluster
QM
QM
QM
Pub
Sub
Sub
QM Sub
•Consistent definitions in cluster
•Multiple routes across cluster

Example of a Publish/Subscribe Hierarchy
QM
QM QM
QM QM QM QMPub Sub

Publish/Subscribe in the WebSphere MQ Explorer

Topic Objects
Topic Object Name
Topic String
• Topic Attributes are
associated with a Topic
Object
• The Topic Object is a
WebSphere MQ object
that can be
administered
• The Topic String is one
of the properties of a
Topic Object
• The topic string
“connects” publishers
and subscribers
• A Topic string is an
unlimited length string
• Topic Objects can have
other properties set

Topic Status – current usage of topics
 DISPLAY TPSTATUS( topic-string )
– Topic attributes (TYPE(TOPIC))
• Number of publishers and subscribers
• Whether a retained publication exists
– Subscriber info (TYPE(SUB)):
• Last resume date of subscription and last message delivery time
• Number of messages sent to this subscriber
– Publisher info (TYPE(PUB)):
• Last publish time
• Number of messages published

Administered Subscriptions
Overview of Publish / Subscribe128
•Subscriptions that are
administratively created
require a name
•A Topic Object can
optionally be referenced
•The Topic String is
required
•Wildcards may be used
•By definition, an
administered subscriptions
is durable
•Administered
subscriptions can use
either managed or
unmanaged destinations
Subscription
Object Name
Topic String
Topic Object Name
(optional)

Testing Publish and Subscribe

Benefits of Publish/Subscribe with WebSphere MQ
 Applications are more loosely coupled than with point-to-point
– No need to agree on queue names, number of receivers, etc
 Applications decide their message exchange patterns
– One-to-one
– One-to-many
– Many-to-one
– Many-to-many
 Messages are “published” to a Topic string
– Which can be created dynamically
– …or administratively for more control over security, etc
 Subscribers receive messages they registered an interest in
– Subscribers may register interest in multiple topics
– Wildcards can be used to filter topic names
– Selectors can be used to filter message properties

Lab 3 – WebSphere MQ Publish/Subscribe
Pub/Sub Administration Using the WebSphere MQ Explorer
● In the third lab you will explore Publish/Subscribe
administration using the MQ Explorer
Overview of Publish / Subscribe

WebSphere MQ Application

Application programming
 Message Queue Interface (MQI)
– a set of calls with which you can send and receive messages, and manipulate MQ
objects.
– a simple API that is consistent across all platforms
 MQ Objects:
– Queue managers
– Queues
– Administrative topic objects
– Namelists
– Services
– Listeners
– Process definitions
– Channels
– Storage classes (WebSphere® MQ for z/OS® only)
– Authentication information objects

HP-UX Windows zLinux Solaris AIX OS/400 NSS OVMS
Programming Interface
zOS Linux
80+ platform configurations
WebSphere MQ
MQ Interface
COBOL, C, RPG,
VB, PL/1, TAL, others
Base Classes For Java
Java
XMS
C, C++, .NET C#
.NET (C#)
Microsoft
SOAP
Web Services
Other Interfaces
HTTP, FTP, …
Multiple APIs
– Supports the broadest range of APIs, programming languages
and OS platforms
– Provides the only JMS engine that can be implemented on
“any” standards-compliant JEE server
– Provides rich web services interfaces meeting customer
needs for WS-Reliability

XMS Clients
a non-Java implementation of the Java Message Service (JMS) API
 Freely available for .NET and C/C++
 Can be downloaded as SupportPac
• IA9H: IBM Message Service Client (XMS) for .NET
http://www-01.ibm.com/support/docview.wss?uid=swg24011756
• IA94: IBM Message Service Client (XMS) for C/C++

Planning Your Design
 What types of queue should you use?
 Should you use shared queues and queue-sharing groups, and should you use queue-
sharing group clusters only?
 Should you use queue manager clusters?
 What types of message should you use?
 Should you use publish/subscribe or point-to-point messaging?
 How can you control your WebSphere MQ programs?
 Will your application run on a WebSphere MQ client?
 Will your application run on a WebSphere MQ server?
 How should you handle exceptions and errors?

Design Your Message
 What type of message should I use?
 Should I assign different priorities to some of the messages that I create?
 Will my messages be discarded when the queue manager restarts?
 Do I want to give information about myself to the recipient of my messages?
 How many queues will receive my messages?

The message queue interface (MQI) philosophy
 Simple call interface
 Limited number of calls
 Rich in function
 Sensible default and initial values
 Supplied “include” files and “copy” files for the definitions of structures and
constants

Common MQI Calls

Other common MQI Calls
MQPUT1 Opens a queue manager, places a message on the queue, and closes the
queue manager
MQINQ Queries the attributes of a WebSphere MQ object
MQSET Changes the attributes of a queue
MQCONNX Connects to a queue manager using the specified options
MQBEGIN Begins a unit of work coordinated by the queue manager
MQCMIT Commits all message PUT and GET operations made since the last
syncpoint
MQBACK Backs out all message PUT and GET operations made since the last
syncpoint
MQSUB Register subscriptions to a previously published topic
MQSUBR Request a retained publication

 WebSphere MQ Application Programming Reference
MQPUT1 (Hconn, ObjDesc, MsgDesc, PutMsgOpts, BufferLength, Buffer,
CompCode, Reason)
 C equivalent
MQPUT1 (Hconn, &ObjDesc, &MsgDesc, &PutMsgOpts, BufferLength,
Buffer, &CompCode, &Reason);
 COBOL equivalent
CALL "MQPUT1" USING HCONN, OBJDESC, MSGDESC, PUTMSGOPTS,
BUFFERLENGTH, BUFFER, COMPCODE, REASON.

MQCONN Call

MQCONNX Call

MQOPEN Call

Queue definition and independence
Four types of queue that an
application can open:
•Local queues
•Remote queues (local definitions
of remote queues; cannot be
opened for input)
•Alias queues
•Model queues (used to create
queues dynamically)

Model queue definition

MQ Open share options

MQPUT Calls

MQGET Calls

MQGET get message options
 Wait
 Set signal
 Browse from start of queue
 Browse from current position in queue
 Get message under browse cursor
 Within syncpoint control
 Outside of syncpoint control
 Accept truncated message
 Convert application data

MQINQ Calls

MQSET Calls

PROGRAMMING

Sample Function Documentation
 Syntax for MQCONN
– MQCONN (QMgrName, Hconn, CompCode, Reason)
 Parameters for MQCONN
The MQCONN call has the following parameters.
– QMgrName (MQCHAR48) – input
Queue manager names can contain certain characters, and there are other restrictions on their formation. You can
use special values of QMgrName to indicate a default queue manager, a queue-sharing group, or a choice of queue
managers.
– Hconn (MQHCONN) – output
– CompCode (MQLONG) – output
– Reason (MQLONG) – output
The reason code qualifying CompCode.
 Usage notes for MQCONN
Description of function usage

Sample Function Documentation
 Language invocations for MQCONN
– C invocation
• MQCONN (QMgrName, &Hconn, &CompCode, &Reason);
• Declare the parameters as follows:
MQCHAR48 QMgrName; /* Name of queue manager */
MQHCONN Hconn; /* Connection handle */
MQLONG CompCode; /* Completion code */
MQLONG Reason; /* Reason code qualifying CompCode */
– COBOL invocation
• CALL 'MQCONN' USING QMGRNAME, HCONN, COMPCODE, REASON.
• Declare the parameters as follows:
** Name of queue manager
01 QMGRNAME PIC X(48).
** Connection handle
01 HCONN PIC S9(9) BINARY.
** Completion code
01 COMPCODE PIC S9(9) BINARY.
** Reason code qualifying COMPCODE
01 REASON PIC S9(9) BINARY.
– Other languages

Connection Handle
 MQCONN(name, Hconn, …
 MQOPEN(Hconn, …
 MQPUT(Hconn, …
 MQGET(Hconn, …
 MQCLOSE(Hconn, …
 MQOPEN(Hconn, …
 MQPUT(Hconn, …
 MQGET(Hconn, …
 MQCLOSE(Hconn, …
 MQDICS(Hconn, …
 Unique. It is not intended to be
used by the program in any way
BUT to interface with the MQI
 Scope of the handle restricted to
smallest unit of parallel execution
– UNIX/Windows/Linux  Thead
– OS/400  Job
– DOS Client  System
– z/OS  CICS Task, IMS Task,
Batch/TSO Task
EXAMPLE

Object Handle
 MQCONN(name, Hconn, …
 MQOPEN(Hconn,ObjDesc,Options,Hobj,…
 MQPUT(Hconn,Hobj,…
 MQGET(Hconn,Hobj,…
 MQCLOSE(Hconn,Hobj,…
 QOPEN(Hconn,ObjDesc,Options,Hobj,…
 MQPUT(Hconn,Hobj,…
 MQGET(Hconn,Hobj,…
 MQCLOSE(Hconn,Hobj,…
 MQDICS(Hconn, …
 The object handle represents the
access that has been
established to the queue
EXAMPLE

More than one object handle
EXAMPLE

Completion codes
 MQCC_OK
– The call completed fully; all output parameters have been set. The Reason parameter
always has the value MQRC_NONE in this case.
 MQCC_WARNING
– The call completed partially. Some output parameters might have been set in addition
to the CompCode and Reason output parameters. The Reason parameter gives
additional information about the partial completion.
 MQCC_FAILED
– The processing of the call did not complete. The state of the queue manager is
unchanged, except where specifically noted. The CompCode and Reason output
parameters have been set; other parameters are unchanged, except where noted.

Reason codes
 The reason code parameter (Reason) qualifies the completion code parameter (CompCode)
• If CompCode is MQCC_OK:
 MQRC_NONE (0, X'000') No reason to report.
• If CompCode is MQCC_WARNING:
 MQRC_ALREADY_CONNECTED
(2002, X'7D2') Application already connected.
 MQRC_CLUSTER_EXIT_LOAD_ERROR
(2267, X'8DB') Unable to load cluster workload exit.
 MQRC_SSL_ALREADY_INITIALIZED
(2391, X'957') SSL already initialized.
• If CompCode is MQCC_FAILED
 MQRC_ADAPTER_CONN_LOAD_ERROR
(2129, X'851') Unable to load adapter connection module.
 MQRC_ADAPTER_DEFS_ERROR
 (2131, X'853') Adapter subsystem definition module not valid
ETC

Transaction
EXAMPLE Before LUW committed :
•Message remain in Q1 and
marked for deletion but it is not
available to be retrieved by other
programs
•Inserted data in database is not
visible to other programs.
•Message has been put in Q2 is not
visible to other programs.
The current depth reflects these
messages but any attempt to use
MQGET to retrieve them fails with
MQRC_NO_MSG_AVAILABLE
If problem is encountered, all
activities associated with the
LUW can be backed out

Local unit of work
 Syncpoint coordination using single phase commit provided by QM
 Start a unit of work by setting the syncpoint option for each message operation
– MQGET = MQGMO_SYNCPOINT
– MQPUT and MQPUT1 = MQPMO_SYNCPOINT
 Ending the unit of work:
– MQCMIT commits the operations
– MQBACK rolls back the operations
– MQDISC commits the operations
– Connection broken without MQDISC, a rollback happens.
MQPUT #with syncpoint opt
MQGET #with syncpoint opt
MQPUT #with syncpoint opt
If RC = O # no errors
MQCMIT #commit
Else #errors
MQBACK #rollback

Global unit of work
 Different resource manager and their activities can be combined (e.g Database
operations)
 Coordinated by:
• Queue manager (internal syncpoint coordination)
Using MQBEGIN, MQCMIT, MQBACK
• External transaction manager
MQBEGIN, MQCMIT, MQBACK is not required.
Error code MQRC_ENVIRONMENT_ERROR if those functions called.
MQPMO_SYNCPOINT or MQGMO_SYNCPOINT should be specified for
MQPUT or MQGET

MQBEGIN Calls

MQCMIT calls

MQBACK calls
 After rollback, any messages that had been retrieved using an MQGET in syncpoint will
have the BackoutCount incremented by one.

Pseudo code - Transaction
DEFINE GET_OPTIONS AS MQGMO
DEFINE PUT_OPTIONS AS MQPMO
CALL MQCONN(...,
CALL MQOPEN(...,
GET_OPTIONS.Options = MQGMO_NO_WAIT + MQGMO_SYNCPOINT +
MQGMQAIL_IF_QUIESCING
CALL MQGET(...,
PUT_OPTIONS.Options = MQPMO_SYNCPOINT + MQPMO_FAIL_IF_QUIESCING
CALL MQPUT1(...,
CALL MQCMIT(...,
EXAMPLE

Platform considerations for transaction

Trigger Monitor

Trigger conditions
 Trigger conditions is set up as part of queue definition
 Trigger when…
– First message arrived (TRIGTYPE=MQTT_FIRST)
– Some messages arrived (TRIGTYPE=MQTT_DEPTH, TRIGDPTH=X)
– Every message arrived (TRIGTYPE=MQTT_EVERY)

Trigger message (MQTM)
 Trigger message format:
– MQTM,
– MQTMC  used only by AS/400
– MQTMC2
 Fields:
– Strucid
– Version
– QName
– ProcessName
– TriggerData
– ApplType (blank in TMC2)
– Applid
– EnvData
– UserData
– QMgrName (TMC2)

Pseudo code - Trigger
DEFINE OBJJJESC AS MQOD
DEFINE PRIG AS MQTMC2
DEFINE CONN_HANDLE AS MQHCONN
DEFINE OBJ_HANDLE AS MQHOBJ
COPY INPUTPARAMETER TO TRIG
QMNAME = PRIG.QMgrName
QNANE = TRIG.QName
CALL MQCONN (QMNAME, CONN_HANDLE, . ..)
OBJ_DESC.ObjectName = QNAME
CALL MQOPEN(CONN_HANDLE, OBJ_DESC, ..., OBJ_HANDLE, ...)
CALL MQGEP (CONN_HANDLE, OBJ_HANDLE, ...)
EXAMPLE

Data conversion
 Character data is being exchanged between platforms where the CodedCharSetId and
Encoding fields differ
 Performed by
– The queue manager
• Using MQXCNVC (convert characters) call
– User exit program

Sample COBOL code: MQPUT
 http://localhost:49253/help/index.jsp?topic=/com.ibm.mq.csqzal.doc/fg18930_.htm

PROGRAMMING USING JAVA

WebSphere MQ
Java API Alternatives
 WebSphere MQ classes for Java Message Service (WebSphere MQ JMS)
 WebSphere MQ classes for Java (WebSphere MQ base Java)
MQ Interface (MQI)
Base Classes For Java
 MQ Classes for JMS
– Benefits:
• Provider-independence and standards
• Easy publish/subscribe
• Administrative configuration via JNDI
• Message selection
• Integration with J2EE Application Servers
 MQ Classes for Java
– Object oriented form of MQI
– Full access to MQ capabilities
• JMS has a few restrictions, such as no support for
distribution lists

MQ Classes for Java
 Connection options
– As a WebSphere MQ MQI client using TCP/IP
– In bindings mode, connecting directly to WebSphere MQ using the JNI
• Mostly provides better performance
• Application must run on the same system as the queue manager
 Contains in com.ibm.mq.jar & com.ibm.mq.jmqi.jar
 Lib directory
– MQ_INSTALLATION_PATHjavalib or lib64
 Sample directory
– Unix/Linux: MQ_INSTALLATION_PATH/samp/wmqjava/
– Windows: MQ_INSTALLATION_PATHtoolswmqjava

Sample Java code: MQ Classes for Java
Sample can be found in <INSTALL_DIR>/tools/wmqjava/samples
MQQueueManager qMgr = new MQQueueManager(“QMANAGER1”);
int openOptions = MQConstants.MQOO_INPUT_AS_Q_DEF |
MQConstants.MQOO_OUTPUT;
MQQueue queue = qMgr.accessQueue("QUEUE1", openOptions);
MQMessage msg = new MQMessage();
msg.writeUTF("Hello, World!");
MQPutMessageOptions pmo = new MQPutMessageOptions();
queue.put(msg, pmo);
Create a connection to the
QueueManager
Set up the options on the
queue we wish to open
Now specify the queue that
we wish to open and the
open options
Define a simple WebSphere
MQ Message
Specify the default put
message options
Put the message to the
queue

Sample Java code (cont’d)
MQMessage msg = new MQMessage();
MQGetMessageOptions gmo = new MQGetMessageOptions();
queue.get(msg, gmo);
String msgText = msg.readUTF();
queue.close();
qMgr.disconnect();
Define a WebSphere MQ
message to receive the data
Specify default get
message options
Get the message off the
queue and read the text
from message
Close the queue
Disconnect from the
QueueManager

LAB 8: Programming with MQ Classes for Java
 In this Lab, you will learn:
– Using Eclipse to setup Java project for MQ application
– Creating Java application using sample code to GET and PUT data from/into a queue

Java Message Service (JMS) - Overview
 JMS is the standard Java API for messaging
– Point-to-point messaging domain
– Publish/subscribe messaging domain
 Vendor-independent Messaging API in Java
– Specification owned by Sun Microsystems
– Managed by The Java Community Process
– Expert Group includes IBM
 Part of Java 2 Enterprise Edition 1.3 and later
 Defines package of Java Interfaces
– Gives provider-independence
– Does not give provider interoperability
• A standard API, not a standard ‘wire format’

JMS for WebSphere MQ
WebSphere
MQ Server
JMS
Application
JMS layer
JAVA layer
MQI
Application
MQI
Pub/Sub Broker
WebSphere
MQ ServerMQ Protocol
JVM
JMS
Application
JMS layer
JAVA layer
JVM
MQI
Application
MQI
MQI
MQI

JMS Key Concepts - Architecture

 Connection Factory: An
administered object that creates a
connection to the provider's
underlying messaging system.
 Connection: An active connection
to a provider.
 Session: A single-threaded context
for sending and receiving messages.
 Message Producer: Used for
sending messages.
 Message Consumer: Used for
receiving messages.
 Destination: An administered object
that encapsulates the identity of a
message destination, such as where
messages are sent to or received
from.

JMS 1.1 Unified Interfaces

Point to Point Messaging

Point to Point Sample Code

Publish/Subscribe Messaging
 NB This example shows JMS 1.0.2 Interfaces

Publish/Subscribe Sample Code

JMS Message
 Header Fields
– MessageId, CorrelationId
– Destination, ReplyTo
– Priority, Timestamp, Expiry
– …
 Properties – Name/Value pairs
– JMSX – Extended, optional header fields
– JMS_<Vendor> – Vendor-specific
metadata
– User – Application-defined metadata
 Body
– Text – Textual character data
– Bytes – Raw byte stream
– Map – Collection of named, typed fields
– Stream – Sequence of typed fields

JMS Message Format for WebSphere MQ
Data
JMS Message
JMS Client
RFH2
Other Data
MQ Message
Data
Data
JMS Message
JMS Client
Mapping Mapping
Copying Copying
Header
MQMD
PropertiesProperties
Header

Additional Features of JMS
 Message Listener
 Exception Listener
 Temporary Destinations
 Selector
– outMessage.setJMSPriority(7);
– outMessage.setStringProperty(“postcode”, “SO21 2JN”);
– session.createMessageConsumer(queue,“postcode LIKE ‘SO21%’ OR JMSPriority < 3”);
 Queue Browser
 Unidentified Producer
– Destination specified on send() rather than on creation
 Requestor
 Application Server Facilities
 XA Support

JMS Sessions
 Session / QueueSession / TopicSession
 Connection.createSession(boolean transacted, int acknowledgeMode);
– transacted :
• true – client will issue commit/rollback calls
• false – auto-commit
– acknowledgeMode :
• AUTO_ACKNOWLEDGE
• DUPS_OK_ACKNOWLEDGE
• CLIENT_ACKNOWLEDGE
• (SESSION_TRANSACTED)

LAB 9: Setting up JMS Provider
 In this Lab, you will learn:
– Configuring the WebSphere MQ JMS Provider using MQ Explorer
• Create Connection Factory
• Create JMS Destination
– Test JMS application to connection to MQ Server and put message on queue
– Explore JMS sample codes

Coding in Java EE/J2EE Application
 Solution Alternatives:
– WebSphere MQ classes for Java Message Service (JMS)
– WebSphere MQ classes for Java (WMQ base Java)
– WebSphere MQ JCA resource adapter
 WebSphere MQ base Java API has restrictions when
being used within a J2EE/JEE environment
 Check the System Requirements document!

WebSPHERE MQ SECURITY

 Ensure each user is uniquely identified
– Identification:- Being able to uniquely identify a user of a system or an application that is
running in the system.
 Prove that a user is who they say they are
– Authentication:- Being able to prove that a user or application is genuinely who that
person or what that application claims to be.
 Limit Access to authorised users only
– Access Control:- Protects critical resources in a system by limiting access only to
authorised users and their applications. It prevents unauthorised use of a resource or the
use of a resource in an unauthorised manner.
 Track who does what to what and when
– Auditing:- Tracking who has done what to what and when

 Protect your sensitive data from unauthorised viewing
– Confidentiality:- Protects sensitive information from unauthorised disclosure.
 Check unauthorised changes have not been made to data
– Data Integrity:- Detects whether there has been unauthorsied modification of
data. There are two ways in which this can occur, accidentally, through
hardware or transmission errors, or by deliberate attack.
 Ensure a message really is associated with whom it claims
– 'Non-Repudiation':- The goal is usually to prove that a particular message is
associated with a particular individual.

Identification
 Identification
– O/S User IDs
– Context
– Link-level considerations (later)
What is Context information?

Authentication - MQCONNX
 MQCSP structure in the Connection
Options (MQCNO structure)
– Connection Security Parameters
– User ID and password
 MQCSP passed to
– Object Authority Manager (OAM)
– Security Exit
 OAM is authorization service that can
use to identify and authenticate the
user.
 The OAM authorizes users based on
the ID contained in the MQCSP but
does not validate the password
MQCSP csp = {MQCSP_DEFAULT};
csp.AuthenticationType = MQCSP_AUTH_USER_ID_AND_PWD;
csp.CSPUserIdPtr = “hughson”;
csp.CSPUserIdLength = 7;
csp.CSPPasswordPtr = “12345”;
csp.CSPPasswordLength = 5;
MQCNO cno = {MQCNO_DEFAULT};
cno.Version = MQCNO_VERSION_5;
cno.SecurityParmsPtr = &csp;
MQCONNX(QMName, &cno, &hConn, &CompCode, &Reason);
To implement password validation in the
authorization service
•by using chained exits with the OAM,
•by replacing the OAM with an alternative
authorization service.

Access Control – Administering WebSphere MQ
New in V7.1

Controling Access to Object (1)
 Command:
setmqaut -m QMgrName -n ObjectProfile -t Type -g GroupName Action
– Type: queue, topic, channel, qmgr, process, namelist, service
– Action:
• +chg, +clr, +crt, +dlt, +dsp. +ctrl
• +alladm = +chg +clr +dlt +dsp
 Showing access:
– dspmqaut -m QMgrName -t qmgr -g GroupName
– dspmqaut -m QMgrName -n QueueName -t q -p UserName

Read-only access to all resource in Queue Manager
 Read-only access to all resource in Queue Manager
setmqaut -m QMgrName -n "**" -t queue -g GroupName +browse +dsp
setmqaut -m QMgrName -n SYSTEM.ADMIN.COMMAND.QUEUE -t queue -g GroupName +dsp +inq +put
setmqaut -m QMgrName -n SYSTEM.MQEXPLORER.REPLY.MODEL -t queue -g GroupName +dsp +inq +get
setmqaut -m QMgrName -n "**" -t topic -g GroupName +dsp
setmqaut -m QMgrName -n "**" -t channel -g GroupName +dsp
setmqaut -m QMgrName -n "**" -t clntconn -g GroupName +dsp
setmqaut -m QMgrName -n "**" -t authinfo -g GroupName +dsp
setmqaut -m QMgrName -n "**" -t listener -g GroupName +dsp
setmqaut -m QMgrName -n "**" -t namelist -g GroupName +dsp
setmqaut -m QMgrName -n "**" -t process -g GroupName +dsp
setmqaut -m QMgrName -n "**" -t service -g GroupName +dsp
setmqaut -m QMgrName -t qmgr -g GroupName +dsp +inq +connect

Full admin access to all resource in Queue Manager
 Full admin access to all resource in Queue Manager
– setmqaut -m QMgrName -n "**" -t queue -g GroupName +alladm +browse
– setmqaut -m QMgrName -n @class -t queue -g GroupName +crt
– setmqaut -m QMgrName -n SYSTEM.ADMIN.COMMAND.QUEUE -t queue -g GroupName +dsp +inq +put
– setmqaut -m QMgrName -n SYSTEM.MQEXPLORER.REPLY.QUEUE -t queue -g GroupName +dsp +inq +get
– setmqaut -m QMgrName -n "**" -t topic -g GroupName +alladm
– setmqaut -m QMgrName -n @class -t topic -g GroupName +crt
– setmqaut -m QMgrName -n "**" -t channel -g GroupName +alladm
– setmqaut -m QMgrName -n @class -t channel -g GroupName +crt
– setmqaut -m QMgrName -n "**" -t clntconn -g GroupName +alladm
– setmqaut -m QMgrName -n @class -t clntconn -g GroupName +crt
– setmqaut -m QMgrName -n "**" -t authinfo -g GroupName +alladm
– setmqaut -m QMgrName -n @class -t authinfo -g GroupName +crt
– setmqaut -m QMgrName -n "**" -t listener -g GroupName +alladm
– setmqaut -m QMgrName -n @class -t listener -g GroupName +crt
– setmqaut -m QMgrName -n "**" -t namelist -g GroupName +alladm
– setmqaut -m QMgrName -n @class -t namelist -g GroupName +crt
– setmqaut -m QMgrName -n "**" -t process -g GroupName +alladm
– setmqaut -m QMgrName -n @class -t process -g GroupName +crt
– setmqaut -m QMgrName -n "**" -t service -g GroupName +alladm
– setmqaut -m QMgrName -n @class -t service -g GroupName +crt
– setmqaut -m QMgrName -t qmgr -g GroupName +alladm +conn

CHLAUTH rules – Default rules on new Queue Managers
 Channel authentication records should be enabled
• ALTER QMGR CHLAUTH(ENABLED)
 Display CLHAUTH
– DIS QMGR CHLAUTH
– DIS CHLAUTH(*)
 Default rules on new Queue Managers
1)set chlauth(‘*’) type(BLOCKUSER) USERLIST(‘*MQADMIN’)
• block all users that are in the MQ admin group, from connecting to the queue manager
1)set chlauth(‘SYSTEM.*’) type(ADDRESSMAP) ADDRESS(‘*’) USERSRC(NOACCESS)
• block connections to the queue manager, using any of the SYSTEM. channels that are predefined
1)set chlauth(SYSTEM.ADMIN.SVRCONN) type(ADDRESSMAP) ADDRESS(‘*’) USERSRC(CHANNEL)
• allow connections to the queue manager, using SYSTEM.ADMIN.SVRCONN (MQ Explorer
connections)

Access Right to Connect to Queue Manager
 Mapping a remote queue manager to an MCAUSER user ID
–SET CHLAUTH('generic-channel-name') TYPE (QMGRMAP) QMNAME(generic-partner-qmgr-name) USERSRC(MAP)
MCAUSER(user)
 Mapping a client asserted user ID to an MCAUSER user ID
–SET CHLAUTH('generic-channel-name') TYPE (USERMAP) CLNTUSER(client-user-name) USERSRC(MAP)
MCAUSER(user)
 Mapping an IP address to an MCAUSER user ID
–SET CHLAUTH('generic-channel-name') TYPE(ADDRESSMAP) ADDRESS('generic-ip-address') USERSRC(MAP)
MCAUSER(user)
–Example:
• SET CHLAUTH(TEST_CHANNEL) TYPE(ADDRESSMAP) ADDRESS(*) MCAUSER('mq-user')
• It says the following:
– For connections requesting TEST_CHANNEL...
– Originating from any IP address...
– Set the MCAUSER to mq-user
Note: generic-channel-name = * means all channel

 Blocking specific user IDs
• SET CHLAUTH('generic-channel-name') TYPE(BLOCKUSER) USERLIST(userID1, userID2)
 Blocking specific IP addresses
• SET CHLAUTH('generic-channel-name') TYPE(BLOCKADDR) ADDRLIST('1.2.3.4')
• SET CHLAUTH('generic-channel-name') TYPE(ADDRESSMAP) ADDRESS('1.2.3.4') USERSRC(NOACCESS)
 Block all except specified IP addresses
– SET CHLAUTH( '*') TYPE(ADDRESSMAP) ADDRESS( '*') USERSRC(NOACCESS) DESCR( 'Block all addresses')
– SET CHLAUTH( '*') TYPE(ADDRESSMAP) ADDRESS( ‘ip-addresses') USERSRC(MAP) MCAUSER( ‘username')
 Allow IP address without mapping the User ID to MCAUSER
– SET CHLAUTH('*') TYPE(ADDRESSMAP) ADDRESS(‘ip-address') USERSRC(CHANNEL)
 See what MCAUSER all your channels are currently running
– DISPLAY CHSTATUS(chl-name) MCAUSER
Note: You cannot specify MCAUSER('*').

Auditing
Distributed Platforms
MQRC_NOT_AUTHORIZED events written to SYSTEM.ADMIN.QMGR.EVENT queue
The event showing specifically what kind of access was attempted and different reason
qualifier recorded in the event message.
– MQRQ_CONN_NOT_AUTHORIZED
– MQRQ_OPEN_NOT_AUTHORIZED
– MQRQ_CLOSE_NOT_AUTHORIZED
– MQRQ_CMD_NOT_AUTHORIZED
– MQRQ_SUB_NOT_AUTHORIZED
– MQRQ_SUB_DEST_NOT_AUTHORIZED

List Connections
 DISPLAY CONN(*) ALL
AMQ8276: Display Connection details.
CONN(AB548F5220032801)
EXTCONN(414D5143514D2E544553542020202020)
TYPE(CONN)
PID(20964) TID(13)
APPLDESC(WebSphere MQ Channel) APPLTAG(MQ Explorer 7.5.0)
APPLTYPE(SYSTEM) ASTATE(STARTED)
CHANNEL(SVRCONN.MQOPR) CONNAME(127.0.0.1)
CONNOPTS(MQCNO_HANDLE_SHARE_BLOCK,MQCNO_SHARED_BINDING)
USERID(mqopr) UOWLOG( )
UOWSTDA( ) UOWSTTI( )
UOWLOGDA( ) UOWLOGTI( )
URTYPE(QMGR)
EXTURID(XA_FORMATID[] XA_GTRID[] XA_BQUAL[])
QMURID(0.0) UOWSTATE(NONE)

Problem Determination & Troubleshooting

Questions when problem occurs
 Has WebSphere MQ run successfully before?
 Are there any error messages?
 Does the Windows Application Event Log show any WebSphere MQ errors? (Windows only)
 Are there any return codes explaining the problem?
 Can you reproduce the problem?
 Have any changes been made since the last successful run?
 Has the application run successfully before?

Troubleshooting
 Check the channel
– View channel status: DIS CHS(*) STATUS
• “AMQ8420: Channel Status not found” may resulted long interval of inactivity.
The receiver channel status will not be displayed until the channel is started
on the sending side.
– Find channel in-doubt status: DIS CHS(*) INDOUBT
• In-doubt status (and the units of work involved) are resolved automatically between
MCAs when a channel is restarted.
• Resolve manually:
RESOLVE CHANNEL(CHNAME) ACTION(COMMIT | BACKOUT )
RESET CHANNEL
– Find out more: DIS CHS(*) SUBSTATE

Troubleshooting DLQ
 When messages are placed onto the Dead Letter Queue (such as
SYSTEM.DEAD.LETTER.QUEUE), a special header is attached to the message giving
information on why the message has been put onto the queue (reason code).
 Troubleshoot using command: amqsbcg DLQ QM1 > amqsbcg.txt
Location:
– WMQ_INSTALL_DIRtoolscSamplesBin (Windows)
– /opt/mqm/samp/bin (UNIX)

Troubleshooting DLQ
• 5th and 6th pairs from the Left is
Reason Code.

Troubleshooting DLQ
• Use mqrc command to know the Reason Code, can use hexadecimal or decimal
• For Unix (except for Linux on x86 – Intel): mqrc 0x000007F3
• For Linux or Windows on x86 the Reason Code is in little-endian format (low-order bytes
first). Example: 0A01 0000  0000 010A  266 in decimal
Command: mqrc 266
• Example result:
• 2085 0x00000825 MQRC_UNKNOWN_OBJECT_NAME
• 2035 0x000007f3 MQRC_NOT_AUTHORIZED
• It is far easier to find out the reason code by browsing a message from the DLQ via MQ
Explorer. It handles the swapping of bytes according to platform.
• You can do reverse lookup via mqrc: mqrc MQRC_UNKNOWN_OBJECT_NAME

Error Log
 Error log locatoin:
– /var/mqm/errors
– /var/mqm/qmgrs/<queueManagerName>/errors
– /var/mqm/qmgrs/@SYSTEM/errors (not used at V6 and higher)
 Error log files: AMQERR01.LOG, AMQERR02.LOG and AMQERR03.LOG
 Find FFST record in FDC file: AMQnnnnnnnn_mm.FDC
nnnnnnnn Is the process id reporting the error
 Run command: ffstsummary

Killing queue managers process
 The first process to end is amqzmuc0 – the critical process manager. This contains the
logger, and ending it prevents any further transactional work.
 The next process to end is amqzxma0 – the execution controller. The execution controller
identifies when other processes die. Stopping this prevents it from producing a pile of
“Process X has died” FFST error reports as they are ended. It also prevents any new
connections being made to the queue manager.
 At the other end of the list is amqpcsea – the command server. By this point in the list,
these are processes which do not access any critical queue manager resources, so can be
safely left until last.

Checking OS resource
 Use mqconfig script to know how to tune the operating system, including user limits and
kernel parameters for resources like shared memory and semaphores.
 http://www-01.ibm.com/support/docview.wss?uid=swg21271236#mqconfig

Escalate problem to IBM Support – Creating PMR
 Make sure you know your IBM Customer Number
 Call IBM WebSphere Support (http://www.ibm.com/planetwide/id/)
Tel: +62-21- 2992 5555
Tel: 1-803-422-291
– Customer name, IBM Customer number
– Software name and version & fix pack level
– OS version & fix pack level
– Brief description of the problem
– Severity of the problem: 1 is the highest (need 24 hours contactable number)
 You will get PMR number and IBM Support engineer will contact you via email/phone

Collect MustGather
 http://www-01.ibm.com/support/docview.wss?uid=swg21229861
 Collect IBM MQ MustGather data when you first open a problem record so you can provide
IBM support the information they need to investigate the problem. Start by selecting the
category which best matches the problem on your system:

What next?

SupportPac
MA46: WebSphere MQ Java client for iSeries V7.0
MA6O: WebSphere MQ - UNIX Administration Tool
MH04: WebSphere MQ - Queue Statistics Tool
MQC7: WebSphere MQ V7.0 Clients
MA96: WebSphere MQ - Message Browser
MS0T: WebSphere MQ Explorer
MS0Q: WebSphere MQ Explorer Publish/Subscribe
plug-in
MS0S: WebSphere MQ Explorer MQSC Editor Plug-in
MS0P: WebSphere MQ Explorer - Configuration and
Display Extension Plug-ins
MO71: WebSphere MQ for Windows GUI
Administrator
MSL1: WebSphere MQ for Linux - Automatic Startup
MS0P: WebSphere MQ Explorer - Configuration and
Display Extension Plug-ins
MA0T: WebSphere MQ - Message Test Utility
MA0Y: WebSphere MQ Bridge for HTTP
http://www-01.ibm.com/support/docview.wss?uid=swg27007197#1
Check SupportPacs web page to find tools/document that might help you.

Cat2 ME02: Search Plug-in

Cat2 MS0P: Events and Stats Plug-in
Now with Command Events!

Cat2 MS0P: Using Trace-route

Cat3 IS02: Message Broker Admin Plug-in

Multi-instance queue managers: How it looks
 As a graphical example, SupportPac MS0P V7.0.1

HTTP Connectivity to WMQ
 Easy access to MQ resources from any device with an HTTP interface
 Extends the scope beyond traditional systems
 Alternative implementation as SupportPac MA94
MQ HTTP Bridge
MQ
JCA +
JMS
http://mq.com:1415/msg/
queues/myQ
topics/stocks/IBM
HTTP: POST /
GET / DELETE
libwww
Web
Browsers
Javascript
AJAX
HTTP
clients
JEE Application Server
Java
SVRCONN
CHANNEL
MQ Bindings
Connection
MQ JMS
client
connection
Queue Manager

Learning Resource

developerWorks

InfoCenter: WebSphere MQ Documentation
http://publib.boulder.ibm.com/infocenter/wmqv7/v7r1/index.jsp?topic=%2Fcom.ibm.mq.doc%2Fzl00000_.htm

IBM WebSphere MQ Introduction

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (20)

Similaire à IBM WebSphere MQ Introduction

Similaire à IBM WebSphere MQ Introduction (20)

Plus de ejlp12

Plus de ejlp12 (20)

Dernier

Dernier (20)

IBM WebSphere MQ Introduction

Notes de l'éditeur