轉自：http://blog.csdn.net/liumm0000/article/details/7543471

物件(objects)

WebSphereMQ物件是一種由WebSphereMQ管理的具有可恢復能力的資源。

佇列管理器（Queue managers）

佇列（Queues）

名字列表（Namelists）

分發列表（Distribution lists）

程式定義（Process definitions）

通道（Channels）

儲存類（Storage classes）

這些物件在異種平臺上都是統一的。對於系統管理員來說，操縱物件的命令都是可用的。這些命令格式，對於不同平臺是有區別的。當你建立佇列管理器時，會自動地建立預設物件。這些預設物件可以幫助您來定義所需的物件。

每一個物件都有一個名字，以便透過命令和MQI呼叫可以引用它。通常在這些物件型別中的每一種物件的名字必須唯一。例如，一個佇列和一個程式的名字可以相同，但是不可以有兩個相同名字的佇列。這意味著一個本地佇列名不能和模板佇列、遠端佇列或別名佇列相同。但是也會有些特殊情況。另外在互連的佇列管理器網路中，佇列管理器名必須唯一。

WebSphereMQ的物件名是大小寫敏感的，因此在定義物件時，需要仔細選擇好大小寫字母。在 WebSphere MQ 中，除最多有 20 個字元的通道之外，名稱最多可以有 48 個字元。

訊息

訊息的型別

WebSphereMQ定義了四種基本型別的訊息。應用程式可以定義其他型別的訊息。四種基本型別是：

1.請求訊息 Request message

請求訊息需要應答。從客戶端發往伺服器的查詢和更新資訊往往是一條請求訊息。請求訊息中應該包含回覆訊息的路由資訊，即回覆訊息發往什麼地方。

2. 回覆訊息 Reply message

回覆訊息是對請求訊息的回應。請求訊息中的資訊決定了回應訊息的目的地。處理請求和回應的應用程式控制著訊息間的關聯，這種關聯和佇列管理器沒有關係。訊息自身帶有足夠的資訊供應用程式實現這種關聯。

3.報文訊息 Datagram message

資料包訊息是不需要回復的訊息，報文訊息只是一次單向的資訊傳送。

4.報告訊息 Report message。

報告訊息用於對一些系統故障的響應。有些報告訊息是由應用程式建立的，有些報告訊息是由佇列管理器建立的。後一種情況是由於遠端佇列已經滿或者遠端佇列不存在引起訊息不能正確傳送。最初傳送者條訊息的應用程式不能檢測到這種錯誤，只有等遠端佇列管理器建立了這樣一條報告訊息併發往本地佇列管理器之後，應用程式才能作相應的處理。

佇列管理器把報告訊息也用於其他目的，比如報告一些事件。訊息可能有一個失效時間限制。如果一條訊息在失效時間過後還沒有被某個應用程式處理，該條訊息將被佇列管理器從系統中清除。當佇列管理器清除一條失效訊息之後，它將建立一條報告訊息，這條報告訊息的目的地址由失效訊息提供。

報告訊息的另一個用途是確保訊息的到達。應用程式可以要求它們所傳送的訊息到達目的地後，他們收到一條報告訊息，這叫做接收確認（Confirmation of arrival）。與此相類似，應用程式也可以要求當另外一個程式取走這條訊息時它們收到一條報告訊息，這被叫做交付確認（Confirmation of delivery）。這兩種情況，都是由佇列管理器建立報告訊息，並把報告訊息傳送到適當地目的地。

另外還一類特殊的訊息叫觸發訊息。觸發訊息是由佇列管理器建立的一類特殊訊息。WebSphere MQ的佇列管理器提供了一種當滿足某一條件時，自動觸發應用程式的機制，而觸發訊息是觸發機制的重要組成部分。

應用程式也可以定義新的訊息型別。佇列管理器不能解釋這些型別，應用程式設定的訊息型別由一個範圍。這些型別值可用來區分不同型別的應用程式在同一個輸入佇列中放入的訊息。

訊息長度

最大訊息長度為 100 MB（其中 1 MB 等於 1 048 576 位元組），預設最大訊息長度是 4 MB。實際上，訊息長度受以下方面的影響：

接收佇列定義的最大訊息長度
佇列管理器定義的最大訊息長度
傳輸佇列定義的最大訊息長度
傳送或接收應用程式定義的最大訊息長度
儲存訊息的可用空間

所以有時可能需要由多個訊息組成的資訊才能滿足應用程式的要求。

應用程式如何傳送和接收訊息？

