Websphere MQ系统管理员指南

Websphere MQ系统管理员指南

转至：https://www.cnblogs.com/zhuozige/p/17025880.html

1 AIX平台WebSphere MQ6.0安装

1.1 安装准备

1) 创建MQ组和用户

# mkgroup -A id=400 mqm

# mkuser id=400 pgrp=mqm groups=mqm home=/home/mqm login=false mqm

2) 创建逻辑卷和文件系统

# mklv -y Tlv_mq -t jfs2 $vg_name 2

# mklv -y Tlv_mq_errors -t jfs2 $vg_name 4

# mklv -y Tlv_mq_log -t jfs2 $vg_name 32

# crfs -v jfs2 -d Tlv_mq -m /var/mqm -A no -p rw -a agblksize=4096 -a logsize=128

# crfs -v jfs2 -d Tlv_mq_errors -m /var/mqm/errors -A no -p rw -a agblksize=4096 -a logsize=128

# crfs -v jfs2 -d Tlv_mq_log -m /var/mqm/log -A no -p rw -a agblksize=4096 -a logsize=128

# mount /var/mqm

# mkdir /var/mqm/errors; mkdir /var/mqm/log

# mount /var/mqm/errors; mount /var/mqm/log

1.2 软件安装

1) 脚本安装

# /nfs/software/midware/inst_script/install_mq.sh

2) 手工安装

1．以root用户登录系统，在MQ 6.0的安装介质目录下执行smitty installp命令。

2．选择当前路径为安装路径。

3．选择预览安装，并接受许可证明。在SOFTWARE to install栏目中，按F4键选择需要安装的组件包。我们至少需要安装如下组件包(如果系统中没有安装JDK，还需要安装MQ 6.0中自带的JDK组件包)：

mqm.Client.Bnd

mqm.Server.Bnd

mqm.base

mqm.client

mqm.java

mqm.keyman

mqm.man.en_US.data

mqm.server

4．选择完毕按回车键确认，进行预览安装。

5．回车确认进行预览安装。

6．预览安装结束后，查看Command为OK，并检查是否所有的文件集均被正确安装。

7．重新选择PREVIEW only为no，进行正式安装。

8．回车确认进行正式安装。

9．安装进行中，注意屏幕输出是否存在异常。

10．安装结束后，查看Command为OK，并且所有的组件包均是SUCCESS状态，代表MQ安装正确。

11．进入到MQ的补丁目录，执行smitty update_all命令执行补丁安装。

12．选择预览安装，并接受许可。

13．回车确认进行预览安装。

14．预览安装结束后，查看Command为OK，所有的预览安装文件集均正式安装。

15．之后选择正式安装，将PREVIEW only设置为no。

16．安装进行中，查看安装进度及相应的输出日志。

17．安装结束后，查看Command为OK，并且所有的组件包状态为SUCCESS，代表MQ的补丁安装正常

1.3 版本检查

1) 检查方法一

# dspmqver

Name: WebSphere MQ

Version: 6.0.2.6

CMVC level: p600-206-090217

BuildType: IKAP - (Production)

2) 检查方法二

# lslpp -l |grep mqm.base.runtime |uniq

mqm.base.runtime 6.0.2.6 APPLIED WebSphere MQ Runtime for

2 WebSphere MQ6.0基本概念

2.1 体系结构

WebSphere MQ的体系结构如图所示，它是由许多对象所组成的，主要包括队列管理器、队列、通道、进程定义等对象。队列管理器和DB2数据库中的实例相似，它是有一组MQ进程和一些内存空间所组成的。它实现了应用程序通过MQI调用可以访问MQ的对象。

队列管理器为应用程序提供了排队服务，并管理属于它的队列。它确保：

n 根据接收到的命令更改对象属性。

n 当满足相应条件时，生成特殊事件（如触发器事件或检测事件）。

n 按照发送 MQPUT 调用的应用程序的请求，将消息放入正确的队列。如果不能完成，则将通知应用程序并给出适当的原因码。

所以在使用WebSphere MQ时，首先需要创建一个队列管理器，然后再队列管理器中在创建队列和通道等其他对象。

图，WebSphere MQ的结构

2.2 消息

消息是对使用它的应用程序有意义的以字节为单位的字符串。消息可以用来实现在相同或不同平台上应用程序间的通信。

WebSphere MQ 消息由两个部分：

1) 消息描述符 (MQMD)

消息描述符标识消息，并包含其它控制信息，如消息类型和消息的优先级。

2) 应用程序数据 (Application data)

应用程序数据的内容和结构由使用它的应用程序定义。如图所示：

图，消息结构

消息描述符的格式由 WebSphere MQ 定义。有关消息描述符的完整描述，参看《WebSphere MQApplication Programming Reference》。

2.3 WebSphere MQ对象(objects)

WebSphere MQ对象是一种由WebSphere MQ管理的具有可恢复能力的资源。以下是常用的对象：

n 队列管理器（Queue managers）

n 队列（Queues）

n 通道（Channels）

n 监听（listener）

n 名字列表（Namelists）

n 进程定义（Process definitions）

WebSphere MQ的对象名是大小写敏感的，因此在定义对象时，需要仔细选择好大小写字母。在 WebSphere MQ 中，除最多有 20 个字符的通道之外，名称最多可以有 48 个字符。

2.3.1队列管理器

在WebSphere MQ中队列管理器是基本的软件系统，队列管理器可看成是队列和其他对象的容器。WebSphere MQ中的每一个队列都属于一个队列管理器，队列管理器是为应用程序和WebSphere MQ部件（一些管理工具）提供对队列管理中对象的访问。

一个队列管理器是WebSphere MQ中的一个基本的独立的执行单元。一台机器上可以运行一个或多个队列管理器。

任何需要访问WebSphere MQ提供的服务的应用程序都必须先和队列管理器相连，和应用程序相连的队列管理器对该应用程序而言就叫“本地队列管理器”（Local Queue Manager）,本地队列管理器为程序提供MQI调用的支持。应用程序可以操作、管理本地队列管理器所拥有的各种资源，也可以向其他的队列管理器发送消息。

应用程序通过一种叫做MQI的编程接口向队列管理器申请服务。这些服务包括“放”一条消息到队列或从队列“取”一条消息等一些基本操作。队列管理器还使队列成为可靠的存储消息的地方，它也控制安全性管理，并提供一些特殊的队列功能，比如触发队列。

为了减少应用程序对于它所运行环境的依赖性，WebSphere MQ的应用程序可以和一个它不知道名字的队列管理器相连，这个队列管理器就是一台机器上的缺省队列管理器。如果程序在调用MQCONN时，把队列管理器名参数设置为空，MQCONN将返回与缺省的队列管理器连接的句柄。

队列管理器拥有每个队列。队列管理器负责维护它所拥有的队列，以及将它接收到的所有消息存储到相应的队列。可以由应用程序或队列管理器将消息放入队列，这些是它的正常操作的一部分。

1) 创建队列管理器

请确认/var/mqm,/var/mqm/errors,/var/mqm/log都已mount

# qm_name=QM_A

# crtmqm -lc -lf 16384 -lp 5 -ls 5 -u SYSTEM.DEAD.LETTER.QUEUE $qm_name

-lc, 数据日志采用循环日志方式

-lf, 每个数据日志的大小(单位为4K),本例数据日志大小=16384*4k=64M

-lp, 指定主数据日志的个数

-ls, 指定辅数据日志的个数

-u, 指定死信队列(dead letter queue)

也可以事后在MQSC中通过 ALTER QMGR DEADQ(死信队列名)属性再指定

注：创建队列管理器时可以带-q参数,则本管理器将成为缺省队列管理器

也可以事后修改配置文件mqs.ini中的DefaultQueueManager分节,指定缺省队列管理器。本例中,需要事先确认/var/mqm/log有超过64M*5=300M的空余空间

2) 启动队列管理器

# strmqm $qm_name

