JP3516344B2

JP3516344B2 - 分散処理システムの多重データ処理方法

Info

Publication number: JP3516344B2
Application number: JP28377790A
Authority: JP
Inventors: 昌之織茂; 欣司森; 茂樹平澤; 洋藤瀬; 増幸竹内; 仁鈴木
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 1990-10-22
Filing date: 1990-10-22
Publication date: 2004-04-05
Anticipated expiration: 2019-04-05
Also published as: DE69130014T2; US5333265A; DE69130014D1; JPH04157541A; EP0482582A3; EP0482582A2; EP0482582B1

Description

【発明の詳細な説明】〔産業上の利用分野〕本発明は、それぞれ多重に配置したリソースを有する
複数のプロセッサをネットワークにより結合し、各プロ
セッサで役割を分担して、多重リソースから発生するデ
ータの処理を行なう分散処理システムの多重データ処理
方法に係り、特に、処理を進めながら各ファイルの整合
性を確認し、信頼性の高い分散処理を効率良く行なうの
に好適な分散処理システムの多重データ処理方法に関す
るものである。〔従来の技術〕現在、コンピュータは、広い分野で利用され、その高
速性、信頼性の向上を主目的として、様々な研究開発が
なされている。特に、分散処理システムは、1960年代中期〜1970代中
期のメインフレーム、1970代中期〜1980代初期のミニコ
ンピュータ、そして、1980年代のパーソナルコンピュー
タに続く第４の波として、コンピュータ産業における成
長が期待されている。分散処理システムとは、複数のコンピュータを接続し
たネットワーク全体を、あたかも一台のコンピュータで
あるかの様に利用するものである。また、分散処理とは、通信回線で結ばれた複数のコン
ピュータが協力しあって、一つのジョブを処理する処理
形態であり、各コンピュータには、そのジョブの一部を
実行するプロセッサが設けられ、それらがメッセージを
授受しあって処理を進める。分散処理の目的は、従来、一台のコンピュータに集中
して処理させていた全ての仕事を、複数のコンピュータ
で分散して処理することにより、機能分散、負荷分散、
地域分散、そして、高信頼化を得るものである。すなわち、それぞれのコンピュータに、それぞれ必要
な機能のみを持たせて、機能を分散することにより、そ
れぞれのコンピュータを小型化し、経済性を良くする。
しかも、各コンピュータが有する機能は高機能なもので
あり、全体として高機能のシステムが構築できる。また、一台のコンピュータの計算速度、記憶容量、入
出力速度の能力以上の仕事に対しても、複数台のコンピ
ュータに分散して処理し、負荷の増減に柔軟に対応でき
る。また、すべての大量のデータを、遠距離にある一台の
コンピュータに送り処理していたのでは、データの伝送
に時間がかかる。しかし、地域分散により、簡単な前処
理を地域のコンピュータで行ない、その結果のみを中央
に送れば、一部の処理結果がその場で得られる。さら
に、伝送するデータの量が少なくて済む。また、一台のコンピュータですべての処理を行なう
と、そのコンピュータが故障した場合には、システム全
体が止まってしまう。しかし、分散処理により、複数の
コンピュータに仕事を分担しておけば、その内の一台が
故障しても、多少性能は落ちても、残りのもので処理の
続行が可能であり、システムの信頼性が向上する。このような、分散処理に関しては、電子情報通信学会
編「電子情報通信ハンドブック」（1988年、オーム社発
行）のpp.1615〜1626に記載されている。さらに、近年の分散処理では、「日経エレクトロニク
ス 1990 ６−11 no.502」（1990年、日経BP社発行）
のpp.121〜148に記載のように、異なるメーカの製品を
ネットワークで結ぶ異機種間分散処理をサポートするも
のもある。〔発明が解決しようとする課題〕従来、分散処理システムにおけるファイルの管理およ
び、制御方法に、重要なファイルのみを任意の多重度で
多重化して管理する方法がある。そして、このような多重化されたファイルの信頼性に
係るものとして、多重化されたファイルからの出力デー
タを、それを使用するコンピュータで一定期間の間収集
し、収集したデータ間の整合性をチェックするものがあ
る。しかし、このような従来の分散処理システムにおける
多重ファイルの制御方法では、内容の不一致状態が発生
した場合の回復の方法に関しての配慮がなされておら
ず、不一致状態の発生時には、そのファイルをアクセス
していた処理が停止するという問題があった。また、多重化されたファイルからの出力データの整合
性のチェックを、一定期間の間収集してから行なうため
に、その間、処理が遅れるなどの問題があった。本発明の目的は、これら従来技術の課題を解決し、任
意の多重度に多重化された多重ファイルに対し、多重フ
ァイル間に不整合が発生した場合でも、ファイルアクセ
スしている処理を中断することなく、不整合状態を自動
的に回復し、かつ、多重ファイル間に発生する不整合状
態の検出処理を、ファイルアクセス応答性能を低下させ
ることなく行ない、分散処理システムの処理性能と信頼
性を向上させる分散処理システムの多重データ処理方法
を提供することである。〔課題を解決するための手段〕上記目的を達成するため、本発明の分散処理システム
の多重データ処理方法は、（１）複数のプロセッサを共
通伝送媒体を介して接続し、複数のプロセッサは、それ
ぞれのプロセッサに多重に配置したリソースから発生す
る多重データを用いて処理を進める分散処理システムの
多重データ処理方法において、複数のプロセッサは、多
重データの最初に受信したデータを用いて処理を進め、
以後受信した多重データを用いて、最初に受信したデー
タの整合性のチェックを行なうことを特徴とする。また、（２）上記（１）に記載の分散処理システムの
多重データ処理方法において、複数のプロセッサのそれ
ぞれに接続した外部記憶媒体のそれぞれにファイルを多
重に配置し、複数のプロセッサの任意のプロセッサは、
多重に配置したファイルに対するアクセス依頼を発生
し、かつ、アクセス依頼に対応する多重に配置したファ
イルからの多重応答データを受信し、そして、多重応答
データの最初に受信した応答データを用いて処理を進
め、以後受信した多重応答データを用いて、最初に受信
した応答データの整合性のチェックを行なうことを特徴
とする。また、（３）上記（２）に記載の分散処理システムの
多重データ処理方法において、アクセス依頼を発生した
プロセッサは、多重応答データ間のチェックが終了する
まで、次のファイルアクセス依頼を発生しないことを特
徴とする。また、（４）上記（３）に記載の分散処理システムの
多重データ処理方法において、応答データの整合性のチ
ェックで応答データ間に不整合を検出した場合は、アク
セス依頼を発生したプロセッサは、アクセス依頼により
生じたファイル状態を解除する命令を発行する第１のリ
トライ処理を行ない、第１のリトライ処理によるファイ
ル状態の解除後、再び、アクセス依頼を発生する第２の
リトライ処理を行ない、応答データ間の不整合がなくな
るまで、第１のリトライ処理、および、第２のリトライ
処理を繰り返すことを特徴とする。また、（５）上記（４）に記載の分散処理システムの
多重データ処理方法において、アクセス依頼を発生した
プロセッサは、第１のリトライ処理、および、第２のリ
トライ処理を、応答データ間の不整合がなくなるまで繰
り返す代わりに、第２のリトライ処理を、予め設定され
た任意の時間ずらして実行することを特徴とする。また、（６）上記（４）、もしくは、（５）のいずれ
かに記載の分散処理システムの多重データ処理方法にお
いて、アクセス依頼を発生したプロセッサは、最初に受
信した応答データを用いた処理を行なわず、多重ファイ
ルからの全応答データを収集し、収集した全応答データ
間の整合性のチェック、および、第１のリトライ処理と
第２のリトライ処理による応答データ間の整合性の確定
後に、処理を行なうことを特徴とする。また、（７）上記（４）〜（６）のいずれか一つに記
載の分散処理システムの多重データ処理方法において、
アクセス依頼を発生したプロセッサは、予め任意に設定
した時間内に収集した多重ファイルからの全応答データ
間の整合性のチェックに基づき、第１のリトライ処理、
および、第２のリトライ処理を行なうことを特徴とす
る。また、（８）上記（７）に記載の分散処理システムの
多重データ処理方法において、アクセス依頼を発生した
プロセッサは、予め任意に設定した時間内に、多重ファ
イルからの全応答データを収集できない場合、予め任意
に設定した時間内に収集した応答データを、整合性のチ
ェックの対象に限定する障害処理を行ない、障害処理の
後に、整合性のチェック、および、第１のリトライ処理
と第２のリトライ処理を行なうことを特徴とする。また、（９）上記（４）に記載の分散処理システムの
多重データ処理方法において、アクセス依頼を発生した
プロセッサは、第１のリトライ処理として、アクセス依
頼がファイル更新時のリードコマンドの場合は、リード
コマンドの排他管理によるレコードの占有状態を解除す
るフリーコマンドを、アクセス依頼が追加コマンドの場
合は、追加コマンドにより追加したレコードを削除する
イレースコマンドを、アクセス依頼が排他オープンコマ
ンドの場合は、排他オープンコマンドによるファイルの
占有状態を解除するクローズコマンドを発行することを
特徴とする。そして、（10）上記（４）〜（６）のそれぞれに記載
の分散処理システムの多重データ処理方法において、複
数のプロセッサは、アクセス依頼メッセージ、および、
アクセス応答メッセージのメッセージを伝送媒体へブロ
ードキャストし、メッセージのやり取りにより分散処理
を行ない、複数のプロセッサのそれぞれは、自プロセッ
サから他プロセッサへのメッセージの伝送媒体へのブロ
ードキャスト、および、伝送媒体へブロードキャストさ
れたメッセージから、自プロセッサに関連するメッセー
ジの取り込みを行なう通信管理モジュールと、通信管理
モジュールで取り込んだメッセージを、メッセージを処
理するユーザプログラムに渡し、かつ、ユーザプログラ
ムからのファイルアクセス命令に基づき、アクセス依頼
メッセージを生成し、通信管理モジュールに送出するク
ライアントファイル管理モジュールと、クライアントフ
ァイル管理モジュールが通信管理モジュールに送出した
メッセージ情報を格納する送信情報格納手段とを有し、
アクセス依頼を発生したプロセッサは、クライアントフ
ァイル管理モジュールを用いて、通信管理モジュールを
介して伝送媒体にメッセージを送出すると同時に、整合
性のチェックに用いる予め任意に設定した収集時間を送
信情報格納手段に格納し、そして、送信情報格納手段に
格納した時間に基づき、多重ファイルからの全応答デー
タ間の整合性のチェック、および、第１のリトライ処理
と第２のリトライ処理を行なうことを特徴とする。〔作用〕本発明においては、各プロセッサは、自ら発行したア
クセス命令に基づき送られてきた多重ファイルからの複
数の応答データを受け取る。この時、多重ファイルから
最初に受信した応答データを、受信したタイミングでユ
ーザプログラムに渡すと共に、自プロセッサ内に格納し
ておく。そして、以後に受信した応答データと、この最初に受
信した応答データとを比較し、応答データ間（すなわ
ち、多重ファイル間）の不整合の発生をチェックする。ここで、応答データ間での不一致を検出した場合、ア
クセス命令を発行した自プロセッサは、まず、多重ファ
イルに対して発行したアクセス命令を解除する命令を発
行し、自プロセッサのアクセス命令により引き起こされ
たファイル状態を解除する（第１のリトライ処理）。そ
して、次に、再び、同じアクセス命令を発行する（第２
のリトライ処理）。ここで、多重ファイル間の不整合状態は、複数のプロ
セッサが、同時に、多重ファイルにアクセスした場合に
発生するものである。そして、アクセス命令の再発行
は、各プロセッサが、独自のタイミングで行なう。その
ために、お互いのアクセス命令再発行のタイミングは自
動的にずれる。このことにより、再発行のアクセス命令
に関しては、不整合状態の発生は自動的に回避される。このことにより、任意の多重度に多重化されたファイ
ルに対し、多重ファイル間に不整合が発生した場合で
も、ファイルアクセスしている処理を中断することな
く、不整合状態を自動的に回復する。また、一番最初に多重ファイルからの応答を受信した
タイミングで、ユーザプログラムに制御が戻るため、フ
ァイル間整合性チェックのために、ファイルアクセス応
答が低下することはない。〔実施例〕以下、本発明の実施例を、図面により詳細に説明す
る。第１図は、本発明を施した分散処理システムの本発明
に係る構成の第１の実施例を示すブロック図である。分散処理システムは、バス型ネットワークのネットワ
ーク４に、それぞれ処理を分担して実行するプロセッサ
１〜３、プロセッサ１〜３のそれぞれに接続され、処理
操作指示の入力機能および処理結果の表示機能を有する
ターミナル10、20、30、同じく、プロセッサ１〜３のそ
れぞれに接続され、処理の対象となるデータを格納する
ディスク11、21、31から構成されている。さらに、プロセッサ１のディスク11と、プロセッサ２
のディスク21内には、ファイル（Ａ）12、22を多重に持
たせている。また、プロセッサ１にはユーザプログラム13（以下UP
a13と記載）が、また、プロセッサ２にはユーザプログ
ラム23（以下UPb23と記載）が存在する。そして、本発明に係る処理を行なうプロセッサ１〜３
のそれぞれは、ネットワーク４上に送出したメッセージ
５の授受により分散処理を行なう。ここで、メッセージ５の構成に関しての説明を行な
う。メッセージ５の初めと終わりを、それぞれ示すフラグ
51、58（図中Ｆと記載）、メッセージの内容を示す内容
コード52（図中CCと記載）、本メッセージを発生したプ
ロセッサのプロセッサ番号を格納する発生源アドレス53
（図中SAと記載）、ネットワーク４による伝送で必要と
なる通番54（図中Ｃと記載）、ファイルをアクセスする
ユーザプログラム（例えば、UPa13）を示す発生源情報5
5（図中SIと記載）、伝送されるべき情報を格納するエ
リアであるデータ部56（図中Dataと記載）、伝送上の誤
りをチェックするためのエリアであるFCS（Frame Chec
k Sequencer）57から構成されている。また、内容コード52は、アクセスするファイルを示す
ファイルネーム部521（図中FNMと記載）、ファイルアク
セス依頼やファイルアクセス応答などのメッセージの種
別を示すID（IDentifier）部522からなる。本第１の実施例では、ファイル名称は、システム内で
ユニーク（唯一）であるという前提のもとに、ファイル
ネーム部521の内容としてファイル名称を用いる。但
し、ファイルネーム部521は、ファイル名称の代わり
に、ファイル内容に対応するコード等を用いても構わな
い。また、発生源情報55は、ユーザプログラムを実行中の
プロセッサのプロセッサ番号を格納するエリアであるプ
ロセッサ番号情報部551（図中PNO551と記載）、実行中
プログラムを示す情報を格納するエリアであるタスク番
号情報部552（図中TNOと記載）、そして、ユーザプログ
ラムが発生するメッセージの順番を示す通番エリアであ
る通番情報部553（図中SEQと記載）からなる。このようなフォーマットのメッセージ５を、本第１の
実施例において、各プロセッサ１〜３は、ネットワーク
４上にブロードキャストする。また、各プロセッサ１〜
３は、ネットワーク上のメッセージ５の内容コード52の
内容に基づき、そのメッセージ５が自らに必要か否かを
判定し、必要なメッセージ５のみを取り込む。次に、各プロセッサ１〜３の構成、および、その機能
を、プロセッサ１を用いて説明する。ネットワークインタフェース101は、ネットワーク４
とのインタフェースを取るためのモジュールで、ディス
クインタフェース111は、ディスク11とのインタフェー
スを取るためのモジュールである。通信管理モジュール102は、ネットワーク４より受信
したメッセージ５の内容（内容コード52）に基づき、受
信メッセージが自プロセッサに必要なものであるか否か
を判定し、必要なメッセージの場合は、それを入力メッ
セージエリア104に格納する。また、出力メッセージエ
リア105内のメッセージをメッセージ５として、ネット
ワークインタフェース101経由で、ネットワーク４にブ
ロードキャストする。尚、この際、通信管理モジュール102は、送出メッセ
ージに対しても、ネットワーク４からの受信メッセージ
と同じように、その送出メッセージが、自プロセッサに
必要であるか否かを判定し、必要な場合は、入力メッセ
ージエリア104に、その送出メッセージを格納する。また、入力メッセージエリア104、出力メッセージエ
リア105には、それぞれ、受信メッセージと送信メッセ
ージが、内容コード52対応に格納されている。内容コードテーブル103には、自プロセッサで必要と
するメッセージ５の内容コードが登録される。具体的に
は、メッセージ５のファイルネーム部521には、自ディ
スク11内ファイルの「ファイル名称」が、また、ID部52
2には、「アクセス依頼」を示すコードが設定された内
容コードが、例えば、プロセッサ立ち上げ時に登録され
る。また、ユーザプログラムの実行状況に応じて、ID部
522にアクセス応答を示すコードが設定された内容コー
ドも登録される。通信管理モジュール102は、受信したメッセージ５内
の内容コード52と、内容コードテーブル103に登録され
ている内容コードとを比較し、一致するメッセージ５を
取り込む。クライアントファイル管理モジュール106は、入力メ
ッセージエリア104内のメッセージをUPa13に渡すと共
に、UPa13からの送出メッセージを、出力メッセージエ
リア105に格納する処理を行なう。送信SI（Source Information、発生源情報）テーブ
ル107は、クライアントファイル管理モジュール106が、
出力メッセージエリア105に格納するメッセージ５の発
生源情報55の内容を、内容コード52対応に格納しておく
テーブルである。ユーザプログラム実行エリア（図中UP実行エリアと記
載）108は、UPa13などのユーザプログラムを実行するエ
リアである。ファイル管理テーブル110、および、サーバファイル
管理モジュール109は、自プロセッサ１に接続されたデ
ィスク11内のファイル（Ａ）12のアクセスを管理するた
めのものである。次に、送信SIテーブル107、および、ファイル管理テ
ーブル110のフォーマットに関して説明する。送信SIテーブル107は、ファイルアクセス依頼を示す
メッセージ５の発生源情報55に対応した行1071〜1072を
有する。そして、これら各行1071〜1072のそれぞれにお
いては、アクセス依頼メッセージの発生源情報55の内容
を格納する発生源情報エリア（図中SIエリアと記載）10
711に、アクセス依頼に対する応答のタイムアウトを検
出するためのタイマエリア10712と、アクセス依頼に対
するアクセス応答を示すメッセージの個数を格納するた
めの個数エリア10713と、受信したアクセス応答メッセ
ージを格納するための受信メッセージエリア10714とが
対応付けられている。ファイル管理テーブル110は、自ディスク11内のファ
イルに対応する行1101〜1102を有する。そして、各行11
01〜1102には、各ファイルに対応するコード（本第１の
実施例ではファイル名称）を格納するファイルネームエ
リア（図中FNMエリアと記載）11011、そのファイルが格
納されているディスク、および、ディスク内での位置を
示す情報を格納する物理情報エリア11012、および、そ
のファイルに対するアクセス依頼メッセージの発生源情
報（メッセージ５における発生源情報55）の内容を格納
するための発生源情報エリア（図中SIエリアと記載）11
013よりなる。このうち、ファイルネームエリア11011と、物理情報
エリア11012は、ファイルアロケート時に、前もって設
定されているものとする。以下、このような構成からなる本第１の実施例の分散
処理システムにおいて、各プロセッサ１〜３間で行なわ
れるメッセージ５の送受信の基本的な動作を説明する。まず、メッセージ５の送信動作を、UPa13がファイル
アクセス命令を発行した時のクライアントファイル管理
モジュール106の処理動作に基づき説明する。 UPa13は、アクセスするファイル名称、および、アク
セス内容を指定してファイルアクセス命令を発行する。このアクセス命令は、クライアントファイル管理モジ
ュール106が取り込み、メッセージ５のフォーマットで
示した内容コード52、発生源情報55、データ部56を以下
のように設定したメッセージを作成し、出力メッセージ
エリア105に格納する。すなわち、内容コード52のファイルネーム部521にはU
Pa13で指定されたファイル名称が、そして、ID部522に
はアクセス依頼を示すコードが設定されている。発生源情報55のプロセッサ番号部551には自プロセッ
サ番号が、また、タスク番号552にはファイルアクセス
命令を発行したUPa13に割り当てられている番号、例え
ば、タスク番号などが、そして、メッセージ順番部553
にはアクセス命令の発行された順番を示す通番が設定さ
れている。さらに、データ部56には、UPa13が指定した
アクセス内容が設定されている。また、この際、設定した発生源情報55の内容を、送信
SIテーブル107の発生源情報エリア10711に設定し、さら
に、対応するタイマエリア10712にタイマを設定する。以上の処理により、出力メッセージエリア105に格納
されたメッセージは、通信管理モジュール102により、
ネットワーク４に、メッセージ５としてブロードキャス
トされる。このようなメッセージを、アクセス依頼メッセージと
呼ぶ。次に、メッセージの受信動作を、サーバファイル管理
モジュール109の処理動作に基づき説明する。例えば、プロセッサ２のクライアントファイル管理モ
ジュールが、UPb23の要求に基づいて、アクセス依頼メ
ッセージを、プロセッサ２の通信管理モジュール経由で
ネットワーク４に、メッセージ５で示したフォーマット
でブロードキャストする。そのアクセス依頼メッセージは、そのメッセージ５内
の内容コード52に指定されたファイル、例えば、ファイ
ル（Ａ）12を自ディスク内に持つプロセッサ、ここで
は、プロセッサ１により取り込まれる。そして、プロセ
ッサ１内の通信管理モジュール102は、このファイル
（Ａ）12へのアクセス依頼メッセージを、入力メッセー
ジエリア104に格納する。サーバファイル管理モジュール109は、入力メッセー
ジエリア104より、このメッセージを取り込み、取り込
んだメッセージ内の発生源情報55の内容を、ファイル管
理テーブル110の発生源情報エリア11013に格納する。そして、サーバファイル管理モジュール109は、メッ
セージ５内のデータ部56で指定されるファイルアクセス
処理を、ファイル管理テーブル110内の物理情報エリア1
1012の内容に基づき実行する。さらに、サーバファイル管理モジュール109は、この
ファイルアクセス処理の結果に基づき、メッセージの内
容コード52、発生源情報55、データ部56を以下の様に設
定したアクセス応答を示すメッセージを作成し、出力メ
ッセージエリア105に格納する。尚、このメッセージを
アクセス応答メッセージと呼ぶ。アクセス応答メッセージにおいては、ファイルネーム
部521にはアクセスしたファイルの名称が、ID部522には
アクセス応答を示すコードが設定されている。また、発
生源情報55には、アクセス依頼メッセージ内の発生源情
報の値（ファイル管理テーブル発生源情報エリア11013
の内容）が設定される。そして、データ部56にはファイ
ルアクセスの結果内容が設定されている。ここで、ファ
イルアクセスの結果内容とは、アクセスが正常終了した
か否か、および、異常終了した場合には、異常の内容を
示す情報のことである。以後、この情報をステータス情
報と呼ぶ。また、リード（READ、読み取り）コマンドの
場合は、リードした内容も含む。以上の処理により出力メッセージエリア105に格納さ
れたファイルアクセス応答メッセージは、通信管理モジ
ュール102により、ネットワーク４に、メッセージ５と
してブロードキャストされる。そして、このアクセス応答メッセージは、アクセス依
頼を発生したユーザプログラム、すなわち、UPb23を実
行中のプロセッサ２により取り込まれる。このようにして、本第１の実施例の分散処理システム
は、各プロセッサ１〜３間でメッセージ５の授受を行な
い、分散処理を進めて行く。以上のような構成からなる第１の実施例の分散処理シ
ステムにおいては、以下に示す問題に対処して、本発明
に係る処理動作を行なう。まず、その問題点を説明する。例えば、二つのUpa13、UPb23が、同時に、多重化され
たファイル（Ａ）12、22をアクセスする場合を想定す
る。 UPa13が、ファイルアクセスコマンドを発行し、アク
セス依頼すると、このファイルアクセスコマンドは、自
プロセッサ１のディスク11内のファイル（Ａ）12と、プ
ロセッサ２のディスク21内のファイル（Ａ）22に送られ
る。この場合、ネットワーク４を介さないで済む自プロセ
ッサ１内のファイル（Ａ）12の方が先に処理される。そ
して、ファイル（Ａ）12のファイルアクセスコマンドに
対する処理結果が、UPa13に送られ、アクセス応答がな
される。一方、UPa13がファイルアクセスコマンドを発行した
のと同時に、UPb23が、UPa13と同一レコードに対するフ
ァイルアクセスコマンドを発行したものとする。すると、UPb23のファイルアクセスコマンドも、UPa13
のファイルアクセスコマンドと同様に、自プロセッサ２
のディスク21内のファイル（Ａ）22と、プロセッサ１の
ディスク11内のファイル（Ａ）12に送られる。この場合は、自プロセッサ２内のファイル（Ａ）22の
方が先に処理される。そして、ファイル（Ａ）22に対するファイルアクセス
コマンドの処理結果が、UPb23に送られる。すなわち、ファイル（Ａ）12に対しては、UPa13がア
クセスし、ファイル（Ａ）22に対しては、UPb23がアク
セスしている状態が発生する。この状態で、ファイル（Ａ）12には、UPb23のアクセ
スコマンドが、また、ファイル（Ａ）22には、UPa13の
アクセスコマンドが到達する。この場合、アクセスコマ
ンドの内容によっては、ハード的には全く障害がなくて
も、例えば、以下に示すような状態が発生する。（ｉ）アクセスコマンドがファイル更新のためのリード
（READ）コマンドの場合：ファイル更新の場合は、ファイルアクセス排他管理を
行なうため、リード（READ、読み取り）受け付け時か
ら、ライト（WRITE、書き込み）処理完了時まで、ファ
イル内の対象となるレコードへの他ユーザプログラムか
らのアクセスを禁止する。そのために、UPa13がリード
（READ）状態のファイル（Ａ）12のレコードに対する、
UPb23のアクセスコマンド（READ）は、排他エラーとし
てはねられ、受け付けられない。同様に、ファイル（Ａ）22に到達したUPa13のリード
（READ）コマンドも排他エラーとしてはねられる。この状態で、UPa13、および、UPb23がライト（WRIT
E）処理を行なうと、ファイル（Ａ）12の対象レコード
はUPa13により、また、ファイル（Ａ）22の対象レコー
ドはUPb23により、それぞれ更新される。そのために、
ファイル（Ａ）12とファイル（Ａ）22の内容が食い違う
ことになる。（ii）アクセスコマンドがレコード追加のための追加
（ADD）コマンドの場合：アクセスコマンドがファイルの同一レコードに対する
追加（ADD）コマンドの場合は、ファイル（Ａ）12に対
してはUPa13の追加内容が、また、ファイル（Ａ）22に
対しては、UPb23の追加内容が反映されている。このこ
とにより、ファイル（Ａ）12とファイル（Ａ）22の内容
が食い違うことになる。（iii）アクセスコマンドが排他オープン（OPEN）コマ
ンドの場合：アクセスコマンドが排他オープン（OPEN）コマンドの
場合は、ファイル（Ａ）12に対してはUPa13のアクセス
コマンドのみが、また、ファイル（Ａ）22に対してはUP
b23のアクセスコマンドのみが受け付けられ状態とな
る。このために、ファイル（Ａ）12とファイル（Ａ）22
の内容が食い違うことになる。以上のような問題を解決するために、本第１の実施例
の分散処理システムにおいて、各プロセッサ１〜３は、
それぞれの多重ファイルからの応答データ間のチェック
を行なう。そして、応答データ間での不一致を検出した
場合は、自プロセッサが、多重ファイルに対して発行し
たアクセス命令を解除する命令を発行し（第１のリトラ
イ処理）、さらに、再び、最初のアクセス命令を発行す
る（第２のリトライ処理）。この時、アクセス命令の再発行は、各プロセッサが独
自のタイミングで行なうために、お互いのアクセス命令
再発行のタイミングは自動的にずれ、不整合状態の発生
は自動的に回避される。このように、ファイル間の不整合が発生した場合は、
発行したアクセス命令を解除する命令を発行した後（第
１のリトライ処理）に、最初のアクセス命令と同じアク
セス命令を再び発行する（第２のリトライ処理）。この
ことにより、処理を中断することなく、不整合状態を自
動的に回復することができる。以上のようにして、本第１の実施例の分散処理システ
ムにおける各プロセッサ１〜３は、多重化したファイル
に対し、その整合性を保ったまま、各ユーザプログラム
が、同時にアクセスすることを可能とする。尚、本第１の実施例及び、以下に示す第2,第３の実施
例のネットワーク構成は、バス型ネットワークである
が、これに限らず、任意の形態のネットワークで構成可
能である。また、各プロセッサ１〜３には、ターミナル10、20、
30およびディスク11、21、31が複数台接続されていても
良いし、一台も接続されていなくとも良い。さらに、本第１の実施例では、ファイルは二重化ファ
イルの例を示しているが、本発明は、任意の多重度に多
重化したファイルにも適用できる。以下、第１の実施例の分散処理システムにおける各プ
ロセッサの本発明に係る動作を、さらに詳しく説明す
る。第２図は、第１図における分散処理システムの本発明
に係る処理動作の第１の実施例を示すフローチャートで
ある。第１図におけるクライアントファイル管理モジュール
106の処理動作に関するものであり、特に、アクセス応
答メッセージの受信時、および、本発明の第１のリトラ
イ処理（以下、リトライ処理（１）と記載）と、第２の
リトライ処理（以下、リトライ処理（２）と記載）の動
作を示すものである。尚、この実施例は、多重化されたファイルからの応答
を一定時間の間収集し、その結果に基づき多重ファイル
間の整合性をチェックする方法である。第２図（ａ）は、受信したアクセス応答メッセージの
読みだしからリトライ処理（１）、（２）からなるリト
ライチェック処理の開始までのフローを示し、第２図
（ｂ）は、リトライチェック処理のフロー、そして、第
２図（ｃ）、（ｄ）は、それぞれ、リトライ処理（１）
と、リトライ処理（２）の処理の一実施例を示してい
る。まず、第２図（ａ）に基づき説明する。クライアント管理モジュールは、ネットワークから受
信し、入力メッセージエリアに格納されたアクセス応答
メッセージを読みだし（ステップ201）、送信SIテーブ
ルをチェックし、アクセス応答メッセージ内の発生源情
報部の値が、送信SIテーブルの発生源情報エリアに登録
されているか否かを判定する（ステップ202）。登録されていない場合は、自プロセッサが発生したア
クセス依頼に対する応答ではないため、そのメッセージ
を廃棄し（ステップ203）、次のアクセス応答メッセー
ジを待つ。登録されている場合は、受信したアクセス応答メッセ
ージを、送信SIテーブルの対応する（メッセージ内の発
生源情報部の内容が登録されている）行の受信メッセー
ジエリアに格納する（ステップ204）。尚、この時、個
数エリアの値を一つ増加させる。次に、アクセス依頼メッセージ発生時にセットしたタ
イマがタイムアウトしているか否かを、送信SIテーブル
のタイマエリアに基づき判定する（ステップ205）。タイムアウトしていない場合は、次のメッセージ受信
の待ち状態となる。タイムアウトの場合は、本発明のリトライ処理
（１）、（２）からなるリトライチェック処理を行なう
（ステップ206）。以下、次のようにしてリトライチェック処理を行な
う。送信SIテーブルに格納したアクセス応答メッセージ
が、リトライ処理（１）に対応するメッセージか否かを
チェックする（ステップ207）。リトライ処理（１）に対応するメッセージでなけれ
ば、送信SIテーブルの受信メッセージエリア内に格納さ
れたアクセス応答メッセージ間で、その内容を比較する
（ステップ208）。尚、その内容の比較の方法としては、メッセージの全
内容を比較する方法もあるが、ここでは、応答メッセー
ジ間で、アクセス処理の終了状態を示すステータス情報
のみを比較する方法とする。さて、応答メッセージ間で、ステータス情報が一致す
る場合は、多重化されている各ファイル間の整合性が保
証されているので、受信したファイルアクセス応答メッ
セージをユーザプログラム、例えば、第１図のファイル
（Ａ）12に渡す（ステップ209）。その後、送信SIテーブルの対応するエリアをリセット
して（ステップ210）、処理を終了する。尚、ここで、受信した応答メッセージ数が「０」の場
合は、ユーザプログラムにファイル障害を示す情報を渡
す。一方、ステップ208において、ファイルアクセス応答
メッセージ間で、終了ステータス情報が一致しない場合
は、多重化ファイル間の整合性が保証できないため、送
信SIテーブルの対応するエリアをリセットし（ステップ
211）、応答メッセージを要求したファイルアクセス依
頼コマンド内容に応じて、次のリトライ処理（１）を行
なう（ステップ212）。また、ステップ207において、アクセス応答メッセー
ジが、リトライ処理（１）に対応するメッセージであれ
ば、リトライ処理（２）を行なう（ステップ213）。以下、第２図（ｂ）に基づき、リトライ処理（１）を
説明する。まず、アクセス依頼がリード（READ）コマンドの場合
（ステップ214）、排他管理によりレコードを占有して
いる状態を解除するためのフリー（FREE）コマンドをデ
ータ部に持つアクセス依頼メッセージを作成し、出力メ
ッセージエリアに格納する（ステップ215）。アクセス依頼が追加（ADD）コマンドの場合には（ス
テップ216）、追加（ADD）コマンドにより追加したコー
ドを削除するためのイレース（ERASE）コマンドをデー
タ部に持つアクセス依頼メッセージを作成し、出力メッ
セージエリアに格納する（ステップ217）。アクセス依頼が排他オープン（OPEN）コマンドの場合
には（ステップ218）、排他オープン（OPEN）コマンド
によりファイルを占有している状態となっているため、
この状態を解除するためのクローズ（CLOSE）コマンド
をデータ部に持つアクセス依頼メッセージを作成して、
出力メッセージエリアに格納する（ステップ219）。このように、それぞれのアクセス依頼メッセージに対
応し（ステップ220）、それぞれのアクセス依頼メッセ
ージによるファイルの占有状態を解除するためのコマン
ドをデータ部に持つアクセス依頼メッセージを作成し、
出力メッセージエリアに格納する（ステップ221）。尚、これらのメッセージ（FREE、ERASE、CLOSEコマン
ドなど）は、通信管理モジュールにより、第１図のネッ
トワーク４にブロードキャストされる。そして、このようなリトライ処理（１）により発行さ
れたアクセス依頼メッセージに対するアクセス応答メッ
セージの受信を待つ。このリトライ処理（１）に対する応答メッセージに関
しても、ステップ201〜206の処理フローに従う。そし
て、ステップ207において、受信メッセージが、リトラ
イ処理（１）により発生されたコマンドに対するアクセ
ス応答メッセージであると確認されれば、リトライ処理
（２）を行なう（ステップ213）。以下、第２図（ｃ）に基づき、リトライ処理（２）を
説明する。このリトライ処理（２）では、リトライ処理（１）を
行なうトリガとなったアクセス依頼コマンドをデータ部
に持つアクセス依頼メッセージを作成し、出力メッセー
ジエリアに格納する。すなわち、リトライ処理（１）でフリー（FREE）コマ
ンドが発行されていれば（ステップ222）、リード（REA
D）コマンドをデータ部に持つアクセス依頼メッセージ
を作成し、出力メッセージエリアに格納する（ステップ
223）。また、リトライ処理（１）でイレース（ERASE）コマ
ンドをデータ部に持つアクセス依頼メッセージを作成し
ていれば（ステップ224）、追加（ADD）コマンドをデー
タ部に持つアクセス依頼メッセージを作成し、出力メッ
セージエリアに格納する（ステップ225）。また、リトライ処理（１）でクローズ（CLOSE）コマ
ンドをデータ部に持つアクセス依頼メッセージを作成し
ていれば（ステップ226）、排他オープン（OPEN）コマ
ンドをデータ部に持つアクセス依頼メッセージを作成し
て、出力メッセージエリアに格納する（ステップ22
7）。このように、リトライ処理（１）によりファイルの占
有状態を解除されたそれぞれのアクセス依頼メッセージ
に対応し（ステップ228）、同じ、アクセス依頼メッセ
ージを再度作成し、出力メッセージエリアに格納する
（ステップ229）。そして、これらのメッセージ（READ、ADD、排他OPEN
コマンドなど）は、通信管理モジュールにより、第１図
のネットワーク４にブロードキャストされる。尚、このリトライ処理（２）と同じ内容のリトライ処
理（２）が、他のプロセッサでも発行されるが、この時
は、それぞれの発行タイミングが異なる。そのために、
リトライ処理（２）により発行されるメッセージによる
ファイル間の不整合は、発生しない。そして、このリト
ライ処理（２）に対応する受信メッセージは、ステップ
208における不整合チェックでOK（「整合」）となり、
正常に終了することができる。このように、本実施例の分散処理システムによれば、
多重ファイル間に不整合が発生した状況でも、リトライ
処理（１）により不整合状態を解除し、その後、リトラ
イ処理（２）によりアクセス処理が再実行されるため、
ファイル間の整合性は、自動的に保証された状態にな
る。尚、各プロセッサによるリトライ処理（２）の実行タ
イミングをずらす目的で、それぞれのリトライ処理
（２）のリトライコマンドを発行する前に、ランダムな
待ち時間をいれても良い。以下、さらに、第１図における実線矢印（ａ）と点線
矢印（ｂ）で示す２つのファイルアクセスに基づき、本
発明に係る処理動作を説明する。第３図は、第１図における分散処理システムの本発明
に係る処理動作の一実施例を示すタイムチャートであ
る。第２図で示した処理動作に基づくタイムチャートであ
り、第１図の二つのユーザプログラム、UPa13とUPb23
が、それぞれ同時に多重化されたファイル（Ａ）12、22
をリード（READ）アクセスする場合を示す。 UPa13が、ファイルアクセスコマンド（READ）300を発
行してアクセス依頼すると、プロセッサ１のクライアン
トファイル管理モジュール106は、ファイルアクセスコ
マンド（READ）300に対応するアクセス依頼メッセージ
（READ）301を、自プロセッサディスク内のファイル
（Ａ）12と、第１図のプロセッサ２のディスク21内のフ
ァイル（Ａ）22に送る。この場合、第１図のネットワーク４を介さないで済む
自プロセッサ内のファイル（Ａ）12の方が先に処理され
る。そして、ファイル（Ａ）12のファイルアクセスコマ
ンド（READ）300に対する処理結果を示すステータス情
報302が、UPa13に送られ、アクセス応答がなされる。 UPa13がファイルアクセスコマンド（READ）300を発行
したのと同時に、UPb23が、UPa13と同一レコードに対す
る同様なファイルアクセスコマンド（READ）320を発行
したものとする。すると、プロセッサ２内のクライアントファイル管理
モジュール126は、UPb23が発生したファイルアクセスコ
マンド（READ）320に対応するアクセス依頼メッセージ
（READ）321を、同様に、自プロセッサディスク内のフ
ァイル（Ａ）22と、プロセッサ１のディスク内のファイ
ル（Ａ）12に送る。この場合、自プロセッサ内のファイル（Ａ）22の方が
先に処理される。そして、ファイル（Ａ）22のファイル
アクセスコマンド（READ）320に対する処理結果を示す
ステータス情報322が、UPb23に送られる。ここでは、ファイル（Ａ）12に対しては、UPa13がア
クセスし、ファイル（Ａ）22に対しては、UPb23がアク
セスしている状態が発生する。この状態で、ファイル（Ａ）12には、UPb23からのフ
ァイルアクセスコマンド（READ）320に対応するアクセ
ス依頼メッセージ321が、一方、ファイル（Ａ）22に
は、UPa13からのファイルアクセスコマンド（READ）300
に対応するアクセス依頼メッセージ301が到達する。こ
の場合、ファイルアクセスコマンド300、320の内容によ
っては、ハード的には全く障害がなくても、第１図の説
明において述べたような状態が発生する。すなわち、ファイルアクセスコマンド300、320が、フ
ァイル更新のためのリード（READ）コマンドであり、フ
ァイルアクセス排他管理を行なうため、UPa13がリード
状態のファイル（Ａ）12のレコードに対するUPb23のフ
ァイルアクセスコマンド（READ）320に対応するアクセ
ス依頼メッセージ321は、排他エラーとしてはねられ、
受け付けられない。同様に、ファイル（Ａ）22に到達したUPa13のファイ
ルアクセスコマンド（READ）300に対応するアクセス依
頼メッセージ301も排他エラーとしてはねられる。この状態で、UPa13、および、UPb23が書き込み処理を
行なうと、ファイル（Ａ）12の対象レコードはUPa13に
より、また、ファイル（Ａ）22の対象レコードはUPb23
により更新されるため、ファイル（Ａ）12とファイル
（Ａ）22の内容が食い違うことになる。このようなファイルの不整合状態の問題を解決するた
めに、第１図における分散処理システムの各プロセッサ
は、それぞれの多重ファイルからの応答データ間のチェ
ックを行ない、かつ、応答データ間での不一致を検出し
た場合は、自プロセッサが、多重ファイルに対して発行
したアクセス命令を解除する命令を発行し、その後、再
び、同じアクセス命令を発行する。すなわち、UPa13を実行しているプロセッサ１のクラ
イアントファイル管理モジュール106は、UPa13が発生し
たファイルアクセスコマンド（READ）300に対応するフ
ァイル（Ａ）12、22からのアクセス応答メッセージのス
テータス情報302、303が食い違っていることにより、第
２図で説明したリトライ処理（１）304を実行し、アク
セス依頼メッセージ（READ）301を解除する解除依頼メ
ッセージ（FREE）305を発行する。この解除依頼メッセージ（FREE）305により、UPa13に
よるファイル（Ａ）12の占有状態が解除される。同様に、クライアントファイル管理モジュール126
は、UPb23が発生したファイルアクセスコマンド（REA
D）320に対するファイル（Ａ）12、22からのアクセス応
答メッセージのステータス情報322、323が食い違ってい
ることにより、第２図におけるリトライ処理（１）324
を実行し、アクセス依頼メッセージ（READ）321を解除
する解除依頼メッセージ（FREE）325を発行する。この解除依頼メッセージ（FREE）325により、ファイ
ル（Ａ）22のUPb23による占有状態が解除される。これらの占有状態の解除が、応答メッセージ306、30
7、326、327により、それぞれのクライアントファイル
管理モジュール106、126に通知される。そして、ファイル（Ａ）12、22の両ファイルとも占有
されていない状態で、UPa13、UPb23が実行されている各
プロセッサ１、２のクライアントファイル管理モジュー
ル106、126は、第２図で説明したリトライ処理（２）30
8、328により、アクセス依頼メッセージ（READ）301、3
21とそれぞれ同じアクセス依頼メッセージ（READ）30
9、329を再発行する。以上のリトライ処理（１）304、324およびリトライ処
理（２）308、328は、アクセス処理が成功するまで繰り
返される。しかし、リトライ処理（２）308、328によるアクセス
依頼メッセージ（READ）309、329の発行は、プロセッサ
１、２が、独自のタイミングで行なう。そのために、ア
クセス依頼メッセージ（READ）309、329の発行のタイミ
ングは自動的にずれ、リトライ処理（２）308、328によ
り発行されるアクセス依頼メッセージ（READ）309、329
に関しては、その不整合状態の発生は自動的に回避され
る。また、UPa13、UPb23でのリトライ実行タイミングをず
らすため、リトライ処理（２）308、328において、リト
ライコマンド（アクセス依頼メッセージ（READ）309、3
29を発行する前に、それぞれにランダムな待ち時間をい
れても良い。このことにより、リトライ処理（２）30
8、328に基づくファイルアクセスを、確実に実行するこ
とができる。以上示した方法は、多重化されたファイルからの応答
を一定時間の間収集し、その結果に基づき多重ファイル
間の整合性をチェックする方法である。これに対して、多重ファイルからの応答を一定時間で
はなく、予め決められた多重度数分を収集する方法も可
能である。以下、この方法による本発明の第２の実施例
を説明する。本第２の実施例を行なうために、第１図で示した送信
SIテーブル107、および、ファイル管理テーブル110にフ
ァイルの多重度を示す多重度エリアを設定する。第４図は、第１図における送信SIテーブルおよびファ
イル管理テーブルの構成の第２の実施例を示す説明図で
ある。第４図（ａ）における送信SIテーブル407は、各行407
1〜4072に、第１図のSIエリア10711、タイマエリア1071
2、個数エリア10713、受信メッセージエリア10714に、
多重度エリア400を付与して構成され、また、第４図
（ｂ）におけるファイル管理テーブル410は、各行4101
〜4102に、第１図のFNMエリア11011、物理情報エリア11
012、SIエリア11013に、多重度エリア401を付与して構
成されている。ファイル管理テーブル410の多重度エリア401は、各プ
ロセッサにおいて、ファイルアロケート時に設定される
ものとする。また、第１図におけるサーバファイル管理モジュール
109は、アクセス依頼に対するアクセス応答メッセージ
内に、ファイル管理テーブル410の多重度エリア401の内
容を多重度情報として設定する。一方、第１図のクライアントファイル管理モジュール
106は、OPENコマンドに対応する応答メッセージ受信時
に、メッセージ内の多重度を、送信SIテーブル407の多
重度エリア400に設定する。この送信SIテーブル407とファイル管理テーブル410を
有する第２の実施例の分散処理システムでは、第１図の
クライアントファイル管理モジュール106は、アクセス
応答メッセージ受信時において、これら送信SIテーブル
407、および、ファイル管理テーブル410に付与された多
重度エリア400、401に基づき、受信メッセージエリアに
格納したアクセス応答メッセージ間の整合性をチェック
する。このように、ある一定の時間前に、必要な数分のアク
セス応答メッセージが返ってきた時点で、アクセス応答
メッセージ間の整合性のチェックを行なうことにより、
第２図のフローチャートで示した処理よりも効率の良い
リトライチェック処理等を行なうことができる。第５図は、第１図における分散処理システムの本発明
に係る処理動作の第２の実施例を示すフローチャートで
ある。第４図における送信SIテーブル407、および、ファイ
ル管理テーブル410を有する分散処理システムの動作で
あり、特に、第１図に示すクライアントファイル管理モ
ジュール106が行なう処理フローを示す。まず、クライアント管理モジュールは、ネットワーク
から受信し、入力メッセージエリアに格納されたアクセ
ス応答メッセージを読みだし（ステップ501）、送信SI
テーブルをチェックし、アクセス応答メッセージ内の発
生源情報部の値が、送信SIテーブルの発生源情報エリア
に登録されているか否かを判定する（ステップ502）。登録されていない場合は、自プロセッサが発生したア
クセス依頼に対する応答ではないため、そのメッセージ
を廃棄し（ステップ503）、次のアクセス応答メッセー
ジを待つ。登録されている場合は、このアクセス応答メッセージ
を、送信SIテーブルの対応する（メッセージ内の発生源
情報部の内容が登録されている）行の受信メッセージエ
リアに格納する（ステップ504）。尚、この時、個数エ
リアの値を一つ増加させる。ここまでの処理は、第２図の第１の実施例におけるス
テップ201〜204と同じである。次に、送信SIテーブル内の個数エリアの値、すなわ
ち、受信したアクセス応答メッセージの数と、第４図に
おける多重度エリア400の値とが一致するか否かを判定
する（ステップ505）。受信したアクセス応答メッセージの数と、多重度エリ
アの値とが一致する場合、すなわち、多重化ファイルの
全てから応答が戻ってきたならば、第２図におけるステ
ップ206と同じリトライチェック処理を行なう（ステッ
プ506）。一致しない場合は、第２図のステップ205と同じタイ
ムアウトチェックを行なう（ステップ507）。すなわ
ち、アクセス依頼メッセージ発生時にセットしたタイマ
がタイムアウトしているか否かを、第４図における送信
SIテーブル407のタイマエリア10712に基づき判定する。タイムアウトしていない場合は、次のメッセージの受
信待ち状態に戻る。タイムアウトの場合は、第４図の送信SIテーブル407
のリセット後（ステップ508）、障害処理を行ない（ス
テップ509）、その後、ステップ506のリトライチェック
処理を行なう。この障害処理では、第４図における送信SIテーブル40
7の多重度エリアの値に、個数エリア10713の値を設定す
る。このようにして、第２の実施例では、多重度数分の応
答メッセージを受信したタイミングで、リトライチェッ
ク処理を行なうことができる。このことにより、第１の実施例よりも、応答性が向上
する。次に、第１図における分散処理システムの第３の実施
例を説明する。本第３の実施例では、第１図に示した配置において、
プロセッサ１のディスク11内のファイル（Ａ）12からの
応答が戻ったタイミングで、UPa13に制御を戻し、か
つ、多重ファイル間の整合性を保証する。すなわち、第２図、および、第５図で示した、第１、
第２の実施例では、リトライチェック処理を、多重ファ
イルからの応答が全て揃ったタイミングで行なってい
た。そのため、応答性の面で、次の問題が生じる。例えば、第１図において、プロセッサ１内で実行中の
UPa13が、自プロセッサディスク11と、プロセッサ２の
ディスク21とに多重化されたファイル（Ａ）12、22をア
クセスする場合、UPa13は、自プロセッサディスク11の
ファイル（Ａ）12をアクセスしているにもかかわらず、
第１、および、第２の実施例では、アクセス応答がUPa1
3に戻るタイミングは、ファイル（Ａ）22の応答がネッ
トワーク４を介して戻るタイミングに合わされてしま
う。本第３の実施例では、このような応答性の低下を防止
するものである。また、本第３の実施例では、送信SIテーブル、およ
び、ファイル管理テーブルの構成は第４図に示す第２の
実施例と同一である。但し、多重化されたファイルの内
の一つを、競合発生時の優先ファイルとして使用する。この優先ファイルの指定は、ファイルアロケート時に
なっても良いし、また、ユーザが指定するのではなく、
ファイルオープン時に応答を返してきた多重ファイルの
内から、そのファイルの属するプロセッサ番号の、例え
ば、一番小さなものを優先ファイルとすることでも良
い。以下、本第３の実施例の処理動作を、第６図に基づき
説明する。第６図は、第１図における分散処理システムの本発明
に係る処理の第３の実施例を示すフローチャートであ
る。第１、第２の実施例と同様に、第１図におけるクライ
アントファイル管理モジュール106のアクセス応答メッ
セージ受信時の処理フローを示す図である。第６図（ａ）は、受信したアクセス応答メッセージの
読みだしから、本第３の実施例におけるリトライチェッ
ク処理に至るまでの処理フローであり、第６図（ｂ）
は、本第３の実施例におけるリトライチェック処理の処
理フロー、そして、第６図（ｃ）および（ｄ）は、それ
ぞれ、本第３の実施例におけるリトライ処理（３）、
（４）の処理フローを示すものである。第６図（ａ）に基づき、アクセス応答メッセージの読
みだしから、本第３の実施例におけるリトライチェック
処理に至るまでの処理を説明する。まず、クライアント管理モジュールは、ネットワーク
から受信し、入力メッセージエリアに格納されたアクセ
ス応答メッセージを読みだし（ステップ601）、送信SI
テーブルをチェックし、アクセス応答メッセージ内の発
生源情報部の値が、送信SIテーブルの発生源情報エリア
に登録されているか否かを判定する（ステップ602）。登録されていない場合は、自プロセッサが発生したア
クセス依頼に対する応答ではないため、そのメッセージ
を廃棄し（ステップ603）、次のアクセス応答メッセー
ジを待つ。ここまでの処理は、第２図、および、第５図における
第１、第２の実施例と同じである。登録されている場合は、このアクセス応答メッセージ
が、後述のリトライ処理（３）に対応するメッセージか
否かをチェックする（ステップ604）。リトライ処理（３）に対応するメッセージであれば、
ステップ608に進む。リトライ処理（３）に対応するメッセージでない場合
は、優先ファイル（Ａ）からの応答であるか否かを判断
する（ステップ605）。優先ファイル（Ａ）からの応答でなければ、後述のス
テップ608に進み、優先ファイル（Ａ）からの応答であ
れば、そのメッセージを依頼先のユーザプログラム（こ
こでは、第１図のUPa13）に渡し（ステップ606）、リト
ライチェック処理モードとする（ステップ607）。次に、このメッセージのステータス情報を送信SIテー
ブルに格納し（ステップ608）、多重度数分の応答を受
信したか否かを判断する（ステップ609）。多重度数分の応答を受信していれば、後述のステップ
613に進みリトライチェック処理を行ない、多重度数分
の応答を受信していなければ、タイムアウトしたか否か
を判断する（ステップ610）。タイムアウトでなければ、ステップ601に戻り、次の
受信メッセージの読みだしを行なう。タイムアウトであれば、送信SIテーブルをリセットし
て（ステップ611）、障害処理を行ない（ステップ61
2）、リトライチェック処理613に移る。尚、この障害処理では、第４図における送信SIテーブ
ル407の多重度エリアの値に、個数エリア10713の値を設
定する。以上のステップ605〜607の処理により、本第３の実施
例では、自プロセッサのファイルからの応答を受信した
タイミングで応答メッセージを依頼した第１図のUPa13
に制御を戻す。また、クライアントファイル管理モジュ
ールは、リトライチェックモードの間は、他のユーザプ
ログラムからのアクセスコマンドを受け付けても、リト
ライチェックモードが解除されるまで、その処理実行を
待つ。すなわち、第１図において、優先ファイルであるファ
イル（Ａ）12からのアクセス応答メッセージ受信時は、
ステップ601〜605における処理を進め、ステップ606で
アクセス応答メッセージをUPa13に渡して制御を戻し、
その後、ステップ607以降の処理を実行する。しかし、優先ファイルでないファイル（Ａ）22からの
アクセス応答メッセージの受信時は、ステップ606か
ら、ステップ608に移り、ステップ609における判断処理
を行なう。ここで、多重度数分の応答を受信している状態であれ
ば、ステップ613のリトライチェック処理を実施する。次に、第６図（ｂ）に基づき、本第３の実施例におけ
るリトライチェック処理を説明する。このリトライチェック処理では、まず、受信した応答
メッセージが、後述のリトライ処理（３）に対応するメ
ッセージか否かを判断する（ステップ614）。リトライ処理（３）に対応するメッセージでなけれ
ば、送信SIテーブルに登録されている応答メッセージの
ステータス情報が一致するか否かをチェックする（ステ
ップ615）。一致の場合は、送信SIテーブルの該当する部分をリセ
ットし（ステップ616）、さらに、ステップ607の処理で
セットしたリトライチェックモードを解除（リセット）
して（ステップ617）、リトライチェック処理を終了す
る。一方、ステップ615の処理において、アクセス応答メ
ッセージ間でステータス情報が、それぞれ、OK、NGと食
い違っていれば、送信SIテーブルをリセットして（ステ
ップ618）、後述のリトライ処理（３）を実施する（ス
テップ619）。また、ステップ614において、受信した応答メッセー
ジがリトライ処理（３）に対応するメッセージであれ
ば、後述のリトライ処理（４）を行なう（ステップ62
0）。第６図（ｃ）に基づき、本第３の実施例におけるリト
ライ処理（３）を説明する。このリトライ処理（３）では、以下の処理を行なう。まず、優先ファイルからの応答の結果（OKまたはNG）
を判断する（ステップ621）。優先ファイルからの応答がOKの場合には（ステップ62
2）、アクセス応答メッセージのトリガとなったコマン
ドに対するアクセス依頼メッセージを、再度、第１図の
出力メッセージエリア105に格納して（ステップ623）、
第１図の通信管理モジュール102による送出に基づき、
ステップ601からの受信メッセージの処理を行なう。一方、優先ファイルからの応答がNGの場合には、第２
図のステップ212の処理で説明したリトライ処理（１）
を行なう（ステップ624）。すなわち、アクセス応答メ
ッセージのトリガとなった発行コマンドに対する状態解
除コマンド（FREE、ERASE、CLOSE等）のアクセス依頼メ
ッセージを、第１図の出力メッセージエリア105に格納
し、第１図の通信管理モジュール102による送出に基づ
き、ステップ601からの受信メッセージの処理を行な
う。このリトライ処理（３）により発生したリトライ処理
依頼メッセージに対する応答メッセージは、ステップ60
4、並びに、ステップ614で確認され、ステップ620のリ
トライ処理（４）を実行する。第６図（ｄ）に基づき、第３の実施例におけるリトラ
イ処理（４）を説明する。まず、リトライ処理（３）における優先ファイルから
の応答がOKの時の応答メッセージの場合、すなわち、ス
テップ623の処理に対応する応答メッセージであり（ス
テップ625）、かつ、アクセス応答メッセージのステー
タス情報がNGとなっていた全ファイルからの応答メッセ
ージのステータス情報がOKとなれば（ステップ626）、
ステップ607で設定したリトライチェックモードを解除
して（ステップ627）、処理を終了する。全ファイルからの応答メッセージのステータス情報が
OKでない場合は、ステップ623に進み、再アクセス依頼
メッセージを、もう一度、出力メッセージエリアに格納
する。一方、リトライ処理（３）における優先ファイルから
の応答がNGの時の応答メッセージの場合、すなわち、ス
テップ624の処理に対応する応答メッセージであり（ス
テップ628）、状態解除依頼メッセージにより、ステー
タス情報がOKとなっていた全ファイルが解除されれば
（ステップ629）、ステップ607で設定したリトライチェ
ックモードを解除し（ステップ630）、第２図における
リトライ処理（２）を行なう（ステップ631）。すなわ
ち、ファイルの不整合を引き起こした最初のアクセス依
頼メッセージを、出力メッセージエリアに格納する。また、ステップ629で、ステータス情報がOKとなって
いた全ファイルが解除されなければ、ステップ624に進
み、再度、リトライ処理（１）を行なう。このように、第３の実施例によれば、ファイルの不整
合が発生した場合も、多重ファイル内容は、全て、優先
ファイル内容に一致し、ファイル間の整合性が保証でき
る。さらに、優先ファイルの応答が戻ったタイミング
で、ユーザプログラムに制御を戻し、多重ファイルの整
合性チェックによる応答性の低下を防止する。次に、この第３の実施例による分散処理システムの動
作を、タイミングチャートを用いて説明する。第７図は、第４図における送信SIテーブルとファイル
管理テーブルを有する分散処理システムの本発明に係る
処理動作の一実施例の処理動作を示すタイムチャートで
ある。第７図（ａ）は、第１、第２の実施例によるタイムチ
ャートであり、第７図（ｂ）は、第３の実施例によるタ
イムチャートである。第１、および、第２の実施例では、第７図（ａ）に示
すように、UPa13からの依頼メッセージ71に対するファ
イル（Ａ）12、22からの応答（応答メッセージ72、73）
の両方が戻ったタイミング74でリトライチェック処理75
を行ない、リトライチェック処理75がOKであれば、UPa1
3への制御の戻し76を行なう。これに対し、第３の実施例では、第７図（ｂ）で示す
ように、まず、ファイル（Ａ）12を優先ファイルとす
る。そして、本第３の実施例では、UPa13が発生した依
頼メッセージ71に対する優先ファイル（Ａ）12からの応
答メッセージ72が戻ってきたタイミング77で、UPa13へ
の制御の戻し78を行なう。その後、ファイル（Ａ）22からの応答メッセージ73が
戻ってきたタイミングでリトライチェック75を行なう。尚、リトライチェック75が終了する前に、UPa13が発
行したコマンド（WRITE）79は、リトライチェック75終
了後にアクセス依頼メッセージ70として、ファイル
（Ａ）12、22に送出する。このように、第３の実施例によれば、優先ファイルで
ある自プロセッサのディスク内のファイルの応答メッセ
ージが戻ったタイミングで、ユーザプログラムに制御を
戻し、多重ファイルの整合性チェックによる応答性の低
下を防止する。尚、第３の実施例で示した多重ファイルからの応答メ
ッセージのチェック方法、すなわち、まず、先着メッセ
ージをユーザプログラムに渡し、後着メッセージの受信
時に、先着メッセージとの整合性のチェックを行なう方
法は、プログラム、プリンタなどの各種資源を多重化し
た場合にも、同様に、適用可能である。以上、第１〜第７図を用いて説明したように、本第１
〜第３の実施例によれば、多重ファイルの不整合が発生
した場合においても、その不整合を自動的に解除するこ
とができる。さらに、最初に受信したファイルの応答メッセージ
で、ユーザプログラムに制御を戻し、その後で、ファイ
ルの整合性をチェックする。このことにより、多重ファ
イルの整合性チェックによる応答性の低下を防止する。尚、第１〜３の実施例で行なうリトライチェックは、
ファイル更新時に必要なチェックであり、例えば、「RE
AD ONLY」のモードでオープンしている場合は不要であ
る。従って、ファイルオープンモードを判定し、更新モ
ードでオープンされていない場合は、第１図のクライア
ントファイル管理モジュール106で、リトライチェック
処理を行なわず、先に受信したアクセス応答メッセージ
を、受信したタイミングで、ユーザプログラムに渡して
しまう方法を取ることも可能である。この際、後から受
信したアクセス応答メッセージに対しては、これを識別
し、廃棄する処理を取る。この方法により、ファイル更
新モード以外でアクセスする場合の応答性を向上させる
ことができる。このように、特に第３の実施例によれば、多重ファイ
ル間に発生する不整合状態を、ファイルアクセス応答を
低下させることなくチェックし、不整合状態発生時に
は、ユーザプログラム側に、それを意識させることな
く、自動的に、その不整合状態を解消することが可能と
なる。このことにより、重要なファイルを任意の多重度で多
重化でき、しかも、その際、アクセス応答性が低下する
ことがないため、ファイルの信頼性が向上するのみでな
く、ユーザに取っての使い勝手も向上する。〔発明の効果〕本発明によれば、任意の多重度に多重化された多重フ
ァイルに対し、多重ファイル間に不整合が発生した場合
でも、ファイルアクセスしている処理を中断することな
く、不整合状態を自動的に回復し、かつ、多重ファイル
間に発生する不整合状態の検出処理を、ファイルアクセ
ス応答性能を低下させることなく行ない、分散処理シス
テムの処理性能と信頼性を向上させることが可能であ
る。

