JP3953808B2 - Reprocessing multiple recovery program, reprocessing multiple recovery device, and reprocessing multiple recovery method - Google Patents

Description

【００３８】
以上のように、図２の（ａ）のログ情報ファイル１３を末尾から順に辿って本発明に係わる再処理すべきジョブ（リランジョブ）および入力ファイルが削除されているときはカウンタ値を＋１した後のカウンタ値を設定することを繰り返し図示のリランジョブテーブルを作成することが可能となる。そして、リランジョブテーブル中のカウンタ値が０のジョブ（ここでは、Ｂ−ジョブ、Ａ−ジョブ）を同時に多重実行させ、いずれかのジョブの処理終了したときに当該ジョブが出力したファイルを入力とするジョブのカウンタ値を１減算してテーブルに設定し、カウンタ値が０のジョブを起動することを繰り返し、ジョブを多重実行させ、迅速に復旧することが可能となる（図７および図８を用いて後述する）。以下説明する。
【００３９】
図４は、本発明の説明図（抽出、その１）を示す。
図４の（ａ）は、ジョブおよび入力ファイル、出力ファイルの例を示す。ここで、ｅジョブがファイルＣ，Ｅからデータをそれぞれ読み込みつつ処理実行中に何らかの原因で当該ファイルＣ，Ｅを格納したボリュームに障害発生したとする。この障害発生時には、図４の（ｂ）に示すようにログ情報が採取され、▲１▼書き込み済みジョブ先頭ジョブブロックおよび▲２▼書き込み先ブロックは、それぞれ図示の位置に設定されている。
【００４０】
次に、図４の（ｂ）のログ情報ファイル１３をもとに、図３の（ｂ）のリランジョブテーブルを作成する手順を、図５および図６を用いて順次詳細に説明する。
【００４１】
図５および図６は、本発明の説明図を示す。
図５において、Ｓ１：障害通知された情報をもとに復旧ファイル情報を抽出する。これは、図４の（ａ）のｅジョブがファイルＣ，Ｅからデータを読み出して処理を行っている途中で当該ファイルＣ，Ｅのあるボリュームに障害発生したという通知をもとに、復旧すべきここではファイルＣ，Ｅとして抽出し、図５の右側に記載したように、復旧ファイルテーブルに当該フィルＣ，Ｅを設定する。
【００４２】
Ｓ２：ログ情報ファイルの▲１▼から読み込む。これは、既述した図４の（ｂ）のログ情報ファイル１３の▲１▼書き込み済みジョブ先頭ブロックの位置のｃジョブのログ情報を読み込む。
【００４３】
Ｓ３：ジョブは復旧ファイルを出力しているかチェックする。ここでは、Ｓ２で読み込んだｃジョブが、Ｓ１で復旧ファイルテーブルに設定したファイルＣ，Ｅを出力しているかチェックする。ここでは、ｃジョブはファイルＣを出力していると判明する。
【００４４】
Ｓ４：出力しているか判別する。ここでは、Ｓ３でｃジョブがファイルＣを出力しているので、ＹＥＳとなり、Ｓ５に進む。もし、出力していなければ、Ｓ５からＳ７をスキップし、Ｓ８に進む。
【００４５】
Ｓ５：リランジョブテーブルにジョブを登録する（ｃジョブ）。復旧ファイルテーブルの当該ファイルに抽出済みを設定する（ファイルＣ）。これにより、図５の右側に記載した復旧ファイルテーブルとリランジョブテーブルのうちの、
・復旧ファイルテーブル中のファイルＣに抽出済みが設定され、
・リランジョブテーブル中に、ｃジョブ（入力カウンタ０） 未実行が設定される。ここで、抽出済みは復旧するジョブがあるという意味を表す。また、入力カウンタ０は初期値であり、未実行は当該ｃジョブが再処理すべきジョブであって、未実行を表す。
【００４６】
Ｓ６：登録したリランジョブの入力ファイル状況をファイル管理から検索する。削除済み、障害の場合、復旧ファイルテーブルにファイルを登録する。リランジョブテーブルに対応関係を設定する。ここでは、ファイルＢは削除済みのため登録する）。これらにより、右側に記載した復旧ファイルテーブルとリランジョブテーブルのうちの、
・ファイルＢを設定、および図５のＳ６の右側の復旧ファイルテーブルとリランジョブテーブル中の矢印のように関係を設定する（ここでは、ｃジョブがファイルＢからデータを読み込み、結果をファイルＣに出力することを図示の矢印で表記する）。
【００４７】
Ｓ７：リランジョブの入力カウンタ（入力ファイルカウンタ）を設定する（ｃジョブは１を設定する）。これは、ｃジョブがデータを読み込むファイルＢは、削除されてないので、現在の入力カウンタ０に＋１した値１を、入力カウンタ１として図示のように設定する。
【００４８】
Ｓ８：復旧ファイルテーブルは全抽出済みか判別する。ここでは、ＮＯであるので、Ｓ９に進む。一方、ＹＥＳの場合には、次のステップ（図８）に進む。
【００４９】
Ｓ９：ログ情報ファイルを１つ辿る。これは、図４の▲１▼から１つ前のブロックに辿る。
【００５０】
同様に、Ｓ１３からＳ１９、Ｓ２３からＳ２９、Ｓ３３からＳ３８についても、Ｓ３からＳ９と同じようにして、図４の（ｂ）の▲３▼のｄジョブ、▲４▼のｂジョブ、▲５▼のａジョブについても繰り返すことにより、それぞれの右側に記載したように、復旧ファイルテーブル、リランジョブテーブルに図示のように設定され、矢印で示すように各ジョブの入力ファイルおよび出力ファイルの関係を設定して抽出し、図６の右下の結果が得られる。
【００５１】
以上によって、図４の（ｂ）のログ情報ファイル１３から図６の右下の▲６▼の復旧ファイルテーブルおよびリランジョブテーブルに設定したように抽出することが可能となる。次に、▲６▼の復旧ファイルテーブルおよびリランジョブテーブルをもとに、入力カウンタ（カウンタ値）が同一ジョブを並列に多重実行させるときの手順について、図７および図８を用いて詳細に説明する。
【００５２】
図７および図８は、本発明の説明図（リトライ）を示す。これら図７および図８は、リランジョブを実行して復旧するときのフローを示す。
【００５３】
図７において、Ｓ４１：リランジョブテーブルの入力カウンタが０のジョブを実行依頼する。ジョブ状況を実行中とする（ａジョブ、ｂジョブ）。これは、右側に記載した▲６▼のリランジョブテーブル（既述した図６の右下の▲６▼と同一）中の入力カウンタ０である、ここでは、ａジョブ、ｂジョブを取り出し、並列に多重実行依頼し、リランジョブテーブルのａジョブ，ｂジョブの欄の未実行を図示のように実行中にそれぞれ設定する。
【００５４】
Ｓ４２：ａジョブ実行完了し、ジョブ正常終了通知受信したので、実行済みにする（ａジョブ）。これにより、右側のリランジョブテーブル中のａジョブの実行中が実行済に設定される。
【００５５】
Ｓ４３：全リランジョブは実行済みか判別する。ここでは、ｂジョブなどが実行完了していないので、Ｓ４４に進む。一方、ＹＥＳの場合には、復旧完了とする。
【００５６】
Ｓ４４：リランジョブの出力ファイルを入力しているジョブの入力カウンタを減算する（ファイルＢを入力しているｃジョブのカウンタを１減算する）。これは、Ｓ４２でａジョブが処理完了し、当該ａジョブが処理結果をファイルＢに格納したので、当該ファイルＢを入力している、ここでは、ｃジョブの入力カウンタの値を１減算し入力カウンタ１を入力カウンタ０に図示のように設定する。
【００５７】
Ｓ４５：入力カウンタが０になったらリランジョブ実行依頼する。実行中とする（ｃジョブを実行依頼し、実行中とする）。これにより、右側に記載したように、リランジョブテーブルの当該ｃジョブが実行中に設定される。
【００５８】
図８のＳ４６：ｂジョブ実行完了し、ジョブ正常終了通知受信したので、実行済みにする（ｂジョブ）。これにより、右側のリランジョブテーブル中のｂジョブが実行中から実行済に設定される。
【００５９】
Ｓ４７：全リランジョブは実行済みか判別する。ここでは、まだ全ジョブが実行完了していないので、Ｓ４８に進む。一方、ＹＥＳの場合には、復旧完了とする。
【００６０】
Ｓ５４：リランジョブの出力ファイルを入力しているジョブの入力カウンタを減算する（ファイルＤを入力しているｄジョブのカウンタを１減算する）。これは、Ｓ４６でｂジョブが処理完了し、当該ｂジョブが処理結果をファイルＤに格納したので、当該ファイルＤを入力している、ここでは、ｄジョブの入力カウンタの値を１減算し入力カウンタ１を入力カウンタ０に図示のように設定する。
【００６１】
Ｓ５５：入力カウンタが０になったらリランジョブ実行依頼する。実行中とする（ｄジョブを実行依頼し、実行中とする）。これにより、右側に記載したように、リランジョブテーブルの当該ｄジョブが実行中に設定される。
【００６２】
Ｓ５６：ｃジョブ実行完了し、ジョブ正常終了通知受信したので、実行済みにする（ｃジョブ）。これにより、右側のリランジョブテーブル中のｃジョブが実行中から実行済に設定される。
【００６３】
Ｓ５７：全リランジョブは実行済みか判別する。ここでは、まだ全ジョブが実行完了していないので、Ｓ６４に進む。一方、ＹＥＳの場合には、復旧完了とする。
【００６４】
Ｓ６４：リランジョブの出力ファイルを入力しているジョブの入力カウンタを減算する（ファイルＣを入力しているジョブはないので何もしない）。これは、Ｓ５６でｃジョブが処理完了し、当該ｃジョブが処理結果をファイルＣに格納したが、当該ファイルＣを入力しているジョブがない（ログファイル中にない）ので、何もしない。
【００６５】
Ｓ６５：入力カウンタが０になったらリランジョブ実行依頼する（ここでは、何もないので、スルーする）。
【００６６】
Ｓ６６：ｄジョブ実行完了し、ジョブ正常終了通知受信したので、実行済みにする（ｄジョブ）。これにより、右側のリランジョブテーブル中のｄジョブが実行中から実行済に設定される。
【００６７】
Ｓ６７：全リランジョブは実行済みか判別する。ここでは、全ジョブが実行完了したので、復旧完了となる。一方、ＮＯの場合には、同様に繰り返す。
【００６８】
以上によって、ログ情報ファイルから自動抽出して作成した図６の右下の▲１▼のリランジョブテーブルおよび復旧ファイルテーブルをもとに入力カウンタが同一のジョブを多重実行させることで、リトライ処理を高速に実行して復旧を迅速に図ることが可能となる。
【００６９】
（付記１）
再処理を多重実行して復旧する再処理多重復旧プログラムであって、
実行したジョブの名前および当該ジョブが読み込んだ入力ファイルの名前と出力した出力ファイルの名前の履歴を記録したログ情報を読み出す手段と、
障害発生時に、上記ログ情報を当該障害発生時から遡って実行したジョブ、当該ジョブが出力したファイル、および当該ファイルが記憶装置上に存在しないときに当該ファイルを入力とするジョブのカウンタ値を増加してテーブルに設定して再処理するジョブを抽出する手段と
してコンピュータに機能させるための再処理多重復旧プログラム。
【００７０】
（付記２）
上記テーブル中の上記カウンタ値をもとにジョブが実行する多重度を検出する手段と
してコンピュータに機能させるための付記１記載の再処理多重復旧プログラム。
【００７１】
（付記３）
上記テーブルに設定されたカウンタ値が初期値のジョブを並列に多重実行させて当該多重実行させたいずれかのジョブがリトライ終了したときに、当該リトライ終了したジョブが出力したファイルを入力とするジョブのカウント値を減算して上記テーブルに設定し、繰り返す手段と
してコンピュータに機能させるための付記１記載の再処理多重復旧プログラム。
【００７２】
（付記４）
再処理を多重実行して復旧する再処理多重復旧装置であって、
実行したジョブの名前および当該ジョブが読み込んだ入力ファイルの名前と出力した出力ファイルの名前の履歴を記録したログ情報を読み出す手段と、
障害発生時に、上記ログ情報を当該障害発生時から遡って実行したジョブ、当該ジョブが出力したファイル、および当該ファイルが記憶装置上に存在しないときに当該ファイルを入力とするジョブのカウンタ値を増加してテーブルに設定して抽出する手段と
を備えたことを特徴とする再処理多重復旧装置。
【００７３】
（付記５）
再処理を多重実行して復旧する再処理多重復旧方法であって、
実行したジョブの名前および当該ジョブが読み込んだ入力ファイルの名前と出力した出力ファイルの名前の履歴を記録したログ情報を読み出すステップと、
障害発生時に、上記ログ情報を当該障害発生時から遡って実行したジョブ、当該ジョブが出力したファイル、および当該ファイルが記憶装置上に存在しないときに当該ファイルを入力とするジョブのカウンタ値を増加してテーブルに設定して再処理するジョブを抽出するステップと
を有する再処理多重復旧方法。
【００７４】
（付記６）
実行したジョブの名前および当該ジョブが読み込んだ入力ファイルの名前と出力した出力ファイルの名前の履歴を記録したログ情報を読み出す手段と、
障害発生時に、上記ログ情報を当該障害発生時から遡って実行したジョブ、当該ジョブが出力したファイル、および当該ファイルが記憶装置上に存在しないときに当該ファイルを入力とするジョブのカウンタ値を増加してテーブルに設定して抽出する手段と
して機能させるプログラムを記録したコンピュータ読取可能な記録媒体。
【００７５】
【発明の効果】
以上説明したように、本発明によれば、障害発生時にジョブ実行したときに取得しておいたログ情報をもとにリトライするジョブおよび入力ファイルのカウント値をテーブルにそれぞれ設定し、リトライ時にカウント値をもとにジョブを多重実行する構成を採用しているため、ログ情報をもとにジョブを多重実行して迅速に復旧を図ることが可能となる。また、ジョブ実行時に保存するログ情報や資源を変更することなく、本願発明によりリトライ時にジョブを多重実行でき、機能追加を容易に実現できる。
【図面の簡単な説明】
【図１】本発明のシステム構成図である。
【図２】本発明の説明図（ログ情報）である。
【図３】本発明の説明図である。
【図４】本発明の説明図（その１）である。
【図５】本発明の説明図（抽出、その１）である。
【図６】本発明の説明図（抽出、その２）である。
【図７】本発明の説明図（リトライ、その１）である。
【図８】本発明の説明図（リトライ、その２）である。
【符号の説明】
１１：障害管理手段
１２：ログ取得手段
１３：ログ情報ファイル
２１：再処理復旧処理手段
２２：リランジョブ抽出手段
２３：リランジョブ実行手段[0001]
BACKGROUND OF THE INVENTION
The present invention relates to a reprocessing multiple recovery program, a reprocessing multiple recovery device, and a reprocessing multiple recovery method that perform recovery by multiple execution of reprocessing.
[0002]
[Prior art]
Conventionally, when a job is sequentially started and each job reads data from a file, processes it, outputs it to a file, and performs a predetermined job, DASD (Direct Access Storage Device, magnetic disk device, etc.) that stores the file ) The log (history) of each job and its start time, read file, written file, etc. is saved as log information in time series order in case the file stored in) fails and cannot be read. . When a failure occurs, the job to be retried and the file to be recreated are extracted and stored until there are no jobs to be retried and files to be recreated in order from the end of the log information. Sequentially retrying the creation of each job and its file to recover.
[0003]
[Problems to be solved by the invention]
For this reason, the above-described method has a problem that it is necessary to proceed with processing while re-executing each job sequentially and re-creating each file at the time of retry, and much time is required until recovery. .
[0004]
For this reason, it is desired that multiple jobs are executed at the time of retry to recover quickly.
[0005]
In order to solve these problems, the present invention sets the count value of the job and the input file to be retried based on the log information acquired when the job is executed when a failure occurs in the table, and counts at the time of the retry. The purpose is to execute multiple jobs based on the values and quickly recover them.
[0006]
[Means for Solving the Problems]
Means for solving the problem will be described with reference to FIG.
[0007]
In FIG. 1, the log acquisition unit 12 acquires logs such as executed jobs, input files, and output files, and creates a log information file 13.
[0008]
The rerun job extracting unit 22 analyzes the log information file 13 and sets a job to be reprocessed and a counter value in a table.
[0009]
The rerun job execution unit 23 executes multiple jobs of the same counter value set in the table at the same time.
[0010]
Next, the operation will be described.
The job name of the job executed by the log acquisition unit 12, the file name of the input file read by the job and the history of the output file name are acquired in the log information file, and the rerun job extraction unit 22 stores the log information file 13. Log information for jobs that have been executed retroactively from the time of the failure, the file that the job output, and the job that receives the file when the file does not exist on the storage device are incremented and set in the table. Is repeated to detect the multiplicity of the job.
[0011]
At this time, the multiplicity executed by the job is detected based on the counter value in the table.
[0012]
In addition, when a job whose counter value set in the table is the initial value is multiple-executed in parallel, and any of the multiple-executed jobs finishes retrying, the job input using the file output by the job that has finished retrying The count value is subtracted, set in the table, and repeated.
[0013]
Therefore, the job and input file count values to be retried are set in the table based on the log information acquired when the job was executed when a failure occurred, and multiple jobs are executed based on the count value at the time of retry. As a result, it is possible to quickly recover jobs by executing multiple jobs based on log information.
[0014]
DETAILED DESCRIPTION OF THE INVENTION
Next, embodiments and operations of the present invention will be described in detail sequentially with reference to FIGS.
[0015]
FIG. 1 shows a system configuration diagram of the present invention. Here, each means described below functions by loading a program on a memory, starting the program, and executing various processes. Further, a program functioning as these means is stored in an external storage medium and provided to a customer.
[0016]
In FIG. 1, an execution management unit 1 executes a job according to a schedule set in a schedule file 2.
[0017]
The schedule file 2 is a file in which a job execution schedule is set.
[0018]
The initiator 3 assigns and executes the resources defined in the resource definition file 5 for the job (batch job 4) instructed from the execution management means 1.
[0019]
The batch job 4 is a job that the execution management unit 1 has taken out from the schedule file 2 and requested execution to the initiator 3.
[0020]
The resource definition file 5 defines various resources used by the job.
The resource management means 6 manages various resources, and in this case, manages the actual file 7 and the file management file 8 on the disk device.
[0021]
The execution file 7 is a file from which data is read or stored when a job is executed.
[0022]
The file management file 8 sets and manages various types of information related to the execution file 7.
[0023]
The fault management unit 11 manages faults. Here, the fault management unit 11 collects a log executed by a job (batch job 4), and includes a log acquisition unit 12 and the like.
[0024]
The log acquisition unit 12 acquires a log executed by the batch job 4 and creates a log information file 13.
[0025]
The log information file 13 is a collection of collected job names, input file names, output file names, and the like.
[0026]
The reprocessing / recovery processing unit 21 performs recovery and recovers, and here, includes a rerun job extraction unit 22 and a rerun job execution unit 23.
[0027]
The rerun job extraction unit 22 traces from the end of the log information file 13 when a failure occurs, and increments the counter value of the job to be reprocessed, the file output by the job, and the job when the file does not exist on the storage device Thus, the setting in the table is repeated to extract the job and the counter value (to be described later with reference to FIGS. 2 to 8).
[0028]
The rerun job execution means 23 retries by executing multiple jobs with the same counter value in the table in parallel (to be described later with reference to FIGS. 2 to 8).
[0029]
Next, the operation of the configuration of FIG. 1 will be sequentially described in detail with reference to FIGS.
FIG. 2 is an explanatory diagram (log information) of the present invention.
[0030]
FIG. 2A shows an example of log information. This is a log obtained by acquiring the log of the job executed by the log acquisition means 12 of FIG. 1 described above, and is generated by registering the following information shown in FIG. It is. Items that have not finished job execution have not been collected.
[0031]
-Job name:
·Start time:
・ End time:
・ Resource usage information:
-Input file name:
-Output file name:
・ Other:
Here, the job name is the name of the job that has completed execution, the start time is the time when the job was started, the end time is the time when the job ended normally, and the input file name in the used resource information is the data The output file name is the name of the file that outputs (stores) the result of the job processing.
[0032]
FIG. 2B schematically shows job names when the log information of FIG. 2A is acquired, and job net configurations of input files and output files.
[0033]
2A and 2B, for example, the A-job starts processing at 13:50 (13:50), reads data from file A, stores the processing result in file B, and 14: The process ends at 30. Similarly, as schematically shown in FIG. 2B, the D-job from the B-job reads data from the corresponding file, stores the processing result in the corresponding file, and ends the processing.
[0034]
In the example of FIG. 2 described above, analysis of log information when multiple executions are performed in parallel in the case of a retry in the present invention (extraction of reprocessing jobs and counter values are extracted from the log information of FIG. 2A and set in a table) ) And multiple execution (multiple execution for jobs having the same counter value with reference to the table) will be sequentially described in detail with reference to FIGS.
[0035]
FIG. 3 is an explanatory diagram of the present invention.
FIG. 3A shows an example (substantially the same as FIG. 2B) schematically representing log information.
[0036]
FIG. 3B shows an example of information extracted from (a) of FIG. 3 (more precisely, the log information of FIG. 2A) and set in the table. Here, the following information shown in the table is extracted and set in the table in accordance with the procedure shown in FIGS.
[0037]
[Table 1]