應用程式使用 MQI 呼叫來實現傳送和接收訊息。

例如，要將訊息放入佇列，應用程式：

透過發出 MQI MQOPEN 呼叫開啟所需的佇列
發出 MQI MQPUT 呼叫以將訊息放入佇列

另一個應用程式可以透過發出MQI MQGET 呼叫，從同一佇列取出訊息

佇列

佇列的型別

按建立方法分類

預定義佇列由管理員使用相應的 MQSC 或 PCF 命令建立。 預定義佇列是永久的；它們的存在與應用程式是否實用它們無關，並且 WebSphere MQ 重新啟動後繼續存在。
動態佇列在應用程式發出設定模型佇列名的MQOPEN呼叫時建立的。被建立的佇列是基於一個模板佇列。您可以使用 MQSC 命令 DEFINE QMODEL 建立模板佇列。動態佇列繼承了模板佇列的屬性。模板佇列有一個屬性可以說明動態佇列是永久的還是臨時的。永久佇列在應用程式和佇列管理器重新啟動後繼續存在；臨時佇列在重新啟動後消失。

按功能分類

1. 本地佇列（local queue）：

一個本地佇列是一個物理上位於本地佇列管理器中的佇列。本地佇列實際上存在與本地系統的記憶體或磁碟儲存終。本地佇列管理器控制佇列的訪問。

應用程式可以“PUT”訊息到本地佇列，也可以從本地佇列“GET”訊息，另外程式還可以查詢或修改這些佇列的某些屬性。對佇列屬性的修改需要相應的許可權。

2. 遠端佇列（remote queue）：

一個遠端佇列屬於一個不與該應用程式直接相連的佇列管理器。對這類佇列的訪問包含有本地佇列管理器和遠端佇列管理器的通訊過程。這種通訊涉及到通道。

應用程式可對遠端佇列進行某些操作，比如程式可以向一個遠端佇列放一條訊息，但程式不能從遠端佇列中去訊息。應用程式只能從本地佇列讀取訊息。

應用程式有兩種不同的方法可用來訪問遠端佇列。第一種是當程式開啟一個遠端佇列時同時提供佇列管理器名和佇列名兩個引數。這要求程式知道目的佇列屬於哪個佇列管理器。第二種方法是在本地佇列管理器上存在一個遠端佇列的定義，這個定義包含有足夠的資訊讓本地佇列管理器確定該遠端佇列所在的佇列管理器。

遠端佇列定義中的目的佇列不一定是遠端佇列管理器的本地佇列，它也可以是一個遠端佇列定義

應用程式放一條訊息到Q1，Q1是本地佇列管理器QM1上的一個遠端佇列定義：Q2at 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）。

3. 傳輸佇列(Transmission queue)：

傳輸佇列是臨時儲存目標為遠端佇列管理器的訊息的佇列。佇列管理器利用傳輸佇列把訊息分階段地發向遠端佇列。佇列管理器和訊息移動程式一起負責把資料傳送到遠端佇列。當佇列管理器收到把一條訊息發往遠端佇列的要求後，它把訊息傳送到一個與目的佇列管理器相關聯的傳輸佇列，傳輸佇列位於本地佇列管理器上。目的佇列管理器的名稱可能由應用程式提供，也可以從遠端佇列定義中得到。

一個傳輸佇列是兩個佇列管理器之間的連線的一端。所有直接目的地是同一佇列管理器的訊息都可放在同一個傳輸佇列上，這些訊息的最終目的可能不一樣。把訊息從一個佇列管理器傳送到另一個佇列管理器只需要一個傳輸佇列，然而也有可能在兩個佇列管理器之間存在著多個連線以提供不同的傳輸服務，每個連線都帶有一個不同的傳輸佇列。

傳輸佇列是由MCA處理的，MCA負責在佇列管理器之間可靠地傳送訊息。MCA實際上是處理傳輸佇列上訊息的MQI應用程式。

4. 動態佇列和模板佇列：

除了有固定定義的佇列之外，WebSphere MQ還為程式在它們執行時提供了動態地建立佇列的能力。例如,一個應用程式作為某種服務的客戶，它可能建立一個動態佇列，並通知伺服器把對服務要求的響應傳送到該動態佇列。當然，這種情況也可以使用具有永久定義的佇列。為了簡化在建立動態佇列時所必需設定的許多引數，動態佇列總是基於模板佇列被建立的，模板佇列定義了動態佇列的所有屬性。當應用程式試圖開啟一個模板佇列時，WebSphere MQ就建立一個動態佇列。WebSphere MQ為應用提供了系統模板佇列。

