JPH02118736A - System for restoring and controlling fault of batch job - Google Patents

Abstract

PURPOSE:To re-perform a batch job without altering a performing environment by controlling a job re-performance information and permitting a program at the time of re-performance to retrieve control information. CONSTITUTION:A control file 5 consisting of performance control information for controlling the job and history control information is provided. Performance control information registers a record by setting the name of the job as a key prior to the performance of the job, performs the job, registers processing information of the input file 1 of a batch processing and makes it to be control information when a fault is re-performed. Consequently, file update without contradiction can be realized by applying a fault restoration control module 8 for a batch program 2 and re-performing the job at the time of re-performance from program aboart. Even in the case of aboart due to the program, a control record can be retrieved and an injustice record can be corrected. Thus, the batch job can be re-performed without altering the performance environment.

Description

[Detailed Description of the Invention] [Industrial Application Field] The present invention relates to a batch job failure recovery management method, and in particular to supporting the pursuit of the cause of a batch job failure and changing the execution environment when the cause is removed. The present invention relates to a batch job failure recovery management method that guarantees updated data contents and enables management of job operation by simply re-executing the job in the same way as before.

[Conventional technology]

Conventional batch job management methods have two types of data updates: some allow the updated data to be updated twice when re-executing in the event of a failure, while others do not allow it to be updated twice due to additions, etc. The program's algorithm includes an item to determine update status in the record item, and determines whether a record has been updated.

Alternatively, if the fault is a program abort due to data error, display the incorrect data information on the output device, correct the data, and then program the program to position the program start position at that data for re-execution. The logicality of the update was ensured by modifying or deleting the processed input file data from the file.

