2.8.10　クラスタの管理

(a)　フルリポジトリを保持するキューマネジャの選択

各クラスタで，フルリポジトリを保持するためには，少なくとも一つ，できれば二つ以上のフルリポジトリキューマネジャを選択する必要があります。クラスタは一つのフルリポジトリキューマネジャでも問題なく動作しますが，二つ使用すると可用性が向上します。その場合，フルリポジトリキューマネジャ間のクラスタセンダチャネルを定義することによって，相互接続します。

図2‒53　一般的な2フルリポジトリキューマネジャのトポロジ

これは，一般的な2フルリポジトリキューマネジャのトポロジを表しています。モデルになるクラスタのシステム構成については，「2.8.1(2)　クラスタの概念」を参照してください。

• 最も重要な検討事項は，選択したフルリポジトリキューマネジャは信頼性が高くよく管理されていなければいけないということです。

• また，キューマネジャのロケーションを検討し，中央の位置，またはクラスタのほかの多数のキューマネジャと同じシステムに位置するものを選択します。

• さらに，キューマネジャがすでにほかのクラスタのためのフルリポジトリを持っているかどうか検討します。一度決定し，あるキューマネジャをクラスタのフルリポジトリとして設定するのに必要な定義を作成したら，同じキューマネジャを使い続けて，メンバであるほかのクラスタのフルリポジトリを保持することをお勧めします。

キューマネジャが自分自身についての情報を送信したり，ほかのキューマネジャについての情報を要求したりすると，その情報や要求は二つのフルリポジトリキューマネジャに送信されます。

事前定義クラスタセンダチャネル定義を一本しか作成していない場合は，次のチャネルを使用して，クラスタ情報を送信します。

• 事前定義クラスタセンダチャネル

• システムが自動的に作成したどれか一つの自動定義クラスタセンダチャネル

事前定義クラスタセンダチャネル定義を二本以上作成した場合は，自動的に作成されたクラスタセンダチャネルは使用しません。クラスタヘ初回参加時に使用した二本の事前定義クラスタセンダチャネルだけを使用して，クラスタ情報を送信します。

送信された情報や要求は，事前定義クラスタセンダチャネル定義上で指定されているフルリポジトリキューマネジャが，要求を処理します。そのフルリポジトリキューマネジャが使用できない場合でも，もう一つの送信先フルリポジトリキューマネジャが要求を処理します。これによって一つのフルリポジトリキューマネジャが使用できなくなっても，最新のクラスタ情報が保持されます。

最初のフルリポジトリキューマネジャが再度利用できるようになると，そのフルリポジトリキューマネジャは最新の変更された情報を収集し，遅れを取り戻します。

クラスタセンダチャネル定義上で指定されているフルリポジトリキューマネジャが，可能な場合要求を処理しますが，選択されたフルリポジトリキューマネジャが利用できない場合，ほかのフルリポジトリキューマネジャが使用されます。最初のフルリポジトリキューマネジャが再度利用可能になると，そのフルリポジトリキューマネジャは最新の変更された情報を収集し，遅れを取り戻します。

とても巨大なクラスタでは千単位のキューマネジャがあり，二つより多くのフルリポジトリキューマネジャが必要になります。その場合，例えば，次に示すようなトポロジにできます。

図2‒54　フルリポジトリキューマネジャをハブアンドスポーク構成にした配置

図2‒55　複雑なフルリポジトリキューマネジャのトポロジ

すべてのフルリポジトリキューマネジャが同時に使用できなくなる場合，自キューマネジャはパーシャルリポジトリにある情報を使用して処理を続行します。新しい情報と更新要求は処理されません。フルリポジトリキューマネジャがネットワークに再接続するとき，すべてのリポジトリ（フルおよびパーシャル）を最新にするようメッセージが交換されることになります。

(b)　クラスタを構成

