JPH1115786A - トランザクション処理システムにおける端末状態管理方法及びコンピュータ読み取り可能な記録媒体 - Google Patents

Abstract

(57)【要約】 【課題】 同一端末にかかる複数トランザクション(TR)
の同時実行拒否などの制御の為に必要な端末状態の管理
をできるだけファイルＩ／Ｏ無しに実現する。 【解決手段】 複数のホスト10で共有される通信処理装
置12において、各端末11毎に、そのTRが何れのホスト10
でも未実行か否かをメモリ上の通信状態123 で管理し、
未実行でない端末からの接続要求及び入力メッセージを
拒否する。ホスト10側でも各端末毎に、そのTRを実行し
ているホストを各ホストTR実行BM1516で管理し、また負
荷分散等によりその端末のTRが任意のホストで実行され
る可能性があることをTR実行状態1516で管理する。そし
て、TR実行可能状態1513を各ホストTR実行BM1516の全ビ
ットがリセットされ且つTR実行状態1516が未実行となっ
た時点で未接続に設定する。通信処理装置12から或る端
末の接続要求を受けたホストにおいて、その端末に対応
するTR実行可能状態1513が未接続でなければ接続を拒否
する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明はトランザクション処
理システムにおける端末状態管理方法に関し、特にトラ
ンザクション処理システムがファイル共有型疎結合クラ
スタシステム上に構築されている場合に好適な端末状態
管理方法に関する。

【０００２】

【従来の技術】トランザクションは、業務処理の実行単
位であり、端末からの１件の入力メッセージに対するホ
ストコンピュータ上の業務処理プログラムの実行の開始
から終了までの処理の範囲に相当する。端末は、ログイ
ンコマンド等によってトランザクション処理システムに
接続した後、例えば問い合わせトランザクションのため
のメッセージを入力することができる。メッセージを入
力してから応答が返されるまでの間は、トランザクショ
ン処理中の状態であり、次のメッセージは入力できな
い。若し、トランザクション処理中の状態で次のメッセ
ージが端末から入力された場合、トランザクション処理
システムはそのメッセージの受け付けを拒否する。

【０００３】このような同一端末にかかる複数トランザ
クションの同時実行を拒否する理由は、例えば、トラン
ザクション１の実行中に次のトランザクション２を受け
付けると、トランザクション１の更新前のデータをトラ
ンザクション２で参照する可能性があり、端末ユーザは
トランザクション２の結果で未更新状態というのを信じ
て次のトランザクション３で二重更新を行ってしまう危
険性があり、そのような運用ミスを防止するためであ
る。

【０００４】このため１台のホストコンピュータ上に構
築された従来のトランザクション処理システムでは、個
々の端末毎の端末状態（トランザクションの実行状態）
をメモリ上で管理し、同一端末にかかる複数トランザク
ションの同時実行を拒否している。

【０００５】

【発明が解決しようとする課題】ところで、最近におい
ては１台のホストコンピュータ上ではなく、ファイル装
置および通信処理装置を共有する複数のホストコンピュ
ータで構成されたファイル共有型疎結合クラスタシステ
ム上にトランザクション処理システムを構築することが
行われている。このようなトランザクション処理システ
ム（以下、クラスタ型トランザクション処理システムと
称す）では、例えば特願平７−３２１０２５号に示され
るように、各ホストコンピュータのトランザクション処
理の負荷を分散したり、例えば特願平７−２７６６５２
号に示されるように、何れかのホストコンピュータでシ
ステム障害が発生しても、一旦受け付けたメッセージは
その他のホストコンピュータで代替処理するようにして
いる。

【０００６】このようなクラスタ型トランザクション処
理システムにおいても、同一端末にかかる複数トランザ
クションの同時実行は拒否する必要がある。しかし、ホ
ストコンピュータ間で共有されるのはメモリではなく、
ファイル装置であるため、単一ホストコンピュータ上に
構築された従来のトランザクション処理システムで採用
されていた技術をそのまま適用すると、ホストコンピュ
ータ間の共有ファイル上で個々の端末毎の端末状態を管
理する構成となってしまう。これでは、ファイルＩ／Ｏ
によるオーバヘッドが非常に大きくなり、処理性能が極
端に低下してしまう。

【０００７】本発明はこのような事情に鑑みて提案され
たものであり、その目的は、同一端末にかかる複数トラ
ンザクションの同時実行拒否などの制御の為に必要な端
末状態の管理を、できるだけファイルＩ／Ｏ無しに実現
することにある。

【０００８】

【課題を解決するための手段】本発明は上記の目的を達
成するために、ファイル装置および通信処理装置を共有
する複数のホストコンピュータで構成されたファイル共
有型疎結合クラスタシステム上に構築されたトランザク
ション処理システムにおいて、通信処理装置において、
各端末毎に、その端末にかかるトランザクションが何れ
のホストコンピュータでも未実行か否かをメモリ上の
「通信状態」において管理し、「通信状態」が未実行で
ない端末からの接続要求および入力メッセージを通信処
理装置において拒否する。

【０００９】通信処理装置は複数のホストコンピュータ
の窓口となっているため、通信処理装置のメモリ上で個
々の端末装置の状態（トランザクション実行状態）を管
理することで、ファイルＩ／Ｏ無しに、同一端末にかか
る複数トランザクションの同時実行拒否の制御が可能と
なる。

【００１０】通信処理装置は、トランザクション完了メ
ッセージが何れかのホストコンピュータから返却された
時点で該当する端末の「通信状態」を未実行にし、端末
からの入力メッセージを受け付けた時点でその端末の
「通信状態」をトランザクション実行中とする。また、
通信処理装置は、トランザクション完了メッセージの待
ち合わせ中に全ホストコンピュータとの間にパス障害が
発生した場合およびタイムアウトが生じた場合、いつま
でもホストコンピュータからの応答を待ちつづけること
はできないため、該当する端末の「通信状態」を未実行
にし、その端末との接続を切断する。切断されれば、端
末ユーザは再接続を試みるが、実際には先に投入された
メッセージはホストコンピュータで受け付けられている
かも知れないし、実行がまだ継続しているかも知れな
い。このような場合に、端末の「通信状態」が未実行で
あることだけで再接続を認めると、同一端末にかかる複
数トランザクションの同時実行の危険性がある。

【００１１】そこで、本発明はこのような場合にも対処
し得るようにするために、ホストコンピュータ側でも端
末の状態を管理する。即ち、ファイル装置上のグローバ
ル端末状態ファイルに各端末毎に設けた端末状態管理レ
コード中の、各ホストコンピュータと１対１に対応する
ビットから構成されるビットマップの各ビットを、その
ビットに対応するホストコンピュータがその端末の接続
要求を処理するか或いはその端末から最初の入力メッセ
ージを受けた時点でセットし、そのビットに対応するホ
ストコンピュータがその端末のトランザクション処理を
実行しておらずその端末と切断状態となった時点でリセ
ットすることにより、各端末毎に、その端末のトランザ
クションを実行している可能性のあるホストコンピュー
タを前記ビットマップで管理する。また、前記端末状態
管理レコード中に設けた「トランザクション実行状態」
を、その端末の入力メッセージを前記グローバルメッセ
ージキューファイルに格納した時点で未実行以外に設定
し、その入力メッセージにかかるトランザクションの実
行が何れかのホストコンピュータで完了した時点で未実
行に設定することにより、各端末毎に、その端末のトラ
ンザクションが何れかのホストコンピュータで実行され
る可能性があるか否かを管理する。そして、端末状態管
理レコード中に設けた「トランザクション実行可能状
態」を、何れかのホストコンピュータがその端末からの
接続要求を受け付けた時点で接続に設定し、前記ビット
マップの全ビットがリセットされ且つ前記「トランザク
ション実行状態」が未実行となった時点で未接続に設定
し、通信処理装置から或る端末の接続要求を受けたホス
トコンピュータにおいて、その端末に対応する前記端末
状態管理レコード中の「トランザクション実行可能状
態」が未接続でなければ接続を拒否する。

【００１２】また、端末状態管理レコード中の「トラン
ザクション実行状態」を、その端末の入力メッセージを
前記グローバルメッセージキューファイルに格納した時
点で未実行以外に設定する前述の処理は、その処理途中
でシステム障害が発生した場合に何れの状態でシステム
障害が発生したかを復旧処理で容易に確認し得るように
するために、新たに採番したシーケンス番号をグローバ
ルメッセージキューファイルに書き込んで「トランザク
ション実行状態」をグローバルメッセージキュー書き込
み開始に設定し、次いで、入力メッセージを前記グロー
バルメッセージキューファイルに書き込むと共に前記シ
ーケンス番号を自ホスト対応のメッセージ順序番号ファ
イルに書き込んで両書き込みをコミットし、次いで、
「トランザクション実行状態」をグローバルメッセージ
キュー書き込み完了に設定する処理を含んでいる。

【００１３】更に本発明では、何れかのホストコンピュ
ータに障害が発生した場合、その障害発生ホストコンピ
ュータが受け持っていた未処理の入力メッセージを前記
グローバルメッセージキューファイルに格納することで
正常な他のホストコンピュータによる代替処理を可能と
した後、その障害発生ホストコンピュータに対応するビ
ットマップのビットをリセットすると共に、その障害発
生ホストコンピュータで処理の完了していたメッセージ
を認識して該当する端末の端末状態管理レコード中の
「トランザクション実行状態」を未実行に設定すること
で、いずれかのホストコンピュータに障害が発生した場
合でも、端末状態の管理状態を正しく補正し、再接続を
可能にしている。

【００１４】

【発明の実施の形態】次に本発明の実施の形態の例につ
いて図面を参照して詳細に説明する。

【００１５】図１を参照すると、本発明を適用したファ
イル共有型疎結合クラスタシステムの一実施の形態は、
複数のホストコンピュータ10が、通信処理装置12と、ホ
ストコンピュータ間の状態管理やメッセージ保証のため
の各種ファイルを持つファイル装置であるホスト間共有
高速メモリ媒体15とを共有しており、また、各ホストコ
ンピュータ10には、ホスト間共有高速メモリ媒体15上の
ファイルのアクセスをレコード単位もしくはファイル単
位で排他制御するための排他管理装置16と、ホストコン
ピュータ10間で制御情報のやりとりを行うためのホスト
間通信装置13と、ホストコンピュータ10のシステム障害
を検出する CPU監視装置14とが接続されている。ユーザ
が使用する複数の端末装置11は、通信処理装置12を通じ
て各ホストコンピュータ10と接続される。

【００１６】通信処理装置12は、各ホストコンピュータ
10との間に通信パス（以降、パスと略す）を開設してお
り、そのパスごとに、通信処理装置12内の図示しないメ
モリ上で、自装置からの要求メッセージをホストコンピ
ュータ10側で区別させるためのシーケンス番号121 を記
録して管理している。また、接続する端末装置11ごと
に、トランザクションの実行状態を管理するための通信
状態123 と、後述するトランザクション負荷分散機構10
1 で採番管理され通知される接続世代番号124 とを同メ
モリ上に記録して管理している。さらに各種タイマー制
御を司るタイマー監視機構126 を有している。

【００１７】ホスト間共有高速メモリ媒体15は、各ホス
トコンピュータ10で共有制御される各種ファイルを配置
するメモリ媒体機構である。ディスク媒体より、高速な
アクセスが可能であるが、ディスクほど大きな容量がと
れないという特徴をもつ。また、ホストコンピュータが
システム障害となった場合でも、ホスト間共有高速メモ
リ媒体15自身が障害となることはないことが必要であ
る。

【００１８】このホスト間共有高速メモリ媒体15には、
以下のような４種類のファイルが格納されている。

【００１９】○GTSF（グローバル端末状態ファイル）15
1;このGTSF151 は、各端末に１対１に対応する端末状態
管理レコードを有し、端末ごとの情報をそのレコードに
保持している。アクセス時には、排他管理装置16によっ
て１レコードごとにホストコンピュータ10間で排他制御
される。

【００２０】GTSF151 の個々のレコードは、当該レコー
ドを検索するための端末名1511と、当該端末と接続する
毎に更新される接続世代番号1512と、端末の接続が許可
されたかもしくは切断処理中かといった端末状態を管理
するためのトランザクション実行可能状態1513と、トラ
ンザクション実行可能である場合の接続業務名1514と、
各ホストコンピュータ10でトランザクションが実行され
ている可能性があることを示す、各ホストコンピュータ
対応のビットから構成される各ホストトランザクション
実行ビットマップ1515と、負荷分散等によっていずれか
のホストコンピュータ10でトランザクションが実行中で
あることを示すトランザクション実行状態1516と、トラ
ンザクション実行状態1516で実行中であるときのシステ
ム障害時に、まさにその実行中であったトランザクショ
ンが完了したのかどうかを識別するためのトランザクシ
ョン実行番号1517と、トランザクション受付処理中にシ
ステム障害が発生したときに、その受付メッセージは確
かに受け取っているのか、受け取られていないかを判断
するためのホストID15181 およびシーケンス番号15182
で構成される重送チェック情報1518とを有する。

【００２１】GMQF（グローバルメッセージキューファイ
ル）152;このGMQF152 は、ホストコンピュータ10が高負
荷である場合に、他のホストコンピュータ10に受信メッ
セージを回すための、メッセージの先入れ先出し機能を
もつキューイングファイルであり、ホストコンピュータ
10間で共有される。複数のホストコンピュータ10間でひ
とつ存在し、複数のメッセージを格納し、もしくは格納
した順番に取り出すというキューイングを行うことがで
きる。このファイルは排他管理装置16によって、ファイ
ルごとに排他制御される。すなわちいずれかのホストコ
ンピュータ10の各処理においてアクセスしている処理が
ある場合、コミットするまでは他のアクセスは待ち合わ
せられる。

【００２２】STCF（スケジュールトランザクション制御
ファイル）153;このSTCF153 は、ホストコンピュータ10
ごとに、実行しようとするトランザクションの受信メッ
セージおよび処理完了したメッセージを格納するファイ
ルである。後述するように、トランザクションが実行さ
れる前に或るホストコンピュータがシステム障害になっ
たときに、メッセージ復旧機構105 によってその障害ホ
ストコンピュータに対応するSTCF153 の内容をGMQF152
に移すことで、トランザクションの再実行を行わせるな
どの制御が行われる。STCF153 はその最終レコードにラ
ストレコード1531をもつ。このラストレコード1531は、
ラストレコードであるということを示すレコードタイプ
15311 と、そのSTCF153 を処理しているホストコンピュ
ータ10の自ホストID107 を格納するホストID15312 で構
成される。

