7.1　ネーミングルールの考慮点

MQのシステムでは、MQアプリケーションと結びつくのは「キューおよびキューマネージャーになります。

システム設計時に、これらのMQオブジェクトのネーミングルールを決めることは重要です。
システム全体のネーミング・ルールに関しては、個々のシステムの環境において標準となるものが規定されていると思われますので、一般的にはそれに従います。

今回は、MQオブジェクトのネーミング・ルールについて、例や考慮点を紹介していきます。
（あくまで一例です。必ずしもこれらのルールに準拠する必要はありませんので、より適したネーミングもご検討ください）

なお、MQのネーミングには、全てのプラットフォームで共通に使用できる文字セットを使用することを推奨します。

• 英字半角大文字（A～Z)
• 数字半角文字（0〜9）
• 区切り文字として、ピリオド（.）、スラッシュ（/）、下線（_）

7.2　キュー・マネージャー

【キューマネージャー】

• キューマネージャー名はネットワーク内でユニークな名前にする。
  
  通常は、一つのマシン上に一つのキューマネージャーを用意します。ただし、大規模なシステムで、パーシスタント・メッセージを多用し、高スループットが求められる場合や、異なる運用要件がある場合などは、複数のキューマネージャーを稼動させることも可能です。MQネットワーク環境では、それぞれのキューマネージャー名をユニークにする必要があります。

• キューマネージャー名は大文字にする

  全てのプラットフォーム上のキュー・マネージャーと通信を可能にするため、名前には大文字を使用することが推奨されます。

• キューマネージャー名はなるべく短くする。

  • zOS環境・・・キューマネージャー名は、サブシステム名と同一にする必要があります。キューマネージャー名は4文字に限られます。
    例） ADDX（A=地名、DD=会社の組織のID、X=識別ID）

  • その他の環境：キューマネージャー名は長いものでも使用することはできますが、短いものをお薦めします。

    • MQMDにてメッセージID生成の際にキューマネージャーの最初12文字を使用するため12文字以下をお薦めします。

    • チャネル名にキューマネージャー名を含めることを想定する場合、チャネル名の20文字という制限に入るキューマネージャー名にします。
      
      例1）CCCDDFNN　
      - CCC=都市ID（TKO：東京、OSK：大阪、など）
      - DD=会社の組織のID
      - F=キューマネージャーの機能（P：プロダクション、T：test、D：開発、など）
      - NN=順序番号（00、01など）
      
      例2) SSSCCFNN
      - SSS=会社のID
      - CC=都市のID
      - F=キューマネージャーの機能
      - NN=順序番号
      
      

【デフォルト･キューマネージャー】

• デフォルトキューマネージャーは定義しない。
  
  CICS/ESAを使用する環境ではCICSは常に一つのキューマネージャーとしか接続できませんが、その他のプラットフォームでは一つのシステム上に複数のキューマネージャーを生成することが可能です。このとき、一つのキューマネージャーをデフォルトとして定義しないでください。間違ったキューマネージャーを選択してしまうエラーの原因となります。
  
  たとえシステム上に一つのキューマネージャーしか作成しない場合も、そのキューマネージャーをデフォルトとしては設定しないでください。デフォルトとすることによって操作が楽になることもありますが、将来、さらに別のキューマネージャーを追加した際に、エラーの原因となります。
  
  

【キューマネージャー別名】

