MB_MQ_Support-1

After reading this article, you will not be a WebSphere MQ expert, but you will have brought your knowledge of MQ to a level where you can have a sensible conversation with your site's MQ administrator about what the Q replication requirements are.

An introduction to MQ

In a nutshell, WebSphere MQ is an assured delivery mechanism, which consists of queues managed by Queue Managers. We can put messages onto, and retrieve messages from queues, and the movement of messages between queues is facilitated by components called Channels and Transmission Queues.

There are a number of fundamental points that we need to know about WebSphere MQ:

• All objects in WebSphere MQ are case sensitive
• We cannot read messages from a Remote Queue (only from a Local Queue)
• We can only put a message onto a Local Queue (not a Remote Queue)

It does not matter at this stage if you do not understand the above points, all will become clear in the following sections.

There are some standards regarding WebSphere MQ object names:

• Queue names, processes and Queue Manager names can have a maximum length of 48 characters
• Channel names can have a maximum length of 20 characters
• The following characters are allowed in names: A-Z,a-z,0-9, and . / _ % symbols
• There is no implied structure in a name — dots are there for readability

Now let's move on to look at MQ queues in a little more detail.

MQ queues

MQ queues can be thought of as conduits to transport messages between Queue Managers.

There are four different types of MQ queues and one related object. The four different types of queues are: Local Queue (QL), Remote Queue (QR), Transmission Queue (TQ), and Dead Letter Queue, and the related object is a Channel (CH).

One of the fundamental processes of WebSphere MQ is the ability to move messages between Queue Managers. Let's take a high-level look at how messages are moved, as shown in the following diagram:

When the application Appl1 wants to send a message to application Appl2, it opens a queue - the local Queue Manager (QM1) determines if it is a Local Queue or a Remote Queue. When Appl1 issues an MQPUTcommand to put a message onto the queue, then if the queue is local, the Queue Manager puts the message directly onto that queue. If the queue is a Remote Queue, then the Queue Manager puts the message onto a Transmission Queue.

The Transmission Queue sends the message using the Sender Channel on QM1 to the Receiver Channel on the remote Queue Manager (QM2). The Receiver Channel puts the message onto a Local Queue on QM2. Appl2 issues a MQGET command to retrieve the message from this queue.

Now let's move on to look at the queues used by Q replication and in particular, unidirectional replication, as shown in the following diagram. What we want to show here is the relationship between Remote Queues, Transmission Queues, Channels, and Local Queues. As an example, let's look at the path a message will take from Q Capture on QMA to Q Apply on QMB.

(Move the mouse over the image to enlarge.)

Note that in this diagram the Listeners are not shown.

Q Capture puts the message onto a remotely-defned queue on QMA (the local Queue Manager for Q Capture). This Remote Queue (CAPA.TO.APPB.SENDQ.REMOTE) is effectively a "place holder" and points to a Local Queue (CAPA.TO.APPB.RECVQ) on QMB and specifes the Transmission Queue (QMB.XMITQ) it should use to get there. The Transmission Queue has, as part of its defnition, the Channel (QMA.TO.QMB) to use. The Channel QMA.TO.QMB has, as part of its defnition, the IP address and Listening port number of the remote Queue Manager (note that we do not name the remote Queue Manager in this defnition—it is specifed in the defnition for the Remote Queue).

The defnition for unidirectional Replication Queue Map (circled queue names) is:

SENDQ: CAPA.TO.APPB.SENDQ.REMOTE on the source

RECVQ: CAPA.TO.APPB.RECVQ on the target

ADMINQ: CAPA.ADMINQ.REMOTE on the target

Let's look at the Remote Queue defnition for CAPA.TO.APPB.SENDQ.REMOTE, shown next. On the left-hand side are the defnitions on QMA, which comprise the Remote Queue, the Transmission Queue, and the Channel defnition. The defnitions on QMB are on the right-hand side and comprise the Local Queue and the Receiver Channel.

Let's break down these defnitions to the core values to show the relationship between the different parameters, as shown next:

We defne a Remote Queue by matching up the superscript numbers in the defnitions in the two Queue Managers:

For defnitions on QMA, QMA is the local system and QMB is the remote system.

For defnitions on QMB, QMB is the local system and QMA is the remote system.

