JPH0934767A

JPH0934767A - 索引編成ファイルの自動復旧方式

Info

Publication number: JPH0934767A
Application number: JP7179973A
Authority: JP
Inventors: Yasukazu Kubota; 安一窪田
Original assignee: Sharp Corp
Current assignee: Sharp Corp
Priority date: 1995-07-17
Filing date: 1995-07-17
Publication date: 1997-02-07

Abstract

(57)【要約】【課題】システムダウンした際にも、データファイル
とインデックスファイルとの整合性を保つことが可能な
索引編成ファイルの自動復旧方式を提供する。【課題解決手段】本発明のファイル自動復旧方式は、
ＷＲＩＴＥ命令によるレコード追加時には、追加される
レコードの番号を不揮発性メモリに格納し、かつ、追加
すべきレコードの内容をデータファイルに登録した後、
追加すべきレコードのキーをインデックスファイルに登
録することが行われる処理であって、システム起動直後
における不揮発性メモリの内容に基づき、ファイルオー
プン中であり、かつ、レコード追加中である際には、追
加すべきレコードの内容がデータファイルに存在してい
るか否かを確認し、存在している場合には、インデック
スファイルに対して追加すべきレコードのキーの再登録
を試みたうえで不揮発性メモリの内容を消去することを
特徴としている。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は索引編成ファイルの
自動復旧方式にかかり、特には、無停電電源装置を具備
していない情報処理装置を構成する停電表示装置のＣＯ
ＢＯＬ言語環境によるファイル処理に関する。

【０００２】

【従来の技術】計算機システムの２次記憶媒体上に格納
されるファイルのバックアップ方式としては、例えば、
特開昭４−９８５４５号公報で開示されているファイル
自動復旧方式がある。そして、このファイル自動復旧方
式においては、２次記憶媒体上でファイルの作成または
更新を行うに際し、まずもって、２次記憶媒体上のファ
イル情報管理テーブルを更新用及び退避用のメモリに読
み込んだ後、退避用メモリ内のファイル情報管理テーブ
ルにファイル情報管理テーブル更新中の表示を立てたう
えで退避用のファイル情報管理テーブルを２次記憶媒体
上にコピーしている。すなわち、この方式では、システ
ムダウン後の回復時における２次記憶媒体に対してアク
セスすることにより、ファイル情報管理テーブル更新中
の表示を参照したうえ、更新中であれば２次記憶媒体上
に退避しておいた更新前のファイル情報管理テーブルを
コピーすることによってファイルを復旧させることにな
っている。

【０００３】

【発明が解決しようとする課題】ところで、前記従来の
ファイル自動復旧方式においては、ソフトウェアやハー
ドウェアの障害などによって計算機システムがダウンし
た際、退避しておいたファイル情報管理テーブルをコピ
ーすることが行われるのであるが、これだけではシステ
ムダウン時に登録中であったファイルを登録以前の状態
にまで戻せるに過ぎず、登録中のレコードの内容が重要
であった場合における運用上の被害が生じることは避け
られない。そして、特に、この際におけるファイルが、
索引編成ファイルのようなファイルシステム、つまり、
複数のファイル同士が互いに関連付けられた構成のファ
イルシステムであった場合には、データファイルとイン
デックスファイルとの整合性が崩れるというような不都
合が発生することになってしまう。

【０００４】本発明は、このような不都合に鑑みて創案
されたものであって、計算機システムがダウンした際に
おいても、登録中であったレコードの内容を可能な限り
有効に利用することができ、データファイルとインデッ
クスファイルとの整合性を保つことが可能な構成とされ
た索引編成ファイルの自動復旧方式を提供するものであ
る。

【０００５】

【課題を解決するための手段】本発明にかかる第１のフ
ァイル自動復旧方式は、上記目的を達成するため、計算
機システムの２次記憶媒体上で索引編成ファイルの更新
を行う際のファイルオープン時には、ファイル名、レコ
ード長及びキー位置などのファイル基本情報を不揮発性
メモリに格納することが行われ、また、ＷＲＩＴＥ命令
によるレコード追加時には、追加されるレコードの番号
を不揮発性メモリに格納し、かつ、追加すべきレコード
の内容をデータファイルに登録した後、追加すべきレコ
ードのキーをインデックスファイルに登録することが行
われ、さらに、ファイルクローズ時には、ファイル基本
情報を消去することが行われる処理であって、システム
起動直後における不揮発性メモリの内容に基づき、ファ
イルオープン中であり、かつ、レコード追加中である際
には、追加すべきレコードの内容がデータファイルに存
在しているか否かを確認し、存在している場合には、イ
ンデックスファイルに対して追加すべきレコードのキー
の再登録を試みたうえで不揮発性メモリの内容を消去す
ることを特徴としている。

【０００６】そして、第２のファイル自動復旧方式は、
計算機システムの２次記憶媒体上で索引編成ファイルの
更新を行う際のファイルオープン時には、ファイル名、
レコード長及びキー位置などのファイル基本情報を不揮
発性メモリに格納することが行われ、また、ＲＥＷＲＩ
ＴＥ命令によるレコード書き換え時には、書き換えられ
るレコードのデータ及び番号を不揮発性メモリに格納
し、書き換え前のレコードの内容を削除して書き換え後
のレコードの内容をデータファイルに登録した後、書き
換え前のレコードのキーを削除して書き換え後のレコー
ドのキーをインデックスファイルに登録することが行わ
れ、さらに、ファイルクローズ時には、ファイル基本情
報を消去することが行われる処理であって、システム起
動直後における不揮発性メモリの内容に基づき、ファイ
ルオープン中であり、かつ、レコード書き換え中である
際には、不揮発性メモリに格納されたレコードの内容
と、データファイルに登録されたレコードの内容とを比
較し、相違している場合には、インデックスファイルに
対して書き換え前のレコードのキーの再削除及び書き換
え後のレコードのキーの再登録を試みたうえで不揮発性
メモリの内容を消去することを特徴とするものである。

