JPS6191730A - ソフトウエア障害に対する自動復旧処理システム - Google Patents

Abstract

(57)【要約】本公報は電子出願前の出願データであるた
め要約のデータは記録されません。

Description

【発明の詳細な説明】 発明の目的 産業上の利用分野 本発明は、電子計算機システムの業務処理ジョブにソフ
トウェア障害が発生した時に、オペレーター等の人手を
介さず自動的に復旧処理を行う自動復旧処理方式に関す
る。

従来の技術 従来、電子計算機システムにおけるソフトウェア障害時
の復旧処理の方式は、ソフトウェア障害の原因をサポー
トＳＥ（プログラマ）やオペレータがメモリ・ダンプ、
ファイル・ダンプ、トレース・ダンプ等により得られる
リストから捜し出して１次のようないずれかの方法で処
理するのが一般的である。

すなわち、第１の方法は障害原因の除去と以後の障害を
回避するために、まずプログラム等を修正し、引続き、
更新途中のファイルの復元を行い修正プログラムを起動
し、再処理を行う。

第２の方法は、障害を誘発したデータの削除と更新途中
ファイルの復元を行った後、障害を起こしたプログラム
を再起動して再処理を行うものである。なお、プログラ
ムの修正と削除したデータの処理は、後日、十分な検討
を加えたのちに行われる。

発明が解決しようとする問題点 上記従来のソフトウェア障害復旧処理は、サポートＳＥ
やオペレータが膨大な量のリストから障害原因を探索す
ることを必要としており、探索漏れによる復旧の失敗や
探索に長い時間を要する等のためシステム稼動率が低下
するという問題がある。

また、メモリ・ダンプ、ファイル・ダンプ等によるリス
トは１６進数に変換されて表示されているため、障害原
因の探索を行う者がリストの内容を解釈できる程度の知
識を有する必要があり、このため復旧処理に携われる作
業者が限定されてしまうという問題もある。

発明の構成 問題点を解決するための手段 上記従来技術の問題点を解決する本発明の自動復旧処理
システムは、業務処理ジョブにおけるソフトウェア障害
の発生に対処して、障害誘発データの削除方法、更新フ
ァイルの復元方法及び再起動方法を含む復旧制御情報を
予め格納しておく復旧制御情報ファイルと、業務処理ジ
ョブが発する入出力要求を、ファイル・アクセス通番、
アクセス中の入出力フアイル及びレコード・アドレスを
記録するインタフェース制御情報記録手段によって管理
しつつオペレーティング・システムの入出力マクロ命令
に変換するインタフェース制御手段と、業務処理ジョブ
におけるソフトウェア障害の発生時に、復旧制御情報フ
ァイル及びインタフェース制御情報記録手段を参照して
障害誘発データの削除及び更新ファイルの復元を行うと
共に、復旧制御情報によって指定された方法で業務処理
ジョブを再起動する手段とを備えるように構成されてい
る。

以下１本発明の作用を実施例によって詳細に説明する。

実施例 第１図は１本発明の自動復旧処理システムの構成の一例
を示す機能ブロック図である。

このシステムによって自動復旧処理される業務処理ジョ
ブ１は、この業務処理ジョブ１に人力するデータを格納
する入力ファイル２と、業務処理ジョブ１によって更新
される更新ファイル３と。

業務処理ジョブ１の出力データを格納する出力ファイル
４を使用して業務処理ジョブを実行する。

上記業務処理ジョブ１に対する自動復旧処理システムを
構成するインタフェース制御部１０は。

ファイル・アクセス通番（業務処理ジョブ１が行う入出
力要求の回数）と入出力レコードの格納媒体上のアドレ
ス等を記憶するインタフェース制御情報テーブル１００
ｆｆＷえ、業務処理ジョブ１が行う入出力要求を、イン
タフェース制御情報テーブル１００を参照しつつ一括管
理すると共に、上記入出力要求をオペレーティング・シ
ステム（以下「Ｏ８」と略称する）の入出力マクロ命令
に変換してＯ８に渡す。

２０はジョブ制御部であり、これは、業務処理ジョブ１
のソフトウェア障害発生時に当該業務処理ジョブを自動
復旧するのに必要な復旧制御情報（障害誘発データとし
て削除すべきデータ情報。

