Ibm Websphere MQ Basics: What Is Mqseries?

97
IBM Websphere MQ basics

What is MQSeries?
A middleware product that implements a messaging and queuing framework.
Middleware – an intermediate software component that bridges dissimilar computing
environments.
Messaging – programs communicate by sending data in messages rather than by calling
each other directly.
Queuing – messages are put on queues in storage, eliminating the need for programs to be
logically connected.
A messaging and queuing framework is inherently ASYNCHRONOUS!
MQSeries Objects (the basics)

Queue Manager
A queue manager is that part of an MQSeries product that provides the messaging
and queuing services to application programs, through the Message Queue Interface
(MQI) program calls. It controls access to queues and serves as transaction
(syncpoint) coordinator for all queue operations.
Queue manager names must be unique!
Queues
MQSeries defines four types of queues. A queue instance is fully qualified by its
queue manager and queue name.
Local Queue – an actual queue for which storage is allocated.
Remote Queue – a definition of a queue on a different queue manager (acts
somewhat like a pointer)
Alias Queue – another name for a local or remote queue. Typically used to switch
queue destinations without modifying program code
Model Queue – a template whose properties are copied when creating a new
dynamic local queue (“ create queue xxx “like” queue yyy).
Some properties of local queues:

 Maximum Message Size
 Maximum Queue Depth
 High/Low Factors
97
 Enable/Disable Put or Get

 Persistent/Not Persistent
Local queues can generate events (messages) under certain conditions (like queue full).
These “event” messages can be used to “trigger” the execution of a program.
These events are called trigger messages. The queue on which they are put is called an
Initiation Queue.
Process
· Process defines an application to an MQSeries queue manager. A process definition object
is used for defining applications to be started by a trigger monitor.
· A trigger monitor is a program that listens on an initiation queue and executes commands
named in Process definitions.
Triggers and Process definitions are useful when you don’t want to deploy long-running
programs. Suppose the message rate is very low (several minutes between requests).
Perhaps it is better to instantiate the program for each message, and then let it exit.
Channels
A channel provides a communication path between Queue Managers. There are two types
of channels – Message Channels and MQI channels (also called Client channels).
Message channels – provide a communication path between two queue managers on the
same, or different, platforms.
A message channel can transmit messages in one direction only. If two-way
communication is required between two queue managers, two message channels are
required.
There are six types of message channels:
 1. Sender – initiates connection to Receiver
 2. Server – Accepts request to start from requester, then becomes Sender
 3. Receiver – Passive; waits for initiation sequence form Sender
 4. Requester – Active at start, then becomes Receiver
 5. Cluster-sender (used amongst Cluster Queue Managers)
 6. Cluster-receiver (ditto)
The Sender side of the session is the “transaction coordinator”.
Message channels implement a protocol that includes a commitment protocol.
Channels recover from failure by agreement: they must agree on the last committed unit
of work [would this be harder if channels were bi-directional??]
97
MQI channels – connect an MQSeries client to a queue manager on a server machine

(where a queue manager is defined). Used for transfer of MQI calls and responses only and
is bi-directional.
Benefits of Websphere MQ
Interoperabilty
across dissimilar networks

between different computing environments
Asynchrony
Eliminates the time dependency between applications (both apps must be
alive AND have a session in synchronous models).
Fewer Network Sessions
Only Queue Mangers need to communicate using network sessions.
Administered Objects
Improves manageability of BIG systems -
Can monitor the state of a queue to determine if apps are doing what they should:
Does any process have queue open for reading or writing?

Has a high water mark been reached?
How many messages have been added and removed in a measured interval?
Message Persistence == Assured Delivery
Queues in stable storage retain messages even if applications fail.
Even memory-only queues persist if at least the Queue Manager stays up.
Transaction Support
Queue operations are just like reads and writes in a database transaction!
Can we combine queue operations AND database operations atomically?
(YES!)
97
Websphere MQ FFST
What is FFST?
FFST stands for First Failure Support Technology, and is technology within
WebSphere MQ designed to create detailed reports for IBM Service with information
about the current state of a part of a queue manager together with historical data.
What are they for?
They are used to report unexpected events or states encountered by WebSphere
MQ. (Alternatively, they can be generated upon request).
Note that return codes are used for application programmers to inform them of
expected states or errors in a WebSphere MQ application. There are exceptions to
this rule, but as a rule of thumb, FFSTs are used to report something that will need
to be actioned by:
• system administrators – such as where FFSTs report resource issues such as
running low on disk space
• IBM – where FFSTs report a potential code error in WebSphere MQ that (unless
already identified and corrected in existing maintenance) may need correcting
Where are they?
On UNIX systems, they are written to /var/mqm/errors
They are contained in files with the extension .FDC
The file name will begin with AMQ followed by the process id for the process which
reported the error. e.g /var/mqm/errors/AMQ12345.0.FDC – is the first FFST file
produced by a process with ID 12345
What do they contain?
FFST files are text files containing error reports for a single process.
If a single process produces more than one error report, these are all included
within the same FFST file for that process, in the order in which they were
generated.
How should I look at these files?
FFST files are just text files, so your favorite text editor is normally the best place
to start.
97
The tool ffstsummary is also useful – it produces a summary of FFST reports in the
current directory, sorted into time order. This can be a good place to start to see
the errors reported in your errors directory.
For example:
[mqm@test~]$ cd /var/mqm/errors
[mqm@test errors]$ ffstsummary
AMQ21433.0.FDC 2007/04/10 10:05:45 amqzdmaa 21433 2 XC338001
xehAsySignalHandler xecE_W_UNEXPECTED_ASYNC_SIGNAL OK
AMQ21429.0.FDC 2007/04/10 10:05:45 amqzmur0 21429 2 XC338001
AMQ21469.0.FDC 2007/04/10 10:05:45 runmqlsr 21469 2 XC338001
AMQ21422.0.FDC 2007/04/10 10:05:45 amqzfuma 21422 2 XC338001
AMQ21424.0.FDC 2007/04/10 10:05:45 amqzmuc0 21424 2 XC338001
AMQ21431.0.FDC 2007/04/10 10:05:45 amqrrmfa 21431 2 XC338001
AMQ21449.0.FDC 2007/04/10 10:05:45 amqzlaa0 21449 2 XC338001
AMQ21434.0.FDC 2007/04/10 10:05:45 amqzmgr0 21434 2 XC338001
AMQ21452.0.FDC 2007/04/10 10:05:45 runmqchi 21452 2 XC338001
AMQ21417.0.FDC 2007/04/10 10:05:45 amqzxma0 21417 4 XC338001
[mqm@testerrors]$
The columns in the output above show:
• filename – which FDC file contains the FFST report
• time and date of the report
• process name – name of the process which produced the report
• process and thread ids – for the process which produced the report
• probe id
97
• component – part of WebSphere MQ where the report was produced

• error code – major errorcode and minor code
What does an FFST report contain?
I’ve added some numbers on the left to mark out points worth noting…
Sample FFST Report:
+—————————————————————————–+
| |
| WebSphere MQ First Failure Symptom Report |
|
=========================================
|
| |
(1) | Date/Time :- Wednesday Feb 02 13:25:56 IST 2008 |
(2) | Host Name :- joseph.joseph.com (Linux 2.6.9-42.0.10.EL) |
| PIDS :- 5724H7207 |
(3) | LVLS :- 6.0.2.0 |
| Product Long Name :- WebSphere MQ for Linux (POWER platform) |
| Vendor :- IBM |
(4) | Probe Id :- XC338001 |
| Application Name :- MQM |
(5) | Component :- xehAsySignalHandler |
(6) | SCCS Info :- lib/cs/unix/amqxerrx.c, 1.214.1.4 |
| Line Number :- 737 |
| Build Date :- Sep 21 2007 |
| CMVC level :- p600-200-060921 |
| Build Type :- IKAP – (Production) |
(7) | UserID :- 00011243 (mqm ) |
( | Program Name :- runmqlsr |
| Addressing mode :- 64-bit |
(9) | Process :- 16337 |
| Thread-Process :- 16337 |
(10) | Thread :- 2 |
| ThreadingModel :- PosixThreads |
97
(11) | Major Errorcode :-

xecE_W_UNEXPECTED_ASYNC_SIGNAL |
| Minor Errorcode :- OK |
| Probe Type :- MSGAMQ6209 |
| Probe Severity :- 3 |
(12) | Probe Description :- AMQ6209: An unexpected asynchronous signal
(2 : |
| SIGINT) has been received and ignored. |
| FDCSequenceNumber :- 0 |
| Arith1 :- 2 2 |
(13) | Comment1 :- SIGINT |
| Comment2 :- Signal sent by pid 0 |
| |
+—————————————————————————–+
(14) MQM Function Stack
xehAsySignalMonitor
xehHandleAsySignal
xcsFFST
(15) MQM Trace History
{ xppInitialiseDestructorRegistrations
} xppInitialiseDestructorRegistrations rc=OK
{ xehAsySignalMonitor
-{ xcsGetEnvironmentInteger
–{ xcsGetEnvironmentString
–} xcsGetEnvironmentString rc=xecE_E_ENV_VAR_NOT_FOUND
(16) Process Control Block
0x80006ad890 58494850 000029E8 00003FD1 00000004 XIHP..)…?…..
0x80006ad8a0 00000000 10029F70 00000000 10033A50 …….p……
0x80006ad8b0 00000000 00000000 00000000 00000000 …………….
0x80006ad8c0 to 0x80006ad900 suppressed, 5 lines same as above
0x80006ad910 00000000 00000001 00000000 00000000 …………….
0x80006ad920 00000000 00000000 00000000 00000000 …………….
0x80006ad930 to 0x80006ad9d0 suppressed, 11 lines same as above
97
0x80006ad9e0 00000000 00000000 00000001 00568001 ………….V..

0x80006ad9f0 00FB8000 00000000 00000080 00760000 ………….v..
0x80006ada00 00000000 00000000 00000000 00000000 …………….
0x80006ada10 to 0x80006ae9f0 suppressed, 255 lines same as above
0x80006aea00 00000000 FFFFFFFF FFFFFFFF 00000000 …………….
0x80006aea10 00000000 00000000 00000001 FFFFFFFE …………….
0x80006aea20 00000001 00000000 00000000 00000000 …………….
0x80006aea30 00000080 0069A380 00000000 00000000 …..i……….
0x80006aea40 00000000 00000000 00000000 00000000 …………….
etc
(17) Environment Variables:
MANPATH=/opt/csm/man:
HOSTNAME=joseph.joseph.com
TERM=xterm
SHELL=/bin/bash
HISTSIZE=1000
SSH_CLIENT=::ffff:9.20.94.90 2625 22
QTDIR=/usr/lib/qt-3.3
OLDPWD=/root
SSH_TTY=/dev/pts/1
USER=root
LS_COLORS=no=00:fi=00:di=00;34:ln=00;36:pi=40;33:so=00;35:bd=40;33;01:
cd=40…
KDEDIR=/usr
MAIL=/var/spool/mail/root
PATH=/usr/kerberos/sbin:/usr/kerberos/bin:/opt/csm/bin:/usr/local/sbin:/usr/local
/bin:/sbin:/bin:…
INPUTRC=/etc/inputrc
PWD=/var/mqm/errors
LANG=en_GB.UTF-8
SSH_ASKPASS=/usr/libexec/openssh/gnome-ssh-askpass
SHLVL=1
HOME=/root
97
LOGNAME=root
SSH_CONNECTION=::ffff:9.20.94.90 2625 ::ffff:9.20.63.20 22
LESSOPEN=|/usr/bin/lesspipe.sh %s
G_BROKEN_FILENAMES=1
_=/usr/bin/runmqlsr
1. Date and time that this report was produced
For many problems, this is the most useful piece of information – allowing an error
report to be correlated with other known events.
2. hostname for the machine where this report was produced
3. Version and maintenance level for WebSphere MQ
This is useful when comparing an error report against a documented known
problem.
4. Probe ID
This is an internal method of identifying the error report. It identifies a single point
in the WebSphere MQ source code where the report was produced (consisting of
two letters giving a component code, a three digit function code, and a three digit
probe identifier).
This often makes it the best way to uniquely identify the error that the report is
describing. More on this a bit later…
5. Component
this is the bit of WebSphere MQ which produced the report. As with the source
information below, it is generally more useful to us than it is to users, although the
name can sometimes give a useful hint as to the nature of the error report. For
example, in this case where the report is the result of my using Control-C to
generate an interrupt signal, you can see that the component which produced the
report was a signal handler.
6. source information
Although this isn’t information isn’t useful to users, I thought it might be
interesting to highlight that an FFST will identify exactly where it was produced,
down to the source code file, line number and version
7. User id that was running the process which produced the report This is useful
to confirm whether a problem was the result of insufficient user privileges.
8. process name of process which produced the report
97
9. process id for the process which produced the report

10. thread id for the process which produced the report
11. error codes for the report
12. a longer description of the error code for the report
This is a textual (English) description containing information that a WebSphere MQ
developer thought might be helpful if the situation were to occur. Sometimes this
information may be useful to users, such as messages identifying an operating
system function which has failed and what the error code was. Other times, it will
only useful to IBM Service.
13. additional comment information
14. function stack for the process at the time of the report
15. a history of function calls made by the process leading up to the report
16. A series of dumps
In the WebSphere MQ source code, functions can register data items that may be
of interest. If it has something that could be useful (such as in diagnosing or
debugging a problem), it can register it with the engine that produces FFST
reports. This means that in the event of an FFST being produced, this data will be
included. These items are deregistered when a function completes.
This is normally of more use to IBM Service than users, however there may be
times – such as when some message data is included – when you will recognise
some of the data here.
17. environment variables for the the environment of the process which produced
the report
What can I do if I have an FFST report?
Monitoring for the production of FDC files is an important part of handling the
occurrence of errors in a WebSphere MQ system. Prompt handling of a problem can
be key to a timely resolution.
If an FDC file is created, the next step is probably to determine if this is something
that requires you to take an action, and if so how urgent is it. A number of factors
will influence this, including:
• Are queue managers running?
• Are applications still working?
• Does the probe description give any insight into why the FFST was generated?
97
• Does the time and date of the FFST correspond with any other known events or
occurrences at the same time which may explain the error?
If the FFST identifies a resource issue, such as low disk space, then this will
normally give enough information for a system administrator to identify and correct
the source of the problem.
If you are unable to determine an explanation for the FFST, then a useful next step
is to look to see if others have seen this FFST before, and if so what they found it
to mean and needed to do.
This is where the probe id from the FFST is very useful. In the majority of cases
(for one notable exception, see my discussion on signals below), this will be a
unique eye-catcher for the issue being reported. This means that you can search
for this short string on the WebSphere MQ support site on ibm.com or in the IBM
Support Assistant. Often, this will reveal cases where someone has encountered
this FFST before and the fix that resulted.
Beyond this point, you will most likely need to raise a PMR with IBM Service. It is
useful to send all FFSTs from your system (rather than just the one that you
believe to be of interest), as following the history can be key to resolving an issue.
It is also useful to send the WebSphere MQ system (/var/mqm/errors/AMQ*.LOG)
and queue manager (/var/mqm/qmgrs/errors/AMQ*.LOG) error logs, together with
a clear description of what you are seeing and the impact on the system and your
business.
Signal handling
Generally find the probe id to be a unique identifier for a specific problem. While
this is usually true, one notable exception is FFSTs produced by the signal and
exception handlers.
The signal handler component produces FFSTs to report signals sent to WebSphere
MQ processes. This means that the information in the FFST (such as the probe id
and source code file, line number, etc.) is about the signal handler which caught
the signal, not whatever it was that caused or created the signal.
This is less of a problem if the signal was generated externally to WebSphere MQ,
such as the SIGINT that I generated with Ctrl-C in the example above. The FFST
contains information about the process which was sent the signal and the time and
date of the signal.
97
It can be more complex if the signal is generated from elsewhere within

WebSphere MQ, such as a SIGSEGV from a segmentation fault in another
WebSphere MQ process. The exception handler will generate an FFST to record the
SIGSEGV, however it is important to bear in mind that any such FFST contains a
report about where the SIGSEGV was caught, not where it was generated. This
doesn’t mean that the cause cannot be found, but it does mean that the FFST
information such as the probe id is not necessarily the sort of unique eye-catcher
described above.
Generating FFSTs on request
I mentioned above that it is possible to generate FFSTs manually. This can be done
using the following commands:
amqldbgn -p PID (on Windows)
or
kill -USR2 PID (on UNIX platforms)
where PID is the process ID for a WebSphere MQ process. FFST reports generated
in this way will have a probe id that ends in 255.
97
Websphere MQ XA Configuration
Websphere MQ XA Configuration
Configuring and using XA transactions with WebSphere MQ V6 Classes for Java
Steps Involved:
a. prepare the XA switch files
b. Configure queue manager to load switch files
c. configure the database
a) Prepare the XA switch files

An XA switch file is a shared library that defines the names of XA functions
implemented in the resource manager. On Windows, the switch libraries are
precompiled and supplied in the install path\Java\lib\jdbc directory (the default
install path is C:\Program Files\IBM\WebSphere MQ).
On UNIX®, you must link object files to their corresponding database libraries
before use. The required libraries are:
jdbcdb2.o
Switch library for DB2 Universal Database V8.2
jdbcora.o
Switch library for Oracle 9i Release 2 and Oracle 10g Release 1.
Both 32-bit and 64-bit versions of the object files are supplied, in the install
path/java/lib/jdbc and install path/java/lib64/jdbc directories respectively.
Makefiles to link the object files are also supplied. These use DB2_HOME and
ORACLE_HOME to define where the database has been installed, which must be set
appropriately. The WebSphere MQ libraries must also be on the system path.
Finally, change to the appropriate jdbc directory (/lib/jdbc for 32-bit, /lib64/jdbc for
64-bit) and issue the command make db2 to build the DB2 switch library and make
oracle to build the corresponding Oracle library. A 32-bit switch library will be
copied to the /var/mqm/exits directory, while a 64-bit switch library will be copied
to /var/mqm/exits64.
b) Configure the queue manager to load the switch file
Once the switch files are ready, you must configure the queue manager to use
them. Here are the parameters you need to define:
97
Name
A unique string that identifies the resource manager. It may be up to 31 characters
in length. This field must be provided.
Switch File
Name of switch library to use (for example, jdbcdb2.dll). Do not use the full path.
XAOpenString
A String containing data to be passed into the database’s xa_open function. This
parameter is product-specific, and generally contains authentication and
configuration information.
XACloseString
A String containing data to be passed into the database’s xa_close function. This
parameter is also product-specific, and is usually empty.
Thread of Control
Set to PROCESS (the default), or to THREAD. The default PROCESS option forces
the queue manager to serialize XA function calls so that only one call per process is
made at any time. The THREAD option offers improved performance if the database
can manage concurrent calls. This setting must match any thread settings in the
XAOpenString
When using Oracle, the XAOpenString is a plus-separated String of the form:
Oracle_XA + required fields + optional fields
Where required fields are Acc=P/user/password (or =P// if a username and
password are not supplied), and SesTm=timeout, which defines the session
timeout after which the transaction is rolled back. Important optional parameters
include a database name, DB=database name, and the thread of control
parameter, threads={true,false}, which specifies if an application is multi-
threaded.
Example:
Oracle_XA+Acc=P/testuser/secret+SesTm=35+DB=TestDB+threads=true
On UNIX platforms, you must manually edit the qm.ini file, which is in
/var/mqm/qmgrs/qmname/, where qmname is the name of the queue manager
being accessed. Add the following stanza to the file:
XAResourceManager:
97
Name=ExampleDB
SwitchFile= < jdbcdb2 or jdbcora >
XAOpenString= < xa open string >
ThreadOfControl= < THREAD | PROCESS >
where the SwitchFile, XAOpenString, and ThreadOfControl parameters have
suitable values for the database being used. No XACloseString is required, and it
does not need to be added to the stanza. Restart the queue manager so this
change will take effect.
You can use multiple stanzas to register multiple datasources.
Example:
XAResourceManager:
Name=OracleDB1
SwitchFile=jdbcora
XAOpenString=+Acc=P/testuser/secret+SesTm=35+DB=testdb+threads=true
ThreadOfControl=THREAD
XAResourceManager:
Name=OracleDB2
SwitchFile=jdbcora
XAOpenString=+Acc=P/testuser/secret+SesTm=35+DB=testdb+threads=true
ThreadOfControl=THREAD
c) Configure the database
Finally, you may need to configure the database.
When using Oracle 9i, you may need to run two scripts, initxa.sql and initjvm.sql,
to configure the database to participate in XA transactions.
In addition, the Oracle user name specified in the XA open String must have
permission to access the DBA_PENDING_TRANSACTIONS table used internally by
the Oracle database to manage transaction recovery. To allow this, as SYSOPER or
SYSDBA, run the command:
GRANT SELECT ON DBA_PENDING_TRANSACTIONS TO USERNAME
Where USERNAME is the user named in the XA open String. Specifying the
username as PUBLIC grants access to all users.
97
Websphere MQ – Queue
Manager Operations
03 Mar
Rate This
Create new Queue manager

