JP2002202953A - プロセス障害またはシステム障害後の回復 - Google Patents

Abstract

(57)【要約】 【課題】 関連グループ内のリモート通信マネージャと
通信マネージャ・セットの間の通信を管理する方法、デ
ータ通信機器、およびコンピュータ・プログラムを提供
すること。 【解決手段】 通信マネージャ・グループはリソースに
共用アクセスが可能であり、グループ内のどの通信マネ
ージャも、グループ内の別の通信マネージャで発生した
障害を回復することが可能となる。具体的には、障害の
発生したインバウンド・チャネルおよびアウトバウンド
・チャネルの回復が達成され、データ送信の可用性が向
上する。好ましくは、その回復に同期情報を使用して、
データが整合性のある状態に回復されるようにし、した
がってデータの完合性を失うことなくチャネルの回復が
達成される。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、データ通信ネット
ワークにおけるプロセス障害またはシステム障害後の回
復に関し、詳細には、可用性を向上させるため、障害が
発生したプロセスまたはサブシステム以外のプロセスま
たはサブシステムによる回復に関する。

【０００２】

【従来の技術】既存の多くのメッセージ・システムは、
単一のメッセージ・マネージャを使用して、リモート・
システム宛てのすべてのメッセージの送信の管理をロー
カル・システムから行い、また、ローカル・システム宛
てのすべてのメッセージの受信を処理する。リモート・
システムへのメッセージの送信を必要とするローカル・
システム上で実行される適用業務プログラムは、ローカ
ル・メッセージ・マネージャに接続し、ローカル・メッ
セージ・マネージャに、必要とされる宛先へメッセージ
を送信するよう要求する。これは、すべての通信に関し
て、単一のメッセージ・マネージャの可用性に依拠して
いることを暗示している。このようなメッセージ・マネ
ージャに影響するいかなる障害も、通信が再開できるよ
うになる前に、メッセージ・マネージャの完全なロール
バックとリスタートが必要となるため、メッセージ交換
のスループットに重大な影響を与える。

【０００３】データ処理環境での複数のデータ処理シス
テムのいずれによってもメッセージを処理することので
きるシステムを提供することは、米国特許第５７９７０
０５号および第５８８７１６８号で知られている。複数
のデータ処理システムの１つによって処理される着信メ
ッセージを格納するために共用キューが設けられる。一
般のキュー・サーバが、メッセージを受信し共用キュー
に入れるので、メッセージを処理するための使用可能な
容量を持つシステムによるメッセージの検索が可能であ
る。使用可能な容量を持つシステムは、キュー・メッセ
ージを検索し、必要な処理を実行し、適切な応答メッセ
ージを共用キュー上に戻す。したがって、共用キュー
は、処理を要求するクライアントと処理を実行するデー
タ処理システムの間でどちらかの方向に送信されるメッ
セージを格納する。メッセージは、共用キュー上に入る
ので、そのキューへアクセス可能な複数のシステムのう
ちのどのシステム上で稼動するアプリケーションによっ
ても処理することができる。冗長性を共用しそれを処理
する自動ワークロードが、この構成によって提供され
る。メッセージを処理中の特定のアプリケーションに障
害が発生した場合、別のアプリケーションが、共用キュ
ーからそのメッセージを検索し、クライアントが元のア
プリケーションがリスタートするのを待つ必要なく処理
を実行する。

【０００４】米国特許出願第６０／２２０６８５号（整
理番号ＧＢ９−２０００−０３２）は、本出願人に譲渡
され、参照により本明細書に組み込むが、通信リンク障
害またはキューイング・サブシステムの障害を原因とす
るキューイング・サブシステムと共用キューの間の接続
障害からの回復の改善を開示している。共用キュー内の
メッセージ・データは、結合機能内に含まれるデータ構
造によって、メッセージ・キューイング・サブシステム
間で通信される。結合機能への接続障害は、障害が発生
したキューイング・サブシステム以外のキューイング・
サブシステムへ通知され、これらのキューイング・サブ
システムは、その後、障害が発生したサブシステムのア
クティブ作業単位の回復をそれらの間で分担する。

【０００５】米国特許出願第６０／２２０６８５号の解
決法は、キューイング・サブシステム・グループ内での
トランザクションの回復を大幅に改善するが、進行中の
通信に影響を与える障害が発生した場合に、キューイン
グ・サブシステム・グループの外部の通信マネージャと
の通信をどのように再開するかの問題には対処していな
い。

【０００６】

【発明が解決しようとする課題】本発明の目的は、関連
グループ内のリモート通信マネージャと通信マネージャ
・セットの間の通信を管理する方法、データ通信機器、
およびコンピュータ・プログラムを提供することであ
る。

【０００７】

【課題を解決するための手段】本発明の第１の態様によ
れば、通信マネージャ・セットとリモート通信マネージ
ャの間の通信を管理する方法であって、データ・ストレ
ージ・リポジトリからリモート通信マネージャへデータ
を送信するために、通信マネージャ・セットの第１の通
信マネージャとリモート通信マネージャの間の通信チャ
ネルを始動するステップであって、前記データ・ストレ
ージ・リポジトリが、通信マネージャ・セットのいずれ
の通信マネージャからもアクセス可能であるステップ
と、通信マネージャ・セットのいずれの通信マネージャ
からもアクセス可能なストレージ・リポジトリ内に、通
信チャネルの状態情報を格納する（データがそこから送
信されるデータ・ストレージ・リポジトリと同一の可能
性がある）ステップと、第１の通信マネージャに影響を
与える障害に応答して、通信マネージャ・セットの第２
の通信マネージャが、格納されたチャネル状態情報を使
用して新しいチャネル・インスタンスを始動し、新しい
チャネル・インスタンスを介して、データ・ストレージ
・リポジトリからリモート通信マネージャへのデータ送
信を再開するステップとを含む方法が提供される。

【０００８】本発明は、通信リソース（格納されたデー
タおよび通信メカニズム）への共用アクセスを使用し
て、関連通信マネージャ・グループに属する通信マネー
ジャが、リモート通信マネージャとの通信の障害から回
復し、それによって、データ送信の可用性の向上を達成
することを可能にする。可用性の向上というこの利点
は、冗長リソース・マネージャを利用することなく、達
成される。この冗長リソース・マネージャは、従来技術
において、通常、障害のない場合は使用されないが、関
連リソース・マネージャとの整合性を保つことが必要と
される。このような冗長性の維持は、コストがかかる。

【０００９】格納されたチャネル状態情報は、現在チャ
ネルの制御権をもっている通信マネージャの識別を含む
ことが好ましい。さらに、状態情報は、（例えば、障害
が発生したときに、チャネルが、実行中であるか、実行
を試みているか、それとも停止中であるかを示す）チャ
ネルの状況の指示を含むことが好ましい。これにより、
グループ内の各アクティブ通信マネージャは、第１の通
信マネージャに問題が発生したとき、どのチャネルが回
復され、それらがどのような状態に回復されるべきかを
決定することができる。

【００１０】チャネルに関する格納された情報はまた、
他の通信マネージャによる同期回復を可能にする、チャ
ネルを介したデータ送信のための同期データを含むこと
が好ましい。この同期データは、状態情報の一部であっ
ても、状態情報とは別に格納してもよい。

【００１１】通信マネージャ・セットの各通信マネージ
ャは、アクティブな各チャネルに関するチャネル定義の
コピーへのアクセス権を保持する、またはアクセスが可
能であることが好ましく、それを格納された状態情報と
共に使用して、第１の通信マネージャ以外の通信マネー
ジャが新しいチャネル・インスタンスを始動し、データ
送信を再開することができる。

【００１２】通信障害から回復するための好ましい方法
は、チャネルの第１のインスタンスが第１の通信マネー
ジャによって実際に使用されている間に、通信チャネル
の第２のインスタンスが始動されるのを防止する（例え
ば、ロックを使用する）ステップと、第１の通信チャネ
ル・インスタンスに障害が発生したという判定に応答し
て、チャネル定義および現チャネル状態情報を使用し
て、チャネルの第２のインスタンスを始動するステップ
と、第２のチャネル・インスタンスを使用してデータを
送信するステップとを含む。複数の同時チャネル・イン
スタンスを回避すると、リソース更新の競合の回避かつ
簡単になるだけでなく、例えば、リモート通信マネージ
ャが、多大な関連接続料金を伴う外部サービス・プロバ
イダである場合に、複数接続に要する費用の回避にも有
利となる可能性がある。