更新ファイルの復元方法、業務処理ジョブの再起動方法
等）を記録する復旧制御情報ファイル２００を備え、ソ
フトウェア障害発生時に、復旧制御情報ファイル２００
と上記インタフェース制御情報テーブル１００を参照し
て障害誘発データを決定しかつ復旧後の障害発生業務処
理ジョブの再起動を行う。

３０は、自動運転制御部であり、これは、復旧制御情報
ファイル２００を参照して復旧処理のための資源を確保
しつつ復旧処理要求を行い、かつ復旧完了後の資源の変
更と障害発生業務処理ジョプの再起動要求を行う。

４０と５０はそれぞれデータ削除処理部とファイル復元
処理部であり、これらは、自動運転制御部からの上記復
旧処理要求を受けて、それぞれ障害誘発データの削除と
更新途中ファイルの復元を行う。

ソフトウェア障害発生時の自動復旧処理を可能にするた
め、操作者が業務処理ジョブ実行前にその業務形態に応
じて設定した復旧制御情報を予め記録しておくための復
旧制御情報ファイル２００が備えられる。第２図乃至第
４図は、制御情報ファイル２００に記録される３種の復
旧制御情報を例示している。

第２図はジョブ制御情報２０１の構成の一例を示す概念
図であり、これらは２業務処理ジヨブごとに作成される
。ジョブ制御情報２０１は。

（１）業務処理ジョブ名 （２）当該業務処理ジョブで使用する業務処理プログラ
ム名 （３）障害発生業務処理プログラムを復旧後に再起動す
る際の形態 （４）再起動形態がチェックポイント・リスフートであ
る場合に展開するチェ、ツクポイント情報の格納先 （５）リスフートすべきチェックポイントの番号（６）
ソフトウェア障害が発生した際削除され得るデータの処
理形態　及び （７）データ削除処理形態ごとの情報 を含んでいる。

上記データ削除処理形態（６）は１次の４種類の中から
業務の運用に応じた最適のものが操作者によって業務処
理ジョブの開始前に復旧制御情報ファイル２００に設定
される。

形態１：データ削除を行なわない。

形Ｂ２：最近にアクセスした入力ファイルのレコードを
削除する。

形態３：入力ファイルが複数の場合、現在処理中のレコ
ードの中で、最小のキー値を 持つレコードを探索し、その入力ファ イル中同一キーを持つレコードを削除 する。

形態４：入力ファイルが複数の場合、削除対処ファイル
名と削除キー値を指定してお き、現在処理中レコードの中で削除対 応ファイル名と削除キーを探索し、そ のファイル中、同一キー値を持つレコ ードを削除する。

第３図は、第１図の復旧制御情報ファイル２００内に記
録される使用ファイル情報２０２の構成の一例を示す概
念図である。この使用ファイル情報２０２は、各業務処
理ジョブが使用する全ファイルの管理情報であり。

（１）業務処理ジョブ名 （２）当該業務処理ジョブで使用する使用ファイルの数 （３）上記使用ファイルの内部ファイル名（論理ふ名） （４）上記使用ファイルの外部ファイル名（実ファイル
名） （５）上記使用ファイルが入力ファイル、出力ファイル
または更新ファイルのいずれであるかの区別　及び （６）上記使用ファイル割当てに必要な情報を含んでい
る。なお、上記情報（３）乃至（６）は、使用ファイル
数分繰り返されている。

第４図は、第１図の復旧制御情報ファイル２゜Ｏに記録
されるファイル復元処理情報２０３（１ＭＪＩ！成の一
例を示す概念図であり、これは更新ファイルごとに作成
される。このファイル復元処理情報２０３は。

（１）更新ファイルの外部ファイル名 （２）上記更新ファイルを使用する業務処理ジョブ名 （３）更新ファイルの復元処理形態 （４）更新ファイルの復元を行うファイル復元ジョブ名 （５）ファイル復元ジョブが復元処理を行うための入力
ファイル名 （６）更新ファイルの媒体種類（ディスク、ドラム、テ
ープ等） （７）更新ファイルが二重化ファイルであるか否かの区
別　及び （８）更新ファイル領域の割当てに必要な情報を含んで
いる。

本実施例においては、以下のような４種の更新ファイル
復元処理形態のうちのいずれかが、業務処理ジョブの開
始前に復旧制御情報ファイル２００に設定される。

ａ、予め保存されている保存ファイル５を、障害を起こ
した更新ファイル３に、再ロードする。

