JPH03129443A - ファイル転送方法とその装置 - Google Patents

Abstract

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

Description

【発明の詳細な説明】 〔産業上の利用分野〕 本発明は、ファイル転送方法およびファイル転送装置に
関するものであり、より特定的には、任意のオペレーテ
ィングシステムが動作するコンピュータによって任意の
ディスクの内容を読み出しおよび書き込みを可能にする
方法および装置に関する。さらに詳しく述べると５本発
明は、ホストコンピュータシステムで動作し、ホストコ
ンピュータのオペレーティングシステムとは異なる（ｆ
。

ｒｅｉｎ）オペレーティングシステムに通したファイル
フォーマットを有するディスクに対してユーザー（利用
者）がアクセスでき、修飾でき、そして、オリジナルシ
ステムで修飾したファイルを異なるディスクに戻し、そ
れにより、ユーザーに明瞭なディスク・ファイルフォー
マットを作成するアプリケーションプログラムを動作さ
せる方法および装置に関する。

〔先行技術〕

本発明と同様の目的を達成するための本出願の先行技術
として１本出願の出願人による米国特許出願番号第０７
／２５４，２７４号（１９８８年１０月６日米国出願１
発明者、ジタン・デブリュウ・ライスラー）に基づいて
我が国に平成元年１０月５日に優先権主張して出願され
た特願平１−２５７．２０８号、「マルチファイル転送
動作を遂行する装置とその方法」がある。

〔従来の技術〕

第１図は従来の、異なるファイルフォーマット内のディ
スクファイル用の転送方法を図解する図である。

第１図に示すように、たとえば、対応する第１のファイ
ルフォーマットを備えた仮想メモリシステム（Ｖ　Ｍ　
Ｓ　：　Ｖｉｒｔｕａｌ　Ｍｅｍｏｒｙ　Ｓｙｓｔｅｍ
）などの。

あるオペレーティングシステムが動作するコンピュータ
システム１２のディスクシステムＩＯから、たとえば、
対応する第２のファイルフォーマットを備えたＭＳ−Ｄ
Ｏ３（マイクロソフト社の商標）などの他のオペレーテ
ィングシステムが動作する第２のコンピュータシステム
１６の他のディスクシスチムニ４ヘデータを転送する従
来の方法は、ローカルエリアネットワーク（ＬＡＮ）を
介して、または、モデム１８および２０を用いる電話回
線システムを介してデータを転送することにある。ディ
スクのファイルフォーマットは２つの事項を有している
。その第１のものは、ディレクトリ構造であり、このデ
ィレクトリ構造はファイルがどこに配置されているか、
ファイル相互間の関係、および、ファイル自体を記述す
る情報を示している。ファイルフォーマットの第２のも
のはファイル内のテキストライン（ｔｅｘｔ　１ｉｎｅ
）に関する記録フォーマットなどのファイルの内部構造
に関するものである。

〔発明が解決しようとする課題］ 上記した方法は、ファイルが共通の伝送ファイルに変換
されるべきこと、および、物理的に接続された異なるコ
ンピュータ１２と１４との相互間の伝送媒体にわたって
転送されるべきことを要求している。他の方法は、磁気
テープなどの共通にフォーマット化された媒体に磁気デ
ータが記憶されること、および、異なるコンピュータ１
２と１４との相互間で磁気テープを物理的に運搬するこ
とである。パーソナルコンピュータなどの数多くの小規
模のシステムは、容易に利用できる磁気テープを有して
おらず、やむをえず、ネットワーク転送方法を用いなけ
ればならない。これら両者の方法は応答が遅く、他の目
的に利用できないハードウェアを要求している。

（課題を解決するための手段） したがって１本発明の目的は、もしオリジナルのオペレ
ーティングシステムが異種のファイルシステムの情報の
ファイルに対応していない場合。

同じコンピュータ上の異なるファイルシステム相互間で
情報をユーザーが移動することを可能にするシステムを
提供することにある。

本発明の他の目的は、異なるディスク上の情報にユーザ
ーがアクセスすることを可能にすることにある。

本発明の付加的な目的は、ユーザーが異なるディスク上
に情報を書き込むことを可能にすることにある。

上述した問題を解決し、上述した目的を遠戚するため１
本発明は、異なる形態でフォーマット化されたディスク
相互間で特定されたファイルをユーザーが転送可能でき
る処理とデータ構造の独立した組を提供することにより
達成する。すなわちそのための処理は、ソースディスク
およびディストネーションディスクのファイルフォーマ
ットを同定し、ソースファイルフォーマット内のソース
ファイルを検索し、ソースディスクのディレクトリ階層
およびディストネーションディスクが維持されることを
可能にするメモリ内のメモリフォーマット内にソースフ
ァイルを記憶し、もし必要ならばテキスト・ソースファ
イル・レコードの内容をディストネーションファイル・
システムの記録フォーマットに翻訳しく　ｔｒａｎｓ　
ｌａ　ｔｅ）　、　　もし必要ならば転送されたフォー
マットについての異種フォーマットのディスクのために
ディレクトリとヘッダを生威し、そして、ホスト・ファ
イルフォーマットがあるディストネーションディスクに
そのファイルを記憶する。そこで１ユーザーはホストコ
ンピュータシステムを用いてファイルにアクセスしてフ
ァイルを修飾することができ、そして。

ソースディスクとして動作するホストシステムフォーマ
ットディスクおよびディストネーションディスクとして
動作する異なるシステムフォーマット化されたディスク
を用いて、同じルーチンを用いて異なるファイルフォー
マット内の異なるディスクに修飾したファイルを再び転
送することができる。

本発明のこれらの目的と他の目的ならびに他の利点は２
それらの一部を形成する添付図面に関連付けて下記によ
り詳細に記述され、特許請求の範囲に記述される詳細な
ｔ！或および動作の詳細によってより明瞭にされるので
あり、添付図面において同じ符号が付された要素は図面
全体を通じて同様の構成要素を示している。

（実施例） 第２図は本発明の動作を図解する図である。

本発明は第２図に示すように、単一のコンピュータ３０
が異種のフォーマットディスク３２．好適には３本出願
の出願人であるアルファトロニクス社が提供する“ｌＮ
５ＰＩＲＥ　（商標）ｎモデルディスクドライブなどの
ディスクドライブ３４に搭載されたフォーマットディス
ク３２にアクセスを可能にしている。本発明の転送シス
テム３６はまた。ユーザー３８によって指定されるもの
としての、異種のフォーマットディスク３２の内容を、
ホスト、または好適にはまたｌＮ５Ｐ　ＩＲＥモデルデ
ィスクドライブであるディスクドライブ４２内の元々の
（ｎａｔｉｖｅ）ファイルフォーマント・ディスク４０
に転送する。この転送システム３６（またはバイパスシ
ステム３６）のアプリケーションプログラムは、ホスト
コンピュータ３０内で動作するホストオペレーティング
システム４４をバイパスし、ホストフォーマットディス
ク４０に記憶されている異種のファイルフォーマ−／　
）・ディスクフォーマットの内容をホストオペレーティ
ングシステム４４のファイルフォーマットに記憶する。

ユーザー３８はそこで、ホストオペレーティングシステ
ム４４を介して、またはホストオペレーティングシステ
ム４４を通してホストフォーマットディスク４０に記憶
されているファイル内容にアクセスするホストアプリケ
ーションプログラム４６のいずれかを介して、ホストフ
ォーマットディスク４０に転送されたファイルにアクセ
スできる。−旦ユーザー３８が転送されたファイルの検
討を終了すると、またはファイルの修飾（ｍｏｄｉｆｉ
ｃａｔｉｏｎ）を終了すると、ホストディスク４０に記
憶されたホストファイルフォーマット内のファイルが、
転送システム３６によって、異種のファイルフォーマッ
ト内のファイルに変換され。

異種のファイルフォーマットディスク３２に記憶される
。それにより１本発明は、ファイルがホストコンピュー
タシステムによってアクセス可能なファイルフォーマッ
ト内にあるか否かに患わされることなく、ユーザー３８
が任意のオペレーティングシステムで動作している任意
のコンピュータのディスクの内容にアクセスすることを
可能にしている。本発明は、ディスクドライブ３４およ
び４２を要求しており、これらのディスクドライブはハ
ードウェア適合性を有しており、これらのディスクドラ
イブにおいてデータが標準の物理的なディスクフォーマ
ットで記憶される。好適な物理的なディスクフォーマッ
トは、ＡＮＳＩ、ｌ５Ｏ１および、トラックとディスク
が分割されているセクタの番号との間隔などのディスク
上の情報の物理的な配置を特定する日本の研究諮問２３
（Ｊａｐａｎ　５ｔｕｄｙ　Ｃｏｍｏ＋１ｔｔｅｅ　２
３：　Ｊ　ａ　ｐ　ａ　ｎ　　２３）によって採用され
ている光学的ディジタルデータ・ディスクフォーマット
である。この物理的なディスクフォーマットの記述は、
　　Ｉ　Ｓ　ＯＬｔ文”Ｏｐ　ｔｉｃａｌ　　Ｄｉｇｉ
ｔａｌ　　Ｄａｔａ　　Ｄｉｓｋ′″に見出される。上
述したｌＮ５ＰＩＲＥモデルデイスクドライブなどの光
学的ディスクドライブの出現は必要とされるハードウェ
ア適合性を提供している。

本発明の転送システム３６は、アプリケーションプログ
ラムであり、好適には、異なるオペレーティングシステ
ムを有するコンピュータシステム相互間で輸送可能なＣ
言語などのプログラム言語で書かれている。アプリケー
ジチンプログラムの動作およびこのアプリケージタンプ
ログラムで用いられるデータ構造がＣプログラム言語の
文脈（ｃａｎ　ｔｅｘ　ｔ）についてのフローチャート
を参照して述べられるが１本発明はＦＯＲＴＲＡＮおよ
びＰＡＳＣＡＬなどの他のプログラム言語でも実現でき
る。本発明の動作はまた。もし必要ならば、好適ではな
いプログラム言語のある種のもので、いわゆる、当業者
としての本出願の明細書の読者が本発明を実施可能とす
るフローチャートを用いて記述される。しかしながら９
本出願では参考資料としてプログラムリストを添付して
おり、この参考資料は好適なプログラム言語で実施する
ために適切な疑似（ｐｓｅｕｄｏ）コード形式の言語で
本発明の処理を詳細に記述しており、この好適なプログ
ラム言語に対して本出願の明細書の読者はフローチャー
トのブロックの詳細について参照することができよう。

本発明はまた特に、ＩＢＭ　　ＰＣ／ＡＴ（１８Ｍ社の
商標）などのＤＯＳオペレーティングシステムが動作す
るマシンで動作するブロックＩ１０を介してＤＯＳソー
スディスクからＶＭＳディストネーションディスクにブ
ロックＩ１０転送を参照して記述される。たとえば、Ｕ
ＮＩＸ（ＡＴ＆Ｔ社からのマルチプルユーザー、マルチ
プルタスク用オペレーティングシステム）などの他のオ
ペレーティングシステムに対して、または、他のオペレ
ーティングシステムから転送することに関する本発明の
詳細な実施がさらに記述される。上述したオペレーティ
ングシステムに関した本発明を実施するに当たって、当
業者である本出願の読者の役にたつ上述したオペレーテ
ィングシステムのファイルシステムの記述が、ＲａｙＤ
ｕｎｃａｎによる”Ａｄｖａｎｃｅｄ　　ＭＳ−ＤＯ３
Ｐｒｏｇｒａｍｉｎｇ　　、ＭｏｒｒｉｓＪ、Ｂａｃｈ
による”Ｔｈｅ　　Ｄｅｓｉｇｎ　　。

ｆ　　ｔｈｅ　　ＵＮＩＸ”　　　’ＳＵＮ　　Ｏ３Ｒ
ｅｆｅｒｅｎｃｅ　　Ｍａｎｕａｌ　　Ｒｅ１ｅａｓｅ
４．０，５ｅｃｔｉｏｎ　　５−Ｆｉｌｅ　　Ｆ。

ｒｍａｔｓ　　　　　　”ＳＵＮ　　　Ｏ３Ｒｅｆｅｒ
ｅｎｃｅ　　　Ｍａｎｕａｌ　　　Ｒｅ１ｅａｓｅ　　
　４．０゜Ｓｙｓｔｅｍ　　　Ｉｎｃｌｕｄｅ　　　Ｆ
ｉｌｅ−ＯｎＬｉｎｅ　　、　　’ＶＡＸ／ＶＭＳ　　
ＵｓｅｒｓＭａｎｕａｌ　　　Ｐａｒｔ　　　２．ＤＣ
Ｌ　　Ａｐｐｅｎｄｉｘ　　、　　”ＶＡＸ／ＶＭＳ　
　　Ｉｌｏ　　Ｒｅｆｅｒｅｎｃｅ　　　Ｖｏｌｕｍｅ
　　　Ｉ”　　　”ＶＡＸＶＭＳ　　　Ｒｅｃｏｒｄｓ
　　　ＭａｎａｇｅｍｅｎｔＳｅｒｖｉｃｅｓ　　　Ｒ
ｅｆｅｒｅｎｃｅ　　　Ｍａｎｕａ　１”、および、こ
こに参照することによって一体化された’ＶＡＸ／ＶＭ
Ｓ　　Ｓｙｓｔｅｍｓ　　５ｅｒｖｉｃｅｓ　　Ｒｅｆ
ｅｒｅｎｃｅ　　Ｍａｎｕａｌなどの参考図書に見出さ
れる。上述したものの他のオペレーティングシステム、
たとえば、アポ口（ＡｐｏｌｌＯ）コンピュータ用のＡ
ＥＧＩｓオペレーティングシステムまたはＩＢＭパーソ
ナルシステムコンピュータ用０３−２オペレーテイング
システムなどは２列挙していないオペレーティングシス
テムについて本発明を実施するために必要な詳細事項が
見出される。上記同様の利用可能な参考文献がある。た
とえば、そのようなオペレーティングシステム内にディ
スクフォーマットされたものとしてオペレーティングシ
ステムディスクをただひとつに同定させる詳細事項がそ
のような参考文献に一般的に見出される。もし。

ある理由のため、あるいは、適切なオペレーティングシ
ステムの参考文献内に特別のオペレーティングシステム
用の他のファイルフォーマット定義情報が利用可能にな
っていない場合、オペレーティングシステムを設計する
当業者は、各ディスクが、たとえば、クラスタサイズ、
ファイルの最大の番号、ディレクトリ名称、アロケーシ
ッン制御リストなどを維持する共通の情報を探し出すフ
ァイルフォーマットを容易にリバースエンジニアするこ
とができる。ディスクのリバースエンジニアリングする
人は、空いているディスクをフォーマット化し、内容を
ダンプし、ディスクを既知の内容および既知のファイル
構造とともにロード（装荷）シ、再びディスクの内容を
ダンプし、それから、ファイルの内容および構造を変更
し、さらにその内容をダンプする。そのような知られて
いる内容および構造のダンプとともに変更する一連の作
業によって、異なるディスク用のファイルフォーマット
情報の配置（１ｏｃａ　ｔ　１ｏｒｉ）および配列（ａ
ｒｒａｎｇｅｍｅｎｔ）を決定することが可能になる。

本発明を実施するユーザー３８は、ディスクドライブ３
４に異種のフォーマットディスク３２を装荷し、および
、ディスクドライブ４２に搭載されたホストフォーマッ
トディスク４０を装荷し。

本発明の転送システムまたはバイパスアプリケーション
プログラム（転送システム）３６をロードし、実行する
。多くの場合、ユーザー３８はホストコンピュータ３０
で必要なファイルの全て、および、異種のフォーマット
ディスク３２に記憶されているファイルの全てについて
は記憶しておらず２またユーザー３８は異なるフォーマ
ットディスク３２上のディレクトリについて検討を可能
にするＤＩＲ（ディレクトリ）などの転送システム・デ
ィレクトリ・アクセス・コマンドを入れる。

ユーザー３８はそれから、コマンドを用いて転送すべき
ファイルを特定するが、そのようなコマンドとしては、
ソースディスクＡ（ディスクドライブ３４）の全てのデ
ィレクトリと、それらのディレクトリ内のファイルを、
　　　ｓｅｔ″で終わるディレクトリを持つディストネ
ーションディスクＥ（ディスクドライブ４２）に複写す
るコマンド“Ｃ０ＰＹ　　Ａ：＼＊ｓｅｔ＼、、、　　
＼＊、＊Ｅ：”がある。転送システム３６は、異種のフ
ォーマットディスク３２のフォーマットを自動的に検出
し、適切なファイルを転送する。この転送システム３６
を簡単に改変することによって、自動的にファイルを検
出する代わりに、ユーザー３８にファイルフォーマット
を同定することを問い合わせることができる。ユーザー
３８はまた。転送決定が行われる前に詳細なファイル内
容の検討についてユーザー用表示装置またプリンタにフ
ァイルの内容を提供するＴ　Ｙ　Ｐ　Ｅ　”などのファ
イルレビューコマンドを入れる。

第３図は本発明のグローバルな動作記述データ構造６０
の内容を図解する図である。

また、第４図は処理実行、および、ファイル入出力（Ｉ
ｌｏ）転送に対するファイル■／○のためのデータの流
れを図解する図である。なお、第４図において、実線は
データの流れを示し、破線はポインタの移動制御を示し
ている。

−旦、転送システム３６について第４図に図解したユー
ザーインターフェース処理プログラム１００がコマンド
を分析すると、コマンド、この状況においては“Ｃ０Ｐ
Ｙ”コマンドが、第３図に図解した。動作記述データ構
造６０のコマンドフィールド６２に記憶される。この動
作記述データ構造６０はアレイ構造であり、このアレイ
構造は”　Ｓ　／　Ｄ″”で終わるフィールドが一方が
ソース（Ｓ）で他方がディストネーション（Ｄ）である
２つのエントリまたは２つのサブフィールドを有してい
る。つまり、第３図の「Ｓ／Ｄ」は、一方がソース（Ｓ
）、他方がディストネーション（Ｄ）である２つのエン
トリのアレイを示している。

この動作記述データ構造６０は、グローバルなデータ構
造であり、このグローバルなデータ構造は本発明の全て
の処理プログラムによって参照される。転送システム３
６はまた。装置名称フィールド７２にディスク装置名称
“Ａ”および°“Ｅ′を記憶する。装置情報７０は、装
置がランダムアクセス・ディスク装置であることを確実
化し、いかにしてそれらが、たとえば、ＶＭＳにファイ
ルを有する異種のディスク装置が搭載されるかを決定す
るために得られる。次いで、転送システム３６はソース
およびディストネーシゴン用のファイルシステムの形式
を決定し、その形式をフィールド６６に記憶する。上述
したように、もし本発明のより簡単な改変が行われた場
合、ユーザーによって特定されるファイルの形式はこの
フィールド６６に挿入されるようになる。

ファイル形式の決定は好適には、後述するように、ＶＭ
ＳとＵＮＩＸとがファイル形式の決定に良好な方法を提
供するチエツクサムを有しておりそれゆえ、ディスクフ
ァイルフォーマントの形式を誤って同定する可能性が少
ないので、　　ＤＯＳファイルフォーマット形式の決定
が最後に行われる順序に従う。ＶＭＳファイルフォーマ
ット化されたディスクにおいては、そのディスクのホー
ムブロックにおける２つのチエツクサムが正しくなけれ
ばならず、そして、ＶＭＳディスクとして一義的に同定
されるべきディスクについてノンゼロ（非ゼロ）でなけ
ればならない。ＵＮＩＸファイルフォーマットディスク
はある種のチエツクサムを有しており、このチエツクサ
ムも正しく、そして、そのディスクがＵＮＩＸフォーマ
ットディスクとして一義的に同定されるようにノンゼロ
でなければならない。ＤＯ３でフォーマット化されたデ
ィスクを同定するために、そのディスクの第１のブロッ
クであるＢ　Ｉ　ＯＳ　（Ｂａｓｉｃ　Ｉｎｐｕｔ　０
ｕｔｐｕｔＳｙｓ　ｔｅｎ）パラメータブロックは、そ
の中のフィールドが有効か否かを決定するためにチエツ
クされなければならない。この有効性の検査は、改定部
およびＯＥＭフィールドが英数字（ａｌｐｈａｎｕｍｅ
ｒｉｃ）文字、ブランク、または、″、ｎ文字のいずれ
かの文字を含んいるかどうかを決定し、クラスタあたり
のセクタ、ファイルアロケーションテーブルの数および
保存セクタの数がゼロでないかどうかを決定し、セクタ
あたりのバイト数が１２８の倍数であるか否かを決定し
、ディスクの全容量が最小のディスク容量より大きいか
否かを決定し。

そして、ディレクトリエントリのルー１−　（ｒｏｏ　
ｔ）の数（エントリあたりのスペース）がセクタと均一
な倍数であるか否かを決定する。もしこれらの全ての決
定が肯定的な場合、そのディスクはり。

Ｓディスクとして一義的に同定される。ソースブロック
リード処理プログラム２７４およびディストネーション
ブロックライト処理プログラム３００は（これらについ
ては後述される）、ディスクの形式を決定するために初
期状態において起動され、そして、上記したように適切
な情報が装荷されているとき、復帰する。異なるディス
クの論理的なブロックサイズも決定され、フィールド６
８に記憶される。この出願明細書の文脈において。

