JP2003196116A - Reprocessing multiple restoration program, reprocessing multiple restoration device and reprocessing multiple restoration method - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To attain a quick restoration in a reprocessing multiple restoration program, reprocessing multiple restoration device and reprocessing multiple restoration method for multiply executing a reprocessing for restoration by setting a job for performing a retry based on log information acquired in the execution of a job in the occurrence of an obstruction and the count value of an input file to a table, respectively, and multiply executing the job on the basis of the count value at the time of retrying. <P>SOLUTION: This device comprises a means for reading the log information in which the histories of the name of the executed job, the name of the input file read by the job, and the name of the output file outputted thereby are recorded; and a means for tracing the log information from the occurrence of the obstruction to extract the executed job, the file outputted by the job, and a job for increasingly setting, when the file concerned is not present on a storage device, the counter value of the job having this file as input in the table to perform the reprocessing. <P>COPYRIGHT: (C)2003,JPO

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a reprocessing multiplex recovery program, a reprocessing multiplex recovery device, and a reprocessing multiplex recovery method for performing multiple reprocessings for recovery.

[0002]

2. Description of the Related Art Conventionally, when a job is sequentially activated, each job reads data from a file, processes the data, and outputs the data to the file repeatedly to perform a predetermined job, a DASD (Direct Access Storage Device) for storing the file is stored.
ce, magnetic disk device, etc.), logs (history) of each job and its start time, read file, written file, etc. are recorded in chronological order in case of failure to read. It is stored as information. When a failure occurs, the jobs to be retried and the files to be recreated are extracted and stored until the jobs to be retried and files to be recreated are deleted from the end of the log information, and the extracted jobs and files are rewritten from the beginning. Each job and its file were retried sequentially to recover them.

[0003]

Therefore, in the above method, it is necessary to sequentially re-execute each job in order to re-create each file at the time of retry, and a great deal of time is required for recovery. There was a problem of becoming.

Therefore, it is desired to execute multiple jobs at the time of retry so as to recover quickly.

The present invention solves these problems.
The count values of the job and the input file to be retried are set in the table based on the log information acquired when the job was executed at the time of failure, and multiple jobs are executed based on the count value at the time of retry to speed up the process. The purpose is to recover.

[0006]

[Means for Solving the Problems] Means for solving the problems will be described with reference to FIG.

In FIG. 1, the log acquisition means 12 acquires logs of executed jobs and input files, output files, etc., and creates a log information file 13.

The rerun job extracting means 22 analyzes the log information file 13 and sets a job to be reprocessed and a counter value in a table.

The rerun job executing means 23 simultaneously executes multiple jobs having the same counter value set in the table.

Next, the operation will be described. Log acquisition means 12
Acquires the history of the job name of the job executed by the job, the file name of the input file read by the job, and the file name of the output file output by the job, and the rerun job extraction unit 22 retrieves the log information in the log information file 13. Jobs executed retroactively from the time of failure, files output by jobs, and when the file does not exist on the storage device, the counter value of the job that uses the file as input is repeatedly increased and set in the table. The multiplicity of is detected.

At this time, the multiplicity executed by the job is detected based on the counter value in the table.

Further, when the counter value set in the table is an initial value, multiple jobs are executed in parallel, and when any of the multiple executed jobs has completed the retry, the file output by the job that has completed the retry is input. The count value of the job to be executed is subtracted and set in the table, and the job is repeated.

Therefore, the count values of the job to be retried and the input file are respectively set in the table based on the log information acquired when the job was executed when the failure occurred, and the job is retried based on the count value at the time of retry. By executing multiple jobs, it is possible to perform multiple jobs based on the log information and quickly recover the jobs.

[0014]

BEST MODE FOR CARRYING OUT THE INVENTION Next, an embodiment and an operation of the present invention will be sequentially described in detail with reference to FIGS.

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, the programs functioning as these means are stored in an external storage medium and provided to the customer.

In FIG. 1, the execution management means 1 executes a job according to the schedule set in the schedule file 2.

The schedule file 2 is a file in which a job execution schedule is set.

The initiator 3 allocates the resources defined in the resource definition file 5 to the job (batch job 4) instructed by the execution management means 1 and executes the job.

The batch job 4 is a job which the execution management means 1 takes out from the schedule file 2 and requests execution to the initiator 3.

The resource definition file 5 defines various resources used by the job. The resource management unit 6 manages various resources, and here manages the real file 7 and the file management file 8 on the disk device.

The execution file 7 is a file for reading and storing data when the job is executed.

The file management file 8 sets and manages various kinds of information regarding the execution file 7.

The failure management means 11 manages failures, and here, collects the log executed by the job (batch job 4), and is composed of the log acquisition means 12 and the like. .

The log acquisition means 12 acquires a log executed by the batch job 4 and creates a log information file 13.