3) 停止队列管理器

# endmqm $qm_name; ##等待所有的应用连接断开

# endmqm -c $qm_name; ##提醒应用终止, 与上等效

# endmqm -w $qm_name; ##等待所有应用程序终止和队列管理器终止

# endmqm -i $qm_name; ##允许当前MQI CALL完成,不接受新的MQI CALL,不等待应用连接断开. Immediate shutdown

# endmqm -p $qm_name; ##极端做法, 立即终止(Preemptive shutdown)

4) 删除队列管理器

# dltmqm $qm_name

5) 显示队列管理器状态

# dspmq

6) 显示队列管理器属性

# echo 'dis qmgr all' | runmqsc $qm_name

7) 修改队列管理器属性

# echo 'alter qmgr deadq(ANOTHERDLQ)' | runmqsc $qm_name

在alter qmgr后面,列出要修改的属性和值,这里修改了deadq属性

2.3.2队列

队列是用于存储消息的数据结构,目前WebSphere MQ 版本 5.3 支持超过 2 GB 大小的队列。以下是不同类型的队列:

1) 本地队列（local queue）：

一个本地队列是一个物理上位于本地队列管理器中的队列。本地队列实际上存在与本地系统的内存或磁盘存储中。本地队列管理器控制队列的访问。

应用程序可以“PUT”消息到本地队列，也可以从本地队列“GET”消息，另外程序还可以查询或修改这些队列的某些属性。对队列属性的修改需要相应的权限。

创建命令：DEFINE QL(QNAME) REPLACE

2) 远程队列（remote queue）：

一个远程队列属于一个不与该应用程序直接相连的队列管理器。对这类队列的访问包含有本地队列管理器和远程队列管理器的通信过程。这种通信涉及到通道。

应用程序可对远程队列进行某些操作，比如程序可以向一个远程队列放一条消息，但程序不能从远程队列中取消息。应用程序只能从本地队列读取消息。

应用程序有两种不同的方法可用来访问远程队列。第一种是当程序打开一个远程队列时同时提供队列管理器名和队列名两个参数。这要求程序知道目的队列属于哪个队列管理器。第二种方法是在本地队列管理器上存在一个远程队列的定义，这个定义包含有足够的信息让本地队列管理器确定该远程队列所在的队列管理器。

远程队列定义中的目的队列不一定是远程队列管理器的本地队列，它也可以是一个远程队列定义，如图所示。

应用程序放一条消息到Q1，Q1是本地队列管理器QM1上的一个远程队列定义：Q2 at QM2。QM2是远程队列管理器。Q2是QM2上的一个远程队列定义Q3 at QM3。Q3是QM3的一个本地队列，经过两次传送，消息最终到达Q3这个QM3的本地队列。

有多种原因使这种多跳（Multihop）传送变得有意义。在一个TCP/IP网络内部，所有机器都有IP地址，IP协议本身处理节点间的路由选择。但假设消息需要穿过不同类型的网络，这就需要中间件参加路由选择。在图中，QM2位于一台连接TCP/IP网和SNA网的机器上，只需在QM2上提供一个远程队列定义Q2：Q3 at QM3，就可以实现消息的跨网络传输。

因为对远程队列的访问总是涉及到队列管理器之间的通信，因而我们需要定义其他一些资源，比如通道、传输队列（Transmission queue）。

创建命令：DEFINE QREMOTE(QRNAME) +

RNAME(AAA) RQMNAME(QMGRNAME) +

XMITQ(QTNAME)

注：RNAME是远程队列管理器的本地队列名

RQMNAME是远程队列管理器名

XMITQ是传输队列名

3) 传输队列(Transmission queue)：

传输队列是临时存储目标为远程队列管理器的消息的队列。队列管理器利用传输队列把消息分阶段地发向远程队列。队列管理器和消息移动程序一起负责把数据传送到远程队列。当队列管理器收到把一条消息发往远程队列的要求后，它把消息发送到一个与目的队列管理器相关联的传输队列，传输队列位于本地队列管理器上。目的队列管理器的名称可能由应用程序提供，也可以从远程队列定义中得到。

一个传输队列是两个队列管理器之间的连接的一端。所有直接目的地是同一队列管理器的消息都可放在同一个传输队列上，这些消息的最终目的可能不一样。把消息从一个队列管理器传送到另一个队列管理器只需要一个传输队列，然而也有可能在两个队列管理器之间存在着多个连接以提供不同的传输服务，每个连接都带有一个不同的传输队列。

传输队列是由MCA处理的，MCA负责在队列管理器之间可靠地传送消息。MCA实际上是处理传输队列上消息的MQI应用程序。

创建命令：DEFINE QLOCAL(QTNAME) USAGE(XMITQ) DEFPSIST(YES) +

INITQ(SYSTEM.CHANNEL.INITQ) +

TRIGDATA(SDR_CHANNEL) +

TRIGDPTH(1) +

TRIGTYPE(FIRST) +REPLACE

注：通过设置传输队列，可以做到当有消息时自动启动inactive的发送通道。方法如下

n INITQ属性设为SYSTEM.CHANNEL.INITQ 。

n TRIGDATA属性设为需要启动的发送通道名。

n TRIGDPTH属性设为1。

n TRIGTYPE属性设为FIRST。

4) 死信队列 （Dead letter queue）

死信（未传递的消息）队列是存储无法发送到其正确目的地的消息的队列。有时候会出现队列管理器不能把消息发送到目的地的情况，此时消息将被发送到某个死信队列中。死信队列中的消息常常暗示了系统可能出现的问题。例如当一条消息到达目的队列管理器之后却发现目的队列并不存在。或者目的队列出现不能接收信消息的情况，比如目的队列已经满了，或者它被设置成不允许再加入新的消息。并不是所有的放消息操作的失败都导致消息被放入死信队列，例如，由于本地队列出现错误造成应用程序不能“放”消息，此时MQI调用直接把错误码返回给应用程序。

有些错误只能由死信队列报告，例如，一条消息穿越网络之后到达目的队列管理器，却发现目的队列已满。发现错误的机器不同于最初“放”消息应用程序所在的机器，甚至可能放消息的应用程序已不在运行状态。此时目的队列管理器把这条消息发往它所拥有的死信队列，而不是简单地扔掉该条消息。这样使得这次错误是可见的，也给应用程序提供了一个改正错误的机会。

死信队列是WebSphere MQ面对远端系统错误时的一种解决方案。应用程序可以利用WebSphere MQ提供的其他一些工具来监视并确保消息的可靠传送和接收。

在队列管理器创建时，系统会缺省创建一个名为SYSTEM.DEAD.LETTER.QUEUE死信队列，建议在生产系统上，需要独立创建一个死信队列，而不使用系统缺省的死信队列。

创建命令：死信队列本质上还是本地队列，所以创建命令与本地队列相同。

注：系统虽然会缺省创建死信队列，却没有将死信队列分配给队列管理器。如要死信队列生效还需执行ALTER QMGR DEADQ(SYSTEM.DEAD.LETTER.QUEUE)

5) 别名队列

别名队列实际上是本地队列、远程队列定义或队列名表的另外一个名字。它是一种简单的名字到名字的映射，它允许应用程序用另外一个名字来访问队列。WebSphere MQ已经为应用程序屏蔽了许多底层系统细节，特别是网络通信的细节，而别名队列允许在不修改应用程序的条件下访问其他名字的队列。

创建命令：DEFINE QALIAS(QALIASNAME) TARGQ(QNAME)

注：QALIASNAME是创建的别名队列名

QNAME是需要映射的队列名

2.3.3通道

1) 消息通道（Message channels）

消息通道是一种提供从一个队列管理器到另一个队列管理器的通信路径。消息通道用在分布式的队列把消息从一个队列管理器发送到另一个队列管理器。它们使应用程序屏蔽了底层的通信协议。队列管理器可能存在同种或异种平台之间。为了实现队列管理器之间的通信，您必需在一个队列管理器中定义一个发送消息的通道对象，在另一个队列管理器中定义一个接收消息的通道对象。消息通道是一个单向链接。它通过消息通道代理（message channel agents）把两个队列管理器连接起来。如图所示：

