2.2.5 Using wait conditions to control the order of unit execution

(a) Units with wait conditions and units whose ends are being waited for

When assigning a wait condition, you specify a target unit. The unit with the wait condition waits for the target unit to finish executing. The status of the target unit (that is, whether it has finished executing) depends on whether the unit has a start condition^#.

For units without a start condition^#

You can assume that the unit whose end is being waited for has finished executing when its status is one of the following:

• Ended normally

• Ended with warning

• Bypassed

For units with a start condition^#

If the default settings are in effect, you can assume that the unit whose end is being waited for has finished executing when the statuses of the monitoring generation and all the execution generations of the unit are as follows:

Monitoring generation

• Monitor-end normal

Execution generation

• Ended normally

• Ended with warning

By setting a start condition for the unit whose end is being waited for, you can change the status that the unit needs to have when it finishes executing. For details, see (5)(c) Behavior of units with wait conditions when start conditions are used for the units whose ends are being waited for.

#

To be able to use a start condition, the root jobnet must satisfy the following criteria:

• A start condition is set for the root jobnet.

• When the root jobnet is registered for execution, the use of a start condition is specified.

  For immediate execution, in the Register for Execution dialog box, in the Start condition section, click Use if defined.

  For planned execution and fixed execution, in the Schedule Rule dialog box, in the Start condition section, click Use if defined.

• Start conditions are not disabled by the -j option of the ajsplan command.

The unit with the wait condition starts to execute when the unit specified in the wait condition finishes executing.

A unit with a wait condition assigned is called a unit with wait conditions. A unit specified in a wait condition is called a unit whose end is being waited for.

The following figure shows how a wait condition controls the order in which jobs are executed.

In this example, a wait condition is assigned to Job 3 in Root Jobnet B, and Job 2 in Root Jobnet A is specified for the wait condition as the unit whose end is being waited for. When the system executes Root Jobnet A and Root Jobnet B, Job 3 waits for Job 2 to finish executing. When Job 2 finishes executing, Job 3 then starts.

You can use wait conditions to control the execution sequence for a variety of units. The following table describes the units to which wait conditions can be assigned, and the units you can specify as units whose end is being waited for.

Legend:

Y: Can be assigned a wait condition or specified as a unit whose end is being waited for

N: Cannot be assigned a wait condition or specified as a unit whose end is being waited for

#1

You can assign wait conditions to these jobs, but you cannot register them for execution.

#2

Even if a root jobnet has a start condition, you can disable the start condition by clicking Do not use in the Start condition section of the Register for Execution dialog box or the Schedule Rule dialog box. This means that you do not know whether the start condition will be applied for the units under the root jobnet with the start condition until the root jobnet is executed. Accordingly, you can assign wait conditions to the units under a root jobnet with a start condition. Also, you can specify a unit under a root jobnet with a start condition as the unit whose end is being waited for. Note, however, that if the start condition is used at execution, an execution error occurs.

#3

The following conditions must be satisfied if you want to assign wait conditions to a root jobnet with a start condition or to specify that root jobnet as the unit whose end is being waited for:

• JP1/AJS3 - Manager is version 10-00 or later.

• condition is set for the PREWAITEXTEND environment setting parameter.

#4

When designating a unit in a root jobnet directly under a planning group as a unit whose end is being waited for, specify the name of the unit without the root jobnet name. That is, specify /planning group/job rather than /planning group/root-jobnet/job.

A wait condition controls the execution sequence of units governed by a single scheduler service. That is, the unit with the wait condition and the unit whose end is being waited for must be under the control of the same scheduler service.

Cautionary notes

• Job flows that incorporate wait conditions can be hard to comprehend, and tend to obscure the flow of work tasks and the jobnet hierarchy. When you create a job flow, to the extent possible, avoid using wait conditions. Use relation lines, nest jobnets, and combine multiple jobs instead.

