JP3175371B2 - データ記憶フォーマット変換方式及びその変換方法及びアクセス制御装置及びデータアクセス方法 - Google Patents

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】この発明は、たとえば、汎用計算
機の磁気ディスク装置で用いられている可変長レコード
方式を市販の小型ディスク装置で用いられている固定長
方式で実現するためのデータ記憶フォーマット変換方式
等に関する。

【０００２】

【従来の技術】従来、汎用計算機システムの外部記憶装
置としては、可変長レコード（ＣＫＤ；Ｃｏｕｎｔ Ｋ
ｅｙ Ｄａｔａ）方式の固定ディスク装置が広く用いら
れている。可変長レコード方式とは、磁気ディスク上の
１トラックに記録する物理的なレコードの長さも数も可
変である記録フォーマットである。一般的に可変長レコ
ード方式の磁気ディスクの１トラックは図３３に示すよ
うにインデックス・マークから始まり、まず最初にホー
ム・アドレス（ＨＡ）と引き続くレコード・ゼロ（Ｒ
０）が存在する。このＨＡとＲ０はそのトラックのシリ
ンダ・アドレスやヘッド・アドレスなどのアドレス情報
以外に、そのトラック上の磁気的な傷の位置や、不良ト
ラックであるか否かの情報、また、不良トラックであれ
ば、交代割り付けされている相手先のトラックのアドレ
ス等の制御情報を含んでいるため、必ず存在しなくては
ならない。このＨＡ、Ｒ０に引き続くレコード１（Ｒ
１）以降のレコードが通常のデータを記録するレコード
で、レコード１個１個の長さも個数もその総容量がトラ
ックに記録できる容量である限り、ホスト計算機上のソ
フトウェア（Ｓ／Ｗ）から自由にフォーマットして使用
することができる。各レコードは、カウント・フィール
ド（ＣＯＵＮＴ）、キー・フィールド（ＫＥＹ）、デー
タ・フィールド（ＤＡＴＡ）の３つのフィールドからな
りたっており、これらのフィールドの頭文字からＣＫＤ
方式と呼ばれる。カウント・フィールドの長さは固定
で、シリンダ・アドレス（ＣＣ）、ヘッド・アドレス
（ＨＨ）、レコード・ナンバ（Ｒ）などのアドレス情報
のほかに、そのレコードのキー・フィールドの長さ（Ｋ
Ｌ）、データ・フィールドの長さ（ＤＬ）などを含んで
いるので、引き続くキー・フィールド、データ・フィー
ルドの長さを自由に変えることができる。キー・フィー
ルド、データ・フィールドがそのレコードの実際のデー
タを記録する部分であるが、そのレコードのキーを記録
すべきキー・フィールドが不要な場合は、カウント・フ
ィールドでＫＬ＝０を指定することにより、キー・フィ
ールドの存在しないレコードを作ることもできる。Ｈ
Ａ、Ｒ０、Ｒ１、Ｒ２・・・などの間には、適当なサイ
ズのレコード間ギャップ（Ｇ１，Ｇ２，Ｇ３）が設けら
れており、特にＲ１，Ｒ２・・・などのレコードの前の
ギャップ（Ｇ３）には、アドレス・マーク（ＡＭ）と呼
ばれる磁気的に特別なマークが記録されているため、ト
ラック内のどの部分から読み始めても、このアドレス・
マークを検出することにより、レコードの読み始めを見
つけることができる。

【０００３】また、各レコードの内部でも各フィールド
を区別するためにそれぞれフィールド間ギャップ（Ｇ
２）が設けられている。これに対し、ミニコンピュー
タ、オフィスコンピュータ、パーソナルコンピュータ、
ワークステーションなどの比較的小規模な計算機システ
ムの外部記憶装置としては、固定長レコード（ＦＢＡ；
Ｆｉｘｅｄ Ｂｌｏｃｋ Ａｒｃｈｉｔｅｃｔｕｒｅ）
方式の固定ディスク装置が用いられている。固定長レコ
ード方式のディスクでは、通常一つのレコード（固定長
レコード方式のディスクではセクタと呼ばれることが多
い）はアドレス情報を記録しているＩＤフィールドとデ
ータを記録するデータ・フィールドからなりたってお
り、いずれのフィールドの長さも固定である。従って、
１トラックあたりのレコード数（セクタ数）も固定であ
る。

【０００４】従来は、可変長レコード方式の磁気ディス
クと固定長レコード方式の磁気ディスクは、対象とする
計算機システムによって上述のような使い分けが行われ
てきた。従って、固定長レコード方式のディスクは、対
象とするシステムが小さいことから、可変長レコード方
式のディスクに比べ、一般的に小型で記憶容量も小さ
く、データ転送速度、シーク速度などの性能も低かっ
た。しかし、近年、可変長レコード方式のディスクも小
型化に対する要求が著しく高くなってきたこと、逆に、
固定長レコード方式のディスクの方は、大容量化、高速
化が著しいことなどから、仕様面での両者の差異は小さ
くなってきた。これに対し、価格の方は可変長レコード
方式のディスクは汎用計算機専用であるため、パーソナ
ル・コンピュータからオフィス・コンピュータまで広く
使用される固定長レコード方式のディスクに比べ量産効
果に劣る。そのため、どうしても割高となり、両者のコ
スト・パフォーマンスのギャップが広がりつつある。こ
のため、汎用計算機でも安価で高性能な固定長レコード
方式のディスクを利用したいと言う要求が強まってい
る。

【０００５】また、ＣＫＤ方式の固定ディスク装置で
は、データを記録するデータ面と、ヘッドを位置決めす
るためのサーボ情報を記録するサーボ面を別々に設ける
サーボ面サーボ方式が用いられてきた。この方式では、
データ面とサーボ面の機械的な位置の精度によってヘッ
ドの位置決め精度も規定されてしまう。そこで、さらに
トラックの高密度化を図るため、データ面中のＩＤフィ
ールドなどにサーボ情報も書き込んでしまうデータ面サ
ーボ方式が用いられるようになってきた。このデータ面
サーボ方式を用いると、極端には、１トラック１レコー
ドも許される可変長レコード方式では常に一定間隔でサ
ーボ情報が得られるという保障はなく、必ず一定間隔で
サーボ情報が得られる固定長レコード方式に比べ、ヘッ
ドの位置決め精度に関して不利になる。さらに、ディス
ク1台1台の性能向上や信頼性向上には限界が有るため、
複数のディスクにデータを分散して記録したり、その分
散したデータ間のパリティなどを記録する冗長ディスク
を設けるなどして、性能・信頼性の向上をはかるディス
ク・アレイの技術が注目されているが、レコードの長さ
や個数が可変である可変長レコード方式のままでは、こ
のような技術に対応することも困難である。しかし、汎
用計算機の世界では膨大なソフトウェア資産がきづかれ
ているため、ディスクの記録フォーマットを可変長から
固定長に変更することは著しく困難である。

【０００６】ここで、図３４及び図３５を用いて従来の
可変長レコード方式で記録された可変長レコードへのア
クセス方式について述べる。図３４はサーボ面サーボ方
式が用いられている磁気ディスクを模式的に示す図であ
り、この磁気ディスク装置にはサーボ面Ｓとデータ面Ｄ
が設けられている。サーボ面Ｓにはセクタ（ＦＢＡ方式
のセクタとは異なる概念のセクタ）が論理的に設けられ
ている。図３５はこのセクタを説明するための図であ
る。ここで１トラックの記憶容量を４８ＫＢであるとす
るとこの１トラックは複数のセクタに分割される。ここ
では１セクタのサイズを２４４Ｂとする。この１セクタ
はさらにセグメントＳ１〜Ｓ７という７つのセグメント
から構成されている。１セクタのサイズが２４４Ｂであ
るので１セグメントは３２Ｂになる。このような磁気デ
ィスク装置を用いてデータ面Ｄにデータを記録する場合
には、データが記録されたセクタの値を記憶しておき、
そのデータを検索する場合には、データ面に書かれたと
きのセクタ値を用いて検索する。こうすることでそのデ
ータを高速に検索することが可能になる。図３６はセク
タ値を用いてデータを検索する場合のホストコンピュー
タで動作するソフトウェアからのアクセスシーケンスの
一例を示す図である。図３６に示すようにホストコンピ
ュータで動作するソフトウェアはアクセスしようとする
データが記録されているセクタをセットセクタコマンド
により指定する。このセットセクタコマンドにより磁気
ディスク装置は、ホスト計算機及び磁気ディスク制御装
置から切り離され、指定されたセクタを自律的に検索す
る。指定されたセクタを発見すると磁気ディスク装置
は、磁気ディスク制御装置を介し、ホスト計算機に再接
続要求を出し、再接続が行なわれる。次にサーチＩＤコ
マンドによりサーチすべきデータのＩＤが送られてく
る。このＩＤは、例えばシリンダ番号やトラック番号
や、あるいはサーチすべきレコード番号である。このサ
ーチＩＤコマンドを受け取ると磁気ディスク装置は、そ
のＩＤとセットセクタコマンドにより指定されたセクタ
から最初に存在するレコードのＩＤを比較し、その結果
をホスト計算機に報告する。両者のＩＤが一致していな
ければ、コマンドの実行は次のトランスファーインチャ
ネルコマンドにより、セットセクタコマンドにジャンプ
して戻され、次のレコードに対し、再度サーチＩＤコマ
ンドが発行される。両者のＩＤが一致していれば、ホス
ト計算機は次のトランスファーインチャネルコマンドを
とばし、最後のリードデータコマンドあるいはライトデ
ータコマンドを発行することにより、検索したデータに
対し、リードまたはライトという命令を実行する。

【０００７】このように汎用計算機で用いられるソフト
ウェアは既に可変長レコード方式に基づいて作成されて
おり、既に築かれたソフトウェアを変更するということ
は著しく困難である。そこで、実際のディスクは固定長
レコード方式のディスクを使用しながら、磁気ディスク
制御装置で可変長レコード方式をエミュレーションする
ことにより、ホスト計算機上のソフトウェアからは従来
どおりの可変長レコード方式のディスクを使用できる技
術が考えられている。

【０００８】ＣＫＤ−ＦＢＡ変換については「記憶制御
方法及び装置」（特開平１−３０６９１号公報）におい
て詳細に述べられている。また、ＣＫＤ−ＦＢＡ変換に
ついては、さらにＩＢＭ社の出版物「ＩＢＭ４３２１／
４３３１プロセッサ互換性機能」（ＧＡ３３−１５２
８、第３版、１９８２年９月）に一般的に記載されてい
る。これらの文献の内容をまとめると、下記のようにな
る。上記の出版物ではＣＫＤからＦＢＡに変換する際す
べてのギャップを取って圧縮している。また、上記の出
版物では図３６に示したセットセクタコマンドがサポー
トされていないことが記述されている。上記の出版物で
はセットセクタコマンドが出された場合には、ノーオペ
レーションになると記載されている。セットセクタコマ
ンドがサポートされていない場合には、サーチＩＤコマ
ンドからレコード検索を行うことになる。サーチＩＤコ
マンドのみによってもレコードを検索することができる
が、そのトラックの先頭から全てのレコードを順番に見
ながらサーチＩＤコマンドで指定されたＩＤと同じＩＤ
のレコードを検索するために検索時間がかかってしま
う。セットセクタコマンドはレコードが存在している身
近のセクタを指定するものであり、セットセクタコマン
ドで指定されたセクタ以後をサーチＩＤコマンドにより
サーチする場合に比べてアクセス時間の点で非常に不利
である。

【０００９】一方、上記公報では（カッコ内の番号は図
３７に対応）、 （１）フィルード間ギャップ（Ｇ２）やＥＣＣ、パディ
ング、物理的パラメータなどは取る。 （２）レコード間ギャップ（１３１，１３３，１３７，
１６３）は残す。 （３）（１）で取ったフィールド間ギャップなどの分
は、同じ分だけ（２）のレコード間ギャップを伸ばす。
これにより、トラックの先頭から各レコードのカウント
・フィールドまでの相対位置は元のまま維持される。
（キー・フィールドやデータ・フィールドの相対位置は
ずれることになるが、カウント・フィールドの相対位置
さえ分かれば、レコードの位置決めには差し支えな
い）。 （４）このトラック・データをＦＢＡの固定ブロック
（セクタ）に分割し、その際、各固定ブロックに含まれ
る最初のレコードのカウント・フィールドの位置情報
（１５６）を各固定ブロックの先頭に付加しておく。こ
れにより、ＦＢＡ方式のディスクに記憶されたＣＫＤレ
コードへの直接かつランダムなアドレッシングが可能に
なる。 （５）そのブロックにカウント・フィールドが含まれな
い場合は、それを示す標識ビットを記録しておく。 さらに整理すると、 （１）各レコードのカウント・フィルードの相対位置を
維持するためレコード間ギャップだけを残し、他の余分
なギャップなどは取り除く。 （２）ＦＢＡの各固定ブロックの先頭に、そこに記録さ
れている最初のカウント・フィールドの位置を示すヘッ
ダを付ける。 の２点が要件となって、こうすることによりＦＢＡ方式
のディスクに記録したＣＫＤレコードへの直接かつラン
ダムなアドレッシングを可能にする。

【００１０】

【発明が解決しようとする課題】しかしながら、上述し
た先行技術においては次の問題点がある。前述した出版
物による技術によればＣＫＤからＦＢＡに変換する際、
全てのギャップをとって圧縮しているがセットセクタコ
マンドがサポートされていないためにレコードのアクセ
スに長時間を要する。また、前述した公報に示された技
術においてはレコード間ギャップは削除するが、フィー
ルド間ギャップは残した上、削除したレコード間ギャッ
プの分だけフィールド間ギャップを伸ばすため、特に、
レコードサイズが小さくレコード数が多い場合、メモリ
上で無駄が増える。

【００１１】また、各ＦＢＡの固定ブロック(固定長レ
コード方式のレコード)に含まれるＣＫＤレコードのう
ち先頭のＣＫＤレコードの位置に関する情報しか持たな
いので、先頭以外のＣＫＤレコードを見つけるために
は、まず先頭のＣＫＤレコードのカウント・フィールド
を読んで、その中のＫＬ，ＤＬから先頭のレコード長を
知り、次のレコードのカウント・フィールドの位置を計
算してから、また、次のレコードのカウント・フィール
ドのＫＬ，ＤＬを読んで、また、その次のレコードのカ
ウント・フィールドを探すという手順を繰り返さなくて
はならない。従って、処理時間がかかるばかりでなく、
トラック・イメージがディスク・キャッシュ上などに集
中管理されている場合は、そのメモリへのアクセス回数
が著しく増え、システム全体の性能を低下させる。さら
に、ＣＫＤレコードの位置情報を各ＦＢＡブロック毎と
いう小さい単位に持つためチャネルとのデータ転送時、
この位置情報をとび越すためのデータ転送一時中断が頻
繁に発生し、データ転送効率の悪化を招く。

【００１２】この発明は、上述した従来例における問題
点を解消するためになされたもので、ＣＫＤレコードを
ＦＢＡレコードにフォーマット変換する際、目的とする
ＣＫＤレコードを発見するためのメモリアクセス回数が
少なくてすみメモリ負荷軽減がなされると共に、トラッ
クデータを保持するためのメモリ容量が少なくてすむレ
コード記憶フォーマット変換方式を得ることを目的とす
る。

【００１３】

【課題を解決するための手段】この発明に係るデータ記
憶フォーマット変換方式は、汎用計算機システムの外部
記憶装置に用いられる記憶フォーマットである可変長レ
コードの１トラックからレコード間ギャップ及びフィー
ルド間ギャップ等全てのギャップを削除し、そのトラッ
クデータを固定長レコードの固定長ブロックサイズの整
数倍に相当する管理単位に分割し、その管理単位に含ま
れる全ての可変長レコードの位置を示すアドレス情報と
各可変長レコードの可変長レコードフォーマットでのト
ラックの先頭からの相対位置を示す相対位置情報とを上
記管理単位に書き入れた後、固定長レコードの固定長ブ
ロックサイズに分割して記憶することを特徴とするもの
である。

【００１４】また、この発明に係るアクセス制御装置は
前述したデータ記憶フォーマット変換方式を用いて作成
されたデータを記憶する記憶部に対してアクセスするア
クセス制御装置であり、従来の可変長レコード方式に基
づいて作成されたソフトウェアから出される可変長レコ
ードのアクセス命令を解釈して、前記固定長レコード方
式で記憶されたレコードをアクセスするものであり、以
下の要素を有するものである。 （ａ）上記記憶部に対して上記管理単位でデータを読み
書きする読み書き手段、（ｂ）上記読み書き手段により
読み書きされるデータを管理単位ごとに格納するメモ
リ、（ｃ）レコードが可変長フォーマットで記憶されて
いるものとして出力された可変長レコードへのアクセス
命令を入力する入力手段、（ｄ）上記入力手段により入
力したアクセス命令から、アクセスする可変長レコード
が記憶されていると考えられる管理単位の位置を概算す
る位置計算手段と、（ｅ）上記位置計算手段により概算
された位置にある管理単位を上記読み書き手段により上
記記憶部から上記メモリに読み込み、上記入力手段によ
り入力されたアクセス命令がアクセスしようとするレコ
ードを検索するレコード検索手段。

【００１５】また、この発明に係るデータ記憶フォーマ
ット変換方法は可変長レコード方式により作成された可
変長レコードからギャップを削除し、これをあらかじめ
定められた管理単位であるフレームに配置すると共に配
置したデータの位置等のアクセス情報を記憶させ、この
フレームを固定長のブロックサイズに分割して固定長フ
ォーマットとして記憶するものであり、以下の工程を有
するものである。 （ａ）データを有するフィールド及びレコード間ギャッ
プ及びフィールド間ギャップを有する可変長フォーマッ
トからレコード間ギャップ及びフィールド間ギャップを
削除して各可変長レコードのフィールドを連結するギャ
ップ削除工程、（ｂ）上記ギャップ削除工程により連結
された各可変長レコードをあらかじめ定められたサイズ
を持つフレームに順に配置するとともに、各可変長レコ
ードをアクセスするためのアクセス情報を各可変長レコ
ードに対応させて記憶するレコード配置工程、（ｃ）上
記フレームを複数の固定長のブロックサイズに分割して
固定長フォーマットとして記憶する固定長ブロック記憶
工程。

【００１６】また、この発明に係るデータアクセス方法
は前述したデータ記憶フォーマット変換方法により作成
された固定長のブロックサイズに分割されたデータに対
して従来から存在する可変長レコード方式のアクセス命
令によりアクセスするための方法であり、以下の工程を
有するものである。 （ａ）可変長フォーマットのレコードをアクセスするた
めのコマンドとアクセスするデータの検索情報を入力す
るアクセスコマンド入力工程、（ｂ）上記アクセスコマ
ンド入力工程により入力した検索情報からアクセスする
レコードが記憶されているフレームの位置情報を推定す
る位置情報推定工程、（ｃ）上記位置情報推定工程によ
り推定された位置情報をもつフレーム以降のフレームを
順に固定長フォーマットで記憶された複数の固定長ブロ
ックから再生し、アクセスするレコードを検索するレコ
ード検索工程。

【００１７】

【作用】この発明におけるデータ記憶フォーマット変換
方式においては、ギャップ削除手段によりギャップを削
除してしまうため、磁気ディスク等にデータを保持する
場合に記憶容量が少なくて済む。またレコード配置手段
が管理単位の中に可変長レコードの位置を示す第１の位
置情報と、可変長レコードとして記録された場合の相対
位置を示す第２の位置情報を記憶しているため、従来の
ソフトウェアから可変長レコード方式ののアクセス命令
が来た場合、可変長レコード方式の相対位置を示す第２
の位置情報を用いて管理単位を検索し、次に検索された
管理単位の中の可変長レコードの位置を示す第１の位置
情報を用いて目的とするレコードを検索することが可能
になる。このためアクセス回数が最小限で済む。

【００１８】また、この発明におけるアクセス制御装置
においては、位置計算手段が、従来のソフトウェアから
の可変長レコード方式のアクセス命令に付随するレコー
ドの相対位置情報から固定長レコード方式による管理単
位の位置を大まかに計算するため、レコード検索手段
が、この計算された位置情報をもとに固定長レコード方
式で記録されたデータをアクセスすることができる。こ
のようにこの発明に係るアクセス制御装置は位置計算手
段とレコード検索手段を備えることにより、従来例で説
明したようなセットセクタコマンドをサポートすること
が可能になる。

【００１９】また、この発明におけるデータ記憶フォー
マット変換方法はギャップ削除工程によりギャップを削
除したのち、レコード配置工程により各可変長レコード
をフレーム内に順に配置すると共にそのアクセス情報を
共にフレームに記憶させる点に特徴がある。さらに、こ
のフレームは固定長のブロックサイズに分割されて記憶
されるためフレームを固定長レコード方式で記憶するこ
とができる。

【００２０】また、この発明におけるデータアクセス方
法においては位置情報推定工程がアクセスコマンドによ
り入力された検索情報から固定長レコード方式に基づい
て記憶される場合の位置情報を推定し、レコード検索工
程によりこの推定された位置情報に基づいてフレームを
検索するのでフレームを検索する回数すなわちメモリの
アクセス回数を最小限に押さえることが可能になり、高
速なアクセスが可能になる。

【００２１】

【実施例】

実施例１．図１はこの発明を説明するための概略ブロッ
ク図である。ホスト計算機１はチャネル２を有してい
る。チャネル２は図に示すように複数のチャネル２ａ〜
２ｅを有している。例えばこのうちのひとつのチャネル
２ｂには磁気ディスク制御装置５が接続されている。磁
気ディスク制御装置５は内部にキャッシュメモリ６を有
している。磁気ディスク制御装置５はキャッシュメモリ
６を介してＦＢＡディスク９との間でデータのリードあ
るいはライトを行なう。ＦＢＡディスク９は固定長のブ
ロックサイズをもつブロック９ａ〜９ｅ有しており、Ｆ
ＢＡディスク９に記憶されるデータは全てこのブロック
単位に読み書きされる。

【００２２】次に、ＣＫＤ−ＦＢＡ変換の概略について
説明する。ホスト計算機１では従来のＣＫＤ方式で記録
されたデータをアクセスするためのソフトウェアが動作
する。このソフトウェアからはＣＫＤコマンド４がチャ
ネル２ｂを介して磁気ディスク制御装置５に出力され
る。例えばＣＫＤコマンド４がライトコマンドである場
合には、ＣＫＤフォーマットのレコード３は可変長レコ
ード３ａ，３ｂ，３ｃとして出力される。磁気ディスク
制御装置５はこの可変長レコード３ａ，３ｂ，３ｃをキ
ャッシュメモリ６に記憶する。その際、キャッシュメモ
リにはＣＫＤのトラックイメージ７が構成される。すな
わちＣＫＤのトラックイメージ７は可変長レコード３
ａ，３ｂ，３ｃをトラックの先頭から順に配置したイメ
ージとなる。従来ならばここでフィールド間ギャップ及
びレコード間ギャップが生成されて付加されることにな
るが、この場合にはギャップは全て取り除かれる。磁気
ディスク制御装置５はキャッシュメモリ６に作られたＣ
ＫＤのトラックイメージ７をＦＢＡフォーマットのレコ
ード８に変換する。ＦＢＡフォーマットのレコード８は
固定長のブロック８ａ〜８ｅによって構成されている。
磁気ディスク制御装置５はこのＦＢＡフォーマットのレ
コード８をＦＢＡディスク９に書き込む場合にはＦＢＡ
コマンド１０を出力する。ブロック８ａ〜８ｅはＦＢＡ
ディスク９にあるブロック９ａ〜９ｅに対応してそれぞ
れ記憶される。