【０００７】また、第３のファイル自動復旧方式は、計
算機システムの２次記憶媒体上で索引編成ファイルの更
新を行う際のファイルオープン時には、ファイル名、レ
コード長及びキー位置などのファイル基本情報を不揮発
性メモリに格納することが行われ、また、ＤＥＬＥＴＥ
命令によるレコード削除時には、削除されるレコードの
番号を不揮発性メモリに格納し、かつ、削除すべきレコ
ードのキーをインデックスファイルから削除した後、削
除すべきレコードの内容をデータファイルから削除する
ことが行われ、さらに、ファイルクローズ時には、ファ
イル基本情報を消去することが行われる処理であって、
システム起動直後の不揮発性メモリの内容に基づき、フ
ァイルオープン中であり、かつ、レコード削除中である
際には、削除すべきレコードの内容がデータファイルに
存在しているか否かを確認し、存在している場合には、
削除すべきレコードの内容をデータファイルから削除す
るとともに、削除すべきレコードのキーをインデックス
ファイルから削除したうえで不揮発性メモリの内容を消
去することを特徴としている。

【０００８】上記第１のファイル自動復旧方式によれ
ば、ＷＲＩＴＥ命令によるレコード追加中に計算機シス
テムがダウンした場合であっても、索引編成ファイルを
構成するデータファイルとインデックスファイルとの整
合性を保つことが可能となる。そして、第２のファイル
自動復旧方式によれば、ＲＥＷＲＩＴＥ命令によるレコ
ード書き換え中に計算機システムがダウンした場合であ
っても、索引編成ファイルを構成するデータファイルと
インデックスファイルとの整合性を保つことが可能とな
る。また、第３のファイル自動復旧方式によれば、ＤＥ
ＬＥＴＥ命令によるレコード削除中に計算機システムが
ダウンした場合であっても、索引編成ファイルを構成す
るデータファイルとインデックスファイルとの整合性を
保つことが可能となる。

【０００９】

【発明の実施の形態】以下、本発明の実施例を図面に基
づいて説明する。

【００１０】図１は本実施例にかかる情報処理装置の全
体構成を示すブロック図、図２は索引編成ファイルの構
造を示す説明図、図３はファイル構成ブロックの構造を
示す説明図、図４はファイルステータスブロックの構造
を示す説明図、図５は不揮発性メモリの構造を示す説明
図であり、図６は索引編成ファイルがオープンされた際
におけるファイルステータスブロック及びファイル構成
ブロックの内容を例示する説明図、図７はファイルオー
プン時の処理手順を示すフローチャート、図８はファイ
ルクローズ時の処理手順を示すフローチャートである。

【００１１】本実施例にかかる情報処理装置は、中央処
理装置（ＣＰＵ）１と、主記憶装置であるダイナミック
ランダムアクセスメモリ（ＤＲＡＭ）２と、不揮発性メ
モリであるところのスタティックランダムアクセスメモ
リ（ＳＲＡＭ）３と、読み出し専用メモリ（ＲＯＭ）４
とを備えており、ＣＰＵ１は情報処理装置全体の制御や
本発明にかかるプログラムを処理するものである一方、
ＤＲＡＭ２は本発明によるプログラムが展開されたり、
ＣＰＵ１による処理の一時的な作業場所を提供したり、
入出力データを一時的に記憶しておくための作業場所を
提供するものとなっている。また、電源の供給がなくて
も内容を保持しているＳＲＡＭ３はファイル処理の情報
を記憶するための作業場所を提供するものであり、ＲＯ
Ｍ４には情報処理装置の電源オン時に実行されるイニシ
ャルプログラムや文字のフォント情報などが格納されて
いる。

【００１２】さらに、この情報処理装置は、表示を行う
表示装置５と、オペレータが手作業によってデータなど
を入力するためのキーボード６と、スキャナ７と、ハー
ドディスク８とを備えており、これらの各々は対応する
制御装置９〜１２でもって制御されるようになってい
る。すなわち、ここでのスキャナ７はスキャナ制御装置
１１でもって制御されながらバーコードイメージを受光
するものであり、受光されたバーコードイメージはスキ
ャナ制御装置１１の制御による一定の規則に従ってデコ
ードされたうえでＣＰＵ１へと転送される。

【００１３】索引編成ファイルは、図２で示すように、
データファイル１５と、例えば、二つのインデックスフ
ァイル、つまり、第１インデックスファイル１６及び第
２インデックスファイル１７とから構成されたものであ
る。そして、データファイル１５は、第１キーの領域１
８及び第２キーの領域１９と、データの領域２０とを持
っており、第１及び第２キーとデータとによってはレコ
ードが構成されることになっている。また、第１インデ
ックスファイル１６及び第２インデックスファイル１７
のそれぞれには、第１キーの領域２１または第２キーの
領域２２と、第１及び第２キーがデータファイル１５に
おける何れのレコードの存在に対応しているかを指示す
る領域２３，２４とが設けられている。なお、これら第
１及び第２キーの領域２１，２２におけるキーのそれぞ
れは、検索時間を短縮するため、昇順に並べられている
のが通常である。