不要和MQI通道（MQI channel）通道混淆。MQI通道有两种类型，分别是服务器连接（server-connection）和客户器连接（client-connection）。

常用的消息通道类型

n 发送通道（Sender）

n 接收通道（Receiver）

n 群集发送通道（Cluster sender）

n 群集接收通道（Cluster receiver）

消息通道用法

如果要在队列管理之间实现消息传输，必须要在两个队列管理器上都要定义相应的通道。发送方和接收方通道的组合形式如下：

由一个系统的发送通道来启动通道，以便它可以发送消息到另一个系统。发送通道向接收通道发送启动请求。发送通道从传输队列发送消息到接收通道。接收通道把消息放到目标队列。

发送通道创建命令：DEFINE CHANNEL(CHLNAME) CHLTYPE(SDR)+

CONNAME(‘100.100.100.215(1418)’) XMITQ(QTNAME) REPLACE

接收通道创建命令：DEFINE CHANNEL(CHLNAME) CHLTYPE(RCVR) REPLACE

注：发送通道名和接收通道名必须一致，否则通道将无法启动。

2) MQI通道

MQI通道是WebSphere MQ 客户端和服务器上的队列管理器的通信的通道。当客户端应用程序发出MQCONN或MQCONNX调用时，才开始建立连接。它是一个双向的通道，可以负责发送和接收，被用作MQI调用的传送和响应。如图所示：

图，MQI通道

一个MQI通道可以把一个客户端连接到单个队列管理器，MQI通道有两种类型，它们定义了双向的MQI通道。

常用的MQI通道类型

n 服务器连接通道（Server-connection channel）

创建命令：DEFINE CHANNEL(SVRCONNNAME) CHLTYPE(SVRCONN) REPLACE

3) 比较消息通道和MQI通道

消息通道与MQI通道之间的区别可以从两方面进行比较：

n MQI通道是双向的：一个MQI通道可以被用来发送请求，也可用来接收响应。而消息通道则只能单向数据通信。如果要在两个队列管理器之间实现双向通信，那么需要定义两个消息通道，一个用来实现数据的发送，另一个用来实现数据的接收。

n MQI通道的通信是同步的：当一个MQI请求从客户端发送服务器端时，WebSphere MQ的客户端在发送下一个请求之间必须要等待来自服务器端的响应。而消息通道，在通道中传输的消息是与时间无关的。大量的消息可以从一个队列管理器发送到另一个队列管理器，发送队列管理器不必等待来自接收队列管理器的任何响应。

2.3.4监听

当使用TCP/IP连接队列管理器时，队列管理器需要向外暴露一个端口。以下命令只使用于WebSphere MQ6.0

1) 创建监听

# echo 'def listener(LN2) trptype(TCP) port(3333) control(QMGR) repl ' |runmqsc $qm_name

2) 启动监听

# echo 'start listener(LN2)' |runmqsc $qm_name

注：仅第一次配置需要启动,因为有CONTROL(QMGR)配置,以后无需再手动启动，监听会随着队列管理器一起启动

3) WebSphere MQ5.3创建启动监听方法

n listener配置方法一:

# cat /etc/services |grep MQSeries

MQSeries 3333/tcp

# cat /etc/inetd.conf |grep MQSeries

MQSeries stream tcp nowait mqm /usr/lpp/mqm/bin/amqcrsta amqcrsta -m QM_A

# refresh -s inetd (第一次配置后启动,以后无需再手动启动)

# lssrc -s inetd -l (查看是否有以下行)

MQSeries /usr/lpp/mqm/bin/amqcrsta amqcrsta -m QM_A active

n listener配置方法二(其实无需配置,直接启动):

# nohup /usr/mqm/bin/runmqlsr -r -m $qm_name -t TCP -p 3333 -i IP地址

4) 检查listener是否活动

# netstat -an |grep LISTEN |grep -w 3333

2.3.5进程

进程定义对象定义响应 WebSphere MQ 队列管理器上的触发器事件启动的应用程序。进程定义属性包含应用程序标识、应用程序类型和特定于应用程序的数据。

创建命令：DEFINE PROCESS(PRONAME) +

DESCR(‘STRING’)+

APPLTYPE(WINDOWSNT)+

APPLICID(‘ runmqchl -c SDR_TEST -m QM_ TEST’)

注：APPLTYPE的值可以是：CICS、UNIX、WINDOWS、WINDOWSNT等

2.4 队列管理器的互连通讯

2.4.1什么是互连通信

对于WebSphere MQ，互连通信意味着把消息从一个队列管理器发送到另一个队列管理器，接收队列管理器可能是在本地机器或远程机器。发送队列管理器和接收队列管理器可以运行在相同的平台，也可以是WebSphere MQ所支持的任何平台，这种环境叫做分布式环境。WebSphere MQ使用DQM(Distributed Queue Management)来实现分布式环境间的通信。

本地队列管理器有时被叫做源队列管理器（source queue manager），而远程队列管理器有时被叫做目标队列管理器（target queue manager），或叫伙伴队列管理器(partner queue manager)。

2.4.2分布式队列的工作原理

下图概括描述了分布队列的组件。

图，分布式队列组件

1. 应用程序使用MQCONN 调用连接到队列管理器。

2. 然后应用程序使用MQOPEN调用打开一个队列，以便可以把消息放到队列中。

3. 队列管理器拥有每个队列的定义。

4.如果消息的目的地是远程系统的队列，那么本地队列管理器将保存消息直到消息被发送到远程队列管理器。这些对于应用程序来说是透明的。

5. 每个队列管理器都有叫做moving service通信软件;通过这个服务,一个队列管理器可以和另一个队列管理器通信。

6. transport service 不依赖于队列管理器，它可以是下列其中的一种，这和平台有关。

n SNA APPC （Systems Network Architecture Advanced Program-to Program Communication）

n TCP/IP (Transmission Control Protocol/Internet Protocol)

n NetBIOS (Network Basic Input/Output System)

n SPX (Sequenced Packet Exchange)

n UDP (User-Datagram Protocol)

分布式组件的定义：

1. WebSphere MQ应用程序可以把消息放到已连接的队列管理器的队列中。

2. 队列管理器可以定义属于自己的队列，也可以定义属于其他队列管理器的队列。这些队列叫做远程队列定义。WebSphere MQ应用程序也可以把消息放置到远程队列中。

3. 如果消息要发送到远程队列管理器中， 本地队列管理器把消息存放到传输队列（transmission queue）中直到它消息发送到远程队列管理器。传输队列是一个特殊的本地队列，在传输队列中的消息一直被保存到被成功地发送到远程队列管理器。

4. 负责消息发送和接收的软件叫消息通道代理（Message Channel Agent (MCA)）。

5. 消息是通过通道（channel）来实现队列管理器之间传输，通道是一条两个队列管理器之间的通信链路，它可以把队列中的所有消息发送到远程队列管理器。

发送消息所需要的组件：

如果要把消息发送到远程队列管理器中，那么本地队列管理器需要定义一个传输队列和一个通道。通道的两端都需要分别定义，例如，发送端或接收端。一个简单通道是由本地队列管理器一个发送通道和远程队列管理器一个接收通道所组成的。这两个定义必须是相同的名字，并共同构成一个通道。

在通道的每一端也被叫做消息通道代理（Message Channel Agent (MCA)）。

每一队列管理器都应该有一个死信队列（dead-letter queue），也叫做不能交付的消息队列（undelivered message queue）。如果消息不能到达目的队列，则将被放置到死信队列。

下图显示了队列管理器、传输队列、通道和MCA之间的关系。

图，发送消息

实现接收消息所需的组件：

