JPH08212122A

JPH08212122A - ファイル書替方式

Info

Publication number: JPH08212122A
Application number: JP7019985A
Authority: JP
Inventors: Hiroshi Kuwabara; 博桑原; Tamotsu Inoue; 保井上; Hideki Futai; 秀樹二井; Kunihiro Sakamoto; 邦裕阪本; Kimihide Jinno; 公秀神野; Kenji Misu; 健司三須; Yoshio Sato; 好男佐藤
Original assignee: Fujitsu Ltd; Nippon Telegraph and Telephone Corp
Current assignee: Fujitsu Ltd; NTT Inc
Priority date: 1995-02-08
Filing date: 1995-02-08
Publication date: 1996-08-20
Anticipated expiration: 2019-09-08
Also published as: JP3563802B2

Abstract

(57)【要約】【目的】運転ファイルよりバックアップファイルへの
ファイル書替方式に関し、データロギング方式により書
替え処理の高信頼性化を図ることを目的とする。【構成】運転ファイルの書替処理は、データ書替が発
生した場合、必ず書替データ（アドレス、旧データ、新
データ）をロギングデータに登録を行った後、メインメ
モリの運転ファイルのデータを書き替え、バックアップ
ファイルの照合は、書替アドレスが運転ファイルにあっ
た場合、運転ファイルとバックアップファイルとロギン
グデータのデータ比較チェックを行い、運転ファイルが
新データでバックアップファイルが旧データの場合は正
常とし、それ以外は異常とし、書替アドレスが無い場合
は、運転ファイルとバックアップファイルとのデータを
比較し、データが一致していれば正常とし、データが不
一致であれば異常とする。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は運転ファイルよりバック
アップファイルへのファイル書替方式に関する。近年の
ソフトウェアプログラムは大規模化してきており、非常
に高い信頼性を持つことが要求されてきている。一般的
なソフトウェアプログラムはシステム上に２種類存在し
ている。

【０００２】１つはメインメモリ（ＭＭ）上に展開され
動作しているプログラムで、運転ファイルと呼んでい
る。もう１つは２次記憶装置（ＯＤ）に蓄えられ万が一
のときに使用するプログラムで、バックアップファイル
と呼んでいる。これらのファイルの信頼性向上対策とし
て従来より様々な手段が実施されている。

【０００３】即ち、２次記憶装置（ＯＤ）の２重化（フ
ァイルのミラー化）とか、ファイルの２重置き（供給時
のファイルと最新ファイル）とかの手段がある。このよ
うな手段をとってきた背景には、ファイルを書き替える
必要性があるからである。

【０００４】ファイルを書き替える必要がなければ、バ
ックアップファイルをリードオンリーファイルにしてお
くことにより、ファイルの信頼性は非常に高いものとな
る。しかしソフトウェアプログラムはシステムデータ等
が書き替えられていくものであり、ファイルの書替作業
をいかに信頼性の高いものにするかが重要である。

【０００５】

【従来の技術】このようなファイルの書替作業の信頼性
向上対策として、従来では図２のバックアップファイル
更新処理手順によりファイルを書替えていた。バックア
ップファイルへの更新方法は、運転ファイルを書き替え
後、ファイルの安定性確認のために一定の監視時間をお
いて行うものである。

【０００６】図において、ＭＭはメインメモリで運転中
のファイルを有し、ＯＤは磁気ディスク等の２次記憶装
置でバックアップファイルを有する。以下の〜の手
順によりバックアップファイルの更新処理を行う。通常運転状態時、運転ファイルを書き替える。運転監視（２４時間）を行う。運転監視後、運転ファイルとバックアップファイルの
照合を行い、照合正常時のみ、運転ファイルをバックア
ップファイルに書き込む。（バックアップファイルの書
き替え）照合異常時（システム異常として）、バックアップフ
ァイルの引上げ処理を行い、運転ファイルを書き替え前
の状態に戻す。

【０００７】

【発明が解決しようとする課題】しかし、この方式では
以下の問題が生じる。 (1) 複数の書替データのうち書替処理が漏れた場合、照
合処理で正常となりバックアップファイルに不完全なフ
ァイルを書き込んでしまう可能性がある。 (2) ファイル監視中に書替データが破壊され、もし破壊
されたデータをアクセス／実行されなかったならば、監
視正常とみなされる可能性があり、破壊されたデータを
バックアップファイルに書き込むことになる。その後、
破壊されたデータをアクセス／実行した場合、運転ファ
イル・バックアップファイル共に正常なファイルが無い
為、システムダウンが発生する可能性がある。