動態佇列也可以分成兩種，它們的生存週期和故障恢復特性不同。在建立臨時動態佇列（Temorary dynamic queue）的應用程式關閉時，這些佇列將被刪除，佇列上的訊息將丟失。這類動態佇列不支援訊息的永續性。如果佇列管理器發生故障重新啟動，臨時動態佇列也不會被恢復。另一種動態佇列是持久動態佇列（Permanent dynamic queue）。只有當一個應用程式關閉持久動態佇列時定義刪除選項，持久動態佇列才會被刪除。刪除持久動態佇列的程式不一定是建立持久動態佇列的程式，持久動態佇列在佇列管理器重啟後會被恢復，並且支援具有永續性的訊息。

5. 啟動佇列

啟動佇列是在觸發中使用的佇列。如果佇列管理器將使用觸發，則必須至少為此佇列管理器定義一個啟動佇列。佇列管理器在觸發器事件發生時將觸發器訊息放入啟動佇列。觸發器事件是由佇列管理器檢測的條件的邏輯組合。例如，當佇列上的訊息數達到預定義深度時，可能會生成觸發器事件。此事件使佇列管理器將觸發器訊息放入指定的啟動佇列。此觸發器訊息由觸發器監視器（即監視啟動佇列的特殊應用程式）檢索。然後觸發器監視器啟動在觸發器訊息中指定的應用程式。

6. 群集傳輸佇列

每個在群集中的佇列管理器有一個稱為 SYSTEM.CLUSTER.TRANSMIT.QUEUE 的群集傳輸佇列。當您定義佇列管理器時，按預設情況建立此佇列的定義。作為群集一部分的佇列管理器可以將群集傳輸佇列上的訊息傳送到在同一群集中的任何其它佇列管理器。在路由解析期間，群集傳輸佇列優先於預設傳輸佇列。當佇列管理器是群集的一部分時，預設操作是使用 SYSTEM.CLUSTER.TRANSMIT.QUEUE，除非當目標佇列管理器不是此群集的一部分。

7. 死信佇列（Dead letter queue）

死信（未傳遞的訊息）佇列是儲存無法傳送到其正確目的地的訊息的佇列。有時候會出現佇列管理器不能把訊息傳送到目的地的情況，此時訊息將被髮送到某個死信佇列中。死信佇列中的訊息常常暗示了系統可能出現的問題。例如當一條訊息到達目的佇列管理器之後卻發現目的佇列並不存在。或者目的佇列出現不能接收信訊息的情況，比如目的佇列已經滿了，或者它被設定成不允許再加入新的訊息。並不是所有的放訊息操作的失敗都導致訊息被放入死信佇列，例如，由於本地佇列出現錯誤造成應用程式不能“放”訊息，此時MQI呼叫直接把錯誤碼返回給應用程式。

有些錯誤只能由死信佇列報告，例如，一條訊息穿越網路之後到達目的佇列管理器，卻發現目的佇列已滿。發現錯誤的機器不同於最初“放”訊息應用程式所在的機器，甚至可能放訊息的應用程式已不在執行狀態。此時目的佇列管理器把這條訊息發往它所擁有的死信佇列，而不是簡單地扔掉該條訊息。這樣使得這次錯誤是可見的，也給應用程式提供了一個改正錯誤的機會。

死信佇列是WebSphere MQ面對遠端系統錯誤時的一種解決方案。應用程式可以利用WebSphere MQ提供的其他一些工具來監視並確保訊息的可靠傳送和接收。

在佇列管理器建立時，系統會預設建立一個死信佇列，佇列名是SYSTEM.DEAD.LETTER.QUEUE。建議在生產系統上，需要獨立建立一個死信佇列，而不使用系統預設的死信佇列。

8. 命令佇列

命令佇列 SYSTEM.ADMIN.COMMAND.QUEUE 是用來存放由應用管理程式放的具有PCF（programcommand format）的訊息的佇列。該佇列主要用於編寫管理程式時使用。具體的使用將在後續章節介紹。在建立佇列管理器時將為每個佇列管理器自動建立命令佇列。

9. 回覆佇列

當應用程式傳送請求訊息時，接收訊息的應用程式可以將回復訊息傳送給傳送應用程式。此回覆訊息放入一個稱為回覆佇列的佇列中，它通常是傳送應用程式的本地佇列。回覆佇列的名稱由作為訊息描述符一部分的傳送應用程式指定。