【００２３】MSNF（メッセージ順序番号ファイル）154;
このMSNF154 は、通信処理装置12からパス経由で受け付
けたメッセージのシーケンス番号1541をホストコンピュ
ータ毎に格納しておくファイルである。ホストコンピュ
ータ10の障害発生時のメッセージ処理状態の確認や、通
信処理装置12がタイムアウトやパス障害を認識したとき
のメッセージ処理状態の確認に使用される。

【００２４】STCF153 ならびにMSNF154 は、各ホストコ
ンピュータ10ごとに存在するが、システム障害時やパス
障害が発生したときに、別ホストコンピュータ10用の内
容を参照更新することがあるため、やはり排他管理装置
16で排他制御される。STCF153 は、レコードごとに排他
制御される。

【００２５】ただし、STCF153 は、システム障害時のみ
他ホストコンピュータ10のメッセージ復旧機構105 から
アクセスされるため、システム障害時には元のホストコ
ンピュータ10から切り離して、復旧するホストコンピュ
ータ10に取り込んでからメッセージ復旧機構105 にてア
クセスし、終わったら元に戻すという手順を踏めば、排
他制御はホストコンピュータ内で行えばよく、排他管理
装置16で排他制御しなくても済み、排他管理装置16の負
荷を低減することができる。

【００２６】また、GMQF152 、STCF153 ならびにMSNF15
4 は、トランザクションファイル入出力制御106 によっ
て、一貫性ならびに原子性が実現される。この方法はこ
こでは詳しく論じないが、たとえば、これらに共通のジ
ャーナルファイルを用意し、各ファイルの更新時には、
更新の始まった時の更新開始と、更新を行ったときに更
新前イメージを出力し、更新終了宣言（コミットとい
う）時には、更新がすべて確実に完了され、更新完了を
出力する。この更新完了が出力されていれば、各ファイ
ルの更新は一貫性が保証されているが、更新完了が出力
されていない状態でのシステム障害や、更新のキャンセ
ル時には、更新開始までさかのぼり更新を元に戻すこと
ができる。これにより、原子性が保証される。

【００２７】なお、トランザクションファイル入出力制
御106 によるGMQF152 、STCF153 、MSNF154 のアクセス
時には、排他管理装置16による排他制御は自動的に行わ
れる。

【００２８】各々のホストコンピュータ10は、トランザ
クションの負荷分散と端末の状態管理を行うトランザク
ション負荷分散機構101 と、要求されたトランザクショ
ンの実行タスクを決定させ、トランザクションプログラ
ムとの送受信インタフェースを実現するトランザクショ
ン実行制御機構102 と、要求されたトランザクションに
より、ユーザの作成したトランザクションプログラムが
動作する複数のトランザクション実行タスク103 と、複
数のファイルの更新時に、更新が中途半端にならないよ
うにし（原子性：Atomicity ）、すべてのデータ内容は
一貫性のとれた内容であり（一貫性：Consistency ）、
他処理からのアクセスに影響されることがなく（独立
性：Isolation ）、あらゆる障害に対して復旧が可能で
ある（耐久性：Durability）というトランザクションの
ACID性質を実現するためのトランザクションファイル入
出力制御106 と、 CPU監視装置14からの指示により、他
ホストコンピュータのシステム障害を認識して、トラン
ザクションファイル入出力制御106 で管理されている各
ファイルのレコードの中途半端な更新内容を復旧する代
替ホスト復旧機構104 と、代替ホスト復旧機構104 の復
旧処理が終了した時点で代替ホスト復旧機構104 から起
動されるメッセージ復旧機構105 とを備えている。ま
た、各ホストコンピュータ10は、自ホストコンピュータ
を識別するためのホストID情報107 を有している。

【００２９】トランザクション負荷分散機構101 は、接
続する端末毎にその状態制御を行うための端末状態テー
ブル1011を自ホストコンピュータ上のメモリに有してい
る。また、ホスト間共有高速メモリ媒体15上のファイル
（GMQF152 ならびにSTCF153）との読み込み、書き出し
をするためのIOバッファ1012や、トランザクション実行
制御機構102 にトランザクションの起動要求を発行する
際に要求ごとに情報を記憶しておき、トランザクション
実行制御機構102 からトランザクションの完了通知を受
ける際に参照するための、トランザクション要求ブロッ
ク1013を有している。更に、各種タイマー制御を行うタ
イマー監視機構1014を備えている。

【００３０】個々の端末状態テーブル1011は、端末状態
テーブル1011を検索するための端末名10111 と、GTSF15
1 の内容において端末状態テーブル1011と同じ情報を、
GTSF151 の内容が変更になったときにのみ読み込み、変
更ないときには読み込まないというファイルIOの最適化
のために使用する接続世代番号10112 と、端末の接続が
許可されたか、もしくは切断処理中かといった、トラン
ザクション実行可能状態10113 と、トランザクション実
行可能である場合の接続業務名10114 と、自ホストコン
ピュータ10内で当該端末にかかるトランザクションを現
在実行中であるかどうかを管理するトランザクション実
行状態10115 とを有する。

【００３１】IOバッファ1012は、トランザクション実行
時にアプリケーションに渡す受信メッセージ10125 と、
システム障害時の復旧時に必要な情報とを格納する。こ
のシステム障害時に復旧するときに必要となる情報は、
GMQF152 やSTCF153 に格納されるレコードの種別（要求
レコード，完了レコード，ラストレコード）を表すレコ
ードタイプ10121 と、GMQF152 からGTSF151 の内容を復
旧するときにどの端末かを選択する端末名10122 と、そ
のメッセージはもともとGMQF152 に格納されたことがあ
るかどうかを示すGMQF格納フラグ10123 と、GMQF152 に
格納されたレコードのレコードタイプ10121 がトランザ
クション完了レコードであるときに、そのレコードはま
さにシステム障害のときに実行中であったかどうかを、
トランザクション実行番号1517と照合することで確認す
るためのトランザクション実行番号10124 とで構成され
る。

【００３２】次に図１と、図２から図７の流れ図を参照
して、本発明の実施の形態の動作について説明する。な
お、各流れ図において、GTSF151 の読み込みが行われる
ときには、そのレコードに対する排他開始指示が排他管
理装置16に要求されており、読み込み終了もしくは書き
込みが行われたあとで排他終了指示が排他管理装置16に
要求されるが、各説明においてこの記載は省く。なおGT
SF151 の各情報を参照更新、もしくは取得設定するとき
には、これらの排他制御は行われない。

【００３３】図２は通信処理装置12が端末装置11から接
続要求を受けたときの動作を示している。接続要求で
は、端末名や接続を希望する業務名（接続業務名）など
が指定される。なお、あるホストコンピュータ10で特定
の業務に接続したとすると、他のホストコンピュータ10
でも同じ業務に接続されたとして制御がなされなければ
ならない。これは、後述する処理s207ならびにs403で実
現されるが、接続に関するその他の情報を各ホストコン
ピュータ10間で共通に意識しなければならない場合に
は、同様の手段をとることができる。

【００３４】ある端末装置11から接続要求を受けると、
通信処理装置12はその端末装置11に対応する通信状態12
3 を確認する(s201)。通信状態123 が未実行でないと
き、すなわちまだ直前に実行していたトランザクション
の完了を自装置12が検出していないときには、端末装置
11に接続拒否を返却する(s202)。これにより、接続は失
敗する。

【００３５】通信状態123 が未実行であるときには、通
信処理装置12は何れかのホストコンピュータ10に接続要
求を送信する(s203)。

【００３６】通信処理装置12から或る端末装置11の接続
要求を受けたホストコンピュータ10のトランザクション
負荷分散機構101 では、GTSF151 中のその端末装置11に
対応するレコードを読み込み、トランザクション実行可
能状態1513を確認する(s204、s205) 。

【００３７】トランザクション実行可能状態1513が未接
続状態でなければ、通信処理装置12は前回のトランザク
ションは完了したと認識しているが、ホストコンピュー
タ側ではトランザクション実行中であるということであ
る。このような状況が生じる場合は、通信処理装置12で
トランザクションが完了したとみなす以下の３通りであ
る。

【００３８】○ホストコンピュータ10でトランザクショ
ンを受け付けたかどうかを通信処理装置12に返却するま
えに、タイムアウトもしくはパス障害が発生した（図３
で後述するs312) が、実際には受け付けられていた場
合。 ○トランザクションの完了メッセージがなかなか返却さ
れず、タイムアウトもしくはパス障害が発生した（図３
で後述するs316) が、実際にはまだ実行中であった場
合。 ○端末装置11が切断され、通信処理装置12から切断通知
を送ろうとしたが、どのホストコンピュータ10とのパス
も切断していた場合（図６のs603の通知に失敗したと
き) 。

【００３９】このような場合でも、同一端末にかかる複
数トランザクションの同時実行を防止するためには、ト
ランザクションの完了を待ち合わせてから接続を許可す
る必要がある。そこで、トランザクション負荷分散機構
101 はGTSF読み込み終了を行い、通信処理装置12には接
続拒否を返却する(s206)とともに、ホストコンピュータ
10内の状態も切断状態とするよう働きかけるために切断
処理を行う(s610 。具体的な内容は図６で後述する) 。

【００４０】接続拒否を受けた通信処理装置12は、さき
ほどと同様に端末装置11に接続拒否を送る(s202)。

【００４１】さて、s205でトランザクション実行可能状
態1513が未接続であった場合には、トランザクション負
荷分散機構101 はGTSF151 のレコードを初期化する。具
体的には、トランザクション実行可能状態1513を接続
に、接続業務名1514を接続先の業務名に、各ホストトラ
ンザクション実行ビットマップ1515を一旦すべてゼロク
リアした後に自ホストに対応するビットのみ“１”に、
トランザクション実行番号1517を未実行に、ホストID15
181 とシーケンス番号15182 をすべてゼロクリアにそれ
ぞれ設定する(s207)。

【００４２】次に端末状態テーブル1011を検索し、初期
化する。具体的には、トランザクション実行可能状態10
113 を接続に、接続業務名10114 を接続先の業務名に、
トランザクション実行状態10115 を未実行に、それぞれ
設定する(s208)。

【００４３】次に接続世代番号1512を１増加し、その結
果を接続世代番号10112 に設定し、またGTSF151 に書き
込む(s209)。

【００４４】次に接続世代番号10112 を伴い、接続許可
を通信処理装置12に返却する(s210)。

【００４５】接続許可を受けると、通信処理装置12は通
知された接続世代番号10112 を接続世代番号124 に設定
し(s211)、端末装置11に接続許可を送信する。これによ
り、端末装置11の接続は成功する(s212)。後述するよう
に通信処理装置12は、接続が許可されたあとのメッセー
ジ送信時にはこの接続世代番号124 をホストコンピュー
タ10に通知し、ホストコンピュータ10は該当する端末状
態テーブル1011の接続世代番号10112 と比較し、不一致
のときGTSF151 中の該当するレコードの接続業務名1514
等を端末状態テーブル1011に転記する。これにより、接
続要求を処理しなかった他のホストコンピュータ10もメ
ッセージが通知された時点で、接続要求時に更新された
GTSF151 の内容が取得できる（後述するs402〜s403) 。

【００４６】図３は、接続以降の通信処理装置12におけ
るメッセージの処理とトランザクション状態管理の処理
について示している。なお、各処理に関連し、ホストコ
ンピュータ10での動作に影響を与えるが、これについて
は適宜説明する。

【００４７】或る端末装置11からメッセージを受け付け
ると、通信処理装置12ではまずその端末装置11に対応す
る通信状態123 を確認する(s301)。通信状態123 がもし
未実行でなければ、端末装置11にメッセージ拒否を返却
する(s302)。その理由は、トランザクション要求をホス
トコンピュータ10に発行し、返却がまだだということか
ら、トランザクション完了を待ちきれずに端末装置11が
メッセージを二重投入してきたものと判断されるからで
ある。

【００４８】通信状態123 が未実行であれば、通信状態
123 をトランザクション実行中と設定し、さらに受信し
たメッセージを送ろうするホストコンピュータ10に対応
するシーケンス番号121 を１加算する(s303)。このあ
と、シーケンス番号121 と接続世代番号124 を伴い、受
信メッセージを含むトランザクション要求（以降、TXre
q と略す）をホストコンピュータ10に送信する(s304)。
本要求を受けたときのホストコンピュータ10の動作は、
図４のs400で説明する。なお、TXreq を何れのホストコ
ンピュータ10に送るかについては、例えば負荷分散を考
慮して各ホストコンピュータに均等に送信するといった
方法が採られる。

【００４９】次に通信処理装置12は、トランザクション
受付（以降、TXack と略す）がホストコンピュータ10か
ら返却されるのを、タイマー監視機構126 によって一定
のタイマーをかけて待ち合わせる(s305)。

【００５０】s305で実行拒否のTXack を受信したら、通
信状態123 を未実行に戻し(s306)、端末装置11にメッセ
ージ拒否を返却する(s307)。このようなメッセージ拒否
の返却につながる実行拒否のTXack は、後述するよう
に、s415でトランザクション実行制御機構102 にトラン
ザクション起動要求を受け付けられなかったときにs420
で返される。

【００５１】s305で正常受付の返却を受けると、端末装
置11にメッセージの正常受付を返却する(s309)。

【００５２】s305でTXreq を送ったホストコンピュータ
10との間のパス障害を検出するか、もしくはタイマー監
視機構126 によってタイムアウトを検出すると、TXack
はもはや返却されないと判断する。しかし、クラスタシ
ステムは複数台のホストコンピュータ10から成り立って
いるため、別ホストコンピュータ10に再度TXreq 要求を
行う。具体的には、s303とは別のホストコンピュータ10
用のシーケンス番号121 を１加算し(s310)、s304で通知
した情報と、今度通知するホストコンピュータ10用のシ
ーケンス番号121 を伴い、再トランザクション要求（以
降、reTXreq と略す）を送る(s311)。

【００５３】reTXreq に載せる情報は、以下のとおりで
ある。例では、s304で通知したホストコンピュータ10の
自ホストID107 を１とし、今回reTXreq を送る自ホスト
ID107 を２とする。

【００５４】○旧TXreq 通知ホスト番号＝１ ○旧TXreq シーケンス番号に、１用のシーケンス番号12
1 ○reTXreq シーケンス番号に、２用のシーケンス番号12
1 ○接続世代番号124

【００５５】reTXreq を受け付けたときのホストコンピ
ュータ10の動作は、後のs450で説明する。

【００５６】通信処理装置12は、reTXreq に対してもそ
のTXack がホストコンピュータ10から返却されるのを、
タイマー監視機構126 によって一定のタイマーをかけて
待ち合わせる(s312)。