フルリポジトリを保持するための幾つかのキューマネジャを選択したら，どのキューマネジャをどのフルリポジトリとリンクするか決める必要があります。クラスタセンダチャネル定義は，クラスタのほかのフルリポジトリが見つかるフルリポジトリキューマネジャにリンクします。そのあと，キューマネジャは，メッセージを二つのフルリポジトリキューマネジャに送信します。この時，必ず最初にクラスタセンダチャネル定義を持っているフルリポジトリキューマネジャに送信します。どのフルリポジトリキューマネジャを選んだかは問題になりません。しかし，自分の構成のトポロジを検討する必要があります。また，キューマネジャの物理的，地理的位置も検討する必要があります。すべてのクラスタ情報は二つのフルリポジトリキューマネジャに送信されるので，2番目のクラスタセンダチャネル定義を作成したいような場合があります。多数のフルリポジトリが広範囲に広がるクラスタで，自分の情報がどのフルリポジトリキューマネジャに送信されるかコントロールするために定義します。

(c)　命名規則

新しいクラスタを設定する場合に，キューマネジャの命名規則を検討します。すべてのキューマネジャは，異なる名前を持つ必要があります。なお，似たような名前を付ければ，どのキューマネジャがグループになっているか覚えやすくなります。

また，すべてのクラスタレシーバチャネルは，ユニークな名前を持つように設定してください。この場合，キューマネジャ名の前にTOを付けるのも，一つの方法です（例えば，TO.QM1，TO.QM2など）。同じキューマネジャへの複数のチャネルを持っており，それぞれの優先度が異なり，異なるプロトコルを使用している場合にはTO.QM1.A1，TO.QM1.N3，およびTO.QM1.T4などの名前を使用して命名規則を拡張できます。

すべてのクラスタセンダチャネルは，対応のクラスタレシーバチャネルと同じ名前を持つことを覚えておいてください。

(d)　マルチクラスタ

複数のクラスタをまとめてマルチクラスタを構成できます。次に示す場合にマルチクラスタの作成を検討してください。

• 異なる組織が独自の管理を行えるようにする場合

• 独立したアプリケーションを別々に管理する場合

• サービス階層を設定する場合

• テスト用と設計用の環境を作成する場合

キューマネジャが複数のクラスタのメンバである場合，定義の数を減らすためにネームリストを利用できます。ただし，TP1/Message Queue 07-50，07-51および07-52ではネームリストをサポートしていません。そのため次に示す項目に注意してください。

• クラスタセンダチャネル

  各クラスタを管理するフルリポジトリキューマネジャに接続するために，フルリポジトリキューマネジャごとに事前定義クラスタセンダチャネル（mqtalccha定義コマンド）が必要です。

• クラスタレシーバチャネル

  各クラスタを管理するフルリポジトリキューマネジャに接続するために，フルリポジトリキューマネジャごとにクラスタレシーバプロセスとクラスタレシーバチャネルが必要です。

• クラスタキュー

  mqamkque -cオプションに指定したクラスタに参加していないキューマネジャからは，アクセスできません。

複数のクラスタがネットワークにある場合，それぞれに異なる名称を付ける必要があります。同じ名称の二つのクラスタをいったん合併した場合は，分離できません。クラスタ，およびチャネルに異なる名称を付け，mqrlsコマンドの出力を参照する時に容易に区別できるようにすることをお勧めします。正常動作をするためには，キューマネジャ名はクラスタ内でユニークである必要があります。

• サービス階層の設定

  ある大学で各スタッフと各学生にキューマネジャがあるとします。スタッフ間のメッセージは優先度が高く，広帯域のチャネルで転送されます。学生間のメッセージは狭くて遅いチャネルで転送されます。通常の分散キューイングでこのネットワークを設定することができます。TP1/Message Queueはあて先キュー名とキューマネジャ名を参照し，どのチャネルを使用するか検知します。

  スタッフと学生を明確に分離するためには，次の図に示すとおりキューマネジャを二つのクラスタに分けることができます。TP1/Message QueueはStaffクラスタで定義されたチャネルだけを使用して，Staffクラスタのmeetingsキューへメッセージを転送します。StudentsクラスタのgossipキューへのメッセージはStudentsクラスタで定義されたチャネルを使用して転送します。こうして適切なサービス階層が設定されます。

  図2‒56　サービス階層