【００１３】データ・ストレージ・リポジトリは、共用
アクセス・メッセージ・キューであることが好ましい。
複数の通信マネージャは、１つまたは複数のメッセージ
・キュー（以後、「キュー共用グループ」と呼ぶ）への
共用アクセスが可能であるキュー・マネージャ・グルー
プ、またはそのようなキュー・マネージャ内のまたはそ
のようなキュー・マネージャに関連した通信マネージャ
のコンポーネントであることが好ましい。あるいは、通
信マネージャは、通信管理動作を行う任意のコンピュー
タ・プログラムまたはデータ処理システムのコンポーネ
ントとすることもできる。

【００１４】好ましい実施形態によれば、本発明は、第
１のキュー・マネージャに障害が発生したとき、キュー
共用グループ内のキュー・マネージャ（またはそれらの
関連通信マネージャ・コンポーネント）が、共用キュー
からメッセージ送信を引き継ぐことを可能にする。障害
が発生したチャネルの新しいインスタンスが、チャネル
定義パラメータおよび現チャネル状態情報を使用して始
動される。キュー共用グループ内のキュー・マネージャ
によるこのような「対等な」回復によって、メッセージ
送信の可用性が向上する。

【００１５】本発明の好ましい実施形態によれば、発信
メッセージ送信の障害からの回復は以下のようにして達
成される。キュー共用グループ内の各キュー・マネージ
ャは、共用発信メッセージ・キューにアクセス可能であ
る。これらのキュー・マネージャはそれぞれ（あるい
は、その通信マネージャ・コンポーネントは）、共用キ
ューと宛先キュー・マネージャの間の送信側チャネルの
定義のコピーを備えており、したがってキュー共用グル
ープ内の各キュー・マネージャ（あるいは、その通信マ
ネージャ・コンポーネント）は、チャネルのインスタン
スを始動することができる。常に、単一のチャネル・イ
ンスタンスのみがアクティブとなることができる。チャ
ネルがアクティブであるときは常に、そのチャネルの状
態情報が格納され、そのような状態情報のサブセット
が、キュー共用グループ内のいずれのキュー・マネージ
ャにも使用できるように、共用アクセス・ストレージ内
に保持される。チャネルを使用中のキュー・マネージャ
に障害が発生した場合、キュー共用グループ内の別のキ
ュー・マネージャまたは通信マネージャ・コンポーネン
トが、共用アクセス・ストレージ内に保持された状態情
報とチャネル定義のコピーとを使用して、チャネルの新
しいインスタンスを始動する。これによって、キュー・
マネージャは、障害が発生したキュー・マネージャの代
わりに、メッセージの送信を続行する。

【００１６】本発明の第２の態様によれば、本発明は、
通信マネージャ・セットのいずれの通信マネージャから
もアクセス可能なデータ・ストレージ・リポジトリと、
データ・ストレージ・リポジトリからリモート通信マネ
ージャにデータを送信するために、各通信マネージャ
が、通信チャネルのインスタンスを始動するように適合
された通信マネージャ・セットであって、各通信マネー
ジャが、前記通信チャネルを介してデータを送信するよ
うに適合された通信マネージャ・セットと、通信チャネ
ルの現状態情報を格納するストレージ・リポジトリであ
って、通信マネージャ・セットのいずれの通信マネージ
ャからもアクセス可能なストレージ・リポジトリとを備
え、通信マネージャ・セットが、通信チャネルの第１の
アクティブ・インスタンスを持つ前記通信マネージャ・
セットの第１の通信マネージャに影響を与える障害に応
答して、格納された現チャネル状態情報を使用してチャ
ネルの第２のインスタンスを始動し、第２のチャネル・
インスタンスを介して、データ・ストレージ・リポジト
リからリモート通信マネージャへのデータ送信を再開す
る、データ通信システムを提供する。

【００１７】本発明の第３の態様によれば、本発明は、
通信マネージャ・セットとリモート通信マネージャの間
の通信を管理する方法の諸ステップを実行するために稼
動する、データ通信機器の操作を制御するためのコンピ
ュータ読み取り可能プログラム・コードを備え、前記の
方法が、データ・ストレージ・リポジトリからリモート
通信マネージャへデータを送信するために、通信マネー
ジャ・セットの第１の通信マネージャとリモート通信マ
ネージャの間の通信チャネルを始動するステップであっ
て、前記データ・ストレージ・リポジトリが、通信マネ
ージャ・セットのいずれの通信マネージャからもアクセ
ス可能であるステップと、通信マネージャ・セットのい
ずれの通信マネージャからもアクセス可能なストレージ
・リポジトリ（データがそこから送信されるデータ・ス
トレージ・リポジトリと同じでもよい）内に、通信チャ
ネルの状態情報を格納するステップと、第１の通信マネ
ージャに影響を与える障害に応答して、通信マネージャ
・セットの第２の通信マネージャが、格納されたチャネ
ル状態情報を使用して新しいチャネル・インスタンスを
始動し、新しいチャネル・インスタンスを介して、デー
タ・ストレージ・リポジトリからリモート通信マネージ
ャへのデータ送信を再開するステップとを含む、コンピ
ュータ・プログラムを提供する。

【００１８】本発明の他の態様によれば、インバウンド
通信フローは、通信マネージャ・セットのいずれの通信
マネージャによっても受け入れられ、これらの通信マネ
ージャのいずれも、通信マネージャ・セット内で、以前
はメッセージを受信していたがもはや受信できない他の
通信マネージャと自動的に置き換わることができる。イ
ンバウンド通信チャネルおよびアウトバウンド通信チャ
ネルの対等な回復は、リモート通信マネージャにとって
透過的であって、リモート通信マネージャには通信マネ
ージャ・セットが単一エンティティに見えることが好ま
しい。

【００１９】本発明のこの態様による好ましい実施形態
は、通信マネージャ・セットとリモート通信マネージャ
の間の通信を管理する方法を含み、この方法は、リモー
ト通信マネージャからデータを受信するために、通信マ
ネージャ・セットの第１の通信マネージャとリモート通
信マネージャの間の通信チャネルの第１のインスタンス
を始動するステップと、チャネルの第１のインスタンス
が第１の通信マネージャによって使用されている間に、
通信チャネルの第２のインスタンスが始動されるのを防
止するステップと、第１の通信マネージャに影響を与え
る障害の後、リモート通信マネージャからのチャネル始
動要求に応答して、通信マネージャ・セットの第２の通
信マネージャとリモート通信マネージャの間のチャネル
の第２のインスタンスを始動し、新しいチャネル・イン
スタンスを介して、リモート通信マネージャからのデー
タ送信を再開するステップとを含む。

【００２０】本発明の他の態様によれば、通信マネージ
ャ・セットのいずれの通信マネージャからもアクセス可
能なデータ・ストレージ・リポジトリと、データ・スト
レージ・リポジトリからリモート通信マネージャへデー
タを送信するために、各通信マネージャが、通信チャネ
ルのインスタンスを始動するように適合された通信マネ
ージャ・セットであって、各通信マネージャが、前記通
信チャネルを介してデータを送信するように適合された
通信マネージャ・セットと、前記通信チャネルを介した
データ送信の同期情報を格納するストレージ・リポジト
リであって、通信マネージャ・セットのいずれの通信マ
ネージャからもアクセス可能であるストレージ・リポジ
トリとを備え、通信マネージャ・セットが、通信チャネ
ルの第１のアクティブ・インスタンスを持つ前記通信マ
ネージャ・セットの第１の通信マネージャに影響を与え
る障害に応答して、前記格納された同期情報を使用し
て、前記第１の通信マネージャのデータ送信を整合性の
ある状態に回復し、それによって、データ・ストレージ
・リポジトリからリモート通信マネージャへのデータ送
信の再開を可能にする、データ通信システムが提供され
る。

【００２１】次に、本発明の実施形態について、添付の
図面を参照しながら、例によって詳しく説明する。

【００２２】