• When you use wait conditions, space out when waits begin so that multiple waits are not concentrated at the same time. Also specify different scheduled start times for jobnets.

  If multiple units with wait conditions must start waiting at the same time, design the job flow taking into account the following points regarding the time required from the time a unit whose end is being waited for ends until the unit with a wait condition starts executing:

  - A unit with a wait condition checks the status of the unit whose end is being waited for. Accordingly, some time is necessary after the unit whose end is being waited for ends until the unit with the wait condition starts executing. How much time is required depends on the number of units with wait conditions that are waiting at the same time. These units include other units with wait conditions in the same scheduler service.

  - One scheduler service can process approximately 4 to 20 units with wait conditions every second. For example, if 100 units with wait conditions simultaneously start waiting for one unit whose end is being waited for, approximately 5 to 25 seconds is required from the time the unit whose end is being waited for ends until the 100th unit with a wait condition starts executing.

  - When you specify a root jobnet with a start condition as the unit whose end is being waited for, the time required until the unit with the wait condition starts executing depends on the number of execution generations of the root jobnet with the start condition. For example, if 100 units with wait conditions simultaneously start waiting for 100 root jobnets with start conditions and 10 execution generations (for each root jobnet), approximately 5 to 20 seconds is required after all the root jobnets with start conditions finish executing until the units with wait conditions start executing. If each of the 100 root jobnets with start conditions has 100 execution generations, the time is approximately 50 to 100 seconds.

  - The length of time required until a unit with a wait condition starts executing depends on the performance of the computer and the jobnet configuration of the unit whose end is being waited for and the unit with the wait condition.

• You can use wait conditions from version 09-50 of JP1/AJS3 - View and JP1/AJS3 - Manager. However, you cannot use wait conditions if the database uses a compatible ISAM configuration, even when running JP1/AJS3 - Manager 09-50 or later.

(b) Wait statuses

The wait status of a unit with wait conditions indicates whether the unit is still waiting for the unit whose end is being waited for to finish executing. The following table describes each wait status.

When the wait status transitions to Wait complete or Wait complete (manual), the wait condition is satisfied and the unit with the wait condition begins to execute.

You can configure the behavior of a unit with a wait condition. For details, see (5) Configuring the behavior of units with wait conditions.

(c) Flow of execution order control

To use wait conditions to control the execution order of units:

1. Define the unit whose end is being waited for and the unit to which the wait condition is to be assigned.

   Create a detailed definition and schedule for the units.

2. Assign a wait condition to the unit.

   The following settings define a wait condition:

   • Name of the unit whose end is being waited for

   • Wait method

   • Behavior when not waiting for any generations

   For details on the wait method and behavior when not waiting for any generations, see (5) Configuring the behavior of units with wait conditions.

   For details on how to assign a wait condition, see 5.2.6 Assigning wait conditions in the JP1/Automatic Job Management System 3 Operator's Guide.

3. Register the root jobnets that manage the related units, namely the unit with wait conditions and the unit whose end is being waited for, for execution.

   The unit with the wait condition waits for the unit whose end is being waited for to finish executing.

   For details on how to register a root jobnet for execution, see 7. Executing Jobnets in the JP1/Automatic Job Management System 3 Operator's Guide.

(a) The unit with the wait condition is in the same root jobnet as the unit whose end is being waited for

When the unit with the wait condition is associated with the same root jobnet as the unit whose end is being waited for, both units are executed as part of the same generation. Therefore, the unit with the wait condition will wait for the unit whose end is being waited for that is executed in the same generation to finish executing.

The following figure shows an example in which the unit with the wait condition and the unit whose end is being waited for are associated with the same root jobnet.

In this example, Job 3 (the unit with wait conditions) and Nested Jobnet 1 (the unit whose end is being waited for) are both defined under Root Jobnet A. If Root Jobnet A is scheduled to execute once per day, generations of Root Jobnet A are scheduled for 7/1 and 7/2 when the jobnet is registered for execution. In this scenario, Job 3 waits for the instance of Nested Jobnet 1 that is in the same generation to finish executing.

(b) The unit with the wait condition and the unit whose end is being waited for are in different root jobnets

When the unit with the wait condition and the unit whose end is being waited for are associated with different root jobnets, generations of each root jobnet are scheduled when you register the root jobnets for execution. In this scenario, the unit with wait conditions waits for the generation of the unit whose end is being waited for that satisfies both of the following conditions:

• Shares the same execution date

• Appears in the same position in the sequence when the generations are sorted in order of execution start time

The following figure shows an example in which the unit with wait conditions and the unit whose end is being waited for are in different root jobnets.