【００１４】図３で示すファイル構成ブロックは、ファ
イル名、レコード長及びキー位置などのファイル基本情
報が格納されるものであり、ファイルオープンに際して
はＳＲＡＭ３上に割り当てたうえで格納され、また、フ
ァイルクローズ時には消去されることになっている。そ
して、この際、ファイル構成ブロックがデータファイル
１５である場合には、図３（ａ）で示すように、データ
ファイルのファイル構成ブロックであることを示すデー
タファイル識別３０、一つのレコード長を示すレコード
サイズ３１、インデックスファイルの数に対応するキー
個数３２、ファイルオープンの型式（ＩＮＰＵＴ、ＩＮ
ＰＵＴ／ＯＵＴＰＵＴ、ＥＸＴＥＮＤ）を示すオープン
タイプ３３、インデックスファイルのファイル番号１〜
ｎを示すインデックスファイル番号３４〜３５、データ
ファイルの名前を表すファイル名３６という内容を有し
ている。

【００１５】また、このファイル構成ブロックが第１イ
ンデックスファイル１６もしくは第２インデックスファ
イル１７である場合には、図３（ｂ）で示すように、イ
ンデックスファイルのファイル構成ブロックであること
を示すインデックスファイル識別４０（４５）、データ
ファイルのレコード中においてキーが始まる位置を示す
キー位置４１（４６）、キーサイズ４２（４７）、デー
タファイルのファイル番号を示すデータファイル番号４
３（４８）、インデックスファイルの名前を表すファイ
ル名４４（４９）という内容を持つことになっている。

【００１６】図４で示すファイルステータスブロックは
ファイル処理の状態を記録するものであり、ファイルオ
ープン時にはＳＲＡＭ３上に割り当てて格納される一
方、ファイルクローズ時には消去されることになってい
る。そして、このファイルステータスブロックは、ファ
イル状態を記録している索引編成ファイルのデータファ
イルの番号を示すファイル番号５０と、命令モード５１
と、処理されるデータファイルのレコード番号５２と、
ＲＥＷＲＩＴＥ命令用バッファ５３とから構成されてお
り、レコード追加（ＷＲＩＴＥ命令）中には「１」、レ
コード書き換え（ＲＥＷＲＩＴＥ命令）中には「２」、
レコード削除（ＤＥＬＥＴＥ命令）中には「３」が命令
モード５１にセットされ、また、これらの命令を実行中
でない時の命令モード５１には「０」がセットされてい
る。なお、ＲＥＷＲＩＴＥ命令用バッファ５３は、レコ
ード書き換えの際のデータ及び番号を記憶しておくため
のものである。

【００１７】図５で示すＳＲＡＭの構造はＳＲＡＭ３上
におけるファイル構成ブロック及びファイルステータス
ブロックの割り当て状態を表しており、ＳＲＡＭ３はフ
ァイル構成ブロック領域とファイルステータスブロック
領域とに分割され、かつ、これらの領域それぞれはブロ
ック配列とされている。すなわち、ファイル構成ブロッ
ク領域は、ファイルの各々に対して物理的かつ固有のも
のとして割り当てられるファイル番号を添え字とするブ
ロックから構成されており、値が「１」であれば該当す
るファイル番号のブロックがデータファイルとしてオー
プンされ、そして、「２」であれば該当するファイル番
号のブロックがインデックスファイルとしてオープンさ
れている一方、値が「０」であれば該当するファイル番
号のブロックがオープンされていないということが分か
るようになっている。

【００１８】さらに、ファイルステータスブロックは索
引編成ファイルの論理ファイルとされたものであり、オ
ープンされた順序に従いながらファイルステータスブロ
ック領域の先頭側のブロックから順に割り当てられてい
る。そして、この際におけるファイル構成ブロックとフ
ァイルステータスブロックとは、以下のような関係を有
している。つまり、図５から分かるように、あるファイ
ルステータスブロック６０のファイル番号５０がファイ
ル構成ブロック領域内のデータファイルのファイル構成
ブロック６１を指示し、かつ、このデータファイルのイ
ンデックスファイル番号３４，３５それぞれがインデッ
クスファイルのファイル構成ブロック６２，６３を指示
しているという関係である。

【００１９】ところで、図６は索引編成ファイルが書き
込み可能な状態（ＯＵＴＰＵＴまたはＩ−Ｏ）でオープ
ンされた際におけるファイルステータスブロック及びフ
ァイル構成ブロックそれぞれの内容を例示しており、こ
こでのファイルステータスブロックは、ファイル番号５
０が「１」で、かつ、命令モード５１が「０」であるこ
とからオープンされただけに過ぎず、レコード番号５２
及びＲＥＷＲＩＴＥ命令用バッファ５３の内容も「０」
となったものである。そして、ファイルステータスブロ
ックのファイル番号５０でもって指示されたファイル構
成ブロックのデータファイル１５におけるデータファイ
ル識別３０は「１」、レコードサイズは「１６」、イン
デックスファイルの数を示すキー個数は「２」、オープ
ンタイプ３３はＩ−Ｏオープンであることを表す「３」
であり、インデックスファイル番号３４，３５のそれぞ
れは「２」，「３」、ファイル名３６は「ＦＩＬＥ０
１．ＤＡＴ」となっている。

【００２０】また、このデータファイルのインデックス
ファイル番号３４で指示された第１インデックスファイ
ル１６では、インデックスファイル識別４０が「２」、
キー位置４１が「１」、キーサイズ４２が「３」、デー
タファイル番号４３が「１」であり、ファイル名４４が
「ＦＩＬＥ０１．ＩＸ１」である一方、インデックスフ
ァイル番号３５によって指示された第２インデックスフ
ァイル１７では、インデックスファイル識別４５が
「２」、キー位置４６が「４」、キーサイズ４７が
「４」、データファイル番号４８が「１」であり、ファ
イル名４９が「ＦＩＬＥ０１．ＩＸ２」となっている。