[0038]
As described above, the log information file 13 in FIG. 2A is sequentially traced from the end, and when the job to be reprocessed (rerun job) and the input file according to the present invention are deleted, the counter value is incremented by +1. The rerun job table shown in the figure can be created by repeatedly setting the counter value. A job whose counter value in the rerun job table is 0 (in this case, B-job, A-job) is concurrently executed, and when the processing of one of the jobs is completed, the file output by the job is input. The counter value of the job to be subtracted by 1 is set in the table, the job having the counter value of 0 is repeatedly started, and the job can be repeatedly executed to quickly recover (see FIGS. 7 and 8). Will be described later). This will be described below.
[0039]
FIG. 4 is an explanatory diagram (extraction, part 1) of the present invention.
FIG. 4A shows examples of jobs, input files, and output files. Here, it is assumed that a failure occurs in the volume storing the files C and E for some reason while the e-job reads data from the files C and E and executes processing. When this failure occurs, log information is collected as shown in FIG. 4B, and (1) the written job head job block and (2) the write destination block are set at the positions shown in the figure.
[0040]
Next, the procedure for creating the rerun job table of FIG. 3B based on the log information file 13 of FIG. 4B will be described in detail with reference to FIG. 5 and FIG.
[0041]
5 and 6 are explanatory diagrams of the present invention.
In FIG. 5, S1: The recovery file information is extracted based on the information notified of the failure. This is restored based on a notification that a failure has occurred in a volume with the files C and E while the e-job of FIG. 4A reads data from the files C and E and performs processing. Here, the files C and E are extracted, and the files C and E are set in the recovery file table as described on the right side of FIG.
[0042]
S2: Read from (1) of the log information file. This reads the log information of the c job at the position of the written job first block in the log information file 13 of FIG.
[0043]
S3: It is checked whether the job outputs a recovery file. Here, it is checked whether the c job read in S2 outputs the files C and E set in the recovery file table in S1. Here, it is found that the c job is outputting the file C.
[0044]
S4: It is determined whether the data is being output. Here, since the c job outputs the file C in S3, the answer is YES, and the process proceeds to S5. If not output, S5 to S7 are skipped and the process proceeds to S8.
[0045]
S5: A job is registered in the rerun job table (c job). Extracted is set for the file in the recovery file table (file C). As a result, of the recovery file table and the rerun job table described on the right side of FIG.
・ Extracted is set for file C in the recovery file table,
-In the rerun job table, c job (input counter 0) not executed is set. Here, extracted means that there is a job to be recovered. Further, the input counter 0 is an initial value, and unexecuted is a job to be reprocessed by the c job and represents unexecuted.
[0046]
S6: The input file status of the registered rerun job is searched from the file management. If deleted or failed, register the file in the recovery file table. Set the correspondence in the rerun job table. Here, file B is registered because it has been deleted). As a result, of the recovery file table and rerun job table listed on the right side,
-Set file B, and set the relationship as indicated by the arrows in the recovery file table on the right side of S6 in FIG. 5 and the rerun job table (here, c job reads data from file B, and the result is in file C) Output is indicated by an arrow in the figure).
[0047]
S7: Set the rerun job input counter (input file counter) (c job sets 1). This is because the file B from which the c job reads data is not deleted, so that the value 1 added to the current input counter 0 is set as the input counter 1 as shown in the figure.
[0048]
S8: It is determined whether the recovery file table has been completely extracted. Here, since it is NO, it progresses to S9. On the other hand, in the case of YES, the process proceeds to the next step (FIG. 8).
[0049]
S9: Trace one log information file. This is traced to the previous block from (1) in FIG.
[0050]
Similarly, for S13 to S19, S23 to S29, and S33 to S38, in the same manner as S3 to S9, d job (3), b job (4), (5) in FIG. By repeating the a job, the recovery file table and rerun job table are set as shown in the figure as shown on the right side, and the relationship between the input file and output file of each job is set as indicated by the arrows. To obtain the result in the lower right of FIG.
[0051]
As described above, it is possible to extract from the log information file 13 in FIG. 4B as set in the recovery file table and the rerun job table in the lower right (6) in FIG. Next, with reference to FIG. 7 and FIG. 8, a detailed description will be given of a procedure when multiple jobs with the same input counter (counter value) are executed in parallel based on the restoration file table and the rerun job table in (6). To do.
[0052]
7 and 8 are explanatory diagrams (retry) of the present invention. FIGS. 7 and 8 show a flow when the rerun job is executed and recovered.
[0053]
In FIG. 7, S41: Submit a job for which the input counter of the rerun job table is 0. Assume that the job status is being executed (a job, b job). This is the input counter 0 in the rerun job table of (6) described on the right side (same as (6) in the lower right of FIG. 6 described above). Here, a job and b job are taken out in parallel. Multiple execution requests are made, and unexecuted in the a-job and b-job columns of the rerun job table are set during execution as shown in the figure.
[0054]
S42: The job execution is completed and the job normal end notification is received, so that the job is completed (a job). As a result, the execution of job a in the rerun job table on the right side is set to executed.
[0055]
S43: It is determined whether all rerun jobs have been executed. Here, since execution of the b job or the like is not completed, the process proceeds to S44. On the other hand, if YES, the recovery is complete.
[0056]
S44: Subtract the input counter of the job that is inputting the output file of the rerun job (subtract the counter of c job that is inputting file B by 1). This is because the a job is completed in S42 and the a job stores the processing result in the file B, so that the file B is input. Here, the value of the input counter of the c job is decremented by 1 and input. Counter 1 is set to input counter 0 as shown.
[0057]
S45: When the input counter reaches 0, a rerun job execution request is made. It is assumed that it is being executed (c job is requested to be executed and is being executed). As a result, as described on the right side, the c job in the rerun job table is set during execution.
[0058]
S46 in FIG. 8: The execution of the b job is completed and the normal job end notification is received. As a result, the b job in the rerun job table on the right side is set as being executed from being executed.
[0059]
S47: It is determined whether all rerun jobs have been executed. Here, since all jobs have not yet been executed, the process proceeds to S48. On the other hand, if YES, the recovery is complete.
[0060]
S54: The input counter of the job that is inputting the output file of the rerun job is subtracted (the counter of the d job that is inputting the file D is decremented by 1). This is because the b job has been processed in S46 and the b job has stored the processing result in the file D, so the file D is input. Here, the value of the input counter of the d job is decremented by 1 and input. Counter 1 is set to input counter 0 as shown.
[0061]
S55: When the input counter reaches 0, a rerun job execution request is made. It is assumed that the job is being executed (d job is requested to be executed and is being executed). As a result, as described on the right side, the d job in the rerun job table is set during execution.
[0062]
S56: c job execution is completed and job normal end notification is received, so execution is completed (c job). As a result, the c job in the right-side rerun job table is set from being executed to being executed.
[0063]
S57: It is determined whether all rerun jobs have been executed. Here, since all jobs have not yet been executed, the process proceeds to S64. On the other hand, if YES, the recovery is complete.
[0064]
S64: The input counter of the job that has input the output file of the rerun job is subtracted (there is nothing because there is no job that has input the file C). This is because the c job is completed in S56, and the c job stores the processing result in the file C. However, since there is no job inputting the file C (not in the log file), nothing is done.
[0065]
S65: When the input counter reaches 0, a rerun job execution request is made (in this case, there is nothing, so it is passed).
[0066]
S66: d job execution is completed and a job normal end notification is received, so execution is completed (d job). As a result, the d job in the rerun job table on the right side is set from being executed to being executed.
[0067]
S67: It is determined whether all rerun jobs have been executed. Here, since all jobs have been executed, the recovery is completed. On the other hand, in the case of NO, the same is repeated.
[0068]
As described above, the retry process is performed by executing the same job with the same input counter on the basis of the rerun job table and the recovery file table (1) in the lower right of FIG. 6 which are automatically extracted from the log information file. It is possible to execute recovery at a high speed and promptly achieve recovery.
[0069]
(Appendix 1)
It is a reprocessing multiple recovery program that recovers by executing multiple reprocessing,
Means for reading log information recording the history of the name of the executed job, the name of the input file read by the job, and the name of the output file output;
When a failure occurs, increase the counter value of the job that executed the log information retroactively from the time of the failure, the file that the job output, and the job that receives the file when the file does not exist on the storage device A reprocessing multiple recovery program for causing a computer to function as a means for extracting a job to be set and reprocessed in a table.
[0070]
(Appendix 2)
The reprocessing multiple recovery program according to supplementary note 1 for causing a computer to function as means for detecting the multiplicity executed by a job based on the counter value in the table.
[0071]
(Appendix 3)
A job whose input is the file output by the retry-executed job when one of the jobs that have been counter-executed and the counter value set in the above table is executed in parallel. The reprocessing multiple recovery program according to appendix 1, for causing the computer to function as a means for subtracting the count value and setting it in the table and repeating it.
[0072]
(Appendix 4)
A reprocessing multiple recovery device that recovers by executing multiple reprocessings,
Means for reading log information recording the history of the name of the executed job, the name of the input file read by the job, and the name of the output file output;
When a failure occurs, increase the counter value of the job that executed the log information retroactively from the time of the failure, the file that the job output, and the job that receives the file when the file does not exist on the storage device And a means for extracting the data by setting it in a table.
[0073]
(Appendix 5)
It is a reprocessing multiple recovery method that recovers by executing multiple reprocessing,
Reading log information that records the history of the name of the executed job, the name of the input file read by the job, and the name of the output file that was output;
When a failure occurs, increase the counter value of the job that executed the log information retroactively from the time of the failure, the file that the job output, and the job that receives the file when the file does not exist on the storage device And a step of extracting a job to be set and reprocessed in a table.
[0074]
(Appendix 6)
Means for reading log information recording the history of the name of the executed job, the name of the input file read by the job, and the name of the output file output;
When a failure occurs, increase the counter value of the job that executed the log information retroactively from the time of the failure, the file that the job output, and the job that receives the file when the file does not exist on the storage device A computer-readable recording medium having recorded thereon a program that functions as means for setting and extracting the table.
[0075]
【The invention's effect】
As described above, according to the present invention, the count value of the job to be retried and the input file are set in the table based on the log information acquired when the job is executed when the failure occurs, and the count is performed at the time of the retry. Since the configuration in which multiple jobs are executed based on the values is employed, multiple jobs can be executed based on the log information so that rapid recovery can be achieved. In addition, without changing log information and resources stored at the time of job execution, the present invention can execute multiple jobs at the time of retry and easily add functions.
[Brief description of the drawings]
FIG. 1 is a system configuration diagram of the present invention.
FIG. 2 is an explanatory diagram (log information) of the present invention.
FIG. 3 is an explanatory diagram of the present invention.
FIG. 4 is an explanatory diagram (part 1) of the present invention.
FIG. 5 is an explanatory diagram (extraction, part 1) of the present invention.
FIG. 6 is an explanatory diagram (extraction, part 2) of the present invention.
FIG. 7 is an explanatory diagram of the present invention (retry, part 1).
FIG. 8 is an explanatory diagram of the present invention (retry, part 2).
[Explanation of symbols]
11: Failure management means 12: Log acquisition means 13: Log information file 21: Reprocessing / recovery processing means 22: Rerun job extraction means 23: Rerun job execution means

