JPH08180018A - 分散処理システム及び分散処理方法 - Google Patents

Abstract

(57)【要約】 【目的】 構成が単純な分散処理システム及び分散処理
方法を提供する。 【構成】 生成手段３が、他のノードに依頼すべきジョ
ブ２を生成する。付加手段４が、ジョブ２の手続きの実
行のための補助情報をジョブ２に付加する。依頼手段６
あ、通信手段５及び通信媒体１を通じてジョブ２を他の
ノードに依頼する。他のノードでは、受任手段７がジョ
ブを受任するか否か決定する。受任したノードでは、準
備手段８が補助情報に基づいてジョブ２実行の準備を行
う。この準備は、例えば非実行形態の手続きを実行形態
に変換したり、所定の環境の設定などである。準備の
後、実行手段９がジョブ２に含まれる手続き（命令）を
実行する。事後処理手段１０が、実行結果をジョブ２で
指示されたように扱うが、典型的には要求先（依頼元）
に返送する。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、複数のノードが通信媒
体を介して接続された分散処理システム及び分散処理方
法の改良に関するものである。

【０００２】

【従来の技術】近年、複数のノード（コンピュータ）が
通信媒体を介して接続された分散処理システム（ネット
ワーク）が広く普及しつつある。このような分散処理シ
ステムでは、ノード間でジョブを依頼しあって各種資源
の有効活用を図っている。従来、ノード間でのジョブの
依頼では、依頼側ノードは被依頼側ノードに対してジョ
ブの内容をなす命令と命令の実行において用いるデータ
を送信して依頼し、受任した側のノードは、ジョブの命
令を実行し結果を依頼側ノードに返送していた（分散処
理方法）。

【０００３】このような従来の分散処理システム及び分
散処理方法では、ジョブは依頼側から一方的に依頼され
ていた。また、複数のジョブを他のノードに連続的に依
頼する場合、依頼はジョブごとに行われ、一つのジョブ
の実行が済むごとに実行結果が一旦依頼元のノードに返
され、依頼元のノードはこの結果を受領してから後続す
るジョブを順次他のノードに依頼していた。

【０００４】

【発明が解決しようとする課題】しかしながら、従来の
分散処理システム及び分散処理方法では、被依頼側ノー
ドは、依頼されるジョブの実行に必要な情報を有してい
る必要があった。例えば、ジョブが、特定の高級言語に
よって記述されたソースコードの場合、このジョブを実
行するノードは、当該言語のコンパイラを有していなけ
ればならない。このため、従来では、被依頼側ノードが
必要な情報を有しているかを依頼側ノードが予めデータ
として保持しておくか、その都度確認するという繁雑な
構成が必要であった。

【０００５】また、どのノードにジョブを依頼するかを
依頼側のノードが決定していたため、依頼が一部のノー
ドに集中し、結果応答までの応答性を著しく損なうとい
った問題も発生する。さらに、従来では、連続する複数
のジョブでもそれぞれ別個のノードに、結果返信を待っ
てから依頼していたため、通信媒体上のボトルネックが
発生しやすく、繁雑なジョブの状態管理が必要であっ
た。

【０００６】本発明は、上記のような従来技術の問題点
を解決するために提案されたもので、その目的は、構成
が単純な分散処理システム及び分散処理方法を提供する
ことである。また、本発明の他の目的は、処理効率の優
れた分散処理システム及び分散処理方法を提供すること
である。

【０００７】

【課題を解決するための手段】上記の目的を達成するた
め、請求項１の分散処理システムは、通信媒体によって
接続された複数のノードを含む分散処理システムにおい
て、各ノードが、前記通信媒体を通じて他のノードと通
信するための通信手段と、他のノードに依頼すべきジョ
ブを生成する生成手段と、前記ジョブに、ジョブの命令
の実行のための補助情報を付加する付加手段と、前記ジ
ョブを前記通信手段を通じて他のノードに送信して実行
を依頼する依頼手段と、他のノードから送信されたジョ
ブを受任する受任手段と、受任したジョブの前記補助情
報に基づいて、当該ジョブの実行の準備を行う準備手段
と、ジョブの命令を実行する実行手段と、前記実行の結
果を処理する事後処理手段と、を有することを特徴とす
る。

【０００８】また、請求項２の発明は、請求項１記載の
分散処理システムにおいて、前記受任手段は、他のノー
ドから送信されてきたジョブを受任するか否かを決定す
るように構成されたことを特徴とする。

【０００９】また、請求項３の発明は、請求項２記載の
分散処理システムにおいて、前記依頼手段は、前記ジョ
ブを全部又は一部の前記ノードに送信するように構成さ
れ、前記受任手段は、ジョブが送信されたノードにおい
て、送信されたジョブを受任できると決定したときは、
当該ジョブを送信した依頼側ノードに仮承諾を返信する
ように構成され、前記依頼手段は、依頼側ノードにおい
て、最早の前記仮承諾を返信したノードに正式依頼を送
信することによってジョブの依頼を行うように構成され
たことを特徴とする。

【００１０】また、請求項４の発明は、請求項１記載の
分散処理システムにおいて、前記生成手段は、所定の場
合に複数のジョブからなる複合ジョブを生成するように
構成され、前記事後処理手段は、前記複合ジョブを受任
したノードにおいて、複合ジョブに含まれる各ジョブの
うち当該ノードが実行すべきジョブの実行後、所定の場
合に残余のジョブを他のノードに依頼するように構成さ
れたことを特徴とする。

【００１１】また、請求項５の発明は、請求項１記載の
分散処理システムにおいて、前記補助情報が、非実行形
態の命令を実行形態の命令に変換するための手順を示す
情報であることを特徴とする。

