JP3516049B2 - Batch job control system - Google Patents

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a batch job control system in which a plurality of hosts cooperate to execute a batch job.

[0002]

2. Description of the Related Art Conventionally, a batch job control system, as shown in FIG.
Here, there are an A system (main system) and a B system (slave system), and when controlling both of them, each host has one schedule file that manages the job execution sequence of each host I will share it with you. On the other hand, the execution management means for controlling the execution of the job is placed in each host, refers to the schedule file, determines the job scheduled as the job of its own host, fetches it, and executes it. The configuration and operation of FIG. 8 will be briefly described below.

FIG. 8 shows an explanatory view of the prior art. In FIG. 8, the A system (main system) and the B system (slave system) are hosts provided at the same site.

The schedule file is provided in the shared volume and stores the scheduled contents of jobs executed by the A system and the B system. The execution management means is provided in each of the A system and the B system, and exclusively refers to the schedule file on the shared volume to take out and execute the job scheduled to the own system.

The schedule creating means is provided in the A system of the main system, refers to the master file to schedule jobs of the A system and B system in advance, and stores them in the schedule file.

Next, the operation of the configuration shown in FIG. 8 will be described. (1) The execution management means of the A system acquires the occupancy of the schedule file on the shared volume, refers to the job of the own system, and releases it. Then, the job of the self system is taken out.

(2) The B-system execution management means is similarly operated. At this time, the schedule file waits until the other releases when one acquires and occupies the exclusion.

[0008]

As described above, under the conventional configuration of FIG. 8, since the job schedules of all hosts are registered in the schedule file on the shared volume, each host (system A) , B system) must acquire and occupy the exclusive of the schedule file, respectively, and then find and retrieve the schedule of the job of the searched own system, and the number of jobs to be searched increases as the number of hosts increases, There is a problem that it takes a lot of time to search and it is difficult to process quickly.

Further, since only one schedule file is arranged on the shared volume, when a plurality of hosts simultaneously make an exclusion acquisition request, the hosts other than the host that acquired the exclusion are kept waiting. In the case of executing a large number of jobs in succession, there is a problem that the occupied time increases, the release is delayed, and another host is made to wait by that amount.

Further, if a host goes down for some reason in the state where the host has acquired and occupied the schedule file, the schedule file remains locked and is not released. I cannot access the schedule file of
There was also a problem that the whole thing went down.

The present invention solves these problems.
A schedule file is provided in each host, and a contact file that does not require exclusion is also provided between the hosts. In accordance with the schedule file in each host, the contact files are used to communicate with each other to execute jobs sequentially. In addition to enabling independent execution without being affected by the operating status of each host, each host has only its own job schedule to reduce the search load, and the reliability of batch operation in cooperation with multiple hosts And to improve overall efficiency.

[0012]

[Means for Solving the Problems] Means for solving the problems will be described with reference to FIG. In FIG. 1, host 1
Is for executing jobs in batch in cooperation with each other.
Here, there are an A system and a B system, which are management means 2, respectively.
And a schedule file 5 and the like.

The management unit 2 manages a job schedule by referring to the schedule file 5, and reads out execution information (information about execution results and succeeding jobs) from the communication file 9 addressed to the own system. The execution information is written in the contact file 9 for contact.

The schedule file 5 stores the schedule of a job to be executed in its own system. The contact file 9 is for notifying execution information.

[0015]

In the present invention, as shown in FIG. 1, the management means 2 uses the schedule file 5 and the contact file 9 addressed to the own system.
A job that can be executed is executed based on the execution information read from the server, and the execution information is written in the file 9 for contacting the host that executes the subsequent job. The management means 2 which has read the execution information from the contact file 9 refers to the schedule file 5 of its own system and executes the succeeding job when the turn comes.

At this time, the contact file 9 is written by only one host of the contact source and read by one or more hosts of the contact destination, and exclusion is unnecessary. Also, the contact file 9 provided in the common area is used as a fixed area,
Exclusive control for expanding is not generated when the area of the communication file 9 is insufficient.

The contact file 9 provided in the common area
The management means 2 reads out the execution information from the host 9 at a predetermined time from the communication file 9 addressed to the host. Therefore, a schedule file 5 is provided in each host, a contact file 9 that does not require exclusive access for communication is provided between the hosts, and the contact file 9 is used between the hosts according to the schedule file 5 in each host. By communicating with each other and executing jobs sequentially, jobs can be executed independently without being affected by the operating status of each host, and each host has only its own job schedule to reduce the search load. Therefore, it is possible to improve the reliability and overall efficiency of batch operation in which multiple hosts cooperate.

