4.5.11 Rerunning a job or jobnet
You can specify the execution results of a jobnet or job that has completed execution, and rerun it.
There are two methods of rerunning a job or jobnet. You can rerun the root jobnet, or rerun a nested jobnet or job. These methods are described below.
To this operation, you can use JP1/AJS3 - View, the Web GUI, the API function to rerun, or the ajsrerun command. For details on using JP1/AJS3 - View, see 9.11 Re-executing jobnets and jobs in the JP1/Automatic Job Management System 3 Operator's Guide. For details on using Web GUI, see A.12 Rerun dialog box in the JP1/Automatic Job Management System 3 Operator's Guide. For details on using the rerun API, see 7.1.17 Rerun API in the manual JP1/Automatic Job Management System 3 Command Reference. Alternatively, for details on the ajsrerun command, see the description of ajsrerun in 3. Commands Used for Normal Operations in the manual JP1/Automatic Job Management System 3 Command Reference.
- Supplementary notes
-
-
For details about rerunning a jobnet when the execution sequence of the root jobnet is controlled using a jobnet connector, see 2.2.4(5) Re-execution of jobnet connectors and connection-destination jobnets in the JP1/Automatic Job Management System 3 System Design (Work Tasks) Guide.
-
For details about re-executing a jobnet when the execution sequence of the unit is controlled by using wait conditions, see the following subsection: 2.2.5 Using wait conditions to control the order of unit execution in the JP1/Automatic Job Management System 3 System Design (Work Tasks) Guide
-
- Organization of this subsection
(1) Rerun the root jobnet
You can choose one of the following rerun methods when you rerun a root jobnet.
- From abnormally ended job
-
This method reruns from an abnormally ended job. If the rerun job ends normally, succeeding jobs are executed and processing continues.
When a nested jobnet has ended abnormally, you can rerun from the specific job in the nested jobnet that ended abnormally.
- From after abnormally ended job
-
This method reruns from the job that follows the abnormally ended job.
When a nested jobnet has ended abnormally, you can rerun from the job that follows the job that ended abnormally in the nested jobnet.
- From abnormally ended jobnet
-
This method reruns from the beginning of an abnormally ended nested jobnet.
When you rerun from an abnormally ended jobnet, the jobs that ended normally in the jobnet also rerun.
If you rerun from an abnormally ended job, jobs that ended normally before the abnormally ended job are not rerun.
- From top of jobnet
-
This method reruns from the top of the root jobnet.
- Only jobs that ended with warning
-
This method reruns only jobs that ended with a warning. When a nested jobnet is defined, you can rerun the jobs that ended with a warning in the nested jobnet.
(2) Rerun a nested jobnet or job
You can choose from the following methods to rerun a nested jobnet or job.
- From the specified jobnet or job
-
This method reruns from the specified jobnet or job. If the rerun jobnet or job ends normally, succeeding jobs are executed and processing continues.
- From the job after the specified jobnet or job
-
This method reruns from the job that follows the specified job or nested jobnet.
- Only the specified jobnet or job
-
This method reruns only the specified job or nested jobnet.
Rerunning a jobnet or job results in an error in the following cases:
-
The jobnet or job to be re-executed is in the Now Running, Running + Abend, Running + Warning, Wait for prev. to end, Wait for start time, or Being held status.
-
The jobnet or job to be re-executed has the Recovery attribute, and the preceding jobnet or job has ended normally or with a warning.
-
The jobnet or job to be re-executed is a judgment job or a dependent unit of a judgment job.
Note that dependent units of judgment jobs are re-executable if yes is set for the RERUNSUBORDINATE environment setting parameter. For details about whether to enable re-execution of dependent units, see (4) Re-executing the dependent unit of a judgment job.
-
The upper-level jobnet of the jobnet or job to be re-executed does not have a schedule.
In the following cases, attempting to execute a job or jobnet does not result in an error but they will not execute:
-
When execution of the job to be re-executed is canceled
-
When the jobnet that you attempted to re-execute does not have a schedule, even though its upper-level jobnet does have a schedule
(3) The job preceding a judgment job ended abnormally
When the job preceding a judgment job ends abnormally, you can rerun jobnets or jobs from the root jobnet as follows.
-
From abnormally ended job
-
From after abnormally ended job#
-
From abnormally ended jobnet
-
From top
-
From any job or jobnet (excludes dependent units)
-
Only jobs that ended with warning
- # Procedure for rerunning a jobnet from the job after the job that ended abnormally
-
When a job preceding a judgment job ends abnormally, if you rerun the jobnet from the next job, the status of the job that ended abnormally changes to Ended normally. The process continues from the next judgment job.
When the judgment job makes a judgment using the return code of the preceding job, it uses the return code from when the preceding job ended abnormally.
(4) Re-executing the dependent unit of a judgment job
The execution of the dependent unit of a judgment job depends on the execution result of the judgment job. If the dependent unit associated with a judgment job terminates abnormally, whether the dependent unit can be re-executed and how to re-execute it depend on the setting of the RERUNSUBORDINATE environment setting parameter. For details about the parameter, see the appropriate manual section for the platform you are using. If you are using Windows, see 6.2.23 Settings for re-executing the dependent units in the JP1/Automatic Job Management System 3 Configuration Guide. If you are using UNIX, see 15.2.21 Settings for re-executing the dependent units in the JP1/Automatic Job Management System 3 Configuration Guide.
- If re-execution of dependent units is disabled (environment setting parameter RERUNSUBORDINATE = no):
-
Unlike ordinary jobs (such as PC jobs and Unix jobs), dependent units cannot be re-executed. Re-execution from the judgment job that precedes a dependent unit is also not possible.
If a dependent unit terminates abnormally, re-execute the jobnet that contains the dependent unit.
- If re-execution of dependent units is enabled (environment setting parameter RERUNSUBORDINATE = yes):
-
Whether dependent units can be re-executed depends on the unit type and the status of the dependent units.
The dependent unit of a judgment job can be re-executed when all of the following conditions exist:
-
The version of JP1/AJS3 - Manager is 10-00 or later.
-
The judgment job evaluates to true.
-
The judgment job is in Ended normally status.
-
In the following table, Y indicates the unit type of a dependent unit that can be re-executed.
Table 4‒5: Unit types of dependent units that can be re-executed No.
Unit type
Unit defined as a dependent unit
Unit defined in a dependent jobnet
1
Job group
--
--
2
Root jobnet
--
--
3
Nested jobnet
Y
Y
4
Root remote jobnet
--
--
5
Nested remote jobnet
Y
Y
6
Manager job group
--
--
7
Manager jobnet
--
--
8
Planning group
--
--
9
Standard job
Y
Y
10
Jobnet connector
--
Y
11
OR job
--
Y
12
Judgment job
--
N
13
Event job
Y
Y
14
Action job
Y
Y
15
Custom job
Y
Y
16
Passing information setting job
Y
Y
17
HTTP connection job
Y
Y
- Legend:
-
Y : The unit can be re-executed (if all necessary conditions are satisfied).
N : The unit cannot be re-executed.
-- : The unit cannot be defined as a dependent unit.
-
In the following table, Y indicates a dependent unit in the indicated can be re-executed.
Table 4‒6: Statuses and types of dependent units that can be re-executed No.
Status
Type of dependent unit
Jobnet
Job
Jobnet connector
1
Not sched. to exe.
N
N
N
2
Wait for start time
N
--
--
3
Wait for prev. to end
N
N
N
4
Being held
N
N
--
5
Waiting to execute
--
N
--
6
Now queuing
--
N
--
7
Not executed + Ended
Y
Y
Y
8
unexec-W
Y
Y
--
9
Bypassed
Y
Y
Y
10
Now running
N
N
N
11
Running + Abend
N
--
N
12
Running + Warning
N
--
N
13
Ended normally
Y
Y
Y
14
Normal end + False
--
--
--
15
Ended with warning
Y
Y
Y
16
Ended abnormally
Y
Y
Y
17
abnormal-WR
Y
Y
--
18
Skipped so not exe.
N
--
--
19
Invalid exe. seq.
Y
--
--
20
Interrupted
Y
--
--
21
Killed
Y
Y
Y
22
kill-WR
Y
Y
--
23
Failed to start
--
Y
--
24
fail-WR
--
Y
--
25
Unknown end status
--
Y
Y
26
unknown-WR
--
Y
--
27
Shutdown
N
N
N
28
Wait for start cond.
--
--
--
29
Now monitoring
--
--
--
30
Unmonitored + Ended
--
--
--
31
Monitor terminated
--
--
--
32
Interrupted monitoring
--
--
--
33
Monitor-end normal
--
--
--
- Legend:
-
Y : The unit can be re-executed.
N : The unit cannot be re-executed.
-- : The unit cannot have the indicated status.
-
(5) Notes about rerunning jobnets or jobs
Take note of the following when you rerun a jobnet or job.
-
Processes from before the rerun have still not ended
When you rerun a jobnet from a specific job, the rerun job may catch up with a job that started before the rerun and still has active processes. In this case, start the rerun job after the preceding job ends.
-
Result information for a job before the rerun
When you rerun a job, the result information for the job (execution start time, execution end time, status, code) is updated to reflect the results of the rerun. However, the information in the standard output file and the standard error output file is retained.
-
Changing the status of a jobnet or job that precedes the rerun jobnet
If the status of the preceding jobnet or job was Ended abnormally, Killed, Failed to start, Unknown end status, or Not executed + Ended, on rerunning the status is forcibly changed to Ended normally, Ended with warning, or Bypassed. The following table details these changes.
Table 4‒7: Status change of units No.
Status of preceding unit
Does the status apply?#1
After status of preceding unit is changed
Jobnet
Job
Set skipped jobs to warning?
Root
Nested
Yes
No
1
Not sched. to exe.
Y
Y
Y
Not sched. to exe.
Not sched. to exe.
2
Waiting for start time
Y
Y
N
Waiting for start time
Waiting for start time
3
Waiting for prev. to end
N
Y
Y
Waiting for prev. to end
Waiting for prev. to end
4
Being held
Y
Y
Y
Being held
Being held
5
Waiting to execute
N
N
Y
Waiting to execute
Waiting to execute
6
Now queuing
N
N
Y
Now queuing
Now queuing
7
Not executed + Ended [-W]
N
Y
Y
Ended with warning
Bypassed
8
Bypassed
N
Y
Y
Bypassed
Bypassed
9
Now running
Y
Y
Y
Now running
Now running
10
Running + Warning
Y
Y
N
Running + Warning
Running + Warning
11
Running + Abend
Y
Y
N
Running + Abend
Running + Abend
12
Ended normally
Y
Y
Y
Ended normally
Ended normally
13
Ended with warning
Y
Y
Y
Ended with warning
Ended with warning
14
Ended abnormally [-WR]
Y
Y
Y
Ended with warning
Ended normally
15
Skipped so not exe.
Y
Y
N
Ended with warning
Bypassed
16
Invalid exe. seq.
Y
Y
N
Ended with warning
Ended normally
17
Interrupted
Y
Y
N
V5: Ended with warning #2
V6: Interrupted #2
V5: Ended with warning #2
V6: Interrupted #2
18
Killed [-WR]
Y
Y
Y
Ended with warning
Ended normally
19
Failed to start [-WR]
N
N
Y
Ended with warning
Ended normally
20
Unknown end status [-WR]
N
N
Y
Ended with warning
Ended normally
21
Shutdown
Y
Y
Y
N/P
N/P
22
Normal end + False
N
N
Y
Normal end + False
Normal end + False
23
Wait for start cond.
Y
Y#3
N
N/P
N/P
24
Now monitoring
Y
Y#3
N
N/P
N/P
25
Unmonitored + Ended
Y
Y#3
N
N/P
N/P
26
Monitor terminated
Y
Y#3
N
N/P
N/P
27
Interrupted monitoring
Y
Y#3
Y#3
N/P
N/P
28
Monitor-end normal
Y
Y#3
N
N/P
N/P
29
Start delay
Y
Y#3
N
#4
#4
30
End delay
Y
Y
Y
#4
#4
31
Nested jobnet delayed start
Y
Y
N
#4
#4
32
Nested jobnet delayed end
Y
Y
N
#4
#4
- Legend:
-
Root: Root jobnet
Nested: Nested jobnet
Y: Applies
N: Does not apply
N/P: Rerun is not possible (an error message is output)
- Note
-
Numbers 1 to 6 indicate the status when the upper-level jobnet is terminated before the preceding unit is rerun.
- #1
-
Indicates whether each type of unit can enter the indicated status.
- #2
-
Partial rerunning of an interrupted unit depends on the setting (V5 or V6) of the environment parameter VRSHIFT_INTRERUN. It is set to V6 by default. The table shows the status for each setting.
- #3
-
Since this status only applies to a start condition (.CONDITION) or an event icon in a start condition, the unit cannot be a preceding unit.
- #4
-
Delay is additional information relating to the unit status. Therefore, the delay status does not change even if the succeeding unit is rerun.
-
When rerunning the succeeding unit of a unit that has terminated abnormally
If a unit has terminated abnormally, all the succeeding units other than recovery units move to the Not executed + Ended status. The status is changed unit by unit in the order in which the units are linked with relation lines. Accordingly, when you rerun the succeeding unit of the abnormally terminated unit, the status of the succeeding unit might not move from the Waiting for prev. to end status to the Not executed + Ended status, depending on the timing. Before you attempt to rerun the succeeding unit of the abnormally terminated unit, wait until all the succeeding units are placed in the Not executed + Ended status. You must be especially careful when you rerun the succeeding unit from a recovery unit.
If you rerun the succeeding unit of an abnormally terminated unit when the succeeding unit is in the Wait for prev. to end status, the following problems might occur:
-
An attempt to rerun the unit fails
This problem occurs when the unit to be rerun is still in the Wait for prev. to end status.
Figure 4‒37: When the unit in the Wait for prev. to end status is rerun Job C is in the Wait for prev. to end status and therefore cannot be rerun. Wait until Job C moves to the Not executed + Ended status, and then rerun it.
-
An attempt is made to rerun only the specified unit, but succeeding units are also run
This problem occurs when you rerun a unit in the Not executed + Ended status while another unit is in the Wait for prev. to end status, resulting in no preceding units in the Ended abnormally status.
Figure 4‒38: When the succeeding job has a unit in the Wait for prev. to end status When Job C in the Not executed + Ended status is rerun, Job C moves to the Wait for prev. to end status, Job A moves to the Ended normally status, and Job B moves to the Bypassed status. Because none of the preceding units for Job D are in the Ended abnormally status, Job D does not move to the Not executed + Ended status, and will therefore run after Job C is rerun.
-
-
When concurrent execution is disabled
If you rerun a jobnet for which concurrent execution is disabled while another generation of the jobnet is running, the status of the re-executed generation changes to Waiting for start time and it is executed when the other generation finishes.
In the same circumstances but with concurrent execution enabled, the jobnet is re-executed immediately.
-
When Schedule skip is set as the schedule option
Execution schedules are not skipped when a jobnet whose schedule option is set to Schedule skip is rerun and the scheduled start time of the next run is reached during the re-execution. In this case, the execution schedule, which was not skipped, is executed in accordance with the settings for concurrent executions. The Schedule skip option applies only when the next start time arrives and the preceding generation was executed at its scheduled start time. For details about skipping a schedule, see 3.3.3(2) Schedule option.
-
When rerunning a root jobnet or preceding unit as the result of a judgment job
Take care when rerunning a root jobnet or preceding unit as the result of a judgment job. For details, see 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) in the JP1/Automatic Job Management System 3 System Design (Work Tasks) Guide.
(6) Notes on resuming processing while a recovery unit is running
If a job has terminated abnormally, JP1/AJS3 starts a sequence of recovery units. However, if you resume the processing from the job after the abnormally terminated one, the rest of the recovery units will be placed in the Not executed + Ended status and will not be executed. In this case, resume processing after all recovery processes have been performed.
If you want to resume the subsequent jobs even when an error is detected, consider whether you can use a judgment job to perform recovery with a dependent unit when the termination code of the judgment job has exceeded a threshold.
(7) Notes on re-executing a jobnet with start conditions
When monitoring of start conditions for a root jobnet is completed and the jobnet status changes from Now monitoring to any of the following statuses, the status of the lower-level units becomes Not executed + Ended.
-
Unmonitored + Ended
-
Monitor terminated
-
Monitor-end normal
Because the Not executed + Ended status is treated as an abnormal termination, be careful when you re-execute a generation of a jobnet that has any of the following statuses.