論理的なブロックサイズは２つの異なる意味を持つ。第
１の意味は、異なるディスクオペレーティングシステム
に戻されるとき解釈されるであろう、異なるディスクの
論理的なブロックサイズである。この情報は、ＢＩＯＳ
パラメータブロックにおけるＤＯ３のために、そして、
ホームブロック内のＶＭＳのためにディスクに記憶され
る。この情報は、これらのブロックがチエツクされ、そ
のディスクの形式が決定されるときに、抽出される。そ
れから、この値は、上述したように、フィールド６８内
のグローバルな動作記述データ構造６０に記憶される。

一方、他の意味は、論理的な人力／出力・リード／ライ
ト動作の間に用いられる、論理的なブロックサイズであ
る。ＶＭＳおよびＵＮＩＸにおいてはＩｌｏの論理的な
ブロックサイズは常に５１２バイトであるが、ＤＯ３に
おいてはその論理的なブロックサイズがディスク間のサ
イズによって変化する。ＤＯＳフォーマット化されたデ
ィスクにおけるブロックＩ１０サイズは、パターン“’
５Ａ”によってバッファが最初に充満されることによっ
て決定される。ここで、バッファはＤＯ３において利用
可能な最大のブロックよりも大きいものとする。最初の
リード（読み出し）コールによってこのバッファは充満
され、そのバッファがいかにして書き込みによって一杯
になるかを見るためにチエツクされる。決定されたサイ
ズはＤＯ３のＩ　／　Ｏ論理的なブロックサイズである
。Ｉ１０コールにおいて生ずる。後述するサイズ相互間
の翻訳処理は、これら２つの意味の相互間の翻訳である
。

上述したように、ディスクファイルシステムの形式がフ
ィールド６６に記憶される一方、転送されているファイ
ルに関するファイル仕様がフィールド７４に記憶される
。上述した例における仕様は’＊ｓｅｔ”である。もし
ソースディスクまたはディストネーションディスクがホ
ストコンピュータ３０のホストオペレーティングシステ
ム４４とは異なる場合、それらのディスクに対する転送
またはそれらのディスクへの転送はブロックＩ１０転送
でなければならない。もしソースディスクまたはディス
トネーションディスクのフォーマントが元々のものであ
れば、すなわち、ホストオペレーティングシステム４４
のフォーマットに等しいならば、そのディスクに対する
転送またはそのディスクからの転送はファイルＩ１０転
送によって行われる。しかしながら、ブロックＩ１０転
送において本発明を用いると、リングバッファリング方
式を用いているので、ファイル■／○転送を用いた場合
より転送が速くなる。たとえば、　ＶＭＳが動作してい
るコンピュータシスチムニ異すったファイルフォーマッ
トが搭載されたＶＭＳディスクを用いると、ブロックＩ
１０転送は９本発明においては、ファイルＩ１０転送よ
り速くなる。

その理由は、異なるオペレーティングシステム（ファイ
ルフォーマット）が搭載されたＶＭＳディスクはシステ
ムの他のユーザーによって同時には修飾されないからで
あり、このよう番こスピードの向上が可能になる。ＤＯ
３が動作しているコンピュータシステムについて、転送
スピードを向上させるためのブロックＩ１０転送も行わ
れる。その理由は、ＤＯ３が単一のユーザーに対する非
多重化タスク処理（ｎｏｎ−ｍｕｌｔｉ−ｔａｓｋｉｎ
ｇ）システムであり、ユーザーがファイルを修飾する危
険を生じさせないようにしており、一方、それらのディ
スクは本発明によってアクセスされているからである。

しかしながら、ＬＡＮ上のＤＯＳファイル・サーバ（ｓ
ｅｒｖｅｒ）が目標とするシステムであるときはファイ
ルＩ１０が用いられなければならない。

その理由は１より多くの（２以上の）コンピュータがデ
ータをアクセスしなければならないかもしれないからで
ある。

解釈の後、もし転送コマンドが実行されていてディスク
のあるものが異種のファイルフォーマットディスクであ
る場合、ユーザー３８はまた。ユーザーインターフェー
ス処理プログラム１００によって、ファイルの内容が翻
訳を必要とするか否かについて質問され、もしそうであ
れば、翻訳フラグ６４がセットされる。翻訳フラグ６４
がセットされている場合全てのファイルが翻訳される。

勿論、ユーザー３８が翻訳を必要とする各々のファイル
を指定することを可能にする特別の翻訳アレイを生成す
ることも可能である。翻訳フラグ６４０セツトは、ユー
ザー３８がテキストファイルの内容のラインレコード・
フォーマットをソースディスクのフォーマットからディ
ストネーションディスクのフォーマットに変換すること
を欲していることを特定している。たとえば、テキスト
ファイル用ＤＯ５において、各ラインレコードはキャリ
ジリターンおよびラインフィードで終わり。

一方、ＶＭＳにおいては、使用されている複数のレコー
ドフォーマットの１つにおいて、ラインレコードはライ
ンレングス・キャラクタで始まる。

翻訳フラグ６４は、適切なレコードフォーマット翻訳を
もたらすことができ、上述した例においては、ラインフ
ィードを加えたり取ったり、ラインレングス・フィール
ドを除去したり加えたり、必要ならば完全にしたり、ヘ
ッダのライン終端フィールドをＶＭＳディスク状況にお
けるラインフィード終端ファイルに適切にセットするこ
とができる。

もしディストネーションディスクがＶＭＳディスクの場
合、ＶＭＳ内のディレクトリエントリが分類されなけれ
ばならないので、ユーザーインターフェース処理プログ
ラム１００によって分類フラグ８４が自動的にセットさ
れる。”　ＣＯＰ　Ｙ”コマンドに関して９分類フラグ
８４が常にセットされ、それにより、詳細については後
述するファイル記述２次元リスト１０８がより迅速に検
索でき、このリスト１０８内のエントリがディストネー
ションディスクのディレクトリにすでに存在するか否か
が決定できる。

（以下余白） 初期状態で起動されているバッファ制御処理プログラム
１０２は、第３図の、現在スキャン番号７日、現在処理
番号８０．および、目標フィールド８２を用いる。現在
スキャン番号７日は処理制御ルーチン３９８によって初
期化され、維持されるが、これについては第１８図を参
照して後述する。現在スキャン番号７８は、詳細につい
ては後述するウィンドー・ビュー（ｗｉｎｄｏｗνｆｅ
ｗ）を決定するために用いられ、スキャン番号によって
決定されたものが選択された場合、最も最近アクセスさ
れたウィンドー・ビューがダウンロードされるように最
適化される。現在処理番号８０は、ある処理プログラム
が他の処理プログラムのポンイタを操作しないようにす
ることを確実化するために用いられる。目標フィールド
８２は目標フォーマットがソースディスクかディストネ
ーションディスクかを特定するために用いられ、そして
、第３図に示したフィールド内の適切なフィールド（ソ
ースまたはディストネーション）がソースディスクおよ
びディストネーションディスクに対する共通動作を遂行
する本発明のルーチンによって選択されることを確実化
するために用いられる。たとえば、後述することから明
らかになるように、ブロックＩ１０転送の間に実行され
るファイルロケーション処理プログラム２７８（第２１
図）が。

アクセスされるフィールド６６〜７６内のどのサブフィ
ールドを特定するのかに使用される目標フィールド８２
を用いてリード処理プログラムおよびライト処理プログ
ラムの両者として実行されるユーザーインターフェース
処理プログラム１００およびバッファ制御処理プログラ
ム１０２によって一旦初期化処理が実行され、そして、
もしソースディスク１０６が元々のディスク（すなわち
、異種のオペレーティングシステムが搭載されていない
もの）として参照されるべき場合、ソースファイル・ル
ックアップ処理プログラム１０４はフィールド７４内の
ファイル仕様を用いてソースディスク１０６からファイ
ルのファイル名称およびディレクトリを入手し、ファイ
ル記述２次元リスト１０８内のノードを生成する。第４
図において、実線はデータの流れを示し、破線はポイン
タの移動制御を示している。

ソースディスク１０６が元々のソースディスクであるか
ら、ソースファイル・ルックアップ処理プログラム１０
４はＣ言語に基づくシステムコールをホストコンピュー
タ３０のホストオペレーティングシステム４４に行うこ
とによってファイル名称を入手する。ソースファイル・
ルックアップ処理プログラム１０４はルートディレクト
リによって始まり５ユーザー３８によって指定されたフ
ァイルのファイル名称を探す従来の方法によってディレ
クトリ構造トリー（ｔｒｅｅ）を探す。このソースファ
イル・ルックアップ処理プログラム１０４において用い
られる。ファイルオーブン、ファイＪｌ／　ＩＪ−ド、
ファイルライト、ファイルクローズなどのいくつかのシ
ステムコールについて、Ｃ言語リイブラリイは標準のイ
ンターフェースを提供し、他のシステムコールに関して
、適切なコールがオペレーティングシステム参考資料に
よって決定され、同様のシステムコールが各オペレーテ
ィングシステムにおいて利用可能である。当業者はどの
システムコールがオペレーティングシステム参考資料か
ら必要であるか容易に同定できる。

第５図は本発明の例示的な階層ディレクトリ構造を示す
図である。

第６図は第５図に示したファイル記述２次元リスト１０
８内の構造を図解する図である。

第７図は第５図に示したファイル記述２次元リスト１０
Ｂ内の構造に関するディレクトリ作成順序を図解する図
である。

第８図は各リストノード１５８の内容を図解する図であ
る。

第９Ａ図〜第９Ｄ図および第１０Ａ図〜第１０Ｂ図は各
リストノード１５８内のフィールドの内容を示す図であ
る。

第５図に示した階層化ディレクトリトリー構造に遭遇し
、全部のディスク複写が特定された場合、本発明は、ソ
ースディスクの階層化ディレクトリ構造を維持するため
に設計された第６図に図解したようなポインタ、および
、たとえば、ＶＭＳディスクがディストネーシッンディ
スク１２２であるとき、ディレクトリ作成順序を維持す
るために用いられる第７図のポインタを有するファイル
記述２次元リス）１０Ｂを生成させる。ＶＭＳ内のディ
レクトリの作成順序は、ディレクトリ内のアルファベッ
ト順であり、たとえば２本発明が検索され挿入される新
しいディレクトリを進めるとき新しいアルファベットの
リストがファイル記述２次元リスト１０８に加えられる
。当業者は、ユーザーの仕様に対応するファイルエント
リまたはディレクトリエントリに遭遇する各々の時間に
適切なポインタとともにファイル記述２次元リスト１０
８の適切な位置にノードを挿入するため、Ｃ言語以外の
他の希望する目標プログラム言語によるルーチンを作る
ことができる。ファイル記述２次元リスト１０Ｂの各ノ
ードは（ただし、ノードはファイル名称によって示され
ている）、協働する複数の異なるポインタを有している
。これらのポインタは、第８図に図解されているように
、各ファイル記述リストノード１５８に記憶される。

第６図に示した階層化ディレクトリ構造は、ファイル記
述リストノード１５８のフィールド１８６および１８８
にそれぞれ記憶されたディレクトリ（ＤＩＲ）構造前進
ポインタ１３０およびＤＩＲ構造後退ポインタ１３２に
よって維持される。第６図の階層化ディレクトリ構造は
また。フィールド１８２に記憶されているファイルポイ
ンタ１３４、フィールド１８０内に記憶された各ノード
１５８用の親ポインタ１３６．および、フィールド１８
４に記憶されているサブディレクトリ・ポインタ１３８
によって維持されている。第７図に図解したように、デ
ィレクトリ作成順序を維持するために、第８図に図解し
たように、前進作成ポインタ１４０および後退作成ポイ
ンタ１４２が対応するフィールド１９０および１９２に
それぞれ記憶される。バッファ制御処理ルーチン１０２
にのみ有効なこれらのフィールド１８０〜１９２が第３
７図〜第４２図に関連づけてより詳細に述べられる。第
８図はまた９本発明がファイル記述２次元リスト１０８
内の任意の他の希望する順序の確立を可能にするために
多くのポインタを加えることによって容易に拡張できる
ことを示す２つの未使用のポインタフィールド１９３を
示している。

ファイル記述２次元リスト１０８は、このリスト１０Ｂ
が複数のリストのリストであるから２次元構成として考
慮されている。この２次元のリストについては、１次元
として複数のディレクトリのリストと、そして、各ディ
レクトリについて第２次元である複数のファイルのリス
トとが存在している。ファイル記述２次元リスト１０８
はまた２次元であるべきものとして考慮されている。そ
の理由は、第６図に図解した１次元としての階層化ディ
レクトリ作成順序が、第７図に図解したように、他方の
次元としてのディレクトリ作成順序とともに同時に維持
されるからである。

第８図おいて、各ファイル記述リストノード１５日はノ
ードの形式、すなわち、ノードがディレクトリノードで
あるかファイルノードであるかを記憶する。ノード形式
フィールド１６０を有している。ファイル記述２次元リ
スト１０８はまた親データポインタフィールド１６２を
有している。

この親データポインタは親ディレクトリデータに対する
ポインタであり、この親ディレクトリデータはそのディ
レクトリにおいてエントリがＤＯＳディレクトリ用のフ
ィールド（親ディレクトリエミンタ）に入っていること
によって配置されているか、エントリがＶＭＳヘッダ内
のバンクリンク（親ファイル同定）フィールドを入れて
いるかを決定するために用いられる。ディレクトリエン
トリ情報フィールド１６４がフィールド１６２に続けら
れている。ディレクトリエントリ情報フィールド１６４
はデータ構造であり、このデータ構造は第９Ａ図に図解
したように１本発明が用いられる。第９Ｂ図〜第９Ｄ図
に示す各オペレーティングシステム用のエントリ１９４
〜１９６を有している。ＶＭＳエントリ１９４は、第９
Ｂ図に図解したように、ヘッダ番号フィールド１９７．
ファイル同定フィールド１９８およびバージョン（改定
）番号フィールド１９９を有している。ＤＯＳエントリ
１９５は、第９Ｃ図に図解したように。

属性フィールド２００”およびファイルに対する割り当
てられる最初のクラスタを示すために用いるフィールド
２０１を有している。第９Ｄ図は。

加えられるべきであり、特定のシステムファイルフォー
マットである他のシステム用のエントリＩ９６の内容を
示している。

第１０Ａ図〜第１０Ｂ図は各リストノード１５８内のフ
ィールドの内容を示す図であって、第１０Ａ図はディス
クロケーション・フィールド１７６を示す図、第１０Ｂ
図はブロックロケーション・レコード２０４を示す図で
ある。

第１０Ａ図および第１０Ｂ図に示したように。

ディスクロケーション・フィールド１７６は２つのサブ
フィールドを有している。これらのサブフィールドは、
Ｉ１０処理に用いられる。第１０Ｂ図に図解したブロッ
クロケーション・レコード２０４の位置に位置づけるブ
ロックロケーション・レコードポインタ２０２．および
、ブロックＩ１０処理よりもファイルＩ１０処理が起動
されるときに用いられるＣ言語内の標準入出力コマンド
用の標準Ｃファイル・ディスクリブタ（ｄｅｓｃｒｉｐ
ｔｏｒ）を有するフィールド２０３を有している。ブロ
ック・ロケーシタンレコード２０４の内容は、リストエ
ントリ（ブロックまたはファイル）に必要な人出力の形
式に依存し１本質的にディスク上のエントリのアドレス
を提供する。複数のデータファイルが一般的にディスク
上に隣接したイクステン）　（ｅｘｔｅｎｔ：広がり）
関係で記憶されるので。

１つのブロックロケーション・レコード２０４が各イク
ステントに必要である。各イクステントが、ブロック内
のイクステントの長さ（大きさ）２０５、ブロック内の
イクステントの開始番号２０６、開始ブロック内のファ
イル用の開始オフセソ）２０７．および５次のブロック
ロケーション・レコードに対するポインタ２０８によっ
て定義される。エントリ名称は第８図のフィールド１６
６に包含され、たとえば、第５図〜第７図に示したルー
トの後の最初のディレクトリに関するエントリ名称は「
アカウント（ａｃｃｏｕｎ　ｔ）　Ｊである◆第８図の
フィールド１６８はエントリを見つけだすために必要な
バスストリング（ｐａｔｈ　ｓｔｒｉｎｇ）を有してお
り、たとえば、第５図〜第７図示した”１ｅｔｔｅｒｌ
”ファイル用のバスストリングは″“ｕｓｅｒｌ、Ａ″
である。フィールド１．７０はファイルの実際の長さを
記憶しており、フィールド１７２はファイルの割り当て
られた長さを記憶している。この記述において明示して
はいないが、ファイルおよびディレクトリは複数のファ
イルを考慮している。フィールド１７４はそのようなオ
ペレーティングシステムを動作可能にする現在の日付を
記憶しており、現在の日付の内容はホストシステムに依
存し、そのようなオペレーティングシステムはこの情報
を更新するためのファイルに対するアクセス状態または
修正状態を記録している。全ての処理プログラムによっ
てアクセス可能な最後のフィールド１７８は共通の属性
フィールドであり、この共通の属性フィールドは本発明
が他のユーザーのために拡張されることが可能になる予
め割り当てられた未定義のフィールドである。

明らかなように、ファイル記述２次元リスト１０８の各
ファイル記述リストノード１５８はソースディスクにエ
ントリを配設し、適切なソースディレクトリ階層化構造
およびディストネーション・ディレクトリ作成順序にエ
ントリを維持するために必要な情報を包含している。

第４図に戻ると、ソースファイル・ルックアップ処理プ
ログラム１０４はソースディスク１０６にアクセスして
ファイル記述リストノード１５８を生成するのに必要な
、少なくともディレクトリエントリの名称である情報を
人手し、バッファ制御処理プログラム１０２をコールし
てファイル記述２次元リス）１０８内の有効なファイル
記述リストノード１５８に対するポインタを人手する。

ただし、新しいエントリに対する情報が記憶されうる。

それから、ソースファイル・ルックアップ処理プログラ
ム１０４は適切な情報とともにファイル記述リストノー
ド１５８をロードする。もしエントリが記憶されなけれ
ばならない場合、万一ポインタが１回以上ファイル記述
２次元リスト１０８を横切らなければならないとき、適
切なポインタが発見されるまで、ソースファイル・ルッ
クアップ処理プログラム１０４はファイル記述２次元リ
スト１０８内の新しいポインタを問い合わせることによ
って適切な挿入ポインタを探す。

第１１図はファイル記述リスト１０８の各ノード１５８
に対する各ポインタのためのポインタ定義を図解する図
である。リストポインタは第１１図に図解の如く定義さ
れており、ノードアドレス２１１、ファイル記述２次元
リスト１０日を介する移動順序２１２．ノード形式２１
３．ポインタが全ノードにわたって進められ完了しまた
は終了したことを示す完了フラグ２１４．ポインタ移動
が発生する他の現象について待機していることを示す待
機状態フラグ２１５．オーナー処理番号２１６、および
、ポインタ割当番号２１７を有している。バッファ制御
処理プログラム１０２はまた親データポインタを初期化
し、ノードの形式をセットし、そのノード内のエントリ
名称およびバス名称を記憶する。すなわち、バッファ制
御処理プログラム１０２はポインタを休止のまま空きに
なって（ｒｅｓｔ　１ｅｆｔ　ｅｎ＋ｐｔｙ）完了して
いるフィールド１６０．１６２，１６６および１６８を
有するノードに戻す。

一旦ソースファイル・ルックアップ処理プログラム１０
４がファイル記述リストノード１５８を生成し、そして
、過去のそのファイル記述リストノード１５８を進め、
または、そのノードで待機状態にある時、ソースファイ
ルリード処理プログラム１１０はそのポインタをファイ
ル記述リストノード１５８まで進め、そのファイル内容
をソースデータリング１１２にロードする。ソースファ
イルリード処理ポインタはファイル記述２次元リスト１
０８内のディレクトリエントリの全体にわたって進めら
れる。

ソースデータリング１１２および本発明に関連づけて記
述される他の全てのリングの定義が第１２図に図解され
ている。

ファイル記述リストノード１５８のパスストリングフィ
ールド１６８に基づくソースファイルリード処理１１０
はファイルの内容を入手し、メモリセグメント２２０〜
２２４の可変番号内のデータを記憶する。ここで、ある
一つのリングを要求している処理は使用されべきメモリ
セグメントバッファの番号を定義する。各セグメントは
そのセグメントが使用されるべきかを表示する状態フィ
ールド２２５を有する。リング定義はバッファセグメン
トポインタ２２６および最後のインデックスフィールド
を有しており、このインデックスフィールド２２８は、
最後のインデックスに対してポインタが進めなければな
らず、そのリング内の先行するポインタがファイルの最
後のイクステントに挿入されていることを示す、最後の
インデックスを示している。フィールド２３０はこのリ
ングのために使用状態にあるポインタの番号を示してお
り、たとえば、リード、ライト、ディレクトリ、ディレ
クトリヘッダなどは使用可能なポインタのいくつかのも
のである。フィールド２３２はこのリングのための最も
高い優先順位のポインタを示している。ソースデータリ
ング１１２について、最も優先順位の高いポインタはブ
ロックリードまたはファイルリードである。フィールド
２３４はバッファセグメントの数を示しており、バッフ
ァセグメントはこのリングのために割り当てられており
、一方、フィールド２３６はセグメントの長さを示して
いる。フィールド２３８はリング内のイクステントの数
を規定しており、好適にはイクステント数は１０であり
、最小の数はそのリング用のポインタの数より大きい１
以上であり。