如果您的应用程序序要从远程队列管理器返回到本地队列管理器，则需要定义另一个通道，它的传输方向与发送的相反。

图，消息的双向传输

2.4.3分布式队列组件

本节描述分布式队列组件，它们分别是：

n 消息通道

n 消息通道代理

n 传输队列

n 通道启动器和侦听程序

n 通道出口程序

1) 消息通道

关于消息通道的内容，前面的章节已经详细介绍了，不再赘述。

2) 消息通道代理（MCA）

MCA是一个控制消息发送和接收的程序。在通道的每一端都有一个MCA。一个MCA是把消息从传输队列取出来，然后放到通讯链路上。另一个MCA接收消息，并把消息放到远程队列管理器的队列中。

初始化通信链路的MCA叫做呼叫MCA，则另一个MCA叫响应MCA。呼叫MCA可以是发送通道，群集发送通道，服务器通道（完全意义的）或请求器通道。响应MCA可以是关联除群集发送通道之外的任何通道。

3) 传输队列

传输队列是一个特殊的本地队列，它是用来存放将被发送到远程队列管理器的消息的队列。在分布式队列环境中，您需要为每一个发送MCA定义一个传输队列，除非使用了WebSphere MQ 的队列管理器群集。

您在远程队列定义中说明了传输队列名，如果没有说明传输队列名，那么队列管理器将会寻找一个和远程队列管理器相同名字的传输队列。

您可以为队列管理器说明一个缺省传输队列。如果您没有说明传输队列名，并且没有定义和远程队列管理器同名的传输队列，那么将会使用这个缺省传输队列。

4) 通道启动器和侦听程序

通道启动器为发送通道充当了触发监控器，因为传输队列可以被定义为一个触发队列。当一个消息到达传输队列中，并满足了队列的触发条件，一个触发消息将被放到启动队列中，通道启动器将取出触发消息来启动相应的发送通道。如果在服务器通道中定义了对方的连接名，则也能触发服务器通道。这意味着基于消息到达传输队列中，使得通道能够被自动启动。

您需要一个通道侦听程序来启动接收（响应）MCA。为了响应呼叫MCA的启动请求接收MCA被启动；通道侦听程序探测接入网络请求，并启动相应的通道。

图，通道启动器和侦听程序

通道启动器的使用依赖于平台，在z/OS平台，每个队列管理器只能有一个通道启动器；在其他平台，您可以启动多个通道启动器，并对每一个通道启动器指定一个启动队列。通常您只需要一个通道启动器。在WebSphere MQ for AIX, iSeries, HP-UX, Solaris 和 Windows

systems, 和 WebSphere MQ for Compaq Tru64 UNIX, 和 OS/2 Warp平台上可以启动三个通道启动器(缺省值)，但是您可以修改这个值。对于支持群集的平台，当启动队列管理器时，通道启动器也会被自动启动。

通道侦听程序的使用也是和平台相关的。在OS/2和Windows系统中, 您可以使用WebSphere MQ 提供的通道侦听程序，也可以使用操作系统提供的程序。MQ的侦听程序有两种配置和启动方式，一种是通过配置/etc/inetd.conf文件选择使用inetd方式, 也可以使用MQ自身提供的runmqlsr程序，所不同的是：runmqlsr 是一个线程应用，所以比inetd需要更少的内存消耗。因此，采用runmqlsr方式可以提高通道相关的性能。与MQ应用程序类似，MQ的通道侦听程序也有trusted(fastpath)和non trusted(standard)两种运行方式，采用trusted运行方式可以降低CPU和内存消耗。将通道和侦听程序设置为trusted方式运行的方法是通过修改qm.ini配置文件中的MQIBindType参数来实现，即创建或修改qm.ini文件中与Channels相关的小节，例如：

Channels:

MQIBindType=FASTPATH 或者

MQIBindType=STANDARD

其中，FASTPATH表示trusted运行方式，而STANDARD表示非trusted运行方式。

2.4.4互连通讯实例

图，互连通讯实例

这部分描述了把消息从一个队列管理器发送到另一个队列管理器的最简单的方法。

在源队列管理器QM1上需要定义如下对象：

– 传输队列

echo “define ql(transQ) usage(XMITQ) defpsist(YES) replace”|runmqsc QM1

– 发送通道

echo “define chl(QM1.QM2) chltype(SDR) conname(‘100.100.100.215(1418)’) xmitq(transQ) replace”|runmqsc QM1

– 远程队列定义

echo “define qr(REMOTEQ.TESTQ) rname(LOCALQ.TESTQ) rqmname(QM2)

xmitq(transQ) ”|runmqsc QM1

在目标队列管理器上需要定义如下对象：

– 接收通道

echo “define chl(QM1.QM2) chltype(RCVR) REPLACE ”|runmqsc QM2

– 目标队列

echo “define ql(LOCALQ.TESTQ) replace”|runmqsc QM2

启动通道

在发送队列管理器上使用“START CHANNEL”命令启动通道。当您启动发送通道时，接收通道将被自动地启动（由侦听程序启动），消息然后被发送到目标队列。消息通道的两端都必须处在“running”状态，消息才能被发送。由于通道的两端是处在不同的队列管理器中，它们使用了不同的属性。

发送消息

当您把消息放在源队列管理器的远程队列定义中时,这消息将被存放在传输队列中，直到通道被启动。当通道被启动，消息被交付到远程队列管理器的目标队列中。

2.5 触发机制

队列管理器把某种条件叫做触发事件，如果队列被设置为触发类型并且触发事件发生了，队列管理器发送触发消息到一个叫做启动队列的队列中，触发消息被放置到启动队列过程意味着产生了触发事件。

由队列管理器产生的触发消息不是永久性消息，这将减少日志工作量（因此提高性能），并最小化系统重启时间。

处理启动队列中的消息叫做触发监控程序（trigger-monitor application）,他的工作是读取触发消息并根据触发消息的信息作出相应的处理。通常将启动别的应用程序来处理产生触发消息的队列。从队列管理器来看，触发监控程序没有什么特殊的，它只是一个从启动队列读取消息的应用程序。

如果队列被设置成触发形式，你可以选择创建一个进程定义（process-definition）的对象，这个对象包含了一个应用程序名，这个应用程序用来处理引起触发事件的消息。如果创建了进程对象，队列管理器将把应用程序名包含在触发消息中，以便触发监控程序可以使用。进程对象名需要在本地队列的ProcessName的属性中设置。每个队列可以配置一个进程对象，或几个队列可以共享同一个进程对象。

对于所有WebSphere MQ 或WebSphere MQ V5的产品，如果你想触发启动通道，可以不必定义进程对象。

有些平台的WebSphere MQ客户端也支持触发机制，例如：UNIX，Windows,OS/2。

运行在客户端的应用程序和运行在完全WebSphere MQ 环境的应用程序是一样的，只是应用程序链接的库有区别。同时触发监控程序和应用程序必需要都在同一系统中运行。

触发所涉及的对象：

n 应用队列：是一个本地队列，并设置为可触发的。当触发条件满足时，将会产生触发消息。

n 进程定义：一个应用队列可能由一个进程定义对象和它关联。进程定义中包含应用程序的信息。该应用程序负责从应用队列中取出消息。

n 传输队列：如果用触发方式来启动通道，则需一个传输队列。传输队列的TriggerData属性中设置成将被启动的通道名。这将可省略进程的定义。

n 触发事件：它是一种引起队列管理器产生触发消息的事件。

n 触发消息：当触发事件发生时，队列管理器将产生触发消息。触发信息来自于应用队列和与应用队列关联的进程定义，它包含了将要被启动的程序名。

n 启动队列：也是一个本地队列，它是被用来存放触发消息的队列。一个队列管理器可以拥有多个启动队列。一个启动队列可以为多个应用队列服务。