【００２３】図２は、前述したＣＫＤ−ＦＢＡ変換の概
略をさらに詳しく説明するためのブロック図である。ホ
スト計算機１、磁気ディスク制御装置５、キャッシュメ
モリ６、ＦＢＡディスク９は前述した図１と同様のもの
でありここではその説明を省略する。この磁気ディスク
制御装置５の詳細な動作について図３、図４、図５を用
いてさらに説明する。

【００２４】図３、図４、図５はレコード記憶フォーマ
ット変換方式を説明するものである。先ず、図３（ａ）
に示す元のＣＫＤトラックフォーマットに対し、図３
（ｂ）に示すように、レコード間ギャップ、フィールド
間ギャップ等全てのギャップＧ１，Ｇ２，Ｇ３を削除す
る。

【００２５】次に、図３（ｂ）に示すギャップ削除後の
例えば４８ＫＢあるＣＫＤレコードの１トラックデータ
を図３（ｃ）に示す如く、後述する制御情報を含んで、
ＦＢＡレコードの固定ブロック長の整数倍（レコード数
倍）に相当する管理単位、例えば、次の（ｄ）で付加す
る制御情報も含め、１２ＫＢ単位に納まるよう分割す
る。

【００２６】次に、図３（ｃ）に示す管理単位に対し、
その中に含まれる全てのＣＫＤレコードの位置を示す制
御情報を、図３（ｄ）及び図４（ｄ）に示す如く、管理
単位の最後尾に後ろから順番に書いていく。

【００２７】ここで、図４（ｄ）においては、レコード
の管理単位内の位置情報のサイズを可変にすることによ
り、位置情報を記憶する場所をあらかじめ確保する必要
がなく位置情報の総容量を減らすことになっている。す
なわち、可変長レコードは管理単位の先頭から記載さ
れ、位置情報は管理単位の後ろから順番に記憶されて行
くため位置情報の数と可変長レコードの数は一致してお
り、両者の記憶領域が管理単位内でぶつかるまで記憶で
きることになる。このようにして実際に記録されている
レコードの分だけしか位置情報領域を使用しないような
制御を可能にする。しかし、位置情報領域のサイズを可
変にすると、データ転送時やフォーマットライト時の制
御が複雑なものとなり得るが、ここでは次のような方式
を採用して改善を図っている。

【００２８】今、図４（ｄ）において、レコードの位置
情報の管理単位をフレーム、実際にＣＫＤレコードを記
録する領域をレコードフレーム、制御情報を記録する領
域をコントロールフレーム、レコードの位置情報をレコ
ードポインタと呼ぶ。・実際に記録されているレコード
の分だけしかレコードポインタを使用しない。これによ
りレコードポインタ領域のサイズは、管理単位のサイズ
を１２ＫＢとし最大９４個のＣＫＤレコードが記録され
レコード１個当りの位置情報として４Ｂとすると、最大
でも、１ＣＫＤトラック当り、 ４Ｂ×９４＝２７６Ｂ で済む。この４Ｂの位置情報は図４（ｄ）においてはレ
コードポインタとして示されており、レコードポインタ
は１Ｂのレコードナンバと１Ｂのセクタ値と２Ｂのメモ
リアドレスから構成されている。レコードナンバは記録
される可変長レコードの番号を記録しておくものであ
る。セクタ値は記録されるレコードがＣＫＤレコード方
式で記録される場合のセクタ値を記憶するものである。
メモリアドレスはフレームに記憶されるレコードのフレ
ーム内のアドレスを記憶するものである。セクタ値はセ
ットセクタコマンドにより指定されたセクタ値と比較さ
れることにより利用される。同様にレコードナンバはサ
ーチＩＤコマンドにより指定されたレコードナンバと比
較されるために利用される。メモリアドレスはレコード
フレームに記憶されている実際のレコードのアドレスを
示すものである。セットセクタコマンド及びサーチＩＤ
コマンドによりレコードポインタのセクタ値とレコード
ナンバが比較され一致した場合にこのメモリアドレスを
用いてレコードが読み出される。

【００２９】レコードポインタを含むコントロールフレ
ームのサイズは、別途、制御情報、すなわちコントロー
ルフレームポインタとして保持している。この情報によ
り、コントロールフレームのサイズが可変となっても、
制御を複雑にせずに済ませる。

【００３０】これらの制御情報であるコントロールフレ
ームは、各フレームの先頭ではなく、最後尾に記録す
る。また、コントロールフレーム内のレコードポインタ
も後ろから順番に並べていく。実際のレコードがレコー
ドフレーム内で前にあるものほど、それに対応するレコ
ードポインタはコントロールフレーム内で後ろにくる。
これにより、フォーマットライト時の制御も無理がなく
なる。

【００３１】次に、図４（ｄ）に示すように、ＣＫＤレ
コードの位置情報等付加後、１２ＫＢのレコードフレー
ムを、図５（ｅ）に示す如く、ＦＢＡレコードのブロッ
クサイズ例えば１０２４Ｂ（１ＫＢ）相当に分割し、さ
らに、図５（ｆ）に示す如く、各レコードのデータフィ
ールドにＩＤフィールドをそれぞれ設けて、図５（ｇ）
に示す如く、ＦＢＡレコード方式のディスクを得る。

【００３２】また、固定ブロック内に記録されているＣ
ＫＤレコード１個ごとにＣＫＤフォーマットでのトラッ
クの先頭からの相対位置を示す情報、例えばセグメント
ナンバを残しておく。このようにすることにより、各レ
コードの位置が分かれば、そのレコードに記録されてい
る相対位置を示す情報から直ちに既に消費しているＣＫ
Ｄフォーマット上でのトラック容量が分かる。

【００３３】次に、図２に戻り磁気ディスク制御装置５
の動作について説明する。磁気ディスク制御装置５はホ
スト計算機１とＦＢＡディスク９との間でデータの変換
及び転送を行うチャネルパスサーバ５１（以下、ＣＰＳ
ともいう）を有している。チャネルパスサーバ５１には
ホスト計算機１からコマンド及びデータを入力するため
の入力部５２を有している。また、ＦＢＡディスク９か
らのデータをホスト計算機１に出力するための出力部５
２を有している。入力部５２からホスト計算機１で動作
しているソフトウェアによる可変長レコード方式のアク
セス命令が入力された場合に位置計算部５３は例えばセ
ットセクタコマンドで指定されたセクタ値に基づいてア
クセスする可変長レコードが記憶されていると考えられ
る管理単位の位置を計算する。この位置計算部による計
算は前述したようにＦＢＡディスク９にデータが記録さ
れる場合には全てのギャップが取り除かれているために
ＣＫＤディスク１０に存在している場合よりも前方向に
詰まった形でデータが記憶されており、位置計算部５３
は推測により、アクセスしようとしてる可変長レコード
が記憶されていると考えられる管理単位の位置を計算す
る。レコード検索部５４は位置計算部５３により計算さ
れた管理単位の位置をもとに管理単位をキャッシュメモ
リ６に読み込みアクセスしようとするレコードを検索す
る。管理単位検索部５６はアクセスしようとするレコー
ドの相対位置情報（セクタ値）と検索された管理単位に
保持されている相対位置情報（セクタ値）とを比較し、
アクセスしようとする相対位置情報をもつ管理単位が見
つかるまでＦＢＡディスク９に存在する管理単位を順に
キャッシュメモリに読み込む。レコード特定部５７は管
理単位検索部５６により目的とする管理単位が検索され
た場合にアクセスしようとする可変長レコードをその管
理単位に含まれるアドレス情報を用いて特定する。ＦＢ
Ａディスク９とキャッシュ・メモリ６の間のデータの読
み書きをＦＢＡコマンドを使用して実行するのは、デー
タ・パス・サーバ（ＤＰＳ）５５である。マネージャ
は、全体の制御とキャッシュ・メモリ６の管理を行な
う。

【００３４】ＣＫＤ−ＦＢＡ変換を行う際には三つのポ
イントが重要となる。すなわち、 Ｉ．ＣＫＤのトラック・フォーマットのどこを残し、ど
こを削除するか？ ＩＩ．そのようにトラック・フォーマットを加工した
後、どのようにして、元のレコードの位置を見つけるか
？ ＩＩＩ．ＣＫＤのトラック容量をどのようにチェックす
るか、すなわち、トラック・オーバランの検知をどのよ
うに行うか？ が三つのポイントとして検討されなければならない。上
記の三つのポイントについて考えてみると、他のバリエ
ーションが考えられることが分かる。以下、順番に各ポ
イントについてバリエーションを考える。

【００３５】まず、Ｉ．については、ＥＣＣやパディン
グ等、元々ディスク装置側で付加していた情報をＤＫＣ
で生成してからＦＢＡに変換するのは無駄である。従っ
て、「どこを残し、どこを削除するか？」ということ
は、事実上「どのギャップを残し、どのギャップを削除
するのか？」ということになる（ＥＣＣやパディング以
外の、ディフェクト情報のようなＤＫＣで管理していた
制御情報や物理パラメータはギャップに含めて考えれば
良い）。このギャップの残し方については、従来の方式
も含め以下のようなバリエーションが考えられる（図６
参照）。 ＜ケース Ｉ−１＞ ・・・「ＩＢＭ４３２１／４３３
１プロセッサ互換性機能」の方法 ・レコード間ギャップも含めすべてのギャップを削除し
てしまう。 ＜ケース Ｉ−２＞ ・・・従来の方法 ・レコード間ギャップだけ残し、フィールド間ギャップ
は取り除く。 ＜ケース Ｉ−３＞ ・レコード間ギャップだけでなく、すべてのフィールド
間ギャップも残す（ＥＣＣやパディングなどは取り除
く）。

【００３６】これらの各方法は、それぞれ、ギャップ以
外の細かい情報の扱いをどうするかによって、さらにい
ろいろなバリエーションが考えられる。また、これらの
各方法は、なんらかのＩＩの手段（レコードの位置決め
方法）と組み合わせられなければならないが、これに
は、従来の方法も含め以下のようないくつかの方法が考
えられる（図７参照、Ｉの各ケースと一対一に対応して
いるわけではない）。 ＜ケース ＩＩ−１＞ ・レコードの位置を示す特別の情報はいっさい持たな
い。 ・レコードを探すときは、常にトラックの先頭のレコー
ドから順番に読んでいき、各レコードのカウント・フィ
ールドに含まれるＫＬ，ＤＬの値から次のレコードのカ
ウント・フィールドの位置を計算する。 ＜ケース ＩＩ−２＞ ・・・従来の方法 ・部分的に、レコードの位置を示す情報をレコードその
ものとは別に保持する。（従来の方法では、各ＦＢＡブ
ロックの先頭に位置するレコードのカウント・フィール
ドの位置を保持する） ・位置を示されているレコードより後ろのレコードは＜
ケースＩＩ−１＞と同じ様に、位置の分かっているレコ
ードから順番に読みだし、各レコードのＫＬ，ＤＬから
次のレコードの位置を計算する。 ＜ケース ＩＩ−３＞ ・すべてのレコードの位置を示す情報をレコードそのも
のとは別に保持する。 ・すべてのレコードはこの情報から位置を探す。 ・レコードの位置情報は全レコード分を一括して一箇所
に保持する方法（例えば、トラックの先頭）と、分散し
て保持する方法（例えば、各ＦＢＡブロックの先頭にそ
のＦＢＡブロックに含まれるレコードの位置を示す情報
を保持する）が考えられる。 ＜ケース ＩＩ−４＞ ・ＦＢＡ変換後の論理的なトラック・イメージ上でもな
んらかのアドレス・マーク（ＡＭ）を生成し、これを目
印にレコードを探す（メモリ上でもＡＭサーチを行
う）。しかし、この方法はうまいアドレス・マークの生
成法を具体的に考えついていないこと、メモリ上でＡＭ
サーチを行うために全データを順番に読み出すことはメ
モリ負荷を不必要に高め非効率的であることなどから、
検討の範囲から除外する。

【００３７】次いで、ＩＩＩのトラック容量のチェック
方法については、以下のような方法が考えられる（図８
参照）。これらの方法は、Ｉのギャップの残し方によっ
ては、適用できるものとできないものがある。 ＜ケース ＩＩＩ−１＞ ・トラックの先頭からのすべてのレコードのＫＬ，ＤＬ
を知り、あいだのギャップやパディングの分（これらは
すべて一意的にそのサイズが決っている）も全部足し込
んで、既に消費されているＣＫＤフォーマット上でのト
ラック容量を計算する。 ＜ケース ＩＩＩ−２＞ ・・・従来の方法 ・削除したＥＣＣやパディングの分を残っているギャッ
プ（従来の方法ではレコード間ギャップ）の長さを伸ば
してつじつまを合わせる。これにより、各レコードのト
ラックの先頭からの相対位置を元のＣＫＤトラックのま
ま維持する。 ・従って、各レコードの位置が分かれば、そのレコード
のメモリ上のアドレスから直ちに既に消費しているＣＫ
Ｄフォーマット上でのトラック容量が分かる。 ＜ケース ＩＩＩ−３＞ ・各レコードにＣＫＤフォーマットでのトラックの先頭
からの相対位置を示す情報（例えばセグメント・ナン
バ）を残しておく。 ・従って、各レコードの位置が分かれば、そのレコード
に記録されている相対位置を示す情報から直ちに既に消
費しているＣＫＤフォーマット上でのトラック容量が分
かる。

【００３８】図８では＜ケース ＩＩＩ−１＞と＜ケー
ス ＩＩＩ−３＞は、すべてのギャップを取り除いてい
るケース＜ケース Ｉ−１＞で表現しているが、これら
の方法はいずれもギャップがどのように残っていても構
わない。また、＜ケース ＩＩＩ−２＞は、レコード間
ギャップだけ残しているケース＜ケース Ｉ−２＞で表
現しているが、すべてのギャップを残すケース＜ケース
Ｉ−３＞でも構わない。ただし、＜ケース ＩＩＩ−２
＞は、すべてのギャップを取り去る＜ケース Ｉ−１＞
では、ギャップ長の調節により、メモリ・アドレスを元
のレコードの相対位置のまま維持することができないの
で、原理上、実現不可能である。これらのＩ、ＩＩ、Ｉ
ＩＩの各ケースの組み合せにより、（上述のように不可
能な組み合わせ、また、無意味な組み合わせも有り）い
くつかのＣＫＤ−ＦＢＡ変換方式ができることになる。
従来の方式は＜ケース Ｉ−２＞，＜ケース ＩＩ−２
＞，＜ケース ＩＩＩ−２＞の組み合せによるＣＫＤ−
ＦＢＡ変換方式ということができる。

【００３９】図９に前述の各ケースの組み合せのうち有
効なものの一覧を示す。各ケースの組み合せのうち、実
現不可能なもの、無意味なものはあらかじめ除いてあ
る。比較項目の欄の説明については、次節以降に示す。
実現不可能なものとしては、前述した下記の組み合せが
ある。 ●＜ケース Ｉ−１＞と＜ケース ＩＩＩ−２＞の組み
合わせ ＜ケース Ｉ−１＞はすべてのギャップを取り除く方式
であるので、ギャップ長の調節により、メモリ・アドレ
スを元のレコードの相対位置のまま維持する＜ケース
ＩＩＩ−２＞のトラック容量のチェック方法は不可能で
ある。また、下記の組み合わせは不可能ではないが、以
下の理由により方式上無意味である。 ●＜ケース ＩＩ−２＞と＜ケース ＩＩＩ−１＞の組
み合わせ ●＜ケース ＩＩ−３＞と＜ケース ＩＩＩ−１＞の組
み合わせ ＜ケース ＩＩ−２＞と＜ケース ＩＩ−３＞はいずれ
もレコードとは別に保持されているレコードの位置情報
からレコードを捜し出す方式である。従って、あるレコ
ードを探すのにトラック上の最初のレコードから順番に
読み出す必要がないという利点がある。しかし、＜ケー
ス ＩＩＩ−１＞はトラック容量をチェックするため
に、トラック上の全カウント・フィールドのデータが必
要である。従って、これらの組み合せでは、結局、一度
はトラック上の最初のレコードから順番に読み出すこと
になり、＜ケース ＩＩ−２＞または＜ケース ＩＩ−
３＞の方式を採用した意味がなくなる。すなわち、＜ケ
ース ＩＩＩ−１＞はレコードの位置決め方式としてト
ラック上の全レコードを読み出す＜ケース ＩＩ−１＞
を採用したときだけ意味を持つトラック容量チェック方
式ということができる。これら以外の組み合わせは、す
べて図９にのせてある。図９の見方は、一行が一つの組
み合せで実現されるＣＫＤ-ＦＢＡ変換方式を示してお
り、○のついている方式がその組み合せで採用されてい
る方式である。従って、例えば一行目の方式は、「ギャ
ップの残し方」の方式としては＜ケース Ｉ−１＞を採
用し、「レコード位置決め方法」については＜ケース
ＩＩ−１＞を、「トラック容量のチェック方法」として
は＜ケース ＩＩＩ−１＞を採用したＣＫＤ−ＦＢＡ変
換方式ということになる。今後、このような方式を便宜
上＜１，１，１＞と表記することにする。この表記法で
は、従来の方式は＜２，２，２＞と表現できる。

【００４０】以後、各ＣＫＤ−ＦＢＡ変換方式の比較を
行うが、まず、そのために、各変換方式の比較ポイント
を下記のように考える。 ａ．ＣＫＤフォーマットのトラック・イメージを磁気デ
ィスク制御装置（ＤＫＣ）のキャッシュ・メモリ（以
下、単にメモリともいう）上に展開する際の、メモリ容
量の大小。・・・このメモリ容量は変換方式だけでな
く、１トラック分の容量はそのときのトラック・フォー
マット（レコード数の大小など）に大きく依存するた
め、しょせん最悪値にあわせて多めに取らざるを得な
い。しかも、このメモリ・イメージをＦＢＡの物理ディ
スクに書くことになるのであるから、ＦＢＡディスクの
ブロック（セクタ）容量の整数倍となる。従って、少々
の大小はあまり重大な問題ではない。主として、ギャッ
プの残し方、レコードの位置決めのためなどに必要な付
加情報の大小などによる。 ｂ．データ転送のやりやすさ・・・チャネルとの間で連
続してデータ転送する部分などは、メモリ上でも連続し
ていた方がやりやすい。例えば、キー・フィールドとデ
ータ・フィールドは、メモリ上でも連続していた方が転
送しやすい。ただし、元々ギャップの存在していた部分
については、時間を取ってやらないとチャネルの方がオ
ーバランを起こす可能性があるので、時間的なことでは
あまり急ぐ必要はない。 ｃ．目的レコードを見つけるときの手順・・・メモリ上
のＣＫＤフォーマットのトラック・イメージ内で目的レ
コードを見つけるための手順である。また、このとき、
単に手順の回数だけでなく、そのために必要なメモリ・
アクセスの回数の多さなども考慮する必要がある。トラ
ック・イメージは共通領域であるキャッシュ・メモリ上
に展開するので、手順そのもの（例えば計算量）が少々
多くても、メモリ・アクセス回数が少ない方がシステム
全体では有利である。主として、このメモリ・アクセス
回数はレコードの位置決め方法で決る。 ｄ．フォーマット・ライト時の手順・・・アップ・デー
ト・ライト時は既にフォーマットされているレコードの
ＫＬ，ＤＬ見てライトすれば良いが、フォーマット・ラ
イト時は、メモリ上で残トラック容量とホストから送ら
れてきたレコードのＫＬ，ＤＬの整合性を調べる必要が
ある。すなわち、トラック・オーバランのチェックが必
要である。さらに、方式によっては、レコード以外の制
御情報をメンテナンスする必要があるので、そのための
手順及び、メモリ・アクセスの多さなども考慮する必要
がある。 以下、この比較ポイントをもとに各ＣＫＤ−ＦＢＡ変換
方式の個々の特徴や、細かい分析を行う。

【００４１】＜１，１，１＞ ・ギャップ：すべて削除 ・レコード位置決め：トラックの最初のレコードから全
レコード・リード ・トラック容量チェック：トラックの最初のレコードか
ら全レコード・リード ａ．メモリ容量 この方式は、ギャップもすべてなく、制御情報の付加も
いっさいないので、メモリの利用効率は、もっとも良
い。 ｂ．データ転送のやりやすさ 各フィールドがメモリ上で連続しているので、チャネル
との間で連続したフィールドのデータ転送する時、メモ
リ・アドレスはカウント・アップしていくだけでよい。 ｃ．目的レコードを見つけるときの手順 目的レコードを見つけるためには、トラックの先頭から
該当レコードまでのレコード数だけメモリをアクセスす
る必要がある。すなわち、各レコードのカウント・フィ
ールドのリードが必要になる。各レコードのカウント・
フィールドを取得した後、それらのＫＬ，ＤＬから目的
レコードの位置を計算していくのは、余分なギャップな
どがないぶん、ＫＬ，ＤＬを足しこんでいけばよく単純
である。 ｄ．フォーマット・ライト時の手順 トラック容量をチェックするためにも、トラックの先頭
から該当レコードまでのレコード数だけメモリをアクセ
スする必要がある。トラック容量のチェックのために
は、逆に、削除してしまったギャップなどの分も換算し
てやる必要がある。フォーマット・ライト時、更新しな
ければならない制御情報はない。

【００４２】＜１，２，３＞ ・ギャップ：すべて削除 ・レコード位置決め：ＦＢＡブロックに含まれる最初の
レコードの位置を保持 ・トラック容量チェック：各レコードにセグメント・ナ
ンバ等の相対位置情報を保持 ａ．メモリ容量 ギャップはすべて削除するが、ＦＢＡのブロックに含ま
れる最初のレコードの位置や、各レコードのセグメント
・ナンバ等を保持するための制御情報の分だけは、＜
１，１，１＞より余分にメモリを使用する。 ｂ．データ転送のやりやすさ やはり、各フィールドがメモリ上で連続しているので、
チャネルとの間で連続したフィールドのデータ転送する
時、メモリ・アドレスはカウント・アップしていくだけ
でよい。しかし、単一フィールド内であっても、ＦＢＡ
のブロックにまたがったような場合は、メモリ上でもＦ
ＢＡブロックに含まれる最初のレコードの位置情報など
により分断されるので、その位置情報の部分をスキップ
・ディフェクトなどのように飛ばしてデータ転送を行う
必要がある。 ｃ．目的レコードを見つけるときの手順 目的レコードを探すためには、ＦＢＡのブロックの最初
のレコードから目的レコードまでの間に存在するレコー
ドの回数だけメモリをアクセスする必要がある。従っ
て、＜１，１，１＞よりはメモリ・アクセス回数は少な
い。ＦＢＡのブロックの最初のレコードの位置から目的
レコードの位置を計算する方法はほとんど＜１，１，１
＞と同じで単純である（カウント・フィールドのサイズ
とＫＬ，ＤＬを足し込んでいけば良い）。 ｄ．フォーマット・ライト時の手順 トラック容量のチェックのためには、フォーマット・ラ
イトしようとしているレコードの一つ前のレコードのセ
グメント・ナンバ（本来のＣＫＤフォーマットで、その
レコードのトラック上での相対位置を示す情報）とＫ
Ｌ，ＤＬから、後どれだけのサイズのレコードがライト
できるか計算する。フォーマット・ライトしたときは、
ライトしたレコード自身にそのレコードのセグメント・
ナンバを書いておかなければならない。同時に、新たな
ＦＢＡブロック上に新たなカウント・フィールドが生じ
たときは、そのＦＢＡブロックに先頭のレコードのカウ
ント・フィールドの位置を示す情報を書かなければなら
ない。

