JPS61226847A - ブロツク内管理方法 - Google Patents
ブロツク内管理方法Info
- Publication number
- JPS61226847A JPS61226847A JP60067002A JP6700285A JPS61226847A JP S61226847 A JPS61226847 A JP S61226847A JP 60067002 A JP60067002 A JP 60067002A JP 6700285 A JP6700285 A JP 6700285A JP S61226847 A JPS61226847 A JP S61226847A
- Authority
- JP
- Japan
- Prior art keywords
- record
- block
- header
- address
- records
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
(57)【要約】本公報は電子出願前の出願データであるた
め要約のデータは記録されません。
め要約のデータは記録されません。
Description
【発明の詳細な説明】
［発明の技術分野］
この発明は、ディスクファイルにおけるブロック内管理
方法に関する。
方法に関する。
［発明の技術的背ＩＩ］
ブロックは、周知のように（ファイルの）磁気ディスク
と主記憶との間の転送（入出力）単位である。このブロ
ック内を管理するには、第７図に示すように、該当ブロ
ックのブロック制御情報を保持するブロックヘッダ（Ｂ
Ｈ）１１と、該当ブロック内に格納されるレコード（レ
コード本体）１２゜１２・・・のレコード制御情報を保
持するレコードヘッダ（ＲＨ）１３．１３・・・が必要
となる。ブロックヘッダ１１は、従来のブロック内管理
方法では、第７図に示すようにブロック先頭領域に配置
され、レコードヘッダ１３は対応するレコード１２と対
を成してブロックヘッダ１１に侵続する領域にレコード
番号等の規則に従った並び順で配置されていた。
と主記憶との間の転送（入出力）単位である。このブロ
ック内を管理するには、第７図に示すように、該当ブロ
ックのブロック制御情報を保持するブロックヘッダ（Ｂ
Ｈ）１１と、該当ブロック内に格納されるレコード（レ
コード本体）１２゜１２・・・のレコード制御情報を保
持するレコードヘッダ（ＲＨ）１３．１３・・・が必要
となる。ブロックヘッダ１１は、従来のブロック内管理
方法では、第７図に示すようにブロック先頭領域に配置
され、レコードヘッダ１３は対応するレコード１２と対
を成してブロックヘッダ１１に侵続する領域にレコード
番号等の規則に従った並び順で配置されていた。
［背景技術の問題点］
上記した従来のブロック内管理方法では、ブロック内レ
コードの検索手段としては例えば可変長レコード形式の
場合であればブロック先頭よりのスキャンサーチ以外に
適当な手段が無い。しかし、スキャンサーチによるブロ
ック内レコード検索では、例えばブロックサイズが大き
く１ブロツク内格納レコ一ド件数が多い場合には処理時
間が長くなりＣＰＵのオーバーヘッドが増加する問題が
あった。
コードの検索手段としては例えば可変長レコード形式の
場合であればブロック先頭よりのスキャンサーチ以外に
適当な手段が無い。しかし、スキャンサーチによるブロ
ック内レコード検索では、例えばブロックサイズが大き
く１ブロツク内格納レコ一ド件数が多い場合には処理時
間が長くなりＣＰＵのオーバーヘッドが増加する問題が
あった。
また仮想記憶方式を適用する計算機では、システムバッ
ファ（通常ブロックサイズと一致する大きさを持つ）が
ページまたがりをする場合、上記のスキャンサーチを行
なうことによりページフォルトが多発する問題もあった
。
ファ（通常ブロックサイズと一致する大きさを持つ）が
ページまたがりをする場合、上記のスキャンサーチを行
なうことによりページフォルトが多発する問題もあった
。
［発明の目的］
この発明は上記事情に鑑みてなされたものでその目的は
、固定長／可変長のレコード形式に無関係にブロック内
スキャンサーチによらずに目的レコードが簡単に検索で
きるブロック内管理方式を提供することにある。
、固定長／可変長のレコード形式に無関係にブロック内
スキャンサーチによらずに目的レコードが簡単に検索で
きるブロック内管理方式を提供することにある。
［発明の概要］
この発明では、ディスクファイルにおけるブロックの後
尾側にブロックヘッダが配置される。ま゛たレコードは
ブロック先頭より格納される。一方、上記レコードのレ
コードヘッダは、予め定められたレコード管理の規則に
従う並び順でブロックヘッダに続く領域よリブロック先
頭に向かって配置される。上記レコードヘッダは、対応
するレコードのブロック内格納領域を示すブロック内格
納レコード領域情報を含む。即ちこの発明では、レコー
ドヘッダをレコード本体から切離し、同レコードヘッダ
をブロックヘッダと共にブロック後尾側に集中させるこ
とにより、目的とするレコードのレコードヘッダがレコ
ード形式に影響されずに一義的に参照できる構成とし、
同レコードヘッダを参照することにより目的レコードを
検索するようにしている。
尾側にブロックヘッダが配置される。ま゛たレコードは
ブロック先頭より格納される。一方、上記レコードのレ
コードヘッダは、予め定められたレコード管理の規則に
従う並び順でブロックヘッダに続く領域よリブロック先
頭に向かって配置される。上記レコードヘッダは、対応
するレコードのブロック内格納領域を示すブロック内格
納レコード領域情報を含む。即ちこの発明では、レコー
ドヘッダをレコード本体から切離し、同レコードヘッダ
をブロックヘッダと共にブロック後尾側に集中させるこ
とにより、目的とするレコードのレコードヘッダがレコ
ード形式に影響されずに一義的に参照できる構成とし、
同レコードヘッダを参照することにより目的レコードを
検索するようにしている。
［発明の実施例］
以下、この発明の一実施例図面を参照して説明する。
第１図はこの発明の一実施例に係るブロックの構造を示
すもので図示左上側がブロック先頭、右下側がブロック
後尾となっている。第１図のブロックでは、ブロック後
尾（下方）から第２図に示すフォーマットの固定長のブ
ロックヘッダ（ＢＨ）２１がまず配置される。一方、ブ
ロック先＠（上方）からは例えば第ルコード２２−１．
第２レコード２２−２．第３レコード２２−３が格納さ
れている。またブロックヘッダ２１に続く領域には、第
３図に示すフォーマットの固定長の第２レコードヘツダ
（ＲＨ−１） ２３−１．第２レコードヘツダ（ＲＨ−
２） ２３−２゜第３レコードヘツダ（ＲＨ−３） ２
３−３が、レコード番号等の規則に従うて配置されてい
る。即ちこの実施例では、レコード＊１＊がブロック先
頭から割当てられ、ブロックヘッダおよびレコードヘッ
ダの制御情報領域がブロック後尾から割当てられる。
すもので図示左上側がブロック先頭、右下側がブロック
後尾となっている。第１図のブロックでは、ブロック後
尾（下方）から第２図に示すフォーマットの固定長のブ
ロックヘッダ（ＢＨ）２１がまず配置される。一方、ブ
ロック先＠（上方）からは例えば第ルコード２２−１．
第２レコード２２−２．第３レコード２２−３が格納さ
れている。またブロックヘッダ２１に続く領域には、第
３図に示すフォーマットの固定長の第２レコードヘツダ
（ＲＨ−１） ２３−１．第２レコードヘツダ（ＲＨ−
２） ２３−２゜第３レコードヘツダ（ＲＨ−３） ２
３−３が、レコード番号等の規則に従うて配置されてい
る。即ちこの実施例では、レコード＊１＊がブロック先
頭から割当てられ、ブロックヘッダおよびレコードヘッ
ダの制御情報領域がブロック後尾から割当てられる。
なお第１図において、Ｍｉレコードヘッダ（ＲＨ−ｉ）
２３−ｉは第３レコード２２−１に対応している。
２３−ｉは第３レコード２２−１に対応している。
次に、上記のようにして管理されるブロック内のレコー
ドを検索（参照）する場合について第４図のフローチャ
ートを参照して説明する。
ドを検索（参照）する場合について第４図のフローチャ
ートを参照して説明する。
一般にレコード検索処理は、ファイルアクセス情報を保
持する図示せぬテーブル（以下、ＡＣＢと称する）上に
持つレコードポインタを用いてＯ８（オペレーティング
システム）により行なわれる。このＡＣＢは主記憶（図
示せず）に置かれ、またレコードポインタは、ファイル
内相対第Ｘブロック内の第ｙレコードを表わす（Ｘ、Ｖ
）の組合わせで構成される。レコード検索処理の制御手
順は以下の通りである。
持する図示せぬテーブル（以下、ＡＣＢと称する）上に
持つレコードポインタを用いてＯ８（オペレーティング
システム）により行なわれる。このＡＣＢは主記憶（図
示せず）に置かれ、またレコードポインタは、ファイル
内相対第Ｘブロック内の第ｙレコードを表わす（Ｘ、Ｖ
）の組合わせで構成される。レコード検索処理の制御手
順は以下の通りである。
■ まず磁気ディスク（図示せず）上に置かれている第
×ブロックを主記憶上に確保されるブロックバッファ領
域（図示せず）に読込む（ステップ５１）。
×ブロックを主記憶上に確保されるブロックバッファ領
域（図示せず）に読込む（ステップ５１）。
■ ブロックバッファ領域に読込んだ第Ｘブロック内の
ブロックヘッダ（２１）の先頭アドレス（ブロックヘッ
ダアドレス）Ａｂｈを算出する（ステップ５２）。この
ブロックアドレスＡｂｈは、ＡＣＢによリブロックバッ
ファ先頭アドレスＡｂおよびサイズｓｂが分り、またブ
ロックヘッダ（２１）のサイズｓｂｈは固定長であるこ
とから、Ａｂｈ−Ａｂ 十Ｓｂ −８ｂｈ の計算により求められる。
ブロックヘッダ（２１）の先頭アドレス（ブロックヘッ
ダアドレス）Ａｂｈを算出する（ステップ５２）。この
ブロックアドレスＡｂｈは、ＡＣＢによリブロックバッ
ファ先頭アドレスＡｂおよびサイズｓｂが分り、またブ
ロックヘッダ（２１）のサイズｓｂｈは固定長であるこ
とから、Ａｂｈ−Ａｂ 十Ｓｂ −８ｂｈ の計算により求められる。
■ ブロックヘッダアドレスＡｂｈに基づいてブロック
ヘッダ（２１）を参照し、同ヘッダ（２１）内に記述さ
れているブロックヘッダ内格納レコード件数とｙとを比
較し、目的とするレコードが存在するか否かをチェック
する（ステップ５３）。
ヘッダ（２１）を参照し、同ヘッダ（２１）内に記述さ
れているブロックヘッダ内格納レコード件数とｙとを比
較し、目的とするレコードが存在するか否かをチェック
する（ステップ５３）。
■ 第ｙレコード（２２−Ｖ）のレコードヘッダ（２３
−ｙ）の先頭アドレス（レコードヘッダアドレス）Ａｒ
ｈを算出する（ステップ５４）。このレコードヘッダア
ドレスＡｒｈは、レコードヘッダのサイズＳｒｈが固定
長であることから、 Ａｒｈ−Ａｂｈ −ｙ−８ｒｈ の計算により求められる。
−ｙ）の先頭アドレス（レコードヘッダアドレス）Ａｒ
ｈを算出する（ステップ５４）。このレコードヘッダア
ドレスＡｒｈは、レコードヘッダのサイズＳｒｈが固定
長であることから、 Ａｒｈ−Ａｂｈ −ｙ−８ｒｈ の計算により求められる。
■ レコードヘッダアドレスＡｒｈに基づいて目的の第
ｙレコード（２３−Ｖ）に対応するレコードヘッダ（２
３−Ｖ）を参照し、（レコード制御フラッグにより）目
的レコードの状態（削除レコード等）をチェックし、更
にブロック内相対レコード位置（ブロック内相対アドレ
ス）並びにレコードサイズを得、目的レコードの検索を
行なう（ステップ５５）。
ｙレコード（２３−Ｖ）に対応するレコードヘッダ（２
３−Ｖ）を参照し、（レコード制御フラッグにより）目
的レコードの状態（削除レコード等）をチェックし、更
にブロック内相対レコード位置（ブロック内相対アドレ
ス）並びにレコードサイズを得、目的レコードの検索を
行なう（ステップ５５）。
以上の手順により、固定長／可変長のレコード形式に無
関係にレコード検索が可能となる。
関係にレコード検索が可能となる。
次に、レコード挿入処理について第５図のブロック状態
遷移図および第６図のフローチャ、−トを参照し、第ｙ
レコードと第２レコードの間に第ｎレコードを挿入する
場合を例にとって説明する。
遷移図および第６図のフローチャ、−トを参照し、第ｙ
レコードと第２レコードの間に第ｎレコードを挿入する
場合を例にとって説明する。
■ まず挿入対象となる第ｎレコードと同レコードに対
応する第ｎレコードヘッダ（ＲＨ−ｎ）が、第５図（ａ
）に示す該当ブロックの空き領域に格納可能であるか否
かをチェックする （ステップ６１）。これは、 Ｓｆ・・・空き領域サイズ ３ｒｎ・・・第ｎレコードのサイズ Ｓｒｈ・・・レコードヘッダのサイズ とすると、次式 ％式％ を満たすか否かの判定により行なわれる。なお空き領域
サイズＳｆは、第２図から明らかなように、（該当ブロ
ックの）ブロックヘッダ（８Ｈ）を参照することにより
求められる。
応する第ｎレコードヘッダ（ＲＨ−ｎ）が、第５図（ａ
）に示す該当ブロックの空き領域に格納可能であるか否
かをチェックする （ステップ６１）。これは、 Ｓｆ・・・空き領域サイズ ３ｒｎ・・・第ｎレコードのサイズ Ｓｒｈ・・・レコードヘッダのサイズ とすると、次式 ％式％ を満たすか否かの判定により行なわれる。なお空き領域
サイズＳｆは、第２図から明らかなように、（該当ブロ
ックの）ブロックヘッダ（８Ｈ）を参照することにより
求められる。
■ 第ｎレコードおよびそのレコードヘッダ（ＲＨ−ｎ
）が該当ブロックの空き領域に格納可能であれば、第５
図（ｂ）に矢印Ａで示すように、第ｎレコードを上記空
き領域の先頭アドレスから順に格納する（ステップ６２
）。なお空きｌ域の先頭アドレスは、第２図から明らか
なように、（該当ブロックの）ブロックヘッダ（ＢＨ）
を参照することにより求められる。
）が該当ブロックの空き領域に格納可能であれば、第５
図（ｂ）に矢印Ａで示すように、第ｎレコードを上記空
き領域の先頭アドレスから順に格納する（ステップ６２
）。なお空きｌ域の先頭アドレスは、第２図から明らか
なように、（該当ブロックの）ブロックヘッダ（ＢＨ）
を参照することにより求められる。
■ 第５図（Ｃ）に矢印Ｂで示すように、第２レコード
ヘツダ（ＲＨ−ｙ）と第２レコードヘツダ（ＲＨ−２）
との闇に第ｎレコードヘッダ（ＲＨ−ｎ）を挿入し、レ
コードヘッダの再編成を行なう（ステップ６３）。この
場合、第２レコードヘツダ（ＲＨ−Ｚ）はルコードヘッ
ダ分上方に移動される。
ヘツダ（ＲＨ−ｙ）と第２レコードヘツダ（ＲＨ−２）
との闇に第ｎレコードヘッダ（ＲＨ−ｎ）を挿入し、レ
コードヘッダの再編成を行なう（ステップ６３）。この
場合、第２レコードヘツダ（ＲＨ−Ｚ）はルコードヘッ
ダ分上方に移動される。
■ 第５図（（ｊ）に矢印Ｃで示すように、ブロックヘ
ッダ（ＢＨ）内に記述されているブロック内格納レコー
ド件数、空き領域先頭アドレス、および空き領域サイズ
を更新する（ステップ６４）。
ッダ（ＢＨ）内に記述されているブロック内格納レコー
ド件数、空き領域先頭アドレス、および空き領域サイズ
を更新する（ステップ６４）。
以上の手順により、レコードヘッダの再編成のみによっ
て、格納レコードを移動することなくレコード挿入処理
が行なえる。
て、格納レコードを移動することなくレコード挿入処理
が行なえる。
［発明の効果］
以上詳述したようにこの発明によれば、次に列挙する作
用効果を奏することができる。
用効果を奏することができる。
■ 固定長のレコード形式は勿論、可変長のレコード形
式の場合でも、高々数口のアドレス計算を行なうだけで
ブロック内スキャンサーチを行なうことなくレコードの
検索が可能であり、したがってレコード検索処理の高速
化が図れ、且つＣＰＵのオーバーヘッドの低減が図れる
。
式の場合でも、高々数口のアドレス計算を行なうだけで
ブロック内スキャンサーチを行なうことなくレコードの
検索が可能であり、したがってレコード検索処理の高速
化が図れ、且つＣＰＵのオーバーヘッドの低減が図れる
。
■ 上記■により仮想計算機ではページフォルトの発生
回数が低減される。
回数が低減される。
■ レコードの論理的な順序で管理する編成法において
、レコード順序を維持するのに格納レコードの移動処理
が不要であり、単にレコードヘッダの再編成だけで済む
ために移動サイズが小ざくて済み、ＣＰＵのオーバーヘ
ッドが低減される。
、レコード順序を維持するのに格納レコードの移動処理
が不要であり、単にレコードヘッダの再編成だけで済む
ために移動サイズが小ざくて済み、ＣＰＵのオーバーヘ
ッドが低減される。
■ ブロック先頭からレコード領域が割当てられること
から、ダンプリストが見易くなる。
から、ダンプリストが見易くなる。
第１図はこの発明の一実施例に係るブロックの構造を示
す図、第２図はブロックヘッダのフォーマット図、第３
図はレコードヘッダのフォーマツト図、第４図はレコー
ド検索処理の手順を示すフローチャート、第５図はレコ
ード挿入処理を説明するブロック状態遷移図、第６図は
レコード挿入処理の手順を示すフローチャート、第７図
は従来例を示す図である。 ２１・・・ブロックヘッダ（Ｂ Ｈ） 、２２−１．２
２−２．２２−３・・・レコード、２３−１ （ＲＨ−
１） 、 ２３−２ （ＲＨ−２） 。 ２３−３ （ＲＨ−３）・・・レコードヘッダ。 出願人代理人 弁理士 鈴 江 武 彦第１図
第４図 第５図
す図、第２図はブロックヘッダのフォーマット図、第３
図はレコードヘッダのフォーマツト図、第４図はレコー
ド検索処理の手順を示すフローチャート、第５図はレコ
ード挿入処理を説明するブロック状態遷移図、第６図は
レコード挿入処理の手順を示すフローチャート、第７図
は従来例を示す図である。 ２１・・・ブロックヘッダ（Ｂ Ｈ） 、２２−１．２
２−２．２２−３・・・レコード、２３−１ （ＲＨ−
１） 、 ２３−２ （ＲＨ−２） 。 ２３−３ （ＲＨ−３）・・・レコードヘッダ。 出願人代理人 弁理士 鈴 江 武 彦第１図
第４図 第５図
Claims (1)
- ディスクファイルにおけるブロックの後尾側にブロック
ヘッダを配置する一方、ブロック先頭よりレコードを格
納し、且つ同レコードのブロック内格納領域を示すブロ
ック内格納レコード領域情報を含むレコードヘッダを上
記ブロックヘッダに続く領域よリブロック先頭に向かっ
て予め定められたレコード管理の規則に従う並び順に配
置し、上記レコードヘッダの上記ブロック内レコード格
納領域情報に基づいてレコード検索を行なうようにした
ことを特徴とするブロック内管理方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP60067002A JPS61226847A (ja) | 1985-03-30 | 1985-03-30 | ブロツク内管理方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP60067002A JPS61226847A (ja) | 1985-03-30 | 1985-03-30 | ブロツク内管理方法 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JPS61226847A true JPS61226847A (ja) | 1986-10-08 |
Family
ID=13332293
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP60067002A Pending JPS61226847A (ja) | 1985-03-30 | 1985-03-30 | ブロツク内管理方法 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JPS61226847A (ja) |
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPS63145582A (ja) * | 1986-12-09 | 1988-06-17 | Toshiba Corp | Ｉｃカード |
| JPH01263714A (ja) * | 1988-04-14 | 1989-10-20 | Fujitsu Ltd | 情報記録管理システム |
| JPH103359A (ja) * | 1996-06-19 | 1998-01-06 | Nec Ibaraki Ltd | フォーマット情報記録方式 |
| JP2012118892A (ja) * | 2010-12-03 | 2012-06-21 | Yazaki Corp | データ格納装置及びデータ格納方法 |
-
1985
- 1985-03-30 JP JP60067002A patent/JPS61226847A/ja active Pending
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPS63145582A (ja) * | 1986-12-09 | 1988-06-17 | Toshiba Corp | Ｉｃカード |
| JPH01263714A (ja) * | 1988-04-14 | 1989-10-20 | Fujitsu Ltd | 情報記録管理システム |
| JPH103359A (ja) * | 1996-06-19 | 1998-01-06 | Nec Ibaraki Ltd | フォーマット情報記録方式 |
| JP2012118892A (ja) * | 2010-12-03 | 2012-06-21 | Yazaki Corp | データ格納装置及びデータ格納方法 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EP0487331B1 (en) | Directory management system | |
| JP3024619B2 (ja) | ファイル管理方法 | |
| US6442553B1 (en) | Hash system and hash method for transforming records to be hashed | |
| JPS61226847A (ja) | ブロツク内管理方法 | |
| JP3515810B2 (ja) | ソート処理方法および装置 | |
| US5170479A (en) | File block managing system using next record header position data and delete history data from block header and record headers to locate requested record block | |
| US5430846A (en) | List-based buffering mechanism for buffering data between processes in a data processing system | |
| JP2874810B2 (ja) | キーの記憶割り当て方法 | |
| JPH0381843A (ja) | ファイル退避復元処理装置 | |
| JPH04112253A (ja) | 多層バッファを用いるデータアクセス方法 | |
| JPS6079444A (ja) | ガ−ベジ・コレクシヨン処理方式 | |
| JPS586570A (ja) | バツフアメモリ装置 | |
| JPH04172541A (ja) | レコード格納装置 | |
| JPS6143338A (ja) | 連想技術を使用して稀薄なデータベースをサーチする方法 | |
| GB2114784A (en) | Information-indexing machines | |
| JPS61278932A (ja) | デ−タ追加処理方法 | |
| JP2619944B2 (ja) | イメージデータ管理処理装置 | |
| JP2612063B2 (ja) | マスクレイアウトデータの表示方法 | |
| JPS62194554A (ja) | メモリ内容管理方式 | |
| JPS62222339A (ja) | ブロツク内レコ−ド管理方式 | |
| JPH07200407A (ja) | 仮想記憶システム | |
| JPH06348572A (ja) | マルチ機構ディスクシステム | |
| JPH1051469A (ja) | Ａｔｍスイッチ | |
| JPS5938845A (ja) | 順次検索方式 | |
| JPS61156450A (ja) | 動的バッファ管理方法 |