JP5497210B1 - Job re-execution support system - Google Patents

Abstract

PROBLEM TO BE SOLVED: To return an input file and an output file to a state before execution of a program selected in a process table at the abnormal end of a job for sequentially executing a program that performs processing using at least one of an input file and an output file.
An input file or an output file used by a program based on a program that performs processing using at least one of an input file and an output file, a job that sequentially executes a plurality of programs, and the source code of the program The process table creation task 17 for creating the process chart 30 illustrated for each program is returned to the state immediately before the program selected in the process chart 30 is executed, and the input file and the output file are returned. A job re-execution task 16 for making the program re-executable.
[Selection] Figure 1

Description

  The present invention relates to a job re-execution support system that supports re-execution of a job that sequentially executes a program that performs processing using at least one of an input file and an output file.

  A batch process or a resident process that is activated in a mainframe including a host is described in a job control language (JCL), and includes a job that sequentially executes a plurality of programs. Since the syntax of JCL is difficult, it takes time and effort to grasp the functions and processing. Further, since the program uses at least one of the input file and the output file, it takes time and effort to grasp when the number of input files or output files to be used increases.

  Therefore, in a program that performs processing using at least one of the input file and the output file, in order to easily grasp the input file and the output file, a related diagram illustrating the relationship between the input file, the output file, and the program is shown. create. Also, by creating a computer processing process schedule (process chart) that shows job input files and output files for each program, it becomes easy to grasp the input files and output files in the job.

  By the way, if a job ends abnormally due to a program failure or input file failure, the input file and output file are updated before the abnormal end, and after the abnormal end, the input file and The output file is not updated.

  Therefore, after resolving the problem by checking the cause of abnormal termination of the job, revising the program or preparing the input file, and then re-executing the job, execute the input file and output file for the job. It is necessary to return to the previous state.

  However, when the number of input files or output files increases or decreases due to the modification of the program, there is a risk of forgetting to update related diagrams and process charts. In addition, even when the related diagrams and process charts are updated correctly, when the number of input files or output files is large, or when input files or output files are updated by multiple programs in a job Takes time and effort to return the input file and the output file to the state before execution of the job.

  By the way, as a technology for automatically generating a batch system design drawing, a system design drawing such as a job flow diagram is automatically created, and when a system design drawing of some design levels is recreated, other design levels A technique for automatically correcting the system design drawing is also known (see, for example, Patent Document 1).

  As a technique for improving the work efficiency of reprocessing, a technique for continuously managing transactions to be reprocessed on a storage device and improving the processing efficiency even when reprocessing is known is known. (For example, refer to Patent Document 2). In this technique, if the transaction record is unsuccessful, a reprocessed transaction record is created and added to the storage unit as an unprocessed transaction record. In addition, a technique for efficiently restarting (rerunning) job processing in which a job has a plurality of job steps and a job program is executed in each job step is known (see, for example, Patent Document 3). . Further, the recovery process necessary for re-execution of the job that has ended abnormally and the re-execution job from the rerun point are incorporated into the rerun TBL. When there is a rollback process, a technique for incorporating this process at the head of the rerun TBL is known (for example, see Patent Document 4). Furthermore, when processing ends abnormally, there is a technology that automatically recovers data from a backup file by using the recovery processing function of the batch processing processing control tool for sequential files as well as recovery processing by database rollback processing. (For example, refer to Patent Document 5).

JP 2007-257384 A JP 11-265307 A JP 2006-293582 A JP 2008-217367 A JP 2008-234142 A

  By the way, when other programs are corrected in relation to the program that caused the abnormal termination of the job, it may be necessary to re-execute from a state before the abnormally terminated program. In this case, the program, the input file, and the output file can be confirmed by the process chart. However, it takes time and effort to return the input file and the output file to a state in which the desired program can be re-executed.

  In the above Patent Documents 2 to 5, although the job can be efficiently re-executed, it takes time and effort to re-execute from the program before the abnormally terminated program or from any program. It was.

  Therefore, the inventor of the present application selects a program to be re-executed (re-execution program) in the process table, and enters the state before execution of the re-execution program, that is, the state immediately before the re-execution program has been completed. If the file and the output file can be returned, the time and labor required to re-execute the job can be reduced.

  Therefore, the present invention solves the above-described problem, and at the time of abnormal termination of a job that sequentially executes a program that performs processing using at least one of an input file and an output file, before executing the program selected in the process table An object of the present invention is to provide a job re-execution support system capable of returning an input file and an output file to a state.

