MQ Listener, Channel and Queue Management

Exclusive offer: get 50% off this eBook here
IBM InfoSphere Replication Server and Data Event Publisher

IBM InfoSphere Replication Server and Data Event Publisher — Save 50%

Design, implement, and monitor a successful Q replication and Event Publishing project with IBM InfoSphere Replication Server and Data Event Publisher using this book and eBook

$35.99    $18.00
by Pav Kumar-Chatterjee | August 2010 | Enterprise Articles IBM

The previous article, IBM WebSphere MQ commands, illustrated the working and setup of WebSphere MQ.

In this article by Pav Kumar-Chatterjee, author of IBM InfoSphere Replication Server and Data Event Publisher, we look at how we manage the MQ Listeners, WebSphere MQ channels and WebSphere MQ queues.

(For more resources on IBM, see here.)

MQ Listener management

Before a local Queue Manager can send messages to a remote Queue Manager, we need to start a Listener for the remote Queue Manager. The default MQ Listener port number is 1414, and if we use this port, then we do not have to specify a port number when we issue the start listener command. This section looks at how we manage the MQ Listeners. We will look at the different ways of defning, starting, and stopping a Listener.

Defning/Starting an MQ Listener

There are two ways of defning and starting an MQ Listener:

The first method uses the run Listener RUNMQLSR command. The parameters for the command are the type of connectivity (-t), the Queue Manager name (-m), and the port number to be started (-p). So if we want to start a TCP listener on port 1450 for Queue Manager QMA, we would issue:

$ runmqlsr -t tcp -m QMA -p 1450

This command can be put into a batch fle (SYSA_QMA_START_RUNMQLSR.BAT) and in UNIX can be run with the nohup and & options:

$ nohup runmqlsr -t tcp -m QMA -p 1450 &

The command to start a TCP listener on port 1451 for Queue Manager QMB is:

$ nohup runmqlsr -t tcp -m QMB -p 1451 &

This command can be put into a SYSB_QMB_START_RUNMQLSR.BAT batch file.

The second method creates the Listener from the MQSC environment, using the following RUNMQSC command fle:

DEFINE LISTENER (QMA1450) +
TRPTYPE (TCP) +
PORT (1450) +
CONTROL(QMGR)

In this text file, we have given the Listener a name (QMA1450), and assigned a port number to that Listener. The last parameter shown is CONTROL, which determines how the Listener is started, with the possible options being MANUAL, QMGR, and STARTONLY, which mean:

  • MANUAL: (default) The Listener is not to be started automatically or stopped automatically. It is to be controlled by use of the START LISTENER and STOP LISTENER commands.
  • QMGR: The Listener being defned is to be started and stopped at the same time as the Queue Manager is started and stopped.
  • STARTONLY: The Listener is to be started at the same time as the Queue Manager is started, but is not requested to stop when the Queue Manager is stopped.

If a Listener is to be controlled manually, then it can be started using the following command issued from the MQSC environment:

: start listener(QMA1450)

So to recap, if we use an MQ command (RUNMQLSR) to start a Listener, then we cannot give it a name, and we have to start it manually every time the Queue Manager is started. If we use a text fle from the MQSC environment, then we can name the Listener and have it start when the Queue Manager starts.

To start the Listeners, issue the following commands on QMA and QMB respectively:

start runmqlsr -t tcp -m QMA -p 1450
start runmqlsr -t tcp -m QMB -p 1451

Both of these commands can be contained in batch fles SYSA_QMA_START_RUNMQLSR.BAT and SYSB_QMB_START_RUNMQLSR.BAT respectively.

Depending on the standards at your site, you can create Listeners according to the second method.

Displaying an MQ Listener

What we mean by "displaying" an MQ Listener is frstly checking if the Listener is actually running and secondly displaying the attributes of the Listener. Let's first look at checking if the Listener is running.

If the Listener was started using the RUNMQLSR MQ command:

$ runmqlsr -t tcp -m QMA -p 1450 &

Then this creates a Listener, whose name is of the form SYSTEM.LISTENER.TCP.<n>. We can check if this listener is running by issuing the DISPLAY LSSTATUS MQSC command:

: display lsstatus(*)

And you'll see:

AMQ8631: Display listener status details.
LISTENER(SYSTEM.LISTENER.TCP.3) STATUS(RUNNING)
PID(12912)

We can see that the status is RUNNING. And the PID corresponds to the output from the UNIX ps –ef command:

$ ps -ef | grep -i "runmqlsr"
mqm 12912 1 0 14:14 pts/1 00:00:00 runmqlsr -t tcp -m QMA -p 1450
db2instp 15937 10695 0 14:43 pts/1 00:00:00 grep -i runmqlsr

If the Listener had been created using the MQSC commands in a fle (as shown previously), then we could have given the Listener a name (QMA1450). And now we can check if the Listener is running using the DISPLAY LSSTATUS MQSC command:

: display lsstatus(*)

And you'll see:

AMQ8631: Display listener status details.
LISTENER(QMA1450) STATUS(RUNNING)
PID(2360)

We could of course have specifed our Listener name in place of the asterisk:

: display lsstatus(QMA1450)
AMQ8631: Display listener status details.
LISTENER(QMA1450) STATUS(RUNNING)
PID(2360) STARTDA(2009-02-19)
STARTTI(16.41.41) DESCR( )
TRPTYPE(TCP) CONTROL(QMGR)
IPADDR(*) PORT(1450)
BACKLOG(100)

If the Listener was created using an MQSC command fle, then its properties can be displayed using the DISPLAY LISTENER MQSC command and specifying a name:

: display listener(QMA1450)
AMQ8630: Display listener information details.
LISTENER(QMA1450) CONTROL(QMGR)
TRPTYPE(TCP) PORT(1450)
IPADDR( ) BACKLOG(100)
DESCR( ) ALTDATE(2009-02-19)
ALTTIME(16.41.41)

If the Listener was started using the RUNMQLSR command, then to display its attributes we need to append the parameter ALL to the DISPLAY LSSTATUS command:

: display lsstatus(*) all
AMQ8631: Display listener status details.
LISTENER(SYSTEM.LISTENER.TCP.3) STATUS(RUNNING)
PID(8256) STARTDA(2010-01-07)
STARTTI(16.54.54) DESCR( )
TRPTYPE(TCP) CONTROL(MANUAL)
IPADDR(*) PORT(1450)
BACKLOG(100)

Stopping an MQ Listener

There are two ways of stopping a Listener. The frst method uses the ENDMQLSR MQ command, and the second method uses the STOP LISTENER MQSC command.

In the following example, we want to stop the Listener for Queue Manager QMA using the ENDMQLSR MQ command:

$ endmqlsr –w -m QMA

In the following example we are using the STOP LISTENER MQSC command to stop a Listener:

: stop listener(QMA1450)

IBM InfoSphere Replication Server and Data Event Publisher Design, implement, and monitor a successful Q replication and Event Publishing project with IBM InfoSphere Replication Server and Data Event Publisher using this book and eBook
Published: August 2010
eBook Price: $35.99
Book Price: $59.99
See more
Select your format and quantity:

(For more resources on IBM, see here.)

MQ Channel management

This section looks at how we define, stop, start, and display the status of WebSphere MQ Channels. For each local Queue Manager, we need a Sender Channel and a Receiver Channel, both of which need a matching pair on a remote Queue Manager.

To defne a Channel

In the following figure, on the left-hand side, we are on QMA and define two Channels:

  • A Sender Channel called QMA.TO.QMB, which uses the Transmission Queue QMB.XMITQ and points to the remote WebSphere MQ system at IP address 127.0.0.1, which is listening on port number 1451 (which is QMB).
  • A Receiver Channel called QMB.TO.QMA, which is used to receive messages (from QMB in this case).

There are corresponding Sender and Receiver Channels defned on QMB. Note that the pair of Sender and Receiver Channel names on both QMA and QMB must be the same, so the Receiver Channel on QMB must have the same name as the Sender Channel on QMA.

MQ Listener, Channel and Queue Management

To start a Channel