The log information file 13 is a file in which executed job names, input file names, output file names, etc. are collected and stored.

The reprocessing restoration processing means 21 executes reprocessing and restores, and is composed of a rerun job extraction means 22 and a rerun job execution means 23 here.

When a failure occurs, the rerun job extraction means 22 traces from the end of the log information file 13, the job to be reprocessed, the file output by the job, and the counter value of the job when the file does not exist in the storage device. Is incremented by 1 and set in the table, and the job and the counter value are extracted (see FIGS. 2 to 8).
Will be used later).

The rerun job executing means 23 is configured to execute jobs in parallel with the same counter value in the table in parallel and retry the operation (described later with reference to FIGS. 2 to 8).

Next, the operation of the configuration of FIG. 1 will be sequentially described in detail with reference to FIGS. FIG. 2 shows an explanatory diagram (log information) of the present invention.

FIG. 2A shows an example of log information. This is obtained by acquiring the log of the job executed by the log acquisition means 12 of FIG. 1 described above, and is generated by acquiring the following information shown and registering when the execution of each job is completed. Is. Jobs whose execution has not finished have not been collected.

Job name: -Start time: -End time: -Resource information: -Input file name: -Output file name: -Others: Here, the job name is the name of the job that has completed execution, and the start The time is the time when the job started, the end time is the time when the job ended normally, the input file name in the used resource information is the name of the file from which the data was read, and the output file name was processed by the job. This is the name of the file that outputs (stores) the result.

FIG. 2B schematically shows the job name when the log information of FIG. 2A is acquired, and the job net structure of the input file and the output file.

In FIGS. 2A and 2B, for example, A
-The job starts processing at 13:50 (13:50), reads data from file A, stores the processing result in file B, and finishes processing at 14:30. Similarly, as schematically shown in FIG. 2B, the B-job to the D-job read data from the corresponding file, store the processing result in the corresponding file, and finish the processing.

With respect to the example of FIG. 2 described above, analysis of log information when parallel execution is performed at the time of retry in the present invention (reprocessing job extraction and counter value extraction from log information of FIG. 2A) is performed. The operations for setting 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.

FIG. 3 shows an explanatory view of the present invention. FIG. 3A is an example in which log information is schematically represented ((b) in FIG. 2).
Almost the same).