【図面の簡単な説明】第１図は本発明を施した分散処理システムの本発明に
係る構成の第１の実施例を示すブロック図、第２図は第
１図における分散処理システムの本発明に係る処理動作
の第１の実施例を示すフローチャート、第３図は第１図
における分散処理システムの本発明に係る処理動作の一
実施例を示すタイムチャート、第４図は第１図における
送信SIテーブルおよびファイル管理テーブルの構成の第
２の実施例を示す説明図、第５図は第１図における分散
処理システムの本発明に係る処理動作の第２の実施例を
示すフローチャート、第６図は第１図における分散処理
システムの本発明に係る処理の第３の実施例を示すフロ
ーチャート、第７図は第４図における送信SIテーブルと
ファイル管理テーブルを有する分散処理システムの本発
明に係る処理動作の一実施例の処理動作を示すタイムチ
ャートである。１〜3:プロセッサ,4:ネットワーク,5:メッセージ,10:タ
ーミナル,11:ディスク,12:ファイル（Ａ）,13:ユーザプ
ログラム（UPa）,20:ターミナル,21:ディスク,22:ファ
イル（Ａ）,23:ユーザプログラム（UPb）,30:ターミナ
ル,31:ディスク,51:フラグ,52:内容コード,53:発生源ア
ドレス,54:通番,55:発生源情報,56:データ部,57:FCS,5
8:フラグ,70:アクセス依頼メッセージ,71:依頼メッセー
ジ,72〜73:応答メッセージ,74:タイミング,75:リトライ
チェック処理,76:戻し制御,77:タイミング,78:戻し制
御,79:コマンド（WRITE）,101:ネットワークインタフェ
ース,102:通信管理モジュール,103:内容コードテーブ
ル,104:入力メッセージエリア,105:出力メッセージエリ
ア,106:クライアントファイル管理モジュール,107:送信
SIテーブル,108:ユーザプログラム実行エリア,109:サー
バファイル管理モジュール,110:ファイル管理テーブル,
111:ディスクインタフェース,300:ファイルアクセスコ
マンド（READ）,301:アクセス依頼メッセージ（READ）,
302〜303:ステータス情報,304:リトライ処理（１）,30
5:解除依頼メッセージ（FREE）,306〜307:応答メッセー
ジ,308:リトライ処理（２）,309:アクセス依頼メッセー
ジ（READ）,320:ファイルアクセスコマンド（READ）,32
1:アクセス依頼メッセージ（READ）,322〜323:ステータ
ス情報,324:リトライ処理（１）,325:解除依頼メッセー
ジ（FREE）,326〜327:応答メッセージ,328:リトライ処
理（２）,329:アクセス依頼メッセージ（READ）,400〜4
01:多重度エリア,407:送信SIテーブル,410:ファイル管
理テーブル,521:ファイルネーム部,522:ID部,551:プロ
セッサ番号情報部,552:タスク番号情報部,553:通番情報
部,1071〜1072:行,1101〜1102:行,4071〜4072:行,4101
〜4102:行,10711:発生源情報エリア,10712:タイマエリ
ア,10713:個数エリア,10714:受信メッセージエリア,110
11:ファイルネームエリア11012:物理情報エリア,11013:
発生源情報エリア。