If it is necessary to transfer data between a job executed in the event of a failure and a re-execution job, an intermediate file may be considered in the job design, or a program dedicated to failures may be used to store information (especially accumulated value,
It was necessary to create a separate program to obtain information such as the number of processed items.

[Problem to be solved by the invention]

Adding an item for update judgment to the conventional file item,
This in itself will increase the record length, and if jobs that update the same file are executed in parallel, it will be necessary to have as many update judgment items as there are concurrent jobs. It has the disadvantage of poor scalability.

This is basically a method that determines whether or not there has been an update based on the contents of the update judgment item, and avoids logical contradictions in records.This method requires file access even for processed data, which wastes time. need. In addition, re-execution after modifying the program or deleting input data requires work such as compiling, creating a new JCL, and modifying data, and there is a risk of double failure due to mistakes, which poses safety issues. .

Furthermore, as the amount of data being processed is increasing, some batch processes require dozens of hours, and operational schedules are becoming more congested, making it difficult to immediately respond by changing the execution environment such as modifying programs when recovering from a failure. Not only is this method incompatible with modern operations, but it also has the disadvantage of not being able to implement a unified recovery procedure because the failure recovery method is different for each job.

[Means to solve the problem]

An embodiment of the present invention utilizes a management file for controlling job execution in a batch job failure recovery management method that creates a prompt re-execution operating environment without logical contradictions in updated data when re-executing a batch job after failure recovery. By doing this, there is a means for storing and deleting records using the job identification name of the job control statement as a search key, and by using that means, update information of the input file of the batch job is obtained, and when re-execution, it is determined whether or not it has been processed. There is also a means for directly locating it in the input/failure record at the time of a failure, a means for a re-execution job to take over the processing data of the failed job, a means for searching that information, and a means for recovering the entire system from failures that are not caused by programs. and means for starting a group of failed jobs all at once in re-execution.

〔Example〕

Next, the present invention will be explained with reference to the drawings.

FIG. 1 shows an embodiment of the invention. In FIG. 1, one embodiment of the present invention manages job re-execution information, and the re-execution program indexes the management information, so that the execution environment of job control statements, programs, files, etc. is not changed. This is a failure recovery management method that allows batch jobs to be re-executed at any time, and has a job management file 5 for managing jobs. This job management file 5 is composed of execution management information and history management information. The execution management information uses the job name in the job control statement as key 5-1 before job execution.
A record is registered and deleted upon normal termination. As the job is executed, input file processing information for batch processing is registered at regular intervals specified by the program, and this is used as control information for re-execution in the event of a failure. This becomes information when correcting incorrect data is required or when finding a corresponding record, and is displayed on the output device 9 using a search function or the like.

A batch program 2 applied to an embodiment of the present invention reads input files 1 in the order of arrow a, randomly accesses update foil 3 using the items of input file 1-1, and updates the values of items 1-2. In the case of normal processing, this program performs processing to add to item 3-2. At the beginning of processing, a job management information record is stored in the job management file 5 using the job name of the job control statement as a key. Then, if we configure a program with the logic of updating an update file for one input file and name this unit a transaction, the number of input processes 5-2 and the input file will be read on the management file every m transactions. The time address 5-3° and the processing time 5-4 are stored as essential data. In addition, the process of carrying over the processing results of each transaction as a cumulative value to the next transaction is as follows.
! - Store the cumulative value in the management file for each run. When input file 1 is processed to the end, the batch program executes the following command from management file 5 as a termination process.
Delete the management record with the job name of the batch program as the key. Next, in the case of re-execution after abnormal termination, if a batch job goes to idiot-1 for a reason not caused by the individual program, such as a system down, if you simply re-execute this job, the failure recovery module will be installed in the initial processing of the program. 8, the management file 5 is searched using the job name as a key, and the presence or absence of a management record determines that this program is an aborted job.

The failure recovery module 8 processes 5- cases of the management file 5.
2 and the number of input files to be read, and instructs the program to skip input file 1 until the number of processed items exceeds 5-2. Or, using address 5-3 of input file 1 stored in management file 5 as a key,
It directly positions the input file at the point of abort. This judgment is made based on the address of the management record or the presence or absence of the key 5-3. When the re-execution job has the take-over information 5-5, the job is re-executed using the take-over information 5-5 provided by the failure recovery module 8. From this point on, similarly to normal processing, management information is stored in the management file 5 via the failure recovery module 8 on a transaction-by-transaction basis, and when the last transaction is processed, the corresponding management record is deleted.

Further, in the case of an abort caused by a program, it is possible to search for the management record and determine whether it is an unauthorized input record based on the job name 5-1, the number of input processes 5-2, and the address or key value 5-3. Then, by linking this with the file maintenance function, the corresponding record is called up on the screen and incorrect data is corrected. Then, by simply re-executing the modified job, there is no need to consider the occurrence of logical contradictions or cumulative value contradictions due to double updates. In the case of re-executing a job after abnormal termination, the failure recovery module 8 uses the job management file 5
Then, a re-execution time is added to the job management information record and stored in the job management file 5 as a failure history record using the system date and automatic serial number as key items.

By accessing the job management file 5 using the date as a key, information on the presence or absence of failures on that day and failure history information (job name, time of failure occurrence, re-execution time,
information on the occurrence of a failure, etc.) can be output to an output device 9 such as a screen or a form.

In particular, in the case of a system down such as a power outage, if you want to unconditionally re-execute the job that was being executed at the time of the downtime, you can obtain the relevant job name by searching the management file, and use that to rerun the job. You can start the corresponding job in the control file.

In this way, an embodiment of the present invention manages job re-execution information, and allows the re-execution program to search for the management information, so that batch processing can be performed without changing the execution environment of job control statements, programs, files, etc. The object of the present invention is to provide a failure management method that allows jobs to be re-executed, and for this purpose, as a management method for job failure recovery, a management file consisting of execution management information and one-history management information for managing jobs is provided.

For execution management information, a record is registered using the job name in the job control statement as a key before job execution, and the record is deleted upon normal completion.When the job is executed, input file processing information for batch processing is registered in the program. Specify with.

When it is necessary to correct incorrect data by registering it at regular intervals and using it as control information for re-execution in the event of a failure,
This information becomes information when finding a corresponding record, and can be displayed on an output device using a search function, etc. In addition, when re-executing, the execution information is registered as failure history information, numbered by the system, and used as a key for management.For abnormally terminated jobs registered in the management file, the system determines whether the job termination status is bad. Then, those jobs can be started all at once.

〔Effect of the invention〕

As explained above, the present invention applies a failure recovery management module to batch programs, so that when a program is aborted due to a system down, etc., it is possible to simply re-execute the job and create a consistent file. This has the advantage of being able to update jobs and automatically start jobs all at once without selecting an abort job. Even in the case of an abort caused by a program, by searching the management record and using the maintenance function, it is possible to correct the incorrect record in a short period of time without error.

patch program, 3... update mask file, 4...
- Failure recovery management system, 5... Job management file, 6... Job-batch startup, 7... Search, 8... Post-failure module, 9... Output device.

[Brief explanation of drawings]

FIG. 1 is a configuration diagram showing the relationship between a batch program of the present invention and a post-failure management system.

Claims (1)

[Claims] In a batch job failure recovery management method that creates a prompt re-execution environment without logical inconsistencies in updated data when re-executing a batch job after failure recovery, job control statements can be changed by using a management file that controls job execution. A method for storing and deleting records using a job identification name as a search key, and by using this method, obtaining update information of a batch job input file, determining whether or not it has been processed at the time of re-execution, and directly inputting it in the event of a failure. A method for locating the processing data of a failed job in a file record, a means for a re-execution job to inherit the processing data of a failed job, a means for searching that information, and a means for re-executing a group of failed jobs at once after recovery from a system-wide failure not caused by a program. A batch job failure recovery management method includes a means for starting a batch job, and promptly re-executes a batch job after a failure occurs.