【００４３】＜１，３，３＞ ・ギャップ：すべて削除 ・レコード位置決め：すべてのレコードの相対位置情報
を保持 ・トラック容量チェック：各レコードにセグメント・ナ
ンバ等の相対位置情報を保持 ａ．メモリ容量 ギャップはすべて削除するが、全レコードの位置情報を
別に保持するため、＜１，２，３＞のようにＦＢＡのブ
ロックに含まれる最初のレコードの位置だけ保持する場
合より、さらにメモリ容量は多く必要である。各レコー
ドにセグメント・ナンバなどを保持するのは＜１，２，
３＞と同じである。 ｂ．データ転送のやりやすさ ほぼ、＜１，２，３＞と同じである。各フィールドがメ
モリ上で連続しているので、チャネルとの間で連続した
フィールドのデータ転送する時、メモリ・アドレスはカ
ウント・アップしていくだけでよい。レコードの位置情
報をＦＢＡのブロックごとに分散して持つ場合は、単一
フィールド内であっても、ＦＢＡのブロックにまたがる
場合、メモリ上でもＦＢＡブロックに含まれるレコード
の位置情報などにより分断されるので、その位置情報の
部分をスキップ・ディフェクトなどのように飛ばしてデ
ータ転送を行う必要がある。 ｃ．目的レコードを見つけるときの手順 目的レコードを探すためには、レコードの位置情報を一
回だけ読み取れば良いので、メモリ・アクセス回数は全
方式の中で最小である。目的レコードの位置は、その情
報からダイレクトに分かる。 ｄ．フォーマット・ライト時の手順 ＜１，２，３＞とトラック容量のチェック方法が同じで
あるので、フォーマット・ライト時の手順も＜１，２，
３＞とほぼ同じである。トラック容量のチェックのため
には、フォーマット・ライトしようとしているレコード
の一つ前のレコードのセグメント・ナンバ（本来のＣＫ
Ｄフォーマットで、そのレコードのトラック上での相対
位置を示す情報）とＫＬ，ＤＬから、後どれだけのサイ
ズのレコードがライトできるか計算する。フォーマット
・ライトしたときは、ライトしたレコード自身にそのレ
コードのセグメント・ナンバを計算して書いておかなけ
ればならない。同時に、必ずレコードの位置情報を保持
している制御情報に、そのレコードのカウント・フィー
ルドの位置を示す情報を書き足さなければならない。

【００４４】＜２，１，１＞ ・ギャップ：フィールド間ギャップのみ削除、レコード
間ギャップは残す ・レコード位置決め：トラックの最初のレコードから全
レコード・リード ・トラック容量チェック：トラックの最初のレコードか
ら全レコード・リード ａ．メモリ容量 余分な制御情報の付加はないが、レコード間ギャップを
残すのでメモリ容量は＜１，＊，＊＞方式より多く必要
である。しかし、残したレコード間ギャップによりレコ
ードの相対位置を維持しようということではないので、
レコード間ギャップを無理に伸ばす必要はない。従っ
て、トラック容量のチェック方法として、レコード間ギ
ャップ長を伸ばしてレコードの相対位置を維持する＜
＊，＊，２＞方式に比べメモリ容量は少なくできるが、
逆に言うと、レコード間ギャップを残した意味もない。 ｂ．データ転送のやりやすさ レコード間ギャップは存在するが、フィールド間ギャッ
プは無いので、チャネルとの間で連続したフィールドの
データを転送するとき（Ｃ→Ｋ→Ｄ）、メモリ・アドレ
スはカウント・アップするだけでよい。余分な制御情報
もないので、単一フィールドがＦＢＡのブロックにまた
がっても、メモリ上でそのフィールドが分断されること
もない。 ｃ．目的レコードを見つけるときの手順 ＜１，１，１＞とほぼ同じである。目的レコードを見つ
けるためには、トラックの先頭から該当レコードまでの
レコード数だけメモリをアクセスする必要がある。すな
わち、各レコードのカウント・フィールドのリードが必
要となる。各レコードのカウント・フィールドを取得し
た後、それらのＫＬ，ＤＬから目的レコードの位置を計
算していくには、ＫＬ，ＤＬに加えレコード間ギャップ
を足しこんでいけばよく単純である。 ｄ．フォーマット・ライト時の手順 これも＜１，１，１＞とほぼ同じである。トラック容量
をチェックするためにも、トラックの先頭から該当レコ
ードまでのレコード数だけメモリをアクセスする必要が
ある。トラック容量のチェックのためには、削除してし
まったフィールド間ギャップなどの分も換算してやる必
要がある。フォーマット・ライト時、更新しなければな
らない制御情報はない。

【００４５】＜２，２，２＞ ・・・従来の方式 ・ギャップ：フィールド間ギャップのみ削除、レコード
間ギャップは残す ・レコード位置決め：ＦＢＡのブロックに含まれる最初
のレコード位置を保持 ・トラック容量チェック：ギャップ長の調節により各レ
コードの相対位置を維持 ａ．メモリ容量 フィールド間ギャップなどは削除するものの、その分レ
コード間ギャップを伸ばして各レコードの相対位置を元
のＣＫＤフォーマットのまま維持するので、結局必要な
メモリ容量は、元のＣＫＤフォーマットのトラック容量
と同じで、さらにＦＢＡのブロックに含まれる最初のレ
コードの位置情報の分だけ余分にメモリが必要である。 ｂ．データ転送のやりやすさ レコード間ギャップは存在するが、フィールド間ギャッ
プは無いので、チャネルとの間で連続したフィールドの
データを転送するとき（Ｃ→Ｋ→Ｄ）、メモリ・アドレ
スはカウント・アップするだけでよい。しかし、＜２，
１，１＞と異なり、単一フィールド内であっても、ＦＢ
Ａのブロックにまたがったような場合は、メモリ上でも
ＦＢＡブロックに含まれる最初のレコードの位置情報な
どにより分断されるので、その位置情報の部分をスキッ
プ・ディフェクトなどのように飛ばしてデータ転送を行
う必要がある。 ｃ．目的レコードを見つけるときの手順 目的レコードを探すためには、ＦＢＡのブロックの最初
のレコードから目的レコードまでの間に存在するレコー
ドの回数だけメモリをアクセスする必要がある。従っ
て、＜２，１，１＞よりはメモリ・アクセス回数は少な
い。ＦＢＡのブロックの最初のレコードの位置から目的
レコードの位置を計算する方法はほとんど＜２，１，１
＞と同じで単純である（カウント・フィールドのサイズ
とＫＬ，ＤＬさらにレコード間ギャップをどんどん足し
込んでいけば良い）。また、各レコードのＣＫＤフォー
マットでの相対位置をメモリ上でも維持しているので、
Ｓｅｔ Ｓｅｃｔｏｒの値から目的レコードの含まれる
ＦＢＡのブロックを正確に求めることができる。 ｄ．フォーマット・ライト時の手順 トラック容量のチェックには、各レコードのＣＫＤフォ
ーマットでの相対位置をメモリ上でも維持しているの
で、フォーマット・ライトしようとしているレコードの
メモリ上のアドレスが分かれば（ｃ．の手順で分か
る）、直ちに後どれだけのサイズのレコードがライトで
きるか計算できる。フォーマット・ライトして、新たな
ＦＢＡブロック上に新たなカウント・フィールドが生じ
たときは、そのＦＢＡブロックに先頭のレコードのカウ
ント・フィールドの位置を示す情報を書かなければなら
ない。

【００４６】＜２，２，３＞ ・ギャップ：フィールド間ギャップのみ削除、レコード
間ギャップは残す ・レコード位置決め：ＦＢＡのブロックに含まれる最初
のレコード位置を保持 ・トラック容量チェック：各レコードにセグメント・ナ
ンバ等の相対位置情報を保持 ａ．メモリ容量 フィールド間ギャップなどは削除し、レコード間ギャッ
プを残すのは＜２，２，２＞と同じであるが、残したレ
コード間ギャップによりレコードの相対位置を維持しよ
うということではないので、レコード間ギャップを無理
に伸ばす必要はない（従って、やはりギャップを残す意
味は薄くなる）。しかし、ＦＢＡのブロックに含まれる
最初のレコードの位置情報の分は余分に必要である。ま
た、各レコードに含まれるセグメント・ナンバの分も必
要であるので、結局メモリ容量としては＜２，１，１＞
より多く、＜２，２，２＞よりは少なくなる。 ｂ．データ転送のやりやすさ これは＜２，２，２＞と全く同じである。レコード間ギ
ャップは存在するが、フィールド間ギャップは無いの
で、チャネルとの間で連続したフィールドのデータを転
送するとき（Ｃ→Ｋ→Ｄ）、メモリ・アドレスはカウン
ト・アップするだけでよい（各レコードに保持されてい
るセグメント・ナンバなどはカウント・フィールドに含
まれるので、データ転送時Ｃ→Ｋの邪魔になることはな
い）。しかし、単一フィールド内であっても、ＦＢＡの
ブロックにまたがったような場合は、メモリ上でもＦＢ
Ａブロックに含まれる最初のレコードの位置情報などの
制御情報により分断されるので、その制御情報の部分を
スキップ・ディフェクトなどのように飛ばしてデータ転
送を行う必要がある。 ｃ．目的レコードを見つけるときの手順 これも＜２，２，２＞と全く同じである。目的レコード
を探すためには、ＦＢＡのブロックの最初のレコードか
ら目的レコードまでの間に存在するレコードの回数だけ
メモリをアクセスする必要がある。従って、＜１，１，
１＞よりはメモリ・アクセス回数は少ない。ＦＢＡのブ
ロックの最初のレコードの位置から目的レコードの位置
を計算する方法はほとんど＜１，１，１＞と同じで単純
である（カウント・フィールドのサイズとＫＬ，ＤＬさ
らにレコード間ギャップをどんどん足し込んでいけば良
い）。 ｄ．フォーマット・ライト時の手順 トラック容量のチェックのためには、フォーマット・ラ
イトしようとしているレコードの一つ前のレコードのセ
グメント・ナンバ（本来のＣＫＤフォーマットで、その
レコードのトラック上での相対位置を示す情報）とＫ
Ｌ，ＤＬから、後どれだけのサイズのレコードがライト
できるか計算する。フォーマット・ライトしたときは、
ライトしたレコード自身にそのレコードのセグメント・
ナンバを計算して書いておかなければならない。同時
に、新たなＦＢＡブロック上に新たなカウント・フィー
ルドが生じたときは、そのＦＢＡブロックに先頭のレコ
ードのカウント・フィールドの位置を示す情報を書かな
ければならない。

【００４７】＜２，３，２＞ ・ギャップ：フィールド間ギャップのみ削除、レコード
間ギャップは残す ・レコード位置決め：すべてのレコードの相対位置情報
を保持 ・トラック容量チェック：ギャップ長の調節により各レ
コードの相対位置を維持 ａ．メモリ容量 残したレコード間ギャップ長の調節により各レコードの
相対位置を元のＣＫＤフォーマットのまま維持するので
あるから、＜２，２，２＞と同じ様に、必要なメモリ容
量は基本的には元のＣＫＤフォーマットのトラック容量
と同じである。しかし、制御情報として付加するレコー
ドの位置情報は、＜２，２，２＞のようにＦＢＡのブロ
ックの最初のレコードの分だけでなく、すべてのレコー
ドの分を保持するので、メモリ容量も＜２，２，２＞よ
り多くなり、全方式中最大である。 ｂ．データ転送のやりやすさ ＜２，２，２＞，＜２，２，３＞と全く同じである。レ
コード間ギャップは存在するが、フィールド間ギャップ
は無いので、チャネルとの間で連続したフィールドのデ
ータを転送するとき（Ｃ→Ｋ→Ｄ）、メモリ・アドレス
はカウント・アップするだけでよい。しかし、レコード
の位置情報をＦＢＡのブロックごとに分散して持つ場合
は、単一フィールド内であっても、ＦＢＡのブロックに
またがったような場合は、メモリ上でもＦＢＡブロック
に含まれるレコードの位置情報などにより分断されるの
で、その位置情報の部分をスキップ・ディフェクトなど
のように飛ばしてデータ転送を行う必要がある。 ｃ．目的レコードを見つけるときの手順 ＜１，３，３＞と全く同じである。目的レコードを探す
ためには、レコードの位置情報を一回だけ読み取れば良
いので、メモリ・アクセス回数は全方式の中で最小であ
る。目的レコードの位置は、その情報からダイレクトに
分かる。また、各レコードのＣＫＤフォーマットでの相
対位置をメモリ上でも維持しているので、Ｓｅｔ Ｓｅ
ｃｔｏｒの値から目的レコードの含まれるＦＢＡのブロ
ックを正確に求めることができる。 ｄ．フォーマット・ライト時の手順 ＜２，２，２＞と＜１，３，３＞の中間的な手順とな
る。トラック容量のチェックには、各レコードのＣＫＤ
フォーマットでの相対位置をメモリ上でも維持している
ので、フォーマット・ライトしようとしているレコード
のメモリ上のアドレスが分かれば（ｃ．の手順で分か
る）、直ちに後どれだけのサイズのレコードがライトで
きるか計算できる。フォーマット・ライトしたときは、
必ずレコードの位置情報を保持している制御情報に、そ
のレコードのカウント・フィールドの位置を示す情報を
書き足さなければならない。

【００４８】＜２，３，３＞ ・ギャップ：フィールド間ギャップのみ削除、レコード
間ギャップは残す ・レコード位置決め：すべてのレコードの相対位置情報
を保持 ・トラック容量チェック：各レコードにセグメント・ナ
ンバ等の相対位置情報を保持 ａ．メモリ容量 フィールド間ギャップなどは削除し、レコード間ギャッ
プを残すのは＜２，３，２＞と同じであるが、残したレ
コード間ギャップによりレコードの相対位置を維持しよ
うということではないので、レコード間ギャップを無理
に伸ばす必要はない（従って、やはりギャップを残す意
味は薄くなる）。しかし、すべてのレコードの位置情報
の分は余分にメモリ容量が必要である。また、各レコー
ドに含まれるセグメント・ナンバの分も必要であるの
で、結局メモリ容量としてはよく似た方式である＜２，
２，３＞よりも多く、＜２，３，２＞よりは少なくな
る。 ｂ．データ転送のやりやすさ これは＜２，３，２＞と全く同じである。レコード間ギ
ャップは存在するが、フィールド間ギャップは無いの
で、チャネルとの間で連続したフィールドのデータを転
送するとき（Ｃ→Ｋ→Ｄ）、メモリ・アドレスはカウン
ト・アップするだけでよい（各レコードに保持されてい
るセグメント・ナンバなどはカウント・フィールドに含
まれるので、データ転送時Ｃ→Ｋの邪魔になることはな
い）。また、レコードの位置情報をＦＢＡのブロックご
とに分散して持つ場合は、単一フィールド内であって
も、ＦＢＡのブロックにまたがる場合、メモリ上でもＦ
ＢＡブロックに含まれるレコードの位置情報などにより
分断されるので、その位置情報の部分をスキップ・ディ
フェクトなどのようにして飛ばしてデータ転送を行う必
要がある。 ｃ．目的レコードを見つけるときの手順 これも＜２，３，２＞と全く同じである。目的レコード
を探すためには、レコードの位置情報を一回だけ読み取
れば良いので、メモリ・アクセス回数は全方式の中で最
小である。目的レコードの位置は、その情報からダイレ
クトに分かる。 ｄ．フォーマット・ライト時の手順 トラック容量のチェックのためには、フォーマット・ラ
イトしようとしているレコードの一つ前のレコードのセ
グメント・ナンバ（本来のＣＫＤフォーマットで、その
レコードのトラック上での相対位置を示す情報）とＫ
Ｌ，ＤＬから、後どれだけのサイズのレコードがライト
できるか計算する。フォーマット・ライトしたときは、
ライトしたレコード自身にそのレコードのセグメント・
ナンバを計算して書いておかなければならない。同時
に、必ずレコードの位置情報を保持している制御情報
に、そのレコードのカウント・フィールドの位置を示す
情報を書き足さなければならない。

【００４９】＜３，１，１＞ ・ギャップ：レコード間ギャップ、フィールド間ギャッ
プとも残す ・レコード位置決め：トラックの最初のレコードから全
レコード・リード ・トラック容量チェック：トラックの最初のレコードか
ら全レコード・リード ａ．メモリ容量 余分な制御情報の付加はないが、レコード間ギャップ、
フィールド間ギャップとも残すので、ほぼＣＫＤフォー
マットのトラック・イメージがそのまま残されるためメ
モリ容量は最大に近くなる。しかし、ＣＫＤフォーマッ
トにおけるレコードの相対位置を積極的に維持しようと
言うのではないので、ＥＣＣやパディングの分まではメ
モリ容量に加える必要はない。そのかわり、ギャップを
残した意味はあまりなくなる。 ｂ．データ転送のやりやすさ メモリ上でもレコード間、フィールド間ともにギャップ
が存在するので、連続したフィールドのデータ転送をチ
ャネルとの間で行うとき、メモリ・アドレスは単純にカ
ウント・アップするだけではなく、ギャップの分を飛ば
して、再設定する必要がある。しかし、余分な制御情報
はないので、単一フィールドがＦＢＡのブロックにまた
がっても、メモリ上でそのフィールドが分断されること
はない。 ｃ．目的レコードを見つけるときの手順 ＜１，１，１＞とほぼ同じである。目的レコードを見つ
けるためには、トラックの先頭から該当レコードまでの
レコード数だけメモリをアクセスする必要がある。すな
わち、各レコードのカウント・フィールドのリードが必
要になる。各レコードのカウント・フィールドを取得し
た後、それらのＫＬ，ＤＬから目的レコードの位置を計
算していくには、ＫＬ，ＤＬに加えレコード間ギャッ
プ、フィールド間ギャップを足しこんでいけばよく単純
である。 ｄ．フォーマット・ライト時の手順 これも＜１，１，１＞とほぼ同じである。トラック容量
をチェックするためにも、トラックの先頭から該当レコ
ードまでのレコード数だけメモリをアクセスする必要が
ある。トラック容量のチェックのためには、ギャップは
そのまま残っているが、ＥＣＣやパディング・データな
どの分は換算してやる必要がある。ＥＣＣの分なども含
めぴったり同じ容量をギャップ長で補正していれば、メ
モリ・アドレスから直ちに残トラック容量が分かるが、
これは＜３，２，２＞方式となる。フォーマット・ライ
ト時、更新しなければならない制御情報はない。

【００５０】＜３，２，２＞ ・ギャップ：レコード間ギャップ、フィールド間ギャッ
プとも残す ・レコード位置決め：ＦＢＡのブロックに含まれる最初
のレコードの位置を保持 ・トラック容量チェック：ギャップ長の調節により各レ
コードの相対位置を維持 ａ．メモリ容量 レコード間ギャップ、フィールド間ギャップとも残って
いるが、ギャップ長を調節して各レコードの相対位置を
元のＣＫＤフォーマットのまま維持するので、結局必要
なメモリ容量は＜２，２，２＞と同じで、元のＣＫＤフ
ォーマットのトラック容量と、ＦＢＡのブロックに含ま
れる最初のレコードの位置情報を加えた分だけ必要であ
る。 ｂ．データ転送のやりやすさ メモリ上でもレコード間、フィールド間ともにギャップ
が存在するので、連続したフィールドのデータ転送をチ
ャネルとの間で行うとき、メモリ・アドレスは単純にカ
ウント・アップするだけではなく、＜３，１，１＞と同
様、ギャップの分を飛ばして、再設定する必要がある。
さらに、＜３，１，１＞と異なり、単一フィールド内で
あっても、ＦＢＡのブロックにまたがったような場合
は、メモリ上でもＦＢＡブロックに含まれる最初のレコ
ードの位置情報などにより分断されるので、その位置情
報の部分をスキップ・ディフェクトなどのように飛ばし
てデータ転送を行う必要がある。 ｃ．目的レコードを見つけるときの手順 ＜２，２，２＞と全く同じである。目的レコードを探す
ためには、ＦＢＡのブロックの最初のレコードから目的
レコードまでの間に存在するレコードの回数だけメモリ
をアクセスする必要がある。従って、＜３，１，１＞よ
りはメモリ・アクセス回数は少ない。ＦＢＡのブロック
の最初のレコードの位置から目的レコードの位置を計算
する方法はほとんど＜３，１，１＞と同じで単純である
（カウント・フィールドのサイズとＫＬ，ＤＬさらにレ
コード間ギャップ、フィールド間ギャップをどんどん足
し込んでいけば良い）。また、各レコードのＣＫＤフォ
ーマットでの相対位置をメモリ上でも維持しているの
で、Ｓｅｔ Ｓｅｃｔｏｒの値から目的レコードの含ま
れるＦＢＡのブロックを正確に求めることができる。 ｄ．フォーマット・ライト時の手順 これも＜２，２，２＞と全く同じである。トラック容量
のチェックには、各レコードのＣＫＤフォーマットでの
相対位置をメモリ上でも維持しているので、フォーマッ
ト・ライトしようとしているレコードのメモリ上のアド
レスが分かれば（ｃ．の手順で分かる）、直ちに後どれ
だけのサイズのレコードがライトできるか計算できる。
フォーマット・ライトして、新たなＦＢＡブロック上に
新たなカウント・フィールドが生じたときは、そのＦＢ
Ａブロックに先頭のレコードのカウント・フィールドの
位置を示す情報を書かなければならない。

【００５１】＜３，２，３＞ ・ギャップ：レコード間ギャップ、フィールド間ギャッ
プとも残す ・レコード位置決め：ＦＢＡのブロックに含まれる最初
のレコードの位置を保持 ・トラック容量チェック：各レコードにセグメント・ナ
ンバ等の相対位置情報を保持 ａ．メモリ容量 レコード間ギャップ、フィールド間ギャップとも残すの
で、ほぼＣＫＤフォーマットのトラック・イメージがそ
のまま残され、さらに、ＦＢＡのブロックに含まれる最
初のレコードの位置情報の分も余分に必要であるためメ
モリ容量は最大に近くなる。しかし、ＣＫＤフォーマッ
トにおけるレコードの相対位置を積極的に維持しようと
言うのではないので、ＥＣＣやパディングの分まではメ
モリ容量に加える必要はない。そのかわり、あまりギャ
ップを残した意味はなくなる。 ｂ．データ転送のやりやすさ これは、＜３，２，２＞と全く同じである。メモリ上で
もレコード間、フィールド間ともにギャップが存在する
ので、連続したフィールドのデータ転送をチャネルとの
間で行うとき、メモリ・アドレスは単純にカウント・ア
ップするだけではなく、＜３，１，１＞と同様、ギャッ
プの分を飛ばして、再設定する必要がある。さらに、＜
３，１，１＞と異なり、単一フィールド内であっても、
ＦＢＡのブロックにまたがったような場合は、メモリ上
でもＦＢＡブロックに含まれる最初のレコードの位置情
報などにより分断されるので、その位置情報の部分をス
キップ・ディフェクトなどのように飛ばしてデータ転送
を行う必要がある。 ｃ．目的レコードを見つけるときの手順 これも＜３，２，２＞と全く同じである。目的レコード
を探すためには、ＦＢＡのブロックの最初のレコードか
ら目的レコードまでの間に存在するレコードの回数だけ
メモリをアクセスする必要がある。従って、＜３，１，
１＞よりはメモリ・アクセス回数は少ない。ＦＢＡのブ
ロックの最初のレコードの位置から目的レコードの位置
を計算する方法はほとんど＜３，１，１＞と同じで単純
である（カウント・フィールドのサイズとＫＬ，ＤＬさ
らにレコード間ギャップ、フィールド間ギャップをどん
どん足し込んでいけば良い）。 ｄ．フォーマット・ライト時の手順 トラック容量のチェックのためには、フォーマット・ラ
イトしようとしているレコードの一つ前のレコードのセ
グメント・ナンバ（本来のＣＫＤフォーマットで、その
レコードのトラック上での相対位置を示す情報）とＫ
Ｌ，ＤＬから、後どれだけのサイズのレコードがライト
できるか計算する。フォーマット・ライトしたときは、
ライトしたレコード自身にそのレコードのセグメント・
ナンバを書いておかなければならない。同時に新たなＦ
ＢＡブロック上に新たなカウント・フィールドが生じた
ときは、そのＦＢＡブロックに先頭のレコードのカウン
ト・フィールドの位置を示す情報を書かなければならな
い。