【００５７】s312で実行拒否のTXack を受信したら、s3
05の場合と同様に通信状態123 を未実行として(s306)、
端末装置11にメッセージ拒否を返却する(s307)。

【００５８】s312で正常受付の返却、もしくは既に受け
付け済みの返却を受けると、端末装置11にメッセージの
正常受付を返却する(s309)。

【００５９】s311でreTXreq を送ったホストコンピュー
タ10との間のパス障害を検出するか、もしくはタイマー
監視機構126 によってタイムアウトを検出すると、TXac
k はもはや返却されないと判断し、通信状態123 を未実
行に戻し(s313)、ホストコンピュータに端末の切断通知
を通知する(s314)。TXreq/reTXreq 送信に対して、TXac
k が返却されなかったのに対して、この処理はほとんど
無効であるようにとれるが、通信処理装置12からホスト
コンピュータに対する送信はいつも成功し、ホストコン
ピュータから通信処理装置12に対する返却はいつも失敗
しているような障害のときには有効であろう。あるい
は、TXreq/reTXreq 送信とは別のホストコンピュータに
対する送信であれば有効である。

【００６０】このあと通信処理装置12は、実際に端末装
置11を切断する(s315)。

【００６１】さて、s305もしくはs312で正常受付のTXac
k が返却されたか、もしくはs312において既に受付済み
のTXack が返却された場合には、通信処理装置12は端末
装置11にメッセージの正常受付を返却し(s309)、いずれ
かのホストコンピュータ10からのトランザクション完了
メッセージ（以降、TXreply と略す）を、タイマー監視
機構126 でタイマーをかけて待ち合わせる(s316)。

【００６２】要求したTXreq は、トランザクション負荷
分散機構101 における負荷分散機能によって、どのホス
トコンピュータ10で処理されるかわからないため、あら
ゆるホストコンピュータ10からのTXreply を待ち合わせ
る。

【００６３】正常完了のTXreply が返却されると、通信
状態123 を未実行に戻し(s317)、端末装置11にトランザ
クション応答メッセージを返却する(s318)。これによ
り、メッセージ受信による一つのトランザクションが正
常に終了したことを端末装置11のオペレータは認識する
ことになる。

【００６４】一方、s316で全てのホストコンピュータ10
のパスが障害になるか、もしくはタイマー監視機構126
からタイムアウトが告げられると、通信処理装置12は、
最悪の場合ホストコンピュータがシステム障害となった
ものと認識し、端末装置11を切断するステップを踏む(s
313,s314,s315)。

【００６５】このように、通信処理装置12は各種障害で
端末装置11を切断する動作を行う。切断されれば、再接
続が実行されるが、実際にはさきに投入したTXreq は受
け付けられているかもしれないし、実行はまだ継続して
いるかもしれない。再接続後の端末装置11に先に投入さ
れたメッセージのトランザクション応答を返却すること
はできないし、先のトランザクション実行が確実に完了
するまでに次のメッセージ投入によるTXreq を処理する
ことはできない。

【００６６】また、システム障害で中途半端な状態でホ
ストコンピュータ10が停止してしまった場合に、ホスト
コンピュータ10内のトランザクション実行を再開し、ま
たトランザクションがすでに完了していれば次の接続を
許可すべくトランザクションの実行中状態をキャンセル
しなくてはならない。以下、図４から図７を参照して、
このような機能を実装するための処理を含めて、残りの
動作について説明する。

【００６７】図４は、TXreq もしくはreTXreq をホスト
コンピュータ10が通信処理装置12から受け取ったときの
動作を示している。なお、通信処理装置12から通知され
たあらゆる要求は、トランザクション負荷分散機構101
に通知され処理される。

【００６８】まずトランザクション負荷分散機構101
は、或る端末装置11にかかるTXreq を受け取ると(s40
0)、その端末装置11に対応する端末状態テーブル1011を
検索する(s401)。TXreq には端末世代番号が付与されて
おり、これと接続世代番号10112を比較する(s402)。

【００６９】もし端末世代番号が異なれば、本ホストコ
ンピュータ10は当該端末の接続処理を行ったホストでな
く且つ接続後初めてTXreq を受けたことを意味し、接続
時にs207やs209で設定されたGTSF151 の内容はまだ自ホ
ストコンピュータは未知であることを意味する。この場
合、GTSF151 の当該端末装置11に対応するレコードを読
み込み、以下の内容を端末状態テーブル1011に設定する
(s403)。

【００７０】○接続世代番号1512を10112 に設定する。 ○トランザクション実行可能状態1513を10113 に設定す
る。 ○接続業務名1514を10114 に設定する。 ○トランザクション実行状態10115 には未実行を設定す
る。

【００７１】また各ホストトランザクション実行ビット
マップ1515の、自ホストID107 で示される位置のビット
を“１”に設定し、書き込みを行う(s404)。これにより
各ホストトランザクション実行ビットマップ1515は、接
続を行ったホストコンピュータ及び接続後にTXreq を受
信したホストコンピュータ10の分だけビットが“１”に
設定されることになる。このビットが“１”に設定され
たホストコンピュータ10では、トランザクションが実行
されている可能性があると見做される。

【００７２】このs403、s404のGTSF151 の入出力は、端
末装置11が接続後に各ホストコンピュータ10でたかだか
一回ずつ行われ、以降切断されるまでいっさい行われな
い。

【００７３】s402で接続世代番号が一致していたか、も
しくはs404が終了したら、トランザクション負荷分散機
構101 は自ホストに対応するMSNF154 を読み込む。この
とき、もし書き込み禁止になっていたら(s405)、コミッ
トして処理をやめる(s406)。これは、TXreq を処理しよ
うとしている間に、通信処理装置12でタイムアウトが検
出されてreTXreq が他ホストコンピュータ10に送られ、
後述するs454の処理がなされたことを意味する。この場
合、reTXreq とTXreq でトランザクションが二重に実行
されるため、これを回避する為に上記の如き処理を行
う。なお、本処理についてはreTXreq のところで再度説
明する。

【００７４】MSNF154 が正常であれば、トランザクショ
ン実行状態10115 をトランザクション実行中と設定する
(s407)。いずれかのホストコンピュータ10で当該端末に
かかるトランザクションが実行中であった場合、端末装
置11が切断されていなければs301で拒否されていたし、
いったん切断されていれば、再接続時にs205で接続拒否
されるため、TXreq 受信時はなにも確認せずにトランザ
クション実行中としてよい。

【００７５】次に、トランザクション負荷分散機構101
は自ホストコンピュータ10の負荷状況や、STCF153 の使
用状況を確認する(s408)。過負荷であったり、STCF153
のレコードが空いていない場合には、他ホストコンピュ
ータ10で今回のトランザクションを実行しなくてはなら
ない。この場合の処理はs430以降で説明する。この判断
が、トランザクションの負荷分散機能となる。

【００７６】自ホストコンピュータ10で処理可能の場合
には、IOバッファ1012に、以下の情報を設定する(s40
9)。

【００７７】○メッセージ10125 にはTXreq 受信メッセ
ージを設定する。 ○レコードタイプ10121 には要求レコードのタイプを設
定する。 ○端末名10122 には端末名を設定する。 ○GMQF格納フラグ10123 にはOFF を設定する。

【００７８】次に、このIOバッファ1012を、空いている
STCF153 のレコードに書き込む(s410)。

【００７９】また、通信処理装置12のs303で採番された
TXreq のシーケンス番号を、MSNF154 のシーケンス番号
1541に書き込む(s411)。

【００８０】そして、s410とs411の書き込み動作をコミ
ットする(s412)。コミット動作が成功すれば、s410とs4
11の書き込みは確実に成功し、他ホストコンピュータ10
でアクセスことができる。また、コミットが成功せずに
システム障害となると、CPU監視装置14が障害を検出し
他ホストコンピュータ10の代替ホスト復旧機構104 に
て、s410を書き込む前の状態に復旧する。この復旧が完
了すると、やはり他ホストコンピュータ10でアクセスこ
とができるようになる。ただし、s413以降の処理は実行
されないことに注目すべきである。

【００８１】さて、s412が終わると、トランザクション
負荷分散機構101 はトランザクション要求ブロック1013
を取得し、端末状態テーブルアドレス10131 には端末状
態テーブル1011のアドレスを、GMQF格納フラグ10132 に
はOFF をそれぞれ設定する(s413)。

【００８２】次に、このトランザクション要求ブロック
1013と、s410で書き込んだSTCF153のレコードのアドレ
スを伴い、トランザクション実行制御機構102 にトラン
ザクション実行要求を発行する(s414)。実行要求先は、
接続業務名10114 に対応するトランザクション実行制御
機構102 とする。

【００８３】トランザクション実行要求が成功すると(s
415)、正常受付のTXack を通信処理装置12に返却する(s
416)。

【００８４】もし、トランザクション実行制御機構102
が終了中など、トランザクションを受け付けられない状
態である場合には、s415にて受付拒否が返される。この
ときは、STCF153 のレコードを削除し(s417)、書き込み
コミットする(s418)。もしこのコミット前にシステム障
害となると、STCFレコードは残ったままとなる。

【００８５】コミットのあと、トランザクション実行状
態10115 の状態を未実行状態に戻し(s419)、通信処理装
置12に実行拒否のTXack を返却する(s420)。

【００８６】さきにs402/s403/s404で述べたとおり、い
ったんTXreq が処理されると、もはやそのホストコンピ
ュータ10ではs403,s404 にてGTSF151 のアクセスが行わ
れることはない。また、s407からs416、もしくはs420ま
での処理では、GTSF151 のアクセスは行わない。このた
め、通常状態でのトランザクションの実行においては、
GTSF151 のアクセスを行うことなくトランザクション処
理を行うことができる。

【００８７】では、s408にて過負荷、もしくはSTCF全レ
コード使用中と判断された場合の、負荷分散方法につい
て説明する。

【００８８】まず、トランザクション負荷分散機構101
はGTSF151 の該当レコードを読み込み、トランザクショ
ン実行番号1517を１加算してGTSF151 に書き戻し、この
値をＩＯバッファ1012のトランザクション実行番号1012
4 に転記する(s430)。

【００８９】また、GTSF151 の該当レコードのホストID
15181 に自ホストID107 の値を、シーケンス番号15182
に、受信したTXreq のシーケンス番号をそれぞれ設定す
る(s431)。

【００９０】次に、GTSF151 の該当レコードのトランザ
クション実行状態1516をグローバルメッセージキュー書
き込み開始（以降、GMQwrit と略す）と設定し、書き込
みを行う(s432)。

【００９１】次に、s433からs436で、GMQF152 へのメッ
セージのキューイングを行う。まず、IOバッファ1012
に、以下の情報を設定する(s433)。

【００９２】○メッセージ10125 にはTXreq 受信メッセ
ージを設定する。 ○レコードタイプ10121 には要求レコードのタイプを設
定する。 ○端末名10122 には端末名を設定する。 ○GMQF格納フラグ10123 にはONを設定する。

【００９３】このIOバッファ1012を、GMQF152 にレコー
ド挿入し書き込む(s434)。

【００９４】また、s303で採番されたTXreq のシーケン
ス番号を、MSNF154 のシーケンス番号1541に書き込む(s
435)。

【００９５】s434とs435の書き込み動作をコミットする
(s436)。

【００９６】さらにGTSF151 の該当レコードを読み込
み、トランザクション実行状態1516をグローバルメッセ
ージキュー書き込み完了（以降、GMQwrot と略す）と設
定し、書き込む(s437)。

【００９７】GMQF152 にメッセージが格納されていると
きは、いずれかのホストコンピュータ10でメッセージが
取り出され、トランザクションが実行されるので、クラ
スタシステム全体をみれば、トランザクション実行中で
ある。メッセージはどのホストコンピュータ10で取り出
されるかわからないため、トランザクション実行中とい
うことを管理するには、各ホストTR実行BM1515でなく、
GTSF151 のトランザクション実行状態1516で以下のよう
に管理する。

【００９８】まず、GMQwrit は、トランザクションが実
行開始したことを示す。GMQF152 は、s436が終了した直
後にシステム障害となれば、メッセージは格納状態とな
り、トランザクションは実行状態となる。この状態を管
理するためには、GMQF152 に書き込む前にGTSF151 に設
定しなくてはならない。また、 s436 が終了する前にシ
ステム障害となれば、メッセージは紛失するのでトラン
ザクションは実行状態ではないことになる。すなわち、
トランザクション実行状態1516がGMQwrit のときには、
トランザクションが実行状態なのか、実行状態でないの
かが特定できないということを意味する。

【００９９】また一方で、GMQwrot は、トランザクショ
ンが確実に実行されることを示す。メッセージはGMQF15
2 に格納されたため、いずれかのホストコンピュータ10
において後述するGMQF内容確認処理s520でトランザクシ
ョンが実行される。

【０１００】GMQwrit の２つの相反する状態の区別は、
GMQwrot となったときに状態が確定するが、GMQwrot と
なる前にシステム障害を検出した時に区別がつかなくな
る。そこで、前述したようにs431で重送チェック情報15
18（ホストID15181,シーケンス番号15182)をGTSF151 の
該当レコードに記録すると共に、s435で同じシーケンス
番号を自ホストに対応するMSNF154 に書き込んでおく。

【０１０１】こうすると、当該ホストコンピュータのシ
ステム障害が検出され、他のホストコンピュータの代替
ホスト復旧機構104 でGMQF152 などを復旧完了したとき
に、S431で書き込まれた重送チェック情報1518中のシー
ケンス番号15182 と、障害ホスト対応のMSNF154 に格納
されたシーケンス番号1541とを比較すれば、一致してい
る場合には、MSNF154 の書き込みはs436まで達成してい
るため成功しており、同時にGMQF152 への書き込みも成
功していると判断でき、また不一致であれば、MSNF154,
GMQF152 への書き込みはs436まで達成していなかったた
め失敗していると判断できる。これにより、トランザク
ション実行状態1516をトランザクション実行状態である
「GMQwrot 」もしくは、トランザクション未実行状態で
ある未実行に補正することができる（詳細は図７のs723
〜s729で説明する）。

【０１０２】つまり、GMQF152 へのメッセージ書き込み
を行う際、MSNF154 の書き込みをともに行っておき、書
き込み前にトランザクション実行状態1516をGMQwrit と
し、書き込みコミット完了後にGMQwrot とすることで、
トランザクション実行状態は以下のように管理すること
ができる。