【００１２】また、請求項６の発明は、請求項１記載の
分散処理システムにおいて、前記補助情報が、スクリプ
トの実行環境を表す情報であることを特徴とする。

【００１３】また、請求項７の分散処理方法は、通信媒
体によって接続された複数のノードを含む分散処理シス
テムにおいて、各ノードが、前記通信媒体を通じて他の
ノードと通信するための通信のステップと、他のノード
に依頼すべきジョブを生成する生成のステップと、前記
ジョブに、ジョブの命令の実行のための補助情報を付加
する付加のステップと、前記ジョブを前記通信のステッ
プを通じて他のノードに送信して実行を依頼する依頼の
ステップと、他のノードから送信されたジョブを受任す
る受任のステップと、受任したジョブの前記補助情報に
基づいて、当該ジョブの実行の準備を行う準備のステッ
プと、ジョブの命令を実行する実行のステップと、前記
実行の結果を処理する事後処理のステップと、を行うこ
とを特徴とする。

【００１４】また、請求項８の発明は、請求項７記載の
分散処理方法において、前記受任のステップでは、他の
ノードから送信されてきたジョブを受任するか否かを決
定することを特徴とする。

【００１５】また、請求項９の発明は、請求項８記載の
分散処理方法において、前記依頼のステップでは、前記
ジョブを全部又は一部の前記ノードに送信し、前記受任
のステップでは、ジョブが送信されたノードにおいて、
送信されたジョブを受任できると決定したときは、当該
ジョブを送信した依頼側ノードに仮承諾を返信し、前記
依頼のステップでは、依頼側ノードにおいて、最早の前
記仮承諾を返信したノードに正式依頼を送信することに
よってジョブの依頼を行うことを特徴とする。

【００１６】また、請求項１０の発明は、請求項７記載
の分散処理方法において、前記生成のステップでは、所
定の場合に複数のジョブからなる複合ジョブを生成し、
前記事後処理のステップでは、前記複合ジョブを受任し
たノードにおいて、複合ジョブに含まれる各ジョブのう
ち当該ノードが実行すべきジョブの実行後、所定の場合
に残余のジョブを他のノードに依頼することを特徴とす
る。

【００１７】また、請求項１１の発明は、請求項７記載
の分散処理方法において、前記補助情報が、非実行形態
の命令を実行形態の命令に変換するための手順を示す情
報であることを特徴とする。

【００１８】また、請求項１２の発明は、請求項７記載
の分散処理方法において、前記補助情報が、スクリプト
の実行環境を表す情報であることを特徴とする。

【００１９】

【作用】上記のような構成を有する本発明は、次のよう
な作用を有する。すなわち、請求項１，７の分散処理シ
ステムでは、あるノードで、他のノードに依頼すべきジ
ョブが生成される。ジョブは、実行すべき手続きと実行
に用いるデータを含む。ジョブには、ジョブの手続きの
実行のための補助情報が付加される。

【００２０】ジョブは通信媒体を通じて他のノードに送
られる。ジョブを受任したノードでは補助情報に基づい
てジョブ実行の準備が行われ命令が実行される。実行結
果はジョブで指示されたように扱われるが、典型的には
要求先に返送される。

【００２１】このように請求項１，７の発明によれば、
ジョブとともに補助情報が送信されるので、各ノードが
処理可能なジョブの種類を依頼側で判断することが不要
になり、構成が単純化される。

【００２２】また、請求項２，８の発明では、被依頼側
ノードが依頼されたジョブを受任するか否かを、自ノー
ドの負荷などに基づいて決定する。このため、一部のノ
ードへのジョブの集中が解決し、全体の処理効率が向上
する。

【００２３】また、請求項３，９の発明では、被依頼側
ノードのうちジョブを受任できるものが仮承諾を依頼側
ノードに返信し、依頼側ノードは最早の仮承諾を返信し
た被依頼側ノードに正式依頼を送信することによってジ
ョブの依頼を行う。このような請求項３，９の発明によ
れば、各ノードでの処理が異なることがないので、構成
が単純化できる。

【００２４】また、請求項４，１０の発明では、実行す
べき処理が複数のジョブから成る場合には、受任したノ
ードから他のノードへ改めて依頼される。このため、依
頼側ノードが各ジョブごとに依頼の処理を繰り返す必要
がなくなり、処理効率が向上する。

【００２５】また、請求項５，１１の発明では、前記補
助情報が、非実行形態の命令を実行形態の命令に変換す
るための手順を示す情報であるので、ジョブの手続き
（命令）が実行形態であるか非実行形態であるかを問わ
ず他のいずれのノードに依頼することもできる。このた
め、全体の処理効率が向上する。また、被依頼側がこの
ような手順を有するか否かの有無を依頼側で確認する必
要がないので、構成が単純となる。

【００２６】また、請求項６，１２の発明では、前記補
助情報が、スクリプトの実行環境を表す情報であるの
で、スクリプトの実行環境が被依頼側に存在するか否か
を依頼側が確認する必要がなく、構成が単純化される。

【００２７】

【実施例】次に、本発明の実施例について図面に従って
具体的に説明する。なお、後述する実施例はコンピュー
タ上に実現され、実施例の各機能は所定の手順（プログ
ラム）がこのコンピュータを制御することで実現され
る。

【００２８】本明細書における各「手段」ないし「部」
は実施例の各機能に対応する概念で、必ずしも特定のハ
ードウェアやソフトウェア・ルーチンに１対１には対応
しない。同一のハードウェア要素が場合によって異なっ
た手段を構成する。例えば、コンピュータはある命令を
実行するときにある手段となり別の命令を実行するとき
は別の手段となりうる。また、一つの手段がわずか１命
令によって実現される場合もあれば多数の命令によって
実現される場合もある。