1. Remote Queue Manager name
2. Name of the queue on the remote system
3. Transmission Queue name
4. Port number that the remote system is listening on
5. The IP address of the Remote Queue Manager
6. Local Queue Manager name
7. Channel name

Queue names:

• QMB: Decide on the Local Queue name on QMB—CAPA.TO.APPB.RECVQ.
• QMA: Decide on the Remote Queue name on QMB—CAPA.TO.APPB.SENDQ.REMOTE.

Channels:

• QMB: Defne a Receiver Channel on QMB, QMA.TO.QMB—make sure the channel type (CHLTYPE) isRCVR.
• The Channel names on QMA and QMB have to match: QMA.TO.QMB.
• QMA: Defne a Sender Channel, which takes the messages from the Transmission Queue QMB.XMITQand which points to the IP address and Listening port number of QMB. The Sender Channel name must be QMA.TO.QMB.

Let's move on from unidirectional replication to bidirectional replication. The bidirectional queue diagram is shown next, which is a cut-down version of the full diagram of the The WebSphere MQ layer and just shows the queue names and types without the details.

The principles in bidirectional replication are the same as for unidirectional replication. There are two Replication Queue Maps—one going from QMA to QMB (as unidirectional replication) and one going fromQMB to QMA.

MQ queue naming standards

The naming of the WebSphere MQ queues is an important part of Q replication setup. It may be that your site already has a naming standard for MQ queues, but if it does not, then here are some thoughts on the subject (WebSphere MQ naming standards were discussed in the Introduction to MQ section):

Queues are related to Q Capture and Q Apply programs, so it would be useful to have that fact refected in the name of the queues.

• A Q Capture needs a local Restart Queue and we use the name CAPA.RESTARTQ.
• Each Queue Manager can have a Dead Letter Queue. We use the prefx DEAD.LETTER.QUEUE with a suffx of the Queue Manager name giving DEAD.LETTER.QUEUE.QMA.
• Receive Queues are related to Send Queues.
  For every Send Queue, we need a Receive Queue. Our Send Queue names are made up of where they are coming from, Q Capture on QMA (CAPA), and where they are going to, Q Apply on QMB (APPB), and we also want to put in that it is a Send Queue and that it is a remote defnition, so we end up withCAPA.TO.APPB.SENDQ.REMOTE. The corresponding Receive Queue will be calledCAPA.TO.APPB.RECVQ.
• Transmission Queues should refect the names of the "to" Queue Manager.
  Our Transmission Queue on QMA is called QMB.XMITQ, refecting the Queue Manager that it is going to, and that it is a Transmission Queue. Using this naming convention on QMB, the Transmission Queue is called QMA.XMITQ.
• Channels should refect the names of the "from" and "to" Queue Managers.
  Our Sender Channel defnition on QMA is QMA.TO.QMB refecting that it is a channel from QMA to QMBand the Receiver Channel on QMB is also called QMA.TO.QMB. The Receiver Queue on QMA is calledQMB.TO.QMA for a Sender Channel of the same name on QMB.
• A Replication Queue Map defnition requires a local Send Queue, and a remote Receive Queue and a remote Administration Queue.
  The Send Queue is the queue that Q Capture writes to, the Receive Queue is the queue that Q Apply reads from, and the Administration Queue is the queue that Q Apply writes messages back to Q Capture with.

MQ queues required for different scenarios

This section lists the number of Local and Remote Queues and Channels that are needed for each type of replication scenario.

The queues and channels required for unidirectional replication (including replicating to a Stored Procedure) and Event Publishing are shown in the following tables. Note that the queues and channels required for Event Publishing are a subset of those required for unidirectional replication, but creating extra queues and not using them is not a problem.

The queues and channels required for unidirectional (including replicating to a Stored Procedure) are shown in the following table:

QMA (7)	QMB (7)
3 Local Queues: CAPA.ADMINQ CAPA.RESTARTQ DEAD.LETTER.QUEUE.QMA 1 Remote Queue: CAPA.TO.APPB.SENDQ.REMOTE 1 Transmission Queue: QMB.XMITQ 1 Sender Channel: QMA.TO.QMB 1 Receiver Channel: QMB.TO.QMA	2 Local Queues: CAPA.TO.APPB.REVCQ DEAD.LETTER.QUEUE.QMB 1 Remote Queue: CAPA.ADMINQ.REMOTE 1 Transmission Queue: QMA.XMITQ 1 Sender Channel: QMB.TO.QMA 1 Receiver Channel: QMA.TO.QMB 1 Model Queue: IBMQREP.SPILL.MODELQ