【０１０３】○TR実行状態1516が未実行であれば、トラ
ンザクションは未実行であるため、端末切断時の再接続
が可能である。 ○TR実行状態1516がGMQwrit であれば、トランザクショ
ンは実行開始している可能性がある。システム障害が発
生していなければ、そのうち状態は変化する。システム
障害が発生したときは、MSNF154 を参照することでGMQw
rot もしくは未実行に状態補正することができる。 ○TR実行状態1516がGMQwrot であれば、トランザクショ
ンは確実に実行開始しているため、端末切断時の再接続
は拒否される。

【０１０４】さて、s437が終了すると、格納したGMQFメ
ッセージを他ホストコンピュータ10で実行させるため
に、今回書き込んだGMQF格納アドレスを伴って、GMQF実
行要求をホスト間通信装置13によってすべての他ホスト
コンピュータ10に伝達する(s438)。後述するように、こ
のホスト間通信を最初に受信したホストコンピュータ10
は、s540にてGMQFからメッセージを取得し、トランザク
ションを実行する。このことは、処理できるホストコン
ピュータ10がGMQFメッセージを取得したことになり、負
荷分散が実現できることになる。これについてはs540で
後述する。

【０１０５】次にトランザクション負荷分散機構101
は、端末状態テーブル1011のトランザクション実行状態
10115 を未実行に設定する(s439)。他のホストコンピュ
ータに実行依頼したため、もはや本ホストコンピュータ
10ではトランザクション実行をしていないからである。
このときのトランザクション実行状態は前述の通り、GT
SF151 のトランザクション実行状態1516によってホスト
コンピュータ間で実行状態にあると管理される。

【０１０６】最後にトランザクション負荷分散機構101
は、正常受付のTXack を通信処理装置12に返却する(s41
6)。

【０１０７】TXack を通信処理装置12に返却すると、通
信処理装置12は他の端末装置11からの別のTXreq を送っ
てくる。このときにs411もしくはs435でMSNF154 は更新
されてしまう。したがって、TXack 返却時にトランザク
ション実行状態1516をGMQwrit のままにしておくと、上
記のシステム障害時の状態補正時に参照することができ
ない。すなわち、s437でGMQwrot 状態にしておくこと
は、システム障害時の状態補正のために必須である。

【０１０８】ここまではTXreq を受け付けたときのトラ
ンザクション負荷分散機構101 の動作の説明であった
が、通信処理装置12から図３のs311で送信されたreTXre
q を受信したとき(s450)の動作も、ほとんど同じであ
る。

【０１０９】まず、トランザクション負荷分散機構101
は、reTXreq に設定されている旧TXreq 通知ホストに対
応するMSNF154 を読み込み(s451)、旧TXreq シーケンス
番号とMSNF154 内シーケンス番号1541とを比較する(s45
2)。

【０１１０】もし一致していれば、コミットし、すでに
受付済みのTXack を返却する(s453)。これを返却する
と、前述したように通信処理装置12では正常受付と同じ
扱いを行う（図３のs312→s309) 。

【０１１１】一致していなければ、トランザクション負
荷分散機構101 は、MSNF154 を書き込み不可というよう
にトランザクションファイル入出力制御106 に指示する
(s454)。これは、旧TXreq 通知ホストにおいてシステム
障害もしくは処理遅延が生じ、reTXreq のほうが先に処
理されたということになる。処理遅延の場合、reTXreq
がこのように先に処理され、後からTXreq 処理が生じな
いように、MSNFを書き込み禁止にする。

【０１１２】このあと、TXreq を受信した時と同じs401
以降の処理を行う。このとき、reTXreq シーケンス番号
をTXreq のシーケンス番号に、reTXreq の受信メッセー
ジをTXreq 受信メッセージに、それぞれ読み替えて処理
する。

【０１１３】次に、s414でトランザクション起動要求を
発行したあとの、トランザクション実行の動作について
説明する。なお、後述するGMQF格納内容確認処理s520の
s534で要求されるトランザクション起動要求のときにも
同じように実行される。ただし、TXreq を受け付けs414
で要求する場合と、いったんGMQF152 にメッセージが格
納されてからs524で要求する場合とでは、STCF153 の内
容に若干の違いがある。この違いは、トランザクション
が実行されるステップにおけるシステム障害が発生した
ときの実行のしかたに違いが現れる。これについては、
図５のs526〜s528で、ここでの説明をふまえて後ほど説
明する。

【０１１４】さて、s414やs534でトランザクション起動
要求を発行すると、起動要求を受けたトランザクション
実行制御機構102 は、トランザクション実行タスク103
を選択してトランザクション処理プログラムを実行す
る。このとき、各種データベースの参照更新の最後にお
いて、s414やs534で渡されたSTCF153 のアドレスのレコ
ードをアクセスし、レコードタイプを完了レコードとし
て書き込み、書き込みコミットを行う。これにより、ト
ランザクション処理プログラムが正常に処理されれば、
更新したデータベースとともに、STCF153 のレコード内
容は完了レコードとなる。しかし、コミット前の処理途
中でシステム障害になれば、更新したデータベースとと
もに別ホストコンピュータ10の代替ホスト復旧機構104
によって元に戻される。すなわち、STCF153 のレコード
のレコードタイプは要求レコードに戻る。

【０１１５】このシステム障害状態は、トランザクショ
ンがまだ実行されていないことと等価である。トランザ
クション処理プログラムが扱うデータベースなどのファ
イルは、すべてトランザクションの一貫性・原子性など
４性質を持つためである。このため、戻されたSTCF153
レコードの内容で、再度トランザクションを起動すれ
ば、通信処理装置12から受け付けたTXreq に対応するト
ランザクション実行は、二重実行されず、確実に一回だ
け実行されることになる。

【０１１６】ここで、システム障害時の動作を簡単に説
明しておく。 CPU監視装置14で或るホストコンピュータ
のシステム障害が検出されると、他ホストコンピュータ
10の代替ホスト復旧機構104 が各種のファイルを復旧
し、すみやかにメッセージ復旧機構105 を起動する。メ
ッセージ復旧機構105 は、障害ホストコンピュータのも
つSTCF153 を読み込み、内容をそっくりGMQF152 にレコ
ード挿入する。もし、トランザクション実行がされてい
ない場合には、レコードタイプが要求レコードのままGM
QF152 に格納されるため、後述するGMQF監視タイマー処
理s740によって、負荷分散された他のメッセージととも
に再度トランザクションが実行される。他方、もしトラ
ンザクション実行が完了していた場合には、レコードタ
イプが完了レコードとなっているため、後述するGMQF監
視タイマー処理s740によってトランザクションの完了処
理が再度実行されることになる。これらシステム障害の
復旧については、通常ルートの実行を図４〜図６で説明
したあとで、図７で再度詳細に説明する。

【０１１７】さて、トランザクション実行タスク103 で
トランザクション処理プログラムの実行が正常に終了
し、書き込みコミットが終わると、トランザクション実
行制御機構102 は完了通知を受け、トランザクション起
動要求時s414（もしくはs534）で指定されたトランザク
ション要求ブロック1013を伴って、トランザクション負
荷分散機構101 に対してトランザクション完了通知を送
る。このあとの処理を図５を参照して以下説明する。

【０１１８】トランザクション負荷分散機構101 は、ト
ランザクション完了通知を受け取ると(s500)、渡された
トランザクション要求ブロック1013の端末状態テーブル
アドレス10131 から、端末状態テーブル1011を特定する
(s501)。GMQF格納フラグ10132 を参照し(s502)、ONであ
ればGTSF151 の該当レコードを読み込み、トランザクシ
ョン実行状態1516を未実行に設定して書き込む(s503)。
これにより、s430〜s437でもしトランザクションがホス
トコンピュータ間で実行状態となった場合には、この時
点で未実行状態に戻る。

【０１１９】次に端末状態テーブル1011のトランザクシ
ョン実行状態10115 を未実行に設定する(s504)。これに
より、s407→s408→s409〜s414で自ホストコンピュータ
内で実行状態となった場合には、この時点で未実行状態
に戻る（これは、後述するs526〜s534→s535の場合も同
じである）。

【０１２０】最後に、トランザクション完了メッセージ
を伴い、TXreply を通信処理装置12に返却することで、
トランザクションは完了する(s505)。

【０１２１】更に、本実施の形態では、トランザクショ
ンが完了したときに以下の２つ処理を行う。

【０１２２】第１は、端末状態テーブル1011のトランザ
クション実行可能状態10113 を参照してこれが切断処理
中かどうかを判断し(s506)、切断処理中なら、GTSF151
を読み込み、各ホストトランザクション実行ビットマッ
プ1515の自ホストID107 で示される位置のビットをクリ
アして、書き込みを行う(s507)ことである。

【０１２３】後述するように或る端末装置11にかかる端
末切断通知が通信処理装置12から或るホストコンピュー
タ10に出された場合、そのホストコンピュータ10ではそ
の端末装置11に対応するGTSF151 のTR実行可能状態1513
を切断処理中にし(s613)、自ホストを含み全ホストコン
ピュータに切断要求を送信後(s614)、各ホストTR実行BM
1515がオールゼロになるのを待ち合わせており、切断要
求を受信したホストコンピュータではGTSF151 の該当レ
コードの転記によって端末状態レコード1011のTR実行可
能状態10113 を切断処理中にし(s622)、その端末状態レ
コード1011のTR実行状態10115 が未実行なら各ホストト
ランザクション実行ビットマップ1515の自ホストID107
で示される位置のビットをクリアするようにしている(s
623)。しかし、TR実行状態10115 が未実行でなければ切
断要求は保留されるため、s623では該当ビットはクリア
されず、s615の待ち合わせは解除されない。s507で各ホ
ストトランザクション実行ビットマップ1515の当該位置
をクリアすることは、s615の待ち合わせを解除させるこ
とになり、最終的に切断処理中状態は未接続状態になり
(s617)、再接続が可能となる。

【０１２４】第２は、GMQF152 からのレコード読み込み
によるトランザクション実行である。トランザクション
実行によってSTCF153 を占有していたことにより、別の
端末装置11のTXreq がs408でNOとなることによってGMQF
152 に書き込まれたり、もしくは後述するs520でGMQF15
2 から読みとる場合にも、s529によってGMQF152 に残し
てしまった場合に、トランザクション完了によってSTCF
153 が空いたことで再度GMQF152 から読み込み、トラン
ザクション実行ができることになる。これは単に、GMQF
格納内容確認処理s520を呼び出すことである。

【０１２５】次に、図４のTXreq 受信処理のs438で、GM
QF152 にメッセージを格納したというGMQF実行要求の送
信をホスト間通信装置13に要求し、別ホストコンピュー
タ10にてGMQF実行要求を受信したときの動作を、s540か
ら説明する。

【０１２６】トランザクション負荷分散機構101 は、受
信したホスト間通信情報内のGMQFレコードアドレスか
ら、GMQF152 の該当レコードを読み込み、IOバッファ10
12に内容を格納する(s541)。読み込みが成功すると、レ
コードタイプ10121 を判断する(s542)。

【０１２７】もし、読み込みが失敗したり、レコードタ
イプ10121 が要求レコードでなければ、ホスト間通信情
報の内容はすでに他ホストコンピュータで処理済みであ
るとみなし、読み込みコミットして処理を終える(s54
3)。

【０１２８】読み込みが成功し且つレコードタイプ1012
1 が要求レコードであった場合、GMQF格納フラグ10123
がOFF であるかどうかをチェックする(s526)。

【０１２９】GMQF格納フラグ10123 がOFF ということ
は、読み込んだレコードは、s412でSTCF153 の内容をコ
ミットしてから、s414でトランザクションを起動し、ト
ランザクション実行完了時のSTCF153 のレコードタイプ
を完了レコードに更新するコミットが行われる前にシス
テム障害が発生した場合に実行されるメッセージ復旧機
構105 で、先に述べたとおりSTCF153 のレコードがGMQF
152 に格納されたときに生成されたレコードであり、s4
09で設定したレコード（GMQF格納フラグ10123=OFF ）が
読み込まれたことを意味する。s400でTXreq 受信時にs4
08にて過負荷でなくSTCFレコードが空いている場合、s4
09〜s414でトランザクション起動しているが、このとき
にはトランザクション実行状態はそのホストコンピュー
タ10の端末状態テーブル1011のトランザクション実行状
態10115 にてs407で設定したトランザクション実行中で
しかなく、ホストコンピュータ間のトランザクション実
行状態であるGTSF151 のトランザクション実行状態1516
を更新していない。ところが、TXreq 受信ホストコンピ
ュータ10ではトランザクション実行がもはやできず、代
替のホストコンピュータ10でトランザクション実行を開
始しているということになれば、これはGTSF151 のトラ
ンザクション実行状態1516を更新しなくてはならない。
受信メッセージはすでにGMQF152 に格納されているの
で、トランザクション実行状態1516をGMQwrot とする必
要がある。

【０１３０】即ち、再度図５のs526に戻ると、もしIOバ
ッファ1012のGMQF格納フラグ10123がOFF であれば、端
末名10122 より対応するGTSF151 のレコードを読み込
み、トランザクション実行番号1517を１加算し設定す
る。この値をIOバッファ1012のトランザクション実行番
号10124 にも設定する (s527) 。そして、トランザクシ
ョン実行状態1516はGMQwrot としてGTSF151 を書き込
む。更に、GMQF格納フラグ10123 をONとし、GMQF152 に
レコードを書き戻す (s528) 。

【０１３１】他方、s526でGMQF格納フラグ10123 がONで
あれば、これらs527,s528 と等価の処理はすでに行われ
ているため不要である(s430,s433,s437 など) 。

【０１３２】次にトランザクション負荷分散機構101
は、STCF153 の空きレコードがあるかどうかチェックす
る(s529)。もし空きがなければ、書き込みコミットを行
う(s530)。このコミットでは、もしs526でGMQF格納フラ
グ10123 がOFF と判断されたときのs528のGMQF152 書き
込みを有効とするものであり、s526でGMQF格納フラグ10
123 がONであった場合には、s541で読み込まれたGMQF15
2 を排他解放するだけである。

【０１３３】s529で空きがあれば、IOバッファ1012の内
容をSTCF153 に書き込み、GMQF152の読み込んだレコー
ドは削除する(s531)。そしてコミットする(s532)。

【０１３４】次にトランザクション要求ブロック1013を
用意し、端末名10122 に対応する端末状態テーブル1011
を捜して端末状態テーブルアドレス10131 に設定し、GM
QF格納フラグ10132 はONとする(s533)。