【００２１】そして、索引編成ファイルをオープンする
際、つまり、ファイルオープン時には、図７のフローチ
ャートで示す手順に従った処理が行われる。まず、索引
編成ファイルのＩＮＰＵＴオープンであるか否かを判定
し（Ｓ１０１）、ＩＮＰＵＴオープンでない場合には、
ＳＲＡＭ３上に設けられたファイルステータスブロック
領域から捜し出した空きブロックに対してファイルステ
ータスブロックの情報を書き込んで設定する（Ｓ１０
２）。次に、索引編成ファイルにおけるデータファイル
のファイル番号ごとに割り当てられたブロックのそれぞ
れに対し、ファイル構成ブロックを構成するデータファ
イル１５と第１及び第２インデックスファイル１６，１
７との情報を書き込んで設定する（Ｓ１０３）。その
後、資源確保などのような従来通りのファイルオープン
処理が行われる（Ｓ１０４）。なお、ＩＮＰＵＴオープ
ン、つまり、読み出し専用であれば索引編成ファイルの
内容が書き換えられることはないので、上記処理を行う
必要はないことになる。

【００２２】一方、索引編成ファイルをクローズする
際、つまり、ファイルクローズ時においては、図８のフ
ローチャートで示す手順に従った処理が行われる。すな
わち、まず、索引編成ファイルのＩＮＰＵＴオープンで
あるか否かを判定し（Ｓ１１１）、ＩＮＰＵＴオープン
でない場合には、資源開放などのような従来通りのファ
イルクローズ処理を行う（Ｓ１１２）。そして、ファイ
ル構成ブロックを構成するデータファイル１５及び第１
及び第２インデックスファイル１６，１７をクリアする
処理を行った（Ｓ１１３）後、ファイルステータスブロ
ックをクリアするのである（Ｓ１１４）。なお、ファイ
ルオープン時と同様、このファイルクローズ時において
も、ＩＮＰＵＴオープンであるならば上記処理を行う必
要はない。

【００２３】引き続いて図９ないし図１３に基づき、Ｗ
ＲＩＴＥ命令によって実行されるレコード追加時の処理
を説明する。ここでの図９はレコード追加時の処理手順
を示すフローチャート、図１０はレコード追加中におけ
るファイルステータスブロックの内容を例示する説明
図、図１１はレコード追加後における索引編成ファイル
の内容を例示する説明図であり、図１２はレコード追加
中に計算機システムがダウンした際における索引編成フ
ァイルの内容を例示する説明図、図１３はレコード追加
中にシステムダウンした際の復旧手順を示すフローチャ
ートである。

【００２４】ＷＲＩＴＥ命令は、データファイル１５に
対してレコードを追加し、かつ、第１及び第２インデッ
クスファイル１６，１７のそれぞれに対してキーを登録
する命令であるので、レコードを追加する際には、図９
のフローチャートで示すような手順に従った処理が行わ
れる。まず、既に同じキーが登録済みであるか否かを判
定し（Ｓ１２１）、登録済みであればエラー処理（Ｓ１
２２）を行ったうえで処理を終了する。また、登録済み
でないと判定された場合には、データファイル１５の空
きレコード番号、例えば、「１０」を捜し出した（Ｓ１
２３）うえ、図１０で示すファイルステータスブロック
の命令モード５１に対してＷＲＩＴＥ命令を示す「１」
をセットするとともに、レコード番号５２に対して空き
レコード番号である「１０」をセットする（Ｓ１２
４）。なお、ファイルステータスブロックにおけるファ
イル番号５０はファイルオープン時に設定された「１」
のままであり、ＲＥＷＲＩＴＥ命令用バッファ５３は使
用されないことになっている。

【００２５】そして、追加されるレコード７０の内容を
図１１で示すデータファイル１５に書き込んだ（Ｓ１２
５）うえ、第１及び第２インデックスファイル１６，１
７のそれぞれに対してレコード７０の第１キー７１と第
２キー７２とを登録する（Ｓ１２６）。その後、ファイ
ルステータスブロックの命令モード５１及びレコード番
号５２をクリアする（Ｓ１２７）。すなわち、ここで
は、索引編成ファイルにレコードを実際に書き込む以前
の時点において、ファイルステータスブロックに命令モ
ード及びレコード番号を書き込んでいる（Ｓ１２４）た
め、レコード追加中に計算機システムのダウンが起こっ
ても、どのような命令に従いながら、どのレコード番号
の処理を行っていたかが分かることになる。また、この
際、特に重要なのは、データファイルへのレコードの書
き込み処理（Ｓ１２５）と、インデックスファイルヘの
キーの書き込み処理（Ｓ１２６）とを、この順序に従っ
て実行することである。つまり、このような順序に従え
ば、データファイル上に残っているレコードの内容に基
づいてインデックスファイルのキーを再登録することが
可能となるのである。