The queues required for Event Publishing are shown in the following table:

QMA (7)	QMB (7)
3 Local Queues: CAPA.ADMINQ CAPA.RESTARTQ DEAD.LETTER.QUEUE.QMA 1 Remote Queue: CAPA.TO.APPB.SENDQ.REMOTE 1 Transmission Queue: QMB.XMITQ 1 Sender Channel: QMA.TO.QMB 1 Receiver Channel: QMB.TO.QMA	2 Local Queues: CAPA.TO.APPB.REVCQ DEAD.LETTER.QUEUE.QMB 1 Receiver Channel: QMA.TO.QMB

The queues and channels required for bidirectional/P2P two-way replication are shown in the following table:

QMA (10)	QMB (10)
4 Local Queues: CAPA.ADMINQ CAPA.RESTARTQ DEAD.LETTER.QUEUE.QMA CAPB.TO.APPA.RECVQ 2 Remote Queues: CAPA.TO.APPB.SENDQ.REMOTE CAPB.ADMINQ.REMOTE 1 Transmission Queue: QMB.XMITQ 1 Sender Channel: QMA.TO.QMB 1 Receiver Channel: QMB.TO.QMA 1 Model Queue: IBMQREP.SPILL.MODELQ	4 Local Queues: CAPB.ADMINQ CAPB.RESTARTQ DEAD.LETTER.QUEUE.QMB CAPA.TO.APPB.RECVQ 2 Remote Queues: CAPB.TO.APPA.SENDQ.REMOTE CAPA.ADMINQ.REMOTE 1 Transmission Queue: QMA.XMITQ 1 Sender Channel: QMB.TO.QMA 1 Receiver Channel: QMA.TO.QMB 1 Model Queue: IBMQREP.SPILL.MODELQ

The queues and channels required for P2P three-way replication are shown in the following table:

QMA (16)	QMB (16)	QMC (16)
5 Local Queues: CAPA.ADMINQ CAPA.RESTARTQ DEAD.LETTER.QUEUE. QMA CAPB.TO.APPA.RECVQ CAPC.TO.APPA.RECVQ 4 Remote Queues: CAPA.TO.APPB. SENDQ.REMOTE CAPB.ADMINQ.REMOTE CAPA.TO.APPC. SENDQ.REMOTE CAPC.ADMINQ.REMOTE 2 Transmission Queues: QMB.XMITQ QMC.XMITQ 2 Sender Channels: QMA.TO.QMC QMA.TO.QMB 2 Receiver Channels: QMC.TO.QMA QMB.TO.QMA 1 Model Queue: IBMQREP.SPILL. MODELQ	5 Local Queues: CAPB.ADMINQ CAPB.RESTARTQ DEAD.LETTER.QUEUE. QMB CAPA.TO.APPB.RECVQ CAPC.TO.APPB.RECVQ 4 Remote Queues: CAPB.TO.APPA. SENDQ.REMOTE CAPA.ADMINQ.REMOTE CAPB.TO.APPC. SENDQ.REMOTE CAPC.ADMINQ.REMOTE 2 Transmission Queues: QMA.XMITQ QMC.XMITQ 2 Sender Channels: QMB.TO.QMA QMB.TO.QMC 2 Receiver Channels: QMA.TO.QMB QMC.TO.QMB 1 Model Queue: IBMQREP.SPILL. MODELQ	5 Local Queues: CAPC.ADMINQ CAPC.RESTARTQ DEAD.LETTER. QUEUE.QMC CAPA.TO.APPC.RECVQ CAPB.TO.APPC.RECVQ 4 Remote Queues: CAPC.TO.APPA. SENDQ.REMOTE CAPA.ADMINQ.REMOTE CAPC.TO.APPB. SENDQ.REMOTE CAPB.ADMINQ.REMOTE 2 Transmission Queues: QMA.XMITQ QMB.XMITQ 2 Sender Channels: QMC.TO.QMA QMC.TO.QMB 2 Receiver Channels: QMA.TO.QMC QMB.TO.QMC 1 Model Queue: IBMQREP.SPILL. MODELQ