There are four ways of starting a Channel, the choice depending on your site standards. The following examples are for the Sender Channel QMA.TO.QMB, defined on QMA. Note that we always start a Sender Channel, never a Receiver Channel.

  • By issuing the RUNMQCHL MQ command on QMA: Using the RUNMQCHL MQ command, shown next (which can be stored in a file called SYSA_QMA_START_RUNMQCHL_AB.BAT):

    start runmqchl -m QMA -c QMA.TO.QMB

  • By issuing the START CHANNEL MQSC command on QMA: We can use the START CHANNEL MQSC command on QMA as follows:

    : start channel(QMA.TO.QMB)

  • By defining and starting a Service: A Service is used to define the user programs that are to be started and stopped when a Queue Manager is started and stopped. We can start a Channel by defning an MQ Service for it and then starting the Service. So let's defne a Service called STSYSACH, to start the Sender Channel QMA.TO.QMB defned on Queue Manager QMA. The Service calls the program RUNMQCHL, and we know what the parameters for this program are, because we covered them in the frst method. These values are passed to the command through the STARTARG parameter. The DEFINE SERVICE MQSC command is:

    : DEFINE SERVICE(STSYSACH) +
    CONTROL(QMGR) +
    SERVTYPE(COMMAND) +
    STARTARG('-c QMA.TO.QMB -m QMA') +
    STARTCMD(RUNMQCHL)

    Once the service has been defined, we need to start it, using the START SERVICE MQSC command on QMA:

    : start service(STSYSACH)

  • As part of the Transmission Queue definition: We may not want the Channel to be continuously active, and only want it activated when there is a message to process. In this situation, we can initiate a Channel start when the Transmission Queue is used.

To display a list of Channels

We use the DISPLAY CHANNEL MQSC command to list out the Channels for a Queue Manager:

: dis channel(*)

To display the status of a Channel

To check that a Channel is running, issue the DISPLAY CHSTATUS MQSC command:

: dis chstatus(*)
AMQ8417: Display Channel Status details.
CHANNEL(QMA.TO.QMB) CHLTYPE(SDR)
CONNAME(127.0.0.1(1450)) CURRENT
RQMNAME( ) STATUS(RUNNING)
SUBSTATE( ) XMITQ(QMB.XMITQ)

We are looking for a status of RUNNING

To stop a Channel

As an example, let's say we want to stop the Sender Channel QMB.TO.QMA defined on QMB. We can stop it by using the STOP CHANNEL MQSC command:

$ runmqsc QMB
: stop channel(QMB.TO.QMA)
1 : stop channel(QMB.TO.QMA)
AMQ8019: Stop WebSphere MQ Channel accepted.

If we now display the Channels, we can see that the QMB.TO.QMA Channel has a status of STOPPED.

: dis chstatus(*)
2 : dis chstatus(*)

AMQ8417: Display Channel Status details.
CHANNEL(QMA.TO.QMB) CHLTYPE(RCVR)
CONNAME(127.0.0.1) CURRENT
RQMNAME(QMA) STATUS(RUNNING)
SUBSTATE(RECEIVE)
AMQ8417: Display Channel Status details.
CHANNEL(QMB.TO.QMA) CHLTYPE(SDR)
CONNAME(127.0.0.1 (1450)) CURRENT
RQMNAME(QMA) STATUS(STOPPED)
SUBSTATE( ) XMITQ(QMA.XMITQ)

MQ Queue management

This section looks at how we manage WebSphere MQ queues once a Queue Manager has been created and started. We cover defining, displaying, and deleting Local Queues.

To defne a Local Queue

The following table shows all the possible parameters, and their possible values, which can be specifed when creating a Local Queue. The example following the table shows a typical defnition of a Local Queue

DEFINE QLOCAL(<qname>)