crtmqm QM_NAME
Display all Queue manages
dspmq
starting Queue Manager
srtmqm QM_NAME
Stopping Queue Manager
endmqm QM_NAME
Connect to Queue Manager
runmqsc QM_NAME
Delete Queue manager
dltmqm Queue_Manager
97
Websphere MQ – Local
Queue Operations
New Local Queue

================
DEFINE QLOCAL(‘LQ_NAME’) +
DESCR (‘description’) +
DEFPSIST(NO) +
TRIGTYPE (FIRST) +
MAXDEPTH(200000) +
MSGDLVSQ(PRIORITY) +
USAGE(NORMAL) +
QDEPTHHI (80) +
QDEPTHLO (20) +
REPLACE
DEFPSIST(NO) -> Persistant YES/NO

TRIGTYPE (FIRST) -> Trigger type
MAXDEPTH(20000) -> Max depth
MSGDLVSQ(PRIORITY) -> Message delivery meth
USAGE(NORMAL) -> Queue usage (NORMAL/XMITQ)
QDEPTHHI (80) -> High Queue depth
QDEPTHLO (20) -> Low queue depth
REPLACE -> Replace if existing
Change the Queue properties
============================
alter qlocal LQ_NAME [property]
Display Queue properties
========================
display qlocal LQ_NAME
97
Give permissions to Queue

==========================
setmqaut -m LQ_NAME -n QM_NAME -t queue -g group/user [+browse +get +dsp
+put]
Display existing permissions
=============================
dspmqaut -m LQ_NAME -n QM_NAME -t queue -g group/user
97
Websphere MQ – Transmit
Queue Operations
New Transmit Queue

==================
DEFINE QLOCAL(‘XQ_NAME’) +
DESCR (‘Description’) +
DEFPSIST(NO) +
TRIGTYPE (FIRST) +
MAXDEPTH(200000) +
USAGE(XMITQ) +
QDEPTHHI (80) +
QDEPTHLO (20) +
REPLACEDEFPSIST(NO) -> Persistant YES/NO
TRIGTYPE (FIRST) -> Trigger type (if present)
USAGE(XMITQ) -> Queue usage (XMITQ)
QDEPTHHI (80) -> High Queue depth
QDEPTHLO (20) -> Low queue depth
============================
alter qlocal XQ_NAME [property]
========================
display qlocal LQ_NAME
==========================
97
setmqaut -m XQ_NAME -n QM_NAME -t queue -g group/user [+browse +get +dsp

+put]
=============================
97
Websphere MQ – Remote
Queue Operations
New Remore Queue

=================
DEFINE QREMOTE (‘RQ_NAME’) +
DESCR(‘Description’) +
PUT(ENABLED) +
EFPSIST(NO) +
MAXDEPTH(200000) +
XMITQ(‘XQ_NAME’) +
TRIGTYPE (FIRST) +
RNAME(‘RLQ_NAME’) +
RQMNAME(‘RQM_NAME’) +
QDEPTHHI (80) +
QDEPTHLO (20) +
REPLACEDEFPSIST(NO) -> Persistant YES/NO
TRIGTYPE (FIRST) -> Trigger type (if present)
PUT -> Put (enable/disable)
XMITQ -> Transmit Queue name
RNAME -> Remore local queue name
RQNAME -> Remote Queue Manager name
QDEPTHHI -> High Queue depth
QDEPTHLO -> Low Queue Depth
============================
alter qremote RQ_NAME [property]
97

========================
display qremote RQ_NAME
==========================
setmqaut -m RQ_NAME -n QM_NAME -t queue -g group/user [+browse +get +dsp
+put]
=============================
97
Websphere MQ – Sender
Channel Operations
New Sender Channel

=============
DEFINE CHANNEL (‘CHANNEL_NAE’) CHLTYPE (SDR) +
TRPTYPE(TCP) +
CONNAME (HOSTNAME(PORT)) +
DESCR (‘Description’) +
XMITQ (XQ_NAME)
Starting Channel
================
start channel (CHANNEL_NAME)
Stopping Channek
================
stop channel (CHANNEL_NAME)
Status of channel
=================
display chs (CHANNEL_NAME)
Display channel properties
==========================
display channel (CHANNEL_NAME)
Channel in Retrying state
=========================
Stop channel
Reset/resolve channel
Start the channel
Starting newly created channel
==============================
1. ping the remote machine (icmp)
97
2. MQ ping the remote side

echo “PING CHANNEL(channel_name)” | runmqsc <qmgr_name>
3. start the channel
4. if channel goes to re-try, then stop, and reset the seq number, and then start
the channel
Websphere MQ – Listener Operations
New Listner
===========
def listener(LISTENER_NAME) trptype(tcp) port(PORT_NUMBER)
Start listener
===============
start listener (LISTENER_NAME)
Stop Listener
==============
stop listener (LISTENER_NAME)
Listener Status
===============
display lsstatus (LISTENER_NAME)
Websphere MQ – Receiver
Channel Operations
New Receiver Channel

===================
DEFINE CHANNEL(CHANNEL_NAME) CHLTYPE(RCVR) REPLACE
Starting Channel
================
start channel (CHANNEL_NAME)
97
Stopping Channek
================
stop channel (CHANNEL_NAME)
Status of channel
=================
display chs (CHANNEL_NAME)
Display channel properties
==========================
display channel (CHANNEL_NAME)
97
JMS (java messag service)
Message-Oriented-Middleware provide a common reliable way for programs to

create, send, receive and read messages in any distributed Enterprise System.
MOM ensures fast, reliable asynchronous electronic communication, guaranteed
message delivery, receipt notification and transaction control.
The Java Message Service (JMS) provides a standard Java-based interface to the
message services of a MOM of some other provider.
Messaging systems are classified into different models that determine which client
receives a message. The most common messaging models are:
Publish-Subscribe Messaging
Point-To-Point Messaging
Request-Reply Messaging
Not all MOM providers support all these models.

Publish-Subscribe Messaging
When multiple applications need to receive the same messages, Publish-Subscribe
Messaging is used. The central concept in a Publish-Subscribe messaging system is
the Topic. Multiple Publishers may send messages to a Topic, and all Subscribers to
that Topic receive all the messages sent to that Topic. This model, as shown in
Figure 1, is extremely useful when a group of applications want to notify each other
of a particular occurrence.
The point to note in Publish-Subscribe Messaging is that, there may be multiple
Senders and multiple Receivers.
Point-To-Point Messaging
When one process needs to send a message to another process, Point-To-Point
Messaging can be used. However, this may or may not be a one-way relationship.
The client to a Messaging system may only send messages, only receive messages,
or send and receive messages. At the same time, another client can also send
and/or receive messages. In the simplest case, one client is the Sender of the
message and the other client is the Receiver of the message.
97
There are two basic types of Point-to-Point Messaging systems. The first one
involves a client that directly sends a message to another client. The second and
more common implementation is based on the concept of a Message Queue. Such
a system is shown in Figure 2.
The point to note in Point-to-Point messaging is that, even though there may be
multiple Senders of messages, there is only a single Receiver for the messages.
Request-Reply Messaging
When an application sends a message and expects to receive a message in return,
Request-Reply Messaging can be used. This is the standard synchronous object-
messaging format. This messaging model is often defined as a subset of one of the
other two models. JMS does not explicitly support Request-Reply Messaging,
though it allows it in the context of the other methods.
The Java Message Service (JMS) Architecture
Figure 3 shows the JMS Architecture. As shown in Figure 3, JMS Service Providers
implement the JMS interface on top of their messaging services. JMS defines
Queues and Topics, but it does not require the provider to implement both. JMS
thus tries to maximize portability of the solution with as many features as possible.
The primary features of JMS are as follows:

 Connection Factories are used in JMS to create connections to a specific JMS
provider.
 In JMS, both Publish-Subscribe Messaging and Point-To-Point are
implemented and defined by separate interfaces so that a Provider does not
have to support both.
 JMS defines the concept of a Topic or a Queue as the target for a Message.
Topics are used for Publish-Subscribe Messaging. Queues are used for Point-
to-Point Messaging.
 The Providers’ code is defined by interfaces in JMS, freeing the
implementation from the limitations of subclassing.
 JMS provides support for distributed transactions.
97
The Java Message Service API

Both Publish-Subscribe Messaging and Point-To-Point Messaging inherit from
a common set of abstract interfaces asshown in the below table
JMS Parent Publish-Subscribe Point-To-Point Domain

Domain
Destination Topic Queue
ConnectionFactory TopicConnectionFactory QueueConnectionFactory
Connection TopicConnection QueueConnection
Session TopicSession QueueSession
MessageProducer TopicPublisher QueueSender
MessageConsumer TopicSubscriber QueueReceiver,

QueueBrowser
Table 1: Relationship of Point-To-Point and Publish-Subscribe

interfaces
Websphere MQ v6 Tutorial
97
MQ Series/MQ: – It is an IBM web sphere product which is evolved in 1990’s. MQ