(For more resources on IBM, see here.)

WebSphere MQ commands

In this section, we look at the WebSphere MQ commands we need to set up and administer the MQ environment. The following table lists the V6 WebSphere MQ commands:

amqccert - Check certificate chains amqmdain - WebSphere MQ services control amqtcert - Transfer certificates crtmqm - Create Queue Manager dltmqm - Delete queue manager dmpmqaut - Dump authority dmpmqlog - Dump log dspmq - Display Queue Managers dspmqaut - Display authority dspmqcsv - Display command server dspmqfls - Display files dspmqrte - WebSphere MQ display route application dspmqtrc - Display formatted trace output dspmqtrn - Display transactions dspmqver - Display version information endmqcsv - End command server endmqlsr - End listener endmqdnm - Stop .NET monitor endmqm - End Queue Manager endmqtrc - End trace mqftapp - Run File Transfer Application GUI

mqftrcv - Receive file on server mqftrcvc - Receive file on client mqftsnd - Send file from server mqftsndc - Send file from client rcdmqimg - Record media image rcrmqobj - Recreate object rsvmqtrn - Resolve transactions runmqchi - Run channel initiator runmqchl - Run channel runmqdlq - Run dead-letter queue handler runmqdnm - Run .NET monitor runmqlsr - Run listener runmqsc - Run MQSC commands runmqtmc - Start client trigger monitor runmqtrm - Start trigger monitor setmqaut - Set or reset authority setmqcrl - Set certificate revocation setmqscp - Set service connection points strmqcfg - Start WebSphere MQ Explorer strmqcsv - Start command server strmqm - Start Queue Manager strmqtrc - Start trace

Only some of these commands are of real interest to us as database administrators! We will go through these relevant commands in the following sections.

Note that it is sometimes desirable to prefx these commands with the operating system START command, which opens a new window for the command to be executed in.

Create/start/stop a Queue Manager

To create a Queue Manager, our userID needs to be part of the mqm group. If we do not have the appropriate authority, then we need to ask our MQ administrator to issue this command.

The command to create a Queue Manager is CRTMQM and there are various parameters available with this command:

crtmqm [-z] [-q] [-c Text] [-d DefXmitQ] [-h MaxHandles]
[-g ApplicationGroup] [-t TrigInt]
[-u DeadQ] [-x MaxUMsgs] [-lp LogPri] [-ls LogSec]
[-lc | -ll] [-lf LogFileSize] [-ld LogPath] QMgrName

The only required parameter is the Queue Manager name (QMgrName), which can be up to 48 characters in length. The optional parameters are:

• -c <text>: Descriptive text (up to 64 characters) for this Queue Manager.
• -d <DefaultTransmissionQueue>: The name of the local Transmission Queue where remote messages are put if a Transmission Queue is not explicitly defned for their destination. There is no default.
• -g <ApplicationGroup>: The name of the group containing members allowed to: run MQI applications, update all IPCC resources, change the contents of some queue manager directories. This option applies only to WebSphere MQ for AIX, Solaris, HP-UX, and Linux. The default value is -g all, which allows unrestricted access. The -g ApplicationGroup value is recorded in the Queue Manager confguration fle,qm.ini. The mqm userID and the user executing the command must belong to the specifed ApplicationGroup.
• -h <MaximumHandleLimit>: (default 256). The maximum number of handles that any one application can have open at the same time. The range is 1 through 999,999,999.
• -lc: Use circular logging. This is the default logging method.
• -ll: Use linear logging.
• -ld <LogPath>: The directory used to hold log fles. On Windows, the default is C:\Program Files\IBM\WebSphere MQ\log (assuming that C is the data drive). On UNIX systems, the default is/var/mqm/log. User ID mqm and group mqm must have full authority on these directories, which occurs automatically if the log fles are in their default locations. If we change the locations of these fles, we must give these authorities manually.
• -lf <LogFilePages>: The log data is held in a series of fles called log fles.
• -lp <LogPrimaryFiles>: The log fles allocated when the Queue Manager is created.
• -ls <LogSecondaryFiles>: The log fles allocated when the primary fles are exhausted.
• -q: Makes this Queue Manager the default Queue Manager.
• -t <IntervalValue>: The trigger time interval in milliseconds for all queues controlled by this Queue Manager. This value specifes the time after receiving a trigger-generating message when triggering is suspended. That is, if the arrival of a message on a queue causes a trigger message to be put on the Initiation Queue, any message arriving on the same queue within the specifed interval does not generate another trigger message.
• -u <DeadLetterQueue>: The name of the Local Queue that is to be used as the Dead Letter Queue. Messages are put on this queue if they cannot be routed to their correct destination. The default is no Dead Letter Queue.
• -x <MaxUMsgs>: The maximum number of uncommitted messages under any one syncpoint. The default value is 10,000 uncommitted messages.
• -z: Suppresses error messages. This fag is used within WebSphere MQ to suppress unwanted error messages. Because using this fag can result in loss of information, do not use it when entering commands through the command line.

