There are several basic job execution patterns that are often used for job flows (order in which jobs are executed). By combining and applying these patterns, advanced processing can be achieved.
The following table explains some typical patterns. Design job flows by referring to these typical patterns.
Job flow pattern | Overview | |
|---|---|---|
Flow task |
| Is the most basic pattern, where jobs are executed in a sequence |
Conditional branching |
| Involves the flow to be branched based on the conditions specified beforehand |
Consolidate-and-branch |
| Requires waiting for multiple preceding jobs to finish before executing (AND condition), and then branching to multiple succeeding jobs |
Event wait |
| Involves evaluating multiple execution conditions with preceding jobs, and then executing a succeeding job if the condition for one of these jobs (logical OR condition) is met |
Layering |
| Requires layering the flow by registering another job flow as a single job There are two methods: registering the job flow as a child job net, and using a linked job net. |
Recovery job |
| Involves registering a job (known as the "recovery job") beforehand that will start if a certain job terminates abnormally If that job terminates abnormally, the recovery job will start automatically. |
This is the most basic type of job net. Use this job net to execute multiple jobs in a sequence.
An example is shown below.
If the preceding job terminates normally, the succeeding jobs are executed in a sequence.
This type of job net is used to specify a branching condition, causing the job flow to branch across different processing.
There are two types of branching:
Branching based on completion codes
Branching based on criterial jobs
Branching based on completion codes
If the preceding job terminates normally or pseudo-normally, it is possible to determine how to start the succeeding job based on the value of the completion code for the preceding job. To determine which job starts next, specify the range of completion codes, which will be used as the execution condition, on the subsequent jobs.
In the following example, a backup task is performed first, and then if the completion code (RC) is no more than 10, the work file is deleted and power is turned off. If the completion code (RC) is more than 10, the data is saved temporarily, an error notification is sent, and then power is turned off.
This method is useful for performing different tasks that depend on the execution results of the preceding job.
Multiple succeeding jobs can be specified for a single preceding job, but from the perspective of the succeeding jobs, there can only be one preceding job. If multiple succeeding jobs have been specified for a single preceding job, and if the preceding job terminates normally or pseudo-normally, all the succeeding jobs that meet the conditions for the completion code of the preceding job will be started. If there are no such jobs, no jobs will be started.
To branch succeeding processing using the completion code of the preceding job, you must configure the preceding job not to become "Abended" even if it has the completion code set as the branch condition. Refer to "4.3.2 Job Flow Operations" for details.
Information
Passed status
The status of a job when it does not start because its conditions are not met is referred to as the "passed status." Even if there are some "passed" jobs that remain without being executed, the job net will still terminate normally if all the other jobs (jobs whose status is not "passed") terminate normally.
The behavior of jobs when the succeeding job is determined based on the completion code of the preceding job is explained below by using the example of a job net with the configuration shown in the following figure.
If Job A terminates normally with the completion code "10", Job B will start because a completion code of 10 or less has been set as its execution condition. Job C will enter the passed status because its execution condition is not met. Job E, which waits only for Job C to terminate normally, will also enter the passed status automatically. As a result, Job F will wait only for Job D to terminate normally.
Job D will be executed if Job B terminates normally.
Job F will be executed if Job D terminates normally.
If Job F terminates normally with the completion code "5", both Job G and Job H will enter the passed status as their execution conditions are not met. Similarly, Job I will also enter the passed status because all of its preceding jobs are in the passed status. The job net will terminate normally if Job F terminates normally, even though there are still some jobs that are in the passed state.
Branching based on criterial jobs
Succeeding jobs can be determined after evaluating the execution results of the preceding job (such as whether an expected file has been created).
By branching the execution of the succeeding job based on the result of the evaluation, it is possible to perform particular processing only when the evaluation criteria are met. It is also possible to abnormally terminate a job net if the evaluation criteria are not met, or to use a recovery job to recover the situation.
In the following example, a backup task is performed first, and then the job net uses the "Determine backup file existence" job to evaluate whether the backup file exists.
The recovery processing is defined to execute if the completion code of the "Determine backup file existence" job is "1".
If the specified file exists, power will be turned off without executing the recovery processing. If the specified file does not exist, the recovery processing will be executed.
This method is useful for performing different tasks after evaluating the execution results of the preceding job.
The following criterial jobs evaluate the execution results of the preceding job:
Determine File Existence job
Determine Job Net Variable job
Check service status job
Check log file job
These jobs evaluate job net variables that have been set on the schedule server. These jobs cannot be executed as network jobs or distributed execution jobs. The default host name specified for a job net is ignored by the "Determine Job Net Variable" job, so that the job is executed as a local job.
This pattern involves waiting for multiple preceding jobs (linked using a logical AND condition) to finish, and then branching to multiple succeeding jobs.
This type of job net can be used in situations, such as when data is collected from various different locations and processed in a single location, and then the results are sent back to different locations. If wait with AND condition is set, the succeeding jobs that wait with AND condition wait for all preceding jobs to become "Completed" before they are executed.
In the following example, the job net receives all the sales data from three servers (Tokyo, Osaka, and Nagoya), and then updates the database. The job net then sends the updated data back to each server.
This type of job net can wait for any one of the preceding jobs linked with a logical OR condition, and then execute the succeeding job.
If an event wait job flow based on OR conditions is used, multiple execution conditions are evaluated for the preceding job and the succeeding job is executed if any one of these conditions is met.
In the following example, two jobs ("Wait for file" and "Wait for time") have been registered as preceding jobs that the succeeding job waits for.
When either of these conditions is met (when either the file is updated or the specified time is reached), the succeeding job is executed.
The following execution conditions can wait with OR condition:
File creation, deletion, and update (file size or update time)
Occurrence of a message event
Time
Lapse of a specified time period
Refer to ""Wait with OR" Condition" in the Systemwalker Operation Manager User's Guide for information on waiting for events using logical OR conditions.
It is possible to register another job net within a job flow. This is called "job net layering."
The job net where another job net is registered is called the "parent job net," while the job net registered with the parent job net is called the "child job net."
For layered job nets, the depth of a layer is expressed as the "N-th layer."
Layering job nets has the following advantages:
Visibility is improved
Appropriate layering makes the flow easier to understand and easier to monitor.
Job nets can be started in an order
The second job net can be made to wait until the first job net has terminated before the second job net starts, just as jobs can be arranged in job flows.
Number of jobs is reduced
A child job net is counted as a single job, so the total number of jobs is reduced.
The following example shows a processing sequence that performs aggregation processing (another job net) registered as a child job net.
Layering based on linked job nets
Job nets can also be layered using linked job nets.
A "linked job net" is a copy of a master linked job net, and is the definition information for the source master linked job net. A linked job net can be registered as a job in multiple job nets.
In the following case, for example, three linked job nets have been registered as jobs with Job net A and Job net B, and all the three linked job nets refer to the same master linked job net.
Child job nets cannot be shared between different parent job nets. Accordingly, if it is necessary to have a child job net that can be registered multiple times and shared between different parent job nets, consider using a master linked job net or a linked job net.
Refer to "4.4.1 Creating Job Nets that Can Be Shared as Jobs between Different Job Nets" for details.
Job nets can be layered up to five layers.
A child job net is counted as a single job in the job net where it has been registered. Up to 255 jobs can be registered in a job net, with each child job net being counted as one job.
There are several conditions that a job net must meet to be registered as a parent job net or a child job net. Refer to "Layering the Job Net" in the Systemwalker Operation Manager User Guide for details.
There are several conditions that a job net must meet to be registered as a master linked job net. Refer to "Registering Linked Job Nets" in the Systemwalker Operation Manager User Guide for details.
A "recovery job" is a job that is started when another job terminates abnormally, such as when an error occurs midway through an operation. Recovery jobs can be registered in advance as jobs that deal with errors that may occur, for example. If a job terminates abnormally, the recovery job will start automatically.
If the causes of errors can be identified to a certain extent, and the procedure for responding to these errors is also determined, recovery jobs make it possible to respond to errors automatically.
In the following example, if an error occurs with the task of updating the sales database, the "Recover database" recovery job will start a program for recovering the database.
Additionally, if a recovery job terminates normally, the job that originally terminated abnormally can be restarted.
The following explains the behavior of recovery jobs using a job net with the configuration shown in the above figure.
If the "Update database" job terminates abnormally, the "Recover database" recovery job will be executed.
If the "Recover database" recovery job terminates normally, and there is a specification to restart the original job, then the original job ("Update database") will be restarted only once.
If the preceding job "Update database" terminates normally, the succeeding job "Stop database" will be executed.
If the succeeding job ("Stop database") terminates normally, the job net will terminate normally.
Note that the job net will terminate abnormally in the following cases:
If the "Recover database" recovery job terminates abnormally
If the "Recover database" recovery job does not have the specification to restart the original job
If the "Recover database" recovery job has the specification to restart the "Update database" job, and the "Recover database" recovery job terminates normally, but the "Update database" job once again terminates abnormally when it is restarted
Only one recovery job can be connected to each job.
A single recovery job cannot connect to more than one preceding job.
A regular job cannot connect to a recovery job as the succeeding job.
Waiting for events using a combination of OR and AND conditions
To create a job net that waits for events with a combination of both OR and AND conditions, use a "Dummy job" that simply terminates normally without actually doing anything but which links two or more event wait jobs with a logical OR condition. Then, create a succeeding job whose preceding jobs are the two jobs that you want to link using an AND condition. (In the following example, these two jobs are the "Dummy job" and the "Pre-processing" job.)