【発明の実施の形態】分散メッセージ・キューイング・
プログラム間通信では、メッセージ・データは、適用業
務プログラムによって呼び出されるインターフェース・
コールを介して適用業務プログラムとインターフェース
するメッセージ・キュー・マネージャを用いて、適用業
務プログラム間で送信される。メッセージ・キュー・マ
ネージャは、メッセージ・キューイング・プログラム間
通信で使用されるリソース・セットを管理する。これら
のリソースには通常、次のものが含まれる。 ・オブジェクト定義（キュー定義を含む）およびメッセ
ージ・データを保持するページ・セット。 ・キュー・マネージャ障害が発生した場合に、メッセー
ジの回復に使用されるログ。 ・プロセッサ・ストレージ。 ・異なるアプリケーション環境からメッセージ・キュー
・マネージャＡＰＩにアクセスするための接続。 ・同一および他のシステム上のキュー・マネージャ間に
おける通信を可能にする、キュー・マネージャ・チャネ
ル・イニシエータ。これについては、後で詳しく説明す
る。

【００２３】キュー・マネージャは、ソフトウェアで実
装することが好ましい。ＩＢＭ社のＯＳ／３９０オペレ
ーティング・システム上で稼動するデータ処理システム
などある種の環境では、キュー・マネージャは、ログに
ついての情報を保持し、オブジェクト定義およびメッセ
ージ・データ（ページ・セットに格納される）を保持す
るオペレーティング・システム・データ・セットを使用
して、名前付きサブシステムとして稼動することができ
る。適用業務プログラムは、そのサブシステム名を使用
して、キュー・マネージャに接続することができる。

【００２４】例として、ＩＢＭ社のＭＱＳｅｒｉｅｓ製
品によって実装されるような分散メッセージ・キューイ
ング環境では、図１に示すように、送信側適用業務プロ
グラム１０が、ローカル・キュー・マネージャ２０によ
って管理されるローカル・キューにメッセージを入れ
る。目標適用業務プログラムもローカル・システム上に
ある場合、ローカル・キューがメッセージの宛先キュー
であり、アプリケーションは、メッセージを処理する準
備ができたときにこのキューからメッセージを検索す
る。目標適用業務プログラムが送信側から離れている場
合、ローカル・キューは送信キュー８０であり、キュー
・マネージャ・ネットワークは、ネットワークを介し
て、リモート・キュー・マネージャ４０によって管理さ
れるリモート宛先キュー３０へのメッセージの送信を処
理する。送信キューは、メッセージが正常に他のキュー
・マネージャへ送信され、そこへ格納されるまでメッセ
ージを格納する、特殊なタイプのローカル・キューであ
る。キュー・マネージャは、異種システム間の相互運用
性および１つ以上の中間キュー・マネージャを介したメ
ッセージの送信を含めて、複雑なネットワーク通信を処
理する。リモート目標適用業務プログラム５０は、準備
ができたとき、宛先キュー３０（入力キュー）からメッ
セージを検索する。

【００２５】メッセージは、２つのキュー・マネージャ
間の単方向通信リンクであるチャネル６０を介してキュ
ー・マネージャ間で送信される。メッセージの送受信を
処理するソフトウェアを、メッセージ・チャネル・エー
ジェント（ＭＣＡ）７０と呼ぶ。キュー・マネージャＱ
Ｍ１からキュー・マネージャＱＭ２へメッセージを送信
するために、キュー・マネージャＱＭ１上の送信メッセ
ージ・チャネル・エージェント７０は、適切な送信キュ
ーおよびチャネル定義を使用して、キュー・マネージャ
ＱＭ２への通信リンクをセットアップする。受信メッセ
ージ・チャネル・エージェント７０'は、キュー・マネ
ージャＱＭ２上で起動され、通信リンクからメッセージ
を受信する。送信ＭＣＡ７０、通信リンク、および受信
ＭＣＡ７０'からなるこの単方向パスがチャネル６０で
ある。送信ＭＣＡ７０は、送信キュー８０からメッセー
ジを取り出し、チャネルを介して受信ＭＣＡ７０'へ送
信する。受信ＭＣＡ７０'は、メッセージを検索し、宛
先キュー３０、３０'に入れる。

【００２６】図１に、キュー・マネージャ、送信キュ
ー、チャネル、ＭＣＡの間のこれらの関係を示す。

【００２７】本発明の好ましい実施形態によれば、特定
のキュー・マネージャに関連する送信ＭＣＡおよび受信
ＭＣＡはすべて、キュー・マネージャの制御下でアドレ
ス空間を使用する、チャネル・イニシエータ・コンポー
ネント（または、「ムーバ（mover）」）内部で稼動す
ることができる。したがって、他のキュー・マネージャ
との通信を管理するのは、チャネル・イニシエータであ
る。キュー・マネージャに接続されるのは、単一のチャ
ネル・イニシエータのみである。同一チャネル・イニシ
エータ内部では、多くのＭＣＡプロセスが同時に実行さ
れることが可能である。チャネルは、きっかけとなる基
準を満たす、送信キュー上のメッセージの到着に応答し
て、チャネル・イニシエータによって動的に始動され
る。

【００２８】図２を参照すると、キュー共用グループ１
００は、同一のメッセージ・キューイング・オブジェク
ト定義およびメッセージ・データにアクセス可能な、
（例えば、単一のＯＳ／３９０シスプレックス内で稼動
する）複数のキュー・マネージャ１１０、１２０、１３
０である。単一の総称アドレスが、グループ内のどのキ
ュー・マネージャへの接続にも使用できるので、ネット
ワーク内の他の場所にあるキュー・マネージャには、キ
ュー共用グループは単一エンティティに見える。キュー
共用グループ１００内の各キュー・マネージャは、総称
アドレスに論理的に関連するアドレス上のインバウンド
・セッション要求に従う。

【００２９】キュー共用グループ内では、共用可能なオ
ブジェクト定義が共用データベース１４０（ＩＢＭ社の
ＤＢ２データベースなど）内に格納され、共用キュー内
のメッセージは、１つまたは複数の結合機能１５０（例
えば、ＯＳ／３９０結合機能リスト構造）内に保持され
る。共用データベース１４０および結合機能構造１５０
は、複数のキュー・マネージャ１１０、１２０、１３０
の間で共用されるリソースである。結合機能は、専用の
電源装置上で稼動し、ソフトウェア障害、ハードウェア
障害および電源異常を迅速に復旧するように構成するこ
とができ、それによって、格納されたメッセージの可用
性を向上することができる。

【００３０】キュー共用グループのキュー・マネージャ
とそのリソースは、メッセージの送信が単一のキュー・
マネージャの可用性に依存しない形で関連付けられてい
る。キュー共用グループのいずれのキュー・マネージャ
も、以前はメッセージを送信していたがもはや送信でき
ない他のキュー・マネージャと自動的に置き換わること
ができる。あるキュー・マネージャで障害が発生したと
き、オペレータまたはアプリケーションが介入なしにメ
ッセージ送信が再開される。

【００３１】さらに、インバウンド・メッセージ・フロ
ーもまた、キュー共用グループのいずれのキュー・マネ
ージャによっても受け入れられ、これらのキュー・マネ
ージャのいずれも、グループ内で、以前はメッセージを
受信していたがもはや受信できない他のキュー・マネー
ジャと自動的に置き換わることができる。

【００３２】したがって、独立型キュー・マネージャに
よって可能となるよりも確実なアウトバウンド／インバ
ウンド・メッセージ・サービスが実現する。これについ
ては、図２〜５を参照しながら、以下に詳しく説明す
る。

【００３３】キュー共用グループ内で、送信キュー１６
０は、グループ内のキュー・マネージャ１１０、１２
０、１３０によって共用される可能性がある。キュー共
用グループのどのキュー・マネージャも、共用送信キュ
ー１６０にアクセスしてメッセージを検索し、それをリ
モート・キュー・マネージャ１８０へ送信することがで
きる。

【００３４】送信側チャネルは、特定の送信キュー上に
あるメッセージをリモート・キュー・メッセージへ送信
するように定義される。共用送信側チャネルは、共用送
信キュー上にあるメッセージを送信するように定義され
たチャネルである。通常、同一の共用送信側チャネル定
義１９０が、キュー共用グループ内のすべてのキュー・
マネージャ上に存在し、これらのキュー・マネージャの
いずれによるチャネルのインスタンスの始動も可能とな
る。

