JPH04229334A - コンピュータ・システム及びアプリケーションプログラム実行方法 - Google Patents

Abstract

(57)【要約】本公報は電子出願前の出願データであるた
め要約のデータは記録されません。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、全般的にはコンピュー
タ・オペレーティング・システムに関するものであり、
具体的には、オーバヘッドを最小にするための、コミッ
ト手順用の資源の登録を提供するコンピュータ・オペレ
ーティング・システムに関するものである。

【０００２】

【従来の技術】本発明のオペレーティング・システムは
、コンピュータ・システムのネットワーク内で使用でき
る。こうした各コンピュータ・システムは、１台の中央
ホスト・コンピュータと、複数の仮想計算機またはその
他の形式の実行環境を含むことができる。仮想計算機用
のホスト・コンピュータには、システム制御プログラム
が含まれ、このシステム制御プログラムは、ホストのデ
ータ・プロセッサに対する各仮想計算機のアクセスをス
ケジューリングし、大容量メモリを含むホストの資源の
管理を助けて、各仮想計算機が別々のコンピュータであ
るように見えるようにする。各仮想計算機はまた、ホス
トを介してメッセージまたはファイルを送るために、他
の仮想計算機と会話することができる。各ＶＭ（米国ニ
ューヨーク州アーモンクのＩＢＭコーポレーションの登
録商標）仮想計算機は、その仮想計算機のユーザと会話
する（すなわち、ユーザから命令を受け取り、ユーザに
プロンプトを提示する）ための、それ自体のシステム制
御プログラムのＣＭＳ部分を有している（“ＣＭＳ”は
、ＩＢＭコーポレーションの登録商標）。共用ファイル
・システム（ＳＦＳ）や共用（ＳＱＬ）関係データベー
スなど、任意のユーザ仮想計算機およびホストからアク
セス可能な資源が存在してもよい。

【０００３】このようなシステムは、それぞれが１台の
実計算機であると見なされる。２台以上のこのような実
計算機をネットワーク内で相互接続し、異なる実計算機
の仮想計算機の間での会話を介してデータを転送するこ
とが一般に行われている。このような転送は、ＡＶＳゲ
ートウェイやＶＴＡＭファシリティ（“ＡＶＳゲートウ
ェイ”および“ＶＴＡＭ”は、ＩＢＭコーポレーション
の登録商標）などの通信ファシリティを介して行われる
。

【０００４】アプリケーションが、データベースまたは
ファイルを変更するには、まずそれらの変更を定義する
作業要求を行う。これに応答して、元のデータベースま
たはファイルは変更しないままで、その作業要求に基づ
く仮の変更がシャドウ・ファイル内で行われる。この時
、シャドウ・ファイルは有効でない。ここで、アプリケ
ーションは、シャドウ・ファイルの変更を有効にし、そ
れによってシャドウ・ファイルの変更で元のファイルを
置換するために、その変更をコミットするよう要求する
ことができる。１段階のコミット手順が使用できる。 この１段階コミット手順は、シャドウ・ファイルに含ま
れる資源の変更を１個のコマンドでコミットするもので
ある。ＳＦＳ資源やＳＱＬ資源などの資源が変更される
時、その資源に対するコミットは、別々の１段階コミッ
ト手順で完了できる。大多数の場合、すべての資源が別
々の手順でエラーや中断なしにコミットされる。しかし
ながら、いずれかの１段階コミット手順の最中に問題が
発生した場合、完了したコミットもあれば完了しないコ
ミットもあり、整合性が失われる。問題が生じた後にク
リティカルでない資源を再構築するコストは、１段階コ
ミット手順の効率を考慮すれば、許容できるものである
。

【０００５】しかし、クリティカルな資源およびクリテ
ィカルな会話を保護するには、２段階のコミット手順が
必要である。たとえば、第１の人物の当座預金口座が第
１のデータベース内で表され、第２の人物の普通預金口
座が第２のデータベース内で表されていると仮定する。 第１の人物が第２の人物に対して小切手を振り出し、第
２の人物がその小切手を自分の普通預金口座に預金する
場合、２段階コミット手順を用いれば、第１の人物の当
座預金口座が借方記入されるなら第２の人物の普通預金
口座が貸方記入され、そうでないならばどちらの口座も
変更しないことが保証される。これらの当座預金口座と
普通預金口座は、保護されたクリティカルな資源と見な
される。というのは、これらの当座預金口座と普通預金
口座にかかわるデータの転送が、信頼のおける取扱いを
受けることが非常に重要であるからである。アプリケー
ション・プログラムは、１個のコマンドで２段階コミッ
ト手順を開始できる。この手順は、以下のステップまた
は段階からなる。 （１）準備段階の間、各関係者（借方と貸方）の資源が
、その資源がすべての変更をコミットする用意ができて
いるかどうか判定するために、同期点マネジャによって
ポーリングされる。各資源は、すべての資源がこの準備
段階を首尾よく完了する、すなわち更新される用意がで
きている場合に、資源更新を完了すると約束する。 （２）コミット段階の間、同期点マネジャは、すべての
資源に更新を最終的なものにするよう指示し、いずれか
の資源が準備段階を首尾よく完了できなかった場合には
、それらを撤回する。

【０００６】コンピュータ・システムでは、コミット手
順に参加する資源を決定し、適当なコミット手順の種類
が１段階か２段階かを決定するための手段が必要である
。従来技術では、保護された資源は、コミット手順に参
加するために、特殊なまたは追加の環境と関連づけられ
てきた。しかし、この関連づけには、下記の欠点がある
。エンド・ユーザ、アプリケーション開発者および管理
者は、この追加の環境を考慮に入れなければならず、エ
ンド・ユーザは、個人用コンピュータ環境からこの特殊
環境に切り換えなければならない。また、データは、こ
の特殊環境専用であり、他の環境からは容易に利用でき
ない。

【０００７】従来技術のシステムであるＩＢＭシステム
３８では、アプリケーションは、アプリケーション用の
コミット制御のイネーブルとディスエーブルを行うこと
のできる動詞（ｖｅｒｂ）を与えられていた。したがっ
て、アプリケーション開発者が、不注意から、２段階コ
ミット手順を使用せずに複数の保護された資源を更新す
るアプリケーションを作成する可能性があった。

【０００８】従来技術のＣＩＣＳ／ＶＳシステムでは、
アプリケーションに含まれる別々のモジュールが分散さ
れていた。このモジュールが、ＳＱＬ／ＤＳ資源マネジ
ャへのアプリケーション・プログラム・インターフェー
ス要求を代行受信し、この資源マネジャのために登録し
た。したがって、アプリケーション開発者と管理者が、
同期点マネジャ・モジュールを管理しなければならなか
った。

【０００９】ＣＩＣＳ／ＶＳシステムの同期点設計では
、資源マネジャがアプリケーション環境に対して活動状
態であることを、資源マネジャがイネーブル機能を介し
てシステムに通知することが必要である。このイネーブ
ルを行うには、ＣＩＣＳ／ＶＳトランザクション環境の
開始時に、操作員が各資源マネジャと対話する必要があ
る。また、このイネーブルは、グローバルすなわち全て
のアプリケーションに対するものである。アプリケーシ
ョンは、このイネーブル機能が実行されるまで、資源（
保護されたものであれ保護されないものであれ）を求め
て資源マネジャにアクセスすることができなかった。

【００１０】ＣＩＣＳ／ＶＳシステムでは、保護された
資源に対する変更をコミットまたはバックアウトするた
めのＣＩＣＳ／ＶＳ動詞が、ＣＩＣＳ／ＶＳシステムに
よって前処理される必要があった。アプリケーション開
発者は、コンパイルの前に、全アプリケーションの前処
理を実行する必要があった。したがって、アプリケーシ
ョン開発プロセスに、余分なステップを追加する必要が
あった。

【００１１】この従来技術のＣＩＣＳ／ＶＳシステムは
、資源アダプタによる、アプリケーションのための登録
の修正をサポートしている。資源マネジャは、ある同期
点への参加を望むか否か（すなわち延期）を述べること
ができた。

【００１２】従来技術のＩＢＭ　　ＶＭ／ＳＰリリース
６制御プログラムに含まれる従来技術のＩＢＭ共用ファ
イル・システム（ＳＦＳ）は、唯一の資源すなわち共用
ファイル・システム資源のみに対する１段階コミット手
順だけをサポートしている。しかし、この１段階コミッ
ト手順は、同一の資源上の複数のファイルに対する更新
を、原子的にコミットすることができる。また、このＳ
ＦＳシステムは、書き込みモードの資源マネジャが１つ
だけである場合には、複数のＳＦＳ資源マネジャを原子
的にコミットすることができる。これは、１段階コミッ
ト手順がこの場合に適しているからである。

【００１３】ＣＭＳ作業ユニットとして知られるコミッ
ト範囲は、特定の作業ユニット内で読み書きされるファ
イルを定義するアプリケーションによって制御される。 この作業ユニットは、単一の更新された資源マネジャに
制限されている。アプリケーションは、複数の作業ユニ
ットを定義して、それらを同時に使用することができる
ので、複数の作業範囲を有することができる。ある作業
ユニットのコミットは、他の作業ユニットに影響を与え
ない。

【００１４】もう１つの従来技術のシステムであるＳＱ
Ｌ／ＤＳシステムには、ＳＦＳに類似したサポートがあ
る。これは、単一の資源マネジャに対して複数の作業ユ
ニットを許容するものであるが、１作業ユニットは、読
み取り専用の場合でも１つの資源マネジャにしかアクセ
スできない。

【００１５】

【発明が解決しようとする課題】本発明の全般的な目的
は、２段階コミット手順を必要とする資源を識別するた
めの効率的なシステムおよび方法を提供することである
。

【００１６】本発明のもう１つの全般的な目的は、保護
された資源を識別するための効率的な方法を提供する際
に、アプリケーションのユーザ、アプリケーション・プ
ログラム開発者、資源マネジャの開発者、システム管理
者および操作員の負担を最小にすることである。

【００１７】本発明のもう１つの全般的な目的は、同期
点処理のオーバヘッドを最小にすることである。

【００１８】

【課題を解決するための手段】本発明は、同期点処理の
ための資源の登録を提供するコンピュータ・システムに
ある。資源には、ファイル・システム、データ・ベース
および保護された会話が含まれる。資源は、アプリケー
ションの実行環境に登録された時に、システムによって
保護されるようになる。実行環境には対話環境が含まれ
るが、それだけに限定されるものではない。したがって
、本発明は、保護された資源を識別するための、効率的
かつ一律な方法を提供する。登録ファシリティは、アプ
リケーションから分離されている。したがって、アプリ
ケーションのユーザ、アプリケーション・プログラム開
発者、システム管理者および操作員は、登録ファシリテ
ィを考慮または設計する必要がなく、提供されたものを
使用するだけでよい。一律であるとは、同期点への参加
を開始、変更、更新および終了するための１つの柔軟な
方法を意味する。本発明の特徴の１つによれば、保護資
源マネジャは、そのアダプタを介して、足りない情報を
追加するか、または既存の情報を変更することによって
、いつでも登録情報を修正することができる。このシス
テムでは、この情報を含む登録が、その時点で資源マネ
ジャに利用できるようにするか、あるいは後で完了する
ようにすることができる。したがって、資源アダプタは
、より効率的な設計になる。システムの性能は、同期点
の最適化を可能にすること、ならびに同期点で交換され
る情報の量を減らすことによって改善される。本発明は
柔軟性があるため、資源アダプタは、その製品目標を満
足するのに必要な自由度を与えられる。本発明のもう１
つの特徴によれば、資源は、参加を望む作業ユニットの
みのために登録する。アプリケーションは、複数の作業
ユニットを有することができる。１つの資源を、そのア
プリケーションの２つの作業ユニットのために登録する
ことができ、２つの資源を単一の作業ユニットのために
登録することもでき、その両方を行うこともできる。 資源は、同じ種類であっても異なる種類であってもよい
。アプリケーションの原始コードに対する制約、その前
処理または後処理が、課せられることはない。柔軟性の
もう１つの様態は、適当な時にはいつでも、保護された
資源がアプリケーション同期点処理から撤退できるよう
にし、したがって、資源マネジャとシステム資源の両方
を保存することである。撤退はいつでも行うことができ
、したがって、資源アダプタの設計が簡単になる。しか
し、アプリケーションは、依然として資源アダプタを使
用する。

【００１９】

【実施例】図面で、複数の図を通じて同じ要素は同じ参
照番号で示す。図１には、従来技術によるＬＵ６．２同
期点タワー・モデルまたはアーキテクチャが示されてい
る。このアーキテクチャは、１つの実行環境として定義
されている。この例では、３つのアプリケーション・プ
ログラム１４、１６および１８が、実行環境１２内で時
分割式に実行される。資源マネジャ２６および２７は、
ＤＢ／２またはＣＩＣＳファイル制御装置（ＤＢ／２お
よびＣＩＣＳはＩＢＭコーポレーションの登録商標）で
あり、それぞれ資源２２および２４へのアクセスを制御
する。ＤＢ／２（ＣＣＩＳ／ＭＶＳオペレーティング・
システム）またはＳＱＬ／ＤＳ（ＣＣＩＳ／ＶＳＥオペ
レーティング・システム）資源マネジャが実行環境１２
の外部にある場合、実行環境１２は、従来技術によって
資源マネジャへインタフェースする資源アダプタを含む
ことになる。この従来技術のアーキテクチャでは、アプ
リケーション・プログラム１４は、同期点マネジャ２０
に対して資源２２および２４を呼び出す作業要求を行っ
た後で、その作業要求に含まれる資源のコミットを要求
する。

【００２０】次に、アプリケーション・プログラム１４
は、以前の作業要求のデータ更新をコミットするため、
同期点マネジャ２０からのコミットを要求する。これに
応答して、同期点マネジャ２０は、資源マネジャ２６お
よび２７をポーリングして、それらが資源をコミットす
る準備ができているか否かを判定し、準備ができている
場合は続いてそのコミットを指令することによって、２
段階のコミット手順を実施する。この２段階コミット手
順の各段階（および各段階の各ステップ）で、同期点マ
ネジャ２０は、２段階コミット手順の状態を示す同期点
情報をログ３０に転送する。この２段階コミット手順中
に障害が発生した場合、同期点マネジャは、資源を整合
性のある状態にするために、同期点回復手順を実施する
。同期点マネジャは、ログ３０内の同期点情報を用いて
、中断以前に２段階コミット手順がどこまで進行したか
を決定する。

【００２１】アプリケーション・プログラム１４、１６
または１８のうちのいずれかが、保護会話マネジャ４０
を介して保護された会話を使用して、同一システム内の
別の環境内にあるパートナ・アプリケーション（図示せ
ず）、または通信ファシリティを介して相互接続された
別のシステム内にあるパートナ・アプリケーション（図
示せず）の通信を試みるときにも、同期点マネジャ２０
と２段階コミット手順が使用される。この従来技術の同
期点アーキテクチャによれば、この別のシステムまたは
別の環境は、実行環境１２と機能的に同等であり、２０
と機能的に同等な別の同期点マネジャ、３０と機能的に
同等な別の同期点ログ、４０と機能的に同等な別の保護
会話マネジャ、ならびに２６および２７と機能的に同等
な別の資源マネジャを含む。この別の環境は、実行環境
１２のそれとは独立した、調整機能および回復機能を提
供する。

【００２２】保護された資源の調整式同期点管理図２に
は、本発明による同期点アーキテクチャが示されている
。本発明は、ＵＮＩＸ環境、ＯＳ／２環境、ＯＳ／２オ
ペレーティング・システム内のＤＯＳ環境、ＶＭオペレ
ーティング・システム内のＣＭＳ環境、ＶＭオペレーテ
ィング・システム内のＡＩＸ環境、ＶＭオペレーティン
グ・システム内のＣＩＣＳ環境、ＶＭオペレーティング
・システム内のＭＵＳＩＣ環境など、それ自体の実行環
境内で実行される分散式および非分散式のアプリケーシ
ョンをサポートする、分散コンピュータ・オペレーティ
ング・システムを含む。分散アプリケーションは、別の
実行環境内の資源を使用するか、あるいは別の実行環境
内のパートナ・アプリケーションとの通信会話（特別な
タイプの資源）を有することを特徴とする。資源マネジ
ャまたはパートナ・アプリケーションの実行環境は、同
一のシステム内にあっても、異なるシステム内にあって
もよく、同一形式の環境であっても、異なる環境であっ
てもよい。分散アプリケーション実行環境は、アプリケ
ーションをそれ自体の環境内でサポートする１つまたは
複数のシステムを含む。前記の環境が必要な資源をすべ
て含む必要はない。これらの資源は、他所に分散されて
おり、通信ファシリティを使って獲得される。分散アプ
リケーションの完全な環境は、すべての機能を備えるよ
うに見える。というのは、分散アプリケーションは、他
の環境にある資源、特に回復ファシリティと通信ファシ
リティを必要とするからである。

【００２３】本発明は、１つまたは複数のシステム（実
計算機または中央電子処理装置群（ＣＥＣ））５０Ａお
よび５０Ｄを含む。この実施例では、システム５０Ａは
、複数の同等な分散アプリケーション環境５２Ａ、５２
Ｂ、５２Ｃ、システム制御プログラム５５Ａの一部であ
る会話マネジャ５３Ａと実行環境制御プログラム６１Ａ
、６１Ｂ、６１Ｃ、および回復ファシリティ７０Ａを含
む。限定ではなく例として示すと、分散アプリケーショ
ン環境５２Ａ、５２Ｂ、５２Ｃはそれぞれ、拡張バージ
ョンのＶＭ仮想計算機であってよく、回復ファシリティ
７０Ａは、別の拡張バージョンのＶＭ仮想計算機に常駐
でき、システム制御プログラム５５Ａは、仮想計算機で
ある分散アプリケーション環境５２Ａ、５２Ｂ、５２Ｃ
用の拡張バージョンのＶＭオペレーティング・システム
であってよい。実計算機であるシステム５０Ａ内の分散
アプリケーション環境５２Ａないし５２Ｃ内で実行され
るアプリケーションは、実計算機であるシステム５０Ｄ
内または他のシステム（図示せず）内で実行される同様
の分散アプリケーション環境内で実行されるパートナ・
アプリケーションと、通信ファシリティ５７Ａおよび５
７Ｄを介して通信できる。たとえば、通信ファシリティ
５７Ａは、仮想記憶通信アクセス方式（“ＶＴＡＭ”）
ファシリティと、ＡＰＰＣ／ＶＭ　　ＶＴＡＭサポート
（ＡＶＳ）ゲートウェイ・ファシリティを含む。各分散
アプリケーション環境５２は、単一の同期点マネジャ（
ＳＰＭ）６０Ａと、複数の保護資源アダプタ６２Ａ、６
２Ｂおよび６４Ａを含む。同期点マネジャを用いると、
変更がアトミックにみえる形で、関連する１群の更新を
コミットまたはバックアウト（取消し）できるようにな
る。同期点間で実行される更新（すなわち、コミットま
たはバックアウト）は、作業論理ユニットと称し、関連
する更新は、回復ファシリティを介して同期点マネジャ
によって割り当てられた、作業論理ユニット識別子と称
する一義的な名前で識別される。作業論理ユニットは、
同一の分散アプリケーション環境内のアプリケーション
からアクセスされる複数の保護された資源を含むことが
でき、また他のアプリケーション環境内のパートナ・ア
プリケーションから保護された資源の１タイプである会
話を介してアクセスされる保護された資源を含むことも
できる。

【００２４】会話とは、２つのパートナ・アプリケーシ
ョンの間で体系的に確立された経路である。各アプリケ
ーションによる会話の使用は、そのアプリケーションの
設計と、使用される会話のパラダイムによって決定され
る。会話が同期点処理に含まれる場合、これを保護され
た会話と称する。保護された資源は、下記「コミット手
順のための資源の登録」で説明する登録と称する処理を
介して同期点マネジャとコンタクトすることによって、
作業論理ユニットの一部になる。各保護資源アダプタは
、アプリケーションならびに同期点マネジャに資源マネ
ジャへのインタフェースを提供する。（資源マネジャが
アプリケーションと同一の実行環境内に常駐する場合に
は、その代わりに、保護資源アダプタを資源マネジャと
組み合わせることができる。）

【００２５】この実施例では、保護された資源は、ファ
イルと会話である。本発明の他の実施例では、保護され
た資源は、データベース・テーブル、待ち行列、遠隔手
順コールその他であってよい。保護資源アダプタ６２Ａ
および６２Ｂは、それぞれ、アプリケーション５６Ａの
ために、ファイル７８Ａおよび７８Ｂを管理する資源マ
ネジャ６３Ａおよび６３Ｂへのインタフェースを取り扱
う。資源マネジャ６３Ａおよび６３Ｂは、同一のシステ
ム内にある。また、これらが通信ネットワーク内の異な
るシステム内に常駐することもできる。この実施例で、
会話は会話マネジャによって管理される。会話マネジャ
は、あるアプリケーションから、同一システム内の異な
る分散アプリケーション環境内、または通信ネットワー
ク内の異なるシステム内の異なる分散アプリケーション
環境内で実行される他のパートナ・アプリケーションへ
の会話または経路を管理する。保護された会話が、同一
システム内の異なるアプリケーション環境内で実行され
る２つのアプリケーション・パートナの間、たとえばア
プリケーション環境５２Ａおよび５２Ｂで実行されるア
プリケーションの間で行われる場合、会話マネジャは、
システム５０Ａのシステム制御プログラム５５Ａに含ま
れ、各保護会話アダプタ６４Ａおよび６４Ｂ（図示せず
）を介してアプリケーション・パートナの間で通信が行
われる。保護された会話が、異なるシステム内の異なる
アプリケーション環境の間、たとえばアプリケーション
環境５２Ａおよび５２Ｄで実行される２つのアプリケー
ション・パートナの間で行われる場合、通信ファシリテ
ィ５７Ａおよび５７Ｄを介してシステム５０Ａ内の会話
マネジャ５３Ａとシステム５０Ｄ内の会話マネジャ５３
Ｄの間で通信が行われる。この実施例では、このような
通信は、対等通信フォーマットを使用する。会話マネジ
ャ５３Ａおよび５３Ｄは、通信ファシリティ５７Ａおよ
び５７Ｄと通信するのに、環境内フォーマットを使用す
る。通信ファシリティ５７Ａおよび５７Ｄは、環境内フ
ォーマットから体系的システム間通信標準フォーマット
に、またその逆に変換する。たとえば、この体系的シス
テム間通信標準フォーマットは、ＩＢＭのシステム・ネ
ットワーク体系、ＬＵ６．２プロトコルによって定義さ
れるタイプのものでよい。

【００２６】回復ファシリティ７０Ａは、実計算機であ
るシステム５０Ａ内の分散アプリケーション環境５２Ａ
、５２Ｂ、５２Ｃのすべてにサービスする。回復ファシ
リティ７０Ａはログ７２Ａを含み、その処理は、同期点
マネジャ６０Ａ、６０Ｂ、６０Ｃに対するロギングを取
り扱い、すべての分散アプリケーション環境５２Ａ、５
２Ｂ、５２Ｃのために、障害が発生した同期点の回復を
行う。システム５０Ｄ上の回復ファシリティ７０Ｄとそ
のログ７２Ｄおよび同期点マネジャ６０Ｄについても同
様である。

【００２７】分散アプリケーション環境５２Ａ内のアプ
リケーション５６Ａが、ファイル７８Ａおよび７８Ｂを
更新したい場合、アプリケーション５６Ａは、アプリケ
ーション５６Ａ内のファイル・アプリケーション・プロ
グラム・インタフェースを介して、別々の２つの更新要
求を行う。これらの要求は、それぞれファイル７８Ａお
よび７８Ｂのための保護資源アダプタ（以下、このタイ
プの資源に関しては保護ファイル・アダプタＰＦＡと呼
ぶ）６２Ａおよび６２Ｂを呼び出す（図３のステップ５
００）。資源マネジャ特有の実施様態に基づいて、保護
ファイル・アダプタは、このファイルが保護されている
ことを知る。まだこの作業ユニットに関して同期点マネ
ジャに登録されていない場合、保護ファイル・アダプタ
６２Ａおよび６２Ｂは、この作業ユニットに関するすべ
てのコミット要求およびバックアウト要求に関わりたい
と、同期点マネジャ６０Ａに登録する（ステップ５０２
）。「作業ユニット」とは、ある同期点に参加する、そ
のアプリケーションから直接アクセス可能であり可視で
ある、すべての資源をグループにまとめたものであり、
通常、作業論理ユニット識別子と関連づけられている。 作業ユニットに関するさらに詳しい説明は、下記の「作
業ユニットに合わせて調整されたローカルおよびグロー
バルなコミット範囲」を参照されたい。次に、保護ファ
イル・アダプタ６２Ａおよび６２Ｂは、それぞれ当該の
資源マネジャ６３Ａおよび６３Ｂにコンタクトして、そ
れぞれファイル７８Ａおよび７８Ｂを更新し（ステップ
５０４）、アプリケーション５６Ａに戻る。次に、アプ
リケーション５６Ａは、同期点マネジャ６０Ａに、同期
点５８Ａを要求する、すなわち、この場合はコミットを
要求する（ステップ５０６）。これに応答して、同期点
マネジャ６０Ａは、保護ファイル・アダプタ６２Ａおよ
び６２Ｂとそのそれぞれの資源マネジャ６３Ａおよび６
３Ｂによって表されるその登録された資源である、ファ
イル７８Ａおよび７８Ｂのために実行すべき、２段階コ
ミット手順を開始する。ステップ５０８で、同期点マネ
ジャ６０Ａは、段階１の「準備」コールで、登録された
その各資源を、登録中に各資源アダプタから同期点マネ
ジャに与えられたアダプタ同期点出口入口点で呼び出す
。

【００２８】その２段階コミット手順を実行する間に、
同期点マネジャ６０Ａは、回復ファシリティ７０Ａに要
求を発行して、段階１の同期点マネジャ情報をログ７２
Ａに強制ロギング（「強制ロギング」とは、同期点マネ
ジャ６０Ａに戻る前に、確実に情報が実際の物理装置に
書き込まれるようにすることを意味する）させる（ステ
ップ５０８）。この情報には、作業論理ユニット識別子
、同期点マネジャの状態および、このコミット要求に参
加する登録された各保護資源アダプタに関する名前その
他の関連情報が含まれる。この情報は、保護ファイル・
アダプタ６２Ａおよび６２Ｂが登録された時に、同期点
マネジャ６０Ａに与えられたものである。同期点マネジ
ャ６０Ａの状態は、準拠する２段階コミット・パラダイ
ムの規則によって決定される。たとえば、この２段階コ
ミット・パラダイムは、ＩＢＭコーポレーションの刊行
物“Ｓｙｓｔｅｍ　Ｎｅｔｗｏｒｋ　Ａｒｃｈｉｔｅｃ
ｔｕｒｅ　ＬＵ　６．２　Ｒｅｆｅｒｅｎｃｅ：　Ｐｅ
ｅｒＰｒｏｔｏｃｏｌｓ，　ＳＣ３１−６８０８，　Ｃ
ｈａｐｔｅｒ　５．３　Ｐｒｅｓｅｎｔａｔｉｏｎ　Ｓ
ｅｒｖｉｃｅｓ　−　Ｓｙｎｃ　Ｐｏｉｎｔ　ｖｅｒｂ
ｓ”に記載されているタイプのものである。この同期点
処理の間に障害が発生した場合、同期点マネジャの状態
を使用して、作業論理ユニットの結果（コミットまたは
バックアウト）を決定する。この実施例で使用する２段
階コミット・パラダイムの規則によれば、同期点マネジ
ャの段階１の状態は、「開始側（Ｉｎｉｔｉａｔｏｒ）
」、「同期点マネジャ保留中（Ｓｙｎｃｐｏｉｎｔ　　
Ｍａｎａｇｅｒ　　Ｐｅｎｄｉｎｇ）」である。２段階
コミット手順の第１段階が中断されずに完了した場合（
判断ブロック５１２）、同期点マネジャ６０Ａは、回復
ファシリティ７０Ａに第２の要求を発行して、ログ７２
Ａにその段階２の状態を強制ロギングさせる。保護ファ
イル・アダプタと資源マネジャからの回答と、使用して
いる２段階コミット・パラダイムの規則とに基づいて、
同期点マネジャ６０Ａは、その第２段階の決定を知る。 この実施例では、このパラダイムは以下のようなもので
ある。１つまたは複数の保護資源アダプタが、段階１の
要求に対して「バックアウト」と回答した場合、段階２
の決定は「バックアウト」である。すべてが「要求コミ
ット」と回答した場合、決定は「コミット」である。図
３に示した例では、保護ファイル・アダプタ６２Ａおよ
び６２Ｂは、「要求コミット」と回答し（ステップ５１
０）、段階２の状態は、同期点マネジャ６０Ａによって
、「開始側コミット済み（Ｉｎｉｔｉａｔｏｒ　　Ｃｏ
ｍｍｉｔｔｅｄ）」としてロギングされる。この例では
、ファイル・マネジャ６３Ａおよび６３Ｂは、段階１の
要求に対してそれぞれの保護ファイル・アダプタ６２Ａ
および６２Ｂを介して「要求コミット」と回答した後、
「不確定（ｉｎｄｏｕｂｔ）」の状態になる、すなわち
、それらのファイル・マネジャは、同期点マネジャ６０
Ａからの段階２の決定に基づいて、ファイル更新をコミ
ットまたはバックアウトできることに留意されたい。

【００２９】ロギングの後、同期点マネジャ６０Ａは、
保護ファイル・アダプタ６２Ａおよび６２Ｂに対して、
コミットの決定と共に段階２のコールを発行する（ステ
ップ５１３）。ファイル・マネジャ６３Ａおよび６３Ｂ
は段階２のコミットの決定を受け取った時、それぞれ先
に進んで、データをコミットするのに、すなわち更新を
恒久的にするのに必要なことを何でも行う（ステップ５
１６）。成功の回答が、当該のファイル・マネジャに代
わって保護ファイル・アダプタ６２Ａおよび６２Ｂから
送られ、同期点処理に中断がなかった場合（判断ブロッ
ク５１４）、同期点マネジャ６０Ａは、回復ファシリテ
ィ７０Ａを呼び出して、この作業論理ユニットに関して
ログ７２Ａに「忘却（ｆｏｒｇｅｔ）」の状態を書き込
む（ステップ５１５）。これは強制ログ書込みである必
要はない。すなわち、ログ・レコードをデータ・バッフ
ァに書込んだ後、同期点マネジャ６０Ａに戻ることがで
きる。このバッファは、後の時点で物理媒体に書き込む
ことができる。この実施例で使用する２段階コミット・
パラダイムに基づいて、同期点マネジャ６０Ａは、作業
論理ユニット識別子を更新し（１つだけ増分する）、こ
れによって、アプリケーション５６Ａの行う次の作業論
理ユニットが一義的であることを保証する。次に同期点
マネジャは、アプリケーション５６Ａに戻る（ステップ
５１５Ａ）。

【００３０】この２段階コミット・パラダイムは、回復
処理用の規則をもち、したがって、回復ファシリティ７
０Ａは、中断された同期点を完了する方法（ステップ５
１７および図４）を知っている。同期点マネジャ６０Ａ
の処理が中断された場合、判断ブロック５１４からステ
ップ５１７に進み、同期点マネジャ６０Ａが回復ファシ
リティ７０Ａにコンタクトする。ステップ５１７で、回
復ファシリティ７０Ａは、同期点マネジャ６０Ａから、
作業論理ユニット識別子と、障害を発生した１つまたは
複数の関連する資源に関する情報を受け取る。次に回復
ファシリティ７０Ａは、正しいログ・エントリを見つけ
る（図４のステップ５１８）。このログ情報を使用され
る２段階コミット・パラダイムと組み合わせて用いると
、回復ファシリティ７０Ａの手順で、中断された同期点
処理が完了できるようになる（ステップ５１９）。この
例で使用される２段階コミット・パラダイムに基づくと
、ログ７２Ａ上の作業論理ユニット識別子に対する同期
点状態エントリが「開始側、同期点マネジャ保留中」で
ある場合、障害を発生した資源マネジャ６３Ａまたは６
３Ｂはそれぞれ、バックアウトするよう命じられる。 そうでない場合は、各資源マネジャは、ログ上にある同
期点マネジャの段階２の状態、すなわちコミットまたは
バックアウトを命じられる（ステップ５２０）。回復状
態が決定された後、回復ファシリティ７０Ａは、下記「
保護された資源を回復するためのログ名の交換」および
「分散アプリケーション用の未完了の同期点のための回
復ファシリティ」に記載するように、障害を発生した各
保護資源マネジャで回復処理を開始する。この処理は、
ログ名の交換と状態の比較からなり、これによって回復
ファシリティ７０Ａの回復処理は、障害を発生した資源
マネジャ６３Ａまたは６３Ｂに、行うべきこと、すなわ
ちコミットまたはバックアウトを命じ、資源マネジャ６
３Ａまたは６３Ｂは、それが行ったことを回復処理に伝
える。回復ファシリティ７０Ａの回復処理は、同期点マ
ネジャ６０Ａがその段階１のロギング活動中に書き込ん
だ情報に基づいて、障害を発生した資源にコンタクトす
る方法を知る。障害を発生した資源マネジャがコンタク
ト可能である場合は（判断ブロック５２１）、即座に回
復が行われる（ステップ５２２）。障害を発生した各資
源で回復が行われた後（判断ブロック５２３）、同期点
マネジャ６０Ａに戻ることができる（ステップ５２３Ａ
）。その後、同期点マネジャ６０Ａは、アプリケーショ
ン５６Ａに戻る（ステップ５１５Ａ）。障害を発生した
資源マネジャがコンタクト不能である場合は、判断ブロ
ック５２１から判断ブロック５２４へ進み、回復ファシ
リティ７０Ａは、アプリケーション５６Ａに戻る前に回
復処理を完了しなければならないか否かを検査する。こ
の判定は、段階１のロギング中に同期点マネジャが書き
込んだ、作業論理ユニットに対するログ・レコードに含
まれる情報に基づいて行われる。回復を完了させなけれ
ばならない場合、回復処理は、障害を発生した資源とコ
ンタクトしようと試み続ける（ステップ５２５）。回復
を後の時点で完了してよい場合、すなわち回復を待つこ
とが以前に選択されている場合、回復ファシリティ７０
Ａは、下記「コミット手順の非同期的再同期化」に記載
のように、同期点マネジャ６０Ａに戻って、回復処理（
すなわち、コミットまたはバックアウト）の意図と、回
復が後で完了されるとの指示とを戻す（ステップ５２６
）。すべての資源が回復された時（ステップ５２５Ａ）
、同期点マネジャ６０Ａは、アプリケーション５６Ａに
この情報を戻す（ステップ５１５）。

【００３１】図２はまた、アプリケーション５６Ａが分
散アプリケーションの一部であり得ることを示している
。これは、アプリケーション５６Ａと共同してその処理
を完了することのできるパートナ・アプリケーションが
、少なくとも１つ存在することを意味する。分散アプリ
ケーションを確立するために、アプリケーション５６Ａ
は、保護された会話を開始する。この保護された会話は
、アプリケーション・プログラム会話開始インタフェー
スを呼び出すことによってシステム５０Ｄ内のパートナ
・アプリケーション５６Ｄを起動し、この会話が保護す
べきものであることを示す（図５Ａ、ステップ５３０）
。この要求は、保護会話アダプタ６４Ａによって処理さ
れる。保護会話アダプタ６４Ａは、同期点マネジャ６０
Ａに作業論理ユニット識別子を求め、これを一義的な会
話識別子と一緒に、遠隔システム５０Ｄに送る情報に含
める。次に、保護会話アダプタ６４Ａは、この要求を会
話マネジャ５３Ａに送り、会話マネジャ５３Ａは、これ
を通信ファシリティ５７Ａに送る。保護会話アダプタ６
４Ａは、会話開始要求が通信ファシリティ５７Ａから通
信ファシリティ５７Ｄに送られた（またはこれから送ら
れる）旨の指示を得る。この時、保護会話アダプタ６４
Ａは、同期点マネジャ６０Ａに登録する（ステップ５３
２）。会話開始要求は、この登録処理とは非同期に、通
信ファシリティ５７Ｄに送られ、次に会話マネジャ５３
Ｄに送られ、次に保護会話アダプタ６４Ｄに送られる（
図５Ａのステップ５３２）。保護会話アダプタ６４Ｄは
、作業論理ユニット識別子と一義的な会話識別子を検索
し、会話マネジャのために同期点マネジャに登録する（
ステップ５３２）。また、この時、保護会話アダプタ６
４Ｄは、会話開始要求時に受け取った作業論理ユニット
識別子を同期点マネジャ６０Ｄに与える。アプリケーシ
ョン５６Ｄによって行われた保護された作業が、最初に
アプリケーション５６Ａによって開始されたこの作業論
理ユニット識別子と関連づけられる（ステップ５３２）
。また、この作業論理ユニット識別子が、アプリケーシ
ョン５６Ｄ用の新しい作業ユニットに割り当てられ、そ
の後アプリケーション５６Ｄが開始される。

【００３２】したがって、アプリケーション５６Ａと５
６Ｄは、パートナ・アプリケーションであり、これらを
まとめて分散アプリケーションと称する。保護された会
話を用いると、アプリケーション５６Ａと５６Ｄが、対
等にデータを送受できるようになる。これは、アプリケ
ーション５６Ａまたはアプリケーション５６Ｄのどちら
側からも送信または受信を開始でき、それが、アプリケ
ーションの製作者と、通信マネジャが使用するパラダイ
ムとによって決定されることを意味する。上述したよう
に、保護された会話は、それぞれ保護会話アダプタ６４
Ａおよび６４Ｄによって、両方の同期点マネジャに登録
される。最初のコミットを発行したアプリケーションに
対する同期点処理の間、保護会話アダプタは、同期点マ
ネジャに対して資源を代理し、要求された作業をコミッ
トできるか否か（第１段階）、およびそれを成功裡に達
成したか否か（第２段階）を応答しなければならない。 パートナの保護会話アダプタから第１段階のコールを受
け取るもう一方の保護会話アダプタにとって、保護され
た会話はパートナの同期点マネジャであり、それを介し
て段階１と段階２の指令を受け取る。そのローカル同期
点マネジャは、資源マネジャのように振る舞う。すなわ
ち、保護会話アダプタは、同期点マネジャの資源が行っ
たことの結果を受け取る（段階１および段階２）。使用
される同期点パラダイムは、アプリケーション・パート
ナが第１のコミットを発行する規則を提供することに留
意されたい。この例では、どのアプリケーション・パー
トナも、最初にコミットを発行することができ、このこ
とは分散アプリケーションの設計によって決まる。

