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

Abstract

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

Description

【発明の詳細な説明】 〔産業上の利用分野〕 本発明は、それぞれ多重に配置したリソースを有する複
数のプロセッサをネットワークにより結合し、各プロセ
ッサで役割を分担して、多重リソースから発生するデー
タの処理を行なう分散処理システムの多重データ処理方
法に係り、特に、処理を進めながら各ファイルの整合性
を確認し、信頼性の高い分散処理を効率良く行なうのに
好適な分散処理システムの多重データ処理方法に関する
ものである。

［従来の技術１ 現在、コンピュータは、広い分野で利用され、その高速
性、信頼性の向上を主目的として、様々な研究開発がな
されている。

特に、分散処理システムは、１９６０年代中期〜１９７
ｏ代中期のメインフレーム、１９７０代中期〜１９８０
代初期のミニコンピユータ、そして、１９８０年代のパ
ーソナルコンピュータに続く第４の波として、コンピュ
ータ産業における成長が期待されている。

分散処理システムとは、複数のコンピュータを接続した
ネットワーク全体を、あたかも−台のコンピュータであ
るかの様に利用するものである。

また、分散処理とは、通信回線で結ばれた複数のコンピ
ュータが協力しあって、一つのジョブを処理する処理形
態であり、各コンピュータには、そのジョブの一部を実
行するプロセッサが設けられ、それらがメツセージを授
受しあって処理を進める。

分散処理の目的は、従来、−台のコンピュータに集中し
て処理させていた全ての仕事を、複数のコンピュータで
分散して処理することにより、機能分散、負荷分散、地
域分散、そして、高信頼化を得るものである。

すなわち、それぞれのコンピュータに、それぞれ必要な
機能のみを持たせて、機能を分散することにより、それ
ぞれのコンピュータを小型化し、経済性を良くする。し
かも、各コンピュータが有する機能は高機能なものであ
り、全体として高機能のシステムが構築できる。

また、−台のコンピュータの計算速度、記憶容量、入出
力速度の能力以上の仕事に対しても、複数台のコンピュ
ータに分散して処理し、負荷の増減に柔軟に対応できる
。

また、すべての大量のデータを、遠距離にある一台のコ
ンピュータに送り処理していたのでは、データの伝送に
時間がかかる。しかし、地域分散により、簡単な前処理
を地域のコンピュータで行ない、その結果のみを中央に
送れば、一部の処理結果がその場で得られる。さらに、
伝送するデータの量が少なくて済む。

また、−台のコンピュータですべての処理を行なうと、
そのコンピュータが故障した場合には、システム全体が
止まってしまう。しかし、分散処理により、複数のコン
ピュータに仕事を分担しておけば、その内の一台が故障
しても、多少性能は落ちても、残りのもので処理の続行
が可能であり、システムの信頼性が向上する。

このような、分散処理に関しては、電子情報通信学会編
「電子情報通信ハンドブックＪ　　（１９８８年、オー
ム社発行）のｐｐ、ｔｓｉ５〜１６２６に記載されてい
る。

さらに、近年の分散処理では、「日経エレクトロニクス
　１９９０　６−１１　　ｎｏ、５０２」（１９９０年
、日経ＢＰ社発行）のｐｐ、ｉ２ｉ〜１４８に記載のよ
うに、異なるメーカの製品をネットワークで結ぶ異機種
間分散処理をサポートするものもある。

〔発明が解決しようとする課題〕

従来、分散処理システムにおけるファイルの管理、およ
び、制御方法に、重要なファイルのみを任意の多重度で
多重化して管理する方法がある。

そして、このような多重化されたファイルの信頼性に係
るものとして、多重化されたファイルからの出力データ
を、それを使用するコンピュータで一定期間の間収集し
、収集したデータ間の整合性をチェックするものがある
。

しかし、このような従来の分散処理システムにおける多
重ファイルの制御方法では、内容の不一致状態が発生し
た場合の回復の方法に関しての配慮がなされておらず、
不一致状態の発生時には、そのファイルをアクセスして
いた処理が停止するという問題があった。

また、多重化されたファイルからの出力データの整合性
のチェックを、一定期間の間収集してから行なうために
、その間、処理が遅れるなどの問題があった。

本発明の目的は、これら従来技術の課題を解決し、任意
の多重度に多重化された多重ファイルに対し、多重ファ
イル間に不整合が発生した場合でも、ファイルアクセス
している処理を中断することなく、不整合状態を自動的
に回復し、かつ、多重ファイル間に発生する不整合状態
の検出処理を、ファイルアクセス応答性能を低下させる
ことなく行ない、分散処理システムの処理性能と信頼性
を向上させる分散処理システムの多重データ処理方法を
提供することである。

【課題を解決するための手段〕

上記目的を達成するため、本発明の分散処理システムの
多重データ処理方法は、（１）複数のプロセッサを共通
伝送媒体を介して接続し、複数のプロセッサは、それぞ
れのプロセッサに多重に配置したリソースから発生する
多重データを用いて処理を進める分散処理システムの多
重データ処理方法において、複数のプロセッサは、多重
データの最初に受信したデータを用いて処理を進め、以
後受信した多重データを用いて、最初に受信したデータ
の整合性のチェックを行なうことを特徴とすまた、（２
）上記（１）に記載の分散処理システムの多重データ処
理方法において、複数のプロセッサのそれぞれに接続し
た外部記憶媒体のそれぞれにファイルを多重に配置し、
複数のプロセッサの任意のプロセッサは、多重に配置し
たファイルに対するアクセス依頼を発生し、かつ、アク
セス依頼に対応する多重に配置したファイルからの多重
応答データを受信し、そして、多重応答データの最初に
受信した応答データを用いて処理を進め、以後受信した
多重応答データを用いて、最初に受信した応答データの
整合性のチェックを行なうことを特徴とする。

また、（３）上記（２）に記載の分散処理システムの多
重データ処理方法において、アクセス依頼を発生したプ
ロセッサは、多重応答データ間のチェックが終了するま
で、次のファイルアクセス依頼を発生しないことを特徴
とする。

また、（４）上記（３）に記載の分散処理システムの多
重データ処理方法において、応答データの整合性のチェ
ックで応答データ間に不整合を検出した場合は、アクセ
ス依頼を発生したプロセッサは、アクセス依頼により生
じたファイル状態を解除する命令を発行する第１のリト
ライ処理を行ない、第１のリトライ処理によるファイル
状態の解除後、再び、アクセス依頼を発生する第２のリ
トライ処理を行ない、応答データ間の不整合がなくなる
まで、第１のリトライ処理、および、第２のリトライ処
理を繰り返すことを特徴とする。

また、（５）上記（４）に記載の分散処理システムの多
重データ処理方法において、アクセス依頼を発生したプ
ロセッサは、第１のリトライ処理、および、第２のリト
ライ処理を、応答データ間の不整合がなくなるまで繰り
返す代わりに、第２のリトライ処理を、予め設定された
任意の時間ずらして実行することを特徴とする。

また、（６）上記（４）、もしくは、（５）のいずれか
に記載の分散処理システムの多重データ処理方法におい
て、アクセス依頼を発生したプロセッサは、最初に受信
した応答データを用いた処理を行なわず、多重ファイル
からの全応答データを収集し、収集した全応答データ間
の整合性のチェック、および、第１のリトライ処理と第
２のリトライ処理による応答データ間の整合性の確定後
に、処理を行なうことを特徴とする。

また、（７）上記（４）〜（６）のいずれか一つに記載
の分散処理システムの多重データ処理方法において、ア
クセス依頼を発生したプロセッサは、予め任意に設定し
た時間内に収集した多重ファイルからの全応答データ間
の整合性のチェックに基づき、第１のリトライ処理、お
よび、第２のリトライ処理を行なうことを特徴とする。

また、（８）上記（７）に記載の分散処理システムの多
重データ処理方法において、アクセス依頼を発生したプ
ロセッサは、予め任意に設定した時間内に、多重ファイ
ルからの全応答データを収集できない場合、予め任意に
設定した時間内に収集した応答データを、整合性のチェ
ックの対象に限定する障害処理を行ない、障害処理の後
に、整合性のチェック、および、第１のリトライ処理と
第２のリトライ処理を行なうことを特徴とする。

また、（９）上記（４）に記載の分散処理システムの多
重データ処理方法において、アクセス依頼を発生したプ
ロセッサは、第１のリトライ処理として、アクセス依頼
がファイル更新時のリードコマンドの場合は、リードコ
マンドの排他管理によるレコードの占有状態を解除する
フリーコマンドを、アクセス依頼が追加コマンドの場合
は、追加コマンドにより追加したレコードを削除するイ
レースコマンドを、アクセス依頼が排他オープンコマン
ドの場合は、排他オープンコマンドによるファイルの占
有状態を解除するクローズコマンドを発行することを特
徴とする。

そして、（１０）上記（４）〜（６）のそれぞれに記載
の分散処理システムの多重データ処理方法において、複
数のプロセッサは、アクセス依頼メツセージ、および、
アクセス応答メツセージのメツセージを伝送媒体へブロ
ードキャストし、メツセージのやり取りにより分散処理
を行ない、複数のプロセッサのそれぞれは、自プロセッ
サから他プロセッサへのメツセージの伝送媒体へのブロ
ードキャスト、および、伝送媒体へブロードキャストさ
れたメツセージから、自プロセッサに関連するメツセー
ジの取り込みを行なう通信管理モジュールと、通信管理
モジュールで取り込んだメツセージを、メツセージを処
理するユーザプログラムに渡し、かつ、ユーザプログラ
ムからのファイルアクセス命令に基づき、アクセス依頼
メツセージを生成し、通信管理モジュールに送出するク
ライアントファイル管理モジュールと、クライアントフ
ァイル管理モジュールが通信管理モジュールに送出した
メツセージ情報を格納する送信情報格納手段とを有し、
アクセス依頼を発生したプロセッサは、クライアントフ
ァイル管理モジュールを用いて、通信管理モジュールを
介して伝送媒体にメツセージを送出すると同時に、整合
性のチェックに用いる予め任意に設定した収集時間を送
信情報格納手段に格納し、そして、送信情報格納手段に
格納した時間に基づき、多重ファイルからの全応答デー
タ間の整合性のチェック、および、第１のリトライ処理
と第２のリトライ処理を行なうことを特徴とする。