10. 別名佇列

別名佇列實際上是本地佇列、遠端佇列定義或佇列名錶的另外一個名字。它是一種簡單的名字到名字的對映，它允許應用程式用另外一個名字來訪問佇列。WebSphere MQ已經為應用程式遮蔽了許多底層系統細節，特別是網路通訊的細節，而別名佇列允許在不修改應用程式的條件下訪問其他名字的佇列。

佇列管理器

在WebSphere MQ中佇列管理器是基本的軟體系統，佇列管理器可看成是佇列和其他物件的容器。WebSphere MQ中的每一個佇列都屬於一個佇列管理器，佇列管理器是為應用程式和WebSphere MQ部件（一些管理工具）提供對佇列管理中物件的訪問。

一個佇列管理器是WebSphere MQ中的一個基本的獨立的執行單元。一臺機器上可以執行一個或多個佇列管理器。

任何需要訪問WebSphere MQ提供的服務的應用程式都必須先和佇列管理器相連，和應用程式相連的佇列管理器對該應用程式而言就叫“本地佇列管理器”（Local Queue Manager）,本地佇列管理器為程式提供MQI呼叫的支援。應用程式可以操作、管理本地佇列管理器所擁有的各種資源，也可以向其他的佇列管理器傳送訊息。

應用程式透過一種叫做MQI的程式設計介面向佇列管理器申請服務。這些服務包括“放”一條訊息到佇列或從佇列“取”一條訊息等一些基本操作。佇列管理器還使佇列成為可靠的儲存訊息的地方，它也控制安全性管理，並提供一些特殊的佇列功能，比如觸發佇列。

為了減少應用程式對於它所執行環境的依賴性，WebSphere MQ的應用程式可以和一個它不知道名字的佇列管理器相連，這個佇列管理器就是一臺機器上的預設佇列管理器。如果程式在呼叫MQCONN時，把佇列管理器名引數設定為空，MQCONN將返回與預設的佇列管理器連線的控制程式碼。

佇列管理器擁有每個佇列。佇列管理器負責維護它所擁有的佇列，以及將它接收到的所有訊息儲存到相應的佇列。可以由應用程式或佇列管理器將訊息放入佇列，這些是它的正常操作的一部分。

通道

訊息通道（Messagechannels）

訊息通道是一種提供從一個佇列管理器到另一個佇列管理器的通訊路徑。訊息通道用在分散式的佇列把訊息從一個佇列管理器傳送到另一個佇列管理器。它們使應用程式遮蔽了底層的通訊協議。佇列管理器可能存在同種或異種平臺之間。為了實現佇列管理器之間的通訊，您必需在一個佇列管理器中定義一個傳送訊息的通道物件，在另一個佇列管理器中定義一個接收訊息的通道物件。訊息通道是一個單向連結。它透過訊息通道代理（message channel agents）把兩個佇列管理器連線起來。

不要和MQI通道（MQI channel）通道混淆。MQI通道有兩種型別，分別是伺服器連線（server-connection）和客戶器連線（client-connection）。

訊息通道分類

訊息通道的定義可以分為以下6種型別：

l 傳送通道（Sender）

l 接收通道（Receiver）

l 伺服器通道（Server）

l 請求器通道（Requester）

l 群集傳送通道（Cluster sender）

l 群集接收通道（Cluster receiver）

訊息通道的組合形式

如果要在佇列管理之間實現訊息傳輸，必須要在兩個佇列管理器上都要定義相應的通道。傳送方和接收方通道的組合形式如下：

l 傳送通道-接收通道（Sender-receiver ）

l 請求器通道-伺服器通道（Requester-server）

l 請求器通道-傳送通道（Requester-sender (callback) ）

l 伺服器通道-接收通道（Server-receiver ）

l 群集傳送通道-群集接收通道（Cluster sender –cluster receiver）

注意：通道的組合形式有5種形式，每種組合方式是固定的，使用者不能隨意組合。每對通道的名稱必需相同例如：在傳送通道-接收通道組合中，傳送通道名和接收通道名必須一致，否則通道將無法啟動。

訊息通道用法傳送通道-接收通道（Sender-receiver）

用法：由一個系統的傳送通道來啟動通道，以便它可以傳送訊息到另一個系統。傳送通道向接收通道傳送啟動請求。傳送通道從傳輸佇列傳送訊息到接收通道。接收通道把訊息放到目標佇列。

請求器通道-伺服器通道（Requester-server）

用法：