In this example, Job 1 (the unit with wait conditions) and Nested Jobnet 1 (the unit whose end is being waited for) are defined under different root jobnets. If Root Jobnet A and Root Jobnet B are scheduled for execution twice on 7/1, two generations of Root Jobnet A are generated for 7/1 with the execution IDs @A101 and @A102. Similarly, two generations of Root Jobnet B are generated for 7/1 with the execution IDs @A103 and @A104. Generations @A103 and @A104 of Job 1 each wait for the generation of Nested Jobnet 1 that shares the same execution date and whose start time appears in the equivalent position. Therefore, the wait condition of the first generation of Job 1 (@A103) applies to the generation of Nested Jobnet 1 that executes first (@A101). Similarly, the wait condition of @A104, the second generation of Job 1, applies to @A102, the second generation of Nested Jobnet 1. Of the generations of Job 1 scheduled for 7/2, each generation waits for the generation of Nested Jobnet 1 that starts in the corresponding position.

Below are examples of using wait conditions in conjunction with JP1/AJS3 functionality.

Using the jobnet release function to replace the jobnet definition of the unit whose end is being waited for

If you use the jobnet release function to switch the jobnet definition of a unit whose end is being waited for without stopping the jobnet, the jobnet targeted by the wait condition switches automatically.

The following figure shows an example of releasing a jobnet serving as a unit whose end is being waited for.

Figure 2‒29: Releasing a jobnet serving as a unit whose end is being waited for

In this example, Root Jobnet A is subject to a release registration that releases the jobnet definition with the release ID 001 at the specified release time of 00:00 on 7/2. When Root Jobnet A is registered for execution, the generation scheduled for 7/1 (@A101) is subject to the jobnet definition associated with release ID AJS_AUTO, and the generation scheduled for 7/2 (@A103) is subject to the jobnet definition associated with release ID 001. On 7/1, Job 1 waits for generation @A101 of the Nested Jobnet 1 associated with release ID AJS_AUTO. From 7/2, Job 1 waits for generation @A103 of the Nested Jobnet 1 associated with release ID 001.

Changing the start order of scheduled generations of a jobnet registered for execution

If you perform a temporary plan change or other operation that changes the order in which generations of a registered jobnet are scheduled to start, the generations targeted by the wait condition automatically change to reflect the order in the new schedule.

The following figure shows an example in which a temporary plan change alters the order in which scheduled generations start.

Figure 2‒30: Example of using a temporary plan change to change the start sequence of scheduled generations

In this example, Root Jobnet A which manages Nested Jobnet 1 (the unit whose end is being waited for), and Root Jobnet B which manages Job 1 (the unit with a wait condition), are both scheduled to execute twice on 7/1. Although generation @A103 of Root Jobnet B was scheduled to execute first on 7/1, a temporary plan change caused its execution to be canceled, and @A104 became the generation executed first. Thus, generation @A104 of Job 1 waits for generation @A101 of Nested Jobnet 1.

Effects of a 48-hour schedule on wait conditions

If you use a 48-hour schedule, the target generation of a wait condition is determined by its execution date in the 48-hour schedule.

The following figure shows an example of wait conditions in a 48-hour schedule.

Figure 2‒31: Example of wait conditions in a 48-hour schedule

In this example, the scheduler services for Root Jobnet A and Root Jobnet B use the 48-hour schedule. Root Jobnet A, which governs Nested Jobnet 1 (the unit whose end is being waited for), is scheduled to execute daily at 10:00. Root Jobnet B, which governs Job 1 (the unit with wait conditions), is scheduled to execute at 38:00 on 7/1. In this scenario, the first generation of Job 1 to be executed on 7/1 is @A103, scheduled for 38:00 (actually 14:00 on 7/2). Thus, generation @A103 of Job 1 waits for generation @A101 of Nested Jobnet 1, which is the first generation of Nested Jobnet 1 scheduled for 7/1.

Cautionary notes

• You can set a different base time for the unit with wait conditions and the unit whose end is being waited for. However, doing so can complicate the process of matching wait conditions to their targets. We recommend that you coordinate the base times of units with wait conditions and their units whose ends are being waited for.

• In UNIX, you can specify different time zones for the unit with the wait condition and the unit whose end is being waited for. However, doing so can complicate the process of matching wait conditions to their targets. We recommend that you coordinate the time zones of units with wait conditions and their units whose ends are being waited for.