Claims (4)

On the computer,
A first step of registering the name of the failed file in the recovery file table when a failure occurs;
A second step of reading the last recorded log information from the log information file in which the name of the job that has been executed, the name of the input file read by the job, and the name of the output file that was output are recorded in association with each other When,
It is checked whether or not the name of the output file included in the log information extracted in the second step or the fifth step exists in the recovery file table. A third step of registering the name of the job and registering the file having the name of the output file in the recovery file table as extracted;
It is checked whether or not the input file included in the log information extracted in the second step or the fifth step is deleted or faulty. If it is deleted or faulty, the input file is input to the recovery file table. A fourth step of registering the name of the file;
It is checked whether or not all the files registered in the recovery file table have been extracted. If all the files have not been extracted, they are recorded immediately before the log information processed in the third step and the fourth step. A fifth step of reading the log information and executing the third step and the fourth step;
A reprocessing multiple recovery program that executes a sixth step of reprocessing a job recorded in the reprocessing job table. In the fourth step, when the name of the input file is registered in the recovery file table, the count value corresponding to the job registered in the reprocessing job table in the third step is increased,
In the sixth step, when there are a plurality of jobs subject to restoration processing with a count value of 0, a plurality of restoration processing jobs with a count value of 0 are simultaneously subjected to restoration processing. The reprocessing multiple recovery program according to claim 1. On the computer,
A first means for registering the name of the failed file in the recovery file table when a failure occurs;
Second means for reading the last recorded log information from the log information file in which the name of the job that has been executed, the name of the input file read by the job, and the name of the output file that was output are recorded in association with each other When,
It is checked whether or not the name of the output file included in the log information extracted by the second means or the fifth means exists in the recovery file table. A third means for registering the name of the job and registering the file having the name of the output file in the recovery file table as extracted;
It is checked whether the input file included in the log information extracted by the second means or the fifth means is deleted or faulty, and if it is deleted or faulty, the input file is input to the recovery file table. A fourth means for registering the name of the file;
It is checked whether or not all the files registered in the recovery file table have been extracted. If all the files have not been extracted, the log information processed by the third and fourth means is recorded one before. Fifth means for reading out the log information and executing the third means and the fourth means;
A reprocessing multiple recovery device that executes a sixth means for reprocessing a job recorded in the reprocessing job table. The means provided in the computer is
A first step of registering the name of the failed file in the recovery file table when a failure occurs;
A second step of reading the last recorded log information from the log information file in which the name of the job that has been executed, the name of the input file read by the job, and the name of the output file that was output are recorded in association with each other When,
It is checked whether or not the name of the output file included in the log information extracted in the second step or the fifth step exists in the recovery file table. A third step of registering the name of the job and registering the file having the name of the output file in the recovery file table as extracted;
It is checked whether or not the input file included in the log information extracted in the second step or the fifth step is deleted or faulty. If it is deleted or faulty, the input file is input to the recovery file table. A fourth step of registering the name of the file;
It is checked whether or not all the files registered in the recovery file table have been extracted. If all the files have not been extracted, they are recorded immediately before the log information processed in the third step and the fourth step. A fifth step of reading the log information and executing the third step and the fourth step;
A reprocessing multiple recovery method that executes a sixth step of reprocessing a job recorded in the reprocessing job table.

Images