【０１３５】そして、トランザクション要求ブロック10
13アドレスとSTCF153 のレコードアドレスを伴い、トラ
ンザクション実行制御機構102 にトランザクション起動
要求を発行する(s534)。これはs414と同じである。ただ
し、端末状態テーブル1011の接続業務名10114 などを参
照する必要があれば、これは接続業務名1514を参照する
か、もしくはs402〜s403の処理によってGTSF151 内容を
端末状態テーブル1011に反映させてから接続業務名1011
4 を参照する。各ホストトランザクション実行ビットマ
ップ1515は更新しない。

【０１３６】トランザクション起動要求の受付が成功で
あれば、端末状態テーブル1011のトランザクション実行
状態10115 をトランザクション実行中と設定する(s53
5)。

【０１３７】受付が失敗すれば、S531で書き込んだSTCF
153 のレコードを削除しコミットする(s536)。GTSF151
を読み込み、トランザクション実行状態1516を未実行に
設定して書き込む(s537)。次に、トランザクションの異
常完了メッセージを、TXreply で通信処理装置12に返却
する(s538)。

【０１３８】s534で受付失敗時にトランザクションが完
了したことは、s500の処理とほぼ変わりないが、s506〜
s507の処理はここでは不要である。s540〜s543, s526〜
s538の流れで、各ホストトランザクション実行ビットマ
ップ1515を更新したことはないし、トランザクション実
行状態10115 を実行中としていないため、トランザクシ
ョン実行可能状態10113 が切断処理中であっても、各ホ
ストトランザクション実行ビットマップ1515が設定され
ていることはないからである。したがって、トランザク
ション完了時にs506からs507の処理を行う必要がない。
（ただし、s534のあとで受け付け成功の場合には、s535
でトランザクション実行状態10115 を実行中としている
ため、過去にs404にて各ホストトランザクション実行ビ
ットマップ1515を立てたことがあれば、トランザクショ
ン実行可能状態10113 が切断処理中のときにトランザク
ション完了時には各ホストトランザクション実行ビット
マップ1515を落とさなければならない。これはまさに、
s506〜s507で行われる）

【０１３９】図４のs408もしくは図５のs529にて、STCF
未使用レコードがない場合には、s414もしくはs534でト
ランザクションが起動されず、GMQF152 にメッセージが
残る。s538でトランザクション完了となった場合も、s5
05の場合と同様に、残っているGMQFメッセージを処理す
るためにGMQF格納内容確認処理s520を行う。

【０１４０】このGMQF格納内容確認処理s520は、GMQFの
先頭の内容を読み込み(s521)、読み込みが成功すると(s
522)、レコードタイプ10121 を判断する(s524)。

【０１４１】もし、レコードタイプ10121 が要求レコー
ドでなければ、処理は図７のリカバリレコード処理s700
に進む。この動作は、システム障害が発生して、いずれ
かのホストコンピュータでメッセージ復旧機構105 が動
作した直後のみ動作する。

【０１４２】あとのs522以降は全く上記と同じ処理を行
う。

【０１４３】GMQF格納内容確認処理(s520)の場合、他の
ホストコンピュータ10が処理を行ってしまっていたら、
s521のGMQF読み込みは失敗する。この場合、読み込みを
コミットして処理をやめる(s523)。ホスト間通信にてGM
QF実行要求を受信(s540)した場合との処理の差は、後ほ
どシステム障害時の復旧の箇所で図７を中心に説明する
ときに述べる。

【０１４４】ここで、本実施の形態の性能効果につい
て、通常のトランザクション実行シーケンスにおいて、
GTSF151 のアクセス回数がどうなっているかを説明す
る。

【０１４５】TXreq を受信したホストコンピュータ10に
て図４のs414でトランザクションが実行された場合は、
トランザクション完了通知を受けたときにもs502によっ
て、結局GTSF151 にはまったくアクセスせずにトランザ
クションを実行させることができていることを意味す
る。トランザクションの実行状態は、トランザクション
実行状態10115 によってのみ管理されている。ただし、
接続して初めてそのホストコンピュータ10でトランザク
ションを実行するときには、s403〜s404でGTSF151 の読
み込みと書き込みを行う。実はこのときに、各ホストト
ランザクション実行ビットマップ1515に設定すること
が、そのホストコンピュータ10でトランザクションを実
行している可能性があることを意味し、ホストコンピュ
ータ間で認識することができる。よって、接続直後以降
はトランザクションの実行状態をGTSF151 を介さずに管
理することができる。なぜこれだけで管理できるかは、
切断時にどのようにしてトランザクション完了を待ち合
わせることができるかという制御であり、これは図６に
おいて後述する。

【０１４６】また、TXreq 受信時にそのホストコンピュ
ータ10でトランザクション実行ができなかった場合に
は、図４のs430〜s432、s437ならびに図５のs503にて、
合計３回、GTSF151 の読み込み、書き込みが行われる。
TXreq を受信したホストコンピュータ10でトランザクシ
ョンが実行できなかったということは、いずれかのホス
トコンピュータ10でそのうちトランザクションが実行、
完了するまでを管理しなくてはならず、これにはGTSF15
1 のトランザクション実行状態1516が用いられる。

【０１４７】次に図６を参照して、端末装置11が切断さ
れる、もしくは切断されたときの状態補正について説明
する。

【０１４８】通信処理装置12は或る端末装置11から切断
要求を受けると(s600)、先ず、s601にてその端末装置11
に対応する通信状態123 が未実行かどうかを判断する(s
601)。未実行でなければ、トランザクション実行中であ
り、TXack 待ちもしくはTXreply を待ち合わせているた
め( 図３のs305,s312,s316参照) 、タイマーをかけて一
定時間後、再度s601のチェックを行う(s602)。通信処理
装置12の通信状態123は、図３を参照すると、タイマー
により未実行にならないことは絶対にない。ただし、タ
イムアウトもしくはパス障害の場合には、真のトランザ
クション完了かどうかはわからないので、このトランザ
クション完了の待ち合わせはトランザクション負荷分散
機構101 にて行う。

【０１４９】通信処理装置12は、通信状態123 が未実行
となったら、ホストコンピュータ10に端末切断の通知を
行う(s603)。なお、この端末切断通知は、端末装置11か
ら切断要求を受けたときだけでなく、通信処理装置12に
てパス障害もしくはタイムアウトを検出したときも通知
される（図３のs314) 。

【０１５０】これを受けた任意のホストコンピュータ10
のトランザクション負荷分散機構101 は、GTSF151 の切
断にかかる端末対応のレコードをまず読み込む(s611)。

【０１５１】次に、GTSF151 の該当レコードのトランザ
クション実行可能状態1513は接続かどうかを確認する(s
612)。もしそうであれば、トランザクション実行可能状
態1513を切断処理中に設定して、GTSF151 に書き込む(s
613)。そして、切断する端末名を伴い、全ホスト切断要
求の送信をホスト間通信装置13に要求する(s614)。この
全ホスト切断要求を受信した各ホストコンピュータはs6
20の処理を行う。なお、ホスト間通信装置13は、要求の
送信元にはメッセージを届けないので、自ホストコンピ
ュータ10ではこれを受けたかのようにs620の処理を行
う。

【０１５２】全ホストコンピュータ10では、まず対象と
なる端末状態テーブル1011を検索する(s621)。つぎに、
GTSF151 の該当するレコードを読み込み、そのレコード
の内容に端末状態テーブル1011をあわせる。具体的に
は、以下の転記を行う(s622)。

【０１５３】○接続世代番号1512を10112 に転記する。 ○トランザクション実行可能状態1513を10113 に転記す
る。 ○接続業務名1514を10114 に転記する。

【０１５４】そして、端末状態テーブル1011のトランザ
クション実行状態10115 がもし未実行なら、各ホストト
ランザクション実行ビットマップ1515の自ホストID107
の位置のビットをクリアして、GTSF151 の書き込みを行
う。そうでなければ、GTSF151 の読み込み完了とする(s
623)。

【０１５５】各ホストコンピュータ10では、接続直後に
最初にTXreq を受信したときには、図４のs404で各ホス
トトランザクション実行ビットマップ1515が設定される
ということを考慮すると、全ホスト処理切断要求受信処
理s620が、すべてのホストコンピュータ10で行われれ
ば、トランザクションを実行中のホストコンピュータ10
だけが各ホストトランザクション実行ビットマップ1515
の該当するビットが設定されたままになっている。

【０１５６】すなわち、これまでGTSF151 にアクセスせ
ずにトランザクションを実行管理していたという状況
が、GTSF151 の各ホストトランザクション実行ビットマ
ップ1515をみれば浮き彫りにされるということになる。

【０１５７】このs620の処理は、s613にてトランザクシ
ョン実行可能状態1513が切断処理中と設定されてから実
施されるため、s622により各ホストコンピュータ10の端
末状態テーブル1011のトランザクション実行可能状態10
113 は切断処理中となる。s623にて、トランザクション
実行状態10115 がトランザクション実行中と判断され、
各ホストトランザクション実行ビットマップ1515のビッ
トを残したホストコンピュータ10では、トランザクショ
ン完了時にトランザクション実行可能状態10113 が切断
処理中であるため、前述した図５のs506〜s507で各ホス
トトランザクション実行ビットマップ1515のビットをク
リアする処理が行われる。これにより、s614によるs620
〜s623が実行されることにより、メモリである端末状態
テーブル1011でのみトランザクションの実行状態を管理
していたホストコンピュータ10内のトランザクションの
実行の完了が、GTSF151 の各ホストトランザクション実
行ビットマップ1515を監視することで、他ホストコンピ
ュータ10でも待ち合わせられるようになる。

【０１５８】また、GMQF152 を経由したホストコンピュ
ータ10間のトランザクションの実行は、GMQF152 に格納
する際にs432でGTSF151 のトランザクション実行状態15
16がGMQwrit と設定するか、もしくはホストコンピュー
タ10内でトランザクション実行完了前にシステム障害と
なったときにメッセージ復旧機構105 によってGMQF152
に格納されたメッセージは、GMQF152 から取り出される
ときにs528でトランザクション実行状態1516がGMQwrot
と設定されるので、トランザクション完了時にs503でト
ランザクション実行状態1516が未実行となるまでは、ト
ランザクション実行状態1516が未実行でない値となる。
従って、GTSF151 のトランザクション実行状態1516を監
視することで、どのホストコンピュータ10で実行される
かわからない負荷分散もしくは障害復旧されたメッセー
ジの完了が待ち合わせられるようになる。

【０１５９】この点を、切断通知を受けたホストコンピ
ュータ10の処理に戻って説明すると、図６では、s614を
行ったら、各ホストトランザクション実行ビットマップ
1515がオールゼロになったかどうかを判断する(s615)。
もしそうであれば、トランザクション実行状態1516が未
実行であるかどうかを判断する(s616)。いずれも満たす
場合には、トランザクション実行可能状態1513を未接続
に設定し、GTSF151 に書き込む(s617)。これにより、ト
ランザクションは完了し、切断は完了したために、以降
に接続要求を受けたときには、図２のs205にて接続が許
可されるようになる。

【０１６０】s615とs616のいずれかが満たされない場合
には、GTSF151 の読み込みを完了し、タイマー監視機構
1014でタイマーをかけて(s618)、一定時間後に再度GTSF
151を読み込み(s619)、s615とs616が満たされるまで待
ち合わせる。

【０１６１】本発明では、このようにして、端末装置11
接続中のトランザクション実行状態の管理は通信処理装
置12の通信状態123 で行われているため、トランザクシ
ョン実行中のメッセージ受信を拒否することができる。
また、端末装置11が切断したときの、トランザクション
実行中の再接続の拒否は、ホストコンピュータ10のトラ
ンザクション負荷分散機構101 で行われることになる。

【０１６２】TXreq を受信したホストコンピュータ10で
トランザクションが実行される場合には、接続直後と切
断処理中以外ではGTSF151 のアクセスは全く行わずにト
ランザクションの実行状態を管理することができる。

【０１６３】ただし、TXreq を受信したホストコンピュ
ータ10ですぐにトランザクションが起動できない場合に
は、GTSF151 のトランザクション実行状態1516を３回更
新することで、トランザクション実行状態を管理する。

【０１６４】このトランザクションの実行状態管理は、
端末装置11の再接続時の確認に用いられる。

【０１６５】最後に、システム障害となったときの状態
復旧方式について、図７を用いて説明する。

【０１６６】さきに何度か説明したことと重複するが、
あるホストコンピュータ10がシステム障害になると、こ
れをCPU 監視装置14が検出してクラスタシステムのいず
れかのホストコンピュータ10で代替ホスト復旧機構104
を起動する。

【０１６７】代替ホスト復旧機構104 では、システム障
害時にトランザクションファイル入出力制御106 を使用
してファイルアクセスしていた事象を検出し、コミット
まで至っていないファイル更新はすべて、更新前の状態
に戻す。そして、そのときに取得していたファイルやレ
コードの排他を、排他管理装置16により解除する。この
処理で状態が復帰されるのは、GMQF152 ，STCF153 なら
びにMSNF154 と、トランザクション実行時にトランザク
ション処理プログラムに更新されたさまざまのデータベ
ース（図示せず）である

【０１６８】なお、この処理ではGTSF151 は対象となら
ないが、GTSF151 を読み込みするときに排他管理装置16
に要求していた排他は、システム障害を検出したときに
代替ホスト復旧機構104 からの排他管理装置16への指示
で解除される。これまでの説明において、GTSF151 のア
クセスは、書き込みはすべて一回で行われているため、
あらゆるアクセス中においてシステム障害が発生して
も、更新内容が中途半端になることはなく、更新前もし
くは更新後のいずれかの内容となることが保証される。

【０１６９】代替ホスト復旧機構104 でのファイル復旧
が終了すると、代替ホスト復旧機構104 はメッセージ復
旧機構105 を起動する。メッセージ復旧機構105 では、
システム障害となったホストコンピュータ10のSTCF153
の内容を順次、GMQF152 にレコード挿入しては、STCF15
3 のレコードを削除することを繰り返す。

【０１７０】ホストコンピュータ10は、起動時に自分の
STCF153 の最終レコードに、レコードタイプ15311 がラ
ストレコード、ホストID15312 が自ホストID107 という
内容のラストレコード1531を書き込んでおく。もし、シ
ステム障害が発生した場合、メッセージ復旧機構105 に
おけるSTCF153 からGMQF152 への移動処理において、最
後にこのラストレコード1531が移動する。

