不可或缺的十種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，請務必說明您選擇它的原因。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/14789789/viewspace-626784/，如需轉載，請註明出處，否則將追究法律責任。