ｂ、障害を起こした更新ファイルを、ジャーナル・ファ
イルの更新前情報で塗り直す。

但し、ジャーナル・ファイルは、Ｏ８によって履歴管理
される。

Ｃ９障害を起こした更新ファイルに、保存ファイルをロ
ードし、ジャーナルファイル４に格納されている更新後
情報で塗り直す。

ｄ、ファイル作成処理をやり直す。

第５図は、第１図のインタフェース制御情報テーブル１
００の構成の一例を示す概念図である。

インタフェース制御情報テーブル１００は、インタフェ
ース制御部ｌＯによって、業務処理ジョブごとに作成さ
れる。

これらインタフェース制御情報テーブルは、第５図に示
すように、当該業務処理ジョブが要求した入出力の回数
を記録するインタフェース制御処理制御情報１０１と、
当該業務処理ジョブの各タスクによって入出力されるフ
ァイルの現アクセスポイントを記録するファイル・アク
セス−パラメーター・テーブル（以下ｒＦＡＰテーブル
」と称する”）１０１−１，１０２−２．　　・　・・
１０２−ｎとから構成される。

さらに上記Ｆ　Ａ　Ｐテーブルは、第６図で示すように
、各タスクが使用するファイル毎のファイル・アクセス
−パラメーター情報（以下ｒＦＡＰ情報」と称する）１
０３−１，１０３−２．　　・・・１０３−ｍから構成
される。

第７図は、第５図に示すインタフェース制御処理制御情
報１０１の構成の一例を示す概念図である。このインタ
フェース制御処理制御情報１０１（１）ファイル・アク
セス通番（インタフェース制御部１０が業務処理ジョブ
エの入出力要求に基づいてＯ８に発行するＯ８の入出力
マクロ命令の発行回数であり、ジョブ単位で一連番号が
付される） （２）業務処理ジョブ１の実行中のタスク数（＝ＦＡＰ
テーブル数）　及び （３）実行中の各タスクが使用するファイルを管理する
ＦＡＰテーブルのアドレス・リスト（先頭番地のリスト
） を含んでいる。上記アドレス・リストは、タスクの数だ
け繰り返される。

第８図は、第６図に示すＦＡＰテーブル１０２を管理す
るＦＡＰ情報１０３の構成の一例を示す概念図である。

このＦＡＰ情報１０３は。

（１）タスク（業務処理プログラム）が使用するファイ
ルの内部ファイル名 （２）上記ファイルの外部ファイル名 （３）現在処理中（最新アクセス）レコードのバッファ
内格納位置 （４）現在処理中の格納媒体上のレコードアドレス　及
び （５）ファイル・アクセス通番 第９図は、第１図に示すインタフェース制御部１０によ
るインタフェース制御処理の一例を示すフローチャート
である。

インタフェース制御部１０は、業務処理ジョブ１からの
入出力要求を受は付けると、インタフェース制御処理を
開始する。インタフェース制御部１０は、まずステップ
１１において業務処理ジョブ１からの入出力要求のパラ
メーターの適否を判定し、不適の場合はステップ１８に
おいてエラーコードをセットし、業務処理ジョブ１に戻
る。パラメーターが正しいときは、ステップ１２に進み
。

ここで上記入出力要求に対応するＯＳの入出力マクロ命
令を発行する。

インタフェース制御部１０は１次のステップ１３におい
て、Ｏ８に対する入出力マクロ命令発行後にＯ８から戻
されるリターンコードが正常か否かを判定する。リター
ンコードが正常でない（入出力に失敗した）場合は、ス
テップ１８に進みエラーコードをセットして業務処理ジ
ョブ１に戻る。

リターンコードが正常（入出力が完了した）の場合、イ
ンタフェース制御部１０は、ステップ１４と１５におい
て、ＦＡＰ情報１０３にそれぞれレコード格納位置（３
）とレコードアドレス（４）を記録する。次に、インタ
フェース制御部１０は。

ステップ１６において、ファイル・アクセス通番をカウ
ントアツプする。インタフェース制御部ｌＯは２次のス
テップ１７において、カウントアツプしたファイル・ア
クセス通番をＦＡＰ情報１０３の（５）とインタフェー
ス制御処理制御情報１０１の（１）に記録し、インタフ
ェース制御処理を終了する。