【０００８】このような問題点を解決するためには、書
き替えるデータが正常に書き替えられているかチェック
する必要があった。本発明は、書替処理の高信頼性がこ
れまで以上に要求されてきているため、データロギング
（履歴）方式によるファイル書替方式を提案することを
目的とする。

【０００９】

【課題を解決するための手段】本発明のデータロギング
方式によるファイル書替方式の原理構成図を図１に示
す。図において、１はメインメモリ（ＭＭ）上の運転フ
ァイル、２は２次記憶装置（ＯＤ）上のバックアップフ
ァイル、３はロギングデータ、４は運転ファイルの書替
処理フロー、５はバックアップファイルの照合フロー、
６はバックアップファイルの更新フローを示す。

【００１０】バックアップファイルの更新は、運転ファ
イル１とバックアップファイル２を照合し、次の条件を
満たしたときのみバックアップファイル２の書き替えを
行う手段を構成する。ロギングデータ３には書替データ
としてアドレス、旧データ、新データが登録される。デ
ータロギング方式によるファイル書替方式は、次の条件
をチェックする。 (1) 書き替えたデータがある。 (2) 書き替えたデータが正常に書き替わっているかどう
か？ (3) 書き替える前のデータ値は正常値であったかどうか
？ (4) 書き替えていないエリアのデータ値の破壊はないか
？ (5) 書き替えるべきデータが全て書き替わっているかど
うか？

【００１１】

【作用】運転ファイル１の書替処理フロー４は、データ
書替が発生した場合、必ず書替データ（アドレス、旧デ
ータ、新データ）をロギングデータ３に登録を行った
後、メインメモリの運転ファイル１のデータを書き替え
る。

【００１２】バックアップファイル２の照合フロー５
は、書替アドレスが運転ファイル１にあった場合、運転
ファイル１とバックアップファイル２とロギングデータ
３のデータ比較チェックを行い、運転ファイル１が新デ
ータでバックアップファイル２が旧データの場合は正常
とし、それ以外は異常とする。

【００１３】書替アドレスが無い場合は、運転ファイル
１とバックアップファイル２とのデータを比較し、デー
タが一致していれば正常とし、データが不一致であれば
異常とする。

【００１４】バックアップファイル更新フロー６は、上
記５の照合結果が全アドレスで正常であればメインメモ
リ上の運転ファイル１を２次記憶装置のバックアップフ
ァイル２へ蓄積する（バックアップファイルの作成）。

【００１５】異常アドレスが一つでも有れば保守者通知
（メッセージ出力による）し、異常原因の解析を行う。

【００１６】

【実施例】以上のデータロギング方式によるファイル書
替方式の実施例をフローチャートで示す。メインメモリ
には、局データ（回線のハード上のデータ）と加入者デ
ータ（加入者毎のデータ）とシステムデータ（実行、処
理プログラム）とから構成されているので、各データに
分けてデータ変更時の書替方式のフローとバックアップ
ファイル収集時のフローを以下に示す。

【００１７】図３は局データ変更時のフロー実施例、図
４は加入者データ変更時のフロー実施例、図５はシステ
ムデータ変更時のフロー実施例、図６と図７は局データ
収集時のフロー実例、図８と図９は加入者データ収集時
のフロー実施例、図１０と図１１はシステムデータ収集
時のフロー実施例を示す。

【００１８】図３の局データ変更時のフロー実施例にお
いて、 (1) ユーザからの書き替え開始を受けて、局データを書
き替える。 (2) 局データの変更通知を行い、ロギングデータに書替
データ（アドレス、旧データ、新データ）を登録する。 (3) 局データ変更ロギング情報を検索し、該当アドレス
が存在するか否かを判定する。 (4) 該当アドレスが存在すれば、局データ変更ロギング
情報の新データ部のみ更新する。 (5) 該当アドレスが存在しなければ、局データ変更ロギ
ング情報にアドレス、旧データ、新データを蓄積する。

【００１９】図４の加入者データ変更時のフロー実施例
において、 (11)ユーザからの書き替え開始を受けて、加入者データ
を書き替える。 (12)加入者データの変更通知を行い、ロギングデータに
書替データ（アドレス、旧データ、新データ）を登録す
る。 (13)加入者データ変更ロギング情報を検索し、該当アド
レスが存在するか否かを判定する。 (14)該当アドレスが存在すれば、加入者データ変更ロギ
ング情報の新データ部のみ更新する。 (15)該当アドレスが存在しなければ、加入者データ変更
ロギング情報にアドレス、旧データ、新データを
蓄積する。