【００３５】チャネルの実行を可能とするために、チャ
ネルについての様々な情報（状態情報）が格納されてい
る。この状態情報のサブセットは、共用チャネルの共用
リポジトリ２００内に保持される（つまり、キュー共用
グループのいずれのキュー・マネージャからもアクセス
可能である）。この共用リポジトリ２００は、共用チャ
ネル状況テーブルとして知られ、それに含まれる情報に
は、情報の最終更新時、チャネル名、送信キュー名（イ
ンバウンド・チャネルの場合は空白）、リモート・キュ
ー・マネージャ名（チャネルの接続相手）、所有キュー
・マネージャ（チャネル・インスタンスを実行中）、チ
ャネル・タイプ（例えば、送信側か受信側か）、チャネ
ル状況（実行中、停止など）、リモート・マシン・アド
レスがあり、また、実装に固有の他の状態情報が含まれ
る可能性もある。

【００３６】障害が発生した場合、共用チャネル状況テ
ーブルから、現在障害が発生しているキュー・マネージ
ャとチャネル・イニシエータの対によってどのチャネル
が実行されていたか判定することができ、複数のキュー
・マネージャが回復プロセスを実行する場合、回復の調
整を行うことができる。これについては、以下に詳しく
説明する。

【００３７】このテーブル内のどのチャネル状況エント
リの更新も、比較交換論理によってしか行うことができ
ない。つまり、更新の後に要求されるエントリ（変更後
イメージ）、ならびに更新前のエントリの値（変更前イ
メージ）が、提供されなければならない。そうでない場
合は、更新の試みが拒否されることになる。変更前イメ
ージがテーブル内にある場合、変更前イメージは、変更
後イメージと置き換えられる。そうでない場合は、変更
は発生しない。

【００３８】キュー共用グループからの可用性の高いメ
ッセージ送信は、以下のようにして達成される。

【００３９】上記に述べたように、チャネル・イニシエ
ータ２５は、メッセージ送信を管理するキュー・マネー
ジャ２０の一部である。１つのキュー・マネージャに対
して１つのチャネル・イニシエータがあるので、キュー
共用グループは、キュー・マネージャとチャネル・イニ
シエータの対を複数有する（図２でＸ、Ｙ、Ｚとして示
す）。これらの各対は、キュー共用グループ内で稼動す
る共用チャネルに関する情報を保持する共用リソースに
アクセスすることができる。１つのチャネル・イニシエ
ータのみが、常に、共用送信キュー１６０からのメッセ
ージ送信を管理し、その送信キュー１６０の送信側チャ
ネル・インスタンス１７０のみを使用する。このチャネ
ル・インスタンスがアクティブである間、共用送信キュ
ーは、チャネル・インスタンスを管理するチャネル・イ
ニシエータ２５によってロックされる（ロックが保持さ
れている間、他のチャネル・イニシエータは、キューか
らメッセージを検索しない）。エントリが、チャネル・
インスタンスの共用チャネル状況テーブル２００内に作
成され、チャネルがアクティブであることを反映するよ
うに更新され、チャネルを管理するチャネル・イニシエ
ータ２５の名前（関連キュー・マネージャ２０の名前で
もある）も格納される。送信キュー１６０は共用である
ので、キュー共用グループ内のキュー・マネージャとチ
ャネル・イニシエータのいずれの対も、現在チャネル・
インスタンスが実行されていない共用キューからメッセ
ージを送信するチャネル・インスタンスを実行すること
ができる。

【００４０】メッセージは、キュー共用グループから
（キュー共用グループのキュー・マネージャではない）
リモート・キュー・マネージャへ、以下のように転送さ
れる。キュー共用グループのチャネル・イニシエータの
１つ、たとえばＸが、キュー・マネージャ１８０のリモ
ート・チャネル・イニシエータＲへのチャネル・インス
タンス１７０を実行する。チャネル定義１９０は、リモ
ート・チャネル・イニシエータにどう接触するか、およ
びチャネルを介して送信するためにどの共用アクセス送
信キューからメッセージを検索するかについて詳述す
る。それによると、チャネル１７０は、ＸとＲの間の通
信リンクであり、送信キュー１６０上にあるメッセージ
の送信に使用される。チャネル・イニシエータＸは、そ
の関連キュー・マネージャ・コンポーネントＸに、送信
キュー１６０（図２のsxmitq）からメッセージを検索す
るよう要求し、これらのメッセージは、チャネルを介し
てそれらを送信するチャネル・イニシエータＸへ引き渡
される。リモート・チャネル・イニシエータＲは、メッ
セージを受け取り、その関連キュー・マネージャＲにメ
ッセージを引き渡し、関連キュー・マネージャＲは、ア
クセス可能な宛先キュー２１０にメッセージを入れる。

【００４１】４つの障害シナリオが検出され処理され
る。 ・共用チャネル状況テーブル接続障害（共用チャネル状
態の更新ができない）。 ・通信サブシステム障害（リモート・システムと通信で
きない）。 ・チャネル・イニシエータ障害。 ・キュー・マネージャ障害。

【００４２】障害シナリオ１および２は、チャネル・イ
ニシエータによって処理され、チャネル・イニシエータ
は、送信キューのロックを解除し、ワークロード・バラ
ンシング・テクニックを使用して選択される適切なキュ
ー共用グループのキュー・マネージャに向けてチャネル
の始動要求を発行することにより、異なるキュー共用グ
ループのキュー・マネージャ上でチャネルを再始動する
よう定期的に試みる。適切なワークロード・バランシン
グ・テクニックは、当技術分野でよく知られている。キ
ュー共用グループのキュー・マネージャが、そのような
始動要求を受信すると、送信キュー上でロックの取得が
試みられ、それが成功すると、新しいチャネル・インス
タンスが始動し、必要に応じて共用状況テーブルが更新
され、メッセージ送信が再開する。

【００４３】本発明の好ましい実施形態によれば、チャ
ネル・イニシエータは、関連キュー・マネージャと対を
なして別のタスク（事実上、別のプログラム）として実
行されるので、チャネル・イニシエータ障害（シナリオ
３）は、キュー・マネージャ障害と関係なく発生する。
チャネル・イニシエータ障害が発生した場合、障害イベ
ントは、そのチャネル・イニシエータと対をなすキュー
・マネージャによってログされ、そのキュー・マネージ
ャがチャネル回復を処理する。対をなすキュー・マネー
ジャ、たとえばＸは、共用チャネル状況テーブルに照会
して、障害が発生したチャネル・イニシエータＸが管理
していたチャネル・インスタンスのすべてのエントリの
リストを取得する（つまり、障害が発生したキュー・マ
ネージャおよびチャネル・イニシエータの名前に設定さ
れている、所有キュー・マネージャおよびチャネル・イ
ニシエータ名を持つ、すべてのエントリ。これは、キュ
ー・マネージャとその関連チャネル・イニシエータが、
同一の名前を共用しているからである）。障害が発生し
たチャネル・イニシエータは依然として非アクティブで
あることが確認され、取得されたエントリのリストは、
チャネル・イニシエータ障害が発生した際に管理されて
いたチャネルのリストであることが保証される。次い
で、チャネルの状態とタイプを調べ、必要な回復アクシ
ョンを実行することによって、リスト内の各アウトバウ
ンド・チャネルが処理される。これにより、明示的に停
止したチャネルの状態が保存され（それには、チャネル
がさらにメッセージを転送することを許可される前に、
手動による始動コマンドの発行が必要）、実行中であっ
た、または実行を試みている過程にあったアウトバウン
ド・チャネルが始動され、他のエントリが（あれば）削
除される。各チャネルの所有権を取得する試みが行われ
る。つまり、関係のある共用チャネル状況エントリが、
前記の比較交換論理を使用して、不良チャネルのリスト
内のイメージに設定された変更前イメージ、および回復
を実行するキュー・マネージャ名を含む変更後イメージ
で更新される。対をなすキュー・マネージャＸによる自
己回復のシナリオでは、共用チャネル状況テーブルのエ
ントリのこのような更新で、その名前は変更されないま
まで、障害時に実行されていたチャネルの状態がそのチ
ャネルが回復中である（実行中ではない）ことを示すよ
うに変更される。第２に、所有権が正常に取得された
（つまり、この自己回復シナリオではそうなるはずであ
るが、更新が成功した）場合、キュー共用グループ内の
適切なキュー・マネージャに向けてチャネルの始動要求
が発行される。これによって、グループ内のアクティブ
・チャネル・イニシエータが新しいチャネル・インスタ
ンスを始動し、所有者をその所有名に更新し、状態を実
行中に更新する。この解決法では比較交換論理を使用す
るため、回復処理の重複が回避され、同一チャネルに対
して複数の始動要求が実行されることが防止される（例
えば、発行される要求セットの第１の要求が実行され、
後続の要求が、チャネルがすでに稼動していることを警
告するエラー・メッセージを作成する）。