CMDSCOPE(' '/<qmgr-name>/*)

DEFBIND(OPEN/NOTFIXED)

QDPMAXEV(ENABLED/ ENABLED)

QSGDISP(QMGR/ COPY/

GROUP/SHARED)

DEFSOPT(SHARED/EXCL)

QSVCIEV(NONE/HIGH/ OK)

LIKE (<qlocalname>)

DISTL(NO/YES)

QSVCINT(999,999,999/ <int>)

NOREPLACE/ REPLACE

GET(ENABLED/DISABLED)

RETINTVL(999,999,999/ <int>)

DEFPRTY(0/<int>)

NOHARDENBO/HARDENBO

SCOPE(QMGR/CELL)

DEFPSIST(NO/YES)

INDXTYPE(NONE/MSGID/

CORRELID/GROUPID/

MSGTOKEN)

SHARE/NOSHARE

DESCR('<desc>')

INITQ(' '/<string>)

STATQ(QMGR/OFF/ON)

PUT(ENABLED/ DISABLED)

MAXDEPTH(5000/<int>)

STGCLASS('DEFAULT'/ <string>)

ACCTQ(QMGR/ON/ OFF)

MAXMSGL(4,194,304/<int>)

TRIGDATA(' '/<string>)

BOQNAME(' '/<string>)

MONQ(QMGR/OFF/LOW/

MEDIUM/HIGH)

TRIGDPTH(1/<int>)

BOTHRESH(0/<int>)

MSGDLVSQ(PRIORITY/FIFO)

NOTRIGGER/TRIGGER

CFSTRUCT(' '/<name>)

NPMCLASS(NORMAL/ HIGH)

TRIGMPRI(0/<int>)

CLUSNL(' '/<name>)

PROCESS(' '/<string>)

TRIGTYPE(FIRST/EVERY/

DEPTH/NONE)

CLUSTER(' '/<name>)

QDEPTHHI(80/<int>)

USAGE(NORMAL/XMITQ)

CLWLPRTY(0/<int>)

QDEPTHLO(40/<int>)

 

CLWLRANK(0/<int>)

QDPHIEV(DISABLED/ ENABLED)

 

CLWLUSEQ(QMGR/ ANY/

LOCAL)

QDPLOEV(DISABLED/ ENABLED)

 

The content of the text file that we pipe into the MQSC environment to create a Local Queue is shown next. This example shows how to create the Administration Queue for Q Capture:

DEFINE QLOCAL(CAPA.ADMINQ) +
REPLACE +
DESCR('LOCAL DEFN OF ADMINQ FOR CAPA CAPTURE') +
PUT(ENABLED) +
GET(ENABLED) +
SHARE +
DEFSOPT(SHARED) +
DEFPSIST(YES)

Two attributes for which we are accepting the default values are:

  • MAXMSGL: The Maximum Message Length. This value specifes the maximum message length of messages (in bytes) allowed in queues for this Queue Manager. The default value is 4,194,304 bytes.
  • MAXDEPTH: The Maximum queue depth. This value specifes the maximum number of messages allowed in the Queue. The default value is 5,000.

The definition of a Dead Letter Queue follows this format, as it is just a Local Queue. So to define a Dead Letter Queue for Queue Manager QMA we would code:

DEFINE QLOCAL(DEAD.LETTER.QUEUE.QMA) +
REPLACE +
DESCR('LOCAL DEAD LETTER QUEUE QMA') +
PUT(ENABLED) +
GET(ENABLED) +
SHARE +
DEFSOPT(SHARED) +
DEFPSIST(YES)

Remember that the name of the Dead Letter Queue is the name that was specified when the Queue Manager was created, see the Create/start/stop a Queue Manager section.

To display the attributes of a Local Queue

We use the DIS QLOCAL MQSC command to display the attributes of a Local Queue. If we want to display the value of one attribute, then we just have to append that attribute name to the command. For example, to check the current depth of the Receive Queue issue the DIS QLOCAL (DIS QL) MQSC command with the CURDEPTH option:

: dis ql(CAPA.TO.APPB.RECVQ) CURDEPTH

To check if there are any messages in the Dead Letter Queue issue the following MQSC command:

: dis ql(DEAD.LETTER.QUEUE.QMA) CURDEPTH

To alter the attributes of a Queue

There are two ways of altering the attributes of a Queue, which are shown next:

  • Using the ALTER QLOCAL (ALTER QL) MQSC command: The following command changes a single attribute, that of the maximum message length (MAXMSGL) – all the other attributes remain the same:

    : alter ql(CAPA.ADMINQ) MAXMSGL(10000)

  • Using the DEFINE QLOCAL MQSC command with the REPLACE option:

    : define ql(CAPA.ADMINQ) MAXMSGL(10000) replace

To empty a Local Queue

To delete messages from a queue (clear it down), use the CLEAR QLOCAL MQSC command:

: clear qlocal(CAPA.ADMINQ)

To delete a Local Queue

To delete a Local Queue, use the DELETE QLOCAL MQSC command:

: delete qlocal(CAPA.ADMINQ) purge

One of the options of the command is NOPURGE (default) / PURGE. This option specifes whether any existing committed messages on the queue are to be purged for the command to work: NOPURGE means that the deletion is not to go ahead if there are any committed messages on the queue. PURGE means that the deletion is to go ahead even if there are committed messages in the queue, and these messages are also to be purged.

To define a Remote Queue

An example of creating a Remote Queue on QMA is shown next. Pipe the following text into the MQSC environment on QMA:

DEFINE QREMOTE (CAPA.TO.APPB.SENDQ.REMOTE) +
REPLACE +
DESCR('REMOTE DEFN OF SEND QUEUE FROM CAPA TO APPB') +
PUT(ENABLED) +
XMITQ(QMB.XMITQ) +
RNAME(CAPA.TO.APPB.RECVQ) +
RQMNAME(QMB) +
DEFPSIST(YES)

The parameters for the command are discussed in the core values fgure in the MQ Queues section.

To define a Model Queue

An example of creating a Model Queue on QMA is shown next. Pipe the following text into the MQSC environment on QMA:

DEFINE QMODEL (IBMQREP.SPILL.MODELQ) +
REPLACE +
DEFSOPT(SHARED) +
MAXDEPTH(500000) +
MSGDLVSQ(FIFO) +
DEFTYPE(PERMDYN)

To define a Transmission Queue

A Transmission Queue is a form of Local Queue which has its USAGE attribute set to MQUS_TRANSMISSION rather than MQUS_NORMAL.

When sending messages to a Remote Queue defned in a local WebSphere MQ server, we need to create a Sender Channel and a Transmission Queue. A Transmission Queue can be defned to start automatically. The following definition would be defned on QMA and is a Transmission Queue to Queue Manager QMB:

DEFINE QLOCAL(QMB.XMITQ) +
REPLACE +
DESCR('TRANSMISSION QUEUE TO QMB') +
USAGE(XMITQ) +
PUT(ENABLED) +
GET(ENABLED) +
TRIGGER +
TRIGTYPE(FIRST) +
TRIGDATA(QMA.TO.QMB) +
INITQ(SYSTEM.CHANNEL.INITQ)

To start the Sender Channel automatically when a message shows up the Transmission Queue, triggering control of the Transmission Queue must be confgured properly—this is what the last four lines of code achieve.

To list Queues

We use the DISPLAY QLOCAL and DISPLAY QREMOTE MQSC commands to list out the Local and Remote Queues for a Queue Manager:

: dis ql(*)
: dis qr(*)

Summary

In this article, we illustrated the management of: the MQ Listeners, WebSphere MQ channels and WebSphere MQ queues.

In the next article WebSphere MQ Sample Programs, we will cover the MQ sample programs, Dead Letter Queue handler and MQ error messages.


Further resources on this subject:


IBM InfoSphere Replication Server and Data Event Publisher Design, implement, and monitor a successful Q replication and Event Publishing project with IBM InfoSphere Replication Server and Data Event Publisher using this book and eBook
Published: August 2010
eBook Price: $35.99
Book Price: $59.99
See more
Select your format and quantity:

About the Author :


Pav Kumar-Chatterjee

Pav Kumar-Chatterjee (Eur Ing, CENG, MBCS) has been involved in DB2 support on the mainframe platform since 1991, and on midrange platforms since 2000. Before joining IBM he worked as a database administrator in the airline industry as well as various financial institutions in the UK and Europe. He has held various positions during his time at IBM, including in the Software Business Services team and the global BetaWorks organization. His current position is a DB2 technical specialist in the Software Business. He was involved with Information Integrator (the forerunner of Replication Server) since its inception, and has helped numerous customers design and implement Q replication solutions, as well as speaking about Q replication at various conferences.
Pav Kumar-Chatterjee has co-authored the “DB2 pureXML Cookbook” (978-0-13-815047-1) published in August 2009.

Books From Packt


IBM Lotus Notes 8.5 User Guide
IBM Lotus Notes 8.5 User Guide

Application Development for IBM WebSphere Process Server 7 and Enterprise Service Bus 7
Application Development for IBM WebSphere Process Server 7 and Enterprise Service Bus 7

IBM Cognos 8 Report Studio Cookbook
IBM Cognos 8 Report Studio Cookbook

IBM Lotus Notes and Domino 8.5.1
IBM Lotus Notes and Domino 8.5.1

IBM WebSphere eXtreme Scale 6
IBM WebSphere eXtreme Scale 6

WebSphere Application Server 7.0 Administration Guide
WebSphere Application Server 7.0 Administration Guide

IBM Cognos 8 Planning
IBM Cognos 8 Planning

Domino 7 Lotus Notes Application Development
Domino 7 Lotus Notes Application Development


Code Download and Errata
Packt Anytime, Anywhere
Register Books
Print Upgrades
eBook Downloads
Video Support
Contact Us
Awards Voting Nominations Previous Winners
Judges Open Source CMS Hall Of Fame CMS Most Promising Open Source Project Open Source E-Commerce Applications Open Source JavaScript Library Open Source Graphics Software
Resources
Open Source CMS Hall Of Fame CMS Most Promising Open Source Project Open Source E-Commerce Applications Open Source JavaScript Library Open Source Graphics Software