【００２０】図５のシステムデータ変更時のフロー実施
例において、 (21)システムデータの書き替え開始を受けて、ＭＭデー
タを書き替える。 (22)ＭＭデータの変更通知を行い、ロギングデータにＭ
Ｍデータ（アドレス、旧データ、新データ）変更を登録
する。 (23)アドレスにより、局データエリアか、加入者データ
エリアか、その他のエリアかを判定する。 (24)判定エリアが局データエリアであれば、局データ変
更ロギング情報を検索し、該当アドレスが存在するか否
かを判定する。 (25)該当アドレスが存在すれば、局データ変更ロギング
情報の新データ部のみ更新する。 (30)該当アドレスが存在しなければ、その他データ変更
ロギング情報にアドレス、旧データ、新データを
蓄積する。 (26)判定エリアが加入者データエリアであれば、加入者
データ変更ロギング情報を検索し、該当アドレスが存在
するか否かを判定する。 (27)該当アドレスが存在すれば、加入者データ変更ロギ
ング情報の新データ部のみ更新する。 (30)該当アドレスが存在しなければ、その他データ変更
ロギング情報にアドレス、旧データ、新データを
蓄積する。 (28)判定エリアがその他のエリアであれば、その他デー
タ変更ロギング情報を検索し、該当アドレスが存在する
か否かを判定する。 (29)該当アドレスが存在すれば、加入者データ変更ロギ
ング情報の新データ部のみ更新する。 (30)該当アドレスが存在しなければ、その他データ変更
ロギング情報にアドレス、旧データ、新データを
蓄積する。

【００２１】図６の局データ収集時のフロー実施例（そ
の１）において、 (31)局データ収集開始を受けて局データバックアップエ
リアを照合し、局データバックアップエリア更新フラグ
がＯＫであり、 (32)加入者データバックアップエリア更新フラグがＯＫ
であれば、 (33)ＭＭとＯＤの局データ部と加入者データ部の内容を
照合し、照合終了すれば（その２）の更新に移る。 (34)照合の結果が一致すればループ処理により(33)に移
るが、不一致であればアドレスにより、局データ変更ロ
ギング情報か、加入者データ変更ロギング情報を検索
し、該当アドレスが変更対象であったか否かを判定す
る。 (35)該当アドレスが変更対象であれば、新データ＝ＭＭ
上の内容か、旧データ＝ＯＤ上の内容か否かを判定し、
一致すればループ処理により(33)に移るが、 (36)不一致であれば保守者通知し、アドレスにより局デ
ータか、加入者データのバックアップエリア更新フラグ
にＮＧを設定する。 (37)該当アドレスが変更対象でなければ、保守者通知
し、アドレスにより局データか、加入者データのバック
アップエリア更新フラグにＮＧを設定する。

【００２２】図７の局データ収集時のフロー実施例（そ
の２）において、 (41)局データ変更ロギング情報が有るか否かを判定し、 (42)有れば検索されなかった局データ変更ロギング情報
が有るか否かを判定し、 (43)検索されなかった局データ変更ロギング情報が有れ
ば保守者通知し、局データバックアップエリア更新フラ
グＮＧを設定する。 (44)局データ変更ロギング情報が無ければ、保守者通知
し、局データバックアップエリア更新フラグＮＧを設定
する。 (45)検索されなかった局データ変更ロギング情報が無け
れば、また局データバックアップエリア更新フラグＮＧ
が設定されれば、加入者データ変更ロギング情報が有る
か否かを判定し、 (46)加入者データ変更ロギング情報が有れば、検索され
なかった加入者データ変更ロギング情報が有るか否かを
判定し、 (47)有れば保守者通知し、局データバックアップエリア
更新フラグＮＧ設定し、 (48)無ければ、加入者データバックアップエリア更新フ
ラグＯＫ／ＮＧ判定し、 (49)ＯＫであれば、局データバックアップエリア更新フ
ラグＯＫ／ＮＧ判定し、 (50)上記(48)と(49)の判定においてＮＧであれば、エラ
ー返送する。 (51)局データバックアップエリア更新フラグＯＫであれ
ば、ＯＤ局データ及び加入者データエリア更新＆照合を
行う。 (52)局データ及び加入者データ変更ロギング情報をクリ
アし、 (53)ＯＫ返送して終了する。 (54)上記(45)の加入者データ変更ロギング情報の判定に
おいて、情報が無ければ加入者データバックアップエリ
ア更新フラグＯＫ／ＮＧ判定し、 (55)ＯＫであれば、局データバックアップエリア更新フ
ラグＯＫ／ＮＧ判定し、 (50)上記(54)と(55)との判定でＮＧであれば、エラー返
送を行う。 (56)上記(55)の判定でＯＫであれば、ＯＤ局データエリ
ア更新＆照合を行い、 (57)局データ変更ロギング情報をクリアし、 (58)ＯＫ返送する。