series does transportation from one point to other. It is an EAI tool (Middleware).
Now it is renamed as WebSphere MQ.
VERSIONS:-5.0, 5.1, 5.3, 6.0, 7.0(new version).
Currently widely used version is 6.2
Note: – MQ series supports more than 35+ operating systems. It is platform
independent. For every OS we have different MQ series software’s.
MQ series deals with two things, they are OBJECTS, SERVICES.
In OBJECTS we have
• QUEUES
• CHANNELS
• PROCESS
• AUTHENTICATION
• QUERY MANAGER.
In SERVICES we have LISTENERS.
Objects: – objects are used to handle the transactions with the help of services.
QUEUE MANAGER maintains all the objects and services.
QUEUE: it is a database structure which stores messages until the application or
program receives messages.
TYPES OF QUEUES:-
• Local Queue
• Alias Queue
• Model Queue
• Remote Queue
• Repository Queue
Local Queue:-
A queue is local if it is owned by the queue manager to which the application
program is connected. It is used to store messages for programs that use the same
queue manager. For Example, program A and program B each has a queue for
incoming messages and another queue for outgoing messages. Since the queue
manager serves both programs, all four queues are local.
97
Note: Both programs do not have to run in the same workstation. Client
workstations usually use a queue manager in a server machine.
Remote Queue:-
The queue which holds the address of the remote queue manager where the
message has to be sent or delivered.
It is a logical queue where we cannot store the messages and get the messages.
Note: To send the messages we use only Remote Queue, none other than this
Message Flow from remote Queue
“Remote queue-> Transmission queue-> Channel->Network receiver channel->
Local queue (finally the message will reach here) “
CHANNEL Channel (123.456)channel name.
CHLTYPE (SDR) sender channel
TRPTYPE (TCP) Transport type using TCP protocol
CONNAME (127.0.0.1)(1414)?the channel will connect to the IP address specified in
the conn name and looks for the queue manager which is having listener, port
number(1414) and connects to the queue manager.
XMITQ (TQ)?the channel will receive the messages from transmission queue
manager.
ALIAS QUEUE:-
Alias queues are not real queues but they are definitions. They are used to assign
different names to the same physical queue.
Advantages of alias queue allow multiple programs to work with the same queue
but with different attributes or properties.
Example:
Alias for LQ with different parameters
DEFINE QALIAS (PQ) TARGQ (LQ) GET (DISABLED) PUT (ENABLED)
DEFINE QALIAS (PQ) TARGQ (LQ) PUT (ENABLED) GET (DISABLED)
DEFINE QLOCAL (LQ)
MODEL QUEUE:-
A model queue is not a real queue. It is a collection of attributes that are used
when a dynamic queue is created.
Repository Queue:-
Repository queues have existed since Version 5.1 and Version 2.1 for OS/390. They
97
are used in conjunction with clustering and hold either a full or a partial repository
of queue managers and queue manager objects in a cluster (or group) of queue
managers.
TYPES OF LOCAL QUEUE:-
• Dead letter Queue
• Transmission Queue
• Initiation Queue
• Local Queue.
DEAD-LETTER QUEUE: – the enrooted (or) undelivered messages will be landed in
to the dead letter queue.
We have one control command called runmqdlq.It is a control command which is
used to route the messages through .rul table.
This is called dead letter handler. It is important that we need a dead letter queue
defined for every queue manager.
Note:- For one Queue manager we can’t have two dead letter queues.
We have system defined objects called SYSTEM.DEAD.LETTER.QUEUE. Or we can
use our own dead letter queue. The messages those are landed in the dead letter
header (DLH). By seeing the dead letter header, we can find the reason and the
destination.
RULE TABLE:-
Syntax:- DESTQ(DLQ) DESTQM(222) REASON(*) WAIT(NO) FWDQ(LQ)
FWDQM(222) HEADER(NO)
Runmqdlq:-rule table path
TRANSMISION QUEUE:-TQ will receive messages from Remote queue and hits or
sends the messages to the channel.
CHANNELS:-
It is a Networked program to transmit or pas the messages over the network.
Channel will receive the messages from XMITQ which is defined in the definition of
the channel. Transmission queue is also a local queue.
TYPES OF CHANNELS:-
• Message channels.
• MQI Channels.
97
MESSAGE CHANNELS:-Message channels are one way piping channels. They are
used for sending or receiving the messages. Message channels are unidirectional.
TYPES OF MESSAGE CHANNELS:-
• Sender Channel(SDR)
• Receiver Channel(RCVR)
• Server Channel(SVR)
• Requester Channel(RQSTR)
• Cluster Sender Channel(CLUSSDR)
• Cluster Receiver Channel(CLUSRCVR)
MQI CHANNELS:-These channels are two way piping channels which can send and
receive the messages in both ways.
TYPES:-
• Server Connection Channel (SVRCONN)
• Client Connection Channel (CLNTCONN)
COMBINATION OF CHANNELS:-
• Sender and Receiver
• Server and Requester
• Cluster sender and Cluster Receiver
• Server Receiver
• Sender Requester
LISTENER:-
• It is a service of MQ series
• Every Queue Manager will have a listener defined with a unique port number.
• (Default port number is:-1414)
• Listener acts as a mediator between external application or queue managers
connecting to the queue manager.
• To contact the queue manager we should approach through Listener.
MQI COMMANDS:-
MQI Commands are of three types.
• CONTROL COMMANDS
• SCRIPT COMMANDS
• PCF (programmable command format) COMMANDS.
97
CONTROL COMMANDS : (case sensitive)

• Dspmqver :-to display MQ series version
• Dspmq :-to view all queue managers of MQ series.
• Crtmqm :-to create a queue manager
• Strmqm :-to start queue manager
• Runmqsc :-to enter in to particular queue manager
• Endmqm :-to end a queue manager
• Dltmqm :-to delete a queue manager
• Dspmqcsv :-to display command server
• Endmqcsv :-to end command server
• Strmqcsv :-to start command server
• Runmqlsr :-to run listener service
• Endmqlsr :-to end listener service
• Runmqchl :-to run a channel out of queue manager
• Runmqdlq :-to execute dead letter handle with the help of rule table
• Setmqaut :-to set authorizations for particular objects like
queuemanager,queue’s channels, listeners to user or group
• Dspmqaut :-to display authorization for particular user
• Dmpmqaut :-to dump authorization for particular user
• Runmqchi :-to run a channel initiator for particular queue manager
• Runmqtrm :-to run trigger monitor on initiation queue for particular queue
manager
• Rcdmqimg :-to take objects (or) record image of a particular queue manager
objects
• Rcrmqobj :-to recreate the mq objects which are already recorded
• Replace :-s
SCRIPT COMMANDS:-
After entering in to queue manager we can find script commands. Script commands
are same for every queue manager. (These Commands should be used in CAPITAL
LETTERS)
• DEFINE :-To define/create MQ manager objects like queue, Channels, process,
and listener.
• ALTER :-to update or modify the existing objects
97
• DISPLAY :-to view all the properties of a particular object or to Display all objects
• DELETE :-to delete created objects
• CLEAR :-to clear the message from the queue
• END :-to come out of the queue manager
• PING :-to check whether other side channel / queue manager is ready to accept
our request.
• START :- to start the particular channel or listener
• STOP :-to stop particular channel or listener
• REFRESH :-used to refresh the security every time after giving or executing, set
mgr or command for queue manager or object
• RESET :-used to reset channel,cluster,queue manager
• RESOLVE :-to resolve the channel which is in indoubt state
• SUSPEND :-to suspend a queue manager from a cluster environment
• RESUME :-to remove a queue manager from a cluster environment
CHANNEL STATES: – Channel states are of 5 types
• Running
• Inactive
• Retrying
• Stopped
• Paused(receiver channel)
1. RUNNING: – before going to Running state the status will be initialization and
binding Initialization:-channel will initiate the listener Binding:-sender channel
binds with receiver, after that it Goes to running state
2. INACTIVE:-we have one attribute called disconnect interval (DISCINT) with 6000
milli seconds (default) and it can be changed as of our convenience. If the channel
is idle for a particular period defined in disconnect interval, the channel will go to
inactive state.
3. RETRYING:-the channel goes to retrying state if the other side queue manager
will not be available, network issue, may be listener not running, may be receiver
channel is in pause state, and may be the receiver channel transportation type is
different…. Etc.
4. PAUSED STATE:- this state is applicable for receiver (RCVR) channel. Paused
state occurs when the receiving queue is full.
97
Note:-
1. If we do any changes to the channels, listeners, queue manager, to effect the
changes we need to stop and then start them.
2. Before starting a channel listener should be in active / running, we can check by
pinging the channel.
3. Ping is used to check whether the receiver is in active state or not.
Syntax: – PING CHANNEL (CHANNEL NAME)
MULTI-HOPPING : ( gate way)
Passing the messages between more than one intermediate queue managers is
called Multi-Hopping.
Note:-
For every queue, except remote queue we have two properties.
1. open input count ( Iproess )
2. open output count ( Oprocss )
3. the application which is connected and putting the messages is called “ O
process “
4. The application which is processing(getting) the messages is calles “ I procss “
PROCEDURE TO CREATE MULTI-HOPPING:-
1. Create a queue manager QM1, QM2, QM3.
2. Start the queue managers QM1, Create a remote queue with attributes local
queue name (Remote Queue Manager) i.e Rname QM3 in RQMname and the
transmission queue called XMITQ (TQ).
3. Create a transmission queue called (TQ)
4. Create a sender channel from (QM1.QM2)
5. In Qm2 create, Create a receiver channel (QM1.QM2)
6. Create a transmission queue with name target queue manager name called
QM3.
7. Create a sender channel from (QM2.QM3) with transmission queue called XMITQ
(QM3)
8. In QM3 create a local queue called (LQ) which is defined in remote queue of QM1
Rqueue(QM1)
9. Create a receiver channel (QM2.QM3)
We should have two listeners in QM2 and QM3.
97
GENERAL ERRORS OCCURING IN REALTIME SCENARIO:-

1. Mqrc 2059 :- Qmanager not available
2. mqrc 2058 :- Qmanager name error
3. mqrc 2085 :-unknown object name
4. mqrc 2035 :- Not authorized
5. mqrc 2033 :-No message available.
(mqrc—mq reason code)
TRIGGERING:-
1. This is an automated event driven by MQ series
2. Triggering is an event which occurs when specific conditions are met on a
queue
3. Triggering are of two types
1. CHANNEL TRIGGERING
2. APPLICATION TRIGGERING
CHANNEL TRIGGERING: – channel triggering is an event which fires the channel
when ever a certain conditions are met on transmission queue.
Disconnect Interval of a Channel :-It is an attribute or property of the
channel(DISCINT).if the channel is idle for particular interval of time the channel
will go to inactive state.(default time is 6000 milli seconds)
TRIGGER CONDITIONS:-
• Trigger ON
• Trigger type(first(t.type),every, depth)
• Trigger data(channel name which is to be fired)
• Initiation queue(SYSTEM.CHANNEL.INITQ)
In command prompt:-
DEFINE QLOCAL (TQ) USAGE (XMITQ) TRIGGERTYPE (FIRST) TRIGDATA (111.222)
INITQ (SYSTEM.CHANNEL.INITQ)
To make changes use alter command
ALTER QLOCAL (TQ) TRIGGER TRIGTYPE (FIRST) TRIGDATA (111.222) INITQ
(SYSTEM.CHANNEL.INITQ)
If we want to remove the trigger condition put NO before trigger condition.
CHANNEL TRIGGERING PROCESS:-
After giving specific conditions to a transmission queue, whenever the messages
97
comes to the transmission queue, the queue manager will look at the queue, if it is
triggered the queue manager will fire a trigger message in to initiation
queue(SYSTEM.CHANNEL.INITQ) with the information called trigger type, trigger
data, the channel which is to be fired.
At the initiation queue (SYSTEM.CHANNEL.INITQ) channel initiator will be watching
(monitoring) the initiation queue.
When ever the trigger message comes to initiation queue, the channel initiator will
read the information and initiates the sender MCA (message channel agent).the
sender message channel agent will start the channel (which is mentioned in the
trigger data).
Note:-MCA (message channel agent) is a program which is defined automatically
whenever a queue manager is created.
We have two types of MCA
• SENDER MCA(SDRMCA)
• RECEIVER MCA(RCVRMCA)
CHANNEL INITIATOR:-
It is a process running on a queue manager when queue manager is in running
state. For every queue manager there will only one channel initiator
Note:- 1.In MQseries 5.3 we have to run this channel initiator as a separate
process for every queue manager.
2.If we use “&” any process will run at background. this applicable for all.
Syntax:- runmqchi –m Qmanagername –q initq.
Example :- runmqchi –m QM1 –q SYSTEM.CHANNEL.INITQ
To run channel initiator for queue manager QM1.
In solaris / unix /linux /AIX we run the channel initiator as follows.
Runmqchi –m QM1 –q SYSTEM.CHANNEL.INITQ &
APPLICATION TRIGGERING:-when ever specific conditions met on a local queue
application triggering works.
TRIGGER CONDITION:-
• Trigger ON
• Trigger type(first, every(t.type),depth)
• Initiation queue(our own defined local queue)
• Process
97
DEFINE QLOCAL (LQ) TRIGGER TRIGTYPE (EVERY) INITQ (IQ) PROCESS

(NOTEPAD).
DEFINE PROCESS (NOTEPAD) APPLICID (NOTEPAD.EXE) APPLTYPE (WINDOWS)
Runmqtrm –m QM1 –q IQ
BACKGROUND PROCESS:-
1. When ever the message comes to triggered local queue, queue manager will fire
trigger message with information called trigger type and the process definition
(application which is to be triggered) in to the initiation queue (IQ) (our own
queue).
2. At the initiation queue a long running time program called trigger monitor will be
watching (monitoring) the initiation queue.
3. Whenever the trigger message occurs in the initiation the trigger monitor will
pick the information and starts the application which is defined in the process.
DEFINE PROCESS (NOTEPAD) APPLICID (NOTEPAD.EXE) APPLYTYPE (WINDOWS
NT)
COMMAND SERVER:-it is a background process for queue manager when the queue
manager starts command server will be running (default)
Note: – we have one attribute (SCMDSERV) and we have two options in that
1. QMGR
2. MANUAL
By default the queue manager command server will be under control of (QMGR)
If we change the SCMDSERV attribute to manual then we need to start command
server manually.
CONTROL COMMANDS FOR COMMAND SERVER:-
• Dspmqcsv
• Strmqcsv
• Endmqcsv
1. Dspmqcsv: – to display the command server for particular queue manager
Syntax:-dspmqcsv qmgrname
E.g.:- Dspmqcsv QM1.qmgr
2. Strmqcsv:-to start the command server for a particular queue manager
Syntax:-strmqcsv –a qmgrname
Eg:-strmqcsv Qm1
97
3. Endmqcsv:-to end the command server for a particular queue manager