【００５２】＜３，３，２＞ ・ギャップ：レコード間ギャップ、フィールド間ギャッ
プとも残す ・レコード位置決め：すべてのレコードの相対位置情報
を保持 ・トラック容量チェック：ギャップ長の調節により各レ
コードの相対位置を維持 ａ．メモリ容量 残したレコード間ギャップ長の調節により各レコードの
相対位置を元のＣＫＤフォーマットのまま維持するので
あるから、＜３，２，２＞と同じ様に、必要なメモリ容
量は基本的には元のＣＫＤフォーマットのトラック容量
と同じである。しかし、制御情報として付加するレコー
ドの位置情報は、＜３，２，２＞のようにＦＢＡのブロ
ックの最初のレコードの分だけでなく、すべてのレコー
ドの分を保持するので、メモリ容量も＜３，２，２＞よ
り多くなり、＜２，３，２＞と同様全方式中最大であ
る。 ｂ．データ転送のやりやすさ これは、＜３，２，２＞，＜３，２，３＞と全く同じで
ある。メモリ上でもレコード間、フィールド間ともにギ
ャップが存在するので、連続したフィールドのデータ転
送をチャネルとの間で行うとき、メモリ・アドレスは単
純にカウント・アップするだけではなく、＜３，１，１
＞と同様、ギャップの分を飛ばして、再設定する必要が
ある。さらに、＜３，１，１＞と異なり、レコードの位
置情報をＦＢＡのブロックごとに分散して持つ場合は、
単一フィールド内であっても、ＦＢＡのブロックにまた
がったような場合は、メモリ上でもＦＢＡブロックに含
まれるレコードの位置情報などにより分断されるので、
その位置情報の部分をスキップ・ディフェクトなどのよ
うに飛ばしてデータ転送を行う必要がある。 ｃ．目的レコードを見つけるときの手順 ＜１，３，３＞、＜２，３，３＞などと全く同じであ
る。目的レコードを探すためには、レコードの位置情報
を一回だけ読み取れば良いので、メモリ・アクセス回数
は全方式の中で最小である。目的レコードの位置は、そ
の情報からダイレクトに分かる。また、各レコードのＣ
ＫＤフォーマットでの相対位置をメモリ上でも維持して
いるので、Ｓｅｔ Ｓｅｃｔｏｒの値から目的レコード
の含まれるＦＢＡのブロックを正確に求めることができ
る。 ｄ．フォーマット・ライト時の手順 ＜２，３，２＞と全く同じである。トラック容量のチェ
ックには、各レコードのＣＫＤフォーマットでの相対位
置をメモリ上でも維持しているので、フォーマット・ラ
イトしようとしているレコードのメモリ上のアドレスが
分かれば（ｃ．の手順で分かる）、直ちに後どれだけの
サイズのレコードがライトできるか計算できる。フォー
マット・ライトしたときは、必ずレコードの位置情報を
保持している制御情報に、そのレコードのカウント・フ
ィールドの位置を示す情報を書き足さなければならな
い。

【００５３】＜３，３，３＞ ・ギャップ：レコード間ギャップ、フィールド間ギャッ
プとも残す ・レコード位置決め：すべてのレコードの相対位置情報
を保持 ・トラック容量チェック：各レコードにセグメント・ナ
ンバ等の相対位置情報を保持 ａ．メモリ容量 レコード間ギャップ、フィールド間ギャップとも残すの
で、ほぼＣＫＤフォーマットのトラック・イメージがそ
のまま残され、さらに、すべてのレコードの位置情報の
分も余分に必要であるためメモリ容量は＜３，２，３＞
よりもさらに多く、最大に近くなる。しかし、ＣＫＤフ
ォーマットにおけるレコードの相対位置を積極的に維持
しようと言うのではないので、ＥＣＣやパディングの分
まではメモリ容量に加える必要はない。そのかわり、ギ
ャップを残した意味はあまりなくなる。 ｂ．データ転送のやりやすさ これは、＜３，２，２＞，＜３，２，３＞，＜３，３，
２＞と全く同じである。メモリ上でもレコード間、フィ
ールド間ともにギャップが存在するので、連続したフィ
ールドのデータ転送をチャネルとの間で行うとき、メモ
リ・アドレスは単純にカウント・アップするだけではな
く、＜３，１，１＞と同様、ギャップの分を飛ばして、
再設定する必要がある。さらに、＜３，１，１＞と異な
り、レコードの位置情報をＦＢＡのブロックごとに分散
して持つ場合は、単一フィールド内であっても、ＦＢＡ
のブロックにまたがったような場合は、メモリ上でもＦ
ＢＡブロックに含まれるレコードの位置情報などにより
分断されるので、その位置情報の部分をスキップ・ディ
フェクトなどのように飛ばしてデータ転送を行う必要が
ある。 ｃ．目的レコードを見つけるときの手順 これは＜３，３，２＞と全く同じである。目的レコード
を探すためには、レコードの位置情報を一回だけ読み取
れば良いので、メモリ・アクセス回数は全方式の中で最
小である。目的レコードの位置は、その情報からダイレ
クトに分かる。 ｄ．フォーマット・ライト時の手順 ＜２，３，３＞と全く同じである。トラック容量のチェ
ックのためには、フォーマット・ライトしようとしてい
るレコードの一つ前のレコードのセグメント・ナンバ
（本来のＣＫＤフォーマットで、そのレコードのトラッ
ク上での相対位置を示す情報）とＫＬ，ＤＬから、後ど
れだけのサイズのレコードがライトできるか計算する。
フォーマット・ライトしたときは、必ずライトしたレコ
ード自身にそのレコードのセグメント・ナンバを書いて
おかなければならない。同時に、レコードの位置情報を
保持している制御情報に、そのレコードのカウント・フ
ィールドの位置を示す情報を書き足さなければならな
い。

【００５４】図９の右半分に前述した各方式の比較結果
をまとめた。「比較項目」の欄には前述した４つの比較
項目を記載している。各比較項目にはその重要度に応じ
５段階のグレード付けをしている。５がもっとも重要な
項目であり、１はあまり重要でない項目である。また、
この各比較項目の中で、５段階評価を行い、各変換方式
に１点から５点の点数を付与している。ある比較項目に
ついてもっとも良い変換方式に５点を付け、もっとも劣
る変換方式に１点を与えている。このようにして付けた
点数を各変換方式ごとに集計して、その変換方式の合計
得点としている。集計の方法は、各比較項目の素点にそ
の比較項目のグレードの値を掛けたものを全部の比較項
目について合計している。従って、合計得点の高い変換
方式ほど優れた変換方式ということになる。図９では、
この合計得点が従来の方式より高い変換方式の合計得点
欄に＊を付している。

【００５５】図９の合計得点は多分に主観的な面もあ
り、あくまで目安である。しかし、試しに点数の与え方
や各比較項目のグレードの値を多少振っても、従来の方
式と同等以上の得点になる変換方式は、やはり図９と同
じものであった。従って、今回の比較項目で考える限
り、良い目安になると考えられる。従来の方式がトップ
にならなかった理由は、おもに目的レコードを見つける
ときの手順におけるメモリ・アクセスの回数である。従
来の方式においては、ＦＢＡのブロック中の最初のレコ
ードは一発で見つけることができるが、その後ろのレコ
ードはそこから順番に後続のレコードのカウント・フィ
ールドを見つけて読んでいかなくてはならない。従来の
方式がこの点を重視しなかった理由は下記の２点が考え
られる。 （１）レコードの位置情報を持つ単位の問題 従来の方式はＦＢＡディスクのブロック（≒セクタ）ご
とにそこに含まれる最初のレコードの位置情報を持つと
している。現実のＳＣＳＩディスクなどでは、このブロ
ックの大きさはせいぜい１〜２ＫＢ程度であるのに対
し、そこに記録するＣＫＤのレコードのサイズは４ＫＢ
程度がもっとも多い。従って、現実には一つのＦＢＡブ
ロックにたくさんのＣＫＤレコードが含まれるケースよ
りも、図１０のように一つのＣＫＤレコードが複数のＦ
ＢＡブロックにまたがり、結局、一つのＦＢＡブロック
に含まれるＣＫＤレコードは１個以下というケースの方
が多いと考えられる。従って、Ｓｅｔ Ｓｅｃｔｏｒに
より、目的のレコードが含まれるＦＢＡブロックさえき
ちんと分かればほとんど１回のメモリ・アクセスで目的
レコードを見つけることができるので、この方式でもメ
モリ・アクセス回数が多くならない。 （２）トラック・バッファの置き場所の問題 従来の方式においては、このようなＣＫＤ−ＦＢＡ変換
を行うエミュレータは、チャネル・プロセッサとＦＢＡ
ディスクの間のどこにあってもよいとされているが（も
ちろんＤＫＣでもよいことになる）、エミュレータはチ
ャネル・プロセッサ自体が実行している。すなわち、デ
ィスク・キャッシュをベースとした大規模なシステムは
あまり意識していない。従って、トラック・イメージを
展開するトラック・バッファ用のメモリもホストＣＰＵ
の主記憶か、チャネル・プロセッサ自身のローカル・メ
モリを考えている。このように、特にトラック・バッフ
ァがチャネル・プロセッサ自身のローカル・メモリにあ
り、そのチャネル・プロセッサがＣＫＤ−ＦＢＡエミュ
レーションを行うような場合は、そこへのメモリ・アク
セス回数が少々多くても、あまり問題にはならない。

【００５６】これらの点から従来はあまりメモリ・アク
セスの回数という点を重視しなかったと考えられるが、
上記の２点はそれぞれ以下のような問題をはらんでい
る。 （１）レコードの位置情報を持つ単位の問題 従来の方式はＦＢＡディスクのブロック（≒セクタ）ご
とにそこに含まれる最初のレコードの位置情報を持つと
しているが、非効率的である。図１１に示すように、デ
ィスク・キャッシュをベースにした４台のデータ・ディ
スクと１台の冗長ディスクをもつアレイ型ディスク状態
（ＲＡＩＤ）を考える場合、物理ディスクへのリード／
ライトの単位はＦＢＡのブロックの様な細かい単位では
なく、例えば、ＣＫＤの１トラック分（例えば４８Ｋ
Ｂ）を各データ・ディスクに分割した１／４トラック分
である。従って、レコードの位置情報もＦＢＡごとよ
り、この１／４トラックごとに持った方がよい（図１１
参照）。１／４トラックごとに位置情報を持つのであれ
ば、１トラック分の位置情報は４箇所に集約されるの
で、ＣＫＤレコードがメモリ上でこの位置情報により分
断されるのも、この４箇所ですむ。しかし、従来方式の
ようにＦＢＡのブロックごとにレコードの位置情報を持
つとすると、１トラックの分断箇所も１トラックに含ま
れるＦＢＡブロックの個数になる。（１ブロック２ＫＢ
ととすると、１トラックで約２４箇所）すなわち、４Ｋ
ＢのＣＫＤレコードであれば必ず１レコード中１〜２箇
所分断されることになる。この分断箇所は特別なハード
ウェア（Ｈ／Ｗ）を用意しない限り磁気ディスク制御装
置のファームウェア（Ｆ／Ｗ）で処理することになる。
そのために数十μｓｅｃかかるとし、チャネルの転送レ
ートを４．５ＭＢ／ｓｅｃとすれば、４ＫＢのレコード
を転送するのにかかる時間が８８９μｓｅｃであるか
ら、１レコード当り数％〜１０％近い性能ダウンにつな
がる。これを避けるために図１１のように、１／４トラ
ックごとに位置情報を持たせることにすると、今度はそ
の中に含まれるＣＫＤレコード数が多くなるので、従来
方式ではメモリ・アクセス回数が多くなってしまう。

【００５７】（２）トラック・バッファの置き場所の問
題 従来の方式のように、トラック・バッファがチャネル・
プロセッサ自身のローカル・メモリにあり、そのチャネ
ル・プロセッサがＣＫＤ−ＦＢＡエミュレーションを行
うような場合は、そこへのメモリ・アクセス回数が少々
多くても、あまり問題にはならない。ところが、ディス
ク・キャッシュを前提に考えている大規模なシステムで
は、トラック・バッファも当然キャッシュ・メモリ上に
なる。キャッシュ・メモリ上のトラック・イメージを、
チャネルとの間でデータ転送したり、また、別のトラッ
ク・バッファに転送するのはそれ自体大きなオーバヘッ
ドとなる。一方、ＣＫＤ−ＦＢＡのエミュレーションは
チャネルとのデータ転送中リアル・タイムに行わなけれ
ばならないので、各チャネルとのデータ転送をつかさど
るＤＫＣ内のチャネル・パス・サーバ（ＣＰＳ）がエミ
ュレーションを行うことになる。従って、従来の方式で
は目的レコードを見つけるために、各チャネル・パス・
サーバは共有部分であるキャッシュ・メモリ上のトラッ
ク・バッファを頻繁にアクセスすることになる。このキ
ャッシュ・メモリへのアクセスはチャネル・パス・サー
バだけでなく、デバイス側からも行われる。つまりこの
キャッシュ・メモリはリード／ライトが高速で行われる
システムのボトル・ネック部分である。このような部分
に細かい単位で頻繁にアクセスすることは、それだけで
著しく内部バスのデータ転送能力を低くする原因とな
る。従って、このキャッシュ・メモリへのアクセスは少
々データ量が多くなっても、１回でアクセスする方式の
方がよい。以上のような理由から、メモリ・アクセスの
回数という点にも注目しているため、その部分で従来の
方式は若干点数を下げ、トップになっておらず、従来の
方式より高得点をあげているのは、このメモリ・アクセ
ス回数の点で有利な＜ケース ＩＩ−３＞を採用してい
る変換方式の中のものである。

【００５８】次に「ギャップの削除方法とメモリ容量の
評価」について説明する。ここでは、ＣＫＤフォーマッ
トのトラック・イメージをキャッシュ・メモリ（トラッ
ク・バッファ）上に展開してＦＢＡディスクに記録する
際、ギャップも含めてメモリ上に展開するか否かについ
て、前述した３方式についてそれぞれ具体的にメモリ容
量がどの程度異なるか評価する。

【００５９】ＣＫＤフォーマットのトラック・イメージ
をキャッシュ・メモリ（トラック・バッファ）上に展開
してＦＢＡディスクに記録する際、ギャップも含めてメ
モリ上に展開するか否かについては、 ＜ケース Ｉ−１＞ ・レコード間ギャップも含めすべてのギャップを削除し
てしまう。 ＜ケース Ｉ−２＞ ・レコード間ギャップだけ残し、フィールド間ギャップ
は取り除く。 ＜ケース Ｉ−３＞ ・レコード間ギャップだけでなく、すべてのフィールド
間ギャップも残す（ＥＣＣやパディングなどは取り除
く）。 という３種類の方式が考えられる。ここでは、これらの
各方式ごとにＣＫＤフォーマット１トラック分のトラッ
ク・イメージを展開するのに必要なメモリ容量（＝ＦＢ
Ａディスクのブロック数）を見積り比較、検討する。た
だし、＜ケース Ｉ−２＞、＜ケース Ｉ−３＞につい
ては、トラック容量のチェック方式として前述した＜ケ
ース ＩＩＩ−２＞（削除したフィールド間ギャップや
ＥＣＣ、パディングの分だけレコード間ギャップを伸ば
して、各レコードのトラックの先頭からの相対位置を元
のＣＫＤトラックのまま維持する方式）と組み合わせた
場合は、トラック・イメージのメモリ容量は常に元のＣ
ＫＤフォーマットと等しくなる。従って、ここではギャ
ップ長の調整は行なわない場合について見積りを行う。

【００６０】ＣＫＤフォーマットでは、ギャップの数は
１トラック中のレコード数及びキー・フィールドの有無
などに依存するため、ギャップの有無によるメモリ容量
の大小を見積もるには、見積もりを行うトラック中のレ
コード数などのトラック・フォーマットを規定する必要
がある。ここでは極端なケースとして、レコード数がも
っとも多い場合、もっとも少ない場合、また、標準的な
ケース等、図１２の４ケースについて見積もりを行う。
いずれも、ＣＫＤフォーマットとしては図３３を想定し
ている。それぞれのケースにおけるトラック当りのレコ
ード数の計算は図１３、図１４、図１５、図１６に示し
てある。図１２のフォーマット２，３は、ここでは述べ
ないが「ディスク・アクセスのワークロード・タイプ調
査」という調査に基づいて定めた。また、ジャーナル・
ファイルのレコード・サイズは２００Ｂ〜３２ＫＢであ
るが、もっともよく用いられているサイズは２００Ｂ〜
３００Ｂくらいであるので、図１２では２００Ｂを用い
ている。

【００６１】メモリ容量を見積もるに当り、ここでは、
下記のような条件で見積りを行う。 （１）トラック・フォーマットとしては図３３を使用す
る。 （２）各フィールドのＥＣＣ、３２Ｂ境界にあわせるた
めの０パディングは削除する。 （３）ＨＡ、カウント・フィールドのその他のパラメー
タはすべて残す。 （４）レコードの位置情報などのＣＫＤ−ＦＢＡ変換の
ための制御情報の容量はここでは見積もらない。これ
は、ギャップの削除方法とはまた別の条件であるので、
別途見積もる。結局、メモリ上ではギャップ以外の各フ
ィールドの中身は図３３のＸで示した部分のようになる
として見積りを行う。見積りケースごとのトラック当り
のレコード数を計算すると図１３〜図１６のようにな
る。

【００６２】また、各ギャップ削除方法ごとのメモリ容
量見積りは以下のようになる。 ＜ケース Ｉ−１＞ ・レコード間ギャップも含めすべてのギャップを削除し
てしまう。 ●フォーマット１（最多レコード数のケース） ＨＡのサイズ ＝４０−１２＝２８ Ｒ０のサイズ ＝Ｒ０Ｃ＋Ｒ０Ｄ＝（４０−１２）＋１
＝２９ Ｒｎのサイズ ＝ＲｎＣ＋ＲｎＤ＝（４０−１２）＋１
＝２９ よって、１トラック分の容量は、 ＨＡ＋Ｒ０＋Ｒｎ×９３＝２８＋２９＋２９×９３＝２
７５４ ●フォーマット２（ジャーナル・ファイルの典型） ＨＡのサイズ ＝４０−１２＝２８ Ｒ０のサイズ ＝Ｒ０Ｃ＋Ｒ０Ｄ＝（４０−１２）＋８
＝３６ Ｒｎのサイズ ＝ＲｎＣ＋ＲｎＤ＝（４０−１２）＋２
００＝２２８ よって、１トラック分の容量は、 ＨＡ＋Ｒ０＋Ｒｎ×６８＝２８＋３６＋２２８×６８＝
１５５６８ ●フォーマット３（ページング、スワッピング、ＶＳＡ
Ｍ） ＨＡのサイズ ＝４０−１２＝２８ Ｒ０のサイズ ＝Ｒ０Ｃ＋Ｒ０Ｄ＝（４０−１２）＋８
＝３６ Ｒｎのサイズ ＝ＲｎＣ＋ＲｎＤ＝（４０−１２）＋４
０９６＝４１２４ よって、１トラック分の容量は、 ＨＡ＋Ｒ０＋Ｒｎ×１０＝２８＋３６＋４１２４×１０
＝４１３０４ ●フォーマット４（最少レコード数のケース）） ＨＡのサイズ ＝４０−１２＝２８ Ｒ０のサイズ ＝Ｒ０Ｃ＋Ｒ０Ｄ＝（４０−１２）＋４
７９８８＝４８０１６ よって、１トラック分の容量は、 ＨＡ＋Ｒ０＝２８＋４８０１６＝４８０４４

【００６３】＜ケース Ｉ−２＞ ・レコード間ギャップだけ残し、フィールド間ギャップ
は取り除く（ＥＣＣやパディングなどは取り除く）。た
だし、フィールド間ギャップやＥＣＣ、パディングなど
を削除してもその分をギャップ長を伸ばしてつじつまを
合わせることにすると、メモリ容量は元のＣＫＤフォー
マットと全く同じになる。従って、ここでは削除分のつ
じつま合わせは行わないケースで見積りを行う。 ●フォーマット１（最多レコード数のケース） ＨＡのサイズ ＝Ｇ１＋ＨＡ=５０４＋（４０−１２）＝５３２ Ｒ０のサイズ ＝Ｇ２Ｃ＋Ｒ０Ｃ＋Ｒ０Ｄ＝２４８＋（４０−１２）＋１ ＝２７７ Ｒｎのサイズ ＝Ｇ３＋ＲｎＣ＋ＲｎＤ＝２１６＋（４０−１２）＋１ ＝２４５ よって、１トラック分の容量は、 ＨＡ＋Ｒ０＋Ｒｎ×９３＝５３２＋２７７＋２４５×９３＝２３５９４ ●フォーマット２（ジャーナル・ファイルの典型） ＨＡのサイズ ＝Ｇ１＋ＨＡ=５０４＋（４０−１２）＝５３２ Ｒ０のサイズ ＝Ｇ２Ｃ＋Ｒ０Ｃ＋Ｒ０Ｄ＝２４８＋（４０−１２）＋８ ＝２８４ Ｒｎのサイズ ＝Ｇ３＋ＲｎＣ＋ＲｎＤ＝２１６＋（４０−１２）＋２００ ＝４４４ よって、１トラック分の容量は、 ＨＡ＋Ｒ０＋Ｒｎ×６８＝５３２＋２８４＋４４４×６８＝３１００８ ●フォーマット３（ページング、スワッピング、ＶＳＡＭ） ＨＡのサイズ ＝Ｇ１＋ＨＡ=５０４＋（４０−１２）＝５３２ Ｒ０のサイズ ＝Ｇ２Ｃ＋Ｒ０Ｃ＋Ｒ０Ｄ＝２４８＋（４０−１２）＋８ ＝２８４ Ｒｎのサイズ ＝Ｇ３＋ＲｎＣ＋ＲｎＤ＝２１６＋（４０−１２）＋４０９６ ＝４３４０ よって、１トラック分の容量は、 ＨＡ＋Ｒ０＋Ｒｎ×１０＝５３２＋２８４＋４３４０×１０＝４４２１６ ●フォーマット４（最少レコード数のケース） ＨＡのサイズ ＝Ｇ１＋ＨＡ=５０４＋（４０−１２）＝５３２ Ｒ０のサイズ ＝Ｇ２Ｃ＋Ｒ０Ｃ＋Ｒ０Ｄ＝２４８＋（４０−１２） ＋４７９８８＝４８２６４ よって、１トラック分の容量は、 ＨＡ＋Ｒ０＝５３２＋４８２６４＝４８７９６