イクステント数が大きいほど効率は向上する。フィール
ド２４０は第１のイクステントを指定するリングポイン
タである。各イクステント２４２はセグメント内におい
てこのイクステントについての実際のデータが配置され
ること定義するために用いられる。したがって、イクス
テントは、セグメント数フィールド２４４．イクステン
トデータポインタ・フィールド２４６．イクステント内
のバイト数フィールド２４８．ファイル内のイクステン
トの位置フィールド２５０を有している。

イクステントはまたファイル記述２次元リスト１０８内
の対応するノードに対するポインタ２５２を有している
。すなわち、フィールド２５２はノードによって示され
たリング内に記憶されたフィールドの内容についてのフ
ァイル記述２次元リスト１０８内の対応するノードを示
す。ソースファイル・ルックアップ処理プログラム１０
４から明らかなように、ソースファイルリード処理プロ
グラム１１０はリングポインタを必要とし、それはその
ポインタビ、こついてのバッファ制御処理プログラム１
０２をコールする。リングを定義する最初のコールはま
た。そのリングについて最高の優先順位を有するポイン
タを生成し、そのリングを定義する処理に関するポイン
タは定義されたリングについて最高位の優先順位を受け
る。最高位の優先順位を得るために定義される処理を可
能にすることによって、２つの処理が同じ２つのリング
で動作し、しかも逆の１頓序で動作するので１巡回的な
優先順位の問題が生ずるおそれがある。たとえば、ブロ
ックライト処理プログラムはリング２９４を充満させる
が、ディレクトリ作成処理プログラムはディレクトリを
引き出し探索する処理に続いて行われ、同時にディレク
トリ作成処理プログラムがディストネーションＤ　Ｉ　
Ｒ−ＯＵＴリング２９６を充満させ、ブロックライト処
理プログラムがディレクトリの内容を書き込む処理に続
けられる。したがって、各リングはポインタの移動を制
御するためにバッファ制御処理プログラム１０２によっ
て用いられるリング定義２５５を有するリング定義２５
５は、第１３図に示すように。

ポインタの優先順位２５６．ポインタのリング番号２５
８．オーナー処理番号２６０．現在のイクステントのイ
ンデックス２６２．および、待機状態フラグ２６４を有
している。

一旦ソースファイルリード処理プログラム１１０が１ま
たは複数のリングセグメントを充満させると、もし起動
された場合、翻訳処理プログラム１１４はテキストファ
イル・レコードをディストネーションディスクに敵した
フォーマットに翻訳し、その翻Δ尺したものをディスト
ネーション・データリング１１６に記憶する。もし翻訳
処理プログラム１１４が起動されない場合は、ディスト
ネーション・データリング１１６の内容とソースデータ
リング１１２の内容とは同じである。

第４図のディストネーション・ディレクトリ生戒処理プ
ログラム１１８はディストネーションディスク（２２の
ためのディレクトリを生成する。

前述したように、システムコールがファイル記述２次元
リスト１０８上の各エントリについてのこの機能を遂行
する。ディストネーション・ディレクトリ作成処理プロ
グラム１１８は、ディレクトリエントリがファイル記述
２次元リスト１０８内で完了しているとき、　（ファイ
ルを飛び越し、ディレクトリエントリに対する指定のみ
行う）そのポインタを進めることができる。ディストネ
ーション・ディレクトリ作成処理プログラム１１８はま
ず、ファイル記述２次元リスト１０Ｂ内のエントリがデ
ィストネーションディスク１２２に存在することを見る
ためにチエツクする。この処理は上述したようなシステ
ムファイルコールによって行われる。もしエントリがデ
ィストネーションディスク１２２に存在しない時には他
のシステムファイルコールが行われてディストネーショ
ンディスク１２２にエントリを生成する。もしエントリ
が存在しない場合には、ノーオペレーション（ｎ。

ｏｐｅｒａｔｉｏｎ）が要求される。−旦ディストネー
ションディスク１２２上のエントリが生成されると、デ
ィストネーションファイル・ライト処理プログラム１２
０はディストネーション・ディレクトリ生成処理プログ
ラム１１８によって生成されたディレクトリエントリに
ついてのファイルに対するファイル記述２次元リスト１
０８内のそのポインタを進めることができ、そのファイ
ルをディストネーションディスク１２２に記憶する。デ
ィストネーションファイル・ライト処理プログラム１２
０は、Ｒ初のイクステントに遭遇するとディストネーシ
ョンディスク１２２上のファイルをオーブンにし、最初
から最後までのイクステント内のデータを人手し、ディ
ストネーションディスク１２２にデータを記憶し、それ
から１最後のイクステントに遭遇したらそのファイルを
クローズする第１４図はブロフクＩ１０転送に対するブ
ロックＩ１０を図解する図である。すなわち、第１４図
はデータの流れとブロックｌ１０−ブロック■／○転送
を行うために協働する処理を図解している。実行の初期
段階において、ソースブロックリード処理プログラム２
７４は、ルートディレクトリを人手しそれをソースディ
レクトリ・リング２７５にロードする。ルートディレク
トリ・ロジカル・ブロックロケーションが、ＶＭＳ上の
ヘッダナンバーフォー　（ｈｅａｄｅｒ　ｎｕｍｂｅｒ
　ｆｏｕｒ）内（ただし　ヘッダフォーのロケーション
はホームブロックから決定される）、および、ＤＯ３上
のＢＩＯＳパラメータブロック内に見出される。ＶＭＳ
に関しては、ヘッダの開始がホームブロックから得られ
る。ルートディレクトリ・ヘッダは常にナンバーフォー
である（４番である）。このヘッダは読み出され、ルー
トディレクトリのブロックロケーションを包含している
。ソースブロックリード処理プログラム２７４はまた。

ソースロケーションウィンドー２７６にルートディレク
トリ・ヘッダをロードする。

ソースロケーション・ウインドー、２７６　ハ仮想メモ
リシステムにおけるページングシステムと非常に類似し
た作用を有しており、隣接してデータを記憶するに充分
なメモリが存在しない場合概念的に隣接したインデック
スデータについてのアクセス方法を提供する。ベージン
グシステムについての当業者はそのようなウィンドーが
いかにして生成できるかについて容易に認識できる。ソ
ースロケーション・ウインドー、２７６内において、ソ
ースディスク２７０のヘッダまたはインデックスについ
ての区分の本質的なスナップショトである５つの可能な
ウィンドー・ビューが示されている５つのウィンドー・
ビューは同時的に発生するであろう複数のウィンドーに
関連づけて動作が図解されるように示されており、複数
のウィンドー・ビューを異なる番号にすることも可能で
ある。

ソースロケーション・ウインドー、２７６の定義が第１
５図に示されている。この図面は２つのウィンドー・ビ
ューのみ示しているが、さらに多くのウィンドー・ビュ
ーを示すことも可能である。

ウィンド一定義３３０は、インデックスサイズ３３２、
インデックス形式３３４．バイト表現のビューレングス
３３６．ウィンドー状態３３８．ライトイネーブル３４
０．オーナー処理番号３４２ウインドーによって提供さ
れるウィンドー数３４４、および、ウィンドー・ビュー
に対するポインタ３４６を有している。各ウィンドー・
ビューはインデックススタート３４８．および、インデ
ックスエンド３５０を有している。ウィンドー・ビュー
はまた。このウィンドー・ビューが最後のリファレンス
３５２であったとき、ビューが修飾されており（３５６
）、修飾カウンタ３５６であるかを示している。ウィン
ドー・ビューはまた。

ウィンドー・ビューの状態を示しており、修飾している
ウィンドー・ビュー内のブロフクのビットマツプ３６２
を提供している。これらの修飾フィ−ルドは、もしウィ
ンドーがライトイネーブルの場合（ただし、そのウィン
ドーはインデックスウィンドー　ビットマツプウィンド
ーまたはヘッダビットマツプである）、修飾されるだけ
である。

ビュ一定義はまたメモリ内の実際のデータに対するポイ
ンタ３６４を有している。ソースロケーション・ウイン
ドー、２７６に関して、ビューはソースディスク２７０
上のインデックスファイルのビューであり、このインデ
ックスファイルはフィールドを配置するためのロケーシ
ョン情報を有している（ＶＭＳ内においては、この位置
情報はヘッダのファイルであり、ＵＮＩＸにおいてはｌ
ノードであり、ＤＯ３においてはファイルアロケーショ
ンテーブルである）。動作中、ある処理プログラム、た
とえば、ソースロケーション処理プログラム２７８がヘ
ッダについて尋ねているとき、　（すなわち、インデッ
クスがＶＭＳヘッダまたはファイルアロケーション・テ
ーブルワードを示しているとき）、バッファ制御処理プ
ログラム１０２は、ヘッダがスタートまたはエンドフィ
ールドを検査することにより見出されることを見るため
。

複数のビューを見る。もしビューがその中のインデック
スとともに発見される場合、バッファ制御処理プログラ
ム１０２は、インデックスサイズ３３２およびインデッ
クススタート３４８と希望するインデックスまたはヘッ
ダ番号との差からバッファ３６６内のインデックスのオ
フセット位置を計算することによって得られるインデッ
クスに対するポインタに戻す、もしヘッダがビュー内に
存在しない場合、バッファ制御処理プログラム１０２は
待機状態に戻る。ブロックリード処理プログラムは後に
、ヘッダから失われているインデックスで始まるヘッダ
のビューまたはディスク上のインデックスファイルのビ
ューを入手し、各ヒユーのフィールド３５２および３５
４を検査することにより一番最近使用したライトイネー
ブルのビューにロードする。

（以下余白） 上述したように１第１４図に図示したソースブロックリ
ード処理プログラム２７４は、ルートディスクを入手し
、ソースディレクトリ・リング２７５内にそのルートデ
ィスクをロードする。これが、フィールド内のリードロ
ケーションを入手するブートストラップ形式の動作の始
まりである。

ルートディレクトリが一旦ソースディレクトリ・リング
２７５にあると、ソースディレクトリ・サーチ処理プロ
グラム２８０はルートディレクトリの内容を解釈し、適
切な挿入ポイントのためのファイル記述２次元リスト１
０８を探索することを含むソースファイル・ルックアッ
プ処理プログラム１０４と同様な方法でファイル記述２
次元リスト１０日内に適切なエントリを生成する。−旦
。

ルートディレクトリエントリがファイル記述２次元リス
ト１０日に生成されると、ソースブロックリード処理プ
ログラム２７４は、ソースロケーション・ウインドー、
２７６の前方を見て、ソースロケーション処理プログラ
ム２７８用のバッファ制御処理プログラム１０２がソー
スディスク２７０上のルートディレクトリにファイルを
ロードすることを可能にするインデックスファイルの適
切な場所を有するソースロケーション・ウインドー、２
７６をロードする。−旦、初期ウィンドー・ビューがロ
ードされると、ソースブロックリード処理プログラム２
７４は、ファイル記述２次元リスト１０Ｂの前方を見て
、ソースロケーション処理プログラム２７８が次に必要
とするインデックスファイルの位置を決定する。前方監
視（ｐｅｅｋ　ａｈｅａｄ：ピークアヘッド）動作につ
いは第２４図を参照して詳細に述べる。それから、ソー
スブロックリード処理プログラム２７４は、必要となる
インデックス情報を有する空きのウィンドー・ビューを
ロードする。ソースロケ−シランリード処理プログラム
２７８は、ファイル記述２次元リスト１０８の各ノード
内のブロックロケーション・レコードポインタ２０２（
第１０Ａ図）を完全にする。

このポインタは単一的にリンクされている一連のレコー
ドを指定しており、これらのレコードはファイルの各デ
ィスクのイクステントのための情報を包含しており、こ
のことがエントリに対応しているファイルのロケーショ
ンに関してファイル記述２次元リスト１０８を完全にす
る。このことはソースブロックリード処理プログラム２
７４がファイル記述２次元リス）１０８を移動させ。

ディレクトリファイルを入手しソースディレクトリ・リ
ング２７５にロードし、データファイルを入手してソー
スデータ・リング１１２にロードすることを始めること
を可能にする。ファイル記述２次元リスト１０８内のデ
ィレクトリ・ノードエントリおよびファイル・ノードエ
ントリを生成する処理プログラムは、ルートディレクト
リ内のサブディレクトリエントリの内容をソースディレ
クトリ・リング２７５にロードするソースリード処理プ
ログラム２７４．エントリ用のロケーション情報を人手
し完全にするソースロケーション処理プログラム２７８
とともにソースディレクトリ・リング２７５をスキャン
しファイル記述２次元リスト１０８にノードエントリを
生成するサーチ処理プログラム、および、リング１１２
および２７５に情報を読み込むソースブロックリード処
理プログラム２７４が続けられる。

ファイル記述２次元リス）１０８が充満され。

入力処理と協働するポインタがデータファイルおよびデ
ィレクトリファイルがソースデータリング１１２および
２７５に記憶されていることを示しているファイル記述
２次元リスト１０８のエントリを介して移動するから、
転送システム３６は翻訳処理プログラム１１４および出
力処理がファイル記述２次元リスト１０８を横断するこ
とを開始し、ディストネーションディスク３０４にディ
レクトリファイルおよびデータファイルをロードするこ
とを可能にする。上述したように、もし翻訳処理プログ
ラム１１４が起動されているとき、ソースデータ・リン
グ１１２からのテキストデータが再フォ−マツト化され
、ディストネーションデータ・リング１１６に記憶され
る。

ディストネーションブロック・ライト処理プログラム３
００は２つの機能を持っている。第１の機能は、データ
ファイル、ディレクトリファイルおよびヘッダをディス
トネーションディスク３０４に記憶する。第２の機能は
、ディストネーションディスク３０４のためのアロケー
ション制御リストおよびヘッダ制御リストにしたがって
、ディストネーションディスク３０４にすでに存在する
任意のディレクトリおよびヘッダ（インデックス）を読
み出す。このことは、ファイル記述２次元リスト１０８
内のファイルおよびディレクトリをディストネーション
ディスク３０４にあるファイルおよびディレクトリと合
併（＋ｔ＋ｅｒｇｅ）することを可能にする。ディスト
ネーション・ディレクトリ・ビルト処理プログラム２８
２は、ファイル記述２次元リスト１０８と、ディストネ
ーションディスク３０４にディレクトリを記憶している
ディストネーションＤＩＲ（ディレクトリ）−ＩＮリン
グ２９４の内容とを比較し９合併したディレクトリエン
トリ、または新しいディレクトリエントリを生威し、こ
の合併した。または新しいディレクトリエントリをディ
ストネーションＤＩＲ，−０ＵＴリング２９６に記憶す
る。メモリ内に存在しないヘッダが必要なとき、ディス
トネーション・ロケーション処理プログラム２８４は待
機状態に入り、ディストネーションブロック・ライト処
理プログラム３０７はディストネーションディスク３０
４からヘッダを入手し、ディストネーション・ロケーシ
ョン処理プログラム２８４はディストネーションディス
ク３０４上のファイルの物理的なロケーションを決定す
る。もしディレクトリエントリがディストネーションデ
ィスク３０４に存在しないとき、ディストネーション・
ディレクトリ作成処理プログラム２８２はディレクトリ
を生威し、存在する場合は存在するディレクトリに加え
る。ヘッダ作成処理プログラム２８６は、ディレクトリ
ファイルおよびデータファイルのためのヘッダまたはイ
ンデックスを生威し、それらをディストネーション・ロ
ケーション・ウィンドー２９０に記憶する。ディストネ
ーションブロック・ライト処理プログラム３００は、デ
ィストネーションＤ　Ｉ　Ｒ−ＯＵＴリング２９６およ
びディストネーション・データリング１１６の内容をデ
ィストネーションディスク３０４に記憶する。または書
き込む。より高い優先順位であるディストネーションブ
ロック・ライト処理プログラム３００は。

ファイルに対してクラスタ（ブロックの郡）を割り当て
るために、ファイルシステム特定ルーチンをコールして
ディストネーションＤＩＲ−ＯＵＴリング２９６および
ディストネーション・データリング１１６のファイルの
ためのスペースを割り当てる。ディストネーション・デ
ィレクトリ作成処理プログラム２８２はヘッダを割り当
てて、ヘッダ番号がディレクトリエントリのために必要
な場合ヘッダ制御リスト・ウインドー２９２を更新させ
る。もし必要なときにはへラダ作成処理プログラム２８
６が続けられ、ヘッダ内にアロケーション情報を記憶す
る。ロケーションおよびアロケージクン情報がファイル
アロケーションテーブルに組み合わされているので、ヘ
ッダ作成処理プログラム２８６はＤＯＳディストネーシ
ョンディスクのためには必要とされない。ディストネー
ションブロック・ライト処理プログラム３００は適切な
段階（ステップ）においてディストネーションディスク
３０４にディストネーション・ロケーション・ウィンド
ー２９０．ヘッダ制御リスト（ＨＣＬ）ウィンドー２９
２およびアロケージジン制ｉ創Ｊスト（ＡＣＬ）ウィン
ドー２９８のビューを書き込む。

第１６図および第１７図はデータの流れとファイルＩ１
０およびブロックＩ１０転送の組合せについての処理実
行を示す図であり、前述したようにこれらの処理は適切
に起動され、実行される。

本発明のこれらの処理の実行順序が第１８図に図解した
処理制御処理または処理制御ルーチン３９８によって制
御される。第１８図は処理実行順序を制御する処理制御
ルーチン３９８のフローチャートである。この処理制御
ルーチン３９８は基本的には、待機状態または完了状態
に到達するまである処理プログラムが動作することが可
能である処理プログラムを起動またはコールするループ
であり、それらの処理プログラムを次の処理プログラム
に移動させる。処理のリストの終わりに到達すると、処
理制御ルーチン３９８は処理の始めで再び起動され、全
ての処理プログラムが行われるまでスキャンを継続する
。処理制御ルーチン３９８の最初のステップは処理プロ
グラムのアドレスをロードするステップ４００である。

処理プログラムのアドレスが処理順序および各処理プロ
グラムのある要素に従ってアレーまたは処理制御リスト
に記憶されている。アレーはまた各処理プログラム用の
状態インジケータを包含している。これらの状態は、レ
ディ（準ＤＩ）状態２データのための待機状態、Ｉｌｏ
のための待機状態、ルームのための待機状態がある。ア
レーはまた。データリングの空き（ｅｍｐｔｙ）または
満杯（ｆｕｌｌ）などの事象を待機していることを生成
することに基づいて停止された処理プログラムのある位
置において待機している処理を開始させることを可能に
するステップ番号を有している。これはサブルーチンの
ための可変エントリポイントのように作用（機能）して
いる。処理プログラムが実行される順序は第４図、第１
４図、第１６図および第１７図に示されており、たとえ
ば、ソースデイレクトリサーチ処理プログラム２８０は
処理番号３であり、この処理番号は、処理番号がゼロか
ら始まるので処理番号アレー内の４番目にあるこの処理
は２実行順序が４であることを示している。この処理番
号はまた処理プログラムのためのポインタの優先番号で
あり、高い番号は優先順位が高いことを示しており、ラ
イト処理プログラムが高い優先順位を持っているという
処理番号からも明らかである。

ステップ４０２において、転送システム３６はソースお
よびディストネーションディスクのファイル形式を決定
するために必要なそれらの処理ををレディ状態にセット
する。この初期段階においてレディ状態にセットする処
理プログラムは、バッファ制御処理プログラム１０２．
ソースブロンクリート処理プログラム２７４．ディスト
ネーションブロック・ライト処理プログラム３００およ
びユーザーインターフェース処理プログラム１００であ
る。ユーザーがファイルフォーマットを問い合わせられ
る簡単なバージョンが採用されるとこのとは単にユーザ
ーインターフェース処理プログラム１００をレディ状態
にセットすることである。これらの処理プログラムが単
なるレディ状態にセットする処理プログラムであるから
、処理制御ルーチン３９８のループを介した最初のバス
を通じて、単にこれらの処理プログラムが実行されるだ
けである。後者のプログラムが処理している間、ディス
ク形式に基づく適切な処理プログラムが起動される。も
しソースディスクが元々のディスクであると決定されホ
ストのファイルシステムを通してアクセスされると、ソ
ースファイルリード処理プログラム１１０およびソース
ファイル・ルックアップ処理プログラム１０４がレディ
状態にセットされ、ディストネーションディスクが異種
のフォーマットディスクの場合ディストネーション・デ
ィレクトリ作成処理プログラム２８２、ディストネーシ
ョン・ロケーション処理プログラム２８４．ヘッダ作成
処理プログラム２８６およびディストネーションブロッ
ク・ライト処理プログラム３００が起動される。