〔作用〕

本発明においては、各プロセッサは、自ら発行したアク
セス命令に基づき送られてきた多重ファイルからの複数
の応答データを受は取る。この時、多重ファイルから最
初に受信した応答データを、受信したタイミングでユー
ザプログラムに渡すと共に、自プロセッサ内に格納して
おく。

そして、以後に受信した応答データと、この最初に受信
した応答データとを比較し、応答データ間（すなわち、
多重ファイル間）の不整合の発生をチェックする。

ここで、応答データ間での不一致を検出した場合、アク
セス命令を発行した自プロセッサは、まず、多重ファイ
ルに対して発行したアクセス命令を解除する命令を発行
し、自プロセッサのアクセス命令により引き起こされた
ファイル状態を解除する（第１のリトライ処理）。そし
て、次に、再び、同じアクセス命令を発行する（第２の
リトライ処理）。

ここで、多重ファイル間の不整合状態は、複数のプロセ
ッサが、同時に、多重ファイルにアクセスした場合に発
生するものである。そして、アクセス命令の再発行は、
各プロセッサが、独自のタイミングで行なう。そのため
に、お互いのアクセス命令再発行のタイミングは自動的
にずれる。このことにより、再発行のアクセス命令に関
しては、不整合状態の発生は自動的に回避される。

このことにより、任意の多重度に多重化されたファイル
に対し、多重ファイル間に不整合が発生した場合でも、
ファイルアクセスしている処理を中断することなく、不
整合状態を自動的に回復する。

また、一番最初に多重ファイルからの応答を受信したタ
イミングで、ユーザプログラムに制御が戻るため、ファ
イル間整合性チェックのために、ファイルアクセス応゛
答が低下することはない。

〔実施例〕

以下、本発明の実施例を、図面により詳細に説明する。

第１図は、本発明を施した分散処理システムの本発明に
係る構成の第１の実施例を示すブロック図である。

分散処理システムは、バス型ネットワークのネットワー
ク４に、それぞれ処理を分担して実行するプロセッサ１
〜３、プロセッサ１〜３のそれぞれに接続され、処理操
作指示の入力機能および処理結果の表示機能を有するタ
ーミナル１Ｏ１２０，３０、同じく、プロセッサ１〜３
のそれぞれに接続され、処理の対象となるデータを格納
するディスク１１．２１．３１から構成されている。

さらに、プロセッサ１のディスク１１と、プロセッサ２
のディスク２１内には、ファイル（Ａ）１２．２２を多
重に持たせている。

また、プロセッサ１にはユーザプログラム１３（以下Ｕ
Ｐａ“１３と記載）が、また、プロセッサ２にはユーザ
プログラム２３（以下ＵＰｂ２３と記載）が存在する。

そして、本発明に係る処理を行なうプロセッサ１〜３の
それぞれは、ネットワーク４上に送出したメツセージ５
の授受により分散処理を行なう。

ここで、メツセージ５の構成に関しての説明を行なう。

メツセージ５の初めと終わりを、それぞれ示すフラグ５
１．５８（図中Ｆと記載）、メツセージの内容を示す内
容コード５２（図中ＣＣと記載）、本メツセージを発生
したプロセッサのプロセッサ番号を格納する発生源アド
レス５３（図中ＳＡと記載）、ネットワーク４による伝
送で必要となる通番５４（図中Ｃと記載）、ファイルを
アクセスするユーザプログラム（例えば、ＵＰａ１３）
を示す発生源情報５５（図中ＳＩと記載）、伝送される
べき情報を格納するエリアであるデータ部５６（図中Ｄ
　ａｔａと記載）、伝送上の誤りをチェックするための
エリアであるＦ　ＣＳ　（Ｆｒａｍｅ　　Ｃｈｅｃｋ　
　５ｅｑｕｅｎｃｅｒ）　５７から構成されている。

また、内容コード５２は、アクセスするファイルを示す
ファイルネーム部５２１　（図中ＦＮＭと記載）、ファ
イルアクセス依頼やファイルアクセス応答などのメツセ
ージの種別を示すＩＤ（ＩＤｅｎｔｉｆｉｅｒ）部５２
２からなる。

重篤１の実施例では、ファイル名称は、システム内でユ
ニーク（唯一）であるという前提のもとに、ファイルネ
ーム部５２１の内容としてファイル名称を用いる。但し
、ファイルネーム部５２１は、ファイル名称の代わりに
、ファイル内容に対応するコード等を用いても構わない
。

また、発生源情報５５は、ユーザプログラムを実行中の
プロセッサのプロセッサ番号を格納するエリアであるプ
ロセッサ番号情報部５５１（図中ＰＮＯ５５１と記載）
、実行中プログラムを示す情報を格納するエリアである
タスク番号情報部５５２（図中ＴＮＯと記載）、そして
、ユーザプログラムが発生するメツセージの順番を示す
通番エリアである通番情報部５５３（図中ＳＥＱと記載
）からなる。

このようなフォーマットのメツセージ５を、重篤１の実
施例において、各プロセッサ１〜３は、ネットワーク４
上にブロードキャストする。また、各プロセッサ１〜３
は、ネットワーク上のメツセージ５の内容コード５２の
内容に基づき、そのメツセージ５が自らに必要か否かを
判定し、必要なメツセージ５のみを取１ノ込む。

次に、各プロセッサ１〜３の構成、および、その機能を
、プロセッサ１を用いて説明する。

ネットワークインタフェースｌ○１は、ネットワーク４
とのインタフェースを取るためのモジュールで、ディス
クインタフェース１１１は、ディスク１１とのインタフ
ェースを取るためのモジュールである。

通信管理モジュール１０２は、ネットワーク４より受信
したメツセージ５の内容（内容コード５２）に基づき、
受信メツセージが自プロセッサに必要なものであるか否
かを判定し、必要なメツセージの場合は、それを入力メ
ツセージエリア１０４に格納する。また、出力メツセー
ジエリア１０５内のメツセージをメツセージ５として、
ネットワークインタフェースｌｏｔ経由で、ネットワー
ク４にブロードキャストする。

尚、この際、通信管理モジュール１０２は、送出メツセ
ージに対しても、ネットワーク４からの受信メツセージ
と同じように、その送出メツセージが、自プロセッサに
必要であるか否かを判定し、必要な場合は、入力メツセ
ージエリア１０４に、その送出メツセージを格納する。

また、入力メツセージエリア１０４、出力メツセージエ
リア１０５には、それぞれ、受信メツセージと送信メツ
セージが、内容コーｈ”５２対応に格納されている。

内容コードテーブル１０３には、自プロセッサで必要と
するメツセージ５の内容コードが登録される。具体的に
は、メツセージＳのファイルネーム部５２１には、自デ
ィスク１１内ファイルの「ファイル名称」が、また、Ｉ
Ｄ部５２２には、「アクセス依頼」を示すコードが設定
された内容コードが、例えば、プロセッサ立ち上げ時に
登録される。また、ユーザプログラムの実行状況に応じ
て、ＩＤ部５２２にアクセス応答を示すコードが設定さ
れた内容コードも登録される。

通信管理モジュール１０２は、受信したメツセージ５内
の内容コード５２と、内容コードテーブル１０３に登録
されている内容コードとを比較し、一致するメツセージ
５を取り込む。

クライアントファイル管理モジュール１０６は、入力メ
ツセージエリア１０４内のメツセージをＵＰａ１３に渡
すと共に、ＵＰａ１３からの送出メツセージを、出力メ
ツセージエリア１０５に格納する処理を行なう。

送信Ｓ　Ｉ　（Ｓｏｕｒｃｅ　　Ｉ　ｎｆｏｒ＋＊ａｔ
ｉｏｎ、発生源情報）テーブル１０７は、クライアント
ファイル管理モジュール１０６が、出力メツセージエリ
ア１０５に格納するメツセージ５の発生源情報５５の内
容を、内容コード５２対応に格納しておくテーブルであ
る。

ユーザプログラム実行エリア（図中ＬＩＰ実行エリアと
記載）１０８は、ＵＰａ１３などのユーザプログラムを
実行するエリアである。

ファイル管理テーブル１１０、および、サーバファイル
管理モジュール１０９は、自プロセッサ１に接続された
ディスクｌｌ内のファイル（Ａ）１２のアクセスを管理
するためのものである。

次に、送信ＳＩ子テーブル０７、および、ファイル管理
テーブル１１０のフォーマットに関して説明する。

送信ＳＩ子テーブル０７は、ファイルアクセス依頼を示
すメツセージ５の発生源情報５５に対応した行１０７１
〜１ｏ７２を有する。そして、これら各行１０７１〜１
ｏ７２のそれぞれにおいては、アクセス依頼メツセージ
の発生源情報５５の内容を格納する発生源情報エリア（
図中ＳＩエリアと記載）１０７１１に、アクセス依頼に
対する応答のタイムアウトを検出するための身イマエリ
ア１０７１２と、アクセス依頼に対するアクセス応答を
示すメツセージの個数を格納するための個数エリア１０
７１３と、受信したアクセス応答メツセージを格納する
ための受信メツセージエリア１０７１４とが対応付けら
れている。

ファイル管理テーブル１１０は、自ディスク１１内のフ
ァイルに対応する行１　ｌｏｔ〜１１０２を有する。そ
して、各行１１０１〜１１０２には、各ファイルに対応
するコード（木簡１の実施例ではファイル名称）を格納
するファイルネームエリア（図中ＦＮＭエリアと記載）
１１０１１、そのファイルが格納されているディスク、
および、ディスク内での位置を示す情報を格納する物理
情報エリア１１０１２、および、そのファイルに対する
アクセス依頼メツセージの発生源情報（メツセージ５に
おける発生源情報５５）の内容を格納するための発生源
情報エリア（図中ＳＩエリアと記載）１１０１３よりな
る。