【００３３】アプリケーション５６Ａは、開始要求が通
信ファシリティ５７Ａから成功裡に送られた旨の指示と
共に制御を得る。この時点で、アプリケーション５６Ａ
は、アプリケーション５６Ｄに要求を送ることができ、
アプリケーション５６Ａは、確立された会話を介してア
プリケーション５６Ｄに要求を送る。この例では、最終
的にこの要求は、アプリケーション５６Ｄにファイル・
アプリケーション・プログラム・インタフェースを呼び
出させて、ファイル７８Ｄを更新させる。上述したよう
に、この更新要求は、保護ファイル・アダプタ６２Ｄに
、（アプリケーション５６Ｄが開始された時にアプリケ
ーション５６Ｄに割り当てられた（ステップ５３２））
同一の作業ユニットの下で、同期点マネジャ６０Ｄに登
録させる（ステップ５３３）。また、ステップ５３３で
、アプリケーション５６Ｄは、会話を介してアプリケー
ション５６Ａに、作業を完了したことを示す応答を送る
。次に、アプリケーション５６Ａは、ファイル７８Ａお
よび７８Ｂに関する更新要求を発行する。上述したよう
に、保護ファイル・アダプタ６２Ａおよび６２Ｂは、す
でに同期点マネジャ６０Ａに登録済みであり、それぞれ
資源マネジャ６３Ａおよび６３Ｂにコンタクトしてこの
更新を実行する（ステップ５３３および５３３Ａ）。

【００３４】ここでアプリケーション５６Ａは、同期点
マネジャ６０Ａにコミット５８Ａを発行する（ステップ
５３４）。上述したように、同期点マネジャ６０Ａは、
回復ファシリティ７０Ａにコンタクトしてその段階１の
ロギングを求め、登録された各資源に対して段階１の「
準備」コールを発行する（ステップ５３４Ａおよび５３
５Ａ）。保護ファイル・アダプタ６２Ａおよび６２Ｂは
、上述したように振る舞う。保護会話アダプタ６４Ａは
、段階１の「準備」コールを受け取った時、それが代理
する保護された会話、すなわち最初にアプリケーション
５６Ａによってアプリケーション５６Ｄに対して確立さ
れた会話を介して、体系的システム間「準備」コールを
送る（ステップ５３５）。保護会話アダプタ６４Ｄは、
この「準備」コールを認識して、会話メッセージ受取コ
ールを発行したアプリケーション５６Ｄに、コミットの
発行を要求する戻りコードを与える（ステップ５３６）
。次に、アプリケーション５６Ｄは、同期点マネジャ６
０Ｄに対してコミット５８Ｄを発行する（ステップ５３
７）。上述したように、同期点マネジャ６０Ｄはその回
復ファシリティにコンタクトするが、この場合は、回復
ファシリティ７０Ｄにコンタクトして、段階１情報をロ
グ７２Ｄに強制ロギングさせる（ステップ５３８）。ア
プリケーション５６Ａが元のコミット要求を発行し、そ
の要求に応じてアプリケーション５６Ｄが後でコミット
を発行したので、この実施例で使用する２段階コミット
・パラダイムに基づくと、同期点マネジャ６０Ｄの段階
１の状態は「開始側カスケード、同期点マネジャ保留中
（Ｉｎｉｔｉａｔｏｒ　　Ｃａｓｃａｄｅ，Ｓｙｎｃｐ
ｏｉｎｔ　　Ｍａｎａｇｅｒ　　Ｐｅｎｄｉｎｇ）」で
ある（ステップ５３８）。同期点マネジャ６０Ｄは、段
階１の「準備」コールを用いて保護ファイル・アダプタ
６２Ｄにコンタクトする（ステップ５３８）。保護ファ
イル・アダプタ６２Ｄとそれに関連する資源マネジャ６
３Ｄは、上述したように段階１の処理を実行し、「コミ
ット要求」の回答を戻す。

【００３５】この例では、中断がなかったので、判断ブ
ロック５３９からステップ５４０に進み、同期点マネジ
ャ６０Ｄが、回復ファシリティ７０Ｄにコンタクトして
、ログ７２Ｄを「代理、不確定（Ａｇｅｎｔ，Ｉｎｄｏ
ｕｂｔ）」の状態に強制ロギングさせる。この状態は、
その後に中断が起こり、その結果、同期点マネジャ６０
Ｄが、同期点マネジャ６０Ａから段階２の決定を受け取
らなくなる場合、回復ファシリティ７０Ａからの回復処
理がその同期点処理を完了するのを待たなければならな
いことを意味する。次に、同期点マネジャ６０Ｄは、保
護会話アダプタ６４Ｄにコンタクトして「コミット要求
」の回答を与える。次に、保護会話アダプタ６４Ｄは、
体系的システム間フォーマットの「コミット要求」を保
護会話アダプタ６４Ａに送り（ステップ５４１）、保護
会話アダプタ６４Ａは、同期点マネジャ６０Ａに「コミ
ット要求」と回答する（ステップ５４２）。 上述したように、同期点マネジャ６０Ａは保護ファイル
・アダプタ６２Ａおよび６２Ｂから「コミット要求」を
受け取った（ステップ５３５Ａ）。この例では中断がな
いので、判断ブロック５４３からステップ５４４に進み
、同期点マネジャ６０Ａが回復ファシリティ７０Ａにコ
ンタクトして、ログ７２Ａを段階２の「開始側、コミッ
ト済み（Ｉｎｉｔｉａｔｏｒ，ｃｏｍｍｉｔｔｅｄ）」
の状態に強制ロギングさせる（ステップ５４４）。次に
、同期点マネジャ６０Ａは、段階２の「コミット済み」
の決定で、登録された各保護資源アダプタを呼び出す（
図５Ｂ、ステップ５４５）。保護ファイル・アダプタ６
２Ａおよび６２Ｂは、上述したようにこのコミットの決
定を処理する（ステップ５４５Ａ）。保護会話アダプタ
６４Ａは、このコミット決定を受け取った時、それが代
理する保護会話、すなわち最初にアプリケーション５６
Ａによってアプリケーション５６Ｄに対して確立された
会話を介して、体系的システム間フォーマットの「コミ
ット済み」コールを送る（ステップ５４６）。保護会話
アダプタ６４Ｄは、この「コミット」コールを受け取り
、同期点マネジャ６０Ｄに段階２の「コミット」の決定
を回答する（ステップ５４７）。

【００３６】上述したように、同期点マネジャ６０Ｄは
、回復ファシリティ７０Ｄにコンタクトして、ログ７２
Ｄを段階２の状態に強制ロギングさせる。アプリケーシ
ョン５６Ａが、元のコミット要求を発行し、それに応じ
てアプリケーション５６Ｄが後でコミットを発行したの
で、この実施例で使用する２段階コミット・パラダイム
に基づいて、同期点マネジャ６０Ｄの段階２の状態は「
開始側カスケード、コミット済み」である（ステップ５
４８）。同期点マネジャ６０Ｄは、保護ファイル・アダ
プタ６２Ｄにコンタクトしてこの段階２のコミットの決
定を与える（ステップ５４９）。保護ファイル・アダプ
タ６２Ｄとそれに関連する資源マネジャ６３Ｄは、上述
のコミット処理を行い、「忘却」の回答を戻す。中断が
なかった（判断ブロック５５０）ので、同期点マネジャ
６０Ｄは回復ファシリティ７０Ｄにコンタクトして、こ
の作業論理ユニットに対する同期点ログ・レコードに対
して、状態「忘却」をログ７２Ｄにロギングさせる（ス
テップ５５１）。「忘却」は、同期点処理が完了し、そ
のログ・レコードが消去可能であることを意味する。次
に、同期点マネジャ６０Ｄは、保護会話アダプタ６４Ｄ
とコンタクトして、「忘却」の回答を与える。この実施
例で使用する２段階コミット・パラダイムに基づいて、
同期点マネジャ６０Ｄは、作業論理ユニット識別子を１
だけ増分し、アプリケーション５６Ｄに、コミットが成
功裡に完了したとの指示を戻す（ステップ５５２）。作
業論理ユニット識別子を更新することによって、分散ア
プリケーションが行う次の作業論理ユニットが一義的で
あることが保証される。

【００３７】次に、保護会話アダプタ６４Ｄは、体系的
システム間フォーマットの「忘却」の回答を保護会話ア
ダプタ６４Ａに送り、保護会話アダプタ６４Ａは、同期
点マネジャ６０Ａに「忘却」を回答する（ステップ５５
３）。上述したように、同期点マネジャ６０Ａは、保護
ファイル・アダプタ６２Ａおよび６２Ｂからも「忘却」
の回答を受け取る（ステップ５４５Ａ）。中断がないと
仮定すると、判断ブロック５５４からステップ５５５に
進んで、同期点マネジャ６０Ａは、回復ファシリティ７
０Ａにコンタクトして、この作業論理ユニットに対して
、状態「忘却」をログ７２Ａにロギングさせる。やはり
、使用する２段階コミット・パラダイムに基づいて、次
に同期点マネジャ６０Ａは作業論理ユニット識別子を１
だけ増分する（ステップ５５６）。この変更によって、
分散アプリケーションに対する次の作業論理ユニット識
別子が一義的であることが保証される。次に、同期点マ
ネジャ６０Ａは、このコミット要求が成功裡に完了した
旨をアプリケーション５６Ａに通知する。２段階コミッ
ト手順中に、同期点マネジャ６０Ａまたは同期点マネジ
ャ６０Ｄまたはその両方内で同期点処理が中断された場
合、回復ファシリティ７０Ａおよび回復ファシリティ７
０Ｄは、論理流れの中でステップ５５７と５５８および
ステップ５５９と５６０で表される回復動作を実施する
ことになる。この回復動作は、下記「保護された資源を
回復するためのログ名の交換」、「分散アプリケーショ
ン用の未完了の同期点のための回復ファシリティ」およ
び「コミット手順の非同期的再同期化」にさらに詳しく
説明されている。

【００３８】図５５は、図２の実施例の代替実施例であ
り、図２と比較して説明するのが最適である。図２およ
び図５５では共に、アプリケーション環境、システム・
ファシリティおよび資源マネジャが分散されている。し
かし、図２では、１つの物理装置、システム５０Ａが、
複数のアプリケーション環境５２Ａ、５２Ｂ、５２Ｃ、
２つの資源マネジャ６３Ａ、６３Ｂ、回復ファシリティ
７０Ａおよび通信ファシリティ５７Ａを含んでいる。図
２では、システム制御プログラム５５Ａは、会話マネジ
ャ５３Ａおよび同期点マネジャ６０Ａ、６０Ｂ、６０Ｃ
を含んでいる。図２のシステム５０Ａは、メインフレー
ム・コンピュータであってよく、このタイプの構成は、
しばしば集中コンピュータ処理と呼ばれる。また、図２
では、システム５０Ａ内のアプリケーション環境が、通
信ネットワークを介してシステム５０Ｄ内のアプリケー
ション環境に接続されている。これとは対照的に、図５
５では、アプリケーション環境、システム・ファシリテ
ィおよび資源マネジャが、それぞれ別々の実計算機内に
ある。この構成は、分散コンピュータ処理と呼ばれる。 この環境では、システム９０Ａ、９０Ｂ、９０Ｃ、１１
０Ｅ、１１４Ｆ、１２０Ｇは、プログラム式ワークステ
ーションであって、図２のシステム５０Ａおよび５０Ｄ
に機能は類似しているが、サイズや性能は必ずしも類似
していない。図５５のシステムは、たとえばローカル・
エリア・ネットワーク（ＬＡＮ）などの通信ネットワー
クによって接続される。図５５のアプリケーション環境
９２Ａ、９２Ｂ、９２Ｃは、図２のアプリケーション環
境５２Ａ、５２Ｂ、５２Ｃと機能は同等である。しかし
、アプリケーション環境９２Ａ、９２Ｂ、９２Ｃはそれ
ぞれ、別々のプログラム式ワークステーションに含まれ
ている。図５５のシステム制御プログラム９５Ａ、９５
Ｂ、９５Ｃはそれぞれ、図２のシステム制御プログラム
５５Ａと機能的に同等である。システム制御プログラム
９５Ａ、９５Ｂ、９５Ｃはそれぞれ、（ａ）同期点マネ
ジャ６０Ａ、６０Ｂ、６０Ｃと機能的に同等な同期点マ
ネジャ１００Ａ、１００Ｂ、１００Ｃ、（ｂ）実行環境
制御プログラム６１Ａ、６１Ｂ、６１Ｃと機能的に同等
な実行環境制御プログラム９１Ａ、９１Ｂ、９１Ｃ、（
ｃ）保護会話アダプタ（ＰＣＡ）６４Ａ、６４Ｂ、６４
Ｃと機能的に同等な保護会話アダプタ１０４Ａ、１０４
Ｂ、１０４Ｃ、（ｄ）資源アダプタ（ＲＡ）６２Ａおよ
び６２Ｂと機能的に同等な資源アダプタ１０２Ａ、１０
２Ｂ、１０２Ｃ、および１０３Ａ、１０３Ｂ、１０３Ｃ
、（ｅ）会話マネジャ５３Ａ、５３Ｂ、５３Ｃと機能的
に同等な会話マネジャ９３Ａ、９３Ｂ、９３Ｃ、および
通信ファシリティ５７Ａと機能的に同等な通信ファシリ
ティ９７Ａ、９７Ｂ、９７Ｃを含む。しかし、図５５の
例では、通信ファシリティは各システム制御プログラム
９５Ａ、９５Ｂ、９５Ｃの一部であって、それ自体の実
行環境に含まれてはいない。また、図５５では、資源マ
ネジャ１１２Ｅおよび１１３Ｆは、図２の資源マネジャ
６３Ａおよび６３Ｂと機能的に同等であり、それらのフ
ァイル１１５Ｅ、１１７Ｆおよびログ１１６Ｅ、１１８
Ｆは、図２のファイル７８Ａ、７８Ｂおよびログ８００
Ａ、８００Ｂと機能的に同等である。しかし、資源マネ
ジャ１１２Ｅおよび１１３Ｆは、それぞれ別々のプログ
ラム式ワークステーション上にある。図５５の回復ファ
シリティ１２１Ｇおよびそのログ１２２Ｇは、図２の回
復ファシリティ７０Ａおよびそのログ７２Ａと機能的に
同等である。しかし、回復ファシリティ１２１Ｇは１つ
のプログラム式ワークステーション内にある。図５５の
システム５０Ｄは、図２のシステム５０Ｄと同一であり
、このネットワークの融通性を示すために含めてある。 この環境での同期点処理の説明は、上記の同期点処理の
説明で、図２の番号を対応する図５５の番号に置き換え
ることによって得られる。したがって、本発明は広範囲
なコンピュータ・システムおよびネットワークで実施で
きる。

【００３９】図２のシステム５０Ａ内で、様々な理由か
ら回復ファシリティ７０Ａが利用不能になる可能性があ
る。したがって、システム５０Ａはバックアップを提供
する。たとえば、回復ファシリティ７０Ａが、資源マネ
ジャをも制御する実行環境の一部であり、この資源マネ
ジャが動作不能になる障害に出会った場合、回復ファシ
リティ７０Ａも動作不能になる。図２８に示した例では
、システム５０Ａは１つの資源マネジャ専用の複数の実
行環境を含み、その資源マネジャを含む各実行環境が回
復ファシリティ・プログラムをも含んでいるが、システ
ム内で同時に活動状態になれる回復ファシリティは１つ
だけである。

【００４０】具体的に言うと、図２８では、システム５
０Ａ内に、それぞれ資源マネジャ（プログラム）２６０
Ａ、２６０Ｂ、２６０Ｃを含む３つの同等な実行環境５
２Ｅ、５２Ｆ、５２Ｇがある。資源マネジャ２６０Ａ、
２６０Ｂ、２６０Ｃはそれぞれ、ＶＭ／ＳＰリリース６
オペレーティング・システムの共用ファイル・システム
（ＳＦＳ）資源マネジャ（“ＶＭ”はＩＢＭコーポレー
ションの登録商標）の拡張バージョンとそれに関連する
資源２６２Ａ、２６２Ｂ、２６２Ｃであることが好まし
い。さらに、各実行環境５２Ｅ、５２Ｆ、５２Ｇはまた
、図２３に示した回復ファシリティ７０Ａの機能を実現
するため、プログラム７０Ａ、７０Ｂ、７０Ｃをも含む
。共用ファイル・システムを含む実行環境内に各回復フ
ァシリティを置くことの利点は、その共用ファイル・シ
ステムに、回復ファシリティが使用できるサービス、す
なわち通信サービスおよびタスク処理サービスが含まれ
ることである。通信サービスは、通信プロトコル、割込
み処理、メッセージ管理を処理する。図２８のシステム
５０Ａでは、回復ファシリティ７０Ａは、当初、実行環
境５２Ｅが初期設定される際に回復ファシリティ・ログ
７２Ａに関連づけられる回復ファシリティとして、シス
テム制御プログラムに識別される。これは、実行環境５
２Ｅの初期設定処理への入力としてあるパラメータを指
定することによって達成される。実行環境５２Ｅは、シ
ステム制御プログラムに対してそれ自体を、回復ファシ
リティとして、かつシステム５０Ａ内での資源識別子ｓ
ｙｎｃ＿ｐｏｉｎｔ＿ｌｏｇに対するすべての通信のタ
ーゲットとして識別する（資源識別子ｓｙｎｃ＿ｐｏｉ
ｎｔ＿ｌｏｇの説明については、「保護された資源を回
復するためのログ名の交換」を参照されたい。）。この
資源識別子ｓｙｎｃ＿ｐｏｉｎｔ＿ｌｏｇは、システム
５０Ａ内で一義的でなければならず、常に１つの実行環
境にしか関連づけることができない。この実施例では、
実行環境５２Ｅが回復ファシリティ・ログ７２Ａを含む
持久記憶域を定義し、その結果、実行環境５２Ｅを指定
すると、別の記憶域を指定するそれに勝る指定がない場
合、自動的にログ７２Ａが資源回復ログとして暗示され
ることになる。

【００４１】ところが、実行環境５２Ｅが利用不能であ
る場合、ユーザはバックアップとして回復ファシリティ
７０Ｂまたは７０Ｃを活動化し、ログ７２Ａを実行環境
５２Ｆまたは５２Ｇに移動することができる。これは、
実行環境５２Ｆまたは５２Ｇの初期設定時に前述のパラ
メータを指定し、この実行環境に対して回復ファシリテ
ィ・ログ７２Ａの位置を指定することによって行われる
。ユーザがログ７２Ａの位置を指定するには、回復ファ
シリティ・ログ７２Ａを含む持久記憶域の位置を識別す
るのに必要な、選択された実行環境５２Ｆまたは５２Ｇ
からのコマンドを、システム制御プログラムに与える。

【００４２】同期点障害の後に再同期化を完了するため
に回復ファシリティが必要とする情報は、すべて回復フ
ァシリティ・ログ７２Ａに含まれており、同期点回復に
必要な情報は、実行環境、資源マネジャまたは関連する
持久記憶域には含まれていない。したがって、回復ファ
シリティ・プログラムを含む資源マネジャを有するどん
な実行環境も、活動状態の回復ファシリティがログ７２
Ａにアクセスできる限り、回復ファシリティ７０Ａとし
て動作することができる。回復ファシリティ機能の、実
行環境５２Ｆへのバックアップ転送は、通信経路２７２
Ｂで示され、回復ファシリティ機能の、実行環境５２Ｇ
へのバックアップ転送は、通信経路２７２Ｃで示されて
いる。

【００４３】回復ファシリティ７０を備えたアプリケー
ション環境内の同期点マネジャ６０Ａ、６０Ｂまたは６
０Ｃのいずれかの間で通信を行うには、システム制御プ
ログラムを介して回復ファシリティに対する会話を開始
する際に、資源識別子ｓｙｎｃ＿ｐｏｉｎｔ＿ｌｏｇを
使用する。

【００４４】作業ユニットに合わせて調整されたローカ
ルおよびグローバルなコミット範囲前述の図５Ａおよび
５Ｂの流れ図には、単一の作業論理ユニットまたはコミ
ット範囲が、たとえば異なるシステム内の複数の実行環
境内の資源とアプリケーションなど、異なるシステム内
の２つのアプリケーション・パートナに拡がり、コミッ
ト手順がこの２つのアプリケーション・パートナの間で
調整される場合の例が示されている。以下に、この処理
、ならびにシステム５０Ａが、同一の実行環境内にある
同一のアプリケーションに別々の作業ユニットまたはコ
ミット範囲を提供できることについて、詳細に説明する
。すべてのシステム５０は、このように１つまたは複数
の関連する作業ユニットに用いられる資源に合わせてコ
ミット範囲を正確に調整することができる。

【００４５】上述したように、「作業ユニット」とは、
１つのアプリケーションから直接アクセス可能であり、
共通の同期点に参加する、資源の範囲である。たとえば
（図２において）、資源アダプタ６２Ａ、６２Ｂおよび
保護会話アダプタ６４Ａに結合された資源は、すべてア
プリケーション５６Ａから直接アクセス可能であり、し
たがって、すべて同一の作業ユニットを有することがで
きる。これらがすべてアプリケーション５６Ａによって
行われる関連する作業要求に用いられる場合、これらは
すべて同一の作業ユニットを有する。作業ユニット識別
子は、システム制御プログラム５５によって選択され、
それぞれの実行環境内で一義的である。この実施例では
、システム制御プログラム５５Ａは、会話マネジャ５３
Ａと、各実行環境５２用の実行環境制御プログラム６１
を含む。限定ではなく例として示すと、実行環境制御プ
ログラム６１Ａは、ＶＭ／ＳＰリリース６オペレーティ
ング・システム（“ＶＭ”はＩＢＭコーポレーション．
の登録商標）の拡張ＣＭＳ構成要素でよい。この実行環
境制御プログラムは、アプリケーション５６Ａの実行を
制御し、上述したように、作業ユニット識別子を割り当
てる。したがって、作業ユニット識別子は、各実行環境
内で一義的である。アプリケーションは、複数の関連す
る作業要求に対して同一の作業ユニットを使用し、関連
しない作業要求に対しては異なる作業ユニットを使用す
る。「作業論理ユニット」識別子とは、関連する作業要
求に使用されるすべての資源に対するグローバルに一義
的な（ネットワーク全体を通じての）識別子であり、関
連する作業要求をすべてカバーする。作業論理ユニット
識別子は、その作業要求を生成したシステムの回復ファ
シリティ７０によって割り当てられ、この実施例では、
下記のものを含む。 （１）相互接続された１群のシステムを識別する、ネッ
トワーク識別子、 （２）そのネットワーク内の１つの通信ファシリティを
識別する、システム識別子、 （３）ローカルに一義的な要素をＬＵＷＩＤに与える、
インスタンス番号（たとえば、タイムスタンプを使用し
てよい）、 （４）特定の同期点インスタンスを識別する、シーケン
ス番号。たとえば、これは、“Ｓｙｓｔｅｍ　Ｎｅｔｗ
ｏｒｋ　Ａｒｃｈｉｔｅｃｔｕｒｅ　ＬＵ６．２　Ｒｅ
ｆｅｒｅｎｃｅ：　Ｐｅｅｒ　Ｐｒｏｔｏｃｏｌｓ，　
ＳＣ３１−６８０８　Ｃｈａｐｔｅｒ　５．３　Ｐｒｅ
ｓｅｎｔａｔｉｏｎ　Ｓｅｒｖｉｃｅｓ−　Ｓｙｎｃ　
Ｐｏｉｎｔ　ｖｅｒｂｓ”によって定義されるタイプの
ものである。同期点マネジャ６０は、保護会話が作業ユ
ニット内で使用される場合、または作業要求が保護会話
を必要としなくとも、２段階コミット手順が必要な場合
に、回復ファシリティから作業論理ユニット識別子（Ｌ
ＵＷＩＤ）を要求する。ＬＵＷＩＤは、資源アダプタが
同期点マネジャを呼び出すことによって要求することが
でき、またＬＵＷＩＤがまだ獲得されていないがコミッ
トのために必要な場合には、コミット処理の始めに同期
点マネジャがＬＵＷＩＤを要求することができる。以下
で詳細に説明するように、保護された会話や多数の保護
された資源などの保護された資源が作業ユニットで使用
される時に、作業ユニットがＬＵＷＩＤと関連づけられ
る。作業ユニットは、複数のファイルと複数のファイル
記憶場所の混合物、他の保護された資源と他の参加する
資源マネジャ、およびある分散アプリケーションの異な
る部分間での保護された会話を含むことができる。保護
された会話の場合は、各アプリケーション・パートナが
、この同一の保護された会話とこのアプリケーションに
よって直接アクセスされる他の資源とに（それぞれの実
行環境内で）異なる作業ユニットを割り当てる場合であ
っても、単一の作業論理ユニットが、２つ以上のアプリ
ケーション・パートナの間に拡がる。したがって、ある
保護された会話に関連する各アプリケーション・パート
ナはそれぞれ、それ自体の作業ユニットをローカルに割
り当てて使用するが、２つ以上のアプリケーション・パ
ートナの作業ユニットは、同一の分散された作業論理ユ
ニットを参照する。各実行環境は、他の実行環境で割り
当てられた作業ユニットの識別を知らず、異なる実行環
境内の作業ユニットが同一の識別子を有することは、偶
然の一致によってしか起こり得ないことに留意されたい
。ＬＵＷＩＤではなく、上述の拡張された範囲をもつ作
業ユニットを使用して、ローカルなコミット範囲が定義
される。というのは、既存のアプリケーションが、最小
限の変更で拡張された機能の利益を享受できるからであ
る。作業ユニットからＬＵＷＩＤへの変更は面倒であり
、既存のアプリケーションを変更する必要がある。

【００４６】図６ないし図９は、同一のアプリケーショ
ン５６Ａ用の異なる作業ユニットおよび作業論理ユニッ
トと、それぞれ異なるシステム５０Ａおよび５０Ｄ内で
実行される複数のアプリケーション・パートナ５６Ａお
よび５６Ｄに関連づけられた複数の資源に拡がる別の作
業論理ユニットとを確立する処理を、実例によって示し
た図である。図７に示した例で、アプリケーション５６
Ａが開始され、実行環境制御プログラム６１Ａから作業
ユニット識別子Ｘを得る（ステップ９２８）。実行環境
制御プログラムは、各実行環境内で一義的な作業ユニッ
ト識別子を選択する責任を負う。次に、アプリケーショ
ン５６Ａは、実行環境５２Ａ内の資源アダプタ６２Ａに
対して作業要求を行って、資源７８Ａ内にある１ファイ
ルを更新してこの作業要求を作業ユニットＸの下で行う
ように、あるいはデフォルトにより、アプリケーション
５６Ａによって指定された「現作業ユニット」の下に割
り当てられるように指定する（ステップ９３０）。資源
アダプタが作業ユニットＸ用のＬＵＷＩＤを要求する場
合（判断ブロック９３５）、同期点マネジャ６０Ａは、
ＬＵＷＩＤがまだ割り当てられていなければ、回復ファ
シリティ７０Ａから作業ユニットＸをカバーするＬＵＷ
ＩＤを要求し、そのＬＵＷＩＤを作業ユニットＸと関連
づける。その後、同期点マネジャは、資源アダプタにこ
のＬＵＷＩＤを戻す（ステップ９３６）。図６に示した
例では、（資源アダプタ６２Ａを介してアクセスされた
）資源７８Ａは、保護された会話ではないので、判断ブ
ロック９３７（図７）からステップ９３９に進み、資源
が更新される。資源アダプタ６２Ａが、まだ作業ユニッ
トＸのために登録されていない場合（判断ブロック９３
３）、資源アダプタ６２Ａを同期点マネジャ６０Ａに登
録する（ステップ９３４）。前述の例では、アプリケー
ション５６Ａは、同一の作業ユニットの下でさらに別の
作業を行うことは望まず（判断ブロック９４０）、関連
しない新規の作業を行うことも望まない（判断ブロック
９４１）ので、次のステップでは、アプリケーション５
６Ａがコミットを発行する（ステップ９４２）。これに
応答して、同期点マネジャ６０Ａは、１段階コミット手
順を開始する（ステップ９４４）。ところで、アプリケ
ーション５６Ａは、他の関連しない作業要求を開始する
前に作業ユニットＸのためにコミットを発行する必要が
ないことに留意されたい（判断ブロック９４１）。この
特定の場合には、同期点マネジャは、１段階のコミット
手順を実行するので、ＬＵＷＩＤは不要である。

【００４７】この例では、アプリケーション５６Ａは、
次に作業ユニットＸとは独立な作業を行うために、下記
の処理を開始する。アプリケーション５６Ａは、実行環
境制御プログラム６１Ａから新規の作業ユニットを要求
し、実行環境制御プログラム６１Ａは、作業ユニットＹ
を戻す（ステップ９２８）。次に、アプリケーション５
６Ａは、資源アダプタ６２Ｂを介して、作業ユニットＹ
の下で資源７８Ｂを更新する要求を行う（ステップ９３
０）。資源アダプタが作業ユニットＹ用のＬＵＷＩＤを
要求する場合（判断ブロック９３５）、同期点マネジャ
６０Ａは、回復ファシリティ７０ＡからＬＵＷＩＤを得
て、それを作業ユニットＹと関連づける（ステップ９３
６）。この時、作業ユニットＹ用の作業論理ユニットは
、資源マネジャ６３Ｂのみに拡がる。次に、資源７８Ｂ
に対する更新を実施する（ステップ９３９）。資源アダ
プタ６２Ｂは、まだ作業ユニットＹのために登録されて
いないので、同期点マネジャ６０Ａに登録される（ステ
ップ９３４）。

【００４８】次に、アプリケーション５６Ａは、同一の
作業ユニットＹの下で、さらに別の作業たとえば他の資
源中のデータの変更を行うことを望む（判断ブロック９
４０）。図６に示した例では、この別の作業は保護され
た会話であり、この保護された会話が、分散アプリケー
ション・パートナ５６Ｄを介してシステム５０Ｄ内の資
源にアクセスするのに使用される。この例では、これが
新規の保護された会話の始まりである。すなわち、アプ
リケーション５６Ａは、作業ユニットＹの下で、アプリ
ケーション５６Ｄとの新規の保護された会話を開始する
（ステップ９３０）。保護会話アダプタ６４Ａは作業ユ
ニットＹ用のＬＵＷＩＤを要求するので、ＬＵＷＩＤが
まだ割り当てられておらず、作業ユニットに関連づけら
れていない場合、同期点マネジャは、回復ファシリティ
を呼び出し、保護会話アダプタにＬＵＷＩＤを戻す（ス
テップ９３６）（保護会話アダプタは、この会話を開始
する時にＬＵＷＩＤを必要とする（ステップ９４７）。 ）。次に、判断ブロック９３７から判断ブロック９４６
に進む。これは新規の保護された会話であるので、会話
マネジャ５３Ａは、保護された会話を開始し、作業ユニ
ットＹに関連するＬＵＷＩＤを通信ファシリティに送る
（ステップ９４７）。この例では、アプリケーション・
パートナ５６Ｄが異なるシステム内に常駐しているので
、通信ファシリティ５７Ａを使用する。しかし、アプリ
ケーション・パートナが同一のシステム５０Ａ内の別の
実行環境、たとえば５２Ｂ内に常駐している場合は、こ
の通信機能は、システム制御プログラム５５Ａの会話マ
ネジャ５３Ａによって提供され、通信ファシリティ５７
Ａは使用されないことに留意されたい。保護会話アダプ
タ６４Ａが会話マネジャ５３Ａから制御を返され、保護
会話開始要求が成功したことが示された時、保護会話ア
ダプタ６４Ａは、同期点マネジャ６０Ａに登録され（ス
テップ９４８）、アプリケーション５６Ａに制御を返す
。この時、アプリケーション５６Ａは、アプリケーショ
ン５６Ｄにメッセージを送って、資源７８Ｄの更新を要
求する（ステップ９４９）。ただし、このメッセージは
、アプリケーション５６Ｄが開始されるまで、システム
５０Ｄ内にバッファされる。メッセージを送った後、ア
プリケーション５６Ａはこれ以上行うべき作業がない（
判断ブロック９４０および９４１）ので、作業ユニット
Ｙに対するコミットを発行する（ステップ９４２）。同
期点マネジャ６０Ａが、２段階コミット手順を開始する
（ステップ９４４）。

【００４９】システム制御プログラム５５Ｄが、通信フ
ァシリティ５７Ｄを介して通信ファシリティ５７Ａから
会話開始要求を受け取った時（図８のステップ９６０）
、システム制御プログラム５５Ｄは、実行環境５２Ｄを
開始する（ステップ９６２）。保護会話アダプタ６４Ｄ
は、実行環境５２Ｄ用の新規の作業ユニットＺを獲得し
、この実行環境５２Ｄ内で、アプリケーション５６Ｄが
実行環境制御プログラム６１Ｄから実行されることにな
る。この作業ユニットは、実行環境５２Ｄ内で一義的で
ある。また、保護会話アダプタ６４Ｄは、開始された会
話で受け取ったＬＵＷＩＤをこの新規の作業ユニットに
関連づけるよう同期点マネジャに指令し、その後、この
新規の作業ユニットの下で同期点マネジャ６０Ｄに登録
される（ステップ９６６）。（ステップ９４７での会話
開始要求の流れは、保護会話アダプタ６４Ａから、会話
マネジャ５３Ａ、通信ファシリティ５７Ａ、通信ファシ
リティ５７Ｄ、会話マネジャ５３Ｄを経て、保護会話ア
ダプタ６４Ｄへと向かう。）その後、アプリケーション
５６Ｄが開始される。

【００５０】次に、アプリケーション５６Ｄは、ステッ
プ９３０Ｄで作業要求を行う。この例では、この最初の
作業要求は、会話上でメッセージを受け取ることである
。この保護された会話はすでにＬＵＷＩＤを有している
ので、判断ブロック９３５Ｄから判断ブロック９３７Ｄ
に進む。これは、保護された会話であるが、新規のアウ
トバウンドな保護された会話ではない（すなわち、新規
の保護された会話の開始ではない）ので、判断ブロック
９３７Ｄおよび９４６Ｄからステップ９４９Ｄに進み、
メッセージをアプリケーション５６Ｄが受け取る。

【００５１】図６以降に示した例では、保護された会話
は、アプリケーション５６Ｄに、追加の作業、たとえば
（資源アダプタ６２Ｄを介して）資源７８Ｄ内のファイ
ルの更新を行わせ、したがって判断ブロック９４０Ｄか
らステップ９３０Ｄに進み、アプリケーション５６Ｄが
、作業ユニットＺを使用して資源７８Ｄを更新するよう
にとの作業要求を行う。資源アダプタがＬＵＷＩＤを要
求する場合（判断ブロック９３５Ｄ）、同期点マネジャ
は資源アダプタにＬＵＷＩＤを戻す（ステップ９３６Ｄ
）。ステップ９６６ですでにＬＵＷＩＤが割り当てられ
、作業ユニットに関連づけられているので、回復ファシ
リティを呼び出してＬＵＷＩＤを割り当てる必要はない
。この作業要求は、保護された会話資源を使用しないの
で、判断ブロック９３７Ｄからステップ９３９Ｄに進み
、作業要求に従って資源７８Ｄを更新する。資源アダプ
タ６２Ｄはまだ登録されていないので、判断ブロック９
３３Ｄからステップ９３４Ｄに進み、資源アダプタ６２
Ｄが同期点マネジャ６０Ｄに登録される。この時点でア
プリケーション５６Ｄは、アプリケーション５６Ａがい
つこの作業のコミットを要求するかを決定する必要があ
る。これは、アプリケーション５６Ｄにより、保護され
た会話上で（作業要求を）受け取ることによって、達成
される。アプリケーション５６Ａがコミットを発行済み
の時には、アプリケーション５６Ｄは、戻りコードＴａ
ｋｅ＿Ｓｙｎｃｐｏｉｎｔを得る。したがって、判断ブ
ロック９４０Ｄからステップ９３０Ｄに進み、アプリケ
ーション５６Ｄが、作業ユニットＺの下で保護された会
話上で受取りを発行する。保護会話アダプタ６４Ｄには
ＬＵＷＩＤが不要であり（判断ブロック９３５Ｄ）、こ
の作業要求は保護された会話を使用し（判断ブロック９
３７Ｄ）、この保護された会話は新規のアウトバウンド
な会話ではない（判断ブロック９４６Ｄ）ので、受取り
が行われる（ステップ９４９Ｄ）。アプリケーション５
６Ｄには、作業ユニットＺ上で行うべき追加の作業がな
いので、判断ブロック９４０Ｄから判断ブロック９４１
Ｄに進む。 アプリケーション５６Ａがコミットを発行済みの時は（
判断ブロック９４１Ｄ）、アプリケーション５６Ｄは、
受取り時に戻りコードＴａｋｅ＿Ｓｙｎｃｐｏｉｎｔを
得て、コミットを発行する（ステップ９４２Ｄ）。次に
、同期点マネジャ６０Ｄが、コミット手順を開始する（
ステップ９４４Ｄ）。この例では、これで作業ユニット
Ｚに関連する作業要求は完了し、判断ブロック９５０Ｄ
からアプリケーション５６Ｄの終わりに進む。この時、
アプリケーション５６Ａは、同期点マネジャ６０Ａから
制御を返され、終了する。

【００５２】図９（および上記の図３ないし図５）には
、本発明で使用する例による、実行環境５２Ａおよび５
２Ｄ内でのコミットのタイミングが示されている。保護
された会話が、実行環境５２Ａに対して送られる状態の
時、アプリケーション５６Ａは、ステップ９４２（図７
）に関して前述したように、作業ユニットＹに関するコ
ミットを発行する。実行環境５２Ｄが、保護された会話
に対して受け取る状態にある時は、実行環境５２Ｄは、
実行環境５２Ａから戻りコードＴａｋｅ＿Ｓｙｎｃｐｏ
ｉｎｔと共にメッセージを受け取る。戻りコードＴａｋ
ｅ＿Ｓｙｎｃｐｏｉｎｔを受け取った後、アプリケーシ
ョン５６Ｄはできるだけ早くコミットを発行すべきであ
ることに留意されたい。というのは、この戻りコードは
、アプリケーション５６Ａがコミットを発行済みであり
、実行環境５２Ｄがそれに対応するコミットを発行する
のを待っていることを示しているからである。したがっ
て、保護された会話上でメッセージと戻りコードを受け
取った後、アプリケーション５６Ｄは、システム５０Ｄ
内の作業ユニットに関連する他の保護された資源に関す
る作業を完了して、それら他の資源を整合性のある状態
にする。これを行った結果、作業ユニットＺに関連する
システム５０Ｄ内のすべての資源が整合性のある状態に
なった後に、アプリケーション５６Ｄは前記のコミット
を発行する。次に、同期点マネジャ６０Ａおよび６０Ｄ
は、それぞれアプリケーション５６Ａおよび５６Ｄから
直接アクセスされる資源に対して２段階コミット手順を
実施する。それぞれのアプリケーションからアクセスさ
れる資源をコミットするために、別々のコミットが呼び
出されるにもかかわらず、この２段階コミット処理の間
に、各同期点マネジャは、同期点状況の情報をもう一方
の同期点マネジャに報告する。同期点処理のさらに詳し
い説明については、「保護された資源の調整式同期点管
理」を参照されたい。

【００５３】コミット手順のための資源の登録図１０は
、資源の自動的かつ総称的な登録を示す図である。この
登録は、保護された資源を同期点マネジャ（ＳＰＭ）６
０に対して識別するファシリティである。それぞれのア
プリケーション実行環境５２で、資源アダプタ６２／６
４および同期点マネジャ６０は、アプリケーション５６
のために登録に参加する。この実施例では、資源マネジ
ャ６３と資源７８は、この環境の外部にある。