Syntax:-endmqcsv –c –I qmgrname
Eg :- endmqcsv –I QM1(queue manager)
-c stops the command in a controlled manner.
-I stop the command immediately.
USE OF COMMAND SERVER:- The command server will allow commands to execute
on a queue manager using
(SYSTEM.ADMIN.COMMAND QUEUE)
When the command server is stopped the commands, the commands will be stored
in the command queue called
(SYSTEM.ADMIN.COMMAND QUEUE)
After command server comes up the commands would be executed those are in the
command queue.
AUTHORIZATIONS:- MQseries provides authorizations(permissions) for the users in
two levels
1. Qmanager level
2. Object level
MQMgroup:- This group is automatically created by MQseries after installation. It
also creates one user (MUSR_MQADMIN)
The users should belong to MQM group so that they can have all the permissions to
administer MQ series.
COMMANDS TO SET AUTHORIZATIONS:-
Setmqaut:- this command is used to set the authorizations.
Syntax:- setmqaut[-m qmgrname] [-n objname] –t objtype [-p principal /-g group]
[-s service component ]
Dspmqaut :-to display the authorizations which are set to the queue manager.
Syntax:-dspmqaut[-M qmgrname] [-n objname ] –t objtype [-p principal/ -g
group ] [-s service component]
Dspmqaut –m QM1 –t qmgr –p XX(new user)
The entity XX have the following authorizations for object QM1
• Inq
• Connect
• Altusr
97
• Crt
• Dlt
• Chg
• Dsp
• Setid
• Setall
Object level :-
Syntax:-
Setmqaut –m QM1 –n LQ –t queue –pXX +put
Dspmqaut –m QM1 –n LQ –t queue –p XX
The setmqaut command completed successfully
Semqaut –m QM1 –n(20.30) –t channel –pXX +allmqi
Runmqsc QM1
Starting MQSC for queue manager 1
• REFRESH CLUSTER
• REFRESH SECURITY(generally we refresh security)
Result: web sphere security cache refreshed
TROUBLE SHOOTING METHODS:
LOGS:- MQseries have two types of logs
1. TRANSMISSION LOGS
2. ERROR LOGS
TRANSMISSION LOGS:-the transactions like messages inbound(incoming) and
outbound(outgoing) objects creation, permissions etc. are going to be written to
the transaction logs for every queue manager
Default path for log files in Windows:-
[ c:\programfiles\IBM\websphere MQ\log\QMGR(QM1)\active directory\log files ]
Default path for log files in LINUX, UNIX, SOLARIS, AIX (other than windows):-
[ $/var/MQM/log/Qm1/active/logfiles ]
Transmission logs are of two types:-
1. CIRCULAR LOGS
2. LINEAR LOGS
LINEAR LOGS: – In linear logs we can recover objects which are damaged and we
can take backup and clear the transactions.
97
By using linear logs we can restart, recover and Image backup. In this we need
some administrative tasks to monitor the logs and to clear the logs.
CHECKPOINT:-It is nothing but creation of objects, which are stored as a
transaction and are stored at Checkpoint (objects are LQ, TQ, and Channel…etc)
Creation of queue manager in linear logging:-
Syntax:-
Crtmqm –LL –Lf 2048 –Lp 10 –LS 1 QM2
• Lq to create a queue manager in linear logging
• Lf to specify the log file size
• Lp to specify the number of log primaries
• Ls to specify the number of secondary logs
Note:-1. In transaction logs we have log primary and log secondary.
2. We can view log primary files but we cannot view log secondary Files.
3. By default queue manager will take –Lp as 3 and –Ls as 2.
4. We can define log primary files maximum up to 250 files and log Secondary files
maximum up to 254 files.
Log primary files maximum—250
Log secondary files maximum—254
Creation of image backup by using linear logs:
Syntax:- rcdmqimg
Rcdmqimg[-z] [-L] [-m Qmgrname ] –t objtype[generic object name]
Rcdmqimg –m Qm1 –t queue LQ
To recover or recreate:-
Rcrmqobj? this command is used to recover the objects.
Syntax:-rcrmqobj[-z] [-m Qmgrname] –t objtype[generic objname]
Eg:- rcrmqobj –m Qm1 –t q LQ
ERROR LOGS:-
The operations going on(running) on MQ series will be written to errorlogs.
We have two types of error logs,
1.MQseries level
2.Queue manager level errors
Queue manager level errors:-the operations and errors are written to the queue
manager error folder.
97
Default path for windows :

[ c:\program files\IBM\websphere MQ\Qmgrs(QM1)\errors\logfiles ]
Path for UNIX, LINUX, and SOLARIS:-
[$/var/mqm/qmgrs/Qm1/errors/logfiles ]
MQ series level errors :- the operations or errors which are occurring on MQ series
are considered as MQ series level errors.
Default path for windows :-
[ C:]program files\IBM\Websphere mq\errors\log files ]
Path for UNIX, LINUX, SOLARIS :-
[ $/var/mqm/errors/logfiles ]
MQ series Client :- The person or user or application trying to connect access
MQseries server or queue manager they need MQ series client installed at their side
MQI channels :-The MQseries client will interact with MQ series server using server
connection (SVRCONN) or Client connection channel(CLNTCONN)
In MQ client sid ewe have three environmental variables
1. MQSERVER ( MQI channels )
2. MQCHLTAB ( MQI channel tables )
3. MQCHLIB (MQI channel library )
Creation of server connection channel :-
DEFINE CHANNEL(SVR) CHLTYPE(SVRCONN) TRPTYPE(TCP) DESCR(‘SERVER
CONNECTION CHANNEL(not mandatory))
Syntax:-
Set mqserver=server connection channel name/trptype/IP address(port)
Eg :- set Mq server=SVR\tcp\127.0.0.1(1000)
Set MQSERVER
Result:- svr\tcp\127.0.0.1(1000)
PERSISTENT AND NON-PERSISTENT MESSAGES :-
MQSeries differentiates
Between persistent and non-persistent messages. Delivery of persistent messages
is assured; they Are written to logs to survive system failures. In an AS/400 these
logs are Journal Receivers.
Non-persistent messages cannot be recovered after a system restart.
97
How a Client Sends a Request:-

The client starts a program that puts a message on a queue. For this function five
MQSeries API calls are executed
• MQCONN to connect to the queue manager in the server
• MQOPEN to open the message queue QS1 for output
• MQPUT to put a message in the queue
• MQCLOSE to close the queue QS1
• MQDISC to disconnect from the queue manager
How the Client Receives a Reply :-
The client program knows the name of its input queue, here QA1 or QB1. The
application can use two modes of communication: • Conversational
If the application uses this mode of communication with the server program, it
waits for the message to arrive before it continues processing. This means, the
reply queue is open and an MQGET with wait option has been issued.
The client application must be able to deal with two possibilities:
• The message arrives in time.
• The timer expires and no message is there.
Websphere MQ Clusters
97
Qns:What is Cluster?
Ans: A cluster is a group of queue managers set up in such a way that the queue
managers can communicate directly with one another over a single network,
without the need for transmission queue, channel, and remote queue definitions.
Qns:What are the Advantages of clustering?
Reduced system administration
Increased high availability
Improved resource utilization
Workload sharing
Qns:What is the algorithm that is followed by MQ in clustering?
Ans: WebSphere MQ uses a workload management algorithm that uses a round-
robin routine to select an available queue manager to route a message to.
Qns:What is Cluster queue manager?
Ans:A cluster Queue manager is a queue manager that is a member of a cluster. A
queue manager can be a member of more than one cluster What happens when we
give a Refresh Cluster mqsc command ?
This command issued on a queue manager, the queue manager discard all locally
held information about a cluster except the FULL repository information. This
enables you to perform a “cold-start” on the cluster.
Qns:How to remove a Qmgr from Cluster?

*Suspend queue manager
*Remove the CLUSRCVR channel definition from the cluster by setting the
CLUSTER attribute to empty
*Stop the CLUSRCVR channel
*Delete the CLUSSDR channel definition
Qns:What is the use of clustering?
Ans. Due to the use of clustering
1. The Administrator tasks can be reduced.
2. We can achieve the Workload balance.
Qns:How many no Full Repository Queue Managers are required for creating a
cluster. What is the difference between full and partial repositories?
97
Ans: In each cluster you must select at least one, preferably two, or possibly more
of the queue managers to hold full repositories. A cluster can work quite
adequately with only one full repository but using two improves availability. Every
cluster has at least one (preferably two) queue managers holding full repositories
of information about the queue managers, queues, and channels in a cluster. These
repositories also contain requests from the other queue managers in the cluster for
updates to the information. The other queue managers each hold a partial
repository, containing information about the subset of queues and queue managers
with which they need to communicate.
Qns:Where does the information about the messages of a QueueManager are
stored when they are in cluster?
Ans: Each queue manager stores its repository information in messages on a queue
called SYSTEM.CLUSTER.REPOSITORY.QUEUE.
The queue managers exchange repository information in messages on a queue
called SYSTEM.CLUSTER.COMMAND.QUEUE.
Qns:What happens when full cluster repository Qmgr goes down?
If your queue manager is a full repository queue manager, alter the queue
manager definition to set the REPOS and REPOSNL attributes to blank. This sends a
notification to other queue managers advising them that they must stop sending
cluster information to this queue manager.
Qns:When will we use RESET CLUSTER command?
To forcibly remove a queue manager from the cluster and resets the cluster
Qns:How does a partial repository QM share information with other clusters when
the full repos QM is down?
The cluster continues to work with information from the other full repository. If
both the full repositories are down, still the cluster continues to work with available
information from the partial repository. A repository handles the request whenever
possible but if the chosen repository is not available another repos used. When the
first repository becomes available again, it collects the latest new and changed
information from the others so that the queue managers are kept in synch. The
repository queue manager send messages to each other to be sure that they are
both kept up to date with new information about the cluster
97
Qns:Algorithm for workload balancing?

Round Robin
Qns:How do I set up a cluster and add a new QM to a cluster?
Determine to which full repository the qmgr has to point to get cluster information,
Define the CLUSRCVR channel, Define a CLUSSDR channel on queue manager
Qns:Components of a cluster?
The components of a cluster are
a group of queue managers.(more than one)
Cluster receiver channel – to communicate with any cluster queue manager
Cluster sender channel- to communicate with any cluster queue manager
The cluster sender channel points to a full repository queue manager
Cluster transmission queue
One transmission queue to transmit message to any cluster queue
Cluster queue
A queue that is available to all cluster queue managers
Qns:How many Transmission Queues are present in a Queue manager present in a
Cluster?
ONE
Qns:When defining a Cluster sender channel, for example if there is more than one
instance in the cluster what will happen?
Qns:How many cluster channel definitions are required for a QM in a cluster?
TWO cluster channel definitions are required: Cluster Sender channel and Cluster
Receiver channel
Qns:What is Cluster queue how is it defined?
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 cluster queue manager makes a local queue definition for the queue, specifying
the name of the cluster where the queue is to be found. This definition has the
effect of showing the other queue managers in the cluster that the queue is there.
The other queue managers in the cluster can put messages to a cluster queue
without needing a corresponding remote-queue definition.
Qns:What makes clustering work?
Defining a cluster-receiver channel has the effect of introducing a queue manager
97
to one of the full repository queue managers. The full repository queue manager
updates the information in its full repository accordingly. Then it automatically
creates a cluster-sender channel back to the queue manager, and sends the queue
manager information about the cluster. Thus a queue manager learns about a
cluster and a cluster learns about a queue manager.
Qns:Types of aliases and remote-queue definitions with clusters?
Queue-manager aliases, reply-to queue aliases, and queue aliases
Qns:What is a gateway queue manager and advantages of using in a cluster?
This enables workload balancing for messages coming from outside the cluster.
Qns:How will you keep a cluster secure?
Stopping the unauthorized Queue manager sending message to your Queue
manager
Stopping unauthorized Queue manager putting messages on your Queues
Stopping Your Queue manager putting messages to remote Queues
Preventing Queue manager from joining a cluster: Define a channel security exit
program
Forcing unwanted queue manager to leave a cluster
Qns:What is Repository queue manager? What are Full and partial repository?
A repository queue manager is a cluster queue manager that holds a full repository
A queue manager that hosts a complete set of information about every queue
manager in the cluster is referred to as having a full repository for the cluster. The
other queue managers in the cluster inquire about the information in the full
repositories and build up their own subsets of this information in partial
repositories. A partial repository contains information about only those queue
managers with which the queue manager needs to exchange messages. The queue
managers request updates to the information they need, so that if it changes, the
full repository queue manager will send them the new information
Qns:Where does each queue manager store its repository information?
SYSTEM.CLUSTER.REPOSITORY.QUEUE
Qns:Where do the queue managers exchange repository information?
SYSTEM.CLUSTER.COMMAND.QUEUE
Qns:What happens when a queue manager fails? What happens if I put-disable a
cluster queue? How long do the queue manager repositories retain information?
97
It must be 90 days but the Qm sends information to all the QM’s in the cluster to
update its information around 30 days
Qns:Adding a new Queue manager to a cluster?
Determine the Full repository to which the QM should refer
Define the CLUSRCVR channel
Define the CLUSSDR channel on the QM
Review the application for message affinities
Qns:Removing a cluster queue from a Queue manager?
Indicate the Queue is no longer available – remove the CLUSTER name from the
local queue definition (ALTER QLOCAL(localqueue) CLUSTER(‘’))
Disable the Queue – ALTER QLOCAL(localqueue) PUT(DISABLE)
Monitor the Queue until it is EMPTY
Monitor the channel to ensure that there is no in-doubt messages
Delete the Queue
Qns:Removing a Queue Manager form a Cluster?
Suspend the QM (SUSPEND QMGR CLUSTER(clusname))
Remove the CLUSRCVR channel definition
Stop the CLUSRCVR channel
Delete the CLUSSDR channel definition
Qns:Converting an existing network to cluster?
Alter two QM to make it a FULL repository MQ
Define CLUSRCVR channel on each Queue manager
Define CLUSSDR channel on each Queue Manager
Delete all remote Queue definitions for the existing network
Qns:What is Workload balancing?
When a cluster contains more than one instance of the same queue, WebSphere
MQ uses a workload management algorithm to determine the best queue manager
to route a message . The algorithm uses a round-robin approach to finalize its
choice between the suitable queue managers.
Qns:Removing a Cluster network?
Remove the cluster queues from the cluster
Stop all applications that have access to cluster Queue
Remove the repository attribute from the full repository Queue manager
97
Remove Cluster channels on each Queue manager

Issue REFRESH cluster command on each Queue manager.
Qns:What is key repository?
IS used to describe the store for digital certificates and their associated private
keys.
Qns:What’s the queue where the full and partial repository is stored?
SYSTEM.CLUSTER.REPOSITORY.QUEUE
**Some important MQSC commands that work with cluster
DISPLAY CLUSQMGR SUSPEND CLUSQMGR
RESUME CLUSQMGR REFRESH CLUSTER
RESET CLUST
MQ Queue Manager Clusters