【００６４】＜ケース Ｉ−３＞ ・レコード間ギャップだけでなく、すべてのフィールド
間ギャップも残す（ＥＣＣやパディングなどは取り除
く）。この場合も、ＥＣＣ、パディングなどを削除して
もその分をギャップ長を伸ばしてつじつまを合わせるこ
とにすると、メモリ容量は元のＣＫＤフォーマットと全
く同じになる。従って、ここでは削除分のつじつま合わ
せは行わないケースで見積りを行う。 ●フォーマット１（最多レコード数のケース） ＨＡのサイズ ＝Ｇ１＋ＨＡ=５０４＋（４０−１２）＝５３２ Ｒ０のサイズ ＝Ｇ２Ｃ＋Ｒ０Ｃ＋Ｇ２＋Ｒ０Ｄ＝２４８＋（４０−１２） ＋２２４＋１＝５０１ Ｒｎのサイズ ＝Ｇ３＋ＲｎＣ＋Ｇ２＋ＲｎＤ＝２１６＋（４０−１２） ＋２２４＋１＝４６９ よって、１トラック分の容量は、 ＨＡ＋Ｒ０＋Ｒｎ×９３＝５３２＋５０１＋４６９×９３＝４４６５０ ●フォーマット２（ジャーナル・ファイルの典型） ＨＡのサイズ ＝Ｇ１＋ＨＡ=５０４＋（４０−１２）＝５３２ Ｒ０のサイズ ＝Ｇ２Ｃ＋Ｒ０Ｃ＋Ｇ２＋Ｒ０Ｄ＝２４８＋（４０−１２） ＋２２４＋８＝５０８ Ｒｎのサイズ ＝Ｇ３＋ＲｎＣ＋Ｇ２＋ＲｎＤ＝２１６＋（４０−１２） ＋２２４＋２００＝６６８ よって、１トラック分の容量は、 ＨＡ＋Ｒ０＋Ｒｎ×６８＝５３２＋５０８＋６６８×６８＝４６４６４ ●フォーマット３（ページング、スワッピング、ＶＳＡＭ） ＨＡのサイズ ＝Ｇ１＋ＨＡ=５０４＋（４０−１２）＝５３２ Ｒ０のサイズ ＝Ｇ２Ｃ＋Ｒ０Ｃ＋Ｇ２＋Ｒ０Ｄ＝２４８＋（４０−１２） ＋２２４＋８＝５０８ Ｒｎのサイズ ＝Ｇ３＋ＲｎＣ＋Ｇ２＋ＲｎＤ＝２１６＋（４０−１２） ＋２２４＋４０９６＝４５６４ よって、１トラック分の容量は、 ＨＡ＋Ｒ０＋Ｒｎ×１０＝５３２＋５０８＋４５６４×１０＝４６６８０ ●フォーマット４（最少レコード数のケース）） ＨＡのサイズ ＝Ｇ１＋ＨＡ=５０４＋（４０−１２）＝５３２ Ｒ０のサイズ ＝Ｇ２Ｃ＋Ｒ０Ｃ＋Ｇ２＋Ｒ０Ｄ=２４８＋（４０−１２） ＋２２４＋４７９８８＝４８４８８ よって、１トラック分の容量は、 ＨＡ＋Ｒ０＝５３２＋４８４８８＝４９０２０

【００６５】図１７に＜ケース Ｉ−１＞〜＜ケース
Ｉ−３＞までの３種類のギャップ削除方法について、そ
れぞれフォーマット１〜４までの４つのトラック・フォ
ーマットをメモリ上に展開したときのメモリ容量を示
す。図１８はこれをグラフで表したものである。

【００６６】図１７、図１８から分かるようにどのトラ
ック・フォーマットでも、＜ケースＩ−１＞〜＜ケース
Ｉ−３＞と残すギャップが多いほどメモリ容量も多く
必要となっている。＜ケース Ｉ−３＞ではすべてのギ
ャップを残すため、どのフォーマットにおいてもほぼ元
のＣＫＤフォーマットでの容量と等しいメモリ容量が必
要となる。フィールド間ギャップを削除している＜ケー
ス Ｉ−２＞でも、トラック容量のチェック方式とし
て、削除したフィールド間ギャップやＥＣＣ、パディン
グの分だけレコード間ギャップを伸ばし、各レコードの
トラックの先頭からの相対位置を元のＣＫＤトラックの
まま維持する方式をとると、必要なメモリ容量は＜ケー
ス Ｉ−３＞とほぼ同じになる。これに対し、すべての
ギャップを削除する＜ケース Ｉ−１＞では、特にレコ
ード・サイズが小さいフォーマット１、２でメモリ容量
が顕著に小さくなっている。９３レコードのフォーマッ
ト１では他の方式の１６〜１７分の１、フォーマット２
でも約３分の１である。このようにトラック・イメージ
を展開するためのメモリ容量が少なくてすむと下記のよ
うなメリットが考えられる（図１９参照）。 （１）キャッシュ・メモリの管理の単位をＣＫＤの１ト
ラック分（約４８ＫＢ）でなく、もっと細かい単位（例
えばデータ・ディスク１台分に書く単位＝１／４トラッ
ク分・・・１２ＫＢ）にすれば、余ったキャッシュ・メ
モリの領域には他のトラックのデータを書くことができ
る。従って、同一のキャッシュ・メモリ容量でより多く
のトラックのデータを保持することができ、キャッシュ
・メモリの利用率向上、引いていはヒット率の向上を期
待することができる。 （２）１トラック分のイメージのデータ量が少なくてす
むということは、物理ディスクへそのデータを書くとき
も少ないデータ量ですむということである。例えば、１
トラック分のイメージのデータがＣＫＤフォーマットの
１／２ですめば、物理ディスクへのデータ転送はデータ
・ディスク１と２、及びパリティ・ディスクだけです
み、フォーマット・ライトでなければデータ・ディスク
３と４にはデータを転送しなくてよい。これは、サブシ
ステム内の各バス等の負荷軽減につながる。ただし、メ
モリ容量が少なくすんでも、物理ディスク上の領域は最
大値に合わせ確保しておかないと制御が非常に複雑にな
る。メモリ上のトラック・イメージがＣＫＤフォーマッ
トの半分だからといって、そのデータをディスクに書く
ときも空いた領域に他のトラックのデータを書いてしま
うと、次にそのトラックが再フォーマットされて、トラ
ック・イメージの量が増えてしまったとき、ディスク上
の連続した領域にはトラック・イメージをライトできな
くなり、ディスク上でどこか空いている領域を探してラ
イトするようなことになる。トラック・イメージのデー
タ量が減った場合、その分物理ディスクの空き領域も有
効に活用できればよりよいが、（１），（２）のメリッ
トだけでも十分魅力的である。 以上のように、メモリ容量の大小を実際に見積もった結
果、ギャップをすべて残した場合と、ギャップをすべて
削除した場合では、レコード数によっては必要なメモリ
容量が数倍以上の開きがでることがわかる。

【００６７】次に、「レコードの位置情報のメモリ容量
見積り」について説明する。目的レコードの位置決めを
行う方式として、＜ケース ＩＩ−１＞と＜ケースＩＩ
−２＞と＜ケース ＩＩ−３＞の３方式をあげた。これ
らのうち、＜ケース ＩＩ−１＞を除く他の２方式は、
いずれもレコードそのものとは別個に、メモリ上でのレ
コードの位置を示す制御情報を保持する方式である。こ
こでは、この位置決めのための制御情報に各方式でどの
程度メモリ容量（＝ＦＢＡディスク上での容量）が必要
なのか見積りを行う。ここでは＜ケース ＩＩ−１＞を
除く、＜ケース ＩＩ−２＞と＜ケース ＩＩ−３＞に
ついて、見積りを行う。また、＜ケース ＩＩ−３＞で
は、レコードの位置情報は全レコード分を一括して一箇
所に保持する方法（例えば、トラックの先頭）と、分散
して保持する方法（例えば、各ＦＢＡブロックの先頭に
そのＦＢＡブロックに含まれるレコードの位置を示す情
報を保持する）があるが、ここでは、分散して保持する
方法について見積りを行う。全レコード分を一括して一
箇所に保持する方法について見積もらない理由は以下の
とおりである。位置情報を一箇所で一括して保持してい
ると、図１９のようなアレイ型ディスク装置を考えた場
合、４台のデータ・ディスクから１ＣＫＤトラック分の
データを読んでくるとき、目的レコードが記録されてい
るディスクからのデータを読み終えても、位置情報が記
録されているディスクからのデータを読み終らないと、
目的レコードの記録位置を見つけることができず、ホス
トとのデータ転送を開始できない。従って、回転同期を
サポートできなかった場合や、サポートしていてもスタ
ンバイ・ディスクが加わって同期が崩れているときなど
に平均回転待ち時間の増加につながる。

【００６８】ここでは、見積り条件を以下のようなもの
とする。まず、レコード１個当りの保持情報として、レ
コード１個につき、下図のような４バイトの情報を保持
するものとする。 レコードＮｏ．：記録されているＣＫＤレコードのレコ
ードＮｏ．である。＜ケース ＩＩ−２＞では制御上必
ずしも必須ではないが、特に＜ケース ＩＩ−３＞では
制御情報中にこのレコードＮｏ．を持っていると、いち
いち実際のレコードのカウント・フィールドを読まなく
ても一発で目的レコードを発見することができる。 セクタ値 ：ＣＫＤレコードとして記憶されている
場合のセクタ値を記憶する。このセクタ値によりセット
セクタコマンドで指定されたセクタ値との比較が可能に
なる。また、このセクタ値によりそのレコードのトラッ
ク先頭からの相対位置を求めることができ、既に消費し
た容量が判定できる。セクタは７つのセグメントから構
成されているため、このセクタ値を用いてセグメントナ
ンバを計算することが可能である。すなわち、セグメン
トナンバ＝セクタ値×７である。 メモリ・アドレス：記録されているＣＫＤレコードのメ
モリ上でのバイト・アドレスである。２Ｂあれば６４Ｋ
Ｂまでアドレッシングできるので、図３３のフォーマッ
トでは十分である。アドレスの起点は、ＣＫＤトラック
の先頭にするか、位置情報の管理単位である各ＦＢＡブ
ロック等の先頭にするかは、とりあえず問わない。

【００６９】また、ＣＫＤレコードの位置情報を管理す
る単位（レコードの位置情報を保持する単位）としては
図２１の２ケースについて見積りを行う。上記の２つの
ケースにおいて、＜ケース ＩＩ−２＞と＜ケース Ｉ
Ｉ−３＞のそれぞれについて記録されているＣＫＤレコ
ードの位置情報を持つためのメモリ容量を見積もる。見
積り結果は以下のとおりである。 ＜ケース ＩＩ−２＞ ：先頭のレコードの位置情報だ
け保持する。この方式では、位置情報の管理単位のサイ
ズにかかわらず、常に管理単位ごとレコード１個分の位
置情報しか保持しないので、位置情報のためのメモリ容
量は管理単位ごとに４Ｂである。 ＜ケース ＩＩ−３＞ ：すべてのレコードの位置情報
を保持する。この方式では、管理単位の大きさによっ
て、そこに記録され得るＣＫＤのレコード数が異なって
くる。さらに、あるサイズの管理単位にどのくらいのＣ
ＫＤレコードが記録できるかは、ギャップの削除方法に
も依存するが、ここでは、もっともレコード数が多くな
る＜ケース Ｉ−１＞（すべてのギャップを削除する）
を採用して見積りを行う。このときの１レコード当りの
最少メモリ容量は、前述した「ギャップの削除方法とメ
モリ容量の評価」の「＜ケース Ｉ−１＞のフォーマッ
ト１（最多レコードのケース）」のＲｎのサイズより、
２９Ｂであることが分かっている。従って、各管理単位
のサイズごとに記録できる最多レコード数ＮＲは、位置
情報のためのメモリ容量をαとすると ＮＲ＝｛（管理単位のサイズ）−α｝÷２９Ｂ ・・・（１） また、管理単位当りの位置情報のメモリ容量αはそのレ
コード数ＮＲに４Ｂを掛ければよいので、 α＝ＮＲ×４Ｂ ・・・（２） で求められる。この２式を解くと、 ＮＲ＝（管理単位のサイズ）／３３ （小数点以下切捨て）・・・（３） となる。従って、（３）式で求めたＮＲを（２）式に代
入することにより、ただちにαも求められる。ただし、
図３３のトラック・フォーマットでは１トラック内のレ
コード数は９４個を越えることはないので（Ｒ０も含
む）、ＮＲの最大値も９４である。以上の結果をまとめ
ると図２２のようになる。

【００７０】前述した「ギャップの削除方法とメモリ容
量の評価」によれば、ＣＫＤレコードを記録するために
正味必要なメモリ容量の最大値は、１トラック１レコー
ド（Ｒ０のみ）でそのデータ・フィールドが最長の場合
である。このとき必要なメモリ容量は、図１７からＨ
Ａ、Ｒ０合わせて図２３のようになる。ＣＫＤトラック
１本のために用意するＦＢＡディスクの容量を４８ＫＢ
（１２ＫＢ×４）とすると、制御情報のために使用でき
るメモリ容量は下式のようになる。 ＜ケース Ｉ−１＞ １０２４×４８−４８０４４＝１１０８ ＜ケース Ｉ−２＞ １０２４×４８−４８７９６＝ ３５６ ＜ケース Ｉ−３＞ １０２４×４８−４９０２０＝ １３２ この値と図２２の値（一番右側の欄）を比較すると、＜
ケース ＩＩ−２＞では、管理単位のサイズにかかわら
ずメモリ容量が不足するという問題ない。これに対し、
＜ケース ＩＩ−３＞では管理単位が大きく（管理単位
２サイズ１２ＫＢ）、位置情報のためのメモリ容量が少
ない場合（１５０４Ｂ）と、レコードのためのメモリ容
量がもっとも少なくて済む＜ケース Ｉ−１＞で比べて
みても位置情報のために使用できるメモリ容量約４００
Ｂが不足してしまう。

【００７１】＜ケース ＩＩ−３＞は目的レコードを探
すためのメモリ・アクセス回数が少なく、従来の方式
（＜ケース ＩＩ−２＞）より有望であるので、この不
足分に対する対策を考える必要がある。この対策として
は、下記のようなものが考えられる。 対策１ 物理ディスク１台当りにリザーブする容量を増
やす。 ｅｘ．） １２ＫＢ→１３ＫＢとすると、ＣＫＤトラッ
ク１本のために使用できる容量は、５２ＫＢととなり、
不足は一挙に解決される。・・・・物理ディスクは５２ＫＢ
／ＣＫＤトラック必要となり、４８ＫＢ／ＣＫＤトラッ
クに比べてディスクエリアが無駄になるが、物理ディス
クのコストが減少してきているので有効な方法のひとつ
である。 対策２ レコード１個当りに必要な制御情報の量を減ら
す。 ｅｘ．） ４Ｂ／レコード→２Ｂ／レコードとすると、
制御情報に必要な総メモリ容量は、７５２Ｂとなり不足
しなくなる。 対策３ 制御情報の個数を減らす。 ｅｘ．） この見積りでは、管理単位２の場合（サイズ
１２ＫＢ）、４つの各管理単位ごとに最大９４個のレコ
ードの位置情報を保持するように考えている。しかし、
実際は４つの管理単位の合計でＭａｘ．９４個が必要で
あるので、うまく工夫して、制御情報の総容量を減らす
ことを考える。

【００７２】以上のように「レコードの位置情報のメモ
リ容量見積り」の結果は以下のとおりである。＜ケース
ＩＩ−２＞では、メモリ容量は不足せず問題ない。＜
ケース ＩＩ−３＞では条件によっても異なるが、位置
情報のために使用できるメモリ容量が若干不足してしま
う。＜ケース ＩＩ−３＞は目的レコードを探すための
メモリ・アクセス回数が少なく、有望であるので、今
後、この不足分に対する対策を考える必要がある。

【００７３】次に、「レコードの位置情報の制御方式の
改善」について説明する。先の見積りの制御方式の問題
点は以下のとおりである。前述した「レコードの位置情
報のメモリ容量見積り」では、ＣＫＤレコードの位置情
報を管理する単位(レコードの位置情報を保持する単位)
ごとに、そこに記録され得る最大レコード数に合わせて
位置情報の領域を確保していた。具体的にいうと、図２
４に示すように、管理単位のサイズを１２ＫＢとしたと
きは、そこに最大９４個のＣＫＤレコードが記録され得
る。レコード１個当りの位置情報としては４ｂｙｔｅを
見積もっていたので、１２ＫＢの管理単位ごとに ４Ｂ×９４＝３７６Ｂ だけの位置情報領域を見積もっていた。ＣＫＤトラック
１本分のトラック・イメージはこの１２ＫＢの管理単位
４個からなっており、ＣＫＤトラック１本当りの位置情
報のメモリ容量は、 ３７６Ｂ×４＝１５０４Ｂ となってしまう。しかし、これでは、ＣＫＤトラック１
本当り９４×４＝３７６レコード分の位置情報の領域を
確保していることになる。図３３のフォーマットでは、
１ＣＫＤトラックの最大レコード数は９４レコード（Ｒ
０含む）であるので、１２ＫＢの各管理単位に記録され
得る最大レコード数がそれぞれ９４個であっても、同時
に全部の管理単位に９４個ずつのレコードが記録される
ことはあり得ない。従って、９４×３＝２８２レコード
分の位置情報の領域は無駄になっていることになる。

【００７４】このような問題点は、レコードの管理単位
内の位置情報領域のサイズを固定にしようとしたことか
ら発生している。位置情報領域のサイズを固定にする
と、（１）管理単位にまたがって記録されているレコー
ドのデータ転送を行うときも、飛び越さなければならな
い位置情報領域のサイズが常に一定なので、制御が簡単
であること、（２）フォーマット・ライト時も、ＣＫＤ
レコードを書き込めるメモリの領域が固定なので、制御
が簡単であること、などの利点が発生する。しかし、位
置情報領域のサイズを固定にする限り、そのサイズは最
大値に合わせざるを得ず、管理単位ごとに９４レコード
分の領域を確保しておくほかない。これに対し、位置情
報領域のサイズを可変にすると、実際に記録されている
レコードの分だけしか位置情報領域を使用しないような
制御も可能であるが、上記のような利点は基本的に失わ
れてしまう。位置情報の総容量を減らすためには、各管
理単位の位置情報領域のサイズを可変にすることが必須
であるが、このような欠点をうまく回避することが重要
である。

【００７５】図２５に位置情報領域のサイズを可変にし
た改善案を示す。以下、この図を基に改善案の説明を行
う。なお、以降はレコードの位置情報の管理単位のサイ
ズはデータ・ディスクへの分割単位のサイズと同じ１２
ＫＢの場合について取り扱う。従来の方式と同じＦＢＡ
ディスクのブロック(セクタ)・サイズと同じ１〜２ＫＢ
では効率が悪いからである（詳細は、前述した「レコー
ドの位置情報を持つ単位の問題」を参照のこと）。ま
た、以後、図２５に示すように、レコードの位置情報の
管理単位のことはフレーム、実際にＣＫＤレコードを記
録する領域のことはレコード・フレーム、制御情報を記
録する領域はコントロール・フレーム、レコードの位置
情報のことはレコード・ポインタ、と呼ぶ。この方式の
ポイントは下記のような点である。 （１）実際に記録されているレコードの分だけしかレコ
ード・ポインタを使用しない。これにより、レコード・
ポインタ領域のサイズは最大でも、１ＣＫＤトラック当
り、 ４ｂｙｔｅ×９４＝３７６ｂｙｔｅ で済む。 （２）レコード・ポインタを含むコントロール・フレー
ムのサイズは、別途、制御情報（図２５のコントロール
・フレーム・ポインタ）として保持している。この情報
により、コントロール・フレームのサイズが可変となっ
ても、制御を複雑にせずに済ませる。 （３）これらの制御情報（コントロール・フレーム）
は、各フレームの先頭ではなく、最後尾に記録する。ま
た、コントロール・フレーム内のレコード・ポインタも
後ろから順番に並べていく。（実際のレコードがレコー
ド・フレーム内で前にあるものほど、それに対応するレ
コード・ポインタはコントロール・フレーム内で後ろに
くる）。これにより、フォーマット・ライト時の制御も
簡単に行える。

【００７６】以下、実際のリード／ライトの動きに従っ
て、フレーム内のレコードの位置決め制御の方法をもう
少し詳細に説明する。 （１）リード／アップデート・ライト時 （ａ）物理ディスクからフレームをキャッシュ・メモリ
上に読み込んできたら、その最後尾のコントロール・フ
レームをＣＰＳが読み取る。このとき、コントロール・
フレームのサイズは読んでみるまで分からないわけであ
るが、とりあえず、フレームの最後尾の適当なバイト数
をまとめて読んでみる。（このとき読み取るバイト数
は、ＣＰＳやキャッシュ・メモリ、バスなどのアーキテ
クチャにより最適値を選択する必要がある。）例えば、
フレームの最後尾３２Ｂを読み取ることにすると、この
フレーム内に記録されているレコード数が７個以下の場
合は、ＣＰＳはこの１回のアクセスですべてのレコード
のレコード・ポインタを取得することができる。例えば
４ＫＢサイズをもっとも多いレコードサイズとする場
合、１フレーム中のレコード数は３個以下であるから、
大部分の場合は、この１回のキャッシュメモリ・アクセ
スですべてのレコード・ポインタを取得できることにな
る。 （ｂ）読み取ったコントロール・フレームの最後尾のコ
ントロール・フレーム・ポインタ中のメモリ・アドレス
から、コントロール・フレームをまだ読み残している
か、否か、判断できる。もし、コントロール・フレーム
を読み残していれば、ＣＰＳはそれを読み取る。これに
より、ＣＰＳは最悪でも２回のメモリ・アクセスですべ
てのレコード・ポインタを取得できることになる。 （ｃ）次に、ホストから送られてくるサーチのアーギュ
メントと取得したレコード・ポインタから、目的レコー
ドのフレーム上のメモリ・アドレスを見つける（これで
オリエンテーションが確立したことになる）。 （ｄ）ホストとの間でデータ転送を開始する前に、目的
レコードのメモリ・アドレスにカウント・フィールドの
サイズ、ＫＬ，ＤＬを加えた値（目的レコードの最後尾
のメモリ・アドレス）と、コントロール・フレーム・ポ
インタ中のコントロール・フレームの先頭を示すメモリ
・アドレスを比較する。もし、目的レコードの最後尾の
メモリ・アドレスがコントロール・フレームに食い込ん
でいるような場合は、ＣＰＳはホストとのデータ転送を
コントロール・フレームの手前で一端停止し、メモリ・
アドレスを次のフレームの先頭まで進めてから、ホスト
とのデータ転送を再開するような制御を行う。目的レコ
ードの最後尾がレコード・フレーム内に収まっていれ
ば、上記のような制御は不要で、ＣＰＳは、目的レコー
ドのデータ転送を途中で中断することなく完了すること
ができる。 （ｅ）引き続き、ホストからリード／アップデート・ラ
イト系のコマンドが出された場合は、次のレコードはそ
のままメモリ上で連続しているので、レコード・ポイン
タを使用しなくてもそのままデータ転送を続けることが
できる。ただし、レコードの最後尾のメモリ・アドレス
と、コントロール・フレームの先頭アドレスの比較は、
各レコードごとに行わなくてはならない。