【００２９】したがって、本明細書では、以下、実施例
の各機能を有する仮想的回路ブロック（手段）を想定し
て実施例を説明する。但し、コンピュータの使用は一例
であり、本発明の機能の全部又は一部は、可能ならば、
カスタムチップ（専用の集積回路）のような電子回路上
に実現してもよい。

【００３０】実施例に用いられるコンピュータは、一般
には、ＣＰＵ（中央演算処理装置）と、ＲＡＭ（随時書
込読出型記憶素子）からなる主記憶装置とを有する。ま
た、前記コンピュータの規模は自由であり、パーソナル
コンピュータ・スモールコンピュータ・ワークステーシ
ョン・メインフレームなど、いかなる規模のものを用い
てもよい。

【００３１】また、前記コンピュータのハードウェア
は、典型的には、キーボードやマウスなどの入力装置
と、ハードディスク装置などの外部記憶装置と、ＣＲＴ
表示装置やプリンタ印字装置などの出力装置と、必要な
入出力制御回路を含む。

【００３２】但し、前記コンピュータのハードウェア構
成は自由であり、本発明が実施できる限り、上記の構成
要素の一部を追加・変更・除外してもよい。例えば、Ｃ
ＰＵの種類は自由であり、ＣＰＵを複数同時に用いた
り、単一のＣＰＵをタイムシェアリング（時分割）で使
用し、複数の処理を同時平行的に行ってもよい。

【００３３】また、他の入力装置（例えば、タッチパネ
ル・ライトペン・トラックボールなどのポインティング
デバイスや、デジタイザ・イメージ読取装置やビデオカ
メラなどの画像入力装置・音声識別装置・各種センサな
ど）を用いてもよい。また、他の外部記憶装置（例え
ば、フロッピーディスク装置・ＲＡＭカード装置・磁気
テープ装置・光学ディスク装置・光磁気ディスク装置・
バブルメモリ装置・フラッシュメモリなど）を用いても
よい。また、他の出力装置（例えば、液晶表示装置・プ
ラズマディスプレイ装置・ビデオプロジェクター・ＬＥ
Ｄ表示装置・音響発生回路・音声合成回路など）を用い
てもよい。

【００３４】また、前記コンピュータにおいて実施例を
実現するためのソフトウェアの構成としては、典型的に
は、実施例の各機能を実現するためのアプリケーション
プログラムが、ＯＳ（オペレーティングシステム）上で
実行される態様が考えられる。また、実施例を実現する
ためのプログラムの態様としては、典型的には、高級言
語やアセンブラからコンパイル（翻訳）された機械語が
考えられる。但し、前記コンピュータのソフトウェア構
成も自由であり、本発明が実施できる限り、ソフトウェ
ア構成を変更してもよい。例えば、必ずしもＯＳを用い
る必要はなく、また、プログラムの表現形式も自由であ
り、ＢＡＳＩＣのようなインタプリタ（逐次解釈実行
型）言語を用いてもよい。

【００３５】また、プログラムの格納態様も自由であ
り、ＲＯＭ（読出し専用メモリ）に格納しておいてもよ
く、また、ハードディスク装置のような外部記憶装置に
格納しておき、コンピュータの起動時や処理の開始時に
主メモリ上にロード（読み込み）してもよい。また、プ
ログラムを複数の部分に分割して外部記憶装置に格納し
ておき、処理内容に応じて必要なモジュールのみを随時
主メモリ上にロード（読み込み）してもよい。さらに、
プログラムの部分ごとに異なった態様で格納してもよ
い。

【００３６】また、本実施例における各手順の各ステッ
プは、その性質に反しない限り、実行順序を変更し、複
数同時に実行し、また、実行ごとに異なった順序で実行
してもよい。このような順序の変更は、例えば、ユーザ
が実行可能な処理を選択するなどメニュー形式のインタ
ーフェース手法によって実現することができる。

【００３７】また、本明細書における「入力」は、本来
の情報の入力のみならず、情報の入力と密接に関連する
他の処理を含む。このような処理は、例えば、入力内容
のエコーバックや修正・編集である。また、「入力」
は、必ずしもコンピュータ外部からの入力には限定され
ず、所定のメモリ領域又はディスク装置から情報を読み
出すことによっても行われる。また、本明細書における
「出力」は、本来の情報の出力のみならず、情報の出力
と密接に関連する他の処理を含む。このような処理は、
例えば、出力すべき範囲の入力や、画面スクロールの指
示である。また、「出力」は、必ずしもコンピュータ外
部への出力には限定されず、所定のメモリ領域又はディ
スク装置に情報を書き込むことによっても行われる。な
お、対話的入出力手順によって入力と出力を一体的操作
によって実現してもよく、このような一体的操作によっ
て、選択・指定・特定などの処理を行ってもよい。

【００３８】また、本明細書におけるデータ（情報）や
データの格納手段は前記コンピュータ上においていかな
る態様で存在してもよい。例えば、データのハードウェ
ア上の所在部分は、主記憶装置・外部記憶装置・ＣＰＵ
のレジスタやキャッシュメモリなどいかなる部分でもよ
い。また、データの保持態様も自由である。例えば、デ
ータは、ファイル形式で保持されるのみならず、メモリ
やディスクなどの記憶装置を物理的アドレスで直接アク
セスすることによって実現してもよい。また、データの
表現形式も自由で、例えば、文字列を表すコードの単位
は、文字単位でも単語単位でもよい。また、データは必
要とされる一定時間だけ保持されれば十分で、その後消
滅してもよく、保持時間の長短は自由である。また、辞
書データのように当面変更されない情報は、ＲＯＭに格
納してもよい。

