不可或缺的十种 WebSphere MQ SupportPac
SupportPac 是什么？
SupportPac 是补充 IBM WebSphere MQ 产品家族中各种产品的增件。面向 WebSphere MQ 的 SupportPac 包括产品扩展、用户和管理工具、出口程序（exits）等等。许多最新的 WebSphere MQ 特性最初都是以 SupportPac 的形式出现的，再根据用户反馈进行细化和改进，最终整合到基本产品之中。Performance Report SupportPac 会为每个新产品版本重新创建，而其他许多 SupportPac 则会沿用十多年。
简而言之，SupportPac 的存在是为了帮助您充分利用 IBM WebSphere 软件。SupportPac 有数百种之多，在一篇文章中评论所有这些内容是不可能的，因而我将为您介绍我最依赖的几种 SupportPac：
IH03: WebSphere Message Broker V6-Message display, test & performance utilities (RFHutil)
MA01: WebSphere MQ - Q Program
MA0W: WebSphere MQ API Trace
MO71: WebSphere MQ for Windows - GUI Administrator (mqmon)
MO72: MQSC Client for WebSphere MQ
MS81: WebSphere MQ internet pass-thru (MQIPT)
MH03: WebSphere MQ SSL Configuration Checker
MO04: WebSphere MQ SSL Wizard
MS03: WebSphere MQ - Save Queue Manager object definitions using PCFs (saveqmgr)
MS0P: WebSphere MQ Explorer - Configuration and Display Extension Plug-ins
本文结尾处的 参考资料 部分列出了上述（及其他所有）SupportPac 的链接。
请使用下方的注释框为本文添加您喜爱的 SupportPac。
1. IH03: WebSphere Message Broker V6-Message display, test & performance utilities (RFHutil)
此 SupportPac 位于 SupportPacs 页面的 Message Broker 部分中。由于其包含的可执行模块 RFHUtil 更为知名，因而如果您不知道在哪里查找，要找到此实用工具极为困难。
IH03 包含大量程序，但这组程序中最闪耀的明星就是 RFHUtil 和客户端版本的 RFHUtilc。这个 GUI 实用工具学习起来比较困难，但值得为之努力。当然，它也执行一些基本操作，例如将数据从文件移动到队列，或从队列移动到文件。但除此之外，它也具有多个标 签对话框，显示 WebSphere MQ API 中可用的所有参数和选项。需要发送或解析 RFH 报头？检查这里。需要快速测试 pub/sub 的工具。在这里也可以找到。需要设置或检查报告选项？确认选项？Reply-to 字段、绑定选项、持久化、过期？一切都能实现!
对于程序员来说，在需要测试时、在接口另一端的程序不可用时，这种实用工具是极为有用的。通常，需要一组特定的消息选项或需要发送非简单字符串的消息。RFHUtil 可设置这些选项，或使用二进制负荷或其他任何 JMS 格式发送消息。
管理员可以使用 RFHUtil，在诊断网络中异常行为时验证消息报头的内容和负荷。例如，我最近使用 RFHUtil 推断出为什么一个应用程序无法接收到确认消息。应用程序生成的请求消息请求 Confirmation on Delivery，而非 Confirmation on Arrival。由于这些类型的确认需要不同的授权，因而所需的确认消息未能生成。RFHUtil 使我能够在短短几分钟内查明问题所在。
在 IH03 内还有其他许多实用工具可以在队列管理器或代理商生成负载，我将来一定也会考虑尝试使用其他一些工具。
2. MA01: WebSphere MQ - Q program
在 SupportPacs MA01 乏味的一行摘要背后，隐藏着多种顶级的 “厨房器具”。许多不知内情的人在读到 “这个 SupportPac 包含一个简单的管道程序 (Q)，它接收来自一个源的消息，并输出给目标” 这句话时，都会打上一个哈欠，却没有想到 Q 可以切片、切丁、切丝、切碎、削皮、研磨、榨汁，或者切条。
Q 的强大力量源于其管道命令程序的设计。（《星际迷航》的拥护者们主张 Q 的力量源于 Q 连续体，请这些人在这里采纳我的意见）。也许您还不熟悉管道程序的概念，其概念就是在一个 “管道” 中连接两个或多个程序，第一个程序的输出作为下一个程序的输入。在一个管道中连接两个或三个简单的程序，您就可以建立有用的程序，如果采用其他方法，将需 要大量编码工作。
例如，您可将任何程序的输出传送到 Q 中，创建 MQ 消息，将消息发送到远程队列管理器，再使用另外一个 Q 实例将消息转回一个文件。但与需要完整文件的文件传输程序不同，管道方法可在文件中的各行被写下时接收这些行。例如，一个生成日志文件的程序可通过管道与 Q 连接，使日志记录实时移入远程服务器。有了管道方法，功能只受您的想象力的限制。
但即便您不需要管道功能，Q 也有其他很多优势。基本的命令行选项可将消息转储为多种格式，按需使用破坏性读取或浏览。Message GET 选项支持按照特定的消息 ID 或关联 ID 进行选择，在删除有害消息或扫描查找测试数据集中是否如期生成特定消息时，这是十分方便的。我们经常会遇到跨两个队列映射消息的需要。这十分简单：只要指 定多个输出队列，将每个传入消息传递给各输出队列即可。–h 选项作为过滤器，支持按任意随机字符串进行消息选择。您是否希望成批生成测试消息？Q 也能为您实现这种功能。
3. MA0W: WebSphere MQ API Trace
如果您认为 WebSphere MQ 的调优和故障排除就像巫术，那么 SupportPac MA0W 就是您进入巫师学校的邀请函。MA0W 与 MQ Trace 极为接近，但提供了更多有用的选项和人类可读的输出。
调试中的一大挑战就是应用程序和 WebSphere MQ API 之间往往存在多层系统代码。例如，一个 Java? EE 服务器提供许多与应用程序控制之外的 WebSphere MQ 交互的功能。尽管服务器公开了影响行为的配置，但实际代码不可用，因而有时必须设法进行推论，而不是直观的检查。MA0W 为您显示每个 API 调用，附带上下文状态，从而使您能够清晰地理解代码。
我最近一次使用 MA0W 是设法推断出我所测试的一组有害消息为什么未被重新排队。有害消息就是出于某些原因无法被处理的消息，应用程序在同步点读取了这样的消息之后，又会将其恢 复到队列。队列中的下一个 GET 将检索到相同的消息。为了避免无限循环，IBM 的 JMS 类会检查消息的恢复计数以及输入队列的恢复阈值和恢复队列属性。只要一个恢复计数超出队列的恢复阈值，JMS 类就会为恢复队列重新排队。这会消除有害消息，使应用程序继续处理队列中的其他消息。
由于有害消息处理内置于 JMS 类中，因而没有代码能够检查应用程序在何时未能如期执行。我对一组有害消息进行测试时，我注意到再有害消息堆叠在一起时，恢复队列的深度增加了，但在停止 测试程序时，所有消息都回到了输入队列。这绝不是我所期待的，我没有执行任何会导致消息最终进入中断队列的操作。
在使用 MA0W 跟踪 API 调用后，一切都明确了。在正常处理中，有害消息极为稀有。通常情况下，在每条有害消息之后都有一条完全有效的消息在等待处理。但我的测试数据集完全由有害 消息组成。API 跟踪表明，有害消息在同步点重新排队，并未被提交。工作单元随后扩展为包含下一条消息，那也是在同步点读取的。操作就这样继续下去，直至所有消息都回滚到 输入队列。得到了这样的信息之后，我在测试集的末尾添加了一条良好的消息。这条良好的信息终于被提交给程序，随后调用了 COMMIT，使所有有害消息都进入恢复队列。
在我的轶事集中，我提到了应用程序 “意料之外的行为”，而当时我并未真正理解系统的工作方式。在 MA0W 展示了 JMS 类所使用的 API 调用后，我才意识到所看到的行为都是正常和意料之中的。
这些年来，我多次使用 MA0W 成功诊断了多种平台上的一些难题。由于它能截取队列管理器本身内的 API 调用，因而 MA0W 与应用程序所用的编程语言无关，实际上也与应用程序是本地的还是远程连接的也没有关系。在其众多选项中，对于忙碌、共享的队列管理器来说，最有价值的莫过 于跟踪特定队列或特定进程的能力。强烈推荐您将 MA0W 加入您的 WebSphere MQ 工具箱。
4. MO71: WebSphere MQ for Windows - GUI Administrator (mqmon)
这个 SupportPac 也称为 MO71，可执行名称为 mqmon，这是一种用于 WebSphere MQ 的 Windows? GUI 管理工具。由于采用了 C 编译代码，因而小、轻、快。要运行 mqmon，只需将其解压到一个文件夹中，再双击可执行文件即可。这将使您立即能够访问任意本地队列管理器，如果安装了 WebSphere MQ 客户端，还可以访问任意远程队列管理器。
关于 mqmon，我认为最有用的就是它能为每个函数打开一个专用的新窗口。尽管它有可能打开过多的窗口，使您的桌面一片混乱，但我发现 WebSphere MQ Explorer 的单任务范例过于局限。如果设置了 WebSphere MQ Explorer for Workbench 模式，即可打开多个窗口，但每个窗口都是一个完整版本的 WebSphere MQ Explorer。利用 mqmon，可以打开仅显示一个队列的一个窗口，也可以仅显示队列的一部分。此外，在我使用一个窗口设置触发发送队列时.也可以打开另一个通道状态窗口。 在 mqmon 中，显示对象列表的窗口中的每个对象显示为一行，列可自定义，表示对象属性。双击任意对象都能向下钻取到该对象的细节，通常有多个与可用对象类型相关的选 项。若您获得了恰当的授权，单击任意值即可轻松更改该值。
当然，mqmon 在特性方面毫不懈怠。任何带有可设置属性或状态的对象在 mqmon 中都有相应的对话框。如果您偏爱命令行，mqmon 也有一个对话框，可直接输入 runmqsc 命令。mqmon 有一个网络视图，显示所有队列管理器的状态概览，还有一个轻量级的监控平台。您甚至可以实现一个 HTTP 侦听器并连接到 mqmon，使用浏览器执行查询和管理任务。
我使用 mqmon 的一个用途就是在遇到无法连接的非 Java 应用程序时测试 SSL 配置。尽管 Java 应用程序，如 WebSphere MQ Explorer 使用 Java keystore，但其他平台使用的是 Key Database 格式的 keystore。使用 mqmon，我就能够使用与应用程序所用相同的 keystore 文件测试 SSL 连接。这使我能够隔离 keystore，验证问题的起因，并排除问题。
MO71 还有其他一些未在 WebSphere MQ Explorer 中出现的特性，例如将一个文件载入队列或将一个队列载入文件的能力，请下载一份拷贝，亲身体验这些特性。
5. MO72: MQSC Client for WebSphere MQ
这个 SupportPac 的说明也是轻描淡写。其说明只有短短三句话，如下：
MQSC Client for WebSphere MQ 允许使用 MQSC 命令，可直接连接到队列管理器，也可通过客户端连接连接到队列管理器。它还提供了多种格式化选项，用于显示命令的结果。也可用于显示或修改客户端通道定义表。在研讨会上讨论这个 SupportPac 时，许多人询问为什么不使用 runmqsc 实现相同的功能。让我们再看看这三句话的说明，来回答这个问题。
首先，可以使用客户端连接在队列管理器上执行脚本命令。这允许通过单独一个位置在整个 WebSphere MQ 网络上运行脚本操作。
例如，我使用 MO72 实现遵从性报告。首先编写一个脚本，遍历一组队列管理器，使用 MO72 收集队列管理器的安全性设置的细节，并将其与目标基准进行比较。随后，脚本大约每周一次地通过电子邮件发送一份遵从性报告，使我能够了解网络上的哪些队列 管理器存在需要关注的配置问题。
我使用相同的框架编写了可在整个网络中实现的脚本，寻找特定 CONNAME 的所有实例，或执行自动监测任务，如故障转移到灾难恢复站点。
但支持此类自动化的不仅仅是使用客户端连接的能力。SupportPac 说明中第二句话提到了输出的 “多种格式化选项”。内置 runmqsc 工具的输出以人类可读为目标，以两列的格式打印，每个对象占用多行。使用脚本解析这样的输出需要大量字符串操作。例如，尝试识别 CONNAME 中带有 “localhost” 的通道就要求脚本从各行提取属性，搜索 CONNAME 属性，并对通道名称属性的每个实例执行控制中断处理。
另一方面，MO71 可生成将每个对象的所有属性显示在一行中的输出。同样的处理现可简化为使用 grep 识别 CONNAME 中为 “localhost” 的所有通道，随后从剩余的行中提取通道名称。MO72 的格式化功能使脚本的编写更加轻松、运行更加迅速。
SupportPac 说明的最后一句话几乎是以事后诸葛的方式提到，MO72 可用于生成客户端通道定义表（CCDT）。生成 CCDT 的教科书方法是使用 runmqsc，在正在运行的队列管理器上定义多个 CLNTCONN 通道，随后分发所得到的 AMQCHL.TAB 文件。大多数人不知道，这种方法不会在所得到的文件内进行任何 “垃圾收集” 处理。删除一个条目时，会在文件内留下一个空洞。这或许可以重用，但永远不会被压缩。因而，使用这种管理方式时，CCDT 文件会不断增大。MO71 能够在每次运行时从零开始生成一个新文件。结果使您总是能够获得最小的 CCDT 文件，仅包含您需要的那组定义。
更引人注目的 是，MO72 不需要运行中的队列管理器生成 CCDT 文件。我过去参与过的一个监测项目曾经使用一些 CGI 脚本和一个 Apache Web 服务器构建 Web 页面，提供可用队列管理器的列表。当管理员选择感兴趣的队列管理器，并单击 “提交” 按钮时，CGI 脚本会按需生成一个 CCDT 文件，并将其下载到该管理员的浏览器中。
当然，您可轻松通过手动驾驭 MO72，也可以使用简单的 shell 脚本。由于 CCDT 是一种编译成果，因而应将源定义包含到项目的变更管理系统之中。据我所知，有一家公司采用了这种方法，他们使用 ant 脚本生成 CCDT，将此作为其应用程序构建的一部分。此类自动化会得到更好的一致性、可重复性和更少的失误。
6. MS81: WebSphere MQ internet pass-thru (MQIPT)
MQIPT 中的 “IPT” 代表 “互联网直通”。这个 SupportPac 在 DMZ 中为 WebSphere MQ 通道提供了一个控制点。一个 MQIPT 实例可管理来自多个外部业务合作伙伴的连接，并将其发送到任意数量的内部队列管理器。每个连接路径都是独立管理、独立控制的。
MQIPT 还可使穿越防火墙更为轻松，它能提供 HTTP 或 HTTPS 内的 WebSpher MQ 通道隧道协议。通常，两家业务合作伙伴各自在其 DMZ 中设置一个 MQIPT 节点，这样就有一个 MQIPT 节点队位于两个队列管理器之间，两个防火墙位于中央。队列管理器仅看正常的 WebSphere MQ 通道，防火墙仅看到 HTTP 或 HTTPS 流量。
我倾向于在 DMZ 中使用 MQIPT，而不是设立完整的队列管理器。理由就是 MQIPT 不会将任何数据排队到磁盘中，因而在出现通道故障时，DMZ 中不会出现数据堆积的现象。作为 WebSphere MQ 管理员，我也十分欣赏在连接请求抵达队列管理器之前启用或禁用外部访问权限的能力。同样的结果也可通过关闭防火墙上的端口来实现，但那需要向另外一个独立 的团队发出申请。通过 MQIPT，MQ 管理员即可直接管理该访问。
在 MQIPT 参与 SSL 连接时，它会向用户编写的退出程序提供一些证书详情。MQIPT 的更大优势在于它能比 WebSphere MQ 认证更多字段，因而，举例来说，如果您需要检查颁发机构的标识名，即可在 MQIPT 退出程序中实现。
MQIPT 是一种杰出的工具，可帮助保护和控制 WebSphere MQ 网络上的外部连接。请务必注意，它能增强您在队列管理器上执行的保护工作 —— 但不是取代。
7. MH03: WebSphere MQ SSL Configuration Checker
这个 SupportPac 将检查一个队列管理器的 SSL 配置设置，也可以选择为客户端进行检查，并报告所发现的任何问题。无需复杂的安装，只需将独立可执行文件拖放到队列管理器所在主机上，再运行即可。程序已 为 AIX?、HP-UX、Linux?、Solaris? 和 Windows 编译。
程序发现问题时，将打印一份详尽的报告，其中通常包含关于问题的简短说明、一个提供问题具体描述的 “建议” 部分、可行解决方法建议。
由于 MH03 是一个独立的可执行文件，因而设置和运行十分轻松。MH03 是我最经常使用的一种 SupportPac，而原因之一就是我依靠它进行远程支持。在现场时，我通常要求客户手动执行 SSL 验证，以便更好地理解所有组件的交互方式。但在通过电话提供支持时，重点往往在于解决问题的速度。MH03 能够达到与手动验证完全相同的效果，但速度更快，也不会有任何遗漏。如果您正在 WebSphere MQ 网络中使用 SSL（如今几乎没有人不这样做），那么您就需要 MH03。
8. MO04: WebSphere MQ SSL Wizard
MO04 SSL Wizard 是我 “最常用” 的 SupportPac 之一，而实际上使用的次数也并非很多。近来，我使用它的方法就是将它介绍给刚刚开始学习 WebSphere MQ SSL 的新手，使他们能够从中学习经验。
MO04 是一种基于 Java 的 GUI，能指导您完成收集通过支持 SSL 的通道连接两个队列管理器（或一个客户端和一个队列管理器）的需求的寻访过程。收集到 SSL 连接双方的详细信息后，SSL Wizard 就会生成一个极为全面流程，包括叙述性说明和必要的命令。命令包括队列管理器名称、通道名称和证书细节等数据的实际值，旨在按原样运行。
它所生成的输出对于理解流程和解答如下问题大有裨益，例如：我是否要导出或提取证书？我要提出的惟一的警告就是：它所生成的部分命令包含语法错误。但该程序的输出在其他方面极为有用和完善，完全可以抵消这种微不足道的瑕疵。
9. MS03: WebSphere MQ - Save Queue Manager object definitions using PCFs (saveqmgr)
一直以来，我最常用的 SupportPac 都是 MS03，通常简称为 saveqmgr。提到备份队列管理器，存在两种学派。有些人倾向于备份包含队列管理器配置的文件系统，而其他一些人则备份关于配置的元数据。我属于第二组。
在文件系统级备份 WebSphere MQ 时，备份包含当时队列管理器上存在的所有消息。在恢复队列管理器时，所有这些消息都会进入队列。除非上游和下游的所有相关程序与数据库都恢复到同一个时间 点，否则这样的恢复会将系统置于不可知的状态，必须调整到一个已知同步点，才能避免出现重复或者遗漏的事务。
这就假设队列管理器可首先恢复，但这是没有保证的。许多企业都在队列管理器运行时进行文件系统备份。结果就是队列文件的备份与日志文件的备份存在些许的不同步现象，可能会有一个或多个文件被破坏。
出于这些原因，我更倾向于备份队列管理器元数据。其中包括对象定义、授权配置文件、SLL keystore、ini 文件和任何退出目录的内容。saveqmgr 程序可为所有版本的 WebSphere MQ 捕捉队列管理器对象定义。对于版本 6.0 及更高版本，saveqmgr 也能捕捉授权配置文件。此后，若有必要恢复队列管理器，可以重新创建一个空的队列管理器，因而无需协调那些无意中随队列管理器一起恢复的数日乃至数周前的 陈旧信息。
与 MO72 相似，saveqmgr 也具有一个我十分常用的客户端版本。当然，这个版本就是 saveqmgrc。我已经看到了许多使用 saveqmgr 在本地捕捉队列管理器配置数据的案例。但对于在磁盘或服务器崩溃后有用的数据，必须存储在另外一台服务器上。我热爱脚本和自动化，因而我的解决方法就是将 saveqmgrc 设置在中央服务器上（可以是 MO72 所在的服务器），使用脚本遍历所有队列管理器，收集对象定义和授权。
通 常情况下，我将输出文件存储在这个中央服务器上，使用树形结构，为每个队列管理器使用一个独立的目录。这种做法的优势之一就是使之成为平面文件数据库，易 于通过简单的 UNIX? find 命令或某些轻量级脚本搜索。这就使您更容易解答 “这个队列将在何时消失？” 这样的问题。
10. MS0P: WebSphere MQ Explorer - Configuration and Display Extension Plug-ins
事件消息是 WebSphere MQ 故障排除中的高度机密之一。在需要调试授权问题时，我会启用授权事件，重建错误。几年前，我会使用 C 头文件的副本和我信任的十六进制计算器，逐个字段地解析事件消息。当然，这是一项冗长的工作。但事件消息能告诉我生成错误的用户 ID、失败的 API 调用、API 调用的目标对象以及所使用的选项。通过一条事件消息诊断授权问题的能力使手动解析十六进制字段的麻烦显得微不足道。
至少在 MS0P 发布之前，都是如此。MS0P 将解析授权或其他任何类型的事件消息，将其解析为人类可读的文本。多亏这个 SupportPac，我的十六进制计算器终于圆满退役。我也变得如此懒惰。我甚至不确定是否还记得如何手动解析事件消息。
即便这个 SupportPac 只能完成这项任务，也值得下载。而实际上，事情还不仅如此。这个插件也支持跟踪路由功能，可以告诉您消息经过了哪些队列管理器。此外还能以图形的格式显示队列活动。
这个工具包中的另外一个插件提供了执行 WebSphere MQ 服务器的远程管理的能力。该插件可管理 Windows、UNIX 和 Linux 系统，可以启动或停止队列管理器，并执行其他通常被视为 “仅能通过命令行执行” 的任务。
第三个插件能够将队列管理器对象定义保存为逗号分隔值（CSV）格式。这使对象定义能够被 Microsoft Excel 处理，也可轻松载入数据库。
最后，该 SupportPac 包含两个极为有用的实用工具程序。mqidcode 实用工具可将十进制或十六进制数值转换为人类可读的内容。例如，您可能拥有一份跟踪记录的输出，需要了解 GET 操作是否制定了 SYNCPOINT。将 Open Options 字段的数值传递给 mqidcode 即可获得答案，无需使用 C 头文件和计算器。另外一个实用工具是 qtune，用于公开队列缓冲区设置，使您能够查询和设置它们。在大容量环境中，队列管理器必须调优为最优性能，因此通常需要更改队列缓冲区的默认设置。 缓冲区被调优之后，就能够通过查询它来验证调优效果或捕捉备份中的配置，这十分有帮助。但至今为止，尚无查询实际设置的简便方法。除了简化查询之 外，qtune 还可简化更改值的过程。
结束语
我希望这份关于我最喜爱的 SupportPac 的指南能鼓励您访问 SupportPac 网站，试用一些新工具。SupportPac 有数百种之多，没有任何一篇文章能够全面涵盖所有这些内容，也不可能有任何两个人的偏爱列表完全相同。我是否忽略了您喜爱的 SupportPac？请使用下面的评论表单，推荐您认为最出色的 SupportPac，请务必说明您选择它的原因。
?