【００４４】キュー・マネージャに障害が発生した場合
（シナリオ４）、これは必ず、対をなすチャネル・イニ
シエータにも障害が発生したことを意味する。これによ
って、現在アクティブなキュー共用グループのすべての
キュー・マネージャでログされている障害イベントがト
リガされる。これらの各キュー・マネージャ（Ｙおよび
Ｚ）は、対等な回復を実施するために、上記と同様の処
理に入る。複数のキュー・マネージャが回復を実行する
ときは、あるキュー・マネージャから発行されるチャネ
ルの所有権を取得する試みは失敗する。別のキュー・マ
ネージャがすでにエントリを処理し、所有キュー・マネ
ージャ名を変更しているからである。１つのチャネルに
対して１つの始動要求のみが実行されるが、異なるキュ
ー・マネージャは異なるチャネルを回復することができ
る。

【００４５】チャネル・イニシエータが始動すると、始
動チャネル・イニシエータについて（まだ回復されてい
ないチャネルが回復される）、次いで他の非アクティブ
なチャネル・イニシエータについて（始動チャネル・イ
ニシエータが、以前に実行されていたキュー共用グルー
プの他のチャネル・イニシエータの障害の後の、キュー
共用グループ内の最初のアクティブ・チャネル・イニシ
エータである場合）回復処理に入る。

【００４６】キュー共用グループへの可用性の高いイン
バウンド・メッセージ送信は、以下のようにして達成さ
れる。

【００４７】インバウンド・チャネルは、アウトバウン
ド・チャネルの回復と同時に回復されるが、そのエント
リは共用状況テーブルから削除される。チャネル障害時
に通信チャネルの送信側はキュー共用グループへの再接
続を試みるので、これによって、送信側リモート・キュ
ー・マネージャがキュー共用グループへの接続を再確立
することが可能になる。障害が発生したインバウンド・
チャネルの状態情報は、キュー共用グループ側で保持さ
れない（つまり、回復処理後、共用状況テーブルから削
除される）。したがって、新しいインバウンド・チャネ
ルを、キュー共用グループの残りのキュー・マネージャ
のいずれかによって確立することができる。情報を保持
するリソースは共用であり、保持される情報で、どのチ
ャネルがインバウンドか（チャネル・タイプを介し
て）、および現在障害が発生しているキュー・マネージ
ャおよびチャネル・イニシエータ上でどのチャネルが実
行されていたか（所有キュー・マネージャ名エントリを
介して）が識別されるので、インバウンド・チャネル状
態情報の削除は可能である。

【００４８】本発明の好ましい実施形態の他の重大な利
点は、チャネルの回復に加えて、チャネルを介して送信
中のデータも、同期した状態へ回復されることである。
本発明のこの同期回復の態様は、ローカル通信マネージ
ャとリモート通信マネージャの間の、メッセージのいか
なるトランザクション転送にも適用できる。これについ
ては、以下に詳しく説明する。

【００４９】トランザクション制御下で、ローカル・キ
ュー・マネージャとリモート・キュー・マネージャの間
でバッチでメッセージを送信することが、当技術分野で
知られている。同期情報がローカル同期キュー上に保持
され、このようなトランザクション制御を容易にする。
既知の解決法に伴う問題は、メッセージ転送中にリモー
ト・キュー・マネージャに障害が発生した場合、リモー
ト・キュー・マネージャ上に保持される同期情報が、ア
クセス不能となることである。これにより、障害が発生
したリモート・キュー・マネージャにメッセージが正常
に転送されたことを確認するのが困難になる。この問題
を図４に示す。

【００５０】本発明の一態様によれば、キューを共用す
るキュー・マネージャを共通の共用ストレージ機能（例
えば、結合機能）内に保持して、キュー・マネージャを
キュー共用グループ（ＱＳＧ）にグループ化する機能
が、この問題の解決に使用される。ＱＳＧの外部にある
クライアント・アプリケーションまたはクライアント・
キュー・マネージャが、チャネルを介して、ＱＳＧ内の
いずれのキュー・マネージャにも接続して、共用キュー
へメッセージを転送することができる。メッセージは、
トランザクション制御下でチャネルを介してバッチで転
送される。結合機能内に保持され、ＱＳＧ内のすべての
キュー・マネージャからアクセス可能な共用同期キュー
が、このトランザクション制御を容易にするために使用
される。これを図５に示す。ＱＳＧ内のキュー・マネー
ジャに障害が発生した場合、クライアント・アプリケー
ションまたはクライアント・キュー・マネージャは、Ｑ
ＳＧ内の残りのアクティブなキュー・マネージャへの接
続を再確立することができる。この別のキュー・マネー
ジャは、共用同期キューにアクセスできるので、相手と
のチャネルを再同期させることができる。これによっ
て、メッセージ転送が確保される。

【００５１】クライアント・キュー・マネージャを識別
する情報および最後に行われた作業単位を記録する識別
子を有する共用同期キュー（ＳＹＮＣＱ）上でメッセー
ジを記録することによって再同期が可能になる。

【００５２】ＱＳＧ内のキュー・マネージャの障害の
後、クライアントまたはクライアント・キュー・マネー
ジャは、最後のメッセージ群を再送信する必要があるか
否かを認識していない状態にある可能性がある。通常、
メッセージ転送に使用されていたチャネルは、障害が発
生すると、再試行の状態に入る。次の再試行で、クライ
アントまたはクライアント・キュー・マネージャとＱＳ
Ｇ内の残りのアクティブ・キュー・マネージャの間で、
接続が再確立される。セッションおよび接続の再確立中
に、ＱＳＧ内のこの別のキュー・マネージャが、共用Ｓ
ＹＮＣＱにアクセスして、認識される最後の良好な状態
を適切に判別し、送信済みの最後のメッセージ群を再送
信する必要があるかどうか、あるいは送信済みの最後の
メッセージ群がすでに受信され、トランザクションが正
常に処理されているかどうかを、クライアントまたはク
ライアント・キュー・マネージャに通知する。このよう
な再同期が行われると、そのチャネルを、次のメッセー
ジ転送に使用することができる。それ以降のどんな同期
情報も、引き続き共用ＳＹＮＣＱへ書き込まれ、ＱＳＧ
内のキュー・マネージャの今後の障害の際に使用される
ことになる。

【００５３】キュー共用グループが、ネットワークから
は単一エンティティに見えることに関連する、他の重大
な利点は、容量、拡張性、可用性、対障害性が大幅に高
まる可能性があることである。しかし、キュー共用グル
ープの外部のキュー・マネージャは、キュー共用グルー
プに属する単一のキュー・マネージャとの通信を望む場
合があり、また、単一エンティティとしてのグループと
の通信を望む場合もある。どちらのオプションも、以下
のようにして可能になる。

【００５４】各キュー・マネージャは、それに関連する
一義的ローカル名を持つ。外部キュー・マネージャ（Ｑ
Ｍ）は、キュー共用グループに属するキュー・マネージ
ャと直接通信することを望み、そのキュー・マネージャ
のみに関連するローカル・ポータルでの通信を目標とす
る。このような場合、外部キュー・マネージャに、キュ
ー・マネージャのローカル名が通知される。

【００５５】キュー共用グループは、グループ名によっ
て識別される。論理的な、総称ポータルが定義される。
外部キュー・マネージャがキュー共用グループへ接続す
ることを望む場合、外部キュー・マネージャ（ＱＭ）か
らの通信の目標となるのはこのポータルである。キュー
共用グループ内の各キュー・マネージャは、グループ・
ポータル（ＧＰ）を持ち、通信が確立される場合、それ
を介して、共用ＱＭ−ＱＳＧサービス・クラスが提供さ
れる。キュー共用グループ内の各キュー・マネージャの
各グループ・ポータルは、論理的に総称ポータルに接続
されている。外部キュー・マネージャは、通信する際、
総称ポータルを使用し、キュー共用グループのグループ
名を通知される。