【００３９】また、本明細書において、特定の情報への
言及は確認的で、言及されない情報の存在を否定するも
のではない。すなわち、本発明の動作では、動作に必要
な一般的な情報やその格納領域、例えば、各種ポイン
タ、スタック、カウンタ、フラグ、パラメータ、ワーク
エリア、バッファなどが適宜用いられる。

【００４０】実施例の各部分が処理に要する情報は、特
に記載がない場合、当該情報を保持している他の部分か
ら獲得される。このような情報の獲得は、例えば、当該
情報を格納している変数やメモリをアクセスすることに
よって実現することができる。なお、情報の消去・抹消
は、当該情報の内容自体を必ずしも記憶領域から現実に
削除せず、消去を表すフラグを設定するなど、情報の意
味付けの変更によって行うことができる。

【００４１】（１）実施例の構成 本実施例は、通信媒体によって接続された複数のノード
を含む分散処理システム及びこの分散処理システムにお
ける分散処理方法であり、請求項１〜１２に相当する。
本実施例の目的は、構成が単純な分散処理システム及び
分散処理方法を提供することである。また、本実施例の
他の目的は、処理効率の優れた分散処理システム及び分
散処理方法を提供することである。

【００４２】まず、図１は本実施例の分散処理システム
において通信媒体１に接続されたノードの一つについ
て、その構成を示す機能ブロック図である。各ノード
は、図１に示すように、他のノードに依頼すべきジョブ
２を生成する生成手段３と、前記ジョブ２に、ジョブ２
の手続きの実行のための補助情報を付加する付加手段４
と、ジョブ２を通信手段５及び通信媒体１を通じて他の
ノードに送信して実行を依頼する依頼手段６と、を有す
る。また、各ノードは、他のノードからジョブ２を受任
する受任手段７と、受任したジョブ２の前記補助情報に
基づいて、当該ジョブ２を実行するための準備を行う準
備手段８と、ジョブの命令を実行する実行手段９と、前
記実行の結果を処理する事後処理手段１０と、を有す
る。

【００４３】（２）実施例の作用及び効果 上記のような構成を有する本実施例は次のような作用を
有する。

【００４４】［概略的作用］図２は、本実施例における
ジョブの依頼とジョブの実行の手順の一例を示すフロー
チャートである。すなわち、本実施例の分散処理システ
ム及び分散処理方法では、あるノードで、他のノードに
依頼すべきジョブ２が生成される（ステップ２１）。ジ
ョブ２は、実行すべき手続きと実行に用いるデータを含
む。ジョブ２には、ジョブ２の手続きの実行のための補
助情報が付加される（ステップ２２）。ジョブ２は通信
手段５及び通信媒体１を通じて他のノードに依頼される
（ステップ２３）。ジョブ２を受任したノードでは（ス
テップ２４）、補助情報に基づいてジョブ２実行の準備
が行われる（ステップ２５）。この準備は、例えば非実
行形態の手続きを実行形態に変換したり、所定の環境の
設定などである。準備の後、ジョブ２に含まれる手続き
（命令）が実行される（ステップ２６）。実行結果はジ
ョブ２で指示されたように扱われるが（ステップ２
７）、典型的には要求先（依頼元）に返送・受信される
（ステップ８７）。

【００４５】［ジョブの生成］まず、各ノードにおい
て、生成手段３が他のノードに依頼すべきジョブ２を生
成する。依頼すべきジョブ２は、明示的に実行依頼を示
したアプリケーション・プログラム又はスケジューラの
動作に基づいて内容や属性が決定される。

【００４６】ここで、図３はジョブ２の生成の手順を示
すフローチャート、図４は生成されるジョブ２ごとのデ
ータ構造を示す。すなわち、各ジョブ２はこの図４に示
すようにヘッダ部、手続き部、データ部から構成され
る。このうちヘッダ部はジョブ２全体の属性を示す形式
的情報、手続き部はジョブ２の内容として実行されるべ
き命令群、データ部は手続きの実行に要するデータであ
り、必要な場合にセットされる。

【００４７】ここで、図５は、ヘッダ部のデータ構造を
示す図である。ジョブ２の生成では、まず、このうち
「手続きの属性」が決定される。「手続きの属性」と
は、手続きがロードモジュールのような実行形態である
か、ソースプログラムやスクリプトのような非実行形態
であるかといった種類と、処理に必要な情報が付属して
いるか、また、処理に必要な情報が直前の手続きの結果
を使用するかどうかといった各種種別を示し、実際には
所定のフラグをセットすることにより表現される（図
３）。

【００４８】例えば、実行形態（ロードモジュール）の
場合はＥｘｅ（ステップ３１，３２）、ソースプログラ
ムの場合はＳｒｃ（ステップ３４，３５）、スクリプト
の場合はＣｍｄなどのフラグがセットされる（ステップ
３８，３９）。また、ジョブ２に何らかの情報が付属し
ている場合は（ステップ４２）ｄａｔａ（ステップ４
３）、ジョブ２の処理に直前の手続きの結果を情報とし
て使用する場合は（ステップ４４）ｃｏｎｔ（ステップ
４５）などのフラグがセットされる。

【００４９】なお、付加手段４は、ジョブ２の手続きの
実行のための補助情報をジョブ２に付加する。例えば、
ジョブ２の命令が非実行形態の場合はこの命令を実行形
態に変換するための手順がセットされる。具体的には、
命令がソースプログラムの場合はコンパイル・リンクの
手順を示したコマンド列（コンパイラ・リンカ）すなわ
ちロードモジュールの生成手順をセットし（ステップ３
７）、命令がスクリプトの場合は実行環境を表すキーワ
ードなどの情報（例えばｃｓｈ）をセットする（ステッ
プ４１）。