【０１７１】この移動処理で移動対象となるSTCF153 の
レコードは、通常は完了レコードとなったものとラスト
レコード1531であるが、図４のs412もしくは図５のs532
でSTCF153 にトランザクション要求レコードが生成さ
れ、トランザクション完了時に完了レコードとしてコミ
ットされる前までにシステム障害となったトランザクシ
ョンについては、トランザクション要求レコードとして
GMQF152 に格納される。トランザクションとして更新し
たあらゆるデータベースは、トランザクション要求レコ
ードとともに代替ホスト復旧機構104 にて元に戻される
ので、トランザクションはまた最初から再実行すること
が必要となり、GMQF152 に格納されたトランザクション
要求レコードは、まさにそれを実現する。

【０１７２】図５のs521で、たまたまメッセージ復旧機
構105 が格納したトランザクション要求レコードを検出
することがあることを前に述べた。この検出されたトラ
ンザクション要求レコードはs526以降で処理される。こ
のように、GMQF152 の内容がトランザクションとして再
度実行されれば問題はない。（ただし、状態補正につい
てはまだ説明することがある）

【０１７３】図７のs740は、このメッセージ復旧機構10
5 の処理がいつ行われても、確実にGMQF152 のレコード
を処理するためのタイマー監視処理である。この処理
は、トランザクション負荷分散機構101 が起動したとき
から動作する。

【０１７４】まず、GMQF152 の先頭レコードの内容を確
認するGMQF格納内容確認処理s520を実行する。この処理
の結果として、全レコードが処理されたかどうか、すな
わちs522で読み込み失敗となったかどうかを返却する
（なお、s529でSTCF全レコード使用中と判断され、s530
で書き込みコミットした場合、s521で次のレコードが処
理されても、全レコード処理完了と判断されてもよい。
ここでは全レコード処理完了と判断されるものとする
が、続く説明には関与しない）。

【０１７５】これを判断し、もし読み込み失敗となって
いない、すなわち残りレコードがあるかもしれない場合
には、s520を繰り返す(s742)。

【０１７６】全レコードを処理したら、タイマー監視機
構1014で一定時間タイマーをかけて待ち合わせ、再度s5
20を行う(s743)。

【０１７７】これで中断されたトランザクションは再実
行されるが、トランザクションの実行状態の復帰は、次
のようにして行われる。

【０１７８】図５のs524でレコードタイプ10121 が要求
レコードでない場合には、リカバリレコード処理(s700)
を実行する。

【０１７９】まず、レコードタイプ10121 が完了レコー
ドであるか否かを判断する(s701)。完了レコードであれ
ば、GMQF格納フラグ10123 を判断する(s731)。GMQF格納
フラグ10123 がOFF であれば、完了レコードは不要であ
るためGMQF152 から削除してコミットする(s734)。GMQF
格納フラグ10123 がONであれば、端末名10122 から、GT
SF151 の該当するレコードを読み込む (s732) 。

【０１８０】もし、IOバッファ1012内のトランザクショ
ン実行番号10124 とGTSF151 内の該当レコードのトラン
ザクション実行番号1517が一致していれば、トランザク
ション実行状態1516を未実行にしてGTSF151 に書き込む
(s733)。このあと、完了レコードを削除する(s734)。

【０１８１】この処理は、TXreq を受信したホストコン
ピュータ10が処理できず、いったんGMQF152 に格納され
たメッセージがトランザクション実行し、トランザクシ
ョン実行タスク103 でトランザクション処理プログラム
が正常終了し、STCF153 は完了レコードとしてコミット
された直後に、トランザクション完了通知がトランザク
ション実行制御機構102 を経由してトランザクション負
荷分散機構101 に伝達され、図５のs500の処理が実行さ
れる前にシステム障害になった場合の状態補正である。

【０１８２】いったんGMQF152 に格納されるときには、
GTSF151 のトランザクション実行状態1516がGMQwrot と
なりトランザクション実行中を表している。GMQF152 か
らトランザクション実行するときには、図５のs533でト
ランザクション要求ブロック1013のGMQF格納フラグ1013
2 をONとすることで、トランザクション完了通知時にs5
02,s503 で、GTSF151 のトランザクション実行状態1516
が未実行に戻され、トランザクション実行が終了したこ
とを表す。このs503の代行処理を、s733において実行す
る。

【０１８３】トランザクションが完了し、s503で未実行
が設定され、次のTXreq を受け付けた後でも、トランザ
クション完了時に完了レコードとしたSTCF153 のレコー
ドは残っている。このため、図４のs432でGMQwrit を書
き込む際や、メッセージ復旧機構105 がSTCF153 からGM
QF152 に移したレコードをGMQF格納内容確認処理s520で
処理する場合のs528でGMQwrot を書き込む際に、それに
先立ってs430やs527においてトランザクション実行番号
1517を１加算して、トランザクションごとに一意の番号
を採番し、トランザクション実行番号10124 に転記して
いる。すなわち、GTSF151 内のトランザクション実行番
号1517の番号と、完了レコードのトランザクション実行
番号10124 が一致していれば、まさにそのとき実行中の
トランザクションの完了レコードであることになり、一
致していなければ、過去にすでに処理された古い完了レ
コードということになる。

【０１８４】s701でレコードタイプ10121 が完了レコー
ドでなければ、ラストレコードである。このレコードの
存在は、システム障害になったホストコンピュータの過
去の実行状態が障害復旧されていないことを意味する。
s720からs730までの一連の処理は、システム障害になっ
たホストコンピュータの障害直前の状態を定常状態に復
旧するための処理となる。

【０１８５】システム障害となったホストコンピュータ
に対応するGTSF151 の各ホストトランザクション実行ビ
ットマップ1515をクリアすることが、本障害復旧処理の
目的の一つである。というのも、通常は端末切断時に
は、各ホストコンピュータ10にてトランザクション実行
中かどうかを判断して、この各ホストトランザクション
実行ビットマップ1515の自ホストのビットをクリアする
のだが（図６のs623ならびに図５のs507）、システム障
害となったホストコンピュータでは、この処理はなされ
ないため、ビットがクリアされずに残ってしまうからで
ある。

【０１８６】システム障害となったホストコンピュータ
では、図４のs409以降の処理にて、GTSF151 の更新を行
わずにトランザクションを実行していた場合に、処理途
中であったトランザクションについては、本処理のきっ
かけとなったラストレコードの検出の前に、すべてs520
のGMQF格納内容確認処理で処理されている。先の説明の
繰り返しとなるが、s526ではGMQF格納フラグを確認し、
s528でGTSF151 のトランザクション実行状態1516をGMQw
rot 状態に書き込んでいるため、トランザクション完了
まで再接続が抑制されることになる。従って、ラストレ
コードを検出したこの図７のs704, S720〜s730において
は、s724において各ホストトランザクション実行ビット
マップ1515の障害ホストのビットをクリアすることが可
能である。

【０１８７】また、もう一つのシステム障害復旧処理の
目的は、ホストコンピュータ10で、s432でGTSF151 のト
ランザクション実行状態1516をGMQwrit にしたにもかか
わらず、GMGF152 およびNSNF154 の書き込みコミットs4
36が実行される直前にシステム障害となった場合の、ト
ランザクション実行状態1516を未実行に戻す処理であ
る。これにより、切断時の再接続が可能となる。

【０１８８】なお、図４にs400でTXreq 受信時に、s430
からs438でGMQF152 に要求レコードを格納した際に、他
のホストコンピュータでこれをいち早く処理させるため
にホスト間通信要求をs438で行っているが、この格納し
たGMQFメッセージを或るホストコンピュータ10で処理さ
れてしまうのと同時に、システム障害のメッセージ復旧
機構105 が動作して、たまたま同じGMQFアドレスにラス
トレコードが格納されてしまった場合、遅れてこのホス
ト間通信要求を受けたホストコンピュータ10では、図５
のs540以降の処理でラストレコードが先に処理されてし
まうと、本実施の形態で述べる障害復旧処理では処理不
足となる。これには、s542で、レコードタイプがラスト
レコードなら、s543の読み込みコミットを行うことで解
決する。

【０１８９】では、図７にてこれらの処理を詳細に説明
する。

【０１９０】s701で完了レコードでない、すなわちラス
トレコードと判断された場合、一旦GMQF152 をコミット
する(s704)。

【０１９１】次に、GTSF151 の最初のレコードを読み込
む(s720)。この読み込みが成功した場合(s722 でNO) 、
そのレコードのトランザクション実行状態1516がGMQwri
t であり、かつホストID15181 が、システム障害となっ
たホストコンピュータ10のものかどうかを確認する。こ
れは、ラストレコード1531におけるホストID15312 と比
較することで確認できる(s723)。

【０１９２】もしそうでなければ、先に述べたように各
ホストトランザクション実行ビットマップ1515のホスト
ID15312 で示されるビットのクリアを行い、GTSF151 を
書き込む。そして次のGTSFレコードを読み(s724)、s722
から繰り返す。

【０１９３】もし、s723の判断が真、つまり、そのレコ
ードのトランザクション実行状態1516がGMQwrit であり
且つホストID15181 がシステム障害となったホストコン
ピュータ10のものであった場合、図４のs432でGMQwrit
を書き込んだ直後に書き込んだ、GMQF152 とMSNF154
が、s436のコミットまで達したかどうかを確認する。そ
れには、さきに述べたとおり、ホストID15181 のホスト
のMSNF154 を読み(s725)、シーケンス番号を15182 と15
41で比較する(s726)。

【０１９４】これらのシーケンス番号が一致していれ
ば、GMQF152 とMSNF154 の書き込みはコミットs436まで
達していることになるため、GTSF151 のトランザクショ
ン実行状態1516をGMQwrot に設定する(s727)。また、一
致していなければトランザクション実行状態1516を未実
行に設定する(s728)。

【０１９５】MSNF154 の読み込みのコミットを行ない(s
729)、s724で各ホストトランザクション実行ビットマッ
プ1515の該当するビットのクリア処理を行う。

【０１９６】s722でGTSF151 の読み込みに失敗したら、
GTSF151 の全レコードが処理されたと解釈し、GMQF152
のラストレコード1531を削除し、コミットする(s730)。
これにより、このリカバリレコード処理(s700)は行われ
なくなる。

【０１９７】以上により、あらゆるタイミングでホスト
コンピュータ10がシステム障害となっても、トランザク
ション実行状態を復帰することができる。上記処理をま
とめると、以下のようになる。

【０１９８】○システム障害ホストコンピュータ10でST
CF153 にメッセージが書き込まれコミットされたのに、
トランザクションが完了しなかったものは、障害復旧後
は、GTSF151 のトランザクション実行状態1516で管理さ
れるようになる(s526 〜s528)。本処理は、s701でラス
トレコード検出がされる前にすべて実行されている。 ○この処理をおこなえば、GTSF151 の各ホストトランザ
クション実行ビットマップ1515はシステム障害ホストコ
ンピュータ10の分をクリアすることができる(s724)。 ○GTSF151 のトランザクション実行状態1516で管理され
ているときに、トランザクションが完了した時点で未実
行を書けずにシステム障害となった場合には、完了レコ
ードによって未実行化する(s731 〜s734) 。 ○GMQwrit を書き込み、GMQwrot を書く前にシステム障
害になった場合には、MSNF154 を判断して状態を補正す
る(s723 〜s729) 。

【０１９９】本発明にて、システム障害となったときの
状態復旧で問題となる点は、TXackを返却しようとして
いたときにシステム障害となった場合のTXack 返却と、
トランザクションが完了したのにもかかわらずトランザ
クション完了通知がトランザクション負荷分散機構101
に届かずにシステム障害になった場合のTXreply 返却で
ある。

【０２００】TXack については、通信処理装置12ではタ
イムアウトを検出すると、一度だけ他ホストコンピュー
タ10にreTXreq を送ることができるが、これも失敗する
と端末装置11を切断することになる( 図３のs312) 。

【０２０１】また、TXreply についてはタイムアウトを
検出すると、端末装置11を切断する（図３のS316）。

【０２０２】しかし、本発明は、このような時点におい
て端末装置11のオペレータが再接続して再度トランザク
ションを実行させようとしたときに、トランザクション
実行中であれば再接続を拒否し、状態復旧が終了すれば
再接続を許すことで、トランザクション処理の順序不整
合を生じないようにしている。

【０２０３】

【実施例】次に、本発明の実施例を、図８を参照して説
明する。

【０２０４】図８は、端末名Term1 の端末装置11が接続
業務名app1で接続しているときに、その端末装置11から
メッセージを受信し、トランザクションを起動するとき
の図である。

【０２０５】通信処理装置12は、自ホストID107 が２で
あるホストコンピュータ10に対しては、これまでたとえ
ば27回のTXreq を送信してきた為、今回でシーケンス番
号121 は28となっている。また、Term1 は本クラスタシ
ステム全体で、過去に９回接続した経緯があるため、今
回の接続世代番号124 は10になっている。シーケンス番
号121 は、通信処理装置12でカウント制御を行い、接続
世代番号124 はGTSF151 の接続世代番号1512でカウント
制御を行っている。

【０２０６】通信処理装置12はホストコンピュータ10に
TXreq を送るときに、通信状態123をトランザクション
実行中と設定する(s303)。また、TXreply や、各種障害
が発生すると、未実行と設定する(s317 、s313) 。これ
により、通信処理装置12のトランザクション実行状態が
管理されることになる。具体的には、図８のように、通
信状態123 がトランザクション実行中と設定されている
状態でTerm1 から次のメッセージを投入されると、s301
で通信状態123 が未実行でないため、拒否される(s30
2)。また、TXreply が通知される前にTerm1 から切断要
求を受け、再接続を受けても、通信状態123 が未実行で
なければs201で接続を拒否する。

【０２０７】ただし、TXack やTXreply のタイムアウト
やパス障害があると、ホストコンピュータ10はシステム
障害になったかもしれないと判断し、通信状態123 を未
実行状態としてしまう(s313)。このため、このときの再
接続を許可するかどうかは、トランザクション負荷分散
機構101 で管理するトランザクション実行状態にかかっ
ている。

【０２０８】ホストコンピュータ10が接続後はじめて端
末装置11からTXreq を受信したときには、端末状態テー
ブル1011の各情報領域がGTSF151 から、図８の10111 〜
10114 のように設定されると同時に、GTSF151 の各ホス
トトランザクション実行ビットマップ1515は、自ホスト
ID107 が２のために２ビット目が設定されている（図
は、各ホストトランザクション実行ビットマップ1515だ
けは二進数で表現している）。また、図８では４番目の
ビットも設定されていることから、自ホストID107 ＝４
の別のホストコンピュータでもTXreq を過去に受信して
いることがわかる（s402〜s404参照）。

【０２０９】TXreq を受け付けて、トランザクション実
行するために、トランザクション実行状態10115 はトラ
ンザクション実行中と設定される（s407）。