n 触发监控器：是一个持续运行的程序，当一个触发消息到达启动队列时，触发监控器获取触发消息，并利用触发消息中的信息，启动应用程序来处理应用队列中的消息，并把触发消息头发送传递给应用程序，消息头中包括应用队列名。

在所有平台上，有一个特殊的触发监控器叫做通道启动器（channel initator），它的作用是启动通道。

触发类型：

n EVERY:当应用队列中每接收到一个消息时，都将产生触发消息。如果应用程序仅处理一个消息就结束时，可采用这种触发类型。

n FIRST：当应用队列中的消息从0变为1才会发生触发事件。如果当队列中的一个消息到达时启动应用程序，直到处理完所有消息就结束，则采用这种触发类型。

n DEPTH：当应用队列中的消息数目和TriggerDepth的属性值相同时，才会产生触发事件。当一系列请求的恢复都收到时，才启动应用程序，则采用这种触发类型。

当采用depth触发时，产生触发消息后，队列将被修改成非触发方式，如果需要再次触发，将要重新设置成允许触发。

队列的TriggerDepth属性表示引起depth触发事件发生时，队列中的消息数目。

触发的工作原理

为了更好地能理解触发机制，我们举一个触发类型为FIRST的例子。

1. 只有一个本地或远程的应用程序A，往应用队列(Application Queue)中PUT了一条消息。

2. 当队列原来的深度为0时，也即队列为空，这时PUT一条消息到队列中，将会形成触发事件，同时会产生一条触发消息，触发消息中将包含进程定义（Process）中的信息。

3. 队列管理器创建触发消息，并把它PUT到与应用队列相关的启动队列（Initiation Queue）。

4. 触发监控器从启动队列中GET出触发消息。

5. 触发监控器处理触发消息，发出启动应用程序B的命令。

6. 应用程序B打开应用队列，并处理队列中的消息。

注意：

7. 如果队列的触发类型为FIRST或DEPTH，同时有多个应用程序往应用队列发送消息，这种情况下将不会形成触发事件。

8. 如果启动队列设置成不允许PUT消息，那么队列管理器将不产生任何触发消息，直到把启动队列的属性修改成允许PUT消息。

9. 如果通道设置成触发方式，建议触发类型为FIRST或DEPTH。

图 2.1触发消息和应用流程

一般情况下，特别是工作负载不均匀分布时，人们总希望有消息需要处理时，才启动相应的应用程序。

这种自动启动应用程序的机制被称作“触发”（Triggering）。基本原理是：当队列管理器发现有一条消息到达被触发的队列之后，他将产生一条

注1:触发队列的定义

DEFINE QLOCAL (MOTOR.INSURANCE.QUEUE) +

PROCESS (MOTOR.INSURANCE.QUOTE.PROCESS) + //trigger产生时执行的应用

MAXMSGL (2000) +

DEFPSIST (YES) +

INITQ (MOTOR.INS.INIT.QUEUE) + //initiation queue名, 放trigger消息

TRIGGER + //使用trigger

TRIGTYPE (DEPTH) + //指定trigger发生的事件: 超过TRIGDPTH

TRIGDPTH (100)+ //产生trigger的消息数量

TRIGMPRI (5); //计算消息的最低优先级

注2:除创建配置相应队列外，要使用触发机制还需启动runmqtrm进程，用以监听initiation Queue。

Usage: runmqtrm [-m QMgrName] [-q InitQ]

3 WebSphere MQ6.0集群

3.1 群集的概念

如果您熟悉WebSphere MQ和分布式队列，则可以把群集认为是一个队列管理器的网络，或是一个队列管理器的集合，群集中的队列管理器可以是不同的操作系统平台。每当您在群集中创建一个接收通道或定义一个队列时，则系统将自动在其它队列管理器中创建相应的发送通道和远程队列定义。

在群集中您不需要创建传输队列定义，因为WebSphere MQ在每个队列管理器中已经定义了一个传输队列。这个传输队列可以把消息发送到任何队列管理器中。

群集的信息是存放在资源库中。大多数队列管理器只保留它们自己所需要的信息，这些信息包括与它们通信的队列管理器和队列的信息。一些队列管理器包含了群集中所有队列管理器的所有信息。

下图显示了一个叫CLUSTER的群集：

n 在这个群集中有三个队列管理器，QM1,QM2和QM3。

n QM1和QM2存放了群集中队列管理器的信息。它们被叫作完全资源队列管理器。

n QM2和QM3中有几个队列，这些队列能被群集中任何其它队列管理器访问。这些队列被叫作群集队列。

n 每一个队列管理器有一个接收通道的定义，它被叫作群集接收通道。用来接收消息。

n 每一个队列管理器也有一个发送通道的定义，它将和完全资源管理器的群集接收通道相连。这个通道叫做群集发送通道。在下图中,QM1和QM3有群集发送通道连接到TO.QM2，QM2有群集发送通道连接到TO.QM1。

一旦群集接收通道和群集发送通道已经定义好了，通道将自动启动。

图，队列管理器群集

3.2 群集的组件

n 群集资源库（队列）

资源库中存放了群集中队列管理器的信息，包括队列管理器名，以及它们的通道和队列等。这些资源库信息通过一个叫SYSTEM.CLUSTER.COMMAND.QUEUE的队列进行交换，并存放到一个叫SYSTEM.CLUSTER.REPOSITORY.QUEUE的固定队列中。

资源库可能是完全或部分的。每个队列管理器至少要连接到一个拥有完全资源库的队列管理器。

每一个群集队列管理器必须有一个叫SYSTEM.CLUSTER.REPOSITORY.QUEUE的本地队列，在群集中至少一个群集队列管理器含有完全资源库。对于每个群集队列管理器，必须要预定义一个群集-发送通道连接到资源库队列管理器中。资源库队列管理器之间必须要互连，网络状况要比较好，和具有高可用性。普通队列管理器只包含有部分资源库信息。

n 群集-发送通道

群集-发送通道的类型为TYPE(CLUSSDR)，群集队列管理器使用群集-发送通道可以把消息发送到完全资源库队列管理器中。这个通道被用来通知队列管理器状态的改变，例如，队列的删除和创建。它仅和第一个完全资源库队列管理器联系。

n 群集-接收通道

群集-接收通道的类型为TYPE(CLUSRCVR)，群集队列管理器可以使用它接收群集内的消息。每一个群集队列管理器至少需要一个群集-接收通道。

n 群集传输队列

从一个队列管理器发送到其它队列管理器的消息都将被放到SYSTEM.CLUSTER

. TRANSMIT.QUEUE队列中，在每个队列管理器中必须要存在群集传输队列。

3.3 实现负载均衡

当在群集中含有同一队列的多个实例时，WebSphere MQ通过使用负载管理算法把消息发送到最方便的队列管理器中。负载管理算法尽可能地选择本地队列管理器作为目的地。如果在本地队列管理器中没有队列，这个算法将选择最合适的目标。合适的原则是取决于通道状态、队列管理器和队列的可用性。在满足条件的队列管理器之间，这个算法使用了轮循的方法进行选择。从而可以实现负载均衡的功能。

使用群集可以减少系统管理，也可以在群集中的几个队列管理器中创建同名的队列。只有拥有队列的队列管理器才能处理队列中的消息，但应用程序发送消息时不用显示说明队列管理器名。负载管理算法决定了那个队列管理器应该处理消息。

下图中显示了一个群集中定义了多个Q3队列的定义。当在QM1的应用程序放一个消息到Q3时，它不必知道是那个Q3队列将处理消息。

当消息正在传输时，群集中的一个本地队列变得不可用，那么消息将被转发到另一个队列中（但需要以BIND_NOT_FIXED的选项打开队列）。如果其它队列也不可用，这个消息将被放到死信队列中。

如果目标队列管理器不能工作，那么消息将仍然被放在传输队列中，系统将尝试更换消息的路由。这样做并不会影响消息的完整性，但如果出现队列管理器失败并消息处在可疑（in doubt）状态，这个消息将不能更换路由。