【００２３】図８の加入者データ収集時のフロー実施例
（その１）において、 (61)局データ変更中か否かを判定し、 (62)非変更中であれば、サービスオーダ（ＳＯＤ）投入
中か否かを判定し、 (63)非投入中であれば、サービスオーダ投入待ち合わせ
指示を行い、 (64)加入者データ変更チェックフラグＯＫとする。上記
(61)の判定で変更中の場合、(62)の判定で投入中の場合
は、（その２）の(79)の処理に移る。 (65)フラグＯＫにより、ＭＭ−ＯＤの加入者データ部の
内容を照合し、照合終了すれば（その２）の更新処理に
移る。 (66)照合の結果が一致すれば、ループ処理により(65)に
戻り、不一致であれば、加入者データ変更ロギング情報
を検索し、該当アドレスが加入者データ変更対象であっ
たか否かを判定し、 (67)対象であれば、新データ＝ＭＭ上の内容＆旧データ
＝ＯＤ上の内容か否かを判定し、 (68)一致すればループ処理により(65)に戻り、不一致で
あれば保守者通知し、加入者データ変更チェックフラグ
ＮＧ設定を行う。 (69)上記(66)の判定で非対象であれば、保守者通知し、
加入者データ変更チェックフラグＮＧ設定を行う。

【００２４】図９の加入者データ収集時のフロー実施例
（その２）において、 (71)加入者データ変更ロギング情報が有るか否かを判定
し、 (72)有れば、検索されなかった加入者データ変更ロギン
グ情報が有るか否かを判定し、 (73)有れば保守者通知し、加入者データ変更チェックフ
ラグＮＧ設定し、 (74)上記(72)の判定結果が無しであれば、加入者データ
変更チェックフラグＯＫ／ＮＧ判定し、 (75)ＯＫであれば、ＯＤ加入者データエリア更新＆照合
を行い、 (76)加入者データ変更ロギング情報をクリアし、 (77)サービスオーダ投入待ち合わせ解除指示を行い、終
了する。 (78)上記(71)の判定結果が無しであれば、加入者データ
変更チェックフラグＯＫ／ＮＧ判定を行い、 (79)ＯＫであれば、ＯＤ加入者データエリア更新処理ス
キップ（正常）し、上記(77)の処理に移る。前記(61)の
判定結果が変更中の場合、前記(62)の判定結果が投入中
の場合も（正常）と見なす。 (80)上記(78)の判定でＮＧであれば、ＯＤ加入者データ
エリア更新処理スキップ（異常）し、前記(74)の判定結
果がＮＧの場合も異常と見なす。

【００２５】図１０のシステムデータ収集時のフロー実
施例（その１）において、 (81)局データ変更中か否かを判定し、 (82)非変更中の場合はサービスオーダ（ＳＯＤ）投入中
か否かを判定し、投入中であれば、また(81)の判定で局
データ変更中の場合は（その２）の(98)に記載されてい
るＯＤ更新スキップ（正常）と見なして終了する。 (83)サービスオーダ非投入中であれば、サービスオーダ
投入待ち合わせ指示を行い、 (84)局データバックアップエリア更新フラグＯＫを確認
し、 (85)加入者データバックアップエリア更新フラグＯＫを
確認し、 (86)その他データバックアップエリア更新フラグＯＫを
確認し、 (87)ＭＭとＯＤの内容を照合し、一致していればループ
照合をアドレス０からｎまで繰り返す。照合終了すれば
（その２）の(92)に移る。 (88)ＭＭとＯＤの内容が不一致であれば、アドレスによ
り局データ変更ロギング情報か、加入者データ変更ロギ
ング情報か、その他データ変更ロギング情報を検索し、
該当アドレス変更対象であったか否かを判定する。 (89)判定の結果変更対象であれば、新データ＝ＭＭ上の
内容＆旧データ＝ＯＤ上の内容か否かを判定し、一致し
ていれば(87)の照合に戻る。 (90)不一致であれば、保守者通知し、アドレスにより局
データか、加入者データか、その他データのバックアッ
プエリア更新フラグにＮＧ設定。 (91)上記(88)の判定において非対象であれば、保守者通
知し、アドレスにより局データか、加入者データか、そ
の他データのバックアップエリア更新フラグにＮＧ設
定。

