導讀：本文介紹了SupportPac是補充IBM WebSphere MQ產品家族的增件，由於有着數百款增件可供選擇，因而在確定最適合您的選擇時十分困難，故筆者爲我們分析了十種不不可少的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
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，將此作爲其應用程序構建的一部分。此類自動化會得到更好的一致性、可重複性和更少的失誤。
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，請務必說明您選擇它的原因。