【００５４】図１０で、アプリケーション５６は２つの
部分、作業要求とコミット要求を有するものとして示さ
れている。これらの部分は共に、通常は同一のアプリケ
ーション実行環境内で実行される。しかし、図中でこれ
ら２つの部分の間にある破線が示すように、このアプリ
ケーションは分散していてもよく、またこれら２種類の
要求が異なる環境から出されてもよい。

【００５５】あるエンド・ユーザが、システム制御プロ
グラムの開始ファシリティを呼び出して、アプリケーシ
ョン５６を開始すると仮定する。この開始ファシリティ
は、アプリケーション実行環境５２を構築し、アプリケ
ーション５６をロードし、それに制御を移す。アプリケ
ーション５６が実行を開始する時、まだ同期点マネジャ
６０に登録されている資源７８はない。

【００５６】図２のアプリケーション５６が、資源７８
を使用するために作業要求を行う時（図３のステップ５
００および図５Ａのステップ５３０）、この要求は、資
源７８に関連する特定の資源アダプタ６２または６４を
呼び出す。資源アダプタ６２または６４の一般的な機能
は、アプリケーション５６を資源マネジャ６３に接続す
ることである。システム５０において、資源アダプタ６
２または６４は、同期点マネジャ６０に自動的に登録を
行う登録サブルーチンと、２段階コミット手順をサポー
トするアダプタ同期点出口入口点とを含むように拡張さ
れている。

【００５７】作業要求の入口点は、アプリケーション５
６から資源マネジャ６３へ作業要求（たとえば、ファイ
ルのオープン、データベースへのレコード挿入、会話の
開始など）をパスする、資源アダプタ６２または６４内
のコード行を示す。また、これらのコード行は、資源ア
ダプタ６２または６４内の登録サブルーチンと相互作用
して、自動的に登録を行う。この登録で、同期点マネジ
ャ６０に、資源７８がある作業ユニットの一部であるこ
とが知らされる。また、この登録で、資源マネジャ６３
が同期点マネジャ６０に対して識別される。これは、具
体的には、同期点マネジャ６０に、アダプタ同期点出口
入口点と、資源マネジャの資源識別子ｏｂｊｅｃｔ＿ｒ
ｅｃｏｖｅｒｙを知らせることからなる。

【００５８】アダプタ同期点出口入口点は、コミット要
求が行われる時に（図３のステップ５０６および図５Ａ
のステップ５３４）同期点マネジャ６０の２段階コミッ
ト・ファシリティが使用する、資源アダプタ６２または
６４内のコード行を示す。資源識別子ｏｂｊｅｃｔ＿ｒ
ｅｃｏｖｅｒｙは、下記「保護された資源を回復するた
めのログ名の交換」（図２６のステップ２２５）で説明
するように、同期点マネジャ６０の２段階コミット手順
中に障害が発生した場合に、回復ファシリティ７０が資
源マネジャ６３との会話を開始するために使用する識別
子である。

【００５９】アプリケーション５６のために自動的登録
を処理するために、資源アダプタ６２または６４のいず
れかに対する作業要求によって開始される処理は、資源
に応じて異なる。使用される資源７８は、本来作業要求
の性質とは無関係に保護されることができ、それがまだ
登録されていない場合には、資源アダプタ６２または６
４が、その登録サブルーチンを使用して、アプリケーシ
ョン５６のためにこの資源を同期点マネジャ６０に自動
的に登録する。また、アダプタ６２または６４は、資源
７８が保護されるか否かを知らず、資源マネジャ６３が
これを知っていてもよい。この場合、資源アダプタ６２
または６４は、資源マネジャ６３に登録して、作業要求
を資源マネジャ６３に渡すことができる。資源マネジャ
６３は、この作業要求を行った後、アダプタ６２または
６４に資源７８が保護を必要とするか否かの指示を戻す
ことができる。保護が不要な場合、資源アダプタ６２ま
たは６４は、その登録サブルーチンを使用して、同期点
マネジャ６０から登録を取り消すことができる。あるい
は、資源アダプタ６２または６４は、その資源がアプリ
ケーション５６によって変更されるか否か、すなわちそ
の資源が読取りだけに使用されるか否かを、作業要求ま
たは資源マネジャ６３から独自に決定することができる
。読取りのみの場合、資源アダプタ６２または６４は、
同期点マネジャ６０の登録ファシリティを使用して、登
録を読取り専用に変更することができる。最後に、資源
アダプタ６２または６４は、資源７８が読取り専用の資
源か、それともできるだけ早く他のアプリケーションに
利用可能にしなければならない、保護されない資源かを
決定することができる。この場合、資源アダプタは、２
段階コミット手順中に「準備」指令を得るために、登録
されたままでいてよい。その後、資源アダプタ６２また
は６４は、資源７８をロック解除する合図としてこの指
令を使用することができる。この場合、アダプタ６２ま
たは６４は、同期点マネジャ６０からの指令に対して「
準備済み」および「コミット」と回答することができる
。

【００６０】以下でさらに詳細に説明するように、登録
の取消しと変更をサポートすることによって、資源アダ
プタ６２または６４は、２段階コミット手順の最適化を
可能にする情報を同期点マネジャ６０に与えることがで
きる（これも以下で説明する）。アプリケーション５６
がコミット要求を発行する時、同期点マネジャ６０は、
１つの資源だけが変更済みとして登録されている（他の
資源が登録されていないか、あるいは他のすべての資源
が読取り専用として登録されている）と認識することが
できる。この場合、同期点マネジャ６０は、より効率的
な１段階コミット手順を使用することができる。

【００６１】次に、図２のアプリケーション５６Ａが実
行中であって、パートナ・アプリケーション５６Ｄとの
保護された会話を求める作業要求を行う（図５Ａのステ
ップ５３０）という特定の例に対して適用した場合の、
前述の一般的な制御の流れについて考察する。この要求
は、資源アダプタの１タイプである保護会話アダプタ６
４Ａによって処理される。アダプタ６４Ａは、その登録
サブルーチンを使用して、同期点マネジャ６０Ａの登録
ファシリティを呼び出す（ステップ５３２）。次に、ア
ダプタ６４Ａは、資源マネジャとして働く通信ファシリ
ティ５７Ａを使用して、パートナ・アプリケーション５
６Ｄを初期設定する。図２に示すように、会話マネジャ
５３Ａは、同一のシステム５０Ａ上のパートナ・アプリ
ケーションを始動することができ、あるいは通信ファシ
リティ５７Ａを介して別のシステム５０Ｄ上の対応する
通信ファシリティ５７Ｄと通信して、システム５０Ｄ内
のアプリケーションを始動することもできる。後者の場
合、パートナ・アプリケーションはシステム５０Ｄ上で
実行され、通信ファシリティ５７Ｄが、システム制御プ
ログラム５５Ｄの開始ファシリティを呼び出すことによ
って、パートナ・アプリケーション５６Ｄを開始する。 このファシリティは、パートナ・アプリケーション５６
Ｄ用の新規のアプリケーション実行環境５２Ｄを構築す
る。開始ファシリティは、それがパートナ・アプリケー
ション５６Ｄを構築中であることを知っているので、起
点側アプリケーション５６Ａとの保護された会話で通信
ファシリティ５７Ｄが使用されることも知っている。し
たがって、開始ファシリティは、一時的にパートナ・ア
プリケーション５６Ｄとして働き、保護された会話のた
めに保護会話アダプタ６４Ｄを呼び出す。次に、資源ア
ダプタ６４Ｄは、この保護された会話を同期点マネジャ
６０Ｄに登録する。したがって、パートナ・アプリケー
ション５６Ｄと起点側アプリケーション５６Ａとの保護
された会話が、パートナを呼び出す前に登録される（そ
の代わりに、パートナ・アプリケーション５６Ｄがアプ
リケーション５６Ａとの会話を使用するまで、登録を遅
延させることもできる）。したがって、図２において、
アプリケーション５６Ａの実行環境５２Ａ内の同期点マ
ネジャ６０Ａと、パートナ・アプリケーション５６Ｄの
実行環境５２Ｄ内の同期点マネジャ６０Ｄは、それぞれ
、この保護された会話資源について知らされる。

【００６２】図２の議論において、この時点で、アプリ
ケーション５６Ａおよびパートナ・アプリケーション５
６Ｄは、それぞれの作業ユニットの下でそれぞれの実行
環境５２Ａおよび５２Ｄ内で実行中であり、それぞれ１
つまたは複数の保護された資源７８Ａまたは７８Ｄを使
用することができる。たとえば、保護されたファイルを
使用することができる。アプリケーション５６Ａが、フ
ァイル資源７８Ａを使用するようにとの要求を行う時、
資源アダプタ６２Ａが呼び出される。アダプタ６２Ａは
、その登録サブルーチンを使用して、同期点マネジャ６
０Ａの登録ファシリティを呼び出す。次に、アダプタ６
２Ａは、ファイル資源マネジャ６３Ａを呼び出す。した
がって、アプリケーション５６Ａによる保護された資源
７８Ａの使用が、やはり自動的に登録される。同様にし
て、実行環境５２Ｄ内で、資源７８Ｄなど１つまたは複
数の資源に対する登録を行うことができる。

【００６３】上記の例から、登録が資源のタイプによら
ないので、この登録の実施例が総称的であることがわか
る。図１０では、保護された資源７８をサポートしよう
とする資源マネジャ６３は、その資源アダプタ６２また
は６４に登録サブルーチンを追加することができる。シ
ステム５０の同期点サポートを変更する必要はない。

【００６４】図１０で、アプリケーション５６が、保護
されない資源を使用することもできる。たとえば、アプ
リケーション５６は、実行中の作業に関するメッセージ
を定期的に表示する保護されないパートナ・アプリケー
ションを生成したいが、この表示を実際の作業の完了と
同期させる必要はないことがある。この場合、アプリケ
ーション５６は、保護されない会話をもつようにとの作
業要求を行う。この制御の流れは、上述の例の保護され
た会話の場合とほぼ同じである。唯一の相違は、資源ア
ダプタ６４が作業要求内の情報から、この会話が保護さ
れず、この実施例では同期点マネジャ６０に登録されな
いことを知っている点である。したがって、保護されな
い会話は、同期点マネジャ６０の同期点処理には参加し
ない。

【００６５】図１０において、上述の登録処理を仮定す
ると、アプリケーション５６がコミット要求を発行する
時、同期点マネジャ６０は、同期させる必要のある保護
された資源の完全なリストをもっている。同期点マネジ
ャ６０内での２段階コミット手順について説明した、前
述の「保護された資源の調整式同期点管理」を参照され
たい。この説明は、資源マネジャ６３内で同期点サポー
トを使用するために、同期点マネジャ６０が、資源アダ
プタ６２または６４内のアダプタ同期点出口入口点をど
のように使用するかを示している。図１０には示されて
いないが、アプリケーション５６はバックアウト要求を
発行することもできる。この場合、同期点マネジャ６０
は、資源アダプタ６２または６４内のアダプタ同期点出
口入口点にバックアウト指令を与える。

【００６６】同期点処理の終りに、各同期点マネジャ６
０は、アプリケーション５６の登録リストを破壊しない
。しかし、各マネジャは、後同期処理のために、資源ア
ダプタの出口をもう１度呼び出す。この呼出しに対して
、アダプタはその登録を修正するよう決定することがで
きる。性能上の理由から、アダプタは、アプリケーショ
ン５６が終了するまで資源を登録状態に保つことができ
る。一方、資源７８がこれ以上使用されない（たとえば
、アプリケーション５６が終了する前に保護された会話
が終わる）ことをアダプタが知っている場合、アダプタ
は、その登録入口点を使用して、同期点マネジャ６０か
ら登録を取り消すことができる。

【００６７】上記の制御の流れでは、分散式の資源マネ
ジャ６３を仮定した。したがって、資源７８を使用する
という要求は、必ず適当な資源アダプタ６２または６４
に向かい、このアダプタは、同期点マネジャ６０内の登
録ファシリティと、分散資源マネジャ６３内の作業要求
を呼び出した。ところが、資源マネジャ６３が分散式で
はない場合、作業要求でアダプタを使用する必要はない
。この場合、資源マネジャ６３と同期点マネジャ６０が
、同一のアプリケーション実行環境５２内にあるので、
資源マネジャ６３は、同期点マネジャ６０内の登録ファ
シリティを直接呼び出すことができる。

【００６８】図１２に示した例では、アプリケーション
５６Ａが複数の作業要求を行う。これらの要求は、シス
テム５０Ａによって並列に処理され、複数の資源マネジ
ャと資源を必要とする。この例について具体的に言うと
、アプリケーション５６Ａは、２つの作業ユニットＣお
よびＤに対して８つの作業要求を行い、これらの要求が
システム５０Ａによって並列に処理される。コミット点
が図１３に示されているが、作業ユニットＣのコミット
点は時刻１９と４４にあり、作業ユニットＤのコミット
点は時刻３３にある。図１３の時間単位は、シーケンス
を表す論理的クロック単位である（物理的クロック単位
ではない）。図１３において、同一の時刻に発生する事
象は、互いの順序がどうでもよいことを暗示している。

【００６９】作業ユニットとは、どの資源がある同期点
に参加するかについてのアプリケーション側の理解また
は範囲である。アプリケーションは、どの作業ユニット
に対して保護された資源の変更が行われるかを指定する
ことができる。また、アプリケーションは、保護された
会話をどの作業ユニットの下で開始するかも指定するこ
とができる。システム５０Ａは、アプリケーション実行
環境（図１２の５２Ａ）内で複数の作業ユニットを許容
する。具体的に言うと、アプリケーション、同期点マネ
ジャ６０Ａおよび保護されたアダプタ（たとえば、図１
２のＳＱＬ資源アダプタ）は、複数の作業ユニットを並
列してサポートすることができる。また、システム５０
Ａは、保護された会話を介して、２つのアプリケーショ
ン実行環境の作業ユニットを結合することも許容する。 各作業ユニットは、一連の同期点を有することができる
。ある作業ユニットに対する同期点要求は、あるアプリ
ケーションの実行環境内の他の作業ユニットの活動には
影響しない。

【００７０】図１２および図１３に示した次の例を考察
する。ホームタウンにいるジョーンズ氏は、息子の信託
預金への振替を行いたいと思っている。ジョーンズ氏の
銀行の安全保護部門は、顧客も従業員も含めて、取引に
かかわるすべての人物を追跡する。安全保護記録と会計
レコードは、互いに「すべてか無か」の包含関係にある
わけではないが、この２つの作業ユニットを並列して処
理する必要があるかもしれない。１つの理由としては、
この２つの作業ユニットを順に処理するのでは応答時間
が遅くなりすぎることが挙げられよう。

【００７１】この例では、時刻１の作業ユニットＣに関
する作業要求は、シカゴにあるこの銀行の本店の安全保
護記録を制御する資源マネジャ６３Ａを使用する。資源
マネジャ６３Ａと通信するために、資源アダプタ６２Ａ
によって保護されない会話１が使用される。時刻１の作
業ユニットＤに関する作業要求も、ジョーンズ氏の信託
預金用にシカゴにある資源マネジャ６３Ａを使用し、一
方、時刻７の要求は、ジョーンズ氏の他の会計レコード
が保存されているホームタウンの資源マネジャ６３Ｂに
対するものである。資源マネジャ６３Ａと通信するため
に、資源アダプタ６２Ａによって保護されない会話２が
使用され、資源マネジャ６３Ｂと通信するために、資源
アダプタ６２Ｂによって保護されない会話３が使用され
る。

【００７２】アプリケーション５６Ａが作業ユニットＣ
を使用してその最初のレコードであるメッセージ“ｓｔ
ａｒｔ　ｓｅｃｕｒｉｔｙ　ｅｖｅｎｔ（安全保護事象
開始）”を書き込む時（図１４のステップ６１２）、資
源マネジャ６３Ａは、その資源アダプタ６２Ａを介して
アプリケーション実行環境５２Ａ内に登録される。同期
点マネジャ６０Ａは、図１２の表１２６内で作業ユニッ
トＣの下に、資源マネジャ６３Ａ用の登録エントリを作
成する（ステップ６１４）。このエントリは、出口ルー
チン名と、資源アダプタ６２Ａが登録の際に渡した特別
なプライベート値とを含む、資源アダプタ６２Ａの出口
に渡すべきパラメータのリストを含む。資源アダプタの
出口は、この特別な値を使用して、会話１用の制御ブロ
ックを探し出すことができる。

【００７３】その結果、アプリケーション５６Ａが、時
刻１９に作業ユニットＣに関するコミットを要求する時
、同期点マネジャ６０Ａは、表１２６を読み取って、ど
の資源アダプタ出口にこのコミット手順を開始するよう
通知するべきかを決定する。この例では、時刻１９に作
業ユニットＣに関するコミットが要求される時、同期点
マネジャ６０Ａが資源アダプタ６２Ａの出口を呼び出し
て、１段階コミット手順を開始する。というのは、保護
された資源が１つだけ登録されているからである。資源
アダプタ６２Ａの出口ルーチンは、同期点マネジャ６０
Ａから、登録中に表１２６にセーブされた特別な値を受
け取るので、会話１を使用して資源マネジャ６３Ａと通
信すべきことを知る。

【００７４】この後、時刻２６にジョーンズ氏の取引を
扱う銀行員の従業員ＩＤをロギングする時には、登録は
行わない（ステップ６１３）。再登録が不要なのは、作
業ユニット登録表１２６から、資源マネジャ６３Ａが作
業ユニットＣに参加していることを、同期点マネジャ６
０Ａがすでに知っているからである。その結果、最初の
作業要求の後の作業ユニットＣに関する各作業要求、お
よびその後の時刻４４でのコミットの処理が、手早く行
われる。また、作業ユニットＣ用の各同期点にで、資源
アダプタ６２Ａと資源マネジャ６３Ａだけが通知を受け
る。他の資源アダプタまたは他の資源マネジャに通知す
ることによる時間の浪費はない。

【００７５】アプリケーション５６Ａが、作業ユニット
Ｄの下で、時刻１と時刻７に作業要求を行う時、資源ア
ダプタ６２Ａおよび６２Ｂの両方が、同期点マネジャ６
０Ａに登録され、同期点マネジャ６０Ａは、表１２７に
登録エントリ６３Ａおよび６３Ｂを追加する。

【００７６】時刻１９に最初の安全保護記録のコミット
が行われる時、時刻１７の信託預金更新は、全く影響を
受けない。時刻３３に信託預金レコードと会計レコード
がコミットされる時、従業員ＩＤメッセージはやはり影
響を受けない。シカゴにある資源マネジャ６３Ａは、別
々な２つの会話１および２を介してアプリケーション５
６Ａと通信しているので、混乱しないことに留意された
い。

【００７７】システム５０Ａが、資源マネジャに対して
どの作業ユニットが活動状態であるかを知っており、資
源アダプタをこのタスクから解放するので、資源アダプ
タの開発は簡単になる。設計が簡単なので、資源アダプ
タ出口は良好に動作する。資源アダプタ出口は、必要な
ものをすべて有しており、同期点マネジャ６０Ａの行動
をその資源マネジャに送るだけである。もう１つの性能
上の展望は、同期点マネジャ６０Ａが、同期点手順を最
適化できることである。というのは、同期点マネジャ６
０Ａは、どの作業ユニットのために資源マネジャが活動
状態であるかを知っており、同期点に関係ない資源のた
めに資源アダプタおよび資源マネジャを呼び出すことに
よるオーバヘッドを回避できるからである。

【００７８】システム５０Ａにおいて、共用ファイルや
データベースなどの保護された資源に対して行われるタ
イプの作業要求が、その資源の状態を変更し、その結果
、登録情報を変更しなければならない場合があり得る。 これが重要であるのは、元の作業要求が、読取り専用の
要求であって、１段階コミット手順しか必要としないの
に、その後の同一の作業ユニットの下での関連する作業
要求が、書込み要求であって、使用される複数の保護さ
れた資源を調整するために、２段階コミット手順を必要
とすることがあるからである。

【００７９】図３に示したもう１つの例として、アプリ
ケーション５６Ａは、通常、更新すべきファイル内の特
定のレコードの位置を探すために、書込み要求を行う前
にそのファイル上で１つまたは複数の読取り要求を行う
。このような読取り動作は、１段階コミット手順を用い
て実施できるが、この場合、資源アダプタ６２Ａは、こ
の読取り作業要求を受け取ると（ステップ５００）、同
期点マネジャ６０Ａに読取りモードで登録される（ステ
ップ５０２）。その後の読取り動作中には、必要なコミ
ット手順のタイプが変化しないので、資源アダプタ６２
Ａが同期点マネジャ６０Ａと相互作用する必要がないこ
とに留意されたい。しかし、その後、アプリケーション
５６Ａが、同一の作業ユニットの下で資源アダプタ６２
Ａに対して書込み要求を行う際には（ステップ５０４）
、資源アダプタ６２Ａは、その同期点マネジャ６０Ａに
おける登録状況を書込みモードに変更する。以下でさら
に詳細に説明するように、複数の保護された資源が、同
一の作業ユニット上で書込みモードで登録される場合に
は、幾分時間のかかる２段階コミット手順が使用される
。

【００８０】この登録変更の例は、図１１の流れ図に詳
細に示されている。ステップ５８０の作業要求が、その
保護された資源に関する最初の要求であり、この要求が
読取り専用である場合、判断ブロック５８１から判断ブ
ロック５８２に進む。資源アダプタ６２Ａは、それが登
録されている各作業ユニットの下で各資源用の内部標識
を保存していることに留意されたい。この標識が、判断
ブロック５８１で検査される。この資源は、保護された
会話ではないので、判断ブロック５８２から判断ブロッ
ク５８３に進む。この作業は読取り専用なので、判断ブ
ロック５８３からステップ５８５に進む。ステップ５８
５で、対応する資源アダプタ６２Ａが、読取り専用資源
として登録される。ステップ５８０の次の作業要求が、
同一の作業ユニットの下での同一の資源への書込みまた
は更新である場合、資源アダプタ６２Ａは、読取りモー
ドとしてであるとはいえ、ステップ５８５ですでに登録
されているので、判断ブロック５８１から判断ブロック
５８４に進む。この資源は保護された会話ではないので
、判断ブロック５８４から判断ブロック５８６に進み、
この要求は更新モード用なので、判断ブロック５８６か
ら判断ブロック５８８に進む。次に、判断ブロック５８
８からステップ５９０に進み、資源アダプタ６２Ａ（ス
テップ５８５ですでに読取りモードとして登録済み）は
、同期点マネジャ６０Ａにおけるその登録を書込みモー
ドに変更する。図１１によれば、この資源に対するある
作業ユニットの下での最初の作業要求が書込みモードで
ある場合には、資源アダプタ６２Ａが、ステップ５９２
で書込みモードとして登録されることに留意されたい。

【００８１】資源マネジャ６３が、ある同期点を完了し
、その同期点の完了以降に別の要求をもたないという状
況もある。その資源アダプタ６２は、同期点手順が完了
した時点で、その登録状況を「中断」に変更することを
許され、その結果、同期点マネジャ６０は、現在、資源
マネジャ６３が、その作業ユニットに関してどの同期点
にも参加していないことを知る。書込みモードの資源の
中断により、たとえばその作業ユニット内に書込みモー
ドの資源が他に１つしかないような時、同期点マネジャ
６０は、残りの資源用のその後のコミット手順（１段階
コミット）を最適化できるようになる。中断された資源
アダプタ６２は、その作業ユニットに関する新規の作業
要求を受け取る場合、同じ登録修正機能を用いてその登
録を活動状態に戻すことができる。

【００８２】ある種の資源マネジャの設計では、その資
源アダプタは、分散式の同期点活動について通知を受け
るために、アプリケーションとの対話の初期に登録され
る必要がある。ただし、その時点では、登録情報が完全
に揃っていなくてもよい。たとえば、保護会話アダプタ
６４Ａは、同期点が発生したか否かを知る必要があるの
で、パートナ・アプリケーション５６Ｄとの保護された
会話を開始する時点で登録される必要があるが、保護会
話アダプタ６４Ａがすべての登録情報を得るのは、会話
のパートナがこの会話を受け入れた後であり、これはず
っと後になってから発生するかも知れない事象である。 この情報は、その後、ステップ５９０に示された前述の
登録変更処理の下で追加することができる。

【００８３】システム５０は、時間を節約するための技
法をこの登録処理に追加して提供する。各資源アダプタ
６２は、初めて同期点マネジャ６０に登録される際に、
資源マネジャ６３の識別と、その資源アダプタの同期点
処理用の出口ルーチン名の他にも、追加の情報を登録す
る。この追加情報の多くは、通常、登録が変更される際
に変更されない。その結果、この追加情報は、ステップ
５９０で資源アダプタ６２の登録が変更される際に再登
録されない。資源アダプタ６２が同期点マネジャに一回
だけ登録し、他の登録情報が変化しても変化しない、前
記の追加情報の一部のリストを下記に示す。１．資源マ
ネジャと資源が、システムおよびネットワーク内のどこ
に位置するかを記述する、資源識別子とネットワーク識
別子、２．製品を示す、すなわち、たとえば共用ファイ
ル、データベース、保護された会話など、資源のタイプ
を示す製品識別子、３．再同期化に必要なその他のデー
タ。これらの追加情報は、毎回再登録されはしないので
、登録処理が手早く行われる。

【００８４】様々な場合に、アプリケーションがもはや
保護された資源を使用できない、または使用しないこと
がある。この例には、アプリケーション終了、資源マネ
ジャ終了、資源マネジャへの経路が利用不能などの事象
が含まれる。ある資源がもはや使用中ではないとアプリ
ケーションが宣言できるようにする、アプリケーション
または資源マネジャのプロトコルを設けることができる
。アプリケーション実行環境が、アプリケーションの終
了以前に資源の登録を取り消すことができるようにする
プロトコルをサポートすることもできる。また、保護さ
れた会話が、アプリケーションの活動のために、または
経路障害などのエラー状態のために、終了することもあ
る。このような場合には、資源アダプタまたは保護会話
アダプタが、同期点マネジャから該当する資源のインス
タンスすべての登録を取り消すことが好ましい（図１４
のステップ６１８）。というのは、この登録取消しによ
って、その後の同期点処理がより効率的になる（考慮す
べき資源の数が減り、多分、消費されるメモリも少なく
なる）からである。さらに、この資源アダプタまたは保
護会話アダプタは、登録された資源に関する制御情報を
削除することができ、したがって、その後の処理をより
効率的にすることができる。

【００８５】図１５は、資源アダプタ６２または保護会
話アダプタ６４が、資源７８または保護された会話が利
用不能であることを発見した（ステップ９０４）、ある
いはアプリケーションが終了したことを発見した（ステ
ップ９０３）場合の、登録解除活動の流れを示す図であ
る。資源が利用不能であることをアダプタが発見するの
は、通常、アプリケーションの作業要求の処理中である
ことに留意されたい（ステップ９０２）。アダプタは、
それ自体の資源登録状況の情報から、どの資源の登録を
取り消さなければならないかを決定する（ステップ９０
６）。このような登録されている各資源について、アダ
プタは、同期点マネジャ６０を呼び出して、その資源の
登録を取り消す（ステップ９０７）。アダプタは、同期
点マネジャ６０に対して、資源と作業ユニットを識別し
なければならないことに留意されたい。

【００８６】図１５では、同期点マネジャ６０を呼び出
すごとに（ステップ９１０）、同期点マネジャ６０は、
アダプタから供給された作業ユニット識別子を使用して
、その作業ユニット資源表を探し出す（ステップ９１１
）。この作業ユニットの資源表から、同期点マネジャ６
０は、アダプタから供給された作業ユニット識別子を使
用して、所望の資源エントリを探し出す（ステップ９１
２）。次に、同期点マネジャ６０は、その資源エントリ
に登録を取り消された旨のフラグを立て（ステップ９１
３）、呼出し側アダプタに戻る（ステップ９１４からス
テップ９０７に戻る）。しかし、論理上、この登録を取
り消された資源エントリは、次の同期点まで保存しなけ
ればならないエラー情報を含んでいるので、同期点マネ
ジャ６０は、まだこの資源エントリを消去することがで
きない（「コミット手順におけるエラー・コードおよび
エラー記述情報の調整式処理」を参照されたい）。

【００８７】ここでアダプタは、登録を取り消された資
源に関する制御情報を削除する（あるいは、登録を取り
消された旨のマークを付ける）ことができる（ステップ
９０８）。登録取消しを引き起こした事象が、複数の資
源登録を削除させる場合があることに留意されたい（た
とえば、１つの資源が複数の作業ユニットのために登録
されている場合がある）。したがって、ステップ９０６
、９０７、９０８をプログラム・ループにして、以前に
登録された該当する各資源を処理することができる。 その後、アダプタは呼出し側に戻ることができる（ステ
ップ９０９）。資源が利用不能であるために作業要求が
失敗した場合、アダプタは、資源アダプタがアプリケー
ション・ユーザにエラー情報を戻すために選択したどん
な機構を用いてもアプリケーションにエラー状態を報告
することができる。

【００８８】資源アダプタは、資源が利用不能であるか
、またはアプリケーションが終了した結果として、他の
処理上の問題を生じることがある。たとえば、資源が利
用不能な状態であったため資源更新のバックアウトを引
き起こす場合、アダプタは、アプリケーションまたは同
期点マネジャ６０あるいはその両方に、該当する作業ユ
ニット上の次の同期点がバックアウトでなければならな
いことを通知する必要がある。同期点処理中にこの状態
が発生すると、アダプタは、（バックアウト中の）資源
の状況を同期点マネジャ６０に通知しなければならない
。この他にも、資源、環境または実施様態に依存する他
の問題が生じるかもしれない。

【００８９】ここで同期点マネジャ６０は、フラグを立
てられた登録取消し済みの（ステップ９１３からの）資
源の処理に従事し、その結果、それらの資源は通常の処
理では無視されて、最終的に消去されることになる。同
期点マネジャ６０は、フラグを立てられた登録取消し済
みの資源エントリを、その影響を受ける作業ユニットの
次の同期点の始めに消去することができる。図１６に、
同期点マネジャ６０内の同期点処理の流れが記述されて
いる。次の同期点処理で、登録された資源の表を読み取
る時（ステップ６２２）、その表中のフラグを立てられ
た登録取消し済みの資源エントリをすべて消去すること
ができる（この行動は図１６には図示せず）。ステップ
６２２で、現在の同期点処理の間のすべての同期点資源
の参加リストを作成するので、アダプタによる資源登録
エントリの資源登録の取消しと変更は、現在の同期点処
理には影響しない。この時点で、登録取消し処理の全体
が完了する。

【００９０】コミット手順の最適化 参加する各資源マネジャは、“Ｓｙｓｔｅｍ　Ｎｅｔｗ
ｏｒｋ　Ａｒｃｈｉｔｅｃｔｕｒｅ　ＬＵ　６．２：　
Ｐｅｅｒ　Ｐｒｏｔｏｃｏｌｓ，　ｓｃ３１−６８０８
，　Ｃｈａｐｔｅｒ　５．３　Ｐｒｅｓｅｎｔａｔｉｏ
ｎ　Ｓｅｒｖｉｃｅｓ　−　Ｓｙｎｃ　Ｐｏｉｎｔ　Ｖ
ｅｒｂｓ”に記載の２段階コミット手順などの２段階コ
ミット手順を実行する能力があり、１段階コミット手順
を実行する能力はあってもなくてもよい。２段階コミッ
ト手順は、資源を保護するのに重要である。しかし、２
段階コミット手順は、１段階コミット手順と比べて、相
対的に複雑で時間のかかる処理である。たとえば、後で
詳細に説明するように、２段階コミット手順では、同期
点参加者に関する情報を回復ファシリティのログ７２（
図２）にロギングするという時間のかかるステップが必
要であるが、１段階コミット手順では、そのようなロギ
ングの必要はない。また、２段階コミット手順では、コ
ミットを実行するのに、資源アダプタ調整出口を２回呼
び出す必要があるが、１段階コミット手順でデータをコ
ミットするには、このような呼出しは１回だけでよい。 「資源アダプタ調整出口」とは、同期点マネジャ６０（
図２）が、関連する資源マネジャに情報を提供するため
の機構である。同期点マネジャは、システムをできるだ
け手早く動作させるのに必要な時に限り、２段階コミッ
ト手順を使用する。要約すると、同期点マネジャは、保
護された会話を使用するか、少なくとも２つの資源が更
新モードであるか、あるいは１つまたは複数の参加する
資源マネジャが１段階コミット手順を実行できない時、
２段階コミット手順を使用する。すべての資源が１段階
コミット手順を実行でき、更新モードの資源がせいぜい
１つである場合には、同期点マネジャは、１段階コミッ
ト手順を使用する。また、ある資源が読取り専用モード
であり、したがってその資源内のデータは読み取られる
が更新されず、かつ資源マネジャが１段階コミット手順
を実行できる場合には、他の資源に使用されるコミット
手順のタイプが何であれ、この資源には１段階コミット
手順が使用される。この最適化の最重要な構成要素は、
資源マネジャおよび資源アダプタが、作業要求によって
定義される状態、すなわち資源が読取り専用モードであ
るか更新モードであるかを、同期点以前に決定できるこ
とである。 ある資源が読取り専用モードである場合、それは、アプ
リケーションがその資源からデータを読み取っただけで
あることを意味する。ある資源が更新モードである場合
、それは、アプリケーションがその資源内のデータを変
更したことを意味する。

【００９１】この最適化処理は、下記のように始まる。 アプリケーション５６（図２）が、ある資源に対する作
業要求を行う（図１４のステップ６１２）。これが特定
の作業ユニットに対する最初の作業要求である場合（図
１４の判断ブロック６１３）、その資源に関連する資源
アダプタ６２（図２）は、それが現在、その作業ユニッ
ト用の活動状態の参加する資源であることを、同期点マ
ネジャに登録する（図１４のステップ６１５）。登録時
（図１４のステップ６１６）に提供しなければならない
、この資源に関する情報の１つは、関連する資源マネジ
ャが１段階コミット手順を実行できるか否かであり、た
とえば、その資源が、特定の情況の下で１段階コミット
手順を実行できるデータベース・マネジャであるかどう
かである。やはり登録中に、資源アダプタは、このアプ
リケーションによって行われた作業要求が、その資源を
読取り専用モードにしたか、それとも更新モードにした
かを同期点マネジャに記録する（図１４のステップ６１
６）。

【００９２】資源の最初の登録の後、アプリケーション
がその資源に対して次の作業要求を行ったとき、資源の
状態が変化することがある。すなわち、資源が読取り専
用モードから更新モードに変化することがある。このよ
うな変化が発生した場合、資源アダプタは、この変化に
ついて同期点マネジャに知らせなければならず、登録情
報は新しい状態を反映するように更新される（図１４の
ステップ６１９）。

【００９３】アプリケーションからの作業要求が、保護
された会話に対するものである場合、保護会話アダプタ
用の登録エントリは、その保護会話アダプタが更新モー
ドであって、１段階コミット手順を実行できないことを
必ず示す。保護会話アダプタは、複数の資源を使用する
可能性のある別のアプリケーション実行環境への通信経
路を表すので、読取り専用モードの資源への通信経路を
表しているのか、それとも更新モードの資源への通信経
路を表しているのかは、保護会話アダプタには決定でき
ない。したがって、別のアプリケーション実行環境への
通信経路が存在する場合には、クリティカルな資源に必
要な保護を提供するために、２段階コミット手順が必要
である。保護会話アダプタは、１段階コミット手順を実
行できない更新モードの資源として登録することによっ
て、２段階コミット手順が使用されることを保証する。

【００９４】アプリケーションは、その作業をすべて完
了した後に、資源上のデータのコミットまたはバックア
ウトを試みる。これを達成するために、アプリケーショ
ンは同期点マネジャに同期点要求を発行する。この同期
点要求の処理を開始するために（図１６のステップ６２
０）、同期点マネジャは、作業ユニット表を読み取って
、影響を受ける作業ユニットのエントリを見つける（図
１６のステップ６２１）。作業ユニットの詳細について
は、「作業ユニットに合わせて調整されたローカルおよ
びグローバルなコミット範囲」を参照されたい。正しい
作業ユニット・エントリが見つかると、同期点マネジャ
は、その作業ユニット用に登録された資源に関する情報
をそのエントリから読み取り、資源の３つのリストを生
成する（図１６のステップ６２２）。

【００９５】これらの表は、それぞれ異なる意味をもつ
。読取り専用リストは、アプリケーションがデータを読
み取っただけである資源を含む。更新リストは、アプリ
ケーションによってそのデータが更新された資源と、読
取り専用の状態であるが、その資源マネジャが１段階コ
ミット手順を実行できない資源を含む。開始側リストは
、更新を資源に同期させたい旨のメッセージを送った通
信パートナのリストを含む。各資源は、これらのリスト
のうちの１つだけにしか現れない。

【００９６】実際には、それぞれの資源の登録には、２
つのフラグが含まれる。これらのフラグは、同期点マネ
ジャに読み取られ、ある資源を更新リストに入れるべき
か、それとも読取り専用リストに入れるべきかを決定す
るのに使用される。第１のフラグは、その資源が読取り
専用モードの時オンとなり、更新モードの時オフとなる
。第２のフラグは、その資源が１段階コミット手順と２
段階コミット手順の両方をサポートする時オンとなり、
２段階コミット手順しか実行できない時オフとなる。実
際には、各資源の登録には、通信パートナが更新を資源
と同期させたい旨を示すメッセージをこの資源アダプタ
が通信パートナから受け取ったか否かに関する情報を含
むフィールドも含まれる。同期点マネジャは、このフィ
ールドを読み取り、そのデータを使用して、その資源を
開始側リストに入れるべきか否かを決定する。

【００９７】資源のリストを作成し終えると、同期点マ
ネジャは、同期点要求のタイプを検査する（図１６の判
断ブロック６２３）。この同期点要求がバックアウトで
ある場合には、同期点マネジャは以下のバックアウト処
理を実行する。まず、更新リスト中に資源アダプタがあ
るならば、それらのすべてに、その資源の変更をバック
アウトするように指令する（図１６のステップ６２６）
。次に、読取り専用リスト中に資源アダプタがあるなら
ば、それらのすべてに、それらの資源に対する作用をバ
ックアウトするよう指令する（図１６のステップ６２７
）。読取り専用の資源に対する「バックアウト」の処理
は、バックアウトすべき資源内の実際のデータが変更さ
れないので、その資源の実施様態によって定義されるこ
とに留意されたい。たとえば、共用ファイル資源マネジ
ャ６３（図２）内の読取り専用ファイルをバックアウト
するための処理は、そのファイルをクローズし、そのア
プリケーションの使用のために以前に維持されていたフ
ァイル位置情報を放棄することを含むことができる。読
取り専用の資源をバックアウトするよう指令した後、開
始側リスト中に資源アダプタがあれば、それらすべてに
、このアプリケーション実行環境がこの同期点に対する
変更をバックアウトしたことを伝える（図１６のステッ
プ６２８）。