ステップ４０４において、現在の処理プログラムが最初
の処理プログラムにセットされ、ループを介した第１の
バスにおいてはこの処理プログラムはユーザーインター
フェース処理プログラムｌＯＯであろう。次いで、決定
ステップ４０６が行われ、現在の処理プログラムが実行
された（ｄｏｎｅ）状態にあるか否かについての決定が
行われ、もし実行されていない場合、現在の処理プログ
ラムの状態が決定される（ステップ４ＩＯ）。上述した
ように、この処理は処理制御アレーをアクセスすること
により決定される。もし現在の処理プログラムがレディ
状態の場合（ステップ４１２）。

ホストコンピュータ３０のＣＰＵが現在の処理プログラ
ムに対して割りつけられる（ステップ４１４）。もしレ
ディ状態でない場合、処理番号が進められ（ステップ４
１６）、現在の処理番号が最後の処理番号よりも大きい
かどうかについての決定のためのテストが行われる（ス
テップ４１８）。もし大きくない場合、ループ処理は連
続する処理プログラムを起動するための処理を行う。も
し現在の処理番号が最後の処理番号より大きい場合（現
在の状況においては最も優先順位の高い番号が付けられ
ているものは処理１３である）、ソースディスクの形式
が決定されているかどうかについての決定が行われる（
ステップ４２０）。−旦ソースディスク形式が決定され
ると、ソースディスクを読み出すために必要な処理プロ
グラムが起動される（ステップ４２２）。次いで、ディ
ストネーションディスクの形式が決定されているかどう
かについての決定が行われ（ステップ４２４）もし決定
されていれば、必要なディストネーション処理プログラ
ムが起動される（ステップ４２６）、もし全ての処理プ
ログラムが実行完了していない場合（ステップ４２Ｂ）
、現在の処理番号が最初の処理番号にセットされ（ステ
ップ４０４）、処理実行制御ループが反復継続される。

全ての処理プログラムが終了している場合、ソースディ
スクからディストネーションディスクへの完全な転送が
行われる。

第１９図はユーザーインターツース処理プログラム１０
０を示すフローチャートである。ユーザーコマンドを解
析することにより、第１９図に示したユーザーインター
フェース処理プログラム１００が起動される。この解析
処理は従来から知られている処理であり、アクセスされ
るソースおよびディストネーションディスク装置および
ファイルを同定する。−旦ユーザーコマンドが解析され
ると、ソースディスクが必要かどうかについてのテスト
が行われる（ステップ４４２）。たとえばもしソースデ
ィスク装置とディストネーションディスク装置とがＣ０
ＰＹコマンドについて異なる場合、たとえば、“Ａ：′
と′Ｅ；“とのように異なる場合、ソースディスクが必
要となる。もし、コマンドがＴＹＰＥまたはＤＩＲの場
合にはソースディスクがまた必要であり、コマンドがＤ
ＥＬＥＴＥまたはＭ　Ｋ　［）　Ｉ　Ｒ（ｍａｋｅ　ａ
　ｄｉｒｅｃｔｏｒｙなど）の場合にはディストネーシ
ョンディスクが必要となる。ソースディスクが必要な場
合、上述したように、ソースディスクの形式が決定され
る（ステップ４４４）。ディストネーションディスクが
必要な場合、ディストネーションディスクについても同
じステップが行われる。この点について、もし簡単なバ
ージョンが採用された場合、ユーザーはディストネーシ
ョンおよびソースディスク形式を特定するために問い合
わせられる。ソースブロックリード処理プログラム２７
４を実行することによってソースおよびディストネーシ
ョンディスクの形式の決定が行われ、ディストネーショ
ンブロック・ライト処理プログラム３００．処理制御ル
ーチン３９８．バッファ制御処理プログラム１０２．お
よび、ユーザーインターツース処理プログラムｌＯＯが
処理を行う。ユーザーインターツース処理プログラム１
００がステップ４４４に到達しソースディスクの形式を
決定することを試みるが、適切な情報がまだディスクか
ら読み出されでていないので、そうすることは出来ない
。したがって、ユーザーインターツース処理プログラム
１００は待機状態に入り、制御を、明らかにソースブロ
ックリード処理プログラム２７４に制御を移す第１８図
に示す処理制御ルーチン３９８に移す。ソースブロック
リード処理プログラム２７４はディスクの形式を決定す
るのに必要な情報を読みだし、処理制御ルーチン３９８
を介してユーザーインターツース処理プログラム１００
に制御を移し、再びユーザーインターツース処理プログ
ラム１００の処理が繰り返される。再び起動されると、
ユーザーインターツース処理プログラムｌＯＯはソース
ディスクの形式を決定する。処理の相互関係から明らか
なように、ソースおよびディストネーションディスクの
形式がレディ状態にセットされるか起動されるかに適切
な処理の前に、処理制御ルーチン３９８を介した複数の
ループ処理が行われる。充分な情報が提供されると。

ユーザーインターツース処理プログラム１００が、解析
されたコマンドおよびディスクの形式から第３図に示し
た動作記述データ構造６０を初期化する。

第２０図に図解したソースディレクトリ・サーチ処理プ
ログラム２８０が、ファイル記述２次元リスト１０８の
ための挿入ポインタを定義する処理を行うことによって
（ステップ４６０）開始される。ポインタ定義動作は、
ソースディレクトリ・サーチ処理プログラム２８０が挿
入に用いるリストポインタアレー内にポインタを指定す
る整数の値に戻すバッファ制御処理プログラム１０２へ
のコールを含んでいる。ファイル記述２次元リスト１０
８用のポインタはディレクトリ作成移動順序ポインタま
たはディレクトリ構造ポインタとは反対の可変移動ポイ
ンタである。そのポインタは、可変移動が許可され、他
のいかなるポインタによっても続けられず、ファイル記
述２次元リスト１０８を通して自由に移動する。その理
由は、エントリをファイル記述２次元リスト１０８にフ
ァイル記述２次元リスト１０８を全体を通した可変のロ
ケーションに挿入するきに必要だからである。次にソー
スディレクトリ・サーチ処理プログラム２８０はソース
ディレクトリ・リング２７５のポインタを定義する（ス
テップ４６２）。この処理はまた。リングポインタアレ
ー内の定義が用いられるべきであることを示す整数を入
手するためバッファ制御処理プログラム１０２をコール
することを含んでいる。ソースディレクトリ・サーチ処
理プログラム２８０はそれから次のディレクトリイクス
テントを得ることによって処理される（ステップ４６４
）。これは、バッファ制御処理プログラム１０２が次の
ディレクトリエントリを提供し２　もしルートディレク
トリが１つのイクステントより大きい場合このループを
通した第１のバスにおいてルートディレクトリのための
第１のイクステントでありうる。もしルートディレクト
リが利用出来ない場合（ステップ４６６）、　ソースデ
ィレクトリ・サーチ処理プログラム２８０は待機状態に
入り、ディレクトリイクステントが提供されるまで待機
する。この待機状態はステップ番号が更新される前に処
理制御ルーチン３９８に実際に戻される。待機状態の間
、処理制御ルーチン３９８は他の処理プログラムを起動
し、明らかにイクステントがレディ状態になる。もし処
理プログラムが全てのディレクトリエントリの終わりに
到達すると、終了したものとしてフラグがたてられる。

ディレクトリが利用可能な場合、バッファ制御処理プロ
グラム１０２は４イクステント、レングス、セグメント
番号およびイクステントのデータの始めに対するポイン
タを規定する情報に戻す。すなわち、バッファ制御処理
プログラム１０２は、実際のイクステントデータを指定
するイクステントレコードの定義に対するポインタに戻
す、次に、イクステントは、バッファ制御処理プログラ
ム１０２を用いたハンドシェーク処理を用いて新しいデ
ィレクトリに遭遇しているかどうかを決定するために検
査される（ステップ４７０）。

もし遭遇していれば、ソースディレクトリ・サーチ処理
プログラム２８０は、ディレクトリを挿入する処理プロ
グラムが完了していることを示す（ステップ４７２）。

このバッファ制御処理プログラム１０２を用いたハンド
シェーク処理は、なんらかの分類処理が今完了したので
以下のポインタがディレクトリのためのエントリに対し
て今進められることをバッファ制御処理プログラム１０
２に知らせる。そこで、ソースディスクの形式に基づく
ファイルシステム特定化ルーチンをコールする。ディレ
クトリエントリが人手される（ステップ４７４）。この
ルーチンは、ディレクトリバッファのアドレスおよびそ
のバッファに対するオフセットが与えられ１次のエント
リに対してオフセットを更新し、もしそれ以上のエント
リがバッファにおいて利用可能でない場合、待機状態に
戻りもし次のエントリがディレクトリの終わりを示して
いる場合終了に戻る。もしこれがそのイクステントにお
いて新しいエントリでない場合には次のエントリが得ら
れる（ステップ４６４）、もし新しいエントリがイクス
テントにあれば、エントリがその処理のために必要かど
うかについての決定が行われる（ステップ４７８）。エ
ントリがユーザー仕様に一致しエントリがファイルであ
るかユーザーが全体のディレクトリツリーの処理を要求
しておりエントリがサブディレクトリ用であるとき、エ
ントリが処理のために必要である。処理のためにエント
リが必要なとき１分類か要求されている場合には、エン
トリはアルファベントの順序でファイル記述２次元リス
ト１０８に挿入される（ステップ４８０）。このことは
、バッファ制御処理プログラム１０２のコールによって
遂行される。分類が要求されていないとき、バッファ制
御処理プログラム１０２は、最後の挿入のためにファイ
ル記述２次元リス）１０８にルームが存在しないことを
示す状態にインジケータを戻し。

ソースディレクトリ・サーチ処理プログラム２８０は利
用可能になるまでファイル記述２次元リスト１０８のス
ペースのために待機する（スペース、１８４　）。しか
しながら１分類が要求されているときには、ファイル記
述２次元リスト１０８の全体が同時にメモリに一致して
いなければならずそして、ルームが存在しないので、エ
ラー状態が存在し、ユーザーは小さい組みのファイルを
特定するために問い合わ゛せられなければならない。繰
り返すと５本発明において発生するたの全ての待機状態
において、これはユーザーインターツース処理プログラ
ム１００に対する転送を含み、ステップ番号が記憶され
た後他の処理が実行できるようにしている。−旦エント
リが挿入されると、制御は８記憶されたステップ番号を
用いて他の待機状態リターンが行われたように、ステッ
プ４７０に戻る。

ソースロケーション処理プログラム２７８およびディス
トネーション・ロケーション処理プログラム２８４の処
理内容が第２１図に図解されている。この処理プログラ
ム５　ソースロケーション処理プログラム２７８／デイ
ストネーシヨン・ロケーション処理プログラム２８４は
８次に処理されるべきノード１５８の整数を要求するバ
ッファ制御処理プログラム１０２をコールするものであ
るファイル記述２次元リスト１０８内のポインタを規定
するステップ４９０から開始する。この処理のためのポ
インタはディレクトリ形成順序にしたがってファイル記
述２次元リスト１０Ｂを介して移動する。ファイル記述
２次元リス）１０８を通してソースロケーションポイン
タが移動するときディスクの各形式がソースディスク内
に見出されなければならないから、その移動はファイル
およびディレクトリで停止するが、ディストネーション
・ロケーションポインタが移動するとき、その移動はフ
ァイル記述２次元リスト１０８内のファイルノードをス
キ・ンブし、ディレクトリのみがディストネーションデ
ィスクから読み出されなければならないのでディレクト
リにおいてのみ停止する。そのルーチンは、ソースディ
スクまたはディストネーションディスクに目標のエント
リを配置するファイルシステム特定化ルーチンのアドレ
スをロードする（ステップ４９２）。それから。

ファイル記述ポインタがファイル記述２次元リス１−１
０８内のルートまで進められる（ステップ４９４）。こ
れはバッファ制御処理プログラム１０２に対するコール
である。さらに第２１図の処理プログラムは、待機状態
が生ずるかそのルーチンが行われるまでロケーション動
作を継続するメインループに入る。そのループの最初の
ステップは、次のファイルまたは次のディレクトリに対
するファイル記述２次元リスト１０８用のりストポイン
タを進めることである（ステップ４９６）、この要求は
、バッファ制御処理プログラム１０２で整数のポインタ
番号を入手させ、ある状態（レディ状態、データをアウ
エイテング状態（ａｗａｉｔｉｎｇ）する状態、終了状
態）に戻る。もし戻った状態が「レディ状態」の場合に
は、バッファ制御処理プログラム１０２はまた次のりス
トエントリ（に対するポインタ）のアドレスに戻る。（
もし次のリングのアドレスを有している場合にはイクス
テントが戻される。） ソースロケーションポインタがディレクトリおよびファ
イルの両者にわたって進められ（それらで停止され）、
そして、ファイル記述２次元リスト１０８を通して最初
に順序づけされた（移動が可変ではない）ポインタであ
る。ディストネーション・ロケーションポインタがその
ディレクトリにわたって進められ、リストエントリをデ
ィストネーションディレクトリ・リングに挿入するディ
レクトリ作成ボインクに続けられる。ディレクトリの作
成処理がロケーション情報を入手するために必要な情報
を有するディストネーションディレクトリから情報を得
るから、ディストネーション・ロケーションポインタが
ディレクトリ形成ポインタに続けられることが要求され
る。ソースロケーションポインタがブロックリードポイ
ンタおよびブロックレディポインタに続けられる。ディ
ストネーション・ロケーションポインタがブロックライ
トポインタに続けられる。

もしエントリが利用可能でない場合（ステップ４９８）
、その処理プログラムはファイル記述２次元リスト１０
８内のエントリが利用可能になるまで待機する（ステッ
プ５００）。もしエントリが利用可能な場合、その処理
プログラムはウィンドー２９０の適切な位置から要求さ
れる情報を配置するためのビューを人手する。これは、
必要なインデックスファイルの部分を特定しファイル・
アロケーションテーブル内のワードを指示するＤＯ３内
のクラスタ番号を特定するため、ＶＭＳヘッダ番号を用
いて適切なウィンドー区分から情報を要求するバッファ
制御処理プログラム１０２をコールすることである。も
う−度バッファ制御処理プログラム１０２が、ポインタ
または情報を配置することがレディ状態でない指示に戻
る。もし情報を配置することがレディ状態でない場合、
この処理プログラムは待機状態に入り（ステップ５０６
）、情報を配置することを待つ。処理制御ルーチン３９
８によってこの処理プログラム２７８／２８４が再びコ
ールされると、待機状態（ステップ５０６）の前に記憶
されているステップ番号が用いられてすくにステップ５
０２に移動させられる。ロケーション情報がレディ状態
のとき（ステップ５０８）、ファイルロケーシッン情報
またはディレクトリロケーション情報が共通のメモリフ
ォーマントに読み込まれ（ステップ５０８）。

整数のディストネーションによって予め提供されたリス
トポインタを用いてファイル記述２次元リスト１０８に
記憶される。

（以下余白） 第２２図に図解したソースブロックリード処理プログラ
ム２７４は、装置情報を入手する処理段階（ステップ５
２０）から始まる。すなわち、ユーザー仕様によって特
定された装置がランダムアクセスかどうか、それらの装
置がディスク装置であるかのチエツクが行われる。この
処理段階および次の３つの処理段階は最初の時点で実行
され。

この処理プログラムが起動され、そして、ディスクの形
式が異種であるかどうかに関わらず「処理終了」として
復帰する。次にユーザーはディスクが搭載されるべきこ
とが必要かどうかについて質問され（ステップ５２２）
、もし必要な場合装置が搭載され（ステップ５２４）、
そうでない場合には処理は停止する。次にソースディス
クの形式を決定するのに必要なソースディスクの情報ブ
ロックが読み出される（ステップ５２６）。この時点で
、ディスクの形式が異種かどうかについての決定が行わ
れる（ステップ５２８）。もしディスクの形式が異種で
ない場合にはソースブロックリード処理プログラム２７
４は再び実行される必要がなく、その処理が終了したこ
とを示してその処理ルーチンから出る。もしディスクの
形式か異種の場合には、ファイルシステム・ロケーショ
ン情報が読み出される（ステップ５３０）、このロケー
ション情報は、ディスクの形式（ＶＭＳホームブロック
またはＤＯ３ＢＩＯＳパラメータブロック）を決定する
ために用いられるディスクの最初の１０２４バイトであ
る。ＤＯ３ＢＩＯＳパラメータブロックは、ファイル・
アロケーションテーブルおよびルートディレクトリの配
置を決定するために用いられる。ＶＭＳホームブロック
はヘッダファイルのロケーションおよびファイル内の第
４のヘッダを特定しルートディレクトリ内のロケーショ
ンを同定する第１のヘッダを入手するために用いられる
。次に、エントリのロケーションを決定するためにソー
スロケーション処理プログラム２７８が用いるルートお
よびビットマツプがロードされる（ステップ５３２）。

後でソースブロックリード処理プログラム２７４がコー
ルされると、この処理はループ処理に入り、そのループ
内で、ディレクトリ、ファイルおよびヘッダがロードさ
れている間可能なかぎり、そして必要なかぎり実行され
る。

ループの第１のブロックの処理の間、ファイル記述２次
元リスト１０８内のソースディレクトリが読み出され（
ステップ５３４）、　ソースディレクトリ・リング２７
５に記憶されるが、これについては第２３図を参照して
詳細に後述する。もしこの処理の間にファイル記述２次
元リスト１０８のディレクトリのリストの終わりになる
と、この処理プログラム２７４は次のステップの処理に
移るかまたはルームのための待機状態になる。しかしな
がら、もしＩ１０待機状態に遭遇すると、このソースブ
ロックリード処理プログラム２７４は現在のステップで
待機しくステップ５３６）、処理制御ルーチン３９８に
戻る。次に、ソースブロックリード処理２７４プログラ
ムは、第２３図に関連づけて述べるように、Ｉ１０待機
状態に遭遇するまで、または、ルーム空き待ちのために
次のステップに移動するまで、ソースファイルデータ・
リング１１２にできるだけ多くのファイル記述２次元リ
スト１０８に列挙されたソースファイルを読み込む（ス
テップ５３８）、それから、ソースブロックリード処理
プログラム２７４は、Ｉ１０待機が必要になるまで（ス
テップ５４４）、または、ウィンドー内により多くのル
ームが必要なので次のステップへの移動が必要になるま
で、ファイル記述２次元リスト１０８のファイルのイン
デックスおよびディレクトリをソースロケーション・ウ
インドー、２７２に読み込む（ステップ５４２）。ヘッ
ダ（インデックス）の読み込み動作については第２４図
を参照して詳細に後述する。

全ての読み込みが行われなかった場合、すなわち。

ファイル記述２次元リスト１０８の最後に到達しなかっ
た場合には、ソースブロックリード処理プログラム２７
４はより多くのデータを読み込むために待機するか、フ
ァイル記述２次元リスト１０８内により多くのルームが
できるまで待機する（ステップ５４８）。この待機状態
からの復帰は。

制御が処理制御ルーチン３９８に転送される前に記憶さ
れたステップ番号を用いて予め実行されたステップ５３
４，５３８および５４２内のステップに戻る。全てのフ
ァイル読みだしが完了したとき、この処理プログラム２
７４は、ユーザー仕様内に特定されたファイルの終わり
に到達しており、状態が終了してものとしてセットされ
る。

適切なリングへのディレクトリのブロックリード処理プ
ログラム５３４およびファイルのブロックリードプログ
ラム５３８が第２３図に図解したものと同じ処理方法に
よって行われる。この処理プログラムはまた。ディスト
ネーションディスク３０４のディレクトリがディストネ
ーシゴンＤＩＲ−ＩＮリング２９２に読み込まれるのに
必要なとき、ディストネーションブロック・ライトプロ
グラム処理３００によって実行される。この処理プログ
ラムは、ソースディレクトリ、ファイルディレクトリま
たはディストネーションディレクトリがローカル処理ア
レー内の対応するポインタを用いることが必要とされる
かどうかを維持し続ける。このアレー内のインデックス
が現在のステップによって決定される。この処理プログ
ラムは。

エントリを次のファイル記述２次元リスト１０８に進め
、読み込まれるブロックロケーションイクステントが存
在する限り、それらをメモリに読み込む。最後のブロッ
クロケーションイクステントが読み出されると、この処
理プログラムはファイル記述２次元リスト１０８内の次
のエントリに進める。ソースブロックリード処理プログ
ラム２７４による最初のステップは、リングイクステン
トが適切なリング１１２または２７５内に割りつけられ
ているか否かを決定するものである（ステップ５６０）
。もし割りつけられていない場合、利用可能なイクステ
ントに対して本質的に適切なポインタを要求するバッフ
ァ制御処理プログラムｌＯ２のコールである次のイクス
テントにリングポインタを進める（ステップ５６２）。