【００７７】（２）フォーマット・ライト時 （２．１）同一フレーム内でレコードを書き足す場合 （ａ）物理ディスクからフレームをキャッシュ・メモリ
上に読み込んできたら、その最後尾のコントロール・フ
レームをＣＰＳが読み取る。 （ｂ）コントロール・フレーム・ポインタを調べ、すべ
てのレコード・ポインタを取得する。 （ｃ）次に、ホストから送られてくるサーチのアーギュ
メントと取得したレコード・ポインタから、目的レコー
ドのフレーム上のメモリ・アドレスを見つける（これで
オリエンテーションが確立したことになる）。 以上の（ａ）〜（ｃ）手順は、リード／アップデート・
ライト時と同じである。 （ｄ）ホストから送られてくるＷｒｉｔｅ ＣＫＤのカ
ウント・フィールドの値からトラック・オーバランを発
生しないか否かを調べる。（この詳細な手順は、別途、
「トラック容量のチェック方式」として説明する。）ト
ラック・オーバランを発生する場合は、以降の制御でト
ラック・オーバラン・ポイントまでデータ転送を行い、
ホストにトラック・オーバランを報告するような制御を
行う。トラック・オーバランのチェックが終ったら、Ｃ
ＰＳが自分で保持しているコントロール・フレーム・ポ
インタ中のコントロール・フレームの先頭を示すメモリ
・アドレスを４Ｂ減じ（コントロール・フレームを４Ｂ
拡張する）、さらに、新しく書き足すレコードのレコー
ド・ポインタをＣＰＳが保持しているコントロール・フ
レームの先頭に書き足す。 （ｅ）Ｗｒｉｔｅ ＣＫＤのカウント・フィールドの値
から新しく書き足すレコードの最後尾のメモリ・アドレ
スを計算し、（ｄ）で更新したコントロール・フレーム
・ポインタ中のメモリ・アドレスと比較する。もし、新
しいレコードの最後尾のメモリ・アドレスがコントロー
ル・フレームに食い込んでいるような場合は、ＣＰＳは
ホストとのデータ転送をコントロール・フレームの手前
で一端停止し、メモリ・アドレスを次のフレームの先頭
まで進めてから、ホストとのデータ転送を再開するよう
な制御を行う。新しいレコードの最後尾がレコード・フ
レーム内に収まっていれば、上記のような制御は不要
で、ＣＰＳは新しいレコードのデータ転送を途中で中断
することなく完了することができる。 （ｆ）引き続き、ホストからＷｒｉｔｅＣＫＤコマンド
が出された場合は、次のレコードはそのままメモリ上で
連続しているので、レコード・ポインタを使用しなくて
もそのままデータ転送を続けることができる。ただし、
トラック・オーバランのチェック、コントロール・フレ
ーム・ポインタの更新、レコード・ポインタの追加、レ
コードの最後尾のメモリ・アドレスと、コントロール・
フレームの先頭アドレスの比較は、各レコードごとに行
わなくてはならない。 （ｇ）コマンドが終了した場合は、ＣＰＳが保持してい
た更新後のコントロール・フレームをキャッシュ・メモ
リ上に書き出す。

【００７８】なお、図２６に示すようなケースではレコ
ード・フレームが３バイト空いているからといって、引
き続き同じフレーム中にレコードを追加しようとしてレ
コード・ポインタを追加すると、レコード・ポインタが
前のレコードの後部に食い込んでしまうことになる。す
なわち、フレームの空き容量が４バイト以下の場合は、
同じフレーム中に新たなレコードは追加できず、次のフ
レームを使用しなくてはならない。このようにして生じ
てしまった空きバイト（４バイト以下）は、コントロー
ル・フレーム中に含めて管理してしまった方が、（ｅ）
のデータ転送時のコントロール・フレームの飛び越しな
どがやりやすい。従って、コントロール・フレーム・ポ
インタ中のメモリ・アドレスはこの空きバイトの先頭ア
ドレスを示すことになる。この空きバイトの先頭から、
レコード・ポインタの先頭アドレスまでのオフセット
（０〜４バイト）は、コントロール・フレーム中の制御
情報として保持しておいて、（ｂ）のレコード・ポイン
タの取得の際、コントロール・フレーム・ポインタ中の
メモリ・アドレスからこのオフセット値を引いてレコー
ド・ポインタの先頭アドレスを求めればよい。

【００７９】（２．２）同一フレーム内で最初にレコー
ドを書く場合 トラックの先頭から全く新しくフォーマットし直す場合
や、レコードが一つも記録されていなかったフレームに
フォーマット・ライトで新しくレコードを書く場合など
は、ＣＰＳがコントロール・フレームを新しく生成する
ことになる。従って、この場合は、（２．１）の（ａ）
〜（ｃ）のコントロール・フレームの取得によるオリエ
ンテーションの確立作業は不要である。（ｄ）のトラッ
ク・オーバランのチェックは（２．１）と同様に行う。 （ｅ）トラック・オーバランのチェックが終ったら、Ｃ
ＰＳが自分のメモリ上にコントロール・フレーム・ポイ
ンタ（コントロール・フレームの先頭アドレスはレコー
ド・ポインタ１個分のところを示す。）を生成し、さら
に、新しく書くレコードのレコード・ポインタをＣＰＳ
が保持しているコントロール・フレームの先頭に書く。 （ｆ）Ｗｒｉｔｅ ＣＫＤのカウント・フィールドの値
から新しく書くレコードの最後尾のメモリ・アドレスを
計算し、（ｅ）で生成したコントロール・フレーム・ポ
インタ中のメモリ・アドレスと比較する。もし、新しい
レコードの最後尾のメモリ・アドレスがコントロール・
フレームに食い込んでいるような場合は、ＣＰＳはホス
トとのデータ転送をコントロール・フレームの手前で一
端停止し、メモリ・アドレスを次のフレームの先頭まで
進めてから、ホストとのデータ転送を再開するような制
御を行う。新しいレコードの最後尾がレコード・フレー
ム内に収まっていれば、上記のような制御は不要で、Ｃ
ＰＳは新しいレコードのデータ転送を途中で中断するこ
となく完了することができる。 （ｇ）引き続き、ホストからＷｒｉｔｅ ＣＫＤコマン
ドが出された場合は、（２．１）と同様となる。 （ｈ）コマンドが終了した場合は、ＣＰＳが保持してい
た新しいコントロール・フレームをキャッシュ・メモリ
上に書き出す。フォーマット・ライト系の処理では、そ
のフレームに記録するレコード数が分かってからでない
と、コントロール・フレームのサイズが確定しない。従
って、コントロール・フレームをフレームの先頭におい
てしまうと、最初のレコードをフレームのどこから書き
始めたらよいのか分からないことになってしまう。 本方式では、上述のようにレコードはフレームの先頭か
ら書き始め、コントロール・フレームはフレームの最後
尾から書き始めることにより、このような問題を回避し
ている。

【００８０】次に、この改善案による位置情報のメモリ
容量の見積りを行う。この改善案による位置情報のメモ
リ容量について、前述した「レコードの位置情報のメモ
リ容量見積り」で見積もったケースのうち図２２の管理
単位２のケースについて見積りを行い、改善効果を見
る。このケースは、管理単位（フレーム）サイズは１２
ＫＢで、レコード数は位置情報（レコード・ポインタ）
がもっとも多くなる９４レコード／ＣＫＤトラックの場
合について、メモリ容量を見積もっている。このケース
では、ギャップの削除方法にもよるが、すべてのギャッ
プを削除してしまう場合では、すべてのレコードが一つ
目のフレームに収まってしまう（「ギャップの削除方法
とメモリ容量の評価」参照）。このとき、本改善案で
は、一つ目のフレームのコントロール・フレームにレコ
ード・ポインタが９４個、コントロール・フレーム・ポ
インタが１個あって、他のフレームに制御情報は特にな
い（というより、他のフレームそのものが要らない）。
従って、位置情報の制御に必要なメモリ容量は、 ４Ｂ×９５＝３８０Ｂ である。この結果と、「レコードの位置情報のメモリ容
量見積り」で見積もった他のケースとの比較を図２７に
示す。＜ケース ＩＩ−２＞は従来の方式で、各ＦＢＡ
ブロック（ここでは、フレーム）の先頭に位置するレコ
ードの位置だけを保持する方式である。＜ケース ＩＩ
−３＞はすべてのレコードの位置情報を保持する方式
で、本改善前の方式である。＜ケース ＩＩ−３＞改が
本方式である。

【００８１】「レコードの位置情報のメモリ容量見積
り」において示したように、ＣＫＤレコードを記録する
ために正味必要なメモリ容量の最大値は、１トラック１
レコード（Ｒ０のみ）でそのデータ・フィールドが最長
の場合である。このとき必要なメモリ容量は、図２３か
ら引用すると図２８のようになる。ＣＫＤトラック１本
のために用意するＦＢＡディスクの容量を４８ＫＢ（１
２ＫＢ×４台）とすると、制御情報のために使用できる
メモリ容量は下式のようになる。 ＜ケース Ｉ−１＞ １０２４×４８−４８０４４＝１１０８ ＜ケース Ｉ−２＞ １０２４×４８−４８７９６＝ ３５６ ＜ケース Ｉ−３＞ １０２４×４８−４９０２０＝ １３２ この値と図２７の＜ケース ＩＩ−３＞改の位置情報の
メモリ容量３８０Ｂと比較すると、ギャップを全部削除
してしまう＜ケース Ｉ−１＞以外ではメモリ容量が足
りなくなるように見える。しかし、図２７の値は、レコ
ード数が９４レコードで位置情報（コントロール・フレ
ーム）のメモリ容量がもっとも多くなるときの値である
のに対し、上の値は１トラック１レコードで、ＣＫＤレ
コードのためのメモリ容量が最大の場合の値である。本
改善案では、レコード数が少なくなると、比例してコン
トロール・フレームのメモリ容量も少なくなり、１トラ
ック１レコードの場合では、２０Ｂで済んでしまう（レ
コード・ポインタ１個、コントロール・フレーム・ポイ
ンタ４個）。結局、本改善方式ではすべての場合につい
て、メモリ容量は足りることになる。（ただし、トラッ
ク容量のチェック方式として、＜ケース ＩＩＩ−３
＞、すなわち、各レコードのＣＫＤフォーマットでの相
対位置を保持するために、ＥＣＣやパディング等削除し
た分をギャップを伸ばして調整する方式をとると、９４
レコードの場合などメモリ容量が足りなくなる可能性も
ある。）また、目的レコードの位置決めのためのメモリ
・アクセスもフレーム当り１回〜２回で済む。このとき
に一度ＣＰＳがコントロール・フレームをキャッシュ・
メモリから取得してしまえば、後の制御ではＣＰＳはこ
の取得したコントロール・フレームを使用すればよいの
で制御のためのメモリ・アクセスは不要である。フォー
マット・ライトなどでフレーム内のレコードの構成が変
わった場合も、ＣＰＳが取得しているコントロール・フ
レームを更新しておいて、最後にキャッシュ・メモリに
書き出せばよい。ホストとのデータ転送中のコントロー
ル・フレームの飛び越し制御や、フォーマット・ライト
時の制御などもＣＰＳが保持しているコントロール・フ
レーム・ポインタ中のメモリ・アドレスのチェックをす
るだけでよく、このような操作はレコード間ギャップ相
当の時間中に実行してしまうので、オーバ・ヘッドにな
らない。以上より、この改善方式は初期の目的を十分達
成したといえる。

【００８２】次に、「セグメント・ナンバを用いたトラ
ック容量のチェック方式の検討」を行なう。ＣＫＤ−Ｆ
ＢＡ変換方式を特徴付ける三つのポイントとして、 ＜Ｉ＞ギャップの削除方法 ＜ＩＩ＞レコードの位置決め方法 ＜ＩＩＩ＞トラック容量のチェック方法 をあげたが、ここでは、＜ＩＩＩ＞のトラック容量のチ
ェック方法について、特に＜ケース ＩＩＩ−３＞のセ
グメント・ナンバを使用してトラック容量をチェックす
る方式について、実際の制御方法を説明する。なお、＜
ＩＩＩ＞のトラック容量のチェック方法については＜ケ
ース ＩＩＩ−１＞と＜ケース ＩＩＩ−２＞と＜ケー
ス ＩＩＩ−３＞の３つの方式が上がっていた。まず、
前提条件を以下のように考える。セグメント・ナンバ
は、図３５のように、３２Ｂを１セグメントとする。セ
グメント・ナンバは、１から順番にふられた絶対セグメ
ント番号（ＡＳＮ）を使用するものとする（図２９参
照）。また、使用する数字はすべて十進数を用いる。

【００８３】次に、制御方法について説明する。まず基
本方針として以下の２点を考える。 （１）ホーム・アドレスＨＡのセグメント・ナンバはＳ
／Ｗから読み書きできるので、ＨＡが通常の位置にある
場合（ＡＳＮ＝１７）と、ＨＡがＭｏｖｅしている場合
（ＡＳＮ＝２３）の２種類をサポートするものとする。 （２）それ以外のＲ０を含む他のレコードについてはＳ
／Ｗからセグメント・ナンバもＳＣ（スキップ・コント
ロール）も読み書きできないので、ＭｏｖｅやＳｐｌｉ
ｔなどはいっさい無いものとする。 （１）セグメント・ナンバの与え方 次に、上記の基本方針に基づき、以下のように各レコー
ドのセグメント・ナンバを付与するものとする。 （ａ）ＨＡのセグメント・ナンバはＳ／Ｗから書き込ま
れる値を絶対セグメント番号に換算したものに従い、Ａ
ＳＮ＝１７、または、２３とする（もちろん、イニシャ
ライズ時はＡＳＮ＝１７とする。）。 （ｂ）Ｒ０のセグメント・ナンバはＨＡのセグメント・
ナンバにかかわらず常にＡＳＮ＝２６とする。 （ｃ）Ｒ１以降のレコード（Ｒｎ）のセグメント・ナン
バは下式により定める。 ・前のレコード（Ｒｎ−１）にキー・フィールドがある
場合、 ＲｎのＡＳＮ＝Ｒｎ−１のＡＳＮ＋［（ＫＬ＋１２）／
３２］＋［（ＤＬ＋１２）／３２］＋２２ ・前のレコード（Ｒｎ−１）にキー・フィールドがない
場合、 ＲｎのＡＳＮ＝Ｒｎ−１のＡＳＮ＋［（ＤＬ＋１２）／
３２］＋１５ ただし、１２はＥＣＣとスペースのバイト数、３２はセ
グメントのバイト数、２２はＧ２（２２４Ｂ）とＧ２
（２２４Ｂ）とＧ３（２１６Ｂ）とカウント・フィール
ド（４０Ｂ）のセグメント数、１５はＧ２（２２４Ｂ）
とＧ３（２１６Ｂ）とカウント・フィールド（４０Ｂ）
のセグメント数であり、［］内は、小数点以下切上げと
する。

【００８４】（２）トラック容量（トラック・オーバラ
ン）のチェック方法 （１）により求めたセグメント・ナンバと、ホストから
送られてくるＫＬ，ＤＬを用いて下式によりトラック・
オーバランのチェックを行う。下式を満たしていればＯ
Ｋ、満たしていなければトラック・オーバランになる。 ・追加するレコード（Ｒｎ）にキー・フィールドがある
場合、 ＲｎのＡＳＮ＋［（ＫＬ＋１２）／３２］＋［（ＤＬ＋
１２）／３２］＋１４≦１５３３ ・追加するレコード（Ｒｎ）にキー・フィールドがない
場合、 ＲｎのＡＳＮ＋［（ＤＬ＋１２）／３２］＋７≦１５３
３ ただし、１４はＧ２（２２４Ｂ）のセグメント数、７は
Ｇ２（２２４Ｂ）のセグメント数、１５３３は最大セグ
メント数であり、［］内は、小数点以下切上げとする。

【００８５】以上をまとめると、フォーマット・ライト
時のトラック・オーバランのチェックの手順は下記のよ
うになる。（１）の手順に従い、書き足すレコードのセ
グメント・ナンバを求める。 ・求めたセグメント・ナンバの値とホストから送られて
きたＫＬ．ＤＬから、（２）の手順に従い、書き足すレ
コードがトラック・オーバランを起こすか否かチェック
する。上記（１），（２）の各式は、ＨＡがＭｏｖｅし
ていようがいまいが、同じ式を用いる。すなわち、この
方式では、図３０に示すように、仮想的なＣＫＤトラッ
ク上でＨＡがＭｏｖｅしていようがいまいが、また、Ｈ
Ａ内のＳＣ（スキップ・コントロール）の値にかかわら
ず、すべてのディフェクトはトラックの最後尾にあるこ
とになる。このような制御にすることにより、トラック
・オーバランのチェックでは常に同じ式を用いることが
できるうえ、また、ＳＣ（スキップ・コントロール）の
値を気にする必要が無くなるので、制御が非常にシンプ
ルになる。もし、ＨＡのＭｏｖｅにあわせてＲ０もずら
していると、トラック・オーバランのチェック時、常
に、トラックの先頭のＨＡのセグメント・ナンバを読み
とってチェックするか、さもなければ、実際のディスク
と同じように、各レコードにおいてもＳＣ（スキップ・
コントロール）を保持して管理する必要がでてくる。基
本的には、フォーマット・ライト時のギャップ中の作業
は、（２）のトラック・オーバランのチェックなど、従
来のディスク制御に比べ増える方向なので、シンプルに
できる部分はシンプルにすべきである。

【００８６】以上より、セグメント・ナンバを使用した
トラック容量のチェック＜ケースＩＩＩ−３＞の方法)
は比較的シンプルな制御で実現可能である。従って、従
来方式＜ケース ＩＩＩ−２＞の方法のようにＣＫＤフ
ォーマットのトラック・イメージをＦＢＡに変換した後
も、ギャップ長を調整して各レコードのトラックの先頭
からのバイト位置を、無理に元のＣＫＤトラックのまま
維持しなくても制御可能である。セグメント・ナンバ自
体はＳ／Ｗインター・フェイス上サポートが必要である
ので（少なくともＨＡについては）、それを積極的に利
用する＜ケース ＩＩＩ−３＞の方法は、ギャップ長を
元のＣＫＤフォーマットと同等の量だけ保持しなければ
ならない＜ケース ＩＩＩ−２＞に比べ、特にレコード
・サイズが小さいときのキャッシュ・メモリの利用効率
において著しく有利である（「ギャップの削除方法とメ
モリ容量の評価」）。また、すべてのレコードのＫＬ．
ＤＬを読んで、トラックの残容量を計算する＜ケース
ＩＩＩ−１＞に対しては、メモリのアクセス回数の点で
有利であり、もっとも有望な方式である。

【００８７】これまでＣＫＤ−ＦＢＡ変換方式を特徴付
ける三つのポイントとして、 ＜Ｉ＞ギャップの削除方法 ＜ＩＩ＞レコードの位置決め方法 ＜ＩＩＩ＞トラック容量のチェック方法 をあげ、それぞれについて下記のような検討を行ってき
た。 ●＜Ｉ＞のギャップの削除方法について ・「ギャップの削除方法とメモリ容量の評価」において
メモリ容量の評価を行った。この結果、すべてのギャッ
プを削除する＜ケース Ｉ−１＞の方式が有利なことが
分かった。 ●＜ＩＩ＞のレコードの位置決め方法について ・「レコードの位置情報のメモリ容量見積り」で、レコ
ードの位置情報を保持する２方式について、位置情報の
ためのメモリ容量の見積りを行った。この結果、メモリ
・アクセス回数の点で＜ケース ＩＩ−２＞（ＦＢＡブ
ロック内の最初のレコードの位置情報だけ保持する）よ
り有利であるとしていた＜ケース ＩＩ−３＞（全レコ
ードの位置情報を保持する）は、そのままでは、レコー
ドの位置情報を保持するためのメモリ容量が多くなりす
ぎることが分かった。 ・そこで、「レコードの位置情報の制御方式の改善」で
＜ケース ＩＩ−３＞のメモリ容量の改善が可能か否か
検討した。その結果、制御方法を工夫することにより、
＜ケース ＩＩ−３＞でも全レコードの位置情報を保持
するためのメモリ容量を十分小さくできることがわかっ
た。 ●＜ＩＩＩ＞のトラック容量のチェック方法について ・＜ケース ＩＩＩ−３＞（セグメント・ナンバなどを
用いて各レコードのＣＫＤフォーマットでの相対位置情
報を保持する。ギャップが不要な分有利）の実現可能性
を「セグメント・ナンバを用いたトラック容量のチェッ
ク方式の検討」で検討した。その結果、セグメント・ナ
ンバを用いてトラック容量のチェックを行うことは容易
で、その具体的な手順も示した。

【００８８】以上のような検討結果前述した図１９に示
すように、もっとも高得点をあげている方式＜１，３，
３＞が採用できることがわかった。この方式は、ギャッ
プの削除方法としては全ギャップを削除するので、特に
ジャーナル・ファイルなどのレコード・サイズが小さい
場合、トラック・イメージを格納するためのメモリ容量
が少なくて済む。レコードの位置決め方式としては、全
レコードの位置情報を保持する方式を採用しているの
で、目的レコードを探すためのメモリ・アクセス回数が
少なくて済む。ただし、位置情報を保持するためのメモ
リ容量を少なくするために、「レコードの位置情報の制
御方式の改善」で検討した＜ケース ＩＩ−３＞改を採
用する必要がある。トラック容量のチェック方式として
は、セグメント・ナンバを使用する方式なので、各レコ
ードの相対位置をＣＫＤフォーマットのまま維持するた
めのギャップは必要無く、従って、ギャップの削除方法
として、全ギャップを削除する方法との併用が可能とな
る。単に得点の大小だけで判定するのでなく、高得点を
あげている他の方式についても、方式＜１，３，３＞と
の比較を行っておく。

【００８９】＜２，３，２＞ ・・・５４点 図９において次点である方式＜２，３，２＞は、＜１，
３，３＞と比較するとトラック容量のチェック方法でセ
グメント・ナンバを使用せず、従来方式であるギャップ
長を調節してメモリ上でも各レコードのＣＫＤフォーマ
ットでの相対位置を維持する方式をとっている。そのた
め全ギャップを削除することはできず、ギャップの削除
方法は必然的に一部のギャップを残す方式となる。この
方式のよい点は、各レコードの相対位置がＣＫＤフォー
マットのまま維持されているので、フォーマット・ライ
ト時、セグメント・ナンバを計算したり、それによる、
トラック容量のチェックをしなくてもよいことである。
従って、セグメント・ナンバそのものも省略できる。悪
い点は、ギャップ長を伸ばして各レコードのＣＫＤフォ
ーマットでの相対位置を維持するため、メモリ上でのト
ラック容量は常にほぼＣＫＤトラック１本分必要となる
ことである。これは、特に、ジャーナル・ファイルなど
のレコード・サイズの小さい場合にキャッシュ・メモリ
の利用効率悪化、ステージング／デステージング時の内
部バスの負荷増大につながる。また、レコードの位置決
め方式として、全レコードの位置情報を保持する方式を
併用しているが、レコードサイズが最少で、レコード数
が最多の９４レコード／トラックのケースでは、「セグ
メント・ナンバを用いたトラック容量のチェック方式の
検討」で検討した改善方法をとっても、メモリ容量不足
となる可能性もある。また、この方式は、レコードの位
置決め方式は従来方式と異なるが、トラック容量のチェ
ック方式は従来方式そのままである。