【００２６】図１１のシステムデータ収集時のフロー実
施例（その２）において、 (92)前記(87)におけるＭＭとＯＤの内容照合終了後、検
索されなかったロギング情報が有るか否かを判定し、有
る場合は保守者通知し、対応する更新フラグにＮＧ設定
をする。 (93)全てのバックアップエリア更新フラグがＯＫか否か
を判定し、 (94)ＯＫであれば、ロギング情報の存在するデータエリ
アのみＯＤ更新実施＆照合を行い、 (95)その後ロギング情報をクリアし、 (96)サービスオーダ投入待ち合わせ解除を指示して終了
する。 (97)上記(93)の判定結果ＯＫでなければ、ＯＤ更新スキ
ップ（異常）と見なす。 (98)前記(81)及び(82)の判定の結果、変更中であり投入
中であれば、ＯＤ更新スキップ（正常）と見なす。

【００２７】

【発明の効果】本発明のデータロギング方式の採用によ
り、従来データに不良があっても動いてしまえば、原因
不明のまま処理ができないが、今回はファイルチェック
毎に判明が可能となる。したがって、不良なバックアッ
プファイルの作成を防止することができる。

【図面の簡単な説明】

【図１】本発明の原理構成図

【図２】従来のバックアップファイル更新処理手順

【図３】局データ変更時のフロー実施例

【図４】加入者データ変更時のフロー実施例

【図５】システムデータ変更時のフロー実施例

【図６】局データ収集時のフロー実施例（その１）

【図７】局データ収集時のフロー実施例（その２）

【図８】加入者データ収集時のフロー実施例（その
１）

【図９】加入者データ収集時のフロー実施例（その
２）

【図１０】システムデータ収集時のフロー実施例（そ
の１）

【図１１】システムデータ収集時のフロー実施例（そ
の２）

【符号の説明】

１運転ファイル２バックアップファイル３ロギングデータ４運転ファイルの書替処理フロー５バックアップファイルの照合フロー６バックアップファイルの更新フロー

───────────────────────────────────────────────────── フロントページの続き (72)発明者井上保神奈川県川崎市中原区上小田中1015番地富士通株式会社内 (72)発明者二井秀樹神奈川県川崎市中原区上小田中1015番地富士通株式会社内 (72)発明者阪本邦裕神奈川県川崎市中原区上小田中1015番地富士通株式会社内 (72)発明者神野公秀東京都千代田区内幸町一丁目１番６号日本電信電話株式会社内 (72)発明者三須健司東京都千代田区内幸町一丁目１番６号日本電信電話株式会社内 (72)発明者佐藤好男東京都千代田区内幸町一丁目１番６号日本電信電話株式会社内

Claims

【特許請求の範囲】

【請求項１】運転ファイルよりバックアップファイル
へのファイル書替方式において、運転ファイルの書替処理は、データ書替が発生した場
合、必ず書替データ（アドレス、旧データ、新データ）
をロギングデータに登録を行った後、メインメモリの運
転ファイルのデータを書き替え、バックアップファイルの照合は、書替アドレスが運転フ
ァイルにあった場合、運転ファイルとバックアップファ
イルとロギングデータのデータ比較チェックを行い、運
転ファイルが新データでバックアップファイルが旧デー
タの場合は正常とし、それ以外は異常とし、書替アドレ
スが無い場合は、運転ファイルとバックアップファイル
とのデータを比較し、データが一致していれば正常と
し、データが不一致であれば異常とし、バックアップファイル更新は、上記照合結果が全アドレ
スで正常であればメインメモリ上の運転ファイルを２次
記憶装置のバックアップファイルへ蓄積し、異常アドレ
スが一つでも有れば保守者通知し、異常原因の解析を行
うことを特徴とするファイル書替方式。
【請求項２】前記データ書替時の処理において、データは局データ、加入者データ、システムデータの各
々について書替処理を行うことを特徴とする請求項１記
載のファイル書替方式。
【請求項３】前記データ収集時の処理において、データは局データ、加入者データ、システムデータの各
々について収集処理を行うことを特徴とする請求項１記
載のファイル書替方式。