【００２６】ところで、索引編成ファイルを構成するデ
ータファイル１５と第１及び第２インデックスファイル
１６，１７との不整合が生じるのは、レコード追加時の
処理手順を示すフローチャートにおけるＳ１２５の処理
が完丁してからＳ１２６の処理が完了するまでの間にシ
ステムダウンが起こった場合である。そして、このよう
な場合には、例えば、図１２で示しているように、索引
編成ファイルを構成するデータファイル１５にレコード
７０の内容が書き込まれ、かつ、第１インデックスファ
イル１６に第１キー７１が登録されているにも拘わら
ず、第２インデックスファイル１７には第２キー７２が
未登録であるというような事態が発生していることにな
る。なお、システムダウンの状況によっては、第２キー
７２のみならず、第１キー７１も未登録となっている場
合がある。すなわち、これらの事態は、索引編成ファイ
ルを構成するデータファイル１５と第１及び第２インデ
ックスファイル１６，１７とが不整合であることを示し
ている。

【００２７】しかしながら、このような事態下であって
も、図１０で例示したファイルステータスブロックを見
れば、その命令モード５１からＷＲＩＴＥ命令の実行中
であり、レコード番号５２の内容から番号「１０」のレ
コードを処理中であったことが分かる。そこで、データ
ファイル１５と第１及び第２インデックスファイル１
６，１７との不整合は、図１３のフローチャートで示す
復旧手順を採用することによって解消される。すなわ
ち、まず、ファイルステータスブロックの命令モード５
１がＷＲＩＴＥ命令を表す「１」であるか否かを判定し
（Ｓ１３１）、「１」であるならばレコード番号５２が
セットされているか否かを判定した（Ｓ１３２）うえ、
セットされていればレコード番号５２に従ってデータフ
ァイル１５内に存在する番号「１０」のレコード７０の
内容を読み取った（Ｓ１３３）後、読み取れたか否かを
判定する（Ｓ１３４）。

【００２８】そして、レコード７０を読み取ることがで
きなければ、第１及び第２インデックスファイル１６，
１７の第１キー７１及び第２キー７２も登録されていな
いのであるから、索引編成ファイルを構成するデータフ
ァイル１５と第１及び第２インデックスファイル１６，
１７との整合性は保たれていることになる。また、レコ
ード７０が読み取れた場合には、このレコード７０の内
容に基づき、第１及び第２インデックスファイル１６，
１７における第１キーの領域２１及び第１キーの領域２
１それぞれに対して第１キー７１及び第２キー７２を再
登録する（Ｓ１３５）。その結果、索引編成ファイルを
構成するデータファイル１５と第１及び第２インデック
スファイル１６，１７との整合性は、図１１で示したと
同一の状態に回復したことになる。

【００２９】そこで、ファイルステータスブロックをク
リア、つまり、ファイル番号５０，命令モード５１，レ
コード番号５２，ＲＥＷＲＩＴＥ命令用バッファ５３の
全てをクリアする（Ｓ１３６）と、正常にファイルクロ
ーズ処理されたのと同じ状態となる。すなわち、以上説
明したシステムダウン時の復旧処理を行った結果、復旧
処理前には未登録であった第２インデックスファイル１
７の第２キー７２が登録されていることになり、データ
ファイル１５と第１及び第２インデックスファイル１
６，１７との整合性が回復したことになる。なお、図１
３のフローチャートにおけるＳ１３１で命令モード５１
が「１」でないと判定され、また、Ｓ１３２でレコード
番号５２がセットされていないと判定された場合には処
理を中断したうえでＳ１３６へと移行する一方、Ｓ１３
４でもってレコード７０を読み込めないと判定された際
にもＳ１３６へと移行することになっている。

【００３０】次に、図１４ないし図１８に基づき、ＲＥ
ＷＲＩＴＥ命令によるレコード書き換え時の処理を説明
する。ここでの図１４はレコード書き換え時の処理手順
を示すフローチャート、図１５はレコード書き換え中に
おけるファイルステータスブロックの内容を例示する説
明図、図１６はレコード書き換え後における索引編成フ
ァイルの内容を例示する説明図であり、図１７はレコー
ド書き換え中にシステムダウンが発生した際における索
引編成ファイルの内容を例示する説明図、図１８はシス
テムダウンした際の復旧手順を示すフローチャートであ
る。

【００３１】ＲＥＷＲＩＴＥ命令は、データファイル１
５内のレコードを書き換え、かつ、第１及び第２インデ
ックスファイル１６，１７のキーを書き換える命令であ
るので、図１４のフローチャートで示すような手順に従
った処理が行われる。すなわち、まず、キーボード６を
通じて指定されたうえで書き換えられるレコードの内容
を読み取り（Ｓ１４１）、読み取れたか否かを判定し
（Ｓ１４２）、読み取れなければエラー処理（Ｓ１４
３）を行ったうえで処理を終了する。そして、読み取れ
た場合には、書き換えるべきレコードの内容、つまり、
データ及び番号を図１５で示すファイルステータスブロ
ックのＲＥＷＲＩＴＥ命令用バッファ５３に格納し（Ｓ
１４４）、かつ、ＲＥＷＲＩＴＥ命令を示す「２」を命
令モード５１にセットするとともに、書き換えるべきレ
コードの番号、例えば、「１０」をレコード番号５２に
対してセットする（Ｓ１４５）。なお、この際、ファイ
ルステータスブロックのファイル番号５０はファイルオ
ープン時のまま、つまり、「１」がセットされたままと
なっている。