【００９８】そうではなくて、この同期点要求がコミッ
トである場合（図１６の判断ブロック６２３）、同期点
マネジャは、このコミットの最適化処理を開始する。こ
の最適化処理の第１ステップでは、開始側リストが空で
あるか否か決定する（図１６の判断ブロック６２４）。 開始側リストが空でないならば、それは、このアプリケ
ーション実行環境が、その同期点ツリー内のカスケード
式開始側であり、このコミットのために完全な２段階コ
ミット手順を使用しなければならないことを意味する。 それが必要なのは、この同期点ツリーの完全な範囲、す
なわちこの同期点に対して活動状態でありかつ更新モー
ドである資源がどれだけあるかを、どのアプリケーショ
ン実行環境も知らないからである。この数が未知である
ので、これらのクリティカルな資源に必要な保護を提供
するために、２段階コミット手順を使用しなければなら
ない。

【００９９】開始側リストが空である場合（図１６の判
断ブロック６２４）は、次のステップで、更新リスト中
に複数の資源があるか否かを決定する（図１６の判断ブ
ロック６２５）。そうである場合は、このコミットのた
めに完全な２段階コミット手順を使用しなければならな
い。すべての資源がそれぞれの変更をコミットできると
認めない限り、どの資源もその変更をコミットしないの
で、この２段階コミット手順は、更新モードの資源に対
してより多くの保護を提供する。

【０１００】更新リスト中に２個未満の資源しかない場
合（図１６の判断ブロック６２５）、次のステップで、
更新リスト中に資源がないか、それとも１つあるか決定
する（図１６の判断ブロック６４０）。更新リスト中に
資源がない場合、読取り専用の資源をコミットするため
に１段階コミット手順を使用する。同様に、更新リスト
中に資源が１つだけあり、その資源マネジャが１段階コ
ミット手順を実行できる場合には、１段階コミット手順
を使用する。

【０１０１】この１段階コミット手順は、更新リスト中
に資源アダプタがあるならば、それに対してその変化を
コミットするよう同期点マネジャが指令することから始
まる（図１６のステップ６４１）。資源マネジャによる
データの１段階コミットは、２段階コミット中には２回
の呼出しが必要であるのとは対照的に、資源アダプタを
１回呼び出すだけで達成されることに留意されたい。こ
の同期点全体を通じて、更新モードの資源はせいぜい１
つしか存在し得ないので、異なる資源に対する異なる決
定によってデータの整合性が失われる可能性はない。ま
た、この１段階コミット手順中には、２段階コミット手
順の一部としてロギングが（図１７のステップ６４４、
６４８、６５１、６５８および６５９）必要であるのと
は対照的に、回復ファシリティのログ７２（図２）への
書込みが行われないことに留意されたい。この１段階コ
ミット手順は、読取り専用リスト中に資源アダプタがあ
るならば、それに対してその変更をコミットするよう同
期点マネジャが指令することで終了する（図１６のステ
ップ６４２）。読取り専用の資源の「コミット」は、コ
ミットすべきデータが実際には変化していないので、資
源の実施様態によって定義されることに留意されたい。 たとえば、一部の共用ファイル資源マネジャ６３（図２
）は、読取りの整合性をもたらすので、あるアプリケー
ションが共用ファイル資源マネジャ内のファイルを読み
取る時に、そのアプリケーションは、そのファイルの整
合性のあるイメージを与えられる。すなわち、他のアプ
リケーション環境がそのファイルに対して行った変更は
、ファイルの内容の読取りに干渉せず、ファイルがオー
プンされた時の内容が読み取られる。アプリケーション
が読取りの目的でファイルをオープンする時、読取り専
用の資源であるとみなされる資源マネジャによってこの
イメージが生成される。アプリケーションは、ファイル
の読取りを終えた時、このファイルをクローズし、コミ
ットを試みる。共用ファイル資源マネジャは、読取り専
用の資源としてこのコミットを実行する時、アプリケー
ションの使用のために維持されたイメージを破棄するこ
とができる。これで、アプリケーションがこのファイル
を再度オープンする場合、他のアプリケーションによっ
て行われたコミット済みの変更をすべて含むファイルの
イメージが見えることになる。

【０１０２】同期点要求の結果が、図１６の判断ブロッ
ク６２４、６２５または６４０の結論に従って、２段階
コミット手順となる場合、同期点マネジャ６０（図２）
は、やはり読取り専用の資源のコミットを最適化する。 読取り専用の資源のこの最適化にはいくつかの部分があ
る。第１に、（図１７のステップ６４４）この読取り専
用の資源に関する情報は、回復ファシリティのログ７２
（図２）に書き込まれない。読取り専用の資源が、それ
自体のログに「不確定」の状態をロギングすることは絶
対にないので、読取り専用の資源に関する情報を回復フ
ァシリティ７０（図２）にロギングする必要はない。こ
れは、資源マネジャが回復ファシリティ７０（図２）と
の再同期化を決して試みず、したがって、回復ファシリ
ティはこの資源に関する知識を必要としないことを意味
する。第２に、この読取り専用の資源は、コミットの第
１段階、すなわち更新リスト中のすべての資源アダプタ
への“ｐｒｅｐａｒｅ（準備）”の送出には使用されな
い（図１７のステップ６４５）。データの整合性の点で
、読取り専用の資源にとってバックアウトはコミットと
同等なので、読取り専用の資源の行動が、資源の保護に
影響を与えることはありえない。

【０１０３】読取り専用の資源が２段階コミット手順に
使用されるのは、コミットの最終決定を伝えられる時、
すなわち、変更をコミットする（図１７のステップ６５
３）か、または変更をバックアウトする（図１７のステ
ップ６５５）よう伝えられる時だけである。

【０１０４】下記に、システム５０（図２）などのシス
テムの一部である３つの異なるアプリケーション実行環
境に関わる、２段階コミット手順の例を示す。各アプリ
ケーション実行環境は、異なるアプリケーションを実行
中である。アプリケーションＡとアプリケーションＢは
、保護された会話を介して通信中である。アプリケーシ
ョンＢとアプリケーションＣは、保護された会話を介し
て通信中である。この２段階コミット手順は、アプリケ
ーションＡが、これと同一の実行環境内で現在実行中の
同期点マネジャにコミット要求Ｂ１（図１８）を発行す
ることによって、コミットを試みる時に開始される。 段階１は、この同期点マネジャが、回復ファシリティの
ログＢ２（図１８）にログ・レコード“ＳＰＭ　Ｐｅｎ
ｄｉｎｇ　（ＳＰＭ保留）”を書き込む時に始まる。ロ
グ・レコード“ＳＰＭ　Ｐｅｎｄｉｎｇ”は、その同期
点用の作業論理ユニット識別子と、その同期点参加者に
関する情報を含み、この場合、ログ・レコード“ＳＰＭ
　Ｐｅｎｄｉｎｇ”は、１つの参加者としてアプリケー
ションＢを示す。

【０１０５】ログ・レコード“ＳＰＭ　Ｐｅｎｄｉｎｇ
”が回復ファシリティへ成功裡に書き込まれた後、同期
点マネジャは、保護会話アダプタを介してアプリケーシ
ョンＢにメッセージ“ｐｒｅｐａｒｅ”を送る。アプリ
ケーションＢは、その会話パートナであるアプリケーシ
ョンＡが資源の同期化を望んでいることを知らされ、そ
の後アプリケーションＢは、それと同一の実行環境内で
現在実行中の同期点マネジャにコミット要求Ｂ３（図１
８）を発行する。

【０１０６】Ｂ側の同期点マネジャについては、２段階
コミット手順の第１段階は、回復ファシリティのログＢ
４（図１８）にレコード“ＳＰＭ　Ｐｅｎｄｉｎｇ”を
書き込むことから始まる（図１８）。レコード“ＳＰＭ
　Ｐｅｎｄｉｎｇ”は、この同期点用の作業論理ユニッ
ト識別子と、この同期点参加者に関する情報を含む。こ
の場合、ログ・レコード“ＳＰＭ　Ｐｅｎｄｉｎｇ”は
、アプリケーションＡに関する、それを同期点開始側と
して示す情報とアプリケーションＣに関する、それを同
期点参加者として示す情報を含む。ログ・レコード“Ｓ
ＰＭ　Ｐｅｎｄｉｎｇ”が回復ファシリティのログに成
功裡に書き込まれると、同期点マネジャは、保護会話ア
ダプタを介してアプリケーションＣにメッセージ“ｐｒ
ｅｐａｒｅ”を送る。アプリケーションＣは、その会話
パートナであるアプリケーションＢが資源の同期化を望
んでいることを知らされ、その後アプリケーションＣは
、それと同一の実行環境内で現在実行中の同期点マネジ
ャに、コミット要求Ｂ５（図１８）を発行する。

【０１０７】同期点マネジャは、レコード“ＳＰＭ　Ｐ
ｅｎｄｉｎｇ”を回復ファシリティのログＢ６（図１８
）に書き込むことによって、２段階のコミット手順第１
段階を開始する。このレコード“ＳＰＭ　Ｐｅｎｄｉｎ
ｇ”は、この同期点参加者に関する情報と、この同期点
用の作業論理ユニット識別子を含む。この例では、レコ
ード“ＳＰＭ　Ｐｅｎｄｉｎｇ”は、この同期点の開始
側であるアプリケーションＢに関する情報を含む。また
、レコード“ＳＰＭＰｅｎｄｉｎｇ”は、アプリケーシ
ョンＣに対する同期点参加者がないことを示している。

【０１０８】参加者がないので、Ｃ側の同期点マネジャ
が、保護会話アダプタを介してメッセージ“ｐｒｅｐａ
ｒｅ”を送る必要はない。そこで、Ｃ側の同期点マネジ
ャは、回復ファシリティに状態レコードを送り、同期点
の状態を「代理、不確定」Ｂ７（図１８）に更新する。 この状態レコードが回復ファシリティのログに成功裡に
書き込まれると、Ｃ側の同期点マネジャは、このメッセ
ージ“ｐｒｅｐａｒｅ”に応答して、保護会話アダプタ
を介してＢ側の同期点マネジャにメッセージ“ｒｅｑｕ
ｅｓｔ　ｃｏｍｍｉｔ（コミット要求）”を送る。

【０１０９】Ｂ側の同期点マネジャは、保護会話アダプ
タを介してＣ側の同期点マネジャからのメッセージ“ｒ
ｅｑｕｅｓｔ　ｃｏｍｍｉｔ”を受け取る。メッセージ
“ｒｅｑｕｅｓｔ　ｃｏｍｍｉｔ”だけが受け取られた
ので、次のステップで、回復ファシリティに状態レコー
ドを送って、同期点の状態を「代理、不確定」Ｂ８（図
１８）に更新する。状態レコードが回復ファシリティの
ログに成功裡に書き込まれると、Ｂ側の同期点マネジャ
は、Ａからのメッセージ“ｐｒｅｐａｒｅ”に応答して
、保護会話アダプタを介してＡ側の同期点マネジャにメ
ッセージ“ｒｅｑｕｅｓｔ　ｃｏｍｍｉｔ”を送る。

【０１１０】Ａ側の同期点マネジャは、Ｂ側の同期点マ
ネジャからメッセージ“ｒｅｑｕｅｓｔ　ｃｏｍｍｉｔ
”を受け取り、これでこの同期点の第１段階が完了する
。次に、この同期点マネジャは、この同期点の開始側と
して、作業論理ユニットをコミットするかそれともバッ
クアウトするかを決定しなければならない。メッセージ
“ｒｅｑｕｅｓｔ　ｃｏｍｍｉｔ”だけがＡ側の同期点
マネジャに受け取られたので、Ａ側の同期点マネジャは
、この作業論理ユニットをコミットすると決定する。こ
の２段階コミット手順の第２段階は、状態レコードを回
復ファシリティに送ることによってこの同期点マネジャ
がこの決定を記録することから始まる。この状態レコー
ドは、この同期点の状態を「開始側、コミット済み」Ｂ
９（図１８）に変更する。この状態レコードが回復ファ
シリティのログに成功裡に書き込まれると、この同期点
マネジャは、保護会話アダプタを介してＢ側の同期点マ
ネジャにメッセージ“ｃｏｍｍｉｔｔｅｄ（コミット済
み）”を送る。

【０１１１】Ｂ側の同期点マネジャは、このメッセージ
“ｃｏｍｍｉｔｔｅｄ”を受け取り、これで２段階コミ
ット手順の第１段階が完了する。第２段階は、この同期
点マネジャが回復ファシリティに状態レコードを送って
、この同期点の状態を「開始側カスケード、コミット済
み」Ｂ１０（図１８）に更新する時に開始される。次に
、Ｂ側の同期点マネジャは、保護された会話を介してＣ
側の同期点マネジャにメッセージ“ｃｏｍｍｉｔｔｅｄ
”を送る。

【０１１２】Ｃ側の同期点マネジャは、このメッセージ
“ｃｏｍｍｉｔｔｅｄ”を受け取り、これで２段階コミ
ット手順の第１段階が完了する。Ｃ側の同期点マネジャ
は、回復ファシリティに状態レコードを送って、この同
期点の状態を「開始側カスケード、コミット済み」Ｂ１
１（図１８）に更新することによって、第２段階を開始
する。メッセージ“ｃｏｍｍｉｔｔｅｄ”を受け取る参
加者は他にはもう存在しないので、Ｃ側の同期点マネジ
ャは、この同期点に関する作業を完了している。このこ
とを記録するために、Ｃ側の同期点マネジャは、状態レ
コードを回復ファシリティに送って、この同期点の状態
を「忘却」Ｂ１２（図１８）に更新する。この状態を介
して回復ファシリティは、この作業論理ユニット識別子
に関してＣ側の同期点マネジャが書き込んだすべてのレ
コードが、もはや不要であり消去可能であることを知る
。この状態レコードが回復ファシリティのログに成功裡
に書き込まれた後、Ｃ側の同期点マネジャは、メッセー
ジ“ｃｏｍｍｉｔｔｅｄ”に応答して、保護会話アダプ
タを介してＢ側の同期点マネジャにメッセージ“ｆｏｒ
ｇｅｔ（忘却）”を送り、これでＣ側の同期点マネジャ
の２段階コミット手順の第２段階が終了する。このメッ
セージ“ｆｏｒｇｅｔ”が送られた後、Ｃ側の同期点マ
ネジャは、この同期点が成功裡に完了したとの指示と共
に、制御をアプリケーションＣに返す。

【０１１３】Ｂ側の同期点マネジャは、Ｃ側の同期点マ
ネジャから保護会話アダプタを介して、メッセージ“ｆ
ｏｒｇｅｔ”を受け取る。このメッセージ“ｆｏｒｇｅ
ｔ”の受取りは、Ｂ側の同期点マネジャがこの同期点を
完了したことを示す。このことを記録するために、Ｂ側
の同期点マネジャは、回復ファシリティに状態レコード
を送って、この同期点の状態を「忘却」Ｂ１３（図１８
）に更新する。この状態から、回復ファシリティは、こ
の作業論理ユニット識別子に関してＢ側の同期点マネジ
ャが書き込んだすべてのレコードが、もはや不要であり
消去可能であることを知る。この状態レコードが回復フ
ァシリティに成功裡に書き込まれた後、Ｂ側の同期点マ
ネジャは、メッセージ“ｃｏｍｍｉｔｔｅｄ”に応答し
て、保護会話アダプタを介してＡ側の同期点マネジャに
メッセージ“ｆｏｒｇｅｔ”を送り、これでＢ側の同期
点マネジャの２段階コミット手順の第２段階が終了する
。メッセージ“ｆｏｒｇｅｔ”が送られた後、Ｂ側の同
期点マネジャは、この同期点が成功裡に完了したとの指
示と共に、制御をアプリケーションＢに返す。

【０１１４】Ａ側の同期点マネジャは、このメッセージ
“ｆｏｒｇｅｔ”を受け取る。このメッセージ“ｆｏｒ
ｇｅｔ”の受取りは、Ａ側の同期点マネジャがこの同期
点を完了したことを示す。このことを記録するために、
Ａ側の同期点マネジャは、回復ファシリティに状態レコ
ードを送って、この同期点の状態を「忘却」Ｂ１４（図
１８）に更新する。この状態から、回復ファシリティは
、この作業論理ユニット識別子に関してＡ側の同期点マ
ネジャが書き込んだすべてのレコードがもはや不要であ
り消去可能であることを知る。これでＡ側の同期点マネ
ジャの２段階コミット手順の第２段階が終了するが、こ
のことは、この同期点がそのすべての参加者について完
了したことを意味する。この状態レコードが回復ファシ
リティのログに成功裡に書き込まれた後、Ａ側の同期点
マネジャは、この同期点が成功裡に完了したとの指示と
共に、制御をアプリケーションＡに返す。

【０１１５】コミット手順におけるエラー・コードおよ
びエラー記述情報の処理の調整図２９ないし３２は、い
ずれかの資源または保護された会話がエラーまたは警告
を報告する場合に、アプリケーション５６Ａに戻りコー
ドを与える、システム５０Ａの構成要素を示す図である
。また、アプリケーション５６Ａは、それぞれの資源お
よび保護された会話から、詳細なエラー情報を要求する
ことができる。この詳細エラー情報は、報告元の資源を
識別し、同期点エラーの理由を記述し、同期点に関する
警告のこともあり得る。

【０１１６】アプリケーション５６Ａは、システム５０
Ａ内の分散アプリケーション実行環境５２Ａ（図３２参
照）内で実行中である。保護資源アダプタ６２Ａは、共
用ファイル資源マネジャ６３Ａ用のアダプタであり、資
源アダプタ６２Ｇは、ＳＱＬ資源マネジャ６３Ｇ用のア
ダプタであり、保護会話アダプタ６４Ａは、保護会話ア
ダプタ６４Ｂを介するシステム５０Ｂとの保護された会
話用のアダプタである。この例では、アダプタ６２Ａお
よび６４Ａは、システム５０Ａ内のシステム制御プログ
ラムに組み込まれた構成要素なので、同一の製品識別子
を有する。アダプタ６２Ｇは、異なる製品の一部なので
、独自の製品識別子を有する。アダプタ６２Ａおよび６
４Ａは、異なる資源アダプタ出口識別子を有する。この
例では、資源アダプタ６２Ｇは、アダプタ５６Ａには解
読不能であって、アダプタ５６Ａに詳細エラー情報を返
すための従来技術の機能を有する、エラー・ブロックを
生成する。

【０１１７】作業要求に応答して（図２９のステップ６
５１）、アダプタ６２Ａ、６２Ｇおよび６４Ａが、同期
点マネジャ６０に登録される（ステップ６５３）。同期
点マネジャ６０は、登録オブジェクト１６２Ａ、１６２
Ｂおよび１６２Ｃを生成し、参加する資源（共用ファイ
ル資源マネジャ６３Ａ、ＳＱＬ資源マネジャ６３Ｇおよ
びシステム５０Ｂ内の保護された会話のパートナ）の識
別子を入れる。また、この登録情報は、資源アダプタ出
口ルーチン名、資源および保護された会話の製品識別子
、および各資源のエラー・ブロックの必要な長さを含む
。資源アダプタ出口ルーチン名は、この例のシステム５
０Ａ内のシステム制御プログラムなどの製品が、２タイ
プの資源を所有する時に必要である。製品識別子と資源
アダプタ出口ルーチン名は共に、参加する資源のタイプ
、たとえば共用ファイル資源マネジャ、ＳＱＬ資源マネ
ジャ、または保護会話マネジャを識別する。１実行環境
内の同一タイプの資源の資源アダプタはすべて、システ
ム５０Ａのページング・セットを縮小するために、同一
のプールからのエラー・ブロックを使用する（図解は図
３１を参照されたい）。ある資源がステップ６５３（図
２９）で、他のタイプの資源と同一のサイズのエラー・
ブロックを要求する場合、そのエラー・ブロック・プー
ルがこれら２つの資源によって共用される。

【０１１８】各登録物（６２Ａ、６２Ｇおよび６４Ａ）
について、資源アダプタ出口ルーチンを呼び出すための
パラメータのリストが、同期点マネジャ６０によって作
成される。このリストは、その資源のエラー・ブロック
のアドレスと、使用可能なエラー情報の長さを含む。登
録エントリ内に使用可能なエラー情報の長さを置いても
、エラーが発生しない場合には、システム５０Ａのペー
ジング・セットは影響を受けない。

【０１１９】次に、アプリケーション５６Ａは、同期点
マネジャ６０からのコミットを要求する（図２９のステ
ップ６５４）。アプリケーション５６Ａが、この同期点
中にエラーが発生する場合に共用ファイル資源マネジャ
６３Ａからの詳細な情報（システム５０Ａ内の共用ファ
イル資源マネジャの従来技術の機能）を望む場合、アプ
リケーション５６Ａは、詳細なエラー情報のコピーを記
憶するための、その実行環境内のデータ域のアドレスを
、エラー・データ・アドレスとしてこのＣｏｍｍｉｔ動
詞と同時に送る（図２９のステップ６５４）。このデー
タは、資源マネジャ６３Ａがエラーまたは警告を報告す
る場合に使用される。同期点マネジャ６０は、共用ファ
イル資源アダプタ６２Ａの代わりにこの動詞を受け取り
、エラー・データ・アドレスは、同期点マネジャ６０に
よってセーブされる。同期点の完了時に、すべてのエラ
ーと警告（図２９のエラー・ブロック６６Ａに記憶され
ている）は、アプリケーション５６Ａのエラー・データ
域（図示せず）に移される。したがって、共用ファイル
資源マネジャの従来技術のエラー・パス・バック・アー
キテクチャとの互換性が保たれている。

【０１２０】ステップ６５５（図２９）で、同期点マネ
ジャ６０は、各資源アダプタ（図３２の６２Ａ、６２Ｇ
および６４Ａ）に、登録オブジェクト１６２Ａないし１
６２Ｃにセーブされたそのエラー・ブロック（オブジェ
クト６６Ａないし６６Ｃ）のアドレスを渡す。登録オブ
ジェクト１６２Ａないし１６２Ｃは、資源アダプタが登
録された時、各資源アダプタごとに作成されている（ス
テップ６５３）。障害がない場合、ステップ６５４から
のコミットが完了し、その後同期点マネジャ６０は、更
新がコミット済みであることをアプリケーション５６Ａ
に報告する（ステップ６５７）。

【０１２１】ところが、ある資源がエラーまたは警告を
検出した場合には（図３０のステップ６７０）、そのア
ダプタ６２Ａ、６２Ｇまたは６４Ａは、エラー・ブロッ
ク６６Ａないし６６Ｃ（図２９）を、設計上必要なもの
をすべて記憶するための場所として使用して、詳細なエ
ラー情報を入れ、入出力パラメータである使用可能なエ
ラーの長さを更新する。資源アダプタ出口ルーチンは、
２段階コミット手順中に何回も呼び出すことができるの
で、必要に応じてエラー・ブロックにエラー情報を付加
できる。たとえば、３つの警告と１つの重大なエラーが
あってもよい。資源アダプタ出口ルーチンは、それ自体
で使用可能なエラーの長さを管理する（ステップ６７２
）。

【０１２２】同期点マネジャ６０は、資源アダプタ出口
ルーチンから、共通のフォーマットの単一の戻りコード
を受け取り、２段階コミット手順の論理を続行する（ス
テップ６７３）。このとき、同期点マネジャ６０は、エ
ラー・ブロック６６Ａないし６６Ｃの内容を知らず、こ
れに関心を持つこともない。２段階コミット手順の論理
がエラーまたは警告を指摘した場合、同期点マネジャは
、統合された戻りコードをアプリケーション５６Ａに返
す（図２９のステップ６５７および図３０のステップ６
７４）。

【０１２３】この戻りコードを受け取ると、アプリケー
ション５６Ａは、同期点マネジャ６０から提供されるル
ーチンを呼び出すことによって、詳細なエラー・ブロッ
クを要求する（図３０のステップ６７６）。これに応答
して、同期点マネジャ６０内部のエラー・ブロック・マ
ネジャ（図３２の機能６９０）が、空でないエラー・ブ
ロックを探し、これをアプリケーション５６Ａのバッフ
ァに移動する。他の出力パラメータは、このエラー・ブ
ロックの所有者の製品識別子と資源アダプタ出口ルーチ
ン名である。次に、アプリケーション５６Ａは、この製
品識別子を検査する。報告を行った製品がシステム５０
Ａ内のシステム制御プログラムである場合（図３０の判
断ブロック６７８）、アプリケーション５６Ａは資源ア
ダプタ出口ルーチン名を検査して、２つのシステム制御
プログラム・アダプタの区別を行う。これで、エラー・
ブロックでその資源名と障害の原因を探すことができる
（ステップ６８０Ａまたは６８０Ｂ）。エラー・ブロッ
クの読取りを助けるためのシステム５０Ａ内のシステム
制御プログラムから、共用ファイル資源マネジャと保護
された会話のための、マッピング・マクロが提供される
。また、エラー・ブロックを都合の良い形であるパラメ
ータ・リストに再フォーマットするために、各アダプタ
からルーチン（図３２の対話６９３）が提供される。 共用ファイル資源マネジャを使用する既存のアプリケー
ションは、エラー・パス・バック方法が変更されていな
いので、変更不要である。保護された会話は新規である
ので、通信を使用する既存のアプリケーションに関する
互換性の目的には反しない。

【０１２４】製品がＳＱＬ資源マネジャである場合（図
３０の判断ブロック６８１）、説明のため、エラー・ブ
ロックが、現在アプリケーション５６Ａが理解できる形
ではないと仮定すると、このエラー・ブロックを解読し
なければならない。したがって、アプリケーション５６
Ａは、アプリケーション５６Ａが理解できる形でエラー
のタイプを識別するよう資源アダプタ６２Ｇに要求する
（ステップ６８２）。これに応答して（ステップ６８３
）、ＳＱＬ資源アダプタ６２Ｇは、アプリケーション５
６Ａの使用するルーチンに非常に類似してはいるが、資
源アダプタ用に特殊化されたルーチンを使って、同期点
マネジャからエラー・ブロックを読み取る。ＳＱＬ資源
アダプタ６２Ｇとアプリケーション５６Ａは一義的なト
ークンを与えられ、その結果、これらの双方が、混乱す
ることなく同一のエラー・ブロック内を巡回できること
に留意されたい。ＳＱＬ資源アダプタ６２Ｇは、エラー
・ブロック６６Ｃ（図２９）内のデータを再フォーマッ
トして、アプリケーション５６Ａと互換性をもつ形に変
換し（図３０のステップ６８４）、その後、この再フォ
ーマットされた詳細なエラー情報をアプリケーション５
６Ａに送る（ステップ６８５）。この例では、既存のＳ
ＱＬ資源アダプタがエラー情報の調整式処理に参加する
には、些細な内部的な変更しか必要でない、すなわち、
同期点マネジャ６０にエラー・ブロックを要求しなけれ
ばならないことに留意されたい。アプリケーション５６
Ａが１つの資源しか更新しない場合、既存のアプリケー
ションは変更を必要としないので、ＳＱＬ資源アダプタ
のエラー・パス・バック・インタフェースの外見が保存
される。アプリケーション５６Ａが、新しい機能である
調整された同期点を使用していることを示す追加のエラ
ー・コードは、非互換性とはみなされない。

【０１２５】その後、アプリケーション５６Ａは、追加
のエラー・ブロックがあるか否かを決定するために、同
期点マネジャ６０に照会を行う（図３０のステップ６７
６）。そうである場合（判断ブロック６７７）、ステッ
プ６７８ないし６８５を繰り返して、同期点マネジャ６
０から１つまたは複数の追加のエラー・ブロックを得る
。これ以上エラー・ブロックがない場合、判断ブロック
６７７から図２９のステップ６８８に進み、ここでアプ
リケーション５６Ａは処理を継続して、異なる機能を続
行するか、あるいは障害の矯正を試みる。

【０１２６】同期点マネジャ６０は、前記「コミット手
順のための資源の登録」で述べたように、次の同期点ま
でエラー・ブロックを保存する。

【０１２７】保護された資源を回復するためのログ名の
交換アプリケーション５６（図２）が同期点要求を発行
する時、すべての保護された資源に対する変更をコミッ
トするために、２段階コミット手順が開始される。保護
された資源には、資源マネジャによって管理されるデー
タベースなどの保護された資源、ならびに分散パートナ
・アプリケーションを表す保護された会話と称する特殊
な分類の資源が含まれる。「保護された資源の調整式同
期点管理」で述べたように、２段階コミット手順の第１
段階は、コミットのための資源の準備である。第１段階
の間にすべての資源マネジャがコミットに同意すると、
第２段階で実際のコミットを行う。第１段階の間に準備
できない資源がある場合、すべての資源は、第２段階の
間にその変更をコミットする代わりにバックアウトする
よう命じられる。すべての資源データの変更は、それら
が実際にコミットされるまで、バックアウトの対象とな
る。

【０１２８】「分散アプリケーション用の未完了の同期
点のための回復ファシリティ」に記載するように、障害
のために同期点が完了できない時に同期点を完了させる
ための回復手順をサポートするには、その以前に同期点
情報が、持久記憶装置内にある回復ファシリティ・ログ
７２および資源マネジャ・ログ８００に記憶され、保持
されていることが必要である。ロギングは、各同期点マ
ネジャ６０ならびに参加する各資源マネジャ６３によっ
て行われる。ログに記録される情報には、ロギングを行
う同期点マネジャまたは資源マネジャからみた同期点の
現在の状態、既知の同期点参加者の同期点ログに関連す
る現在の名前、および、同期点マネジャの場合には、同
期点障害からの回復の際に同期点参加者との会話を確立
するのに必要な情報が含まれる。

【０１２９】既知の同期点参加者のログ名に関する情報
は、その他の同期点情報とは分離または区分してロギン
グされる。このログ名情報は、ログ名ログ７２Ａ２（図
１９）に記録され、残りの情報は、同期点ログ７２Ａ１
に記録される。

【０１３０】いずれかの同期点ログに情報を記録する際
に障害が発生し、そのログを再初期設定する必要が生じ
、実際に新しいログを開始する時は、そのログに新しい
名前が割り当てられる。これが発生した時は、同期点に
参加する他の同期点マネジャおよび資源マネジャが、新
しいログの所有者および維持者と共に、そのログが再初
期設定されたこと、および新しい名前が有効であること
を知らされることが重要である。

【０１３１】各同期点マネジャおよび参加者が、有効な
同期点ログを有することは、自動的再同期化のために不
可欠である。すなわち、再同期化の時点でのログは、同
期点中に使用されたものと同一のログでなければならな
い。いずれかのログが置換されまたは損傷を受けた場合
、再同期化は正常に進行できない。すべてのログが正し
いことを保証するために、各同期点マネジャおよび参加
する資源のログ名に関して同期点以前に同意が行われる
。これはログ名交換と称する手順によって行われる。 再同期化の開始直前にもう１つのログ名交換があり、そ
の結果、すべての参加者のログ名が同期点開始時と同一
であると決定され、ログの再初期設定を行った参加者が
ないとわかるので、再同期を続行して、障害を発生した
同期点を回復することができる。この手順を省くと、無
効な同期点ログ情報のために、回復処理に障害が生じた
り、回復処理から誤った結果が生ずる可能性がある。

【０１３２】同一のシステム内のアプリケーション環境
（たとえば、システム５０Ａ内の分散アプリケーション
環境５２Ａおよび５２Ｂ）間での保護された会話の最適
化としては、ログ名を交換する必要はない。というのは
、同期点マネジャ６０Ａおよび６０Ｂが、それぞれ同一
の回復ファシリティ・ログ７０Ａおよび回復ファシリテ
ィ・ログ７２Ａを共用しているからである。共通の回復
ファシリティ・ログ７２Ａが存在する時は、（ログ名交
換による）ログ同期化のステップは、不要であり、省略
してよい。同期点マネジャのロギングは、サポートされ
る同期点マネジャ６０と同一のシステム内に常駐する共
通の回復ファシリティ７０によって行われる。システム
５０Ａ内の同期点マネジャ６０Ａ、６０Ｂ、６０Ｃはす
べて、共通の回復ファシリティ７０Ａを共用し、回復フ
ァシリティ・ログ７２Ａ内のログの、同一のサポート対
（同期点およびログ名）を共用している。

【０１３３】図３３には、３つのシステム５０Ａ、５０
Ｄ、５０Ｆと、そのそれぞれの中にある回復ファシリテ
ィと、これらのシステム間の通信が示されている。アプ
リケーション環境５２Ａ、５２Ｂ、５２Ｄ、５２Ｆ、５
２Ｇは、それぞれ調整式の資源回復のために同期点マネ
ジャ６０Ａ、６０Ｂ、６０Ｄ、６０Ｆ、６０Ｇを使用す
る、アプリケーション・プログラム５６Ａ、５６Ｂ、５
６Ｄ、５６Ｆ、５６Ｇ（図示せず）を含む。同期点マネ
ジャは、そのシステム内の回復ファシリティを使用して
、同期点と、障害を発生した同期点からの回復に必要な
ログ名ログとを管理する。たとえば、アプリケーション
環境５２Ａおよび５２Ｂ内の同期点マネジャは、回復フ
ァシリティ７０Ａを使用してログ７２Ａに記録する。 資源マネジャ６３Ａ、６３Ｂ、６３Ｄ、６３Ｅ、６３Ｆ
、６３Ｇは、それぞれそれ自体の同期点と、ログ名ログ
８００Ａ、８００Ｂ、８００Ｄ、８００Ｅ、８００Ｆ、
８００Ｇを維持する。図示の同期点の範囲は、実線と矢
印で示されている。同期点はいずれの参加者でも開始で
き、かつ同期点の範囲は動的であるが、図を簡単にする
ためにこの図は静的なものである。この図の静的な場合
では、同期点は、アプリケーション環境の間で、５２Ｂ
から５２Ｄへ、さらに５２Ｆへと、関連する同期点マネ
ジャおよび保護会話アダプタ（図示せず）を介し、通信
の実線８０１および８０２を経て流れ、またアプリケー
ション環境５２Ａ、５２Ｂ、５２Ｄ、５２Ｆ、５２Ｇか
ら、関連する同期点マネジャおよび保護会話アダプタを
介し、それぞれ通信の実線８０３Ａ−１、８０３Ａ−２
、８０３Ｂ、８０３Ｄ、８０３Ｅ、８０３Ｆ、８０３Ｇ
を経て、資源マネジャ６３Ａ、６３Ｂ、６３Ｄ、６３Ｅ
、６３Ｆ、６３Ｇへ流れる。点線は、同期点以前の同意
の際と、障害を発生した同期点を回復するための再同期
化の際に使用される通信経路を示す。資源マネジャにと
って、この点線で示された通信は、起点側アプリケーシ
ョン環境のシステムの資源マネジャと回復ファシリティ
の間に存在し、たとえば、資源マネジャ６３Ｅからは、
７０Ｄにではなく７０Ａに向かう。

【０１３４】３つの同期点の範囲が、図３３に含まれて
いる。第１の範囲は、単一のアプリケーション環境５２
Ａ（および同期点マネジャ）を含み、２つの資源マネジ
ャ６３Ａおよび６３Ｅを使用する。第２の同期点の範囲
は、３つのアプリケーション環境５２Ｂ、５２Ｄおよび
５２Ｆを含み、これらはそれぞれ、様々な参加する資源
マネジャ（５２Ｂには６３Ｂ、５２Ｄには６３Ｄと６３
Ｅ、５２Ｆには６３Ｆと６３Ｇ）を含む。これを図３４
の同期点ツリーに示す。

【０１３５】図１９のブロック図および図２０、図２１
、図２２の流れ図は、システム５０Ａとシステム５０Ｄ
の間の保護された会話を使用するログ名交換の処理を実
例によって示す図である。アプリケーション５６Ａは、
アプリケーション５６Ｄとの保護された会話を開始する
（図２０のステップ８３１）。アプリケーション５６Ａ
はシステム５０Ａ内のアプリケーション環境５２Ａで実
行中であり、アプリケーション５６Ｄはシステム５０Ｄ
内のアプリケーション環境５２Ｄで実行中である。 会話の開始には、経路（システム識別子、この例では“
Ｂ”）と、パートナ・アプリケーションの資源識別子を
指定することが含まれる。この経路はシステム５０Ｄを
識別し、この資源識別子は目的のアプリケーション５６
Ｄを識別する。資源識別子については、本節で後で詳し
く説明する。システム制御プログラムは、アプリケーシ
ョンの資源マネジャとして働くファシリティを含み、こ
れはアプリケーション用のアプリケーション資源識別子
の確立をサポートし、これらの識別子が会話開始に使用
された際にこれを認識し、その後、実行環境内でアプリ
ケーションを活動状態にし、またすでに活動状態である
場合には、新規の会話をその活動状態のアプリケーショ
ンに経路指定する。したがって、アプリケーション用の
会話の経路指定には経路（システム識別子）と資源識別
子を使用する。その際に、経路は、それぞれシステムを
代表する通信ファシリティの解釈に従ってシステム間の
経路指定を行い、資源識別子は、アプリケーション資源
用の資源マネジャとして働くシステム制御プログラムの
解釈に従って、システム内の実行環境内のアプリケーシ
ョンへの経路指定またはそのアプリケーションの活動化
を行う。

【０１３６】この会話開始を受け取ると、通信ファシリ
ティ５７Ａは、その交換ログ名状況テーブル（ＥＬＳＴ
）２０８Ａを探索して、現経路である経路Ｂ用のエント
リを求める（図２０のステップ８３３）。交換ログ名状
態テーブルの経路Ｂ用のエントリは、状況０によって、
システム５０Ａが最後に開始されて以降にこの経路上に
は保護された会話が発生していないことを示す。したが
って（図２０の判断ステップ８３４）、交換ログ名状態
テーブルの経路Ｂ用のエントリ２０８Ａが、状況１に変
更され（図２０のステップ８３６）、会話開始メッセー
ジ５０５（図１９）が代行受信され、この会話は、通信
ファシリティ５７Ａによって中断される（図２０のステ
ップ８３７）。次に、通信ファシリティ５７Ａ（図１９
）は、ローカルの回復ファシリティ７０Ａへの制御経路
上にメッセージ２００（図１９）を送って、この会話開
始が通信ファシリティ５７Ａに受諾されないうちに、経
路Ｂに対してログ名交換を初期設定すべきであると指示
する（図２０のステップ８３８）。

【０１３７】回復ファシリティ７０Ａは、このメッセー
ジを受け取り（図２１のステップ８５０）、その後、Ｅ
ＬＳＴ２０７Ａの経路Ｂ用のエントリを状況１にセット
して、経路Ｂ用のログ名交換が進行中であることを示す
（図２１のステップ８５１）。次に、回復ファシリティ
７０Ａ（図１９）は、通信経路Ｂ上で保護されない会話
を開始する（図１９のメッセージ２０２）。この会話は
「保護されていない」ので、通信ファシリティによる代
行受信の可能性はない。というのは、保護された会話だ
けが、ログ名交換手順を強制するために代行受信がある
かどうか監視されるからである。システム５０Ａからシ
ステム５０Ｄへの通信ファシリティを介する経路指定は
、上記と同様である。