第１０図は、第１図のシステムにおいて、業務処理ジョ
ブ１に障害が発生した場合に、この障害発生業務処理ジ
ョブが再起動されるまでの処理の全体を示すフローチャ
ートである。

■、削除データ決定処理 ジョブ制御部２０の削除データ決定部２１は。

業務処理ジョブに障害が発生すると、上述した復旧制御
情報ファイル２００とインタフェース制御情報テーブル
１００内の情報を参照して。

削除データの決定処理を行う。

■、復旧処理の起動処理 ジョブ制御部２０から復旧処理要求を受けた自動運転制
御部３０の復旧処理要求部３１は。

データの削除とファイルの復元に必要な資源の確保等復
旧処理の起動に必要な前処理を行う。

■、データ削除処理及び■、ファイル復元処理データ削
除処理部４０とファイル復元処理部５０のそれぞれは９
自動運転制御部３０からの、起動によってデータ削除処
理とファイル復元処理を行う。

■、再起動要求処理 自動運転制御部３０の再起動要求部３２は。

データ削除処理とファイル復元処理の終了の通知を受け
ると、業務処理ジョブ１の再起動に必要な資源の確保等
の処理を行う。

■、再起動処理 ジョブ制御部２０の再起動部２２は、自動運転制御部３
０の再起動要求部３２から再起動指令を受けると、復旧
制御情報ファイル２００を参照し、指定された形態で業
務処理ジョブ１を再起動する。

以下、第１０図の処理の流れに従って、各部のフローチ
ャートを用い詳細に説明する。

１、削除データ決定処理 第１１図は、ジョブ制御部２０の削除データ決定部２１
における。ソフトウェア障害発生時の削除データ決定処
理の一例を示すフローチャートである。

削除データ決定部２１は、業務処理プログラムによる異
常終了の通知、または業務処理プログラム例外を起こし
た場合のＯ８によるプログラム例外の通知を受けると、
削除データ決定処理を開始する。

削除データ決定部２１は、削除データ決定処理を開始す
ると、まずステップ２１０において、対応の業務処理プ
ログラムに関する通知内容を解析し、ソフトウェア障害
（論理矛盾プログラム例外）かどうかをチェックする。

通知内容がソフトウェア障害の場合、ステップ２１１に
進み、この業務処理ジョブ内の他の業務処理プログラム
を全て強制終了させる。

削除データ決定部２１は９次のステップ２１２において
、復旧制御情報ファイル２００のジョブ制御情報２０１
からデータ削除処理形態情報（６）を読出し、削除デー
タの有無（形態１であるかどうか）を検査する。削除デ
ータがない場合（形態１の場合）には、復旧処理を行な
うことなくステップ２１５に進む。削除データ決定部２
１は、ステップ２１２において、削除データが存在する
こと（形態２．３または４のいずれかの場合）を判定す
ると、ステップ２１３へ進み、ここで、以下の処理を行
う。

（イ）データ削除処理形態２　（最新アクセス入力ファ
イル内の最新アクセスレコードを削除する）の場合： 削除データ決定部２１は、インタフェース制御処理制御
情報１０１とＦＡＰ情報１０３及び使用ファイル情報２
０２を参照して最新アクセス入力ファイルとその最新ア
クセスレコードを決定し。

以下の情報を削除データ情報として取得する。

（１）外部ファイル名（実ファイル名）（２）該当レコ
ードの媒体上のレコード・アドレス（例えばディスクの
場合、シリンダ・アドレス、トラック・アドレス、ブロ
ック内相対バイト位置等） （３）ジョブ名 （４）データ削除処理形態 （ロ）データ処理形態３　（最小キー値を持つ入力レコ
ードを削除する）の場合　： 削除データ決定部２１は、ジョブ制御情報２０１と使用
ファイル情報２０２及びＦＡＰ情報１０３を参照し、複
数の入力ファイルの現在処理中のレコードの中で最小キ
ー値を持つ入力レコードを決定し、上記（イ）の場合と
同様の（１）乃至（４）から成る削除データ情報を取得
する。

（ハ）データ削除処理形態４　（指定ファイルの指定キ
ー値を持つ入力ファイルのレコードを削除する）の場合
： 削除データ決定部２１は、ジョブ制御情報２０１と使用
ファイル情報２０２及びＦＡＰ情報１０３を参照し、■
または複数の削除対象ファイルの現在処理中レコードの
中で指定キー値を持つレコードを決定し、情報（イ）と
（ロ）の場合と同様の（１）乃至（４）から成る削除デ
ータ情報を取得する。