图，在群集中一个队列有多个实例

3.4 群集实例

针对上图实例，由四个队列管理器组成一个集群。假设QM1，QM2为完整存储库；QM3，QM4为部分存储库。集群名为MYCLUSTER。

队列管理器名 IP PORT

QM1 192.168.0.1 1411

QM2 192.168.0.2 1412

QM3 192.168.0.3 1413

QM4 192.168.0.4 1414

1) 每个集群推荐配置2个完整资源库，先将QM1，QM2设置为完整资源库

echo “alter qmgr repos(MYCLUSTER)”|runmqsc QM1

echo “alter qmgr repos(MYCLUSTER)”|runmqsc QM2

2) 集群中每个队列管理器只需要创建一个集群发送通道和一个集群接收通道。

集群发送通道的conname属性指向任意一个完整资源库。此例中QM1指向QM2，QM2指向QM1。QM3,QM4可以任意指向一个完整资源库，此例中QM3指向QM2,QM4指向QM1。

n 创建QM1的集群发送通道，集群接收通道，集群队列

echo “define chl(TO.QM2) chltype(CLUSSDR) cluster(MYCLUSTER) conname(‘192.168.0.2（1412）’)”|runmqsc QM1

echo “define chl(TO.QM1) chltype(CLUSRCVR) cluster(MYCLUSTER) conname(‘192,168.0.1(1411)’)”|runmqsc QM1

echo “define ql(Q1) cluster(MYCLUSTER)”|runmqsc QM1

n 创建QM2的集群发送通道，集群接收通道，集群队列

echo “define chl(TO.QM1) chltype(CLUSSDR) cluster(MYCLUSTER) conname(‘192.168.0.1（1411）’)”|runmqsc QM2

echo “define chl(TO.QM2) chltype(CLUSRCVR) cluster(MYCLUSTER) conname(‘192.168.0.2(1412)’)”|runmqsc QM2

echo “define ql(Q1) cluster(MYCLUSTER)”|runmqsc QM2

echo “define ql(Q3) cluster(MYCLUSTER)”|runmqsc QM2

n 创建QM3的集群发送通道，集群接收通道，集群队列

echo “define chl(TO.QM2) chltype(CLUSSDR) cluster(MYCLUSTER) conname(‘192.168.0.2（1412）’)”|runmqsc QM3

echo “define chl(TO.QM3) chltype(CLUSRCVR) cluster(MYCLUSTER) conname(‘192.168.0.3(1413)’)”|runmqsc QM3

n 创建QM4的集群发送通道，集群接收通道，集群队列

echo “define chl(TO.QM2) chltype(CLUSSDR) cluster(MYCLUSTER) conname(‘192.168.0.1（1411）’)”|runmqsc QM4

echo “define chl(TO.QM3) chltype(CLUSRCVR) cluster(MYCLUSTER) conname(‘192.168.0.4(1414)’)”|runmqsc QM4

echo “define ql(Q3) cluster(MYCLUSTER)”|runmqsc QM4

3) 创建队列管理器别名

定义一个空的远程队列作为队列管理器别名。当对方远程队列需要连接集群中的本地队列时，对方远程队列中的队列管理器属性配置这个队列管理器别名而不是队列管理器名。一般情况下队列管理器别名创建在作为网关的队列管理器上。

echo “define qr(ANY.CLUSTER)”|runmqsc QM1

注1：创建通道时，确保conname 属性填写正确，因为除两个手工创建的集群通道外，集群会自动根据conname属性为队列管理器创建与其他集群成员连通的集群通道，所以如果conname有误。自动创建的集群通道也将错误，而修改自动创建的集群通道将非常的麻烦。

注2：与接收通道不同，集群接收通道一定要设置conname属性，否则集群会出现问题。

4) 重启4个队列管理器

5) 集群的验证

登陆队列管理器，查看集群发送，接收通道状态是否running

dis chs(TO.*)

查看集群队列管理器,此例中每个队列管理器都应显示4个集群队列管理器

dis clusqmgr(*)

clusqmgr(QM1) …….

clusqmgr(QM2)……

clusqmgr(QM3)……

clusqmgr(QM4)……

6) 现在Q1，Q3对于整个集群中的队列管理器来说都是可见的。我们可以往QM1队列管理器的Q3队列里PUT消息，尽管QM1上没有Q3队列，但默认情况下消息仍然会平均分发至QM2或QM4的Q3队列中。

3.5 群集管理

您有时需要对群集中的队列管理器进行维护，例如，您可能需要备份队列中的数据，或把补丁应用到系统中。如果队列管理器包含队列，则必须暂停队列管理器。当维护结束后，将继续队列管理器的工作。

n 为暂停队列管理器，可以使用命令SUSPEND QMGR，例如：

SUSPEND QMGR CLUSTER(SALES)

它将临时从群集中移走一个队列管理器，这样将不会有任何消息发送到这个队列管理器。暂停的队列管理器和对象的信息都被保留在资源库中，但是队列管理器被标记为暂停。

n 当维护队列管理器的工作完成后，需要让队列管理器继续工作。通过执行RESUME QMGR则可以实现，例如：

RESUME QMGR CLUSTER(SALES)

RESUME QMGR命令将通知完全资源库，这个队列管理器将又重新可用。完全资源队列管理器散布这个信息到其它队列管理器。

n 在群集中的队列管理器可以执行刷新启动命令。在正常环境下不需要执行刷新命令，

例如：

REFRESH CLUSTER(SALES)

执行刷新命令，将丢弃所有本地的关于群集的信息。

n 如果要从群集中强制除去一个队列管理器，则可以通过RESET CLUSTER命令实现。或一个队列管理器已经被删除，但是定义到群集的群集-接收通道仍然存在，那么您也可以使用RESET CLUSTER命令来快速地清理这些定义信息。

使用RESET CLUSTER命令是删除自定义群集-发送通道的唯一方法。在正常的环境中，您不必运行这个命令。这个命令只能在资源管理器中执行，例如：

RESET CLUSTER(SALES) QMNAME(QM0000) ACTION(FORCEREMOVE) QUEUES(NO)

n 查看群集中队列管理器信息，可以使用命令DISPLAY CLUSQMGR，例如：

DISPLAY CLUSQMGR(*) CLUSTER(SALES)

n 您可以定义群集队列，例如：

DEFINE QLOCAL(0000_1) CLUSTER(SALES)

欲了解更详细的有关群集管理的信息，请参考《Queue Manager Clusters》。

4 WebSphere MQ6.0常用文件与目录说明

1) /var/mqm

MQ根目录

2) /var/mqm/mqs.ini

MQSeries configuration file(公共配置文件), 记录队列管理器的统一配置。详细配置请看“WebSphere MQ6.0常用配置说明.mqs.ini”

3) /var/mqm/errors

MQ产品错误日志，一般记录严重错误，MQ的FDC错误文件存放在此目录。

4) /var/mqm/conv/table/ccsid.tbl

MQ字符转换配置文件。MQ会自动转换消息编码，当遇到无法转换指定编码的情况将会报错。

将/var/mqm/conv/table/ccsid.tbl文件中的

#default 0x1100 500

#default 0x2100 850

注释解开。此时如遇到无法转换编码，将使用默认编码，避免报错。

5) /var/mqm/qmgrs/

MQ队列管理器目录。存放本机所有队列管理器的信息。

6) /var/mqm/qmgrs/队列管理器名/qm.ini

queue manager configurationfile(队列管理器配置文件), 记录每个队列管理器的个性化配置。详细配置请看“WebSphere MQ6.0常用配置说明.qm.ini”

7) /var/mqm/qmgrs/队列管理器名/errors/AMQERR01.LOG

队列管理器错误日志,比较重要,故障排查时的首选查看文件。

8) /usr/mqm

MQ安装目录。

9) /usr/mqm/bin

MQ命令存放目录。

10) /usr/mqm/inc

MQ头文件存放目录。