(e)　オブジェクト

クラスタを使用するには次に示すオブジェクトが必要です。

SYSTEM.CLUSTER.REPOSITORY.QUEUE

各キューマネジャは，SYSTEM.CLUSTER.REPOSITORY.QUEUEというローカルキューを持っています。このキューは，すべてのリポジトリ情報を保存するのに使用されます。

このキューのメッセージは削除しないでください。削除した場合，OpenTP1が異常終了することがあります。また，削除したことによって，以前のクラスタ参加情報が失われるため，再度クラスタに参加する必要があります。

SYSTEM.CLUSTER.COMMAND.QUEUE

クラスタの各キューマネジャは，SYSTEM.CLUSTER.COMMAND.QUEUEというローカルキューを持っています。このキューは，メッセージをフルリポジトリに転送するのに使用されます。キューマネジャはこのキューをあて先として使用して，自分についての新しい情報または変更された情報をフルリポジトリキューマネジャに送信したり，ほかのキューマネジャについての情報の要求を送信したりします。

また，要求した情報の応答，および取得済みの情報の変更された情報を受信するキューとして使用します。

SYSTEM.CLUSTER.TRANSMIT.QUEUE

各キューマネジャは，SYSTEM.CLUSTER.TRANSMIT.QUEUEというローカルキューを持っています。これは，クラスタ内のすべてのキューやキューマネジャへのすべてのメッセージに使用されるクラスタ転送キューです。

注意事項

SYSTEM.CLUSTER.TRANSMIT.QUEUEには，ユーザメッセージとともにシステム制御用のシステムメッセージが登録されます。ユーザメッセージを削除する必要がある際には，システムメッセージを削除しないように注意してください。

(a)　キューマネジャのリフレッシュ

キューマネジャが保持するクラスタについての情報をリフレッシュできます。ただし，通常の運用ではほとんど実行する必要がありません。リフレッシュするにはmqrrefreshコマンドを入力します。自システム以外のキューマネジャに関連するすべてのクラスタキューマネジャオブジェクトとすべてのクラスタキューオブジェクトを，パーシャルリポジトリから削除できます。また，このコマンドはクラスタ転送キューにメッセージがなく，フルリポジトリキューマネジャに接続されていない自動定義クラスタチャネルを削除します。

注意事項

通常，mqrrefreshコマンドを入力する必要はありません。mqrrefreshコマンドを入力するのは，フルリポジトリキューマネジャが保持するリポジトリ情報とTP1/Message Queueがパーシャルリポジトリで保持するリポジトリ情報とに不整合が発生した場合です。次に示す場合にコマンドを入力します。

• リポジトリ情報の破棄

  フルリポジトリキューマネジャと通信するリポジトリ情報が破棄された場合です。例えば，運用やアプリケーションの誤りによってSYSTEM.CLUSTER.COMMAND.QUEUEのメッセージを削除した場合や，SYSTEM.CLUSTER.COMMAND.QUEUEに登録すべき自キューマネジャあてのメッセージが，他キューマネジャのSYSTEM.CLUSTER.TRANSMIT.QUEUEから削除された場合です。

• 米国IBM社からの指示

  米国IBM社によってREFRESH CLUSTERコマンドを入力することが指示された場合です。

• クラスタレシーバチャネル名の重複解消

  クラスタ内の複数のキューマネジャに，同じ名前のクラスタレシーバチャネルがある場合，意図しないキューマネジャにメッセージが転送されることがあります。この場合，クラスタレシーバチャネルの名前を重複しないように変更したあと，重複したクラスタレシーバチャネルを使用している他キューマネジャからmqrrefreshコマンドまたはREFRESH CLUSTERコマンドを入力する必要があります。

• RESET CLUSTERコマンドの誤入力

  誤ってRESET CLUSTER ACTION(FORCEREMOVE)コマンドを入力した場合です。

• 復元後のキューマネジャ再開始

  キューファイルのバックアップを復元するなどして，キューマネジャを最後に終了した時点よりも前の状態で再度開始した場合です。