• Make sure that the saved generations for the unit with the wait condition and the unit whose end is being waited for cover at least one day of operation. This is to ensure that the unit with the wait condition waits as intended and starts executing when the unit whose end is being waited for finishes. If you cannot save one day's generations of the unit whose end is being waited for, there is a chance that the unit might not start executing. On the other hand, if you cannot save one day's generations of the unit with the wait condition, the condition might target a unit whose end is being waited for other than the one intended.

(c) The unit with the wait condition or the unit whose end is being waited for uses a start condition

(d) A planning group is specified as the unit whose end is being waited for

When you specify a planning group as a unit whose end is being waited for, the target of the wait condition is the root jobnet running under the planning group. When the planning group switches execution from one root jobnet to another, the target of the wait condition changes automatically.

The following figure shows an example in which a planning group is specified as the unit whose end is being waited for.

In this example, Planning Group P is specified as the unit whose end is being waited for, and defines two root jobnets: Root Jobnet P1 which runs between 6/1 and 6/30, and Root Jobnet P2 which runs between 7/1 and 7/31. From 6/1 to 6/30, Job 1 waits for Root Jobnet P1. When 7/1 arrives and the root jobnet running under the planning group switches to Root Jobnet P2, Root Jobnet P2 becomes the target of Job 1's wait condition.

(a) Status transitions of units with wait conditions and units whose ends are being waited for when no start condition is used

(b) Status transitions of units with wait conditions and units whose ends are being waited for when a start condition is used

(c) Status transitions of units when units with wait conditions are not executed even if a wait condition is satisfied

Note that if the unit with wait conditions and the unit whose end is being waited for are defined or run under the following circumstances, the unit with wait conditions might not run even if the wait condition is satisfied:

• The unit with wait conditions connects to a preceding unit by a relation line

• A hold attribute is set for the unit with wait conditions

• Multiple instances of the unit with wait conditions are set to run concurrently

• You rerun the unit with wait conditions or the unit whose end is being waited for

The following describes the status transitions that take place in these scenarios.

(d) Treatment of a wait condition when the succeeding unit of a unit, whose end is being waited for, is rerun

The status of a unit whose end is being waited for by the succeeding unit might change when the succeeding unit is rerun. By using the PREWAITRERUNSTATUS environment setting parameter, whether to meet the wait condition can be controlled based on this status change. In a newly installed JP1/AJS3, the environment setting parameter is initially set to meet the wait condition.

For details about the PREWAITRERUNSTATUS environment setting parameter, see 20.4.2(110) PREWAITRERUNSTATUS in the JP1/Automatic Job Management System 3 Configuration Guide.

Configuring so that the wait condition is met:

If the PREWAITRERUNSTATUS environment setting parameter is set to no and running the succeeding unit changes the status of the unit whose end is being waited for, the wait condition is met and the unit with wait conditions then starts running.

The following figure shows an example of rerunning the succeeding job of a unit whose end is being waited for, while the PREWAITRERUNSTATUS environment setting parameter is set to no.

Figure 2‒50: Example of rerunning a succeeding unit of a unit whose end is being waited for (configuring so that the wait condition is met)

In this example, Job 2 is the unit whose end is being waited for and Job 3 is a succeeding unit of Job 2. If Job 3 is re-executed while both Job 3 and Job 2 are in Not executed + Ended status, the status of Job 2 changes from Not executed+ Ended to Bypassed.

If the PREWAITRERUNSTATUS environment setting parameter is set to no, the wait status changes to Wait complete, causing the wait condition to be met. As a result, root jobnet A, which is a unit with wait conditions, starts running.

If the PREWAITRERUNSTATUS environment setting parameter is set to no, be careful if rerunning of the succeeding unit changes the status of a unit whose end is being waited for. If you intend to rerun a succeeding unit of a unit whose end is being waited for, make sure that you are fully aware of the effects such an action will have. You can do so by conducting a search to make sure that the unit whose end is being waited for is not one of the units whose status will be affected. For details on rerunning a unit, see 4.5.11 Rerunning a job or jobnet in the manual JP1/Automatic Job Management System 3 Overview. For details on how to search for wait conditions, see 10.2 Finding and displaying units in the JP1/Automatic Job Management System 3 Operator's Guide.

Configuring so that wait condition is not met:

If the PREWAITRERUNSTATUS environment setting parameter is set to yes, the wait condition is not met when the status of a unit whose end is being waited for is changed by rerunning the succeeding unit. Therefore, the status of the unit with wait conditions does not change.