97
=> CLUSTERING
===========
Clustering is a way to logically group WebSphere MQ queue managers
- reduced system administration due to fewer channel, remote queue, and
transmission queue definitions
- increased availability and workload balancing.
=> Basic Cluster setup
===============
> Step-1
Determine which queue manager should hold full repositories
A full repository contains a complete set of information about every queue manager
and object in the cluster
You will need at least one, preferably two
> Step-2
Alter the queue manager definitions to add repository definitions
ALTER QMGR REPOS(cluster_name)
> Step-3
Define the CLUSRCVR channels
Every queue manager in the cluster needs a CLUSRCVR with a conname pointing to
itself.
DEFINE CHANNEL(channel_name) CHLTYPE(CLUSRCVR) TRTYPE(TCP)
CONNAME(‘my_ip_name_or_address(port)’) CLUSTER(cluster_name)
> Step-4
Define the CLUSSDR channels
Define one CLUSSDR to a full repository queue manager. The channel name must
match that of the CLUSRCVR on the full repository
DO NOT define a CLUSSDR to point to a partial repository.
DEFINE CHANNEL(channel_name) CHLTYPE(CLUSSDR) TRPTYP(TCP)
CONNAME(‘remote_ip_name_or_address(port)’) CLUSTER(cluster_name)
> Step-5
Define a cluster queue
DEFINE QLOCAL(qname) CLUSTER(cluster_name)
97
Other queue managers in the cluster can send message to it without making
remote-queue definitions for it.
Only the local queue manager can read messages from an instance of the cluster
queue
You can use a sample program to test putting messages to clustered queues
=> Cluster Commands
===============
DISPLAY QMGR REPOS REPOSNL QMID
AMQ8408: Display Queue Manager details.
QMNAME(QM1) QMID(QM1_2005-07-12_17.14.38) REPOS(QMCLUS)REPOSNL( )
QMID is an internally generated unique name that consists of the queue manager
name plus the time the queue manager was created
DISPLAY CLUSQMGR(*) ALL
Display cluster Queue managera details
dis chstatus(*) all
Display channel status details
DISPLAY QCLUSTER(*) ALL
It displays information about clustered queues only.
A cluster queue will not be displayed on a partial repository until an application has
opened it.
DISPLAY QUEUE(*) CLUSINFO
This command displays information about queues with TYPE(QCLUSTER)
=> Work load balancing
================
When a cluster contains more than one instance of the same queue, workload
balancing determines the best queue manager to route a message to
- At its simplest, workload management results in a round-robin effect
MQ V6 has additional parameters that can be used to influence the results of the
algorithm.
- Queues: CLWLPRTY, CLWLRANK, CLWLUSEQ
- Queue Managers: CLWLUSEQ, CLWLMRUC
- Channels: CLWLPRTY, CLWLRANK, CLWLWGHT, NETPRTY
For workload balancing to occur:
97
- open the queue with the MQOO_BIND_NOT_FIXED open option

- open with the default MQOO_BIND_AS_Q_DEF and with DEFBIND(NOTFIXED) set
in the queue definition
- Leave MQMD.ObjectQMgrName blank to allow the queue manager to chose the
queue instance
- To force the message to a specific instance of the clustered queue, specify that
queue manager’s name in ObjectQmgrName
=> Namelists in clusters
================
- A queue manager may be a member of more than one cluster. List those clusters
in a NAMELIST.
- You can alter a full repository QMGR to use REPOSNL(namelist) rather than
REPOS.
- For channels and queues, you can specify CLUSNL(namelist) rather than
specifying the CLUSTER parameter.
=> REFRESH CLUSTER
===============
- REFRESH CLUSTER removes and rebuilds locally held information about a cluster.
- REFRESH CLUSTER(clustername) REPOS(NO)
- REFRESH CLUSTER(clustername) REPOS(YES), also refreshes information about
full repository queue managers and may not be issued from a full repository.
- REFRESH CLUSTER(*)
=> RESET CLUSTER
=============
RESET CLUSTER is issued from a full repository queue manager. It forcibly removes
a queue manager or specific QMID from a cluster.
- RESET CLUSTER(clustername) QMNAME(qmname) ACTION(FORCEREMOVE)
QUEUES(NO)
- RESET CLUSTER(clustername) QMID(qmid) ACTION(FORCEREMOVE)
QUEUES(NO)
=> Troubleshooting
=============
- Is the repository manager still running?
97
Check the AMQERRxx.log or CHIN joblog.

- Are channels able to run in both directions?
Display CLUSQMGR and CHSTATUS information.
- Are the SYSTEM.CLUSTER.* queues enabled?
Issue DISPLAY QUEUE(SYSTEM.C*) ALL
- Are there messages on
SYSTEM.CLUSTER.COMMAND.QUEUE or
SYSTEM.CLUSTER.TRANSMIT.QUEUE?
- Are there duplicate QMIDs for a given QMGR?
Issue DISPLAY CLUSQMG(*) QMID.
- DISPLAY CLUSQMGR may show CLUSQMGR names starting with SYSTEM.TEMP.
The queue manager has not received all necessary information from the full
repository.
Logging in MQ
=> MQ log are also known as transaction logs.

97
=> MQ logs consists of two parts

- Data log file (named S0000000.LOG – S9999999.LOG)
- Control log file (named amqhlctl.lfh)
=>Transaction logs are created when you create the Queue Manager. When you
choose the default locations, the logs will goes to
- /var/mqm/logs/Queue_Manager in unix
-c:/program files/IBM/log/Queue_Manager in windows
=> These MQ logs/ Transaction logs holds the following information
- Transaction activity known as Unit Of Work
- Persistant messages
- Internan data about queue manager objects
- Persistant channel status
=> Type of logging
MQ provides 2 type of logging options 1. Circular (default) 2. Linear
Circular Logging
- Good performance
- Esay administration
Linear logging
- Media Recovery
- Ability to archive/backup
=> Configuring Logging
Logging configuration will have direct effect on the performance of MQ. Some of
the configuration parameters of logging can be changed after creating Queue
Manager but some can not be changed.
Primary Logs are the initial and minimum logs.
Secondary logs can be created when the primary logs become full.
Default minimum Max (unix) Max (Win)
Primary 3 2 510 254
Secondary 2 1 509 253
=> Maximum of primary/secondary logs have a constraint of 511 on unix and 255
on windows platforms. These are the active logs
=> Log file size is a multiple of 4KB log file page size. This can not be changed
after creating the Queue Manager.
97
=> Log file size details table

pages filesize Max
Default Win 256 1MB 256MB
Default unix 1024 4MB 2GB
Minimum Win 32 128KB 32MB
Minimum Win 64 256KB 128MB
Maximum 65535 256MB 64GB(win)/128GB(unix)
=> Log buffer size specifies number of 4KB pages MQ uses to beffer log file writes.
- Default is 128 which is specified by 0 in MQ configuration file
- Minimum is 18 and maximum is 4096
=> Log write integrity is the algorithm used to ensure the integrity of the logs.
- Default algorithm is triple write.
- This can be changed from QM configuration file
=> Logging Configuration files
- mqs.ini is the config file for MQ level settings
- qm.ini is the config file for effective/QM lelvel settings
Examples:
-mqs.init
Log Defaults:
LogPrimaryFiles=3
LogSecondaryFiles=2
LogFilePages=1024
LogType=CIRCULAR
LogBufferPages=0
LogDefaultPath=/var/mqm/logs
-qm.ini
LogPrimaryFiles=3
LogSecondaryFiles=2
LogFilePages=1024
LogType=CIRCULAR
LogBufferPages=0
LogDefaultPath=/var/mqm/logs
LogWriteIntegrity=TrippleWrite
97
=> Log Management

- Circular logging do not need manual log management
- Linear logging needs manual backup/cleaning
=> Some logging related MQ codes
- AMQ7467 Old log file required for queue manager start
- AMQ7468 old log file required for Queue Manager media recovery
- AMQ5037 Queue manager task ‘LOG-FORMAT’ started
- AMQ5037 Queue Manager task ‘LOGGEREU’ stared
- AMQ5037 Queue Manager task ‘LOGGER-IO’ started
=> Media Recording and Recovery
- Recording media images
rcdmqimg command will record the image of the queue manager specified.
- Recovery
is required when a powerloss/reboot/QM failure occurs
When the recovery is performed
- Queues are restored to their comitted state at the time of failure
- Persistant data is not lost
- non-persistant messages will be discarded
=> Log Recovery scenarios
- Disk Failures
In case of circular logging, restore QM and logs from backup
Rebuild QM using support pac MS03
In case of linear logging, restored damaged objects using rcrmqobj
=> Log recovery summary
- In case of circular logging, no recovery is available
- In case of linear logging, use rcrmqobj to recover/recreate the objects fron media
image
Websphere MQ Triggering
MQ Trigering
97
=========
=> What is Triggering?
WebSphere MQ provides a feature that enables an application or channel to be
started automatically when there are messages available to retrieve from a queue.
=> How it works?
- A message is put to a queue defined as triggered.
- If a series of conditions are met, the queue manager sends a trigger message to
an initiation queue. This is called a trigger event.
- A trigger monitor reads the trigger message and takes the appropriate action
based on the contents of the message, which is typically to start a program to
process the triggered queue.
- Trigger monitors may be built-in, supplied by a SupportPac, or user written.
=> Types of Trigger (TRIGTYPE)

- FIRST: A trigger event occurs when the current depth of the triggered queue
changes from 0 to 1.
Use this type of trigger when the serving program will process all the messages on
the queue (i.e. until MQRC_NO_MSG_AVAILABLE).
- EVERY: A trigger event occurs every time a message arrives on the triggered
queue.
Use this type of trigger when the serving program will only process one message at
a time.
- DEPTH: A trigger event occurs when the number of messages on the triggered
queue reaches the value of the TRIGDPTH attribute.
Use this type of trigger when the serving program is designed to process a fixed
number of messages (i.e. all replies for a certain request).
=> Trigger interval (TRIGINT)
- TriggerInterval or TRIGINT is a time interval specified on the QMGR definition for
use by queues defined as TRIGTYPE=FIRST.
- Situations may occur when messages are left on the queue. New messages will
not cause another trigger message. To help with this situation, a trigger message
will be created when the next message is put if TriggerInterval has elapsed since
the last trigger message was created for the queue.
97
=> Trigget setup

- Create an initiation queue or use the default SYSTEM.CHANNEL.INITQ.
- Create a process definition (optional). TriggerData may be specified in lieu of a
process definition.
- Create or alter a transmission queue.
- Associate the initiation queue and the process definition (if applicable) with the
transmission queue, and specify the trigger attributes.
=> Triggering Example1
- DEFINE QLOCAL(QM2) REPLACE USAGE (XMITQ) TRIGGER TRIGTYPE(FIRST)
TRIGDATA(QM1.TO.QM2) INITQ (SYSTEM.CHANNEL.INITQ)
- QM2 is the name of the XMITQ
- QM1.TO.QM2 is the name of the channel to be started when a message hits the
XMITQ
- SYSTEM.CHANNEL.INITQ is the initq monitored by the channel initiator
=> Triggering Example2
- DEFINE QLOCAL(QM4) TRIGGER INITQ(SYSTEM.CHANNEL.INITQ) PROCESS(P1)
USAGE (XMITQ) ? DEFINE PROCESS(P1) USERDATA(QM3.TO.QM4)
- The XMITQ definition has PROCESS instead of TRIGDATA
- The channel name is in USERDATA
=> Application Triggering
- Create an initiation queue or use the default
SYSTEM.DEFAULT.INITIATION.QUEUE.
- Create a process definition.
- Create or alter a local or model queue.
- Associate the initiation queue and process definition with the local queue, and
specify the trigger attributes .
APPLICID is the name of the application executable file, e.g.
- For APPLTYPE(UNIX):
APPLICID (‘/u/admin/test/IRMP01′)
- For APPLTYPE(WINDOWSNT):
APPLICID(‘c:\appl\test\irmp01.exe.’)
- On UNIX® systems, ENVRDATA can be set to the ampersand character to make
the started application run in the background.
97
- The application can receive a parm list with an MQTMC2 containing USRDATA and
ENVRDATA.
=> Application Trigger Example1
- DEFINE QLOCAL (‘IQ’) REPLACE
- DEFINE PROCESS (PROC) REPLACE APPLTYPE (‘CICS’) APPLICID (‘PAYR’)
USERDATA (‘Payroll data’)
- DEFINE QLOCAL (Q1) REPLACE INITQ (‘IQ’) PROCESS (‘PROC’) TRIGGER
TRIGTYPE (FIRST)
- Note: If using TRIGTYPE(DEPTH) then TRIGDEPTH must also be specified.
=> Application Trigger Example2
- CRTMQMQ QNAME(initq_name)
- CRTMQMPRC PRCNAME(proc_name) APPID(lib/pgm) ENVDATA
(‘JOBNAME(trigapl) JOBD(lib/jobd)’)
- CRTMQMQ QNAME(lclq_name) PRCNAME (proc_name) TRGENBL(*YES)
TRGTYPE(*FIRST) INITQNAME(initq_name)
- Note: If using TRGTYPE(*DEPTH) then TRGDEPTH must also be specified.
=> Trigger Conditions
- A trigger message is sent to the initiation queue when all of the following
conditions are satisfied:
1. A message is put on a transmission or local queue.
2. The message’s priority is greater than or equal to the TriggerMsgPriority of the
queue.
3. The number of messages on queue was previously
- Zero for trigger type FIRST
- Any number for trigger type EVERY or *ALL
- TriggerDepth minus 1 for trigger type DEPTH
4. For trigger type FIRST or DEPTH, no program has the trigger queue open for
GETs (Open input count=0).
5. The Get enabled attribute is set to YES on the triggered queue.
6. A Process name is specified and exists, or for transmission queues, TriggerData
contains the name of a channel.
7. An Initiation queue is specified and exists and GETs and PUTs are enabled for
the initiation queue.
97
8. The trigger monitor has been started and has the initiation queue open for GETs
9. The TriggerControl attribute is set to YES on the triggered queue.
10. The TriggerType attribute is not set to NONE.
11. For Trigger Type FIRST, the queue was not previously empty, but the
TriggerInterval set for the QMGR has elapsed.
12. The only application serving the queue issues MQCLOSE and there are still
messages on the queue that satisfy Conditions 2 and 6-10.
13. Certain trigger attributes of the triggered queue are changed, such as
- NOTRIGGER to TRIGGER
- PUT or GET DISABLED to ENABLED
- or a trigger monitor opens the Initiation queue.
14. MSGDLVSQ is set correctly relative to the priority of the messages and the
TriggerMsgPriority setting.
=> Triggering Problem determination
- If the setup is brand new or any configuration changes have been made, verify all
the definitions are complete and correct.
- If the setup is brand new or has worked before, verify all the conditions for a
trigger event are satisfied.
- If channel triggering, verify the correct channel name is specified and the channel
is not in a STOPPED state.
- If application triggering
- verify the application name is correct and exists
- verify the application is coded correctly
- verify the correct authorizations are in place.
- Verify a trigger message can be delivered.
- Verify a trigger monitor is active.
- Verify trigger type and application design match.
- Try manually starting the triggered application to see if it is able to run.
- Stranded messages may occur when the triggered application fails to remove one
or more messages
- for TriggerType FIRST, use TriggerInteval as a “safety net”, because a trigger
event only occurs when depth goes from 0 to 1.
- for TriggerType EVERY, if the triggered application only does one MQGET, manual
97
intervention will be required to process the messages. Otherwise, the application