リードファイルポインタは、そのリングを通して最初の
ポインタであり、リングからデータを抽出するために用
いられる処理ポインタに続けられる。ソースディレクト
リに関してはそのポインタはソースサーチポインタであ
り、ソースデータリングに関してはそのポインタは翻訳
ポインタであるかブロックライトポインタであり、ディ
ストネーションディレクトリ・リングに関しては次のポ
インタはディレクトリ作成処理ポインタである。最初の
ポインタはバッファ制御ポインタである最後のポインタ
の前に入手してはならない。もしリングイクステントが
レディ状態でない場合には（ステップ５６４）、待機状
態となる（ステップ５６６）。次に第１０Ａ図に図解し
たブロック・ロケーションレコード２０３のフィールド
を検査することによりファイル・ロケーションイクステ
ントが利用可能か否かについての検査が行われる（ステ
ップ５６日）。もし利用可能でない場合、バッファ制御
処理プログラム１０２に対する他のコールを行うことに
よってファイル記述ポインタが進められる（ステップ５
７０）、再び、ポインタの番号またはポインタが進めら
れるかどうかの指示に戻る。次に処理は、イクステント
レングス２０４とセグメントレングス２３Ｇとを比較す
ることにより、適切なものとしファイルまたはディレク
トリ用の対応するリングセグメント内にルームが存在す
るかどうかについて決定する（ステップ５７６）。もし
存在しない場合、再びバッファ制御処理プログラム１０
２をコールすることにより新しいリングセグメントが割
りつけられる（ステップ５７８）。バッファ制御処理プ
ログラム１０２は状態フィールド２２５を用いて最初の
自由なセグメントを捜し出し、自由なセグメントを割り
つけるが、そうでない場合には、利用可能でない指示に
戻されこのステップで待機状態となる。それから、この
処理プログラムは、イクステントレングス２０４とセグ
メントレングス２３６とを比較することによりどれだけ
の大きさのファイルブロック・ロケーションイクステン
トが読み込めるかを決定しくステップ５８４）、待機し
ながら（ステップ５９０）データの適切な部分を読み込
む（ステップ５８６）。ステップ５８６における読み込
み動作は、第４９図を参照して詳述する絶対読み込み（
ａｂｓｏｌｕｔｅ　ｒｅａｄ）を従来方式でコールする
ものである。−旦、データが読み込まれ、適切なリング
の適切なイクステントに記憶される（ステップ５９２）
。この更新処理は、リング内に新しく記憶されたデータ
量をそのリングのセグメント内で利用可能な全部のスペ
ースを減算することを含む。もしフィールド２５０をチ
エツクすることによって決定される全部のプロックイク
ステントが読み込まれると（ステップ５９４）、　この
処理プログラムは、第１０Ａ図の次のブロック・ロケー
ションレコード２０３に対するポインタ２１０が続けら
れる次のファイルブロック・ロケーションイクステント
に進める。ただし、各ブロック・ロケーションレコード
２０３は１つのイクステントに応答する。それからこの
処理プログラムは、データを読み込む処理を継続するた
めにループバックする第２４図は第２２図のステップ５
４２のヘッダ（インデックス）のブロック読み込みを図
解している。第２４図のヘッダのブロックリード処理プ
ログラム５４２はディストネーションブロック・ライト
プログラム処理３００によっても用いられヘッダが必要
な場合ヘッダをディストネーション・ロケーション・ウ
ィンドー２９０にロードする。このルーチンは、ユーザ
ーによって特定されたファイルまたはファイルを合併す
るために必要なファイルのためのロケーション情報（本
質的にファイルヘッダまたはインデックス）をロードす
るためにコールされる。ＶＭＳにおいてこの情報はヘッ
ダであり、ＵＮＩＸにおいてこの情報はｌ−Ｎ０ＤＢＳ
であり、ＤＯ３においてこの情報はファイルアロケーシ
ョンテーブルである。ヘッダは、適切なソースロケーシ
ョンまたはソースロケーションポインター２７６および
２９０に記憶される。最初に、このブロックリード処理
プログラム５４２は１　ピークアヘッド・バリアプル値
ＮをＩにセットすることである（ステップ６１０）。

このピークアヘッド・バリアプル値Ｎは、実施するに必
要なヘッダのブロックリードがファイル記述２次元リス
ト１０８のためのソースロケーションポインタに対して
どれだけ離れた前方にあるかを示すために用いられる。

ブロックリード処理ルーｆン５４２は、ロケーション処
理プログラムがファイル記述２次元リスト１０８内のポ
インタを進めていることを知っており、ブロックリード
処理ルーチン５４２はウィンドーに必要な情報をロード
することを試みる。このピークアヘッドは可変である。

その理由は、ソースデイレクトリサーチ処理プログラム
２８０がソースディレクトリ・リング２７５を検査して
おり、ロードされている任意のディレクトリのためにフ
ァイル記述２次元リスト１０Ｂ内にエントリを生成して
いるからである。次に第２４図のブロックリード処理ル
ーチン５４２は、エントリＮの番号のためにファイル記
述２次元リスト１０８内にピークアヘッドする（ステッ
プ６１２）。ここで起こるバンファ制御ピークアヘッド
は、ロケーションポインタによって指定される現在のア
ドレスを保存するために用いられ、バッファ制御処理プ
ログラム１０２をコールしてポインタをＮ回進め、その
アドレスを元・の現在アドレスに復活させ、そのポイン
タは将来Ｎ回コールするために進められるアドレスに復
帰させる。ピークアヘッドは、ファイル記述リストノー
ド１５８のアドレスを入手するが、その処理は、ソース
およびディストネーション処理がそれらを入手するとき
行われ、そして、ピークアヘッドは、へンダをウィンド
ーにロードすべきことが必要か否かを決定するためにレ
コード外のヘッダフィールド内容を入手する。もしリス
トレコードがレディ状態でない場合（ステップ６３６）
、読み込むべき何らかのヘッダが存在するか否かについ
ての決定が行われ（ステップ６３６）　、　　もし存在
する場合、この処理ルーチンはヘッダを読み込む（ステ
ップ６３０）。ウィンドーが現在使用すべきヘッダを有
しているので読み込むべきヘッダが存在しない場合、ま
たは、ピークアヘッドデータが利用可能でない場合、こ
の処理ルーチンはピークアヘッドによって指定されるフ
ァイル記述２次元リス）１０８内にエントリが利用可能
になるまで待機する（ステップ６３８）。レコードがレ
ディ状態の場合、ヘッダ番号１９７がソースディスフ２
７０のブロック番号に変換され、ブロック・ロケーショ
ンレコード２０３に記憶される。次に、このヘッダが新
しいビュー内の最初のへ・ンダであるか否かの決定が行
われる（ステ・ンプ６１Ｂ）。すなわち、ページング（
ページ割りつけ）処理において、ウィンドーのビューの
インデ・ンクス範囲が探し出されたヘッダの番号に対し
て比較され、もしその範囲内に存在しない場合にはその
ヘッダは新しいビューである。その場合にはデータビュ
ーが割りつけられ、最大範囲がセ・ントされる（ステッ
プ６２０）。データビューがレディ状態でない場合（ス
テップ６２２）、適切なウィンドーにおいて利用可能に
なるまで待機する（ステップ６２２）。そのビューのヘ
ッダおよびプロ・ツク番号が読み出しのために割りつけ
られた最初のヘッダおよびブロック番号と比較される。

へ・ンダ番号とブロック番号とが同じでない場合、デー
タは連続していないので、新しいヘッダはウィンドーに
ロードするために割りつけられない。もしデータがディ
スク上に隣接している場合、そのへ、ンダのウィンドー
ビュー内にルームが存在するか否かについてのチエツク
が行われる。もしルームが存在しない場合１次のヘッダ
をウィンドーに嵌め込むことが可能か否かについて検査
する。検査した結果衣のヘッダがウィンドーに嵌め込む
ことができない場合、または、その検査がさらに前方を
見ることができない場合、そのデータがウィンドーに読
み込まれる。もしロードすべき他のヘッダが存在する場
合、そして、他のデータビューが利用可能な場合、その
ヘッダが割り当てられる次のデータビュー内で最初のヘ
ッダとなる。

第２５図に示したソースファイル・ルックアップ処理プ
ログラム１０４において、最初に行われる処理はファイ
ル記述２次元リスト１０８にファイルエントリを挿入す
るポインタを定義することである。もう−度述べると、
これはバッファ制御処理プログラム１０２をコールして
ポインタについての整数の指定（ｄｅｓｉｇｎａｔｉｏ
ｎ　）を得ることである。このポインタはソースサーチ
ポインタのように可変移動ポインタである。次にポイン
タは。

再びバッファ制御処理プログラム１０２をコールするこ
とによりファイル記述２次元リスト１０８内のルートデ
ィレクトリエントリに対して進められる。それから、こ
の処理プログラムは、ファイル記述２次元リスト１０８
内にファイルエントリを生成する処理ループに入る。ま
ず、ファイル仕様内の次のディレクトリエントリが入手
されるが（ステップ６５４）、　　この処理は元々のフ
ァイルシステムＩ１０ルーチンに対するコールである。

もしディレクトリエントリが利用可能な場合（ステップ
６５６）、上述したようにエントリが処理のために必要
か否かについて決定が行われる（ステップ６５８）。次
に、前述したように、ノクツファ制御処理プログラム１
０２をコールすることＧこより、エントリをファイル記
述２次元リスト１０８内に挿入する。もしそれ以上ディ
レクトリエントリが存在しない場合、サブディレクトリ
につ０）ての処理が必要か否かについての決定が行われ
る（ステップ６６２）。もｔ存在しない場合、ポインタ
が次のディレクトリに対して進められ（ステップ６６４
）、そして９　このポインタを進める要求に関してバッ
ファ制御処理プログラム１０２がレディ状態でない状態
に復帰しているとき、ディレクトリがレディ状態かどう
かについての決定が行われる（ステップ６６６）。もし
ディレクトリがレディ状態の場合、ディレクトリがファ
イル仕様サーチバスに加えられ（ステップ６６Ｂ）、こ
の処理は次のエントリを入手するために復帰する（ステ
ップ６５４）。

第２６図に図解されているソースファイルリード処理プ
ログラム１１０もソースデータリング１１２およびファ
イル記述２次元リス）１０８のためのポインタを定義す
る処理ステップで始まり（ステップ６５０，６５２）、
　　この処理はバッファ制御処理プログラム１０２を適
切にコールすることにより行われる。このリストポイン
タは挿入ポインタが続けられ、ディレクトリエントリに
わたってスキンプするディレクトリ作成順序に従って移
動する。ファイルリードポインタが最初であり、翻訳処
理が行われている場合鉗訳ポインタが続けられ、そうで
ない場合ブロックライトポインタが続けられ、そして、
ファイルリードポインタがディレクトリリストノードに
わたってスキップするディレクトリ作成順序にしたがっ
て移動する。

次にファイル記述２次元リスト１０８用のポインタが次
のファイルに対して進められ（ステップ６８２）、もし
エントリがレディ状態でない場合（ステップ６８４）、
待機状態になる（ステップ６８６）。次に、ファイル名
称によって特定されたファイルが１元々のオペレーティ
ングシステムに対して従来のＣ言語コールを行うことに
よって読み込みに対してオープンにされる（ステン１６
８８）。フィールド２０３が復帰情報によって完全にさ
れ、そして、そのフィールドがファイルを特定するため
のリード、ライトおよびクローズコールに対して通過さ
せられる。それから、レコード２０３およびレコード２
２５を用いる上述した方法によって、スペースがリング
のソースデータセグメント上で利用可能かどうかについ
て決定が行われる（ステップ６９０）。もし利用可能な
場合、バッファ制御処理プログラム１０２をコールする
ことにより次のソースデータセグメントが得られる（ス
テップ６９２）。もしセグメントがレディ状態でない場
合（ステップ６９４）、待機状態となる（ステップ６９
６）。リングセグメントが利用可能な場合、イクステン
トがレディ状態でない場合には（ステップ７０２）待機
しながら（ステップ７０４）、ポインタが次のイクステ
ントに対して進められる（ステップ７００）。それから
ファイル内のデータが読み込まれ（ステップ７０４）、
イクステント情報の更新（ステップ７１０）が続けられ
る利用可能なセグメントスペースの更新（ステップ７０
８）とともに、そのデータがセグメントに記憶される。

もし、ノンゼロバイトの読み込み復帰によって決定され
る全体のファイルがまだ読み込まれていない場合（ステ
ップ７１２）、読み込み処理が継続しくステップ６９０
）、そうでない場合には１元々のオペレーティングシス
テムに対して標準のＣ言語を用いて、ファイルがクロー
ズされる（ステップ７１４）。

第２７図は翻訳処理プログラム１１４の動作を図解して
おり、この翻訳処理は、ソースデータリング１１２内の
データがレディ状態か否かについての検査（ステップ７
２０）から開始している。

データがレディ状態でない場合、バッファ制御処理プロ
グラム１０２のコールが行われて次のソースデータ・リ
ングイクステント２４２を入手する（ステップ７２２）
。もしソースデータ・リングイクステント２４２がレデ
ィ状態でない場合（ステップ７２４）、待機状態となる
（ステップ７２６）、もしソースデータ・リンダイクス
テント２４２内のデータがレディ状態の場合ラインまた
はレコードが抽出され（ステップ７２Ｂ）、ディストネ
ーションデータ・リング１１６のイクステント内にルー
ムが存在するか否かについて検査が行われる（ステップ
７３０）。もしルームが存在しない場合、バッファ制御
処理プログラム１０２をコールすることによってリング
ポインタが進められる（ステップ７３４）。もしディス
トネーションデータ・リング１１６用のイクステントが
レディ状態でない場合（ステップ７３６）、他の待機状
態となり（ステップ７３８）、イクステントがレディ状
態かもしくは存在する場合にはディストネーションデー
タ・リング１１６のディストネーションデータセグメン
ト（２２０〜２２４）内のライン用のルームが存在する
か否かについての決定が行われる（ステップ７４０）。

もしルームが存在しない場合、リングセグメント情報が
更新され（ステップ７４２）、再びバッファ制御処理プ
ログラム１０２をコールすることにより、新しいデータ
セグメントの割りつけ処理（ステップ７４４）が続けら
れる。イクステントがセグメント境界を横切らないので
、新しいセグメントが割りつけられる。もし新しいセグ
メントがレディ状態であるか（ステン１７４６）古いセ
グメントがルームを有している場合（ステップ７４．０
　）　、新しいフォーマット内のディストネーションデ
ータセグメント内にラインが置かれ（ステップ７５０）
、ディストネーション・ファイルサイズを増加させる処
理（ステップ７５２）が続けられる。もしこのラインが
ファイル内の最後のラインでない場合（ステップ７５４
）、　　ソースデータリング１１２からディストネーシ
ョンデータ・リング１１６に移動する処理が続く。丁度
全記憶されたラインがファイル内の最後のラインの場合
、ディストネーションファイルのサイズがファイル記述
２次元リスト１０８に記憶され（ステップ７５６）、　
　リングイクステント情報が更新される（ステップ７５
８）。

第２８図に図解したディストネーション・ディレクトリ
作威処理プログラム２８２がまずコールされると、この
処理プログラムはバッファ制御処理プログラム１０２を
コールしくステップ７７０）、ディストネーションＤＩ
ＲｉＮリング２９４およびディストネーシジンＤＩＲ−
ＯＵＴリング２９６のためのポインタの定義に沿ってフ
ァイル記述２次元リス）１０Ｂ用のディレクトリ作成ポ
インタを定義する。リストポインタは翻訳ポインタまた
はブロックリードまたはファイルリードポインタに続い
ており、ディストネーションロケーションポインタが続
けられている。ディストネーションＤＩＲ−ＩＮリング
２９４のポインタはブロックリードデイレクトリポイン
タに続いており、バッファ制御ポインタが続けられてお
り、−方５ディストネーションＤ　Ｉ　Ｒ−ＯＵＴリン
グ２９６のポインタが最初で、ブロックライト・デイレ
クトリポインタが続けられている０次に、ディストネー
ション・ディレクトリ作成処理ルーチン２８２は、リン
グ内のディストネーションディレクトリから次のディレ
クトリエントリを人手するファイルシステム特定化ルー
チン用のアドレスをロードしくステップ７７２）、ディ
ストネーションＤＩＲ−ＯＵＴリング２９６内に新しい
エントリを挿入し、ディレクトリエントリから名称と形
式を抽出する。リングポインタ内のりストボインクおよ
びディストネーションディレクトリがルートに対して進
められ（ステップ７７４）、それによって、ファイル記
述ポインタおよびポインタ内のディストネーションディ
レクトリが同じディレクトリに対応する。それから、デ
ィストネーションディレクトリエントリが予め決定され
たデイストネーシゴンディスク３０４のファイルフォー
マットに基づいて分類されるべきか否かについての決定
が行われる（ステップ７７６）。もしディレクトリエン
トリが分類されるべき場合、ディレクトリエントリは、
第２９図を参照して記述される分類順序に従って合併さ
れる（ステップ７７８）。もしディレクトリエントリが
分類されない場合、それらは、第３０図を参照して述べ
る非分類に従って合併される（ステップ７８０）。現在
のディレクトリ用のエントリが一旦合併されると、ノ＼
ッファ制御処理プログラム１０２をコールすることによ
って、ディストネーションＤＩＲ−ＩＮリング２９４内
のディストネーションディレクトリ用のポインタが次の
ディレクトリに対して進められる（ステップ７８２）。

もし次のディレクトリがレディ状態でない場合（ステッ
プ７８４）、待機状態となるが、そうでない場合には処
理が継続される。もしファイル記述２次元リスト１０Ｂ
内のディストネーションディレクトリの終わりおよびデ
ィストネーションＤＩＲ−ＩＮリング２９４内のディス
トネーションディレクトリの終わりに到達すると、この
処理ルーチン２８２は終了し。

終わりを示すフラグがたてられる。

（以下余白） 処理プロ７り７７８の分類されたディレクトリエントリ
の合併処理ルーチンが第２９図に図解され、ＶＭＳに関
して、ファイル記述２次元リスト１０８のエントリとデ
ィストネーションディスク３０４のエントリとがアルフ
ァベット順に合併される。このルーチンは、ファイル記
述２次元リスト１０８から分類されたディレクトリを取
り、それをディストネーションＤＩＲ−ＩＮリング２９
４内のディストネーション内の分類されたディレクトリ
と合併する。最初のステップは、ディストネーションＤ
ＩＲ−ＩＮリング２９４のエントリ内の他のディレクト
リが必要か否かについて決定を行うことである（ステッ
プ８００）。もし他のディレクトリが必要な場合、この
処理はファイルシステム特定化ルーチンをコールするこ
とにより、ディストネーシヲンＤＩＲ−ＩＮリング２９
４のエントリ内の次のディレクトリを入手する（ステッ
プ８０２）。もしディストネーションＤＩＲ−ＩＮリン
グ２９４内のエントリがレディ状態でない場合（ステッ
プ８０４）、待機状態となるが、ディストネーションデ
ィスク３０４のディレクトリの終わりに到達している場
合、ディストネーションディスク３０４からディレクト
リを入手する。もしディレクトリエントリがレディ状態
の場合、ファイル記述２次元リスト１０８から新しいエ
ントリが必要か否かについての決定を行う（ステップ８
０８）。もし現在のエントリがすでに処理されておりデ
ィストネーションＤＩＲ−ＯＵＴリング２９６に置かれ
ている場合５現在のエントリはディストネーシゴンＤＩ
Ｒ−ＩＮリング２９４の現在のエントリの前にアルファ
ベット順になっているので、新しいエントリが必要にな
る。もし新しいエントリが必要な場合、ファイル記述２
次元リスト１０８用のデイレクトリポインタがバッファ
制御処理１０２をコールすることによって進められる（
ステップ８１０）。もし新しいエントリを挿入すること
が必要な場合（ステップ８１２）、その新しいエントリ
はディストネーションＤＩＲ−ＩＮリング２９４の現在
のエントリの前にアルファヘット順になっているから、
新しいエントリのためのディストネーシゴンＤＩＲ−Ｏ
ＵＴリング２９６内にルームが存在するか否かについて
の決定を行う（ステップ８１４）、ルームが存在しない
場合、バッファ制御処理プログラム１０２に対するコー
ルが行われ、ディストネーションＤ　Ｉ　Ｒ−ＯＵＴリ
ング２９６のための新しいセグメントが割りつけられる
（ステップ８１６）。

もし新しいエントリが割りつけられていない場合（ステ
ップ８１８）、待機状態となり（ステップ８２０）、処
理制御ルーチン３９８に制御が戻り他の処理プログラム
またはルーチンの実行を可能にする。次に１合併ルーチ
ン７７８がファイル記述２次元リスト１０８を指定する
エントリとディストネーシゴンＤＩＲＩＮリング２９４
を指定するエントリとを比較しくステップ８２２）、そ
のエントリが二重化されている場合、システム特定化ル
ーチンが二重化エントリを挿入するためにコールされる
（ステップ８２４）、たとえば、ＶＭＳに関して、ファ
イルの付加的なバージョンが生成される。もしエントリ
が二重化エントリでない場合には、システム特定化ルー
チンがコールされて分類順序に従って２つの比較された
エントリのうち最も優先順位の高いエントリが挿入され
る。これらの２つの挿入ルーチンはまた。前進スキャン
または後進スキャンのいずれかによって、第１の未割り
つけヘッダをサーチすることによりヘッダ制御リスト（
ＨＣＬ）ウィンドー２９２内にヘッダを割りつける。こ
のルーチン７７８は復帰してディストネーションＤＩＲ
−ＩＮリング２９４から他のエントリを入手する。