但し、指定キー値を持つレコードがない場合。

自動再処理対象外ジョブとして、当該業務処理ジョブを
異常終了させる。

削除データ決定部２１は、上述のようにして削除データ
を決定すると１次のステップ２１４において、決定した
削除データ情報を付して、自動運転制御部３０の復旧起
動部３１に復旧処理の起動を要求する。

更に、削除データ決定部２１は、ステップ２１５におい
て、ソフトウェア障害を生じた業務処理プログラムを含
む全業務処理ジョブを異常終了させ、削除データ決定処
理を全て終了する。

■、復旧処理の起動処理 第１２図は、自動運転制御部３０内の復旧処理起動部３
１の動作の一例を示すフローチャートである。

復旧処理起動部３１は、ジョブ制御部２０の削除データ
決定部２１からの復旧処理要求を受は付けると、復旧処
理の起動処理を開始する。すなわち、復旧処理起動部３
１は、まずステップ３１０において、削除データ決定部
２１から渡された削除データ情報と復旧制御情報ファイ
ル２００内のファイル復元処理情報２０３とに基づき、
データ削除処理に必要な資源を確保する。次に、復旧処
理起動部３１は、ステップ３１において、前述の削除デ
ータ情報を付加して、データ削除処理部４０にデータ削
除処理を要求する。

また、復旧処理起動部３１は、ステップ３１２において
、使用ファイル情報２０２とファイル復元処理情報２０
３とを参照して、復元を必要とする１または複数の更新
ファイルを決定する。

次に、復旧処理起動部３１は、ステップ３１３ニオいて
、復元すべき更新ファイルの一つについて、ファイル復
元処理に必要な資源を確保した後。

ステップ３１４において、ファイル復元に関する情報を
付してファイル復元処理部５０にファイル復元処理を要
求する。

復旧処理起動部３１は、ステップ３１５において、復元
すべき更新ファイルの全てについて、ファイル復元処理
要求の発行が終了したか否かを判定し、未終了であれば
、ステップ３１３に戻り。

次の更新ファイルについて上述の処理を繰り返す。

■、データ削除処理 第１３図は、データ削除処理部４０におけるデータ削除
処理の一例を示すフローチャートである。

データ削除処理部４０は、復旧処理起動部３１からのデ
ータ削除処理要求を受は付けると、データ削除処理を開
始する。

データ削除処理部４０は、ステップ４１と４２において
、復旧処理要求部３１から受けた削除デ−タ情報Ｇこ従
って、入力ファイル内の全ての該当データに削除フラグ
をセットすることにより該当のデータを全て削除する。

■、ファイル復元処理 第１４図は、ファイル復元処理部５０における更新ファ
イル復元処理の一例を示すフローチャートである。

ファイル復元処理部５０は、復旧処理起動部３１からフ
ァイル復元要求を受は付けると、ファイル復元処理を開
始する。

ファイル復元処理５０は、ステップ５１において、復旧
処理起動部３１から受けただファイル復元処理形態情報
（第４図の（３））に従い、第４図のファイル復元処理
情報２０３に関して既に説明したａ乃至ｄのいずれかの
形態によって、障害を起こした更新ファイルの復元処理
を行う。

■、再起動要求処理 第１５図は、自動運転制御部３０の再起動要求部３２の
動作の一例を示すフローチャートである。

再起動要求部３２は、データ削除処理部４０とファイル
復元処理部５０から処理終了の通知を受けると、再起動
要求処理を開始する。再起動要求部３２は、ステップ３
２０において、データ削除処理とファイル復元処理の終
了に伴う使用資源の変更を行い２次のステップ３２１に
おいて、ソフトウェア障害を起こした業務処理ジョブの
再起動を、ジョブ制御部２０の再起動部２２に要求する
。

■、再起動処理 第１６図は、ジョブ制御部２０の再起動部２２による。

障害発生業務処理ジョブの再起動処理の一例を示すフロ
ーチャートである。

再起動部２２は、自動運転制御部３０の再起動要求部３
２から再起動処理要求を受は付けると。

再起動処理を開始する。すなわち、再起動部２２は、ま
ずステップ２２０において、ジョブ制御情報２０１を参
照して当該業務処理ジョブのジョブ再処理形Ｂ（３）を
判定する。この再処理形態が。