will only read the oldest message on the next successful trigger and the queue
depth will remain non-zero.
- If there is a loop or high CPU:
- Change the triggered application to specify a WaitInterval on its MQGET.
- Check the BackoutCount in the MQMD
=> TIPS
- For trigger EVERY, if the trigger monitor ends prematurely, no matter how many
messages reside on the queue only one trigger message will be created on restart.
- RUNMQTRM will not get another trigger message until the application completes.
To prevent trigger messages from accumulating
- Run multiple trigger monitors or
- Run the applications in the background
- A trigger message is put to the dead letter queue when
- The queue manager can not put a trigger message on the INITQ
- RUNMQTRM detects an error in the trigger message structure
- RUNMQTRM detects an unsupported application type
- RUNMQTRM can not start the application
- RUNMQTRM detects a data conversion error
- Trigger messages are non-persistent.
- Conditions for a trigger event are “persistent”, so, if a trigger message is lost a
trigger message will be created when the conditions are met.
- Trigger messages take on the default priority of the INITQ.
- Trigger monitors can not retrieve messages that are part of a unit of work until
the unit of work completes (applies whether it is committed or backed out).
- The queue manager counts both committed and uncommitted messages on the
trigger queue when assessing the conditions for a trigger event.
- After recycling the queue manager or trigger monitor, a trigger message may be
created if the triggered queue has messages on it and provided the trigger
conditions are met.
- When triggering channels, trigger type FIRST or DEPTH is recommended.
- Disabling triggering is not under syncpoint control so triggering can not be re-
97
enabled by backing out a unit of work. If a program backs out a unit of work or
abends, triggering for DEPTH must be reenabled by MQSET, ALTER or CHGMQMQ.
97
MQ Problem determination –
Queue Manager Diagnostics
Problem determination – Queue Manager Diagnostics

=> Error Reporting
- when connected to Queue Manager, all the logs routed to
/var/mqm/qmgrs/QM_NAME/errors
- all other messages routed to /var/mqm/errors
=>Error message components
- message always include an identifier and basic text
- message contains date/date/pid/user/program/exception message/suggested
action/source file which generated it
=> Log Rollover
- current message are always appended to the first error log
- rollover occurs when the log reaches ~256k
- this size setting can be changed by setting the following
-queue manager
ErrorLogSize=1048576 #1Mb error log file
-for System error logs
export MQMAXERRORLOGSIZE=1048576
=> Suppression of messages
- Allows non-critical messages to be suppressed
- can be set using the ini stanza
example
QMErrorLog:
ExcludeMesssage=9001,9002,9999 #don’t write these
SuppressMessage=9508 #only write once
Suppressinterval=30 #in any 30secs
=> Error log Recomandations
- save all error logs after a serious error occurs as well as the qm.ini
- be sure to note the time you observed the problem
97
- look for related messages before and after the time of the error
- try to correlate error log message with other diagnostics
=> FFST
- FFST is first failure support technology
- FFST are files written to /var/mqm/errors
- FFST file names format is AMQ[PID].x.FDC
- all threads in a process will append their FFSTs to the same file
=> FFST layout
-The header
this includes
date/time/hostname/pids/probeID/builddate/user/program/process/thread/QM/pro
betype/monitcode etc…
-The Function stack
every thread executing MQ code has a thread control block which contains stack for
MQ functions. this stack shows context in which error occured
-The Trace history
the trace shows sequence of events leading up to a failure
-The component dumps
shows the commom services control blocks
-Environment
includes all user settings at time of error
=> Base MQ tracing
- Tracing records the sequence of events in a program
- MQ supports tracing on all queue managers and clients
- Trace are binary files which requir formatting
- MQ shipps programs for starting/stopiing/formatting traces
-strmqtrc
-endmqtrc
-dspmqtrc
- traces are written to /var/mqm/trace
- trace contains a header with extended process information, then each line of
trace contains pid/tid/trace data
97
Migrating WebSphere MQ
queue manager clusters
MQ Migration
========
Migrating queue managers is generally a simple process, because WebSphere MQ is
designed to automatically migrate objects and messages, and support mixed
version clusters. However, when planning the migration of a cluster, you need to
consider a number of issues, which are described below.
Forward migration involves upgrading an existing queue manager to a later version
and is supported on all platforms. You may wish to forward migrate in order to take
advantage of new features or because the old version is nearing its end-of-service
date.
Testing
———-
It is important when making any system changes to test the changes in a test or
QA environment before rolling out the changes in production, especially when
migrating software from one version to another. Ideally, an identical migration plan
would be executed in both test and production to maximise the chance of finding
potential problems in test rather than production. In practice, test and production
environments are unlikely to be architected or configured identically or to have the
same workloads, so it is unlikely that the migration steps carried out in test will
exactly match those carried out in production. Whether the plans and environments
for test and production differ or not, it is always possible to find problems when
migrating the production cluster queue managers
Plan
—–
When creating the migration plan, you need to consider general queue manager
migration issues, clustering specifics, wider system architecture, and change
control policies. Document and test the plan before migrating production queue
97
managers. Here is an example of a basic migration plan for a cluster queue

manager:
1. Suspend queue manager from the cluster.
* Issue SUSPEND CLUSTER <cluster name>
* Monitor traffic to the suspended queue manager. The cluster workload algorithm
can choose a suspended queue manager if there are no other valid destinations
available or an application has affinity with a particular queue manager.
2. Save a record of all cluster objects known by this queue manager. This data will
be used after migration to check that objects have been migrated successfully.
* Issue DISPLAY CLUSQMGR(*) to view cluster queue managers.
* Issue DISPLAY QC(*) to view cluster queues.
3. Save a record of the full repositories view of the cluster objects owned by this
queue manager. This data will be used after migration to check that objects have
been migrated successfully.
* Issue DISPLAY CLUSQMGR <migrated queue manager name> on the full
repositories.
* Issue DISPLAY QC(*) WHERE(CLUSQMGR EQ <migrated queue manager name>)
on the full repositories.
4. Stop queue manager.
5. Take a backup of the queue manager.
6. Install the new version of WebSphere MQ.
7. Restart queue manager.
8. Ensure that all cluster objects have been migrated successfully.
* Issue DISPLAY CLUSQMGR(*) to view cluster queue managers and check output
against the data saved before migration.
* Issue DISPLAY QC(*) to view cluster queues and check output against the data
saved before migration.
9. Ensure that the queue manager is communicating with the full repositories
correctly. Check that cluster channels to full repositories can start.
10. Ensure that the full repositories still know about the migrated cluster queue
manager and its cluster queues.
* Issue DISPLAY CLUSQMGR<migrated queue manager name> on the full
repositories and check output against the data saved before migration.
97
* Issue DISPLAY QC(*) WHERE(CLUSQMGR EQ <migrated queue manager name>)

on the full repositories and check output against the data saved before migration.
11. Test that applications on other queue managers can put messages to the
migrated cluster queue manager’s queues.
12. Test that applications on the migrated queue manager can put messages to the
other cluster queue manager’s queues.
13. Resume the queue manager.
* Issue RESUME CLUSTER<cluster name>
14. Closely monitor the queue manager and applications in the cluster for a period
of time.
Backout plan
—————-
A backout plan should be documented before migrating. It should detail what
constitutes a successful migration, the conditions that trigger the backout
procedure, and the backout procedure itself. The procedure could involve removing
or suspending the queue manager from the cluster, backwards migrating, or
keeping the queue manager offline until an external issue is resolved.
97
Websphere MQ interview
Questions – part1
What is the maximum channel name size ?

ans: 20
The common application programming interface for MQSeries is
Ans: MQI
Which installable service component supplied to provide security is?
Ans: Object Authority Manager
It is possible to manage OS/390 MQSeries system from an AIX MQSeries system?
Ans: Yes
When using CRTMQM to create a queue manager, which of the following indicates
the queue manager’s dead letter queue?
Ans: -u SYSTEM.DEAD.LETTER.QUEUE
The default type of logging on a Sun Solaris queue manager is:
Ans: Circular
How do you define a queue manager alias?
Ans: DEFINE QREMOTE command
To find the transformed file name associated with an MQSeries object, which
command should you use?
Ans DSPMQFLS
When an application opens a model queue, the application also must specify
whether the dynamic queue is temporary or permanent dynamic
Ans: False
For a channel on HP-UX, what does LONGRTY parameter specify
Ans: Number of times the channel is to try to allocate a session with its partner.
How do you identify a queue as a transmission queue?
Ans: Set the usage attribute appropriately
With NPMSPEED set to FAST, it is possible that messages can be thrown away?
Ans: True
97
Will non-persistant messages survive a queue manager restart, if they are part of a
unit of work?
Ans: No
Which of the following is a queue manager event?
Ans: Remote event.
Every message on a queue is prefaced by
Ans: Message descriptor
Can media image be taken for all the logging types?
Ans: No
Which of the following are valid channel types (message channel agents), that can
send data held in a tranmission queue ? (Two options from the list are correct.)
Ans: SENDER, SERVER
In MQSeries triggering, which program/service starts the triggered program:?
Ans: Trigger monitor
If a trigger event causes triggering to be turned off, which of the following was
specified in the application queue definition?
Ans: TRIGTYPE(DEPTH)
Alias queues can point to
Ans: Local queues, Remote queues
Does AS400 supports MQ client ?
Ans: No
When setting up triggering on a channel, if a process definition is used, what field
is used to name the channel to be started?
Ans: USERDATA
If an application attempts to put a ‘REQUEST-type’ message on a queue, what field
in the MQMD does the queue manager check to be sure it has a value?
Ans: ReplyToQ
97
questions – part2
Answers will not be provided for the question……as the question are to help you
preparing for the interviews. Read and findout the answers.
1.If the client application is running on on machine and moved to another then
what is the attribute need to set.
2.Qmgr Q1 in london and Qmr2 in paris forms a cluster. for adding Qmgr3 in
washington into the cluster how many more channels need to be created in
Qmgr1 and Qmgr2?
3. When the 2 repositories go down what happens to other queue managers in the
cluster.
4. two channel are defined with same xmitq, when one channel is started what
happens when you try to start the other.
5. To find out the status of a remote queue manager what command is used?
6. Which exit is used to check if the user is trusted party?
7. Two applications running on a Queumanagers are connected to 2 remote Queue
managers via two Xmit Queueus. Channels are running at ful capacity. How can we
increase the perfomance?
8. An event message is generated in Qmgr1 and even messages are monitored by
Qmgr2. Expiration time of even message is 1 min. the link frm qmgr1 and qmgr2 is
down. What happens to the message?
9. MQGET fails and the message is still in the Queue. What command is used to
find the error caused?
10. Three Qmgrs Q1 Q2 Q3. There is no connection between Q1 and Q2. A
message is put into Q1 and it has to reach Q3 via Q3.(Multi Hopping) Now the lnk
between Q2 and Q3 is down. What happens to the message.
11. Command USed to find the message length?
12. which installable service component can be used for security?
13. channels defined btwn qm1 and qm2 are qm1.t.qm2 & qm2.t.qm1. how to
know the link status
14. how to define for port xxxx, in channel definition
97
15. command used for browsing messages

1. How do you define when a message on a Queue to be shared on Qmanagers
QM1, QM2 and QM3?
2. A person wants to define a Controlled Queue Manager, which will be used to
control objects on other Client Queue managers which one will mention the best
realtionship between Controlled ueue manager and Client Queue manager?
3. When a channel is running, if it fails suddenly, what command u use to roll the
back the messages which are in Transmission Queue?
4. When we try to put a message on a Queue and if it fails, with saying as Queue is
in use. Which command u use to find which application uses this Queue?
5. What is the command in Unix to direcly run the Channel?
6. If the channel has to stop after 1hour how do u define Disconnect interval?
7. If the AIX appilcation sends a message to Windows application where do u
specify a convert option?
8. If MQseries wants to know the conversation obtained by Sending application
sends a message to Server, which option you use in message descriptor?
9. When a message sending from one channel to another and if the message needs
to be changed in header of the message where do u change it?
10. If a channel is defined with TCP then which field will tell you the TCP value?
Websphere MQ interview questions

– part4
1) There are two queue manager connected. For using SSL on channel, what all the
required parameters to be defined.
2) On unix where are the ssl certificates stored
3) the queuemanger wants to authinicate the client , which option should be used
to set.
4) On window which command will display the queuemanger status
5) from windows to unix client connection is setup. which protocol to use
97
6) for moving all unprocessed messages should be moved to another queue which
option should be set on queue definition
7) the queue is damaged which is the option to recreate the queue.
only one message requires to be encrypted which exit best option for
9) Which attribue of the DEFINE PROCESS command have the name of the
application executable file, specified as a fully qualified file name
10) there are two queuemangaers QM1 & QM2 . QM1 is having sender channer.
The channel in QM2 needs to be stared to start the channel in QM1. which type of
channel is QM2.
11) Which exit is used to perform compression during transmission
12) What happens when a message cannot be delivered in the distribution list.
13) when the cluster is crashed the queumanger will go down? or is uses its partial
repositories
14) What is the parameter used to spceify the deadletter queue during crtmqm.
15) What does SHORTRTY in the channel definition specify?
Questions – Part5
*) The command for creating a dead-letter queue in UNIX is ?

*) IF undelivered message is simply put on the dead-letter queue at the receiving
end, does channel and its transmission queue available?
*) Which configuration file in UNIX systems contains configuration parameters for
the queue manager?
*) The only options to restart a Queue Manager is the Start command . Is it True?
*) Object names in MQSC commands are folded to uppercase, unless the names
are not enclosed within single quotation marks ?
*) How can you terminate command input explicitly?
*) To stop working with MQSC commands interactively, which MQSC command is
used :
97
*) what happens if you don’t specify queue manager name in runmqsc command?
*) can you run control commands from runmqsc?
*) Using runmqsc, which attribute of the queue manager will list the version of the
MQSeries currently being used?
*) When you use the LIKE attribute on a DEFINE command, you are copying the
queue attributes What about messages on that queue?
*) If you decrease the maximum message length on an existing queue, existing
messages are affected ?
*) If an application has the queue open, can the queue be cleared ?
*) MQSeries provides a sample queue browser that you can use to look at the
contents of the messages on a queue. what two input parameters are required to
use it?
*) An alias queue provides a way of referring indirectly to another queue. What
type of queue can be referred?
*) Can An alias queue can be deleted, if an application currently has the referred
queue open?
*) What is the convenient method for applications to create queues as they are
required ?
*) Triggering requires a number of queue attributes to be defined on the
application queue. How do you enable triggering itself?
*) When a trigger event occurs, the queue manager puts a trigger message on the
initiation queue specified in the application queue definition. Do Initiation queues
need special settings ?
*) Which attribue of the DEFINE PROCESS command have the name of the
application executable file, specified as a fully qualified file name ?
97
Questions – part6
*) Will PCF commands cover the same range of functions provided by the MQSC
facility?
*) What is the character limit on properties of PCF commands?.
*) What data type is used by MQAI to performs administration tasks on a queue
manager
*) What is the only common property for both sender-receiver channel pair?
*) Which agent in MQ will take care of taking messages from the transmission
queue and put them on the communication link between the queue managers
*) To set up a cluster, what channel definitions MUST be defined?

*) Which paramater is not required for defining the receiver channel at the source
queue manager
*) Will stopping a queue manager ends the command server associated with it ?
*)_ Which MQSC attribute defines whether a queue is a transmission queue or a
normal queue ?
*) The channel provides a one-way link to the remote queue manager. Messages
are queued at the transmission queue until the channel can accept them. When you
define a channel, you must specify a transmission queue name at which end of the
message channel.
*) Is there an attribute of the local queue manager where the transmission queue
name can be defined?
*) In addition to locating a queue on another queue manager, Can you use a local
definition of a remote queue for any other purposes?
*) When is data conversion recommended ?
*) When you have used the CCSID attribute of the ALTER QMGR command to
change the CCSID of the queue manager. What should be done to use the
changed CCSID value ?
97
*) Which file on UNIX platforms, users can modify MQSeries configuration

