【IT168 信息化】
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
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中，创建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，将此作为其应用程序构建的一部分。此类自动化会得到更好的一致性、可重复性和更少的失误。