【０１３８】この会話開始は、資源識別子ｐｒｏｔｅｃ
ｔｅｄ＿ｃｏｎｖｅｒｓａｔｉｏｎ＿ｒｅｃｏｖｅｒｙ
（保護会話回復）と称する、グローバルに予約された資
源識別子も使用する。この資源識別子を使用すると、識
別された目的システム５０Ｄの回復ファシリティ７０Ｄ
への経路指定が可能になる。回復ファシリティ７０Ａお
よび７０Ｄはそれぞれ、初期設定の際に、システム制御
プログラムに対して、“ｐｒｏｔｅｃｔｅｄ＿ｃｏｎｖ
ｅｒｓａｔｉｏｎ＿ｒｅｃｏｖｅｒｙ”と称するグロー
バル資源に対するローカル資源マネジャとしてそれ自体
を識別する。この結果、システム５０Ｄ用のシステム制
御プログラムは、ｐｒｏｔｅｃｔｅｄ＿ｃｏｎｖｅｒｓ
ａｔｉｏｎ＿ｒｅｃｏｖｅｒｙ資源識別子を有する会話
を、ローカルの回復ファシリティ７０Ｄに経路指定し、
また回復ファシリティ７０Ｄは、この会話を開始するの
に使用されたｐｒｏｔｅｃｔｅｄ＿ｃｏｎｖｅｒｓａｔ
ｉｏｎ＿ｒｅｃｏｖｅｒｙ資源識別子に基づいて、この
会話の目的が、別の回復ファシリティ７０Ａとのログ名
交換であると判定する。この会話の初期メッセージ２０
２（図１９）は、ログ７２Ａのログ名、ならびにそのロ
グ名が「新規」であるか否か、すなわち、「旧」ログに
関連する重大な障害または喪失の結果としてそのログ名
が新規のログを反映するように変更されたか否かの標識
を含む（図２１のステップ８５２）。現在の例では、こ
のログは新規ではないと仮定する。回復ファシリティ７
０Ａは、メッセージ２０２（図１９）に対する応答を待
つ。

【０１３９】回復ファシリティ７０Ｄは、通信線２０２
に沿って回復ファシリティ７０Ａから送られたログ名情
報を受け取った後に（図２２のステップ８７０）、経路
Ｂに関するＥＬＳＴ２０７Ｄを状況１にセットし、ロー
カル通信ファシリティ５７Ｄは、メッセージ２０３（図
１９）を介して、やはり経路Ｂに関するＥＬＳＴ２０８
Ｄを状況１に変更するよう通知される（図２２のステッ
プ８７１）。図２０のステップ８４１、図２０のステッ
プ８４２、図２０のステップ８４３および図２０のステ
ップ８４６は、通信ファシリティ内のＥＬＳＴを変更す
るステップを示す。回復ファシリティ７０Ｄは、メッセ
ージ２０２（図１９）から、回復ファシリティ７０Ａの
ログ名が新規でなく（図２２の判断ステップ８７２）、
それ自体のログも新規ではない（図２２の判断ステップ
８７６）と判定し、最後に、メッセージ２０２（図１９
）内のログ名が、回復ファシリティ７０Ｄのログ名ログ
７２Ｄ２の経路Ｂに関するエントリに記憶されたログ名
と一致すると判定する。したがって、ＥＬＳＴ２０７Ｄ
は、経路Ｂに関して状況２にセットされ、ローカル通信
ファシリティ５７Ｄは、メッセージ２０３（図１９）を
介して、やはり経路Ｂに関するＥＬＳＴ２０８Ｄを状況
２にセットするよう通知される（図２２のステップ８７
９、図２０のステップ８４１および図２０のステップ８
４２）。その後、回復ファシリティ７０Ｄは、回復ファ
シリティ７０Ａに正常に応答して（図１９のメッセージ
２０６）、そのログ７２Ｄのログ名とそれが新規である
か否かの標識を送る（図２２のステップ８８２）。

【０１４０】回復ファシリティ７０Ａは、この正常な応
答を受け取り（図２１の判断ステップ８５３）、回復フ
ァシリティ７０Ａのログ７２Ａが新規ではなく（図２１
の判断ステップ８５７）、メッセージ２０６（図１９）
によれば回復ファシリティ７０Ｄのログ７２Ｄが新規で
はないので（図２１の判断ステップ８５８）、回復ファ
シリティ７０Ａは、回復ファシリティ７０Ｄからメッセ
ージ２０６（図１９）中で送られたログ７２Ｄの名前と
、ログ７２Ａ２の経路Ｂに関するエントリに記憶された
ログ名の突合せに成功し（図２１の判断ステップ８５９
）、したがって、ＥＬＳＴ２０７Ａの経路Ｂに関するエ
ントリを状況２にセットし、メッセージ２０４（図１９
）を介して、ローカル通信ファシリティ５７Ａに、ＥＬ
ＳＴ２０８Ａを状況２にセットするよう通知する（図２
１のステップ８６２）。その後、回復ファシリティ７０
Ａは、経路Ｂ上の回復ファシリティ７０Ｄとの会話の正
常終了を行って（図２１のステップ８６３）、回復ファ
シリティ７０Ｄが、正常に完了できるようにする（図２
２の判断ステップ８８３と図２２のステップ８８６）。 通信ファシリティ５７Ａが、経路Ｂの状況をＥＬＳＴ２
０８Ａに記入するよう伝えるメッセージ２０４（図１９
）を受け取ると（図２０のステップ８４１と図２０のス
テップ８４２）、代行受信され中断された経路Ｂ上の会
話５０５は、その初期設定を完了できるようになる（図
２０の判断ステップ８４３、図２０のステップ８４５お
よび図２０のステップ８４６）。この完了によって、こ
の会話の中断状態が解消され、この会話は、その宛先で
ある通信ファシリティ５７Ｄに向かって流れることがで
きるようになる。目的の通信ファシリティ５７Ｄで保護
会話到着事象（図２０のステップ８３２）があり、その
後、ＥＬＳＴ２０８Ｄ内の経路エントリを検索して、状
況が２であることが示され（図２０の判断ステップ８３
４）、この会話開始が、アプリケーション５６Ｄに正常
に流れることができるようになる（図２０のステップ８
３９）。

【０１４１】これで、会話の代行受信とログ名交換の正
常な場合の流れが完了する。いくつかの追加の場合も図
示されている。図２０のステップ８３４と図２０のステ
ップ８３５は、この経路用のログ名交換がすでに進行中
であることを示す１の状況が確立されると、同一の経路
上の追加の会話も中断されることを示している。

【０１４２】目的の回復ファシリティ７０Ｄが、メッセ
ージ２０２（図１９）中で送られたログ名と経路Ｂに関
してログ７２Ｄ２に記憶されたログ名が一致しないこと
を見つけた場合（図２２の判断ステップ８７７）、メッ
セージ２０６（図１９）中でエラーが戻され（図２２の
ステップ８８０）、ＥＬＳＴ２０７Ｄは、経路Ｂに関し
て状況０にセットされ、通信ファシリティ５７Ｄは、メ
ッセージ２０３（図１９）を介して、同様にそのＥＬＳ
Ｔ２０８Ｄを変更するよう通知される（図２０のステッ
プ８４１、図２０のステップ８４２および図２２のステ
ップ８８１）。

【０１４３】原始ログ７２Ａが新規であり（図２２の判
断ステップ８７２）、ログ７２Ｄも新規である（図２２
の判断ステップ８７３）ことを示すメッセージ２０２（
図１９）を、回復ファシリティ７０Ｄが受け取った場合
、ログ７２Ａの新規のログ名が、経路Ｂに関するログ７
２Ｄ２に記憶され（図２２のステップ８７８）、前記と
同様に正常な完了が継続する（図２２のステップ８７９
、図２２のステップ８８２など）。

【０１４４】原始ログ７２Ａは新規であるが（図２２の
判断ステップ８７２）、ログ７２Ｄは新規でない（図２
２の判断ステップ８７３）ことを示すメッセージ２０２
（図１９）を、回復ファシリティ７０Ｄが受け取り、か
つ同期点ログ７２Ｄ１から、経路Ｂに関して未解決の同
期点回復（未処理の再同期化）が存在すると判定された
（図２２の判断ステップ８７４）場合には、システム５
０Ｄの操作員に対してエラー・メッセージが生成され（
図２２のステップ８７５）、メッセージ２０６（図１９
）中で、回復ファシリティ７０Ａにエラーが戻され（図
２２のステップ８８０）、ＥＬＳＴ２０７Ｄは状況０に
変更され、ローカル通信ファシリティは、メッセージ２
０３（図１９）を介して、ＥＬＳＴ２０８Ｄを状況０に
変更するよう通知され（図２２のステップ８８１、図２
０のステップ８４１、図２０のステップ８４２）、その
後、リターンする（図２２のステップ８８２）。

【０１４５】回復ファシリティ７０Ａが、回復ファシリ
ティ７０Ｄからのメッセージ２０６（図１９）中でエラ
ー応答を検出し（図２１の判断ステップ８５３）、かつ
未処理の再同期化が存在するとログ７２Ａ１で示される
（図２１の判断ステップ８５４）場合には、システム５
０Ａの操作員にメッセージが送られ（図２１のステップ
８５５）、ＥＬＳＴ２０７Ａおよび２０８Ａは、状況０
に変更される（図２１のステップ８５６）。ＥＬＳＴ２
０８Ａは、通信ファシリティ５７Ａに対するメッセージ
２０４（図１９）を介して状況０に変更される（図２０
のステップ８４１と図２０のステップ８４２）。この結
果、代行受信された会話を開始したアプリケーション５
６Ａにエラーが戻され、会話は拒絶される（図２０のス
テップ８４４）。未処理の再同期化がない場合は（図２
１の判断ステップ８５４）、操作員にメッセージは送ら
れない（図２１の判断ステップ８５４）。

【０１４６】回復ファシリティ７０Ｄからのメッセージ
２０６（図１９）中で、新規のログ名が回復ファシリテ
ィ７０Ａに戻されると（図２１の判断ステップ８５７）
、このログ名はログ７２Ａ２の経路Ｂに関するエントリ
に記憶され（図２１のステップ８６１）、２のＥＬＳＴ
状況が経路Ｂに関してセットされ（図２１のステップ８
６２）、通信ファシリティ５７Ａは、この会話を中断か
ら解放する（図２０のステップ８４１、図２０の判断ス
テップ８４３および図２０のステップ８４５）。

【０１４７】回復ファシリティ７０Ｄからメッセージ２
０６（図１９）中で戻されたログ名が、経路Ｂに関して
ログ７２Ａ２に記憶された名前と一致しないことを回復
ファシリティ７０Ａが検出するか（図２１の判断ステッ
プ８５８および８５９）、あるいはログ７２Ｄ２に対し
て新規のログ名が戻され（図２１の判断ステップ８５８
）、経路Ｂに関して必要な未処理の再同期化が存在する
とログ７２Ａ１から回復ファシリティ７０Ａが決定した
（図２１の判断ステップ８６０）場合は、回復ファシリ
ティ７０Ａは、メッセージ２０２および２０６（図１９
）をサポートした会話を異常終了させることによって、
回復ファシリティ７０Ｄに重大なエラーが存在すること
を知らせ（図２１のステップ８６４）、システム５０Ａ
の操作員に対するメッセージを生成し（図２１のステッ
プ８６５）、ＥＬＳＴ２０７Ａの状況をリセットし、通
信ファシリティ５７Ａに対するメッセージ２０４（図１
９）を介して、ＥＬＳＴ２０８Ａの状況をもリセットす
る（図２１のステップ８６６）。この結果、代行受信さ
れた会話を開始したアプリケーション５６Ａにエラーが
戻され、会話は拒絶される（図２０のステップ８４４）
。

【０１４８】すべての場合において、回復ファシリティ
７０Ｄは、回復ファシリティ７０Ａに応答（図２２のス
テップ８８２）した後であっても、会話の異常終了を通
じて回復ファシリティ７０Ａから送られるエラー（図２
１のステップ８６４）を検出することができる（図２２
の判断ステップ８８３）。それが発生した時、ＥＬＳＴ
２０７Ｄの経路Ｂのエントリと、通信ファシリティ５７
Ｄへのメッセージ２０３（図１９）（および図２０のス
テップ８４１と図２０のステップ８４２）を介してＥＬ
ＳＴ２０８Ｄの経路Ｂのエントリとが、状況０にリセッ
トされ（図２２のステップ８８４）、ログ７２Ｄ２の経
路Ｂに関するログ名エントリが消去され（図２２のステ
ップ８８５）、以前のステップ８７８（図２２）を否定
する。

【０１４９】図１９のＥＬＳＴ２０８Ａおよび２０８Ｄ
に示されるように、各通信ファシリティは、各経路に対
する会話の代行受信（状況２以外）、ログ名交換の開始
（状況０）および正常な会話の流れ（状況２）を制御す
る。各回復ファシリティが維持するＥＬＳＴ２０７Ａお
よび２０７Ｄも同様であるが、任意選択の最適化である
。ＥＬＳＴ２０７Ａおよび２０７Ｄを用いると、通信フ
ァシリティのＥＬＳＴの更新が実際には不要である時に
、ローカル通信ファシリティに対する更新要求のメッセ
ージが回避できる。これについては後でさらに説明する
。

【０１５０】図１９には、さらに、システムのうちの１
つが障害を発生した時に必要な処理が示されている。通
信ファシリティ５７Ａ、回復ファシリティ７０Ａまたは
それらの間の通信経路に障害があるものと仮定する。こ
のような障害は、通信ファシリティ５７Ａ内のＥＬＳＴ
２０８Ａおよび回復ファシリティ内７０ＡのＥＬＳＴ２
０７Ａを状況０にリセットさせる。このことが重要なの
は、そうしないと、このような障害によって、ログ障害
も発生していた可能性がマスクされ得るためである。こ
の可能性のゆえに、交換ログ名状況テーブルのエントリ
の状況を０にすることによって、すべての同期点同意が
リセットされる。アプリケーション環境５２Ａまたは５
２Ｄの障害は、これらのアプリケーション環境がログ名
交換処理に直接影響しないので、ログ名交換状況テーブ
ルのリセットを起こさないことに留意されたい。アプリ
ケーション環境はシステム・ファシリティよりも障害を
発生しやすいので、このことは重要である。同様に、共
通の論理経路（図示せず）を共用する複数のアプリケー
ション環境のうちの１つの障害は、その経路を使用する
他のアプリケーションの処理には影響を与えない。

【０１５１】さらに、通信ファシリティ５７Ａ、回復フ
ァシリティ７０Ａまたはそれらの間の制御経路の障害の
後に、アプリケーション５６Ｄが、アプリケーション環
境５２Ａ内のアプリケーション５６Ａに対する経路Ｂに
沿った会話を開始するものと仮定する。通信ファシリテ
ィ５７Ｄ内の交換ログ名状況テーブルは、経路Ｂの状況
が２であり、通信ファシリティ５７Ｄ内のテーブルが、
システム５０Ａに障害が発生した際にはリセットされな
かったことを示しているので、この会話は、通信ファシ
リティ５７Ｄによって代行受信されない。ところが、こ
の会話が通信ファシリティ５７Ａまで達すると、保護会
話到着事象があり（図２０のステップ８３２）、ＥＬＳ
Ｔ２０８Ａを検索すると、状況が０であることが示され
（図２０の判断ステップ８３４）、通信ファシリティ５
７Ａはこの会話の経路指定を代行受信し（図２０のステ
ップ８３６と図２０のステップ８３７）、したがって通
信ファシリティ５７Ａは、回復ファシリティ７０Ａに対
するメッセージ２００（図１９）によって、ログ名交換
を要求する（図２０のステップ８３８）。これによって
、前述のログ名交換処理が繰り返される。このログ名交
換がその交換処理中に回復ファシリティ７０Ｄ中で受け
取られた時、回復ファシリティ７０Ｄ内の交換ログ名状
況テーブルは、経路Ｂのエントリの状況が２であること
を示す。したがって、回復ファシリティ７０Ｄは、通信
ファシリティ５７Ｄに、経路Ｂに関して交換ログ名状況
テーブルを変更するよう通知することはしない。このよ
うな交換は不要である。この点が、このログ名交換処理
における、上述の障害発生前の処理との唯一の相違点で
ある。ログ名交換処理が完了した後に、回復ファシリテ
ィ７０Ａは、メッセージ２０４（図１９）を介して通信
ファシリティ５７Ａに、経路Ｂの状況を０から２に変更
するよう通知する。その後、通信ファシリティ５７Ａは
、経路Ｂに沿った会話を解放し、この会話がアプリケー
ション５２Ａに流れるようになる。

【０１５２】前述の２つの例では、回復ファシリティ７
０Ａが、メッセージ２０２（図１９）を介して経路Ｂ上
のログ名交換を開始したことに留意されたい。しかし、
その代わりに、通信ファシリティ５７Ｄが保護された会
話を最初に代行受信する通信ファシリティであった場合
には、回復ファシリティ７０Ｄが、メッセージ２０６（
図１９）で示されるログ名交換処理を開始する。保護さ
れた会話のために同一の経路を使用する、同一のシステ
ム５０Ａ内のすべてのアプリケーション環境に対して同
期点以前の同意を満足するには、単一のログ名交換で十
分なことにも留意されたい。共通のログ名交換状況テー
ブル２０８Ａに記録することによって、これが可能にな
る。さらに、同一のシステム内にあるすべてのアプリケ
ーション環境が同一のログ７２を共用するので、保護さ
れた会話に関係するシステム５０Ａおよび５０Ｄのそれ
ぞれにアプリケーション環境が複数存在する時でも、同
期点以前の同意の要件を満足するには、上述の単一のロ
グ名交換処理で十分であることに留意されたい。また、
保護された会話が、アプリケーション環境５２Ａからそ
れと同一のシステム５０Ａ内にあるアプリケーション環
境５２Ｂに向けて開始される時は、アプリケーション環
境５２Ａおよび５２Ｂが同一のログ７２Ａを共用し、ロ
グ名交換が不要であるので、通信ファシリティ５７Ａは
この会話を代行受信しない。

【０１５３】たとえば、この体系的システム間通信の標
準は、ＩＢＭコーポレーションの刊行物“Ｓｙｓｔｅｍ
　Ｎｅｔｗｏｒｋ　Ａｒｃｈｉｔｅｃｔｕｒｅ　ＬＵ　
６．２　Ｒｅｆｅｒｅｎｃｅ：　Ｐｅｅｒ　Ｐｒｏｔｏ
ｃｏｌｓ，　ＳＣ３１−６８０８，　Ｃｈａｐｔｅｒ　
５．３　Ｐｒｅｓｅｎｔａｔｉｏｎ　Ｓｅｒｖｉｃｅｓ
　−　Ｓｙｎｃ　Ｐｏｉｎｔ　Ｖｅｒｂｓ”に記載のタ
イプのものでよい。本節で述べたログ名交換は、交換の
実行、制御および最適化のための処理を対象とするので
あって、交換用の体系的プロトコルを対象としてはいな
い。

【０１５４】ログ名交換は、回復ファシリティと、共用
ファイルやデータベースなどの保護された資源の資源マ
ネジャとの間でも必要である。同一のシステム内で会話
が行われる時（会話が共通の同期点ログを共用するので
）ログ名交換が不要である、保護された会話とは違って
、資源マネジャはそれ自体の同期点ログを維持するので
、参加する資源マネジャが開始側のアプリケーションと
同一のシステム内にある場合であっても、それらの資源
マネジャにはログ名交換が必要である。上記のＳｙｓｔ
ｅｍ　Ｎｅｔｗｏｒｋ　Ａｒｃｈｉｔｅｃｔｕｒｅ　Ｌ
Ｕ６．２に記載の保護された会話とログ名交換を確立す
るための通信プロトコルが使用できる、保護された会話
とは違って、保護された資源は、これらの機能のために
、保護されない会話と専用のメッセージ・プロトコルを
使用する。また、保護された資源では、通信ファシリテ
ィを代行受信機能として用いることによって資源マネジ
ャに対する初期の通信を集中的に代行受信することが、
あらゆる場合に実用的なわけではない。これらの通信が
必ずしも通信ファシリティを介して進行するわけではな
いからである。この１例が、アプリケーション環境５２
Ａと同一のシステム５０Ａ内にある資源マネジャ６３Ａ
（図２）と、その資源を使用するアプリケーション５６
Ａの場合である。この状況では、通信ファシリティを通
過するのに資源との会話は不要であるが、その代わりに
会話マネジャ５３Ａまたは他のローカルなファシリティ
を介した会話をサポートする。もう１つの理由は、資源
マネジャがその資源のユーザとの会話の方法を完全に変
更する必要なしにＳｙｓｔｅｍ　Ｎｅｔｗｏｒｋ　Ａｒ
ｃｈｉｔｅｃｔｕｒｅ　ＬＵ　６．２の通信プロトコル
に適合できるように、資源マネジャのサポートに柔軟性
を与えることである。同期点障害からの自動的な回復処
理には、上述の保護された会話の場合と同様に、様々な
参加者のログの名前がその同期点が始まる前と同一であ
ることが必要である。

【０１５５】図２３は、保護された資源のマネジャに関
するログ名交換を示す図である。この実施例では、シス
テム５０Ａは、アプリケーション環境５２Ａ、関連する
資源アダプタ６２Ａ、回復ファシリティ７０Ａおよび共
通の資源回復のログ７２Ａを含む。資源マネジャはロー
カルでもリモートでもよいが、この図はローカルの場合
である。以下で詳細に説明するように、リモート資源マ
ネジャの場合の処理は、システム間通信の完了に通信フ
ァシリティが使用される点を除いて、基本的に同一であ
る。ローカルであれリモートであれ、保護された会話は
、通信には必ず通信ファシリティを使用して、同期点以
前の同意のためのログ名交換を開始するための共通の代
行受信点を提供するのに対して、資源マネジャは、図の
ように、ローカルの場合には通信ファシリティの使用を
回避することができ、同期点以前のログ名交換を開始す
るための上記の集中的代行受信点はない。

【０１５６】ログ８００Ａ内のログ名ログ８００Ａ２は
、資源マネジャ６３Ａと関連づけられており、開始側の
回復ファシリティ７０Ａのログ７２Ａの名前を記憶する
。また、ログ８００Ａ内の同期点ログ８００Ａ１は、資
源マネジャ６３Ａと関連づけられており、同期点手順に
おける、その保護された資源の状態を記憶する。以下で
詳細に説明するように、図２３は、同期点マネジャと参
加する資源マネジャの間での適時のログ名交換と、ログ
７２Ａおよび８００Ａの一方または両方の再初期設定を
強制する障害によってもたらされたログ名の変更を認識
する能力とを保証するのに必要な、不可欠の要素を示す
図である。アプリケーション５６Ａが、資源アダプタ６
２Ａを介して資源マネジャ６３Ａに要求を送った時（図
２６のステップ２２１）、資源アダプタ６２Ａは、同期
点マネジャ６０Ａを呼び出して、下記のものを要求する
（ステップ２２２）。 １．回復ファシリティのログ７２Ａのログ名。 ２．資源マネジャ６３Ａによる初期のログ名交換のため
に回復ファシリティ７０Ａとの会話を確立するのに必要
な、回復ファシリティ７０Ａの資源識別子ｌｏｇ＿ｎａ
ｍｅ＿ｌｏｇ。この識別子は、回復ファシリティ７０Ａ
を一義的に識別し、また回復ファシリティ７０Ａが、入
りログ名交換会話を、以下で説明するように、接続のた
めに資源識別子ｓｙｎｃ＿ｐｏｉｎｔ＿ｌｏｇを使用す
る同期点マネジャの会話などの他の会話から区別できる
ようにする。その後、同期点マネジャ６０Ａは、資源識
別子ｓｙｎｃ＿ｐｏｉｎｔ＿ｌｏｇを使用して、ローカ
ル回復ファシリティ７０Ａとの会話を確立する（図２６
のステップ２２３）。

【０１５７】資源識別子は、システム内の資源を識別す
るのに使用され、より具体的には、そのシステム内の現
在の実行環境内の資源のマネジャへの会話を完了するた
めに使用される。ある資源のマネジャは、その初期設定
時に、システム制御プログラム・ファシリティを使って
、資源をシステムに対して識別する。システム制御プロ
グラムは、強制的にこれらの資源識別子を一義的なもの
にする。図２の資源マネジャ６３に加えて、他のファシ
リティも資源マネジャとして活動できる。その１例が回
復ファシリティ７０であり、この回復ファシリティ７０
のログは、回復ファシリティ７０がその資源識別子を有
する資源であると見なされる。資源には４つのタイプが
あり、そのそれぞれが、資源識別子のタイプによって識
別される。これらのうちの第１のものは、基本的に総称
的であり、どんな資源も含むように拡張することができ
る。その他のものは、明確に資源回復用に定義されてい
る。 １．資源識別子ｏｂｊｅｃｔによって識別される、ｏｂ
ｊｅｃｔ（オブジェクト）資源。これは資源マネジャ６
３によって管理されるオブジェクト７８の集合である。 これは、総称的資源マネジャとその資源の場合であり、
この資源は、データ・ファイル、待ち行列、記憶装置ま
たはアプリケーションからなる集合を含むあらゆる資源
に拡張することができる。このタイプの資源識別子は、
その資源のマネジャ６３の所有する資源を、たとえばフ
ァイル・オープン、アプリケーションの起動など何らか
の形で使用するために、資源マネジャとの会話を確立す
るのに使用される。 ２．資源識別子ｏｂｊｅｃｔ＿ｒｅｃｏｖｅｒｙによっ
て識別されるｏｂｊｅｃｔ＿ｒｅｃｏｖｅｒｙ（オブジ
ェクト回復）資源。これは、資源マネジャのログ８００
であり、障害を発生した同期点手順から回復する際の回
復ファシリティ７０との協力の手順をサポートする。こ
の識別子は、障害を発生した同期点から回復する時点で
、その資源のマネジャ６３との会話を確立して、自動的
回復の一部としてログ名を交換し、その同期点を完了す
るために、回復ファシリティ７０が使用する。 ３．資源識別子ｓｙｎｃ＿ｐｏｉｎｔ＿ｌｏｇによって
識別されるｓｙｎｃ＿ｐｏｉｎｔ＿ｌｏｇ（同期点ログ
）資源。これは回復ファシリティ７０Ａによって管理さ
れるログ７２Ａ（図１９および図２３）と、ログ７２Ａ
の保守をサポートする１組の手順である。この識別子は
、同期点の状況に関するログ情報を提供するために、同
期点マネジャ６０（図２）が、その回復ファシリティ７
０との会話を確立するのに使用する。 ４．資源識別子ｌｏｇ＿ｎａｍｅ＿ｌｏｇによって識別
されるｌｏｇ＿ｎａｍｅ＿ｌｏｇ（ログ名ログ）資源。 これは、回復ファシリティ７０Ａによって管理されるロ
グ名ログ７２Ａ２（図２３）と、ログ名ログ７２Ａ２の
保守をサポートする１組の手順である。この識別子は、
適当な回復ファシリティ７０Ａとの会話を確立して、そ
の回復ファシリティ７０Ａとログ名を交換するために、
資源マネジャ６３Ａが使用する。

【０１５８】回復ファシリティ７０Ａとの接続を確立し
た後に、同期点マネジャ６０Ａは、資源アダプタ６２Ａ
が要求した回復情報を得る。この回復情報は、同期点マ
ネジャ６０Ａによって資源アダプタ６２Ａに戻され（図
２６のステップ２２４）、要求を行っている他の資源ア
ダプタにを解放するために、同期点マネジャ６０Ａがこ
れを保持する。次に、資源アダプタ６２Ａ（図２３）は
、同期点マネジャ６０Ａ（図２３）に、下記の同期点回
復情報をも提供する（図２６のステップ２２５）。 １．同期点中に障害が発生した場合に、資源マネジャ６
３Ａに接続するために回復ファシリティ７０Ａ（図２３
）が使用することのできる、資源識別子ｏｂｊｅｃｔ＿
ｒｅｃｏｖｅｒｙ。この資源識別子ｏｂｊｅｃｔ＿ｒｅ
ｃｏｖｅｒｙを使用すると、資源マネジャは、それぞれ
その処理に異なるプログラムを必要とする、資源アダプ
タ６２Ａからの入り会話と回復ファシリティ７０Ａから
の入り会話を区別できるようになる。全資源マネジャ用
の標準のｏｂｊｅｃｔ＿ｒｅｃｏｖｅｒｙ資源識別子を
確立するのではなくて、資源アダプタ６２Ａを介して資
源マネジャ６３Ａにそれ自体の資源識別子ｏｂｊｅｃｔ
＿ｒｅｃｏｖｅｒｙを提供する能力を与えることによっ
て、回復ファシリティ７０Ａは、この資源マネジャ６３
Ａまたは他のいずれかの資源マネジャの使用する他の資
源識別子との衝突を回避して、すべての資源マネジャが
同期点処理に参加するための、一般化された非破壊的な
インタフェースを維持する。 ２．同期点障害が存在する時、その同期点に参加する資
源マネジャ６３Ａを識別し、ログ名ログ７２Ａ２のそれ
用のエントリを見つけるために、回復ファシリティ７０
Ａが使用できる資源識別子ｏｂｊｅｃｔ。この識別子は
、同期点の管理、同期点障害の場合の同期点のロギング
、および障害を発生した同期点からの回復のために、資
源マネジャを一義的に識別する。

【０１５９】上述の資源７８Ａの使用を求めるアプリケ
ーション５６Ａの最初の要求に従って、資源アダプタ６
２Ａは、それ自体の資源識別子ｏｂｊｅｃｔを使用して
、資源マネジャ６３Ａへの会話を初期設定し、回復ファ
シリティ７０Ａの資源識別子ｌｏｇ＿ｎａｍｅ＿ｌｏｇ
と、同期点マネジャから取得したログ７２Ａの現在の名
前とを含む、回復情報を渡す（図２６のステップ２２６
）。

【０１６０】図２３では、資源回復に責任を負う回復フ
ァシリティ７０Ａが１つだけ示されているが、複数のシ
ステム内にあるそれぞれそれ自体の回復ファシリティを
備えた複数のアプリケーションが資源を使用することが
あるので、単一の資源マネジャで複数の回復ファシリテ
ィを扱うことができる。これが図３３に示されている。 図３３において、資源マネジャ６３Ｅは、システム５０
Ａ内のアプリケーション５２Ａとシステム５０Ｄ内のア
プリケーション５２Ｄの両方によって使用され、したが
って２つの回復ファシリティ７０Ａおよび７０Ｄからの
ログ名情報を必要とする。

【０１６１】障害を発生した同期点の回復をサポートす
るために、資源マネジャ６３Ａは、ログ名ログ８００Ａ
２（図２３）に、各回復ファシリティのログ７２の名前
用のエントリを必要とする。これらの各ログ名はそれぞ
れ、１つまたは複数のアプリケーション５６と同期点マ
ネジャ６０を介して資源を使用するシステム５０の１つ
を表す。参加する資源マネジャ６３Ａ用のログ名ログ８
００Ａ２（図２３）は、関連する回復ファシリティ７０
のそれぞれについて、下記の情報を含む。 １．関連する各回復ファシリティ７０（図２３の場合は
回復ファシリティ７０Ａ）を識別する資源識別子ｌｏｇ
＿ｎａｍｅ＿ｌｏｇ。 ２．回復ファシリティ７０のログ名（図２３の場合、ロ
グ７２Ａの名前）。 ３．ログ名が成功裡に交換済みであることを示すｅｘｃ
ｈａｎｇｅ＿ｄｏｎｅ（交換終了）フラグ。ｅｘｃｈａ
ｎｇｅ＿ｄｏｎｅフラグは、論理的にはログ名ログ８０
０Ａ２（図２３）の一部であるにもかかわらず、それに
関連する資源マネジャが初期設定されるごとに論理的に
リセットされるので、これを持久記憶装置に書き込む必
要はない。このフラグの目的は、特定の回復ファシリテ
ィ７０Ａのあるシステム５０Ａ内で動作中の資源アダプ
タ６２Ａからの最初の会話を除き、その回復ファシリテ
ィ７０Ａに関するログ名交換を避けることである。１つ
のシステム内に、すべてが同一の回復ファシリティのサ
ービスを受け、それぞれが同一のまたは異なる資源マネ
ジャとの会話を有する資源アダプタを備える、多数のア
プリケーション環境が存在することがある。資源マネジ
ャがログ名交換を開始する必要があるのは、同一の回復
ファシリティに関連する資源アダプタの１つとの会話の
最初のインスタンスの際だけである。フラグｅｘｃｈａ
ｎｇｅ＿ｄｏｎｅがセットされると、それ以後の交換が
防止される。

【０１６２】図２６の残りの部分には、ログ名交換を開
始する時を決定するために、資源マネジャ６３Ａ（図２
３）が実行するアルゴリズムが示されている。資源識別
子ｏｂｊｅｃｔを最初に受け取った時（ステップ２２６
）、資源マネジャ６３Ａは、ログ名ログ８００Ａ２を検
索して、資源アダプタ６２Ａ（図２３）から渡された回
復情報に含まれる資源識別子ｌｏｇ＿ｎａｍｅ＿ｌｏｇ
によって識別される回復ファシリティ７０Ａ用のエント
リがあるか否かを判定する（図２６のステップ２３０）
。この資源マネジャは、ログ名ログ８００Ａ２（図２３
）を検索するのに、資源アダプタから受け取った資源識
別子ｌｏｇ＿ｎａｍｅ＿ｌｏｇを使用する。エントリが
ない場合、資源マネジャ６３Ａはログ名交換を開始する
（図２６のステップ２３２）。ステップ２３０で、回復
ファシリティ７０Ａ（図２３）用のエントリが見つかっ
た場合、資源マネジャ６３Ａは、フラグｅｘｃｈａｎｇ
ｅ＿ｄｏｎｅがセットされているか否かを判定する（図
２６のステップ２３４）。フラグｅｘｃｈａｎｇｅ＿ｄ
ｏｎｅは、ログ名交換が成功した時にセットされ、資源
マネジャが異常終了するかまたは正常に遮断されるまで
、セットされたままである。回復ファシリティとの会話
を開始するのに失敗したために、資源マネジャがログ名
を交換できない場合には、資源マネジャは、その資源ア
ダプタによって開始された会話を打ち切る。フラグｅｘ
ｃｈａｎｇｅ＿ｄｏｎｅがセットされていない場合、資
源マネジャ６３Ａ（図２３）は、ステップ２３２（図２
６）でログ名交換を開始する。しかし、フラグｅｘｃｈ
ａｎｇｅ＿ｄｏｎｅがセットされている場合には、資源
マネジャ６３Ａ（図２３）は、資源アダプタ６２Ａから
送られたログ名を、前記のエントリ内のログ名と比較す
る（図２６のステップ２３６）。これら２つのログ名が
同一である場合には、資源マネジャはログ名交換を開始
しないが（図２６のステップ２４２）、異なる場合には
、資源マネジャ６３Ａ（図２３）は、ステップ２３２（
図２６）でログ名交換を開始する。前述のアルゴリズム
は、資源マネジャがいずれかの回復ファシリティに関連
する資源アダプタと初めて通信する際に、その回復ファ
シリティに関してログ名が交換されることを保証する。 また、このアルゴリズムは、その後に回復ファシリティ
７０Ａ（図２３）用のログ名が変更される時、ログ名が
交換されることを保証する。後者の場合、資源マネジャ
６３Ａが資源アダプタから回復ファシリティのログ７２
Ａの新しい名前を得る場合であってもこのログ名交換は
必要である。というのは、回復ファシリティ７０Ａのロ
グ名ログを資源マネジャ６３Ａのログ名ログと同期させ
なければならず、回復ファシリティ７０Ａに資源マネジ
ャのログ８００Ａのログ名を与えることが必要だからで
ある。

【０１６３】ステップ２３２（図２６）の、資源マネジ
ャ６３Ａ（図２３）と回復ファシリティ７０Ａの間での
ログ名交換は、図２７にさらに詳しく示されており、以
下のステップを含む（ログ７２Ａがそのログであると仮
定する） １．図２７のステップ２４３。資源マネジャ６３Ａ（図
２３）が、資源アダプタ６２Ａから得た資源識別子ｌｏ
ｇ＿ｎａｍｅ＿ｌｏｇを使用して、回復ファシリティ７
０Ａとの会話２５０を開始する。 ２．図２７のステップ２４３。資源マネジャ６３Ａ（図
２３）が、回復ファシリティ７０Ａに資源マネジャ６３
Ａを一義的に識別するｏｂｊｅｃｔ資源識別子を送る。 ３．図２７のステップ２４４。資源マネジャ６３Ａ（図
２３）が、回復ファシリティ７０Ａにログ８００Ａのロ
グ名を送る。 ４．図２７のステップ２４５。回復ファシリティ７０Ａ
（図２３）が、資源マネジャ８００Ａのログ名で、ログ
名ログ７２Ａ２を更新する。 ５．図２７のステップ２４６。回復ファシリティ７０Ａ
（図２３）が、資源マネジャ６３Ａに応答を戻して、ロ
グ７２Ａのログ名を与える。 ６．図２７のステップ２４７。資源マネジャ６３Ａ（図
２３）が、ログ７２Ａの名前でログ名ログ８００Ａ２を
更新する。 ７．図２７のステップ２４８。資源マネジャ６３Ａ（図
２３）が、ログ名ログ８００Ａ２内のフラグｅｘｃｈａ
ｎｇｅ＿ｄｏｎｅをセットする。

【０１６４】アプリケーション５６Ａ（図２３）が、同
期点マネジャ６０Ａから同期点を要求する時、同期点マ
ネジャ６０Ａは、上記の資源識別子ｏｂｊｅｃｔ＿ｒｅ
ｃｏｖｅｒｙと資源識別子ｏｂｊｅｃｔを回復ファシリ
ティ７０Ａに送り、そこではこれらの識別子がその同期
点処理の状態を記述する情報と共に同期点ログ７２Ａ１
に記憶される。同期点中に障害が発生した場合、回復フ
ァシリティ７０Ａが活動化されて、同期点手順を完了す
るのに必要な動作を行う。障害を発生している同期点に
資源が参加していた場合、関連する回復ファシリティの
同期点ログのエントリ内の回復情報を使用して、回復を
達成するためにそれらの資源とコンタクトすることが可
能になる。たとえば、アプリケーション５６Ａが２段階
コミット動作中にダウンした場合、回復ファシリティ７
０Ａが、活動化された後に、資源マネジャ６３Ａとログ
名を交換する。この第２の交換で、この同期点の開始以
降にログ名が変化していないことが示された場合には、
回復ファシリティ７０Ａは、この同期点の回復を続行で
きることを知る。この交換でログ名が一致しない場合は
、自動的回復に必要なログ情報が失われており、したが
って自動的回復を試みてはならないことを示している。 回復ファシリティ７０Ａは、第２のログ名交換を開始し
、資源マネジャ６３Ａに、この障害前の資源マネジャ６
３Ａの状態または段階がどうであったかを尋ねる。上述
したように、最初のログ名交換が資源マネジャによって
開始されるのに対して、障害発生後に必要なログ名交換
は、下記のように回復ファシリティ７０Ａによって開始
される。 １．障害を発生している同期点に関連する同期点ログ７
２Ａ１内に回復情報がある各資源について、回復ファシ
リティ７０Ａは、同期点ログ７２Ａ１のエントリ内で見
つかった資源識別子ｏｂｊｅｃｔを、ログ名ログ７２Ａ
２のエントリに適用する検索の引数として使用し、その
資源のログ名を得ることによって、その資源のログ名ロ
グのエントリを識別する。これを図２５に示す。 ２．回復ファシリティは、この同期点ログのエントリ内
で見つかった資源識別子ｏｂｊｅｃｔ＿ｒｅｃｏｖｅｒ
ｙを使用して、資源マネジャ６３Ａへの会話２５２（図
２３）を確立する。 ３．回復ファシリティ７０Ａは、それ自体のログ名、資
源識別子ｌｏｇ＿ｎａｍｅ＿ｌｏｇ（回復ファシリティ
７０Ａの一義的識別子）、およびこの資源のログ名を、
会話２５２を使って資源マネジャ６３Ａに送る。