(b)　キューマネジャの脱退

キューマネジャをクラスタから脱退できます。ただし，通常の運用ではほとんど実行する必要がありません。

脱退するにはmqrremoveコマンドを入力します。自システムのクラスタレシーバチャネルについてフルリポジトリに削除依頼を送信します。

注意事項

通常，mqrremoveコマンドを入力する必要はありません。mqrremoveコマンドを入力するのは，使用されなくなるTP1/Message Queue環境を削除する場合や，フルリポジトリキューマネジャが保持するリポジトリ情報とTP1/Message Queueがパーシャルリポジトリで保持するリポジトリ情報に不整合が発生した場合です。次に示す場合にコマンドを入力します。

• 復元後のキューマネジャ再開始

  キューファイルのバックアップを復元するなどして，キューマネジャを最後に終了した時点よりも前の状態で再度開始した場合です。

• クラスタセンダチャネルの情報の消滅

  システム時刻を戻したことなどによってクラスタセンダチャネルの情報が消滅し，リポジトリ情報をフルリポジトリに送信できない場合です。

• SYSTEM.CLUSTER.TRANSMIT.QUEUEに障害が発生した場合

• SYSTEM.CLUSTER.REPOSITORY.QUEUEに障害が発生した場合

• SYSTEM.CLUSTER.COMMAND.QUEUEに障害が発生した場合

(c)　クラスタ転送キューの保守

クラスタ転送キューの可用性とパフォーマンスは，クラスタのパフォーマンスにとって重要です。満杯にならないようにする必要があります。また，mqasetコマンドを間違って発行して取り出し不可や登録不可にしないように注意してください。なお，クラスタ転送キューが格納されるキューファイルは，満杯にならないように注意してください。

(d)　キューマネジャ失敗時の処理

メッセージがバッチ転送によって特定のキューマネジャに送信されたがそのキューマネジャが利用不可になった場合，次に示すような対策ができます。

• ファーストチャネルのファーストメッセージ（喪失されることがある）を除き，未転送のメッセージバッチは，送信したキューマネジャのクラスタ転送キューに戻されます。

  • 戻されたメッセージバッチに問題がなく，メッセージが特定のキューマネジャとバインドされていない場合，メッセージ送信経路の再設定が行われ，適切な代替キューマネジャを選択し，メッセージを送信します。

  • すでにキューマネジャに転送されたり（送達未確認状態），問題があったり，適切な代替のキューマネジャが見つからないメッセージは，元のキューマネジャが再度利用可能になるまで待つ必要があります。

(e)　リポジトリへの登録失敗時の処理

クラスタ情報は，SYSTEM.CLUSTER.COMMAND.QUEUEというローカルキューを介してパーシャルリポジトリに反映されます。このキューが満杯の状態である場合，リポジトリ管理サーバは動作を停止しているので，クラスタ情報メッセージはデッドレターキューに転送されます。ログメッセージから発生がわかったら，デッドレターキューからメッセージを回復し，それを正しいあて先へと転送し直すアプリケーションを実行する必要があります。

リポジトリ情報はSYSTEM.CLUSTER.REPOSITORY.QUEUEというローカルキューに格納されています。このキューが満杯の状態である場合，クラスタ情報の追加と更新ができないでエラーログが出力されます。その場合，キューマネジャを停止し，キューの容量を拡大したあと，開始してください。

キューを再作成した場合は，以前のクラスタ参加情報は失われ，再度クラスタ参加を実行します。この場合，mqrsupとmqrsppの起動をする前に，フルリポジトリキューマネジャからRESET CLUSTERコマンドを実行して，自キューマネジャをクラスタから削除してください。

キューマネジャのリポジトリの共用メモリ不足が発生した場合（とてもまれな場合），共用メモリ確保エラーがログ出力されます。この場合，キューマネジャを停止し，使用共用メモリを拡大したあと，開始します。

(f)　クラスタキュー登録不可時の処理