───────────────────────────────────────────────────── フロントページの続き (72)発明者森欣司神奈川県川崎市麻生区王禅寺1099番地株式会社日立製作所システム開発研究所内 (72)発明者平澤茂樹神奈川県川崎市麻生区王禅寺1099番地株式会社日立製作所システム開発研究所内 (72)発明者藤瀬洋神奈川県横浜市戸塚区戸塚町5030番地株式会社日立製作所ソフトウエア工場内 (72)発明者竹内増幸神奈川県横浜市戸塚区戸塚町5030番地株式会社日立製作所ソフトウエア工場内 (72)発明者鈴木仁愛知県尾張旭市晴丘町池上１番地株式会社日立製作所旭工場内 (56)参考文献ＫｅｎｎｅｔｈＰ．Ｂｉｒｍａｎ ”Ｒｅｐｌｉｃａｔｉｏｎａｎｄｆａｕｌｔ−ｔｏｌｅｒａｎｃｅｉｎｔｈｅＩＳＩＳｓｙｓｔｅｍ” ＯｐｅｒａｔｉｎｇＳｙｓｔｅｍＲｅｖｉｅｗＶｏｌ．19 Ｎｏ．５（1985）ｐｐ．79−86 (58)調査した分野(Int.Cl.⁷，ＤＢ名) G06F 12/00