[0018]

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Next, the construction and operation of an embodiment of the present invention will be sequentially described in detail with reference to FIGS.

FIG. 1 shows a block diagram of an embodiment of the present invention.
In FIG. 1, the host 1 executes jobs in batch in cooperation with each other. Here, there are an A system and a B system at the same site, and a management unit 2, a schedule file 5, and a schedule creation unit 6 are respectively provided. , System starting means 7
It is composed of etc.

The management means 2 manages a job schedule by referring to the schedule file 5, and is composed of an information reflection means 3 and an execution management means 4.

The information reflecting means 3 reads the execution information including the job execution result and the succeeding job from the contact file 9 of the host that executes the preceding job, and reflects the execution information in the schedule file 5 for its own system. Is.

The execution management means 4 executes a job that can be executed by referring to the schedule file 5, reflects the execution result in the schedule file 5, and writes the execution information in the communication file 9 for own system. is there.

The schedule file 5 is a file in which the schedule of the own system job is registered. The schedule creating means 6 searches the master file 12 in the shared area on the shared volume 10 at the beginning of starting, retrieves all the schedules of jobs scheduled to be executed by the own system, and creates a schedule file in the own system. 5 is to be stored.

The system starting means 7 refers to the status file 11 in the common area to initialize the communication file 9 for the own system, or when the preprocessing of the own system is completed and the system is in the operating state. Is set (updated) in the status file 11 to start the own system.

The shared volume 8 is a volume provided in a shared area accessible by each host, and here, a communication file 9 for each host is provided. The contact file 9 is provided exclusively for each host, and is written only by the contact source host and read by the contact destination host, without the need for exclusion. By eliminating this exclusion, other hosts will not be kept waiting when executing information is communicated between hosts, and
This eliminates the problem that a failure occurs when one host acquires exclusive control, and other hosts cannot refer to it and operation stops.

The shared volume 10 is a volume provided in a shared area accessible by each host. Here, the status file 11 and the master file 1 are used.
2 is provided.

The status file 11 sets the status of each host (stopped, operating, etc.). The master file 12 is a file in which all schedules of jobs executed by each host are registered.

Next, according to the order shown in the flowchart of FIG. 2, the operation from the start-up to the operation and the stop from the operation of the configuration of FIG. 1 will be described in detail. Here, since the A system and the B system of FIG. 1 perform similar processing, only the A system will be described.

In FIG. 2, S1 creates a schedule. This is because the schedule creating means 6 of FIG. 1 extracts a job operating on the host (system A) from the shared master (master file 12 in the shared area) and stores it in the schedule file 5 within the system.

At S2, IPL is performed. The IPL is performed by the host (system A) in FIG. In S3, the communication file (for A system) in the fixed area is initialized. To do this, the system starting means 7 of the A system of FIG. 1 refers to the status file 11 of the common area, acquires the communication file 9 for the A system as a fixed area in the common area, and performs initialization.

In step S4, the own host (system A) information in the shared status file 11 is updated to "initialized". S5
Checks the status of other hosts. This means that the system starting means 7 of system A in FIG.
Check the status of the host of the system. If it is determined that the other host (system B) has been initialized, the process proceeds to S7.
On the other hand, if it is determined that the other host (system B) has not been initialized, the host of the other party to be linked has not been initialized, and the process stands by (S6).

In step S7, the execution management / information reflection means starts operating. As a result, the execution management unit 4 executes the job that can be executed by referring to the schedule file 5 and the execution information read from the communication file 9 for the local system, and the execution information including the execution result and the succeeding job. Is written in the contact file 9 of the host which executes the subsequent job by the information reflecting means 3 and contacts.

In S8, the jobs are sequentially executed according to the schedule by the execution management / information reflecting unit in S7, and the operation is started. S9:
The own host (system A) information in the shared status file 11 is updated to "not initialized".