11) /usr/mqm/samp

MQ辅助程序目录。

5 WebSphere MQ6.0常用配置说明

5.1 mqs.ini公共配置文件

WebSphere MQ 配置文件 mqs.ini 包含和节点上所有队列管理器都相关的信息。它在安装期间自动创建。 WebSphere MQ UNIX 系统版的 mqs.ini 文件在 /var/mqm 目录中。它包含：

• 队列管理器的名称

• 缺省队列管理器的名称

• 和每个文件关联的文件位置

如图显示 WebSphere MQ 配置文件的示例：

#***********************************************************************# #* Module Name: mqs.ini *# #* Type : WebSphere MQ Configuration File *# #* Function : Define WebSphere MQ resources for the node *# #***********************************************************************# AllQueueManagers: #***********************************************************************# #* The path to the qmgrs directory, below which queue manager data *# #* is stored *# #***********************************************************************# DefaultPrefix=/var/mqm LogDefaults: LogPrimaryFiles=3 LogSecondaryFiles=2 LogFilePages=104 LogType=CIRCULAR LogBufferPages=0 LogDefaultPath=/var/mqm/log QueueManager: Name=saturn.queue.manager Prefix=/var/mqm Directory=saturn!queue!manager QueueManager: Name=pluto.queue.manager Prefix=/var/mqm Directory=pluto!queue!manager DefaultQueueManager: Name=saturn.queue.manager

1) DefaultPrefix=directory_name

– 指定队列管理器信息目录(qmgrs)的存储路径

2) DefaultQueueManager:

Name=default_queue_manager

– 指定默认的队列管理器名

3) LogDefaults:

– 所有队列管理器的默认日志信息

LogPrimaryFiles=3|2-254 (Windows)|2-510 (UNIX systems)

– 队列管理器的主日志数量

LogSecondaryFiles=2|1-253 (Windows)|1-509 (UNIX systems)

– 队列管理器的次日志数量

LogFilePages=number

– 日志文件的页数。每页为4KB。AIX默认为1024页。

LogType=CIRCULAR|LINEAR

– 日志类型:循环日志(CIRCULAR);线性日志(LINEAR)。

LogBufferPages=0|0-4096

– 日志缓存的页数。每页为4KB。最小值为18 ，最大值为4096。如指定页数小于18，以18计算。Websphere MQ6.0默认为128(512KB)。

LogDefaultPath=directory_name

– 日志文件存放路径

4) QueueManager:

– 队列管理器信息

Name=queue_manager_name

– 队列管理器名

Prefix=prefix

– 队列管理器存放路径

Directory=name

– 队列管理器对象文件名

5.2 qm.ini 队列管理器配置文件

队列管理器配置文件 qm.ini, 包含和特定队列管理器相关的信息。每个队列管理器都有一个队列管理器配置文件。创建队列管理器时，将自动创建此文件。

qm.ini 文件保存在队列管理器的目录树的根中。例如，队列管理器 QMNAME 的配置文件的路径和名称是： /var/mqm/qmgrs/QMNAME/qm.ini

队列管理器名称最大长达 48 个字符。

如图显示了在 WebSphere MQ UNIX 系统版中队列管理器配置文件的配置属性。

#*******************************************************************# #* Module Name: qm.ini *# #* Type : WebSphere MQ queue manager configuration file *# # Function : Define the configuration of a single queue manager *# #*******************************************************************# ExitPath: ExitsDefaultPath=/var/mqm/exits Service: Name=AuthorizationService EntryPoints=9 ServiceComponent: Service=AuthorizationService Name=MQ.UNIX.auth.service Module=/opt/mqm/bin/amqzfuno.o 1 ComponentDataSize=0 Service: Name=NameService EntryPoints=5 ServiceComponent: Service=NameService Name=MQ.DCE.name.service Module=/opt/mqm/lib/amqzfa 2 ComponentDataSize=0 Log: LogPrimaryFiles=3 LogSecondaryFiles=2 LogFilePages=1024 LogType=CIRCULAR LogBufferPages=0 LogPath=/var/mqm/log/saturn!queue!manager/ XAResourceManager: Name=DB2 Resource Manager Bank SwitchFile=/usr/bin/db2swit XAOpenString=MQBankDB XACloseString= ThreadOfControl=THREAD CHANNELS: MaxChannels = 20 ; Maximum number of Channels allowed. MaxActiveChannels = 100 ; Maximum number of Channels allowed to be ; active at any time. TCP: ; TCP/IP entries. KeepAlive = Yes ; Switch KeepAlive on

1) ExitPath:

– 用户出口程序存放目录

ExitDefaultPath=string

– 32位出口程序存放目录

ExitDefaultPath64=string

– 64位出口程序存放目录

2) Service:

– 服务信息

Name=AuthorizationService|NameService

– 服务名

EntryPoints=number-of-entries

– EntryPoints数

3) ServiceComponent:

– 服务组件信息

Service=service_name

– 服务名。与Service标签中的NAME属性匹配。

Name=component_name

– 服务组件名

Module=module_name

– 组件程序路径。必须是绝对路径。

ComponentDataSize=size

– 组件数据大小

4) Log:

– 队列管理器的日志信息

LogPrimaryFiles=3|2-254 (Windows)|2-510 (UNIX systems)

– 队列管理器的主日志数量

LogSecondaryFiles=2|1-253 (Windows)|1-509 (UNIX systems)

– 队列管理器的次日志数量

LogFilePages=number

– 日志文件的页数。每页为4KB。AIX默认为1024页。

LogType=CIRCULAR|LINEAR

– 日志类型:循环日志(CIRCULAR);线性日志(LINEAR)。

LogBufferPages=0|0-4096

– 日志缓存的页数。每页为4KB。最小值为18 ，最大值为4096。如指定页数小于18，以18计算。Websphere MQ6.0默认为128(512KB)。

LogDefaultPath=directory_name

– 日志文件存放路径

5) CHANNELS:

– 通道信息

MaxChannels=100|number

– 最大通道数

MaxActiveChannels=MaxChannels_value

– 最大活动的通道数。默认与MaxChannels数相同

AdoptNewMCA=NO|SVR|SDR|RCVR|CLUSRCVR|ALL|FASTPATH

– 如果当通道收到启动命令却发现通道已运行时，必须停止旧有的通道进程后，才能启动新的通道进程。AdoptNewMCA属性允许你停止旧有通道进程启动指定类型的通道。一般当网络出现闪断时，发送方通道已停止，而接收通道还处于运行状态。这时如果再启动发送通道，由于状态不一致，通道将无法启动。开启AdoptNewMCA属性后，可以有效解决这一问题。

AdoptNewMCATimeout=60|1 – 3600（秒）

– 启用AdoptNewMCA属性后，新的通道进程尝试停止旧进程。如旧进程没有响应，AdoptNewMCATimeout设置的时间后，旧进程停止。

AdoptNewMCACheck=QM|ADDRESS|NAME|ALL

– AdoptNewMCA检查类型。QM-检查队列管理器名匹配的通道。ADDRESS-检查通讯地址匹配的通道。NAME-检查通道名匹配的通道。ALL-检查三项都匹配的通道。推荐使用ALL。

6) TCP:

KeepAlive=YES|NO

– KeppAlive开关。如果KeepAlive=YES，MQ会检查TCP/IP对端的连接是否可用。如果不可用，关闭通道。

欲了解更详细的有关MQ配置信息，请参考《WebSphere MQ System Administration Guide》。

6 对象管理工具runmqsc(MQSC)的用法

runmqsc中的命令和属性不区分大小写, 但对象本身是区分大小写的,当字符中存在小写字符或小括号时，字串需要用单引号括起来，否则将全部为大写字符。

例:dis qlocal(‘LOCAL.Shop.REQ’)

define listener(LN1) trptype(TCP) conname(’22.188.129.11(1414)’)

runmqsc支持输入/输出的重定向(stdin/stdout)。