このうち、ファイルネームエリア１１０１１と、物理情
報エリア１１０１２は、ファイルアロケート時に、前も
って設定されているものとする。

以下、このような構成からなる木簡１の実施例の分散処
理システムにおいて、各プロセッサ１〜３間で行なわれ
るメツセージ５の送受信の基本的な動作を説明する。

まず、メツセージ５の送信動作を、ＵＰａ１３がファイ
ルアクセス命令を発行した時のクライアントファイル管
理モジュール１０６の処理動作に基づき説明する。

ＵＰａ１３は、アクセスするファイル名称、および、ア
クセス内容を指定してファイルアクセス命令を発行する
。

このアクセス命令は、クライアントファイル管理モジュ
ール１０６が取り込み、メツセージ５のフォーマットで
示した内容コード５２、発生源情報５５、データ部５６
を以下のように設定したメツセージを作成し、出力メツ
セージエリア１０５に格納する。

すなわち、内容コード５２のファイルネーム部５２１に
はＵＰａ１３で指定されたファイル名称が、そして、Ｉ
Ｄ部５２２にはアクセス依頼を示すコードが設定されて
いる。

発生源情報５５のプロセッサ番号部５５１には自プロセ
ッサ番号が、また、タスク番号５５２にはファイルアク
セス命令を発行したＵＰａ　１３に割り当てられている
番号、例えば、タスク番号などが、そして、メツセージ
順番部５５３にはアクセス命令の発行された順番を示す
通番が設定されている。さらに、データ部５６には％Ｕ
Ｐａ　ｌ　３が指定したアクセス内容が設定されている
。

また、この際、設定した発生源情報５５の内容を、送信
ＳＩ子テーブル０７の発生源情報エリア１０７１１に設
定し、さらに、対応するタイマエリア１０７１２にタイ
マを設定する。

以上の処理により、出力メツセージエリア１０５に格納
されたメツセージは、通信管理モジュール１０２により
、ネットワーク４に、メツセージ５としてブロードキャ
ストされる。

このようなメツセージを、アクセス依頼メツセージと呼
ぶ。

次に、メツセージの受信動作を、サーバファイル管理モ
ジュール１０９の処理動作に基づき説明する。

例えば、プロセッサ２のクライアントファイル管理モジ
ュールが、ＵＰｂ２３の要求に基づいて、アクセス依頼
メツセージを、プロセッサ２の通信管理モジュール経由
でネットワーク４に、メツセージ５で示したフォーマッ
トでブロードキャストする。

そのアクセス依頼メツセージは、そのメツセージ５内の
内容コード５２に指定されたファイル、例えば、ファイ
ル（Ａ）１２を自ディスク内に持つプロセッサ、ここで
は、プロセッサｌにより取り込まれる。そして、プロセ
ッサ１内の通信管理モジュール１０２は、このファイル
（Ａ）１２へのアクセス依頼メツセージを、入力メツセ
ージエリア１０４に格納する。

サーバファイル管理モジュール１０９は、入力メツセー
ジエリア１０４より、このメツセージを取り込み、取り
込んだメツセージ内の発生源情報５５の内容を、ファイ
ル管理テーブル１１０の発生源情報エリア１１０１３に
格納する。

そして、サーバファイル管理モジュール１０９は、メツ
セージ５内のデータ部５６で指定されるファイルアクセ
ス処理を、ファイル管理テーブル１１０内の物理情報エ
リア１１０１２の内容に基づき実行する。

さらに、サーバファイル管理モジュールｌ○９は、この
ファイルアクセス処理の結果に基づき、メツセージの内
容コード５２、発生源情報５５、データ部５６を以下の
様に設定したアクセス応答を示すメツセージを作成し、
出力メツセージエリア１０５に格納する。尚、このメツ
セージをアクセス応答メツセージと呼ぶ。

アクセス応答メツセージにおいては、ファイルネーム部
５２１にはアクセスしたファイルの名称が、ＩＤ部５２
２にはアクセス応答を示すコードが設定されている。ま
た、発生源情報５５には、アクセス依頼メツセージ内の
発生源情報の値（ファイル管理テーブル発生源情報エリ
ア１１０　’ｌ　３の内容）が設定される。そして、デ
ータ部５６にはファイルアクセスの結果内容が設定され
ている。

ここで、ファイルアクセスの結果内容とは、アクセスが
正常終了したか否か、および、異常終了した場合には、
異常の内容を示す情報のことである。

以後、この情報をステータス情報と呼ぶ。また、リード
（ＲＥＡＤ、読み取り）コマンドの場合は、リードした
内容も含む。

以上の処理により出力メツセージエリア１０５に格納さ
れたファイルアクセス応答メツセージは、通信管理モジ
ュール１０２により、ネットワーク４に、メツセージ５
としてブロードキャストされる。

そして、このアクセス応答メツセージは、アクセス依頼
を発生したユーザプログラム、すなわち、ＵＰｂ２３を
実行中のプロセッサ２により取り込まれる。

このようにして、水弟１の実施例の分散処理システムは
、各プロセッサ１〜３間でメツセージ５の授受を行ない
、分散処理を進めて行く。

以上のような構成からなる第１の実施例の分散処理シス
テムにおいては、以下に示す問題に対処して、本発明に
係る処理動作を行なう。

まず、その問題点を説明する。

例えば、二つのＵＰａ１３、Ｕｐｂ２３が、同時に、多
重化されたファイル（Ａ）１２．２２をアクセスする場
合を想定する。

ＵＰａ　１３が、ファイルアクセスコマンドを発行し、
アクセス依頼すると、このファイルアクセスコマンドは
、自プロセッサ１のディスクｌｌ内のファイル（Ａ）１
２と、プロセッサ２のディスク２１内のファイル（Ａ）
２２に送られる。

この場合、ネットワーク４を介さないで済む自プロセッ
サ１内のファイル（Ａ）１２の方が先に処理される。そ
して、ファイル（Ａ）１２のファイルアクセスコマンド
に対する処理結果が、ＵＰａ１３に送られ、アクセス応
答がなされる。

一方、ＵＰａ１３がファイルアクセスコマンドを発行し
たのと同時に、ＵＰｂ２３が、ＵＰａ１３と同一レコー
ドに対するファイルアクセスコマンドを発行したものと
する。

すると、ＵＰｂ２３のファイルアクセスコマンドも、Ｕ
Ｐａ１３のファイルアクセスコマンドと同様に、自プロ
セッサ２のディスク２１内のファイル（Ａ）２２と、プ
ロセッサ１のディスク１１内のファイル（Ａ）１２に送
られる。

この場合は、自プロセッサ２内のファイル（Ａ）２２の
方が先に処理される。

そして、ファイル（Ａ）２２に対するファイルアクセス
コマンドの処理結果が、ＵＰｂ２３に送られる。

すなわち、ファイル（Ａ）１２に対しては、ＵＰａ１３
がアクセスし、ファイル（Ａ）２２に対しては、ＵＰｂ
２３がアクセスしている状態が発生する。

この状態で、ファイル（Ａ）１２には、ＵＰｂ２３のア
クセスコマンドが、また、ファイル（Ａ）２２には、Ｔ
ＪＰａ１３のアクセスコマンドが到達する。この場合、
アクセスコマンドの内容によっては、ハード的には全く
障害がなくても、例えば、以下に示すような状態が発生
する。

（１）アクセスコマンドがファイル更新のためのリード
（ＲＥ　Ａ　Ｄ）コマンドの場合：ファイル更新の場合
は、ファイルアクセス排他管理を行なうため、リード（
ＲＥＡＤ、読み取り）受は付は時から、ライト（ＷＲＩ
ＴＥ、書き込み）処理完了時まで、ファイル内の対象と
なるレコードへの他ユーザプログラムからのアクセスを
禁止する。そのために、ＵＰａ１３がリード（ＲＥＡＤ
）状態のファイル（Ａ）１２のレコードに対する、ＵＰ
ｂ２３のアクセスコマンド（ＲＥＡＤ）は、排他エラー
としてはねられ、受は付けられない。

同様に、ファイル（Ａ）２２に到達したＵＰａ１３のリ
ード（ＲＥＡＤ）コマンドも排他エラーとしてはねられ
る。

この状態で、ＵＰａ　１３、および、ＵＰｂ２３がライ
ト（ＷＲＩＴＥ）処理を行なうと、ファイル（Ａ）１２
の対象レコードはＵＰａ　１３により、また、ファイル
（Ａ）２２の対象レコードはＵＰｂ２３により、それぞ
れ更新される。そのために、ファイル（Ａ）１２とファ
イル（Ａ）２２の内容が食い違うことになる。

（ｉｔ）アクセスコマンドがレコード追加のための追加
（ＡＤＤ）コマンドの場合： アクセスコマンドがファイルの同一レコードに対する追
加（ＡＤＤ）コマンドの場合は、ファイル（Ａ）１２に
対してはＬＪＰａ　１３の追加内容が、また、ファイル
（Ａ）２２に対しては、ＬＩ　Ｐ　ｂ　２３の追加内容
が反映されている。このことにより、ファイル（Ａ）１
２とファイル（Ａ）２２の内容が食い違うことになる。

（ｉｔｔ）アクセスコマンドが排他オーブン（ＯＰＥＮ
）コマンドの場合： アクセスコマンドが排他オーブン（ＯＰＥＮ）コマンド
の場合は、ファイル（Ａ）１２に対してはＵＰａ１３の
アクセスコマンドのみが、また、ファイル（Ａ）２２に
対してはＵＰｂ２３のアクセスコマンドのみが受は付け
られ状態となる。このために、ファイル（Ａ）１２とフ
ァイル（Ａ）２２の内容が食い違う二とになる。