クラスタキューが登録不可になると，この状況は，そのキューに関係している各キューマネジャのフルリポジトリに反映されます。ワークロード管理機能は，可能な場合メッセージを登録できるあて先に送信しようとします。登録できるあて先がなく，ローカルキューもない場合，MQOO_BIND_ON_OPENを指定したMQOPEN命令はリターンコードMQRC_CLUSTER_PUT_INHIBITEDをアプリケーションに返します。MQOO_BIND_NOT_FIXEDが指定されている場合，またはローカルキューがある場合，MQOPEN命令は成功しますが，以後のMQPUT命令はリターンコードMQRC_PUT_INHIBITEDで失敗します。

(g)　リポジトリ情報の保持期間

各リポジトリ情報の保持期間を次の表2-16，表2-17，表2-18に示します。

表2‒16　リモートキューマネジャ情報の保持期間

リポジトリ情報名	内容	保持期間※	備考
クラスタキューマネジャ情報	リモートのキューマネジャに存在するクラスタレシーバチャネル情報	60〜90日	フルリポジトリキューマネジャから，リモートキューマネジャの情報が通知されます（キューマネジャ問い合わせ情報またはキューマネジャ識別子問い合わせ情報の応答として受信します）。
クラスタキュー情報	リモートのキューマネジャに存在するクラスタキュー情報	60〜90日	フルリポジトリキューマネジャから，クラスタキューの情報が通知されます（キュー問い合わせ情報の応答として受信します）。

表2‒17　ローカルキューマネジャ情報の保持期間

リポジトリ情報名	内容	保持期間※	備考
クラスタキューマネジャ情報	ローカルキューマネジャに存在するクラスタレシーバチャネル情報	90日	クラスタ参加時に送信したあとは，27日周期で有効期間を更新し，フルリポジトリキューマネジャに再送信します。
クラスタキュー情報	ローカルキューマネジャに存在するクラスタキュー情報	90日

表2‒18　問い合わせ情報の保持期間

リポジトリ情報名	内容	保持期間※	備考
問い合わせ情報（キューマネジャ，キューマネジャ識別子，キュー）	次の情報を問い合わせます。 リモートのキューマネジャに存在するクラスタレシーバチャネル情報 リモートのキューマネジャに存在するクラスタキュー情報	30日	ローカルキューマネジャがリモートのキューマネジャに存在するクラスタレシーバチャネル情報またはクラスタキュー情報を必要とした（MQOPEN命令，MQPUT命令，MQPUT1命令などが実行された）場合に送信されます。 問い合わせ情報の応答として，クラスタキューマネジャ情報またはクラスタキュー情報が通知されます。 問い合わせ情報の有効期限内にクラスタキューマネジャ情報またはクラスタキュー情報を使用した場合には，27日周期で問い合わせ情報の有効期間を更新し，フルリポジトリキューマネジャに再送信します。

自キューマネジャでのクラスタキューの追加

キューマネジャが，例えば，新しいキューの作成を通知するためフルリポジトリキューマネジャに，自キューマネジャのクラスタキュー情報を送信すると，フルリポジトリキューマネジャおよびパーシャルリポジトリキューマネジャは，その情報を30日間保管します。リポジトリの情報の期限が切れないように，自キューマネジャは，27日後に自動的に自分についてのすべての情報を再送します。有効期間が過ぎても，情報はフルリポジトリキューマネジャおよびパーシャルリポジトリキューマネジャ上のリポジトリから即座には削除されません。60日の猶予期間で保管されます。猶予期間中に更新情報を受け取らなかった場合，情報は削除されます。有効期日にキューマネジャが一時的に使用できなくなるおそれを考慮して猶予期間があります。キューマネジャが90日を超えてクラスタから切断された場合，キューマネジャはクラスタの一部ではなくなります。

リポジトリ情報の保持期間について次の図に示します。

図2‒57　リポジトリ情報の保持期間

注※

90日以上経過したことでリポジトリ情報が削除され，パーシャルリポジトリキューマネジャはクラスタから除去されます。