attributes within an MQSeries configuration file to effect changes for MQSeries on
the node as a whole.
*) Which file on UNIX platforms, users can modify MQSeries configuration
attributes within a queue manager configuration file to effect changes for specific
queue managers.
*) Which file contains the following details?
a. The name of the default queue manager
b. The names of the queue managers
c. The location of the files associated with each of them
*) In MQSeries for UNIX systems, the AuthorizationService stanza and its
associated ServiceComponent stanza are added automatically when the queue
manager is created, but can be overridden through the use of :-
*) MQSeries queue managers handle the transfer of information that is potentially
valuable, so which types of security controls you need to consider ?
*) do you need to be a member of the mqm group to issue MQI calls from an
application program (unless you want to use the fastpath bindings on the
MQCONNX call).
*) When are the security checks made for a typical application
*) The OAM maintains an access control list (ACL) for each resource that it
controls. Authorization data is stored on which local queue?
*) What is the command used to change the authorizations to an object or to a
class of objects. ?
97
Queue Manager Alias

in Websphere MQ
Queue Manager Aliases enable you to refer to queue managers by more than one
name.
Queue manager alias definitions apply when an application that opens a queue to
put a message, specifies the queue name and the queue manager name.
Queue manager alias definitions have three uses:
* When sending messages, remapping the queue manager name
* When sending messages, altering or specifying the transmission queue
* When receiving messages, determining whether the local queue manager is the
intended destination for those messages.
Queue-manager aliases, which are created using a remote-queue definition with a
blank RNAME, have four uses:
Remapping the queue-manager name when sending messages
A queue-manager alias can be used to remap the queue-manager name
specified in an MQOPEN call to another queue-manager. This can be a cluster
queue manager. For example, a queue manager might have the queue-
manager alias definition:
DEFINE QREMOTE(YORK) RNAME(' ') RQMNAME(CLUSQM)
This defines YORK as a queue-manager name that can be used as an alias for
the queue manager called CLUSQM. When an application on the queue
manager that made this definition puts a message to queue manager YORK,
the local queue manager resolves the name to CLUSQM. If the local queue
manager is not called CLUSQM, it puts the message on the cluster
transmission queue to be moved to CLUSQM, and changes the transmission
header to say CLUSQM instead of YORK.
Note:
This does not mean that all queue managers in the cluster resolve the name
YORK to CLUSQM. The definition applies only on the queue manager that
makes it. To advertise the alias to the whole cluster, you need to add the
97
CLUSTER attribute to the remote-queue definition. Then messages from other

queue managers that were destined for YORK are sent to the queue manager
with the alias definition and the alias is resolved.
Altering or specifying the transmission queue when sending messages
This method of aliasing can be used to join a cluster to a non-cluster system.
For example, for queue managers in the cluster ITALY to communicate with
the queue manager called PALERMO, which is outside the cluster, one of the
queue managers in the cluster must act as a gateway. From this queue
manager, issue the command:
DEFINE QREMOTE(ROME) RNAME(' ') RQMNAME(PALERMO) XMITQ(X) CLUSTER(ITALY)
This is a queue-manager alias definition, which defines and advertises ROME

as a queue manager over which messages from any queue manager in the
cluster ITALY can multi-hop to reach their destination at PALERMO. Any
message put to a queue opened with the queue-manager name set to ROME
in the open handle, is sent to the gateway queue manager, where the queue
manager alias definition was made. Once there, it is put on the transmission
queue X and moved by conventional, non-cluster channels to the queue
manager PALERMO.
The choice of the name ROME in this example is not significant. The values
for QREMOTE and RQMNAME could both be the same.
Determining the destination when receiving messages
When a queue manager receives a message, it looks in the transmission
header to see the name of the destination queue and queue manager. If it
has a queue-manager alias definition with the same name as the queue
manager referenced, it substitutes the RQMNAME from its definition for the
queue manager name in the transmission header.There are two reasons for
using a queue-manager alias in this way:
 To direct messages to another queue manager
 To alter the queue manager name to be the same as the local queue
manager
Using a queue manager as a gateway into the cluster.
This enables workload balancing for messages coming from outside the
cluster.Suppose you have a queue called EDINBURGH on more than one
97
queue manager in the cluster, and you want the clustering mechanism to
balance the workload for messages coming to that queue from outside the
cluster.A queue manager from outside the cluster needs a transmit queue
and sender channel to one queue manager in the cluster, which is called a
gateway queue manager. To take advantage of the default workload
balancing mechanism, the gateway queue manager must not contain an
instance of the EDINBURGH queue.
Actual IBM
documentation : http://publib.boulder.ibm.com/infocenter/wmqv6/v6r
0/index.jsp?topic=/com.ibm.mq.csqzah.doc/qc10790_.htm
97
Backup Queue Manager

in Websphere mq
Creating a backup queue manager
========================
1. Create a backup queue manager for the existing queue manager using the
control command crtmqm. The backup queue manager requires the following:
* To have the same attributes as the existing queue manager, for example the
queue manager name, the logging type, and the log file size.
* To be on the same platform as the existing queue manager.
* To be at an equal, or higher, code level than the existing queue manager.
2. Take copies of all the existing queue manager’s data and log file directories,
including all subdirectories, as described in Backing up queue manager data.
3. Overwrite the backup queue manager’s data and log file directories, including all
subdirectories, with the copies taken from the existing queue manager.
4. Execute the following control command on the backup queue manager:
strmqm -r BackupQMName
This flags the queue manager as a backup queue manager within WebSphere®
MQ, and replays all the copied log extents to bring the backup queue manager in
step with the existing queue manager.
starting a backup queue manager

=======================
1. Execute the following control command to activate the backup queue manager:
strmqm -a BackupQMName
The backup queue manager is activated. Now active, the backup queue manager
can no longer be updated.
2. Execute the following control command to start the backup queue manager:
strmqm BackupQMName
3. Restart all channels
Note: stop the existing Qmgr using endmqm -w, before copying the qmgr date to
backup qmgr
97
Bridging clusters in Websphere MQ

 Bridging two clusters in mq
 The above picture has:
 BLOG cluster with QM1 having Q1
WIKI cluster with QM3 having Q3
QM2 is the bridge for the two clusers.
 =>
QM1 has defined a cluster queue Q1, as follows:
 DEFINE QLOCAL(Q1) CLUSTER(BLOG)
 QM3 has defined a cluster queue Q3, as follows:
 DEFINE QLOCAL(Q3) CLUSTER(WIKI)
 QM2 has created a namelist called BLOGWIKI, containing the names of both
clusters:
 DEFINE NAMELIST(BLOGWIKI)
 DESCR('BLOGWIKI namelist')
 NAMES(BLOG, WIKI)
 QM2 has also defined a cluster queue Q2, as follows:
 DEFINE QLOCAL(Q2) CLUSNL(BLOGWIKI)
 QM2 is a member of both clusters and is the bridge between them. For each
queue that you want to make visible across the bridge, you need a QALIAS
definition on the bridge.
 DEFINE QALIAS(MYQ3) TARGQ(Q3) CLUSTER(BLOG) DEFBIND(NOTFIXED)
 This means that an application connected to a queue manager in BLOG
(example QM1), can put a message to a queue, which it refers to as MYQ3,
and this message is routed to Q3 at QM3.
 When you open a queue you need to set DEFBIND to either (NOTFIXED) or
(QDEF) because if it is left as the default (OPEN) the queue manager will
resolve the alias definition to the bridge queue manager that hosts it, and the
bridge will not forward the message on.
 For each queue manager that you want to make visible, you need a queue-
manager alias definition. For example on QM2 you need:
 DEFINE QREMOTE(QM1) RNAME(' ') RQMNAME(QM1) CLUSTER(WIKI)
 This means that an application connected to any queue manager in WIKI (for
example QM3), can put a message to any queue on QM1, by naming QM1
explicitly on the MQOPEN call.
97
Creating a cluster in websphere

MQ (code)
97
Queue Managers: QM1,2 (full repos), QM3,4 (partial repos)

NOTE: all queue managers are on same machine
Change my name in the commands, if you don’t want it in your machine :)
QM1
——
crtmqm QM1
strmqm QM1
runmqsc QM1
alter qmgr repos(JOSEPH)
DEFINE CHANNEL(TO.QM2) CHLTYPE(CLUSSDR) TRPTYPE(TCP)
CONNAME(‘LOCALHOST(7001)’) CLUSTER(JOSEPH)
DEFINE CHANNEL(TO.QM1) CHLTYPE(CLUSRCVR) TRPTYPE(TCP)
DEFINE LISTENER(QM1_LSNR) TRPTYPE(TCP) PORT(7000) CONTROL(QMGR)
 QM2
——
crtmqm QM2
strmqm QM2
runmqsc QM2
97
alter qmgr repos(JOSEPH)

DEFINE CHANNEL(TO.QM1) CHLTYPE(CLUSSDR) TRPTYPE(TCP)
DEFINE LISTENER(QM2_LSNR) TRPTYPE(TCP) PORT(7001) CONTROL(QMGR)
 QM3
——
crtmqm QM3
strmqm QM3
runmqsc QM3
define channel(TO.QM2) CHLTYPE(CLUSSDR) TRPTYPE(TCP)
DEFINE LISTENER(QM3_LSNR) TRPTYPE(TCP) PORT(7002)
START LISTENER(QM3_LSNR)
 QM4
——
crtmqm QM4
strmqm QM4
runmqsc QM4
define channel(TO.QM1) CHLTYPE(CLUSSDR) TRPTYPE(TCP)
DEFINE LISTENER(QM4_LSNR) TRPTYPE(TCP) PORT(7003)
START LISTENER(QM4_LSNR)
Websphere MQ Dead
Letter Queue (DLQ)
97
Dead Letter Queue

- When messages can not be delivered to the intended queue, the messages may
be delivered to a Dead Letter Queue (DLQ) if the queue manager has one defined.
- By default a queue manager does not have a DLQ but you should define one for
every queue manager.
 Dead Letter Messages
Messages can be placed on the DLQ by the queue manager, the channels
(MCA) or by applications
When the messages are put onto DLQ, they should have a Dead Letter
Header (DLH). DLH will be generated by Queue manager and MCA.
If application are putting the messages onto DLQ, applications must create
the DLH.
 MQRC and MQFB
Reason code in the MQDLH will be a value from either the MQRC reason
codes or MQFB feedback codes
 Example MQDLH
MQOPEN - 'SYSTEM.DEAD.LETTER.QUEUE'
MQGET of message number 1
****Message descriptor****
StrucId : 'MD ' Version : 2
Report : 0 MsgType : 8
Expiry : -1 Feedback : 0
Encoding : 273 CodedCharSetId : 819
Format : 'MQDEAD ‘
Priority : 0 Persistence : 1
MsgId : X'414D5120626F776D616E676120202020524E244220001501'
CorrelId : X'000000000000000000000000000000000000000000000000'
BackoutCount : 0
ReplyToQ : ' '
ReplyToQMgr : 'QM1_TEST ‘
** Identity Context
UserIdentifier : 'joseph '
AccountingToken :
X'16010515000000030D6D3BAB5CDD6E5F7E9E53EB03000000000000000000000B'
ApplIdentityData : ' '
** Origin Context
97
PutApplType : '11'
PutApplName : ‘WebSphere MQ\bin\amqsputc.exe'
PutDate : '20091018'
PutTime : '12044424'
ApplOriginData : ' '
GroupId : X'000000000000000000000000000000000000000000000000'
MsgSeqNumber : '1'
Offset : '0'
MsgFlags : '0'
OriginalLength : '-1'
**** Message ****
length - 194 bytes
00000000: 444C 4820 0000 0001 0000 0805 5445 5354 'DLH ........TEST‘
00000010: 2020 2020 2020 2020 2020 2020 2020 2020 ' ‘
00000020: 2020 2020 2020 2020 2020 2020 2020 2020 ' ‘
00000030: 2020 2020 2020 2020 2020 2020 4741 4220 ' GAB ‘
00000040: 2020 2020 2020 2020 2020 2020 2020 2020 ' ‘
00000050: 2020 2020 2020 2020 2020 2020 2020 2020 ' ‘
00000060: 2020 2020 2020 2020 2020 2020 0000 0222 ' ..."‘
00000070: 0000 01B5 4D51 5354 5220 2020 0000 0006 '...µMQSTR ....‘
00000080: 616D 7172 6D70 7061 2020 2020 2020 2020 'amqrmppa ‘
00000090: 2020 2020 2020 2020 2020 2020 3230 3035 ' 2009‘
000000A0: 3033 3031 3132 3439 3531 3735 7465 7374 '030112495175test‘
000000B0: 206F 6620 4D65 7373 6167 6520 746F 2044 ' of Message to D‘
000000C0: 4C51 'LQ
 DLQ Handler
Once a message arrives on the DLQ you can automate the handling of that
message using the DLQ handler program. You can have the handler running
and waiting for messages to arrive on the DLQ or you can set up the DLQ to
trigger the start of the handler program
 Starting the DLQ Handler
You can start the DLQ handler using the runmqdlq command.
Example: runmqdlq DLQ QMGR < rules.tb
where DLQ = name of your dead letter q
QMGR = queue manager name and
rules.tb is a file with your rules table
 Rules Table
It Defines how the DLQ handler will process the messages on the DLQ
97
Two types of entries in the rules table

-Control Data
-Rules
 runmqdlq can take rules table from command line or redirect from file.
 Sample Program
Websphere MQ supplies a sample program called amqsdlq which provides
similar function as runmqdlq. This allows users to customize the way
messages are handled from the DLQ, especially useful if you have
applications placing messages directly onto DLQ.
 How to write Rules in rule table explained
Rule table is looks something like: Pattern/Keyword Action. ( simillat to find a
particular keyword and the do the action specified)
 Pattern Keywords – allow you to match only certain messages on the DLQ
Ex: REASON – match only messages with a specified reason code
DESTQ – match only messages which were destined for a specified queue
 Action Keywords describe how a matching message is processed
ACTION(DISCARD|IGNORE|RETRY|FWD)
FWDQ – name of queue where message is forwarded
FWDQM – name of qmgr where message is forwarded
HEADER(YES|NO) – do messages have DLH header
PUTAUT(DEF|CTX) – userid of runmqdlq program or userid from the MD of
the message on the DLQ
RETRY – number of times to retry each matching rule
 More about Rule Table
A rules table must contain at least one rule.
Keywords can occur in any order.
A keyword can be included only once in any rule.
Keywords are not case-sensitive.
A keyword and its parameter value must be separated from other keywords
by at least one blank space or comma.
There can be any number of blanks at the beginning or end of a rule, and
between keywords, punctuation, and values.
Each rule must begin on a new line.
For reasons of portability, the significant length of a line must not be greater
than 72 characters.
97
 Sample Rule Table