以上のような問題を解決するために、木簡１の実施例の
分散処理システムにおいて、各プロセッサ１〜３は、そ
れぞれの多重ファイルからの応答データ間のチェックを
行なう。そして、応答データ間での不一致を検出した場
合は、自プロセッサが、多重ファイルに対して発行した
アクセス命令を解除する命令を発行しく第１のリトライ
処１り、さらに、再び、最初のアクセス命令を発行する
（第２のリトライ処理）。

この時、アクセス命令の再発行は、各プロセッサが独自
のタイミングで行なうために、お互いのアクセス命令再
発行のタイミングは自動的にずれ、不整合状態の発生は
自動的に回避される。

このように、ファイル間の不整合が発生した場合は、発
行したアクセス命令を解除する命令を発行した後（第１
のリトライ処理）に、最初のアクセス命令と同じアクセ
ス命令を再び発行する（第２の゛リトライ処理）、この
ことにより、処理を中断することなく、不整合状態を自
動的に回復することができる。

以上のようにして、本第゛１の実施例の分散処理システ
ムにおける各プロセッサ１〜３は、多重化したファイル
に対し“−その整合性を保ったまま、各ユーザプログラ
ムが、同時にアクセスすることを可能とする。

尚、木簡１の実施例及び、以下に示す第２．第３の実施
例のネットワーク構成は、バス型ネットワークであるが
、これに限らず、任意の形態のネットワークで構成可能
である。

また、各プロセッサ１〜３には、ターミナルｌ０１２０
．３０およびディスク１１．２１．３１が複数台接続さ
れていても良いし、−台も接続されていなくとも良い。

さらに、木簡１の実施例では、ファイルは二重化ファイ
ルの例を示しているが、本発明は、任意の多重度に多重
化したファイルにも適用できる。

以下、第１の実施例の分散処理システムにおける各プロ
セッサの本発明に係る動作を、さらに詳しぐ説明する。

第２図は、第１図における分散処理システムの本発明に
係る処理動作の第１の実施例を示すフローチャートであ
る。

第１図におけるクライアントファイル管理モジュール１
０６の処理動作に関するものであり、特に、アクセス応
答メツセージの受信時、および、本発明の第１のリトラ
イ処理（以下、リトライ処理（１）と記載）と、第２の
リトライ処理（以下、すトライ処理（２）と記載）の動
作を示すものである。

尚、この実施例は、多重化されたファイルからの応答を
一定時間の間収集し、その結果に基づき多重ファイル間
の整合性をチェックする方法である。

第２図（ａ）は、受信したアクセス応答メツセージの読
みだしからリトライ処理（１）、（２）からなるリトラ
イチェック処理の開始までのフローを示し、第２図（ｂ
）は、リトライチェック処理のフロー、そして、第２図
（ｃ）、（ｄ）は、それぞれ、リトライ処理（１）と、
リトライ処理（２）の処理の一実施例を示している。

まず、第２図（ａ）に基づき読切する。

クライアント管理モジュールは、ネットワークから受信
し、入力メツセージエリアに格納されたアクセス応答メ
ツセージを読みだしくステップ２０１）、送信ＳＩ子テ
ーブルチェックし、アクセス応答メツセージ内の発生源
情報部の値が、送信ＳＩ子テーブル発生源情報エリアに
登録されているか否かを判定する（ステップ２０２）。

登録されていない場合は、自プロセッサが発生したアク
セス依頼に対する応゛答ではないため、そのメツセージ
を廃棄しくステップ２ｏ３）、次のアクセス応答メツセ
ージを待つ。

登録されている場合は、受信したアクセス応答メツセー
ジを、送信ＳＩ子テーブル対応する（メツセージ内の発
生源情報部の内容が登録されている）行の受信メツセー
ジエリアに格納する（ステップ２０４）。尚、この時、
個数エリアの値を一つ増加させる。

次に、アクセス依頼メツセージ発生時にセットしたタイ
マがタイムアウトしているか否かを、送信ＳＩ子テーブ
ルタイマエリアに基づき判定する（ステップ２０５）。

タイムアウトしていない場合は、次のメツセージ受信の
待ち状態となる。

タイムアウトの場合は、本発明のリトライ処理（１）、
（２）からなるリトライチェック処理を行なう（ステッ
プ２０６）。

以下、第２図（ｂ）に基づき、リトライチェック処理を
説明する。

送信ＳＩ子テーブル格納したアクセス応答メツセージが
、リトライ処理（１）に対応するメツセージか否かをチ
ェックする（ステップ２０７）。

リトライ処理（１）に対応するメツセージでなければ、
送信ＳＩ子テーブル受信メツセージエリア内に格納され
たアクセス応答メツセージ間で、その内容を比較する（
ステップ２０８）。

尚、その内容の比較の方法としては、メツセージの全内
容を比較する方法もあるが、ここでは、応答メツセージ
間で、アクセス処理の終了状態を示すステータス情報の
みを比較する方法とする。

さて、応答メツセージ間で、ステータス情報が一致する
場合は、多重化されている各ファイル間の整合性が保証
されているので、受信したファイルアクセス応答メツセ
ージをユーザプログラム、例えば、第１図のファイル（
Ａ）１２に渡すぐステップ２０９）。

その後、送信ＳＩ子テーブル対応するエリアをリセット
して（ステップ２１ｏ）、処理を終了する。

尚、ここで、受信した応答メツセージ数が「０」の場合
は、ユーザプログラムにファイル障害を示す情報を渡す
。

一方、ステップ２０８において、ファイルアクセス応答
メツセージ間で、終了ステータス情報が一致しない場合
は、多重化ファイル間の整合性が保証できないため、送
信ＳＩ子テーブル対応するエリアをリセットしくステッ
プ２１１）、応答メツセージを要求したファイルアクセ
ス依頼コマンド内容に応じて、次のリトライ処理（１）
を行なう（ステップ２１２）。

また、ステップ２０７において、アクセス応答メツセー
ジが、リトライ処理（’１　）に対応するメツセージで
あれば、リトライ処理（２）を行なう（ステップ２１３
）。

以下、第２図（Ｃ）に基づき、リトライ処理（１）を説
明する。

まず、アクセス依頼がリード（ＲＥＡＤ）コマンドの場
合（ステップ２１４）、排他管理によりレコードを占有
している状態を解除するためのフリー（ＦＲＥＥ）コマ
ンドをデータ部に持つアクセス依頼メツセージを作成し
、出力メツセージエリアに格納する（ステップ２１５）
。

アクセス依頼が追加（ＡＤＤ）コマンドの場合には（ス
テップ２１６）、追加（ＡＤＤ）コマンドにより追加し
たコードを削除するためのイレース（ＥＲＡ　Ｓ　Ｅ）
コマンドをデータ部に持つアクセス依頼メツセージを作
成し、出力メツセージエリアに格納する（ステップ２１
７）。

アクセス依頼が排他オーブン（ＯＰＥＮ）コマンドの場
合には（ステップ２１８）、排他オーブン（ＯＰＥＮ）
コマンドによりファイルを占有している状態となってい
るため、この状態を解除するためのクローズ（ＣＬＯＳ
Ｅ）コマンドをデータ部に持つアクセス依頼メツセージ
を作成して、出力メツセージエリアに格納する（ステッ
プ２１９）。

このように、それぞれのアクセス依頼メツセージに対応
しくステップ２２０）、それぞれのアクセス依頼メツセ
ージによるファイルの占有状態を解除するためのコマン
ドをデータ部に持つアクセス依頼メツセージを作成し、
出力メツセージエリアに格納する（ステップ２２１）。

尚、これらのメツセージ（ＦＲＥＥ、ＥＲＡＳＥ、ＣＬ
Ｏ８Ｅコマンドなど）は、通信管理モジュールにより、
第１図のネットワーク４にブロードキャストされる。

そして、このようなリトライ処理（１）により発行され
たアクセス依頼メツセージに対するアクセス応答メツセ
ージの受信を待つ。

このリトライ処理（１）に対する応答メツセージに関し
ても、ステップ２０１〜２０６の処理フローに従う、そ
して、ステップ２０７において、受信メツセージが、リ
トライ処理（１）により発生されたコマンドに対するア
クセス応答メツセージであると確認されれば、リトライ
処理（２）を行なう（ステップ２１３）。

以下、第２図（ｄ）に基づき、リトライ処理（２）を説
明する。

このリトライ処理（２）では、リトライ処理（１）を行
なうトリガとなったアクセス依頼コマンドをデータ部に
持つアクセス依頼メツセージを作成し、出力メツセージ
エリアに格納する。

すなわち、リトライ処理（１）でフリー（Ｆ　ＲＥ　Ｅ
）コマンドが発行されていれば（ステップ２２２）、す
、−ド（ＲＥＡＤ）コマンドをデータ部に持つアクセス
依頼メツセージを作成し、出力メツセージエリアに格納
する（ステップ２２３）。

また、リトライ処理（１）でイレース（ＥＲＡＳＥ）コ
マンドをデータ部に持つアクセス依頼メツセージを作成
していれば（ステップ２２４）、追加（ＡＤＤ）’コマ
ンドをデータ部に持つアクセス依頼メツセージを作成し
、出力メツセージエリアに格納する（ステップ２２５）
。

また、リトライ処理（１）でクローズ（ＣＬＯＳＥ）コ
マンドをデータ部に持つアクセス依頼メツセージを作成
していれば（ステップ２２６）、排他オーブン（ＯＰ　
Ｅ　Ｎ）コマンドをデータ部に持つアクセス依頼メツセ
ージを作成して、出力メツセージエリアに格納する（ス
テップ２２７）。

このように、リトライ処理（１）によりファイルの占有
状態を解除されたそれぞれのアクセス依頼メツセージに
対応しくステップ２２８）、同じ、アクセス依頼メツセ
ージを再度作成し、出力メツセージエリアに格納する（
ステップ２２９）。

そして、これらのメツセージ（ＲＥＡＤ１ＡＤＤ１徘他
０ＰＥＮコマンドなど）は、通信管理モジュールにより
、第１図のネットワーク４にブロードキャストされる。