【００５６】総称ポータルの使用によって、セッション
が、各キュー・マネージャのグループ・ポータルに割り
振られるようにするいくつかのメカニズムがある。これ
らについては、以下に簡単に説明するが、このアーキテ
クチャでは、どのような基礎テクノロジも使用できる。

【００５７】・ネームによる解決。外部ネーム・サービ
スが、可能性のあるすべてのグループ・ポータルを総称
ポータルにマップする。外部キュー・マネージャが総称
ポータルとの通信を望む場合、そのネームをネーム・サ
ービス・プロバイダに渡し、ネーム・サービス・プロバ
イダは、使用可能なグループ・ポータルの１つを返す。
その後、外部キュー・マネージャは、そのキュー・マネ
ージャとのセッションを明示的に確立する。

【００５８】・セッションの引き渡し。総称ポータルに
相当する物理ポータルとの通信リンクが確立される。こ
のセッションは、キュー共用グループ内の１つのキュー
・マネージャのグループ・ポータルの１つに渡される。

【００５９】・セッションの再確立。ＱＳＧの外部のキ
ュー・マネージャからＱＳＧ内のキュー・マネージャへ
のアウトバウンド・セッションが、ＱＳＧ内のキュー・
マネージャの障害によって失われた場合、ＱＳＧの外部
のキュー・マネージャのアウトバウンド・チャネルは、
再試行の状態に入る。次の再試行で、ＱＳＧ内の残りの
アクティブ・キュー・マネージャとの間で、セッション
が再確立される。

【００６０】従来技術の解決法によれば、ローカル・キ
ュー・マネージャは、１つまたは複数のリモート・キュ
ー・マネージャとのセッションを確立することができる
が、各リモート・キュー・マネージャは、ローカル・キ
ュー・マネージャにとって単一エンティティに見え、各
リモート・キュー・マネージャの機能は、それぞれ独立
にセッションの確立に使用することができ、リモート・
キュー・マネージャに障害が発生した場合、ローカル・
キュー・マネージャとリモート・キュー・マネージャの
間のセッションは失われる。

【００６１】キュー共用グループ内のキュー・マネージ
ャの導入によって、キュー・共用グループ（ＱＳＧ）内
のキュー・マネージャ・セットが、ネットワークにとっ
て単一エンティティに見えるようになる。これによっ
て、以下の点で、大幅な向上が可能となる。

【００６２】容量および拡張性：ＱＳＧ内のすべてのキ
ュー・マネージャが、ＱＳＧの外部のキュー・マネージ
ャとのセッションの確立に使用できる。

【００６３】可用性および対障害性：ＱＳＧ内のキュー
・マネージャに障害が発生した場合、そのキュー・マネ
ージャとＱＳＧの外部のキュー・マネージャの間のセッ
ションが失われ、ＱＳＧの外部のキュー・マネージャか
らのどのアウトバウンド・チャネルも再試行の状態に入
る。次の再試行で、続いて、ＱＳＧ内の残りのアクティ
ブ・キュー・マネージャとのセッションを確立すること
ができる。したがって、どのようなセッションの障害も
最小限に抑えることができる。

【００６４】上記に詳しく述べた各態様を組み込んだ本
発明の実施形態の方法ステップの概要を図３に示す。本
発明の異なる態様の上述の特徴の他のセットやサブセッ
トも本発明の範囲内に含まれることは、当業者には理解
されよう。

【００６５】図３は、回復可能な通信を管理する方法の
以下のステップを示す。

【００６６】ＱＳＧの第１のキュー・マネージャとリモ
ート・キュー・マネージャの間のチャネル・インスタン
スを始動し（３００）、チャネルを介してデータを送信
する。

【００６７】キュー共用グループ内の各キュー・マネー
ジャからアクセスできるように、アクティブ・チャネル
のチャネル定義を格納する（３１０）。

【００６８】第１のインスタンスがアクティブである間
に、第２のチャネル・インスタンスが始動されるのを防
止する（３２０）。

【００６９】共用アクセス・ストレージ内にチャネル状
態情報を記録する（３３０）。

【００７０】第１のキュー・マネージャまたはその通信
マネージャ・コンポーネントに障害が発生した場合、リ
モート・キュー・マネージャとＱＳＧ内の別のキュー・
マネージャの間で第２チャネル・インスタンスを始動す
る（３４０）。アウトバウンド・チャネルでは、新しい
インスタンスが、格納されたチャネル状態情報および格
納されたチャネル定義を使用する。ＱＳＧ内で使用可能
なキュー・マネージャが、共用アクセス同期キュー内の
情報を使用して、障害の発生したチャネルを回復し、障
害の発生した各アウトバウンド・チャネルの新しいアウ
トバウンド・チャネル・インスタンスを始動し、リモー
ト・キュー・マネージャからの始動要求に応答して、障
害の発生した各インバウンド・チャネルの新しいインバ
ウンド・チャネル・インスタンスを始動する。これによ
って、新しいチャネル・インスタンスを介してデータ送
信が続行される。

【００７１】まとめとして、本発明の構成に関して以下
の事項を開示する。