The command to create a Queue Manager called QMA with a Dead Letter Queue called DEAD.LETTER.QUEUE.QMA is:

$ crtmqm –u DEAD.LETTER.QUEUE.QMA QMA

You should see something similar to the following on your screen:

WebSphere MQ queue manager created.
Creating or replacing default objects for QMA.
Default objects statistics : 43 created. 0 replaced. 0 failed.
Completing setup.
Setup completed.

Note that this command just tells the Queue Manager that it can use a Dead Letter Queue calledDEAD.LETTER.QUEUE.QMA, which is a Local Queue, and still has to be created, see the MQ Queue management—to defne a Local Queue section. As we have not specifed any logging options, we will be using circular logging.

It is not possible to change the type of logging once the Queue Manager has been defned.

As can be seen from the command description, the CRTMQM command has only a small number of parameters that can be specifed. A Queue Manager has many more attributes, and these are automatically set to default values. These default values can be changed using the ALTER QMGR MQSC command. One such parameter that is assigned when a Queue Manager is created is the SCHINIT attribute, which controls channel initiators and is discussed next.

All Queue Managers need a channel initiator to monitor the system-defined initiation queueSYSTEM.CHANNEL.INITQ, which is the Initiation Queue for all Transmission Queues.

When we start a Queue Manager, a channel initiator is automatically started if the Queue Manager attribute SCHINIT is set to QMGR (which is the default value). Otherwise, it can be started using the START CHINIT MQSC command or the RUNMQCHI command.

Starting a Queue Manager

Before we can use a Queue Manager, we need to start it, using the STRMQM command. The command to start a Queue Manager called QMA is:

$ strmqm QMA

You should see output similar to the following on your screen:

WebSphere MQ queue manager 'QMA' starting.
2108 log records accessed on queue manager 'QMA' during the log
replay phase.
Log replay for queue manager 'QMA' complete.
Transaction manager state recovered for queue manager 'QMA'.
WebSphere MQ queue manager 'QMA' started.

Checking that the Queue Manager is running

To check that a Queue Manager is active, use the DSPMQ MQ command:

$ dspmq

If the Queue Manager is active it should have a status of "Running" as follows:

QMNAME(QMA)     STATUS(Running)

Stopping a Queue Manager

To stop (end) a Queue Manager, use the ENDMQM command. This command has four possible parameters:

• -c: Controlled/quiesced shutdown. This is the default. The queue manager stops, but only after all applications have disconnected. Any calls currently being processed are completed.
• -w: Wait shutdown. This type of shutdown is equivalent to a controlled shutdown except that control is returned to you only after the Queue Manager has stopped. You receive the message Waiting for Queue Manager qmName to end while shutdown progresses.
• -i: Immediate shutdown. The Queue Manager stops after it has completed all the calls currently being processed. Any MQI requests issued after the command has been issued fail. Any incomplete units of work are rolled back when the Queue Manager is next started. Control is returned after the Queue Manager has ended.
• -p: Preemptive shutdown—use this type of shutdown only in exceptional circumstances. For example, when a Queue Manager does not stop as a result of a normal endmqm command. The Queue Manager might stop without waiting for applications to disconnect or for MQI calls to complete.

If we want to suppress error messages, then we just have to add the –z parameter to the command.

An example of the command to stop Queue Manager QMA is shown next:

$ endmqm –i QMA

Deleting a Queue Manager

The command to delete/drop a Queue Manager is DLTMQM, but before we can issue that command we need to stop all the Listeners for the Queue Manager and then stop (end) the Queue Manager.