【００５０】次に、ヘッダ中の「制約条件」が決定され
る（図５）。制約条件は手続きを実行するための制約事
項であり主にアクセスコントロールに関して実行ユーザ
ＩＤ、実行ディレクトリを定義する。この内容となる値
は、必要な場合にはアプリケーション又はスケジューラ
によって与えられる。

【００５１】さらに、ヘッダ最後の「実行後の処理」が
セットされる。通常、手続きが実行された結果を要求元
に返送する場合にＲｅｔｕｒｎ（ステップ４６，４
７）、他のノードに転送する場合はＳｅｎｄ（ステップ
４８，４９）がセットされる。「実行後の処理」は、一
定の目的を達成するため複数連続したものとして生成さ
れるジョブ２（以下「複合ジョブ」という）の場合には
次のようにセットされる。なお、図６は、複合ジョブの
データ構造を示す。複合ジョブを構成する各ジョブ２は
上記のような手順の繰り返しによって生成される。

【００５２】複合ジョブの場合、次に継続手続きがあり
次の手続きの結果の転送を待つ場合はＮｅｘｔＷａｉｔ
を（ステップ５０，５１，５３）、手続きの処理結果を
次の手続きに引き渡す場合はＮｅｘｔＤａｔａをセット
する（ステップ５１，５２）。なお、Sendの場合のみ、
その直後に転送先ネットワークアドレスを定義する（ス
テップ４９）。この項目が設定されておらずデフォルト
の場合、受任側ノードでは命令実行後何もせず終了とな
る。

【００５３】なお、ジョブ２には、ジョブ２をネットワ
ーク上で一意に識別するためのジョブＩＤが生成・付加
される。ジョブＩＤは図７に示すようにネットワーク上
の位置を示すネットワークアドレス、要求ユーザのユー
ザＩＤ、要求コンピュータ内での要求シリアル番号の組
み合わせを含む。図８は、ジョブＩＤが付加されたジョ
ブ２の状態を示す。

【００５４】［ジョブの依頼と受任］ジョブ２が生成さ
れると、依頼手段６が、ジョブ２を前記通信手段５を通
じて他のノードに送信して実行を依頼する。依頼は、他
のノードの受任手段７によって次のように処理され、ジ
ョブ２の受任が成立する。ここで、依頼手段６は通信手
段５及び通信媒体１を通じてジョブＩＤとジョブ２をブ
ロードキャスト（同報通信）によって他の全てのノード
に送信し、応答を待つ。図９は、依頼側ノードと被依頼
側ノードとの間での通信の状態を示す。依頼手段６は、
依頼する各ジョブ２の状態をテーブルで管理する。図１
０はジョブ２を管理するテーブルの構造の例を示す。

【００５５】依頼側ノードが送信したジョブ２は通信媒
体１及び通信手段５を通じて他のノードの受任手段７に
到達する。このとき、被依頼側ノードの受任手段７は、
他のノードから送信されてきたジョブ２を受任するか否
かを決定する。図１１は被依頼側ノードにおける受任の
処理手順を示すフローチャートである。すなわち、被依
頼側ノードの受任手段７はジョブ２が自身のノード上で
実行可能か否かを判断する。

【００５６】この判断は、まず、ジョブ２自体の種別・
内容に基づいて行う。すなわち、実行形態のロードモジ
ュールであれば（ステップ１１５）手続きが（ステップ
１１６）コードセットなどとの関係で実行可能か（ステ
ップ１１７）、非実行形態のソースプログラムであれば
（ステップ１１８）メモリ容量等との関係において、補
助情報たるコンパイラで実行モジュールが生成可能か
（ステップ１１９）、スクリプトであれば（ステップ１
２０）対応する実行環境が提供できるか（ステップ１２
１）、によって判断される。ジョブ２自体が実行可能な
場合は、自身のノードの負荷から当該ジョブ２を実行可
能かが判断される（ステップ１２２）。なお、複数手続
きで構成されるジョブ２の場合は先頭の手続きに関して
上記のように判断する。

【００５７】被依頼側ノードの受任手段７は、ジョブ２
を実行できる場合は、仮承諾を依頼側ノードに返送す
る。ここで、図１１のうちステップ１１３，１１４は便
宜上、依頼側ノードの依頼手段６の動作を示したもので
ある。すなわち、依頼側ノードの依頼手段６は、最早の
仮承諾（最初の応答）を返送してきたノードに（ステッ
プ１１３）正式依頼を送信するとともに、前記ジョブ管
理テーブルにジョブＩＤ、要求ユーザ、依頼日時、依頼
先ノードを登録する（ステップ１１４）。

【００５８】なお、依頼手段６は２番目以降に返送され
た仮承諾は無視し、一方、無視された仮承諾を発送した
被依頼側ノードの受任手段７は、一定時間のタイムアウ
トによりこれを判定し、対応する要求依頼を消去する。

【００５９】このように、本実施例では、被依頼側ノー
ドが依頼されたジョブ２を受任するか否かを、自ノード
の負荷などに基づいて決定する。このため、一部のノー
ドへのジョブ２の集中が解決し、システム全体の処理効
率が向上する。

【００６０】また、本実施例では、上記のように、被依
頼側ノードのうちジョブ２を受任できるものが仮承諾を
依頼側ノードに返信し、依頼側ノードは最早の仮承諾を
返信した被依頼側ノードに正式依頼を送信することによ
ってジョブ２の依頼を行う。このような本実施例によれ
ば、各ノードでの処理が異なることがなく、各ノードを
同一の構成・手順で実現すればよいので、システム全体
の構成が単純化できる。