6.1 runmqsc使用方法

1) 方法一：进入runmqsc, 然后执行MQSC命令

# runmqsc [ 队列管理器名 ]

不带参数则管理缺省队列管理器, 否则管理指定的队列管理器

2) 方法二：事先将所有MQSC命令编辑进脚本,通过输入重定向, 批量执行MQSC命令

# runmqsc 队列管理器名 < test.mqsc

test.mqsc是MQSC命令的集合,可以事先编辑好(或者通过MS03生成)

n 每行不要超过72个字符

n 行首为星号(*)时, 表示本行为注释行

n 行尾为加号(+)时, 表示续行, 本命令未结束

n 行尾没有加号时, 表示本命令结束, 也可用分号(;)明确表示结束

n MQ自带的范例文本:

/usr/mqm/samp/amqscos0.tst: Definitions of objects used by sample programs

/usr/mqm/samp/amqscic0.tst: Definitions of queues for CICS transactions

3) 方法三：利用管道,不进入runmqsc执行MQSC命令

# echo 'dis qmgr' | runmqsc 队列管理器名

将要执行的MQSC命令做为echo的输出,通过管道将其做为runmqsc的输入

在操作系统使用ksh时,这种方法有利于重复或者修改再执行曾经执行过的命令

eg:查看队列管理器通道当前连接数：

echo " display CONN(*) TYPE(CONN) CONNAME CHANNEL" | mqsc -e -m QM1 -p width = 1000 | grep "CHANNEL(A.QM1.CH1)" | wc -l

4) 退出runmqsc

只有上述的方法一需要退出

输入end 或者输入Ctrl_d

6.2 runmqsc命令

n 定义本地队列

DEFINE QL(QNAME) REPLACE

n 定义别名队列

DEFINE QALIAS(QALIASNAME) TARGQ(QNAME)

n 远程队列定义

DEFINE QREMOTE(QRNAME) +

RNAME(AAA) RQMNAME(QMGRNAME) +

XMITQ(QTNAME)

n 定义模型队列

DEFINE QMODEL(QNAME) DEFTYPE(TEMPDYN)

n 定义本地传输队列

DEFINE QLOCAL(QTNAME) USAGE(XMITQ) DEFPSIST(YES) +

INITQ(SYSTEM.CHANNEL.INITQ)+

PROCESS(PROCESSNAME) REPLACE

n 创建进程定义

DEFINE PROCESS(PRONAME) +

DESCR(‘STRING’)+

APPLTYPE(WINDOWSNT)+

APPLICID(’ runmqchl -c SDR_TEST -m QM_ TEST’)

其中APPLTYPE的值可以是：CICS、UNIX、WINDOWS、WINDOWSNT等

n 创建发送方通道

DEFINE CHANNEL(SDRNAME) CHLTYPE(SDR)+

CONNAME(‘100.100.100.215(1418)’) XMITQ(QTNAME) REPLACE

其中CHLTYPE可以是：SDR、SVR、RCVR、RQSTR、CLNTCONN、SVRCONN、CLUSSDR和CLUSRCVR。

n 创建接收方通道

DEFINE CHANNEL(SDR_ TEST) CHLTYPE(RCVR) REPLACE

n 创建服务器连接通道

DEFINE CHANNEL(SVRCONNNAME) CHLTYPE(SVRCONN) REPLACE

n 显示队列的所有属性

DISPLAY QUEUE(QNAME) [ALL]

n 显示通道的所有属性

DISPLAY CHL(CHLNAME) [ALL]

n 显示队列的所选属性

DISPLAY QUEUE(QNAME) DESCR GET PUT

DISPLAY QUEUE(QNAME)MAXDEPTH CURDEPTH

n 显示队列管理器的所有属性

DISPLAY QMGR [ALL]

n 显示进程定义

DISPLAY PROCESS(PRONAME)

n 更改属性

ALTER QMGR DESCR(‘NEW DESCRIPTION’)

ALTER QLOCAL(QNAME) PUT(DISABLED)

ALTER QALIAS(QNAME) TARGQ(TARGQNAME)

n 删除队列

DELETE QLOCAL(QNAME)

DELETE QREMOTE(QRNAME)

n 清除队列中的所有消息

CLEAR QLOCAL(QNAME)

n 查看队列状态

DISPLAY QSTATUS (QNAME) TYPE (HANDLE)

其中PID属性是正在使用此队列的程序进程号。当操作队列报错‘IN USE’时，可以通过此命令查询占用队列的程序

7 WebSphere MQ实用程序

7.1 WebSphere MQ6.0自带程序

WebSphere MQ6.0自带提供浏览，发送，获取消息等功能的实用程序。源码默认目录为/usr/mqm/samp;执行程序默认目录为/usr/mqm/samp/bin。

1) amqsbcg

浏览指定队列管理器中的队列。

# amqsbcg $queueName $queueManagerName

2) amqsget

从指定队列管理器的本地队列中获取消息。

# amqsget $queueName $queueManagerName

注：

此程序只能获取一定长度的消息，如果消息较长，将会报错无法取出消息。解决方法是修改源码，新增获取消息选项’ MQGMO_ACCEPT_TRUNCATED_MSG’,重新编译。具体操作如下：

n 修改源码

# vi amqsget0.c

gmo.Options = MQGMO_WAIT /* wait for new messages */

+ MQGMO_CONVERT /* convert if necessary */

+ MQGMO_ACCEPT_TRUNCATED_MSG;

n 编译源码

32位:

$ xlc_r -o amqsgetc_32_r amqsget0.c -I/usr/mqm/inc -L/usr/mqm/lib -lmqm_r

64位:

$ xlc_r -q64 -o amqsgetc_64_r amqsget0.c -I/usr/mqm/inc -L/usr/mqm/lib64 -lmqm_r

使用重新编译后的程序就可以取出较大的消息。

3) amqsput

向指定队列管理器的队列放置消息。

# amqsput $queueName $queueManagerName

7.2 MS03

IBM提供的MQ备份实用程序。可以将队列管理器的所有对象导出为MQSC命令的脚本。

n 使用方法

# ./ saveqmgr.aix -m $qm_name -o -f ./`hostname`.$qm_name.mqsc

$qm_name 需要导出的队列管理器名

$ qm_name.mqsc 导出的脚本名

n 恢复方法

# crtmqm -lc -lf 16384 -lp 5 -ls 5 -u SYSTEM.DEAD.LETTER.QUEUE $qm_name

# strmqm

# runmqsc $qm_name < ./`hostname`.$qm_name.mqsc

注:

n 如果队列管理器$qm_name已存在,只是对其中的对象重定义,则不用执行第一步

n 如果是新建队列管理器(crtmqm),需要事先确认/var/mqm/log有超过300M的空余空间

n 也可以按照要求,直接修改*.mqsc中各参数,如(QM名,通道,队列,IP地址等),然后导入到新系统中

8 经验心得

8.1 死信原因查看方法

1) 预览死信内容,过滤DLH行,16进制数据块倒数第三列即错误码.

本例中存在两类错误(0x08DE,0x0119)

# /usr/mqm/samp/bin/amqsbcg QUEUE名 QM名 | grep DLH | more

00000000: 444C 4820 0000 0001 0000 08DE 5342 5333 'DLH ........SBS3'

00000000: 444C 4820 0000 0001 0000 0119 4241 4E43 'DLH ........BANC'

2) 错误码解析

# mqrc 0x08DE

2270 0x000008de MQRC_NO_DESTINATIONS_AVAILABLE

# mqrc 0x0119

No matching return codes

# printf "%d\n" 0x0119

281

## 注:将16进制数0x0119 翻译成10进制数,即281

# cat /usr/mqm/inc/cmqc.h |grep -w 281

define MQFB_BIND_OPEN_CLUSRCVR_DEL 281

注：具体的出错解释可以查看<< WebSphere_MQ_V6.0_Information_Center_Win>>