OpenTP1開始時に，パーシャルリポジトリキューマネジャは参加した情報を保持しているため，開始時に参加メッセージを送信しないで，自マネジャ情報だけを送信します。そのため，mqrremoveコマンドによって脱退しないとクラスタに参加できません。

リポジトリ情報の有効期間が切れないように，キューマネジャは27日を経過したことを検出したときに，自動的に自分についてのすべての情報を，フルリポジトリに対応するクラスタセンダチャネルを使用して再送します。クラスタセンダチャネルで送信中は，チャネル状態は「チャネル動作中」になります。

なお，事前定義クラスタセンダチャネルやデフォルトチャネル定義のチャネルの確立方法（mqtalccha定義コマンド-iオプション指定値）にmanualを指定している場合，フルリポジトリに対するクラスタセンダチャネルが動作中でないとき自動的にはリポジトリ情報は再送されません。このためユーザがチャネルを動作させる必要があります。

最後のリポジトリ情報の送信から90日以上チャネルを確立しない場合（OpenTP1未開始など），リポジトリ情報は失われます。

TP1/Message Queueは次に示す契機に有効期間の確認を行い，有効期間が過ぎている場合は更新情報を送信します。

• リポジトリ管理サーバ開始時

• リポジトリ管理サーバ開始後の一定間隔

• リポジトリ管理サーバ終了時

クラスタキューへのメッセージ登録

自キューマネジャ上のアプリケーションが，例えば，任意のパーシャルリポジトリキューマネジャのクラスタキューにメッセージを登録しようとした場合，自キューマネジャはフルリポジトリキューマネジャに対して，問い合わせ情報を送信します。問い合わせ情報の存続期間は30日です。自キューマネジャは，27日後に問い合わせ情報をチェックします。27日の間に問い合わせ情報で取得した情報が参照された場合，その問い合わせ情報は自動的にリフレッシュされます。この期間に参照されなかった場合，その問い合わせ情報は期限満了の対象として各キューマネジャから除去されます。

フルリポジトリキューマネジャは，問い合わせ情報に対応するリポジトリ情報（クラスタレシーバチャネル情報およびクラスタキュー情報）を送信します。キューマネジャは，その情報を受信後30日間保管します。有効期間が過ぎても，これらの情報はリポジトリから即座には削除されません。60日の猶予期間で保管されます。猶予期間中に更新情報を受け取らなかった場合，リポジトリ情報は削除されます。有効期日にキューマネジャが一時的に使用できなくなるおそれを考慮して猶予期間があります。

問い合わせ情報がリフレッシュされないで，フルリポジトリキューマネジャから削除された場合，フルリポジトリキューマネジャはリポジトリ情報を送信しなくなります。

自キューマネジャ上のアプリケーションは，MQOPEN命令，MQPUT命令，またはMQPUT1命令で，受信したこれらのリポジトリ情報を使用します。

通常，定期的（30日以内）にMQOPEN命令，MQPUT命令，またはMQPUT1命令を実行している場合は，問い合わせ情報は自動的にリフレッシュされ，リポジトリ情報は最新に更新されます。一方，MQOPEN命令を実行後，長期間MQPUT命令を実施しないまま放置するなど，定期的に使用されない場合は，自キューマネジャのリポジトリ上からリポジトリ情報は削除されます。

リポジトリ情報の保持期間について次の図に示します。

図2‒58　リポジトリ情報の保持期間

最後の情報の受信から90日以上チャネルを確立しない場合（OpenTP1未開始など），フルリポジトリキューマネジャ上から情報が失われます。

TP1/Message Queueは次に示す契機で有効期間を確認し，有効期間が過ぎている場合は，情報を除去します。

• リポジトリ管理サーバ開始時

• リポジトリ管理サーバ開始後の一定間隔

• リポジトリ管理サーバ終了時

(h)　環境不正によるリポジトリ情報の有効期限切れの通知

フルリポジトリキューマネジャと接続するチャネル（クラスタセンダまたはクラスタレシーバ）の障害などの環境不正が発生すると，定期的（30日以内）に使用しているリポジトリ情報が更新されなくなります。