• キューマネージャー別名はキューマネージャー名に接尾語をつけたものとする。
  
  キューマネージャー別名を使用する際、実在するキューマネージャー名と同一に設定してメッセージの交換をすることは推奨できません。
  
  キューマネージャー別名と実在するキューマネージャーに同一の名前をもたせることは、間違ったキューマネージャーにメッセージを届けてしまう原因となります。
  ⚪︎ MDのReplyToQMgrがブランクになっている場合、キューマネージャー名は別名ではなく実在のローカルキューマネージャー名を記入します。
  ⚪︎ デッドレターキューのメッセージはキューマネージャー別名ではなく、実在するキューマネージャーを認識します。
  
  

  キューマネージャーは別名12文字以上でも可能です(MVSで4文字以上でも可能です）。
  キューマネージャー別名は、キューマネージャー間で複数のチャネルを利用することによって大量のメッセージ送受信を可能にする場合などに使用します。
  この際、キューマネージャー別名とそれに関連するチャネル名の接尾語を同一にします。
  チャネル名の長さ制限を考慮して、接尾語の長さは3文字程度とします。

  例）
  - キューマネージャー名：JUPITER
  - キューマネージャー別名：JUPITER_XL

7.3　キュー

【キュー】

• キューの機能を明示する名前をつける。
  
  キューは何らかのサービスを提供するものですので、そのサービスの内容をキュー名に明記すると分かりやすくなります。

• 階層的に名前をつける。
  
  通常キューは、"<アプリケーション>.<機能>"のように命名することを薦められます。
  MQが提供するオブジェクトには通常"SYSTEM."という接頭語が使用されますので、このキーワードはアプリケーションで使用するキューには使用しないようにします。
  

  MQエクスプローラやMQSCコマンドなどを使用して、キューのリストを表示させる場合、キューはアルファベット順にソートされて表示されます。
  関連するキューをグループ分けするために共通の接頭語を持たせると、MQの管理（キューの検索をするとき、MVSのセキュリティ管理時、デッドレター・ハンドラーなど）が楽になります。
  
  大規模なアプリケーションでは、より多くの階層付けを行います。

  例）　<システム名>.<アプリケーション名>.<機能>.<サブ機能> など

• キューマネージャー名は含めない。
  
  MQは、キュー名とそのキューを管理するキューマネージャー名によって、個々のキューを識別します。従って、キュー名にキューマネージャー名を含める必要はありません。
  たとえば、キュー名にキューマネージャー名を含めてしまうと、そのキューが別のキューマネージャーに移動した場合に、キュー名自体を変更する必要が出てきます。（ただし、トランスミッションキュー名は除きます）。

• ローカルキュー名の接尾語としてバージョンをつける。
  
  アプリケーションが扱うキューに複数のバージョンが混在する際は、キュー名の接尾語としてバージョンをつけます。
  
  例）
  <アプリケーション名>.<機能>_TEST
  <アプリケーション名>.<機能>_V2.1
  <アプリケーション名>.<機能>_THURSDAY
  
  こうすることで、アプリケーションのパラメーターとしてキュー名がより明確に判断できるようになります。
  
  

【特殊なキュー】

トランスミッションキュー

• 宛先のキューマネージャーと同一の名前にする。
  
  

  特別な目的が無い限り、宛先のキューマネージャー名と同一の名前を使用します。
  （ただし、二つ以上のチャネルを並行して定義する場合などには、個々のチャネルごとに、異なる名前（連番を付与するなど）でトランスミッションキューを定義する必要があります）
  
  MQクラスター用のトランスミッションキューは"SYSTEM.CLUSTER.TRANSMIT.QUEUE"で固定されます。

応答キュー

• 命名パターン
  
  応答キューのネーミングコンベンションは今までと同じ階層型とし、"<アプリケーション名>.REPLY"とします。
  後にパフォーマンスチューニングなどで構成を変更する可能性があるため、名前にはキューマネージャー名やローカルキューのキュータイプなどは含めません。
  共有の応答キューが複数のバージョンを持っているときなどは、別名を使用することも可能です。
  
  

デッドレターキュー

• 要件に応じて、デッドレターキューを定義する。

  "SYSTEM.DEAD.LETTER.QUEUE"というローカルキューをデッドレターキューとして使用します。
  これはいくつかのプラットフォームでは自動的に生成されます。自動的に生成されないプラットフォームでは、これと同じ名前のデッドレターキューを作成してください。
  どのプラットフォームでも共通の名前をもたせることにより、判別が容易になります。

  デッドレターキューを使用するには、キューマネージャー設定でデッドレターキュー名をDEADQ属性に設定する必要があります。

  ただし、デッドレターキューを設定することで、障害発生時にメッセージの転送先が変わったり、メッセージの送信順序性が崩れる可能性があります。デッドレターキューを使用するかどうかは、運用手順等も考慮しながら、別途検討するようにしてください。

ブリッジとリンクのためのキュー

• アプリケーションの階層構造にブリッジもしくはリンクのタイプを入れる。
  
  例）
  <アプリケーション名>.IMS、
  <アプリケーション名>.R/3、
  <アプリケーション名>.CICS
  
  

イニシエーションキュー

• 一般的なトリガリングにはシステムで定義されているキューを使用する。
  
  いくつかのプラットフォームでは、キューマネージャーが作成された際に、トリガーモニターのデフォルトとして、イニシエーションキューが定義されます。(SYSTEM.DEFAULT.INITIATION.QUEUEやSYSTEM.CICS.INITIATION.QUEUEなど）
  これら、システムで定義されたイニシエーションキューを使用することにより、トリガリングを容易に行うことができます。

• 階層的な命名を使用する。
  
  

  アプリケーションのいろいろな機能に対するイニシエーションキューを作成する際は、以下のような命名パターンとすることができます。
  
  例）　<アプリケーション名>.INITQ

7.4　チャネル

【チャネル】

クラスターチャネル

• 命名パターン
  
  クラスターの送信側および受信側においても、"TO.<キューマネージャー名>."のパターンを使用します。
  メッセージの送信宛先がわかるようにキュー・マネージャー名を使用します。
  
  - 送信側チャネルの場合：TO.<リポジトリー・キューマネージャー名>
  - 受信側チャネルの場合：TO.<自分のキューマネージャー名>
  
  

メッセージチャネル

• 命名パターン
  
  メッセージチャネルの命名法は、"<送信元のキューマネージャー名>.<送信先のキューマネージャー名>"（または"<送信元のキューマネージャー名>.TO.<送信先のキューマネージャー名>など）とします。この名前は全部20文字以内とします。
  
  

  前述のトランスミッションキューのネーミング・ルールに従っている場合には、これは<送信元のキューマネージャー名>.<トランスミッションキュー名>と同等です。
  キューマネージャー別名を使用し、チャネルが複数存在する場合は、この<送信先のキューマネージャー名>は、<キューマネージャー別名>となります。

• 必要な場合は使用するネットワーク・プロトコル名をつける
  
  

  使用するネットワーク・プロトコルが全てTCP/IPである場合は쁸文字しか制限のないチャネル名にわざわざプロトコル名を記述することは不要ですが、使用するプロトコルの種類がTCPI/IPやSNAなど複数混在する場合は、チャネル名にネットワーク・プロトコル名を含めることをお薦めします。
  
  

  例）　MARS.TO.JUPITER_SNA
  　　　MQRS.SNA.JUPITER
  
  

クライアントチャネル

• 命名パターン
  
  メッセージチャネルの命名法は、　"CL.<クライアント側のサブシステムID>"　とします。
  この名前は全部20文字以内とします。
  
  クライアントチャネル定義は、複数クライアント、複数サーバーで共有することができます。
  運用管理を考慮して、どの単位（アプリケーション単位/クライアント単位/サブシステム単位など）でチャネルを共有するかを検討し、それに合ったネーミングをつける必要があります。
  また、SSL機能のある/なしなど、機能や用途に応じた接尾語を付与することも可能です。

7.5　その他

【その他のコンポーネント】

MQクラスター名

• クラスター名はネットワーク内でユニークな名前にする。
  
  例）　CLUSTnn
  CLUST=クラスターを表す接頭語
  nn=通番（01〜99）
  
  

プロセス

• キューがそれ用のプロセスを持つ場合は、キュー名と同一の名前をつける。
  
  キューにバージョンがついている場合は、接尾語としてバージョン名をつけます。
  プロセスは独自のネームスペースを持つため、名前にそれがプロセスであることを記述する必要はありません。
  
  例1）　PR.APP.キュー名
  ⇒キューのトリガリングの場合（トリガー対象のキュー名）
  例2）　PR.CHL.チャネル名
  ⇒チャネルのトリガリングの場合
  
  
• プロセスが共有されている場合、全体の機能を記述する。
  
  いくつかのキューが共通のプログラムにより共有されている場合、ひとつのプロセスオブジェクトを定義します。
  

  トリガー機能により起動されるアプリケーションが識別できる名前にします。
  全体の機能に対し、階層的なネーミングをつけます。

  
  例3）　PR.機能名
  ⇒複数のキューからトリガリングされる場合
  
  

ストレージクラス（ｚOSのみ）

• ストレージクラスは機能を明示する名前にする。
  
  例）　SC.サブシステム.機能（.サブ機能1.サブ機能2）
  ⚪︎ サブシステム：　サブシステム名（在庫管理、給与管理、など）
  ⚪︎ 機能：　業務機能
  ⚪︎ サブ機能：　機能を細分化する任意の拡張子
  
  あくまでもシンプルに、例えばIMSブリッジのキューのストレージクラスであれば"IMS"と名づけたりします。
  将来変更する際に分かりやすいように機能を明確に記述します。
  名前には、それがストレージクラスであるということをわざわざ含む必要はありません。ストレージクラスは他のMQのオブジェクトとは異なるネームスペースを持っているため、オブジェクトリストにてそれがストレージクラスであるということはすぐにわかります。