尚、このリトライ処理（２）と同じ内容のリトライ処理
（２）が、他のプロセッサでも発行されるが、この時は
、それぞれの発行タイミングが異なる。

そのために、リトライ処理（２）により発りされるメツ
セージによるファイル間の不整合は、発生しない、そし
て、このリトライ処理（２）に対応する受信メツセージ
は、ステップ２０８における不整合チェックでＯＫ（ｒ
整合」）となり、正常に終了することができる。

このように、本実施例の分散処理システムによれば、多
重ファイル間に不整合が発生した状況でも、リトライ処
理（１）により不整合状態を解除し、その後、リトライ
処理（２）によりアクセス処理が再実行されるため、フ
ァイル間の整合性は、自動的に保証された状態になる。

尚、各プロセッサによるリトライ処理（２）の実行タイ
ミングをずらす目的で、それぞれのリトライ処理（２〕
のリトライコマンドを発行する前に、ランダムな待ち時
間をいれても良い。

以下、さらに、第１図における実線矢印（ａ）と点線矢
印（ｂ）で示す２つのファイルアクセスに基づき、本発
明に係る処理動作を説明する。

第３図は、第１図における分散処理システムの本発明に
係る処理動作の一実施例を示すタイムチャートである。

第２図で示した処理動作に基づくタイムチャートであり
、第１図の二つのユーザプログラム、ＵＰａ１３とＬ７
Ｐｂ２３が、それぞれ同時に多重化されたファイル（Ａ
）１２．２２をリードＣＲＥＡＤ〕アクセスする場合を
示す。

ＵＦ’ａ１３が、ファイルアクセスコマンド（ＲＥＡＤ
）３００を発行してアクセス依頼すると、プロセッサｌ
のクライアントファイル管理モジュール１０６は、ファ
イルアクセスコマンド（ＲＥＡＤ）３００に対応するア
クセス依頼メツセージ（ＲＥＡＤ）３０１を、自プロセ
ッサディスク内のファイル（Ａ）１２と、第１図のプロ
セッサ２のディスク２１内のファイル（Ａ）２２に送る
。

この場合、第１図のネットワーク４を介さないで済む自
プロセッサ内のファイル（Ａ）１２の方が先に処理され
る。そして、ファイル（Ａ）１２のファイルアクセスコ
マンド（ＲＥＡＤ）３００に対する処理結果を示すステ
ータス情報３０２が、ＵＰａ１３に送られ、アクセス応
答がなされる。

ＵＰａ１３がファイルアクセスコマンド（ＲＥＡＤ）３
００を発行したのと同時に、ＵＰｂ２３が、ＵＰａ　１
３と同一レコードに対する同様なファイルアクセスコマ
ンド（ＲＥＡＤ）３２０を発行したものとする。

すると、プロセッサ２内のクライアントファイル管理モ
ジュール１２６は、ＵＰｂ２３が発生したファイルアク
セスコマンド（ＲＥＡＤ）３２０に対応するアクセス依
頼メツセージ（ＲＥＡＤ）３２１を、同様に、自プロセ
ッサディスク内のファイル（Ａ）２２と、プロセッサｌ
のディスク内のファイル（Ａ）１２に送る。

この場合、自プロセッサ内のファイル（Ａ）２２の方が
先に処理される。そして、ファイル（Ａ）２２のファイ
ルアクセスコマンド（ＲＥＡＤ）３２０に対する処理結
果を示すステータス情報３２２が、ＵＰｂ２３に送られ
る。

ここでは、ファイル（Ａ）１２に対しては、ＵＰａ１３
がアクセスし、ファイル（Ａ）２２に対しては、ＵＰｂ
２３がアクセスしている状態が発生する。

この状態で、ファイル（Ａ）１２には、ＵＰｂ２３から
のファイルアクセスコマンド（ＲＥＡＤ）３２０に対応
するアクセス依頼メツセージ３２１が、一方、ファイル
（Ａ）２２には、ＵＰａ　１３がらのファイルアクセス
コマンド（ＲＥＡＤ）３００に対応するアクセス依頼メ
ツセージ３０１が到達する。この場合、ファイルアクセ
スコマンド３００．３２０の内容によっては、ハード的
には全く障害がなくても、第１図の説明において述べた
ような状態が発生する。

すなわち、ファイルアクセスコマンド３００．３２０が
、ファイル更新のためのリード（ＲＥＡＤ）コマンドで
あり、ファイルアクセス排他管理を行なうため、ＵＰａ
　１３がリード状態のファイル（Ａ）１２のレコードに
対するＵＰｂ２３のファイルアクセスコマンド（ＲＥＡ
Ｄ）３２０に対応するアクセス依頼メツセージ３２１は
、排他エラーとしてはねられ、受は付けられない。

同様に、ファイル（Ａ）２２に到達したＵＰａ　１３の
ファイルアクセスコマンド（ＲＥＡＤ）３００に対応す
るアクセス依頼メツセージ３０１も排他エラーとしては
ねられる。

二の状態で、ＵＰａ　１３、および、ＵＰｂ２３が書き
込み処理を行なうと、ファイル（Ａ’）　１２の対象レ
コードはＵＰ’ａ１３により、また、ファイル（Ａ）２
２の対象レコードはＵＰｂ２３により更新されるため、
ファイル（Ａ）１２とファイル（Ａ）２２の内容が食い
違うことになる。

このようなファイルの不整合状態の問題を解決するため
に、第１図における分散処理システムの各プロセッサは
、それぞれの多重ファイルからの応答データ間のチェッ
クを行ない、かつ、応答データ間での不一致を検出した
場合は、自プロセッサが、多重ファイルに対して発行し
たアクセス命令を解除する命令を発行し、その後、再び
、同じアクセス命令を発行する。

すなわち、ＵＰａ　１３を実行しているプロセッサｌの
クライアントファイル管理モジュール１０６は、ＵＰａ
１３が発生したファイルアクセスコマンド（ＲＥＡＤ）
３００に対応するファイル（Ａ）１２．２２からのアク
セス応答メツセージのステータス情報３０２，３０３が
食い違っていることにより、第２図で説明したリトライ
処理（１）３０４を実行し、アクセス依頼メツセージ（
ＲＥＡＤ）３０１を解除する解除依頼メツセージ（Ｆ　
ＲＥ　Ｅ）３０５を発行する。

この解除依頼メツセージ（ＦＲＥＥ）３０５により、Ｕ
Ｐａ　１３によるファイル（Ａ）１２の占有状態が解除
される。

同様に、クライアントファイル管理モジュール１２６は
、ＵＰｂ２３が発生したファイルアクセスコマンド（Ｒ
ＥＡＤ）３２０に対するファイル（Ａ）１２．２２から
のアクセス応答メツセージのステータス情報３２２．３
２３が食い違っていることにより、第２図におけるリー
トライ処理（１）３２４を実行し、アクセス依頼メツセ
ージ（ＲＥＡＤ）３２１を解除する解除依頼メツセージ
（ＦＲＥＥ）３２５を発行する。

この解除依頼メツセージ（ＦＲＥＥ）３２５により、フ
ァイル（Ａ）２２のＵＰｂ２３による占有状態が解除さ
れる。

これらの占有状態の解除が、応答メツセージ３０６．３
０７．３２６．３２７により、それぞれのクライアント
ファイル管理モジュール１０６．１２６に通知される。

そして、ファイル（Ａ）１２．２２の両ファイルとも占
有されていない状態で、ＵＰａ１３、ＵＰｂ２３が実行
されている各プロセッサ１．２のクライアントファイル
管理モジュール１８０６．１２６は、第２図で説明した
リトライ処理（２）３０８．３２８により、アクセス依
頼メツセージ（ＲＥＡＤ）３０１，３２１とそれぞれ同
じアクセス依頼メツセージ（ＲＥＡＤ）３０９．３２９
を再発行する。

以上のリトライ処理（１）３０４．３２４およびリトラ
イ処理（２）３０８．３２８は、アクセス処理が成功す
るまで繰り返される。

しかし、リトライ処理（２）３０８．３２８によ。

るアクセス依頼メツセージ（ＲＥＡＤ）３０９，３２９
の発行は、プロセッサ１．２が、独自のタイミングで行
なう、そのために、アクセス依頼メツセージ（ＲＥＡＤ
）３０９．３２９の発行のタイミングは自動的にずれ、
リトライ処理（２）３０８．３２８により発行されるア
クセス依頼メツセージ（ＲＥＡＤ）３０９．３２９に関
しては、その不整合状態の発生は自動的に回避される。

また、ＵＰａ１３、ＵＰｂ２３でのリトライ実行タイミ
ングをずらすため、リトライ処理（２）３０８．３２８
において、リトライコマンド（アクセス依頼メツセージ
（ＲＥＡＤ）３０９．３２９を発行する前に、それぞれ
にランダムな待ち時間をいれても良い。このことにより
、リトライ処理（２）３０８．３２８に基づくファイル
アクセスを、確実に実行することができる。

以上示した方法は、多重化されたファイルからの応答を
一定時間の間収集し、その結果に基づき多重ファイル間
の整合性をチェックする方法である。

これに対して、多重ファイルからの応答を一定時間では
なく、予め決められた多重度数分を収集する方法も可能
である。以下、この方法による本発明の第２の実施例を
説明する。

水弟２の実施例を行なうために、第１図で示した送信Ｓ
Ｉテーブル１０７、および、ファイル管理テーブル１１
０にファイルの多重度を示す多重度エリアを設定する。

第４図は、第１図における送信Ｓｌテーブルおよびファ
イル管理テーブルの構成の第２の実施例を示す説明図で
ある。

第４図（ａ）における送信Ｓｌテーブル４０７は、各行
４０７１〜４０７２に、第１図のＳＩエリア１０７１１
、タイマエリア１０７１２、個数エリア１０７１３、受
信メツセージエリア１０７１４に、多重度エリア４００
を付与して構成され、また、第４図（ｂ）におけるファ
イル管理テーブル４１０は、各行４１０１〜４１０２に
、第１図のＦＮＭエリア１１０１１．物理情報エリア１
１０１２、Ｓ　Ｉ工１，１７１１０１３ニ、多重度エリ
ア４０１を付与して構成されている。