FIG. 3B shows an example of information extracted from FIG. 3A (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 accordance with the procedure of FIGS. 4 to 6 described later.

[0037]

[Table 1]

As described above, when the log information file 13 in FIG. 2A is sequentially traced from the end and the job (rerun job) to be reprocessed according to the present invention and the input file are deleted, the counter value is changed. It is possible to create the illustrated rerun job table by repeatedly setting the counter value after incrementing by one. Then, a job whose counter value in the rerun job table is 0 (here, B-
(Job, A-job) are simultaneously executed in parallel, and when the processing of one of the jobs is completed, the counter value of the job whose file output by the job is input is subtracted by 1 and set in the table, and the counter value is 0. It is possible to perform multiple jobs by repeating the activation of the job of (1) and quickly recover (described later with reference to FIGS. 7 and 8). This will be described below.

FIG. 4 is an explanatory view of the present invention (extraction, part 1).
Indicates. FIG. 4A shows a job and an input file,
An example of an output file is shown. Here, it is assumed that a failure occurs in the volume storing the files C and E for some reason while the process is being executed while the e-job reads data from the files C and E, respectively. When this failure occurs, log information is collected as shown in FIG. 4B, and the written job head job block and the write destination block are set at the positions shown in the figure.

Next, the log information file 1 of FIG. 4 (b)
3, the procedure for creating the rerun job table in FIG. 3B will be sequentially described in detail with reference to FIGS. 5 and 6.

5 and 6 are explanatory views of the present invention. In FIG. 5, S1: Extract the recovery file information based on the information notified of the failure. This is restored based on the notification that the e-job in FIG. 4A reads a data from the files C and E and is in the middle of processing, and a failure has occurred in a volume containing the files C and E. It should be extracted as files C and E here, and the files C and E are set in the recovery file table as described on the right side of FIG.

S2: Read from the log information file. This reads the log information of the c job at the position of the written job start block of the log information file 13 of FIG. 4B described above.

S3: The job checks whether a recovery file is output. 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.

S4: It is determined whether or not it is outputting. Here, since the c job outputs the file C in S3,
If YES, the process proceeds to S5. If not output, S5 to S7 are skipped and the process proceeds to S8.

S5: Register the job in the rerun job table (c job). The extracted file is set to the file in the recovery file table (file C). As a result, of the recovery file table and the rerun job table shown on the right side of FIG. 5, the file C in the recovery file table is set to have been extracted, and the c job (input counter 0) is set in the rerun job table. Not executed is set. Here, extracted means that there is a job to be restored. Further, the input counter 0 is an initial value, and unexecuted is a job to be reprocessed by the c job and represents unexecuted.

S6: The input file status of the registered rerun job is searched from the file management. In case of deletion or failure, register the file in the recovery file table. Set the correspondence in the rerun job table. here,
File B has already been deleted, so register it.) From these, among the recovery file table and the rerun job table described on the right side, the file B is set, and the relationship is set as the arrow in the recovery file table and the rerun job table on the right side of S6 in FIG. 5 ( Here, it is indicated by an arrow in the drawing that the c job reads data from the file B and outputs the result to the file C).

S7: The input counter (input file counter) of the rerun job is set (1 is set for the c job). This is file B where the c job reads the data.
Is not deleted, +1 is added to the current input counter 0.
The value 1 is set as the input counter 1 as shown in the figure.

S8: It is determined whether the recovery file table has been completely extracted. Here, since it is NO, the process proceeds to S9.
On the other hand, in the case of YES, the process proceeds to the next step (FIG. 8).

S9: Trace one log information file. This traces to the previous block from FIG.

Similarly, S13 to S19 and S23 to S
29, S33 to S38 are repeated for the d job, the b job, and the a job of (b) of FIG. 4 in the same manner as S3 to S9. The recovery file table and the rerun job table are set as shown in the drawing, and the relationship between the input file and the output file of each job is set and extracted as shown by the arrow, and the result at the lower right of FIG. 6 is obtained.

As described above, the log information file 13 in FIG. 4B can be extracted as set in the recovery file table and the rerun job table in the lower right of FIG. Next, based on the recovery file table and the rerun job table, a procedure when multiple jobs having the same input counter (counter value) are executed in parallel will be described in detail with reference to FIGS. 7 and 8.

7 and 8 are explanatory views (retry) of the present invention. 7 and 8 show a flow when the rerun job is executed and restored.

In FIG. 7, S41: request execution of a job whose input counter of the rerun job table is 0. It is assumed that the job status is being executed (a job, b job). This is the input counter 0 in the rerun job table described on the right side (the same as in the lower right part of FIG. 6 described above),
Here, a jobs and b jobs are taken out, multiple execution requests are made in parallel, and unexecuted in the columns of a jobs and b jobs in the rerun job table are set to “in execution” as illustrated.

S42: Since the execution of the job a has been completed and the notification of the normal end of the job has been received, the job has already been executed (job a).
As a result, the execution status of the job a in the rerun job table on the right side is set to the executed status.

S43: Determine whether all rerun jobs have been executed. Here, since the execution of the b job or the like has not been completed, the process proceeds to S44. On the other hand, in the case of YES, the restoration is completed.

S44: The input counter of the job inputting the output file of the rerun job is decremented (the counter of the c job inputting the file B is decremented by 1).
This is because the job a is completed in S42 and the processing result of the job a is stored in the file B, so 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.

S45: When the input counter reaches 0, a rerun job execution request is issued. The job is being executed (the job c is submitted and the job is being executed). As a result, as described on the right side, the relevant c job in the rerun job table is set to being executed.

S46 of FIG. 8: b job execution is completed, and since the job normal end notification is received, it is set as executed (b job). As a result, b in the rerun job table on the right side
The job is set to being executed from being executed.

S47: It is determined whether all rerun jobs have been executed. Here, since the execution of all the jobs has not been completed yet, the process proceeds to S48. On the other hand, in the case of YES, the restoration is completed.

S54: The input counter of the job inputting the output file of the rerun job is decremented (the counter of the d job inputting the file D is decremented by 1).
This is because the b job has completed processing in S46 and the processing result of the b job has been stored 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.

S55: When the input counter reaches 0, a rerun job execution request is issued. Assume that the job is being executed (submit the job d and assume that the job is being executed). As a result, as described on the right side, the d job in the rerun job table is set to being executed.

S56: Since the execution of the c job has been completed and the job normal end notification has been received, the job has been completed (c job).
As a result, the c job in the right rerun job table is set from being executed to being executed.

S57: It is determined whether all rerun jobs have been executed. Here, since the execution of all the jobs has not been completed yet, the process proceeds to S64. On the other hand, in the case of YES, the restoration is completed.

S64: The input counter of the job inputting the output file of the rerun job is decremented (there is no job inputting file C, so nothing is done). This is because in step S56, the c job has completed processing, and the processing result of the c job has been stored in the file C, but since there is no job that is inputting the file C (not in the log file), nothing is done.

S65: When the input counter reaches 0, a rerun job execution request is made (here, since there is nothing, the process is passed through).

S66: Since the d job execution is completed and the job normal end notification is received, it is set to have been executed (d job).
As a result, the d job in the right rerun job table is set from being executed to being executed.

S67: It is determined whether all rerun jobs have been executed. Here, since all the jobs have been executed, the recovery is completed. On the other hand, in the case of NO, the same is repeated.

As described above, the retry process is performed by executing the jobs having the same input counter in a multiple manner based on the rerun job table and the recovery file table in the lower right of FIG. 6 which are automatically extracted from the log information file. It becomes possible to execute the restoration at high speed and to promptly recover.

(Supplementary Note 1) A reprocessing multiple restoration program for executing multiple reprocessings to restore 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 by the job. A means for reading the recorded log information and a job that executes the above log information retroactively when the failure occurs, a file output by the job, and a file that is output when the file does not exist in the storage device. A reprocessing multiple recovery program for causing a computer to function as a means for extracting a job to be reprocessed by increasing a counter value of an input job and setting it in a table.

(Additional remark 2) The reprocessing multiple restoration program according to additional remark 1 for causing a computer to function as a means for detecting a multiplicity executed by a job based on the counter value in the table.

(Supplementary Note 3) When a job whose counter value set in the above table is an initial value is multiplexed in parallel and one of the multiple jobs is retried, the job that has been retried is output. The reprocessing multiple restoration program according to appendix 1 for causing a computer to function as a means for repeating by subtracting the count value of a job whose input is the file and setting it in the table.

(Supplementary Note 4) A reprocessing multiplexing recovery apparatus for recovering by executing reprocessing multiple times, in which 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 by the job are recorded. A means for reading the recorded log information and a job that executes the above log information retroactively when the failure occurs, a file output by the job, and a file that is output when the file does not exist in the storage device. And a means for increasing the counter value of an input job, setting it in a table, and extracting it.

(Supplementary Note 5) This is a reprocessing multiple restoration method for recovering by executing reprocessing multiple times, in which 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 by The step of reading the recorded log information, and when a failure occurs, the job that executed the above log information retroactively from the occurrence of the failure, the file output by the job, and the file when the file does not exist in the storage device And a step of increasing the counter value of an input job and setting it in a table to extract a job to be reprocessed.

(Supplementary Note 6) A means for reading out 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 by the job, and the above log information when the failure occurs. Jobs executed retroactively from the time of failure, files output by the job, and when the file does not exist in the storage device, the counter value of the job that inputs the file is increased and set in the table and extracted. A computer-readable recording medium in which a program for functioning as means is recorded.

[0075]

As described above, according to the present invention,
The configuration is such that the count values of the job and the input file to be retried are set in the table based on the log information that was acquired when the job was executed at the time of failure, and multiple jobs are executed based on the count value at the time of retry. Since this is adopted, it is possible to execute multiple jobs based on the log information and quickly recover. Further, according to the present invention, it is possible to execute multiple jobs at the time of retry without changing the log information and resources to be saved when the job is executed, and it is possible to easily realize the addition of functions.

[Brief description of 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 (1) of the present invention.

FIG. 5 is an explanatory diagram (extraction, No. 1) of the present invention.

FIG. 6 is an explanatory diagram (extraction, part 2) of the present invention.

FIG. 7 is an explanatory diagram (retry, No. 1) of the present invention.

FIG. 8 is an explanatory diagram (retry, No. 2) of the present invention.

[Explanation of symbols]

11: Fault 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 (5)

[Claims] Claim: What is claimed is: 1. A reprocessing multiple restoration program for performing multiple reprocessings for restoration, wherein a 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 by the job is recorded. A means for reading log information, a job that executes the above log information retroactively when the failure occurs, a file output by the job, and an input file when the file does not exist in the storage device. A reprocessing multiple recovery program for causing a computer to function as a means for extracting a job to be reprocessed by increasing the counter value of the job to be set in a table. 2. A reprocessing multiple restoration program according to claim 1, which causes a computer to function as means for detecting a multiplicity executed by a job based on the counter value in the table. 3. A file output by a job that has completed retry processing when any of the multiple-executed jobs whose counter values set in the table are initial values are concurrently executed in parallel. Set the above table by subtracting the count value of the input job
The reprocessing multiple restoration program according to claim 1, which causes a computer to function as a repeating unit. 4. A reprocessing multiplexing recovery apparatus for recovering by executing reprocessing multiple times, wherein a 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 by the job is recorded. A means for reading log information, a job that executes the above log information retroactively when the failure occurs, a file output by the job, and an input file when the file does not exist in the storage device. And a means for increasing the counter value of the job to be set and extracting it in a table. 5. A reprocessing multiple recovery method for recovering by executing reprocessing multiple times, wherein a 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 by the job is recorded. The step of reading log information, and when a failure occurs, the job that executed the above log information retroactively from the time of the failure, the file output by the job, and the file input when the file does not exist in the storage device are input. Re-multiplexing recovery method including the step of increasing the counter value of the job to be set and setting it in the table and extracting the job to be re-processed.