【００６１】［ジョブ実行の準備］正式依頼の送信によ
って依頼が成立すると、依頼側ノードでは、まず、準備
手段８が、受任したジョブ２の補助情報に基づいて、当
該ジョブ２実行の準備を行う。すなわち、図１２は、受
任したノードにおける準備の手順を示すフローチャート
である。準備手段８は、受任手段７から制御を引き渡さ
れた場合、該当するジョブ２を取り出し（ステップ１２
０２，１２０３）、ジョブ２をヘッダ部、手続き部、デ
ータ部に分解する（ステップ１２０４）。なお、複数の
ジョブ２がキュー（待ち列）を構成している場合や受任
しているジョブ２が複合ジョブである場合が考えられる
が、いずれの場合も準備の対象はキューや複合ジョブに
含まれるジョブ２のうち、未処理の最初のジョブ２であ
る。次に、ヘッダ部が解析される。

【００６２】このとき、「手続き属性」がＥｘｅの場合
はジョブの命令は実行形態（ロードモジュール）である
から（ステップ１２０５）、メモリ領域の確保のような
一般的処理が行われる（図示せず）他は、特段の処理は
行われない。手続き属性がＳｒｃの場合はジョブの命令
はソースプログラムのため（ステップ１２０６）セット
されている補助情報たる生成手順に従ってコンパイルを
行なう（ステップ１２０７）。また、手続き属性がＣｍ
ｄの場合はジョブの命令はスクリプトであるから（ステ
ップ１２０８）、「生成手順」にセットされている実行
環境を取り出し、スクリプトと合わせて実行形態とする
（ステップ１２０９）。

【００６３】このように、本実施例では、前記補助情報
が、非実行形態の命令を実行形態の命令に変換するため
の手順を示す情報を含むので、実行形態であるか非実行
形態であるかを問わず他のいずれのノードに依頼するこ
ともできる。このため、全体の処理効率が向上する。ま
た、被依頼側がこのような手順を有するか否かの有無を
依頼側で確認する必要がないので、構成が単純となる。

【００６４】また、本実施例では、前記補助情報がスク
リプトの実行環境を表す情報を含むので、スクリプトの
実行環境が被依頼側に存在するか否かを依頼側が確認す
る必要がなく、構成が単純化される。

【００６５】なお、準備の最後に、ヘッダ中の残りの情
報である「制約事項」と「実行後の処理」を取り出す
（ステップ１２１０）。ここで、「手続きの属性」中の
Ｃｏｎｔフラグがセットされているかをチェックし、セ
ットされている場合は直前の手続きの結果を当該手続き
の処理に使用するためその終了を待つ。すなわち、実行
しようとするジョブ２が複合ジョブ中の２番目以降のジ
ョブ２の場合、直前のジョブ２の結果の利用が指定され
ていることが考えられる。この場合、直前のジョブ２は
他のノードに依頼されている場合も考えられるし、同一
のノードにおいて並行処理の他のタスクによって実行さ
れていることも考えられる。この場合、直前のジョブ２
の結果を待つため、実行形態の手続きとデータおよび取
り出した「制約事項」と「実行後の処理」を待ち状態と
する。Ｃｏｎｔがセットされていない場合は実行形態の
手続きとデータを共に実行手段９に渡す。

【００６６】［ジョブの実行］準備の後、実行手段９が
ジョブ２の命令を実行する（ステップ１２１１）。つま
り、実行手段９は、準備手段８より渡された実行可能な
手続きを、データをパラメータとして実行する。この
時、準備手段８より渡されるヘッダ中の「制約条件」の
チェックを行なう。ここで、図１３はジョブ２の実行及
び実行後の処理の手順を示すフローチャートである。

【００６７】すなわち、対象とするジョブ２をメモリか
ら取り出し（ステップ１３０１）ヘッダ中のフラグ「制
約条件」にＵｓｅｒＩＤ，Ｄｉｒが指定されている場合
は（ステップ１３０２）それを実行ＵｓｅｒＩＤおよび
作業ディレクトリにセットする（ステップ１３０３）。
また、指定がない場合は（ステップ１３０２）デフォル
トとして（ステップ１３０４）、要求元ノードの要求ユ
ーザのユーザＩＤをＵｓｅｒＩＤとし、そのユーザのホ
ームディレクトリを作業ディレクトリとする（ステップ
１３０３）。デフォルトチェックによって、ＵｓｅｒＩ
Ｄ，Ｄｉｒの指定がなく実行ノード上で要求元のユーザ
が登録されていないことが判明した場合は、実行要求を
棄却し通信手段５を通じて依頼元ノードにジョブ２を返
送する（ステップ１３０５）。

【００６８】続いて、実行手段９が、命令をデータに基
づいて実行する（ステップ１３０６）。このとき、実行
形態およびＳｒｃ（ソースプログラム）の属性を持った
手続きは既に実行形態になっているため直接実行し結果
を保存する。また、スクリプトである命令は「生成手
順」に指定された環境下でスクリプトのまま実行し結果
を保存する。

【００６９】このように本実施例によれば、ジョブ２と
ともに補助情報が送信されるので、各ノードが処理可能
なジョブ２の種類を依頼側で判断することが不要にな
り、構成が単純化される。

【００７０】［実行後の処理］実行後、事後処理手段９
が実行の結果を処理する。すなわち、「実行後の処理」
にＮｅｘｔＤａｔａがセットされている場合は（ステッ
プ１３０７）、結果を待っている次のジョブ２が存在し
ており、次のジョブ２は、終了したジョブ２（手続き）
の実行結果をパラメータとして実行する必要がある。こ
のため、事後処理手段９は、実行結果にジョブＩＤを付
加し準備手段８に渡す（ステップ１３０８）。この場
合、実行結果を受領した準備手段８は、この結果を次の
ジョブ２に渡すべく、後続する待ち状態のジョブ２のデ
ータに、実行手段９より渡された結果を追加する。そし
て、後続するジョブ２についての準備を行った後、再度
実行手段９に制御を引き渡す（ステップ１３０９）。