At S10, the system is stopped. As described above, when the power of the host 1 is turned on, the schedule of the job executed by the local host is extracted from the master file 12 in the shared area and stored in the schedule file 5 within the local host.
Create a fixed area contact file 9 in the IPL and the common area, and refer to the status file 11 in the common area to operate when another host to be linked is in an executable state (initialization of the contact file) To start. When the operation is stopped, the status file 11 in the common area is set to "not initialized" and the operation is stopped. With these, each host
Even if another host fails and stops, it becomes possible to independently execute the job by referring to the schedule file 5 in the local host, and the execution information is sent to the host of the succeeding job using the contact file. It becomes possible to communicate and continue processing.

Next, the operation during operation will be described in detail with reference to FIG. FIG. 3 shows an operation explanatory flowchart (during operation) of the present invention. Here, since the A-system and B-system of the host operate exactly the same, the operation will be described here for only the A-system host.

In FIG. 3, in step S21, a job that is executable (all preceding jobs are completed) and has a status of "unexecuted" is extracted from the schedule file and activated. For example, referring to the A-system schedule file 5 of FIG. 6A, which will be described later, all of the preceding jobs have ended (here, it is assumed that all the preceding jobs have ended), and as an “unexecuted” job, "JOB1" is extracted and activated.

In step S22, the job is executed. This is S
For example, "JOB1" started in step 21 is executed. S2
3 changes the status of the schedule file 5 to "finished" for the finished job. This is for example S22
The "JOB1" executed in step 1 ends and the end job "J"
The status of "OB1" is changed to "end" (the status of the job name "JOB1" in FIG. 6A is changed from "not executed" to "end").

A step S24 decides whether or not there is a succeeding job of the host. This is, for example, the succeeding job “JOB3” of the end job “JOB1” of FIG.
System 3) JOB 3) is present. If yes,
In S25, the preceding job information (finished job) of the schedule file 5 is updated to "finished" for the succeeding job in the host. This is, for example, the preceding job "JOB" in the preceding job information of the job "JOB3" in FIG.
The status of "1" is updated to "end".
Go to 6. On the other hand, if the answer is NO in S24, the process proceeds to S26.

In step S26, it is determined whether there is a succeeding job from another host. This is, for example, the succeeding job “JOB2” of the end job “JOB1” of FIG.
System 2) JOB 2). If yes,
In S27, the end data of the end job is sent to the host (system A)
Stored in the contact file for communication. This is the contact file for the local host (system A) that contains the termination data (execution result) of the terminated job and the execution information, and a contact file for writing to the local host (system A) of the contact. Write and notify. Then, the process proceeds to S28. On the other hand, if the answer is NO in S26, the process proceeds to S28.

In step S28, the contact file for another host (system B) is periodically checked to extract new end data. This is the end data (execution information consisting of the execution result and the succeeding job information) written in the communication file 9 addressed to the B-system host from the A-system host in S27.
Is periodically read by the B-system host by polling.

In step S29, the preceding job information (for the finished job) in the schedule file 5 is updated to "finished" for the corresponding succeeding job based on the finish data. This allows
This means that the fact that the execution of the succeeding job notified from the A system host is completed in the communication file has been updated to the B system schedule file 5 as completed. Then, the process returns to S21, and the process of taking out and executing an executable job subsequent to the completed job is repeated.

As a result, of the jobs executed by the local host registered in the schedule file 5 in each host, those that can be executed are executed, and those that cannot be executed are polled in the contact file 9 to execute the preceding job. Execute when is completed. At this time, since each host has the schedule file 5 inside, it is possible to execute jobs independently, and a communication file 9 is provided for each host so that one host can write data and another host can read data exclusively by one-way communication. Since the communication is performed bidirectionally without the need for control, it avoids waiting for exclusion or stopping the execution of jobs on all hosts due to being unable to operate while a certain host has acquired exclusion. It has become possible.

FIG. 4 shows a job network diagram (part 1) between hosts according to the present invention. This is, as shown,
FIG. 3 is a schematic diagram showing a case where there is a preceding job of JOB2 as JOB1 in the system.

As an expected job network, as shown in the figure, JOB1 is executed in the A system, and the execution result and the succeeding job "JOB2" are notified to the B system.・ As the registration contents, as shown in the figure, JOB1 → JOB2 (B system) is registered in the schedule file (A system) 5, and JOB1 (A system) → JOB2 is registered in the schedule file (B system) 5. That is, it is registered in the schedule file 5 of the A system that the succeeding job of JOB1 is scheduled to be executed in the B system by JOB2. The preceding job of JOB2 is JO in the schedule file 5 of B system.
Register that B1 is scheduled to be executed in the A system.