【０１６５】これに応答して、資源マネジャ６３Ａは以
下のステップを実行する。 １．資源マネジャ６３Ａは、回復ファシリティ７０Ａか
らの会話が、資源識別子ｏｂｊｅｃｔ＿ｒｅｃｏｖｅｒ
ｙを含んでいるので、その会話が同期点回復の目的を意
図したものであることを認識する。 ２．資源マネジャ６３Ａは、回復ファシリティ７０Ａか
ら送られた資源識別子ｌｏｇ＿ｎａｍｅ＿ｌｏｇを使用
して、ログ名ログ８００Ａ２内の、回復ファシリティ７
０Ａに関連するエントリを検査する。 ３．資源マネジャ６３Ａは、回復ファシリティ７０Ａか
ら送られた資源のログ名が、それ自体のログ８００Ａの
ログ名と対応することを確認する。 ４．資源マネジャ６３Ａは、ログ名ログ８００Ａ２内で
回復ファシリティ７０Ａに関連するエントリを見つけら
れない場合、会話２５２上で回復ファシリティ７０Ａに
エラー信号を戻す。 ５．資源マネジャ６３Ａは、上記の検査ステップのいず
れかが失敗した場合、会話２５２上で回復ファシリティ
７０Ａにエラー信号を送る。

【０１６６】回復の始めにログ名交換でエラー状態が検
出されると、回復ファシリティ７０Ａの自動的同期点障
害回復手順の継続が阻止される。このようなエラー状態
は、１つまたは複数の参加するログの障害が、この同期
点障害と同時に発生したことを示す。あるログの喪失は
、そのログ内のすべての情報が失われ、新規のログ名が
割り当てられることを意味する。このような障害には、
障害を発生している同期点を解決するため、手動の介入
およびヒューリスティックな判断が必要である。このよ
うなエラー状態を検出することが、同期点障害の後に実
施されるログ名交換処理の主目的である。

【０１６７】図２３に示されたローカル資源マネジャ６
３Ａの場合と同様に、図２４には、システム５０Ｄの資
源マネジャ６３Ｅが、資源マネジャ６３Ｅによって管理
される資源を使用するシステム５０Ａのアプリケーショ
ン環境５２Ａおよびアプリケーション５６Ａに対してリ
モートである場合の、ログ名交換が示されている。リモ
ート資源マネジャ６３Ｅとローカルなアプリケーション
５６Ａおよび回復ファシリティ７０Ａの間の通信は、シ
ステム制御プログラムによって提供されるシステム間通
信サポートではなくて、システム間通信ファシリティ５
７Ａおよび５７Ｄを介して行われる。同期点マネジャ６
０Ａは、回復ファシリティ７０Ａを使用して、同期点と
、障害を発生している同期点からの回復に必要なログ名
ログ７２Ａとを管理する。資源マネジャ６３Ｅは、それ
自体の資源マネジャ・ログ８００Ｅを維持する。同期点
以前の同意の時点と、障害を発生している同期点を回復
するための再同期化の時点で使用される通信経路は、資
源マネジャ６３Ｅとシステム５０Ａの回復ファシリティ
７０Ａの間にある。システム５０Ｄの回復ファシリティ
７０Ｄ（図示せず）は、この場合には使用されない。 というのは、起点側の同期点マネジャ、アプリケーショ
ンおよび関連する回復ファシリティが、システム５０Ｄ
に対してローカルではなく、リモートなシステム５０Ａ
内にあるからである。資源マネジャがローカルの場合と
リモートの場合でのログ名交換処理の唯一の相違点は、
リモート資源マネジャ６３Ｅと資源アダプタ６２Ａまた
は回復ファシリティ７０Ａの間での通信が、ローカル・
システム制御プログラムのシステム間通信サービスでは
なく、通信ファシリティ５７Ａまたは５７Ｄを介して行
われる点である。それ以外は、このログ名交換の処理は
、図２３を参照しながら説明した上記の処理と同一であ
る。通信ファシリティ５７Ａおよび５７Ｄは、リモート
・ログとログ名を交換する時期の決定には参加しない。 すなわち、これらの通信ファシリティは、図１９の保護
された会話の場合のような、会話の代行受信は行わない
。

【０１６８】分散式アプリケーション用の未完了の同期
点のための回復ファシリティ図２に示した回復ファシリ
ティ７０Ａは、障害に出会った同期点を完了させるのに
使用する。ほとんどの場合、回復（再同期化）は、回復
ファシリティ７０Ａによって自動的に実行される。回復
ファシリティ７０Ａは、障害を認識した後に、ローカル
同期点マネジャ６０Ａの代理として働いて、その同期点
の参加者への代替のまたは再取得された通信を用いて、
その同期点を正常に完了させる。障害には、障害を発生
している同期点マネジャ６０Ａ、同期点マネジャ６０Ａ
とその回復ファシリティ７０Ａの間の通信の障害、アプ
リケーション・パートナ５６Ｄまたは資源マネジャ６３
の障害またはそれらとの通信の障害、および回復ファシ
リティ７０Ａの障害が含まれる。

【０１６９】たとえば、この体系的システム間通信標準
は、ＩＢＭコーポレーション刊行物の“Ｓｙｓｔｅｍ　
Ｎｅｔｗｏｒｋ　Ａｒｃｈｉｔｅｃｔｕｒｅ　ＬＵ　６
．２　Ｒｅｆｅｒｅｎｃｅ：　Ｐｅｅｒ　Ｐｒｏｔｏｃ
ｏｌｓ，　ＳＣ３１−６８０８，　Ｃｈａｐｔｅｒ　５
．３　Ｐｒｅｓｅｎｔａｔｉｏｎ　Ｓｅｒｖｉｃｅｓ　
−　Ｓｙｎｃ　Ｐｏｉｎｔ　ｖｅｒｂｓ”に記載のタイ
プのものとすることができる。

【０１７０】回復ファシリティ７０Ａは、システム５０
内の、アプリケーション実行環境５２Ａ、５２Ｂおよび
５２Ｃと、参加する同期点アプリケーションにサービス
し、同期点回復のために、共通の回復ファシリティ・ロ
グ７２Ａを使用する。通常、複数のシステムが通信ファ
シリティ５７を介して互いに相互接続されており、した
がって、複数の回復ファシリティ７０を回復処理に使用
することができる。

【０１７１】図３３は、システム５０Ａ、５０Ｄおよび
５０Ｆに関係する、様々な回復状況を示す図である。各
アプリケーション実行環境５２Ａ、５２Ｂ、５２Ｄ、５
２Ｆ、５２Ｇは、資源回復を調整するためにそれぞれ同
期点マネジャ６０Ａ、６０Ｂ、６０Ｄ、６０Ｆ、６０Ｇ
（図示せず）を使用するアプリケーション５６Ａ、５６
Ｂ、５６Ｄ、５６Ｆ、５６Ｇ（図示せず）を実行する。 各同期点マネジャは、そのシステム内の回復ファシリテ
ィを使用して、同期点と、障害を発生している同期点か
らの回復に必要なログ名ログとを管理する。たとえば、
アプリケーション環境５２Ａおよび５２Ｂ内の同期点マ
ネジャは、回復ファシリティ７０Ａを使用して、同期点
回復情報を回復ファシリティ・ログ７２Ａに書き込む。 資源マネジャ６３Ａ、６３Ｂ、６３Ｄ、６３Ｅ、６３Ｆ
、６３Ｇは、それぞれ、それ自体の同期点と、ログ名ロ
グ８００Ａ、８００Ｂ、８００Ｄ、８００Ｅ、８００Ｆ
、８００Ｇとを管理する。この例では、同期点の範囲が
矢印付きの実線で示されている。同期点はいずれの参加
者によって開始されることもでき、同期点の範囲は動的
であるが、図を簡単にするためにこの図は静的なもので
ある。図の静的な場合では、同期点は、アプリケーショ
ン環境５２Ｂから５２Ｄへさらに５２Ｆへと、関連する
同期点マネジャおよび保護会話アダプタ（図示せず）を
介し、実線の通信経路８０１および８０２を経て流れ、
またアプリケーション環境５２Ａ、５２Ｂ、５２Ｄ、５
２Ｆ、５２Ｇから、関連する同期点マネジャおよび保護
会話アダプタを介し、それぞれ実線の通信経路８０３Ａ
−１、８０３Ａ−２、８０３Ｂ、８０３Ｄ、８０３Ｅ、
８０３Ｆ、８０３Ｇを経て、資源マネジャ６３Ａ、６３
Ｂ、６３Ｄ、６３Ｅ、６３Ｆ、６３Ｇへと流れる。

【０１７２】３つの同期点の範囲が、図３３に含まれて
いる。第１の範囲には、同期点マネジャ６０Ａを含む単
一のアプリケーション環境５２Ａが含まれ、２つの資源
マネジャ６３Ａおよび６３Ｅを使用する。第２の同期点
の範囲には、３つのアプリケーション環境５２Ｂ、５２
Ｄおよび５２Ｆが含まれ、これらはそれぞれ、様々な参
加資源マネジャ（５２Ｂには６３Ｂ、５２Ｄには６３Ｄ
と６３Ｅ、５２Ｆには６３Ｆと６３Ｇ）を含む。これを
図３４の同期点ツリーに示す。第３の同期点の範囲には
、アプリケーション環境５２Ｇと資源マネジャ６３Ｇが
含まれる。

【０１７３】図３３中の破線は、同期点以前の同意の時
点と、障害を発生している同期点の回復のための再同期
化の時点で使用される通信経路を示す（前記の「保護さ
れた資源を回復するためのログ名の交換」を参照された
い）。資源マネジャでは、同期点以前の同意および再同
期化の経路は、その資源マネジャと、起点側アプリケー
ション環境（すなわち、その資源マネジャが管理する資
源を使用、たとえば更新する側）のシステムの回復ファ
シリティの間にあり、たとえば、アプリケーション環境
５２Ａが起点側である（資源マネジャ６３Ｅの管理する
資源を使用する）時は、経路８０４Ａ−２を介して資源
マネジャ６３Ｅと回復ファシリティ７０Ａの間にあり、
アプリケーション環境５２Ｄが起点側である時は、経路
８０４Ｄを介して資源マネジャ６３Ｅと回復ファシリテ
ィ７０Ｄの間にある。

【０１７４】同期点は、その同期点の参加者中をカスケ
ード式に伝播して、図３４に示された同期点ツリーを形
成する。アプリケーション５６Ｂ、５６Ｄおよび５６Ｆ
は、それぞれ保護会話アダプタ６４Ｂ、６４Ｄおよび６
４Ｆ（図示せず）によって管理される保護された会話８
０１および８０２を介して、互いに通信する。アプリケ
ーション５６Ｂ、５６Ｄおよび５６Ｆは、それぞれ資源
アダプタ６２Ｂ、６２Ｄ、６２Ｆ（図示せず）を使用し
、これらの資源アダプタは、それぞれ保護されない会話
８０３Ｂ、８０３Ｄ、８０３Ｅ、８０３Ｇ、８０３Ｆを
使用して、資源マネジャ６３Ｂ、６３Ｄ、６３Ｅ、６３
Ｇ、６３Ｆと通信する。このツリーには、同期点開始側
のアプリケーション５６Ｂとそれに参加する資源マネジ
ャ６３Ｂおよび分散アプリケーション５６Ｄ、分散アプ
リケーション５６Ｄに参加する資源マネジャ６３Ｅ、６
３Ｄおよび分散アプリケーション５６Ｆ、分散アプリケ
ーション５６Ｆに参加する資源マネジャ６３Ｇおよび６
３Ｆが含まれる。

【０１７５】同期点回復のために、１つの同期点ログ、
たとえば７２Ｄが、同期点マネジャ６０Ｄによって（図
示されない回復ファシリティ７０Ｄを介して）、同期点
ツリー内でその直前にある環境５２Ｂ内のアプリケーシ
ョン５６Ｂと、直接参加者であることが同期点マネジャ
６０Ｄにわかっている、資源マネジャ６３Ｅ、６３Ｄお
よびアプリケーション環境５２Ｆ内のアプリケーション
５６Ｆとに関する情報と共に維持されるが、その他の同
期点参加者６３Ｂ、６３Ｇまたは６３Ｆに関しては、同
期点ログ７２Ｄ内に何も維持されない。

【０１７６】図３５は、同期点回復の主要要素の高水準
流れ図２９８である。この図は、回復ファシリティ７０
の２つの部分、同期点以前の回復同意（ステップ２９９
、３００、３０１および３０２）と同期点障害からの回
復（ステップ３０３ないし３０６）を表している。

【０１７７】同期点が発生する前に、その同期点の参加
者の間で、その同期点に関連するログの一致と、それら
のそれぞれのログ７２の現在のレベルとに関する同意が
なければならない（前述の「保護された資源を回復する
ためのログ名の交換」を参照されたい）。この同期点以
前の回復同意は、同期点障害の場合にその同期点障害か
ら回復するのに使用されるログが、その同期点が開始さ
れる前と同一のものであり、同一のレベルであることを
保証するのに重要である。同期点以前の回復同意の時点
（上述のログ名の交換）から同期点障害の発生までの間
に、１つまたは複数の参加者のログに障害があって、新
規のログを用いて開始しなければならない場合には、こ
の障害を発生したログに関連する自動的回復手順は失敗
する。

【０１７８】同期点の参加者の間でログ名を交換し、ロ
グ名をログ７２に記録すると、同期点障害の場合に、こ
の情報を妥当性検査に使用できるようになる。これらの
交換は、特定の経路上で通信が初めて確立されるのを検
出した時に開始される。通信はローカルにもリモートに
も開始され得るので、回復ファシリティ７０は、出ログ
名交換が必要なローカル検出（ステップ２９９および３
００）と、入りログ名交換が必要なリモート検出（ステ
ップ３０１および３０２）の両方をサポートする。

【０１７９】回復ファシリティ７０は、同期点障害から
の自動的回復を実現し、これには、回復手順を開始させ
る様々な事象が発生するステップ３０３、回復手順の初
期設定ステップ３０４、回復ドライバ処理と称する実際
の回復ステップ３０５、および回復手順終了ステップ３
０６が含まれる。回復ファシリティ７０は、複数の同期
点障害事象の非同期的処理を含む。

【０１８０】図３６は、この回復手順の「同期点障害か
らの回復」の部分（ステップ３０３ないし３０６）をよ
り詳細に示す図である。下記の５種類の事象（ステップ
３０３）が、この回復手順を開始させる。 （１）同期点マネジャ６０が、その１つまたは複数の同
期点参加者（たとえば、資源マネジャ６３）との通信障
害に出会った時に同期点マネジャから要求を受け取った
結果として発生する、同期点要求事象３１１。この同期
点マネジャ６０は、この同期点の活動をロギングするの
に使用するのと同一の経路を使って回復ファシリティ７
０に要求を送ることによって、明示的に回復手順を開始
する。この要求は、対応する同期点識別子を使った、障
害を発生している参加者の記述を含む。指定された各同
期点識別子ごとに１つの事象が発生する。 （２）同期点開始側を表す回復処理が、その参加者の１
つに回復要求を送る時に、ターゲット回復ファシリティ
７０（障害を発生している同期点の参加者を表す回復フ
ァシリティ）で発生する、回復要求事象３１２。 （３）アプリケーション環境から回復ファシリティ７０
にログ情報を送るのに使用される経路上の接続が断たれ
た時に、その回復ファシリティ７０内で発生する、通信
障害事象３１３。障害を発生した経路を使用していたア
プリケーション環境に関して進行中の各同期点ごとに１
つの事象が発生する。 （４）回復ファシリティの終了に障害があり、その結果
、同期点のロギングを行えない時に発生する、回復ファ
シリティ障害事象３１４。障害の時点で完了していない
各同期点ごとに１つの事象が発生し、これらの事象は、
回復ファシリティが再始動される時に発生する。 （５）正常な自動的回復手順中に長い遅延または重大な
障害に出会った同期点障害を修復するのに用いられる管
理コマンドの結果として生じる、回復管理要求事象３１
５。この要求は、通常なら自動的回復プロトコルを介し
て入手可能な応答状態情報を、手動で供給する。適当な
応答状態情報は、同期点のログ・レコードを手動で調べ
てオフラインで決定する。適当な応答データ（状態情報
）は、システム管理者が、同期点のログ・レコードを手
動で調べて決定する。

【０１８１】この回復手順が開始される際、ステップ３
０４で、受け取った各回復事象に対する非同期的サブプ
ロセスが開始される。参加ドライバ・サブプロセス（ス
テップ３１７）が、一貫した解決策に関する同意を得る
ために、通信を開始し、障害を発生している同期点の下
流側の各参加者からの応答を受け入れる。この通信では
、参加ドライバを用いて、回復サーバのログ名と、ｃｏ
ｍｍｉｔやｂａｃｋ　ｏｕｔなどの同期点状態とを含む
メッセージを送り、その後、送られた回復サーバのログ
名に対する同意または不同意の指示、参加者のログ名、
およびｃｏｍｍｉｔｔｅｄやｂａｃｋｅｄ　ｏｕｔなど
の同期点状態に対する応答を含む、参加者からの応答を
受け取る。参加ドライバは、このようにして受け取った
各応答メッセージに対して、応答処理ドライバを呼び出
す（ステップ３１８）。応答処理ドライバは、この応答
を分析し、必要なすべての行動と記録を完了する。これ
には、その参加者のログ名をログ７２内に記録されたそ
の参加者のログ名と突き合わせて、その参加者がこの同
期点の開始以来ログ障害に出会っていないことを検査す
ることが必要である。さらに、この同期点応答を回復フ
ァシリティ・ログ７２に記入することも必要である。そ
の後、応答処理ドライバは、参加ドライバにリターンす
る。すべての応答を受け取って処理した後に、開始側応
答ドライバ（ステップ３１９）が呼び出されて、応答を
作成してこの同期点の開始側を代理する回復ファシリテ
ィにそれを送り、当該の場合には、この回復ファシリテ
ィがこの同期点をその同期点の開始側と共に解決できる
ようにする。開始側への応答は、現回復ファシリティが
その参加者から受け取った応答に類似しており、現回復
ファシリティのログ名と、それ自体のすべての同期点参
加者からの結果に基づくｃｏｍｍｉｔｔｅｄやｂａｃｋ
ｅｄ　ｏｕｔなどの応答同期点状態を含む。最後に、回
復終了サブプロセス（ステップ３０６）が、関係するす
べての処理を終了する。

【０１８２】図３７は、この回復手順に必要な制御構造
を示す図である。回復制御構造３４０は、特定の回復事
象に関する情報を保持し、その事象の現処理の間ずっと
存在する。制御構造３４０は、関連する同期点に対する
すべての参加者の回復に共通する情報を保持する。また
、ログ７２内の関連するエントリ３４２へのアンカと、
参加者制御構造３４４のチェーンへのアンカを保持し、
各参加者制御構造３４４は、現在の回復状況とこの回復
参加者の経路識別子を保持する。同期点ログのエントリ
３４２は、ローカルの同期点参加者に共通するヘッダ情
報３４８、ならびに直接開始側と各直接参加者とに関す
る本体情報３５０を有する。最後に、この同期点ログに
関連する回復ファシリティに既知の、各同期点経路に関
する初期ログ名交換情報を保持する、ログ名ログ・エン
トリ３５４がある。

【０１８３】これらのフィールドの目的を、以下の構造
流れによってさらに示す。一部のフィールドは、あらか
じめ説明が必要である。”Ｃｈａｉｎ”（チェーン）フ
ィールドは、同じタイプの構造を相互接続するのに使用
される。

【０１８４】“Ｓｔａｔｅ”（状態）フィールドＳＰＬ
＿ＳＹＮＣＰＯＩＮＴ＿ＳＴＡＴＥは、同期点の全体的
な状態である。同期点が段階２に達すると、この状態に
よって、下流側の参加者を駆動してその同期点を解決す
ることが可能になる。同期点が、障害を発生した時点で
段階１であった場合には、回復要求事象の処理で、開始
側回復ファシリティの指示に従って、この状態を変更す
ることができる。

【０１８５】ＳＰＬ＿ＰＡＲＴＩＣＩＰＡＮＴ＿ＳＴＡ
ＴＥは、応答処理ドライバ３１８によって、参加者から
の応答状態を用いて更新される。

【０１８６】ＲＣＳ＿ＰＡＲＴＩＣＩＰＡＮＴＳ＿ＳＴ
ＡＴＥは、影響を受ける下流側の同期点参加者を駆動す
る目的で、様々な回復事象処理によってセットされる。

【０１８７】ＲＣＳ＿ＩＮＩＴＩＡＴＯＲ＿ＲＥＳＰＯ
ＮＳＥ＿ＳＴＡＴＥは、様々な回復事象処理３１１ない
し３１５によってＲＣＳ＿ＰＡＲＴＩＣＩＰＡＮＴＳ＿
ＳＴＡＴＥと共に初期設定されるが、ある状況の下では
、すなわち、開始側への応答が、ヒューリスティック応
答として知られる単方向性の決定から生じた、参加者か
らの異常かつ予期されない応答を反映するためのもので
ある場合には、応答処理ドライバ３１８によっても更新
される。このフィールドは、開始側に戻される状態を形
成するために開始側応答ドライバ３１９が使用する。

【０１８８】“Ｐａｔｈ　ＩＤ”（経路識別子）フィー
ルドＲＣＳ＿ＰＡＴＨ＿ＩＤは、入り事象に関連する経
路であり、その事象の起点側に応答するのに使用できる
。

【０１８９】ＰＣＳ＿ＰＡＴＨ＿ＩＤは、障害を発生し
た同期点の参加者に関連する経路である。これは、参加
者にとってＳＰＬ＿ＲＥＣＯＶＥＲＹ＿ＰＡＴＨ＿ＩＤ
と同一である。

【０１９０】ＳＰＬ＿ＲＥＣＯＶＥＲＹ＿ＰＡＴＨ＿Ｉ
Ｄは、同期点回復ファシリティに必要な、参加者または
開始側に達する経路である。

【０１９１】ＳＰＬ＿ＳＹＮＣＰＯＩＮＴ＿ＰＡＴＨ＿
ＩＤは、同期点ログ情報を、ローカル回復ファシリティ
の同期点ログに供給するために、アプリケーション実行
環境内の同期点処理が使用する経路である。

【０１９２】“Ｆｌａｇ”（フラグ） ＲＣＳ＿ＲＥＳＰＯＮＤ＿ＴＯ＿ＩＮＩＴＩＡＴＯＲは
、同期点回復ファシリティの直接開始側に対して、応答
を生成すべきであることを示す。ＲＣＳ＿ＲＥＴＵＲＮ
＿ＴＯ＿ＣＡＬＬＥＲは、待機標識（以下で説明する）
を使用する時、同期点回復要求からの同期リターンを制
御するために使用する。ＲＣＳ＿ＥＲＡＳＥ＿ＬＯＧは
、回復管理要求がＰＵＲＧＥ（パージ）オプションを含
んでおり、処理の完了時に同期点ログのエントリを消去
させることを記録するために使用する。 ＳＰＬ＿ＩＮＩＴＩＡＴＯＲは、同期点ログのエントリ
の本体の特定のサブエントリ内の情報が、この同期点の
開始側または参加者に関するものであることを示す。

【０１９３】“Ｍｉｓｃｅｌｌａｎｅｏｕｓ”（雑）フ
ィールドＲＣＳ＿ＦＵＮＣＴＩＯＮ＿ＩＤは、新しいプ
ロセス内で実行するために呼び出すべき機能を決定する
ために、サブプロセス開始サービスが使用する。

【０１９４】ＳＰＬ＿ＳＹＮＣＰＯＩＮＴ＿ＩＤは、同
期点の一義的な識別子であり、同期点ツリー内のノード
である。同期点ログの各エントリは、独自の同期点識別
子を有する。

【０１９５】ＳＰＬ＿ＳＵＳＰＥＮＤＥＤ＿ＰＲＯＣＥ
ＳＳ＿ＩＤは、中断された処理を識別するためにタイマ
待機サービスがセットするもので、この時限待機間隔が
終了した時にリセットされる。これは、特定のプロセス
に対する時限待機を早めに終了させるために、再開サー
ビスを呼び出すのに使用される。

【０１９６】ＰＣＳ＿ＳＴＡＴＵＳは、回復手順の各参
加者との会話の状況を記録するのに使用される。これが
とり得る値は４つあり、ＲＥＳＴＡＲＴ（再始動）、Ｃ
ＯＮＮＥＣＴＥＤ（接続済み）、ＲＥＴＲＹ（再試行）
およびＲＥＳＰＯＮＤＥＤ（応答済み）である。

【０１９７】ＬＬ＿ＬＯＧＮＡＭＥは、同期点参加者の
ログ名である。潜在的な同期点通信に関係する各経路ご
とに１つずつ記録される。

【０１９８】図３８は、ステップ２９９で事象（図３５
の同じステップに対応する）によってトリガされ、回復
ファシリティ７０の活動化中に同期点通信が初めて開始
される時に回復ファシリティ７０によって実行される、
処理ステップ３００を示す流れ図である。この処理では
、ローカル回復ファシリティと、同期点通信のターゲッ
トに関連する回復ファシリティの間でログ名を交換する
ための処理を開始する（ステップ３５９）。

【０１９９】受取サービスが、この処理のための入力デ
ータ（経路識別子）を提供する（ステップ３６１）。ロ
グ名ログは、ログ名の交換に使用される経路に関連する
ログ名を検索するのに使用される（ステップ３６２）。 このログ名交換の際には、予期されるターゲット・ログ
名が、ローカル回復ファシリティのログ名と共に送られ
る。このログ名交換の要求が送られ（ステップ３６３な
いし３６５）、その応答が処理される（ステップ３６６
）。この交換に成功すると、ログ名ログは、新規のまた
は変更されたターゲット・ログ名で更新される。次に回
復ファシリティは、この経路から切断され（ステップ３
６７）、最初の通信サービスを呼び出して、この交換が
成功であったことを記録し、この処理された経路に対す
る将来の交換事象を抑止し、あるいは交換が不成功であ
ったことを記録して、通信の中断の継続を保証し、ログ
名交換の完了を試みる（ステップ３６８）。

【０２００】図３９は、ステップ３０１（図３５の同じ
ステップに対応する）で事象によってトリガされ、入り
ログ名交換要求の到着の結果として起こる、ステップ３
０２の詳細を示す流れ図である。開始（ステップ３７０
）の後に、ログ名と経路識別子を受け取り（ステップ３
７１）、それに応じてログ名ログが更新される（ステッ
プ３７１ないし３７３）。その経路に関連する中断（タ
イマ待機）中の回復処理が存在する場合（ステップ３７
４）、回復ファシリティ７０は、再開サービスを呼び出
して、各回復処理にその処理を再開させる。ログ名交換
応答（ステップ３７４Ａ）は、ローカルのログ名と、受
け取った交換データに対する同意または不同意の指示を
含む。この応答は起点側に送られ（ステップ３７５）、
交換に成功した場合には、最初の通信サービスを呼び出
して（ステップ３７６）、これ以降のその経路でのログ
名交換を抑止する。

【０２０１】図４０は、同期点回復の実行を求める、活
動状態の同期点からの明示的要求事象（図３６のステッ
プ３１１に対応するステップ３１１）に対する手順を示
す流れ図である。これは、アプリケーション環境５２内
で部分的な障害が発生して、同期点からの回復が必要と
なるが、そのアプリケーションまたは同期点は終了させ
る必要のない場合に発生する。アプリケーション環境５
２内の同期点マネジャからの要求は、この同期点識別子
と、障害を発生している同期点を完了するのに使用され
る指示（コミットまたはバックアウト）を提供する。こ
れに加えて、障害を発生した各同期点参加者について、
回復経路識別子が与えられる。必要な処置は、以下で詳
細に説明するように、同期的（待機標識が与えられる）
または非同期的（待機標識が与えられない）に完了する
ことができる。

【０２０２】この要求の到着は、同期点ログを探索して
、一致するＳＰＬ＿ＳＹＮＣＰＯＩＮＴ＿ＩＤをもつエ
ントリを探す（ステップ３８１）ことを必要とする、手
順（ステップ３８０）を開始する事象（ステップ３７９
）である。それが見つかると、その同期点ログのエント
リへのアンカを備える回復制御構造が作成され、この要
求中で渡された指令に合わせてＲＣＳ＿ＰＡＲＴＩＣＩ
ＰＡＮＴＳ＿ＳＴＡＴＥが設定される（ステップ３８２
）。これに加えて、フラグＲＣＳ＿ＲＥＳＰＯＮＤ＿Ｔ
Ｏ＿ＩＮＩＴＩＡＴＯＲをセットすると、この同期点の
開始側を代理する回復ファシリティに応答を送ることが
抑止され、待機標識が渡されている場合には、フラグＲ
ＣＳ＿ＲＥＴＵＲＮ＿ＴＯ＿ＣＡＬＬＥＲがセットされ
、回復処理が完了するまでこの要求に対する応答を遅ら
せる。待機標識がない場合は、回復処理が開始した後に
、開始側要求への応答がある。次に、与えられた経路識
別子で表される各参加者ごとに代理制御構造が作成され
（ステップ３８３）、ＰＣＳ＿ＳＴＡＴＵＳがＲＥＳＴ
ＡＲＴに初期設定される。代理制御構造のチェーンは、
回復制御構造にアンカされる。次に、回復初期設定を呼
び出して（ステップ３８４）、回復制御構造を渡す。こ
の初期設定から戻る時、呼出し側への応答がある（ステ
ップ３８５）。待機標識が使用されていた時は、呼出し
側は完了を知らされる。そうでない場合は、この通知は
、完了、または要求の処理が開始された（後で完了する
）との指示のいずれかである。

【０２０３】図４１は、障害を発生している同期点の直
接開始側を代理する回復ファシリティから回復要求を受
け取ったことによって開始された事象（ステップ３１２
）から生じる手順を示す流れ図である。これは、手順（
ステップ３９０）を開始して（ステップ３８８）、受取
サービスを呼び出し（ステップ３９１）、入り要求に関
連する経路識別子、障害を発生している同期点の同期点
識別子（その同期点内のローカル・ノードも識別する）
、起点側の同期点ログに関連するログ名、開始側の回復
ファシリティが現回復ファシリティの同期点ログの名前
と一致すると予想しているログ名、およびこの障害を解
決するのに使用される指示（状態）を得る。

【０２０４】経路識別子は、ローカルのログ名ログ内の
エントリを見つけるのに使用される（ステップ３９２）
。次に、起点側のログ名を用いてＬＬ＿ＬＯＧＮＡＭＥ
を検査し、渡された予期されるログ名を用いてローカル
の同期点ログの名前を検査する（ステップ３９３）。次
に、同期点ログを探索して、同期点識別子が一致するエ
ントリを探す（ステップ３９４）。それが見つかると、
その同期点ログのエントリへのアンカを備えた回復制御
構造が作成され、この要求中で渡された指示に合わせて
ＲＣＳ＿ＰＡＲＴＩＣＩＰＡＮＴ＿ＳＴＡＴＥが設定さ
れる（ステップ３９５）。さらに、開始側への応答が適
当であることを示すフラグＲＣＳ＿ＲＥＳＰＯＮＤ＿Ｔ
Ｏ＿ＩＮＩＴＩＡＴＯＲをセットし、ＲＣＳ＿ＰＡＴＨ
＿ＩＤを開始側の入り経路の経路識別子に設定する。ア
プリケーション環境５２内の呼出し側同期点マネジャ６
０へのリターンを抑止するため、フラグＲＣＳ＿ＲＥＴ
ＵＲＮ＿ＴＯ＿ＣＡＬＬＥＲをセットする。最後に、回
復初期設定を呼び出して（ステップ３９６）、回復制御
構造を渡す。

【０２０５】図４２は、アプリケーション環境５２と回
復ファシリティ７０の間の経路に障害があって、同期点
のロギングが動作不能になる（ステップ３１３）時に行
われる処理（ステップ４００）を示す流れ図である。処
理が開始された（ステップ３９９）後、同期点ログを探
索して、下記の両方の条件を満足するエントリを探す（
ステップ４０１）。（１）ＳＰＬ＿ＳＹＮＣＰＯＩＮＴ
＿ＰＡＴＨ＿ＩＤが障害を発生している経路と一致する
。（２）ＳＰＬ＿ＳＹＮＣＰＯＩＮＴ＿ＳＴＡＴＥが、
この同期点を完了するために、同期点の直接参加者を駆
動できることを示す。これは、以下のいずれかによって
示される。ＳＰＬ＿ＳＹＮＣＰＯＩＮＴ＿ＳＴＡＴＥが
同期点段階１を示し、開始側の“ｐｒｅｐａｒｅ”に対
する応答がなかった場合、あるいはＳＰＬ＿ＳＹＮＣＰ
ＯＩＮＴ＿ＳＴＡＴＥが同期点段階２を示す場合。

【０２０６】これらの条件が満たされる場合、その同期
点ログのエントリへのアンカを備えた回復制御構造が（
そのような各ログ・エントリごとに）作成される（ステ
ップ４０２）。その際に、ＴＯＲ＿ＲＥＳＰＯＮＳＥ＿
ＳＴＡＴＥとＲＣＳ＿ＰＡＲＴＩＣＩＰＡＮＴＳ＿ＳＴ
ＡＴＥは、共にＳＰＬ＿ＳＹＮＣＰＯＩＮＴ＿ＳＴＡＴ
Ｅから導かれる。ＳＰＬ＿ＰＡＲＴＩＣＩＰＡＮＴ＿Ｓ
ＴＡＴＥが、ＲＣＳ＿ＩＮＩＴＩＡＴＯＲ＿ＲＥＳＰＯ
ＮＳＥ＿ＳＴＡＴＥの設定にも影響する場合がある。こ
れは、たとえば参加者からの応答が、単方向の（ヒュー
リスティックな）行動を示していた時に起こる。さらに
、フラグＲＣＳ＿ＲＥＳＰＯＮＤ＿ＴＯ＿ＩＮＩＴＩＡ
ＴＯＲをセットすると、この同期点の開始側を代理する
回復ファシリティに応答を送ることが抑止され、フラグ
ＲＣＳ＿ＲＥＴＵＲＮ＿ＴＯ＿ＣＡＬＬＥＲをセットす
ると、戻るべき呼出し側の同期点マネジャが存在しない
ことを示す。この結果得られる回復制御構造が、相互に
連鎖される。最後に、回復初期設定を呼び出して（ステ
ップ４０３）、回復制御構造のチェーンを渡す。

【０２０７】図４３は、回復ファシリティ７２の障害が
発生した（ステップ３１４）場合に行われる処理（ステ
ップ４０８）を示す流れ図である。回復ファシリティ７
０が再始動される（ステップ４０７）時、ログ７２を検
索して（ステップ４１１）、下記の条件を満足するすべ
てのエントリを探す。ＳＰＬ＿ＳＹＮＣＰＯＩＮＴ＿Ｓ
ＴＡＴＥが、この同期点を完了するために、同期点の直
接参加者を駆動できることを示していること。これは、
以下のいずれかによって示される。ＳＰＬ＿ＳＹＮＣＰ
ＯＩＮＴ＿ＳＴＡＴＥが同期点段階１を示し、開始側の
“ｐｒｅｐａｒｅ”に対する応答がなかった場合、ある
いはＳＰＬ＿ＳＹＮＣＰＯＩＮＴ＿ＳＴＡＴＥが同期点
段階２を示す場合。

【０２０８】この条件が満たされる場合、そのような各
ログ・エントリごとにその同期点ログへのアンカを備え
た回復制御構造が作成される（ステップ４１２）。その
際に、ＲＣＳ＿ＩＮＩＴＩＡＴＯＲ＿ＲＥＳＰＯＮＳＥ
＿ＳＴＡＴＥとＲＣＳ＿ＰＡＲＴＩＣＩＰＡＮＴＳ＿Ｓ
ＴＡＴＥは、共にＳＰＬ＿ＳＹＮＣＰＯＩＮＴ＿ＳＴＡ
ＴＥから導かれる。 場合によっては、ＳＰＬ＿ＰＡＲＴＩＣＩＰＡＮＴ＿Ｓ
ＴＡＴＥが、ＲＣＳ＿ＩＮＩＴＩＡＴＯＲ＿ＲＥＳＰＯ
ＮＳＥ＿ＳＴＡＴＥの設定にも影響を与える。これは、
参加者からの応答が、たとえば単方向の（ヒューリステ
ィックな）行動を示していた時に起こる。さらに、フラ
グＲＣＳ＿ＲＥＳＰＯＮＤ＿ＴＯ＿ＩＮＩＴＩＡＴＯＲ
をセットすると、この同期点の開始側を代理する回復フ
ァシリティに応答を送ることが抑止でき、フラグＲＣＳ
＿ＲＥＴＵＲＮ＿ＴＯ＿ＣＡＬＬＥＲをセットすると、
戻るべき呼出し側の同期点マネジャが存在しないことを
示す。この結果得られる回復制御構造が、相互に連鎖さ
れる。最後に、回復初期設定を呼び出して（ステップ４
０３）、回復制御構造のチェーンを渡す。

【０２０９】図４４は、回復管理要求（ステップ３１５
）のサポート（ステップ４０９）を示す図である。この
サポートは、下流側での解決のための同期点参加者との
会話（参加者の場合）、または、同期点完了のためにそ
の参加者を駆動する指示（状態）を与えるための同期点
開始側との会話（開始側の場合）を開始できなかったた
めに動かなくなった自動的同期点回復の修復を、手動で
開始できるようにするものである。

【０２１０】参加者の場合、この要求が参加者の応答の
代りをつとめ、その結果、下流側の参加者を駆動してい
る回復ファシリティ７０は、実際にその参加者と通信す
ることなく回復を完了できるようになる。開始側の場合
、この要求は、開始側がローカルの回復ファシリティ７
０と接続できないために発生し得ない、通常の回復処理
によって開始される回復要求事象（図４１参照）の代り
をつとめる。後者の場合、この応答によって、ローカル
の回復ファシリティは、図４１に示された事象なしに、
その参加者を駆動できるようになる。

【０２１１】開始側の場合、このサポートが開始された
（ステップ４０８）後に、回復制御構造を作成し（ステ
ップ４１４）、渡された指示に合わせてＲＣＳ＿ＩＮＩ
ＴＩＡＴＯＲ＿ＲＥＳＰＯＮＳＥ＿ＳＴＡＴＥとＲＣＳ
＿ＰＡＲＴＩＣＩＰＡＮＴＳ＿ＳＴＡＴＥを設定して、
回復処理が開始した回復要求と等価な要求を形成する。 さらに、ＲＣＳ＿ＲＥＳＰＯＮＤ＿ＴＯ＿ＩＮＩＴＩＡ
ＴＯＲをオフにセットして、応答の生成を抑止し、ＲＣ
Ｓ＿ＲＥＴＵＲＮ＿ＴＯ＿ＣＡＬＬＥＲをオフにセット
して、処理の完了時に回復初期設定から戻るのを抑止す
る。回復初期設定を呼び出して（ステップ４１５）、処
理を開始させる。