チェックポイント・リスタートでなくて再ランであれば
、ステップ２２１において当該業務処理ジョブを通常処
理として再起動する。

再起動部２２は、再処理形態がチェックポイントリスク
ートであれば、ステップ２２２に進み。

復旧制御情報ファイル２００内のジョブ制御情報２０１
のチェックポイント情報格納域名（４）とチェックポイ
ント通番（５）を得て展開する。

次に、再起動部２２は、ステップ２２３において、該当
業務処理ジョブを該当チェックポイント時点から再開す
る。

このようにして、ソフトウェア障害時の自動復旧処理が
全て終了する。

データ削除処理形態１の場合や、データ削除処理形態４
の場合において該当レコードが存在しないときに異常終
了した業務処理ジョブについては。

操作者が適宜な方法でその障害原因の解明と除去を行っ
たのちに、操作者が再起動する。

自動運転制御部３０．データ削除処理部４０゜ファイル
復元処理部５０はジョブ形式であってもよい。

発明の効果 以上詳細に説明したように１本発明の自動復旧処理シス
テムは、業務処理ジョブにおけるソフトウェア障害の発
生に対処して、業務処理形態に適した復旧制御情報を予
め設定しておくと共に、業務処理ジョブのファイル使用
状況をインタフェース制御部で管理することにより削除
データを自動的に決定する構成であるから、障害発明に
対する復旧処理を自動的に行うことが可能になる。

このため、従来例におけるようにサポートＳＥやオペレ
ータが膨大な量のリストから障害原因を探索する必要が
なくなり、探索漏れによる復旧の失敗や探索に長い時間
を要するという問題がなくなり、システム稼動率が大幅
に向上すると共に。

オペレータの負荷を軽減することができる。

【図面の簡単な説明】

第１図は本発明の一実施例の構成を示す機能ブロック図
、第２図乃至第４図は第１図の制御情報ファイル２００
内の各種制御情報の構成の一例を示す概念図、第５図乃
至８図は第１図のインタフェース制御情報テーブル１０
０内の各種情報の構成の一例を示す概念図、第９図は第
１図のインクフェース制御部１０の動作の一例を説明す
るフローチャート、第１０図は第１図の全システムの動
作の一例を示すフローチャート、第１１図は第１図の削
除データ決定ブロック２１の動作の一例を説明するだめ
のフローチャート、第１２図は第１図の復旧処理起動部
３１の動作−例を説明するためのフローチャート第１３
図は第１図のデータ削除処理部４０の動作の一例を説明
するためのフローチャート、第１４図は第１図のファイ
ル復元処理部５０の動作の一例を説明するためのフロー
チャート、第１５図は第１図の再起動要求部３２の動作
の一例を説明するためのフローチャート第１６図は第１
図乃再起動部２２の動作の一例を説明するためのフロー
チャートである。 １０・・インタフェース制御部、２０・・ジョブ制御部
、３０・・自動運転制御部、４０・・データ削除処理部
、５０・・ファイル復元処理部。 １００・・インタフェース制御情報テーブル、２００・
・復旧制御情報ファイル。 特許出願人　　日本電気株式会社 代　理　人　　弁理士　櫻井俊彦 第２図 第３図 第４図 第５図 第７図 第８図 第９図 第１０図 再起動 第１１図 第１２図 第１３囚 第１４図

Claims (1)

1. 【特許請求の範囲】 業務処理ジョブにおけるソフトウェア障害の発生に対処
   して、障害誘発データの削除方法、更新ファイルの復元
   方法及び再起動方法を含む復旧制御情報を予め格納して
   おく復旧制御情報ファイルと、 前記業務処理ジョブが発する入出力要求を、ファイル・
   アクセス通番、アクセス中の入出力ファイル及びレコー
   ド・アドレスを記録するインタフェース制御情報記録手
   段によって管理しつつ、オペレーティング・システムの
   入出力マクロ命令に変換するインタフェース制御手段と
   、 業務処理ジョブにおけるソフトウェア障害の発生時に、
   前記復旧制御情報ファイル及びインタフェース制御情報
   記録手段を参照して障害誘発データの削除及び更新ファ
   イルの復元を行うと共に、前記復旧制御情報によって指
   定された方法で該業務処理ジョブを再起動する手段とを
   備えたことを特徴とするソフトウェア障害に対する自動
   復旧処理システム。