対策しない場合にリポジトリ情報の保持期間が満了すると，リポジトリ情報は使用できなくなり，MQOPEN命令，MQPUT命令，またはMQPUT1命令が失敗します。そのため，障害が解決されないままリポジトリ情報が有効期間切れとなった場合，保持期限を通知するKFCA31546-WおよびKFCA31547-Wメッセージを出力します。

メッセージが出力された場合，必要なリポジトリ情報が更新されるように対策してください。

図2‒59　リポジトリ情報有効期限切れ通知機能

注意事項

• リポジトリ管理サーバ（mqrsup）が停止している間はメッセージが出力されません。リポジトリ管理サーバ（mqrsup）停止中に出力契機に達した場合，リポジトリ管理サーバ（mqrsup）を再起動したときにメッセージが出力されます。

• OpenTP1を長期間停止していた場合，OpenTP1の開始時にメッセージが1度だけ出力されることがあります。この場合は，リポジトリ管理サーバ（mqrsup）によってリポジトリ情報が更新されるため対策不要です。必要に応じて，リポジトリ情報の更新状況を照会するコマンド（mqrlsコマンドの-uオプション）を入力し，リポジトリ情報の保持期限が更新されたことを確認してください。

• メッセージが出力されたリポジトリ情報について対策しなかった場合，保持期限を過ぎるとリポジトリ情報が削除されます。削除されたリポジトリ情報についてはメッセージが出力されなくなります。

(i)　リポジトリ情報送信契機の通知

TP1/Message Queueは，リポジトリ情報の有効期限が切れる前に，フルリポジトリキューマネジャに対してリポジトリ情報の更新のため，自動的に問い合わせ情報を再送信します。更新の対象となるのは有効期限内だけです。

リポジトリ情報送信通知機能では，リポジトリ情報更新時の問い合わせ情報の再送信契機をメッセージ出力（リポジトリ情報送信通知メッセージ（KFCA31544-I），およびリポジトリ情報送信完了メッセージ（KFCA31545-I））によって事前に確認できるようになります。これによって，メッセージ出力されているリポジトリ情報は有効期限内で使用されているものであることが確認できます。

ただし，更新対象が複数存在する場合は，最も早くに送信契機に達するリポジトリ情報に対してだけ，メッセージが出力されます。そのため，その時点で更新対象となるすべてのリポジトリ情報については，mqrlsコマンドの-uオプションで，リポジトリ情報の有効期間を確認してください。

有効期限の更新が必要なリポジトリ情報は，アプリケーションでMQI命令（MQOPEN命令，MQPUT命令，またはMQPUT1命令）を発行してください。

定義

次の環境変数をリポジトリ管理サーバユーザサービス定義ファイル（$DCCONFPATH/mqrsup）に定義してください。

• リポジトリ情報送信通知メッセージの出力要否：DCMQA_MQR_REFRESH_REPORT

  この環境変数にYを指定した場合，最も早くに送信契機に達するリポジトリ情報に対してだけ，このメッセージが出力されます。