【００３２】そして、図１６で示すデータファイル１５
における番号「１０」のレコードの内容を削除したうえ
で書き換え後のレコード７０の内容とし（Ｓ１４６）、
かつ、第１及び第２インデックスファイル１６，１７か
ら書き換え前のレコードに対応する第１及び第２キーを
削除した（Ｓ１４７）後、削除されたキーのそれぞれに
対して書き換え後のレコード７０に対応した第１及び第
２キー７１，７２を登録する（Ｓ１４８）。その後、フ
ァイルステータスブロックの命令モード５１及びレコー
ド番号５２をクリアし（Ｓ１４９）、処理を終了する。
すなわち、この処理では、レコードを実際に書き換える
以前の時点において、ファイルステータスブロックに対
して命令モード及びレコード番号と書き換え後のレコー
ドの内容とを予め書き込んでいる（Ｓ１４４，Ｓ１４
５）ため、レコード書き換え中にシステムダウンが起こ
った場合であっても、どのような命令に従いながら、ど
のレコード番号の処理を行っていたかが分かる。

【００３３】また、ここで重要なのは、データファイル
へのレコードの書き換え処理（Ｓ１４６）と、インデッ
クスファイルからキーを削除する処理（Ｓ１４７）及び
キーを登録する処理（Ｓ１４８）とを、この順序で実行
することである。つまり、このようにすれば、データフ
ァイル上に存在するレコード７０の内容とファイルステ
ータスブロックのＲＥＷＲＩＴＥ命令用バッファ５３の
内容とに基づき、インデックスファイルのキーの再削除
及び再登録を行うことが可能となるのである。

【００３４】ところで、レコードの書き換え時におい
て、データファイル１５と第１及び第２インデックスフ
ァイル１６，１７との不整合が生じるのは、図１４のフ
ローチャート中におけるＳ１４６の処理が完丁してから
Ｓ１４８の処理が完了するまでの間に計算機システムが
ダウンした場合である。そして、このような場合には、
図１７で例示しているように、データファイル１５のレ
コード７０及び第１インデックスファイル１６の第１キ
ー７１が書き換え済みであるにも拘わらず、第２インデ
ックスファイル１７の第２キー７２が書き換えられてい
ないという事態が生じる。なお、システムダウンの状況
によっては第１キー７１も書き換えられていないことが
あり、これらの事態はデータファイル１５と第１及び第
２インデックスファイル１６，１７とが不整合であるこ
とを示している。

【００３５】しかしながら、この事態下においても、図
１５で示したファイルステータスブロックを見れば、そ
の命令モード５１からＲＥＷＲＩＴＥ命令の実行中であ
り、レコード番号５２の内容から番号「１０」のレコー
ドを処理中であったことが分かる。そこで、データファ
イル１５と第１及び第２インデックスファイル１６，１
７との不整合は、図１８のフローチャートでもって示す
復旧手順を採用することによって解消される。すなわ
ち、まず、ファイルステータスブロックにおける命令モ
ード５１がＲＥＷＲＩＴＥ命令を示す「２」であるか否
かを判定し（Ｓ１５１）、「２」であるならばレコード
番号５２がセットされているか否かを判定する（Ｓ１５
２）。そして、レコード番号５２がセットされているの
であれば、レコード番号５２の内容に従ってデータファ
イル１５内における番号「１０」のレコード７０を読み
取った（Ｓ１５３）うえ、読み取れたか否かを判定する
（Ｓ１５４）。

【００３６】そして、レコード７０を読み取ることがで
きなければ、ファイルステータスブロックをクリアし
（Ｓ１３６）、処理を終了する。また、レコード７０が
読み取れた場合には、読み取ったレコード７０の内容
と、ファイルステータスブロックにおけるＲＥＷＲＩＴ
Ｅ命令用バッファ５３の内容とを互いに比較し（Ｓ１５
５）、相違しているか否かを判定した（Ｓ１５６）う
え、ＲＥＷＲＩＴＥ命令用バッファ５３の内容に基づい
て第１及び第２インデックスファイル１６，１７から第
１及び第２キーを削除する（Ｓ１５７）。さらに、削除
されたキーのそれぞれに対し、書き換え後のレコード７
０に対応した第１及び第２キー７１，７２を再登録した
（Ｓ１５８）後、ファイルステータスブロックをクリア
して処理を終了する（Ｓ１５９）。その結果、索引編成
ファイルを構成するデータファイル１５と第１及び第２
インデックスファイル１６，１７との整合性は、図１６
で示した通りに回復していることになる。

【００３７】すなわち、以上説明した復旧処理を行った
結果、復旧処理前には不整合であった第２インデックス
ファイル１７の第２キー７２がデータファイル１５及び
第１インデックスファイル１７と整合していることにな
り、正常にファイルクローズ処理されたのと同じ状態と
なる。なお、図１８のフローチャートにおけるＳ１５１
で命令モード５１が「２」でないと判定され、また、Ｓ
１５２でレコード番号５２がセットされていないと判定
された場合には処理を中断したうえでＳ１５９へと移行
し、Ｓ１５４でもってレコード７０を読み込めないと判
定された際にもＳ１５９へと移行することになってい
る。

【００３８】さらに、引き続いて図１９ないし図２３に
基づき、ＤＥＬＥＴＥ命令によって実行されるレコード
削除時の処理を説明する。ここでの図１９はレコード削
除時の処理手順を示すフローチャート、図２０はレコー
ド削除中におけるファイルステータスブロックの内容を
例示する説明図、図２１はレコード削除後における索引
編成ファイルの内容を例示する説明図であり、図２２は
レコード削除中にシステムダウンが発生した際における
索引編成ファイルの内容を例示する説明図、図２３はレ
コード削除中にシステムダウンした際の復旧手順を示す
フローチャートである。