FIG. 5 shows an example of a schedule file.
In this example, the A system in the example of FIG. 4 is registered in the schedule file (A system) of FIG. 5A, and the B system is registered in the schedule file (B system) of FIG. 5B. .

FIG. 5A shows a schedule file 5 for system A. Initially, the following registration is performed as shown in the figure. Predecessor job information Subsequent job information Job name Status Job name Host ID Status Job name Host ID JOB1 Not executed --- JOB2 B system This is the A schedule file 5 of FIG. 4 described above.
The job name is "JOB1" and the job is unexecuted, and the succeeding job is "JOB2" and is scheduled to be executed in the "B system".

FIG. 5B shows the B-system schedule file 5. Initially, the following registration is performed as shown in the figure. Predecessor job information Subsequent job information Job name Status Job name Host ID Status Job name Host ID JOB2 Not executed JOB1 A system not executed --- This is the schedule file 5 of B system in Fig. 4 described above.
The job name is "JOB2", the job is unexecuted, and the preceding job is "JOB1" and the job is scheduled to be executed by "A system".

FIG. 7 shows an example of the contact file of the present invention. This is an example of the contact file 9 to be written when the A system contacts the B system in FIG. Here, the execution management means 4 of the A-system host writes in the communication file 9 for the subsequent job as shown below, and the information reflection means 3 of the B-system host of the subsequent job reads it by polling. It is a thing.

Subsequent job information End job name Job name Host ID JOB1 JOB2 B system This is the end job "JOB1" and the succeeding job "J".
The file is set in the contact file 9 and sent to the host B system of OB2 ″.

[0050]

As described above, according to the present invention,
Schedule file 5 is provided in each host,
A contact file 9 that does not require exclusive access for hosts is provided, and according to the schedule file 5 in each host, a contact file 9 is used to communicate between the hosts and jobs are sequentially executed. As a result, jobs can be executed independently without being affected by the operating status of each host, and each host has only the schedule of jobs to be executed by its own system to reduce the search load. It is possible to improve the reliability and overall efficiency of batch operation in cooperation with.

[Brief description of drawings]

FIG. 1 is a configuration diagram of an embodiment of the present invention.

FIG. 2 is a flowchart explaining the operation of the present invention.

FIG. 3 is a flowchart for explaining the operation of the present invention (during operation).

FIG. 4 is an example (1) of a job network between hosts of the present invention.

FIG. 5 is an example (2) of a job network between hosts of the present invention.

FIG. 6 is an example of a schedule file of the present invention.

FIG. 7 is an example of a contact file of the present invention.

FIG. 8 is an explanatory diagram of a conventional technique.

[Explanation of symbols]

1: Host 2: Management means 3: Information reflection means 4: Execution management means 5: Schedule file 6: Schedule creation means 7: System starting means 8, 10: Shared volume 9: File for contact 11: Status file 12: Master file

─────────────────────────────────────────────────── ─── Continuation of front page (72) Inventor Hiroko Mitori 8-4-10 Nishi-Kamata, Ota-ku, Tokyo Within Fujitsu Financial Systems Limited (56) Reference JP-A-6-131299 (JP, A) 58-2939 (JP, A) JP-A-8-6904 (JP, A) (58) Fields investigated (Int.Cl. ⁷ , DB name) G06F 15/00

Claims (4)

(57) [Claims] 1. In a batch job control system for executing jobs in cooperation with a plurality of hosts, a schedule file for each host that stores the conditions of a job executed by each host, and execution by each host based on the schedule file Execution information about the specified job is executed. If the contact file for each host and the execution information in the contact file of another host are read, and the execution conditions in the schedule file of the local host match, the corresponding job is executed. A batch job control system, comprising: 2. The batch job control according to claim 1, wherein the contact file is written by only one host of the contact source and read by one or more hosts of the contact address, and exclusion is unnecessary. system. 3. The contact file provided in the common area is used as a fixed area so that exclusive control for expanding when the contact file area is insufficient does not occur. 2. The batch job control system described in 2. 4. The host computer reads out the execution information of the contact file provided in the common area from the contact file addressed to its own system at a predetermined time interval. One of the batch job control systems.