【００７２】（１）通信マネージャ・セットとリモート
通信マネージャの間の通信を管理する方法であって、デ
ータ・ストレージ・リポジトリからリモート通信マネー
ジャへデータを送信するために、通信マネージャ・セッ
トの第１の通信マネージャとリモート通信マネージャの
間の通信チャネルを始動するステップであって、前記デ
ータ・ストレージ・リポジトリが、通信マネージャ・セ
ットのいずれの通信マネージャからもアクセス可能であ
るステップと、通信マネージャ・セットのいずれの通信
マネージャからもアクセス可能なストレージ・リポジト
リ内に、通信チャネルの状態情報を格納するステップ
と、第１の通信マネージャに影響を与える障害に応答し
て、通信マネージャ・セットの第２の通信マネージャ
が、格納されたチャネル状態情報を使用して新しいチャ
ネル・インスタンスを始動し、新しいチャネル・インス
タンスを介して、データ・ストレージ・リポジトリから
リモート通信マネージャへのデータ送信を再開するステ
ップとを含む方法。 （２）前記アクセス可能なリポジトリ内に格納された状
態情報が、チャネルの制御を行う通信マネージャの識別
を含み、第１の通信マネージャに影響を与える障害の
後、第１の通信マネージャによって制御されるチャネル
の認識を可能とする、上記（１）に記載の方法。 （３）前記アクセス可能なリポジトリ内に格納された状
態情報が、チャネルの現状況を含む、上記（２）に記載
の方法。 （４）通信マネージャ・セットの各通信マネージャが、
前記通信マネージャ・セットの通信マネージャの各アク
ティブ・チャネルの定義を格納している、あるいは、各
通信マネージャから各アクティブ・チャネルの定義にア
クセス可能である、上記（１）ないし（３）のいずれか
一項に記載の方法。 （５）通信チャネルの第１のインスタンスが第１の通信
マネージャによって使用されている間に、通信チャネル
の第２のインスタンスが始動されるのを防止するステッ
プと、第１の通信チャネル・インスタンスに障害が発生
したという判定に応答して、チャネル定義および現チャ
ネル状態情報を使用して、チャネルの第２のインスタン
スを始動するステップと、第２のチャネル・インスタン
スを使用してデータを送信するステップとを含む、上記
（４）に記載の方法。 （６）通信マネージャ・セットが、キュー共用グループ
内のキュー・マネージャ・セットであり、キュー・マネ
ージャ・セットのいずれのキュー・マネージャからもア
クセス可能なデータ・ストレージ・リポジトリが、共用
アクセス・メッセージ・キューであり、そこからキュー
・マネージャ・セットのいずれのキュー・マネージャ
も、リモート・キュー・マネージャへ送信するメッセー
ジを検索することができる、上記（１）ないし（５）の
いずれか一項に記載の方法。 （７）通信マネージャ・セットのいずれの通信マネージ
ャからもアクセス可能なデータ・ストレージ・リポジト
リと、各通信マネージャが、データ・ストレージ・リポ
ジトリからリモート通信マネージャへデータを送信する
ために、通信チャネルのインスタンスを始動するように
適合され、各通信マネージャが、前記通信チャネルを介
してデータを送信するように適合された通信マネージャ
・セットと、通信チャネルの現状態情報を格納するスト
レージ・リポジトリであって、通信マネージャ・セット
のいずれの通信マネージャからもアクセス可能なストレ
ージ・リポジトリとを備えるデータ通信システムであっ
て、通信マネージャ・セットが、通信チャネルの第１の
アクティブ・インスタンスを持つ前記通信マネージャ・
セットの第１の通信マネージャに影響を与える障害に応
答して、格納された現チャネル状態情報を使用してチャ
ネルの第２のインスタンスを始動し、第２のインスタン
ス・チャネルを介して、データ・ストレージ・リポジト
リからリモート通信マネージャへのデータ送信を再開す
るデータ通信システム。 （８）前記通信チャネルを介したデータ送信の同期情報
を格納するストレージ・リポジトリを含み、前記ストレ
ージ・リポジトリが通信マネージャ・セットのいずれの
通信マネージャからもアクセス可能であり、通信マネー
ジャ・セットが、通信チャネルの第１のアクティブ・イ
ンスタンスを持つ前記通信マネージャ・セットの第１の
通信マネージャに影響を与える障害に応答して、前記格
納された同期情報を使用して、前記第１の通信マネージ
ャのデータ送信を整合性のある状態に回復し、それによ
って、データを失うことなくデータ・ストレージ・リポ
ジトリからリモート通信マネージャへのデータ送信の再
開を可能にする、上記（７）に記載のデータ通信システ
ム。 （９）通信マネージャ・セットが、キュー共用グループ
内のキュー・マネージャ・セットであり、前記マネージ
ャ・セットのいずれのマネージャからもアクセス可能な
データ・ストレージ・リポジトリが、キュー・マネージ
ャ・セットのいずれのキュー・マネージャも、そこから
リモート・キュー・マネージャへ送信するメッセージを
検索することができる共用アクセス・メッセージ・キュ
ーと、前記同期情報を格納する共用アクセス同期キュー
とを含む、上記（８）に記載のデータ通信システム。 （１０）通信マネージャ・セットとリモート通信マネー
ジャの間の通信を管理する方法の諸ステップを実行する
ために稼動する、データ通信機器の操作を制御するため
のコンピュータ読み取り可能プログラム・コードを備え
るコンピュータ・プログラムであって、前記方法が、デ
ータ・ストレージ・リポジトリからリモート通信マネー
ジャへデータを送信するために、通信マネージャ・セッ
トの第１の通信マネージャとリモート通信マネージャの
間の通信チャネルを始動するステップであって、データ
・ストレージ・リポジトリが、通信マネージャ・セット
のいずれの通信マネージャからもアクセス可能であるス
テップと、通信マネージャ・セットのいずれの通信マネ
ージャからもアクセス可能なストレージ・リポジトリ内
に、通信チャネルの状態情報を格納するステップと、第
１の通信マネージャに影響を与える障害に応答して、通
信マネージャ・セットの第２の通信マネージャが、格納
されたチャネル状態情報を使用して新しいチャネル・イ
ンスタンスを始動し、新しいチャネル・インスタンスを
介してデータ・ストレージ・リポジトリからリモート通
信マネージャへのデータ送信を再開するステップとを含
むコンピュータ・プログラム。 （１１）通信マネージャ・セットのいずれの通信マネー
ジャからもアクセス可能なデータ・ストレージ・リポジ
トリと、各通信マネージャが、データ・ストレージ・リ
ポジトリからリモート通信マネージャへデータを送信す
るために通信チャネルのインスタンスを始動するように
適合され、各通信マネージャが、前記通信チャネルを介
してデータを送信するように適合された通信マネージャ
・セットと、前記通信チャネルを介したデータ送信の同
期情報を格納するストレージ・リポジトリであって、通
信マネージャ・セットのいずれの通信マネージャからも
アクセス可能であるストレージ・リポジトリとを備える
データ通信システムであって、通信マネージャ・セット
が、通信チャネルの第１のアクティブ・インスタンスを
持つ前記通信マネージャ・セットの第１の通信マネージ
ャに影響を与える障害に応答して、前記格納された同期
情報を使用して、前記第１の通信マネージャのデータ送
信を整合性のある状態に回復し、それによって、データ
・ストレージ・リポジトリからリモート通信マネージャ
へのデータ送信の再開を可能にするデータ通信システ
ム。 （１２）通信マネージャ・セットとリモート通信マネー
ジャの間の通信を管理する方法であって、リモート通信
マネージャからデータを受信するために、通信マネージ
ャ・セットの第１の通信マネージャとリモート通信マネ
ージャの間の通信チャネルの第１のインスタンスを始動
するステップと、通信チャネルの第１のインスタンスが
第１の通信マネージャによって使用されている間に、通
信チャネルの第２のインスタンスが始動されるのを防止
するステップと、第１の通信マネージャに影響を与える
障害の後、リモート通信マネージャからのチャネル始動
要求に応答して、通信マネージャ・セットの第２の通信
マネージャとリモート通信マネージャの間のチャネルの
第２のインスタンスを始動し、新しいチャネル・インス
タンスを介してリモート通信マネージャからのデータ送
信を再開するステップとを含む方法。

【図面の簡単な説明】

【図１】当技術分野で知られている、メッセージおよび
キューイング・プログラム間通信環境における、チャネ
ルを介したキュー・マネージャ間のメッセージの送信を
示す概略図である。

【図２】本発明の実施形態による、アウトバウンド通信
チャネルを介した通信に関与するコンポーネントを示す
図である。

【図３】本発明の実施形態による、通信を管理する方法
の諸ステップを示す図である。

【図４】リモート・キュー・マネージャに障害が発生し
たとき、リモート・キューの同期情報にアクセスできな
いという問題を示す図である。

【図５】本発明の実施形態による、共用アクセス・リソ
ースをどのように使用すればチャネルの同期回復が可能
になるかを示す図である。

【符号の説明】

２０ キュー・マネージャ ２５ チャネル・イニシエータ １００ キュー共用グループ １１０ キュー・マネージャ １２０ キュー・マネージャ １３０ キュー・マネージャ １４０ 共用データベース １５０ 結合機能 １６０ 送信キュー １７０ チャネル・インスタンス １８０ キュー・マネージャ １９０ チャネル定義 ２００ 共用リポジトリ ２００ 共用チャネル状況テーブル ２１０ 宛先キュー