【００７１】複合ジョブは、このように準備手段８と実
行手段９との間で相互に制御をやり取りすることによっ
て順次実行される。但し、複合ジョブの途中に当該ノー
ドで実行できないものが含まれている場合は、実行でき
ないジョブ２又は実行できないジョブ２を含む残りのジ
ョブ２は他のノードに再度依頼される。この時、ジョブ
ＩＤは要求元で作成したジョブＩＤを使用する。

【００７２】このように、本実施例では、実行すべき処
理が複数のジョブ２から成る場合には、受任したノード
から他のノードへ改めて依頼される。このため、依頼側
ノードが各ジョブ２ごとに依頼の処理を繰り返す必要が
なくなり、処理効率が向上する。

【００７３】なお、「実行後の処理」にＮｅｘｔＤａｔ
ａがセットされていないものについては次のように結果
が送信される（ステップ１３１０）。すなわち、「実行
後の処理」がＲｅｔｕｒｎ（要求元への返送）であれ
ば、実行結果は通信手段５に渡され、依頼側ノードに返
送される。また、「実行後の処理」がＳｅｎｄ（指定先
への転送）であれば、実行結果は通信手段５及び通信媒
体１を通じて指定のノードに転送される。なお、図１４
は「実行後の処理」がＲｅｔｕｒｎであるかＳｅｎｄで
あるかによって実行結果の送信先が異なる様子を示す概
念図である。

【００７４】［ジョブの処理の実例］上記のような本実
施例におけるジョブ２の処理の実例を示す（図１５）。
例えば、ノードＮ１でデータＤ１を用いた手続きＰ１
（ロードモジュール）と、その結果を用いる手続きＰ２
（ソースプログラム）からなる複合ジョブＪ１が生成さ
れたと仮定する。この場合、手続きＰ１には補助情報と
してコンパイラＣ１付加される。

【００７５】被依頼側ノードＮ２，Ｎ３，Ｎ４がブロー
ドキャストされたジョブＪ１を受信する。ノードＮ２は
メモリ容量不足のため手続きＰ１が実行できないので仮
承諾は返信しない。ノードＮ３，Ｎ４は実行可能と判断
し仮承諾をノード１に返信し、このうちノードＮ３の仮
承諾がノードＮ１に先着した。ノードＮ１はノードＮ３
に正式依頼を返信し、これによってノードＮ１からノー
ドＮ３へのジョブＪ１の依頼が成立する。

【００７６】ノードＮ１はノードＮ４からの仮承諾を無
視し、一方、ノードＮ４は正式依頼が返信されないので
タイムアウトによりジョブを消去する。ノードＮ３で
は、手続きＰ１はそのまま実行され、「実行後の処理」
ｎｅｘｔｄａｔａに基づいてその結果Ｒが手続きＰ２の
データＤ２に付加される。ソースプログラムである手続
きＰ２はコンパイラＣによって実行形態にコンパイルさ
れ、データＤ２＋Ｒに基づいて実行される。手続きＰ２
の「実行後の処理」がｒｅｔｕｒｎの場合、最終的実行
結果はノードＮ１に返送される。

【００７７】（３）他の実施例 本発明は上記実施例に限定されるものではなく、実施態
様の変更は自由であるから、次に例示するような他の実
施例をも包含するものである。例えば、通信手段はブロ
ードキャスト形式（同報通信）には限定されず、ノード
間でジョブを順次転送するなど他の形式でもよい。ま
た、補助情報はコンパイラやスクリプトの環境には限定
されず、他の内容でもよい。また、受任手段は必ずしも
自ら受任の可否を決定しなくともよく、この場合は、例
えばスケジューラが各ノードの負荷に基づいて各ジョブ
の依頼先を振り分けてもよい。また、受任の手続きでは
必ずしも仮承諾と正式依頼を用いる必要はなく、例えば
最早に受任することを決定したノードが他の全てのノー
ドに受任宣言を送信するなど他の手続きを用いてもよ
い。また、本発明の分散処理システム及び分散処理方法
では、必ずしも複合ジョブを扱える必要はない。

【００７８】

【発明の効果】以上説明したように本発明によれば、構
成が単純な分散処理システム及び分散処理方法を提供す
ることができるので、分散処理システム及び分散処理方
法を構築する費用が削減され、システムのメンテナンス
も容易になる。

【図面の簡単な説明】

【図１】本発明の実施例の分散処理システムにおいて通
信媒体１に接続されたノードの一つについて、その構成
を示す機能ブロック図。

【図２】本発明の実施例の分散処理システムにおけるジ
ョブの依頼とジョブの実行の手順の一例を示すフローチ
ャート。

【図３】本発明の実施例の分散処理システムにおけるジ
ョブの生成の手順を示すフローチャート。

【図４】本発明の実施例の分散処理システムにおいて生
成されるジョブごとのデータ構造を示す図。

【図５】本発明の実施例の分散処理システムにおけるジ
ョブのヘッダ部のデータ構造を示す図。

【図６】本発明の実施例の分散処理システムにおける複
合ジョブのデータ構造を示す図。

【図７】本発明の実施例の分散処理システムにおけるジ
ョブＩＤのユーザＩＤ、要求コンピュータ内での要求シ
リアル番号の組み合わせを示す図。

【図８】本発明の実施例の分散処理システムにおいてジ
ョブＩＤが付加されたジョブの状態を示す図。

【図９】本発明の実施例の分散処理システムにおける依
頼側ノードと被依頼側ノードとの間での通信の状態を示
す図。