【００９０】＜２，３，３＞ ・・・５３点 この方式は、ギャップを一部残すこと以外は＜１，３，
３＞と同じである。従って、ギャップを残しても特にそ
れを使用しないので、ギャップを残す意味がなく、＜
１，３，３＞に比べ、わざわざ採用する必然性がない方
式である。上記説明では、アレイ型ディスク装置（ＲＡ
ＩＤ）を前提としていたが、ここでは、通常のディスク
装置を用いる場合にも＜１，３，３＞の方式を採用でき
ることについて述べる。 ●＜Ｉ＞のギャップの削除方法について ギャップの削除方法によるメモリ容量の大小がキャッシ
ュの利用効率に大きく関わることは、ＲＡＩＤであって
もなくても同じであり、この点からは、すべてのギャッ
プを削除する＜ケース Ｉ−１＞の方式が有利なことに
変わりはない。 ●＜ＩＩ＞のレコードの位置決め方法について バスの負荷を下げ高転送レートを出しやすくするために
は、１回のバス獲得である程度まとまった量のデータ転
送を行ってしまう方がよい。すなわち、レコードの位置
情報も一括してアクセスできる方が、毎回各レコードの
カウント・フィールドをアクセスする方式よりも有利で
ある。従って、レコードの位置決め方法についても、メ
モリ・アクセス回数が少ない＜ケース ＩＩ−３＞（全
レコードの位置情報を保持する）の方が、従来方式の＜
ケース ＩＩ−２＞（ＦＢＡブロック内の最初のレコー
ドの位置情報だけ保持する）より有利である。 ●＜ＩＩＩ＞のトラック容量のチェック方法について これも、ＲＡＩＤでなくなってもギャップが不要な方式
の方がキャッシュの利用効率上有利であることに変わり
はない。従って、従来方式の＜ケース ＩＩＩ−２＞
（ギャップ長を調節して、メモリ上でも各レコードのＣ
ＫＤフォーマットでの相対位置を維持する）よりも、＜
ケース ＩＩＩ−３＞（セグメント・ナンバなどを用い
て各レコードのＣＫＤフォーマットでの相対位置情報を
保持する。ギャップが不要な分有利）のままでよい。

【００９１】次に、ＣＫＤ−ＦＢＡ変換におけるコマン
ド・エミュレーション方式について検討する。ここで
は、前述した具体的な変換方式に基づいて、実際のＳ／
Ｗインタフェース上の代表的な、コマンドごとにこのＣ
ＫＤ−ＦＢＡ変換方式における実現方法を検討する。

【００９２】１．ＳＥＴ ＳＥＣＴＯＲ ＜機能＞ チャネルから１バイトのセクタ情報を受け取り、セクタ
を検索する。 （セクタ情報：Ｘ’００’〜Ｘ’ＤＤ’，Ｘ’ＦＦ’た
だしＸ’ ’は１６進数を表す。） ＜実現方式＞ このディスク・サブシステムでは、セクタ値は、まず、
ＣＫＤトラックを四つに分割したフレームのうち、どの
フレームに目的レコードが存在するかを知るために使用
する。フレームが見つかった後は、コントロール・フレ
ーム中のレコード・ポインタに書かれている各レコード
のセグメント・ナンバと、このセクタ値を比較すること
により、より精度の高い位置決めができる（フレーム、
及びコントロール・フレームやレコード・ポインタの概
略については図２５に示したが、詳細は「レコードの位
置情報の制御方式の改善」参照のこと）。 ○目的レコードが存在するフレームの計算 実際のＣＫＤディスクでは、セクタ１個分は２２４バイ
トからなりたっているので、セクタ値からＣＫＤフォー
マットのトラック上でのそれに相当する絶対バイト・ア
ドレスはただちに計算できる。しかし、フレーム上では
ギャップやＥＣＣ、パディングなどは削除して記録して
いるので、その絶対バイト・アドレスがどのフレームに
含まれているかは、その削除してしまった分を換算しな
いと分からない。この削除した分量はレコード数にも依
存する。

【００９３】以下、目的レコードが存在するフレームの
計算について説明する。フレーム上ではＣＫＤフォーマ
ットのトラックから何バイト削除しているかは、フレー
ム上でのトラック・フォーマットが詳細に決らなくては
定まらないが、図３３のようなフォーマットであるとす
ると、各フィールドごとにフレーム上で削除されている
バイト数は図３１のようになる。目的レコードの前には
Ｒ０を除いて（目的レコードのレコード・ナンバ−１）
個のレコードが存在するので、セクタ値で示されるＣＫ
Ｄフォーマットのトラック上での位置は、フレーム上で
はトラックの先頭から下式のバイト数ＢＣ１で表される
位置に相当する。 ＢＣ１＝２２４×セクタ値−１０３８−７５２×（レコ
ード・ナンバ−１） また、これだけのレコードを記録するためには、フレー
ム上ではレコード数分（Ｒ０も入れてレコード・ナンバ
個）のレコード・ポインタが必要である。レコード・ポ
インタ１個は４バイトとしているので、この分も含めた
バイト数ＢＣ２は下式のようになる。 ＢＣ２＝ＢＣ１＋４×レコード・ナンバ フレーム１個にはコントロール・フレーム・ポインタ４
バイトを除くと、レコード・ポインタも含め１２ＫＢ−
４Ｂ記録できるので、セット・セクタ値に相当する位置
は、下式で求められるＮ番目のフレームに存在すること
が期待できる。 Ｎ＝［ＢＣ２／１２２８４］ ただし、［］内は、小数点以下切上げとする。これらの
式を一つにまとめると、下式のようになる。 Ｎ＝［（２２４×セクタ値−２８６−７４８×レコード
ナンバ）／１２２８４］ ただし、［］内は、小数点以下切上げとする。また、負
の値になったときはＮ＝１とする。正確には、フレーム
上で削除されているバイト数は各レコードにキー・フィ
ールドが存在しているか否か、また、３２の整数倍にす
るためにＫＬ，ＤＬにゼロ・パディングしているバイト
数などにもよって異なってくるため、上式は、あくまで
概算式となる。上式では、このような不定の部分につい
ては、削除されるバイト数が最大になるように仮定して
計算しているので、これにより求めたフレームの番号は
実際よりも前の方を示す傾向になる。従って、上式で求
めたフレームに目的レコードが存在しなかった場合は、
次のフレームを探せばよい。しかし、この式の精度はも
ともとフレームのサイズ１２ＫＢでよく、それに対し誤
差の量はレコード１個当り最大でも２８６バイト（２２
４＋３１＋３１）であるので、通常は問題無い。

【００９４】また、ＳＥＡＲＣＨコマンドが来なかった
り、ＳＥＡＲＣＨコマンドであってもＳＥＡＲＣＨ Ｋ
ＥＹであったためレコードナンバが得られなかった場合
は、フレームを特定することを諦めて、任意のフレーム
（例えば最初にステージングが完了したフレーム）中の
レコードのセグメント・ナンバを調べていくことになる
（次の項の手順参照）。 ○目的レコードの探索 上の手順により、目的レコードが存在するフレームを特
定したら、後は、そのフレーム中のレコード・ポインタ
を調べて、目的レコードを探せばよい（詳細な手順は、
「レコードの位置情報の制御方式の改善」参照）。ま
ず、そのフレームの先頭のレコードのレコード・ポイン
タ（コントロール・フレーム中では最後尾にある）から
順番にレコード・ポインタ中に記録されているセクタ値
を調べていく。そして、チャネルから送られてきたセク
タ値よりも大きいセクタ値を持つ最初のレコードのレコ
ード・ポインタを見つける。もし、このフレーム中のレ
コードすべてがチャネルから送られてきたセクタ値より
小さいセクタ値しか持っていなければ、次のフレームに
対して、同じ操作を行っていく。条件を満たす最初のレ
コードのレコード・ポインタが見つかったら、引き続く
ＳＥＡＲＣＨＩＤコマンドのアーギュメントとそのレコ
ードのカウント・フィールドを比較し、一致していれば
そのレコードにオリエンテーションを確立する。もし、
一致しなければ次のレコードのカウント・フィールドと
の比較を繰り返していき、最初にアーギュメントと一致
したレコードにオリエンテーションを確立し、次のコマ
ンドに移っていく（ＣＫＤの論理トラックの最後まで探
して一致するレコードが見つからなかった場合などにつ
いては、「４．ＳＥＡＲＣＨ ＩＤＥＱ」コマンドを参
照のこと）。なお、先行するＳＥＥＫコマンドによるヒ
ット・チェックの結果、既に目的トラックがキャッシュ
上に存在することが分かっている場合（ヒット時）はた
だちに次のコマンドへ進んでよいが、ミス・ヒット時、
または、ヒットしていてもトラックの一部分しかキャッ
シュ上に存在しておらず、目的レコードが含まれるフレ
ームがキャッシュ上に存在しない場合は、チャネル・エ
ンドＣＥのみ返し一旦チャネルからディスコネクトし
て、目的のフレームを物理ディスクからステージングし
た後、デバイス・エンドＤＥを返して次のコマンドへ進
むことになる。

【００９５】２．ＳＥＡＲＣＨ ＩＤＥＮＴＩＦＩＲＥ
ＥＱＵＡＬ ＜機能＞チャネルから５バイトのＳＥＡＲＣＨ情報を受
け取り、デバイスから読み出されたカウント・フィール
ド（Ｒ０フィールドも含む）のＣＣＨＨＲと比較する。 ＜実現方式＞ ○ＳＥＴ ＳＥＣＴＯＲコマンドからチェインした場合 「１．ＳＥＴ ＳＥＣＴＯＲ」で示した動作により、Ｃ
ＣＨＨＲの一致したレコードにオリエンテーションを確
立する。実際のＣＫＤディスクでは、ＳＥＴ ＳＥＣＴ
ＯＲ後、最初に見つけたレコードのＣＣＨＨＲが一致し
なければ不一致報告をし（ＣＥ，ＤＥ）、ホストがトラ
ンスファーインチャネルＴＩＣを併用して再度ＳＥＡＲ
ＣＨ ＩＤ ＥＱコマンドを発行するのを待つ。しか
し、このサブシステムでは、「１．ＳＥＴ ＳＥＣＴＯ
Ｒ」で示したように一回のＳＥＡＲＣＨ ＩＤ ＥＱコ
マンドでトラック全体をサーチできてしまう。エミュレ
ーションの厳密性からいえば、あくまで、１個のＳＥＡ
ＲＣＨ ＩＤ ＥＱコマンドで１個のレコードのサーチ
しか行うべきでないが、そうすることによるメリットは
特に考えられないので、処理効率の点から「１．ＳＥＴ
ＳＥＣＴＯＲ」で示した一括サーチの方式でよいと考
える。ＳＥＴ ＳＥＣＴＯＲで指定されたセクタから後
ろに一致するレコードが無かった場合は、マルチ・トラ
ック・ビットがセットされていれば、不一致報告（Ｃ
Ｅ，ＤＥ）を行う。ただし、レコードそのものが存在し
なかった場合はそのまま次のトラックにヘッド・スイッ
チする。ＳＥＴ ＳＥＣＴＯＲコマンドで指定されたセ
クタから後ろに目的レコードが見つからず（レコードが
存在しなかった場合も含む）、マルチ・トラック・ビッ
トもセットされていなかった場合は、同じトラックの最
初のフレームの最初のレコード（Ｒ０も含む）に戻って
比較を繰り返し、それでも一致するレコードが見つから
なければＮｏ Ｒｅｃｏｒｄ Ｆｏｕｎｄを報告する。 ○ＲＥＡＤ，ＷＲＩＴＥ，ＳＥＡＲＣＨ系コマンド、ま
たは、ＳＰＡＣＥ ＣＯＵＮＴコマンドからチェインし
た場合 先行するコマンドでオリエンテーションしていた次のレ
コードに対しＣＣＨＨＲの比較を行う。この場合は、既
にオリエンテーションが確立しているのであるから、Ｓ
ＥＴ ＳＥＣＴＯＲコマンドからチェインした場合と異
なり、実物のＣＫＤディスク同様、サーチするレコード
は次のレコード１個だけの方がよい。オリエンテーショ
ンしていた所より後ろにレコードが存在していなかった
場合は、マルチ・トラック・ビットがセットされていれ
ば次のトラックに移り、セットされていなければ同じト
ラックの先頭に戻って、比較する。ただし、同一ＣＣＷ
チェイン内でもう一度、トラックの最後までいってしま
ったらＮｏ ＲｅｃｏｒｄＦｏｕｎｄを報告する。 ○他のコマンドからのチェイン、または、チェインの先
頭であった場合 この場合、実際のＣＫＤディスクでは、現在のトラック
上で最初に発見したレコードに対しサーチ動作を行う
が、このサブシステムでは常にＲ０から順番にサーチす
るほかは、「ＳＥＴ ＳＥＣＴＯＲコマンドからチェイ
ンした場合」と同じでよい。ミスヒットしていてステー
ジングが完了していなかった場合や、マルチ・トラック
・ビットがたっていて、次のトラックがミスヒットして
いた場合などは、このコマンドでステージングを完了さ
せる。また、ＳＥＥＫコマンドが先行しなかった場合の
現在トラックの認識のためにそのボリュームに対する最
後のアクセス・トラックは常に覚えておかなければなら
ない。

【００９６】３．ＲＥＡＤ ＤＡＴＡ ＜機能＞ディスクから読み出したデータ・フィールドの
情報をチャネルに転送する。 ＜実現方式＞ ○ＲＥＡＤ，ＷＲＩＴＥ，ＳＥＡＲＣＨ系コマンド、ま
たは、ＳＰＡＣＥ ＣＯＵＮＴコマンドからチェインし
た場合 フレーム上でオリエンテーションが確立していたフィー
ルド以降にある最初のデータ・フィールドの情報をチャ
ネルに転送し、オリエンテーションを維持する。もし、
オリエンテーションが確立していたフィールドより後ろ
に、もはや、データ・フィールドが存在しなかった場
合、マルチ・トラック・ビットがセットされていれば、
次のトラックのＲ１（Ｒ０の次のコマンド）のデータ・
フィールドを転送する。マルチ・トラック・ビットがセ
ットされていなければ、ヘッド・スイッチせず同じトラ
ックのＲ１のデータ・フィールドを転送する（Ｒ０のデ
ータ・フィールドを転送する場合は、Ｒ０フィールドの
比較を満足したＳｅａｒｃｈ系コマンド、または、Ｒ０
ＣをバイパスしたＳＰＡＣＥ ＣＯＵＮＴコマンドから
チェインした場合のみである）。 ○他のコマンドからのチェイン、または、チェインの先
頭であった場合 オリエンテーションが確立していない状態であるので、
実際のＣＫＤディスクでもどのレコードを検出するかは
一定でない。従って、毎回、Ｒ１（Ｒ０の次のコマン
ド）のデータ・フィールドの情報を転送して特に問題な
い（Ｒ１が存在すれば）。転送後は、そのままオリエン
テーションを確立する。もし、Ｒ１が存在せず、かつ、
マルチ・トラック・ビットがセットされていれば、次の
トラックのＲ１のデータ・フィールドを転送する（アド
レス・マークが見つからないまま、インデックスを検知
してしまった場合に相当する）。マルチ・トラック・ビ
ットがセットされていなければ、Ｎｏ Ｒｅｃｏｒｄ
Ｆｏｕｎｄを報告する。もちろん、次のトラックがキャ
ッシュ上に存在しなかった場合は、まず、ステージング
してからチャネルへデータ転送する。同一ＣＣＷチェイ
ン内でＳＥＥＫコマンドが先行していない場合は、同一
ボリュームにおける最後にアクセスしたトラックに対し
て、ＲＤ ＤＡＴＡコマンドを実行する。

【００９７】４．ＷＲＩＴＥ ＣＯＵＮＴ ＫＥＹ Ａ
ＮＤ ＤＡＴＡ ＜機能＞チャネルから受け取った情報を、Ｒｎフィール
ド（Ｒ０フィールドを除く）としてディスク上に書き込
む。 ＜実現方式＞このコマンドは、ＣＣＨＨＲの一致したＳ
ＥＡＲＣＨ ＩＤ ＥＱコマンド（ＲＤ Ｄ，ＲＤ Ｋ
Ｄ，ＷＲ Ｄ，またはＷＲ ＫＤが続いていてもよ
い）、すべてのキーの一致したＳＥＡＲＣＨ ＫＥＹ
ＥＱコマンド（ＲＤ Ｄ，またはＷＲＤが続いていても
よい）、ＷＲ Ｒ０コマンド、またはＷＲ ＣＫＤコマ
ンドからチェインした場合以外はコマンド・リジェクト
となるので、このコマンドが実行される場合は事実上、
必ず既にオリエンテーションが確立している。従って、
チャネルから情報を受け取ったら、ただちに下記のよう
なオペレーションを実行する（図２５参照）。 （１）カウント・フィールドの受取 チャネルからＲｎのＣＣＨＨＲＫＬＤＬを受け取り、そ
れに、Ｒ_n-1 ０のカウント・フィールドの他の情報をつ
けたす。まだ、キャッシュ上には書き出さない。Ｒｎの
カウント・フィールドの他の情報としては、ＳＣ（スキ
ップ・コントロール）、ＳＮ（セグメント・ナンバ）、
ＰＡ（フィジカル・アドレス）、Ｆ（フラグ）等であ
る。ＳＣは、今回のサブシステムではスキップ・コント
ロールはサポートしないので、事実上、一定値を書いて
おくだけである（ただし、エリアだけは確保しておいた
方が、将来何かの使い道がありそうな気がする）。ＳＮ
も先行するレコードのＳＣの値から計算して書き込む
（計算方法は「セグメント・ナンバを用いたトラック容
量のチェック方式の検討」参照）。また、同時にこの値
からセクタ値も計算して、コントロール・フレーム中の
レコード・ポインタに（３）で書き込む。ＰＡ，ＦはＨ
Ａと同じ値のままでよい。 （２）トラック・オーバランのチェック チャネルから受け取ったＫＬ，ＤＬとセグメント・ナン
バからからトラック・オーバランを発生しないか否かを
調べる（詳細な計算方法は「セグメント・ナンバを用い
たトラック容量のチェック方式の検討」参照）。もし、
トラック・オーバランを発生する場合は、以降の制御で
トラック・オーバラン・ポイントまでデータ転送を行
い、ホストにトラック・オーバランを報告するような制
御を行う。 （３）レコード・ポインタの追加 トラック・オーバランのチェックが終ったら、現在オリ
エンテーションを確立しているフレームの（ＣＰＳが自
分で保持している）コントロール・フレーム・ポインタ
中のコントロール・フレームの先頭を示すメモリ・アド
レスを４Ｂ減じ（コントロール・フレームを４Ｂ拡張す
る）、さらに、Ｒｎのレコード・ポインタを（ＣＰＳが
保持している）コントロール・フレームの先頭に書き足
す。もし、４Ｂ減じることによって、コントロール・フ
レームがレコード・フレームに食い込んでしまうような
場合は、そのフレームにレコードを追加することは諦
め、次のフレームのコントロール・フレームにレコード
・ポインタを追加する。必要ならば、マネージャに次の
フレームのエリアを確保してもらう。 （４）フレームのさかいめのチェック チャネルから受け取ったＫＬ，ＤＬからＲｎの各フィー
ルドの最後尾のメモリ・アドレスを計算し、（３）で更
新したコントロール・フレーム・ポインタ中のメモリ・
アドレスと比較する。もし、Ｒｎのどれかのフィールド
の最後尾のメモリ・アドレスがコントロール・フレーム
に食い込んでいるような場合は、ホストとのデータ転送
をコントロール・フレームの手前で一端停止し、メモリ
・アドレスを次のフレームの先頭まで進めてから、ホス
トとのデータ転送を再開するような制御を（ＣＰＳが）
行う。Ｒｎの最後尾がレコード・フレーム内に収まって
いれば、上記のような制御は不要で、Ｒｎのデータ転送
を途中で中断することなく実行することができる。 （５）カウント・フィールドのキャッシュへの書きだし これらの一連のチェックが完了してからＣＰＳ内のカウ
ント・フィールドのデータをキャッシュ・メモリ上の該
当アドレスへ書き出す。もし、カウント・フィールド内
にフレームのさかいめが来てしまうような場合は、そこ
で一旦キャッシュへの書き出しを停止して、メモリ・ア
ドレスを次のフレームの先頭まで進めてから、書き出し
を再開する。 （６）キー・フィールド、データ・フィールドの受取 （４）のチェックの結果、Ｒｎの最後尾がレコード・フ
レーム内に収まっていれば、まず、キー・フィールドの
データをチャネルから受けとって、キャッシュ上に書き
込んだのち、適当なギャップ相当時間経過後、データ・
フィールドのデータもチャネルから受けとってキャッシ
ュに書き込む。もし、（４）のチェックの結果、途中で
フレームの切れ目に遭遇することが分かっていれば、そ
こで一旦データ転送を中断する。現在オリエンテーショ
ンが確立しているフレームが最終フレームでなかった場
合は、ＣＰＳはその次のフレームのキャッシュ上でのア
ドレスも知っているので、データ転送のためのメモリ・
アドレスを次のフレームの先頭に進めた後、チャネルと
のデータ転送／キャッシュへの書き込みを再開する。現
在オリエンテーションを確立しているフレームが最終フ
レームであった場合は、もともとキャッシュ上にはその
次以降のフレームの領域は確保されていないので、ＣＰ
Ｓはマネージャに次のフレームのための領域を要求し
て、そのアドレスをマネージャから教えてもらった後、
そこに対してデータ転送を再開する（このような新しい
フレームの領域確保などの処置はギャップ相当のタイミ
ングで、データ転送を中断している間に実行してしまえ
ばよい）。データ転送したフレームに対しては、各フレ
ームのコントロール・フレーム中の相当するＦＢＡブロ
ックの更新フラグをセットしておく。 （７）ＣＥの報告 ここまですんだら、ＣＰＳはコマンド・チェインの有無
を確認するため、一旦チャネルにチャネルとの間のデー
タ転送が終了したことを示すチャネル・エンドＣＥを報
告する。 −−−コマンド・チェイン指示がなかった場合 （８）ＣＰＳ→マネージャ デステージング要求 コマンド・チェイン指示がなければ、ＣＰＳはＲｎの最
後尾が書かれたフレームの残りの部分にゼロ・パディン
グするとともに、ゼロ・パディングをした部分に対応す
るＦＢＡブロックの更新フラグもセットする。次いで、
更新したフレームのコントロール・フレームをキャッシ
ュ上に書き出した後、マネージャを介しＤＰＳにデステ
ージングを要求する。この際、Ｒｎの最後尾が書かれた
フレームより後ろにもともとの最終フレームあった場合
は、ＣＰＳはマネージャにＲｎの最後尾のフレーム以降
のフレームが無効になったことも報告する。もともとＲ
ｎの最後尾が書かれたフレームより最終フレームが前で
あった（同じ場合も含む）場合は、それ以降のフレーム
ももともと無効フレームであったのであるから、あらた
めて、以降のフレームが無効になったことは報告しな
い。 （９）マネージャ→ＤＰＳ デステージング要求 マネージャは、無効になったフレームが存在することも
あわせて報告された場合は、該当トラックのキャッシュ
上の無効フレームを抹消した後（自分の管理情報をメン
テナンスする）、ＤＰＳに該当トラックのデステージン
グを指示する。この際マネージャは、ＤＰＳに対し、物
理ディスクに書き出すべきデータのアドレスとして、キ
ャッシュ上での有効データの存在するフレームのアドレ
スを知らせるとともに、新たに無効フレームが発生した
場合のみ、無効フレームに書き込むデータとして、無効
フレーム用のデータをあらかじめどこか一箇所に用意し
ておき、そこのアドレスを指示する（すなわち、無効フ
レームはすべて無効フレーム用のデータが用意されてい
るメモリ上の同一のデータを物理ディスクに書き込むこ
とになる。この無効フレーム用データはキャッシュ・メ
モリ上にマネージャが用意しておいてもよいし、各ＤＰ
Ｓが自分のボードの中に持っていてもよい）。新たに無
効フレームが発生しなかった場合は、ＤＰＳに対しもと
もと無効フレームであったフレームをあらためて書き直
すことは指示しない。 （１０）デステージング ＤＰＳはマネージャからの指示を受け、キャッシュ・メ
モリ上のデータを物理ディスクに書き出す。ＤＰＳはマ
ネージャから指示されたフレームの更新フラグがたって
いるＦＢＡブロックについてライトを行う。 （１１）デステージング終了報告 物理ディスクへの書き出しが終了すると、ＤＰＳはマネ
ージャを介して、ＣＰＳに終了報告を行う。 （１２）ＤＥ報告 ＣＰＳはチャネルに、全ての処理が終了したことを示す
デバイス・エンドＤＥを報告する。 −−−コマンド・チェイン指示があった場合 （８）’コマンド・チェインが指示されれば、ＣＰＳは
ＤＥを報告し、次のコマンドを受け取る。 （９）’次のコマンドがＷＲ ＣＫＤまたはＥＲＡＳＥ
であればその処理に移る。他のコマンドであれば、ＣＰ
ＳはＣＥ，ＵＣＫ，ＳＭを報告しコマンド・リトライを
要求する。 （１０）’この後、上記の（８）〜（１１）を実行す
る。 （１１）’ＤＰＳから物理ディスクへのライト終了が報
告されたら、ＣＰＳはＤＥを報告し、先にコマンド・リ
トライ要求したコマンドを受け取り直し、そのコマンド
の実行に移る。