In order to solve the above problems, the invention of claim 1 is directed to a program for performing processing using at least one of an input file and an output file, a job for sequentially executing a plurality of the programs , the program, A server device for registering a job, a change history storage means for storing a change history when it is detected that the program or job has been changed and registered in the server device, and when a failure occurs in the job In addition, when it is determined that the program has been changed based on the failure history storage unit that stores the failure content and the change history storage unit, the program is changed based on the source code of the program that has been changed and registered. There at least one of the input or output file used is shown for each of the programs, A step table creation means job including further the program creates a process chart illustrated in chronological, the state immediately before the program selected in the step table created by the process chart creating means is executed, input Job re-execution support, comprising: a job re-execution unit that returns a file and an output file, makes the program re-executable, and waits for input of a re-execution instruction for the selected program System.

According to this invention, the job re-execution means returns the input file and the output file to the state immediately before the program selected in the process table is executed, so that the program can be re-executed , Wait for input of re-execution instruction for the selected program .

  The invention according to claim 2 is the job re-execution support system according to claim 1, wherein when the program ends abnormally, the process table creation means illustrates the program abnormally ended in the process table. It is characterized by that.

According to a third aspect of the present invention, in the job re-execution support system according to the first or second aspect, if it is determined that the program is registered or changed based on the change history storage unit, the source of the program And a related diagram creating means for creating a related diagram illustrating the relationship between the program and at least one of the input file and the output file based on the code.

According to the first aspect of the present invention, when it is determined that the program has been changed based on the change history storage unit, the process including the changed program is illustrated in time series by the process table creation unit. Since the table is created, it is possible to accurately grasp the input file or output file of the program included in the job. For this reason, if a developer finds a bug in a program or the job ends abnormally, the developer can determine where to modify the program and where to re-execute the job by referring to the process chart. . Further, simply selecting a program to be re-executed in the process table makes the program re-executable by the job re-execution means, thus enabling efficient re-execution.

  Further, since the job re-execution is facilitated, it is possible to reduce the man-hours required for program development and testing that repeats the program correction and the job re-execution associated therewith. As described above, since the job can be easily re-executed, it is possible to reduce the man-hours required for the program development and the test in which the correction of the program and the accompanying job re-execution are repeated.

  According to the second aspect of the present invention, when the program is abnormally terminated, the process table creation means displays the abnormally terminated program in the process table, so that the abnormally terminated program can be confirmed at a glance. That is, since the abnormal end point is visually shown in the process chart, it becomes easy to grasp the relation between the program included in the job and the input file or the output file, and the correction point can be easily determined. As a result, it is possible to prevent mistakes and omissions in program corrections.

According to the third aspect of the present invention, when it is determined that the program has been registered or changed, the relation diagram illustrating the relation between the program and at least one of the input file and the output file by the relation diagram creation means. Therefore, it becomes easy to check the input file or output file for each program. As a result, it is possible to prevent mistakes and omissions in program corrections.