【図１０】本発明の実施例の分散処理システムにおける
ジョブを管理するテーブルの構造の例を示す図。

【図１１】本発明の実施例の分散処理システムにおける
被依頼側ノードによるジョブの受任の処理手順を示すフ
ローチャート。

【図１２】本発明の実施例の分散処理システムにおける
受任したノードでのジョブ実行の準備の手順を示すフロ
ーチャート。

【図１３】本発明の実施例の分散処理システムにおける
ジョブの実行及び実行後の処理の手順を示すフローチャ
ート。

【図１４】本発明の実施例の分散処理システムにおい
て、「実行後の処理」によって実行結果の送信先が異な
る様子を示す概念図。

【図１５】本発明の実施例の分散処理システムにおける
ジョブの処理の実例を示す図。

【符号の説明】

１：通信媒体 ２：ジョブ ３：生成手段 ４：付加手段 ５：通信手段 ６：依頼手段 ７：受任手段 ８：準備手段 ９：実行手段 １０：事後処理手段

Claims (12)

【特許請求の範囲】
1. 【請求項１】 通信媒体によって接続された複数のノー
   ドを含む分散処理システムにおいて、 各ノードが、 前記通信媒体を通じて他のノードと通信するための通信
   手段と、 他のノードに依頼すべきジョブを生成する生成手段と、 前記ジョブに、ジョブの命令の実行のための補助情報を
   付加する付加手段と、 前記ジョブを前記通信手段を通じて他のノードに送信し
   て実行を依頼する依頼手段と、 他のノードから送信されたジョブを受任する受任手段
   と、 受任したジョブの前記補助情報に基づいて、当該ジョブ
   の実行の準備を行う準備手段と、 ジョブの命令を実行する実行手段と、 前記実行の結果を処理する事後処理手段と、 を有することを特徴とする分散処理システム。
2. 【請求項２】 前記受任手段は、他のノードから送信さ
   れてきたジョブを受任するか否かを決定するように構成
   されたことを特徴とする請求項１記載の分散処理システ
   ム。
3. 【請求項３】 前記依頼手段は、前記ジョブを全部又は
   一部の前記ノードに送信するように構成され、 前記受任手段は、ジョブが送信されたノードにおいて、
   送信されたジョブを受任できると決定したときは、当該
   ジョブを送信した依頼側ノードに仮承諾を返信するよう
   に構成され、 前記依頼手段は、依頼側ノードにおいて、最早の前記仮
   承諾を返信したノードに正式依頼を送信することによっ
   てジョブの依頼を行うように構成されたことを特徴とす
   る請求項２記載の分散処理システム。
4. 【請求項４】 前記生成手段は、所定の場合に複数のジ
   ョブからなる複合ジョブを生成するように構成され、 前記事後処理手段は、前記複合ジョブを受任したノード
   において、複合ジョブに含まれる各ジョブのうち当該ノ
   ードが実行すべきジョブの実行後、所定の場合に残余の
   ジョブを他のノードに依頼するように構成されたことを
   特徴とする請求項１記載の分散処理システム。
5. 【請求項５】 前記補助情報が、非実行形態の命令を実
   行形態の命令に変換するための手順を示す情報であるこ
   とを特徴とする請求項１記載の分散処理システム。
6. 【請求項６】 前記補助情報が、スクリプトの実行環境
   を表す情報であることを特徴とする請求項１記載の分散
   処理システム。
7. 【請求項７】 通信媒体によって接続された複数のノー
   ドを含む分散処理システムにおいて、 各ノードが、 前記通信媒体を通じて他のノードと通信するための通信
   のステップと、 他のノードに依頼すべきジョブを生成する生成のステッ
   プと、 前記ジョブに、ジョブの命令の実行のための補助情報を
   付加する付加のステップと、 前記ジョブを前記通信のステップを通じて他のノードに
   送信して実行を依頼する依頼のステップと、 他のノードから送信されたジョブを受任する受任のステ
   ップと、 受任したジョブの前記補助情報に基づいて、当該ジョブ
   の実行の準備を行う準備のステップと、 ジョブの命令を実行する実行のステップと、 前記実行の結果を処理する事後処理のステップと、 を行うことを特徴とする分散処理方法。
8. 【請求項８】 前記受任のステップでは、他のノードか
   ら送信されてきたジョブを受任するか否かを決定するこ
   とを特徴とする請求項７記載の分散処理方法。
9. 【請求項９】 前記依頼のステップでは、前記ジョブを
   全部又は一部の前記ノードに送信し、 前記受任のステップでは、ジョブが送信されたノードに
   おいて、送信されたジョブを受任できると決定したとき
   は、当該ジョブを送信した依頼側ノードに仮承諾を返信
   し、 前記依頼のステップでは、依頼側ノードにおいて、最早
   の前記仮承諾を返信したノードに正式依頼を送信するこ
   とによってジョブの依頼を行うことを特徴とする請求項
   ８記載の分散処理方法。
10. 【請求項１０】 前記生成のステップでは、所定の場合
    に複数のジョブからなる複合ジョブを生成し、 前記事後処理のステップでは、前記複合ジョブを受任し
    たノードにおいて、複合ジョブに含まれる各ジョブのう
    ち当該ノードが実行すべきジョブの実行後、所定の場合
    に残余のジョブを他のノードに依頼することを特徴とす
    る請求項７記載の分散処理方法。
11. 【請求項１１】 前記補助情報が、非実行形態の命令を
    実行形態の命令に変換するための手順を示す情報である
    ことを特徴とする請求項７記載の分散処理方法。
12. 【請求項１２】 前記補助情報が、スクリプトの実行環
    境を表す情報であることを特徴とする請求項７記載の分
    散処理方法。