【０２１０】トランザクションが実行可能であるとs408
で判断されると、トランザクション要求ブロック1013が
設定される。GMQF格納フラグ10132 がOFF となっている
(s413)ため、トランザクションの完了時には、GTSF151
をアクセスすることはなく(s502)、トランザクション実
行状態10115 のみ未実行に更新されるだけである(s50
4)。これにより、ホストコンピュータ10でのトランザク
ション実行状態は、そのホストコンピュータ10で最初の
TXreq 受信でなく(s402)、切断処理中でない(s506)場合
については、全くGTSF151 にアクセスすることなく管理
されることになる。

【０２１１】たとえばTXack/TXreply のタイムアウトや
パス障害が発生したことによって、端末切断通知を受け
ると(s603)、GTSF151 のトランザクション実行可能状態
1513を切断処理中と設定し(s613)、s622で端末状態テー
ブル1011のトランザクション実行可能状態10113 に設定
される。以降でトランザクションが終了したときにはs5
06,s507 で各ホストトランザクション実行ビットマップ
1515をクリアする。これにより、図８では各ホストトラ
ンザクション実行ビットマップ1515の第２ビットがクリ
アされることになる。

【０２１２】また、s614の全ホスト切断要求のホスト間
通信によって、ホストコンピュータ10でトランザクショ
ンがすでに完了しており、トランザクション実行状態10
115が未実行であれば、各ホストトランザクション実行
ビットマップ1515の該当ビットをクリアする(s623)。こ
れにより、図８では各ホストトランザクション実行ビッ
トマップ1515の第４ビット以降もクリアされる。

【０２１３】s615とs616で、各ホストトランザクション
実行ビットマップ1515とトランザクション実行状態1516
を確認するが、図８の状態ではトランザクション実行状
態1516は未実行であり、各ホストトランザクション実行
ビットマップ1515は上記処理で、現在実行中のトランザ
クションが完了時にクリアされるため、s617でトランザ
クション実行可能状態1513が未接続に設定される。これ
により、トランザクションが完了すれば、再接続時のs2
05で接続を拒否されなくなる。

【０２１４】受信メッセージイメージはIOバッファ1012
に設定されて、STCF153 に書かれ(s410)、MSNF154 には
シーケンス番号121 値が設定されて（s411）コミットさ
れている(s412)。

【０２１５】このトランザクションは、トランザクショ
ン実行タスク103 で実行されたときにSTCF153 のレコー
ドは完了レコードに変更される。これにより、システム
障害発生時がトランザクション完了前であれば、他ホス
トコンピュータ10のメッセージ復旧機構105 によって、
STCFレコードがGMQF152 に格納されることで、s520によ
りトランザクションが再実行される。

【０２１６】STCF153 に書き込むコミットの前(s412)に
システム障害が発生すれば当然再実行はされない。これ
は、s416で返されるべきTXack が通信処理装置12に返却
されないため、通信処理装置12のタイマー監視機構126
でタイムアウトを検出し(s305 →s310) 、reTXreq が別
ホストコンピュータ10に通知されて再実行が行われるか
らである。もしここでもTXack が遅れた場合には、Term
1 はs315で切断される。切断された場合、Term1 から投
入したメッセージは受け付けられたかどうかが不明であ
り、トランザクションが実行されたかどうかは端末オペ
レータからはわからないが、再接続して拒否されれば実
行中ということがわかる。再接続が成功したら、さきの
トランザクションは確実に完了しているか、まったく未
実行でいっさい行われないかのいずれかであるため、デ
ータベースを参照すればその行方がわかることになる。

【０２１７】一方、STCF153 に書き込むコミットの後(s
412)にシステム障害が発生した場合には、トランザクシ
ョンは確実に実行される。しかし、TXack を返却する前
にシステム障害が発生した場合には、通信処理装置12と
しては前と同様タイムアウトを検出し（s305→s310）、
reTXreq を送ってくる。この場合には、MSNF154 に旧TX
req 通知ホスト番号=2、旧TXreq シーケンス番号=28 で
あるので、MSNFを読むと、28と書き込んであるために、
s453ですでに受付済みのTXack が通信処理装置12に返却
される。これにより、s312→s309と動作し、Term1 を切
断せずに、トランザクションの完了であるTXreply を通
信処理装置12は待つことになる。端末には、正常受付が
返っているため、この場合はトランザクションは確実に
実行されるということを認識できることになる。

【０２１８】システム障害が発生すると、正規のTXrepl
y がたとえ返却されたとしても、障害ホストコンピュー
タ10の各ホストトランザクション実行ビットマップ1515
がクリアされないので、このままではTerm1 が切断され
たときにs615の判断でタイマー待ち合わせになり、トラ
ンザクション実行可能状態1513が切断処理中のままとな
ってしまうため、このあとの再接続がs205で許可されな
くなってしまう。

【０２１９】これを防ぐため、本実施例では、トランザ
クション負荷分散機構101 起動時にSTCF153 のラストレ
コード1531を作成しておく。メッセージ復旧機構105 で
このラストレコード1531をGMQF152 に格納すると、GMQF
監視タイマー処理s740やその他の処理により、s524の判
断でリカバリレコード処理s700が実行される。ここで
は、最終的にs724にて、発見されたラストレコード1531
のホストID15312 と一致する位置の各ホストトランザク
ション実行ビットマップ1515のビットをクリアするた
め、この処理が行われればTerm1 切断時のs615は解決さ
れ、再接続が可能となる。

【０２２０】ただし、実行中のトランザクションは、ST
CF153 のレコードが残っているため、これがメッセージ
復旧機構105 でGMQF152 に移され、GMQF監視タイマー処
理s740などでGMQF格納内容確認処理s520にてトランザク
ション実行が行われ、これが完了するまで待ち合わせな
ければならない。

【０２２１】このため、TXreq 受信時のSTCFレコード作
成時には、図８のようにIOバッファ1012に10121 から10
124 までの情報を書き込んでおく(s409)。

【０２２２】もし、このトランザクション実行前のレコ
ードがGMQF152 に格納されたままで実行されずにいた場
合には、ラストレコード1531によるリカバリレコード処
理s700においてs724に各ホストトランザクション実行ビ
ットマップ1515クリア処理が行われる前に、s740のGMQF
監視タイマー処理もしくはs500のトランザクション完了
通知の処理の延長で実行されるs520のGMPF格納内容確認
処理において、GMQFレコードを読み込み、レコードタイ
プ10121 が要求レコードでGMPF格納フラグ10123 がOFF
のもの(s524,s526) は、s527〜s528の処理によって、ト
ランザクション実行状態1516がGMQwrot と更新される。
これにより、ラストレコード1531によるリカバリレコー
ド処理s700においてs724で各ホストトランザクション実
行ビットマップ1515がクリアされても、トランザクショ
ンが完了するまで、s616で切断処理は待ち合わせられ、
再接続は待たされることになる。s528にてGMQF格納フラ
グ10123 がONと設定されるため、トランザクション完了
時にはs502,s503 によってトランザクション実行状態15
16が未実行状態に戻されるため、切断処理中ならs616は
解除され、再接続が許可される。

【０２２３】図９は、TXreq を受け付けたときにホスト
過負荷状態もしくは空きSTCFレコードがない場合の、GM
QF152 にメッセージを格納したときのコミット直後の図
である。図８と異なる点は、GTSF151 のトランザクショ
ン実行状態1516がGMQwrit 、トランザクション実行番号
1517が１加算されていることと、IOバッファ1012のGMQF
格納フラグ10123 がON、トランザクション実行番号1012
4 にトランザクション実行番号1517の値が格納されてい
ること、ならびにIOバッファ1012の内容がGMQF152 に書
き込まれていることである。

【０２２４】このあと、なにも障害がなければトランザ
クション実行状態1516はGMQwrot と設定され(s437)、s4
38によるGMQF実行要求のホスト間通信を受けて最初に実
行したホストコンピュータ10が、s540にてレコードを読
み込み、トランザクションを実行する。このとき、トラ
ンザクション要求ブロック1013のGMQF格納フラグ10132
はONとなるため(s533)、トランザクション完了時にはs5
02〜s503でトランザクション実行状態1516が未実行とさ
れる。

【０２２５】このトランザクションの実行状態の管理
は、図８のSTCFレコードがシステム障害によってGMQF15
2 に格納されたときの管理とまったく同じため、詳細な
説明は省略する。

【０２２６】さて、図９の状態、もしくは図９の直前の
状態で、トランザクション実行状態1516がs432でGMQwri
t と設定されたまま、GMQwrot とならずにシステム障害
となった場合をここでは説明する。

【０２２７】もし、図９のように書き込みコミットs436
が実行された後であるときを説明する。システム障害と
なると、まずs416で返却されるべきTXack が通信処理装
置12に通知されないため、通信処理装置12はs311でreTX
req を送ってくる。旧TXreq処理ホスト番号=2、旧TXreq
シーケンス番号=29 であるため、MSNF154 を参照して
これはs453によりすでに受け付け済みのTXack が返却さ
れることにより、通信処理装置12は正常にTXreply を待
つことになる。

【０２２８】GMQF152 のレコードは、そのうち他のトラ
ンザクションの完了通知s500の延長やGMQF監視タイマー
s740によって起動されるGMQF格納内容確認処理s520に
て、トランザクションが実行される。このトランザクシ
ョンの完了時には、トランザクション実行状態1516がGM
Qwrot でなくとも、s503で未実行となる。

【０２２９】もし、TXreq 受信時に書き込みコミットs4
36の直前でシステム障害となった場合にはどうなるであ
ろうか。通信処理装置12はs416で返されるべきTXack の
パス障害もしくはタイムアウトを検出し、reTXreq を送
ってくる(s305,s310,s311)。これはs450で処理され、s4
52の判断でs401に流れ、通常のTXreq と同じルートを通
過し、トランザクションは通常どおり動作する。このと
き、トランザクション実行状態1516が未実行でないのに
もかかわらずトランザクションが実行されることになる
が、この処理ではトランザクション実行状態1516がGMQw
rit としたメッセージがs452の判断で確実に書かれてい
ないため問題はない。

【０２３０】ただし、このreTXreq が通知されなければ
どうなるであろうか。たとえば、reTXreq の処理でs408
でトランザクション実行不可と判断され、s430〜s436と
なる前にシステム障害が発生してしまうケースである。
この場合、通信処理装置12はs312の判断でs313〜s315の
処理により、端末切断となってしまう。

【０２３１】この場合には、トランザクション実行状態
1516がGMQwrit のままで残っているため、s314で送られ
た切断通知を受けたトランザクション負荷分散機構101
は、s616で待ち合わせを起こしてしまう。

【０２３２】このため、システム障害をラストレコード
によって検出したリカバリレコード処理s700では、s722
のループ処理によって全GTSF151 レコードを読み、s723
にてトランザクション実行状態1516がGMQwrit であり、
かつ障害ホストコンピュータ10で書かれたものであれ
ば、s726にてMSNF154 を確認し、この場合にはs728にて
トランザクション実行状態1516を未実行に補正する。こ
れにより、s616の待ち合わせは解除され、再接続が可能
となる。

【０２３３】なお、通信処理装置12でこのようなタイム
アウトもしくはパス障害を検出し、端末装置11を切断し
た場合は、ホストコンピュータ10に切断通知を行うs314
も失敗する可能性がある。この場合に備え、再接続時
に、切断処理が完了していなければ、s206のあとでs610
の切断処理を行っておき、次回接続時に備える。

【０２３４】図１０は本発明を適用したトランザクショ
ン処理システムの構成例を示し、図１と同一符号は同一
部分を示し、1000,1001 はCD-ROM, 磁気ディスク等の機
械読み取り可能な記録媒体である。記録媒体1000に記録
された通信処理装置用プログラムは、通信処理装置12を
構成するコンピュータに読み取られ、そのコンピュータ
の動作を制御し、そのコンピュータに先の実施の形態お
よび実施例で説明した各種の処理を行わせる。また、記
録媒体1001に記録されたホストコンピュータ用プログラ
ムは、ホストコンピュータ10に読み取られ、そのホスト
コンピュータの動作を制御し、そのホストコンピュータ
に先の実施の形態および実施例で説明した各種の処理を
行わせる。

【０２３５】

【発明の効果】以上説明したように本発明によれば以下
のような効果が得られる。

【０２３６】通信処理装置のメモリ上の「通信状態」で
個々の端末装置の状態（トランザクション実行状態）を
一括管理することで、ファイルＩ／Ｏ無しに、同一端末
にかかる複数トランザクションの同時実行拒否の制御が
通信処理装置において可能となる。

【０２３７】ホストコンピュータ側でも端末状態管理レ
コード中の各ホストコンピュータと１対１に対応するビ
ットから構成されるビットマップ，「トランザクション
実行状態」，「トランザクション実行可能状態」で個々
の端末装置の状態（トランザクション実行状態）を管理
しているため、通信処理装置が、トランザクション完了
メッセージの待ち合わせ中に全ホストコンピュータとの
間にパス障害が発生した場合およびタイムアウトが生じ
た場合に該当する端末の「通信状態」を未実行にした場
合、実際には先に投入されたメッセージがホストコンピ
ュータで受け付けられていたり、実行がまだ継続してい
た場合に、同一端末にかかる複数トランザクションの同
時実行に結びつく再接続を確実に阻止することができ
る。また、ビットマップ，「トランザクション実行状
態」，「トランザクション実行可能状態」へのアクセス
はごく限られた時点で行われ、各ホストコンピュータ内
での端末毎のトランザクションの実行状態はメモリ上の
端末状態テーブルで行うため、この意味でもファイルＩ
／Ｏ数が削減される。

【０２３８】障害発生ホストコンピュータに対応するビ
ットマップのビットのリセット，障害発生ホストコンピ
ュータが処理を担っていた端末の端末状態管理レコード
中の「トランザクション実行状態」の状態変更機能を有
することにより、いずれかのホストコンピュータに障害
が発生した場合でも、端末状態の管理状態を正しく補正
して端末の再接続が可能となる。

【図面の簡単な説明】

【図１】本発明の実施の形態の例を示す構成図である。

【図２】端末装置からの接続における処理と拒否方式に
関する流れ図である。

【図３】端末からメッセージを受信し、トランザクショ
ンとして実行するときの、通信処理装置の流れ図であ
る。

【図４】通信処理装置からTXreq を受け付けてから、ト
ランザクションを起動するまでのトランザクション負荷
分散機構の流れ図である。

【図５】トランザクションが完了したことをトランザク
ション負荷分散機構が受け取ったときの流れ図、ならび
にその時点でGMQFにキューイングされていたメッセージ
の再処理の流れ図である。

