JP2000515657A - 共有資源の分散制御を可能にする方法と装置 - Google Patents

Abstract

(57)【要約】 システムは制御表（２０６、２０８）と制御プロセスから成り、前者は制御表（２０６、２０８）が使用可能か否かを示す可用性インデシアとデータボリューム所有権を示すインデシアとを含み、後者は記憶ボリューム（６４、６６）への排他的書込アクセスをクライアントに提供するため、制御表（２０６、２０８）の排他的所有権の要求、取得を求めて各クライアント（５４、５６）上で実行される。クライアントは記憶ボリューム(６４、６６)、又は、各々がソースファイル名(１４５８)、宛先ファイル名(１４７８)、アプリケーションプログラムコード（１４７４）を含む１つ又はそれ以上の記録を含むプロジェクト管理フォルダの何れかへの排他的編集アクセスを求め互いに裁定し合う。各クライアントは管理プロセス（１３０６、１３１２）を実行して、プロジェクト管理フォルダ（１３１４、１３２０）の位置を特定し、常駐アプリケーション（１４５６）を使って記録を管理するが、これらは共に未完成であり、処理クライアント上に見つかるアプリケーションを呼び出す。

Description

【発明の詳細な説明】 共有資源の分散制御を可能にする方法と装置 関連仮出願に関するクロスレファレンス 本出願は、１９９６年８月２日出願の米国仮特許出願第６０／０２３，２１８ 号の発明の恩典を主張し、ここに参考資料として挙げる。本出願は、ジェームス ・Ｊ・ウォルフを発明者とし１９９７年８月１日出願（弁理士事件整理番号１６ ５９８．７０２）の米国特許出願第 号「共有記憶ボリュームを分散制御する 方法と装置」、ジェームス・Ｊ・ウォルフ、ダビット・ラスロップを発明者とし １９９７年８月１日出願（弁理士事件整理番号１６５９８．７０３）の米国特許 出願第 号「複数プロセッサを分散制御する方法と装置」、ジェームス・Ｊ・ ウォルフを発明者とし１９９７年８月１日出願（弁理士事件整理番号１６５９８ ．７０４）の米国特許出願第 号「データベースを分散制御する方法と装置」 に関係している。これら参考文献もここに参考資料として挙げる。 発明の背景 著作権の承認 本特許書類が開示するものの一部は、著作権保護を受けた資料を含んでいる。 そうした資料が特許開示の際にファクシミリで複製されることについて、米国特 許商標局のファイル又は記録に登場するのであれば、著作権者は異議を申し立て るものではないが、これ以外の場合に関しては全著作権を留保する。 発明の技術的分野 本発明は一般的には、コンピュータネットワーク上の共有資源を分散制御する システムに関係している。より詳しくは、記憶装置、データベース、プロジェク ト等の資源に対してネットワーク化された環境での複数のコンピュータ間に制御 を分散させることに関係している。 背景 コンピュータシステムの場合、様々なコミュニケーシヨン手段によりファイル 情報を複数のコンピュータで共有するのが普通である。コンピュータがファイル 情報を送るには、モデムとネットワークが使われる。モデムはネットワークに比 べ速度が非常に遅い。ネットワークはファイルサーバを必要とし、高速ネットワ ークの場合ファイルサーバの速度は隘路となる。この隘路は、ファイルサーバの 追随できる速度以上でファイル情報を共有せねばならぬアプリケーションに対し 障害となる。ファイルサーバは、いわゆるクライアント／サーバ・パラダイムの 下で作動する。このパラダイムの下では、クライアントがサーバに要求をすると 次にサーバがその要求を実行する。１つのファイルサーバの場合、複数のクライ アントがファイルサーバに要求をすることがあり得る。ファイルサーバは要求を 受理し、要求を待機させ、要求に対し一度で答える。ファイルシステムの一貫性 はこの方法で維持されるが、それは、１つのエンティティであるファイルサーバ が、ファイル情報が１つの記憶媒体上に論理的かつ一貫性をもって存在するファ イルシステムを制御するデータ構造上で作動しているからである。 ネットワーク技術の進歩により、１つのプリンタをネットワーク全体の付随周 辺機器（ＮＡＰ）としてネットワークに取り付けたように、様々な手段で記憶装 置をネットワーク上に直接取り付けることができるようになった。ＮＡＰパラダ イムではファイルサーバに関する速度上の隘路を除去できるようになるが、柔軟 性が犠牲になる。ＮＡＰパラダイムの下では、ファイルシステムの一貫性を維持 する方法がない。このため、複数コンピュータはファイル情報への読み取り専用 アクセスに制限されることになり、ファイル情報の変更が許されなくなる。複数 コンピュータでファイル情報を修正する場合ファイルシステムは損なわれること になるが、それは、キャッシュされたファイルシステムのデータ構造の一貫性を 維持する手段がない儘でファイルシステムを修正しようとするエンティティが複 数存在し、記憶媒体上に論理的かつ一貫性のあるやり方でファイルシステムのデ ータ構造を維持する方法がないためである。それゆえ、このようなＮＡＰ型シス テムは、高速の読み取り専用のファイル情報共有システムとなっている。 ファイル情報を共有するためのより改善されたシステムと方法が必要とされて いる。こうしたシステムは、ＮＡＰパラダイムが引き起こす、アクセス速度を高 める際のファイルサーバの隘路を取り除き、同時にクライアント／サーバ・パラ ダイムの柔軟性を維持することが好ましい。 コンピュータシステムの場合、計算の集中的処理を完了させるには膨大な時間 が掛かるのが普通である。マルチプロセッサシステムの場合、コンピュータ中に 存在するプロセッサに処理を配分すれば、計算を迅速に処理することができる。 これが可能な理由は、１台のコンピュータ中に存在するプロセッサが、処理の基 である同一の物理的資源（ＰＣＩ、メモリ、ディスク、ＣＰＵバス）を、直付け する方法で共有するからである。このアプローチの欠点は、非常に高価で一般的 ではないハードウェア装置が必要なことであり、そして特定のハードウェアモデ ル上でのこの能力の利点を生かすようにソフトウェアを書かなければならないこ とである。更に処理能力は、１台のコンピュータシステムに設置できるＣＰＵの 数に厳格に制限されてしまう。１台のコンピュータでマルチプロセッサを使うア プローチは、物理的資源を数の増えたＣＰＵの間で分割する際に生ずる厳しい隘 路によって更に制限を受ける。 二番目のアプローチは、１つのネットワークを通して取り付けられている複数 のプロセッサに対して処理を配分するものである。このアプローチは、関与する プロセッサの数が実質的に制限されず、使用されるコンピュータは高価なもので なく普通のものである点から魅力的である。しかし、このアプローチには多くの 欠点があるために極端に非効率的となり、多くの場合ほとんど役に立たない。ネ ットワークに処理を分散させる第一の欠点は、各マシンが処理を実行する際に必 要とする情報の伝達及び処理結果の伝達が、従来のクライアント／サーバネット ワーク（クライアント／サーバモデルが関係する隘路と並んで）を通して普通の 遅いネットワーク接続で行わねばならないために、非常に遅くなりかねないこと である。この制約は、入出力の少なくとも一方で膨大なデータが必要な場合には 膨大な処理オーバーヘッドを生じさせることになる。処理にコンピュータを増や すに連れてネットワーク内での送信量が増えるため、分散処理の効率は更に低下 してしまう。 ネットワークを通じて分散処理するためのより改善されたシステムと方法が必 要とされている。こうしたシステムは、現在の分散ネットワークに関係する隘路 と欠点を取り除き、同時にその長所を維持するものである。そうしたシステムで は、処理の分散機能が働くようになり、クロスプラットフォーム環境下に管理さ れることになろう。 発明の概要 ボリュームの分散制御 本発明の第一実施例では分散ボリューム管理システムを開示する。本実施例で は、ネットワーク上の複数クライアントが、データ記憶ボリュームの一貫性に関 し制御と責任を共有している。このシステムはデータ記憶ボリュームに関係した 制御表を有している。制御表は、制御表が利用可能か否かを示す可用性インデシ アと制御表の所有状態を示す識別インデシアとを含んでいる。システムは又クラ イアント上で実行される制御プロセスを含んでいる。制御プロセスでは、クライ アントにデータ記憶ボリュームへの排他的な書込アクセスを提供するために、制 御表に関する排他的所有権が要求され取得される。 本発明のある実施例では、データ記憶ボリュームに接続された複数のクライア ントの間で、データ記憶ボリュームへの排他的な書込アクセスを互いに実施させ る方法は、第一クライアントの書込要求を検出する行為と、前記検出行為に応じ て第一クライアント上で要求ルーチンを開始する行為と、第二クライアントの解 放要求を取得する行為と、前記取得行為に応じて第二クライアント上で解放ルー チンを開始する行為とから成り、前記要求ルーチンは、ａ）制御表中の所有イン デシアに基づいて、第二クライアントがデータ記憶ボリュームへの書込アクセス を有していると決定する行為と、ｂ）前記決定する行為に応じて、第二クライア ントが書込アクセスを解放するよう、解放要求を送る行為と、ｃ）第二クライア ントからの肯定通告に応じて、ｉ）制御表中の所有インデシアを第一クライアン トの所有インデシアに置き換える行為と、ｉｉ）書き込みアクセスのためにデー タ記憶ボリュームをマウントする行為とから成り、前記解放ルーチンは、ａ）前 記データ記憶ボリュームに対する書き込みアクセスを解放する行為と、ｂ）肯定 通告を解放行為の第一クライアントに送付する行為とから成っている。 データベースの分散制御 本発明のもう一つの実施例では分散データベース管理システムが開示されてい る。本実施例では、ネットワーク上の複数クライアントが、複数の記録を含むデ ータベースの一貫性に関し制御と責任を共有している。クライアントは各記録内 の各フィールドへの排他的編集アクセスに関し互いの間で裁定する。データベー ス管理システムは複数記録内の各フィールドに関係するロックフィールドを含ん でいる。各クライアントは常駐コヒーレンシープロセスを実行する。コヒーレン シープロセスはフィールドを編集する要求に応答する。このプロセスはフィール ド上にフィールドロックがない場合に要求を認める。要求が認められると、コヒ ーレンシープロセスはフィールドにロックを設置し、フィールドの排他的所有を 主張する。コヒーレンシープロセスは、フィールドの編集を出る要求にも応答す る。編集を出る要求が受信されると、コヒーレンシープロセスはロックを取り除 きフィールドの排他的所有を取り下げる。各クライアントはデータベース処理を 実行して、照会を受付け、照会に応えてデータベースから記録を提供し、フィー ルドを編集する要求を受付け、フィールドを編集する要求をコヒーレンシープロ セスへ送る。データベースプロセスはフィールドを編集する要求を受付け、そし てフィールドの編集を出る要求をコヒーレンシープロセスに伝える。 本発明のある実施例では、複数の記録を含むデータベースを管理し、各記録内 のフィールド各々への排他的編集アクセスをデータベースに接続されているクラ イアントに提供するための方法は、第一クライアントにおいてフィールドを編集 する要求を検知する行為と、前記検知する行為に応じて第一クライアント上でコ ヒーレンシールーチンを開始する行為と、前記複数のクライアントの第一のクラ イアントにおいてフィールドの編集を出る要求を取得する行為と、取得する行為 に応じて第一のクライアント上でコヒーレンシールーチンを開始し、そこで前記 コヒーレンシールーチンは第一クライアント所有インデシアをそのフィールドか ら取り除く行為とから成り、前記コヒーレンシールーチンは、ａ）フィールドに 関係する所有インデシアに基づいて、複数のクライアントの内の他のクライアン トがフィールドに編集アクセスすることを決定する行為と、ｂ）決定する行為に 応じて、所有権の取り下げられるフィールドに関する所有インデシアを待つ行為 と、ｃ）フィールドに関する所有インデシアの取り下げに応じて、ｉ）編集され るフィールドに第一クライアントの所有インデシアを取り付ける行為と、ｉｉ） そのフィールドに編集アクセスを提供する行為とから成っている。 プロセッシングの分散制御 本発明のもう一つの実施例では、分散プロジェクト管理システムが開示されて いる。本実施例では、ネットワーク上の複数クライアントが、ネットワーク上に 記憶され、クライアントがアクセス可能なプロジェクト管理フォルダに定義され ているプロジェクトに対し制御と責任を共有している。プロジェクト管理フォル ダは一つ又はそれ以上の記録を含んでいる。記録には、ソースファイル名、ソー スファイル位置、アプリケーション名、アプリケーションプログラムコード、宛 先ファイル名、宛先ファイル位置が含まれている。ネットワーク上の各クライア ントは、フォルダの位置を探し、フォルダ内の記録を読むために管理プロセスを 実行する。記録が読まれると、資源即ち記録が必要とするアプリケーションがク ライアントに在るか否かが判定される。もし無ければ、クライアントはフォルダ へ進む。もし資源が在れば、管理プロセスは、ソースファイル名、ソースファイ ル位置、アプリケーション名、アプリケーションプログラムコード、宛先ファイ ル名、宛先ファイル位置をはじめとする記録の内容を読む。管理プロセスは次に クライアントの常駐アプリケーション／資源に記録内に名前が挙げられているソ ースファイルを開かせる。次に管理プロセスは、クライアントの常駐アプリケー ションに、これも又記録から得られたアプリケーションプログラムコードの指示 の下にそのソースファイルに関するプロセスを実行させる。管理プロセスが、ア プリケーションプログラムコードに従ってアプリケーションがタスクを完了した と検知すると、管理プロセスはアプリケーション／資源に指示して、完了したタ スク／成果物を記録内の宛先ファイル名に対応する名称を付けてファイル内に記 憶させ、そのファイルを記録内で見つけられた宛先ファイル位置に対応するネッ トワーク上の位置に記憶させる。管理プロセスは次に、プロジェクト管理フォル ダに完了の印を付ける。 本発明のある実施例では、コンピューターネットワークに接続されている選択 されたクライアントにプロジェクトの管理を分配する方法は、コンピューターネ ットワーク上にプロジェクト管理ファイルを作り、且つソースファイル名、ソー スファイル位置、第一アプリケーション名、第一アプリケーションプログラムコ ード、第一アプリケーション宛先ファイル名、第一アプリケーション宛先ファイ ル位置を含む少なくとも一つの記録を含むプロジェクト管理フォルダを作る行為 と、第一クライアントにおいてプロジェクト管理ファイルのネットワーク上の位 置を検知する行為と、前記検知する行為に応じて第一クライアント上で管理プロ セスを開始する行為とから成り、前記管理プロセスは、ａ）プロジェクト管理フ ァイル記録を読む行為と、ｂ）第一アプリケーション名が第一クライアント上の 対応するアプリケーションと合うと裁定する行為と、ｃ）対応するアプリケーシ ョンに、第一アプリケーションプログラムコードに従ってソースファイル上で演 算を実行させ、宛先ファイル位置において結果成果物を宛先ファイル名のついた ファイルに記憶させるために、対応するアプリケーションに第一アプリケーショ ンプログラムコードを送る行為と、ｄ）少なくとも一つの記録が完了したと印を 付ける行為とから成っている。 図面の簡単な説明 本発明のこうした特徴と利点は、以下の詳細な記述と付属図面とを付き合わせ ることで当業者に一層明らかなものとなろう。 図１Ａは、従来技術によるクライアントサーバネットワークのハードウェアブ ロック線図である。 図１Ｂは、図１Ａの各クライアント上に存在するソフトウェアモジュールを示 す。 図１Ｃは、図１Ｂのモジュールの機能上の関係を示す。 図２Ａは、複数クライアントと共有記憶ボリュームとの間をサーバ無しでネッ トワーク接続した場合のハードウェアブロック線図である。 図２Ｂは、図２Ａの各クライアント上に存在するソフトウェアモジュールを示 す。 図２Ｃは、図２Ａのソフトウェアモジュール間の機能上の関係を示す。 図３Ａは、図２Ａの共有記憶ボリューム上のアクセス制御表を示す。 図３Ｂは、図２Ａの共有記憶ボリューム内のボリューム制御表を示す。 図４は、図２Ａの共有記憶ボリュームに関するファイルディレクトリ構造の例 を示す。 図５Ａ−Ｅは、複数クライアントが、一つの共有記憶ボリュームへの読取／書 込アクセスをできるようにするプロセスを示す。 図６は、クライアントネットワークに接続された、従来技術によるデータベー スサーバのハードウェアブロック線図である。 図７は、複数クライアントが、一つの共有記憶ボリューム上のデータベースに 直接取り付けられる場合のハードウェアブロック線図である。 図８Ａは、図７の共有ボリューム上のアクセス制御表を示す。 図８Ｂは、図７の共有ボリューム上のボリューム制御表を示す。 図８Ｃは、図７の共有ボリューム上の更新リストを示す。 図９Ａ、９Ｂはそれぞれ、図７の共有ボリューム上のリレーショナルデータベ ース、フラットデータベースに関する強化されたデータ構造を示す。 図１０は、分散データベースプロセスを実行する各クライアント上のソフトウ ェアモジュールを示す機能ブロック線図である。 図１１は、あるデータベースエンジンの全体構造内に、図１０Ａ−Ｆの各々を 組み込んだ全体プロセスフローである。 図１２Ａ−Ｆは、共有記憶ボリューム上に一貫性のあるデータベースを維持す るために、図７の各クライアント上で実行されるプロセスを示す。 図１３Ａ−Ｃは、あるプロジェクト管理ファイルが命じたタスクを複数クライ アントが共同で処理するネットワーク環境を示す。 図１４Ａ−Ｄは、図１３Ａ−Ｃのプロジェクト管理ファイルに関する詳細デー タ構造を示す。 図１５Ａ−Ｂは、図１３Ａ−Ｃのネットワーク上で実行できるプロジェクトの 例を示す。 図１６Ａ−Ｄは、図１５Ａのプロセスに関する画面インタフェイスを示す。 図１７Ａ−Ｆは、分散プロセス管理を実行するために、図１３Ａ−Ｃのクライ アント上で実行されるプロセスを示す。 発明の詳細な説明 図１Ａは、従来技術によるクライアントサーバネットワークのハードウェアブ ロック線図である。ネットワークはクライアント５４−５６(各々をクライアン トＡ−Ｂと名付ける)、サーバ６０、記憶ボリューム６４、６６とから成る。記 憶ボリューム６６はコンパクトディスクである。記憶ボリューム６４はディスク の冗長配列（ＲＡＩＤ）である。各記憶ボリュームは自分に関するファイルディ レクトリを有する。記憶ボリューム６４はファイルディレクトリ６２を含む。各 クライアント５４、５６はそれぞれファイルディレクトリ６２のキャッシュコピ −５０、５２を含む。 コンピュータ５４、５６はローカルエリアネットワーク（ＬＡＮ）を介してサ ーバ６０に接続される。サーバ６０は、スモールコンピュータシステムインタフ ェイス（ＳＣＳＩ）コネクションにより、記憶ボリューム６４、６６に接続され る。クライアントＡ、Ｂが記憶ボリューム６４、６６のいずれかと接続するため には、まずサーバ６０へのアクセス要求をログしなければならない。要求に応じ てサーバ６０は、記憶ボリュームの一貫性を維持するために、ボリューム管理、 書込アクセス、ファイル管理に対応するプロセス５８を実行する。 図１Ｂは電源が入っている間のサーバ６０上のハードウェアモジュールとソフ トウェアモジュールを示す。サーバ６０は不揮発性メモリ８４、ＣＰＵ８０、ロ ーカル記憶装置８６とから成る。不揮発性メモリ８４内には、オペレーティング システム(ＯＳ)カーネルとして識別されるソフトウェアモジュールが存在する。 記憶装置８６はフルＯＳ９０、関連ドライバー９２、スタートアップ構成９４を 含む。作動時に電源が入ると、ＣＰＵ８０はＯＳカーネル８８のコードシーケン スを開始する。次にＣＰＵは、記憶装置８６上の主ＯＳ９０にアクセスする。Ｏ Ｓ初期設定の間に、種々のドライバー９２が初期設定される。これらのドライバ ーはＣＰＵを、キーボード、モニター、プリンタ、記憶装置等の周辺装置に接続 する。ＯＳが初期設定されると、スタートアップファイル９４が実行され、１つ 又はそれ以上のアプリケーションが実行可能な状態になる。 ソフトウェアモジュールブロック８２に、電源が入っているときに作動可能な ソフトウェアモジュールを示す。ＯＳに関係するモジュールは、アクセス制御モ ジュール９６、コマンド受信モジュール９８、スケジューリングモジュール１０ ２、ロジカル・ツー・フィジカル・トランスレーション及びスペース割当モジュ ール１１０である。他のモジュールは、スクリーンドライバー１０４、ＣＤドラ イバー１０６、ＲＡＩＤ記憶ドライバー１０８である。最後に、アプリケーシヨ ンモジュール１００がスタートアップファイル９４で実行可能な状態にされる。 図１Ｃは、図１Ｂ、Ｃのソフトウェアモジュール間の機能上の入出力Ｉ／Ｏの 関係を示すブロック線図であり、この関係には、最初の図１Ａに示したようにク ライアントアプリケーション１５０がサーバ６０と交信し、次にサーバ６０が記 憶装置６４、６６のいずれかと交信する様子が含まれている。ファイルサーバ６ ０は、ロジカルＩ／Ｏブロック１５８とフィジカルＩ／Ｏブロック１６０から成 る。ロジカルＩ／Ｏブロック１５８は、コマンド受信モジユール９８、アクセス 制御モジュール９６、ファイルディレクトリ１６６から成る。フィジカルＩ／Ｏ ブロック１６０は、スケジューリングモジュール１０２、ロジカル・ツー・フィ ジカルトランスレーション及びスペース割当モジュール１１０、モニタ、ＣＤ、 ＲＡＩＤ記憶装置のそれぞれに関係するドライバー１０４−１０８から成る。Ｒ ＡＩＤ記憶装置６４はファイルディレクトリ６２を有しており、ファイルディレ クトリ６２には記憶装置６４上に位置する全データに関するディレクトリツリー とアクセス権が含まれている。 作動中、クライアントアプリケーション１５０はサーバ６０を介し記憶装置６ ４、６６のいずれかと交信する。クライアントアプリケーション１５０から受信 するコマンドには、クリエイト削除、オープン、クローズ、読取、書込が含まれ る。各コマンドにはロジカルファイル名が付いている。コマンドはコマンド受信 モジュール９８からアクセス制御モジュール９６へと転送される。アクセス制御 モジュール９６は各々対応するファイルディレクトリ１６６の一つとインタフェ ースが取れている。一般的には、各フィジカルボリュームに対して１つのファイ ルディレクトリがある。更に、ボリュームは複数のフィジカル記憶装置に亘って 存在することがソフトウェアストライピングの場合のように可能である。フィジ カルボリュームは１つの記憶装置でもよいし記憶装置上の１区画でもよい。 ファイルディレクトリについては図４との関連で詳細に述べるが、通常、ロジカ ルファイル名のディレクトリツリーと各ファイル名に関するアクセス特権とを含 んでいる。アクセス制御モジュール９６はファイルディレクトリ１６６に含まれ ているアクセス特権に基づいて、特定のコマンドが実行されるべきか否かを決定 する。例えばアプリケーションコマンドが、読取専用としてリストされているフ ァイル又はボリュームに対する書込要求を含む場合、アクセス制御モジュールは その要求を実行しない。その代わり、アクセス制御モジュールが実行するコマン ドが受信されると、当該コマンドに関係したデータはスケジューリングモジュー ル１０２へ直接転送される。フィジカルＩ／Ｏブロックは、コンピュータシステ ム外の環境との主要なインタフェイスである。フィジカルＩ／Ｏは、ディスク又 はテープシステムとの間で交換されるデータブロックをやり取りする。従ってフ ィジカルＩ／Ｏは、二次記憶装置上のブロックの配置と主メモリー中でのブロッ クのバッファリングに関係し、スケジューリングモジュールは、性能を最適化す るためにディスク又はテープへのアクセスをスケジューリングすることに関係し ている。Ｉ／Ｏバッファ、二次メモリーの割当はこのレベルでなされる。例えば 、特定のロジカル位置からデータを読み取るコマンドは、スケジューリングモジ ュール１０２からロジカル・ツー・フィジカル・トランスレーション及びスペー ス割当モジュール１１０へ転送される。モジュール１１０はロジカル位置を特定 の記憶装置上の実際の物理的位置に直す役目を担っている。ファイルは例えば、 記憶装置の連続した部分に記憶されなくても構わない。代わりに切れ切れのセグ メント上に記憶されてもよい。次にこのモジュールは、ロジカルファイル名を一 連のフィジカルセグメントに翻訳する。このモジュールはスペース割当の役目も 担っている。スペース割当の意味は、書込コマンドが受信された場合、データが 書き込まれるべき実際の物理的アロケーションをモジュール１１０が決定すると いうことである。サーバ６０と記憶装置との間の最終的なソフトウェアインタフ ェイスは、適当なデバイスドライバー経由でなされる。各デバイスドライバーは １つのデバイスタイプを扱う。デバイスドライバーは、ディスクコントローラが どれだけのレジスターを有しており、そのレジスターが何に使われるのかを知っ ているＯＳの唯一の部分である。セクター、トラック、シリンダー、ヘッドアー ム の動き、インタリーブファクタ、モータドライブ、ヘッドセットリング回数、及 び記憶装置を適切に作動させるその他全てのメカニックに関して知っているのは このデバイスドライバーのみである。概略的に言えば、デバイスドライバーの仕 事は、デバイスとは独立しているソフトウェアから抽象的な要求を受け取り、当 該要求が実施されるのを見届けることにある。 図２Ａは、ボリューム内に含まれるデータの一貫性を失わせずに、１つ又はそ れ以上の共有記憶ボリュームにクライアントを直接接続する本発明の好適実施例 のハードウェアブロック線図である。クライアント５４−５６、記憶装置６４− ６６、サーバ６０が示されている。ＲＡＩＤ記憶装置６４は、ファイルディレク トリ２０４、アクセス制御表２０６、ボリューム制御表２０８を含む。各クライ アント５４、５６は、記憶装置６４−６６を分散管理するプロセスを実行する。 クライアント５４、５６はプロセス２１４、２１６をそれぞれ実行する。クライ アント５４、５６はファイルディレクトリ６２の常駐コピ−２００−２０２を有 する。 ｘマーカー２１２で示されているサーバ６０は、クライアント５４、５６のい ずれかが記憶装置６４−６６に対して発する要求に答えるためにはもはや必要で はない。替わりに、クライアント５４、５６は記憶ボリューム６４−６６に直接 接続されている。ある好適実施例では、ファイバチャネルＡＮＳＩスタンダード Ｘ３．２３０及び／又はＳＣＳＩ−３ＡＮＳＩスタンダードＸ３．２３０のいず れかを基に接続がなされるが、他のメディア接続によるシステムの支援も可能で ある。本発明の他の実施例は、記憶装置８０２とホスト８０４を接続させる他の 方法を支援するように適合化することもでき、そうした例として、ファースト４ ０（ウルトラＳＣＳＩ）、シリアルストレージアーキテクチャ(ＳＳＡ)、「ファ イヤワイア」ＩＥＥＥ標準Ｐ１３９４、非同期転送モード（ＡＴＭ）、スケーラ ブルコヒーレントインタフェイス（ＳＣＩ）ＩＥＥＥ標準１５９６−１９９２及 び上記の内の幾つかの組合せを挙げることができる。ファイバチャネルアーキテ クチャは、シリアルコミュニケーションとＩ／Ｏ記憶装置の両者に対して高速イ ンタフェイスリンクを提供する。このリンクは、業界標準のインタフェイスを使 って、既存アーキテクチャの１０倍から１００倍の速度でデータの転送をする ことができる。ファイバチャネルはデータ通信における極々最近の革命的出来事 の一部であるが、パラレルベースタイプのデータ送信を従来使用してきたアプリ ケーションとコンピュータアーキテエクチュアに、シリアル伝送線、設計技法、 設計技術を組み込むことによりもたらされたものである。伝送線は、データ送信 とバスベース設計に対し優れた特性を有しており、長距離及び／又は高速でエラ ーのない信号送信を可能にする。ファイバチャネルは、ポイント・ツー・ポイン トリンク、パケット切換、共有メディアループトポロジイを始めとする柔軟なト ポロジイを支援している。ある好適実施例では、ファイバチャネルネットワーク がクライアント５４、５６を記憶装置６４、６６の両方ににリンクさせる。記憶 装置６４には、複数ディスクに亘ってデータを同時に読取・書込するストライピ ングソフトウェアが備えられている。このストライピング能力により、ネットワ ーク媒体であるファイバチャネルの帯域を記憶装置の帯域に等しくすることがで きる。記憶装置上の個々のディスクはネットワーク接続の帯域の一部のデータし か提供できないと言う事実にも拘わらず、こうしたことが起こるのである。ファ イルを複数ディスクに亘ってストライピングすることにより、複数ディスクが並 行してデータをドライバーに提供できるようになり、ヘッドアームに関して物理 的限界によって課せられる帯域制約は克服されることになる。 クライアントＡ，Ｂのどちらかが記憶装置６４に書込んだデータの一貫性を維 持するため、プロセス２１４−２１６がクライアント５４、５６上でそれぞれ実 行される。各プロセスは新たなボリュームのマウンティング、書込アクセス、フ ァイル管理を制御する。記憶装置６４にデータを書込むために、クライアントは 先ず、共有記憶ボリューム上のアクセス制御表２０６、ボリューム制御表２０８ の両者の内に書込条件が存在することを確認しなければならない。当該条件が存 在することが確認されると、クライアントは記憶ボリュームにデータを書込むこ とができる。当該条件が存在しない場合、書込要求は拒否される。ある好適実施 例では、アクセス制御表、ボリューム制御表は物理的な記憶装置上の、読取・書 込の両能力を備えた個別のボリューム上に存在する。従って、アクセス制御表、 ボリューム制御表は、両制御表がアクセスを制御している同一の物理的デバイス 上に存在する必要はなく、通常、実際にも存在しない。代わりに２１４、２１６ の各プロセスは共通なアクセス制御表、ボリューム制御表を共有して、プロセス が接続される多くの装置のどれか１つへ、何時どんな条件の下で書込めるのかを 確認する。 図２Ｂは、クライアント５４のハードウェア・ソフトウェアブロック線図であ る。クライアント５４は、ＣＰＵ２５０、不揮発性メモリ２５４、ローカル記憶 装置２５８から成る。不揮発性メモリ２５４はＩＳＯ２５６を含んでいる。不揮 発性メモリ２５８は、メインＯＳ２６０、デバイスドライバ２６２、スタートア ップファイル２６４から成る。 電源が入ると、ＣＰＵ２５０はＯＳカーネルをブートＲＯＭ２５４からアップ ロードしＯＳ２６０の残りの部分をローカル記憶装置２５８であるディスクドラ イブから読み取る。ＯＳ作動が使用可能な後の段階の間は、デバイスドライバ２ ６２、スタートアップファイル２６４が使用可能である。ソフトウェアモジュー ルブロック２５２は、電源が入っている際に使用可能なソフトウェアモジュール を示す。ＯＳ２６０が使用可能な間は、コマンド受信モジュール９８、アクセス 制御モジユール９６、スケジューリングモジュール１０２、ロジカル・ツー・フ ィジカル・トランスレーション及びスペース割当モジュール１１０、変換モジュ ール２６８は使用可能である。デバイスドライバ２６２が使用可能な間、スクリ ーンドライバー１０４、ＣＤドライバー１０６、ＲＡＩＤドライバー２７０は使 用可能である。スタートアップファイルのイニシエーションの間、ボリューム制 御アプリケーション２６６と常駐アプリケーション１００は使用可能である。 図２Ｃは、図２Ｂで電源が入っている間に使用可能なソフトウェアモジュール 間の機能上の関係を示す。クライアント５４と物理的記憶装置６４、６６が示し てある。物理的記憶装置６４はファイルディレクトリ６２、アクセス制御表２０ ６、ボリューム制御表２０８、１からＮまでのブロックを含んでいる。物理的記 憶装置６６は自分自身のファイルディレクトリと１からＮまでのブロックを含ん でいる。クライアント５４はボリューム制御アプリケーション２６６、ロジカル Ｉ／Ｏブロック１５８、物理的Ｉ／Ｏブロック１６０を含んでいる。ロジカルＩ ／Ｏブロック１５８は、コマンド受信モジュール９８、アクセス制御モジュール ９６、ファイル変換モジュール２６８、ファイルディレクトリ１６６を含んでい る。物理的ブロック１６０はスケジューリングモジュール１０２、ロジカル・ツ ー・フィジカル・トランスレーション及びスペース割当モジュール１１０、デバ イスドライバ１０４−１０６、２７０を含んでいる。 作動状態であっても、ＯＳが初期設定されている間、デバイスドライバ２７０ は全面的に使用可能な訳ではない。従ってクライアント５４にとっては、物理的 装置６４は利用可能状態、即ち接続されているようには見えない。ボリューム制 御モジュール２６６は使用可能になると、一連のコマンドをコマンド受信モジュ ール９８に送る。このコマンドにより、ボリューム制御モジュール２６６がロッ ク記憶ドライバ２７０を発見することになる。この発見プロセスの間、ボリュー ム制御モジュールは物理的記憶装置６４上のアクセス制御表２０６とボリューム 制御表２０８をも発見する。この発見プロセスの間、ボリューム制御アプリケー ション以外の他のアプリケーションは、物理的記憶装置６４にアクセスしない。 ボリューム制御モジュール２６６がアクセス制御表２０６とボリューム制御表２ ０８から、アクセス特権とボリューム特権をそれぞれ読み取ると、次にボリュー ム制御モジュール２６６はファイルディレクトリ１６６にアクセス特権を書き込 むよう意図された一連のコマンドに携わる。例えば、クライアント５４が物理的 デバイス６４へ読み取り／書込アクセスすることをボリューム制御表が標示する と決められると、ボリューム制御モジュールは次にマウントＲ／Ｗコマンドを発 し、このコマンドをコマンド受信モジュールが受信すると、ファイルディレクト リ１６６は更新されこの特権が含まれることになる。続いて、ファイルディレク トリ１６６が物理的デバイス６４に書き戻されると、実際の物理的デバイス６４ 上に常駐するファイルディレクトリ６２も更新される。従って、アクセス特権と ボリューム特権はアクセス制御表とボリューム制御表から読み取られ、ボリュー ム制御モジュール２６６によってキャッシュされたファイルルディレクトリ１６ ６と物理的ファイルディレクトリ６２に書き込まれる。好適実施例中のデバイス の１つにのみ存在するアクセス及びボリューム制御表に基づいて、本プロセスを 複数の物理的デバイスに亘って実行することが可能であるが、これらの表を他の 場所に置くこともできる。 機能の観点から未だ論じていない残りのモジュールは、プロトコル変換モジュ ール２６８である。プロトコル変換モジュール２６８はアクセス制御モジュール ９６をファイルディレクトリ１６６にインタフェースし、一様なファイルディレ クトリ構造を、例えばクライアント５４、５６に存在しうる異種のＯＳに跨って 維持している。例えばクライアント５４は、マッキントシュシステム７のＯＳを 作動させ、クライアント５６は、ウィンドウズＮＴを作動させているかもしれな い。これら各クライアント上のプロトコル変換モジュール２６８は均質なファイ ルディレクトリ構造を強要し、本発明によるクロスプラットフォームを使用可能 にする。プロトコル変換モジュール２６８は、共通ＡＰＩの交信規則及びコマン ドフォーマットへ、交信規則変換及びコマンドフォーマット変換を提供する。従 って、ディレクトリとファイルを複数のＯＳにまたがってデータフォーマットの 形で記憶させることができる。このフォーマットは特定のＡＳＣＩＩ文字、ファ イル名に関する規定、特定の規定を有しているが、これについてはファイルディ レクトリとアクセス制御に関する図４の関係で詳述する。プロトコル変換ユニッ トがコマンドを受信すると、コマンドのタイプに対応する処理ルーチンを自身内 部から呼び出し、この処理ルーチンがコマンドを扱う。 図３Ａは、図２Ａ−Ｃに関連して先に述べたアクセス制御表２０６の詳細なデ ータ構造を示す。アクセス制御表のログドオンフィールド３５６は、どのユーザ ープロセス２１４−２１６（図２Ａ参照）が、アクセス制御表とボリューム制御 表に対してログオンされているかを標示する。あるユーザーがアクセス制御表に ログオンするまでは、そのクライアント上の如何なるアプリケーションも、デバ イスドライバーがデバイスドライバー２７０に似たロック制御を有するような如 何なる物理的デバイスにもアクセスできない（図２Ｃ参照）。アクセス及び制御 表は、各クライアントに関係したリフレッシュ通知フィールド３５８も有してい る。特定クライアントに関係したフィールド内のブール真条件は、システム上の 他ユーザーのアクセス特権に変化が起きた時、クライアントはその常駐ボリュー ム制御プロセスによって知らせを受けることを保証している。ブール偽条件は反 対の効果をもたらし、即ち、アクセス制御表のリフレッシュ通知フィールドにブ ール偽を有するクライアント上のボリューム制御プロセスは通知を与えることは ない。アクセス制御表は、クライアント間でメッセージを転送する能力を提供す る。フィールド３６０は要求メッセージを含んでいる。フィールド３６２とフィ ールド３５４は各々テキストベース及びブールベース応答メッセージを含んでい る。最後に、アクセス制御表はセマフォフィールド３５２を有している。セマフ ォフィールド内にセマフォが存在すれば、クライアント５４、５６の一方がアク セス制御表２０６とボリューム制御表２０８をそれぞれ制御していることを示し ていることになる。セマフォフィールド３５２に識別子を書き込んだクライアン トプロセスは各ボリュームに関係する特権を変更することができ、又書込状態中 に変化を開始させることができる。 図３Ｂはボリューム制御表２０８に関するデータ構造を示す。特に、表２０８ Ａ、２０８Ｂを示す。各ボリューム毎に１つのボリューム制御表が存在し、複数 ライターによる分散制御を支援する。制御記録２０８Ａ内のフィールドは全てサ フィクスＡで識別される。ボリューム制御表２０８Ｂで識別されるフィールドは 全てサフィクスＢを有する。フィールド３９０は特定のボリューム制御表に関係 するロジカルボリュームを識別する。フィールド３９０ＡはＲＡＩＤ記憶装置６ ４（図２Ａ参照）がボリューム制御表２０８Ａに関係していることを示す。フィ ールド３９０ＢはＣＤ−ＲＯＭ６６（図２Ａ参照）がボリューム制御表２０８Ｂ に関係していることを示す。フィールド３９２は、特定のボリュームが書込可能 であるか否かを示すブール真偽標示を含んでいる。フィールド３９２Ａは、ＲＡ ＩＤ装置６４（図２Ａ参照）が書込可能であることを示す。フィールド３９２Ｂ は、ＣＤ−ＲＯＭ６６（図２Ａ参照）が書込可能でないことを示す。フィールド ３９４は、現在どのクライアントが特定のボリュームに書込アクセスしているか を示す。フィールド３９４Ａは、クライアント５４（図２Ａ参照）が現在ＲＡＩ Ｄ記憶装置６４に書込アクセスしていることを示す。フィールド３９４Ｂは、ど のクライアントもＣＤ−ＲＯＭ６６（図２Ａ参照）に書込アクセスしていないこ とを示す。フィールド３８８は、どのクライアントが各特定のボリュームに対す るマウントアクセス特権を有しているかを示す。ブール真値は、クライアントが ボリュームをマウントできることを示す。ブール偽値はこの逆を示す。フィール ド３９６は各クライアントが現在のボリュームセッティングに対して変更を要求 する能力について示す。ブール偽値は、クライアントが変更要求、例えば読み取 り専用から読み取り／書込（又はその逆）に変更することから閉め出されていな いことを示す。ブール真値は、クライアントが変更要求することから閉め出され ていることを示す。フィールド３８４はブール真偽値であり、特定のボリューム に関して他のクライアントが変更を行った時に、読み取り専用の特権を有するク ライアントが更新されるか否かを示している。フィールド３８６はタイムスタン プであり、クライアントがファイルディレクトリ６２（図２Ａ参照）の更新コピ ーを最後に受信した時を示す。フィールド３８２はタイムスタンプであり、特定 のボリュームが何れかのクライアントによる最終の変更の時を示す。最終変更時 フィールド３８６をボリューム変更時フィールド３８２と比べることにより、プ ロセス２１４−２１６（図２Ａ参照）は、自動更新特権を有するクライアントが ファイルディレクトリリフレッシュをいつ必要とするか確認することができる。 以下に、ボリューム制御表とアクセス制御表に関する別の実施例の場合につい て、データ構造と機能コールをリストで示す。リストはこれらの表に関するデー タ構造要素の一部を示す。アクセス表は、ＳｔｕｄｉｏＢＯＳＳ＿ＤＢ＿Ｈｅａ ｄｅｒ１４ｘｘとＰａｒｔｉｔｉｏｎ Ｖｏｌｕｍｅ Ｒｅｃｏｒｄ‘ｓ１４ｘ ｘのアレイで構成される。Ｖｏｌｕｍｅ ＤＢ Ｈｅａｄｅｒ １４ｘｘ Ｖｏｌｕｍｅ ＤＢ Ｈｅａｄｅｒ １４ｘｘは、本発明の第一実施例のボリ ューム表の先頭に記憶されるが、実際の位置は変わってもよい。各フィールドを 以下に記載する。 Ｔａｂｌｅ Ｖｅｒｓｉｏｎ Ｎｕｍｂｅｒ １４ｘｘ 表フォーマットのバージョンナンバーを表す。現在の所ＳＢ＿ＤＢ＿ＶＥＲＳ ＩＯＮにセットされている。将来の互換性を狙ったものである。 Ｔａｂｌｅ＿Ｏｐｅｎ＿Ｃｏｕｎｔｅｒ １４ｘｘ 表が開けられた回数を追跡する。現在の所ＤＥＭＯコピーと共に使われ、ＤＥ ＭＯバージョンの満了に関する基準の１つを決定する(ＳＢ＿ＤＢ＿ＯＰＥＮＳ ＿ＵＮＴＩＬ＿ＥＸＰＩＲＥ １４ｘｘ参照)。 Ｔａｂｌｅ＿Ｗｒｉｔｅ＿Ｌｏｃｋｏｕｔ＿Ｓｅｍａｐｈｏｒｅ １４ｘｘ 表にアクセスしても安全であれば、ＭＡＸＩＭＵＭ＿ＵＳＥＲＳ １４ｘｘに セットされる。そうでない場合、セマフォを捕らえているユーザー番号にセット される。捕らえられている場合、表は信頼性がなく、表を変更してはならない。 Ｎｕｍｂｅｒ Ｏｆ Ｕｓｅｒｓ １４ｘｘ 表中に作成された全ユーザー数を示す。 Ｎｕｍｂｅｒ Ｏｆ Ｖｏｌｕｍｅｓ １４ｘｘ 表中の全ボリューム数を示す。 Ｕｓｅｒ＿Ｎａｍｅｓ［ＭＡＸＩＭＵＭ＿ＵＳＥＲＳ １４ｘｘ］１４ｘｘ 表中のユーザーの名前をパスカルストリングフォーマットで示す(長さバイト ＋文字)。注意：リスト中で次の名前を見つけるには、次の非零長ストリングの アレイを探すこと。 Ｕｓｅｒ＿Ｈａｓ＿Ｏｗｎｅｒ［ＭＡＸＩＭＵＭ＿ＵＳＥＲＳ １４ｘｘ］１４ ｘｘ ユーザーが有効ならＴＲＵＥに、そうでなければＦＡＬＳＥにセットする。 Ｕｓｅｒ＿Ｌｏｇｇｅｄ＿Ｏｎ［ＭＡＸＩＭＵＭ＿ＵＳＥＲＳ １４ｘｘ］１４ ｘｘ ユーザーが表にログオン中ならＴＲＵＥに、そうでなければＦＡＬＳＥにセッ トする。 Ｕｓｅｒ＿Ｒｅｆｒｅｓｈ＿ＤＢ［ＭＡＸＩＭＵＭ＿ＵＳＥＲＳ １４ｘｘ］１ ４ｘｘ 表ファイルを完全に閉鎖／再スタートせねばならぬ表の変更をユーザーに知ら せる必要がある場合、ＴＲＵＥにセットする(ユーザーのログオン等によってボ リュームが追加又は削除されたときなど)。 Ｕｓｅｒ＿Ｒｅｃｅｉｖｉｎｇ＿Ｒｅｑｕｅｓｔ １４ｘｘ 受信パーティのユーザー数であるか、そうでない場合はＭＡＸＩＭＵＭ＿ＵＳ ＥＲＳ １４ｘｘにセットされる。 Ｕｓｅｒ＿Ｓｎｄｉｎｇ＿Ｒｅｑｕｅｓｔ １４ｘｘ 送信パーティのユーザー数であるか、そうでない場合はＭＡＸＩＭＵＭ＿ＵＳ ＥＲＳ １４ｘｘにセットされる。 Ｖｏｌｕｍｅ＿Ｗｉｔｈ＿Ｒｅｑｕｅｓｔ＿Ｐｏｓｉｔｉｏｎ １４ｘｘ 要求を含んだボリューム記録のファイルのスタートからのインデックスである か、そうでない場合は０。 Ｒｅｑｕｅｓｔ＿Ｒｅｓｐｏｎｓｅ １４ｘｘ レスポンスが正でレスポンス＿メッセージが有効である場合、ＴＲＵＥにセッ トする。 Ｓｅｎｄｅｒ＿Ｍｅｓｓａｇｅ １４ｘｘ 要求の一部として送信者から受信者に送られるパスカル型ストリングのメッセ ージ。 Ｒｅｓｐｏｎｓｅ＿Ｍｅｓｓａｇｅ １４ｘｘ 要求の一部として受信者から送信者に送られるパスカル型ストリングのメッセ ージ。 ＤＢ＿Ｈｅａｄｅｒ＿Ｆｉｌｌｅｒ［４００］ 特別に確保してある。０にセットすべきものである。Ｐａｒｔｉｔｉｏｎ Ｖｏｌｕｍｅ Ｒｅｃｏｒｄ［ＭＡＸＩＭＵＭＶＯＬＵＭ ＥＳ １４ｘｘ］１４ｘｘ Ｖｏｌｕｍｅ＿ＤＢ＿Ｈｅａｄｅｒ １４ｘｘの後に、Ｐａｒｔｉｔｉｏｎ＿ Ｖｏｌｕｍｅ＿Ｒｅｃｏｒｄ‘ｓ １４ｘｘが続く。各フィールドを以下に記載 する。 Ｖｏｌｕｍｅ Ｉｎｆｏ １４ｘｘ 本フィールドはＰａｒｔｉｔｉｏｎ＿Ｖｏｌｕｍｅ＿Ｈｅａｄｅｒ １４ｘｘ 記録であって、表中の次のボリュームに関する情報を含んでいる。フィールドに 関する全体の記述を以下に掲げる。 Ｕｓｅｒｓ［ＭＡＸＩＭＵＭ ＵＳＥＲＳ １４ｘｘ］１４ｘｘ 本フィールドはＰａｒｔｉｔｉｏｎ＿Ｕｓｅｒ＿Ｒｅｃｏｒｄ １４ｘｘ記録 のアレイであって、ボリュームのＭＡＸＩＭＵＭ ＵＳＥＲＳ １４ｘｘ（２０ ０）ユーザーまでの情報を含んでいる。フィールドに関する全体の記述を以下に 掲げる。Ｐａｒｔｉｔｉｏｎ Ｖｏｌｕｍｅ Ｈｅａｄｅｒ １４ｘｘ Ｐａｒｔｉｔｉｏｎ＿Ｖｏｌｕｍｅ＿Ｈｅａｄｅｒ １４ｘｘ記録フィールド に関する記述を以下に掲げる。 Ｖｏｌｕｍｅ Ｎａｍｅ １４ｘｘ ボリューム名のパスカルストリング。 Ｗｒｉｔｅｒ Ｕｓｅｒ Ｎｕｍｂｅｒ １４ｘｘ ボリュームに対して書き込みアクセスを有するユーザー数。いない場合、ＭＡ ＸＩＭＵＭ ＵＳＥＲＳ １４ｘｘにセットする。 Ｖｏｌｕｍｅ Ｌａｓｔ Ｍｏｄｉｆｉｅｄ Ｔｉｍｅ １４ｘｘ ボリュームが変更されたことにソフトウェアが気付いた最後の時を含む。 Ｖｏｌ＿Ｈｅａｄｅｒ＿Ｆｉｌｌｅｒ［１００］１４ｘｘ 特別に確保してある。０にセットすべきものである。Ｐａｒｔｉｔｉｏｎ Ｕｓｅｒ Ｒｅｃｏｒｄ １４ｘｘ Ｐａｒｔｉｔｉｏｎ Ｕｓｅｒ Ｒｅｃｏｒｄ １４ｘｘの記録フィールドに 関する記述を以下に掲げる。 Ｕｓｅｒ Ｎｕｍｂｅｒ １４ｘｘ 表中のユーザー数である。ユーザーの［ＭＡＸＩＭＵＭ ＵＳＥＲＳ １４ｘ ｘ］アレイへのインデックスに等しくなければならない。 Ｗｒｉｔｅ Ａｃｃｅｓｓ １４ｘｘ ユーザーが読み取り／書込アクセスを有しているなら、ＴＲＵＥに、そうでな い場合はＦＡＵＬＳＥにセットされる。 Ｍｏｕｎｔ Ａｃｃｅｓｓ １４ｘｘ ユーザーが、アクセスするためボリュームをマウントして欲しいとしているな ら、ＴＲＵＥににセットされる。 Ａｕｔｏ＿Ｕｐｄａｔｅ １４ｘｘ ボリュームが変更に関して自動的にチェックされかつ更新されることをユーザ ーが欲するなら、ＴＲＵＥにセットされる。ＦＡＵＬＳＥにセットされると、下 記Ａｕｔo＿Ｕｐｄａｔｅ＿Ｃｈｅｃｋ＿Ｓｅｃｏｎｄｓ １４ｘｘは無効にな る。 Ａｕｔｏ＿Ｕｐｄａｔｅ＿Ｃｈｅｃｋ＿Ｓｅｃｏｎｄｓ １４ｘｘ Ａｕｔｏ＿Ｕｐｄａｔｅ １４ｘｘがＴＲＵＥならば、ボリュームが変更に関 し再度チェックされるまでに必要な秒数を表す。 Ｌａｓｔ Ｍｏｄｉｆｉｅｄ Ｔｉｍｅ １４ｘｘ ボリュームが変更されたことにユーザーが気が付いた最後の時を含む。 Ｒｅｓｅｒｖｅｄ[５０] 特別に確保してある。０にセットすべきものである。 各ホストコンピューターにはＰｒｅｆｅｒｅｎｃｅ＿Ｒｅｃｏｒｄ １４ｘｘ から成る優先ファイルが配置されている。この情報の目的は、各ホストが固有の ユーザー番号をボリューム表内に持てるようにして、各ホストがボリューム表に ログインし、各ファイルシステムに対し構成されるパラメータの自分自身のセッ トを持てるようにすることである。 Ｆｉｌｅ＿Ｓｉｇｎａｔｕｒｅ １４ｘｘ これは、以下の情報がＰｒｅｆｅｒｅｎｃｅ＿Ｒｅｃｏｒｄ １４ｘｘとして 依存できる有効なデータセットに最もふさわしいことを標示する固有の値に対し てセットされる。 Ａｄｍｉｎ＿Ｅｘｐｉｒｅｄ １４ｘｘ これはＴＲＵＥ又はＦＡＬＳＥの何れかにセットされる値であり、満了したソ フトウェアのＤＥＭＯコピーであるか否かを標示する。 Ｔｏｔａｌ ｔａｂｌｅｓ １４ｘｘ この値は、構成され先の検索で発見されたボリューム表の総数を標示する。こ れはネットスタートアップ時に発見されると自動的に期待される数である。 ＳＢ Ｐｒｏｃｅｓｓ Ｔｉｃｋｓ １４ｘｘ これは、ボリュームファイル制御ソフトウェア構成要素がユーザー事象又は表 変更のチェックをするために呼び出される各時間の間の時間値である。 Ｍｏｎｉｔｏｒ ＤＢ Ｔｉｃｋｓ １４ｘｘ これは、ボリュームファイル制御ソフトウェア構成要素が、他のユーザーから の書込アクセスに関する要求のような表変更に対しチェックを行うまでに経過す るにちがいない時間値である。 Ｕｓｅｒ Ｎａｍｅ １４ｘｘ これはボリューム表ログオンに際し検索される、ユーザー名を表示する文字ス トリングであり、これからユーザー番号が生成され後のアクセスに用いられる。 Ａｄｍｉｎ Ｐａｓｓｗｏｒｄ １４ｘｘ これは、このホストに対するボリュームファイル制御ソフトウェア構成要素の アドミニストレーター関数へのアクセスに必要な現在のパスワードを標示する、 文字ストリングである。 Ｖｏｌｕｍｅ＿Ｖｏｌｕｍｅ＿Ｎａｍｅｓ[ＭＡＸＩＭＡＭ＿Ｖｏｌｕｍｅ]１４ ｘｘ これは、ボリュームファイル制御ソフトウェア構成要素がボリューム表を検索 すべきファイルシステム名を標示する、文字ストリングのアレーである。 Ｐｒｅｆ Ｆｉｌｌｅｒ １４ｘｘ これは、将来の拡張のためのプレースフォルダであるバイトのアレーである。 Ｉｇｎｏｒｅ＿Ｂａｄ＿Ｍｏｕｎｔ １４ｘｘ これは、失敗したファイルシステムのマウント試行の間に、ユーザーにエラー を知らせるべきか否かを標示する、ＴＲＵＥ又はＦＡＬＳＥにセットできる変数 である。 Ｌｏｃｋｏｕｔ＿Ａｃｃｅｓｓ＿Ｃｈａｎｇｅ １４ｘｘ これは、ユーザーが、読み取り／書込特権を変更する要求のようなボリューム 表の変更を許されているか否かを標示する、ＴＲＵＥ又はＦＡＬＳＥにセットで きる変数である。ユーザーは如何なるセッティングの変更もできてはならないと 決められたら、アドミニストレーターはこれをセットすることができる。 Ｋｅｅｐ＿ＤＢ＿Ｖｏｌｕｍｅ＿Ｌｏｃｋｅｄ １４ｘｘ これはＴＲＵＥ又はＦＡＬＳＥにセットできる変数であり、ボリュームファイ ル制御ソフトウェア構成要素が、ボリューム表ファイルが配置されているファイ ルシステムをロックしているか否かを標示する。これはＴＲＵＥにセットされて いることが望ましいが、必要条件ではない。 Ｋｅｅｐ＿ＤＢ＿Ｖｏｌｕｍｅ＿Ｕｎｍｏｕｎｔｅｄ １４ｘｘ これはＴＲＵＥ又はＦＡＬＳＥにセットできる変数であり、ボリュームファイ ル制御ソフトウェア構成要素が、ボリューム表が配置されているファイルシステ ムをマウントされていないままにしておくべきか否かを標示する。これはＴＲＵ Ｅにセットされていることが望ましいが、必要条件ではない。 Ｖｏｌｕｍｅ Ｎｏｄｅ Ｒｅｃｏｒｄ １４ｘｘはボリュームファイル制御 ソフトウェア構成要素によってリンクされたリストの形式で使用されるデータ構 造であり、モニターされる各ファイルシステムのためのものである。 Ｎｅｘｔ Ｖｏｌｕｍｅ Ｎｏｄｅ １４ｘｘ これは、リンクされたリスト内の次のＶｏｌｕｍｅ＿Ｎｏｄｅ＿Ｒｅｃｏｒｄ １４ｘｘに対するポインターである変数である。 Ｖｏｌｕｍｅ Ｒｅｆｅｒｅｎｃｅ １４ｘｘ これはファイルシステムに対するリファランスであり、その内部演算システム 依存構造であるデータ構造である。それは、ロック／アンロックし、マウント／ アンマウントし、フリースペースや最終修正時間等の情報を発見するためにファ イルシステムにリファランスを付けるのに使われる。 Ｖｏｌｕｍｅ Ｃｈｅｃｋ Ｔｉｍｅｒ １４ｘｘ この変数は、満了の際には、ボリュームをリフレッシュする必要があるかどう かを見るためにボリュームをチェックする時間であることを標示するタイマーで ある。 Ｆｒｅｅ＿Ｍｅｇａｂｙｔｅｓ １４ｘｘ この変数はファイルシステム上のフリースペースの量を標示する変数である。 Ｖｏｌｕｍｅ Ｒｅｃｏｒｄ Ｐｏｓｉｔｉｏｎ １４ｘｘ この変数は、このファイルシステムをこのホストのために記述するボリューム 表内の位置の表示である。 Ｕｓｅｒ Ｒｅｃｏｒｄ Ｐｏｓｉｔｉｏｎ １４ｘｘ この変数は、このユーザー情報をこのホストのために表示するボリューム表内 の位置の表示である。 ＳＮ ＤＢ Ｆｉｌｅ Ｒｅｆｅｒｅｎｃｅ １４ｘｘ この変数は、ボリューム表それ自身へのアクセスに使われるリファレンスデー タ構造である。 Ｖｏｌｕｍｅ Ｅｎａｂｌｅｄ １４ｘｘ これは、ファイルシステムが使用可能か不可能かを標示する、ＴＲＵＥ又はＦ ＡＬＳＥ何れかである、変数である。使用不可能なファイルシステムはそれに関 する正常なモニタリング機能を何も有していない。これは使用不可能ボリューム は更新されず、必要であればリフレッシュされることを意味している。通常、ボ リュームは使用可能であり、ファイルシステムが正常なエンティティとしてシス テムに関与できるようにする。 ボリュームファイル制御ソフトウェア構成要素に全面的に有用なデータ構造を 以下に幾つか挙げる。 ＳＢ Ａｄｍｉｎ Ｐｒｅｆｅｒｅｎｃｅｓ １４ｘｘ このホストに対するＰｒｅｆｅｒｅｎｃｅ＿Ｆｉｌｅ＿Ｒｅｃｏｒｄ １４ｘ Ｘである。 Ｈｅａｄ Ｖｏｌｕｍｅ Ｎｏｄｅ １４ｘｘ 開始からのリストを検索するのに用いられるＶｏｌｕｍｅ＿Ｎｏｄｅ＿Ｒｅｃ ｏｒｄ １４ｘｘのリンクされたリストの開始に対するポインターである。 Ｔａｉｌ Ｖｏｌｕｍｅ Ｎｏｄｅ １４ｘｘ 新しい記録の挿入に用いられるＶｏｌｕｍｅ＿Ｎｏｄｅ＿Ｒｅｃｏｒｄ １４ ｘｘのリンクされたリストの最後に対するポインターである。 Ｃｕｒｒｅｎｔ Ｖｏｌｕｍｅ Ｎｏｄｅ １４ｘｘ モニターされている現在のＶｏｌｕｍｅ＿Ｎｏｄｅ＿Ｒｅｃｏｒｄ １４ｘｘ に対するポインターである。 Ｃｕｒｒｅｎｔ ＤＢ Ｈｅａｄｅｒ Ｐｔｒ １４ｘｘ ｃｕｒｒｅｎｔ＿Ｖｏｌｕｍｅ＿Ｎｏｄｅ １４ｘｘと標示される、モニター されている現在のファイルシステムをメインライン化している表の現在のＶｏｌ ｕｍｅ＿ＤＢ＿Ｈｅａｄｅｒに対するポインターである。 Ｃｕｒｒｅｎｔ ＤＢ Ｖｏｌｕｍｅ Ｈｅａｄｅｒ Ｐｔｒ １４ｘｘ モニターされている現在のファイルシステムに属する現在のＰａｒｔｉｔｉｏ ｎ Ｖｏｌｕｍｅ Ｈｅａｄｅｒ １４ｘｘに対するポインターである。 Ｃｕｒｒｅｎｔ ＤＢ Ｕｓｅｒ Ｒｅｃｏｒｄ Ｐｔｒ １４ｘｘ モニターされている現在のファイルシステムに属する現在のＰａｒｔｉｔｉｏ ｎ＿Ｕｓｅｒ＿Ｒｅｃｏｒｄ １４ｘｘに対するポインターである。 ＳＢ Ｐｒｏｃｅｓｓ Ｔｉｍｅｒ １４ｘｘ 満了時には、次のファイルシステムをチェックする時間であることを標示する タイマーである。 Ｍｏｎｉｔｏｒ ＤＢ Ｔｉｍｅｒ １４ｘｘ 満了時には、保留されている表の要求の何れをもチェックするｓｉｓ時間であ ることを標示する、タイマーである。 Ａｄｍｉｎｉｓｔｒａｔｉｏｎ Ｍｏｄｅ １４ｘｘ 何時ボリュームファイル制御ソフトウェア構成要素がユーザーの利用可能なア ドミニストレーター関数と共に作動しているかを標示する、ＴＲＵＥ又はＦＡＬ ＳＥの何れかである変数である。 Ｒｅｓｔａｒｔ Ｖｏｌｕｍｅ １４ｘｘ 全ての表をログアウトしてログインし直す、遮断と再開の時間であるかを標示 する、ＴＲＵＥ又はＦＡＬＳＥの何れかである変数である。 Ｓｕｓｐｅｎｄ＿Ｏｐｅｒａｔｉｏｎｓ １４ｘｘ 全てのファイルシステム及び表のモニタリングを中断すべきかを標示する、Ｔ ＲＵＥ又はＦＡＬＳＥの何れかである変数である。 図４は本発明を利用した両クライアントＡ−Ｂ上で実行される一様ファイルデ ィレクトリフォーマットに関する詳細なデータ構造線図である。本ディレクトリ 構造は、各クライアント上のＯＳに妨げられることなく、図２Ｃに述べたプロト コル変換モジュール２６８によって維持することができる。図４はファイルディ レクトリ６２及び記憶装置６４に対する物理アドレスマップ４５２を示す。ファ イルディレクトリ６２はボリュームヘッダー４５４、ディレクトリ記録４５６、 ファイル記録４５８、ファイル位置記録（エクステント）４６０から成る。本デ ィレクトリ構造は一般的に、マッキントッシュコンピュータにより提供されてい るシステム８ＯＳに関するＨＦＳファイルディレクトリフォーマットに関係して いる。ボリュームヘッダー４５４は、ボリューム名、作成日、更新日、ソフトウ ェアロック、属性と特権に関するリスト、ボリューム可用性ビットマップ、物理 的ボリュームを広範に定義付けする他の多くのパラメータを有している。ボリュ ーム記録４５４には、その記録４５６が参照される複数のディレクトリ記録が関 係している。各ディレクトリ記録は、親ディレクトリに対するポインタ、名称、 作成時、更新時を含んでいる。その次は、そのファイル記録４５８が参照される 各ディレクトリに関係する複数のファイル記録である。各ファイル記録は名称、 タイプ、ロックインジケーター、作成された時、更新された時、ファイルレベル の他の情報を含んでいる。各ファイル及びディレクトリ記録に関係して、複数の ファイル位置記録が存在し、このファイル位置記録に関しては記録４６０が参照 される。各ファイル位置記録は、ファイルが始まる物理的アドレスに対するポイ ンタと、ファイル長さに関する標示を含んでいる。ファイルが不連続なセグメン トに記憶されている場合、ファイルの次の部分の物理的アドレスと当該部分の長 さを示すオーバーフローインジケーターが存在する。物理的アドレス記録４５２ に示されているように、ファイル位置記録アドレスとアドレス長は、ファイル内 容の実際の物理的アドレス位置に対応する。例えば、ファイル位置記録４６０で は、ファイル１は物理的アドレス１０００で始まり、４４セクター長を持ってい るとリスとされている。物理的アドレス記録４５２では、ファイル１は物理的メ モリアドレスが１０００から始まり１０４４まで伸びており、全体で４４セクタ の長さである。各ＯＳは固有のファイルディレクト構造を有し、その構造は図４ に開示したものとは多くの面で異なっている。図２Ｃで述べた本発明の好適実施 例の場合、各クライアントプロセス２１４、２１６に関係するプロトコル変換モ ジュール２６８は、各クライアント上のＯＳに妨げられることなく、一様なファ イルディレクトリフォーマットを要求する。このお陰で、クライアント上に存在 するＯＳに妨げられることなく、いずれのクライアント上の如何なるアプリケー ションの間でもクロスプラットフォーム互換性が保証される。従って、マッキン トシュシステム８のＯＳを作動させるクライアントでも、ウィンドウズＮＴのＯ Ｓを作動させる別のクライアントが作成したファイルに対して読み取り又は書込 ができる。 図５Ａ−Ｅは、図２ＡのクライアントＡ、Ｂに関係したプロセス２１４、２１ ６を示す。各クライアントは図５Ａ−Ｅに示した全機能を実行する。 パワーアップとログオンに関係するプロセスを図５Ａに示す。プロセス５００ に始まり、デバイスドライバーとボリューム制御プロセスがクライアントにロー ドされる。制御は次にプロセス５００に移行し、ここではロッキング機能を含む ようカスタマイズされたデバイスドライバーが配置される。更に、ボリューム制 御表とアクセス制御表（図２Ｃ参照）を含む物理的ボリュームに接続された特定 のデバイスドライバーが識別される。制御は次に決定プロセス５０４に移る。決 定プロセス５０４では、ボリューム及びアクセス制御表が作成されているか否か の決定が下される。決定が否定の場合、制御は次にプロセス５０６に移行し、ボ リューム制御プロセスはアクセス及びボリューム制御表を作成するテンプレート を、アドミニストレーターに提供する。制御は次にプロセス５０８に移行し、新 たに作成されたアクセス及びボリューム制御表は、カストマイズされたロック可 能ドライバーを有するボリューム上に記憶される。制御は次に決定プロセス５１ ２に移行する。決定プロセス５０４で決定が肯定、即ちボリューム制御表が存在 するとなった場合、制御はプロセス５１２に直接移行する。 決定プロセス５１２では、セマフォフィールド３５２（図３Ａ参照）が空であ るか否かの決定が下される。決定が否定の場合、制御はプロセス５１０に移行し 遅延を導入した後、遅延インターバル制御は決定プロセス５１２に戻る。決定プ ロセス５１２で肯定の決定が下された場合、即ちアクセス制御表２０６（図２Ａ 参照）のセマフォフィールド３５２が空であるとなった場合、制御はプロセス５ １４に移行する。プロセス５１４でクライアント識別子はセマフォフィールドに 書き込まれる。次に制御はプロセス５１６に移行し、アクセス及びボリューム制 御表を捕らえたクライアントはボリューム制御表とアクセス制御表を読み取る。 次に制御は決定プロセス５１８に移行する。決定プロセス５１８ではフィールド ３５２内のクライアント識別子がプロセスを実行するクライアントのＩＤである か否かのついての決定が下される。決定が否定の場合、クライアントはボリュー ム制御表とアクセス制御表を捕らえていないことになる。従って制御は決定プロ セス５１２に移行する。決定が肯定の場合、クライアントはボリューム制御表と アクセス制御表を捕らえているとの決定が、決定プロセス５１８で下され、制御 は次にプロセス５２２に移行する。プロセス５２２で、クライアントはボリュー ム制御表とアクセス制御表を読み取る。制御は次にプロセス５２０に移行する。 プロセス５２０で、クライアントはＩＤをアクセス制御表２０６のフィールド３ ５６（図３Ａ参照）上の対応するログに書き込む。制御は次にプロセス５２４に 移行する。プロセス５２４でクライアントは、ボリューム制御表とアクセス制御 表をその識別子をセマフォフィールド３５２から除去することにより解放する。 制御は次にプロセス５２６に移行し、アクセス制御モジュール２６６（図２Ｃ参 照）は各物理的デバイスのアクセス特権を、本プロセスを実行する特定クライア ントのためのアクセス及びボリューム制御表に標示されているこれら特権に従っ てセットする。図２Ｃで先に述べたように、これらの特権は、マウントボリュー ムコマンドをコマンド受信モジュール９８に送るボリューム制御プロセスでセッ トされ、読み取り特権又は読み取り／書込特権のいずれかを有している。制御は 次に接続ブロックＡに移行する。 図５Ｂは、ファイルシステム又はボリュームに対する書込特権を要求するクラ イアント上で実行されるプロセスを示す。接続ブロックＡに始まる制御は、決定 プロセス５５０に移行する。決定プロセス５５０では、書込要求がボリューム制 御プロセス２６６（図２Ｃ参照）により受信されたか否かについて決定が下され る。ボリューム制御プロセスは本書込要求を、グラフィカルユーザーインタフェ イス（ＧＵＩ）経由でいつでも受信できる。ＧＵＩにより、ユーザーは自分が読 み取り特権を有する特定ボリュームを選択でき、又そうした特権を書込特権に変 更するよう要求することができる。代わりに、別のプロセス経由で書込要求をプ ログラムすることもできる。決定が否定、即ちボリューム制御プロセスで書込要 求が受信も生成もされていない場合、制御は接続ブロックＤに移行する。決定プ ロセス５５０で肯定となった場合、制御は決定プロセス５５４に移行する。決定 プロセス５５４では、アクセス制御表（図３Ａ参照）内のフィールド３５２にセ マフォアがあるか否かについて決定が下される。この決定が否定の場合、制御は プロセス５５２に移行し、ポーズが導入される。次に制御は決定プロセス５５４ に戻る。決定プロセス５５４で肯定となった場合、制御はプロセス５５６に移行 し、書込コマンドが発行され、プロセスを実行するクライアントの識別子がフィ ールド３５２に書込まれる。次に制御はプロセス５５８に移行する。プロセス５ ５８でフィールド３５２の値が読み取られる。次に制御は決定プロセス５６０に 移行する。決定プロセス５６０では、フィールド３５２の値がプロセスを実行す るクライアントＩＤに対応するか否かについて決定が下される。本決定が否定の 場合、制御は決定プロセス５５４に戻る。決定プロセス５６０で肯定の決定にな った場合、制御は決定プロセス５６２に移行する。決定プロセス５６２では、書 込要求がなされているボリュームをこの特定クライアントがマウントできるか否 かについて、マウントアクセスフィールド３８８（図３Ｂ参照）に基づいて決定 が下される。この決定が否定の場合、制御はプロセス５７０に移行し書込要求が 拒否された旨の通知が出される。制御は次に接続ブロックＤに移行する。決定プ ロセス５６２で、プロセスを実行するクライアントに関してボリュームがマウン トできる旨の決定が下された場合、制御は決定プロセス５６４に移行する。決定 プロセス５６４では、このクライアントが特定ボリュームへの書込アクセスを得 られるか否か又はクライアントが要求アクセスから閉め出されているか否かにつ いて、マウントアクセスフィールド３９６（図３Ｂ参照）に基づいて決定が下さ れる。決定が肯定、即ちクライアントは書込アクセスを得られない場合、制御は 上記のプロセス５７０に移行する。決定プロセス５６４での決定が否定、即ちク ライアントはボリュームへの書込アクセスを得ることから閉め出されていない場 合、制御は決定プロセス５６６に移行する。決定プロセス５６６では、現在のラ イターがネットワークから事実上ログオフしているか否かについて、フィールド ３９４（図３Ｂ参照）とフィールド３５６（図３Ａ参照）に基づいて決定が下さ れる。この決定が肯定の場合、制御は次にプロセス５７２に移行し、ボリューム に対する取り外しコマンドが発行される。制御は次にプロセス５７４に移行し、 マウントボリュームコマンドがボリューム制御プロセス２６６（図２Ｃ参照）に よりコマンド受信モジュール９８に送られる。こうして最新の変更を反映したボ リュームがマウントされることになる。制御は次にプロセス５７６に移行し、ボ リューム制御表中のフィールド３９４（図３Ｂ参照）がプロセスを実行するクラ イアントＩＤで更新される。制御は次にプロセス５７８に移行し、クライアント はアクセス制御表とボリューム制御表を、そのセマフォ、即ちＩＤをボリューム 制御表のセマフォフィールド３５２（図３Ａ参照）から除くことにより、解放す る。制御は次に接続ブロックＤに移行する。 決定プロセス５６６で、現在のライターがネットワークからログアウトしてい ない旨の決定がなされると、制御はプロセス５６８に移行する。プロセス５６８ では、書込要求がアクセス制御表の要求フィールド３６０（図３Ａ参照）に書き 込まれる。この要求は、書込要求が向けられるボリュームの識別子、要求を行っ ているクライアント識別子、要求者からのテキストメッセージを含んでいる。書 込要求が向けられるボリュームの識別子は、ボリューム記録のフィールド３９４ から読み取られる。テキストメッセージは、ボリューム制御プロセス２６６（図 ２参照）が提供するＧＵＩインタフェイス中に手動で入力できる。制御は次に決 定プロセス５８０に移行する。決定プロセス５８０では、応答メッセージ３６２ と応答ブールフィールド３５４（図３Ａ参照）が読み取られ、現在のライターが 書込特権を放棄したか否かについての決定が、これらのフィールドに基づいて下 される。この決定が肯定の場合、制御は先に論じたプロセス５７４に移行する。 この決定が否定の場合、制御はプロセス５７８に移行し、そこで現在の要求者は そのＩＤをアクセス制御表のセマフォフィールド３５２（図３Ａ参照）から取り 除き、次に制御は接続ブロックＣに移行する。 図５Ｃは書込アクセス特権を要求する別のクライアントに対する応答に接続 されたプロセスを示す。プロセス部分は接続ブロックＢから始まり、制御はプロ セス６００に移行する。プロセス６００では、アクセス制御表と特定要求メッ セージフィールド３６０（図３Ａ参照）が読み取られる。制御は次に決定プロセ ス６０２に移行する。決定プロセス６０２では要求に関係するクライアントＩＤ がプロセスを実行するクライアントＩＤに対応しているか否かが決定される。決 定が肯定、即ちプロセスを実行するクライアントが要求の向けられたクライアン トである場合、制御は決定プロセス６０４に移行する。決定プロセス６０４では 、この特定クライアントに対して自動応答機能が使用可能であるか否かが決定さ れる。ある好適実施例では、アクセス制御表２０６（図３Ａ参照）内の別のフィ ールドエントリに基づいてこの決定を下すことができる。この実施例には各クラ イアントに対応するフィールドがあり、そこで、ブール真条件は自動応答が使用 可能であったことを示し、ブール偽条件は自動応答が使用可能でなかったことを 示すことになる。決定プロセス６０４で、自動応答が使用可能であったという決 定が下された場合、制御は決定プロセス６１０に直接移行する。決定プロセス６ １０では、クライアント上の現在の処理に基づいて、その時に制御を放棄できる か否かについての決定が下される。例えばクライアントが大量のレンダリングプ ロジェクトを行っている最中であるなら、否定の決定が下るであろう。否定の決 定の場合、制御は決定プロセス６１４に移行する。プロセス６１４では、応答す るクライアントは、アクセス制御表の応答メッセージフィールド３６２（図３Ａ 参照）にブール偽条件を書き込むことになる。制御は接続ブロックＤに移行する ことになる。 決定プロセス６０２で、要求に関係するクライアントＩＤがプロセスを実行す るクライアントＩＤでなかった旨の決定が下されると、制御は接続ブロックＤに 直接移行することになる。 決定プロセス６０４で、要求がプロセスを実行するクライアントで作られてお り(プロセスブロック６０２がイエスの場合)、更に自動応答機能が使用可能でな かった旨の決定が下されると、制御はプロセス６０６に直接移行することになる 。プロセス６０６では、ボリューム制御プロセス２６６（図２Ｃ参照）のＧＵＩ 部が、メッセージプロンプトをユーザーに提供する。ユーザーは、要求にイエス ・ノーを回答するか、テキストベースのメッセージに応答するかの選択肢を提供 される。この応答は応答メッセージフィールド３６２とブール応答フィールド ３５４（図３Ａ参照）に書き込まれることになる。制御は次に決定プロセス６０ ８に移行する。決定プロセス６０８では、ユーザーが書込特権を放棄したか否か についての決定が下される。肯定の決定の場合、制御は決定プロセス６１６に移 行する。決定プロセス６１０で、書込制御を現時点では放棄できない旨の決定が 下される場合も、制御はプロセス６１６に移行する。プロセス６１６では、ブー ル真条件がアクセス制御表と特定のブール応答フィールド３５４（図３Ａ参照） に書き込まれる。これは、要求を受信し現在書込特権を有するクライアントがこ れらの特権を解放しようとしていることを示す。制御は次にプロセス６１８に移 行する。プロセス６１８では、要求されたボリューム上の全てのファイルが閉じ られ、読み取り及び書込アクセスに関するボリュームは取り外され、読み取り専 用アクセスモードに再マウントされる。制御は次に接続ブロックＤに移行する。 決定プロセス６０８で、ユーザーは要求ボリュームに対する書込特権を放棄し ないという選択をしている旨の決定が下されると、制御は次にプロセス６１２に 移行する。プロセス６１２では、ブール偽条件がアクセス制御表とその特定のブ ール応答フィールド３５４（図３Ａ参照）に書き込まれる。制御は次に接続ブロ ックＤに移行する。 図５Ｄは、書込特権をファイルシステムへの実際の書込アクセスに変換するこ とに関係したプロセス部分を示している。プロセス部分は接続ブロックＣに始ま り、制御は決定プロセス６５０に移行する。決定プロセス６５０では、ボリュー ム制御表内のフィールド３９２（図３Ｂ参照）に基づいて、書込要求の向けられ ているボリュームが実際に使用可能であるか否かについての決定が下される。こ の決定が否定の場合、制御はプロセス６６６に移行し、ボリューム制御プロセス ２６６（図２Ｃ参照）のＧＵＩインタフェイス部分が、当該ボリュームは使用不 可能であり書込アクセスを提供できない旨を示すメッセージをユーザーに提供す る。制御は次に接続ブロックＢに移行する。決定プロセス６５０で肯定、即ち書 込要求の向けられているボリュームが実際に使用可能である旨の決定が下ると、 制御は次に決定プロセス６５２に移行する。決定プロセス６５２では、プロセス を実行するクライアントに対してボリュームがマウントされているか否かについ ての決定が下される。この決定が否定の場合、制御はプロセス６５８に移行し、 ボリューム制御プロセス２６６（図２Ｃ参照）は読み取り書込特権付きのマウン トコマンドをコマンド受信モジュール９８に送る(図２Ｃ参照)。この結果、読み 取り書込特権付きのボリュームがマウントされる。制御は次に決定プロセス６５ ４に移行する。決定プロセス６５２で肯定、即ち読み取り特権又は読み取り／書 込特権何れかの付いたボリュームがマウントされている旨の決定が下ると、制御 は決定プロセス６５４に移行する。決定プロセス６５４では、この特定ボリュー ムに関してファイルディレクトリーレベルでソフトウェアロックビットが使用可 能であるか否か、及び当該ソフトウェアロックビットがボリュームへのアクセス を妨げるか否かについての決定が下される。この決定が肯定の場合、制御はプロ セス６６０に移行する。プロセス６６０では、ソフトウェアロック及びファイル ディレクトリがバイパスされるか或いは使用不能にされる。ある好適実施例では 、ソフトウェアロックをバイパスするのが好ましい。そうすることにより、ボリ ューム制御プロセスフォームを有していないネットワーク上のクライアントが制 御されたボリュームにうっかりアクセスするのを防ぐ利点が得られる。制御は次 にプロセス６５６に移行する。プロセス６５４で、ソフトウェアロックがファイ ルディレクトリレベルに存在しないか、或いはファイルディレクトリレベルのソ フトウェアロックをボリューム制御プロセス２６６のコマンドによってバイパス できるかの何れかの決定が下されると、制御は決定プロセス６５６に直接移行す る。 決定プロセス６５６では、読み取り及び書込特権付きのボリュームが現在マウ ントされているか否かに付いての決定が下される。この決定が否定の場合、制御 はプロセス６６２に移行し、そこでボリューム制御プロセス２６６がコマンド受 信モジュール９８（図２Ｃ参照）に、要求されたボリュームに関するボリューム 取り外しコマンドを次に読み取り／書込特権付きのマウントコマンドを送る。こ れにより、読み取り／書込特権付きのボリュームをクライアントに関して再マウ ントすることになる。制御は次に接続ブロックＤに移行する。決定プロセス６５ ６での決定が肯定、即ちボリュームがマウントされしかも読み取り／書込特権付 きでマウントされている場合、制御は接続ブロックＢに直接移行する。図５Ｄの プロセスによってもたらされるファイルディレクトリ内の変更は、書込アクセス が提供されたボリュームに対応するファイルデイレクトリ１６６のキャッシュさ れたコピー内でまず立証される（図２Ｃ参照）。次にキャッシュされたコピーの 更新はフラッシュバックされるか物理的デバイス６４上のファイルディレクトリ に書き戻されるかして、結果的に一貫性のあるファイルディレクトリのセットと なり、このセット中で新たなアクセス特権が立証される。 図５Ｅは、読み取り専用ボリュームに関係するプロセス部分を含んでいる。ボ リュームに対して読み取り専用状態でマウントされたクライアントは、当該ボリ ュームに対して起こるファイルディレクトリ内の変更、即ちシステム上の他のク ライアントに関係して当該ボリュームに書込がなされた時でも、更新されること がない。従って自動更新能力を欲するクライアントに対して、図５Ｅのプロセス によってその能力が与えられる。プロセスは接続ブロックＤに始まり、制御は決 定ブロック７００に移行する。決定ブロック７００では、ボリューム制御表のフ ィールド３８４（図３Ｂ参照）に基づいて、クライアントが現在読み取り専用状 態で接続されている全てのボリュームが自動更新を示しているか否かについての 決定が下される。こうしたボリュームの各々に関し、この特定クライアントに対 する最新変更時期フィールド３８６（図３Ｂ参照）がプロセス７０２で読み取ら れ、フィールド３８２（図３Ｂ参照）と比較される。このプロセスの目的は以下 の通りである あるボリュームに対する読み取り特権を有するクライアントは当該ボリューム に対するファイルディレクトリーのローカルのキャッシュされたコピーをリフレ ッシュしない。その結果、コピーは古くなり、即ち、もはや存在しないディレク トリ／ファイルを示すか、或いは実際に存在するディレクトリ／ファイルを示さ ないかの何れかが起こりかねない。従って、読み取り専用アクセスを有するクラ イアントは、他のクライアントがボリュームを変更した時には自分のキャッシュ されたディレクトリーコピーを定期的にリフレッシュさせるオプションを持てる ことが重要となる。このリフレッシュと更新のオプションを提供するのがフィー ルド３８４（図３Ｂ参照）である。リフレッシュ／更新が必要か否かに関する決 定は、制御が次に移行するプロセス７０４、７０６でなされる。プロセス７０４ では、最後のボリューム変更に関するタイムスタンプ即ちフィールド３８２と、 ファイルディレクトリの新しいコピーを得るためにクライアントがディスマウン トとマウントを行った最後の時即ちフィールド３８６との間で比較が行われる。 決定プロセス７０６では、クライアントのキャッシュされたディレクトリコピー が古いか否かについての決定が下される。この決定が否定の場合、クライアント はボリューム上にあるファイルディレクトリの最新のコピーを有していることに なる。更新は不必要なので制御は接続ブロックＡに移行する。決定プロセス７０ ６で決定が肯定、即ちキャッシュされたファイルディレクトリ１６６（図３Ｂ参 照）が古いと決定された場合、制御は決定プロセス７０８に移行する。決定プロ セス７０８では、アクセス制御データベースセマフォフィールド３５２（図３Ａ 参照）が空であるか否かについて決定が下される。この決定が否定の場合、制御 はプロセス７１０に移行する。決定プロセス７１０ではポーズが導入された後、 制御はプロセス７０８に戻る。決定プロセス７０８でセマフォフィールド３５２ が利用可能である旨の決定が下されると、制御はプロセス７１２に移行して、ク ライアントＩＤがアクセス制御表２０６（図３Ａ参照）セマフォフィールドに書 き込まれる。次に制御はプロセス７１４に移行し、アクセス制御表のセマフォフ ィールド部分が読み取られ、次に制御は決定プロセス７１６に移行する。決定プ ロセス７１６では、セマフォフィールドに存在するクライアントＩＤが本プロセ スを実行するクライアントのＩＤと同一か否かについて決定が下される。この決 定が否定の場合、クライアントはアクセス制御表を捕らえていないことになり、 処理は決定プロセス７０８に戻る。この決定が肯定、即ちクライアントがアクセ ス制御表を捕らえている場合、制御はプロセス７１８に移行する。プロセス７１ ８では、ボリューム制御プロセス２６６が、コマンド受信モジュール９８（図２ Ｃ参照）に、先ずボリューム取り外しコマンドを次に読み取り／書込特権付きの マウントコマンドを送る。これにより、更新されたファイルディレクトリ１６６ のコピーがプロセス７２０でユーザーに表示されることになる。ユーザーへの表 示は全ボリュームと当該ボリュームに関係する全クライアントの状態に関する情 報、即ちマウント／ディスマウント、読み取り専用、読み取り／書込、ロック／ アンロックを含んでいてもよい。次に制御は接続ブロックＡに移行する。 分散データベース 図６は従来技術によるクライアントデータベースサーバの構成である。ハード ウェア構成要素としてクライアント５４−５６、サーバ６０、記憶装置６４が含 まれる。各々複数のフィールドを有する複数記録のデータベース７５４は記憶装 置６４に記憶され、同記憶装置はＳＣＳＩ接続によりサーバ６０に接続される。 サーバ６０はＬＡＮ経由でクライアント５４、５６両方に接続される。クライア ント５４、５６の何れかが照会を開始すると、照会に応えてサーバ６０はデータ ベース機能７５０を実行する。次にサーバ６０は、物理的装置６４上に記憶され ているデータベースのコピーを得て、クライアントの照会に一致する記録を探す ため記録をソートする。次にサーバは照会に一致する記録のみをクライアントに 提供する。この従来技術によるアーキテクチュアの利点は、データベースをソー ト探索するという膨大な作業を高速サーバにまかせ、高価でないクライアントの ワークスステーションが照会プロセスに携われるようになる点である。 図７は、本発明の別の実施例を示しており、ここでは共有資源であるデータベ ースは、直接接続しているクライアント全てにより分散管理される。本アーキテ クチャの利点は、データベースが記憶されている物理的装置とデータベースにア クセスするクライアントとの間を仲介するサーバを必要としない点である。本ア ーキテクチャの不利な点は、各クライアントが一揃いのデータベースエンジンを 実行することを要求することである。にもかかわらず、データベースが一連のフ ィールドからなり、各フィールドが膨大な画像、動画、音声ファイルのポインタ を有するような、ある種のデータベースアプリケーションでは、本発明を有利な ものとして利用できる。この例では、各クライアントの処理時間が、転送される 画像音声ファイル又は動画に対するポインターを見つけだして行われる実際の照 会及び分類プロセスに際して行われるよりも、より密接に画像転送プロセスに関 連している。このような条件の下では、隘路となるサーバーのない方が有利であ る。又、この実施例を修正して、(ＬＡＮでクライアントに接続されている)多数 の従来型サーバー全てを共有の記憶装置に直接接続するようにすれば、全サーバ ーが（従って全クライアントが）アクセスできる単一の場所に全てのデータが記 憶されることになり、データの可用性が高くなる。 図７の構成要素には、各々クライアントＡ、Ｂとラベルの付けられたクライア ント５４、５６と、サーバー６０と、記憶装置６４が含まれる。データベース８ ０４は物理的記憶装置６４上に常駐しており、本発明のこの実施例を実行するの に適した追加のフィールドを含んでいる。この追加のフィールドは、以下の図９ Ａ、９Ｂに詳細に記載する。記憶装置６４は各クライアントＡ、Ｂに直接接続さ れている。ネットワーク接続は例えば図２Ａで記述し論議したようにファイバー チャネルであってもよい。このタイプのネットワークは記憶装置６４と各クライ アントの間に非常に高い帯域の交信経路を提供する。これにより、ビットマップ された画像、動画、サウンドクリップを、削除のマーク２１２で示したように取 り除かれたサーバーに邪魔されることなく、迅速に転送できるようになる。クラ イアント５４、５６は各々データベースソーティングインデックスのキャッシュ コピーを含んでいる。ソーティングインデックス８００、８０２は各々クライア ント５４、５６に関連している。これらのインデックスは実際の物理的装置６４ 上に記憶されているメインインデックスから定期的にリフレッシュされる。クラ イアント５４、５６は各々、エンハンスされたデータベースプロセス８０８、８ １０を実行する。照会、マッチング、ロッキングという正規のデータベース機能 に加え、これらのプロセスには記録ロッキング、記録更新、ボリューム制御の機 能が含まれており、これらを詳細に論議することとする。個々の記録及び１つの 記録内のフィールドへのデータベースアクセスの一貫性は、クライアント常駐の プロセス８０８、８１０と、アクセス制御表２０６、ボリューム制御表２０８、 更新リスト８０６との間の対話によって維持されるが、これらの表及びリストは 全て物理的装置６４内のボリュームにに常駐しており、このボリュームには全て のクライアントがアクセスできる。 図８Ａにアクセス制御表２０６の詳細なデータ構造を示す。アクセス制御表は 図３Ａで説明、議論したものと同じである。このアクセス制御表は以下の図１２ Ｆで議論するプロセスに利用される。 図８Ｂに、データベース８０４（図７参照）がソートされる読み取りボリュー ムと関係するボリューム制御表の詳細なデータ構造を示す。ロックアウトフィー ルド３９６Ａに、クライアント５４及び５６各々が、両者がそのボリュームに対 する書込特権を持っていることを意味するブール偽値で標示されていることに注 目されたい。更に、クライアントＡ及びＢは双方ともフィールド３９４Ａ内で同 時書込特権を持っているものとして識別されている。 図８Ｃに、更新リスト８０６（図７参照）の詳細なデータ構造を示す。更新リ ストは各クライアントフィールド８３０に対し、クライアントが編集しているフ ィールドに関係する対応する記録ポインター８３２を含んでいる。このリストは エンハンスされたデータベースプロセス８０８、８１０（図７参照）が、フィー ルドに対する更新を、対応する記録を現在参照しているクライアント全てに同報 通信するために利用する。フィールド８３２に示すように、クライアント５４、 ５６の双方は記録２内のフィールドを現在参照している。 図９Ａに、図７で議論したデータベース８０４の関係データベース実施例８０ ４Ａに関連する詳細なデータ構造を示す。この関係データベースには、名称表８ ０４Ａ−１、ワークアドレス表８０４Ａ−２、ホームアドレス表８０４Ａ−３が 含まれる。表は各々複数のフィールドを含んでおり、各フィールドに対し対応す るロックフィールドがある。表８０４Ａ−１内には、各記録に対する接頭語及び 最終名称フィールドがある。ロックフィールド８５６は接頭語フィールドの各々 に、ロックフィールド８５８は最終名称フィールドに関連する。ワークアドレス 表内には各記録に対してストリートフィールドとシティフィールドがある。スト リートフィールドの各々には対応するフィールドロック８６２が関係する。シテ ィフィールドの各々にはフィールドロック８６４が関係する。ホームアドレス表 ８０４Ａ−３は各記録に対するストリートフィールドとシティフィールドの両方 を含む。ストリートフィールドは対応するロックフィールド８６８を有する。シ ティフィールドは対応するロックフィールド８７０を有する。各表中の各記録に はフリーフィールド８６０、８６６、８７２が関係し、これは２つの状態、即ち アクティブかフリーかの何れであるかを標示する。アクティブの印が付けられた フリーフィールドを有する記録は有効なデータを含む。フリーの印が付けられた フリーフィールドを有する記録はデータを含んでおらず、新しい記録の追加に使 用できる。削除の印が付けられたフリーフィールドは、データベースの記憶要件 を低減するためにデータベースから物理的に削除するように決められた記録を含 んでいる。それ故、データベースからの記録の削除は、記録にフリーと印を付け るか削除の印を付けるかの何れかで行うことができる。データベースに記録を追 加するには、フリーフィールドをアクティブフィールドに変えるか、新しい記録 をデータベースに物理的に加えるかの何れかで行うことができる。これらの行為 に関係するプロセスは図１２Ａ−１２Ｆで詳細に論議する。 図９Ｂにデータベース８０４のフラットデータベース実現８０４Ｂに関係する 詳細なデータ構造を示す。データベース８０４Ｂは、行から構成されており、そ の各行が個別の記録に対応する。データベースは接頭語フィールド、最終名称フ ィールド、ホーム及びワークアドレスフィールド、シティフィールドを含んでい る。接頭語フィールドに関係して、ロックフィールド８８０Ｂがある。最終名称 フィールドに関係して、対応するロックフィールド８８２Ｂがある。ホーム／ワ ークアドレスフィールドの各々に関係して、対応するロックフィールド８８４Ｂ がある。シティフィールドの各々に関係して、対応するロックフィールド８８６ Ｂがある。各記録に関係して、対応するフリーフィールド８８８Ｂがあり、その 中ではアクティブ、フリー、削除の各状態が可能である。これらフリーフィール ドの状態の影響は図９Ａで論議したものと同じである。 図１０に分散データベースを管理するための各クライアント上のソフトウェア モジュールを示す。クライアント５４とＲＡＩＤ記憶装置６４が示されている。 ＲＡＩＤ記憶装置６４はデータベース及びロッキングフィールド８０４を含んで いる。クライアント５４は実行時間スーパバイザ９００、処理ルーチン９０２、 コマンド及びパスインタセプト９０４、バッファマネジャ９０８、ロックマネジ ャ９０６、ロックリルーター９１０を含んでいる。 作動時には、実行時間スーパバイザ９００が照会を受信し、処理ルーチンモジ ュール９０２に送る。処理ルーチンモジュールは記憶媒体６４からの記録に対す る要求を提出する。この要求は、コマンド及びパスインタセプションモジュール ９０４によってインタセプトされる。このコマンドパスインタセプトモジュール は、要求をバッファマネジャ９０８に送る前に、図１２Ａ−Ｆで詳細を論ずる分 散管理機能を開始する。バッファマネジャ９０８は記憶装置６４内のデータベー ス８０４のデータを読み取り、それにデータを書込む。処理要求がコマンド及び パスインタセプトモジュール９０４に通知される時には、それはロックマネジャ ９０６へも通知される。ロックマネジャはロック要求を要求されたソースへ発行 する。この要求はロックリルーター９１０によってインタセプトされる。ロック リルーター９１０フィールドロック手続きを実行する責任を持っており、これに ついては図１２Ｃ−Ｆで詳細に論ずる。 図１１に、各クライアント５４、５６についての、分散データベースプロセス ８０８、８１０各々に関わる全体プロセスフローを示す。処理はプロセス９５０ で始まり、アドミニストレーターが、特定のフィールド及び記録特性を有し複数 のライターを許容する特定の記憶ボリューム上に、データベースをセットアップ する。データベース内のフィールドは、テキスト、又は数字データ、又は画像フ ァイル、音声ファイル、動画ファイルに対するポインターを含んでいてもよい。 ある好適実施例では、データベースは、将来の利用を勘案したサイズを予め規定 するため複数の空／フリー／利用可能記録で樹立されることとなる。それ故、新 しい記録は物理的記憶スペースを変更する要求無しに、データベースに追加する ことができる。制御は次にプロセス９５２に移行し、そこでは、照会を受け取り 処理できるように、ユーザーにＧＵＩが提供される。次に制御はプロセス９５４ に移行し、データベースから検索した記録が参照される。次に制御はサブルーチ ンブロック９５６に移行する。サブルーチンブロック９５６は図１２Ａに詳細を 示すプロセスに対応する。次に制御は決定ブロック９５８に移行する。決定ブロ ック９５８ではユーザーが参照中の記録内の特定のフィールドを編集することを 欲しているか否かについて決定が下される。この決定が否定であれば、制御は決 定ブロック９６６に移行する。この決定が肯定、即ち、フィールドは編集される 場合、制御はサブルーチン９６０に移行する。サブルーチン９６０でのプロセス は図１２Ｃで詳細に述べる。次に制御は決定プロセス９６２に戻る。決定プロセ ス９６２では、ユーザーが編集されているフィールドから出たか否かについて決 定が下される。決定が肯定、即ち、ユーザーがフィールドを出ている場合、制御 はサブルーチンモジュール９６４に移行する。サブルーチンモジュール９６４は 図１２Ｄで詳細が述べられるプロセスに対応する。サブルーチンを実行した後、 制御は決定プロセス９６６に戻る。決定プロセス９６６では、ユーザーが記録を 出たか否かについての決定が下される。この決定が否定の場合、制御は決定プロ セス９５８に戻る。決定が肯定の場合、即ち、ユーザーが記録を出ている場合、 制御はサブルーチンブロック９６８に移行する。サブルーチンブロック９６８は 図１２Ｂで詳細を述べるプロセスに対応する。制御はサブルーチン９６８から決 定プロセス９７０に移行する。決定プロセス９７０では、ユーザーが記録の追加 を欲しているか否かについて決定が下される。この決定が肯定の場合、制御はサ ブルーチン９７２に移行する。サブルーチン９７２は図１２Ｆで詳細を述べるプ ロセスに対応する。サブルーチン９７２から帰ると、制御は削除決定プロセス９ ７４に移行する。決定プロセス９７０で否定のの決定が下される場合、即ち、ユ ーザーが記録の追加を欲していない場合、制御は削除決定プロセス９７４に直接 移行する。削除決定プロセス９７４では、ユーザーが記録の削除を欲しているか 否かについて決定が下される。この決定が否定の場合、制御は照会プロセス９５ ２に移行する。この決定が肯定の場合、即ち、ユーザーが記録の削除を欲してい る場合、制御はサブルーチンモジュール９７６に移行する。サブルーチンモジュ ール９７６は後に図１２Ｅで詳細に述べるプロセスを含んでいる。 図１２Ａは、先に図１１で論議した参照記録サブルーチンモジュール９５６に 関係するプロセスの概要を示す。プロセスは接続ブロックＡで始まり、インタセ プトプロセス１０００に移行する。インタセプトプロセス１０００では、参照さ れている記録に対応する記録ポインターがコマンドパスインタセプトモジュール ９０４（図１０参照）によってインタセプトされる。制御はセクター予約プロセ ス１００２に移行する。セクター予約プロセス１００２では、記録更新表８０６ （図８Ｃ参照）に対応する記憶装置６４内のセクターが予約される。次に、制御 は予約確認決定プロセス１００４に移行する。予約確認決定プロセス１００４で は、セクターが実際に予約されたか否かについて決定が下される。この決定が肯 定の場合、制御はセクター読み取りプロセス１００６に移行する。セクター読み 取りプロセス１００６では、更新表を含んでいるセクターが読み取られ、プロセ スを実行するクライアントのＩＤと同じＩＤを持つ表内の特定の記録に対するポ インターが入手される。制御は次にプロセス１００８に移行する。プロセス１０ ０８では、プロセス１０００で入手された記録ＩＤ及び／又は記録ポインターが このプロセスを実行中のクライアントに対応する制御表内のフィールドに書き込 まれる。制御は次にセクター解放プロセス１０１０に移行する。プロセス１０１ ０では読み取られたセクターが解放される。制御は次に接続ブロックＢ経由で帰 る。 図１２Ｂに、先に図１１で述べたサブルーチンモジュール９６８に関係する記 録離脱プロセスを示す。サブルーチンは接続ブロックＣで始まり、制御はプロセ ス１０３０に移行する。プロセス１０３０では、ユーザーが離脱する記録に対す る記録ポインターをコマンドパスインタセプトモジュール９０４（図１０参照） が入手する。制御は次にセクター予約プロセス１０３２に移行する。このプロセ スでは、更新表（図８Ｃ参照）のある記憶装置６４上のセクターが予約される。 制御は次に予約確認決定プロセス１０３４に移行する。この決定プロセスでは、 セクター予約が受け付けられ実行されているか否かについて決定が下される。肯 定の決定であれば、制御はセクター読み取りプロセス１０３６に移行する。セク ター読み取りプロセス１０３６では、更新表が読み取られ、プロセスを実行する クライアントに対応するその表内の特定の行に対してポインターが入手される。 制御は次にプロセス１０３８に移行する。プロセス１０３８では、プロセスを実 行するクライアントに対応する記録ＩＤフィールドが消去される。これは、ユー ザーが最早記録を参照していないことを意味する。制御は次にプロセス１０４０ に移行する。プロセス１０４０では、予約セクターが解放され、制御は接続ブロ ックＤ経由で戻る。 図１２Ｃに、フィールドを編集するためサブルーチンモジュール９６０（図１ １参照）により実行されるプロセスを示す。このサブルーチンは接続ブロックＥ で始まり制御はプロセス１０７０へ移行する。プロセス１０７０では、コマンド パスインタセプトモジュール９０４（図１０参照）が編集されるフィールドに対 応するフィールドポインターをインタセプトする。制御は次にプロセス１０７２ に移行する。プロセス１０７２では、セクター予約要求が、フィールドが記憶さ れる物理的記憶装置６４（図１０参照）内のセクターに対して設置される。制御 は次に確認決定プロセス１０７４に移行する。確認決定プロセス１０７４では、 要求されたセクターが実際に予約されているか否かについて決定が下される。決 定が否定の場合、制御は同報通信決定プロセス１０７６に移行する。同時通信決 定プロセス１０７６では、現在そのセクターを予約している他のクライアントが そのセクターが解放されていることを標示するメッセージを同報通信したか否か について決定が下される。肯定の決定の場合、制御はセクター予約プロセス１０ ７２に戻る。決定プロセス１０７４で肯定の決定が下されると、制御はプロセス １０７８に移行する。プロセス１０７８では予約セクターが読み取られる。制御 は次に、決定プロセス１０８０に移行する。決定プロセス１０８０では、編集権 が要求されているフィールドが実際にフリーであるか否かについて決定が下され る。この決定は、先に図９Ａ−Ｂに関して記載し論議したロックフィールドに基 づいて行われる。決定が否定の場合、制御はセクター解放プロセス１０８２に移 行する。プロセス１０８２では、セクターが解放され、制御は同報通信決定プロ セス１０７６に戻る。 決定プロセス１０８０での決定が肯定の場合、即ち、要求されたフィールドが ロックされていない場合、制御はプロセス１０８４に移行する。プロセス１０８ ４では、ロックリルーター９１０（図１０参照）がクライアントのＩＤを編集さ れるロッキングフィールドに記入する。制御は次にセクター解放プロセス１０８ ６に移行する。セクター解放プロセス１０８６では、予約されたセクターが解放 され、制御はプロセス１０８８に移行する。プロセス１０８８でユーザーは選択 されたフィールドを編集し、制御は接続ブロックＦ経由で帰る。 図１２Ｄに、編集したフィールドから出るためにサブルーチンモジュール９６ ４（図１１参照）により実行されるプロセスを示す。先に図１１に関して記述し 論議したサブルーチンモジュール９６４はこれらのプロセスに対応する。このサ ブルーチンは接続ブロックＧで始まり、制御はプロセス１１００に移行する。プ ロセス１１００では、離脱するフィールドに対するポインター及び対応する記録 ポインターを、コマンドパスインタセプトモジュール９０４（図１０参照）が入 手する。制御は次にプロセス１１０２に移行する。プロセス１１０２では、記録 及びフィールドの在る物理的記憶装置上のセクターが予約される。次に制御は予 約確認決定プロセス１１０４に移行する。決定プロセス１１０４では、セクター が実際に予約されているか否かについて決定が下される。決定が否定の場合、制 御は同報通信決定１１０６に移行する。同報通信決定１１０６では、セクターが 何時、誰であれ今そのセクターを予約しているクライアントによって解放される かについての決定が下される。解放されると制御は次にプロセス１１０２に移行 する。決定プロセス１１０４で肯定の決定が下された場合、即ち、セクターが予 約されている場合、制御はプロセス１１０８に移行する。プロセス１１０８では 予約セクターが読み取られ、制御はプロセス１１１０に移行する。プロセス１１ １０ではロックリルーター９１０（図１０参照）が離脱するフィールドに関係す るブロックフィールドを消去し、制御はプロセス１１１２に移行する。プロセス １１１２では、コマンドパスインタセプトモジュール９０４（図１０参照）編集 されたフィールドに対する更新記録を物理的記憶装置６４に送る。制御は次にプ ロセス１１１４に移行する。プロセス１１１４では、記録ポインターフィールド ８３２（図８Ｃ参照）が更新表８０６（図８Ｃ参照）を読み取り、ソートする。 制御は次にプロセス１１１６に移行し、そこで、更新されたばかりのフィールド に関係する記録と同じ記録を参照しているクライアントが識別される。制御は次 にプロセス１１１８に移行する。プロセス１１１８で同報通信メッセージが更新 された記録を参照するクライアントに送られる。このメッセージには、更新され たばかりのフィールドを含む記録に対応する識別子が含まれている。制御は次に １１２０に移行する。プロセス１１２０では予約されたセクターが解放され、制 御は接続ブロックＨ経由で戻る。 図１２Ｅに、記録を削除することに関係する、先に図１１に関して記述し論議 したサブルーチン９７６に対応する詳細なプロセスを示す。プロセスは接続ブロ ックＩで始まり、制御はプロセス１１５０に移行する。プロセス１１５０では、 削除される記録に対するポインターがコマンドパスインタセプトモジュール９０ ４（図１０参照）によってインタセプトされる。制御は次にプロセス１１５２に 移行する。プロセス１１５２では、削除される記録に関係する物理的記憶装置内 のセクターが予約される。制御は次に決定プロセス１１５４に移行する。決定プ ロセス１１５４では、予約されたセクターが実際に予約されているか否かについ て決定が下される。決定が否定の場合、制御は決定プロセス１１５６に戻る。決 定プロセス１１５６では、そのセクターを予約しているクライアントがそのセク ターを何時解放するかについて決定が下される。肯定的決定が下されると、制御 はプロセス１１５２に戻る。 決定プロセス１１５４において肯定的決定が下された場合、即ち、セクターが 予約されていた場合、制御はプロセス１１５８に移行する。プロセス１１５８で は、ロックリルーター９１０（図１０参照）が記録を含む物理的記憶装置上のセ クターを読み取る。制御は次に決定プロセス１１６０に移行し、そこでロックリ ルーターが記録内の全てのロックフィールドがフリーであるか否かについての決 定を下す。決定が否定、即ち、全てのフィールドがフリーではなく、従って他の クライアントがフィールドの一つを編集している場合、制御はプロセス１１６２ に移行する。プロセス１１６２では、予約セクターは解放され、制御は同報通信 決定プロセス１１５６に戻る。 決定プロセス１１６０で肯定の決定が下された場合、即ち、削除される記録内 の全てのロックフィールドがフリーである場合、制御はプロセス１１６４に移行 する。プロセス１１６４では、ロックリルーター９１０がフリーフィールド（図 ９Ａ−Ｂ参照）に削除インジケーターを書き込む。制御は次にプロセス１１６６ に移行する。プロセス１１６６では、削除される記録内の全てのフィールドをロ ックリルーター９１０が消去する。制御は次にプロセス１１６８に移行する。プ ロセス１１６８では予約セクターが解放される。制御は次に接続ブロックＪ経由 で戻る。 図１２Ｆに、図１１のサブルーチンモジュール９７２に関連して先に記述し論 議した記録の追加に関係する詳細なプロセスを示す。制御は接続ブロックＫで始 まりプロセス１１８０に移行する。プロセス１１８０では、コマンドパスインタ セプトモジュール９０４（図１０参照）が追加処理要求をインタセプトし、制御 をプロセス１１８２に進める。プロセス１１８２では、データベース内の全ての 記録のフリーフィールドが分析され、制御は決定プロセス１１８４に移行する。 決定プロセス１１８４では、現在データベース内にある各記録に関係するフリー フィールドの何れかがフリーインジケーターを含んでいるか否かについての決定 が下される。決定が否定、即ち、利用できる記録がない場合、制御はプロセス１ １８６に移行する。プロセス１１８６では、アクセス制御表に対するセマフォフ ィールド３５２（図８Ａ参照）が捕捉される(図５Ａ、プロセス５１０−５１８ 参照)。制御は次にプロセス１１８８に移行する。プロセス１１８８では、デー タベース用に予約されている実際の物理的記憶スペースが新しい記録を追加する ことにより増やされる。これらの新しい記録のフリーフィールドにはフリーイン ジケーターの印が付けられる。制御は次にプロセス１１９０に移行する。プロセ ス１１９０では、制御表２０６（図８Ａ参照）に対しセマフォフィールド３５２ が解放される。制御は次にプロセス１１９２に戻る。 決定プロセス１１８４で肯定の決定が下された場合、即ち、データベース内に 現在フリーの記録がある場合、制御はプロセス１１９２に移行する。プロセス１ １９２では、フリーの記録が関係する物理的セクターが予約される。制御は次に 決定プロセス１１９４に移行する。決定プロセス１１９４では、セクターが実際 に予約されているか否かについての決定が下される。決定が否定の場合、制御は 決定プロセス１１９６に移行する。決定プロセス１１９６では、現在そのセクタ ーを予約しているクライアントが何時その予約を解除するかについて決定が下さ れる。決定が肯定である場合、制御はプロセス１１９２に戻る。決定プロセス１ １９４において肯定の決定が下された場合、即ち、セクターが実際に予約されて いる場合、制御はプロセス１１９８に移行する。プロセス１１９８では、フリー の記録を含んでいる物理的セクターが読み取られる。制御は次にプロセス１２０ ０に移行する。プロセス１２００では、アクティブインジケーターが記録のフリ ーフィールド（図９Ａ−Ｂ参照）に書き込まれる。これは記録が使用下に置かれ ていることを標示する。制御は次にプロセス１２０２に移行する。プロセス１２ ０２では、予約されたセクターは解放され、制御は接続ブロックＬ経由で戻る。 分散処理 図１３Ａ−Ｃに、ネットワーク環境内の複数のプロセッサーに跨る分散制御の ための全体フォーマットを示す。ネットワーク環境は、ＮＡＰパラダイム及びク ライアントーサーバーパラダイムの両方又は何れかで構成することができる。図 １３Ａ−Ｃはクライアント５４−５６及び１３０２−１３０４を含んでおり、こ れらはネットワーク１３００に接続されている。一連のプロジェクト管理フォル ダ１３１４−１３２０は、ネットワーク上の全てのクライアントが利用可能であ る。各クライアントがアプリケーションプログラム及び分散プロジェクト管理プ ロセスを含んでいる。クライアント５４は分散プロジェクト管理プロセス１３１ ０を含んでおり、クライアント５６は分散プロセス管理プロセス１３１２を含ん でおり、クライアント１３０２は分散プロセス管理プロセス１３０６を含んでお り、クライアント１３０４は分散プロジェクト管理プロセス１３０８を含んでい る。分散プロジェクト管理プロセスは各々が、プロジェクト管理フォルダを選択 し、そのプロジェクト管理フォルダの選択された部分の処理を開始し、結果のフ ァイルをアッセンブリ位置に記憶する能力を含んでいる。このように画像編集、 レンダリング、キーフレーム変換を始めとしたマルチメディア表示のような複雑 なプロジェクトをネットワーク環境内の複数のクライアントと共同で実行するこ とができる。 図１３Ｂでは、クライアント５４−５６及び１３０２は各々プロジェクト管理 フォルダ１３１４のコピー１３１４Ａ−Ｃを入手している。各クライアントはプ ロジェクト管理フアイル（ＰＭＦ）１３１４内で定義されたプロジェクトのセグ メントを選択している。プロジェクト管理プロセス１３１０−１３１２及び１３ ０６は、ＰＭＦ１３１４の選択されたセグメントに関係する処理の際に、その各 クライアント上に存在するアプリケーションを利用する。常駐アプリケーション が要求されたタスクを完了すると、結果はファイル内に記憶される。 図１３Ｃは、クライアント５４−５６及び１３０２がＰＭＦ１３１４のコピー を解放したことを示している。更に、常駐プロセス１３１０−１２及び１３０６ は、ローカルアプリケーションにより生成された成果物をネットワーク上に記憶 させている。クライアント５４は、例示の目的で画像フレームの左側部分１５０ ０として絵画的に表現しているその成果物をネットワーク上のファイル１３３０ 内に記憶している。クライアント５６は画像フレームの中央部分１５０２として 絵画的に表現しているその成果物をネットワーク上のファイル１３３２内に記憶 している。クライアント１３０２は画像フレームの右側部分１５０４として絵画 的に表現しているその成果物をネットワーク上のファイル１３３４内に記憶して いる。これらファイル各々のネットワーク上の位置はＰＭＦ１３１４に記録され ている。 処理が開始される次のＰＭＦはＰＭＦ１３１８である。クライアント１３０２ −１３０４は各々、ＰＭＦ１３１８のコピー１３１８Ｃ−Ｄを入手している。こ れらのクライアントはこれらのＰＭＦのあるセグメントを処理するよう契約され ている。 図１４Ａ−Ｄに、プロジェクト管理フォルダに関係するデータ構造を示す。図 １４Ａはプロジェクト管理フォルダに対応するデータ構造を示す。プロジェクト 管理フォルダ１３１４を見ると、プロジェクトファイル１４５０、容量表１３５ ０、プロセスオプションテンプレート１４００Ａ−Ｂが含まれている。 図１４Ｂに容量表１３５０に関係する詳細なデータ構造を示す。容量表１３５ ０はネットワーク上の各クライアント毎に１つの行／記録を有している。各クラ イアント毎に、記録アプリケーション可用性フィールド１３５６−１３６２がク ライアント上でのアプリケーションの可用性を記録する。これらアプリケーショ ンの各々に対し、アプリケーションが消費する処理帯域幅の割合のインジケータ ーがある。例えば、クライアントＡ（５４）では、電気的画像レンダリングパッ ケージ１３５８がその処理容量の２５％を消費したと示されている。ＣＡＤパッ ケージ１３６０は、クライアントＡ（５４）では、処理容量の１０％を消費した と示されている。レンダリングパッケージ１３６２は、クライアントＡ（５４） の処理帯域幅の２５％を消費したと示されている。最後に残った規定されていな いアプリケーション及びＯＳは、クライアントＡの処理帯域幅の別の１０％を消 費している。更に、ワープロパッケージがフィールド１３５６にＮ／Ａと表示し て挙げてあるが、これはこのアプリケーションがクライアントＡ（５４）上に丁 度存在しないことを示している。フィールド１３５２は各クライアントに対し、 特にこの例ではクライアントＡ（５４）について、フィールド１３５６−６２に おける利用エンティティの積算を記録する。このように、クライアントＡでは、 利用１３５２がその合計処理帯域幅の７０％と表示されている。容量表の残りの フィールドは秒当たり百万命令（ＭＩＰＳ）の単位で表した処理速度１３５４で ある。クライアントＡ（５４）は表示してあるように、２６６ＭＩＰＳの処理容 量を持っている。ネットワーク上の全てのクライアントが相当する情報を利用で きる。容量表内の各記録は、対応する分散プロジェクト管理プロセス１３０６− １３１２の一つによって保守更新される。プロセスはＯＳ呼び出しを生成する。 これらの呼び出しは、アプリケーション特定ベースでブレークダウンしたパーセ ント利用に対応する変数を返す。次にプロセスはこれらの更新された結果を、制 御表内のそれらの記録に関係する対応するフィールドに書き込む。このように、 単一の表が、共通の位置内の全てのネットワーク資源に対するパーセント利用を 記録するのに利用される。 図１４Ｃに、プロセスオプションテンプレート１４００Ａ−Ｂに対応する詳細 なデータ構造を示す。通常、プロセスオプションテンプレートは特定のアプリケ ーションと関係している。プロセスオプションテンプレートはクライアント上に 在るアプリケーションを特定のやり方で実行させる。例えば、プロセスオプショ ンテンプレート１４００Ａは電気影像というソフトウェアアプリケーションと関 係している。フィールド１４０２Ａ−１４０８Ａは各々、アプリケーションに対 する適切なフレームサイズ、圧縮、書式、秒当たりフレーム、持続時間インジケ ーターを記録する。図１４Ｃに示す例では、フレームサイズ１４０２Ａは６４０ ｘ４８０と示されている。ＪＰＥＧ圧縮技法１４０４Ａが表示されている。フレ ーム／秒で表した再生速度１４０６Ａは１５と表示してある。最後の、動画の意 図持続時間１４０８Ａは２秒である。 プロセスオプションテンプレート１４００Ｂはコンピューター支援設計（ＣＡ Ｄ）アプリケーションと関係している。このアプリケーションに対しては、フレ ームサイズ圧縮技法及びビット深さ標準が各々フィールド１４０２Ｂ−１４０８ Ｂに表示されている。Ｘ軸フレームサイズは２４、ｙ軸フレームサイズは１２、 圧縮技法はＴＩＦＦ、ビット解像度は８ビットである。プロセスオプションテン プレートの各々は多くの方法のどれで生成してもよい。プロセスオプションテン プレートは、アプリケーションが使用可能なように、好みの処理パラメーターを 選択し、そしてそれらを関係する出力ファイルに記憶させながら、ユーザーが作 ることがもきる。又、プロセスオプションテンプレートは管理的に作って、丁度 そのような目的に意図されたシェルプログラムに添付することもできる。 図１４Ｄに、プロジェクトファイル１４５０の詳細なデータ構造を示す。この プロジェクトファイルは、契約フィールド１４５４、マスター参照フィールド１ ４５２を有するヘッダーを含んでいる。契約フィールドは、ネットワーク上の様 々なクライアント中のどのクライアントがプロジェクトと契約しているかを表示 する。クライアントＡ、Ｂ、Ｃはプロジェクトと契約しており、クライアントＤ はしていないことが標示されている。マスター状態フィールド１４５２内の全て のエンティティがゼロなので、クライアントは誰もマスター状態に要求されても いなければ指名されてもいない。 プロジェクトファイル１４５０は資源要件セクションを含んでいる。このセク ションはプロジェクトを完了するのに必要なアプリケーションの名前を含んでい る。更に、実行可能パスフィールド１４５６はアプリケーションに対する実行可 能ファイルを指定する。ソースデータファイルフィールド１４５８は、各アプリ ケーションがどのファイルをロードすべきかを標示する。この特定のプロジェク トは、ワープロアプリケーション、電気影像アプリケーション、ＣＡＤアプリケ ーション、レンダリングアプリケーションを必要とする。電気影像アプリケーシ ョンは「center.vsd」という名前のソースデータファイルを必要とし、このファ イルへのパスはc:＼＼center.vsdと標示されている。プロジェクトファイルの次 の部分はセグメント部である。２つのセグメント部が示されている。一般的には 、これらの部の数はネットワーク上のクライアントの数に対応し、これだけは特 定のプロジェクトに関係する処理に同時に関与できる。あるプロジェクトは１つ のセグメントを有し、又、ある複雑なレンダリングプロジェクトは多数のクライ アントに分割できて、多数のセグメントを持つことになる。 各セグメントはセグメント定義フィールド１４６０、プログラムフィールド１ ４６２、記憶パスフィールド１４６４、優先フィールド１４６６、処理者フィー ルド１４６８、セグメント状態フィールド１４７０から成る。 セグメント定義フィールド１４６０は、特定のセグメントに対する開始点と終 了点を定義する。電気影像アプリケーションに対する第１セグメントにおける開 始点と終了点はフレーム１−２と表示してある。プログラム制御フィールド１４ ６２は制御スクリプト、即ち、この特定のプロジェクトに適したやり方でアプリ ケーションを実行させるビジュアルベーシック・ジャバ、又は「ＤＤＥスクリプ ト」を含んでいる。但し、ここで言う「アプリケーション」とは、オートカード のような高級なプログラムからＯＳを始めとする低級なアプリケーションまで、 コンピューター上で実行されるあらゆるプロセスを含む。記憶パスフィールド１ ４６４は結果を何処に記憶するか（図１３Ｃ、１３３０−１３３４参照）を標示 する。フィールド１４６６はプロジェクト内でのアプリケーションとセグメント の処理順序を決める。処理者フィールド１４６８はネットワーク上のクライアン トの内誰が局部駐在のアプリケーションを使ってＰＭＦのセグメントを実行した かを標示する。例えばセグメント１では、「a」識別子が、クライアントＡ上の プロジェクト管理プロセスが電気影像タスクのセグメント１の処理を引き受けて いることを示している。最後のセグメント状態フィールド１４７０はプロジェク トファイル内の各セグメント及び各アプリケーションに対し、セグメントの状態 がどうであるかを標示する。可能な項目は「０」、「１」、「２」である。項目「０ 」はセグメントがまだ処理されていないことを示し、項目「１」はセグメントが 処理中であることを示し、項目「２」はセグメント処理が完了し、処理の結果と して生成されたファイルがネットワーク上の記憶パス位置に記憶されていること を示している。プロジェクトファイルの次の部分は、フィールド１４７２−１４ ７８から成るアッセンブリー部分である。フィールド１４７２は様々なクライア ントの内誰が最終アッセンブリーを行ったかを示すＩＤフィールドである。フィ ールド１４７４は、そのタスクの実行に関係するプログラムコード又はＤＤＥシ ーケンスを含んでいる。フィールド１４７８は結果が記憶されるネットワーク上 の位置を標示する。プロジェクトファイルの次の部分はプロセスオプションテン プレートフィールド１４８０である。このフィールドは各アプリケーションに対 し、対応するプロセスオプションテンプレート又はプロセスオプションテンプレ ートパスを標示する。 図１５Ａ−Ｂに分散プロジェクトの２つの例を示す。図１５Ａは２次元の画像 を示し、レンダリングされる画像が３つの部分に分割され、その各々を別々のク ライアントがレンダリングしている。１５００部分は画像の左部分、１５０２部 分は画像の中心部分、１５０４部分は画像の右部分である。これら各部分はネッ トワーク上の対応するファイル１３３０−１３３４に記憶される。 図１５Ｂは６つのフレームから成る動画シーケンスである。最初の２つのフレ ーム１５２２は一人のクライアントが作り、ネットワーク上のファイル１３３０ に記憶される。次の部分１５２４は動画帯のフレーム３と４から成り、ネットワ ーク上のファイル１３３２に記憶される。プロジェクトの最後の部分１５２６は フレーム５と６であり、ネットワーク上のファイル１３３４に記憶される。ファ イル１３３０−１３３４が最終アッセンブリーで接続されると動画シーケンス１ ５２０が出来上がる。 図１６Ａ−Ｄに、分散プロジェクト管理プロセスの指示の下で、クライアント 常駐アプリケーションが、ファイルを処理し（図１６Ｃ参照）、ファイルをセー ブする（図１６Ｄ）するためにソースデータファイル（図１６Ａ−Ｂ参照）を開 くところを示す。アプリケーションはこのやり方で、セグメントに関係する制御 スクリプト１４６２（図１４Ｄ）が実行する。このコードは分散管理プロセスに よってアップロードされ、プロセスはこれを利用してアプリケーションを予め定 められた方法で実行する。図１６ＡにアプリケーションのためのＧＵＩ１５５０ を示す。このＧＵＩに重ねて、ファイルを開くＧＵＩ１５５４が示されている。 ファイルを開くＧＵＩは、ファイルメニュー１５５２内にあるファイルを開くコ マンドを実行するプログラムコードスクリプトで使用可能である。ＧＵＩオペレ ーター１５５４内には、選択されたファイル１５５８の内容が示されるプレビュ ーウィンドウ１５５６がある。図１６Ｂでは、ファイル１５５８に関係する画像 １５６０がＧＵＩ１５５０内に表示されている。 図１６Ｃでは、プロジェクト管理プロセスがＣＡＤアプリケーションに実行可 能なコードの次のラインを送り、その結果ツールメニュー１５６２から陰影処理 が選択される。この選択の結果、ＣＡＤアプリケーションは画像１５６０の一部 １５６４に陰影を施し、それを表示する。図１６Ｄでは、分散プロジェクト管理 プロセスがアプリケーションにコードの次のラインを送る。コードの次のライン を受け取ると、アプリケーションはメニューツリー１５５２内のファイル「セー ブアズ」機能を実行する。これに応えて、「セーブアズ」ＧＵＩインタフェース １５５６が使用可能となり、ファイル名「center.vsd」がファイル名ウィンドウ に表示される。続いて、今処理されたセグメントに対応するファイルがネットワ ーク上に記憶される。 図１７Ａ−Ｆに、様々な分散プロジェクト管理プロセスを示すプロセスフロー 線図を示す。 図１７Ａはプロジェクト生成プロセスを示す。開始ブロックから始まって制御 はプロセス１６５２に移行する。プロセス１６５２でプロジェクトファイルが生 成される。ある好適実施例では、ユーザーには図１４Ｄで示したのとは異なるＧ ＵＩインタフェースが提示される。このテンプレートを使って、ユーザーはプロ ジェクトファイルに対し様々なパラメータを入力する。制御は次にプロセス１６ ５４に移行する。プロセス１６５４ではプロセスオプションテンプレートが生成 される。ある好適実施例では、図１４Ｃに示したのに似たＧＵＩインタフェース を使って、ユーザーもこれらを生成する。制御は次にプロセス１６５６に移行す る。プロセス１６５６では、プロセス管理フィールドと、関係するプロセスオプ ションテンプレートとがネットワーク上に記憶される。制御は次に接続ブロック Ａに移行する。 図１７Ｂに、図１４Ｂに示した利用／容量表１３５０の保守に関するプロセス を示す。先に記述し論議したように、分散管理プロセス１３０２、１３０４、１ ３１０、１３１２（図１３Ａ−Ｃ参照）は独立してこのプロセスステップを実行 する。接続ブロックＡに始まって、制御はプロセス１６８０に移行する。アプリ ケーションによってブレークダウンされた利用情報を得るために、機能呼び出し がＯＳに送られる。制御は次にプロセス１６８２に移行する。プロセス１６８２ では、利用表が見つけだされ、読み取られる。制御は次にプロセス１６８４に移 行する。プロセス１６８４では、このプロセスを実行中のクライアントに対応す る利用表中の行／記録が識別される。制御は次にプロセス１６８６に移行する。 プロセス１６８６では、先にプロセス１６８０で得られた値が利用表中の適切な フィールドに置かれる。制御は次にプロセス１６８８に移行する。プロセス１６ ８８では、利用表に入力されたクライアントに対する処理速度がその表から読み 取られる。制御は次にプロセス１６９０に移行する。プロセス１６９０では、ク ライアントの処理速度を得るために、機能呼び出しがＯＳに送られる。制御は次 に決定プロセス１６９２に移行する。決定プロセス１６９２では、表中の項目が プロセスを実行しているクライアントの実際の処理速度に対応しているか否かに ついての決定が下される。両者が合っていない場合、プロセスはプロセス１６９ ４に移行し、そこで表中の項目が現在のクライアントの処理能力を反映するよう に更新される。制御は次に接続ブロックＢに移行する。決定プロセス１６９２で 肯定の決定が下された場合、即ち、このクライアントに関する利用表中の項目が 正しい場合、制御は接続ブロックＢに直接移行する。 図１７Ｃに、マスター／スレーブ（主／従）関係が使用できる場合に実行され る分散管理プロセスの部分を示す。分散プロセス管理に対しては基本的に２つの モードがある。主／従モードでは、予めマスター状態に指名されるか、或いはＰ ＭＦを最初に捕捉しマスター状態を得るかしたクライアントがプロジェクトファ イルの全てのセグメントの次の処理を指示する。もう一つの実施例では、分散処 理に対する対等関係アプローチが実行される。対等関係アプローチでは、各クラ イアントはプロセスに対する未完成のＰＭＦを継続的に探している。 図１７Ｃでは、プロセスは接続ブロックＢで始まる。制御はプロセス１７２０ に移行し、次のＰＭＦの位置が特定される。ある好適実施例では、次のＰＭＦは 先入れ先出し（ＦＩＦＯ）待ち行列から選択され、そのＰＭＦに関する処理はフ ァイル内の全セグメントが完成し最終アッセンブリーが行われるまで続く。又別 の好適実施例では、次のＰＭＦは、未完成のセグメントを持っているか、又は最 終アッセンブリーされていない何れかのファイルと定義される。制御は次にプロ セス１７２２に移行し、そこで選択されたＰＭＦが読み取られる。制御は次に決 定プロセス１７２４に移行する。決定プロセス１７２４では、この特定のプロジ ェクト管理フォルダが主／従状態に対して使用可能か否かについて決定が下され る。決定が否定の場合、制御は接続ブロックＤに移行する。決定が肯定の場合、 制御は決定プロセス１７２６に移行する。決定プロセス１７２６で、マスターフ ィールド１４５２（図１４Ｄ参照）に基づいて、何れかのマスターがこのプロジ ェクト管理フォルダに契約されているか否かについての決定が下される。決定が 肯定の場合、制御は接続ブロックＣに移行する。否定の決定が下された場合、制 御は決定プロセス１７２８に移行する。決定プロセス１７２８では、マスター状 態フィールド１４５２（図１４Ｄ参照）でマスター状態に指名されたクライアン トが自分のＩＤに対応するＩＤを持っているか、即ちそのクライアントがこのプ ロセスを実行しているか否かについての決定が下される。決定が否定の場合、制 御は接続ブロックＣに移行する。決定が肯定の場合、制御はプロセス１７３０に 移行する。プロセス１７３０では、クライアントはマスターを引き受けることを 契約し、プロジェクト管理フォルダ内の適当なフィールド１４５４に契約識別子 を書き込んでこれを行う。制御は次にプロセス１７３２に移行する。プロセス１ ７３２では、スレーブの可用性及び処理容量を決めるために利用表が読み取られ る。制御は次にプロセス１７３４に移行する。プロセス１７３４では未だ「２」 の印が付けられたセグメント状態フィールド１４７０（図１４Ｄ参照）を持って いない、最高優先度１４６６（図１４Ｄ参照）を有するセグメント記録が入手さ れ、そのセグメントに必要なアプリケーション１４５６が決定される。制御は次 にプロセス１７３６に移行する。 プロセス１７３６では、マスターはスレーブ請求及び／又はスレーブ割当てプ ロセスに従事する。セグメントに対するアプリケーション１４５６に合った局所 駐在アプリケーションを持ったスレーブだけが選ばれる。又、プロセス１７３２ で使用可能な処理能力が高く且つ利用されていないと判定されたスレーブは、処 理速度が遅く能力が限られているものよりも好まれる。制御は次に決定プロセス １７３８に移行する。決定プロセス１７３８では、スレーブがスレーブ状態を受 け容れたか否かについての決定が下される。スレーブ状態を受け容れたスレーブ に対して、制御はプロセス１７４０に移行し、スレーブＩＤが決定される。制御 は次にプロセス１７４２に移行する。プロセス１７４２では、スレーブが処理す るように指定されたＰＭＦセグメントに基づいて、マスターは情報をスレーブに 送る。この情報は、スレーブがプロセスに従事するために必要となるソースファ イルに対するポインター、どのセグメントを処理するかを表示するセグメント定 義、スレーブがその駐在アプリケーションを使用可能なようにするための実行可 能なコードシーケンス、プロセスオプションテンプレートを含んでいる。最後に マスターは、スレーブがその成果物を記憶させるネットワーク上の位置に対する ポインターをスレーブに送る。制御は次に決定プロセス１７４４に移行する。決 定プロセス１７４４では、未完成のセグメントが残っているか否かについて決定 が下され、残っている場合、制御は次のスレーブを選択するためにプロセス１７ ３８に戻る。未完成の項目が残っていない場合、制御は決定プロセス１７４６に 移行する。決定プロセス１７４６では、全てのスレーブがこの仕事を完了したか 否かについての決定が下される。プロジェクトファイル、及び特にセグメント状 態フィールド１４７０（図１４Ｄ参照）内のスレーブによって作られた項目に基 づいて、仕事の完成が決定される。決定が肯定の場合、即ち、全てのセグメント が処理されている場合、制御はプロセス１７４８に移行する。プロセス１７４８ では、プロジェクトファイル（図１４Ｄ参照）のアッセンブリー部分に含まれる 命令に従って、プロジェクトファイルの各セグメントの最終アッセンブリーを完 了する。制御は次にプロセス１７５０に移行する。プロセス１７５０でマスター は、ＰＭＦそして特にフィールド１４７２に、最終アッセンブリーが完了し、こ のプロジェクト管理フォルダを閉じてもよいことを標示する状態インジケーター を書き込む。制御は次に接続ブロックＡに移行する。 図１７Ｄに、スレーブが従事するプロセスを示す。処理は接続ブロックＣで始 まり、制御は決定プロセス１７８０へと進む。決定プロセス１７８０では、マス ターの要求が受信されているか否かについての決定が下される。決定が否定の場 合、制御は接続ブロックＢに移行する。決定が肯定の場合、制御はプロセス１７ ８２に移行する。プロセス１７８２でスレーブは、スレーブ状態を受け容れるこ とを標示する肯定応答をマスターに送る。制御は次にプロセス１７８４に移行し て、そこでスレーブは、プロジェクトファイルの指定されたセグメントを処理す るのに必要な情報をマスターから受け取る。制御は次にプロセス１７８６に移行 する。プロセス１７８６では、スレーブは指定されたアプリケーションを使用可 能であり、そのアプリケーションを適切な制御スクリプトで制御し、オプション テンプレートを処理する。これによってアプリケーションはその指定された機能 を実行する。制御は次にプロセス１７８６に移行する。プロセス１７８６でスレ ーブは、プロジェクトファイル（図１４Ｄ参照）内の対応するセグメント状態フ ィールド１４７０に、状態「１」インジケーターを書き込む。これは、このプロ ジェクトファイルを読んでいる全てのクライアントに、そのセグメントをスレー ブが現在処理していることを標示する。制御は次に決定プロセス１７８８に移行 し、そこでスレーブは常駐アプリケーションがそのプロジェクトセグメントを完 了したか否かについて決定を下す。決定が肯定の場合、制御はプロセス１７９０ に移行する。プロセス１７９０でアプリケーションは、その成果物をプロセス１ ７８４で指定された位置に記憶し、アプリケーションは閉じる。制御は次にプロ セス１８００に移行する。プロセス１８００では、セグメント完了インジケータ ー「２」が、プロジェクトファイル内の適切なフィールド１４７０に書き込まれ る。制御は次に接続ブロックＢに移行する。 図１７Ｅは、クライアント間の主／従関係ではなく対等関係に関連する分散プ ロジェクトプロセスの部分を開示する。処理は接続ブロックＤで始まる。制御は 次にプロセス１８２０に移行し、そこで次のＰＭＦが読み取られる。制御は次に プロセス１８２２に移行し、そこで利用表が読み取られる。制御は次にプロセス １８２４に移行し、そこでＰＭＦ内のセグメントが優先度でソートされ、それら のセグメントがまだ完成されていないか否かについて決定が下される。この決定 は先に述べ論議した優先度１４６６及びセグメント状態１４７０フィールド（図 １４Ｄ参照）内の項目に基づいている。制御は次に決定プロセス１８２６に移行 する。決定プロセス１８２６では、未完成のセグメントが残っているか否かにつ いての決定が下される。決定が否定の場合、制御は接続ブロックＥへ進む。決定 が肯定の場合、即ち、処理されるべきセグメントが残っている場合、制御はプロ セス１８２８へ進む。プロセス１８２８では、次に優先順位の高いセグメントに 関係するアプリケーションがこのプロセスを処理するクライアント上で利用可能 であるか否かについて決定が下される。制御は次に決定プロセス１８３０に移行 し、そこで決定が実行される。 プロセス１７３６で、マスターはスレーブ請求及び／又はスレーブ割当てプロ セスに従事する。セグメントに対するアプリケーション１４５６に合う局所常駐 アプリケーションを有するスレーブのみが選ばれる。又、ある好適実施例では、 プロセス１７３２で使用可能な処理能力が高く且つ利用されていないと判定され たスレーブは、処理速度が遅く能力が限られているものよりも好まれる。プロセ スを実行するクライアントがアプリケーション呼び出しを持っていなければ、制 御は接続ブロックＢに移行する。決定が肯定の場合、即ち、クライアントが必要 な常駐アプリケーションを持っている場合は、制御はプロセス１８３２に移行す る。プロセス１８３２では、クライアントはプロジェクトファイル内のセグメン トと契約する。クライアントは、状態「１」インジケーターをプロジェクトファ イル（図１４Ｄ参照）内の適切なセグメント状態フィールド１４７０に書き込む ことによってこれを行う。制御は次にプロセス１８３４に移行する。プロセス１ ８３４では、クライアントはプロセスファイルから、ソースファイルに対するポ インター、セグメント定義、アプリケーション処理コード、プロセスオプション テンプレート及び／又はプロセスオプションテンプレートに対するパスステート メント、成果物を記憶させる指定された位置を含む適切なセグメント情報を読み 取る。制御は次にプロセス１８３６に移行する。プロセス１８３６では、クライ アントは、プログラムコードシーケンス及びプロジェクトファイルから提供され たプロセスオプションテンプレートを利用するその常駐アプリケーションを使用 可能である。制御は次にプロセス１８３８に移行し、そこでプロジェクトを完遂 したアプリケーションはその成果物を記憶する。記憶位置は指定されたソースパ ス（図１４Ｄ参照）に対応する。制御は次にプロセス１８４０に移行する。プロ セス１８４０では、状態フィールド１４７０の中の適切な１つが、特定のセグメ ントが完成していることをプロジェクトファイル内に標示するため、状態「２」 に更新される。 図１７Ｆに、全てのセグメントが完成したプロジェクトファイルの再アッセン ブリーに関係する対等関係に関するプロセスを示す。処理は接続ブロックＥで始 まり、制御はプロセス１８６０に移行する。プロセス１８６０でプロジェクト管 理フォルダが読み取られる。制御は次に決定プロセス１８６２に移行する。決定 プロセス１８６２では、プロジェクトフィールド（図１４Ｄ参照）内の最終アッ センブリーフィールド１４７２に基づいて、ＰＭＦがアッセンブリされた否かに ついて決定が下される。決定が肯定の場合、制御は接続ブロックＢに戻る。決定 が否定の場合、即ち、ＰＭＦがまだ最終アッセンブリーされていない場合、制御 はプロセス１８６４に移行する。プロセス１８６４で、最終アッセンブリーが、 ＰＭＦ内に記憶されているアッセンブリー命令に従って実行される。制御は次に プロセス１８６６に移行する。プロセス１８６６では、適切な最終アッセンブリ ーフィールドに、最終アッセンブリーが完了したことを標示する状態「２」の印 が付けられる。Ｉｎｔｅｒ Ａｐｐｌｉｃａｔｉｏｎ Ｃａｌｌｓ Ｄｉｓｔｒｉｂｕｔｅ＿Ｐｒｏｃｅｓｓ(ＰＯＴ＿Ｆｉ１ｅ＿Ｐａｔｈｎａｍｅ ，Ｐｒｏｊｅｃｔ＿Ｆｉ１ｅ＿Ｐａｔｈｎａｍｅ)Ｆｒｏｍ Ｔｏ Ｎｏｔｅｓ ＭＰＡ ＭＳＢ ＭＰＣＡ ＭＳＢ Ｌａｕｎｃｈ＿ＰｒｏｃｅｓｓＦｒｏｍ Ｔｏ Ｎｏｔｅｓ ＳＳＢ ＳＰＡ ＭＳＢ ＳＰＡ マスター機の処理能力が必要な時に用いる。（未オープン） Ｐｒｏｃｅｓｓ＿Ｓｅｇｍｅｎｔ（ＰＭＦ＿Ｆｉｌｅ＿Ｐａｔｈｎａｍｅ，Ｐｌ ｕｇｉｎ＿ＩＤ，Ｔｉｍｅｓｔａｍｐ,Ｓｅｇｍｅｎｔ＿Ｐａｒａｍｅｔｅｒｓ ）Ｆｒｏｍ Ｔｏ Ｎｏｔｅｓ ＳＢＰＩ ＳＰＡ ＳＢＰＩ ＭＰＡ マスター機の処理能力が必要な時に用いる。 Ｐｒｏｃｅｓｓｉｎｇ＿Ｓｅｇｍｅｎｔ(ＰＭＦ＿Ｆｉｌｅ＿Ｐａｔｈｎａｍｅ, Ｐｌｕｇｉｎ＿ＩＤ，Ｔｉｍｅｓｔａｍｐ，Ｓｅｇｍｅｎｔ＿Ｐａｒａｍｅｔｅ ｒｓ）Ｆｒｏｍ Ｔｏ Ｎｏｔｅｓ ＳＰＡ ＳＳＢ 要求セグメントの処理が実際に始まったことを示す。 ＭＰＡ ＭＳＢ マスター機の処理能力が必要な時に用いる。 Ｓｅｇｍｅｎｔ＿Ｄｏｎｅ（ＰＭＦ＿Ｆｉ１ｅ＿Ｐａｔｈｎａｍｅ，Ｐｌｕｇｉ ｎ＿ＩＤ，Ｔｉｍｅｓｔａｍｐ，Ｓｅｇｍｅｎｔ＿Ｐａｒａｍｅｔｅｒｓ）Ｆｒｏｍ Ｔｏ Ｎｏｔｅｓ ＳＰＡ ＳＳＢ 要求セグメントの処理を終了したことを示す。 ＭＰＡ ＭＳＢ 同じ、マスター機の処理能力が必要な時に用いる。 Ｑｕｉｔ＿ＰｒｏｃｅｓｓＦｒｏｍ Ｔｏ Ｎｏｔｅｓ ＳＳＢ ＳＰＡ ＭＳＢ ＳＰＡ マスター機の処理能力を使った場合(最初開いておらず)。 Ａｓｓｅｍｂｌｅ＿Ｐｒｏｃｅｓｓ（ＰＭＦ＿Ｆｉｌｅ＿Ｐａｔｈｎａｍｅ，Ｐ ｌｕｇｉｎ＿ＩＤ，Ｔｉｍｅｓｔａｍｐ）Ｆｒｏｍ Ｔｏ Ｎｏｔｅｓ ＳＢＰＩ ＳＰＡ プラグイン自身で結果を組立られない時のオプションの組立 方法。 ＳＢＰＩ ＭＳＢ 同じ、マスター機の処理能力が必要な時に用いる。 ＡＳＳｅｍｂｌｙ＿Ｄｏｎｅ（ＰＭＦ＿Ｆｉｌｅ＿Ｐａｔｈｎａｍｅ，Ｐｌｕｇ ｉｎ＿ＩＤ，Ｔｉｍｅｓｔａｍｐ）Ｆｒｏｍ Ｔｏ Ｎｏｔｅｓ ＳＰＡ ＳＳＢ プロセス助手を使って組立が済んだ場合、完了を示す。 ＭＰＡ ＭＳＢ 同じ、マスター機の処理能力を使った場合に用いる。 Ｐｒｏｃｅｓｓ＿Ｃｏｍｐｌｅｔｅ（ＰＯＴ＿Ｆｉｌｅ＿Ｐａｔｈｎａｍｅ，Ｐ ｒｏｊｅｃｔ＿Ｆｉｌｅ＿Ｐａｔｈｎａｍｅ）Ｆｒｏｍ Ｔｏ Ｎｏｔｅｓ ＭＳＢ ＭＰＡ 全プロセスの完了を示す。 ＭＳＢ ＭＰＣＡ 同じＳｔｕｄｉｏＢＯＳＳ ｔｏ ＳｔｕｄｉｏＢＯＳＳ Ｃａｌｌｓ ＦＯＲ ＰＲＯＣＥＳＳ ＣＯＮＲＴＲＯＬ ＳＢ＿Ｐｒｏｃｅｓｓ＿Ｓｅｇｍｅｎｔ(ＰＭＦ＿Ｆｉ１ｅ＿Ｐａｔｈｎａｍｅ ， ＰＭＦ＿Ｒｅｆｅｒｅｎｃｅ)Ｆｒｏｍ Ｔｏ Ｎｏｔｅｓ ＭＳＢ ＳＳＢ ＳＢ＿Ｐｒｏｃｅｓｓｉｎｇ＿Ｓｅｇｍｅｎｔ（ＰＭＦ＿Ｒｅｆｅｒｅｎｃｅ）Ｆｒｏｍ Ｔｏ Ｎｏｔｅｓ ＳＳＢ ＭＳＢ 要求セグメントの処理が実際に始まったことを示す。 ＳＢ＿Ｓｅｇｍｅｎｔ＿ＤｏｎｅＦｒｏｍ Ｔｏ Ｎｏｔｅｓ（ＰＭＦ＿Ｒｅｆｅｒｅｎｃｅ） ＳＳＢ ＭＳＢ 要求セグメントの処理が終ったことを示す。 ＳＢ＿Ｑｕｉｔ＿Ｐｒｏｃｅｓｓ（ＰＭＦ＿Ｒｅｆｅｒｅｎｃｅ）Ｆｒｏｍ Ｔｏ Ｎｏｔｅｓ ＭＳＢ ＳＳＢ 要求セグメントの処理終了後、清掃のため呼ばれる。 ＳＢ＿Ａｓｓｅｍｂｌｅ＿Ｐｒｏｃｅｓｓ（ＰＭＦ＿Ｒｅｆｅｒｅｎｃｅ）Ｆｒｏｍ Ｔｏ Ｎｏｔｅｓ ＭＳＢ ＳＳＢ プロセス結果を組み立てるために呼ばれる。（プラグイン／ アプリケーションをＭＳＢ上で利用できない場合）ＦＯＲ ＡＲＢＩＴＲＡＴＩＯＮ ＭＡＳＴＥＲ／ＳＬＡＶＥ ＣＯＮＴＲＯＬ ＳＢ＿Ｂｅｃｏｍｅ＿Ｓｌａｖｅ（ＰＭＦ＿Ｆｉｌｅ＿Ｐａｔｈｎａｍｅ，ＰＭ Ｆ＿Ｒｅｆｅｒｅｎｃｅ）Ｆｒｏｍ Ｔｏ Ｎｏｔｅｓ ＭＳＢ ＳＳＢ スレーブとなるために呼ばれる。 ＳＢ＿Ｓｌａｖｅ＿Ｒｅｓｐｏｎｓｅ（ＰＭＦ＿Ｆｉｌｅ＿Ｐａｔｈｎａｍｅ， ＰＭＦ＿Ｒｅｆｅｒｅｎｃｅ）Ｆｒｏｍ Ｔｏ Ｎｏｔｅｓ ＳＳＢ ＭＳＢ プロセスに対しスレーブとなる場合、（真／偽）応答する。 ＳＢ＿Ｂｅｃｏｍｅ＿ＦｒｅｅＦｒｏｍ Ｔｏ Ｎｏｔｅｓ ＭＳＢ ＳＳＢ スレーブを解放するＰｌｕｇｉｎ Ｃａｌｌｓ ＰＩ＿Ｐｒｏｃｅｓｓ＿Ｓｅｇｍｅｎｔ（ＰＭＦ＿Ｆｉｌｅ＿Ｐａｔｈｎａｍｅ ） プロセスセグメントを分散させるために呼ばれる。Ｐｒｏｃｅｓｓ＿Ｓｅｇｍｅ ｎｔ ＩＡＣを呼ぶことになる。 ＰＩ＿Ａｓｓｅｍｂｌｅ＿Ｐｒｏｃｅｓｓ（ＰＭＦ＿Ｆｉｌｅ＿Ｐａｔｈｎａｍ ｅ） プロセスセグメントを組み立てるために呼ばれる。プラグインはプロセスアプリ ケーションなしで結果を組み立てられる、又は全てを組み立てるためＡｓｓｅｍ ｂｌｅ＿Ｐｒｏｃｅｓｓ ＩＡＣを呼び出す命令をオプションとして出せる。 凡例 ＭＰＡ マスタープロセスアプリケーション ＭＰＣＡ マルチプロセスコントローラアプリケーション ＰＩ プラグイン ＰＭＦ プロセス管理ファイル ＳＢ スタジオボス ＭＳＢ マスタースタジオボス ＳＳＢ スレーブスタジオボス ＰＯＴ プロセスオプションテンプレート ＳＢＰＩ ＭＳＢ又はＳＳＢの内部にあるスタジオボスプラグインＰＲＯＣＥＳＳ ＯＰＴＩＯＮ ＴＥＭＰＬＡＴＥ（ＰＯＴ） Ｔｅｍｐｌａｔｅ＿Ｓｉｇｎａｔｕｒｅ （アプリケーションの特別オプション） ＰＯＴ例、メモリ中に組み立てられる結果−フレームベースプロセスの場合 Ｔｅｍｐｌａｔｅ＿Ｓｉｇｎａｔｕｒｅ Ｂｉｔ＿ＤｅＰｔｈ Ｆｒａｍｅ＿Ｓｉｚｅ＿Ｘ Ｆｒａｍｅ＿Ｓｉｚｅ＿Ｙ ＰＯＴ例、ファイル中に組み立てられる結果−タイムベースプロセスの場合 Ｔｅｍｐｌａｔｅ＿Ｓｉｇｎａｔｕｒｅ Ｆｒａｍｅ＿Ｓｉｚｅ Ｆｒａｍｅｓ＿Ｐｅｒ＿Ｓｅｃｏｎｄ Ｃｏｍｐｒｅｓｓｏｒ Ｓｔａｒｔ＿Ｔｉｍｅ Ｅｎｄ＿ＴｉｍｅＰＭＦ Ｐｒｏｊｅｃｔ＿Ｆｉｌｅ＿Ｐａｔｈ Ｒｅｍａｉｎｉｎｇ＿Ｓｅｇｍｅｎｔｓ＿Ｔｏ＿Ｐｒｏｃｅｓｓ Ｐｒｏｃｅｓｓ＿Ａｐｐｌｉｃａｔｉｏｎ＿Ｓｉｇｎａｔｕｒｅ Ｍａｓｔｅｒ＿Ｈｏｓｔ＿ＩＤ Ｒｅａｓｓｅｍｂｌｙ＿Ｍｅｔｈｏｄ Ｎｕｍｂｅｒ＿Ｏｆ＿Ｓｌａｖｅｓ （各スレーブ毎に以下がある） Ｓｌａｖｅ＿ＩＤ Ｓｅｇｍｅｎｔ＿Ｂｅｉｎｇ＿Ｐｒｏｃｅｓｓｅｄ Ｓｇｍｅｎｔ＿Ｓｔａｔｕｓ（ｎｏｔ＿ｐｒｏｃｅｓｓｉｎｇ，ｐｒｏｃｅｓｓ ｉｎｇ＿ｉｎ＿ｐｒｏｇｒｅｓｓ，ｐｒｏｃｅｓｓｉｎｇ＿ｃｏｍｐｌｅｔｅ） Ｒｅｓｕｌｔ＿Ｌｏｃａｔｉｏｎ Ｐｒｏｃｅｓｓ＿Ｏｐｔｉｏｎ＿Ｔｅｍｐｌａｔｅ 以上、本発明の好適実施例についての記述を図解と説明を目的として行った。 本記述は、発明を網羅し、開示した形式そのものに本発明を制限することを意図 するものではない。多くの修正、変更が行えることは当業者には自明である。本 発明の範囲は、以下の請求項並びにそれと等価なものによって規定されるもので ある。

───────────────────────────────────────────────────── フロントページの続き (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＤＥ， ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，Ｌ Ｕ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ，ＣＦ ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＭＬ，ＭＲ，ＮＥ， ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，ＫＥ，ＬＳ，ＭＷ，Ｓ Ｄ，ＳＺ，ＵＧ，ＺＷ)，ＥＡ(ＡＭ，ＡＺ，ＢＹ，ＫＧ ，ＫＺ，ＭＤ，ＲＵ，ＴＪ，ＴＭ)，ＡＬ，ＡＭ，ＡＴ ，ＡＵ，ＡＺ，ＢＡ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ， ＣＨ，ＣＮ，ＣＵ，ＣＺ，ＤＥ，ＤＫ，ＥＥ，ＥＳ，Ｆ Ｉ，ＧＢ，ＧＥ，ＧＨ，ＨＵ，ＩＬ，ＩＳ，ＪＰ，ＫＥ ，ＫＧ，ＫＰ，ＫＲ，ＫＺ，ＬＫ，ＬＲ，ＬＳ，ＬＴ， ＬＵ，ＬＶ，ＭＤ，ＭＧ，ＭＫ，ＭＮ，ＭＷ，ＭＸ，Ｎ Ｏ，ＮＺ，ＰＬ，ＰＴ，ＲＯ，ＲＵ，ＳＤ，ＳＥ，ＳＧ ，ＳＩ，ＳＫ，ＳＬ，ＴＪ，ＴＭ，ＴＲ，ＴＴ，ＵＡ， ＵＧ，ＵＳ，ＵＺ，ＶＮ，ＹＵ，ＺＷ

Claims (1)

1. 【特許請求の範囲】 １．データ記憶ボリュームを管理し、データ記憶ボリュームに接続される複数の クライアントへ排他的書込アクセスを提供するボリューム管理システムにおい て、ａ）制御表が利用可能か否かを示す可用性インデシアと、ｂ）データ記憶 ボリュームの所有権を示す識別インデシアとを含む、前記データ記憶ボリュー ムに関係する制御表と、複数の制御プロセスであって、各プロセスが前記複数 のクライアントの内の対応するクライアント上で実行され、前記複数の制御プ ロセスが、前記複数のクライアントの各々に前記データ記憶ボリュームへの排 他的な書込アクセスを提供するために、前記制御表に関する排他的な所有権を 要求して取得する、そのような複数の制御プロセスとから成ることを特徴とす るボリューム管理システム。 ２．前記制御表が、ｃ）前記複数のクライアントの各々に関し、前記データ記憶 ボリュームへのアクセス特権を示すセキュリティインデシアを更に含み、前記 複数の制御プロセスが、データ記憶ボリュームへの読み取り専用アクセス特権 を示すセキュリティインデシアを有するとして前記制御表中に標示された複数 のクライアントの中のあるクライアントに対して、データ記憶ボリュームへの 書込アクセスを拒否するプロセスを更に含むことを特徴とする、請求項１に記 載のボリューム管理システム。 ３．前記複数の制御プロセスが、読み取り専用アクセス特権を有する前記複数の クライアントの各々の上のデータ記憶ボリュームに対応するファイルディレク トリを、更新するプロセスを更に含むことを特徴とする、請求項１に記載のボ リューム管理システム。 ４．前記複数の制御プロセスが、読み取り専用アクセス特権を有する前記複数の クライアントの各々の上のデータ記憶ボリュームに対応するファイルディレク トリを更新するプロセスを更に含むことを特徴とする、請求項２に記載のボリ ューム管理システム。 ５．前記複数の制御プロセスが、前記データ記憶ボリュームへの排他的書込アク セスを有する前記複数のクライアントの内の一クライアントのモニター上 に、排他的書込状態を解放する要求を表示するプロセスと、複数のクライアン トの内の一クライアントの入力装置から、解放要求に対する諾否の応答を受理 するプロセスとを更に含むことを特徴とする、請求項１に記載のボリューム管 理システム。 ６．前記複数の制御プロセスが、データ記憶ボリュームに関する複数のクライア ントの各々の状態を、あるクライアントのモニター上に表示するプロセスを更 に含み、前記状態は、読み取り専用と読み取り／書込の状態を含むことを特徴 とする、請求項１に記載のボリューム管理システム。 ７．前記複数の制御プロセスが、複数のクライアントの各々をデータ記憶ボリュ ームに接続する複数のデータ記憶ボリュームドライバーの各々を、複数のクラ イアントの各々が初期パワーアップされる間ロックするプロセスと、要求プロ セスと取得プロセスの開始時には、複数のデータ記憶ボリュームドライバーの 各々をアンロックするプロセスとを更に含むことを特徴とする、請求項１に記 載のボリューム管理システム。 ８．前記複数の制御プロセスが、前記複数のクライアントの内の第一クライアン トから前記複数のクライアントの内の第二クライアントへのメッセージを受理 し、かつ前記メッセージを前記制御表に書き込むプロセスと、メッセージが前 記制御表中に存在する旨決定し、かつ前記メッセージを前記複数のクライアン トの内の前記第二クライアントのモニター上に表示するプロセスとを更に含む ことを特徴とする、請求項１に記載のボリューム管理システム。 ９．データ記憶ボリュームに接続される複数のクライアントの間で、前記データ 記憶ボリュームに対し、互いに排他的な書込アクセスを実施させるコンピュー タシステム中の方法において、前記互いに排他的な書込アクセスを実施させる 方法が、制御表可用性のインデシアとデータ記憶ボリュームの所有権のインデ シアを記憶するために、前記複数のクライアントの各々に接続される制御表を 作成する行為と、前記複数のクライアントの内の第一クライアントの所で書込 要求を検出する行為と、前記検出行為に応じて、前記複数のクライアントの内 の前記第一クライアントに関する要求ルーチンを開始する行為であって、前記 要求ルーチンは、ａ）データ記憶ボリュームの所有権に関 するインデシアを基にして、前記複数のクライアントの内の他クライアントが 前記データ記憶ボリュームへの書込アクセスを有していると決定する行為と、 ｂ）前記決定する行為に応じて前記複数のクライアントの内の前記他のクライ アントに書込アクセスを解放するように解放要求を送る行為と、ｃ）前記複数 のクライアントの内の前記他のクライアントからの肯定通告に応じて、ｉ）所 有権に関するインデシアを、第一クライアントの所有権に関するインデシアで 置き換える行為と、ｉｉ）書込アクセス用に前記データ記憶ボリュームをマウ ントする行為とから成る、そのような要求ルーチンを開始する行為と、前記解 放要求を前記複数のクライアントの内の前記第二クライアントのところで取得 する行為と、前記複数のクライアントの内の前記第二クライアントに関する解 放ルーチンを開始する行為であって、前記解放ルーチンは、ａ）前記データ記 憶ボリュームへの書込アクセスを解放する行為と、ｂ）前記解放行為に関して 前記第一クライアントに肯定通告を送る行為とから成る、そのような解放ルー チンを開始する行為とから成ることを特徴とする方法。 １０．前記要求ルーチンと前記解放ルーチンが、複数の異なるファイルシステム プロトコルから発生してもよいことを特徴とする、請求項９に記載の方法。 １１．前記作成する行為が、データ記憶ボリュームへのアクセス特権を示すため の前記制御表中のセキュリティインデシアの記憶を複数のクライアントの各々 に提供する行為を更に含み、書込要求を検出する前記行為が、データ記憶ボリ ュームへの読み取り専用アクセスを標示する前記制御表中のセキュリティイン デシアを持った前記複数のクライアントの内の一つのクライアントに対して、 データ記憶ボリュームへの書込要求を拒否する行為を更に含むことを特徴とす る、請求項９に記載の方法。 １２．互いに排他的な書込アクセスを実施させる方法が、前記データ記憶ボリュ ームファイルディレクトリに変更が起きた際には、データ記憶ボリュームへの 読み取り専用アクセス特権を有する複数のクライアントの内の一クライアント 上のデータ記憶ボリュームファイルのコピーを更新する行為を更に含むことを 特徴とする、請求項９に記載の方法。 １３．互いに排他的な書込アクセスを実施させる方法が、排他的書込状態を解放 する要求を、前記データ記憶ボリュームへの排他的書込アクセスを有する複数 のクライアントの内の一クライアントのモニター上に表示する行為と、複数の クライアントの内の一クライアントの入力装置から、解放要求に対する肯定及 び拒否の応答を受理する行為とを更に含むことを特徴とする、請求項９に記載 の方法。 １４．互いに排他的な書込アクセスを実施させる方法が、データ記憶ボリューム に関する複数のクライアントの各々の状態を、複数クライアントの内の一クラ イアントのモニター上に表示する行為を更に含むことを特徴とする、請求項９ に記載の方法。 １５．互いに排他的な書込アクセスを実施させる方法が、複数のクライアントの 各々をデータ記憶ボリュームに接続する複数のデータ記憶ボリュームドライバ ーの各々を、複数のクライアントの各々の初期パワーアップの間ロックする行 為と、複数のデータ記憶ボリュームドライバーの各々を、前記要求及び取得プ ロセスが開始された時にアンロックする行為とを更に含むことを特徴とする、 請求項９に記載の方法。 １６．互いに排他的な書込アクセスを実施させる方法が、前記複数のクライアン トの内の第一クライアントから、前記複数のクライアントの内の第二クライア ントへのメッセージを受理し且つ前記制御表に前記メッセージを書き込む行為 と、メッセージが前記制御表中に存在することを決定する行為と、前記複数の クライアントの内の前記第二クライアントのモニター上にメッセージを表示す る行為とを更に含むことを特徴とする、請求項９に記載の方法。 １７．データ記憶ボリュームに接続された複数のクライアント間で、前記データ 記憶ボリュームへの互いに排他的な書込アクセスを実行させるべく具体化され たコンピュータ読み取り可能プログラムコード手段を有するコンピュタ使用可 能媒体において、前記製造物品中の前記コンピュータ読み取り可能プログラム コード手段が、制御表可用性のインデシアとデータ記憶ボリューム所有権のイ ンデシアを記憶するために、前記複数のクライアントの各々に接続された制御 表をコンピュータに作成させるためのコンピュータ読み取り 可能プログラムコード手段と、前記複数のクライアントの内の第一クライアン トのところで書込要求をコンピュータに検出させるコンピュータ読み取り可能 プログラムコード手段と、書込要求の前記検出に応じて前記複数のクライアン トの内の第一クライアントに関する要求ルーチンをコンピュータに開始させる ためのコンピュータ読み取り可能プログラムコード手段であって、前記要求ル ーチンは、ａ）前記複数クライアントの内の他クライアントが前記データ記憶 ボリュームへの書込アクセスを有している旨を、データ記憶ボリューム所有権 のインデシアに基づいて決定する行為と、ｂ）前記決定行為に応じて、前記複 数のクライアントの内の前記他クライアントに、書込アクセスを解放するよう 解放要求を送る行為と、ｃ）前記複数のクライアントの内の前記別のクライア ントからの肯定通告に応じて、ｉ）所有権インデシアを第一クライアントの所 有権インデシアで置き換える行為と、ｉｉ）書込アクセス用に前記データ記憶 ボリュームをマウントする行為から成る、そのような要求ルーチンをコンピュ ータに開始させるためのコンピュータ読み取り可能プログラムコード手段と、 前記複数のクライアントの内の前記第二クライアントのところで、前記解放要 求をコンピュータに取得させるためのコンピュータ読み取り可能プログラムコ ード手段と、前記解放要求の前記取得に応じて前記複数のクライアントの内の 前記第二クライアント上で解放ルーチンをコンピュータに開始させるためのコ ンピュータ読み取り可能プログラムコード手段であって、前記解放ルーチンは ａ）前記データ記憶ボリュームへの書込アクセスを解放する行為と、ｂ）前記 解放行為に関する肯定通告を前記第一クライアントに送る行為とから成る、そ のような解放ルーチンをコンピュータに開始させるためのコンピュータ読み取 り可能プログラムコード手段とから成ることを特徴とする、コンピュータ使用 可能媒体。 １７．複数のアクセス可能な記録のデータベースを管理し、各記録内の各フィー ルドへの排他的編集アクセスを、前記データベースに接続される複数のクライ アントに提供するための分散データベース管理システムにおいて、複数のロッ クフィールドであって、各フィールドが前記複数のアクセス可能な記録のフィ ールドの内の対応する一フィールドに関係する、そのような複数の ロックフィールドと、複数のコヒーレンシープロセスであって、各コヒーレン シープロセスは、前記複数のクライアントの内の対応する一クライアント上で 実行され、前記複数のコヒーレンシープロセスは、フィールドを編集する要求 を受信し、フィールド上に既存フィールドロックが無い場合、編集されたフィ ールドに係する前記複数のロックフィールドの内の一フィールドの排他的所有 権を主張することによりフィールド編集の要求を許可し、編集離脱要求を受信 した際には、編集されたフィールドに関係する前記複数のロックフィールドの 内の一フィールドの排他的所有権を取り下げる、そのような複数のコヒーレン シープロセスと、複数のデータベースプロセスであって、各データベースプロ セスが前記複数のクライアントの内の対応する一クライアント上で実行され、 前記複数のデータベースプロセスは、照会を受信し、照会に応じてデータベー スから記録を提供し、記録内のフィールドを編集する要求を受理し、フィール ド編集要求を対応するコヒーレンシープロセスに送り、フィールド編集離脱要 求を受理し、フィールド編集離脱要求を対応するコヒーレンシープロセスに送 る、そのような複数のデータベースプロセスとから成ることを特徴とする分散 データベース管理システム。 １８．前記複数のデータベースプロセスが、記録削除コマンドを受信し、記録の フィールドを消去し、前記記録に「フリー」のインジケーターを付けるプロセ スを更に含むことを特徴とする、請求項１７に記載の分散データベース管理シ ステム。 １９．前記複数のデータベースプロセスが、「フリー」のインジケーターを有す る記録の位置を特定し且つ前記インジケーターを「アクティブ」に変更するこ とにより、記録を追加するプロセスを更に含むことを特徴とする、請求項１８ に記載の分散データベース管理システム。 ２０．前記複数のデータベースプロセスが、前記複数のクライアントの各々が参 照する記録のリストを保守するためのプロセスを更に含むことを特徴とする、 請求項１７に記載の分散データベース管理システム。 ２１．前記複数のデータベースプロセスが、リスト中の第一記録に関係するクラ イアントに編集離脱通告を同報通信することにより、第一記録のフィール ドに関する編集離脱通告に応答するプロセスを更に含むことを特徴とする、請 求項２０に記載の分散データベース管理システム。 ２２．前記複数のデータベースプロセスが、フィールド編集を離脱するクライア ントからの同報通信を受信することにより、既存のフィールドロックを取り除 く時を決定するプロセスを更に含むことを特徴とする、請求項１７に記載の分 散データベース管理システム。 ２３．前記複数のデータベースプロセスが、データベースへの排他的な書込アク セスを捕らえ、記録を追加し、排他的書込アクセスを解放することにより、記 録を追加するプロセスを更に含むことを特徴とする、請求項１７に記載の分散 データベース管理システム。 ２４．前記複数のデータベースプロセスが、データベースの１部分であるロック フィールドを更に含むことを特徴とする、請求項１７に記載の分散データベー ス管理システム。 ２５．複数のアクセス可能な記録のデータベースを管理し、各記録内の各フィー ルドへの排他的な編集アクセスを前記データベースに接続される複数のクライ アントに提供するためのコンピュータシステムにおける方法において、前記デ ータベースを管理するための方法が、前記複数のクライアントの内の第一クラ イアントのところであるフィールドを編集するための要求を検出する行為と、 前記検出する行為に応じて前記複数のクライアントの内の第一クライアント上 でコヒーレンシールーチンを開始する行為であって、前記コヒーレンシールー チンは、ａ）前記フィールドに関係する所有権インデシアに基づいて、前記複 数のクライアントの内の別クライアントが前記フィールドへの編集アクセスを 有していると決定する行為と、ｂ）前記決定する行為に応じて、取り下げられ るべきフィールドに関係する所有権インデシアを待つ行為と、ｃ）フィールド に関係する所有権インデシアの取り下げに応じて、ｉ）編集されるべきフィー ルドに第一クライアントの所有権インデシアを付ける行為と、ｉｉ）フィール ドに編集アクセスを提供する行為とから成る、そのようなコヒーレンシールー チンを開始する行為と、前記複数のクライアントの内の第一クライアントのと ころでフィールド編集離脱要求を取得する 行為と、前記取得する行為に応じてａ）前記フィールドから第一クライアント の所有権インデシアを取り除く行為を含むコヒーレンシールーチンを前記複数 のクライアントの内の第一クライアント上で開始する行為とから成ることを特 徴とする方法。 ２６．前記データベースを管理するための方法が、記録削除コマンドを受信する 行為と、前記受信する行為に応じて、ａ）前記記録のフィールドを消去する行 為と、ｂ）前記記録に「フリー」のインジケーターを付ける行為とを更に含む ことを特徴とする、請求項２５に記載の方法。 ２７．前記データベースを管理するための方法が、記録追加コマンドを受信する 行為と、前記受信する行為に応じて、ａ）「フリー」のインジケーターを有す る記録の位置を特定する行為と、ｂ）前記「フリー」のインジケーターを「ア クティブ」のインジケーターに変更する行為とを更に含むことを特徴とする、 請求項２５に記載の方法。 ２８．前記データベースを管理するための方法が、記録を参照する行為と、前記 参照する行為に応じて、ａ）複数のクライアントの各々が参照する記録のリス トを更新する行為とを更に含むことを特徴とする、請求項２５に記載の方法。 ２９．前記データベースを管理するための方法が、リスト中の第一記録に関係す るクライアントに編集離脱通告を同報通信することにより、前記第一記録のフ ィールドに対する編集離脱要求に応答する行為を更に含むことを特徴とする、 請求項２８に記載の方法。 ３０．前記データベースを管理するための方法が、フィールド編集を離脱するク ライアントからの同報通信を受信することにより、既存のフィールドロックを 取り除く時を決定する行為を更に含むことを特徴とする、請求項２５に記載の 方法。 ３１．前記データベースを管理するための方法が、データベースへの排他的書込 アクセスを捕らえ、記録を加え、排他的書込アクセスを解放することにより、 データベースに記録を追加する行為を更に含むことを特徴とする、請求項２５ に記載の方法。 ３２．前記データベースを管理するための方法が、前記ロックフィールドを前記 データベース内に作成する行為を更に含むことを特徴とする、請求項２５に記 載の方法。 ３３．複数のクライアントに接続されているネットワーク上のプロジェクトを管 理するための分散プロジェクト管理システムにおいて、前記分散プロジェクト 管理システムが、コンピューターネットワーク上に記憶された少なくとも一つ のプロジェクト管理フォルダと、各管理プロセスが前記複数のクライアントの 内の対応するクライアント上で作動する複数の管理プロセスとから成り、前記 プロジェクト管理フォルダは少なくとも一つの記録を含み、前記少なくとも一 つの記録は、ソースファイル名、ソースファイル位置、第一アプリケーション 名、第一アプリケーションプログラムコード、第一アプリケーション宛先ファ イル名、第一アプリケーション宛先ファイル位置を含んでおり、前記複数の管 理プロセスは、前記プロジェクト管理フォルダ内の前記少なくとも一つの記録 を読み取り、前記第一アプリケーション名に対応する常駐アプリケーションに 前記ソースファイルを読ませ、前記ソースファイル上で前記第一アプリケーシ ョンプログラムコードに従って演算実行させ、結果的成果物を宛先ファイル名 を有するファイル内の宛先ファイル位置に記憶せることを特徴とする分散プロ ジェクト管理システム。 ３４．宛先ファイル位置に結果的成果物を記憶させるための前記複数の管理プロ セスが、前記少なくとも一つのプロジェクト管理フォルダ内の前記少なくとも ーつの記録に完了の印を付けるプロセスを更に含むことを特徴とする、請求項 ３３に記載の分散プロジェクト管理システム。 ３５．前記複数の管理プロセスが、複数のクライアントの間で複数のクライアン トの各々に対する利用インジケーターを共有するプロセスを更に含むことを特 徴とする、請求項３３に記載の分散プロジェクト管理システム。 ３６．前記複数の管理プロセスが、前記利用インジケーターに基づいて、前記複 数のクライアントの内の一つのクライアントにプロジェクト管理フォルダを割 り当てるプロセスを更に含むことを特徴とする、請求項３５に記載の分散プロ ジェクト管理システム。 ３７．前記複数の管理プロセスが、複数のプロジェクト管理フォルダを管理する プロセスを更に含むことを特徴とする、請求項３３に記載の分散プロジェクト 管理システム。 ３８．複数のプロジェクト管理フォルダを管理するための前記プロセスが、前記 複数のプロジェクト管理フオルダに処理優先順位を割り当てるプロセスを更に 含むことを特徴とする、請求項３７に記載の分散プロジェクト管理システム。 ３９．複数のプロジェクト管理フォルダを管理するための前記プロセスが、複数 クライアントの内の選択されたクライアントにプロジェクト管理フォルダの管 理を分配するためのプロセスを更に含むことを特徴とする、請求項３３に記載 の分散プロジェクト管理システム。 ４０．複数のクライアントの内の選択されたクライアントが、前記プロジェクト 管理フォルダ上で対等な関係で作動することを特徴とする、請求項３９に記載 の分散プロジェクト管理システム。 ４１．複数のクライアントの内の選択されたクライアントが、前記プロジェクト 管理ファイル上で階層的関係で作動することを特徴とする、請求項３９に記載 の分散プロジェクト管理システム。 ４２．複数のクライアントに接続されたネットワーク上でプロジェクトを管理す るための方法において、コンピュータネットワーク上でプロジェクト管理ファ イルを作成する行為であって、前記プロジェクト管理フォルダは少なくとも１ つの記録を含み、前記少なくとも１つの記録は、ソースファイル名、ソースフ ァイル位置、第一アプリケーション名、第一アプリケーションプログラムコー ド、第一アプリケーション宛先ファイル名、第一アプリケーション宛先ファイ ル位置を含む、そのようなコンピュータネットワーク上でプロジェクト管理フ ァイルを作成する行為と、前記複数のクライアントの内の第一クライアントの ところで、プロジェクト管理ファイルのネットワーク上の位置を検出する行為 と、前記検出する行為に応じて前記複数のクライアントの内の前記第一クライ アント上で管理プロセスを開始する行為であって、前記管理プロセスは、ａ） 前記プロジェクト管理ファイル内の前記少なくとも 一つの記録を読み取る行為と、ｂ）前記第一アプリケーション名が前記複数の クライアントの内の前記第一クライアント上の対応するアプリケーションに合 致することを決定する行為と、ｃ）前記対応するアプリケーションに前記第一 アプリケーションプログラムコードに従って前記ソースファイル上で演算を実 行させ、結果的成果物を宛先ファイル名を有するファイル内の宛先ファイル位 置に記憶させるため、前記第一アプリケーションプログラムコードを、前記対 応するアプリケーションに送る行為とから成る、そのような前記複数のクライ アントの内の前記第一クライアント上で管理プロセスを開始する行為とから成 ることを特徴とする、プロジェクトを管理するための方法。 ４３．前記送る行為が、前記少なくとも一つのプロジェクト管理フォルダの中の 前記少なくとも一つの記録に完了の印を付ける行為を更に含むことを特徴とす る、請求項４２に記載のプロジェクトを管理するための方法。 ４４．複数のクライアントの間で、複数のクライアントの各々に対する利用イン ジケーターを共有することを特徴とする、請求項４２に記載のプロジェクトを 管理するための方法。 ４５．プロジェクト管理フォルダを前記複数のクライアントの内の一つに、前記 利用インジケーターに基づいて割り当てる行為を更に含むことを特徴とする、 請求項４２に記載のプロジェクトを管理するための方法。 ４６．複数のプロジェクト管理フォルダを管理する行為を更に含むことを特徴と する、請求項４２に記載のプロジェクトを管理するための方法。 ４７．前記複数のプロジェクト管理フォルダに、処理優先順位を割り当てる行為 を更に含むことを特徴とする、請求項４６に記載のプロジェクトを管理するた めの方法。 ４８．プロジェクト管理フォルダの管理を複数のクライアントの内の選択された クライアントに配分する行為を更に含むことを特徴とする、請求項４２に記載 のプロジェクトを管理するための方法。 ４９．複数のクライアントの内の前記選択されたクライアントが、前記プロジェ クト管理ファイル上で、対等の関係で作動することを特徴とする、請求項４８ に記載のプロジェクトを管理するための方法。 ５０．複数のクライアントの内の前記選択されたクライアントが、前記プロジェ クト管理ファイル上で、階層的関係で作動することを特徴とする、請求項４８ に記載のプロジェクトを管理するための方法。