【０２１２】参加者の場合、回復制御構造と中断された
回復処理がすでに存在していなければならない。この処
理は、タイマ待機中は中断され、各時間間隔の終わりに
、参加者との会話の初期設定が再試行される。これを検
査した後に（ステップ４１６）、渡された回復経路識別
子に関連する参加者の参加者制御構造を見つけ、この参
加者が実際に応答した場合と同様にＰＣＳ＿ＳＴＡＴＵ
ＳをＲＥＳＰＯＮＤＥＤに設定し（ステップ４１７）、
渡された指示に合わせてＳＰＬ＿ＰＡＲＴＩＣＩＰＡＮ
Ｔ＿ＳＴＡＴＥを設定する。その後、同期点ログのエン
トリを更新する。次に、ＳＰＬ＿ＳＵＳＰＥＮＤＥＤ＿
ＰＲＯＣＥＳＳ＿ＩＤを用いて再開サービスを呼び出し
、中断されたプロセスを再始動する（ステップ４１８）
。いずれの場合にも、起点側要求に対して、適当な置換
が行われ、回復処理が再び活動状態になっていることを
示す応答が行われる（ステップ４１９）。ｐｕｒｇｅオ
プションが渡された場合は、ＲＣＳ＿ＥＲＡＳＥ＿ＬＯ
Ｇがオンになり、プロセスの終了時に同期点ログのエン
トリが消去される。

【０２１３】図４５は、回復初期設定機能（ステップ３
０４）に必要なステップを示す流れ図である。初期設定
（ステップ３０３）の後に、フラグＲＣＳ＿ＲＥＴＵＲ
Ｎ＿ＴＯ＿ＣＡＬＬＥＲに従って、参加ドライバが現在
のプロセス内で呼び出されたか（オン）、それとも別の
並行プロセス内で呼び出されたか（オフ）を判定する（
ステップ４２１）。ＲＣＳ＿ＲＥＴＵＲＮ＿ＴＯ＿ＣＡ
ＬＬＥＲがセットされている場合、参加ドライバを呼び
出して（ステップ４２２）、回復制御構造を渡す。そう
でない場合は、「参加ドライバ」を示すようにＲＣＳ＿
ＦＵＮＣＴＩＯＮ＿ＩＤを設定して、渡された各回復制
御構造ごとに、サブプロセス開始サービスを呼び出す（
ステップ４２３）。

【０２１４】図４６は、参加ドライバのステップ３１７
の流れを示す流れ図である。参加ドライバの主な機能は
、関連する同期点ログが、その同期点の開始時と同一レ
ベルであることを保証し、その同期点を解決するための
基礎となる同期点状態情報を提供するために、障害を発
生している同期点の参加者との通信を開始し、それらの
参加者から応答を得ることである。

【０２１５】参加ドライバの初期設定（ステップ４３０
）の後に、現在のＲＣＳ＿ＰＡＲＴＩＣＩＰＡＮＴＳ＿
ＳＴＡＴＥに従って、ＳＰＬ＿ＳＹＮＣＰＯＩＮＴ＿Ｓ
ＴＡＴＥを設定する（ステップ４３１）。 この同期点の参加者に対する参加者制御構造が、まだ作
成されていない場合は、この時点でそれらの制御構造を
作成し、互いに連鎖し、現回復制御構造にアンカする。 ＰＣＳ＿ＰＡＴＨ＿ＩＤは、各参加者のＳＰＬ＿ＲＥＣ
ＯＶＥＲＹ＿ＰＡＴＨ＿ＩＤから得られる。ＳＰＬ＿Ｐ
ＡＲＴＩＣＩＰＡＮＴ＿ＳＴＡＴＥがＰＣＳ＿ＳＴＡＴ
ＵＳがＲＥＳＰＯＮＤＥＤに設定されて、その特定の参
加者に対する同期点が解決されていると示さない限り、
ＰＣＳ＿ＳＴＡＴＵＳはＲＥＳＴＡＲＴに初期設定され
る。

【０２１６】ステップ４３２〜４４４の流れは、各参加
者に対するＰＣＳ＿ＳＴＡＴＵＳの値によって制御され
る。とり得る値は以下の通りである。 （１）ＲＥＳＴＡＲＴ　　　　この参加者との会話が必
要であることを示す。 （２）ＣＯＮＮＥＣＴＥＤ　　この参加者との会話の初
期設定に成功したことを示し、この参加者へ回復要求メ
ッセージを送らせる。 （３）ＲＥＳＰＯＮＤＥＤ　　この参加者への回復要求
メッセージの送出が完了し、この参加者からの応答を得
たことを示す。応答処理ドライバを呼び出して（ステッ
プ４３８ないし４３９）、この応答を処理する。 （４）ＲＥＴＲＹ　　　　　　接続（すなわち、会話の
確立）（ステップ４３６ないし４３７）またはメッセー
ジの送出（ステップ４４０ないし４４１）の試みに失敗
したこと、あるいはログ名が一致しなかったこと（ステ
ップ４４０ないし４４１）を示す。参加者に関するすべ
てのフラグＰＣＳ＿ＳＴＡＴＵＳが状況ＲＥＳＴＡＲＴ
およびＣＯＮＮＥＣＴＥＤよりも先に進んでいるが、通
信障害に出会ったものがある（他のものはＲＥＳＰＯＮ
ＤＥＤ）状態になった後に、現同期点の参加ドライバは
、時限間隔の間、実行を中断する。この中断が完了した
時、ＲＥＴＲＹであったＰＣＳ＿ＳＴＡＴＵＳは、すべ
てＲＥＳＴＡＲＴに変更され、再接続が試みられる。

【０２１７】多重事象待機サービス（ステップ４３３）
は、未処理の接続または送出のサービス要求のうちの最
初のものが完了するのを待って、制御をその経路識別子
および成否の指示と共に参加ドライバに戻すのに使用す
る。参加者に送られた回復要求（ステップ４３４ないし
４３５）には、送出側の回復ファシリティ７０のログ名
と、参加者に関連する予期されるログ名が含まれる。参
加者の実際の状態と比較して、適当な回復行動を定義で
きるようにするために、ＲＣＳ＿ＰＡＲＴＩＣＩＰＡＮ
ＴＳ＿ＳＴＡＴＥが送られる。時限待機サービス（ステ
ップ４４２〜４４３）は、不成功であった会話の開始を
再試行する前に、システムで定義された時間間隔の間プ
ロセスを遅延させるのに使用する。この意図的な遅延は
、すべての参加経路を駆動し終えて、何らかの障害に出
会った後だけ試みられる。時限待機完了（ステップ４４
４）は、中断されたプロセスを再始動させて、参加者と
の接続をもう１度試みさせる働きをする。すべての参加
者が状況ＲＥＳＰＯＮＤＥＤに達し、応答処理ドライバ
による処理を完了した後、開始側応答ドライバを呼び出
して（ステップ４４５）、同期点開始側を代理する回復
処理への可能な応答を処理する。

【０２１８】図４７は、障害を発生した同期点の参加者
に送られた回復要求に対する応答を処理するのに必要な
処理を示す示す流れ図である。応答処理ドライバ（ステ
ップ３１８）は、同期点識別子、経路識別子および参加
者から受け取った状態を渡される（ステップ４５０）。 次に、ログ名交換の応答が処理される（ステップ４５１
）。ログ名が一致しない場合、流れは参加ドライバに戻
って（図３６のステップ３１７）、時限待機の再試行を
起こさせるエラーを戻す。

【０２１９】同期点識別子は、同期点ログのエントリを
見つけるのに使用される。その後、経路識別子を使用し
て、その同期点ログのエントリの本体内で、ＳＰＬ＿Ｒ
ＥＣＯＶＥＲＹ＿ＰＡＴＨ＿ＩＤに一致する参加者を見
つける。次に、前記の状態を用いて、ＳＰＬ＿ＰＡＲＴ
ＩＣＩＰＡＮＴ＿ＳＴＡＴＥを更新する（ステップ４５
２）。

【０２２０】ＲＣＳ＿ＩＮＩＴＩＡＴＯＲ＿ＲＥＳＰＯ
ＮＳＥ＿ＳＴＡＴＥは、たとえば、単方向の（ヒューリ
スティックな）決定を反映するなど、参加者からの予期
せぬ応答の結果として更新される場合がある（ステップ
４５３）。最後に、切断サービスを呼び出して、現経路
の接続を断つ（ステップ４５４）。

【０２２１】図４８は、開始側応答ドライバ（ステップ
３１９）を示す流れ図である。まず、開始側応答ドライ
バが開始される（ステップ４６０）。ＲＣＳ＿ＲＥＳＰ
ＯＮＳＥ＿ＴＯ＿ＩＮＩＴＩＡＴＯＲがセットされてい
ない場合（判断ブロック４６１）、応答する必要はない
。したがって、同期点ログのエントリを消去するだけで
よい（ステップ４６８）。 応答すべき開始側がない時（ステップ４６２）、すなわ
ち、回復ファシリティが同期点ツリーの最初のノードを
表している時も、応答は行わない。

【０２２２】回復処理が開始し、中断されている、開始
側への応答の処理を求め、回復要求（図４１に図示の事
象）がなく、その開始側に応答すべき既存の会話が存在
しない（判断ステップ４７９）時は、現回復ファシリテ
ィ７０が代理する参加者が応答の準備ができていること
を、その開始側を代理する回復ファシリティに通知する
ために、その回復ファシリティとの上流向きの通信を試
みるのが適当である（ステップ４６４）。これは、ロー
カル回復ファシリティ７０との通信の試みに以前に失敗
したために時限中断の状態になっているその開始側の回
復ファシリティがある時、すなわち、現在完了している
回復がローカル回復ファシリティ７０の障害の結果生じ
た同期点障害から生じたものである（図４３に図示の事
象）時に、最も効果的である。この上流向けの通信は、
時限中断を早めに打ち切り、したがって、同期点の解決
の遅延を最小にするという効果があるはずである。図３
９のステップ３７４が、（開始側を代理する）受信側回
復ファシリティの行動を示している。

【０２２３】ＳＰＬ＿ＳＵＳＰＥＮＤＥＤ＿ＰＲＯＣＥ
ＳＳ＿ＩＤが定義されておらず、ＲＣＳ＿ＰＡＴＨ＿Ｉ
Ｄが設定されていない場合（判断ブロック４７９）、回
復中の同期点の同期点ログ・エントリの本体中から開始
側のエントリを見つけ、それに関連するＳＰＬ＿ＲＥＣ
ＯＶＥＲＹ＿ＰＡＴＨ＿ＩＤを使って、ＳＰＬ＿ＲＥＣ
ＯＶＥＲＹ＿ＰＡＴＨ＿ＩＤに対する接続サービスを呼
び出すことによって、上流向けの通信が達成される。こ
の会話を初期設定する試みに失敗した時は、再試行は行
われない（ステップ４６４Ａの判断経路“ｎｏ”）。そ
れは、この会話を完了し開始側に通知するための任意選
択の最適化手段だからである。この会話が開始される場
合（ステップ４６４Ａの判断経路“ｙｅｓ”）、図３８
のステップ３６４〜３６７に従って、通常のログ名交換
要求が送られ（ステップ４６４Ｂ）、その後、判断ステ
ップ４７７を経て脱出する。 接続が完了していない場合は、回復終了を呼び出す（ス
テップ４６９）。

【０２２４】ＲＣＳ＿ＰＡＴＨ＿ＩＤが設定されていな
い（判断ブロック４６５）時は、開始側への応答（ステ
ップ４６６および４６７）は行われない。そうでない場
合は、ＲＣＳ＿ＩＮＩＴＩＡＴＯＲ＿ＲＥＳＰＯＮＳＥ
＿ＳＴＡＴＥ（ステップ４６６）と応答サービス（ステ
ップ４６７）を使用して、開始側への正常な応答が行わ
れる。ＲＣＳ＿ＲＥＳＰＯＮＤ＿ＴＯ＿ＩＮＩＴＩＡＴ
ＯＲまたはＲＣＳ＿ＥＲＡＳＥ＿ＬＯＧがオンである場
合（判断ブロック４７７）、完了の前に、回復終了機能
が呼び出される（ステップ４６８）。

【０２２５】図４９は、回復終了論理（ステップ３０６
）を示す流れ図である。この論理は、ステップ４７０で
開始した後、記憶域と制御構造をきれいにして（ステッ
プ４７１）、呼出し側に戻る（終了）か、またはサブプ
ロセス終了サービスを呼び出して、現プロセスを完了す
る（ステップ４７２）。

【０２２６】コミット手順の非同期的再同期化システム
５０内での同期点処理中に障害が発生した時、参加する
アプリケーションの使用を最適化するために、下記の非
同期式再同期化の手順およびファシリティが提供される
。この手順に従えば、コミットを発行したアプリケーシ
ョンが、再同期化中に遊休状態で待機する必要がなくな
るので、そのアプリケーションの実行の際の長い遅延が
回避される。そのアプリケーションは、その代わりに、
以下で詳細に説明するように、再同期化を待つ間に他の
有用な作業を行うことができる。同期点マネジャと回復
ファシリティは、デフォルトのアプリケーションまたは
システムがそれを要求する場合、この手順を実行する。 回復ファシリティ７０は、非同期的再同期化（進行中の
再同期化）をサポートし、この非同期的再同期化処理を
サポートする体系的システム間通信の流れの新規の拡張
版をサポートする。たとえば、システム間通信プロトコ
ルは、“Ｓｙｓｔｅｍ　Ｎｅｔｗｏｒｋ　Ａｒｃｈｉｔ
ｅｃｔｕｒｅ　ＬＵ　６．２　Ｒｅｆｅｒｅｎｃｅ：　
Ｐｅｅｒ　Ｐｒｏｔｏｃｏｌｓ，　ＳＣ３１−６８０８
，　Ｃｈａｐｔｅｒ　５．３　Ｐｒｅｓｅｎｔａｔｉｏ
ｎ　Ｓｅｒｖｉｃｅｓ　−　Ｓｙｎｃ　Ｐｏｉｎｔ　ｖ
ｅｒｂｓ”によって定義されている。システム５０内の
体系的システム間通信の拡張版には、Ｃｏｍｍｉｔｔｅ
ｄ（最後の代理のみ）、Ｆｏｒｇｅｔ、Ｂａｃｋｏｕｔ
などの流れに関して再同期化が進行中であることを示す
追加の指示が含まれている。２つの異なるシステムの回
復ファシリティの間での初期交換中または再同期化中の
交換ログ名のために定義されたデータ・フィールド中に
、この交換ログ名の送出側が進行中の再同期化をサポー
トすることを示す標識がある。交換ログ名の処理は、上
記の「保護された資源を回復するためのログ名の交換」
に記述されている。このファシリティを使用するために
は、両方の回復ファシリティが進行中の再同期化をサポ
ートしなければならない。最後に、状態比較データ・フ
ィールド中に、再同期化が進行中であることをパートナ
に伝える標識がある。

【０２２７】前述の「保護された資源の調整式同期点管
理」および図２、図５４、図３、図４および図５では、
２つのパートナ・アプリケーション５６Ａおよび５６Ｄ
、それらのアプリケーション環境、それらの処理および
成功したコミット処理について記述し図示した。本節で
は、非同期的再同期化をもたらすコミット処理中の障害
の説明を含むように上記の内容を拡張する。本明細書に
記載の非同期的再同期化処理は、保護された会話が同一
のシステム上にあるアプリケーション・パートナ間で行
われ、両方のアプリケーションが、たとえばＶＭオペレ
ーティング・システム（“ＶＭ”はＩＢＭコーポレーシ
ョンの登録商標）の拡張バージョンの異なる仮想計算機
など、異なるアプリケーション環境内にある時にも適用
可能であることを理解されたい。また、他の実施例では
、アプリケーション５６Ａまたはアプリケーション５６
Ｄが、異なるタイプの実行環境内で実行できることにも
留意されたい。

【０２２８】「保護された資源の調整式同期点管理」で
述べたように、アプリケーション５６Ａは、保護された
会話を介してアプリケーション５６Ｄを開始する（図５
Ａのステップ５３０）。保護会話アダプタ６４Ａおよび
６４Ｄが、当該の同期点マネジャに登録される（図５Ａ
のステップ５３２）。図５０Ａは、アプリケーション５
６Ａが次に行う処理（図５Ａのステップ５３３）を拡張
したものである。図５０Ａに示されるように、アプリケ
ーション５６Ａは、同期点マネジャ６０Ａに対して、“
ｓｅｔ　ｓｙｎｃｐｏｉｎｔ　ｏｐｔｉｏｎｓ　ｗａｉ
ｔ＝　ｎｏ（同期点オプション待機をｎｏにセット）”
コールを発行して、同期点処理中に障害が生じた場合に
、アプリケーション５６Ａが、同期的再同期化をいつま
でも待つつもりがないことを示し（ステップ９００）、
同期点マネジャ６０Ａは、このオプションを記録する（
ステップ９０２）。アプリケーション５６Ａがアプリケ
ーション５６Ｄにコンタクトして何らかの作業を行うよ
う伝えた後に（図５Ａのステップ５３３）、アプリケー
ション５６Ｄによって同様の処理（図５０Ｂのステップ
９０４および９０６）が行われる。この実施例では、体
系化デフォルトは、ＷＡＩＴ　＝　ｙｅｓであることに
留意されたい。ただし、要望に応じて、システム５０Ａ
およびシステム５０Ｄのデフォルト条件をＷＡＩＴ　＝
　ｎｏにすることも可能である。そのような場合、アプ
リケーション５６Ａおよびアプリケーション５６Ｄは、
ＷＡＩＴ　＝　ｎｏを望むならば、“ｓｅｔ　ｓｙｎｃ
ｐｏｉｎｔ　ｏｐｔｉｏｎｓ（同時点オプション設定）
”コールを発行する必要がない。“ｓｅｔ　ｓｙｎｃｐ
ｏｉｎｔ　ｏｐｔｉｏｎｓ”はローカル値である。 したがって、障害が検出された同期点マネジャ側で有効
な“ｓｙｎｃｐｏｉｎｔ　ｏｐｔｉｏｎｓ”の値が、実
際に使用される値である。

【０２２９】処理は、「保護された資源の調整式同期点
管理」の記述と、図２および図５のステップ５３３Ａ〜
５４６に従って進む。上記の詳細を要約すると、アプリ
ケーション５６Ａは、保護された会話を介してアプリケ
ーション５６Ｄに要求を送って、アプリケーション５６
Ｄにファイル７８Ｄを更新させる。アプリケーション５
６Ｄは、アプリケーション５６Ａに回答して、アプリケ
ーション５６Ａにファイル７８Ａおよび７８Ｂを更新さ
せる。アプリケーション５６Ａは、コミットを発行して
（図５Ａのステップ５３４）、同期点マネジャ６０Ａに
保護会話アダプタ６４Ａを呼び出させて、保護会話アダ
プタ６４Ｄへ段階１“ｐｒｅｐａｒｅ”コールを送らせ
る。これにより、アプリケーション５６Ｄは、コミット
発行要求を受け取る。アプリケーション５６Ｄは、コミ
ットを発行し（ステップ５３７）、同期点マネジャ６０
Ｄは、その段階１の処理を行い、保護会話アダプタ６４
Ａに“ｒｅｑｕｅｓｔ　ｃｏｍｍｉｔ”と回答するため
に保護会話アダプタ６４Ｄを呼び出す。この時、同期点
マネジャ６４Ｄの状態は「不確定」である（その旨がそ
のログ７２Ｄに記入される）。保護会話アダプタ６４Ａ
は、同期点マネジャ６０Ａに“ｒｅｑｕｅｓｔ　ｃｏｍ
ｍｉｔ”と回答する。同期点マネジャ６０Ａの他の資源
も“ｒｅｑｕｅｓｔ　ｃｏｍｍｉｔ”と回答したので、
同期点マネジャ６０Ａの状態は、現在“ｃｏｍｍｉｔｔ
ｅｄ”であり、この状態をそのログ７２Ａに書き込む。 次に同期点マネジャ６０Ａは、その登録された資源にコ
ンタクトして、段階２の決定“ｃｏｍｍｉｔｔｅｄ”を
渡す（図５Ｂのステップ５４５）。次に、保護会話アダ
プタ６４Ａが、この段階２の決定“ｃｏｍｍｉｔｔｅｄ
”を保護会話アダプタ６４Ｄに送る（図５Ｂのステップ
５４６）。ところが、この処理中に保護会話アダプタ６
４Ａが、障害を発見し、その結果、アプリケーション５
６Ａとアプリケーション５６Ｄの間の保護された会話の
ための、システム５０Ａとシステム５０Ｄの間の経路が
使用不能になる。 保護会話アダプタ６４Ａは、同期点マネジャ６０Ａに“
ｒｅｓｏｕｒｃｅ　ｆａｉｌｕｒｅ（資源障害）”と回
答する。これは同期点マネジャ６０Ａの処理への割込み
であり（図５Ｂのステップ５５０）、同期点マネジャ６
０Ａに回復処理を開始させる（図５Ｂのステップ５５７
）。

【０２３０】回復手順は、使用される２段階コミットの
例によって定義される。この実施例では、２段階コミッ
トの例は、「保護された資源の調整式同期点管理」で使
用したものである。回復処理は、同期点マネジャの段階
１または段階２の呼出しに対して、保護資源アダプタが
異常な回答をした場合に発生する。この異常な回答は、
システム障害、経路障害、プログラム障害または資源マ
ネジャ障害によって引き起こされる資源障害の結果であ
る。回復は、それを必要とする、障害を発生した保護さ
れた各資源ごとに独立に行われる。回復の目的は下記の
通りである。 １．保護された資源を、可能なら整合性のある状態に置
く。不可能なら、そのシステムの操作員に通知し、保護
された会話に障害が発生した場合には、その損傷を検出
したシステムに通知する。 ２．ロックされた資源を他の用途に自由に使用できるよ
うに、ロック解除する。 ３．回復ファシリティのログを更新して、そのＬＵＷＩ
Ｄに関して保護されたすべての資源に同期点作業がこれ
以上は不要であると示す。

【０２３１】回復すなわち再同期化に伴うステップには
、下記のものが含まれる。 １．回復ファシリティが動作しているシステムが障害を
発生した場合に、同期点の動作状況を表す、回復ファシ
リティのログ・レコードからのデータ構造が復元される
。これらのデータ構造から、回復ファシリティ（他の実
施例では、１つのファシリティが同期点処理と回復処理
の両方を実行するので、回復ファシリティが同期点マネ
ジャと呼ばれることもある）は、それが回復を開始する
責任を負う資源を決定する。この回復がシステム障害な
しに発生する場合には、この回復ファシリティによって
使用される同期点中に書かれたデータ構造がまだ無傷な
ので、ログから情報を復元する必要はない。 ２．回復を開始する責任を負う回復ファシリティ内のプ
ログラムが起動される。この実施例で保護された会話に
使用される会話の例では、これは、下記のことを意味す
る。保護された会話に関して、最初にこの同期点に関係
した、確認を必要とするタイプのシステムの回復ファシ
リティ内で実行中のパートナ回復プログラムとの保護さ
れない会話を確立する。（これには、活動化すべき２つ
のシステムの間に新規の経路が必要になることがある。 ）パートナが、ＬＵＷＩＤの適当な記憶を有することを
検査するためにログ名を交換する。両パートナのＬＵＷ
ＩＤの状態（すなわち、ｃｏｍｍｉｔまたはｂａｃｋｏ
ｕｔ）を比較し調節する。回復完了時に回復ファシリテ
ィ・ログのエントリを消去し、その結果を両パートナの
操作員に通知する。 ３．この２段階コミット手順に参加する他の資源マネジ
ャに対して、同様の回復方法が定義される。一般に、非
分散式保護資源マネジャに対する回復処理は、同期点サ
ポートを実施するオペレーティング・システムによって
定義される。保護された会話に対する回復処理は、シス
テム間通信アーキテクチャによって定義される。たとえ
ば、前者は、ＶＭオペレーティング・システム（“ＶＭ
”はＩＢＭコーポレーションの登録商標）の拡張バージ
ョンによって定義されるタイプでよく、後者は、“Ｓｙ
ｓｔｅｍ　Ｎｅｔｗｏｒｋ　Ａｒｃｈｉｔｅｃｔｕｒｅ
　ＬＵ　６．２　Ｒｅｆｅｒｅｎｃｅ：　Ｐｅｅｒ　Ｐ
ｒｏｔｏｃｏｌｓ，　ＳＣ３１−６８０８，　Ｃｈａｐ
ｔｅｒ　５．３　Ｐｒｅｓｅｎｔａｔｉｏｎ　Ｓｅｒｖ
ｉｃｅｓ　−　Ｓｙｎｃ　Ｐｏｉｎｔ　ｖｅｒｂｓ”で
部分的に定義されるタイプのものでよい。

【０２３２】次に、同期点マネジャ６０Ａは、障害を発
生した資源の識別子（この例の場合、この資源は保護さ
れた会話６４Ａである）と処理中のＬＵＷＩＤを用いて
回復ファシリティ７０Ａを呼び出す。回復ファシリティ
７０Ａは、そのＬＵＷＩＤのログ・エントリと保護され
た会話６４Ａのエントリを見つける（図４のステップ５
１８）。回復ファシリティ７０Ａは、このエントリ中の
状態情報から、回復の判断を決定する（ステップ５１９
）。上述の処理に基づけば、この判断は“Ｃｏｍｍｉｔ
”である。回復ファシリティ７０Ａは、回復すべき資源
が保護された会話であることを知っており、回復処理を
開始する。この回復処理は、その会話のための体系化さ
れた回復方法と使用される２段階コミット・パラダイム
とによってその処理が定義されるアプリケーションであ
る。 この回復処理は、システム５０Ｄ上の回復ファシリティ
７０Ｄ内のパートナの回復処理のために、保護されない
会話を開始する（ステップ５２０）。この回復の試みは
、経路障害のために２つのシステム間で会話が開始でき
ない（判断ブロック５２１のＮＯ分岐）ので、失敗する
。その後、回復ファシリティ７０Ａは、ログ・エントリ
を検査して、アプリケーション５６Ａが、回復が完了し
ないうちに、回復ファシリティ７０Ａが同期点マネジャ
６０Ａにリターンできることを意味する　ＷＡＩＴ　＝
　Ｎｏを要求したか否かを調べる。次いで、回復ファシ
リティ７０Ａは、後でアプリケーション５６Ａとは非同
期的に回復を完了することができる（ステップ５２４）
。この情報は、同期点マネジャ６０Ａが、その段階１の
ログ書込み中に書き込んだものである。上述したように
、アプリケーション５６Ａは、“ｓｅｔ　ｓｙｎｃｐｏ
ｉｎｔ　ｏｐｔｉｏｎｓ　ｗａｉｔ　＝　ｎｏ”コール
を発行した。したがって、回復ファシリティ７０Ａは、
同期点マネジャ６０Ａに回復の意図すなわちコミットと
、再同期（回復）がまだ進行中であるとの指示を戻す（
ステップ５２６）。同期点マネジャ６０Ａは、すでに他
の保護された資源から“ｆｏｒｇｅｔ”を伝えられてい
るので（図５Ｂのステップ５４５Ａ）、ＬＵＷＩＤの値
を１だけ更新し、アプリケーション５６Ａに、意図した
結果であるＣｏｍｍｉｔと、すべての資源がコミットさ
れてはいないこととを示す戻りコード“ＲＣ＝　ＯＫ．
ＬＵＷ＿ＯＵＴＣＯＭＥ＿ＰＥＮＤＩＮＧ”を戻す（図
５Ｂのステップ５５８）。これは、このコミット処理が
アプリケーション５６Ａとは非同期的に完了されること
を意味する。したがって、アプリケーション５６Ａはそ
の後に他の作業の処理を継続でき、再同期化を待って時
間を浪費することがない。

【０２３３】回復ファシリティ７０Ａは、システム５０
Ｄ上の回復ファシリティ７０Ｄを用いて、保護会話アダ
プタ６４Ａの回復の完了を成功させようと繰り返し試み
る（図４のステップ５２７）。回復を開始して最終的に
完了した時（判断ブロック５２１のＹＥＳ分岐）、回復
ファシリティ７０Ａと回復ファシリティ７０Ｄは共に、
回復が開始されたこと、およびそれが成功裡に完了した
ことを示す操作員メッセージを書く（ステップ５２２）
。 同期点マネジャ６０Ｄも、その登録された資源である保
護会話アダプタ６４Ｄを介して、障害を発生した会話に
ついて知らされている。同期点マネジャ６０Ｄは、障害
を発生した資源、この場合は保護された会話６４Ｄの識
別子とＬＵＷＩＤとを用いて、その回復ファシリティ７
０Ｄにもコンタクトしていた。回復ファシリティ７０Ｄ
は、同期点マネジャの「不確定」の状態に基づいて、回
復ファシリティ７０Ａによる回復のためにコンタクトさ
れるのを待たなければならなかったことを知っていた。 この回復が最終的に完了する時（判断ブロック５２３の
分岐ＹＥＳ）、回復ファシリティ７０Ｄは同期点マネジ
ャ６０Ｄにコミットの判断を戻す（ステップ５２３Ａ）
。 その後、同期点マネジャ６０Ｄはその段階２の処理を実
行する。保護された会話が中断しているので、同期点マ
ネジャ６０Ｄは続いて新規の一義的なＬＵＷＩＤを得る
。その後、同期点マネジャ６０Ｄはアプリケーション５
６Ｄにコミットの結果を戻す。これで、アプリケーショ
ン５６Ｄはその処理を実行できるようになる。以前の例
では、同期点マネジャ６０Ａに対して保護会話アダプタ
６４Ａによって代理される保護された会話ではなく、ス
テップ５４５Ａでファイル・マネジャ６３Ａで障害が起
こり得たことに留意されたい。この代替例では、回復フ
ァシリティ７０Ａは、オペレーティング・システムによ
って定義される保護されない会話用の回復方法に基づい
て、回復ファシリティ７０Ｄの代わりにファイル・マネ
ジャ６３Ａを用いて回復を開始することになる。

【０２３４】図５では、アプリケーション５６Ａ（した
がって、同期点マネジャ６０Ａも）が、コミット要求の
開始側であった。ところが、図５１は、アプリケーショ
ン５６Ａではなく、システム５０Ｈにある別のアプリケ
ーション５６Ｈがコミットを開始した（ステップ７００
）別の例を示す図である。アプリケーション５６Ｈが実
行されるアプリケーション環境は、アプリケーション５
６Ａが実行される環境と類似していても異なっていても
よい。ただし、両方のシステムおよびアプリケーション
環境は、どちらも前述の通信と２段階コミット手順をサ
ポートする。システム５０Ａとシステム５０Ｄは、図２
のそれと同一である。図５１（およびそれに続く図５２
と図５３）に示す例では、アプリケーション５６Ｈは、
システム５０Ｈ内の同期点マネジャ６０Ｈに対して、シ
ステム５０Ｈ、システム５０Ａおよびシステム５０Ｄ内
の資源を使用するコミット要求（ＳＹＮＣＰＴ）を発行
した。このコミット要求に応答して、同期点マネジャ６
０Ｈは、段階１の“ｐｒｅｐａｒｅ”コールを用いて、
その登録された資源である保護会話アダプタ６４Ｈを呼
び出す。次に、保護会話アダプタ６４Ｈが、システム５
０Ａ内の保護会話アダプタ６４Ｂに体系的システム間“
ｐｒｅｐａｒｅ”コールを送る（ステップ７０１）。前
述したように、この“ｐｒｅｐａｒｅ”信号は、２段階
コミット手順の第１段階の一部である。次に、保護会話
アダプタ６４Ｂがアプリケーション５６Ａに“Ｔａｋｅ
　Ｓｙｎｃｐｏｉｎｔ”の通知を与え（ステップ７０４
）、これに応答して、アプリケーション５６Ａが同期点
マネジャ６０Ａに対してコミット要求（ＳＹＮＣＰＴ）
を発行する（ステップ７０６）。次に、同期点マネジャ
６０Ａが、段階１の“ｐｒｅｐａｒｅ”コールを用いて
保護会話アダプタ６４Ａを呼び出す。保護会話アダプタ
６４Ａは、システム５０Ｄ内の保護会話アダプタ６４Ｄ
に体系的システム間ｐｒｅｐａｒｅコールを送る（ステ
ップ７０８）。これに応答して、保護会話アダプタ６４
Ｄがアプリケーション５６Ｄに“Ｔａｋｅ　Ｓｙｎｃｐ
ｏｉｎｔ”通知を与える（ステップ７１０）。これに応
答して、アプリケーション５６Ｄが同期点マネジャ６０
Ｄにコミット（ＳＹＮＣＰＴ）要求を発行する（ステッ
プ７１２）。同期点マネジャ６０Ｄは、その登録された
すべての資源に段階１の“ｐｒｅｐａｒｅ”コールを発
行する。同期点マネジャ６０Ｄによってアクセスされる
すべての資源がコミットの準備ができた時、同期点マネ
ジャ６０Ｄは、“ｒｅｑｕｅｓｔ　ｃｏｍｍｉｔ”の回
答を用いて保護会話アダプタ６４Ｄを呼び出す。保護会
話アダプタ６４Ｄは、体系的システム間“ｒｅｑｕｅｓ
ｔ　ｃｏｍｍｉｔ”コールをこのコミット要求の開始側
、この場合には保護会話アダプタ６４Ａに送り、保護会
話アダプタ６４Ａは同期点マネジャ６０Ａに“ｒｅｑｕ
ｅｓｔ　ｃｏｍｍｉｔ”と回答する（ステップ７１４）
。同期点マネジャ６０Ａは、この要求と、その資源がす
べて作動可能である旨の通知とを受け取った後に、保護
会話アダプタ６４Ｂに“ｒｅｑｕｅｓｔ　ｃｏｍｍｉｔ
”と回答する。保護会話アダプタ６４Ｂは、体系的シス
テム間“ｒｅｑｕｅｓｔ　ｃｏｍｍｉｔ”コールを、こ
のコミット要求の開始側、この場合には開始側の保護会
話アダプタ６４Ｈと同期点マネジャ６０Ｈに送る（ステ
ップ７１６）。同期点マネジャ６０Ａの代理として保護
会話アダプタ６４Ｈからのこの回答と、同期点マネジャ
６０Ｈの資源がすべて作動可能である旨の通知とを受け
取った後に、同期点マネジャ６０Ｈの段階２の決定がコ
ミットされる。同期点マネジャ６０Ｈは、段階２の決定
“ｃｏｍｍｉｔ”を用いてすべての資源を呼び出す。保
護会話アダプタ６４Ｈは、呼び出されると、体系的シス
テム間“ｃｏｍｍｉｔ”コールを保護会話アダプタ６４
Ｂに送り、保護会話アダプタ６４Ｂは同期点マネジャ６
０Ａに“ｃｏｍｍｉｔｔｅｄ”と回答し、これがその段
階２の決定になる（ステップ７１８）。

【０２３５】ここまでは、２段階コミット手順の実施に
問題がなかった。また、各アプリケーションが、ステッ
プ７００、７０６および７１２で当該の同期点マネジャ
にコミット要求を発行した後に、各同期点マネジャが、
段階１の情報と状態をそれぞれ当該の回復ファシリティ
・ログにロギングすることに留意されたい。同様に、同
期点マネジャ６０Ａおよび６０Ｄはそれぞれ、それに関
連する資源からすべての資源が作動可能である旨の通知
を受け取ると、それぞれ当該の回復ファシリティ・ログ
のエントリに“ｉｎ　ｄｏｕｂｔ”とロギングする。１
つまたは複数の資源がコミットできない場合、ログ・エ
ントリは作成されないが、上流側の開始側に“ｂａｃｋ
ｏｕｔ”と回答する前に、バックアウト処理が完了して
いる。同様に、同期点マネジャ６０Ｈは、その登録され
たすべての資源から“ｒｅｑｕｅｓｔ　ｃｏｍｍｉｔ”
を受け取ると、その回復ファシリティ・ログに“ｃｏｍ
ｍｉｔ”の決定を書き込む。同期点マネジャ６０Ａおよ
び６０Ｄは、それぞれこのコミット判断を受け取ると、
その登録された資源にコンタクトする前に、それぞれ当
該の回復ファシリティ・ログにこのコミット決定を書き
込む。

【０２３６】次に、同期点マネジャ６０Ａが、段階２の
“ｃｏｍｍｉｔ”決定を用いて、その登録されたすべて
の資源を呼び出す。同期点マネジャ６０Ａが、“ｃｏｍ
ｍｉｔ”コールで保護会話アダプタ６４Ａを呼び出すと
、保護会話アダプタ６４Ａは、体系的システム間“ｃｏ
ｍｍｉｔ”コールを保護会話アダプタ６４Ｄに送ること
を試み、保護会話アダプタ６４Ｄは、同期点マネジャ６
０Ｄに“ｃｏｍｍｉｔｔｅｄ”と回答しなければならな
い。ところが、この例ではこの送信は会話経路の障害の
ために成功しない（ステップ７２０）。この障害に応答
して、同期点マネジャ６０Ａは、このＬＵＷＩＤと保護
された会話とのための回復処理を求めて回復ファシリテ
ィ７０Ａにコンタクトする。上述したように、回復ファ
シリティ７０Ａは、回復ファシリティ７０Ｄを用いた回
復の実行を１回試みる（ステップ７２２）。この例では
、通信経路の障害が持続しているので、この試みも成功
しない。次に、回復ファシリティ７０Ａは、ログ・エン
トリを読み取って、非同期的再同期化が必要なことを知
る。そこで回復ファシリティ７０Ａは、同期点マネジャ
７０Ａに、この失敗した回復の試みと、回復が非同期的
に継続されることを通知する。その後、同期点マネジャ
６０Ａは、“ｆｏｒｇｅｔ，　ｒｅｓｙｎｃｈｒｏｎｉ
ｚａｔｉｏｎ−ｉｎ−ｐｒｏｇｒｅｓｓ（ＲＩＰ）（忘
却、進行中の再同期化）”を用いて、保護会話アダプタ
６４Ｂを呼び出す。保護会話アダプタ６４Ｂは、体系的
システム間“ｆｏｒｇｅｔ，　ＲＩＰ”コールを保護会
話アダプタ６４Ｈに送り、保護会話アダプタ６４Ｈは同
期点マネジャ６０Ｈに“ｆｏｒｇｅｔ，　ＲＩＰ”と回
答する（ステップ７２６）。その後、同期点マネジャ６
０Ａは、アプリケーション５６Ａに戻りコード“ＲＣ　
＝　ＯＫ．　ＬＵＷ＿ＯＵＴＣＯＭＥ＿ＰＥＮＤＩＮＧ
”を与えて、ｃｏｍｍｉｔの意図と、このコミット処理
が非同期的に完了されることを知らせる（ステップ７２
４）。ステップ７２６の“Ｆｏｒｇｅｔ，　ＲＩＰ”通
知は、ステップ７１８に対する肯定応答として働き、そ
れによって同期点マネジャ６０Ｈは、ステップ７００の
同期点に関係する同期点情報用のその回復ファシリティ
・ログに“ｆｏｒｇｅｔ”の状態を書き込む。というの
は、この時、２段階コミット処理がアプリケーション５
６Ｈの要求したコミットに関して完了しているからであ
る。同期点マネジャ６０Ｈは、その保護会話アダプタ６
４Ｈから“Ｆｏｒｇｅｔ，　ＲＩＰ”の指示を受け取る
と（このコミットに関係する他のすべての資源からメッ
セージを受け取っていると仮定して）、アプリケーショ
ン５６Ｈに戻りコード“ＲＣ　＝　ＯＫ．　ＬＵＷ＿Ｏ
ＵＴＣＯＭＥ＿ＰＥＮＤＩＮＧ”を戻して、コミットの
意図と、このコミット処理が非同期的に完了されること
を知らせることができる（ステップ７２８）。