【００９８】５．ＷＲＩＴＥ ＤＡＴＡ ＜機能＞チャネルから受け取った情報により、レコード
のデータ・フィールドを更新する。 ＜実現方式＞このコマンドは、ＣＣＨＨＲの一致したＳ
ＥＡＲＣＨ ＩＤ ＥＱコマンド、または、すべてのキ
ーの一致したＳＥＡＲＣＨ ＫＥＹ ＥＱコマンドから
チェインした場合以外はコマンド・リジェクトとなるの
で、このコマンドが実行される場合は、事実上、必ず既
にオリエンテーションが確立している。従って、チャネ
ルから情報を受け取ったら、ただちに下記のようなオペ
レーションを実行する。 （１）フレームのさかいめのチェック データを書き込もうとしているレコードのカウント・フ
ィールドのＫＬ，ＤＬからＲｎの最後尾のメモリ・アド
レスを計算し、現在オリエンテーションを確立している
フレームのコントロール・フレーム・ポインタ中のメモ
リ・アドレスと比較する。もし、Ｒｎの最後尾のメモリ
・アドレスがコントロール・フレームに食い込んでいる
ような場合は、ホストとのデータ転送をコントロール・
フレームの手前で一端停止し、メモリ・アドレスを次の
フレームの先頭まで進めてから、ホストとのデータ転送
を再開するような制御を（ＣＰＳが）行う。Ｒｎの最後
尾がレコード・フレーム内に収まっていれば、上記のよ
うな制御は不要で、Ｒｎのデータ転送を途中で中断する
ことなく実行することができる。 （２）データ・フィールドの受取 （１）のチェックの結果、Ｒｎの最後尾がレコード・フ
レーム内に収まっていれば、データ・フィールドのデー
タをチャネルから受けとってキャッシュに書き込む。も
し、（１）のチェックの結果、途中でフレームの切れ目
に遭遇することが分かっていれば、そこで一旦データ転
送を中断する。アップデート・ライトの場合は、このよ
うなケースでは必ず次のフレームは存在しているので、
ＣＰＳはデータ転送のためのメモリ・アドレスを次のフ
レームの先頭に進めた後、チャネルとのデータ転送／キ
ャッシュへの書き込みを再開する。データ転送したフレ
ームに対しては、各フレームのコントロール・フレーム
中の相当するＦＢＡブロックの更新フラグをセットして
おく。 （３）ＣＥの報告 ここまですんだら、ＣＰＳはコマンド・チェインの有無
を確認するため、一旦チャネルにチャネルとの間のデー
タ転送が終了したことを示すチャネル・エンドＣＥを報
告する。 −−−コマンド・チェイン指示がなかった場合 （４）ＣＰＳ→マネージャ デステージング要求 コマンド・チェイン指示がなければ、マネージャを介し
ＤＰＳにデステージングを要求する。アップデート・ラ
イトの場合は、新たに無効フレームが発生するようなこ
とはない。 （５）マネージャ→ＤＰＳ デステージング要求 マネージャは、ＤＰＳに対し、物理ディスクに書き出す
べきデータのアドレスとして、キャッシュ上での有効デ
ータの存在するフレームのアドレスを知らせ、デステー
ジングを指示する。 （６）デステージング ＤＰＳはマネージャからの指示を受け、キャッシュ・メ
モリ上のデータを物理ディスクに書き出す。ＤＰＳはマ
ネージャから指示されたフレームのうち更新フラグのあ
るＦＢＡブロックだけ書き直す。 （７）デステージング終了報告 物理ディスクへの書き出しが終了すると、ＤＰＳはマネ
ージャを介して、ＣＰＳに終了報告を行う。 （８）ＤＥ報告 ＣＰＳはチャネルに、全ての処理が終了したことを示す
デバイス・エンドＤＥを報告する。 −−−コマンド・チェイン指示があった場合 （４）’コマンド・チェインが指示されれば、ＣＰＳは
ＤＥを報告し、次のコマンドを受け取る。 （５）’次のコマンドがＳＥＡＲＣＨ系のコマンド、ま
たは、フォーマット・ライト系コマンドであればその処
理に移る。同一のコマンドチェイン内で、ＳＥＡＲＣＨ
系またはＷＲＩＴＥ系以外のコマンドが指示された場合
は、ＣＰＳはＣＥ，ＵＣＫ，ＳＭを報告しコマンド・リ
トライを要求する。 （６）’この後、上記の（４）〜（７）を実行する。 （７）’ＤＰＳから物理ディスクへのライト終了が報告
されたら、ＣＰＳはＤＥを報告し、先にコマンド・リト
ライ要求したコマンドを受け取り直し、そのコマンドの
実行に移る。

【００９９】以上のように、この実施例によれば、可変
長レコードの１トラックからレコード間ギャップ及びフ
ィールド間ギャップ等全てのギャップを削除し、そのト
ラックデータを固定長レコードの固定ブロック長サイズ
の整数倍に相当する管理単位に分割し、その管理単位に
含まれる全ての可変長レコードの位置を示す制御情報を
上記管理単位の最後尾に後ろから順番に書き入れた後、
固定長レコードの固定ブロック長サイズに分割すると共
に、各固定長レコードには、可変長レコードフォーマッ
トでのトラックの先頭からの相対位置を示す情報を保持
させるので、固定ブロック内で目的の可変長レコードの
位置確認のためのメモリアクセス回数が少なくて済みメ
モリ負荷軽減となると共に、全てのギャップを削除でき
るのでトラックデータを保持するためのメモリ容量が少
なくて済み、従って、ディスクキャッシュをベースとし
たディスクサブシステムに好適で、キャッシュのヒット
率が向上する。さらに、制御情報領域のサイズを可変に
でき可変長レコードの個数だけ用意すればよくメモリが
少なくて済む。

【０１００】実施例２．上記実施例１においては、図２
５に示したようにコントロールフレームの後ろにもたせ
コントロールフレームの長さを可変とする場合を示した
が、図２４に示すように位置情報領域すなわちコントロ
ールフレームを各管理単位の先頭に設けるようにしても
構わない。ただし、この場合には前述したように９４レ
コード分の位置情報領域をあらかじめ設定しておく必要
があるために１つの管理単位を１２ＫＢとした場合には
容量不足が生じてしまう。したがって１つの管理単位を
１３ＫＢとする必要がある。このようにコントロールフ
レームを４Ｂ×９４レコード分あらかじめもつことによ
りコントロールフレームのサイズが固定されると共にレ
コードフレームのエリアも固定されるため、管理単位の
アクセス方法が単純になる。

【０１０１】実施例３．上記実施例１においては、可変
長レコードフォーマットでのトラックの先頭からの相対
位置として、セクタ値を用いる場合を示したが、これは
セットセクタコマンドで用いられる相対位置がセクタ値
であることからセクタ値を使用することが望ましいため
である。もし、セットセクタコマンドがその他の相対位
置例えば、可変長レコードフォーマットでのトラックの
先頭からのセグメント値を用いている場合には、この相
対位置はセクタ値ではなくセグメント値を用いても構わ
ない。すなわち、図２５に示したレコード・ポインタの
セクタ値という値は、セグメント値であっても構わな
い。

【０１０２】実施例４．上記実施例１においては、トラ
ック容量を計算する場合にはＣＫＤレコード各々にセグ
メント値を持たせている場合を示したが、トラック容量
をセグメント単位に管理するのではなく、セクタ単位に
管理する場合にはセグメント値ではなくセクタ値を持た
せておいても構わない。

【０１０３】実施例５．上記実施例１においては、コン
トロール・フレーム内のレコード・ポインタにセクタ値
を持たせ、レコード・フレーム内の各ＣＫＤレコード内
にはセグメント値を持たせる場合を示したが、セクタ値
とセグメント値は一定の関係にあり（セクタ値×７＝セ
グメント値）、どちらか一方を用いる場合でも構わな
い。すなわち、レコード・ポインタにセクタ値を有して
おれば各ＣＫＤレコードにセグメント値は覚えておかな
くてもよい。ただし、この場合はトラックの使用容量が
セクタ単位しか計算できなくなる。一方、レコード・ポ
インタにセクタ値を有さず、レコード・フレーム内のＣ
ＫＤレコードにセグメント値を持たせている場合には、
トラックの使用容量がセグメント単位で計算することが
可能になる。しかしこの場合には、セットセクタコマン
ドでセクタ値が指定された場合にレコード・ポインタに
は、セクタ値が存在しないためレコード・ポインタのメ
モリアドレスからＣＫＤレコードを探し出し、そのＣＫ
Ｄレコードにあるセグメント値からセクタ値を算出しな
ければ、検索しているセクタかどうかが判定できなくな
る。

【０１０４】実施例６．上記実施例１では特に明記しな
かったが、ＦＢＡディスク９が１つのディスクで構成さ
れる場合、あるいはアレイ形ディスクで構成される場合
のいずれの場合でも構わない。また上記実施例１では明
記しなかったが、ＦＢＡディスク９は磁気ディスク装置
あるいは光ディスク装置等のデータを記録できる装置で
あればどのような媒体を使用するものであっても構わな
い。

【０１０５】実施例７．上記実施例１においてはＣＫＤ
−ＦＢＡ変換方式が磁気ディスク制御装置５に存在する
場合を示したが、ＣＫＤ−ＦＢＡ変換を行うのは磁気デ
ィスク制御装置である場合に限らず、ホスト計算機１の
チャネルが行っても構わない。あるいは磁気ディスク装
置等の記憶装置自身が行っても構わない。図３２は、磁
気ディスク装置等の記憶装置自身がＣＫＤ−ＦＢＡ変換
を行う場合の一実施例を示す図である。図３２に示すよ
うに、ＣＫＤの磁気ディスク制御装置５００のキャッシ
ュ・メモリに記憶された可変長レコードを変換して、固
定長ブロックをもつＦＢＡディスク９００に記憶し直す
場合には、ＦＢＡディスク９００内にあるＣＫＤ−ＦＢ
Ａ変換部１００が動作する。ギャップ削除部１０１は、
磁気ディスク制御装置５００のキャッシュ・メモリに記
憶された可変長レコードをキャッシュ・メモリ６００に
読み込む。この場合は、磁気ディスク制御装置５００の
キャッシュ・メモリの１トラックのレコードを全てキャ
ッシュ・メモリ６００に読み込む。そしてこの１トラッ
ク分の可変長レコードからレコード間ギャップ及びフィ
ールド間ギャップを削除する。キャッシュ・メモリ６０
０に読み込まれたＣＫＤのトラックイメージ７００は、
この時点でギャップが削除されたトラックデータ７ａに
変換される。

【０１０６】次に、レコード配置部１０２はトラックデ
ータ７ａをフレームと呼ばれる管理単位７ｂ，７ｃ，７
ｄ，７ｅに順に配置する。このフレームと呼ばれる管理
単位７ｂ〜７ｅのサイズは例えばＣＫＤのトラックイメ
ージ７が４８ＫＢのサイズをもっている場合には４等分
した１２ＫＢのサイズをそれぞれ有している。レコード
配置部１０２はトラックデータ７ａの可変長レコードを
順にフレーム７ｂから配置してゆく。この場合に、各フ
レームに含まれる可変長レコードの位置を示すアドレス
情報を各フレームに記憶する。また、そのレコードがＣ
ＫＤディスク１０で記憶されていたトラック先頭からの
相対位置（セクタ値）を示すセクタ情報を同様に記憶す
る。

【０１０７】次に、固定ブロック記憶部１０３はフレー
ムをＦＢＡディスク９００の記憶部２００に記憶する。
ここでＦＢＡディスク９の固定長ブロックのサイズをそ
れぞれ１ＫＢとすると、フレーム７ｂ，７ｃ，７ｄ，７
ｅはそれぞれ１２ＫＢのサイズをもっているため、１つ
のフレームは１２個の固定長ブロックを用いて記録され
る。

【０１０８】このようにして、ＣＫＤの磁気ディスク制
御装置から出力される１トラック分のデータがＦＢＡの
記憶部に記憶される。逆に、ＦＢＡディスク１００の記
憶部２００からの読み込みは、上記動作の逆を行なうこ
とにより達成される。

【０１０９】

【発明の効果】この発明においては、上記ギャップの削
除によりトラックデータを保持するメモリ容量を低減で
きる。また、上記位置情報により目的とするＣＫＤレコ
ードの位置確認ができるのでメモリアクセス回数及びメ
モリ容量の低減に役立つ。

【図面の簡単な説明】

【図１】この発明のフォーマット変換方式の概略ブロッ
ク図である。

【図２】この発明のフォーマット変換方式を説明するた
めのブロック図である。

【図３】この発明のフォーマット変換の動作を説明する
図である。

【図４】この発明のフォーマット変換の動作を説明する
図である。

【図５】この発明のフォーマット変換の動作を説明する
図である。

【図６】ギャップの残し方を説明を説明するための図で
ある。

【図７】レコードの位置決め方法を説明するための図で
ある。

【図８】トラック容量のチェック方法を示す図である。

【図９】ＣＫＤ−ＦＢＡ変換方式の比較表を示す図であ
る。

【図１０】ＣＫＤレコードのＦＢＡブロックへの分割例
を示す図である。

【図１１】ＲＡＩＤにおけるＣＫＤトラックの分割例を
示す図である。

【図１２】メモリ容量の見積りを示す図である。

【図１３】トラック当りのレコード数を示す図である。

【図１４】トラック当りのレコード数を示す図である。

【図１５】トラック当りのレコード数を示す図である。

【図１６】トラック当りのレコード数を示す図である。

【図１７】メモリ容量の見積りを示す図である。

【図１８】メモリ容量の見積りのグラフ図である。

【図１９】１トラック分のイメージデータが少ない場合
のメリットを示す図である。

【図２０】レコードポインタの保持情報を示す図であ
る。

【図２１】位置情報の管理単位を示す図である。

【図２２】位置情報のメモリ容量の見積りを示す図であ
る。

【図２３】レコードのために必要な最大メモリ容量を示
す図である。

【図２４】位置情報の保持方法の一例を示す図である。

【図２５】レコード位置決め方式の改善案を示す図であ
る。

【図２６】フレーム中の空きバイトを示す図である。

【図２７】位置情報のメモリ容量の見積りを示す図であ
る。

【図２８】レコードのために必要な最大メモリ容量を示
す図である。

【図２９】Ｅ１８８０系のセグメントナンバを説明する
図である。

【図３０】仮想ＣＫＤトラック上のフォーマットイメー
ジを示す図である。

【図３１】フィールド毎の最大削除バイト数を示す図で
ある。

【図３２】この発明の他の実施例を示す図である。

【図３３】ＣＫＤレコードのフィールドの内容を示す図
である。

【図３４】サーボ面サーボ方式を用いる磁気ディスクの
概略図である。

【図３５】トラックとセクタとセグメントの関係を示す
図である。

【図３６】従来のソフトウェアがＣＫＤレコード方式に
基づいて出力するコマンドシーケンスの一例を示す図で
ある。

【図３７】従来のＣＫＤ−ＦＢＡ変換方式を示す図であ
る。

【符号の説明】

１ ホスト計算機 ２ａ チャネル ２ｂ チャネル ２ｃ チャネル ２ｄ チャネル ２ｅ チャネル ３ ＣＫＤフォーマットのレコード ４ ＣＫＤコマンド ５ 磁気ディスク制御装置 ６ キャッシュ・メモリ ７ ＣＫＤのトラックイメージ ８ ＦＢＡフォーマットのレコード ９ ＦＢＡディスク １０ ＦＢＡコマンド ５１ チャネルパスサーバ（ＣＰＳ） ５２ 入力部／出力部 ５３ 位置計算部 ５４ レコード検索部 ５５ 読み書き部 ５６ 管理単位検索部 ５７ レコード特定部 １００ ＣＫＤ−ＦＢＡ変換装置 １０１ ギャップ削除部 １０２ レコード配置部 １０３ 固定ブロック記憶部 ＣＫＤレコード 可変長レコード ＦＢＡレコード 固定長レコード

Claims (11)

(57)【特許請求の範囲】
1. 【請求項１】 可変長フォーマットで記憶されたレコー
   ドを固定長フォーマットに変換して記憶するデータ記憶
   フォーマット変換方式において、 可変長フォーマットで記録される１トラック分の可変長
   レコードからレコード間ギャップ及びフィールド間ギャ
   ップを削除してトラックデータを生成するギャップ削除
   手段、 上記ギャップ削除手段によりギャップを削除したトラッ
   クデータを所定のサイズの管理単位に配置し、その管理
   単位に含まれる可変長レコードの位置を示す第１の位置
   情報と、その管理単位に含まれる可変長レコードの可変
   長レコードフォーマットでのトラックの先頭からの相対
   位置を示す第２の位置情報とを上記管理単位に記憶する
   レコード配置手段、 上記管理単位を固定長レコードの固定長ブロック長サイ
   ズに分割して記憶する固定ブロック記憶手段を備えたこ
   とを特徴とするデータ記憶フォーマット変換方式。
2. 【請求項２】 上記レコード配置手段は、可変長レコー
   ドを上記管理単位の一方から順に配置するとともに、配
   置した可変長レコードに対応する第１と第２の位置情報
   を上記管理単位の他方から順に配置することを特徴とす
   る請求項１記載のデータ記憶フォーマット変換方式。
3. 【請求項３】 上記レコード配置手段は、あらかじめ管
   理単位内に、第１と第２の位置情報を記憶する領域と可
   変長レコードを記憶する領域とを定めておくことを特徴
   とする請求項１記載のデータ記憶フォーマット変換方
   式。
4. 【請求項４】 上記第１の位置情報は管理単位に含まれ
   る可変長レコードの管理単以内のメモリアドレスであ
   り、上記第２の位置情報はトラックの先頭からのセクタ
   値、あるいはセグメント値であることを特徴とする請求
   項１記載のデータ記憶フォーマット変換方式。
5. 【請求項５】 上記可変長レコードは、可変長レコード
   内に、可変長レコードフォーマットでのトラックの先頭
   からの相対位置を示すセグメント情報を有していること
   を特徴とする請求項１記載のデータ記憶フォーマット変
   換方式。
6. 【請求項６】 可変長フォーマットからギャップを削除
   し、そのデータを所定サイズの管理単位に配置し、その
   管理単位に含まれる可変長レコードの位置を示すアドレ
   ス情報と、その管理単位に含まれる可変長レコードの可
   変長フォーマットでの先頭からの相対位置を示す相対位
   置情報を保持させ、固定長レコードの固定長ブロックサ
   イズに分割して固定長フォーマットとして記憶させた記
   憶部に対して以下の要素を用いてアクセスするアクセス
   制御装置 （ａ）上記記憶部に対して上記管理単位でデータを読み
   書きする読み書き手段、 （ｂ）上記読み書き手段により読み書きされるデータを
   管理単位ごとに格納するメモリ、 （ｃ）レコードが可変長フォーマットで記憶されている
   ものとして出力された可変長レコードへのアクセス命令
   を入力する入力手段、 （ｄ）上記入力手段により入力したアクセス命令に基づ
   いて、アクセスする可変長レコードが記憶されていると
   考えられる管理単位の位置を概算する位置計算手段、 （ｅ）上記位置計算手段により概算された位置にある管
   理単位を上記読み書き手段により上記記憶部から上記メ
   モリに読み込み、上記入力手段により入力されたアクセ
   ス命令がアクセスしようとするレコードを検索するレコ
   ード検索手段。
7. 【請求項７】 上記アクセス制御装置は、さらに、相対
   位置情報を用いて、可変長レコード方式でレコードが記
   憶されている場合のトラックの使用容量を判定すること
   を特徴とする請求項６記載のアクセス制御装置。
8. 【請求項８】 上記入力手段はアクセスしようとするレ
   コードの相対位置情報を入力するとともに、 上記レコード検索手段は、 上記アクセスしようとするレコードの相対位置情報を、
   検索された管理単位に保持されている相対位置情報とを
   比較し、アクセスしようとするレコードの相対位置情報
   を持つ管理単位が見つかるまで、読み書き手段により次
   の管理単位を記憶部からメモリに読み込むことにより管
   理単位を検索する管理単位検索手段と、上記管理単位検
   索手段によりアクセスしようとするレコードの相対位置
   情報を持つ管理単位が見つかった場合に、その管理単位
   に含まれるアドレス情報を用いてアクセスしようとする
   可変長レコードを特定するレコード特定手段を有するこ
   とを特徴とする請求項６記載のアクセス制御装置。
9. 【請求項９】 以下の工程を有するデータ記憶フォーマ
   ット変換方法 （ａ）データを有するフィールド及びレコード間ギャッ
   プ及びフィールド間ギャップを有する可変長フォーマッ
   トからレコード間ギャップ及びフィールド間ギャップを
   削除して各可変長レコードのフィールドを連結するギャ
   ップ削除工程、 （ｂ）上記ギャップ削除工程により連結された各可変長
   レコードをあらかじめ定められたサイズを持つフレーム
   に順に配置するとともに、各可変長レコードをアクセス
   するためのアクセス情報を各可変長レコードに対応させ
   て記憶するレコード配置工程、 （ｃ）上記フレームを複数の固定長のブロックサイズに
   分割して固定長フォーマットとして記憶する固定長ブロ
   ック記憶工程。
10. 【請求項１０】 上記レコード配置工程は、アクセス情
    報として、各可変長レコードが配置されたフレームの位
    置情報と、各可変長レコードが可変長フォーマットに基
    づいて記憶されている場合の位置情報を記憶することを
    特徴とする請求項９記載のデータ記憶フォーマット変換
    方法。
11. 【請求項１１】 以下の工程を有し、上記請求項９記載
    のデータ記憶フォーマット変換方法により記憶された固
    定長フォーマットのデータをアクセスするデータアクセ
    ス方法 （ａ）可変長フォーマットのレコードをアクセスするた
    めのコマンドとアクセスするデータの検索情報を入力す
    るアクセスコマンド入力工程、 （ｂ）上記アクセスコマンド入力工程により入力した検
    索情報からアクセスするレコードが記憶されているフレ
    ームの位置情報を推定する位置情報推定工程、 （ｃ）上記位置情報推定工程により推定された位置情報
    をもつフレーム以降のフレームを順に固定長フォーマッ
    トで記憶された複数の固定長ブロックから再生し、アク
    セスするレコードを検索するレコード検索工程。