This setting can prevent a wait condition from being unintentionally met when the status of the preceding unit is changed by rerunning a unit.

The following figure shows an example of rerunning the succeeding job of a unit whose end is being waited for if the PREWAITRERUNSTATUS environment setting parameter is set to yes.

Figure 2‒51: Example of rerunning a succeeding unit of a unit whose end is being waited for (configuring so that the wait condition is not met)

The unit definitions in the above example are the same as those in the example in the case where the wait condition is met. When job 3 is rerun, the status of job 2 changes from Not executed + Ended to Bypassed.

However, if the PREWAITRERUNSTATUS environment setting parameter is set to yes, the wait condition changes to Wait incomplete. As a result, the wait condition is not met. Therefore, the status of root jobnet A, which is a unit with wait conditions, does not change.

Note that if job 2, which is a unit whose end is being waited for, is re-executed and the execution ends, the wait condition is met, causing root jobnet A to start running.

If the unit whose end is being waited for is a jobnet and subordinate units are individually rerun, a wait is completed when the jobnet ends. If necessary, set the hold attribute or change the job status so that the wait condition is not met.

(a) Wait methods for conditions with multiple units whose ends are being waited for

You can specify, for each unit with wait conditions, a maximum of 32 units whose ends are being waited for. If you specify more than one unit whose end is being waited for, you can specify whether the condition is satisfied when all of the units whose ends are being waited for finish executing, or just one.

You can choose either of the following wait methods:

• AND

  The wait condition is satisfied when all specified units whose ends are being waited for finish executing.

• OR

  The wait condition is satisfied when any one of the specified units whose ends are being waited for finishes executing.

The following figure shows the difference between the two wait methods.

In these examples, Nested Jobnet 1 and Nested Jobnet 2 are specified for Job 1, the unit with wait conditions, as the units whose ends are being waited for.

In Example 1, which uses the AND wait method, the condition is satisfied and Job 1 starts executing when Nested Jobnet 1 and Nested Jobnet 2 have both finished executing.

In Example 2, which uses the OR wait method, the condition is satisfied and Job 1 starts executing when Nested Jobnet 1 finishes executing.

Cautionary note

Assigning a large number of wait conditions to a single unit can slow down the processing speed of the JP1/AJS3 system. When designing a unit with wait conditions, try to use as few units whose ends are being waited for as possible.

The following figure shows an example of how you can reduce the number of units whose ends are being waited for.

Figure 2‒53: Example of reducing the number of units whose ends are being waited for

In the example with the greater number of units whose ends are being waited for, Job 1, Job 2, and Job 3 are specified for job 4 (the unit with wait conditions) as the units whose ends are being waited for. In this example, the number of units whose ends are being waited for is reduced by defining an empty job (Job 0) as a succeeding unit of Jobs 1, 2, and 3, and connecting each of Jobs 1, 2, and 3 to Job 0 by relation lines. For Job 4, you can then specify Job 0 as the unit whose end is being waited for, achieving the same results with fewer units whose ends are being waited for. However, defining empty jobs like the one pictured above can complicate job management. For this reason, we recommend that you avoid defining superfluous units unless performance considerations demand it.

Supplementary note

When using the AND wait method, if you perform a hot restart of the scheduler service after some of the units whose ends are being waited for have finished executing, the status of the wait condition is retained after the scheduler service restarts. This means that the wait condition will be satisfied when the remaining units whose ends are being waited for finish executing.

For example, suppose that in Example 1 of Figure 2-52 you perform a hot restart of the scheduler service after Nested Jobnet 1 has ended normally and Nested Jobnet 2 is running. In this scenario, the wait condition is satisfied when Nested Jobnet 2 finishes executing after the scheduler service restarts.

(b) Behavior of units with wait conditions when there are no applicable generations of units whose ends are being waited for

Units with wait conditions wait for specific generations of their units whose end is being waited for to finish executing, according to the rules described in (2) Rules governing waiting regarding units with wait conditions and units whose ends are being waited for. However, if there are no generations of the unit whose end is being waited for that satisfy the wait rule, the unit with the wait condition can be configured to behave in either of the following ways:

• Do not start executing

  When there are no applicable generations of the unit whose end is being waited for, the unit with the wait condition continues waiting for the wait condition to be satisfied with a status of either Wait for start time, Wait for prev. to end, or Not sched. to exe.^#.

  #

  If yes is specified for the PREWAITNOSCHUNITS environment setting parameter, the unit with wait conditions performs a wait even if the unit is in the Not sched. to exe. status. For details about the PREWAITNOSCHUNITS environment setting parameter, see 20.4.2(122) PREWAITNOSCHUNITS in the JP1/Automatic Job Management System 3 Configuration Guide.

• Start executing

  When there are no applicable generations of the unit whose end is being waited for, the unit with the wait condition immediately starts executing. If the wait condition applies to multiple units whose ends are being waited for, the unit starts executing when there are no applicable generations of any units whose ends are being waited for that have not finished executing.

This setting applies when the unit with wait conditions and the unit whose end is being waited for are associated with different root jobnets. If both units are under the same root jobnet, they run as part of the same generation, which means there is always a generation of the unit whose end is being waited for that satisfies the wait rule.

The following figure shows the differences between the settings that govern how wait conditions behave when there are no applicable generations of units whose ends are being waited for.

In Example 1, the setting for when there are no applicable generations of units whose ends are being waited for is Do not start executing. When Root Jobnet B, an upper-level unit of Job 1 (the unit with wait conditions), is registered for immediate execution, a generation of Job 1 is generated. Because there is no generation of Nested Jobnet 1 (the unit whose end is being waited for), Job 1 enters Wait for prev. to end status and waits for the wait condition to be satisfied. If Root Jobnet A, an upper-level unit of Nested Jobnet 1, is registered for immediate execution, and then Nested Jobnet 1 ends normally, the wait condition is satisfied and Job 1 starts executing.

In Example 2, the setting for when there are no applicable generations of units whose ends are being waited for is Start executing. When Root Jobnet B is registered for immediate execution, a generation of Job 1 is generated. Because no generation of Nested Jobnet 1 exists at this time, Job 1 immediately starts executing. If Root Jobnet A, an upper-level unit of Nested Jobnet 1, is registered for immediate execution after Job 1 has already started executing, a normal termination of Nested Jobnet 1 will not trigger another generation of Job 1.

Supplementary notes

• If the status of the unit whose end is being waited for is Not sched. to exe., the setting governing behavior when no applicable generations are present does not apply if the root jobnet associated with the unit whose end is being waited for has an execution schedule. In this scenario, the unit whose end is being waited for enters Bypassed status when its root jobnet is executed. This causes the unit whose end is being waited for to be seen as having finished executing, which satisfies the wait condition.

• If the status of the root jobnet of the unit whose end is being waited for is Not registered, the Start executing setting does not take effect and the unit with wait conditions does not start to execute.

(c) Behavior of units with wait conditions when start conditions are used for the units whose ends are being waited for

When you use a start condition for a unit whose end is being waited for, you can change the wait condition to change the status the unit whose end is being waited for must have so it can finish executing.

• When the monitoring generation of the unit whose end is being waited for ends in the Unmonitored + Ended status

  The wait condition can be satisfied when the monitoring generation ends in the Unmonitored + Ended status.

• When an execution generation of the unit whose end is being waited for ends abnormally

  The wait condition can be satisfied when an execution generation ends abnormally.

  The wait condition can also be satisfied when the abnormal termination status of an execution generation is the Skipped so not exe.

The following examples describe how you can change a wait condition:

• If you want a unit to end without satisfying a start condition during event monitoring

  If you want operation to be treated as normal even if no start condition at all is satisfied during the time period specified as the valid range for the start condition, you can cause the wait condition to be satisfied when the monitoring generation enters the Unmonitored + Ended status.

• If you want operation to continue when an execution generation enters the Ended abnormally or Killed status

  When a start condition is satisfied multiple times, if you want operation to be treated as normal even if some of generated execution generations end abnormally, you can cause the wait condition to be satisfied when execution generations end abnormally.

• If generations waiting to be executed are set not to be retained even when many start conditions are to be satisfied while the monitoring generation is in the Now monitoring status

  If execution generations waiting to be executed are set not to be retained even when many start conditions are satisfied, the execution generations that have not started executing enter the Skipped so not exe. status. If you want operation to be treated as normal even when execution generations enter the Skipped so not exe. status, you can cause the wait condition to be satisfied when execution generations enter the Skipped so not exe. status.