JPH0934767A - 索引編成ファイルの自動復旧方式 - Google Patents
索引編成ファイルの自動復旧方式Info
- Publication number
- JPH0934767A JPH0934767A JP7179973A JP17997395A JPH0934767A JP H0934767 A JPH0934767 A JP H0934767A JP 7179973 A JP7179973 A JP 7179973A JP 17997395 A JP17997395 A JP 17997395A JP H0934767 A JPH0934767 A JP H0934767A
- Authority
- JP
- Japan
- Prior art keywords
- file
- record
- contents
- index
- key
- 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)【要約】
【課題】 システムダウンした際にも、データファイル
とインデックスファイルとの整合性を保つことが可能な
索引編成ファイルの自動復旧方式を提供する。 【課題解決手段】 本発明のファイル自動復旧方式は、
WRITE命令によるレコード追加時には、追加される
レコードの番号を不揮発性メモリに格納し、かつ、追加
すべきレコードの内容をデータファイルに登録した後、
追加すべきレコードのキーをインデックスファイルに登
録することが行われる処理であって、システム起動直後
における不揮発性メモリの内容に基づき、ファイルオー
プン中であり、かつ、レコード追加中である際には、追
加すべきレコードの内容がデータファイルに存在してい
るか否かを確認し、存在している場合には、インデック
スファイルに対して追加すべきレコードのキーの再登録
を試みたうえで不揮発性メモリの内容を消去することを
特徴としている。
とインデックスファイルとの整合性を保つことが可能な
索引編成ファイルの自動復旧方式を提供する。 【課題解決手段】 本発明のファイル自動復旧方式は、
WRITE命令によるレコード追加時には、追加される
レコードの番号を不揮発性メモリに格納し、かつ、追加
すべきレコードの内容をデータファイルに登録した後、
追加すべきレコードのキーをインデックスファイルに登
録することが行われる処理であって、システム起動直後
における不揮発性メモリの内容に基づき、ファイルオー
プン中であり、かつ、レコード追加中である際には、追
加すべきレコードの内容がデータファイルに存在してい
るか否かを確認し、存在している場合には、インデック
スファイルに対して追加すべきレコードのキーの再登録
を試みたうえで不揮発性メモリの内容を消去することを
特徴としている。
Description
【0001】
【発明の属する技術分野】本発明は索引編成ファイルの
自動復旧方式にかかり、特には、無停電電源装置を具備
していない情報処理装置を構成する停電表示装置のCO
BOL言語環境によるファイル処理に関する。
自動復旧方式にかかり、特には、無停電電源装置を具備
していない情報処理装置を構成する停電表示装置のCO
BOL言語環境によるファイル処理に関する。
【0002】
【従来の技術】計算機システムの2次記憶媒体上に格納
されるファイルのバックアップ方式としては、例えば、
特開昭4−98545号公報で開示されているファイル
自動復旧方式がある。そして、このファイル自動復旧方
式においては、2次記憶媒体上でファイルの作成または
更新を行うに際し、まずもって、2次記憶媒体上のファ
イル情報管理テーブルを更新用及び退避用のメモリに読
み込んだ後、退避用メモリ内のファイル情報管理テーブ
ルにファイル情報管理テーブル更新中の表示を立てたう
えで退避用のファイル情報管理テーブルを2次記憶媒体
上にコピーしている。すなわち、この方式では、システ
ムダウン後の回復時における2次記憶媒体に対してアク
セスすることにより、ファイル情報管理テーブル更新中
の表示を参照したうえ、更新中であれば2次記憶媒体上
に退避しておいた更新前のファイル情報管理テーブルを
コピーすることによってファイルを復旧させることにな
っている。
されるファイルのバックアップ方式としては、例えば、
特開昭4−98545号公報で開示されているファイル
自動復旧方式がある。そして、このファイル自動復旧方
式においては、2次記憶媒体上でファイルの作成または
更新を行うに際し、まずもって、2次記憶媒体上のファ
イル情報管理テーブルを更新用及び退避用のメモリに読
み込んだ後、退避用メモリ内のファイル情報管理テーブ
ルにファイル情報管理テーブル更新中の表示を立てたう
えで退避用のファイル情報管理テーブルを2次記憶媒体
上にコピーしている。すなわち、この方式では、システ
ムダウン後の回復時における2次記憶媒体に対してアク
セスすることにより、ファイル情報管理テーブル更新中
の表示を参照したうえ、更新中であれば2次記憶媒体上
に退避しておいた更新前のファイル情報管理テーブルを
コピーすることによってファイルを復旧させることにな
っている。
【0003】
【発明が解決しようとする課題】ところで、前記従来の
ファイル自動復旧方式においては、ソフトウェアやハー
ドウェアの障害などによって計算機システムがダウンし
た際、退避しておいたファイル情報管理テーブルをコピ
ーすることが行われるのであるが、これだけではシステ
ムダウン時に登録中であったファイルを登録以前の状態
にまで戻せるに過ぎず、登録中のレコードの内容が重要
であった場合における運用上の被害が生じることは避け
られない。そして、特に、この際におけるファイルが、
索引編成ファイルのようなファイルシステム、つまり、
複数のファイル同士が互いに関連付けられた構成のファ
イルシステムであった場合には、データファイルとイン
デックスファイルとの整合性が崩れるというような不都
合が発生することになってしまう。
ファイル自動復旧方式においては、ソフトウェアやハー
ドウェアの障害などによって計算機システムがダウンし
た際、退避しておいたファイル情報管理テーブルをコピ
ーすることが行われるのであるが、これだけではシステ
ムダウン時に登録中であったファイルを登録以前の状態
にまで戻せるに過ぎず、登録中のレコードの内容が重要
であった場合における運用上の被害が生じることは避け
られない。そして、特に、この際におけるファイルが、
索引編成ファイルのようなファイルシステム、つまり、
複数のファイル同士が互いに関連付けられた構成のファ
イルシステムであった場合には、データファイルとイン
デックスファイルとの整合性が崩れるというような不都
合が発生することになってしまう。
【0004】本発明は、このような不都合に鑑みて創案
されたものであって、計算機システムがダウンした際に
おいても、登録中であったレコードの内容を可能な限り
有効に利用することができ、データファイルとインデッ
クスファイルとの整合性を保つことが可能な構成とされ
た索引編成ファイルの自動復旧方式を提供するものであ
る。
されたものであって、計算機システムがダウンした際に
おいても、登録中であったレコードの内容を可能な限り
有効に利用することができ、データファイルとインデッ
クスファイルとの整合性を保つことが可能な構成とされ
た索引編成ファイルの自動復旧方式を提供するものであ
る。
【0005】
【課題を解決するための手段】本発明にかかる第1のフ
ァイル自動復旧方式は、上記目的を達成するため、計算
機システムの2次記憶媒体上で索引編成ファイルの更新
を行う際のファイルオープン時には、ファイル名、レコ
ード長及びキー位置などのファイル基本情報を不揮発性
メモリに格納することが行われ、また、WRITE命令
によるレコード追加時には、追加されるレコードの番号
を不揮発性メモリに格納し、かつ、追加すべきレコード
の内容をデータファイルに登録した後、追加すべきレコ
ードのキーをインデックスファイルに登録することが行
われ、さらに、ファイルクローズ時には、ファイル基本
情報を消去することが行われる処理であって、システム
起動直後における不揮発性メモリの内容に基づき、ファ
イルオープン中であり、かつ、レコード追加中である際
には、追加すべきレコードの内容がデータファイルに存
在しているか否かを確認し、存在している場合には、イ
ンデックスファイルに対して追加すべきレコードのキー
の再登録を試みたうえで不揮発性メモリの内容を消去す
ることを特徴としている。
ァイル自動復旧方式は、上記目的を達成するため、計算
機システムの2次記憶媒体上で索引編成ファイルの更新
を行う際のファイルオープン時には、ファイル名、レコ
ード長及びキー位置などのファイル基本情報を不揮発性
メモリに格納することが行われ、また、WRITE命令
によるレコード追加時には、追加されるレコードの番号
を不揮発性メモリに格納し、かつ、追加すべきレコード
の内容をデータファイルに登録した後、追加すべきレコ
ードのキーをインデックスファイルに登録することが行
われ、さらに、ファイルクローズ時には、ファイル基本
情報を消去することが行われる処理であって、システム
起動直後における不揮発性メモリの内容に基づき、ファ
イルオープン中であり、かつ、レコード追加中である際
には、追加すべきレコードの内容がデータファイルに存
在しているか否かを確認し、存在している場合には、イ
ンデックスファイルに対して追加すべきレコードのキー
の再登録を試みたうえで不揮発性メモリの内容を消去す
ることを特徴としている。
【0006】そして、第2のファイル自動復旧方式は、
計算機システムの2次記憶媒体上で索引編成ファイルの
更新を行う際のファイルオープン時には、ファイル名、
レコード長及びキー位置などのファイル基本情報を不揮
発性メモリに格納することが行われ、また、REWRI
TE命令によるレコード書き換え時には、書き換えられ
るレコードのデータ及び番号を不揮発性メモリに格納
し、書き換え前のレコードの内容を削除して書き換え後
のレコードの内容をデータファイルに登録した後、書き
換え前のレコードのキーを削除して書き換え後のレコー
ドのキーをインデックスファイルに登録することが行わ
れ、さらに、ファイルクローズ時には、ファイル基本情
報を消去することが行われる処理であって、システム起
動直後における不揮発性メモリの内容に基づき、ファイ
ルオープン中であり、かつ、レコード書き換え中である
際には、不揮発性メモリに格納されたレコードの内容
と、データファイルに登録されたレコードの内容とを比
較し、相違している場合には、インデックスファイルに
対して書き換え前のレコードのキーの再削除及び書き換
え後のレコードのキーの再登録を試みたうえで不揮発性
メモリの内容を消去することを特徴とするものである。
計算機システムの2次記憶媒体上で索引編成ファイルの
更新を行う際のファイルオープン時には、ファイル名、
レコード長及びキー位置などのファイル基本情報を不揮
発性メモリに格納することが行われ、また、REWRI
TE命令によるレコード書き換え時には、書き換えられ
るレコードのデータ及び番号を不揮発性メモリに格納
し、書き換え前のレコードの内容を削除して書き換え後
のレコードの内容をデータファイルに登録した後、書き
換え前のレコードのキーを削除して書き換え後のレコー
ドのキーをインデックスファイルに登録することが行わ
れ、さらに、ファイルクローズ時には、ファイル基本情
報を消去することが行われる処理であって、システム起
動直後における不揮発性メモリの内容に基づき、ファイ
ルオープン中であり、かつ、レコード書き換え中である
際には、不揮発性メモリに格納されたレコードの内容
と、データファイルに登録されたレコードの内容とを比
較し、相違している場合には、インデックスファイルに
対して書き換え前のレコードのキーの再削除及び書き換
え後のレコードのキーの再登録を試みたうえで不揮発性
メモリの内容を消去することを特徴とするものである。
【0007】また、第3のファイル自動復旧方式は、計
算機システムの2次記憶媒体上で索引編成ファイルの更
新を行う際のファイルオープン時には、ファイル名、レ
コード長及びキー位置などのファイル基本情報を不揮発
性メモリに格納することが行われ、また、DELETE
命令によるレコード削除時には、削除されるレコードの
番号を不揮発性メモリに格納し、かつ、削除すべきレコ
ードのキーをインデックスファイルから削除した後、削
除すべきレコードの内容をデータファイルから削除する
ことが行われ、さらに、ファイルクローズ時には、ファ
イル基本情報を消去することが行われる処理であって、
システム起動直後の不揮発性メモリの内容に基づき、フ
ァイルオープン中であり、かつ、レコード削除中である
際には、削除すべきレコードの内容がデータファイルに
存在しているか否かを確認し、存在している場合には、
削除すべきレコードの内容をデータファイルから削除す
るとともに、削除すべきレコードのキーをインデックス
ファイルから削除したうえで不揮発性メモリの内容を消
去することを特徴としている。
算機システムの2次記憶媒体上で索引編成ファイルの更
新を行う際のファイルオープン時には、ファイル名、レ
コード長及びキー位置などのファイル基本情報を不揮発
性メモリに格納することが行われ、また、DELETE
命令によるレコード削除時には、削除されるレコードの
番号を不揮発性メモリに格納し、かつ、削除すべきレコ
ードのキーをインデックスファイルから削除した後、削
除すべきレコードの内容をデータファイルから削除する
ことが行われ、さらに、ファイルクローズ時には、ファ
イル基本情報を消去することが行われる処理であって、
システム起動直後の不揮発性メモリの内容に基づき、フ
ァイルオープン中であり、かつ、レコード削除中である
際には、削除すべきレコードの内容がデータファイルに
存在しているか否かを確認し、存在している場合には、
削除すべきレコードの内容をデータファイルから削除す
るとともに、削除すべきレコードのキーをインデックス
ファイルから削除したうえで不揮発性メモリの内容を消
去することを特徴としている。
【0008】上記第1のファイル自動復旧方式によれ
ば、WRITE命令によるレコード追加中に計算機シス
テムがダウンした場合であっても、索引編成ファイルを
構成するデータファイルとインデックスファイルとの整
合性を保つことが可能となる。そして、第2のファイル
自動復旧方式によれば、REWRITE命令によるレコ
ード書き換え中に計算機システムがダウンした場合であ
っても、索引編成ファイルを構成するデータファイルと
インデックスファイルとの整合性を保つことが可能とな
る。また、第3のファイル自動復旧方式によれば、DE
LETE命令によるレコード削除中に計算機システムが
ダウンした場合であっても、索引編成ファイルを構成す
るデータファイルとインデックスファイルとの整合性を
保つことが可能となる。
ば、WRITE命令によるレコード追加中に計算機シス
テムがダウンした場合であっても、索引編成ファイルを
構成するデータファイルとインデックスファイルとの整
合性を保つことが可能となる。そして、第2のファイル
自動復旧方式によれば、REWRITE命令によるレコ
ード書き換え中に計算機システムがダウンした場合であ
っても、索引編成ファイルを構成するデータファイルと
インデックスファイルとの整合性を保つことが可能とな
る。また、第3のファイル自動復旧方式によれば、DE
LETE命令によるレコード削除中に計算機システムが
ダウンした場合であっても、索引編成ファイルを構成す
るデータファイルとインデックスファイルとの整合性を
保つことが可能となる。
【0009】
【発明の実施の形態】以下、本発明の実施例を図面に基
づいて説明する。
づいて説明する。
【0010】図1は本実施例にかかる情報処理装置の全
体構成を示すブロック図、図2は索引編成ファイルの構
造を示す説明図、図3はファイル構成ブロックの構造を
示す説明図、図4はファイルステータスブロックの構造
を示す説明図、図5は不揮発性メモリの構造を示す説明
図であり、図6は索引編成ファイルがオープンされた際
におけるファイルステータスブロック及びファイル構成
ブロックの内容を例示する説明図、図7はファイルオー
プン時の処理手順を示すフローチャート、図8はファイ
ルクローズ時の処理手順を示すフローチャートである。
体構成を示すブロック図、図2は索引編成ファイルの構
造を示す説明図、図3はファイル構成ブロックの構造を
示す説明図、図4はファイルステータスブロックの構造
を示す説明図、図5は不揮発性メモリの構造を示す説明
図であり、図6は索引編成ファイルがオープンされた際
におけるファイルステータスブロック及びファイル構成
ブロックの内容を例示する説明図、図7はファイルオー
プン時の処理手順を示すフローチャート、図8はファイ
ルクローズ時の処理手順を示すフローチャートである。
【0011】本実施例にかかる情報処理装置は、中央処
理装置(CPU)1と、主記憶装置であるダイナミック
ランダムアクセスメモリ(DRAM)2と、不揮発性メ
モリであるところのスタティックランダムアクセスメモ
リ(SRAM)3と、読み出し専用メモリ(ROM)4
とを備えており、CPU1は情報処理装置全体の制御や
本発明にかかるプログラムを処理するものである一方、
DRAM2は本発明によるプログラムが展開されたり、
CPU1による処理の一時的な作業場所を提供したり、
入出力データを一時的に記憶しておくための作業場所を
提供するものとなっている。また、電源の供給がなくて
も内容を保持しているSRAM3はファイル処理の情報
を記憶するための作業場所を提供するものであり、RO
M4には情報処理装置の電源オン時に実行されるイニシ
ャルプログラムや文字のフォント情報などが格納されて
いる。
理装置(CPU)1と、主記憶装置であるダイナミック
ランダムアクセスメモリ(DRAM)2と、不揮発性メ
モリであるところのスタティックランダムアクセスメモ
リ(SRAM)3と、読み出し専用メモリ(ROM)4
とを備えており、CPU1は情報処理装置全体の制御や
本発明にかかるプログラムを処理するものである一方、
DRAM2は本発明によるプログラムが展開されたり、
CPU1による処理の一時的な作業場所を提供したり、
入出力データを一時的に記憶しておくための作業場所を
提供するものとなっている。また、電源の供給がなくて
も内容を保持しているSRAM3はファイル処理の情報
を記憶するための作業場所を提供するものであり、RO
M4には情報処理装置の電源オン時に実行されるイニシ
ャルプログラムや文字のフォント情報などが格納されて
いる。
【0012】さらに、この情報処理装置は、表示を行う
表示装置5と、オペレータが手作業によってデータなど
を入力するためのキーボード6と、スキャナ7と、ハー
ドディスク8とを備えており、これらの各々は対応する
制御装置9〜12でもって制御されるようになってい
る。すなわち、ここでのスキャナ7はスキャナ制御装置
11でもって制御されながらバーコードイメージを受光
するものであり、受光されたバーコードイメージはスキ
ャナ制御装置11の制御による一定の規則に従ってデコ
ードされたうえでCPU1へと転送される。
表示装置5と、オペレータが手作業によってデータなど
を入力するためのキーボード6と、スキャナ7と、ハー
ドディスク8とを備えており、これらの各々は対応する
制御装置9〜12でもって制御されるようになってい
る。すなわち、ここでのスキャナ7はスキャナ制御装置
11でもって制御されながらバーコードイメージを受光
するものであり、受光されたバーコードイメージはスキ
ャナ制御装置11の制御による一定の規則に従ってデコ
ードされたうえでCPU1へと転送される。
【0013】索引編成ファイルは、図2で示すように、
データファイル15と、例えば、二つのインデックスフ
ァイル、つまり、第1インデックスファイル16及び第
2インデックスファイル17とから構成されたものであ
る。そして、データファイル15は、第1キーの領域1
8及び第2キーの領域19と、データの領域20とを持
っており、第1及び第2キーとデータとによってはレコ
ードが構成されることになっている。また、第1インデ
ックスファイル16及び第2インデックスファイル17
のそれぞれには、第1キーの領域21または第2キーの
領域22と、第1及び第2キーがデータファイル15に
おける何れのレコードの存在に対応しているかを指示す
る領域23,24とが設けられている。なお、これら第
1及び第2キーの領域21,22におけるキーのそれぞ
れは、検索時間を短縮するため、昇順に並べられている
のが通常である。
データファイル15と、例えば、二つのインデックスフ
ァイル、つまり、第1インデックスファイル16及び第
2インデックスファイル17とから構成されたものであ
る。そして、データファイル15は、第1キーの領域1
8及び第2キーの領域19と、データの領域20とを持
っており、第1及び第2キーとデータとによってはレコ
ードが構成されることになっている。また、第1インデ
ックスファイル16及び第2インデックスファイル17
のそれぞれには、第1キーの領域21または第2キーの
領域22と、第1及び第2キーがデータファイル15に
おける何れのレコードの存在に対応しているかを指示す
る領域23,24とが設けられている。なお、これら第
1及び第2キーの領域21,22におけるキーのそれぞ
れは、検索時間を短縮するため、昇順に並べられている
のが通常である。
【0014】図3で示すファイル構成ブロックは、ファ
イル名、レコード長及びキー位置などのファイル基本情
報が格納されるものであり、ファイルオープンに際して
はSRAM3上に割り当てたうえで格納され、また、フ
ァイルクローズ時には消去されることになっている。そ
して、この際、ファイル構成ブロックがデータファイル
15である場合には、図3(a)で示すように、データ
ファイルのファイル構成ブロックであることを示すデー
タファイル識別30、一つのレコード長を示すレコード
サイズ31、インデックスファイルの数に対応するキー
個数32、ファイルオープンの型式(INPUT、IN
PUT/OUTPUT、EXTEND)を示すオープン
タイプ33、インデックスファイルのファイル番号1〜
nを示すインデックスファイル番号34〜35、データ
ファイルの名前を表すファイル名36という内容を有し
ている。
イル名、レコード長及びキー位置などのファイル基本情
報が格納されるものであり、ファイルオープンに際して
はSRAM3上に割り当てたうえで格納され、また、フ
ァイルクローズ時には消去されることになっている。そ
して、この際、ファイル構成ブロックがデータファイル
15である場合には、図3(a)で示すように、データ
ファイルのファイル構成ブロックであることを示すデー
タファイル識別30、一つのレコード長を示すレコード
サイズ31、インデックスファイルの数に対応するキー
個数32、ファイルオープンの型式(INPUT、IN
PUT/OUTPUT、EXTEND)を示すオープン
タイプ33、インデックスファイルのファイル番号1〜
nを示すインデックスファイル番号34〜35、データ
ファイルの名前を表すファイル名36という内容を有し
ている。
【0015】また、このファイル構成ブロックが第1イ
ンデックスファイル16もしくは第2インデックスファ
イル17である場合には、図3(b)で示すように、イ
ンデックスファイルのファイル構成ブロックであること
を示すインデックスファイル識別40(45)、データ
ファイルのレコード中においてキーが始まる位置を示す
キー位置41(46)、キーサイズ42(47)、デー
タファイルのファイル番号を示すデータファイル番号4
3(48)、インデックスファイルの名前を表すファイ
ル名44(49)という内容を持つことになっている。
ンデックスファイル16もしくは第2インデックスファ
イル17である場合には、図3(b)で示すように、イ
ンデックスファイルのファイル構成ブロックであること
を示すインデックスファイル識別40(45)、データ
ファイルのレコード中においてキーが始まる位置を示す
キー位置41(46)、キーサイズ42(47)、デー
タファイルのファイル番号を示すデータファイル番号4
3(48)、インデックスファイルの名前を表すファイ
ル名44(49)という内容を持つことになっている。
【0016】図4で示すファイルステータスブロックは
ファイル処理の状態を記録するものであり、ファイルオ
ープン時にはSRAM3上に割り当てて格納される一
方、ファイルクローズ時には消去されることになってい
る。そして、このファイルステータスブロックは、ファ
イル状態を記録している索引編成ファイルのデータファ
イルの番号を示すファイル番号50と、命令モード51
と、処理されるデータファイルのレコード番号52と、
REWRITE命令用バッファ53とから構成されてお
り、レコード追加(WRITE命令)中には「1」、レ
コード書き換え(REWRITE命令)中には「2」、
レコード削除(DELETE命令)中には「3」が命令
モード51にセットされ、また、これらの命令を実行中
でない時の命令モード51には「0」がセットされてい
る。なお、REWRITE命令用バッファ53は、レコ
ード書き換えの際のデータ及び番号を記憶しておくため
のものである。
ファイル処理の状態を記録するものであり、ファイルオ
ープン時にはSRAM3上に割り当てて格納される一
方、ファイルクローズ時には消去されることになってい
る。そして、このファイルステータスブロックは、ファ
イル状態を記録している索引編成ファイルのデータファ
イルの番号を示すファイル番号50と、命令モード51
と、処理されるデータファイルのレコード番号52と、
REWRITE命令用バッファ53とから構成されてお
り、レコード追加(WRITE命令)中には「1」、レ
コード書き換え(REWRITE命令)中には「2」、
レコード削除(DELETE命令)中には「3」が命令
モード51にセットされ、また、これらの命令を実行中
でない時の命令モード51には「0」がセットされてい
る。なお、REWRITE命令用バッファ53は、レコ
ード書き換えの際のデータ及び番号を記憶しておくため
のものである。
【0017】図5で示すSRAMの構造はSRAM3上
におけるファイル構成ブロック及びファイルステータス
ブロックの割り当て状態を表しており、SRAM3はフ
ァイル構成ブロック領域とファイルステータスブロック
領域とに分割され、かつ、これらの領域それぞれはブロ
ック配列とされている。すなわち、ファイル構成ブロッ
ク領域は、ファイルの各々に対して物理的かつ固有のも
のとして割り当てられるファイル番号を添え字とするブ
ロックから構成されており、値が「1」であれば該当す
るファイル番号のブロックがデータファイルとしてオー
プンされ、そして、「2」であれば該当するファイル番
号のブロックがインデックスファイルとしてオープンさ
れている一方、値が「0」であれば該当するファイル番
号のブロックがオープンされていないということが分か
るようになっている。
におけるファイル構成ブロック及びファイルステータス
ブロックの割り当て状態を表しており、SRAM3はフ
ァイル構成ブロック領域とファイルステータスブロック
領域とに分割され、かつ、これらの領域それぞれはブロ
ック配列とされている。すなわち、ファイル構成ブロッ
ク領域は、ファイルの各々に対して物理的かつ固有のも
のとして割り当てられるファイル番号を添え字とするブ
ロックから構成されており、値が「1」であれば該当す
るファイル番号のブロックがデータファイルとしてオー
プンされ、そして、「2」であれば該当するファイル番
号のブロックがインデックスファイルとしてオープンさ
れている一方、値が「0」であれば該当するファイル番
号のブロックがオープンされていないということが分か
るようになっている。
【0018】さらに、ファイルステータスブロックは索
引編成ファイルの論理ファイルとされたものであり、オ
ープンされた順序に従いながらファイルステータスブロ
ック領域の先頭側のブロックから順に割り当てられてい
る。そして、この際におけるファイル構成ブロックとフ
ァイルステータスブロックとは、以下のような関係を有
している。つまり、図5から分かるように、あるファイ
ルステータスブロック60のファイル番号50がファイ
ル構成ブロック領域内のデータファイルのファイル構成
ブロック61を指示し、かつ、このデータファイルのイ
ンデックスファイル番号34,35それぞれがインデッ
クスファイルのファイル構成ブロック62,63を指示
しているという関係である。
引編成ファイルの論理ファイルとされたものであり、オ
ープンされた順序に従いながらファイルステータスブロ
ック領域の先頭側のブロックから順に割り当てられてい
る。そして、この際におけるファイル構成ブロックとフ
ァイルステータスブロックとは、以下のような関係を有
している。つまり、図5から分かるように、あるファイ
ルステータスブロック60のファイル番号50がファイ
ル構成ブロック領域内のデータファイルのファイル構成
ブロック61を指示し、かつ、このデータファイルのイ
ンデックスファイル番号34,35それぞれがインデッ
クスファイルのファイル構成ブロック62,63を指示
しているという関係である。
【0019】ところで、図6は索引編成ファイルが書き
込み可能な状態(OUTPUTまたはI−O)でオープ
ンされた際におけるファイルステータスブロック及びフ
ァイル構成ブロックそれぞれの内容を例示しており、こ
こでのファイルステータスブロックは、ファイル番号5
0が「1」で、かつ、命令モード51が「0」であるこ
とからオープンされただけに過ぎず、レコード番号52
及びREWRITE命令用バッファ53の内容も「0」
となったものである。そして、ファイルステータスブロ
ックのファイル番号50でもって指示されたファイル構
成ブロックのデータファイル15におけるデータファイ
ル識別30は「1」、レコードサイズは「16」、イン
デックスファイルの数を示すキー個数は「2」、オープ
ンタイプ33はI−Oオープンであることを表す「3」
であり、インデックスファイル番号34,35のそれぞ
れは「2」,「3」、ファイル名36は「FILE0
1.DAT」となっている。
込み可能な状態(OUTPUTまたはI−O)でオープ
ンされた際におけるファイルステータスブロック及びフ
ァイル構成ブロックそれぞれの内容を例示しており、こ
こでのファイルステータスブロックは、ファイル番号5
0が「1」で、かつ、命令モード51が「0」であるこ
とからオープンされただけに過ぎず、レコード番号52
及びREWRITE命令用バッファ53の内容も「0」
となったものである。そして、ファイルステータスブロ
ックのファイル番号50でもって指示されたファイル構
成ブロックのデータファイル15におけるデータファイ
ル識別30は「1」、レコードサイズは「16」、イン
デックスファイルの数を示すキー個数は「2」、オープ
ンタイプ33はI−Oオープンであることを表す「3」
であり、インデックスファイル番号34,35のそれぞ
れは「2」,「3」、ファイル名36は「FILE0
1.DAT」となっている。
【0020】また、このデータファイルのインデックス
ファイル番号34で指示された第1インデックスファイ
ル16では、インデックスファイル識別40が「2」、
キー位置41が「1」、キーサイズ42が「3」、デー
タファイル番号43が「1」であり、ファイル名44が
「FILE01.IX1」である一方、インデックスフ
ァイル番号35によって指示された第2インデックスフ
ァイル17では、インデックスファイル識別45が
「2」、キー位置46が「4」、キーサイズ47が
「4」、データファイル番号48が「1」であり、ファ
イル名49が「FILE01.IX2」となっている。
ファイル番号34で指示された第1インデックスファイ
ル16では、インデックスファイル識別40が「2」、
キー位置41が「1」、キーサイズ42が「3」、デー
タファイル番号43が「1」であり、ファイル名44が
「FILE01.IX1」である一方、インデックスフ
ァイル番号35によって指示された第2インデックスフ
ァイル17では、インデックスファイル識別45が
「2」、キー位置46が「4」、キーサイズ47が
「4」、データファイル番号48が「1」であり、ファ
イル名49が「FILE01.IX2」となっている。
【0021】そして、索引編成ファイルをオープンする
際、つまり、ファイルオープン時には、図7のフローチ
ャートで示す手順に従った処理が行われる。まず、索引
編成ファイルのINPUTオープンであるか否かを判定
し(S101)、INPUTオープンでない場合には、
SRAM3上に設けられたファイルステータスブロック
領域から捜し出した空きブロックに対してファイルステ
ータスブロックの情報を書き込んで設定する(S10
2)。次に、索引編成ファイルにおけるデータファイル
のファイル番号ごとに割り当てられたブロックのそれぞ
れに対し、ファイル構成ブロックを構成するデータファ
イル15と第1及び第2インデックスファイル16,1
7との情報を書き込んで設定する(S103)。その
後、資源確保などのような従来通りのファイルオープン
処理が行われる(S104)。なお、INPUTオープ
ン、つまり、読み出し専用であれば索引編成ファイルの
内容が書き換えられることはないので、上記処理を行う
必要はないことになる。
際、つまり、ファイルオープン時には、図7のフローチ
ャートで示す手順に従った処理が行われる。まず、索引
編成ファイルのINPUTオープンであるか否かを判定
し(S101)、INPUTオープンでない場合には、
SRAM3上に設けられたファイルステータスブロック
領域から捜し出した空きブロックに対してファイルステ
ータスブロックの情報を書き込んで設定する(S10
2)。次に、索引編成ファイルにおけるデータファイル
のファイル番号ごとに割り当てられたブロックのそれぞ
れに対し、ファイル構成ブロックを構成するデータファ
イル15と第1及び第2インデックスファイル16,1
7との情報を書き込んで設定する(S103)。その
後、資源確保などのような従来通りのファイルオープン
処理が行われる(S104)。なお、INPUTオープ
ン、つまり、読み出し専用であれば索引編成ファイルの
内容が書き換えられることはないので、上記処理を行う
必要はないことになる。
【0022】一方、索引編成ファイルをクローズする
際、つまり、ファイルクローズ時においては、図8のフ
ローチャートで示す手順に従った処理が行われる。すな
わち、まず、索引編成ファイルのINPUTオープンで
あるか否かを判定し(S111)、INPUTオープン
でない場合には、資源開放などのような従来通りのファ
イルクローズ処理を行う(S112)。そして、ファイ
ル構成ブロックを構成するデータファイル15及び第1
及び第2インデックスファイル16,17をクリアする
処理を行った(S113)後、ファイルステータスブロ
ックをクリアするのである(S114)。なお、ファイ
ルオープン時と同様、このファイルクローズ時において
も、INPUTオープンであるならば上記処理を行う必
要はない。
際、つまり、ファイルクローズ時においては、図8のフ
ローチャートで示す手順に従った処理が行われる。すな
わち、まず、索引編成ファイルのINPUTオープンで
あるか否かを判定し(S111)、INPUTオープン
でない場合には、資源開放などのような従来通りのファ
イルクローズ処理を行う(S112)。そして、ファイ
ル構成ブロックを構成するデータファイル15及び第1
及び第2インデックスファイル16,17をクリアする
処理を行った(S113)後、ファイルステータスブロ
ックをクリアするのである(S114)。なお、ファイ
ルオープン時と同様、このファイルクローズ時において
も、INPUTオープンであるならば上記処理を行う必
要はない。
【0023】引き続いて図9ないし図13に基づき、W
RITE命令によって実行されるレコード追加時の処理
を説明する。ここでの図9はレコード追加時の処理手順
を示すフローチャート、図10はレコード追加中におけ
るファイルステータスブロックの内容を例示する説明
図、図11はレコード追加後における索引編成ファイル
の内容を例示する説明図であり、図12はレコード追加
中に計算機システムがダウンした際における索引編成フ
ァイルの内容を例示する説明図、図13はレコード追加
中にシステムダウンした際の復旧手順を示すフローチャ
ートである。
RITE命令によって実行されるレコード追加時の処理
を説明する。ここでの図9はレコード追加時の処理手順
を示すフローチャート、図10はレコード追加中におけ
るファイルステータスブロックの内容を例示する説明
図、図11はレコード追加後における索引編成ファイル
の内容を例示する説明図であり、図12はレコード追加
中に計算機システムがダウンした際における索引編成フ
ァイルの内容を例示する説明図、図13はレコード追加
中にシステムダウンした際の復旧手順を示すフローチャ
ートである。
【0024】WRITE命令は、データファイル15に
対してレコードを追加し、かつ、第1及び第2インデッ
クスファイル16,17のそれぞれに対してキーを登録
する命令であるので、レコードを追加する際には、図9
のフローチャートで示すような手順に従った処理が行わ
れる。まず、既に同じキーが登録済みであるか否かを判
定し(S121)、登録済みであればエラー処理(S1
22)を行ったうえで処理を終了する。また、登録済み
でないと判定された場合には、データファイル15の空
きレコード番号、例えば、「10」を捜し出した(S1
23)うえ、図10で示すファイルステータスブロック
の命令モード51に対してWRITE命令を示す「1」
をセットするとともに、レコード番号52に対して空き
レコード番号である「10」をセットする(S12
4)。なお、ファイルステータスブロックにおけるファ
イル番号50はファイルオープン時に設定された「1」
のままであり、REWRITE命令用バッファ53は使
用されないことになっている。
対してレコードを追加し、かつ、第1及び第2インデッ
クスファイル16,17のそれぞれに対してキーを登録
する命令であるので、レコードを追加する際には、図9
のフローチャートで示すような手順に従った処理が行わ
れる。まず、既に同じキーが登録済みであるか否かを判
定し(S121)、登録済みであればエラー処理(S1
22)を行ったうえで処理を終了する。また、登録済み
でないと判定された場合には、データファイル15の空
きレコード番号、例えば、「10」を捜し出した(S1
23)うえ、図10で示すファイルステータスブロック
の命令モード51に対してWRITE命令を示す「1」
をセットするとともに、レコード番号52に対して空き
レコード番号である「10」をセットする(S12
4)。なお、ファイルステータスブロックにおけるファ
イル番号50はファイルオープン時に設定された「1」
のままであり、REWRITE命令用バッファ53は使
用されないことになっている。
【0025】そして、追加されるレコード70の内容を
図11で示すデータファイル15に書き込んだ(S12
5)うえ、第1及び第2インデックスファイル16,1
7のそれぞれに対してレコード70の第1キー71と第
2キー72とを登録する(S126)。その後、ファイ
ルステータスブロックの命令モード51及びレコード番
号52をクリアする(S127)。すなわち、ここで
は、索引編成ファイルにレコードを実際に書き込む以前
の時点において、ファイルステータスブロックに命令モ
ード及びレコード番号を書き込んでいる(S124)た
め、レコード追加中に計算機システムのダウンが起こっ
ても、どのような命令に従いながら、どのレコード番号
の処理を行っていたかが分かることになる。また、この
際、特に重要なのは、データファイルへのレコードの書
き込み処理(S125)と、インデックスファイルヘの
キーの書き込み処理(S126)とを、この順序に従っ
て実行することである。つまり、このような順序に従え
ば、データファイル上に残っているレコードの内容に基
づいてインデックスファイルのキーを再登録することが
可能となるのである。
図11で示すデータファイル15に書き込んだ(S12
5)うえ、第1及び第2インデックスファイル16,1
7のそれぞれに対してレコード70の第1キー71と第
2キー72とを登録する(S126)。その後、ファイ
ルステータスブロックの命令モード51及びレコード番
号52をクリアする(S127)。すなわち、ここで
は、索引編成ファイルにレコードを実際に書き込む以前
の時点において、ファイルステータスブロックに命令モ
ード及びレコード番号を書き込んでいる(S124)た
め、レコード追加中に計算機システムのダウンが起こっ
ても、どのような命令に従いながら、どのレコード番号
の処理を行っていたかが分かることになる。また、この
際、特に重要なのは、データファイルへのレコードの書
き込み処理(S125)と、インデックスファイルヘの
キーの書き込み処理(S126)とを、この順序に従っ
て実行することである。つまり、このような順序に従え
ば、データファイル上に残っているレコードの内容に基
づいてインデックスファイルのキーを再登録することが
可能となるのである。
【0026】ところで、索引編成ファイルを構成するデ
ータファイル15と第1及び第2インデックスファイル
16,17との不整合が生じるのは、レコード追加時の
処理手順を示すフローチャートにおけるS125の処理
が完丁してからS126の処理が完了するまでの間にシ
ステムダウンが起こった場合である。そして、このよう
な場合には、例えば、図12で示しているように、索引
編成ファイルを構成するデータファイル15にレコード
70の内容が書き込まれ、かつ、第1インデックスファ
イル16に第1キー71が登録されているにも拘わら
ず、第2インデックスファイル17には第2キー72が
未登録であるというような事態が発生していることにな
る。なお、システムダウンの状況によっては、第2キー
72のみならず、第1キー71も未登録となっている場
合がある。すなわち、これらの事態は、索引編成ファイ
ルを構成するデータファイル15と第1及び第2インデ
ックスファイル16,17とが不整合であることを示し
ている。
ータファイル15と第1及び第2インデックスファイル
16,17との不整合が生じるのは、レコード追加時の
処理手順を示すフローチャートにおけるS125の処理
が完丁してからS126の処理が完了するまでの間にシ
ステムダウンが起こった場合である。そして、このよう
な場合には、例えば、図12で示しているように、索引
編成ファイルを構成するデータファイル15にレコード
70の内容が書き込まれ、かつ、第1インデックスファ
イル16に第1キー71が登録されているにも拘わら
ず、第2インデックスファイル17には第2キー72が
未登録であるというような事態が発生していることにな
る。なお、システムダウンの状況によっては、第2キー
72のみならず、第1キー71も未登録となっている場
合がある。すなわち、これらの事態は、索引編成ファイ
ルを構成するデータファイル15と第1及び第2インデ
ックスファイル16,17とが不整合であることを示し
ている。
【0027】しかしながら、このような事態下であって
も、図10で例示したファイルステータスブロックを見
れば、その命令モード51からWRITE命令の実行中
であり、レコード番号52の内容から番号「10」のレ
コードを処理中であったことが分かる。そこで、データ
ファイル15と第1及び第2インデックスファイル1
6,17との不整合は、図13のフローチャートで示す
復旧手順を採用することによって解消される。すなわ
ち、まず、ファイルステータスブロックの命令モード5
1がWRITE命令を表す「1」であるか否かを判定し
(S131)、「1」であるならばレコード番号52が
セットされているか否かを判定した(S132)うえ、
セットされていればレコード番号52に従ってデータフ
ァイル15内に存在する番号「10」のレコード70の
内容を読み取った(S133)後、読み取れたか否かを
判定する(S134)。
も、図10で例示したファイルステータスブロックを見
れば、その命令モード51からWRITE命令の実行中
であり、レコード番号52の内容から番号「10」のレ
コードを処理中であったことが分かる。そこで、データ
ファイル15と第1及び第2インデックスファイル1
6,17との不整合は、図13のフローチャートで示す
復旧手順を採用することによって解消される。すなわ
ち、まず、ファイルステータスブロックの命令モード5
1がWRITE命令を表す「1」であるか否かを判定し
(S131)、「1」であるならばレコード番号52が
セットされているか否かを判定した(S132)うえ、
セットされていればレコード番号52に従ってデータフ
ァイル15内に存在する番号「10」のレコード70の
内容を読み取った(S133)後、読み取れたか否かを
判定する(S134)。
【0028】そして、レコード70を読み取ることがで
きなければ、第1及び第2インデックスファイル16,
17の第1キー71及び第2キー72も登録されていな
いのであるから、索引編成ファイルを構成するデータフ
ァイル15と第1及び第2インデックスファイル16,
17との整合性は保たれていることになる。また、レコ
ード70が読み取れた場合には、このレコード70の内
容に基づき、第1及び第2インデックスファイル16,
17における第1キーの領域21及び第1キーの領域2
1それぞれに対して第1キー71及び第2キー72を再
登録する(S135)。その結果、索引編成ファイルを
構成するデータファイル15と第1及び第2インデック
スファイル16,17との整合性は、図11で示したと
同一の状態に回復したことになる。
きなければ、第1及び第2インデックスファイル16,
17の第1キー71及び第2キー72も登録されていな
いのであるから、索引編成ファイルを構成するデータフ
ァイル15と第1及び第2インデックスファイル16,
17との整合性は保たれていることになる。また、レコ
ード70が読み取れた場合には、このレコード70の内
容に基づき、第1及び第2インデックスファイル16,
17における第1キーの領域21及び第1キーの領域2
1それぞれに対して第1キー71及び第2キー72を再
登録する(S135)。その結果、索引編成ファイルを
構成するデータファイル15と第1及び第2インデック
スファイル16,17との整合性は、図11で示したと
同一の状態に回復したことになる。
【0029】そこで、ファイルステータスブロックをク
リア、つまり、ファイル番号50,命令モード51,レ
コード番号52,REWRITE命令用バッファ53の
全てをクリアする(S136)と、正常にファイルクロ
ーズ処理されたのと同じ状態となる。すなわち、以上説
明したシステムダウン時の復旧処理を行った結果、復旧
処理前には未登録であった第2インデックスファイル1
7の第2キー72が登録されていることになり、データ
ファイル15と第1及び第2インデックスファイル1
6,17との整合性が回復したことになる。なお、図1
3のフローチャートにおけるS131で命令モード51
が「1」でないと判定され、また、S132でレコード
番号52がセットされていないと判定された場合には処
理を中断したうえでS136へと移行する一方、S13
4でもってレコード70を読み込めないと判定された際
にもS136へと移行することになっている。
リア、つまり、ファイル番号50,命令モード51,レ
コード番号52,REWRITE命令用バッファ53の
全てをクリアする(S136)と、正常にファイルクロ
ーズ処理されたのと同じ状態となる。すなわち、以上説
明したシステムダウン時の復旧処理を行った結果、復旧
処理前には未登録であった第2インデックスファイル1
7の第2キー72が登録されていることになり、データ
ファイル15と第1及び第2インデックスファイル1
6,17との整合性が回復したことになる。なお、図1
3のフローチャートにおけるS131で命令モード51
が「1」でないと判定され、また、S132でレコード
番号52がセットされていないと判定された場合には処
理を中断したうえでS136へと移行する一方、S13
4でもってレコード70を読み込めないと判定された際
にもS136へと移行することになっている。
【0030】次に、図14ないし図18に基づき、RE
WRITE命令によるレコード書き換え時の処理を説明
する。ここでの図14はレコード書き換え時の処理手順
を示すフローチャート、図15はレコード書き換え中に
おけるファイルステータスブロックの内容を例示する説
明図、図16はレコード書き換え後における索引編成フ
ァイルの内容を例示する説明図であり、図17はレコー
ド書き換え中にシステムダウンが発生した際における索
引編成ファイルの内容を例示する説明図、図18はシス
テムダウンした際の復旧手順を示すフローチャートであ
る。
WRITE命令によるレコード書き換え時の処理を説明
する。ここでの図14はレコード書き換え時の処理手順
を示すフローチャート、図15はレコード書き換え中に
おけるファイルステータスブロックの内容を例示する説
明図、図16はレコード書き換え後における索引編成フ
ァイルの内容を例示する説明図であり、図17はレコー
ド書き換え中にシステムダウンが発生した際における索
引編成ファイルの内容を例示する説明図、図18はシス
テムダウンした際の復旧手順を示すフローチャートであ
る。
【0031】REWRITE命令は、データファイル1
5内のレコードを書き換え、かつ、第1及び第2インデ
ックスファイル16,17のキーを書き換える命令であ
るので、図14のフローチャートで示すような手順に従
った処理が行われる。すなわち、まず、キーボード6を
通じて指定されたうえで書き換えられるレコードの内容
を読み取り(S141)、読み取れたか否かを判定し
(S142)、読み取れなければエラー処理(S14
3)を行ったうえで処理を終了する。そして、読み取れ
た場合には、書き換えるべきレコードの内容、つまり、
データ及び番号を図15で示すファイルステータスブロ
ックのREWRITE命令用バッファ53に格納し(S
144)、かつ、REWRITE命令を示す「2」を命
令モード51にセットするとともに、書き換えるべきレ
コードの番号、例えば、「10」をレコード番号52に
対してセットする(S145)。なお、この際、ファイ
ルステータスブロックのファイル番号50はファイルオ
ープン時のまま、つまり、「1」がセットされたままと
なっている。
5内のレコードを書き換え、かつ、第1及び第2インデ
ックスファイル16,17のキーを書き換える命令であ
るので、図14のフローチャートで示すような手順に従
った処理が行われる。すなわち、まず、キーボード6を
通じて指定されたうえで書き換えられるレコードの内容
を読み取り(S141)、読み取れたか否かを判定し
(S142)、読み取れなければエラー処理(S14
3)を行ったうえで処理を終了する。そして、読み取れ
た場合には、書き換えるべきレコードの内容、つまり、
データ及び番号を図15で示すファイルステータスブロ
ックのREWRITE命令用バッファ53に格納し(S
144)、かつ、REWRITE命令を示す「2」を命
令モード51にセットするとともに、書き換えるべきレ
コードの番号、例えば、「10」をレコード番号52に
対してセットする(S145)。なお、この際、ファイ
ルステータスブロックのファイル番号50はファイルオ
ープン時のまま、つまり、「1」がセットされたままと
なっている。
【0032】そして、図16で示すデータファイル15
における番号「10」のレコードの内容を削除したうえ
で書き換え後のレコード70の内容とし(S146)、
かつ、第1及び第2インデックスファイル16,17か
ら書き換え前のレコードに対応する第1及び第2キーを
削除した(S147)後、削除されたキーのそれぞれに
対して書き換え後のレコード70に対応した第1及び第
2キー71,72を登録する(S148)。その後、フ
ァイルステータスブロックの命令モード51及びレコー
ド番号52をクリアし(S149)、処理を終了する。
すなわち、この処理では、レコードを実際に書き換える
以前の時点において、ファイルステータスブロックに対
して命令モード及びレコード番号と書き換え後のレコー
ドの内容とを予め書き込んでいる(S144,S14
5)ため、レコード書き換え中にシステムダウンが起こ
った場合であっても、どのような命令に従いながら、ど
のレコード番号の処理を行っていたかが分かる。
における番号「10」のレコードの内容を削除したうえ
で書き換え後のレコード70の内容とし(S146)、
かつ、第1及び第2インデックスファイル16,17か
ら書き換え前のレコードに対応する第1及び第2キーを
削除した(S147)後、削除されたキーのそれぞれに
対して書き換え後のレコード70に対応した第1及び第
2キー71,72を登録する(S148)。その後、フ
ァイルステータスブロックの命令モード51及びレコー
ド番号52をクリアし(S149)、処理を終了する。
すなわち、この処理では、レコードを実際に書き換える
以前の時点において、ファイルステータスブロックに対
して命令モード及びレコード番号と書き換え後のレコー
ドの内容とを予め書き込んでいる(S144,S14
5)ため、レコード書き換え中にシステムダウンが起こ
った場合であっても、どのような命令に従いながら、ど
のレコード番号の処理を行っていたかが分かる。
【0033】また、ここで重要なのは、データファイル
へのレコードの書き換え処理(S146)と、インデッ
クスファイルからキーを削除する処理(S147)及び
キーを登録する処理(S148)とを、この順序で実行
することである。つまり、このようにすれば、データフ
ァイル上に存在するレコード70の内容とファイルステ
ータスブロックのREWRITE命令用バッファ53の
内容とに基づき、インデックスファイルのキーの再削除
及び再登録を行うことが可能となるのである。
へのレコードの書き換え処理(S146)と、インデッ
クスファイルからキーを削除する処理(S147)及び
キーを登録する処理(S148)とを、この順序で実行
することである。つまり、このようにすれば、データフ
ァイル上に存在するレコード70の内容とファイルステ
ータスブロックのREWRITE命令用バッファ53の
内容とに基づき、インデックスファイルのキーの再削除
及び再登録を行うことが可能となるのである。
【0034】ところで、レコードの書き換え時におい
て、データファイル15と第1及び第2インデックスフ
ァイル16,17との不整合が生じるのは、図14のフ
ローチャート中におけるS146の処理が完丁してから
S148の処理が完了するまでの間に計算機システムが
ダウンした場合である。そして、このような場合には、
図17で例示しているように、データファイル15のレ
コード70及び第1インデックスファイル16の第1キ
ー71が書き換え済みであるにも拘わらず、第2インデ
ックスファイル17の第2キー72が書き換えられてい
ないという事態が生じる。なお、システムダウンの状況
によっては第1キー71も書き換えられていないことが
あり、これらの事態はデータファイル15と第1及び第
2インデックスファイル16,17とが不整合であるこ
とを示している。
て、データファイル15と第1及び第2インデックスフ
ァイル16,17との不整合が生じるのは、図14のフ
ローチャート中におけるS146の処理が完丁してから
S148の処理が完了するまでの間に計算機システムが
ダウンした場合である。そして、このような場合には、
図17で例示しているように、データファイル15のレ
コード70及び第1インデックスファイル16の第1キ
ー71が書き換え済みであるにも拘わらず、第2インデ
ックスファイル17の第2キー72が書き換えられてい
ないという事態が生じる。なお、システムダウンの状況
によっては第1キー71も書き換えられていないことが
あり、これらの事態はデータファイル15と第1及び第
2インデックスファイル16,17とが不整合であるこ
とを示している。
【0035】しかしながら、この事態下においても、図
15で示したファイルステータスブロックを見れば、そ
の命令モード51からREWRITE命令の実行中であ
り、レコード番号52の内容から番号「10」のレコー
ドを処理中であったことが分かる。そこで、データファ
イル15と第1及び第2インデックスファイル16,1
7との不整合は、図18のフローチャートでもって示す
復旧手順を採用することによって解消される。すなわ
ち、まず、ファイルステータスブロックにおける命令モ
ード51がREWRITE命令を示す「2」であるか否
かを判定し(S151)、「2」であるならばレコード
番号52がセットされているか否かを判定する(S15
2)。そして、レコード番号52がセットされているの
であれば、レコード番号52の内容に従ってデータファ
イル15内における番号「10」のレコード70を読み
取った(S153)うえ、読み取れたか否かを判定する
(S154)。
15で示したファイルステータスブロックを見れば、そ
の命令モード51からREWRITE命令の実行中であ
り、レコード番号52の内容から番号「10」のレコー
ドを処理中であったことが分かる。そこで、データファ
イル15と第1及び第2インデックスファイル16,1
7との不整合は、図18のフローチャートでもって示す
復旧手順を採用することによって解消される。すなわ
ち、まず、ファイルステータスブロックにおける命令モ
ード51がREWRITE命令を示す「2」であるか否
かを判定し(S151)、「2」であるならばレコード
番号52がセットされているか否かを判定する(S15
2)。そして、レコード番号52がセットされているの
であれば、レコード番号52の内容に従ってデータファ
イル15内における番号「10」のレコード70を読み
取った(S153)うえ、読み取れたか否かを判定する
(S154)。
【0036】そして、レコード70を読み取ることがで
きなければ、ファイルステータスブロックをクリアし
(S136)、処理を終了する。また、レコード70が
読み取れた場合には、読み取ったレコード70の内容
と、ファイルステータスブロックにおけるREWRIT
E命令用バッファ53の内容とを互いに比較し(S15
5)、相違しているか否かを判定した(S156)う
え、REWRITE命令用バッファ53の内容に基づい
て第1及び第2インデックスファイル16,17から第
1及び第2キーを削除する(S157)。さらに、削除
されたキーのそれぞれに対し、書き換え後のレコード7
0に対応した第1及び第2キー71,72を再登録した
(S158)後、ファイルステータスブロックをクリア
して処理を終了する(S159)。その結果、索引編成
ファイルを構成するデータファイル15と第1及び第2
インデックスファイル16,17との整合性は、図16
で示した通りに回復していることになる。
きなければ、ファイルステータスブロックをクリアし
(S136)、処理を終了する。また、レコード70が
読み取れた場合には、読み取ったレコード70の内容
と、ファイルステータスブロックにおけるREWRIT
E命令用バッファ53の内容とを互いに比較し(S15
5)、相違しているか否かを判定した(S156)う
え、REWRITE命令用バッファ53の内容に基づい
て第1及び第2インデックスファイル16,17から第
1及び第2キーを削除する(S157)。さらに、削除
されたキーのそれぞれに対し、書き換え後のレコード7
0に対応した第1及び第2キー71,72を再登録した
(S158)後、ファイルステータスブロックをクリア
して処理を終了する(S159)。その結果、索引編成
ファイルを構成するデータファイル15と第1及び第2
インデックスファイル16,17との整合性は、図16
で示した通りに回復していることになる。
【0037】すなわち、以上説明した復旧処理を行った
結果、復旧処理前には不整合であった第2インデックス
ファイル17の第2キー72がデータファイル15及び
第1インデックスファイル17と整合していることにな
り、正常にファイルクローズ処理されたのと同じ状態と
なる。なお、図18のフローチャートにおけるS151
で命令モード51が「2」でないと判定され、また、S
152でレコード番号52がセットされていないと判定
された場合には処理を中断したうえでS159へと移行
し、S154でもってレコード70を読み込めないと判
定された際にもS159へと移行することになってい
る。
結果、復旧処理前には不整合であった第2インデックス
ファイル17の第2キー72がデータファイル15及び
第1インデックスファイル17と整合していることにな
り、正常にファイルクローズ処理されたのと同じ状態と
なる。なお、図18のフローチャートにおけるS151
で命令モード51が「2」でないと判定され、また、S
152でレコード番号52がセットされていないと判定
された場合には処理を中断したうえでS159へと移行
し、S154でもってレコード70を読み込めないと判
定された際にもS159へと移行することになってい
る。
【0038】さらに、引き続いて図19ないし図23に
基づき、DELETE命令によって実行されるレコード
削除時の処理を説明する。ここでの図19はレコード削
除時の処理手順を示すフローチャート、図20はレコー
ド削除中におけるファイルステータスブロックの内容を
例示する説明図、図21はレコード削除後における索引
編成ファイルの内容を例示する説明図であり、図22は
レコード削除中にシステムダウンが発生した際における
索引編成ファイルの内容を例示する説明図、図23はレ
コード削除中にシステムダウンした際の復旧手順を示す
フローチャートである。
基づき、DELETE命令によって実行されるレコード
削除時の処理を説明する。ここでの図19はレコード削
除時の処理手順を示すフローチャート、図20はレコー
ド削除中におけるファイルステータスブロックの内容を
例示する説明図、図21はレコード削除後における索引
編成ファイルの内容を例示する説明図であり、図22は
レコード削除中にシステムダウンが発生した際における
索引編成ファイルの内容を例示する説明図、図23はレ
コード削除中にシステムダウンした際の復旧手順を示す
フローチャートである。
【0039】DELETE命令は、データファイル15
からレコードを削除し、かつ、第1及び第2インデック
スファイル16,17のそれぞれからも対応するキーを
削除する命令であるので、図19のフローチャートで示
すような手順に従った処理が行われる。まず、キーボー
ド6で指定されたうえで削除されるレコードの内容を読
み取り(S161)、読み取れたか否かを判定した(S
162)後、読み取れなければエラー処理(S163)
を行ったうえで処理を終了する。そして、読み取れた場
合には、図20で示しているように、ファイルステータ
スブロックの命令モード51に対してDELETE命令
を示す「3」をセットするとともに、削除されるレコー
ドの番号、例えば、「10」をレコード番号52に対し
てセットする(S164)。なお、この際、ファイルス
テータスブロックのファイル番号50はファイルオープ
ンを示す「1」のままとされており、REWRITE命
令用バッファ53は使用されないことになっている。
からレコードを削除し、かつ、第1及び第2インデック
スファイル16,17のそれぞれからも対応するキーを
削除する命令であるので、図19のフローチャートで示
すような手順に従った処理が行われる。まず、キーボー
ド6で指定されたうえで削除されるレコードの内容を読
み取り(S161)、読み取れたか否かを判定した(S
162)後、読み取れなければエラー処理(S163)
を行ったうえで処理を終了する。そして、読み取れた場
合には、図20で示しているように、ファイルステータ
スブロックの命令モード51に対してDELETE命令
を示す「3」をセットするとともに、削除されるレコー
ドの番号、例えば、「10」をレコード番号52に対し
てセットする(S164)。なお、この際、ファイルス
テータスブロックのファイル番号50はファイルオープ
ンを示す「1」のままとされており、REWRITE命
令用バッファ53は使用されないことになっている。
【0040】そして、図21で示すように、索引編成フ
ァイルを構成する第1及び第2インデックスファイル1
6,17から対応するキーを削除し(S165)、か
つ、データファイル15から対応するレコードを削除し
た(S166)うえでファイルステータスブロックの命
令モード51及びレコード番号52をクリアする(S1
67)。すなわち、この処理では、索引編成ファイルか
らレコードを実際に削除する以前の時点において、ファ
イルステータスブロックに命令モード及びレコード番号
を書き込んでいる(S164)ため、レコード削除中に
システムダウンが発生したとしても、どのような命令に
従ってどのレコード番号の処理を行っていたかが分か
る。また、ここで重要となるのは、データファイルから
レコードを削除する(S166)よりも先にインデック
スファイルからキーを削除する(S165)ことであ
る。つまり、このようにしておけば、データファイル上
に残っているレコードの内容に基づき、インデックスフ
ァイルのキーを再削除することが可能となるからであ
る。
ァイルを構成する第1及び第2インデックスファイル1
6,17から対応するキーを削除し(S165)、か
つ、データファイル15から対応するレコードを削除し
た(S166)うえでファイルステータスブロックの命
令モード51及びレコード番号52をクリアする(S1
67)。すなわち、この処理では、索引編成ファイルか
らレコードを実際に削除する以前の時点において、ファ
イルステータスブロックに命令モード及びレコード番号
を書き込んでいる(S164)ため、レコード削除中に
システムダウンが発生したとしても、どのような命令に
従ってどのレコード番号の処理を行っていたかが分か
る。また、ここで重要となるのは、データファイルから
レコードを削除する(S166)よりも先にインデック
スファイルからキーを削除する(S165)ことであ
る。つまり、このようにしておけば、データファイル上
に残っているレコードの内容に基づき、インデックスフ
ァイルのキーを再削除することが可能となるからであ
る。
【0041】ところで、索引編成ファイルを構成するデ
ータファイル15と第1及び第2インデックスファイル
16,17との不整合がレコード削除中に生じるのは、
図19で示したフローチャートにおけるS165の処理
が完了してからS166の処理が完了するまでの間にシ
ステムダウンが起こった場合である。そして、この場合
には、例えば、図22で示すように、索引編成ファイル
を構成する第1インデックスファイル16からは第1キ
ー71が削除されているにも拘わらず、第2インデック
スファイル17からは第2キー72が削除されておら
ず、また、データファイル15からレコード70が削除
されていないというような事態が生じる。なお、場合に
よっては、第1キー71までもが削除されずに残ってい
ることもある。すなわち、これらの事態は、データファ
イル15と第1及び第2インデックスファイル16,1
7とが互いに不整合であることを示している。
ータファイル15と第1及び第2インデックスファイル
16,17との不整合がレコード削除中に生じるのは、
図19で示したフローチャートにおけるS165の処理
が完了してからS166の処理が完了するまでの間にシ
ステムダウンが起こった場合である。そして、この場合
には、例えば、図22で示すように、索引編成ファイル
を構成する第1インデックスファイル16からは第1キ
ー71が削除されているにも拘わらず、第2インデック
スファイル17からは第2キー72が削除されておら
ず、また、データファイル15からレコード70が削除
されていないというような事態が生じる。なお、場合に
よっては、第1キー71までもが削除されずに残ってい
ることもある。すなわち、これらの事態は、データファ
イル15と第1及び第2インデックスファイル16,1
7とが互いに不整合であることを示している。
【0042】しかしながら、このような事態下であって
も、図20で例示したファイルステータスブロックを見
れば、その命令モード51からDELETE命令の実行
中であり、レコード番号52の内容から番号「10」の
レコードを処理中であったことが分かる。そこで、デー
タファイル15と第1及び第2インデックスファイル1
6,17との不整合は、図23のフローチャートで示す
復旧手順を採用することによって解消される。すなわ
ち、まず、ファイルステータスブロックの命令モード5
1がDELETE命令を表す「3」であるか否かを判定
し(S171)、かつ、「3」であるならばレコード番
号52がセットされているか否かを判定し(S17
2)、セットされていればレコード番号52に従ってデ
ータファイル15内に存在する番号「10」のレコード
70の内容を読み取る(S173)。
も、図20で例示したファイルステータスブロックを見
れば、その命令モード51からDELETE命令の実行
中であり、レコード番号52の内容から番号「10」の
レコードを処理中であったことが分かる。そこで、デー
タファイル15と第1及び第2インデックスファイル1
6,17との不整合は、図23のフローチャートで示す
復旧手順を採用することによって解消される。すなわ
ち、まず、ファイルステータスブロックの命令モード5
1がDELETE命令を表す「3」であるか否かを判定
し(S171)、かつ、「3」であるならばレコード番
号52がセットされているか否かを判定し(S17
2)、セットされていればレコード番号52に従ってデ
ータファイル15内に存在する番号「10」のレコード
70の内容を読み取る(S173)。
【0043】そして、読み取れたか否かを判定し(S1
74)、読み取れた場合にはレコード70の内容に基づ
いて第2インデックスファイル17における第2キー7
2、あるいはまた、第1キー71も残っている場合に
は、第1及び第2インデックスファイル16,17にお
ける第1キー71及び第2キー72をともに削除する
(S175)。その後、データファイル15内に残って
いたレコード70を削除し(S176)、ファイルステ
ータスブロックをクリア、つまり、ファイル番号50,
命令モード51,レコード番号52,REWRITE命
令用バッファ53の全てをクリアして処理を終了する
(S177)。
74)、読み取れた場合にはレコード70の内容に基づ
いて第2インデックスファイル17における第2キー7
2、あるいはまた、第1キー71も残っている場合に
は、第1及び第2インデックスファイル16,17にお
ける第1キー71及び第2キー72をともに削除する
(S175)。その後、データファイル15内に残って
いたレコード70を削除し(S176)、ファイルステ
ータスブロックをクリア、つまり、ファイル番号50,
命令モード51,レコード番号52,REWRITE命
令用バッファ53の全てをクリアして処理を終了する
(S177)。
【0044】その結果、索引編成ファイルを構成するデ
ータファイル15と第1及び第2インデックスファイル
16,17との整合性は図21で示した通りに回復し、
正常にファイルクローズ処理されたのと同じ状態とな
る。なお、図23のフローチャートにおけるS171で
命令モード51が「3」でないと判定され、また、S1
72でレコード番号52がセットされていないと判定さ
れた場合には処理を中断したうえでS177へと移行
し、S174でもってレコード70を読み込めないと判
定された際にもS177へと移行することになる。
ータファイル15と第1及び第2インデックスファイル
16,17との整合性は図21で示した通りに回復し、
正常にファイルクローズ処理されたのと同じ状態とな
る。なお、図23のフローチャートにおけるS171で
命令モード51が「3」でないと判定され、また、S1
72でレコード番号52がセットされていないと判定さ
れた場合には処理を中断したうえでS177へと移行
し、S174でもってレコード70を読み込めないと判
定された際にもS177へと移行することになる。
【0045】
【発明の効果】以上説明したように、本発明にかかる索
引編成ファイルの自動復旧方式によれば、WRITE命
令によるレコード追加中に計算機システムがダウンした
場合であっても、追加中であったレコードの内容を可能
な限り有効に利用しながら復旧することができ、索引編
成ファイルを構成するデータファイルとインデックスフ
ァイルとの整合性を保つことができる。そして、この際
においては、限られたSRAMのメモリ容量でもって復
旧作業を実行することができ、従来例よりも高速の処理
を実現することが可能となる。さらにまた、本発明によ
れば、レコード追加中のみならず、レコード書き換え中
やレコード削除中にシステムダウンが発生した場合であ
っても、データファイルとインデックスファイルとの整
合性を容易に確保することができるという効果が得られ
る。
引編成ファイルの自動復旧方式によれば、WRITE命
令によるレコード追加中に計算機システムがダウンした
場合であっても、追加中であったレコードの内容を可能
な限り有効に利用しながら復旧することができ、索引編
成ファイルを構成するデータファイルとインデックスフ
ァイルとの整合性を保つことができる。そして、この際
においては、限られたSRAMのメモリ容量でもって復
旧作業を実行することができ、従来例よりも高速の処理
を実現することが可能となる。さらにまた、本発明によ
れば、レコード追加中のみならず、レコード書き換え中
やレコード削除中にシステムダウンが発生した場合であ
っても、データファイルとインデックスファイルとの整
合性を容易に確保することができるという効果が得られ
る。
【図1】本実施例にかかる情報処理装置の全体構成を示
すブロック図である。
すブロック図である。
【図2】索引編成ファイルの構造を示す説明図である。
【図3】ファイル構成ブロックの構造を示す説明図であ
る。
る。
【図4】ファイルステータスブロックの構造を示す説明
図である。
図である。
【図5】SRAMの構造を示す説明図である。
【図6】索引編成ファイルがオープンされた際における
ファイルステータスブロック及びファイル構成ブロック
の内容を例示する説明図である。
ファイルステータスブロック及びファイル構成ブロック
の内容を例示する説明図である。
【図7】ファイルオープン時の処理手順を示すフローチ
ャートである。
ャートである。
【図8】ファイルクローズ時の処理手順を示すフローチ
ャートである。
ャートである。
【図9】レコード追加時の処理手順を示すフローチャー
トである。
トである。
【図10】レコード追加中におけるファイルステータス
ブロックの内容を例示する説明図である。
ブロックの内容を例示する説明図である。
【図11】レコード追加後における索引編成ファイルの
内容を例示する説明図である。
内容を例示する説明図である。
【図12】レコード追加中に計算機システムがダウンし
た際における索引編成ファイルの内容を例示する説明図
である。
た際における索引編成ファイルの内容を例示する説明図
である。
【図13】レコード追加中にシステムダウンした際の復
旧手順を示すフローチャートである。
旧手順を示すフローチャートである。
【図14】レコード書き換え時の処理手順を示すフロー
チャートである。
チャートである。
【図15】レコード書き換え中におけるファイルステー
タスブロックの内容を例示する説明図である。
タスブロックの内容を例示する説明図である。
【図16】レコード書き換え後の索引編成ファイルの内
容を例示する説明図である。
容を例示する説明図である。
【図17】レコード書き換え中にシステムダウンが発生
した際における索引編成ファイルの内容を例示する説明
図である。
した際における索引編成ファイルの内容を例示する説明
図である。
【図18】レコード書き換え中にシステムダウンした際
の復旧手順を示すフローチャートである。
の復旧手順を示すフローチャートである。
【図19】レコード削除時の処理手順を示すフローチャ
ートである。
ートである。
【図20】レコード削除中におけるファイルステータス
ブロックの内容を例示する説明図である。
ブロックの内容を例示する説明図である。
【図21】レコード削除後における索引編成ファイルの
内容を例示する説明図である。
内容を例示する説明図である。
【図22】レコード削除中にシステムダウンが発生した
際における索引編成ファイルの内容を例示する説明図で
ある。
際における索引編成ファイルの内容を例示する説明図で
ある。
【図23】レコード削除中にシステムダウンした際の復
旧手順を示すフローチャートである。
旧手順を示すフローチャートである。
Claims (3)
- 【請求項1】 計算機システムの2次記憶媒体上で索引
編成ファイルの更新を行う際のファイルオープン時に
は、ファイル名、レコード長及びキー位置などのファイ
ル基本情報を不揮発性メモリに格納することが行われ、
また、レコード追加時には、追加されるレコードの番号
を不揮発性メモリに格納し、かつ、追加すべきレコード
の内容をデータファイルに登録した後、追加すべきレコ
ードのキーをインデックスファイルに登録することが行
われ、さらに、ファイルクローズ時には、ファイル基本
情報を消去することが行われる処理であって、 システム起動直後における不揮発性メモリの内容に基づ
き、ファイルオープン中であり、かつ、レコード追加中
である際には、追加すべきレコードの内容がデータファ
イルに存在しているか否かを確認し、存在している場合
には、インデックスファイルに対して追加すべきレコー
ドのキーの再登録を試みたうえで不揮発性メモリの内容
を消去することを特徴とする索引編成ファイルの自動復
旧方式。 - 【請求項2】 計算機システムの2次記憶媒体上で索引
編成ファイルの更新を行う際のファイルオープン時に
は、ファイル名、レコード長及びキー位置などのファイ
ル基本情報を不揮発性メモリに格納することが行われ、
また、レコード書き換え時には、書き換えられるレコー
ドのデータ及び番号を不揮発性メモリに格納し、書き換
え前のレコードの内容を削除して書き換え後のレコード
の内容をデータファイルに登録した後、書き換え前のレ
コードのキーを削除して書き換え後のレコードのキーを
インデックスファイルに登録することが行われ、さら
に、ファイルクローズ時には、ファイル基本情報を消去
することが行われる処理であって、 システム起動直後における不揮発性メモリの内容に基づ
き、ファイルオープン中であり、かつ、レコード書き換
え中である際には、不揮発性メモリに格納されたレコー
ドの内容と、データファイルに登録されたレコードの内
容とを比較し、相違している場合には、インデックスフ
ァイルに対して書き換え前のレコードのキーの再削除及
び書き換え後のレコードのキーの再登録を試みたうえで
不揮発性メモリの内容を消去することを特徴とする索引
編成ファイルの自動復旧方式。 - 【請求項3】 計算機システムの2次記憶媒体上で索引
編成ファイルの更新を行う際のファイルオープン時に
は、ファイル名、レコード長及びキー位置などのファイ
ル基本情報を不揮発性メモリに格納することが行われ、
また、レコード削除時には、削除されるレコードの番号
を不揮発性メモリに格納し、かつ、削除すべきレコード
のキーをインデックスファイルから削除した後、削除す
べきレコードの内容をデータファイルから削除すること
が行われ、さらに、ファイルクローズ時には、ファイル
基本情報を消去することが行われる処理であって、 システム起動直後の不揮発性メモリの内容に基づき、フ
ァイルオープン中であり、かつ、レコード削除中である
際には、削除すべきレコードの内容がデータファイルに
存在しているか否かを確認し、存在している場合には、
削除すべきレコードの内容をデータファイルから削除す
るとともに、削除すべきレコードのキーをインデックス
ファイルから削除したうえで不揮発性メモリの内容を消
去することを特徴とする索引編成ファイルの自動復旧方
式。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP7179973A JPH0934767A (ja) | 1995-07-17 | 1995-07-17 | 索引編成ファイルの自動復旧方式 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP7179973A JPH0934767A (ja) | 1995-07-17 | 1995-07-17 | 索引編成ファイルの自動復旧方式 |
Publications (1)
Publication Number | Publication Date |
---|---|
JPH0934767A true JPH0934767A (ja) | 1997-02-07 |
Family
ID=16075224
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP7179973A Pending JPH0934767A (ja) | 1995-07-17 | 1995-07-17 | 索引編成ファイルの自動復旧方式 |
Country Status (1)
Country | Link |
---|---|
JP (1) | JPH0934767A (ja) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2007023784A1 (ja) * | 2005-08-22 | 2007-03-01 | Sony Corporation | 記録装置、記録方法、プログラムおよびコンピュータ読み取り可能な記録媒体 |
-
1995
- 1995-07-17 JP JP7179973A patent/JPH0934767A/ja active Pending
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2007023784A1 (ja) * | 2005-08-22 | 2007-03-01 | Sony Corporation | 記録装置、記録方法、プログラムおよびコンピュータ読み取り可能な記録媒体 |
US8346064B2 (en) | 2005-08-22 | 2013-01-01 | Sony Corporation | Recording apparatus, recording method, program and computer-readable recording medium |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP4268396B2 (ja) | 1回プログラム可能な不揮発性メモリデバイスのファイル管理 | |
US7890720B2 (en) | Snapshot system | |
JP4037605B2 (ja) | 不揮発性メモリユニットのコントローラ、同コントローラを有するメモリシステム及び不揮発性メモリユニットの制御方法 | |
JP3797649B2 (ja) | 不揮発性半導体記憶装置 | |
US5086502A (en) | Method of operating a data processing system | |
JPH04233639A (ja) | ファイル管理システム | |
JP2006040264A (ja) | メモリカードの制御方法および不揮発性半導体メモリの制御方法 | |
KR100703680B1 (ko) | 플래시 파일 시스템 | |
CN109325005B (zh) | 一种数据处理方法和电子设备 | |
JP2000020367A (ja) | 情報記憶方法および情報記憶装置および記録媒体 | |
US20050149493A1 (en) | Data recording apparatus and data recording method | |
JPH0934767A (ja) | 索引編成ファイルの自動復旧方式 | |
JP3082344B2 (ja) | ディスクファイル制御装置およびアップデート方法 | |
JP2001084180A (ja) | ファイル管理装置 | |
US20060143423A1 (en) | Storage device, data processing method thereof, data processing program thereof, and data processing system | |
JP2002023964A (ja) | コンピュータ・システムにおける記録媒体に記憶された情報の制御方法 | |
JPH06282386A (ja) | ディスク記憶装置 | |
JP2002063057A (ja) | データ更新装置 | |
JP2008123104A (ja) | データアクセス装置 | |
JPH0561754A (ja) | データ処理装置 | |
JP6241373B2 (ja) | 記憶装置、フラッシュメモリ制御装置、及びプログラム | |
CN114880277B (zh) | 块设备快照方法、系统和存储介质 | |
US10732875B2 (en) | Data processing method for solid state drive | |
JP2004005524A (ja) | データ記録装置、データ記録方法、当該方法を実行するためのプログラム及びプログラム記録媒体 | |
JP2005222531A (ja) | データ記録装置及びデータ記録方法 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20040302 |