第２８図のステップ７８０の未分類エントリの合併処理
ルーチンが第３０図に図解されている。

このＪレーチン７８０は１　それ自身ディストネーショ
ンソースの元のファイルのためのディレクトリよりディ
ストネーションディレクトリ構造において高いディスト
ネーションディスクからのファイル用のディレクトリを
挿入する。この順序は、リングからの全てのエントリが
挿入されているかどうかを決定するためにチェツクする
ステップ８４０において行われる検査を簡単に変えるこ
とにより反転できる。もしファイル記述２次元リストｌ
Ｏ８からの全てのエントリが挿入されていると。

この処理ルーチン７８０はバッファ制御処理プログラム
１０２をコールすることによりファイル記述２次元リス
ト１０Ｂ用のポインタを進め（ステップ８４２）、もし
エントリがレディ状態でない場合には（ステップ８４４
）、待機する（ステップ８４６）。リングからの全ての
エントリが挿入されていない時には、この処理ルーチン
７８０はファイルシステム特定化処理を用いてディスト
ネーションＤＩＲ−ＩＮリング２９４内のディストネー
ションディレクトリからのエントリを入手する（ステッ
プ８４８）。もしエントリが待機状態でない場合（ステ
ップ８５０）、　この処理ルーチン７８０は待機状態と
なる（ステップ８５２）。エントリがレディ状態の場合
、新しいエントリのためのディストネーションＩＩＲ−
ＯＵＴリング２９６にルームが存在するか否かについて
の決定が行われる（ステップ８５４）、もしルームが存
在しない場合、バッファ制御処理プログラム１０２をコ
ールすることにより、新しいセグメントが割りつけられ
る（ステップ８５６）。セグメントがレディ状態でない
場合（ステップ８５８）。

待機状態となる（ステップ８６０）。二重化エントリの
比較処理（ステップ８６２）および二重化エントリの挿
入処理（ステップ８６４）または簡単な挿入処理が第２
９図に示したルーチン７７８と同様に行われる（ステッ
プ８６６）。

ディストネーションディスクがＤＯＳディスクの場合に
は起動されない、第３１図に図解したヘッダ作成処理ル
ーチン２８６の始まりにおいて前述した方法と同様の方
法でバッファ制御処理プログラム１０２をコールするこ
とにより、ファイル記述２次元リスト１０８用のヘッダ
形成ポインタを定義する（ステップ８８０）。このリス
トポインタは、ファイルのブロックライトポインタおよ
びディレクトリのブロックライトポインタに続いており
、バッファ制御ポインタが続けられ、そして、ファイル
記述２次元リスト１０８内のファイルノードおよびディ
レクトリノードで停止するディレクトリ作成順序に従っ
て進められる。次に、ディストネーションディスク３０
４のフォーマット内にヘッダを作成するフォーマットシ
ステム特定化ルーチンのアドレスがロードされる。この
ループを通じた最初のバスにおいて、ヘッダ作成処理用
のリストポインタがヘッダを要求する最初のファイルま
たはディレクトリに対して進められる（ステップ８８４
）。これはバッファ制御処理プログラム１０２を再びコ
ールすることでありもしポインタが進められない場合（
ステップ８８６）、待機を要求する（ステップ８８８）
。それから、新しいヘッダがファイル記述２次元リスト
１０８の情報から形成され、ディストネーション・ロケ
ーション・ウィンドー２９０に挿入され（ステップ８９
２）、ヘッダ制御リスト（ＨＣＬ）ウィンドー２９２が
更新される。挿入動作は、ディストネーション・ロケー
ション・ウィンドー２９０にルームが存在するか否かを
再び示す（ステップ８９２）バッファ制御処理プログラ
ム１０２をコールすることであり、ルームが存在しない
場合、適切なディストネーション・ロケーション・ウィ
ンドー２９０のロードのために待機する（ステップ８９
６）。次に、ファイルシステム特定化ルーチンがコール
され、ヘッダ情報を記憶する（ステップ８９８）。

ディストネーションブロック・ライト処理プログラム３
００が第３２図に図解されているが、この処理プログラ
ム３００の最初の７つのブロックの処理内容は、第２２
図を参照して述べたソースブロックリード処理プログラ
ム２７４の対応する同じステップと同じである。ブロッ
クライト処理プログラムは、異なるタスクの番号と協働
するポインタを異なる方法で進める。サブディレクトリ
の読みはファイル記述２次元リスト１０８内のディレク
トリにわたって進められており、このポインタがディス
トネーション・ロケーションポインタに続いており、そ
して、ヘッダ作成ポインタが続けられている。ディレク
トリを書き込むためのポインタはディストネーションＤ
ＩＲ−ＯＵＴリング２９６を通じて進められており、デ
ィレクトリ形成ポインタに続いており、バッファ制御ポ
インタが続けられている。ファイルの書き込みは。

ポインタの翻訳の後ディストネーションデータリングを
通してか５ブロツクリードポインタの後のソースデータ
リングを通して、進める。ファイルおよびディレクトリ
の書き込みについて、ファイル記述２次元リストｌＯ８
を通して移動するポインタが存在し、このポインタは実
際の書き込みポインタに続いており、ブロック書き込み
によって最終的なディストネーションロケーションが割
りつけられる前にヘッダを作成することからディレクト
リ作成ポインタの順序づけを防止するために用いられる
。このポインタはブロック書き込みに対しては機能しな
い、−旦ディスクの形式か決定され、処理制御ルーチン
３９８が再びディストネーションブロックライト処理プ
ログラム３００をコールすると、書き込みループ内の最
初のステップがディストネーション・ロケーション・ウ
ィンドー２９０からディストネーションディスク３０４
に１２４個全てのヘッダの書き込みを試みる。

このステップについては第３３図を参照して詳細に後述
する。もしディストネーションディスク３０４がビジィ
状態の場合にはＩ１０待機状態となり（ステップ９２６
）、ステップ９２４が、全てのロケーション・ウィンド
ー・ヘッダがディストネーションディスク３０４に書き
込まれるまで。

または、ディストネーション・ロケーション・ウィンド
ー２９０が空で充満されることを必要とするまで、実行
を継続する。次に、この処理プログラム３００はディス
トネーションＤ　Ｉ　Ｒ−ＯＵＴリング２９６からディ
ストネーションディスク３０４に全てのディレクトリを
書き込み（ステップ９２８）、必要ならば待機する（ス
テップ９３０）。この処理ルーチンについての詳細につ
いては第３４図を参照して後述するが、ディストネーシ
ョンＤＩＲ−ＯＵＴリング２９６が空になるまで実行を
継続する。ステップ９３２において、第２３図を参照し
て述べたように、ある必要なディレクトリがディストネ
ーションＤＩＲ−ＩＮリング２９４に読み込まれ、ステ
ップ９３４において。

第２４図に図解したように、ヘッダがディストネーショ
ン・ロケーション・ウィンドー２９０に読み込まれる。

次に、ディストネーションディスク３０４がヘッダまた
はインデックス形式レコード制御リストを有している場
合、アロケーション制御リスト用の隣接した知られたロ
ケーシタンビットマップおよび隣接した知られたロケ−
シランヘッダ制御リストについてのビットマツプが読み
込まれる（ステップ９３６）。それらのビットマツプが
一旦読み込まれると、ファイルがディストネーションデ
ータ・リング１１６からディストネーションディスク３
０４に書き込まれる（ステップ９４０）、全ての読み込
みおよび書き込みがまだ終了していない場合にはさらに
多くのデータを読み込みまたは書き込むために転送シス
テム３６は待機する（ステップ９４６）。この待機状態
（ステップ９４６）からの復帰は特別の処理（ステップ
９２４〜９４０）への復帰であり、これらの処理の特別
のステップが最初の位置で待機状態となる。全ての書き
込みが行われた場合、更新されたピントマツプがディス
トネーションディスク３０４に連続的に書き込まれる（
ステップ９４８）。

第３２図に示したステップ９２４および９４０における
ファイルまたはディレクトリのブロック書き込み処理が
第３３図に図解されている。第１のステップ９６０は、
前述したバッファ制御処理プログラム１０２をコールす
るポインタを定義することである。それから転送システ
ム３６は、ファイルの場合にはディストネーションデー
タ・リング１１６について、ディレクトリの場合にはデ
ィストネーションＤ　Ｉ　Ｒ−ＯＵＴリング２９６につ
いての適切なりングイクステントポインタを進め（ステ
ップ９６２）、前述した状況と同様の方法でイクステン
トがレディ状態か否かを決定しくステップ９６４）、イ
クステントがレディ状態でない場合には待機する（ステ
ップ９６６）。イクステントがレディ状態の場合、その
イクステントのためのスペースがディストネーションデ
ィスク３０４に割りつけられているか否かについての決
定が行われる（ステップ９６８）。スペースが割りつけ
られていない場合、隣接したスペースが割りつけられ（
ステップ９７０）、アロケーション制御リスト（ＡＣＬ
）ウィンドー２９８に対する適切な更新が行われる。次
に、ディストネーション・ロケーション情報がファイル
記述２次元リスト１０８内のエントリに記憶され（ステ
ップ９７２）、ディストネーションディスク３０４に割
りつけられた部分の書き込みが行われる（ステップ９７
４）。この書き込み処理ルーチン９７４は。

第４９図を参照して詳細に後述する絶対的な書き込みで
ある。全てのイクステントがまだディストネーションデ
ィスク３０４に書き込まれていない場合１割りつけ処理
および書き込み処理が継続される。イクステントが完全
に書き込まれている場合、リングイクステントポインタ
を進める処理ステップ９６２に移行する。

第３２図のブロックライト・ウィンドー処理ルーチン９
２８が第３４図に図解されている。このルーチン９２８
はまず、バッファ制御処理プログラム１０２をコールし
て書き込むための次のビューを人手する（ステップ９８
０）。次のビューがレディ状態でない場合（ステップ９
Ｂ２）、他の処理の全てのブロック書き込みステップが
完了しているか否かについての決定が行われる（ステッ
プ９８６）。すなわち、書き込み処理アレー内の各書き
込み処理の状態が検査され、その状態が終了しているか
否か決定される。もし終了していない場合、ウィンドー
書き込み処理は次のビューのために待機する（ステップ
９８４）。ビューがレディ状態の場合、ウィンドーの開
始インデックスがディストネーションディスク３０４上
のブロック番号に変換され（ステップ９８８）、全ての
修飾されたブロックがディストネーションディスク３０
４に書き込まれる（ステップ９９０）。

第３５図に示したように、ディストネーション・ディレ
クトリ作成処理プログラム１１８は起動されるとまず、
ファイル記述２次元リスト１０８用のポインタを定義す
る（ステップ１０００）。

このポインタは、ブロックリードデイレクトリボインク
に続いており、ファイルライトポインタが続けられ、サ
ブディレクトリでは停止しないで通過する。それからル
ープ処理に入り、そこの最初のステップ１００２におい
てポインタがファイル記述２次元リスト１０８内の次の
ディレクトリエントリに対して進められる。ステップ１
００および１００２はバッファ制御処理プログラム１０
２をコールする。ディレクトリエントリがレディ状態で
ない場合（ステップ１００４）、待機し再び第１８図の
ステップ４０４の処理制御ルーチン３９８に戻る。バッ
ファ制御処理プログラム１０２が終了状態に戻っている
場合、ディストネーション・ディレクトリ作成処理プロ
グラム１１８は終了状態に戻る。次のステップはディス
トネーションディスク３０４にディレクトリが存在する
か否かを決定する処理であり（ステップ１００８）。

ホストコンピュータ３０のホストオペレーティングシス
テム４４をコールすることにより決定が行われる。ディ
レクトリがディストネーションディスク３０４に存在し
ない場合はこの処理ルーチンはループバックし、一方、
ディレクトリが存在する場合は元々のホストオペレーテ
ィングシステム４４をコールし、ファイル記述２次元リ
スト１０８のノードからディレクトリがディストネーシ
ョンディスク１２２に生成される。

第３６図に示したディストネーションファイル・ライト
処理プログラム１２０も標準システムＣを用いて元々の
オペレーティングシステム４４をコールする。こ処理プ
ログラムは最初に起動された時ディストネーションデー
タ・リング１１６のポインタを定義しくステップ１０２
０）、次のディストネーションデータイクステントを入
手するが（ステップ１０２２）、ステップ１０２０およ
び１０２２はバッファ制御処理プログラム１０２をコー
ルする処理である。イクステントがレディ状態の場合、
このイクステントがファイル内の最初のインデックスで
あるか否かについての決定が行われる（ステップ１０２
８）。そのイクステントが最初のイクステントの場合元
々のホストオペレーティングシステム４４に対する標準
システムＣコールがディストネーションディスク３０４
にファイルを生成する。イクステントがファイル内の最
初のイクステントでない場合、そのイクステントがふ書
き込まれ（ステップ１０３２）、そのイクステントが最
後のイクステントであるか否かについての決定が行われ
る（ステップ１０３４９゜そのイクステントが最後のイ
クステントでない場合、処理プログラムはループバック
してディストネーションディスク３０４のファイルにイ
クステントを書き込む処理が継続される。最後のイクス
テントに到達すると２元々のホストオペレーティングシ
ステム４４に対する標準システムＣを用いてファイルが
クローズされる（ステップ１０３６）。

第３７図に、第１８図の処理制御ルーチン３９８によっ
てコールされるバッファ制御処理プログラム１０２の一
部が示されている。バッファ制御処理プログラム１０２
の最初の動作は、ウィンドーがまだ定義されていないこ
とを示すために各ウィンドーの状態フィールド３３８内
の値を簡単に設定するウィンドーを初期化しくステップ
１０５０）、ルートエントリであるファイル記述２次元
リスト１０８内のあるエントリを挿入することを意味し
ているファイル記述２次元リスト１０８を初期化しくス
テップ１０５２）、各リングがまだ定義されていないこ
とを示していることを意味する複数のリングを初期化す
ることである（ステップ１０５４）。上記初期化処理の
後に１各リング用のポインタがファイル記述２次元リス
ト１０８用のポインタとともに初期化される（ステップ
１０５６）。それから、ループ処理に入り、最初のステ
ップにおいて、最初のリングを処理するリングのリング
番号をセットする（ステップ１０５８）。次いで、その
リングが空かどうかについてのチエツク処理を行う（ス
テップ１０６０）。そのリングが空でない場合、新しい
データイクステントに対する処理に進む（ステップ１０
６２）。そのデータがレディ状態の場合（ステップ１０
６４）、そのデータが新しいバッファセグメント内にあ
るか否かについての検査が行われる（ステップ１０６６
）。そのデータがバッファセグメント内にあれば、古い
バッファセグメントの状態２２５が自由状態に解放され
る（ステップ１０６８）。

リングが空の場合、そのリング番号が増加させられ（ス
テップ１０７０）、そのリングがリングリスト内の最も
優先順位の高いリングかどうかについての決定が行われ
る（ステップ１０７２）。そのリングが最も優先順位の
高いリングの場合、ファイル記述２次元リスト１０８の
ポインタが完全かどうか、すなわち、ポインタを進める
要求が終了状態に戻っているかどうかについて決定がな
される。そうでない場合、ファイル記述２次元リスト１
０８に対するポインタが、後述するバッファ制御処理プ
ログラム１０２の適切な部分をコールすることにより進
められる（ステップ１０７６）。ポインタが完全でない
場合（ステップ１０７４）、または、ポインタがまだ進
められていない場合（ステップ１０７８）、ポインタの
全てが完全かどうかについての決定が行われ（ステップ
１０８２）、完全でない場合には、処理制御ルーチン３
９８に処理の制御が移行し、新しいデータのために待機
する（ステップ１０８４）。ポインタが進められている
場合１丁度完全にされたりストエントリのノードがファ
イルノードのときそのノードがメモリから除去され、デ
ィレクトリ内の全てのノード（ファイル）が除去される
ときディレクトリ用のノードが除去されるが、その理由
は、全てのファイルが除去されるまで、ディレクトリノ
ードがデータ構造内の親（元）となる要素を介して参照
されるようになっているからである。このことはマルチ
ポインタリストからノードを除去するために必要な従来
から知られているポインタ除去動作を含んでいるが、前
のノードから前進しているポインタが後ろのノードに対
するポインタに変換され、新しいノードを割りつけるた
めにメモリを自由にするとともに、後ろのノードからの
後のポインタが前のノードに対するポインタに変換され
る。

前に述べた処理がバッファ制御処理プログラム１０２を
コールしてファイル記述２次元リスト１０８用のポイン
タを定義するとき、第３８図に示した処理１０９８が行
われる。まずルーチン１１００がポインタを最低位の優
先順位に設定するがこのポインタは最も最近利用された
ことを示している。そのコールが順序に従ってポインタ
が移動されるべきことを要求している場合（ステップ１
１０２）、比較のための他のポインタが存在するかどう
かについての決定が行われる（ステップ１１０４）。た
とえば、ノード除去ポインタは。

他の全てのポインタがあるノードについての動作が完了
するまで、そのノードに対して移動させることができな
い。そのノード除去ポインタは、バッファ制御処理プロ
グラム１０２が最も優先順位の高い処理番号を持ってい
るにも係わらず、それは最も低い優先順位であるから、
全てのポインタと比較されなければならない。しかしな
がら、ソースサーチポインタは、比較される必要がない
可変移動形ポインタである。ステップ１１０４における
決定が肯定的な場合、同じ順序でファイル記述２次元リ
スト１０８を通して移動するポインタを列挙している。

可変移動用またはディレクトリ牽制用サブリストが発見
されているかどうかについての決定が行われる（ステッ
プ１１０６）、リストが発見されると、ポインタが同じ
順序で移動しているか否かについての決定が行われる（
ステップ１１０８）。ポインタが同じ順序で移動してい
る場合、そのポインタが比較されべきポインタよりも優
先順位が高いかどうかについての決定が行われ（ステッ
プ１１１０）、続けて、優先順位の低いポインタが進め
られていないかどうかの確認がされ（ステップ１１１２
）、比較されたポインタの優先順位にその優先順位が切
り換えられる（ステップ１１１４）、もし決定ステップ
１１０２．１１０４．１１０８および１１１０のいずれ
かが否定的な結果の場合、ポインタ定義がステ・ンブ１
１１６において充満させられ、優先順位リスト内のポイ
ンタの順序が割りつけられ、そうでない場合は処理プロ
グラムはループバックしてポインタのための優先順位の
位置を探す処理を継続する。

第３９図は他の処理によってコールされるときはいつで
もファイル記述リストポインタを進めるバッファ制御処
理プログラム１０２内で行われる処理１１２２８を示し
ている。この処理の第１のステップにおいて、最も優先
順位の高いポインタについてのインデックスが入手され
（ステップ１１３０）、それから、ノードが入手される
が（ステップ１１３２）、そのノードには最も優先順位
の高いポインタが配置されている。次の処理１１３４に
おいて、入力ポインタ（進められるべきポインタ）のた
めのリスト内にある次のノードが入手され、それから、
そのポインタがリスト１０８の最後のものであるか否か
についての決定が行われる（ステップ１１３６）。その
ホストが最後のポインタである場合、ポインタを進める
処理が終了状態で復帰する（ステップ１ｉ３４）。ポイ
ンタが最後のリスト１０８内の最後のポインタではない
場合、新しいノードがレディ状態であるか否かについて
の決定が行われる（ステップ１１４０）。新しいノード
がレディ状態でない場合、ポインタは待機状態にセット
され（ステップ１１４２）、待機状態をコールする処理
への復帰が行われる。新しいノードがレディ状態の場合
、そのノードが高い優先順位のノードと同じであるかど
うかについての決定が行われ（ステップ１１４６）。