【００３９】ＤＥＬＥＴＥ命令は、データファイル１５
からレコードを削除し、かつ、第１及び第２インデック
スファイル１６，１７のそれぞれからも対応するキーを
削除する命令であるので、図１９のフローチャートで示
すような手順に従った処理が行われる。まず、キーボー
ド６で指定されたうえで削除されるレコードの内容を読
み取り（Ｓ１６１）、読み取れたか否かを判定した（Ｓ
１６２）後、読み取れなければエラー処理（Ｓ１６３）
を行ったうえで処理を終了する。そして、読み取れた場
合には、図２０で示しているように、ファイルステータ
スブロックの命令モード５１に対してＤＥＬＥＴＥ命令
を示す「３」をセットするとともに、削除されるレコー
ドの番号、例えば、「１０」をレコード番号５２に対し
てセットする（Ｓ１６４）。なお、この際、ファイルス
テータスブロックのファイル番号５０はファイルオープ
ンを示す「１」のままとされており、ＲＥＷＲＩＴＥ命
令用バッファ５３は使用されないことになっている。

【００４０】そして、図２１で示すように、索引編成フ
ァイルを構成する第１及び第２インデックスファイル１
６，１７から対応するキーを削除し（Ｓ１６５）、か
つ、データファイル１５から対応するレコードを削除し
た（Ｓ１６６）うえでファイルステータスブロックの命
令モード５１及びレコード番号５２をクリアする（Ｓ１
６７）。すなわち、この処理では、索引編成ファイルか
らレコードを実際に削除する以前の時点において、ファ
イルステータスブロックに命令モード及びレコード番号
を書き込んでいる（Ｓ１６４）ため、レコード削除中に
システムダウンが発生したとしても、どのような命令に
従ってどのレコード番号の処理を行っていたかが分か
る。また、ここで重要となるのは、データファイルから
レコードを削除する（Ｓ１６６）よりも先にインデック
スファイルからキーを削除する（Ｓ１６５）ことであ
る。つまり、このようにしておけば、データファイル上
に残っているレコードの内容に基づき、インデックスフ
ァイルのキーを再削除することが可能となるからであ
る。

【００４１】ところで、索引編成ファイルを構成するデ
ータファイル１５と第１及び第２インデックスファイル
１６，１７との不整合がレコード削除中に生じるのは、
図１９で示したフローチャートにおけるＳ１６５の処理
が完了してからＳ１６６の処理が完了するまでの間にシ
ステムダウンが起こった場合である。そして、この場合
には、例えば、図２２で示すように、索引編成ファイル
を構成する第１インデックスファイル１６からは第１キ
ー７１が削除されているにも拘わらず、第２インデック
スファイル１７からは第２キー７２が削除されておら
ず、また、データファイル１５からレコード７０が削除
されていないというような事態が生じる。なお、場合に
よっては、第１キー７１までもが削除されずに残ってい
ることもある。すなわち、これらの事態は、データファ
イル１５と第１及び第２インデックスファイル１６，１
７とが互いに不整合であることを示している。

【００４２】しかしながら、このような事態下であって
も、図２０で例示したファイルステータスブロックを見
れば、その命令モード５１からＤＥＬＥＴＥ命令の実行
中であり、レコード番号５２の内容から番号「１０」の
レコードを処理中であったことが分かる。そこで、デー
タファイル１５と第１及び第２インデックスファイル１
６，１７との不整合は、図２３のフローチャートで示す
復旧手順を採用することによって解消される。すなわ
ち、まず、ファイルステータスブロックの命令モード５
１がＤＥＬＥＴＥ命令を表す「３」であるか否かを判定
し（Ｓ１７１）、かつ、「３」であるならばレコード番
号５２がセットされているか否かを判定し（Ｓ１７
２）、セットされていればレコード番号５２に従ってデ
ータファイル１５内に存在する番号「１０」のレコード
７０の内容を読み取る（Ｓ１７３）。

【００４３】そして、読み取れたか否かを判定し（Ｓ１
７４）、読み取れた場合にはレコード７０の内容に基づ
いて第２インデックスファイル１７における第２キー７
２、あるいはまた、第１キー７１も残っている場合に
は、第１及び第２インデックスファイル１６，１７にお
ける第１キー７１及び第２キー７２をともに削除する
（Ｓ１７５）。その後、データファイル１５内に残って
いたレコード７０を削除し（Ｓ１７６）、ファイルステ
ータスブロックをクリア、つまり、ファイル番号５０，
命令モード５１，レコード番号５２，ＲＥＷＲＩＴＥ命
令用バッファ５３の全てをクリアして処理を終了する
（Ｓ１７７）。

【００４４】その結果、索引編成ファイルを構成するデ
ータファイル１５と第１及び第２インデックスファイル
１６，１７との整合性は図２１で示した通りに回復し、
正常にファイルクローズ処理されたのと同じ状態とな
る。なお、図２３のフローチャートにおけるＳ１７１で
命令モード５１が「３」でないと判定され、また、Ｓ１
７２でレコード番号５２がセットされていないと判定さ
れた場合には処理を中断したうえでＳ１７７へと移行
し、Ｓ１７４でもってレコード７０を読み込めないと判
定された際にもＳ１７７へと移行することになる。

【００４５】

【発明の効果】以上説明したように、本発明にかかる索
引編成ファイルの自動復旧方式によれば、ＷＲＩＴＥ命
令によるレコード追加中に計算機システムがダウンした
場合であっても、追加中であったレコードの内容を可能
な限り有効に利用しながら復旧することができ、索引編
成ファイルを構成するデータファイルとインデックスフ
ァイルとの整合性を保つことができる。そして、この際
においては、限られたＳＲＡＭのメモリ容量でもって復
旧作業を実行することができ、従来例よりも高速の処理
を実現することが可能となる。さらにまた、本発明によ
れば、レコード追加中のみならず、レコード書き換え中
やレコード削除中にシステムダウンが発生した場合であ
っても、データファイルとインデックスファイルとの整
合性を容易に確保することができるという効果が得られ
る。