(1)由一個系統中的請求器通道來啟動通道，以便它能從另一個系統接收到訊息。請求器通道向通道另一端的伺服器通道傳送請求來啟動。伺服器通道從傳輸佇列把訊息傳送到請求器通道。

(2) 伺服器通道也能啟動通道，併傳送訊息到請求器, 但這僅應用於完全意義的伺服器通道, 也即伺服器通道定義中應含有對方的連線名。一個完全意義的伺服器通道可以由請求器通道啟動, 也可以發起和伺服器通道的通訊。

(3) 最好不要手工去停止Server和Request通道，而是依靠Server通道的Discint的屬性來停止通道。

請求器通道-傳送通道（Requester-sender (callback)）

用法：請求器通道啟動通道，傳送通道終止這個會話。傳送通道然後依據它的通道定義中的資訊(稱為 callback)來重新啟動會話。它把訊息從傳輸佇列傳送給請求器通道。最好不要手工去停止Sender和Request通道，而是依靠Sender 通道的Discint屬性來停止通道。

伺服器通道-接收通道（Server-receiver）

用法：類似於傳送通道-接收通道，但僅應用在完全意義的伺服器通道。也即伺服器通道定義應含有對方的連線名，通道的啟動方是伺服器通道。

群集傳送通道（Cluster sender）

用法：在一個群集中，每個佇列管理器都有一個群集傳送通道，透過它可以把送群集資訊傳送到其中一個佇列管理器資源管理器。佇列管理器透過這個通道也可以把訊息傳送到其他的佇列管理器。

群集接收通道（cluster receiver）

功能：在一個群集中，每一個佇列管理器都有一個群集接收通道。透過這個通道可以接收資料訊息和關於群集的訊息。

MQI通道

MQI通道是WebSphere MQ 客戶端和伺服器上的佇列管理器的通訊的通道。當客戶端應用程式發出MQCONN或MQCONNX呼叫時，才開始建立連線。它是一個雙向的通道，可以負責傳送和接收，被用作MQI呼叫的傳送和響應。

一個MQI通道可以把一個客戶端連線到單個佇列管理器，MQI通道有兩種型別，它們定義了雙向的MQI通道。

客戶端連線通道（Client-connectionchannel）

這種型別為WebSphereMQ 的客戶端所使用。

伺服器連線通道（Server-connectionchannel）

這種型別為執行佇列管理器的伺服器端所使用，執行在WebSphere MQ 客戶端的應用程式將使用這種通道進行通訊。

比較訊息通道和MQI通道

訊息通道與MQI通道之間的區別可以從兩方面進行比較：

l MQI通道是雙向的：一個MQI通道可以被用來傳送請求，也可用來接收響應。而訊息通道則只能單向資料通訊。如果要在兩個佇列管理器之間實現雙向通訊，那麼需要定義兩個訊息通道，一個用來實現資料的傳送，另一個用來實現資料的接收。

l MQI通道的通訊是同步的：當一個MQI請求從客戶端傳送伺服器端時，WebSphere MQ的客戶端在傳送下一個請求之間必須要等待來自伺服器端的響應。而訊息通道，在通道中傳輸的訊息是與時間無關的。大量的訊息可以從一個佇列管理器傳送到另一個佇列管理器，傳送佇列管理器不必等待來自接收佇列管理器的任何響應。

程式

程式定義物件定義響應 WebSphere MQ 佇列管理器上的觸發器事件啟動的應用程式。程式定義屬性包含應用程式標識、應用程式型別和特定於應用程式的資料。

群集

在使用分散式排隊的傳統 WebSphere MQ 網路中，每個佇列管理器是獨立的。如果佇列管理器需要將訊息傳送到另一個佇列管理器，則它必須定義一個傳輸佇列、一個到遠端佇列管理器的通道，以及它要將訊息傳送到的每個佇列的遠端佇列定義。

群集是一組以佇列管理器可以在不需要傳輸佇列、通道和遠端佇列定義的情況下在單個網路上彼此直接通訊的方法設定的佇列管理器。

名稱列表

名稱列表是包含其它 WebSphere MQ 物件列表的 WebSphere MQ 物件。通常，應用程式（如觸發器監視器）使用名稱列表，它們用於標識一組佇列。使用名稱列表的優點是它獨立於應用程式維護；可以在不停止任何使用它的應用程式的情況下更新它。並且，如果一個應用程式失敗，則名稱列表不受影響，其它應用程式可以繼續使用它。