• リポジトリ情報送信通知メッセージの出力時間設定：DCMQA_MQR_REFRESH_REPORT_TIME

  リポジトリ情報送信時刻から換算してこの環境変数に指定した時間だけ前にKFCA31544-Iメッセージが出力されます。また，KFCA31544-Iメッセージで表示されたリポジトリ情報の送信後にKFCA31545-Iメッセージが出力されます。

  注意事項

  • リポジトリ管理サーバ（mqrsup）が停止している間はメッセージが出力されません。リポジトリ管理サーバ（mqrsup）停止中にDCMQA_MQR_REFRESH_REPORT_TIMEに指定した出力契機に達した場合，リポジトリ管理サーバ（mqrsup）を再起動したときにDCMQA_MQR_REFRESH_REPORT_TIMEで指定した時刻より短い時間でメッセージが出力されます。

  • DCMQA_MQR_REFRESH_REPORTの指定値をYからNへ変更しリポジトリ管理サーバ（mqrsup）を再起動した場合，オペランド変更前に出力されたKFCA31544-Iメッセージは引き継がれません。オペランドを再度NからYに変更した場合に，DCMQA_MQR_REFRESH_REPORT_TIMEに指定した出力契機に達したリポジトリ情報に対して，再度KFCA31544-Iメッセージが出力されます。

  • KFCA31544-Iメッセージ出力後，リポジトリ情報送信前にKFCA31544-Iメッセージで表示されたリポジトリ情報が削除された場合，KFCA31545-Iメッセージは出力されません。

  • 次の条件のどれかに一致するリポジトリ情報に対してだけ，KFCA31544-IおよびKFCA31545-Iメッセージが出力されます。

    ・クラスタ状態がJOINでフルリポジトリキューマネジャが存在する場合

    ・クラスタ状態がREFRESHの場合

    ・クラスタ状態がBINDINGの場合（ただし，mqrremoveコマンドの-sオプション実行後にクラスタ状態がBINDINGとなった場合）

  • KFCA31544-Iメッセージ出力後，かつKFCA31545-Iメッセージ出力前にOpenTP1を停止させた場合，OpenTP1再起動後のリポジトリ管理サーバ（mqrsup）開始時に，以前と同じリポジトリ情報に対して再度KFCA31544-Iメッセージが出力されます。

  • リポジトリ情報の有効期限を定期的（1時間間隔）に確認しているため，KFCA31544-IメッセージはDCMQA_MQR_REFRESH_REPORT_TIMEで指定した時間より最大で１時間遅れて出力される場合があります。

    また，KFCA31545-Iメッセージは，KFCA31544-Iメッセージで表示されたリポジトリ情報の送信までの時間より最大で１時間遅れて出力される場合があります。DCMQA_MQR_REFRESH_REPORT_TIMEオペランドには１時間の遅れを考慮した値を指定するようにしてください。

  • DCMQA_MQR_REFRESH_REPORT_TIMEの値を以前の値とは異なる値に変更した場合，リポジトリ管理サーバ（mqrsup）を再起動してから有効となりますが，オペランド変更前に出力されたKFCA31544-Iメッセージは引き継がれません。新しく指定した値（時刻）で再度KFCA31544-Iメッセージが出力されます。

各リポジトリ情報の保持期間と，リポジトリ情報の送信契機を次に示します。

表2‒19　リポジトリ情報の保持期間と情報送信契機

リポジトリ情報名称	保持期間	情報送信契機
ローカルキューマネジャ情報 （自キューマネジャに存在するクラスタレシーバチャネル情報）	90日※1	27日
ローカルキュー情報 （自キューマネジャに存在するクラスタキュー情報）	90日※1	27日
リモートキューマネジャ情報 （リモートのキューマネジャに存在するクラスタレシーバチャネル情報） （送信しない）	60〜90日※2	なし
リモートキュー情報 （リモートのキューマネジャに存在するクラスタキュー情報） （送信しない）	60〜90日※2	なし
システム用問い合わせ情報	無期限	27日
問い合わせ情報 （キューマネジャ，キューマネジャ識別子，キュー）	30日	27日※3

(j)　クラスタチャネル

クラスタを使用すればチャネルを定義する必要がなくなりますが，分散キューイングで使われているのと同じチャネル技術が，クラスタのキューマネジャ間の通信に使用されています。次に示すことを理解しておいてください。

• チャネルの動作方法

  「2.8.9　クラスタ環境の通信構成」を参照してください。

• チャネルのステータスの見つけ方

  6章の「mqtlscha（チャネルの状態表示）」を参照してください。

• メッセージ編集出口の使い方

  「3.　ユーザオウンコーディング」を参照してください。

(k)　IBM MQでSUSPEND QMGRコマンドを実行した場合

IBM MQのキューマネジャにSUSPEND QMGRコマンドを実行した場合，ワークロード管理機能は，該当するキューマネジャに対して，そこで処理する必要のあるメッセージだけを送信するようになります。その後，RESUME QMGRコマンドを実行すると，ワークロード管理機能は通常の動作に戻ります。