ファイル管理テーブル４１０の多重度エリア４０１は、
各プロセッサにおいて、ファイルアロケート時に設定さ
れるものとする。

また、第１図におけるサーバファイル管理モジュール１
０９は、アクセス依頼に対するアクセス応答メツセージ
内に、ファイル管理テーブル４１Ｏの多重度エリア４０
１の内容を多重度情報として設定する。

一方、第１図のクライアントファイル管理モジュール１
０６は、０ＰＥＮコマンドに対応する応答メツセージ受
信時に、メツセージ内の多重度を、送信ＳＩ子テーブル
０７の多重度エリア４ｏ○に設定する。

この送信Ｓｌテーブル４０７とファイル管理テーブル４
１０を有する第２の実施例の分散処理システムでは、第
１図のクライアントファイル管理モジュール１０６は、
アクセス応答メツセージ受信時において、これら送信Ｓ
Ｉ子テーブル０７、および、ファイル管理テーブル４１
０に付与された多重度二リア４００．４０１に基づき、
受信メツセージエリアに格納したアクセス応答メツセー
ジ間の整合性をチェックする。

このように、ある一定の時間前に、必要な数分のアクセ
ス応答メツセージが返ってきた時点で、アクセス応答メ
ツセージ間の整合性のチェックを行なうことにより、第
２図のフローチャートで示した処理よりも効率の良いリ
トライチェック処理等を行なうことができる。

第５図は、第１図における分散処理システムの本発明に
係る処理動作の第２の実施例を示すフローチャートであ
る。

第４図における送信ＳＩ子テーブル０７、および、ファ
イル管理テーブル４１０を有する分散処理システムの動
作であり、特に、第１図に示すクライアントファイル管
理モジュール１０６が行なう処理フローを示す。

まず、クライアント管理モジュールは、ネットワークか
ら受信し、入力メツセージエリアに格納されたアクセス
応答メツセージを読みだしくステップ５０１）、送信Ｓ
エテーブルをチェックし、アクセス応答メツセージ内の
発生源情報部の値が、送信ＳＩ子テーブル発生源情報エ
リアに登録されているか否かを判定する（ステップ５０
２）。

登録されていない場合は、自プロセッサが発生したアク
セス依頼に対する応答ではないため、そのメツセージを
廃棄しくステップ５０３）、次のアクセス応答メツセー
ジを待つ。

登録されている場合は、このアクセス応答メツセージを
、送信ＳＩ子テーブル対応する（メツセージ内の発生源
情報部の内容が登録されている）行の受信メツセージエ
リアに格納する（ステップ５０４）。尚、この時、個数
エリアの値を一つ増加させる。

ここまでの処理は、第２図の第１の実施例におけるステ
ップ２０１〜２０４と同じである。

次に、送信ＳＩテーブル内の個数エリアの値、すなわち
、受信したアクセス応答メツセージの数と、第４図にお
ける多重度エリア４００の値とが一致するか否かを判定
する（ステップ５０５）。

受信したアクセス応答メツセージの数と、多重度エリア
の値とが一致する場合、すなわち、多重化ファイルの全
てから応答が戻ってきたならば、第２図におけるステッ
プ２０６と同じリトライチェック処理を行なう（ステッ
プ５０６）。

一致しない場合は、第２１１１のステップ２０５と同じ
タイムアウトチェックを行なう（ステップ５０７）。す
なわち、アクセス依頼メツセージ発生時にセットしたタ
イマがタイムアウトしているが否かを、第４図における
送信ＳＩ子テーブル０７のタイマエリア１０７１２に基
づき判定する。

タイムアウトしていない場合は、次のメツセージの受信
待ち状態に戻る。

タイムアウトの場合は、第４図の送信Ｓｌテーブル４０
７のリセット後（ステップ５０８）、障害処理を行ない
（ステップ５０９）、その後、ステップ５０６のリトラ
イチェック処理を行なう。

この障害処理では、第４図における送信ＳＩ子テーブル
０７の多重度エリアの値に、個数エリア１０７１３の値
を設定する。

このようにして、第２の実施例では、多重度数分の応答
メツセージを受信したタイミングで、リトライチェック
処理を行なうことができる。

このことにより、第１の実施例よりも、応答性が向上す
る。

次に、第１＠における分散処理システムの第３の実施例
を説明する。

末弟３の実施例では、第１図に示した配置において、プ
ロセッサｌのディスクｌｌ内のファイル（Ａ）１２から
の応答が戻ったタイミングで、ＵＰａ１３に制御を戻し
、かつ、多重ファイル間の整合性を保証する。

すなわち、第２図、および、第５図で示した、第１、第
２の実施例では、リトライチェック処理を、多重ファイ
ルからの応答が全て揃ったタイミングで行なっていた。

そのため、応答性の面で、次の問題が生じる。

例えば、第１図において、プロセッサｌ内で実行中のＵ
Ｐａ１３が、自プロセッサディスク１１と、プロセッサ
２のディスク２１とに多重化されたファイル（Ａ）１２
．２２をアクセスする場合、ＵＰａ　ｌ　３は、自プロ
セッサディスク１１のファイル（Ａ）１２をアクセスし
ているにもかかわらず、第１１および、第２の実施例で
は、アクセス応答がＵＰａ１３に戻るタイミングは、フ
ァイル（Ａ）２２の応答がネットワーク４を介して戻る
タイミングに合わされてしまう。

末弟３の実施例では、このような応答性の低下を防止す
るものである。

また、末弟３の実施例では、送信Ｓ１テーブル、および
、ファイル管理テーブルの構成は第４図に示す第２の実
施例と同一である。但し、多重化されたファイルの内の
一つを、競合発生時の優先ファイルとして使用する。

この優先ファイルの指定は、ファイル７０ケート時にな
っても良いし、また、ユーザが指定するのではなく、フ
ァイルオーブン時に応答を介してきた多重ファイルの内
から、そのファイルの属するプロセッサ番号の、例えば
、一番小さなものを優先ファイルとすることでも良い。

以下、末弟３の実施例の処理動作を、第６図に基づき説
明する。

第６図は、第１図における分散処理システムの本発明に
係る処理の第３の実施例を示すフローチャートである。

第１、第２の実施例と同様に、第１図におけるクライア
ントファイル管理モジュール１０６のアクセス応答メツ
セージ受信時の処理フローを示す図である。

第６図（ａ）は、受信したアクセス応答メツセージの読
みだしから、末弟３の実施例におけるリトライチェック
処理に至るまでの処理フローであり、第６図（ｂ）は、
末弟３の実施例におけるリトライチェック処理の処理フ
ロー、そして、第６図（ｃ）および（ｄ）は、それぞれ
、末弟３の実施例におけるリトライ処理（３）、（４）
の処理フローを示すものである。

第６図（ａ）に基づき、アクセス応答メツセージの読み
だしから、末弟３の実施例におけるリトライチェック処
理に至るまでの処理を説明する。

まず、クライアント管理モジュールは、ネットワークか
ら受信し、入力メツセージエリアに格納されたアクセス
応答メツセージを読みだしくステップ６０１）、送信Ｓ
Ｉ子テーブルチェックし、アクセス応答メツセージ内の
発生源情報部の値が、送信Ｓｔ子テーブル発生源情報エ
リアに登録されているか否かを判定する（ステップ６０
２）。

登録されていない場合は、自ブロセ５ツサが発生したア
クセス依頼に対する応答ではないため、そのメツセージ
を廃棄しくステップ６０３）、次のアクセス応答メツセ
ージを待つ。

ここまでの処理は、第２図、および、第５図における第
１、第２の実施例と同じである。

登録されている場合は、このアクセス応答メツセージが
、後述のリトライ処理（３）に対応するメツセージか否
かをチェックする（ステップ６ｏ４）。

リトライ処理（３）に対応するメツセージであれば、ス
テップ６０８に進む。

リトライ処理（３）に対応するメツセージでない場合は
、優先ファイル（Ａ）からの応答であるか否かを判断す
る（ステップ６０５）。

優先ファイル（Ａ）からの応答でなければ、後述のステ
ップ６０８に進み、優先ファイル（Ａ）からの応答であ
れば、そのメツセージを依頼先のユーザプログラム（こ
こでは、第１図のＵＰａ１３）に渡しくステップ６０６
）、リトライチェック処理モードとする（ステップ６０
７）。

次に、このメツセージのステータス情報を送信ＳＩ子テ
ーブル格納しくステップ６０８）、多重度数分の応答を
受信したか否かを判断する（ステップ６０９）。

多重度数分の応答を受信していれば、後述のステップ６
１３に進みリトライチェック処理を行ない、多重度数分
の応答を受信していなければ、タイムアウトしたか否か
を判断する（ステップ６１０）。

タイムアウトでなければ、ステップ６０１に戻り、次の
受信メツセージの読みだしを行なう。

タイムアウトであれば、送信ＳＩ子テーブルリセットし
て（ステップ６１１）、障害処理を行ない（ステップ６
１２）、リトライチェック処理６１３に移る。

尚、この障害処理では、第４図における送信Ｓ■子テー
ブル０７の多重度エリアの値に、個数エリア１０７１３
の値を設定する。

以上のステップ６０５〜６０７の処理により、重篤３の
実施例では、自プロセッサのファイルからの応答を受信
したタイミングで応答メツセージを依頼した第１図のＵ
Ｐａ　ｌ　３に制御を戻す。また、クライアントファイ
ル管理モジュールは、リトライチェックモードの間は、
他のユーザプログラムからのアクセスコマンドを受は付
けても、リトライチェックモー−が解除されるまで、そ
の処理実行を待つ。

すなわち、第ｉｌｌにおいて、優先ファイルであるファ
イル（Ａ）１２からのアクセス応答メツセージ受信時は
、ステップ６０１〜６０５における処理を進め、ステッ
プ６０６でアクセス応答メツセージをＵＰａ　１３に渡
して制御を戻し、その後、ステップ６０７以降の処理を
実行する。