フロントページの続き (72)発明者 アマルデープ・シンク・バッタル イギリス エス・オー17 １キュー・ユー ハンプシャー州サザンプトン ハイフィ ールド アボッツ・ウェイ ３ (72)発明者 モラグ・アン・ヒューソン イギリス エス・オー16 ８ディー・アー ル ハンプシャー州サザンプトン ローン ハムス ファーニーハースト・アベニュー ４エイ (72)発明者 ネイル・ケニス・ジョンストン イギリス エス・オー15 ２ティー・エル ハンプシャー州サザンプトン ノースラ ンズ・ロード キャヴェンディッシュ・ミ ューズ ７ (72)発明者 アンソニー・ジョン・オダウド イギリス オー・エス22 ５エイチ・ビー ハンプシャー州ウィンチェスター チル ボルトン・アベニュー 17 Ｆターム(参考） 5B045 BB28 BB42 GG01 JJ01 JJ42 5B085 AC11 AC16 CA00 CA04

Claims (12)

【特許請求の範囲】
1. 【請求項１】通信マネージャ・セットとリモート通信マ
   ネージャの間の通信を管理する方法であって、 データ・ストレージ・リポジトリからリモート通信マネ
   ージャへデータを送信するために、通信マネージャ・セ
   ットの第１の通信マネージャとリモート通信マネージャ
   の間の通信チャネルを始動するステップであって、前記
   データ・ストレージ・リポジトリが、通信マネージャ・
   セットのいずれの通信マネージャからもアクセス可能で
   あるステップと、 通信マネージャ・セットのいずれの通信マネージャから
   もアクセス可能なストレージ・リポジトリ内に、通信チ
   ャネルの状態情報を格納するステップと、 第１の通信マネージャに影響を与える障害に応答して、
   通信マネージャ・セットの第２の通信マネージャが、格
   納されたチャネル状態情報を使用して新しいチャネル・
   インスタンスを始動し、新しいチャネル・インスタンス
   を介して、データ・ストレージ・リポジトリからリモー
   ト通信マネージャへのデータ送信を再開するステップと
   を含む方法。
2. 【請求項２】前記アクセス可能なリポジトリ内に格納さ
   れた状態情報が、チャネルの制御を行う通信マネージャ
   の識別を含み、第１の通信マネージャに影響を与える障
   害の後、第１の通信マネージャによって制御されるチャ
   ネルの認識を可能とする、請求項１に記載の方法。
3. 【請求項３】前記アクセス可能なリポジトリ内に格納さ
   れた状態情報が、チャネルの現状況を含む、請求項２に
   記載の方法。
4. 【請求項４】通信マネージャ・セットの各通信マネージ
   ャが、前記通信マネージャ・セットの通信マネージャの
   各アクティブ・チャネルの定義を格納している、あるい
   は、各通信マネージャから各アクティブ・チャネルの定
   義にアクセス可能である、請求項１ないし３のいずれか
   一項に記載の方法。
5. 【請求項５】通信チャネルの第１のインスタンスが第１
   の通信マネージャによって使用されている間に、通信チ
   ャネルの第２のインスタンスが始動されるのを防止する
   ステップと、 第１の通信チャネル・インスタンスに障害が発生したと
   いう判定に応答して、チャネル定義および現チャネル状
   態情報を使用して、チャネルの第２のインスタンスを始
   動するステップと、 第２のチャネル・インスタンスを使用してデータを送信
   するステップとを含む、請求項４に記載の方法。
6. 【請求項６】通信マネージャ・セットが、キュー共用グ
   ループ内のキュー・マネージャ・セットであり、キュー
   ・マネージャ・セットのいずれのキュー・マネージャか
   らもアクセス可能なデータ・ストレージ・リポジトリ
   が、共用アクセス・メッセージ・キューであり、そこか
   らキュー・マネージャ・セットのいずれのキュー・マネ
   ージャも、リモート・キュー・マネージャへ送信するメ
   ッセージを検索することができる、請求項１ないし５の
   いずれか一項に記載の方法。
7. 【請求項７】通信マネージャ・セットのいずれの通信マ
   ネージャからもアクセス可能なデータ・ストレージ・リ
   ポジトリと、 各通信マネージャが、データ・ストレージ・リポジトリ
   からリモート通信マネージャへデータを送信するため
   に、通信チャネルのインスタンスを始動するように適合
   され、各通信マネージャが、前記通信チャネルを介して
   データを送信するように適合された通信マネージャ・セ
   ットと、 通信チャネルの現状態情報を格納するストレージ・リポ
   ジトリであって、通信マネージャ・セットのいずれの通
   信マネージャからもアクセス可能なストレージ・リポジ
   トリとを備えるデータ通信システムであって、 通信マネージャ・セットが、通信チャネルの第１のアク
   ティブ・インスタンスを持つ前記通信マネージャ・セッ
   トの第１の通信マネージャに影響を与える障害に応答し
   て、格納された現チャネル状態情報を使用してチャネル
   の第２のインスタンスを始動し、第２のインスタンス・
   チャネルを介して、データ・ストレージ・リポジトリか
   らリモート通信マネージャへのデータ送信を再開するデ
   ータ通信システム。
8. 【請求項８】前記通信チャネルを介したデータ送信の同
   期情報を格納するストレージ・リポジトリを含み、前記
   ストレージ・リポジトリが通信マネージャ・セットのい
   ずれの通信マネージャからもアクセス可能であり、 通信マネージャ・セットが、通信チャネルの第１のアク
   ティブ・インスタンスを持つ前記通信マネージャ・セッ
   トの第１の通信マネージャに影響を与える障害に応答し
   て、前記格納された同期情報を使用して、前記第１の通
   信マネージャのデータ送信を整合性のある状態に回復
   し、それによって、データを失うことなくデータ・スト
   レージ・リポジトリからリモート通信マネージャへのデ
   ータ送信の再開を可能にする、請求項７に記載のデータ
   通信システム。
9. 【請求項９】通信マネージャ・セットが、キュー共用グ
   ループ内のキュー・マネージャ・セットであり、前記マ
   ネージャ・セットのいずれのマネージャからもアクセス
   可能なデータ・ストレージ・リポジトリが、キュー・マ
   ネージャ・セットのいずれのキュー・マネージャも、そ
   こからリモート・キュー・マネージャへ送信するメッセ
   ージを検索することができる共用アクセス・メッセージ
   ・キューと、前記同期情報を格納する共用アクセス同期
   キューとを含む、請求項８に記載のデータ通信システ
   ム。
10. 【請求項１０】通信マネージャ・セットとリモート通信
    マネージャの間の通信を管理する方法の諸ステップを実
    行するために稼動する、データ通信機器の操作を制御す
    るためのコンピュータ読み取り可能プログラム・コード
    を備えるコンピュータ・プログラムであって、前記方法
    が、 データ・ストレージ・リポジトリからリモート通信マネ
    ージャへデータを送信するために、通信マネージャ・セ
    ットの第１の通信マネージャとリモート通信マネージャ
    の間の通信チャネルを始動するステップであって、デー
    タ・ストレージ・リポジトリが、通信マネージャ・セッ
    トのいずれの通信マネージャからもアクセス可能である
    ステップと、 通信マネージャ・セットのいずれの通信マネージャから
    もアクセス可能なストレージ・リポジトリ内に、通信チ
    ャネルの状態情報を格納するステップと、 第１の通信マネージャに影響を与える障害に応答して、
    通信マネージャ・セットの第２の通信マネージャが、格
    納されたチャネル状態情報を使用して新しいチャネル・
    インスタンスを始動し、新しいチャネル・インスタンス
    を介してデータ・ストレージ・リポジトリからリモート
    通信マネージャへのデータ送信を再開するステップとを
    含むコンピュータ・プログラム。
11. 【請求項１１】通信マネージャ・セットのいずれの通信
    マネージャからもアクセス可能なデータ・ストレージ・
    リポジトリと、 各通信マネージャが、データ・ストレージ・リポジトリ
    からリモート通信マネージャへデータを送信するために
    通信チャネルのインスタンスを始動するように適合さ
    れ、各通信マネージャが、前記通信チャネルを介してデ
    ータを送信するように適合された通信マネージャ・セッ
    トと、 前記通信チャネルを介したデータ送信の同期情報を格納
    するストレージ・リポジトリであって、通信マネージャ
    ・セットのいずれの通信マネージャからもアクセス可能
    であるストレージ・リポジトリとを備えるデータ通信シ
    ステムであって、 通信マネージャ・セットが、通信チャネルの第１のアク
    ティブ・インスタンスを持つ前記通信マネージャ・セッ
    トの第１の通信マネージャに影響を与える障害に応答し
    て、前記格納された同期情報を使用して、前記第１の通
    信マネージャのデータ送信を整合性のある状態に回復
    し、それによって、データ・ストレージ・リポジトリか
    らリモート通信マネージャへのデータ送信の再開を可能
    にするデータ通信システム。
12. 【請求項１２】通信マネージャ・セットとリモート通信
    マネージャの間の通信を管理する方法であって、 リモート通信マネージャからデータを受信するために、
    通信マネージャ・セットの第１の通信マネージャとリモ
    ート通信マネージャの間の通信チャネルの第１のインス
    タンスを始動するステップと、 通信チャネルの第１のインスタンスが第１の通信マネー
    ジャによって使用されている間に、通信チャネルの第２
    のインスタンスが始動されるのを防止するステップと、 第１の通信マネージャに影響を与える障害の後、リモー
    ト通信マネージャからのチャネル始動要求に応答して、
    通信マネージャ・セットの第２の通信マネージャとリモ
    ート通信マネージャの間のチャネルの第２のインスタン
    スを始動し、新しいチャネル・インスタンスを介してリ
    モート通信マネージャからのデータ送信を再開するステ
    ップとを含む方法。