すなわち、そのノードが新しいノードを指定する高い優
先順位のポインタであるかどうかについての決定が行わ
れ、その場合には、より高い優先順位のポインタが待機
状態にあるかどうかについての決定が行われる（ステッ
プ１１４８）。待機状態にある場合には、そのノードが
分類されていることを示すノードのための分類されたマ
ーカー（ｍａｋｅｒ）が分類されたポインタによって通
過させられているかどうかについての決定が行われる（
ステップ１１５０）。このマーカーはバッファ制御処理
プログラム１０２によって維持されている内部的に可変
の値を持つ、そのマーカーは、ソースサーチおよびファ
イルルックアップがあるブイレフ斗りのための全てのエ
ントリが挿入されているとき、進められる。その場合に
は、ポインタが待機状前になり、復帰される。そうでな
い場合には、ポインタが新しいノードに対して進められ
（ステップ１１５２）、そのノードがそのポインタにつ
いて正しい形式のものであるかどうかについての決定が
行われる（ステップ１１５４）。たとえば、ポインタが
ファイル記述２次元リスト１０８のディレクトリエント
リを指定しているだけであり、ノードがデータファイル
エントリノードの場合、そのノード１５８は正しくない
。ノードが正しいノードでない場合、正しい高いノード
が発見されまで、上述したように、各ノードについてノ
ードのチエツクが継続される。しかしながら、ポインタ
が待機状態にあるより高い優先順位を持ったノートを指
定している場合そのポインタは進められない。たとえば
、バンファ制御除去ポインタは、依然として参照される
べきノードを除去しているので、待機状態にあるポイン
タが待機状態を過ぎても進められない。ポインタを指定
している時点において、待機状態がクリアされ（ステッ
プ１１５６）、新しいノードのインデックスによっで復
帰する （ステップ１ １５８） （以下余白） 新しいノードがファイル記述２次元（ＦＤ２）リスト１
０Ｂに挿入される必要があるときはいつでも、バンファ
制御処理プログラム１０２内の一部の処理である第４０
図に示した処理１２１８がコールされる。この処理の最
初において、新しいノードが続いているファイル記述２
次元リスト１０８からノードが人手される（ステップ１
２２０）。これは、ノードポインタ番号を入手し、フィ
ールド２１１からアドレスを人手し、そのアドレスのあ
とに挿入することを意味している。続けられるノードが
決定された後、ノードおよび名称用のメモリ、および、
バスフィールドが割りつけられ（ステップ１２２２）、
続いて、ディレクトリ作成およびソースディレクトリ階
層化順序内のファイル記述２次元リス）１０８内にノー
ドが挿入される（ステップ１２２４）。新しいノードが
ファイルノードの場合（ステップ１２２６）、　このフ
ァイルが親ディレクトリ内の最初のファイルであるか否
かについて決定処理が行われ（ステップ１２２８）、そ
うである場合、親ファイルポインタが新しいノードにセ
ットされるが（ステップ１２３０）、そうでない場合に
は、そのファイルはファイルリストの最後に加えられる
（ステップ１２３２）、新しいノードがディレクトリノ
ードである場合、このノードが親ディレクトリ内の最初
のノードであるか否かについての決定処理が行われ（ス
テップ１２３４）、そうであれば、親のサブデイレクト
リポインタが新しいノー１′にセットされ（ステップ１
２３６）、そうでない場合には、新しいノードはディレ
クトリのファイル記述２次元リスト１０８に加えられる
（ステップ１２３８）。次に、従来から知られている技
法を用いて残っているディレクトリ構造ポインタがセッ
トされ（ステップ１２４０）、続いて、知られているデ
ータフィールドを充満させ（ステップ１２４２）、第３
９図のポインタを進める処理１１２８をコールしてポイ
ンタを新しいノードに対して進める（ステップ１２４６
）。

処理がバッファ制御処理プログラム１０２をコールして
リングポインタを定義するとき、第４１図に示した処理
１１６８が実施される。この処理１１６８は第３８図の
ファイル記述ポインタを定義する処理１０９８と非常に
類似しており、ポインタを最も優先順位の低いものにセ
ットする処理１１７０から開始する。第３８図を参照し
て述べたと同じ比較処理が、規定を要求するポインタが
リング規定情報が完了する（ステップ１１８４）時点に
おいて発見されるまで、リングポインタのアレーを用い
るリングポインタを参照して行われる。

第４２図に示したリングポインタを進める処理１１８８
は、リングの最後には遭遇しないことを除いて、ファイ
ル記述２次元リスト１０８のポインタを進める処理と実
質的に同じである。この処理は入力ポインタが最後のイ
クステントにあるか否かについての決定処理１１９０で
始まり、そうであれば、処理は復帰する（ステ・ンブ１
１９２）。そうでなければ、リングポインタ用の次のイ
クステントが入手され、続けて、ポインタのリング番号
処理が続けられる。ポインタが続いており。

人力ポインタが同じイクステントにあるとき（ステップ
１１９８）、ポインタは待機状態にセットされ（ステッ
プ１２００）、待機状態になる（ステップ１２０２）。

ポインタが同じイクステントにない場合、ステップ１２
０４において１次のポインタがイクステントに続くポイ
ンタと同じであるか否かについての決定が行われる（ス
テップ１２０４）。もしそうであれば、続くポインタが
待機状態にあるか否かについての決定が行われる（ステ
ップ１２０６）。もし待機状態にない場合。

もう−度待機状態にさせられる。一方、待機状態にある
場合は１人カポインタが次のイクステントに対して更新
させられ（ステップ１２０８）、ポインタの待機状態が
クリアされ（ステップ１２１０）、新しいイクステント
のアドレスに復帰する（ステップ１２１２）。

特定的な例として１本発明が、　　　ｓｅｔ”で終わる
全てのディレクトリトリーを複写し、それらのディレク
トリの他のものとして、ＤＯＳディスクを保持している
一方のディスクドライブから■ＭＳディスクを保持して
いる他方のディスクドライブへの全てのファイル（“”
（＊’）を複写するために用いられるとき、挿入される
コマンドはは次のものである。

ｂｙｐａｓｓ　　ｃｏｐｙ　　ａ：＼本ｓｅＬ＼７１．
　　＼Ｉｌ＋０本ｅ：＼０．。

このコマンドは、マシンとしてＩＢＭ　　ＰＣなどのマ
シンが用いられたとき、ＤＯＳオペレーティングシステ
ムにＶＭＳブロック１１０に対するＤＯＳブロックＩ１
０を転送させる。この例示において、我々は、ソースお
よびディストネーションディストネーションのディレク
トリが下記のようになっていると仮定している。

占のソース−・　２ Ｄｏｓ　　　Ｒｏｏｔ　　　Ｄｉｒ： １１０、ＳＹＳ ＭＳＤＯ３，ＳＹＳ ＣＯＭＭＡＮＤ、　　ＣＯＭ ＤＩＳＫ、　　ＶＯＬ ＣＯＬＯＲ３ＥＴ Ｓ　Ｗ　Ａ　Ｐ　Ｅ　Ｓ　Ｅ　Ｔ ＴＥＸＴＳＥＴ Ｃｏｌｏｒｓｅｔ　　　Ｄｉｒ： Ｂｌｕｅ、　　ｔｘｔ Ｇｒｅｅｎ、　　ｔｘｔ Ｒｅｄ、　　ｊｘｔ Ｓｈａ　　　ｅｓｅｔ　　　Ｄｉｒ： Ｃ１ｒｃｌｅ、　ｔｘｔ Ｓｑｕａｒｅ、　　ｔｘｔ Ｔｒｉａｎｇｌｅ、　　ｔｘｔ Ｔｅｓｔｓｅｔ　　　Ｄｉｒ： Ｔｅ５ｔｌ、　　ｔｘｔ Ｔｅｓｔ２．　　ｔｘｔ 占にお番る一゛ ス ーショアー゛ レクトリ ○○Ｏ○○○、ｄｉｒ ｂａｃｋｕｐ、　　５ｙｓ ｂａｄｂｌｋ、　Ｓ　ｙｓ ｂａｄｌｏｇ、　　ｓｙｓ ｂｉｔｍａｐ、　　５ｙｓ ｃｏｎｔｉ、　　ｓｙｓ ｃｏｒｉｍｉｇ、　　５ｙｓ ｉｎｄｅｘｆ、　　ｓｙｓ ｋｉｎｇ、　　ｄｉｒ ＶＯＩＳｅｔ、　　Ｓ）’Ｓ ｗｈｆｓｌｕ、ｄｉｒ ディストネーションデータリング内の最初のイクステン
トが書き込まれる時点において処理が停止されるとき３
種々のデータ構造および協働するポインタが第４３図〜
第４８図に示される。すなわち、第４３図〜第４８図は
転送によって分離される本発明のデータ構造についての
内容のスナップショトを提供している。第４３図に示す
ようにスナップショトの時点において、ソースデータリ
ング１１２はグリーンテキスト（”ｇｒｅｅｎ　ｔｅｘ
ｔ”）内容、レッドテキスト（”ｒｅｄ　ｔｅｘｔ”）
内容、ブルーテキスト（”ｂｌｕｅ　ｔｅｘｔ’）内容
およびサークルテキスト（ｃｉｒｃｌｅ　ｔｅｘｔ”）
内容で埋められる。ＩＩ　ｔｅ　ｓ　ｔ　１　”および
°“ｔｅｓｔ２”の内容はまだ読み込まれていない。翻
訳処理プログラム１１４は、ディストネーションデータ
・リング１１６に示したソースデータリングの内容につ
いての翻訳処理を完了している。ソースディレクトリ・
リング２７５は依然として、　　　ｃｏｆｏｒ　　ｓｅ
ｔ”ディレクトリ、および、　　　５ｈａｐｅ　　ｓｅ
ｔ”ディレクトリのためのディレクトリ内容を有してい
る。しかしながら、　°″ｔｅｓｔ　　ｓｅｔ″ディレ
クトリの内容はまだソースディレクトリ・リング２７５
には転送されていない。ソースディスク２７０がブロッ
クＩ　１０　Ｄ　ＯＳソースディスクなので、ソースロ
ケーションウィンドー２７６は隣接するウィンドー内に
ＤＯ３のためのファイルアロケーションテーブルを有し
ている。ディストネーシゴンＤＩＲ−ＩＮリング２９４
内のディストネーションディレクトリは依然として、デ
ィストネーションディレクトリ・ルート、および、　　
　Ｃ０ｆｏｒ　　ｓｅｔ”ディレクトリおよび”　ｓ　
ｈ　ａ　ｐｅ　　ｓｅｔ″ディレクトリの空内容を有し
ている。ディストネーションＤ　Ｉ　Ｒ−ＯＵＴリング
２９６は、第４７図に図解されている合併したルートデ
ィレクトリ内容および合併した’ｃｏｆｏｒｓｅｔ”デ
ィレクトリ内容を有している。ディストネーションディ
スク３０４がＶＭＳであるから、ディストネーション・
ロケーション・ウィンドー２９０はヘッダ１〜４，４５
０〜４５３および４５４〜４５７を有しており、ヘッダ
制御リスト（ＨＣＬ）ウィンドー２９２は隣接している
ＶＭＳビットマツプを有しており、アロケーション制御
ウィンドーはブロックｌ〜７８および７８〜１５６のビ
ットを有している。

第４４図にディレクトリ作成ポインタに関連づけたスナ
ップショト時点におけるファイル記述２次元リスト１０
８が示されている。両方向に矢印がつけられて示されて
いるディレクトリ作成ポインタは順序を占めており、こ
の順序に従って。

ｔｅｘｔ　　ｓｅｔ″ディレクトリのファイルがまだフ
ァイル記述２次元リスト１０Ｂに加えられていないこと
を示している疑問符によってディレクトリが作成される
。このファイル記述２次元リスト１０８内において、バ
ッファ制御除去ポインタ１２６０がルートディレクトリ
１２６２を指定していることを示している待機状態にあ
る。ヘッダ形成デイレクトリポインタ１２６４が“’ｃ
ｏｌ。

ｒ　　ｓｅｔ″ディレクトリを指定している。　　５ｈ
ａｐｅ　　ｓｅｔ”ディレクトリエントリノード１２６
日が待機状態にあるディストネーション・ロケーション
・ディレクトリ・ポインタ１２７０、アウェーテングデ
ータであるブロックライトデイレクトリポインタ１２７
４．待機状態にあるディレクトリ作成ポインタ１２７６
によって指定されている。ファイル記述２次元リスト１
０８内の”ｔｅｘｔ　　ｓｅｔ”ディレクトリエントリ
１２７８が、ソースディレクトリ・リング２７５に空き
ルームを待っているブロックリードディレクトリポイン
タ１２７９によって指定される。　　ｒｅｄ　　ｔｅｘ
ｔ”エントリ１２７４が、待機状態にあるファイルのた
めのヘッダブロックポインタ１２８６、および、また待
機状態にあるファイルのためのブロックライトポインタ
１２８８によって指定される。　　ｃｉｒｃｌｅ　　ｔ
ｅｘｔ”エントリ１２９０が、ともに待機状態にあるデ
ィレクトリ作成挿入ポインタ１２９２および翻訳ポイン
タ１２９４によって指し示される。　　５ｑｕａｒｅｔ
　ｅ　ｘ　ｔ　”が、ソースサーチ可変移動ポインタ１
２９８、および、ソースファイルデータ・リング１１２
にルームを待っているブロックリードファイルポインタ
１３００によって指し示される。

”ｔｒｉａｎｇｌｅ　　ｔｅｘｔ”エントリ１３０２が
、待機状態にあるソースロケーションポインタ１３０４
によって指し示される。

第４５図にはファイル記述２次元リスト１０８のソース
ディレクトリ階層次元が示されている。

この構造は、　　　ｒｏｏｔ”　１２６２を指定してい
る親ポインタ１３１０．ディレクトリエントリの前の前
進デイレクトリポインタ１３１２および後進デイレクト
リポインタ１３１４．　　ファイルポインタ１３１６．
前進ファイルポインタ１３１８および後進ファイルポイ
ンタ１３２０．　　ファイル親ポインタ１３２２．およ
び、サブデイレクトリポインタ１３２４を有している。

第４６図にはディストネーションデータ・リング１１６
の内容が示されている。ディストネーションポインタ２
２５がバッファセグメント２２０を有しており、このバ
ッファセグメントは利用可能なスペースと割りつけられ
ている１つのバッファセグメント２２２とを有している
。このディストネーションデータ・リング１１６に用い
るポインタの数は３であり、最も優先順位の高いポイン
タは翻訳ポインタ１２９４である。削りつけられた２つ
のバッファセグメントは８にバイトの大きさを有してお
り、ディストネーションデータ・リング１１６は１０個
のイクステント（ｅｘｔｌ　〜ｅｘｔｌＯ）を有してい
る。イクステント１〜５　（ｅｘｔｌ〜ｅｘｔ５）　は
、　　”　ｂ　Ｉ　ｕ　ｅ　　ｔ　ｅ　ｘ　ｔ　”　　
　　ｒ　ｅ　ｄ　　ｔｅｘｔ”、　　　ｇｒｅｅｎ　　
ｔｅｘｔ″の第１および第２の半分、および、　　　ｃ
ｉｒｃｌｅ　　ｔｅｘｔ”のためのロケ−シラン情報を
有している。翻訳ポインタ１２９４はイクステント６　
（ｅｘ　ｔ６）において空白としてデータを待っている
ことを示しており、イクステント５　（ｅｘｔ５）にお
いて、ファイルのブロックライトおよびバッファ制御ポ
インタが“ｃｉｒｃｌｅ　　ｔｅｘｔ”のためのもので
ある。

第４７図に示したように、スナップショツト時点におけ
るディストネーション・ロケーション・ウィンドー２９
０は、ディストネーシジンディスク３０４に存在するデ
ィストネーションディスクファイルおよびｃｏｌｏｒ　
　ｓｅｔ”ディレクトリ用のヘッダ、ｂｌｕｅ　　ｔ、
ｅｘｔ”ディレクトリ、　　　ｇｒｅｅｎ　　ｔｅｘｔ
”ディレクトリ、および、　　　ｒｅｄ　　ｔｅｘｔ”
ディレクトリを有している。バッファも初期化されてい
ないヘッダのためのスペースおよびまだ割り付けされて
いないヘッダを有している。

第４８図にはディストネーション・デイレクトリアウド
（Ｄ　Ｉ　Ｒ−ＯＵＴ）リング２９６の内容が示されて
いる。この内容はディストネーションディレクトリ作成
処理プログラム２８２によってディレクトリがアルファ
ベットの順序で分類されていることを示している。ヘッ
ダの番号が各ディレクトリについて割りつけられており
９ヘツダ制御リストウインドー２９２の対応するビット
がそのヘッダが割りつけられていることを示すためにセ
ットされている。

ＶＭＳにおいて読み込み処理および書き込み処理が行わ
れているとき、各ブロックの大きさは５１２バイトであ
るが、ＤＯ３においては各ブロックの大きさは８にバイ
トである。本発明で行われる絶対的な読み込み処理およ
び書き込み処理は。

転送システム３６が何を要求しているかということから
何のディスクフォーマットを要求しているかということ
までの希望するディスクフォーマットについて適切な翻
訳処理を行う。たとえば、ディストネーションデータ・
リング１１６の内の最初のイクステントについてのブロ
ック書き込みがディストネーションディスク３０４に行
われているとき、第４９図において斜線で示したディス
クブロックの内容は“ｂｌｕｅ　　ｔｅｘｔ”ファイル
の内容を有している。目標のディスクのブロックの大き
さは５１２バイトであり、目標のＩ１０ブロックの大き
さは８にバイトである。“’ｂｌｕｅ　　ｔｅｘｔ″゛
ファイルは４にバイトであるからＶＭＳにおイテは、ブ
ロック１０３３３〜１０３４０が割りつけられる。ブロ
ックの比率は８に１５１２または１６である。ディスト
ネーションディスク３０４に°’ｂｌｕｅ　　ｔｅｘｔ
”を書き込む処理は、ディストネーションディスク３０
４からバッファにＤＯＳブロック６４５〜６４６を読み
出す処理、ＤＯＳブロック６４５バッファの最後に”　
ｂ　Ｉ　ｕ　ｅ　　ｔ　ｅ　ｘ　ｔ　”を複写し、ＤＯ
Ｓブロック６４６の最初に“ｂｌｕｅ　　ｔｅｘｔ”の
最後の２５６０ビツトを複写する処理、および、ディス
トネーションディスク３０４にブロック１０３３３〜１
０３４０を書き込む処理を含んでいる。

選択的なファイル翻訳能力を提供するために。

各ファイルノードがソースファイル・ルックアップ処理
プログラム１０４またはソースディレクトリ・サーチ処
理プログラム２８０によってファイル記述２次元リスト
１０８内に生成されるとき。

ユーザーがユーザーインターツース処理プログラム１０
０に対応して指定することにより、どのファイルが翻訳
を要求するかを特定することができる。このため、ファ
イルノードが生成されるいずれかの時に、ユーザーイン
ターツース処理プログラム１００をコールして、ユーザ
ーインターツース処理プログラム１００が簡単な質問メ
ツセージ「ファイル名称を翻訳すべきか？　（Ｓｈｏｕ
ｌｄ″ｆｉｌｅｎａｍｅ’　ｂｅ　ｔｒａｎｓｌａｔｅ
ｄ？）　」を出力して問い合わせる。このコールからの
復帰情報は、ファイル記述２次元リストｌＯ８の対応す
るノードの翻訳フィールドに記憶されているｙｅｓ”ま
たは“ｎ。

パのメツセージとなる。翻訳処理プログラム１１４はフ
ラグを検査し、フラグが問い合わせに対して“ｙｅｓ”
状態にセットされている場合には上述したように翻訳処
理を行い、そうでない場合には、翻訳処理を行わずにソ
ースファイルデータ・リング１１２からディストネーシ
ョンデータ・リング１１６にファイルが移動させる。

ＤＩＲコマンドはリード処理プログラム、特にファイル
記述２次元リスト１０８にディレクトリおよびファイル
エントリノードを生成するディレクトリリード処理プロ
グラムを起動する。ソースディレクトリ・サーチ処理プ
ログラム２８０がファイル記述２次元リスト１０８にエ
ントリを生成するとき、エントリファイル名称がそのフ
ァイルのためのディレクトリパスによってユーザースク
リーンに再び映し出される。

ユーザーによって挿入されたとき、復習のためにユーザ
ースクリーンにファイルを書き込むためのＴＹＰＥコマ
ンドもまた。リード処理プログラム、特に、ソースブロ
ックリード処理プログラム２７４を起動する。ファイル
内容がソースファイルデータ・リング１１２に置かれる
べきとき、ソースブロックリード処理プログラム２７４
は入力バッファの内容をユーザースクリーンに映し出す
。この場合、ディスクが異種のファイルフォーマットデ
ィスクのときには、ファイルの内容を元々のオペレーテ
ィングシステムのフォーマットに翻訳しない。翻訳した
ファイルをユーザースクリーンに転送するため、ディス
トネーションファイルライト処理プログラム１２０は、
リード処理プログラムに加えて翻訳処理プログラム１１
４およびディストネーションファイルライト処理プログ
ラム１２０の起動を要求する翻訳処理プログラムによる
翻訳の後、ディストネーションデータ・リング１１６か
らのファイルをユーザースクリーンに書き込む。

本発明の種々の特徴および利点が上記記述から明瞭であ
り、その結果として１本発明の真の技術的思想および範
囲にある本発明のそのような特徴および利点の全てが添
付の請求の範囲の記載事項によって包囲されることが意
図されている。さらに２種々の変形態様および改変が当
業者によって容易になされ９図解し記述した明確な構成
および動作にだけに本発明が限定されるものではなく。

本発明の全ての変形形態および均等なものが本発明の範
囲に含まれるということについて訴追されるであろう。

たとえば１本発明は全ての処理を行う単一のプロセッサ
に関連づけて記述している。

第３７図は複数の動作のある処理動作は、もし共通メモ
リにアクセスするマルチプロセッサが利用可能ならば、
並列に行われ得ることが図解している。他の動作および
処理が、並列処理が可能な分野における当業者によって
認識され得る。

〔発明の効果〕

以上に述べたように１本発明によれば、ホストコンピュ
ータのオペレーティングシステムとは異なるオペレーテ
ィングシステムに適したファイルフォーマットを有する
ディスクに対してユーザーがアクセスでき、修飾でき、
ホストコンピュータ側で修飾したファイルを異種のファ
イルフォーマットディスクに戻し、ユーザーがそのディ
スクでファイルフォーマットを作成できる。簡便なファ
イル転送方法および装置が提供できる。