しかし、優先ファイルでないファイル（Ａ）２２からの
アクセス応答メツセージの受信時は、ステップ６０６か
ら、ステップ６０８に移り、ステップ６０９における判
断処理を行なう。

ここで、多重度数分の応答を受信している状態であれば
、ステップ６１３のリトライチェック処理を実施する。

次に、第６図（ｂ）に基づき、重篤３の実施例における
リトライチェック処理を説明する。

このリトライチェック処理では、まず、受信した応答メ
ツセージが、後述のリトライ処理（３）に対応するメツ
セージか否かを判断する（ステップ６１４）。

リトライ処理（３）に対応するメツセージでなければ、
送信ＳＩ子テーブル登録されている応答メツセージのス
テータス情報が一致するか否かをチェックする（ステッ
プ６１５）。

一致の場合は、送信ＳＩ子テーブル該当する部分をリセ
ットしくステップ６１６）、さらに、ステップ６０７の
処理でセットしたリトライチェックモードを解除くリセ
ット）して（ステップ６１７）、リトライチェック処理
を終了する。

一方、ステップ６１５の処理において、アクセス応答メ
ツセージ間でステータス情報が、それぞれ、ＯＫ、ＮＧ
と食い違っていれば、送信ＳＩ子テーブルリセットして
（ステップ６１８）、後述のリトライ処理（３）を実施
する（ステップ６１９）。

また、ステップ６１４において、受信した応答メツセー
ジがリトライ処理（３）に対応するメッセ−ジであれば
、後述のリトライ処理（４）を行なう（ステップ６２０
）。

第６図（Ｃ）に基づき、木簡３の実施例におけるリトラ
イ処理（３）を説明する。

このリトライ処理（３）では、以下の処理を行なう。

まず、優先ファイルからの応答の結果（ＯＫまたはＮＧ
）を判断する（ステップ６２１）。

優先ファイルからの応答がＯＫの場合には（ステップ６
２２）、アクセス応答メツセージのトリガとなったコマ
ンドに対するアクセス依頼メツセージを、再度、第１図
の出力メツセージエリア１０５に格納して（ステップ６
２３）、第１図の通信管理モジュール１０２による送出
に基づき、ステップ６０１からの受信メツセージの処理
を行なう。

一方、優先ファイルからの比容がＮＧの場合には、第２
図のステップ２１２の処理で説明したリトライ処理（１
）を行なう（ステップ６２４）、すなわち、アクセス応
答メツセージのトリガとなった発行コマンドに対する状
態解除コマンド（ＦＲＥＥ、ＥＲＡＳＥ、ＣＬＯＳＥ等
）のアクセス依頼メツセージを、第１図の出力メツセー
ジエリア１０５に格納し、第１１！ｌの通信管理モジュ
ール１０２による送出に基づき、ステップ６０１からの
受信メツセージの処理を行なう。

このリトライ処理（３）により発生したリトライ処理依
頼メツセージに対する応答メツセージは、ステップ６０
４、並びに、ステップ６１４で確認され、ステップ６２
０のリトライ処理（４）を実行する。

第６ＷＩ（ｄ）に基づき、第３の実施例におけるリトラ
イ処理（４）を説明する。

まず、リトライ処理（３）における優先ファイルからの
応答がＯＫの時の応答メツセージの場合、すなわち、ス
テップ６２３の処理に対応する応答メツセージであり（
ステップ６２５）、かつ、アクセス応答メツセージのス
テータス情報がＮＧとなっていた全ファイルからの応答
メツセージのステータス情報がＯＫとなれば（ステップ
６２６）、ステップ６０７で設定したリトライチェック
モードを解除して（ステップ６２７）、処理を終了する
。

全ファイルからの応答メツセージのステータス情報がＯ
Ｋでない場合は、ステップ６２３に進み、再アクセス依
頼メツセージを、もう−度、出力メツセージエリアに格
納する。

一方、リトライ処理（３）における優先ファイルからの
応答がＮＧの時の応答メツセージの場合、すなわち、ス
テップ６２４の処理に対応する応答メツセージであり（
ステップ６２８）、状態解除依頼メツセージにより、ス
テータス情報がＯＫとなっていた全ファイルが解除され
れば（ステップ６２９）、ステップ６０７で設定したリ
トライチェックモードを解除しくステップ６３０）、第
２図におけ′るリトライ処理（２）を行なう（ステップ
６３１）、すなわ′ち、ファイルの不整合を引き起こし
た最初のアクセス依頼メツセージを、出力メツセージエ
リアに格納する。

また、ステップ６２９で、ステータス情報がＯＫとなっ
ていた全ファイルが解除されなければ、ステップ６２４
に進み一１再度、リトライ処理（１）を行なう。

このように、第３の実施例によれば、ファイルの不整合
が発生した場合も、多重ファイル内容は、全て、優先フ
ァイル内容に一致し、ファイル間の整合性が保証できる
。さらに、優先ファイルの応答が戻ったタイミングで、
ユーザプログラムに制御を戻し、多重ファイルの整合性
チェックによる応答性の低下を防止する。

次に、この第３の実施例による分散処理システムの動作
を、タイミングチャートを用いて説明する。

第７図は、第４図）二おける送信Ｓ−エテーブルとファ
イル管理テーブルを有する分散処理システムの本発明に
係る□処理動作の一実施例の処理動作を示すタイムチャ
ートである。

第７図（ａ）は、第１．第２の実施例によるタイムチャ
ートであり、第７図（ｂ）は、第３の実施例によるタイ
ムチャートである。

第１、および、第２の実施例では、第７図（ａ）に示す
ように、ＵＰａ１３からの依頼メッセージ７１に対する
ファイル（Ａ）１２．２２からの応答（応答メツセージ
７２．７３）の両方が戻ったタイミング７４でリトライ
チェック処理７５を行ない、リトライチェック処理７５
がＯＫであれば、ＵＰａ１３への制御の戻し７６を行な
う。

これに対し、第３の実施例では、第７図（ｂ）で示すよ
うに、まず、ファイル（Ａ、）１２を優先ファイルとす
る。そして、重篤３の実施例では、ＵＰａ１３が発生し
た依頼メツセージ７１に対する優先ファイル（Ａ）１２
からの応答メツセージ７２が戻ってきたタイミング７７
で、ＵＰａ１３への制御の戻し７８を行なう。

その後、ファイル（Ａ）２２からの応答メツセージ７３
が戻ってきたタイミングでリトライチェック７５を行な
う。

尚、リトライチェック７５が終了する前に、ＵＰａ１３
が発行したコマンド（ＷＲＩＴＥ）７９は、リトライチ
ェック７５終了後にアクセス依頼メツセージ７０として
、ファイル（Ａ）１２．２２に送出する。

このように、第３の実施例によれば、優先ファイルであ
る自プロセッサのディスク内のファイルの応答メツセー
ジが戻ったタイミングで、ユーザプログラムに制御を戻
し、多重ファイルの整合性チェックによる応答性の低下
を防止する。

尚、第３の実施例で示した多重ファイルからの応答メツ
セージのチェック方法、すなわち、まず、先着メツセー
ジをユーザプログラムに渡し、後着メツセージの受信時
に、先着メツセージとの整合性のチェックを行なう方法
は、プログラム、プリンタなどの各種資源を多重化した
場合にも、同様に、適用可能である。

以上、第１〜第７図を用いて説明したように、本第１〜
第３の実施例によれば、多重ファイルの不整合が発生し
た場合においても、その不整合を自動的に解除すること
ができる。

さらに、最初に受信したファイルの応答メツセージで、
ユーザプログラムに制御を戻し、その後で、ファイルの
整合性をチェックする。このことにより、多重ファイル
の整合性チェックによる応答性の低下を防止する。

尚、第１〜３の実施例で行なうリトライチェックは、フ
ァイル更新時に必要なチェックであり、例えば、ｒＲＥ
ＡＤ　　０ＮＬＹＪのモードでオープンしている場合は
不要である。従って、ファイルオープンモードを判定し
、更新モードでオープンされていない場合は、第１図の
クライアントファイル管理モジュール１０６で、リトラ
イチェック処理を行なわず、先に受信したアクセス応答
メツセージを、受信したタイミングで、ユーザプログラ
ムに渡してしまう方法を取ることも可能である。この際
、後から受信したアクセス応答メツセージに対しては、
これを識別し、廃棄する処理を取る。この方法により、
ファイル更新モード以外でアクセスする場合の応答性を
向上させることができる。

このように、特に第３の実施例によれば、多重ファイル
間に発生する不整合状態を、ファイルアクセス応答を低
下させることなくチェックし、不整合状態発生時には、
ユーザプログラム側に、それを意識させることなく、自
動的に、その不整合状態を解消することが可能となる。

このことにより１重要なファイルを任意の多重度で多重
化でき、しかも、その際、アクセス応答性が低下するこ
とがないため、ファイルの信頼性が向上するのみでなく
、ユーザに取っての使い勝手も向上する。

【発明の効果］ 本発明によれば、任意の多重度に多重化された多重ファ
イルに対し、多重ファイル間に不整合が発生した場合で
も、ファイルアクセスもている処理を中断することなく
、不整合状態を自動的に回復し、かつ、多重フ′アイル
間に発生する不整合状態の検出処理を、ファイルアクセ
ス応答性能を低下させることなく行ない、分散処理シス
テムの処理性能と信頼性を向上させることが可能である
。

【図面の簡単な説明】