The following command will stop all the Listeners associated with Queue Manager pointed to by the –mflag (QMA in this example). The –w flag means the command will wait until all the Listeners are stopped before returning control:

$ endmqlsr -w -m QMA

The command to stop (end) the Queue Manager is:

$ endmqm QMA

And fnally the command to delete the Queue Manager is:

$ dltmqm QMA

The Queue Manager confguration fle

The Queue Manager confguration fle is called qm.ini on UNIX systems. On Windows the confguration information is stored in the Windows Registry.

On UNIX, the qm.ini fle is in directory /var/mqm/qmgrs/<QMname>/. This name may not be unique, so the name is generated.

On Windows, we can access the Windows Registry by typing regedit from a windows line command. Then navigate down through:
HKEY_LOCAL_MACHINESOFTWARE|IBM|MQSeries|, as shown in the following screenshot:

MQ logging

The default logging option (circular) can be found in the qm.ini fle on UNIX or the Windows Registry on Windows. The alternative is linear logging (which DB2 people call archive logging). The type of logging is determined at Queue Manager creation time and cannot be altered afterwards.

Issuing commands to a Queue Manager (runmqsc)

Once we have created a Queue Manager, we will want to perform administrative tasks, such as creating queues, among others. To enable us to communicate with our Queue Manager, we use the RUNMQSC MQ command, which opens the MQSC (MQ Script Center) environment.

After entering the MQSC environment, we can issue one of the following MQSC commands: ALTER, CLEAR, DEFINE, DELETE, DISPLAY, END, PING, REFRESH, RESET, RESOLVE, RESUME, START, STOP, or SUSPEND. Each of these commands has it's own options, which are shown in the following table:

ALTER	CLEAR	DEFINE	DELETE	DISPLAY	END	PING
AUTHINFO CHANNEL PROCESS NAMELIST QALIAS QLOCAL QMGR QMODEL QREMOTE SERVICE LISTENER	QLOCAL	AUTHINFO CHANNEL PROCESS NAMELIST QALIAS QLOCAL QMODEL QREMOTE SERVICE LISTENER	AUTHINFO CHANNEL PROCESS NAMELIST QALIAS QLOCAL QMODEL QREMOTE SERVICE LISTENER	AUTHINFO QREMOTE CHANNEL QUEUE CHSTATUS QSTATUS CLUSQMGR CONN PROCESS SERVICE NAMELIST LISTENER QALIAS SVSTATUS QCLUSTER LSSTATUS QLOCAL QMSTATUS QMGR QMODEL		CHANNEL QMGR

REFRESH	RESET	RESOLVE	RESUME	START	STOP	SUSPEND
CLUSTER SECURITY	CHANNEL CLUSTER QMGR	CHANNEL	QMGR CLUSTER QMGR CLUSNL	CHANNEL CHINIT LISTENER SERVICE	CHANNEL LISTENER SERVICE CONN	QMGR CLUSTER QMGR CLUSNL

We can either enter the these MQSC commands interactively or pipe the commands into the MQSCenvironment.

To invoke the MQSC environment for Queue Manager QMA, issue the RUNQMSC command as follows:

$ runmqsc QMA

You should see something similar to the following on your screen:

5724-H72 (C) Copyright IBM Corp. 1994, 2004. ALL RIGHTS RESERVED.
Starting MQSC for queue manager QMA.

And then enter the command we want. For example, to defne a Local Queue called CAPA.ADMINQ, we would enter:

DEFINE QLOCAL(CAPA.ADMINQ) REPLACE PUT(ENABLED) 
GET(ENABLED) SHARE DEFSOPT(SHARED) DEFPSIST(YES)
      1 : DEFINE QLOCAL(CAPA.ADMINQ) REPLACE PUT(ENABLED)
GET(ENABLED) SHARE DEFSOPT(SHARED) DEFPSIST(YES)
AMQ8006: WebSphere MQ queue created.
end
      2 : end
One MQSC command read.
No commands have a syntax error.
All valid MQSC commands were processed.

Note that the end command exits the MQSC environment.

Alternatively, and more usually, we can create a text fle containing the commands to execute, and then pipe this text fle into the MQSC environment:

$ runmqsc QMA < <input-text-file>

For example, to run the commands in the create_qlocal.txt text fle, we would type:

$ runmqsc QMA < create_qlocal.txt

And you'll see this on your screen:

5724-H72 (C) Copyright IBM Corp. 1994, 2004. ALL RIGHTS RESERVED.
Starting MQSC for queue manager QMA.
    1 : DEFINE QLOCAL(CAPA.ADMINQ) +
       : REPLACE +
       : PUT(ENABLED) +
       : GET(ENABLED) +
       : SHARE +
       : DEFSOPT(SHARED) +
       : DEFPSIST(YES)
AMQ8006: WebSphere MQ queue created.
One MQSC command read.
No commands have a syntax error.
All valid MQSC commands were processed.

Comment lines in the MQSC text fle start with an asterisk (*) symbol.
The line continuation character is the plus (+) symbol.

Displaying the attributes of a Queue Manager

To display the attributes of a Queue Manager (say QMA), use the DIS QMGR MQSC command:

$ runmqsc QMA

And you will see:

: dis qmgr
 1 : dis qmgr
AMQ8408: Display Queue Manager details.
  QMNAME(QMA)     ACCTCONO(DISABLED)
  ACCTINT(1800)    ACCTMQI(OFF)
  ACCTQ(OFF)     ACTIVREC(MSG)
  ALTDATE(2007-06-19)    ALTTIME(20.34.04)
  AUTHOREV(DISABLED)    CCSID(1252)
  CHAD(DISABLED)    CHADEV(DISABLED)
  CHADEXIT( )     CHLEV(DISABLED)
  CLWLDATA( )     CLWLEXIT( )
  CLWLLEN(100)     CLWLMRUC(999999999)
  CLWLUSEQ(LOCAL)    CMDLEVEL(600)
  COMMANDQ(SYSTEM.ADMIN.COMMAND.QUEUE)  CRDATE(2007-06-19)
  CRTIME(20.34.04)    DEADQ(DEAD.LETTER.QUEUE.QMA)
  DEFXMITQ( )     DESCR( )
  DISTL(YES)     INHIBTEV(DISABLED)
  IPADDRV(IPV4)    LOCALEV(DISABLED)
  LOGGEREV(DISABLED)    MAXHANDS(256)
  MAXMSGL(4194304)    MAXPRTY(9)
  MAXUMSGS(10000)    MONACLS(QMGR)
  MONCHL(OFF)     MONQ(OFF)
  PERFMEV(DISABLED)    PLATFORM(WINDOWSNT)
  QMID(QMA_2007-06-19_20.34.04)  REMOTEEV(DISABLED)
  REPOS( )     REPOSNL( )
  ROUTEREC(MSG)    SCHINIT(QMGR)
  SCMDSERV(QMGR)    SSLCRLNL( )
  SSLCRYP( )     SSLEV(DISABLED)
  SSLFIPS(NO)
  SSLKEYR(C:\Program Files\IBM\WebSphere MQ\qmgrs\QMA\ssl\key)
  SSLRKEYC(0)     STATACLS(QMGR)
  STATCHL(OFF)     STATINT(1800)
  STATMQI(OFF)     STATQ(OFF)
  STRSTPEV(ENABLED)    SYNCPT
  TRIGINT(999999999)

We can see the Dead Letter Queue name specifed on the CRTMQM command.

Changing the attributes of a Queue Manager

We can change the attributes of a Queue Manager by using the ALTER QMGR MQSC command. As an example, to change the MAXUMSGS value for a Queue Manager, issue the following command:

$ runmqsc QMA
: alter qmgr maxumsgs(10001)
   3 : alter qmgr maxumsgs(10001)
AMQ8005: WebSphere MQ queue manager changed.
: dis qmgr maxumsgs
   4 : dis qmgr maxumsgs
AMQ8408: Display Queue Manager details.
   QMNAME(QMA)   MAXUMSGS(10001)

We can see that the value has been changed from the default value of 10,000 to the value we specifed in the command.

Summary

In this article, we introduced you to WebSphere MQ in terms of how it is used in Q replication to achieve assured delivery of messages once and only once. We covered the MQ queues required for the various scenarios, and gave some guidelines on naming standards. We then went on to cover the MQ commands that we would usually come across, such as creating, starting, and stopping a Queue Manager and issuing commands to a Queue Manager.

In the next article, MQ Listener, Channel and Queue Management, we will take a look at how we manage the WebSphere MQ Listeners, channels and queues.