【図６】端末から切断が通知されたときの、クラスタシ
ステム全体の流れ図である。

【図７】システム障害が発生したとき、他ホストコンピ
ュータでこれを検出したときの状態補正処理の流れ図、
ならびにこれを検出するためのタイマー監視処理の流れ
図である。

【図８】TXreq を受け付けて、トランザクションを起動
する直前の実施例の図である。

【図９】TXreq を受け付けて、GMQFに格納した直後の実
施例の図である。

【図１０】本発明を適用したトランザクション処理シス
テムの構成例を示す図である。

【符号の説明】

10 ホストコンピュータ 101 トランザクション負荷分散機構 1011 端末状態テーブル 10111 端末名 10112 接続世代番号 10113 トランザクション実行可能状態 10114 接続業務名 10115 トランザクション実行状態 1012 IOバッファ 10121 レコードタイプ 10122 端末名 10123 GMQF格納フラグ 10124 トランザクション実行番号 10125 メッセージ 1013 トランザクション要求ブロック 10131 端末状態テーブルアドレス 10132 GMQF格納フラグ 102 トランザクション実行制御機構 103 トランザクション実行タスク 104 代替ホスト復旧機構 105 メッセージ復旧機構 106 トランザクションファイル入出力制御 107 自ホストID（識別値） 11 端末装置 12 通信処理装置 121 シーケンス番号 123 通信状態 124 接続世代番号 126 タイマー監視機構 13 ホスト間通信装置 14 CPU 監視装置 15 ホスト間共有高速メモリ媒体 151 グローバル端末状態ファイル(GTSF) 1511 端末名 1512 接続世代番号 1513 トランザクション実行可能状態 1514 接続業務名 1515 各ホストトランザクション実行ビットマップ 1516 トランザクション実行状態 1517 トランザクション実行番号 1518 重送チェック情報 15181 ホストID 15182 シーケンス番号 152 グローバルメッセージキューファイル(GMQF) 153 スケジュールトランザクション制御ファイル(S
TCF) 1531 ラストレコード 15311 レコードタイプ 15312 ホストID 154 メッセージ順序番号ファイル(MSNF) 1541 シーケンス番号 16 排他管理装置

───────────────────────────────────────────────────── フロントページの続き (51)Int.Cl.⁶ 識別記号 ＦＩ Ｇ０６Ｆ 15/16 ３８０ Ｇ０６Ｆ 15/16 ３８０Ｄ

Claims (9)

【特許請求の範囲】
1. 【請求項１】 ファイル装置および通信処理装置を共有
   する複数のホストコンピュータで構成されたファイル共
   有型疎結合クラスタシステム上に構築されたトランザク
   ション処理システムにおいて、 通信処理装置で、各端末毎に、その端末にかかるトラン
   ザクションが何れのホストコンピュータでも未実行か否
   かをメモリ上の「通信状態」において管理し、「通信状
   態」が未実行でない端末からの接続要求および入力メッ
   セージを拒否することを特徴とするトランザクション処
   理システムにおける端末状態管理方法。
2. 【請求項２】 通信処理装置において、トランザクショ
   ン完了メッセージが何れかのホストコンピュータから返
   却された時点で該当する端末の「通信状態」を未実行に
   し、端末からの入力メッセージを受け付けた時点でその
   端末の「通信状態」をトランザクション実行中とする請
   求項１記載のトランザクション処理システムにおける端
   末状態管理方法。
3. 【請求項３】 通信処理装置において、トランザクショ
   ン完了メッセージの待ち合わせ中に全ホストコンピュー
   タとの間にパス障害が発生した場合およびタイムアウト
   が生じた場合、該当する端末の「通信状態」を未実行に
   し、且つその端末との接続を切断することを特徴とする
   請求項２記載のトランザクション処理システムにおける
   端末状態管理方法。
4. 【請求項４】 ファイル装置上のグローバル端末状態フ
   ァイルに設けた各端末毎のレコード中に、その端末から
   の接続要求を何れかのホストコンピュータが受け付けた
   時点で「接続」に設定され、その端末にかかるトランザ
   クションが何れのホストコンピュータでも実行されてい
   る可能性が無くなり再接続可能な状態となった時点で
   「未接続」に設定される「トランザクション実行可能状
   態」を設け、 各ホストコンピュータにおいて、通信処理装置から或る
   端末にかかる接続要求を受けたとき、グローバル端末状
   態ファイルのその端末に対応するレコードの「トランザ
   クション実行可能状態」を参照し、「未接続」でなけれ
   ば接続を拒否することを特徴とする請求項３記載のトラ
   ンザクション処理システムにおける端末状態管理方法。
5. 【請求項５】 ファイル装置および通信処理装置を共有
   する複数のホストコンピュータで構成されたファイル共
   有型疎結合クラスタシステム上に構築され、ファイル装
   置上のグローバルメッセージキューファイルを通じてト
   ランザクション処理にかかるメッセージをホストコンピ
   ュータ間で受け渡すことによりトランザクション処理の
   負荷を各ホストコンピュータで分散するようにしたトラ
   ンザクション処理システムにおいて、 通信処理装置のメモリ上に各端末毎に設けた「通信状
   態」を、その端末にかかるトランザクション完了メッセ
   ージが何れかのホストコンピュータから通信処理装置に
   返却された時点，トランザクション完了メッセージの待
   ち合わせ中に全ホストコンピュータとの間にパス障害が
   発生した時点およびタイムアウトが生じた時点で未実行
   に設定し、その端末からの入力メッセージを受け付けた
   時点でトランザクション実行中に設定することにより、
   各端末の状態を通信処理装置で一括管理し、「通信状
   態」が未実行でない端末からの接続要求および入力メッ
   セージがあったときは、通信処理装置において拒否する
   ようにし、 ファイル装置上のグローバル端末状態ファイルに各端末
   毎に設けた端末状態管理レコード中の、各ホストコンピ
   ュータと１対１に対応するビットから構成されるビット
   マップの各ビットを、そのビットに対応するホストコン
   ピュータがその端末からの接続要求を処理するか或いは
   最初の入力メッセージを受けた時点でセットし、そのビ
   ットに対応するホストコンピュータがその端末のトラン
   ザクション処理を実行しておらずその端末と切断状態と
   なった時点でリセットすることにより、各端末毎に、そ
   の端末のトランザクションを実行している可能性のある
   ホストコンピュータを前記ビットマップで管理しておく
   と共に、前記端末状態管理レコード中に設けた「トラン
   ザクション実行状態」を、その端末の入力メッセージを
   前記グローバルメッセージキューファイルに格納した時
   点で未実行以外に設定し、その入力メッセージにかかる
   トランザクションの実行が何れかのホストコンピュータ
   で完了した時点で未実行に設定することにより、各端末
   毎に、その端末のトランザクションが負荷分散により何
   れかのホストコンピュータで実行される可能性があるか
   否かを管理しておき、更に、前記端末状態管理レコード
   中の「トランザクション実行可能状態」を、何れかのホ
   ストコンピュータがその端末からの接続要求を受け付け
   た時点で接続に設定し、前記ビットマップの全ビットが
   リセットされ且つ前記「トランザクション実行状態」が
   未実行となった時点で未接続に設定し、通信処理装置か
   ら或る端末の接続要求を受けたホストコンピュータにお
   いて、その端末に対応する前記端末状態管理レコード中
   の「トランザクション実行可能状態」が未接続でなけれ
   ば接続を拒否することを特徴とする請求項４記載のトラ
   ンザクション処理システムにおける端末状態管理方法。
6. 【請求項６】 前記端末状態管理レコード中の「トラン
   ザクション実行状態」を、その端末の入力メッセージを
   前記グローバルメッセージキューファイルに格納した時
   点で未実行以外に設定する処理は、新たに採番したシー
   ケンス番号をグローバルメッセージキューファイルに書
   き込んで「トランザクション実行状態」をグローバルメ
   ッセージキュー書き込み開始に設定し、次いで、入力メ
   ッセージを前記グローバルメッセージキューファイルに
   書き込むと共に前記シーケンス番号を自ホスト対応のメ
   ッセージ順序番号ファイルに書き込んで両書き込みをコ
   ミットし、次いで、「トランザクション実行状態」をグ
   ローバルメッセージキュー書き込み完了に設定する処理
   を含むことを特徴とする請求項５記載のトランザクショ
   ン処理システムにおける端末状態管理方法。
7. 【請求項７】 ファイル装置および通信処理装置を共有
   する複数のホストコンピュータで構成されたファイル共
   有型疎結合クラスタシステム上に構築され、ファイル装
   置上のグローバルメッセージキューファイルを通じてト
   ランザクション処理にかかるメッセージをホストコンピ
   ュータ間で受け渡すことによりトランザクション処理の
   負荷を各ホストコンピュータで分散すると共に、何れか
   のホストコンピュータに障害が発生した場合、その障害
   発生ホストコンピュータが受け持っていた未処理の入力
   メッセージを前記グローバルメッセージキューファイル
   に格納することで正常な他のホストコンピュータによる
   代替処理を可能としたトランザクション処理システムに
   おいて、 通信処理装置のメモリ上に各端末毎に設けた「通信状
   態」を、その端末にかかるトランザクション完了メッセ
   ージが何れかのホストコンピュータから通信処理装置に
   返却された時点，トランザクション完了メッセージの待
   ち合わせ中に全ホストコンピュータとの間にパス障害が
   発生した時点およびタイムアウトが生じた時点で未実行
   に設定し、その端末からの入力メッセージを受け付けた
   時点でトランザクション実行中に設定することにより、
   各端末の状態を通信処理装置で一括管理し、「通信状
   態」が未実行でない端末からの接続要求および入力メッ
   セージがあったときは、通信処理装置において拒否する
   ようにし、 ファイル装置上のグローバル端末状態ファイルに各端末
   毎に設けた端末状態管理レコード中の、各ホストコンピ
   ュータと１対１に対応するビットから構成されるビット
   マップの各ビットを、そのビットに対応するホストコン
   ピュータがその端末からの接続要求を処理するか或いは
   最初の入力メッセージを受けた時点でセットし、そのビ
   ットに対応するホストコンピュータがその端末のトラン
   ザクション処理を実行しておらずその端末と切断状態と
   なった時点でリセットすることにより、各端末毎に、そ
   の端末のトランザクションを実行している可能性のある
   ホストコンピュータを前記ビットマップで管理しておく
   と共に、前記端末状態管理レコード中の「トランザクシ
   ョン実行状態」を、その端末の入力メッセージを前記グ
   ローバルメッセージキューファイルに格納した時点で未
   実行以外に設定し、その入力メッセージにかかるトラン
   ザクションの実行が何れかのホストコンピュータで完了
   した時点で未実行に設定することにより、各端末毎に、
   その端末のトランザクションが負荷分散により何れかの
   ホストコンピュータで実行される可能性があるか否かを
   管理しておいて、ビットマップの全ビットがリセットさ
   れていないか、「トランザクション実行状態」が未実行
   でない端末からの接続要求は、その要求を通信処理装置
   から受けたホストコンピュータにおいて拒否するように
   し、 何れかのホストコンピュータに障害が発生した場合、そ
   の障害発生ホストコンピュータが受け持っていた未処理
   の入力メッセージを前記グローバルメッセージキューフ
   ァイルに格納することで正常な他のホストコンピュータ
   による代替処理を可能とした後、その障害発生ホストコ
   ンピュータに対応するビットマップのビットをリセット
   すると共に、その障害発生ホストコンピュータで処理の
   完了していたメッセージを認識して該当する端末の端末
   状態管理レコード中の「トランザクション実行状態」を
   未実行に設定するようにしたことを特徴とするトランザ
   クション処理システムにおける端末状態管理方法。
8. 【請求項８】 ファイル装置および通信処理装置を共有
   する複数のホストコンピュータで構成されたファイル共
   有型疎結合クラスタシステム上に構築されたトランザク
   ション処理システムの前記通信処理装置を構成するコン
   ピュータに、各端末毎に、その端末にかかるトランザク
   ションが何れのホストコンピュータでも未実行か否かを
   メモリ上の「通信状態」において管理し、「通信状態」
   が未実行でない端末からの接続要求および入力メッセー
   ジを拒否する処理を行わせるプログラムを記録したコン
   ピュータ読み取り可能な記録媒体。
9. 【請求項９】 ファイル装置および通信処理装置を共有
   する複数のホストコンピュータで構成されたファイル共
   有型疎結合クラスタシステム上に構築され、ファイル装
   置上のグローバルメッセージキューファイルを通じてト
   ランザクション処理にかかるメッセージをホストコンピ
   ュータ間で受け渡すことによりトランザクション処理の
   負荷を各ホストコンピュータで分散するようにしたトラ
   ンザクション処理システムの前記ホストコンピュータ
   に、 ファイル装置上のグローバル端末状態ファイルに各端末
   毎に設けた端末状態管理レコード中の、各ホストコンピ
   ュータと１対１に対応するビットから構成されるビット
   マップの各ビットを、そのビットに対応するホストコン
   ピュータがその端末からの接続要求を処理するか或いは
   最初の入力メッセージを受けた時点でセットし、そのビ
   ットに対応するホストコンピュータがその端末のトラン
   ザクション処理を実行しておらずその端末と切断状態と
   なった時点でリセットすることにより、各端末毎に、そ
   の端末のトランザクションを実行している可能性のある
   ホストコンピュータを前記ビットマップで管理する処理
   と、 前記端末状態管理レコード中に設けた「トランザクショ
   ン実行状態」を、その端末の入力メッセージを前記グロ
   ーバルメッセージキューファイルに格納した時点で未実
   行以外に設定し、その入力メッセージにかかるトランザ
   クションの実行が何れかのホストコンピュータで完了し
   た時点で未実行に設定することにより、各端末毎に、そ
   の端末のトランザクションが負荷分散により何れかのホ
   ストコンピュータで実行される可能性があるか否かを管
   理する処理と、 前記端末状態管理レコード中の「トランザクション実行
   可能状態」を、何れかのホストコンピュータがその端末
   からの接続要求を受け付けた時点で接続に設定し、前記
   ビットマップの全ビットがリセットされ且つ前記「トラ
   ンザクション実行状態」が未実行となった時点で未接続
   に設定する処理と、 通信処理装置から或る端末の接続要求を受けたホストコ
   ンピュータにおいて、その端末に対応する前記端末状態
   管理レコード中の「トランザクション実行可能状態」が
   未接続でなければ接続を拒否する処理とを行わせるプロ
   グラムを記録したことを特徴とする請求項８記載のコン
   ピュータ読み取り可能な記録媒体。