第１図は本発明を施した分散処理システムの本発明に係
る構成の第１の実施例を示すブロック図、第２図は第１
図における分散処理システムの本発明に係る処理動作の
第１の実施例を示すフローチャート、第３図は第１図に
おける分散処理システムの本発明に係る処理動作の一実
施例を示すタイムチャート、第４図は第１図における送
信ＳＩ子テーブルよびファイル管理テーブルの構成の第
２の実施例を示す説明図、第５図は第１図における分散
処理システムの本発明に係る処理動作の第２の実施例を
示すフローチャート、第６ＦＭは第１図における分散処
理システムの本発明に係る処理の第３の実施例を示すフ
ローチャート、第７図は第４！１１における送信ＳＩ子
テーブルファイル管理テーブルを有する分散処理システ
ムの本発明に係る処理動作の一実施例の処理動作を示す
タイムチャートである、 １〜３：プロセッサ、４：ネットワーク、５：メッセー
ジ、１０：ターミナル、１１：ディスク。 １２：ファイル（Ａ）、１３ニユーザブログラム（ＵＰ
ａ）、２０：ターミナル、２１：ディスク。 ２２：ファイル（Ａ）、２３ニユーザブログラム（ＵＰ
ｂ）、３０：ターミナル、３１：ディスク。 ５１：フラグ、５２二内容コード、５３：発生源アドレ
ス、５４：通番、５５：発生源情報、５６：データ部、
５７：ＦＣ３，５８：フラグ、７０：アクセス依頼メツ
セージ、７１：依頼メツセージ。 ７２〜７３；応答メツセージ、７４：タイミング。 ７５：リトライチェック処理、７６：戻し制御。 ７７：タイミング、７８：戻し制御、７９：コマンド（
ＷＲＩＴＥ）、ｌ　０１　：ネットワークインタフェー
ス、１０２：通信管理モジュール、　　１０３：内容コ
ードテーブル、１０４：入カメッセージエリア、１０５
：出力メッセージエリア、１０６：クライアントファイ
ル管理モジュール、１０７：送信ＳＩ子テーブル１０８
ニユーザブログラム実行エリア、１０９：サーバファイ
ル管理モジュール、１１０：ファイル管理テーブル、１
１１：ディスクインタフェース、　３ＯＯ：ファイルア
クセスコマンド（ＲＥＡＤ）、　３０１　：アクセス依
頼メツセージ（ＲＥＡＤ）、３０２〜３０３：ステータ
ス情報、３０４：リトライ処理（１）、３０５：解除依
頼メツセージ（ＦＲＥＥ）、３０６〜３０７：応答メツ
セージ、３０８：リトライ処理（２）。 ３０９：アクセス依頼メツセージ（ＲＥＡＤ）。 ３２０：ファイルアクセスコマンド（ＲＥＡＤ）。 ３２１：アクセス依頼メツセージ（ＲＥＡＤ）。 ３２２〜３２３：ステータス情報、３２４：リトライ処
理（１）、３２５：解除依頼メツセージ（ＦＲＥＥ）、
３２６〜３２７：応答メツセージ。 ３２８：リトライ処理（２）、３２９：アクセス依頼メ
ツセージ（ＲＥＡＤ）、４００〜４０１：多重度エリア
、４０７：送信ＳＩ子テーブル４１０：ファイル管理テ
ーブル、５２１：ファイルネーム部、５２２：ＩＤ部、
５５１：プロセッサ番号情報部、５５２：タスク番号情
報部、５５３：通番情報部、１０７１〜１０７２：行、
１１０１〜１１０２：行、４０７１〜４０７２：行、４
１０１〜４１０２：行、１０７１１：＊先駆情報エリア
。 １０７１２：タイマエリア、１０７１３：個数エリア、
１０７１４：受信メツセージエリア、１１０１１：ファ
イルネームエリア１１０１２：物理情報エリア、１１０
１３１生源情報エリア。 第４図 ｆａ） 第　　５　　図 第　　６　　図（その３） （ｃ） 第　　６　　図（その４） （ｄ） 第　　７　　図（その１） （ａ］ 第　　７　　図（その２） ｆｂ）

Claims (1)

1. 【特許請求の範囲】 １、複数のプロセッサを共通伝送媒体を介して接続し、
   上記複数のプロセッサは、それぞれのプロセッサに多重
   に配置したリソースから発生する多重データを用いて処
   理を進める分散処理システムの多重データ処理方法にお
   いて、上記複数のプロセッサは、上記多重データの最初
   に受信したデータを用いて上記処理を進め、以後受信し
   た多重データを用いて、上記最初に受信したデータの整
   合性のチェックを行なうことを特徴とする分散処理シス
   テムの多重データ処理方法。 ２、請求項１に記載の分散処理システムの多重データ処
   理方法において、上記複数のプロセッサのそれぞれに接
   続した外部記憶媒体のそれぞれにファイルを多重に配置
   し、上記複数のプロセッサの任意のプロセッサは、該多
   重に配置したファイルに対するアクセス依頼を発生し、
   かつ、該アクセス依頼に対応する上記多重に配置したフ
   ァイルからの多重応答データを受信し、そして、該多重
   応答データの最初に受信した応答データを用いて上記処
   理を進め、以後受信した多重応答データを用いて、上記
   最初に受信した応答データの整合性のチェックを行なう
   ことを特徴とする分散処理システムの多重データ処理方
   法。 ３、請求項２に記載の分散処理システムの多重データ処
   理方法において、上記アクセス依頼を発生したプロセッ
   サは、上記多重応答データ間のチェックが終了するまで
   、次のファイルアクセス依頼を発生しないことを特徴と
   する分散処理システムの多重データ処理方法。 ４、請求項３に記載の分散処理システムの多重データ処
   理方法において、上記応答データの整合性のチェックで
   、上記応答データ間に不整合を検出した場合は、上記ア
   クセス依頼を発生したプロセッサは、上記アクセス依頼
   により生じたファイル状態を解除する命令を発行する第
   １のリトライ処理を行ない、該第１のリトライ処理によ
   る上記ファイル状態の解除後、再び、上記アクセス依頼
   を発生する第２のリトライ処理を行ない、上記応答デー
   タ間の不整合がなくなるまで、上記第１のリトライ処理
   、および、第２のリトライ処理を繰り返すことを特徴と
   する分散処理システムの多重データ処理方法。 ５、請求項４に記載の分散処理システムの多重データ処
   理方法において、上記アクセス依頼を発生したプロセッ
   サは、上記第１のリトライ処理後、上記第２のリトライ
   処理を、予め設定された任意の時間ずらして実行するこ
   とを特徴とする分散処理システムの多重データ処理方法
   。 ６、請求項４、もしくは、請求項５のいずれかに記載の
   分散処理システムの多重データ処理方法において、上記
   アクセス依頼を発生したプロセッサは、上記多重ファイ
   ルからの全応答データを収集して、該収集した全応答デ
   ータ間の整合性のチェック、および、上記第１のリトラ
   イ処理と第２のリトライ処理による上記応答データ間の
   整合性の確定後に、上記処理を行なうことを特徴とする
   分散処理システムの多重データ処理方法。 ７、請求項４〜６のいずれか一つに記載の分散処理シス
   テムの多重データ処理方法において、上記アクセス依頼
   を発生したプロセッサは、予め任意に設定した時間内に
   収集した上記多重ファイルからの全応答データ間の整合
   性のチェックに基づき、上記第１のリトライ処理、およ
   び、第２のリトライ処理を行なうことを特徴とする分散
   処理システムの多重データ処理方法。 ８、請求項７に記載の分散処理システムの多重データ処
   理方法において、上記アクセス依頼を発生したプロセッ
   サは、上記予め任意に設定した時間内に、上記多重ファ
   イルからの全応答データを収集できない場合、上記予め
   任意に設定した時間内に収集した応答データを、上記整
   合性のチェックの対象に限定する障害処理を行ない、該
   障害処理の後に、上記整合性のチェック、および、上記
   第１のリトライ処理と第２のリトライ処理を行なうこと
   を特徴とする分散処理システムの多重データ処理方法。 ９、請求項４に記載の分散処理システムの多重データ処
   理方法において、上記アクセス依頼を発生したプロセッ
   サは、上記第１のリトライ処理として、上記アクセス依
   頼がファイル更新時のリードコマンドの場合は、該リー
   ドコマンドの排他管理によるレコードの占有状態を解除
   するフリーコマンドを、上記アクセス依頼が追加コマン
   ドの場合は、該追加コマンドにより追加したレコードを
   削除するイレースコマンドを、上記アクセス依頼が排他
   オープンコマンドの場合は、該排他オープンコマンドに
   よるファイルの占有状態を解除するクローズコマンドを
   発行することを特徴とする分散処理システムの多重デー
   タ処理方法。 １０、請求項４〜６のそれぞれに記載の分散処理システ
   ムの多重データ処理方法において、上記複数のプロセッ
   サは、アクセス依頼メッセージ、および、アクセス応答
   メッセージのメッセージを上記上記伝送媒体へブロード
   キャストし、該メッセージのやり取りにより分散処理を
   行ない、上記複数のプロセッサのそれぞれは、自プロセ
   ッサから他プロセッサへの上記メッセージの上記伝送媒
   体へのブロードキャスト、および、上記伝送媒体へブロ
   ードキャストされた上記メッセージから、自プロセッサ
   に関連するメッセージの取り込みを行なう通信管理モジ
   ュールと、該通信管理モジュールで取り込んだ上記メッ
   セージを、該メッセージを処理するユーザプログラムに
   渡し、かつ、該ユーザプログラムからのファイルアクセ
   ス命令に基づき、上記アクセス依頼メッセージを生成し
   、上記通信管理モジュールに送出するクライアントファ
   イル管理モジュールと、該クライアントファイル管理モ
   ジュールが上記通信管理モジュールに送出したメッセー
   ジ情報を格納する送信情報格納手段とを有し、上記アク
   セス依頼を発生したプロセッサは、上記クライアントフ
   ァイル管理モジュールを用いて、上記通信管理モジュー
   ルを介して上記伝送媒体に上記メッセージを送出すると
   同時に、上記整合性のチェックに用いる予め任意に設定
   した収集時間を上記送信情報格納手段に格納し、そして
   、該送信情報格納手段に格納した時間に基づき、上記多
   重ファイルからの全応答データ間の整合性のチェック、
   および、上記第１のリトライ処理と第２のリトライ処理
   を行なうことを特徴とする分散処理システムの多重デー
   タ処理方法。