名稱列表還與佇列管理器群集一起使用，以維護多個 WebSphere MQ 物件引用的群集列表。

認證資訊物件

佇列管理器認證資訊物件（AUTHINFO）組成安全套接字層（SSL）安全性的WebSphere MQ 支援的部件。它提供使用LDAP 伺服器檢查證書撤銷列表（CRL）所需的定義。CRL 允許認證中心取消不再可信的證書。

本書描述對認證資訊物件使用setmqaut、dspmqaut、dmpmqaut、rcrmqobj、rcdmqimg 和 dspmqfls 命令。有關 SSL 概述以及 AUTHINFO 的使用，請參閱 WebSphere MQ Security。

系統預設物件

系統預設物件是一組每次建立佇列管理器時自動建立的物件定義。您可以複製和修改這些物件定義中的任何一個，以在安裝時用於應用程式。

預設物件名具有項 SYSTEM.DEFAULT；例如，預設本地佇列是 SYSTEM.DEFAULT.LOCAL.QUEUE，並且預設接收方通道是 SYSTEM.DEFAULT.RECEIVER。您無法重新命名這些物件；這些名稱的預設物件是必需的。

當您定義物件時，從相應的預設物件複製您不明確指定的任何屬性。例如，如果您定義本地佇列，則從預設佇列 SYSTEM.DEFAULT.LOCAL.QUEUE 獲取您未指定的那些屬性。

請參閱附錄1, "系統和預設物件"以獲取有關係統預設的更多資訊。

MQI（message queue interface）

MQI(訊息佇列介面)有下列組成部分：

l 函式介面：應用程式透過函式可以訪問佇列管理器和它的部件。

l ：應用程式使用提供的資料介面來是實現把資料傳遞給佇列管理器，或從佇列管理器中獲得資料。

l 基本資料型別：也是用來實現從佇列管理器傳遞資料，或從佇列管理器中獲得資料。

控制命令

以下是每個 WebSphere MQ 控制命令的參考資訊：

命令名	目的
amqmcert	管理 SSL 證書
amqmdain	配置或控制 WebSphere MQ 服務（僅 Windows 系統）
crtmqcvx	轉換資料
crtmqm	建立本地佇列管理器
dltmqm	刪除佇列管理器
dmpmqaut	轉儲開啟物件的許可權
dmpmqlog	轉儲日誌
dspmq	顯示佇列管理器
dspmqaut	顯示開啟物件的許可權
dmpmqcap	顯示處理程式容量和處理程式數
dspmqcsv	顯示命令伺服器狀態
dspmqfls	顯示檔名
dspmqtrc	顯示格式化跟蹤輸出（HP-UX、和 Solaris）
dspmqrtn	顯示事務的詳細資訊
endmqcsv	停止佇列管理器上的命令伺服器
endmqlsr	停止佇列管理器上的偵聽器程式
endmqm	停止本地佇列管理器
endmqtrc	停止對實體的跟蹤（不用於 AIX）
rcdmqimg	向日志寫物件的映象
rcrmqobj	根據它們在日誌中的映象重新建立一個物件
rsvmqtrn	提交或逆序恢復事務
runmqchi	啟動通道啟動器程式
runmqchl	啟動傳送方或請求者通道
runmqdlq	啟動死信佇列處理程式
runmqlsr	啟動偵聽器程式
runmqsc	向佇列管理器發出 MQSC 命令
runmqtmc	呼叫客戶機的觸發器監控器（僅 AIX 客戶機）
runmqtrm	呼叫伺服器的觸發器監控器
setmqaut	更改開啟物件的許可權
setmqcap	設定處理程式容量
setmqcrl	設定證書撤銷列表（CRL）伺服器定義
setmqscp	設定服務連線點（僅 Windows 系統）
strmqcsv	啟動佇列管理器的命令伺服器
strmqm	啟動本地佇列管理器
strmqtrc	啟用跟蹤（不用於 AIX）

舉例
1. 此命令建立一個稱為 Paint.queue.manager 的預設佇列管理器，建立系統和預設物件，並請求兩個主日誌檔案和三個次日誌檔案：

crtmqm -c"Paint shop" -ll -lp 2 -ls 3 -q Paint.queue.manager

2. 下列命令刪除佇列管理器 travel 並且也抑制任何由該命令發出的訊息。

dltmqm -z travel

3. 此命令立即結束名為 saturn.queue.manager 的佇列管理器。完成所有當前 MQI 呼叫，但不允許新的呼叫。

endmqm -isaturn.queue.manager

MQ 基本概念