1 is a schematic configuration diagram of a job re-execution support system according to an embodiment of the present invention. FIG. 2 is a data configuration diagram of a template database of the job re-execution support system in FIG. 1. 3 is an example of a template database template of the job re-execution support system in FIG. 2, (a) is a program template, and (b) is an input file and output file template. FIG. 2 is a data configuration diagram of a change history database of the job re-execution support system in FIG. 1. FIG. 2 is a data configuration diagram of a failure history database of the job re-execution support system of FIG. 1. 3 is a flowchart showing a related diagram creation process by the job re-execution support system of FIG. 1. It is a flowchart which shows the process chart preparation process by the job re-execution support system of FIG. 3 is a flowchart showing job re-execution processing by the job re-execution support system of FIG. 1. 3 is a flowchart showing job re-execution verification processing by the job re-execution support system of FIG. 1. FIG. 2 is a flowchart showing an operation of a developer in charge of program correction using the job re-execution support system of FIG. 1 and processing in a development server. 2 is a part of a job code of the job re-execution support system in FIG. 1. FIG. 2 is a part of a program related diagram created by a related diagram creation process of the job re-execution support system of FIG. It is a part of computer processing process schedule created by the process schedule creation process of the job re-execution support system of FIG.

  The present invention will be described below based on the illustrated embodiments.

  1 to 13 show an embodiment of the present invention. The job re-execution support system 1 is a system that supports re-execution at the time of abnormal termination of a job that sequentially executes a program that performs processing using at least one of an input file and an output file. In this embodiment, the job re-execution support system 1 is activated by a development server (not shown). Further, it is assumed that jobs and programs are coded in, for example, JCL (Job Control Language). Here, JCL is defined so that one line is one statement, and when one statement extends over multiple lines, the last line is described as “,” (comma) and continued on the next line. .

  In this embodiment, specifically, a job JOB01 as shown in FIG. 11 will be described. The job JOB01 is composed of a plurality of programs PRG. For example, in the program PRG01, the preceding program is the program PRG99 and the succeeding program is the program PRG02. The program PRG01 uses a plurality of files DATASET1 to DATASETN as input files, sorts the acquired data, and outputs them as an output file (work file) DATASETWi. The relationship diagram 20 and the process chart 30 are used to grasp the relationship between such a job or program and an input file or output file.

  As shown in FIG. 12, the related diagram 20 shows the relationship between the program input file, the output file, and the program based on the code of the program. A file 22, a program 23, an output file 24, an article 25, and a subsequent program 26 are illustrated. Specifically, for example, the program PRG01 (JOBSTEP01) included in the job JOB01 as shown in FIG. 11 will be described. In FIG. 20, as shown in FIG. 12, an ID for identifying a job is displayed as job ID 21 as “JOB01”, data sets DATASET1 to DATASETN are illustrated as an input file 22, and a program for performing sort processing as a program 23 PRG01 (job step JOBSTEP01) is illustrated, and a data set DATASETWi is illustrated as the output file 24. Also, a sort key is displayed as the article 25, and JOBSTEP02 is illustrated as the subsequent program 26.

  As shown in FIG. 13, the process table 30 shows devices to be referred to and updated by programs in each program based on job codes, divided into cards, tapes, storage files, and work files. , Job No 31, program 32, job step 33, card / tape 34, saved file 35, and work file 36 are illustrated. Specifically, for example, a job JOB01 as shown in FIG. 11 will be described. An ID for identifying a job is displayed as job No 31 and “JOB01” is displayed as the program 32 and job step 33, for example, an ID for identifying a program and a job step is displayed as “PRG99 (job step JOBSTEP99)”. A data set DATASET 99 is illustrated as the save file 35.

  The job re-execution support system 1 mainly includes a template storage unit 11, a change history storage unit 12, a failure history storage unit 13, a change history management task 14, a failure history management task 15, and a related diagram creation unit. Related chart creation task 16, process chart creation task 17 as process chart creation means, job re-execution task 18 as job re-execution means, job re-execution verification task 19, storage unit 10 b, and control of these And a control unit 10a.

  The template storage unit 11 is for illustrating a relational diagram 20 and a process chart 30 to be described later from a program or job code, and a template database for illustrating the relational chart 20 and the process chart 30 for each statement type. 11a is stored. Here, the statement type is a type of statement sentence including “EXEC”, “DD”, “RTN”, and the like. As shown in FIG. 2, the template information database 11 a stores a name 112, acquired information 113, a template 114, and other 115 for each statement type 111. The statement type 111 stores a statement type, that is, a type of statement sentence including “EXEC”, “DD”, “RTN”, and the like. The name 112 stores the name of the statement type 111. For example, “program execution”, “data definition”, “return value”, and the like are stored for each statement type 111. The acquisition information 113 stores information acquired from the statement and illustrated in the related diagram 20 and the process chart 30. For example, when the statement type 111 is “EXEC”, the job step name and program name are stored. When the statement type 111 is “DD”, information described in the DD statement such as a data set name and device information is stored as data information. Further, when the statement type 111 is “RTN”, information described in the RTN statement, for example, KEY information is stored as return value information. The template 114 stores a template (template) used when the statement types 111 are illustrated in the related diagram 20 and the process chart 30. Information to be displayed as a character string is also stored in these figures. For example, when the statement type 111 is “EXEC”, the figure representing the program as shown in FIG. 3A, the program ID (job step ID), and the illustration of the processing contents are stored. In addition, when the statement type 111 is “DD”, it is stored that a figure representing a file as shown in FIG.

  The change history storage means 12 stores a program change history database 12a. As shown in FIG. 4, the change history database 12 a stores a change date 124, a change content 125, and other information 126 for each job ID 121, program ID 122, and version 123. The job ID 121 stores a job ID, the program ID 122 stores a program ID, and the version 123 stores a version of the program. The change date / time 124 stores the date / time when the program was changed, and the change content 125 stores change information of the program, that is, change information including the correction location, the correction content, the corrector, and the like. The change history database 12a is updated by a change history management task 14 described later.

  The failure history storage unit 13 stores a failure history database 13a of a failure that has occurred in a job. As shown in FIG. 5, the failure history database 13 a stores a failure occurrence date / time 131, a job ID 132, a program ID 133, a failure content 134, a failure response content 135, and other 136. The failure occurrence date / time 131 stores the date / time when the failure occurred in the job, the job ID 132 stores the job ID, and the program ID 133 stores the program ID. The failure content 134 stores the content of the failure that has occurred, the occurrence event of the failure, the cause of the failure, and the start date and time of the job. The failure response content 135 stores the job, program, A correction location, a pointer to the change history database 12a, and the like are stored. The failure history database 13a is updated by a failure history management task 15 described later.

  The change history management task 14 is a program having a function of updating the job ID 121, program ID 122, version 123, change date 124, and change content 125 of the change history database 12a when the program is changed. The change history management task 14 constantly monitors that the JCL, which is the job source code, is registered in a predetermined storage location, for example, a development server, and updates the change history database 12a when JCL registration is detected. The process is started. At this time, a change content is generated from a comment indicating a correction portion described in the code and a difference from the previous version of the program and stored in the change history database 12a.

  The failure history management task 15 is a program having a function of updating the failure occurrence date / time 131, the job ID 132, the program ID 133, the failure content 134, and the failure handling content 135 of the failure history database 13a when a failure occurs. It is. The failure history management task 15 constantly monitors the return value of the program or job, the log file, the update status of the file, etc. When it detects that the program or job has ended abnormally, the return value, log file, A process of generating a failure content from the update status of the file and registering it in the failure history database 13a is started.

  The relationship diagram creation task 16 is a program having a function of creating a relationship diagram 20 as shown in FIG. 12 by illustrating the relationship between the program, the input file, and the output file based on the code of the program. The related diagram creation task 16 constantly monitors that the JCL is registered in a predetermined storage location, for example, a development server, and when the JCL registration is detected, it is changed in the program included in the JCL. It is controlled by the control unit 10a so as to start processing for creating a related diagram of the program. Here, whether or not the program is changed is determined based on whether or not update data corresponding to the change history database 12a exists. The presence / absence of corresponding update data is determined, for example, when the update date / time is within a predetermined time from the current time, and corresponding update data exists.

  The related diagram creation task 16 has a function of acquiring the code of the changed program and showing the corresponding template based on the template database 11a for each statement, and processing based on the flowchart shown in FIG. I do. First, the program code is acquired (step S11), one statement is acquired (step S12), and it is determined whether or not the statement is an input file, that is, whether or not the statement is a DD statement ( Step S13). In the case of an input file (in the case of “YES”), an input file or an output file is illustrated (step S14). That is, from the template database 11a, data with the statement type 111 being “DD” is acquired, and the acquisition information 113 is the data set name, unit classification, and the template 114 is acquired. Then, based on the acquired template 114, a disk classification or the like is illustrated based on the statement in a graphic representing a file as shown in FIG. When it is not an input file (in the case of “NO”), the statement information is illustrated. That is, from the template database 11a, data with a statement type 111 other than “DD”, for example, data with “EXEC” is acquired, and the acquisition information 113 is a job step name, program name, template 114, and the like. To do. And based on the acquired template 114, program ID (job step ID) and the processing content are illustrated in the figure showing the program as shown to Fig.3 (a).

  Then, the presence / absence of the next statement is determined (step S16). When the next statement exists (in the case of “YES”), the process returns to step S12, and the processing of step S12 to step S16 is repeated for all statements.

  If the next statement does not exist (in the case of “NO”), the processing of this task is terminated.

  Here, for example, a program “PRG01” as shown in FIG. 11 will be described. First, the program “PRG01” has a comment “// ** UPD YYYYMMDD” at the top, which indicates that the program is changed. In addition, a change history corresponding to this change is stored in the change history database 12a. From the statement on the first line, “JOB01” is illustrated in the job ID 21 of FIG. Then, from the statement of the EXEC statement, what is displayed as “PRG01 (JOBSTEP01)” on the graphic representing the program as shown in FIG. Then, from the statements of a plurality of DD statements, that is, from the line of DD = SORTIN to DD = SORTOUT, to the input file 22 and the graphics representing the file as shown in FIG. The display is illustrated. Then, from the statement of the DD sentence, that is, from the line of DD = SORTWi, the output file 24 is displayed with “DATASETWi” displayed on the graphic representing the file as shown in FIG. Then, “’ c1, c2,..., “D2, d2,...” Is displayed in the KEY information 25 from the statement of the RTN sentence. Then, “JOBSTEP02” is displayed in the next job step 26 from the statement of the next EXEC statement. Then, arrows are shown from the input file 22 to the program 23, from the program 23 to the output file 24, and from the output file 24 to the next job step 26.

  Thus, based on the code of the changed program, a related diagram 20 of the program, the input file, and the output file is created.

  The process chart creation task 17 has a function of creating a process chart 30 as shown in FIG. 13 which shows input files and output files of a plurality of programs included in a job for each program based on the code of the program. It is a program that has.

  The process chart creation task 17 is controlled by the control unit 10a so that it is started when the related diagram creation task 16 is finished. That is, processing is performed for the JCL that has been changed and registered.

  The process chart creation task 17 performs processing based on the flowchart shown in FIG. First, the job code is acquired (step S21), and the job is shown in the process chart (step S22). That is, the job ID acquired from the job code is displayed in job No31. And a program is acquired (step S23) and a program is illustrated in a process table (step S24). That is, the program ID and job step ID acquired from the program code are displayed in program No. 32 and job step No. 33. A device is illustrated for the program (step S25). Specifically, the program code is acquired and acquired one statement at a time, and it is determined whether or not the statement is a data definition statement (DD statement). In the case of a data definition statement (in the case of “YES”), the device is illustrated. At this time, when the device is a card / tape, the card / tape 34 is illustrated with a predetermined template, when the device is a storage file, the storage file 35 is illustrated with a predetermined template, and when the device is a work file. The work file 36 is illustrated with a predetermined template. When it is not a data definition sentence (in the case of “NO”), statement information, for example, KEY information is illustrated in the article 37. Then, the presence / absence of the next statement is determined. When the next statement exists (in the case of “YES”), the same processing is repeated for all the statements. When the next statement does not exist (in the case of “NO”), the process proceeds to step S26.

  Then, the presence or absence of the next program is determined (step S26). When the next program exists (in the case of “YES”), the process returns to step S23 to repeat the processes in steps S23 to S26 for all the programs. When the next program does not exist (in the case of “NO”), The processing of this task is finished.

  Here, for example, a job “JOB01” as shown in FIG. 11 will be described. This job includes a plurality of EXEC statements and is composed of a plurality of programs. First, “JOB01” is described in job No. 31 in FIG. 13 from the statement on the first line. Then, “PRG99” is described in the program 32 and “JOBSTEP99” is described in the job step 33 from the statement of the first EXEC statement. Then, a diagram in which “DATASET99” is displayed as a graphic representing the saved file is shown in the saved file 35 from the statement of the DD sentence.

  Next, from the second EXEC statement statement, “PRG01” is described in the program 32 and “JOBSTEP01” is described in the job step 33. Then, a plurality of DD statement statements, that is, the ones displaying “DATASET1” to “DATASETN” on the graphic representing the saved file from the line of DD = SORTIN to DD = SORTOUT are shown. Then, from the statement of the RTN sentence, the article 37 is illustrated as “’ c1, c2,..., “,“ D2, d2,.

  Next, “PRG02” is described in the program 32 and “JOBSTEP02” is described in the job step 33 from the statement of the next EXEC statement.

  Such processing is repeated for each statement of the program, and the job process table 30 including the changed program is created.

  In addition, the process table creation task 17 has a function of displaying the process that has been terminated abnormally in the latest created process table 30 when the program has terminated abnormally. In addition, the control unit 10a controls the function to be activated.

  The job re-execution task 18 can return to the state of the input file and output file immediately before the program (re-execution program) selected in the process table 30 and re-execute the re-execution program when the job ends abnormally. It is a program having a function to make a state. Here, backups of all input files and output files are stored in the storage unit 10b, and can be recovered to a state before starting the job. The job re-execution task 18 is controlled by the control unit 10a so as to be activated when a program is selected in the process chart 30.

  The job re-execution task 18 performs processing based on the flowchart shown in FIG. First, the job code is acquired (step S31), and the state of the input file and the output file in the state where the program immediately before the re-execution program is completed is returned (step S32).

  That is, from the job code and the process table 30, the devices used at the abnormal end of the job, that is, the input file and the output file, and the devices used up to the program immediately before the re-execution program, that is, the input file and Extract the output file. Then, delete the input file and output file at the time of abnormal end of the job from the predetermined folder, acquire the input file before the abnormal end of the job (immediately before starting the job) from the backup and save it in the predetermined folder Then, the job that has ended abnormally is made re-executable. Then, the program immediately before the re-execution program is re-executed. In this way, the state of the input file and the output file in the state in which the program immediately before the re-execution program is completed is restored.

  Then, the development staff is notified that the input file and the output file have returned to the state in which the program immediately before the re-execution program has ended, and the input of the “continuation command” from the development staff is awaited (step S33).

  If the “re-execution instruction” is input from the developer (in the case of “YES”), the job is re-executed from the re-execution program (step S34).

  The job re-execution verification task 19 is a program that is controlled by the control unit 10a to be activated after the job is re-executed by the job re-execution task 18, and has a function of verifying whether the job is correct.

  The job re-execution verification task 19 performs processing based on the flowchart shown in FIG. First, the code before the job is re-executed (at the time of abnormal termination) and after the re-execution (after correction), the difference between the input file and the output file is acquired (step S41), and the code before and after the job is re-executed The presence or absence of the difference is determined (step S42). When it is determined that there is a difference in the code (in the case of “YES”), the changed part is verified (step S43). Specifically, if there is a difference between the code and the input file or output file before and after re-execution, the input file or output file to be changed is predicted from the changed part of the code, and the changed input file or output file Determines whether there is a difference from the prediction. For example, when there is no difference, it is output that the job is correct, that is, the correction is correct, and when there is a difference, it is output that the job is not correct, that is, the correction is insufficient. Then, the code, the difference between the input file or the output file and the determination result before and after re-execution of the job are output (step S44).

  If it is determined in step S42 that there is no difference in code (in the case of “NO”), the difference between the input file or the output file and the fact that there is no change in the code are output (step S45). Here, in this case, the input file is corrected and re-executed, and only when there is a difference in the input file or the output file, whether the job has ended normally and the output file has been output correctly To check. Specifically, it is checked whether there is a difference between output files before and after the job is re-executed.

  The storage unit 10b stores information and work acquired by the change history management task 14, the failure history management task 15, the relationship diagram creation task 16, the process chart creation task 17, the job re-execution task 18, and the job re-execution verification task 19. Stores files and the like.

  Next, information processing means and operation in the job re-execution support system 1 having such a configuration will be described. Here, a case where one program PRG01 in the job JOB01 is modified will be described.

  First, as shown in FIG. 10, the development person M modifies the program PRG01 (step S51). When the repair is completed, the program PRG01 is registered in the development server, and an execution command for the job JOB01 is issued. Further, when the program PRG01 is registered, the change history database 12a is updated by the change history management task 14 (step S52), and the related diagram 20 is created by the related diagram creation task 16 (step S53). Further, the process chart 30 is created by the process chart creation task 17 (step S54).

  Then, job JOB01 is executed (step S55), and the execution result (normal / abnormal) is notified. Here, the job JOB01 ends abnormally, the failure history management task 15 is activated, and data is added to the failure history database 13a (step S56). Further, the development person M is notified together with the process chart 30 that the job JOB01 has ended abnormally. At this time, when the person in charge of development M refers to the process chart 30, the program PRG01 abnormally terminated in the process chart 30 by the process chart creation task 17 is displayed in red (step S57).

  Then, the development person M confirms and corrects the program PRG01 (step S58). When the correction is completed, the failure handling content 135 in the failure history database 13a is updated.

  The corrected program PRG01 is registered in the development server. When the program PRG01 is registered, the change history database 12a is updated by the change history management task 14 (step S59), and the related diagram 20 is created by the related diagram creation task 16 (step S60). Further, the process chart 30 is created by the process chart creation task 17 (step S61).

  Then, the development person M issues an execution command for the job re-execution task 18 with the program PRG01 selected in the process chart 30.

  When the job re-execution task 18 is executed (step S62), the input file and the output file are returned to the state where the program PRG99 immediately before the program PRG01 is finished, and the result of the task is waited for from the developer M. Stop processing.

  Then, the development person M confirms that the input file and output file have been confirmed and processed correctly, that is, the program PRG01 is in a re-executable state (step S63). OK (re-execution instruction) is issued.

  Then, the job re-execution task 18 is resumed, and the job is re-executed from the program PRG01 (resumption of step S62).

  Then, the job re-execution verification task 19 is activated (step S64), and the result is output.

  The developer M confirms the result of the job re-execution verification task 19 and repeats the processing from step S58 to step S64 until there is no problem with the program.

  As described above, according to the job re-execution support system 1, when the JCL is registered in the development server, the process chart 30 is created by the process chart creation task 17, and the related chart 20 is created by the related chart creation task 16. Is done. For this reason, if a person in charge of development finds a problem in the program or the job ends abnormally, the developer can determine the correction part of the program or the re-execution part of the job by referring to the process chart 30. it can. In addition, simply selecting a program to be re-executed in the process table 30 makes the program re-executable by the job re-execution task 18, so that efficient re-execution is possible.

  Further, since the job re-execution is facilitated, it is possible to reduce the man-hours required for program development and testing that repeats the program correction and the job re-execution associated therewith. As described above, since the job can be easily re-executed, it is possible to reduce the man-hours required for the program development and the test in which the correction of the program and the accompanying job re-execution are repeated.

  Further, when the program ends abnormally, the process table creation task 17 displays the abnormally ended program in the process table 30, so that the abnormally ended program can be confirmed at a glance. That is, since the abnormal end point is visually shown in the process table 30, it becomes easy to grasp the relationship between the program included in the job and the input file or the output file, and the correction point can be easily determined. This makes it possible to prevent mistakes and omissions in program and file correction locations.

  Further, since the relationship diagram creation task 16 creates a relationship diagram 20 illustrating the relationship between the program and at least one of the input file and the output file, it is possible to confirm the input file or the output file for each program. It becomes easy. As a result, it is possible to prevent mistakes and omissions in program corrections.

  Although the embodiment of the present invention has been described above, the specific configuration is not limited to the above embodiment, and even if there is a design change or the like without departing from the gist of the present invention, Included in the invention. For example, in the above embodiment, the job and the program have been described as being coded in JCL, but it is needless to say that other languages may be used.

  Further, the job re-execution task 18 can be executed even when the input file is inconsistent, for example, other than when the job is abnormally terminated. Specifically, after the input file is replaced with a correct one and an instruction to execute the job re-execution task 18 is issued in a state where a program using the input file is selected in the process table 30, the job re-execution task 18 Thus, the program can be re-executed, that is, the program can be re-executed with a correct input file.