【図面の簡単な説明】

【図１】本実施例にかかる情報処理装置の全体構成を示
すブロック図である。

【図２】索引編成ファイルの構造を示す説明図である。

【図３】ファイル構成ブロックの構造を示す説明図であ
る。

【図４】ファイルステータスブロックの構造を示す説明
図である。

【図５】ＳＲＡＭの構造を示す説明図である。

【図６】索引編成ファイルがオープンされた際における
ファイルステータスブロック及びファイル構成ブロック
の内容を例示する説明図である。

【図７】ファイルオープン時の処理手順を示すフローチ
ャートである。

【図８】ファイルクローズ時の処理手順を示すフローチ
ャートである。

【図９】レコード追加時の処理手順を示すフローチャー
トである。

【図１０】レコード追加中におけるファイルステータス
ブロックの内容を例示する説明図である。

【図１１】レコード追加後における索引編成ファイルの
内容を例示する説明図である。

【図１２】レコード追加中に計算機システムがダウンし
た際における索引編成ファイルの内容を例示する説明図
である。

【図１３】レコード追加中にシステムダウンした際の復
旧手順を示すフローチャートである。

【図１４】レコード書き換え時の処理手順を示すフロー
チャートである。

【図１５】レコード書き換え中におけるファイルステー
タスブロックの内容を例示する説明図である。

【図１６】レコード書き換え後の索引編成ファイルの内
容を例示する説明図である。

【図１７】レコード書き換え中にシステムダウンが発生
した際における索引編成ファイルの内容を例示する説明
図である。

【図１８】レコード書き換え中にシステムダウンした際
の復旧手順を示すフローチャートである。

【図１９】レコード削除時の処理手順を示すフローチャ
ートである。

【図２０】レコード削除中におけるファイルステータス
ブロックの内容を例示する説明図である。

【図２１】レコード削除後における索引編成ファイルの
内容を例示する説明図である。

【図２２】レコード削除中にシステムダウンが発生した
際における索引編成ファイルの内容を例示する説明図で
ある。

【図２３】レコード削除中にシステムダウンした際の復
旧手順を示すフローチャートである。

Claims

【特許請求の範囲】

【請求項１】計算機システムの２次記憶媒体上で索引
編成ファイルの更新を行う際のファイルオープン時に
は、ファイル名、レコード長及びキー位置などのファイ
ル基本情報を不揮発性メモリに格納することが行われ、
また、レコード追加時には、追加されるレコードの番号
を不揮発性メモリに格納し、かつ、追加すべきレコード
の内容をデータファイルに登録した後、追加すべきレコ
ードのキーをインデックスファイルに登録することが行
われ、さらに、ファイルクローズ時には、ファイル基本
情報を消去することが行われる処理であって、システム起動直後における不揮発性メモリの内容に基づ
き、ファイルオープン中であり、かつ、レコード追加中
である際には、追加すべきレコードの内容がデータファ
イルに存在しているか否かを確認し、存在している場合
には、インデックスファイルに対して追加すべきレコー
ドのキーの再登録を試みたうえで不揮発性メモリの内容
を消去することを特徴とする索引編成ファイルの自動復
旧方式。
【請求項２】計算機システムの２次記憶媒体上で索引
編成ファイルの更新を行う際のファイルオープン時に
は、ファイル名、レコード長及びキー位置などのファイ
ル基本情報を不揮発性メモリに格納することが行われ、
また、レコード書き換え時には、書き換えられるレコー
ドのデータ及び番号を不揮発性メモリに格納し、書き換
え前のレコードの内容を削除して書き換え後のレコード
の内容をデータファイルに登録した後、書き換え前のレ
コードのキーを削除して書き換え後のレコードのキーを
インデックスファイルに登録することが行われ、さら
に、ファイルクローズ時には、ファイル基本情報を消去
することが行われる処理であって、システム起動直後における不揮発性メモリの内容に基づ
き、ファイルオープン中であり、かつ、レコード書き換
え中である際には、不揮発性メモリに格納されたレコー
ドの内容と、データファイルに登録されたレコードの内
容とを比較し、相違している場合には、インデックスフ
ァイルに対して書き換え前のレコードのキーの再削除及
び書き換え後のレコードのキーの再登録を試みたうえで
不揮発性メモリの内容を消去することを特徴とする索引
編成ファイルの自動復旧方式。
【請求項３】計算機システムの２次記憶媒体上で索引
編成ファイルの更新を行う際のファイルオープン時に
は、ファイル名、レコード長及びキー位置などのファイ
ル基本情報を不揮発性メモリに格納することが行われ、
また、レコード削除時には、削除されるレコードの番号
を不揮発性メモリに格納し、かつ、削除すべきレコード
のキーをインデックスファイルから削除した後、削除す
べきレコードの内容をデータファイルから削除すること
が行われ、さらに、ファイルクローズ時には、ファイル
基本情報を消去することが行われる処理であって、システム起動直後の不揮発性メモリの内容に基づき、フ
ァイルオープン中であり、かつ、レコード削除中である
際には、削除すべきレコードの内容がデータファイルに
存在しているか否かを確認し、存在している場合には、
削除すべきレコードの内容をデータファイルから削除す
るとともに、削除すべきレコードのキーをインデックス
ファイルから削除したうえで不揮発性メモリの内容を消
去することを特徴とする索引編成ファイルの自動復旧方
式。