***************************************************
* An example rules table for the runmqdlq command *
***************************************************
* Control data entry
* ------------------
* If parameters are not supplied on the runmqdlq command use
* SYSTEM.DEAD.LETTER.QUEUE as the input queue, use QM1_TEST as the
* queue manager and set retry interval to 20 seconds
inputq('SYSTEM.DEAD.LETTER.QUEUE') inputqm('QM1_TEST') retryint(20)
*
* Rules entries
* -----
* Include a rule with ACTION (RETRY) first to try to deliver the
* message to the intended destination. If a message is placed on the
* DLQ because its destination queue is full, attempt to forward the
* message to its destination queue. Make 5 attempts at approximately
* 20 second intervals (the default value for RETRYINT). Also include
* the "+" just to show how to wrap a command over to the next line.
REASON(MQRC_Q_FULL) ACTION(RETRY) RETRY(5)
* If a message is placed on the DLQ due to put inhibited, attempt to
* forward the message to its destination queue. Make 5 attempts at
* approximately 20 second intervals (the default value for RETRYINT).
REASON(MQRC_PUT_INHIBITED) ACTION(RETRY) RETRY(5)
* Include a rule to handle messages which do not match any of the
* patterns specified above. Send the messages to another queue named
* DEADQ where they can be handled later.
ACTION(FWD) FWDQ('DEADQ')
 Runmqdlq examples
If you use the DLQ handler without redirecting stdin from a file (the rules
table), the DLQ handler reads its input from the keyboard.
In WebSphere MQ for AIX, Solaris, HP-UX, and Linux, the DLQ handler does
not start to process the named queue until it receives an end_of_file (Ctrl+D)
character.
In WebSphere MQ for Windows it does not start to process the named queue
until you press the following sequence of keys: Ctrl+Z, Enter, Ctrl+Z, Enter
 C:\>runmqdlq SYSTEM.DEAD.LETTER.QUEUE QM1_TEST
WAIT(YES) RETRYINT(20)
97
REASON(MQRC_Q_FULL) ACTION(RETRY) +
RETRY(5)
REASON(MQRC_PUT_INHIBITED) ACTION(RETRY) RETRY(5)
REASON(*) ACTION(FWD) FWDQ('DEADQ')
^Z
^Z
2005-04-08 02.20.09 AMQ8708: Dead-letter queue handler started to process
INPUTQ(SYSTEM.DEAD.LETTER.QUEUE)
Websphere MQ Quick reference

 05 Nov

 1 Votes

MQSC: indicates a runmqsc command, which can be executed while in

runmqsc [QmgrName] or as one line command using:
echo command | runmqsc [QmgrName]
on Unix platforms add double quotes:
echo “command” | runmqsc [QmgrName]
97

 MQ Display commands
97

 MQ start-Stop commands

 MQ status verification commands
Websphere MQ v7
97
 WebSphere MQ (WMQ) Version 7 takes its central theme from requirements

to extend its support for JMS applications. WMQ has supported the JMS API
for many years but recent growth in user applications written to use the JMS
API, and growth in SOA solutions that need to exploit a JMS provider for
access to messaging (for example as part of an Enterprise Service Bus), have
increased the importance of this programming interface. This has lead to
incorporation of a number of JMS features into the core WebSphere MQ
engine, and in turn has allowed these features to be easily accessible to
applications using the native MQ API (MQI), not just those written to the JMS
API.
 The publish/subscribe messaging pattern is one of the two patterns defined
by the JMS API, the other being the point-to-point matter. WebSphere MQ V7
therefore extends its publish/subscribe provision. WebSphere MQ Version 7
provides publish/subscribe capabilities that exploit the natural high vailability
capabilities in WMQ including queue manager clustering. It incorporates a
comprehensive range of qualities of service for message delivery, ranging
from assured delivery to lightweight non persistent. It also permits a range
of topologies, including support for very large numbers of subscribers.
 The pub/sub implementation in V7 has been designed to ensure that we can
reach a simplified, and fullyintegrated, relationship with Message Broker’s
pub/sub capabilities.
 WebSphere MQ Version 7 provides application programming interfaces that
support the concepts required by JMS, including publish/subscribe, in the
MQI, which JMS exploits.
 Enhancements to the programming and administrative interfaces are all
modelled after existing WMQ interfaces, to deliver a familiar and easy-to-
learn route towards the new features.
97
Difference Between WebSphere MQ

and Message Broker
 WebSphere MQ is a solution for application-to-application communication
services regardless of where your applications or data reside. Whether on a
single server, separate servers of the same type, or separate servers of
different architecture types, WebSphere MQ facilitates communications
between applications by sending and receiving message data via messaging
queues. Applications then use the information in these messages to interact
with Web browsers, business logic, and databases. WebSphere MQ provides a
secure and reliable transport layer for moving data unchanged in the form of
messages between applications but it is not aware of the content of the
messages. WebSphere MQ uses a set of small and standard application
programming interfaces (APIs) that support a number of programming
languages, including Visual Basic, NATURAL, COBOL, Java, and C across all
platforms.
 WebSphere Message Broker is built to extend WebSphere MQ, and it is
capable of understanding the content of each message that it moves through
the Broker. Customers can define the set of operations on each message
depending on its content. The message processing nodes supplied with
WebSphere Message Broker are capable of processing messages from various
sources, such as Java Message Service (JMS) providers, HyperText Transfer
Protocol (HTTP) calls, or data read from files. By connecting these nodes with
each other, customers can define linked operations on a message as it flows
from one application to its destination.
Message Broker can do the following:
* Matches and routes communications between services
* Converts between different transport protocols
* Transforms message formats between requestor and service
* Identifies and distributes business events from disparate sources
 Together, WebSphere MQ and WebSphere Message Broker deliver a
comprehensive publish and subscribe facility, connecting Message Broker’s
97
broad transport and format support to WebSphere MQ’s messaging

backbone. WebSphere Message Broker extends the WebSphere MQ publish
and subscribe functionality with advanced function such as content-based
publish and subscribe by means of an enhanced Publication node. The two
products share a common publish and subscribe domain for topic- and
content-based operations
97
Communicating with a Queue Manager outside

Cluster | Websphere MQ
Assumptions:
1. You already have a Queue Manager cluster (named JOSEPH) setup with 2 Queue Managers with
names QM1 and QM2 and all the requires channels are setup for communication between QM1 and QM2
2. You have QM3, which is outside the cluster
3. QM2 has a Queue [Q2] defined at cluster level.
In this tutorial, let us send message from QM3’s Q3 to QM2’s Q2 and in the reverse path.
In this case one of your Queue Managers should act as a gateway. Say for example, lets make QM1 as the
gateway for cluster and QM3 is outside cluster.
Steps:
1. The queue manager outside the cluster must have a QREMOTE definition for each queue in the cluster
that it wants to put messages to.
DEFINE QREMOTE(Q2) RNAME(Q2) RQMNAME(QM2) XMITQ(TQ1) [in this case Q2 is a

cluster queue and i want to put message from QM3 -> QM2]
2. QM3 must have a SDR channel and TX queue to QM1 and QM1 should have corresponding RCVR
channel
For replies:
3. The gateway (QM1) advertises a queue-manager alias for the queue manager outside the cluster. It
advertises this alias to the whole cluster by adding the cluster attribute to its queue-manager alias
definition.
DEFINE QREMOTE(QM3) RNAME(‘ ‘) RQMNAME(QM4) CLUSTER(JOSEPH)
4. QM1 must have a SDR channel and TX queue to QM4 and QM4 should have corresponding RCVR
channel.
Observe the below diagram, to understand the setup

97
Now, you need to define the following, for communicating from QM3 to Cluster and Cluster to QM3.
on QM1:
DEFINE QL(TQ3) USAGE(XMITQ)
DEFINE LISTENER(QM1_LIST) TRPTYPE(TCP) PORT(1111)
DEFINE CHANNEL(TO.QM3) CHLTYPE(SDR) TRPTYPE(TCP) CONNAME(‘localhost(3333)’)
XMITQ(TQ3)
DEFINE CHANNEL(TO.QM1) CHLTYPE(RCVR) TRPTYPE(TCP)CONNAME(‘localhost(1111)’)
DEFINE QREMOTE(QM3) RNAME(‘ ‘) RQMNAME(QM3) XMITQ(TQ3) CLUSTER(JOSEPH)
on QM2:
DEFINE QL(Q2) CLUSTER(JOSEPH)
on QM3:
DEFINE QL(Q3)
DEFINE QL(TQ1) USAGE(XMITQ)
DEFINE CHANNEL(TO.QM1) CHLTYPE(SDR) TRPTYPE(TCP) CONNAME(‘localhost(1111)’)
XMITQ(TQ1)
DEFINE CHANNEL(TO.QM3) CHLTYPE(RCVR) TRPTYPE(TCP)CONNAME(‘localhost(3333)’)
DEFINE QREMOTE(Q2) RNAME(Q2) RQMNAME(QM2) XMITQ(TQ1)
Start all the listeners on QM1/2/3 and Ensure all channels are running. First test that you are able to
communicate between QM1 and QM2.
97
Then, you should be able to put messages

QM3[Q3] –> QM2[Q2]
QM2[Q2] –> QM3[Q3]
Similarly, if you have any queue on QM1, create corresponding QREMOTE on QM3(which is outside).
Multi instance Queue Managers | Websphere

MQ v7
Are multi-instance queue managers new to MQ ? I say no, earlier we used to implement this concept by
using external software. Now with MQ v7, this feature was provided inbuilt.
The concept of these multi-instance queue managers is to share the queue manager data in a high
available storage place (line SAN), which should be accessible by more than 1 queue manager. For
example, we have QM1 and QM2 on different machine. For both these queue managers we keep the logs
and QM data in a shared location /shared/QMdata. Now if you start the QM1 first, then QM2 becomes
passive. When QM1 is not operational or crashed then QM2 will take over the proceedings.
When you intend to use a queue manager as a multi-instance queue manager, create a single queue
manager on one of the servers using the crtmqm command, placing its queue manager data and logs in
shared network storage. On the other server, rather than create the queue manager again, use the
addmqinf command to create a reference to the queue manager data and logs on the network storage.
To create and use this multi-instance queue managers, we need:
# Client and channel reconnection to transfer WebSphere MQ connections to the computer that takes over
running the active queue manager instance.
# A high performance shared network file system that manages locks correctly and provides protection
against media and file server failure.
# Resilient networks and power supplies to eliminate single points of failure in the basic infrastructure.
# Applications that tolerate failover. In particular you need to pay close attention to the behavior of
transactional applications, and to applications that browse WebSphere MQ queues.
# Monitoring and management of the active and standby instances to ensure that they are running, and to
restart active instances that have failed.
How to create the multi-instance Queue Manager?
Note: mqm user and mqm group should have required access permissions to the shared data file system.
the mqm user and group should be available across all the machines which has the QMs and they
UID/GID should be same in Linux.
Steps:
I’m assuming that you already have MQ installed on server1 and server2.
Aslo assuming that, you have a NFS/SAN share with name /MQHA with full access to mqm user on both
machines. [otherwise, contact your Linux admin to set this]
On Server1, Which will host QM1:

1. Create the shared directory which holds the logs and QM data on the shared network/NFS (like
MQHA)
2. Now verify that locking to ensure that multi-instance queue mangers are supported on both
machines.
97
# Run amqmfsck, without any options, on each system to check basic locking
# Run amqmfsck on both WebSphere MQ systems simultaneously, using the -c option, to test
writing to the directory concurrently.
# Run amqmfsck on both WebSphere MQ systems at the same time, using the -w option, to test
waiting for and releasing a lock on the directory concurrently.
3. check the UID/GID of mqm user
4. Create the logs and data directories in the shared file system
1. mkdir /MQHA
2. mkdir /MQHA/logs
3. mkdir /MQHA/qmgrs
5. Create the queue manager
crtmqm -ld /MQHA/logs -md /MQHA/qmgrs -q QM1
6. Copy the queue manager configuration details from Server 1
dspmqinf -o command QM1
and copy the result to the clip board,
addmqinf -s QueueManager
-v Name=QM1
-v Directory=QM1
-v Prefix=/var/mqm
-v DataPath=/MQHA/qmgrs/QM1
On server2. which will host QM2:

1. Verify the access to shared directory (MQHA)
2. Verify the locking to ensure that multi-instance queue managers are supported [see step2, in
Machine1/QM1]
3. Check the GID and UID of mqm and ensure that they are same as Machine1
4. Now, paste the QM configuration information which you got in Step6 of QM1
addmqinf -s QueueManager
-v Name=QM1
-v Directory=QM1
-v Prefix=/var/mqm
-v DataPath=/MQHA/qmgrs/QM1
Start the queue manager instances, in either order, with the -x parameter:
strmqm -x QM1
If you start QM1 first, QM1 will be active and QM2 is passive and vise versa if you start QM2 first.
Testing
Stop the active Queue Manager using, endmqm command with -s option. The client programs reconnect
to the new queue manager instance and continue to work with the new instance after a slight delay.

Ibm Websphere MQ Basics: What Is Mqseries?

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Ibm Websphere MQ Basics: What Is Mqseries?

Hochgeladen von

Copyright:

Verfügbare Formate

97

IBM Websphere MQ basics

MQSeries Objects (the basics)

Some properties of local queues:

 Enable/Disable Put or Get

MQI channels – connect an MQSeries client to a queue manager on a server machine

across dissimilar networks

Does any process have queue open for reading or writing?

• component – part of WebSphere MQ where the report was produced

(11) | Major Errorcode :-

0x80006ad9e0 00000000 00000000 00000001 00568001 ………….V..

9. process id for the process which produced the report

It can be more complex if the signal is generated from elsewhere within

a) Prepare the XA switch files

Create new Queue manager

New Local Queue

DEFPSIST(NO) -> Persistant YES/NO

Give permissions to Queue

New Transmit Queue

setmqaut -m XQ_NAME -n QM_NAME -t queue -g group/user [+browse +get +dsp

New Remore Queue

Display Queue properties

New Sender Channel

2. MQ ping the remote side

Websphere MQ – Listener Operations

New Receiver Channel

JMS (java messag service)

Message-Oriented-Middleware provide a common reliable way for programs to

Not all MOM providers support all these models.

The primary features of JMS are as follows:

The Java Message Service API

JMS Parent Publish-Subscribe Point-To-Point Domain

Destination Topic Queue

ConnectionFactory TopicConnectionFactory QueueConnectionFactory

Connection TopicConnection QueueConnection

Session TopicSession QueueSession

MessageProducer TopicPublisher QueueSender

MessageConsumer TopicSubscriber QueueReceiver,

Table 1: Relationship of Point-To-Point and Publish-Subscribe

MQ Series/MQ: – It is an IBM web sphere product which is evolved in 1990’s. MQ

CONTROL COMMANDS : (case sensitive)

GENERAL ERRORS OCCURING IN REALTIME SCENARIO:-

DEFINE QLOCAL (LQ) TRIGGER TRIGTYPE (EVERY) INITQ (IQ) PROCESS

3. Endmqcsv:-to end the command server for a particular queue manager

Default path for windows :

How a Client Sends a Request:-

Qns:How to remove a Qmgr from Cluster?

Qns:Algorithm for workload balancing?

Remove Cluster channels on each Queue manager

MQ Queue Manager Clusters

- open the queue with the MQOO_BIND_NOT_FIXED open option

Check the AMQERRxx.log or CHIN joblog.

=> MQ log are also known as transaction logs.

=> MQ logs consists of two parts

=> Log file size details table

=> Log Management

=> Types of Trigger (TRIGTYPE)

=> Trigget setup

intervention will be required to process the messages. Otherwise, the application

Problem determination – Queue Manager Diagnostics

managers. Here is an example of a basic migration plan for a cluster queue

* Issue DISPLAY QC(*) WHERE(CLUSQMGR EQ <migrated queue manager name>)

What is the maximum channel name size ?