【０２３７】回復ファシリティ７０Ａは、システム５０
Ｄ上の回復ファシリティ７０Ｄを用いた回復処理の実行
を定期的に試み、同時にコミットの指令を試みる（ステ
ップ７３０）。上述したように、回復が完了した時、回
復ファシリティ７０Ｄは段階２の“ｃｏｍｍｉｔ”決定
で同期点マネジャ６０Ｄに回答する。同期点マネジャ６
０Ｄは、その段階２の処理を完了し、アプリケーション
５６Ｄにこのコミット要求が成功裡に完了したことを意
味する戻りコード“ＲＣ　＝ＯＫ．　ＡＬＬ＿ＡＧＲＥ
ＥＤ”を戻す（ステップ７３２）。アプリケーション５
６Ｈ、５６Ａおよび５６Ｄは、いずれも他の処理を続行
できる。回復ファシリティ７０Ａと回復ファシリティ７
０Ｄの間で回復処理が行われる時は、回復の開始とその
処理の結果を示すメッセージが、操作員コンソールに送
られることに留意されたい。

【０２３８】また、同期点マネジャ６０Ａは、回復ファ
シリティ７０Ａから“ＦＡＩＬＥＤ　ＡＴＴＥＭＰＴ　
ＴＯ　ＲＥＳＹＮＣ（再同期化の試みに失敗した）”通
知を受け取った時、ログ７２Ａ内のログ・エントリ内の
ＬＵＷＩＤの状態を“Ｆｏｒｇｅｔ，　ＲＩＰ”に更新
することにも留意されたい。システム５０Ａは、後で、
このＬＵＷＩＤに含まれる保護された会話を搬送してい
たシステム５０Ａとシステム５０Ｈの間の会話経路上に
次の正常な流れが到着した時に、このＬＵＷＩＤに“ｆ
ｏｒｇｅｔ”の状態を書き込む。これが“ｉｍｐｌｉｅ
ｄ　ｆｏｒｇｅｔ（暗黙の忘却）”動作である。同期点
マネジャ６０Ａが“Ｆｏｒｇｅｔ，　ＲＩＰ”の状態を
書き込んだ後、“ｉｍｐｌｉｅｄ　ｆｏｒｇｅｔ”を受
け取る前に、システム５０Ａとシステム５０Ｈの間の会
話経路（これを介して、進行中の再同期化の通知を受け
取ったコミット手順に関係していた保護された会話が流
れていた）が働かなくなる障害が生じた場合、システム
５０ＡのＬＵＷＩＤのログ・エントリが、使用される２
段階コミット・パラダイムによって定義される正常な回
復手順によって消去される。ただし、これには、以前に
定義した比較状態データ流れ中で、新規の進行中の再同
期化の標識が送られることが必要となる。“ｉｍｐｌｉ
ｅｄ　ｆｏｒｇｅｔ”が受け取られ、それによってシス
テム５０Ａが回復ファシリティ・ログ７２Ａに“ｆｏｒ
ｇｅｔ”の状態を書き込む場合は、回復ファシリティ７
０Ｄでの回復が完了しない限り、回復ファシリティ７０
Ａはこの回復レコードを実際に忘却させない。

【０２３９】同期点マネジャ間には移送経路があるので
、前述の非同期的再同期化（進行中の再同期化）機能を
サポートする同期点マネジャは、これをサポートしない
他の同期点マネジャと通信できることにも留意されたい
。同期点処理をサポートするシステムが最初に互いに通
信する時は、両方のシステムに使用される通信体系と２
段階コミット手順とによって定義される初期ケイパビリ
ティ交換の際に、これらのシステムが前述の進行中の再
同期化機能をサポートするか否かが決定される。コミッ
ト要求の開始側、図５１の上記の例では同期点マネジャ
６０Ｈが、進行中の再同期化をサポートしない場合には
、カスケード式の開始側（このコミット要求を受け取る
同期点マネジャ、上記の例では同期点マネジャ６０Ａ）
は、このコミット要求を開始した同期点マネジャ（上記
の例では同期点マネジャ６０Ｈ）に、同期点要求の意図
（コミットまたはバックアウト）を送り返すが、再同期
化が後で非同期的に行われるとの指示は送り返さない。 ローカル・アプリケーションは、故障停止が発生し（上
記の例ではアプリケーション５６Ａ）、同期点マネジャ
が進行中の再同期化をサポートする（上記の例では同期
点マネジャ６０Ａ）場合、この進行中の再同期化通知を
受け取る。

【０２４０】図５２は、同期点マネジャ６０Ｈが、以下
で詳細に示すようにバックアウトを発行する場合の進行
中の再同期化の機能を示す図である。ステップ７００〜
７１４は、図５１と同一である。ただし、同期点マネジ
ャ６０Ｈは、ステップ７１６で同期点マネジャ６０Ａか
ら保護会話アダプタ６４Ｈを介して回答“ｒｅｑｕｅｓ
ｔ　ｃｏｍｍｉｔ”を受け取った後に、その保護された
資源のうちの１つまたは複数が動作不能であるために、
バックアウトすることを決定する。そこで、同期点マネ
ジャ６０Ｈは、段階２の決定“ｂａｃｋｏｕｔ”を用い
てその登録された資源を呼び出す。この決定“ｂａｃｋ
ｏｕｔ”が、同期点マネジャ６０Ａに与えられる（保護
会話アダプタ６４Ｈが、体系的システム間ｂａｃｋｏｕ
ｔコールを保護会話アダプタ６４Ｂに送り、保護会話ア
ダプタ６４Ｂが、同期点マネジャ６０Ａに“ｂａｃｋｏ
ｕｔ”と回答する）（ステップ７４０）。 同期点マネジャ６０Ａは、段階２の決定“ｂａｃｋｏｕ
ｔ”でその登録された資源を呼び出す。保護会話アダプ
タ６４Ａは、ステップ７４２で、保護会話アダプタ６４
Ｄを介して同期点マネジャ６０Ｄにシステム間ｂａｃｋ
ｏｕｔコールを送ろうと試みる。ところがこの例では、
通信経路障害またはその他のタイプの障害のために、ス
テップ７４２は失敗する。これに応答して、同期点マネ
ジャ６０Ａは、ステップ７４４で、ＬＵＷＩＤと障害を
発生した資源の識別子とを用いて回復ファシリティ７０
Ａを呼び出し、システム５０Ｄ上の回復ファシリティ７
０Ｄを用いた回復処理を実行させる。しかし、この例で
は、この回復の試みも失敗する。回復ファシリティ７０
Ａは、同期点マネジャ６０Ａに、この回復の試みに失敗
したが、非同期的に回復処理を完了すると回答する。他
の保護された資源からの通知を受けた後に、同期点マネ
ジャ６０Ａは、その回復ファシリティのログ７２Ａに、
“ｂａｃｋｏｕｔ，　ｒｉｐ”の状態を書き込む。その
後、同期点マネジャ６０Ａは、“ｂａｃｋｏｕｔ，　ｒ
ｉｐ”の回答を用いて保護会話アダプタ６４Ｂを呼び出
す。体系的システム間ｂａｃｋｏｕｔコールに基づいて
、保護会話アダプタ６４Ｂは、保護会話アダプタ６４Ｈ
からの元の段階２の“ｂａｃｋｏｕｔ”コールに対して
エラー回答を送る（ステップ７４８）。その後、保護会
話アダプタ６４Ｂは、保護会話アダプタ６４Ｈに、体系
的システム間“ｂａｃｋｏｕｔ，　ｒｉｐ”コールを送
る（ステップ７５０）。保護会話アダプタ６４Ｈは、こ
の“ｂａｃｋｏｕｔ，　ｒｉｐ”の指示を受け取った後
に、体系的システム間肯定応答を送り（ステップ７５２
）、同期点マネジャ６０Ｈに“ｂａｃｋｏｕｔ，　ｒｉ
ｐ”と回答する（ステップ７５２）。同期点マネジャ６
０Ｈは、他の資源からの回答を得た後に、アプリケーシ
ョン５６Ｈに、バックアウトが保留中であることを通知
する戻りコード“ＲＣ　＝　Ｂａｃｋｏｕｔ，　ＬＵＷ
＿ＯＵＴＣＯＭＥ＿ＰＥＮＤＩＮＧ”を戻して、アプリ
ケーション５６Ｈが他の有用な作業を行ってもよいと知
らせる（ステップ７５４）。保護会話アダプタ６４Ｂは
、保護会話アダプタ６４Ｈから“ｂａｃｋｏｕｔ，　ｒ
ｉｐ”コールに対する肯定応答（ステップ７４８および
７５０に対する応答）を得ると、同期点マネジャ６０Ａ
に“ｏｋ”と回答する。その後同期点マネジャ６０Ａは
、回復ファシリティのログ７２Ａ内のこのＬＵＷＩＤ用
のログエントリに“ｆｏｒｇｅｔ”の状態を書き込み、
アプリケーション５６Ａに戻りコード“ＲＣ　＝　Ｂａ
ｃｋｏｕｔ，　ＬＵＷ＿ＯＵＴＣＯＭＥ＿ＰＥＮＤＩＮ
Ｇ”を戻す（ステップ７４６）。この戻りコードは、こ
のコミット要求の意図された結果がバックアウトである
が、すべての資源がバックアウトしたわけではないこと
を意味する。ここでアプリケーション５６Ａは、その処
理を続行できる。回復ファシリティのログ７２Ａ内のＬ
ＵＷＩＤエントリは、上述の“ｉｍｐｌｉｅｄ　ｆｏｒ
ｇｅｔ”としてシステム５０Ａによって忘却される。こ
の“ｆｏｒｇｅｔ”が書き込まれる時、このＬＵＷＩＤ
内の障害を発生した資源がまだ回復されていない場合は
、回復が行われるまでそのＬＵＷＩＤエントリは実際に
は忘却されない。その間に、回復ファシリティ７０Ａは
、システム５０Ｄ内の回復ファシリティ７０Ｄを用いて
非同期的に回復の試みを続ける（ステップ７５６）。回
復が完了した時、同期点マネジャ６０Ｄは、バックアウ
トの通知を受け、その段階２の処理を完了する。その後
同期点マネジャ６０Ｄはアプリケーション５６Ｄに、す
べての資源がバックアウトされたことを意味する戻りコ
ード“ＲＣ　＝　ＢＡＣＫ　ＯＵＴ．　ＡＬＬ＿ＡＧＲ
ＥＥＤ”を戻す（ステップ７５８）。アプリケーション
５６Ｈ、５６Ａおよび５６Ｄは、いずれも他の処理を続
行できる。回復ファシリティ７０Ａと回復ファシリティ
７０Ｄの間で回復処理が行われる際に、回復の開始とそ
の処理の結果を示すメッセージが操作員コンソールに送
られることに留意されたい。

【０２４１】図５３は、同期点マネジャ６０Ａが、以下
で詳細に示すようにバックアウトを発行する場合の進行
中の再同期化の機能を示す図である。ステップ７００〜
７１４は、図５２と同一である。ただし、同期点マネジ
ャ６０Ａは、ステップ７１４で回答“ｒｅｑｕｅｓｔ　
ｃｏｍｍｉｔ”を受け取った後、同期点マネジャ６０Ａ
に関連する資源のうちの１つまたは複数がコミット不能
であるため、段階２の“ｂａｃｋｏｕｔ”コールを用い
てその登録された資源を呼び出す（ステップ７５９）。 保護会話アダプタ６４Ａは、保護会話アダプタ６４Ｄに
体系的システム間“ｂａｃｋｏｕｔ”コールを送ろうと
試みる（ステップ７６０）。 ところが、ステップ７６０に示されるように、通信経路
障害またはその他の障害のため、この“ｂａｃｋｏｕｔ
”コールを保護会話アダプタ６４Ｄは受け取らない。同
期点マネジャ６０Ａは、ＬＵＷＩＤと障害を発生した資
源の識別子とを用いて回復ファシリティ７０Ａを呼び出
し、回復処理を実行するよう求める。回復ファシリティ
７０Ａは、システム５０Ｄ内の回復ファシリティ７０Ｄ
を用いて、回復処理を実行しようと試みる（ステップ７
４４）。通信経路の障害が持続しているので、ステップ
７４４も失敗し、その結果、同期点マネジャ６０Ａは、
図５２を参照して上述したステップ７４６の信号を送る
。 ステップ７５０〜７５８も、図５２と同一である。

【０２４２】図５４は、以下で詳細に示すように異なる
障害のために、同期点マネジャ６０Ａがバックアウトを
発行する場合の進行中の再同期化の機能を示す図である
。ステップ７００〜７０６は、図５２と同一である。 ただし、同期点マネジャ６０Ａは、ステップ７０６でコ
ミット要求を受け取った後に、段階１の“ｐｒｅｐａｒ
ｅ”コールを用いてその登録された資源を呼び出す。保
護会話アダプタ６４Ａは、保護会話アダプタ６４Ｄに体
系的システム間“ｐｒｅｐａｒｅ”コールを送ろうと試
みる（ステップ７０８Ａ）。ところが、ステップ７０８
Ａに示されるように、通信経路の障害またはその他の障
害のために、この“ｐｒｅｐａｒｅ”コールを保護会話
アダプタ６４Ｄは受け取らない。同期点マネジャ６０Ａ
は、段階２のｂａｃｋｏｕｔコールを用いてそのローカ
ルな登録された資源を呼び出す（ステップ７６３）。そ
の後同期点マネジャ６０Ａは、ＬＵＷＩＤと障害を発生
した資源の識別子とを用いて回復ファシリティ７０Ａを
呼び出し、回復処理を実行するよう求める。回復ファシ
リティ７０Ａは、システム５０Ｄ内の回復ファシリティ
７０Ｄを用いて回復処理を実行しようと試みる（ステッ
プ７４４）。通信経路の障害が持続しているので、ステ
ップ７４４も失敗し、その結果、同期点マネジャ６０Ａ
は、図５２を参照して上述したステップ７４６の信号を
送る。ステップ７５０〜７５６は、図５２と同一である
。同期点マネジャ６０Ａによって行われる処理とは非同
期的に、アプリケーション５６Ｄが、以前（アプリケー
ション５６Ａがアプリケーション５６Ｄを開始した時）
に確立されたアプリケーション５６Ａとの保護された会
話上で経路障害の指示を受け取る（ステップ７６１）。 この経路障害のため、保護会話アダプタ６４Ｄは保護会
話アダプタ６４Ａからｐｒｅｐａｒｅコールを受け取れ
なかった。この経路障害は、保護された会話に対して発
生したので、アプリケーション５６Ｄはバックアウト要
求を発行しなければならない。アプリケーション５６Ｄ
は、バックアウト要求を発行し（ステップ７６２）、最
終的に、すべての資源がバックアウトされたことを示す
戻りコードを受け取る（ステップ７６４）。この時点で
、アプリケーション５６Ｈ、５６Ａおよび５６Ｄは、い
ずれも他の処理を続行できる。 その間に、回復ファシリティ７０Ａは、システム５０Ｄ
内の回復ファシリティ７０Ｄを用いて非同期的に回復の
試みを続ける（ステップ７５６）。回復処理が回復ファ
シリティ７０Ａと回復ファシリティ７０Ｄの間で行われ
る際に、回復の開始とその処理の結果を示すメッセージ
が操作員コンソールに送られることに留意されたい。

【０２４３】以上の説明により、本発明を実施する方法
およびシステムが開示された。ただし、本発明の範囲を
逸脱することなく、多数の変更および置換が可能である
。したがって、本発明の開示は、例示的なものであって
、限定的なものではなく、本発明の範囲を決定するには
、頭記の特許請求の範囲を参照すべきである。

【０２４４】以下は、部分的な用語集である。

【０２４５】アプリケーション ある実行環境内で実行され、コミット、バックアウトま
たは作業要求のうちの１つまたは複数を発行できる、ユ
ーザ・プログラムまたはサービス・プログラムまたは資
源マネジャと統合された作業分散機能。

【０２４６】実行環境 仮想計算機、パーソナル・コンピュータ、ワーク・ステ
ーション、ミニ・コンピュータ、メインフレーム・コン
ピュータまたはその他のタイプのコンピュータあるいは
それらの任意の組合せにおいて、アプリケーション、シ
ステム・ファシリティ（回復ファシリティ、通信ファシ
リティなど）、資源マネジャまたはその他のプログラム
あるいはそれらの任意の組合せを実行するための、何ら
かの計算手段。

【０２４７】保護された会話 何らかの形の同期点処理または保護的コミットもしくは
バックアウト手順の対象となる会話。

【０２４８】保護された資源 何らかの形の同期点処理または他の保護的コミットもし
くはバックアウト手順の対象となる資源。

【０２４９】回復ファシリティ 障害を発生した同期点またはその他のコミットもしくは
バックアウト手順の回復の責任を負うファシリティ。

【０２５０】２段階コミット手順 更新または保護会話あるいはその両方の、コミットまた
はバックアウトを調整または同期あるいはその両方を行
うための手順。通常、２段階コミット手順は、保護され
た会話を介して、複数の資源または単一の資源を原子的
にコミットまたはバックアウトするのに使用される。た
とえば、２段階コミット手順には、ポーリングまたは準
備段階と、バックアウトまたはコミット段階を含めるこ
とができる。

【２５１】

【発明の効果】本発明は、同期点処理のための資源の登
録を提供するコンピュータ・システムを提供する。資源
には、ファイル・システム、データ・ベースおよび保護
された会話が含まれる。資源は、アプリケーションの実
行環境に登録された時に、システムによって保護される
ようになる。

【図面の簡単な説明】

【図１】各実行環境内にすべてのコミット機能と回復機
能を組み込んだ、従来技術によるコンピュータ・システ
ムのブロック図である。

【図２】本発明による、２つの相互接続されたコンピュ
ータ・システムを含むコンピュータ・ネットワークのブ
ロック図である。各システムは、共通の回復ファシリテ
ィとログで複数の実行環境をサポートする。

【図３】図２の実行環境内で実行されるアプリケーショ
ンによって使用される資源に関する、２段階コミット手
順の流れ図である。

【図４】図３に示した２段階コミット手順中に割込みが
発生する時に実施される、回復処理の流れ図である。

【図５Ａ】図２の同期点ファシリティをサポートする保
護された会話によって接続された、２つの分散アプリケ
ーション環境内で実行されるパートナ・アプリケーショ
ンによって使用される資源に関する、２段階コミット手
順の流れ図である。

【図５Ｂ】図２の同期点ファシリティをサポートする保
護された会話によって接続された、２つの分散アプリケ
ーション環境内で実行されるパートナ・アプリケーショ
ンによって使用される資源に関する、２段階コミット手
順の流れ図である。

【図６】単一の図２の実行環境内で異なるコミット範囲
を定義する複数の作業ユニットと、図２の複数のシステ
ムにまたがるコミット範囲とを示す、ブロック図である
。

【図７】コミット処理の範囲を定義し、コミット処理を
容易にするための、図２の１つのアプリケーション環境
による、ローカル作業ユニットとグローバルな作業論理
ユニットの使用を示す、流れ図である。

【図８Ａ】コミット処理の範囲を定義し、コミット処理
を容易にするための、図２のもう１つの関連するアプリ
ケーション環境による、ローカル作業ユニットとグロー
バルな作業論理ユニットの使用を示す、流れ図である。

【図８Ｂ】コミット処理の範囲を定義し、コミット処理
を容易にするための、図２のもう１つの関連するアプリ
ケーション環境による、ローカル作業ユニットとグロー
バルな作業論理ユニットの使用を示す、流れ図である。

【図９】図７および図８のグローバルな作業論理ユニッ
トにおける、保護された会話のタイミング図である。

【図１０】図２のシステム内での資源の自動的かつ総称
的な登録を示す、ブロック図である。

【図１１】図６の同期点マネジャ内に適当なタイプのコ
ミット手順用の資源を登録する手順と、そのコミット手
順のステップとを示す、流れ図である。

【図１２】図２のシステム内での作業ユニットに基づく
登録を示す、ブロック図である。

【図１３】作業ユニットに基づく登録を示す、銀行取引
の時間の流れを示す図である。

【図１４】同期点マネジャで、資源を登録し、資源の登
録情報を変更し、資源を登録解除する手順を示す、流れ
図である。

【図１５】資源アダプタ、保護会話アダプタおよび同期
点マネジャが、資源の登録を解除するのに使用する手順
を示す、流れ図である。

【図１６】同期点要求に応答して同期点マネジャが行う
処理と、１段階コミット処理か２段階コミット処理かを
選択する際に同期点マネジャが行う最適化とを示す、流
れ図である。

【図１７】２段階コミット手順を示す、流れ図である。

【図１８】２段階コミット手順に参加する３つの分散ア
プリケーション・プログラムを示す、流れ図である。

【図１９】図２のあるシステム内のアプリケーションと
別のシステム内のパートナ・アプリケーションの間で保
護された会話が行われる時に、障害を発生したコミット
手順の回復をサポートするためのログ名交換に用いる構
成要素と手順を示す、ブロック図である。

【図２０】通信ファシリティによる、初期の事象とその
後の会話事象のための図１９に関連する処理の流れ図で
ある。

【図２１Ａ】ローカル通信ファシリティが回復ファシリ
ティにある経路用のログ名を交換するよう要求した時に
、その結果として生じる、回復ファシリティによる、図
１９に関連する処理の流れ図である。

【図２１Ｂ】ローカル通信ファシリティが回復ファシリ
ティにある経路用のログ名を交換するよう要求した時に
、その結果として生じる、回復ファシリティによる、図
１９に関連する処理の流れ図である。

【図２２】別の回復ファシリティからログ名交換要求を
受け取った結果として生じる、回復ファシリティによる
、図１９に関連する処理の流れ図である。

【図２３】図２の一部における、ローカル資源マネジャ
を用いログ名交換のための構成要素と手順を示す、ブロ
ック図である。

【図２４】図２のシステムとリモート資源マネジャを使
用するログ名交換のための構成要素と手順を示す、ブロ
ック図である。

【図２５】図２の回復ファシリティの内容を示す、ブロ
ック図である。

【図２６】ログ名の交換を実施すべき時点を決定する処
理を示す、流れ図である。

【図２７】参加する資源マネジャと回復ファシリティの
間でログ名を交換するための処理を示す、流れ図である
。

【図２８】同期点ログの可搬性とバックアップ回復ファ
シリティを活動化する能力を示す、ブロック図である。

【図２９】コミット手順における問題を定義するエラー
・フラグおよび情報をアプリケーション・プログラムに
渡す際の、図２の資源アダプタと同期点マネジャの参加
を示す、ブロック図である。

【図３０】図２９の構成要素を使ってアプリケーション
・プログラムにエラー情報を渡す手順を示す、流れ図で
ある。

【図３１】システムの作業用記憶域を減らすために、図
２９に関連するエラー・ブロックが使用するページを共
用するための、制御ブロック構造を示す図である。

【図３２】図２９のエラー・フラグおよび情報の生成と
管理に参加する、図２の構成要素のブロック図である。

【図３３】開始側アプリケーションと同一のシステムお
よび異なるシステムに常駐する資源マネジャと、コミッ
ト処理中に使用される通信経路ならびに同期点回復処理
のために使用される経路を組み込んだ、複数のシステム
・コミット範囲にわたるコミット・サイクルを含む、３
つのシステムを示す、ブロック図である。

【図３４】同期点参加者のツリーを形成する、図３３の
３つの参加するアプリケーションおよびアプリケーショ
ン環境とそれらが使用する資源マネジャとを示す、ブロ
ック図である。

【図３５】回復ファシリティの、同期点以前の同意の手
順と同期点障害からの回復の手順を示す、高水準の流れ
図である。

【図３６】同期点障害からの回復のための回復ファシリ
ティの手順をより詳細に示す、流れ図である。

【図３７】図２のログ７２の内容と、図３５で表される
手順を制御するのに必要な制御構造とを示す、ブロック
図である。

【図３８】図３５のステップ２９９および３００の詳細
を示す流れ図である。

【図３９】図３５のステップ３０１および３０２の詳細
を示す流れ図である。

【図４０】図３６のステップ３１１の詳細を示す流れ図
である。

【図４１】図３６のステップ３１２の詳細を示す流れ図
である。

【図４２】図３６のステップ３１３の詳細を示す流れ図
である。

【図４３】図３６のステップ３１４の詳細を示す流れ図
である。

【図４４】図３６のステップ３１５の詳細を示す流れ図
である。

【図４５】図３６のステップ３０４の詳細を示す流れ図
である。

【図４６Ａ】図３６のステップ３１７の詳細を示す流れ
図である。

【図４６Ｂ】図３６のステップ３１７の詳細を示す流れ
図である。

【図４７】図３６のステップ３１８の詳細を示す流れ図
である。

【図４８Ａ】図３６のステップ３１９の詳細を示す流れ
図である。

【図４８Ｂ】図３６のステップ３１９の詳細を示す流れ
図である。

【図４９】図３６のステップ３０６の詳細を示す流れ図
である。

【図５０Ａ】同期点処理中にエラーが発生した場合に、
アプリケーション５６Ａおよびアプリケーション５６Ｄ
が非同期的再同期化を要求する様子を示すブロック図で
ある。

【図５０Ｂ】同期点処理中にエラーが発生した場合に、
アプリケーション５６Ａおよびアプリケーション５６Ｄ
が非同期的再同期化を要求する様子を示すブロック図で
ある。

【図５１】追加のシステム５０Ｈを伴う、非同期的な進
行中の再同期化のステップを示す、流れ図である。

【図５２】システム５０Ｈから発する障害を発生したバ
ックアウト指令に関係する、非同期的な進行中の再同期
化のステップを示す、流れ図である。

【図５３】システム５０Ａから発する障害を発生したバ
ックアウト指令に関係する、非同期的な進行中の再同期
化のステップを示す、流れ図である。

【図５４】システム５０Ａから発する障害を発生したｐ
ｒｅｐａｒｅコールに関係する、非同期的な進行中の再
同期化のステップを示す、流れ図である。

【図５５Ａ】図２の代替例としての、本発明のもう１つ
の実施例のブロック図である。

【図５５Ｂ】図２の代替例としての、本発明のもう１つ
の実施例のブロック図である。

【符号の説明】

５０　　システム ５２　　アプリケーション実行環境 ５３　　会話マネジャ ５５　　システム制御プログラム ５６　　アプリケーション ６０　　同期点マネジャ（ＳＰＭ） ６２　　資源アダプタ ６３　　資源マネジャ ６４　　保護会話アダプタ ７０　　回復ファシリティ ７２　　ログ

Claims (45)

【特許請求の範囲】
1. 【請求項１】第１資源と第２資源を必要とする作業要求
   を行うアプリケーションを実行する実行環境手段と、前
   記第１資源および第２資源のためのコミット手順を制御
   する同期点マネジャ手段と、前記アプリケーションをサ
   ポートし、前記アプリケーションの作業要求に応答して
   、前記第１資源および第２資源が前記コミット手順に用
   いられることを示す、前記第１資源および第２資源のた
   めの登録を自動的に行う手段とを備える、コンピュータ
   ・システムまたはネットワーク。
2. 【請求項２】前記同期点マネジャ手段が、前記実行環境
   手段内にあることを特徴とする、請求項１に記載のコン
   ピュータ・システムまたはネットワーク。
3. 【請求項３】登録手段が、前記実行環境内で前記登録を
   行うことを特徴とする、請求項１に記載のコンピュータ
   ・システムまたはネットワーク。
4. 【請求項４】登録手段が、１段階コミット手順のために
   前記第１資源を登録し、２段階コミット手順のために前
   記第２資源を登録する手段を含むことを特徴とする、請
   求項１に記載のコンピュータ・システムまたはネットワ
   ーク。
5. 【請求項５】登録手段が、前記アプリケーションの作業
   要求の実行のみに応答して、前記第１資源と第２資源を
   登録することを特徴とする、請求項１に記載のコンピュ
   ータ・システムまたはネットワーク。
6. 【請求項６】前記登録手段が、前記第１資源用の第１資
   源アダプタと前記第２資源用の第２資源アダプタを備え
   、前記第１資源アダプタと第２資源アダプタが、前記実
   行環境手段内にあることを特徴とする、請求項５に記載
   のコンピュータ・システムまたはネットワーク。
7. 【請求項７】登録手段が、前記アプリケーションによっ
   て行われる作業要求の種類に基づいて、１段階または２
   段階のどちらかのコミット手順のために各資源を登録す
   ることを特徴とする、請求項１に記載のコンピュータ・
   システムまたはネットワーク。
8. 【請求項８】登録手段が、前記資源の特性に基づいて、
   １段階または２段階のどちらかのコミット手順のために
   各資源を登録することを特徴とする、請求項１に記載の
   コンピュータ・システムまたはネットワーク。
9. 【請求項９】登録手段が、必要なコミット手順の種類の
   変更を示すように前記第１資源または第２資源のための
   登録を変更する手段を含むことを特徴とする、請求項７
   に記載のコンピュータ・システムまたはネットワーク。
10. 【請求項１０】登録手段が、前記第１資源用の他の登録
    情報を保持したままで前記第１資源用の一部の登録情報
    を変更する手段を含むことを特徴とする、請求項１に記
    載のコンピュータ・システムまたはネットワーク。
11. 【請求項１１】実行環境と、第１コミット範囲に対する
    第１作業ユニットの下で第１の複数の資源を登録する手
    段と、第２コミット範囲に対する第２作業ユニットの下
    で第２の資源を登録する手段と、登録にアクセスして、
    前記第１の複数の資源のために第１コミット手順を実行
    し、前記第２の資源のために第２コミット手順を実行す
    る手段とを備える、コンピュータ・システム。
12. 【請求項１２】コミット手順実行手段が、前記実行環境
    内にあることを特徴とする、請求項１１に記載のコンピ
    ュータ・システム。
13. 【請求項１３】両方の登録手段が、前記実行環境内で実
    行中のアプリケーションによってなされた作業要求に応
    答して、前記第１の複数の資源と前記第２の資源を登録
    することを特徴とする、請求項１１に記載のコンピュー
    タ・システム。
14. 【請求項１４】登録手段が、前記第１の複数の資源用の
    少なくとも１つの資源アダプタと、前記第２の資源用の
    別の資源アダプタを備え、前記資源アダプタが、前記実
    行環境内にあることを特徴とする、請求項１１に記載の
    コンピュータ・システム。
15. 【請求項１５】前記の各登録手段がそれぞれ、前記アプ
    リケーションによる作業要求に応答してそれぞれの資源
    を登録すること、および後続の作業要求に対して同一の
    資源に対する登録を回避する手段を含むことを特徴とす
    る、請求項１１に記載のコンピュータ・システム。
16. 【請求項１６】コミット手順実行手段が、前記第１コミ
    ット手順を実行すること、および前記第１資源を含むコ
    ミット要求に応答した前記第２コミット手順の実行を回
    避する手段を含むことを特徴とする、請求項１１に記載
    のコンピュータ・システム。
17. 【請求項１７】登録が、前記実行環境内の登録簿に行わ
    れることを特徴とする、請求項１１に記載のコンピュー
    タ・システム。
18. 【請求項１８】コミット手順実行手段が、登録解除され
    た資源の識別を、後で登録から消去する手段を含むこと
    を特徴とする、請求項１７に記載のコンピュータ・シス
    テム。
19. 【請求項１９】登録手段が、前記第１の複数の資源のう
    ちの１つへの接続の喪失に応答して、第１作業ユニット
    の登録から前記１つの資源を自動的に登録解除すること
    を特徴とする、請求項１７に記載のコンピュータ・シス
    テム。
20. 【請求項２０】前記第１資源と第２資源が同一の種類で
    あることを特徴とする、請求項１に記載のコンピュータ
    ・システムまたはネットワーク。
21. 【請求項２１】第１資源と第２資源を必要とする作業要
    求を行うアプリケーションの実行を制御する手段と、前
    記第１資源および第２資源のためのコミット手順を制御
    する同期点マネジャ手段と前記アプリケーションから分
    離しており、前記アプリケーションの作業要求に応答し
    て、前記第１資源および第２資源が前記コミット手順に
    用いられることを示す、前記第１資源および第２資源の
    ための登録を自動的に行う手段とを備え、コンピュータ
    可読媒体を有するコンピュータ・システム。
22. 【請求項２２】前記同期点マネジャ手段が、前記実行制
    御手段と同じ所にあることを特徴とする、請求項２１に
    記載のコンピュータ・システム。
23. 【請求項２３】登録手段が、前記実行制御手段内で前記
    登録を行うことを特徴とする、請求項２１に記載のコン
    ピュータ・システム。
24. 【請求項２４】登録手段が、１段階コミット手順のため
    に前記第１資源を登録し、２段階コミット手順のために
    前記第２資源を登録する手段を含むことを特徴とする、
    請求項２１に記載のコンピュータ・システム。
25. 【請求項２５】登録手段が、前記アプリケーションの作
    業要求の実行のみに応答して、前記第１資源と第２資源
    を登録することを特徴とする、請求項２１に記載のコン
    ピュータ・システム。
26. 【請求項２６】前記登録手段が、前記第１資源用の第１
    資源アダプタと前記第２資源用の第２資源アダプタを備
    え、前記第１資源アダプタと第２資源アダプタが、前記
    実行制御手段と同じ所にあることを特徴とする、請求項
    ２５に記載のコンピュータ・システム。
27. 【請求項２７】登録手段が、前記アプリケーションによ
    って行われる作業要求の種類に基づいて、１段階または
    ２段階のどちらかのコミット手順のために各資源を登録
    することを特徴とする、請求項２１に記載のコンピュー
    タ・システム。
28. 【請求項２８】登録手段が、前記資源の特性に基づいて
    、１段階または２段階のどちらかのコミット手順のため
    に各資源を登録することを特徴とする、請求項２１に記
    載のコンピュータ・システム。
29. 【請求項２９】登録手段が、必要なコミット手順の種類
    の変更を示すように前記第１資源または第２資源のため
    の登録を変更する手段を含むことを特徴とする、請求項
    ２７に記載のコンピュータ・システム。
30. 【請求項３０】登録手段が、前記第１資源用の他の登録
    情報を保持したままで前記第１資源用の一部の登録情報
    を変更する手段を含むことを特徴とする、請求項２１に
    記載のコンピュータ・システム。
31. 【請求項３１】実行環境内でのアプリケーションの実行
    を制御する手段と、第１コミット範囲に対する第１作業
    ユニットの下で第１の複数の資源を登録する手段と、第
    ２コミット範囲に対する第２作業ユニットの下で第２の
    資源を登録する手段と、登録にアクセスして、前記第１
    の複数の資源のために第１コミット手順を実行し、前記
    第２の資源のために第２コミット手順を実行するための
    手段とを備え、コンピュータ可読媒体を有するコンピュ
    ータ・システム。
32. 【請求項３２】コミット手順実行手段が、前記実行制御
    手段と同じ所にあることを特徴とする、請求項３１に記
    載のコンピュータ・システム。
33. 【請求項３３】両方の登録手段が、前記アプリケーショ
    ンによってなされた作業要求に応答して、前記第１の複
    数の資源と前記第２の資源を登録することを特徴とする
    、請求項３１に記載のコンピュータ・システム。
34. 【請求項３４】登録手段が、前記第１の複数の資源用の
    少なくとも１つの資源アダプタと、前記第２の資源用の
    別の資源アダプタを備え、前記資源アダプタが、前記実
    行制御手段と同じ所にあることを特徴とする、請求項３
    １に記載のコンピュータ・システム。
35. 【請求項３５】前記の各登録手段がそれぞれ、前記アプ
    リケーションによる作業要求に応答してそれぞれの資源
    を登録すること、および後続の作業要求に対して同一の
    資源に対する登録を回避する手段を含むことを特徴とす
    る、請求項３１に記載のコンピュータ・システム。
36. 【請求項３６】コミット手順実行手段が、前記第１コミ
    ット手順を実行すること、および前記第１資源を含むコ
    ミット要求に応答した前記第２コミット手順の実行を回
    避する手段を含むことを特徴とする、請求項３１に記載
    のコンピュータ・システム。
37. 【請求項３７】コミット手順実行手段が、前記登録手段
    による前記資源のうちの１つを登録解除するようにとの
    要求に応答して、登録内の前記の登録解除された資源の
    同一性を保持しながら、前記登録簿内に登録解除マーカ
    を作成する手段を含むことを特徴とする、請求項３１に
    記載のコンピュータ・システム。
38. 【請求項３８】コミット手順実行手段が、登録解除され
    た資源の識別を後で登録から消去する手段を含むことを
    特徴とする、請求項３７に記載のコンピュータ・システ
    ム。
39. 【請求項３９】登録手段が、前記第１の複数の資源のう
    ちの１つへの接続の喪失に応答して、第１作業ユニット
    の登録から前記１つの資源を自動的に登録解除すること
    を特徴とする、請求項３７に記載のコンピュータ・シス
    テム。
40. 【請求項４０】前記同期点マネジャ手段が、登録手段ま
    たは前記アプリケーションのいずれかによる前記資源の
    うちの１つを登録解除するようにとの要求に応答して、
    前記登録簿内に登録解除エントリを作成する手段を含む
    ことを特徴とする、請求項１に記載のコンピュータ・シ
    ステムまたはネットワーク。
41. 【請求項４１】前記同期点マネジャ手段が、登録解除さ
    れた資源の識別を後で登録から消去する手段を含むこと
    を特徴とする、請求項４０に記載のコンピュータ・シス
    テムまたはネットワーク。
42. 【請求項４２】前記同期点マネジャ手段が、前記資源の
    うちの１つへの接続の喪失に応答して、登録から前記１
    つの資源を自動的に登録解除することを特徴とする、請
    求項４０に記載のコンピュータ・システムまたはネット
    ワーク。
43. 【請求項４３】前記第１資源が保護された会話であるこ
    とを特徴とする、請求項１に記載のコンピュータ・シス
    テムまたはネットワーク。
44. 【請求項４４】登録手段が、前記作業要求に応答して、
    一律な手順を用いて様々な前記資源を自動的に登録する
    ことを特徴とする、請求項１に記載のコンピュータ・シ
    ステムまたはネットワーク。
45. 【請求項４５】コミット手順実行手段が、前記登録手段
    による前記資源のうちの１つを登録解除するようにとの
    要求に応答して、登録内の前記の登録解除された資源の
    識別を保持しながら、前記登録簿内に登録解除マーカを
    作成する手段を含むことを特徴とする、請求項１７に記
    載のコンピュータ・システム。