【図面の簡単な説明】

第１図は従来の異なるファイルフォーマット内のディス
クファイル用の転送方法を図解する図であり。 第２図は本発明の動作を図解する図であり。 第３図は本発明のグローバルな動作記述データ構造６０
の内容を図解する図であり。 第４図は本発明の処理実行、および、ファイル入出力（
１／○）転送に対するファイルＩ１０のためのデータの
流れを図解する図であり。 第５図は本発明の例示的な階層ディレクトリ構造を示す
図であり１ 第６図は第５図に示したファイル記述２次元（ＦＤ２）
リスト１０８の構造を図解する図であり第７図は第５図
に示したファイル記述２次元（ＦＤ２）リスト１０Ｂ内
の構造のためのディレクトリ作成順序を図解する図であ
り 第８図は第５図のファイル記述２次元リスト１０８の各
リストノー１’１５８の内容を図解する図であり。 第９Ａ図〜第９Ｄ図は第５図のファイル記述２次元リス
ト１０８の各リストノード１５８内のフィールドの内容
を示す図であって、第９Ａ図は第９Ｂ図〜第９Ｄ図の全
体を示す図、第９Ｂ図はＶＭＳエントリの構成を示す図
、第９Ｃ図はＤＯＳエントリの構成を示す図、第９Ｄ図
は次のシステムエントリを示す図であり。 第１０Ａ図および第１０Ｂ図は第５図のファイル記述２
次元リスト１０８の各リストノード１５８内のフィール
ドの内容を示す図であって、第１０Ａ図はディスク・ロ
ケーション・フィールド１７６を示す図、第１０Ｂ図は
ブロックロケーション・レコード２０４を示す図であり
。 第１１図は第５図のファイル記述リスト１０８の各ノー
ド１５８に対する各ポインタのためのポインタ定義を図
解する図であり。 第１２図は本発明に用いるリングの内容を図解する図で
あり。 第１３図は本発明のリングポインタの定義を示す図であ
り。 第１４図はブロックｒ１０転送に対するブロックＩ１０
を図解する図であり 第１５図はウィンドーバッファを図解する図であり。 第１６図および第１７図はデータの流れとファイルＩ１
０およびブロックＩ１０転送の組合せについての処理実
行を示す図であり。 第１８図は処理実行順序を制御する処理制御ルーチン３
９８のフローチャートであり。 第１９図はユーザーインターツース処理プログラム１０
０のフローチャートであり。 第２０図はソースデイレクトリサーチ処理プログラム２
８０のフローチャートであり。 第２１図はソースロケーシジン処理プログラム２７８お
よびディストネーションロケーション処理プログラム２
８４のフローチャートであり。 第２２図はブロックリード処理プログラム２７４を示す
フローチャートであり。 第２３図は第２２図のブロック５３４および５３８内の
ディレクトリとファイルの読みを示す図であり。 第２４図は第２２図のブロック５４２内のヘッダの読み
を示す図であり。 第２５図はファイル・ルックアップ処理プログラム１０
４のフローチャートであり２ 第２６図はファイルリード処理プログラム１１０を示す
フローチャートであり。 第２７図は翻訳処理プログラム１１４の動作を図解する
フローチャートであり。 第２８図はディレクトリ作成処理プログラム２８２の流
れを示すフローチャートであり。 第２９図は第２８図の合併分類処理動作を図解する図で
あり。 第３０図は第２８図の合併・非分類処理動作プログラム
７８０の流れを示す図であり。 第３１図はヘッダ作成処理プログラム２８６のフローチ
ャートであり。 第３２図はブロックライト処理プログラム３００のフロ
ーチャートであり、 第３３図は第３２図におけるファイルまたはディレクト
リのブロック書き込み段階（ステップ）９２４または９
４０を示す図であり。 第３４図は第３２図のウィンドー書き込み段階９２８の
流れを示す図であり。 第３５図はディレクトリ作成処理プログラムｌ１８のフ
ローチャートであり。 第３６図はファイルライト処理プログラム１２０を示す
図であり。 第３７図は第１８図のプロセス制御ルーチン３９８によ
ってコールされるバッファ制御処理プログラム１０２の
一部を図解する図であり。 第３８図はバッファ制御処理プログラム１０２のファイ
ル記述ポインタの定義動作を図解する図であり。 第３９図はバッファ制御処理プログラム１０２のファイ
ル記述ポインタを進める処理１１２８を示す図であり。 第４０図はファイル記述２次元リスト内のノードのため
の挿入動作１２１８を図解する図であり第４１図はバッ
ファ制御処理プログラム１０２のリングポインタの定義
処理１１６８のフローチャートであり。 第４２図はバッファ制御プログラム１０２によって遂１
テされるリングポインタを進める処理１１８８を図解す
る図であり。 第４３図は転送スナップショットの間のリングの全体内
容を図解する図であり。 第４４図はスナップショットにおけるディレクトリ作成
の関連から明らかなファイル記述２次元リスト１０８の
内容を示す図であり２ 第４５図はソースディレクトリ構造階層順序内のファイ
ル記述２次元リスト１０Ｂを示す図であり。 第４６図はスナップショットにおけるディストネーショ
ンデータ・リング１１６の内容を示す図であり。 第４７図はディストネーションウィンドー２９０の内容
のスナップショットを示す図であり。 第４８図はディストネーションディレクトリ・アウト（
ＤＩＲ−ＯＵＴ）リング２９６の内容を示す図であり。 第４９図はディストネーションデータ・リング１１６に
ある第１の内容がディストネーションディスク３０４に
書き込まれる時のＤＯＳブロックとＶＭＳブロックとの
関係を図解する図である。 （以下余白） （符号の説明） １０・・・ホストディスクシステム。 １２・・・ホストコンピュータシステム。 １４・・・異種ディスクシステム。 １６・・・異種コンピュータシステム。 １８．２０・・・モデム。 ３０・・・ホストコンピュータ。 ３２・・・異種フォーマットディスク。 ３４・・・異種ディスクドライブ。 ３６・・・転送システム（バイパスアプリケーションプ
ログラム）。 ３８・・・ユーザー ４０・・・ホストフォーマットディスク。 ４２・・・ホストディスクドライブ。 ４４・・・ホストオペレーティングシステム ４６・・・ホストアプリケーションプログラム。 ６０・・・動作記述データ構造。 １００・・・ユーザーインターフェース処理プログラム
。 １０２・・・バッファ制御処理プログラム。 １０４・・・ソースファイル・ルックアップ処理プログ
ラム。 １０６・・・ソースディスク。 １０日・・・ファイル記述２次元（ＦＤ２）リスト。 １１０・・・ソースファイルリード処理プログラム。 １１２・・・ソースデータ・リング。 １１４・・・翻訳処理プログラム。 １１６・・・ディストネーションデータ・リング。 １１８・・・ディストネーシジンディレクトリ作成処理
プログラム。 １２０・・・ディストネーシッンファイルライト処理プ
ログラム。 １２２・・・ディストネーションディスク。 １５８・・・ファイル記述リストノード。 ２４２・・・イクステント（ＥＸＴＥＮＴ）２７４・・
・ソースブロックリード処理ルーチン。 ２７５・・・ソースディレクトリ・リング。 ２７６・・・ソースロケーションウィンドー２７８・・
−ノースロケーション処理ルーチン ２８０・・・ソースデイレクトリサーチ処理プログラム
。 ２８２・・・ディストネーション・ディレクトリ作成処
理プログラム。 ２８４・・・ディストネーションロケーション ２８６・・・ヘッダ作成処理プログラム。 ２９０・・・ディストネーション・ロケーション・ウィ
ンドー ２９２・・・ヘッダ制御リスト（ＨＣＬ）ウィンドー ２９４・・・ディストネーションＤＩＲ−ＩＮリング。 ２９６・・・ディストネーシゴンＤＩＲ−ＯＵＴリング
。 ２９８・・・アロケーション制御リスト（ＡＣＬ）ウィ
ンドー ３００・・・ディストネーションブロック・ライト処理
プログラム。 ３０２・・・ディスク情報。 ３０４・・・ディストネーションディスク。 ３０７・・・ディストネーションブロック・ライト処理
プログラム。 ３３０・・・ウィンド一定義。 ３９８・・・処理制御ルーチン。 ５３４・・・ソースディレクトリリードルーチン。 ５３８・・・ソースファイルリードルーチン５４２　・ ７７８　・ ７８０　・ ・・ブロックリード処理ルーチン。 ・・ディレクトリエントリ合併処理 ルーチン。 ・・未分類エントリの合併処理ルー ９２４　・ ９２８　・ ９３２　・ ９４０　　・ ９６２　・ ９７４　・ １１２８　・ ｌ　１８８　・ ｌ　２６２　・ １２６６　・ １２６８　・ １２７８　・ チン。 ・・ファイルブロック・ライトルー チン。 ・・ブロックライト・ウィンドー処 理ルーチン。 ・　・リードルーチン。 ・・デイレクトリブロック・ライト ルーチン。 ・・リングイクステントポインタを 進める処理ルーチン。 ・・ライトルーチン。 ・・ポインタを進める処理。 ・・リングポインタを進める処理。 ・・ルートディレクトリ。 ・・Ｃ０ＬＯＲ３ＥＴデイレクトリ エントリノード。 ・・５ＷＡＰＥＳＥＴデイレクトリ エントリノード。 ・・ＴＥＸＴＳＥＴデイレクトクリ エントリノード。 １２８０　・ １２８２　・ １２８４　・ １２９０　　・ １２９６　・ １３０２　　・ ・ＢＬＵＥ、ＴＸＴ。 ・ＧＲＥＥＮ、ＴＸＴ。 ・ＲＥＤ、ＴＸＴ。 ・ＣＩＲＣＬＥ、ＴＸＴ。 ・５ＱＵＡＲＥ、ＴＸＴ。 ・ＴＲＩＡＮＧＬＥ、ＴＸＴ。

Claims (1)

1. 【特許請求の範囲】 １、第１のファイルフォーマットを有するディスクから
   コンピュータを用いてファイルを読み出す段階、および
   、 第２のファイルフォーマットを有するファイルをコンピ
   ュータを用いて書き込む段階 を具備するファイル転送方法。 ２、前記ファイル読み出しは第１のディスクから行い、
   前記書き込みは第２のディスクに行う請求項１記載のフ
   ァイル転送方法。 ３、前記第１および第２のファイルフォーマットを特定
   するため、ユーザーに問い合わせる段階をさらに具備す
   る請求項２記載のファイル転送方法。 ４、前記読み出し段階は前記第１のディスクの、内容か
   ら前記第１のファイルフォーマットを決定する段階を具
   備し、 前記書き込み段階は前記第２のディスクの内容から前記
   第２のファイルフォーマットを決定する段階を具備する
   、請求項２記載のファイル転送方法。 ５、第１のディスクファイル内容をソースファイル内容
   リングに記憶する段階、 第１のディスクディレクトリ内容をソースディレクトリ
   ・リングに記憶する段階、 前記第１のディスクの第１のディレクトリ構造を秩序づ
   ける（ｃｏｏｒｄｉｎａｔｉｎｇ）第１の次元を有し、
   前記第２のディスクの第２のディレクトリ構造を秩序づ
   ける第２の次元を有する前記ディレクトリ内容から２次
   元リストを生成する段階、 ソースファイル内容リングの内容をディストネーション
   ファイル・リングに記憶する段階、および、 第２のディレクトリ内容をディストネーションディレク
   トリ・リングに記憶する段階 をさらに具備する請求項４記載のファイル転送方法。 ６、前記ディレクトリファイル内容ディレクトリと前記
   ソースファイル内容リングとは同じリングである請求項
   ５記載のファイル転送方法。 ７、ファイル用ヘッダおよび前記第２のディスク用ディ
   レクトリを生成する段階をさらに具備する請求項５記載
   のファイル転送方法。 ８、前記ソースファイル内容リングからファイル内容を
   前記ディストネーションファイル内容リングに移動させ
   翻訳する段階をさらに具備する請求項７記載のファイル
   転送方法。９、前記リングおよびリストにアクセスする
   ことを制御する段階をさらに具備する請求項８記載のフ
   ァイル転送方法。 １０、第１のディスクの内容から第１のファイルフォー
   マットを決定する段階、 第２のディスクの内容から第２のファイルフォーマット
   を決定する段階、 前記第１のファイルフォーマットを有する前記第１のデ
   ィスクからコンピュータを用いてファイルを読み出す段
   階、 第１のファイルディスク内容をソースディストネーショ
   ン・リングに記憶する段階、 第１のディスクディレクトリ内容をソースファイル内容
   リングに記憶する段階、 前記第１のディスクの第１のディレクトリ構造を秩序づ
   ける第１の次元を有し、前記第２のディスクの第２のデ
   ィレクトリ構造を秩序づける第２の次元を有するディレ
   クトリ内容から２次元リストを生成する段階、 前記ファイル内容のための第２のディレクトリ内容を前
   記第２のディレクトリ構造に基づいてディストネーショ
   ンディレクトリ・リングに記憶する段階、 前記ソースファイル内容リングの内容をディストネーシ
   ョンファイル内容リングに転送する段階前記ファイル用
   ヘッダおよび前記第２のディスク用のディレクトリを生
   成する段階、 ディストネーションフィールド内容リングからのファイ
   ル、および、ディストネーションディレクトリ・リング
   からのディレクトリを前記と同じコンピュータを用いて
   第２のファイルフォーマットを有する前記第２のディス
   クに書き込む段階、および、 前記リングおよびリストへのアクセスを制御する段階 を具備するファイル転送方法。 １１、ディスクドライブ、および、 該ディスクドライブに接続され、第１のファイルフォー
   マットから第２のファイルフォーマットにファイルを転
   送するための転送手段 を具備するファイル転送装置。 １２、前記転送手段が、 第１のディスクの内容から前記第１のファイルフォーマ
   ットを決定する手段、および、 第２の内容から前記第２のファイルフォーマットを決定
   する手段 を具備する請求項１１記載のファイル転送装置。 １３、前記転送手段が、 第１のディスクディレクトリ内容をソースディレクトリ
   ・リングに記憶する手段、 第１のファイル内容をソースファイル・リングに記憶す
   る手段、 前記第１のディスクの第１のディレクトリ構造を秩序づ
   ける第１の次元を有し、前記第２のディスクの第２のデ
   ィレクトリ構造を秩序づける第２の次元を有するディレ
   クトリ内容から２次元リストを生成する手段、 ディストネーションファイル内容リングとしてソースフ
   ァイル・リングの内容を指定する手段、および、 第２のディレクトリ内容をディストネーションディレク
   トリ・リングに記憶する手段 をさらに具備する請求項１２記載のファイル転送装置。 １４、前記転送手段がファイル用ヘッダおよび前記第２
   のディスクのディレクトリを生成する手段をさらに具備
   する請求項１３記載のファイル転送装置。 １５、前記転送装置がディストネーションファイル内容
   リングを有し、 前記転送手段が前記ソースファイル内容リングから前記
   ディストネーションファイル内容リングにファイル内容
   を移動させ翻訳する手段をさらに具備する請求項１４記
   載のファイル転送装置。 １６、前記転送手段が前記リングおよび前記リストにア
   クセスする制御する手段をさらに具備する請求項１５記
   載のファイル転送装置。 １７、前記転送手段が、 第１のディスクからファイルを読み出し、前記ファイル
   をソースディレクトリ・リングに記憶するソースファイ
   ル読み出し手段、 前記第１のディスクのファイルの位置を決定するソース
   ファイル・ルックアップ手段、 前記第１のディスクからブロックを読みだし、前記ファ
   イルを前記ソースデータ・リングに記憶し、ディレクト
   リをソースディレクトリ・リングに記憶するソースブロ
   ック読み出し手段、 前記ディスクのディレクトリの位置を決定するソースロ
   ケーション手段、 前記ソースディレクトリ・リングのディレクトリからフ
   ァイル記述リスト内のファイルおよびディレクトリエン
   トリを生成するソースディレクト・リサーチ手段、 前記ソースデータ・リング内の前記ファイルを翻訳し、
   前記ファイルをディストネーションデータ・リングに記
   憶する翻訳手段、 第２のディスクのディレクトリを位置づけるディストネ
   ーションディレクトリ・ロケーション手段、 ファイル用ヘッダ、および、前記ファイル記述リストに
   列挙されたディレクトリを組み立てるヘッダ作成手段、 前記ファイル記述リストのエントリおよび前記第２のデ
   ィスクのディレクトリからディレクトリを組立て、ディ
   レクトリをディストネーションディレクトリ・アウト・
   リングのディレクトリに記憶するディストネーションデ
   ィレクトリ作成手段ディレクトリデータ・リングからの
   ファイルおよび前記ディストネーションディレクトリ・
   アウト・リングからディレクトリ、および、ヘッダを前
   記ディスクに記憶するディストネーションブロック書き
   込み手段、 前記第２のディスクのディレクトリを生成するディスト
   ネーションディレクトリを生成する手段前記ディストネ
   ーションデータ・リングからファイルを前記ディスクに
   書き込むディストネーションファイル書き込み手段、 前記リストを制御し、および、前記リストにアクセスす
   ることを制御するバッファ制御手段、および、 前記各手段の実行順序を制御する処理制御手段を具備す
   る、請求項１１記載のファイル転送装置。 １８、前記処理制御手段が前記第１および第２のディス
   クに応答する手段を選択的に駆動する請求項１５記載の
   ファイル転送装置。 １９、ディレクトリ構造階層順序およびディレクトリ作
   成順序内のファイルおよびディレクトリエントリを記憶
   している２次元ファイル記述リストを具備するファイル
   転送装置のデータ構造。 ２０、前記リスト内にリスト化されたファイルを記憶し
   ているソースデータ・リング、 前記リスト内のリスト化されたソースディレクトリ・リ
   ング、および。 前記リストに列挙されたディレクトリ、および、ディス
   トネーションディスクからのディレクトリを記憶してい
   るディレクトリ・アウト・リングをさらに具備する請求
   項１９記載のデータ構造。 ２１、前記リストに列挙されたファイルを記憶するディ
   ストネーションデータ・リングをさらに具備する請求項
   ２０記載のデータ構造。 ２２、前記リスト内に列挙されたファイル用ロケーショ
   ン情報を記憶するディストネーションロケーションウイ
   ンドー、および、 前記リスト内にリスト化されたファイル、および、前記
   ディストネーションディスクからのファイル用のロケー
   ション情報を記憶するディストネーションロケーション
   ウインドーをさらに具備する請求項２１記載のデータ構
   造。 ２３、前記ディストネーションディスクに配置されたス
   ペースのインジケータを記憶するアロケーション制御リ
   スト・ウインドー、および、前記ディストネーションデ
   ィスクに配置されたインデックスのインジケータを記憶
   するインデックス制御リスト・ウインドー をさらに具備する請求項２２記載のデータ構造。 ２４、ソースディスク・ディレクトリ構造階層順序およ
   びディストネーションディスク・ディレクトリ作成順序
   におけるファイルおよびディレクトリエントリを記憶す
   る２次元ファイル記述リスト、 ソースディスクからの前記リスト内に列挙されたファイ
   ルを記憶するソースデータ・リング、前記ソースディス
   クから前記リスト内に列挙されたディレクトリを記憶す
   るソースディレクトリ・リング、 前記ソースデータリングの翻訳された内容を記憶するデ
   ィストネーションデータ・アウト・リング、 前記リスト内に列挙され、そして、ディストネーション
   データからディレクトリを記憶するディレクトリ・アウ
   ト・リング、 前記リスト内に列挙されたファイル用のソースディスク
   ロケーション情報を記憶するソースロケーション・ウイ
   ンドー、 前記リスト内に列挙されたファイル、および、前記ディ
   ストネーションディスクからのファイルのためのロケー
   ション情報を記憶するディストネーションロケーション
   情報、 前記ディストネーションディスクに配置されたスペース
   のインジケータを記憶するアロケーション制御リスト・
   ウインドー、および、 前記ディストネーションディスクに配置されたインデッ
   クスのインジケータを記憶するインデックス制御リスト
   ・ウインドー を具備する、ディスクファイル転送システム用データ構
   造。 ２５、第１のファイルフォーマットを有するディスクか
   らのフォーマットおよびディレクトリ名称を、第２のフ
   ァイルフォーマットを用いるオペレーティングシステム
   を実行するコンピュータを用いて、読み出し、表示する
   段階、を具備するフォーマット構造レビュー方法。 ２６、前記読み出し・表示段階が、前記ディスクからの
   ファイルまたはディレクトリ名称が得られたとき、ファ
   イル名称およびディレクトリパスをユーザースクリーン
   に再び戻す段階を有する請求項２５記載の方法。 ２７、コンピュータを用いて第１のファイルフォーマッ
   トを有するディスクからファイルを読み出す段階、およ
   び、 コンピュータを用いて第２のファイルフォーマットを有
   するファイルを表示する段階 を具備するファイル表示方法。 ２８、前記ファイル内容が表示の前に翻訳される請求項
   ２７記載の方法。