2.4.3 Dynamically changing a process depending on the result of a preceding job (example of defining a jobnet that uses a judgment job)

Use a judgment job for a jobnet in which processing is to change dynamically depending on the results of the preceding job, on whether a file exists, or on the information inherited from the preceding job.

Organization of this subsection

(1) Example of using a judgment job
(2) Example of defining a jobnet that uses a judgment job
(3) Example of using a succession of judgment jobs
(4) Example of defining judgment jobs in parallel
(5) Cautionary notes

(1) Example of using a judgment job

JP1/AJS3 provides judgment jobs in which the next process is selected according to the end result of the preceding process. Judgment takes place according to the following two patterns:

Judgment based on return code
Judgment based on whether a file exists

The following provides examples of using each type of judgment job.

We also explain how to rerun a dependent unit if it ends abnormally.

(a) Judgment based on return code

The following figure shows an example of using a judgment job that works with return codes.

The jobnet created in this example creates a purchase order form if the stock level is low, or an order entry form if there is adequate stock, depending on the execution result of a job that checks the stock level.

Figure 2‒67: Example of using a judgment job that works with return codes

The stock check job returns 3 or a lower value if there is adequate stock, 4 if the stock level is low, and 5 or higher if there is a stock shortage.

By creating a processing flow like that in the figure above, you can execute the following processing:

When there is adequate stock

The return code is 3 or lower. Therefore, the create purchase order form job is skipped and the create order entry form job is executed.
When the stock level is low

The return code is 4. Therefore, the create purchase order form job is executed first, followed by the create order entry form job.

(b) Judgment based on file presence or absence

The following figure shows an example of using a judgment job based on the presence or absence of a file.

Figure 2‒68: Example of using a judgment job based on the presence or absence of a file

By creating a processing flow like that shown in the figure above, you can also detect abnormalities in other processing (commands) executed in the executable file lenchk, and execute the dependent job dataput.

Note that judgments based on the presence or absence of files are used to check files at the host where the work task manager (JP1/AJS3 - Manager) is installed. Depending on the environment settings, you might be able to check the presence or absence of files on other hosts. However, because communication problems or other issues can make the result of the judgment potentially unreliable, we recommend that judgments based on the presence or absence of files specify files on the manager host. For details, see 3.1.1(1)(c) Judgment job in the manual JP1/Automatic Job Management System 3 Overview.

(c) Rerunning dependent units

Dependent units are rerun differently than normal units. For precautions on rerunning dependent units, see 4.5.11 Rerunning a job or jobnet in the manual JP1/Automatic Job Management System 3 Overview.

To Page Top

(2) Example of defining a jobnet that uses a judgment job

In the example below, a judgment job is used to define a jobnet that creates a purchase order form if the stock level is slightly down, or an order entry form if there is adequate stock, depending on the execution result of a job that checks the stock level. If there is a definite stock shortage, the stock check job ends abnormally and a recovery job is executed. For details on recovery jobs, see 2.4.6 Executing a specific process when a job ends abnormally (example of defining a jobnet that uses a recovery unit).

Figure 2‒69: Example of defining a jobnet that uses a judgment job

In this example, the judgment depends on the return value of the preceding job. The stock check job returns 3 or a lower value if there is adequate stock, 4 if the level is slightly down, and 5 or higher if there is a stock shortage.

First, set Judgment by threshold as the end judgment of the stock check job. Set the warning threshold to 3 and the abnormal threshold to 4. With these settings, the stock check job is judged by its return value, and its status changes as follows:

Return value is 3 or lower: Ended normally
Return value is 4: Ended with warning
Return value is 5 or higher: Ended abnormally

Set the judgment job to execute a dependent job if the stock check job's return code equals the judgment value of 4.

Accordingly, the succeeding job of the stock check job is as follows:

When the return value of the stock check job is 3 or lower:

The return value does not match the judgment value of 4 set in the judgment job. Therefore, the dependent job create purchase order form is skipped and the create order entry form job is executed.
When the return value of the stock check job is 4:

The return value matches the judgment value set in the judgment job, so the dependent job create purchase order form is executed first. At normal termination of the dependent job, the create order entry form job is executed.
When the return value of the stock check job is 5 or higher:

A recovery job is executed. Because no succeeding job is executed in the event of an abnormal termination, the create order entry form job is not executed after the recovery job.

You can define two or more judgment jobs in succession. This allows you to define a number of processing paths equivalent to the number of defined judgment jobs, each depending on the end result of the preceding job.

The following explains how to use multiple judgment jobs.

To Page Top

(3) Example of using a succession of judgment jobs

You can define two or more judgment jobs in succession.

When you define multiple judgment jobs based on a return code, the second and subsequent judgment jobs evaluate the return code set in the preceding job of the first judgment job, not the return code of the dependent unit.

Conversely, when you define multiple judgment jobs based on the presence or absence of a file, the second and subsequent judgment jobs evaluate the file information current at the time they make their evaluation, not the file information current when the first judgment job performed its evaluation.

An example of defining a succession of judgment jobs is shown below.

Figure 2‒70: Example of using a succession of judgment jobs

Suppose that each unit is defined as follows:

Standard job A: End judgment is set to Judgment by threshold, and 5 is entered in the Warning field
Judgment job B: The judgment type is Return code = judgment value., and 0 is specified for Judgment value.
Judgment job C: The judgment type is Return code = judgment value., and 4 is specified for Judgment value.

When you execute this jobnet, the return value of standard job A determines the succeeding job, as follows:

When standard job A returns 0

The return code matches the condition set for judgment job B. Therefore, standard job B' (the dependent job of judgment job B) is executed. Next, judgment job C evaluates the return code. Because the return code does not match the condition set for judgment job C, C's dependent job (standard job C') is not executed. Instead, standard job D is executed.
When standard job A returns 4

Because this return code does not match the condition set for judgment job B, B's dependent job (standard job B') is not executed. Judgment job C now evaluates the return code. Because it matches the condition set for C, C's dependent job (standard job C') is executed, followed by standard job D.
When standard job A returns a value other than 0 or 4

Because the return code matches neither of the conditions for judgment jobs B and C, neither of their dependent jobs (standard jobs B' and C') is executed. Only standard job D is executed.

To Page Top

(4) Example of defining judgment jobs in parallel

You can define judgment jobs in parallel.

The following figure shows an example of defining judgment jobs in parallel.

Figure 2‒71: Example of defining judgment jobs in parallel

The units are defined as follows.

Standard job A

End judgment: Judgment by threshold

Warning: 30

Judgment job X

Judgment type is Return code and Condition is Return code within judgment value range.

Greater than or equal to: 1

Less than or equal to: 9

Judgment job Y

Judgment type is Return code and Condition is Return code within judgment value range.

Greater than or equal to: 10

Less than or equal to: 19

Judgment job Z

Judgment type is Return code and Condition is Return code not within judgment value range.

Greater than or equal to: 1

Less than or equal to: 19

The following figure shows the range of judgment values for each judgment job.

Figure 2‒72: Range of judgment values

When you execute this jobnet, the return code of standard job A determines the succeeding job as follows:

When standard job A returns a code in the range from 1 to 9

The return code matches the condition set for judgment job X. Therefore, standard job B (the dependent job of judgment job X) is executed.
When standard job A returns a code in the range from 10 to 19

The return code matches the condition set for judgment job Y. Therefore, standard job C (the dependent job of judgment job Y) is executed.
When standard job A returns a code smaller than 1 or greater than 19

The return code matches the condition set for judgment job Z. Therefore, standard job D (the dependent job of judgment job Z) is executed.

To Page Top

(5) Cautionary notes

If you want to rerun a root jobnet or the preceding unit based on the result of a judgment job, define the job that you want to rerun as a dependent job as shown in the following figure:

Figure 2‒73: Example of rerunning a root jobnet from the result of a judgment job

If you define the job that you want to rerun under a dependent jobnet, the dependent jobnet might execute again depending on the termination timing of the rerun job.

In the first of the two definition examples in the figure below, recovery and rerun processing are defined in a single dependent jobnet. If you want to implement a recovery process before rerunning a job, you must define a dependent jobnet that performs the recovery process and a dependent job that reruns the root jobnet, as shown by the second improved example.

Figure 2‒74: Definition examples incorporating a recovery process before re-execution

To Page Top