Claims

(57)【特許請求の範囲】【請求項１】複数のプロセッサを共通伝送媒体を介して
接続し、上記複数のプロセッサのそれぞれのファイルに
多重データを配置する分散処理システムの多重データ処
理方法であって、ユーザプログラムからのデータアクセス依頼を受けた任
意のプロセッサ（第１のプロセッサ）において各プロセ
ッサへデータアクセス命令を発行すると共に当該データ
アクセス依頼に対応する処理を行なう第１のステップ
と、上記第１のプロセッサにおいて、上記データアクセス命
令に対応する対応データを予め１つ指定された優先ファ
イルから正常に受信すると、該応答データを上記ユーザ
プログラムに送信して該ユーザプログラムでの上記応答
データに基づく処理を開始させる第２のステップと、該ユーザプログラムでの上記優先ファイルからの応答デ
ータに基づく処理中に、上記第１のプロセッサにおい
て、上記各プロセッサから受信した上記データアクセス
命令に対応する応答データと上記ユーザプログラムに送
信した応答データとを比較して応答データ間の不整合の
発生の有無をチェックする第３のステップと、上記第１のプロセッサにおいて、上記データアクセス命
令に対応して上記優先ファイルから異常終了応答を受信
すると、該第１のプロセッサから各プロセッサに、上記
発行したデータアクセス命令を解除する命令を発行する
第４のステップと、上記第３のステップにおいて応答データ間の不整合の発
生を検知すると、上記第１のプロセッサから各プロセッ
サに上記データアクセス命令を再び発行する第５のステ
ップとを有することを特徴とする分散処理システムの多
重データ処理方法。