DESCRIPTION OF SYMBOLS 1 Job re-execution support system 11 Template storage means 12 Change history storage means 13 Failure history storage means 14 Change history management task 15 Failure history management task 16 Related figure creation means (related figure creation task)
17 Process chart creation means (process chart creation task)
18 Job re-execution means (job re-execution task)
19 Job Re-execution Verification Task 20 Program Related Diagram (Related Diagram)
30 Computer Processing Schedule (Schedule)

Claims (3)

A program that performs processing using at least one of an input file and an output file;
A job for sequentially executing a plurality of the programs;
A server device for registering the program and the job;
A change history storage means for storing a change history when it is detected that the program or job has been changed and registered in the server device;
Fault history storage means for storing fault contents when a fault occurs in the job;
If it is determined that the program has been changed based on the change history storage means, at least one of an input file and an output file used by the program based on the source code of the program that has been changed and registered Is created for each program, and a process table creating means for creating a process chart in which a job including the changed program is illustrated in time series ,
The input file and the output file are returned to the state immediately before the program selected in the process table created by the process table creating unit is executed, and the program is selected to be re-executable . Job re-execution means waiting for input of a program re-execution instruction ;
A job re-execution support system comprising: The process chart creation means illustrates the program that has ended abnormally in the process chart when the program ends abnormally,
The job re-execution support system according to claim 1. When it is determined that the program is registered or changed based on the change history storage unit, the relationship between the program and at least one of the input file and the output file is illustrated based on the source code of the program. A related diagram creating means for creating a related diagram;
The job re-execution support system according to claim 1 or 2, further comprising:

Images