4.5.17 Changing job and jobnet definitions without unregistering the jobnet

(a) Changes you can make to definitions

The changes you can make to definitions while the root jobnet is registered for execution, and the changes that are unavailable are listed below.

Changes that are available

• Adding a new unit^#

• Changing an existing definition

• Changing a wait condition

• Deleting an existing unit

• Changing the map size

• Adding a start condition^#

• Deleting a start condition

You can also change the definition of units defined under a remote jobnet.

#

The following units cannot be added into a root jobnet for which release entry was performed (a release-target jobnet).

• Remote jobnet

• .CONDITION (start condition)

• Jobnet connector

Changes that are unavailable

• Changing the name of an existing unit

  However, you can change the name of a unit added during suspension.

• Moving a unit

  To move a unit, first copy the source unit and paste it to the destination. Then delete the source unit.

• Deleting a running unit

The following paragraphs describe in detail the types of editing you can perform on lower-level definitions while the root jobnet is registered for execution, and the points to consider when editing a definition.

Adding a new unit

You can add a new unit. The status of the added unit during suspension depends on the status of the jobnet one level above the unit. The following table shows the status of the unit one level above the added unit, and the status of the added unit.

Table 4‒10: Status of a unit added during suspension

Status of unit one level above added unit	Status of added unit
Waiting	Not scheduled
Now running	Not scheduled
Ended	Bypassed

Changing an existing definition

You can change an existing definition. However, note the following:

• You cannot change the name of an existing unit.

  However, you can change the name of a unit added during suspension.

• You can change the definition of a unit that is running. However, you cannot delete it.

• Even if you change an existing definition, the past execution results remain.

• When you change an existing definition, the jobnet may execute in a different configuration from before. Be aware of this when you rerun the jobnet.

• The dummy schedule for a jobnet registered for planned execution, displayed in the Daily Schedule or Monthly Schedule window, is calculated from the changed definition information even while the jobnet is suspended.

Changing a wait condition

You can change a wait condition. However, note the following:

• If you suspend a unit with wait condition and change the wait condition when the status of the unit is Now running, the new change is not applied. When the suspension is released, the unit continues execution with the old wait condition.

• While execution of a unit with wait condition is suspended, if the unit whose end is being waited for terminates, the result is a wait condition that is not satisfied immediately. If the unit whose end is being waited for has terminated when suspension is released, the result is a wait condition that has been satisfied.

• While execution of a unit whose end is being waited for is suspended, the associated unit with wait condition does not terminate abnormally even if the definition of the unit whose end is being waited for is not correct. If the definition of the unit whose end is being waited for is incorrect when the suspension is released, the associated unit with wait condition terminates abnormally.

Deleting an existing unit

You can delete an existing unit. However, note the following:

• When you delete an existing unit, past execution results for the unit are also deleted, and you can no longer display them. If you need this past history information, either reference the scheduler log information, or save the information using the ajsshow command, before deleting the unit. For the ajsshow command syntax, see ajsshow in 3. Commands Used for Normal Operations in the manual JP1/Automatic Job Management System 3 Command Reference.

• When you delete an existing unit, the jobnet may execute in a different configuration from before. Be aware of this when you rerun the jobnet.

Changing the map size

You can change the map size, regardless of the status of the jobnet.

Adding a start condition

When you use a start condition, first you create the start condition object (.CONDITION). You then set the schedule by using schedule rules, or by temporarily changing the execution plan. Note that the schedule recalculation method differs according to the execution registration method. Therefore, the time when a start condition added to a jobnet is enabled also depends on the execution registration method.

The time when an added start condition is enabled is as follows:

• When the jobnet is registered for immediate execution

  The added start condition is enabled for generations created after suspension is released. The added start condition is not enabled for any generations created before the suspension.

  To enable added start conditions for generations created before the jobnet execution is suspended, use either of the following methods:

  - Cancel execution registration of the jobnet, add start conditions, and then re-register the jobnet for execution.

  - When there are generations in Being held status, suspend execution of the jobnet, add start conditions, release suspension, and then execute the ajsplan command for the generations created before suspension to enable the start conditions.

• When the jobnet is registered for planned execution

  The added start condition is valid from the next generation that is scheduled for execution.

• When the jobnet is registered for fixed execution in a specified period

  The added start condition is enabled for generations created after suspension is released. The added start condition is not enabled for any generations created before the suspension.

  To enable added start conditions for generations created before the execution of the jobnet is suspended, use either of the following methods:

  - Cancel execution registration of the jobnet, add start conditions, and then re-register the jobnet for execution.

  - Add start conditions to cancel suspension, and then execute the ajsplan command for the generations created before suspension.

• When the jobnet is registered for fixed execution for a specific number of future generations

  The added start condition is valid from the first generation created after the suspension is released. The added start condition is not enabled for any generations created before the suspension.

  To enable added start conditions for generations created before the jobnet execution is suspended, use either of the following methods:

  - Cancel execution registration of the jobnet, add start conditions, and then re-register the jobnet for execution.

  - Add start conditions to cancel suspension, and then execute the ajsplan command for the generations created before suspension.

  Note that, if you add start conditions to a root jobnet, an error occurs when suspension is canceled.

For details on the ajsplan command, see ajsplan in 3. Commands Used for Normal Operations in the manual JP1/Automatic Job Management System 3 Command Reference.

Deleting start conditions

You can delete start conditions that have been defined (.CONDITION). Note, however, that you might be unable to delete start conditions depending on the execution registration method. This is because the schedule re-calculation method differs according to the execution registration method. If you cannot delete start conditions, you can disable them.

The time when a start condition is deleted or disabled is as follows:

• When the jobnet is registered for immediate execution

  When start conditions are deleted from a jobnet, they are not added to any jobnet generations created after suspension is released. In the case of monitoring generations created before suspension, start conditions are not deleted, and the status of the monitoring generations changes to Monitor terminated.

  Although you cannot delete start conditions from generations that were created before suspension, you can disable the start conditions. To disable the start conditions, suspend the jobnet when there are generations in Being held status, delete the start conditions, release the suspension, and then use the ajsplan command to disable the start conditions.

• When the jobnet is registered for planned execution

  The deleted start conditions are disabled, starting from the next generation that has been scheduled for execution.

• When the jobnet is registered for fixed execution in a specified period

  When start conditions are deleted from a jobnet, they are not added to any jobnet generations created after suspension is released. In the case of monitoring generations created before suspension, start conditions are not deleted, and the status of the monitoring generations changes to Monitor terminated.

  To delete or disable the start conditions from generations created before the jobnet execution is suspended, use either of the following methods:

  - Cancel the execution registration of the jobnet, delete the start conditions, and then re-register the jobnet for execution.

  - Delete the start conditions, release suspension, and then use the ajsplan command to disable start conditions for the generations that were created before suspension.

• When the jobnet is registered for fixed execution for a specific number of future generations

  When start conditions are deleted from a jobnet, they are not added to any jobnet generations created after suspension is released. In the case of monitoring generations created before suspension, start conditions are not deleted, and the status of the monitoring generations changes to Monitor terminated.

  To delete or disable the start conditions from generations created before the jobnet execution is suspended, use either of the following methods:

  - Cancel the execution registration of the jobnet, delete the start conditions, and then re-register the jobnet for execution.

  - Delete the start conditions, release suspension, and then use the ajsplan command to disable start conditions for the generations that were created before suspension.

  For details on the ajsplan command, see ajsplan in 3. Commands Used for Normal Operations in the manual JP1/Automatic Job Management System 3 Command Reference.

When you edit the definition of a jobnet that is registered for execution, the changes are reflected in the past execution results, and all running and scheduled generations. For example, if you edit the definition of a jobnet and then display the past history of the jobnet in the Jobnet Monitor window, the status for the edited jobnet is displayed.

(b) Available changes according to unit type and status

The changes you can make to the definition of a unit under a root jobnet that is registered for execution differs according to the type and status of the unit.

The following table shows the different changes you can make for each type of unit.

Table 4‒11: Unit types and available editing operations

Edit operation			Unit
			Job	Jobnet
Editing a unit	Adding a unit		Y	Y
	Deleting a unit	Running unit	N	N
		Non-running unit	Y	Y
Editing a relation line	Adding a relation line		Y	Y
	Deleting a relation line		Y	Y
Editing a wait condition	Changing units whose end is being waited for	Adding	Y#1	Y#1
		Deleting	Y#1	Y#1
	Changing the wait method		Y#1	Y#1
	Changing the behavior if there is no generation to wait for		Y#1	Y#1
Editing unit information	Changing a unit name	New unit	Y	Y
		Existing unit	N	N
	Changing a comment		Y	Y
	Changing the execution host		Y	Y
	Changing a definition		Y	Y
	Changing the transfer file		Y	--
	Changing an attribute	Type	Y#1,#2	Y#1,#2
		Other attribute	Y	Y
Other	Changing the map size		--	Y

Legend:

Y : Available

N : Not available

-- : Not applicable

#1

This edit operation can be performed during suspension.

#2

This edit operation can only be performed from JP1/AJS3 - View.

Note that the available editing options differ, depending on the status of the unit you are editing. The following table shows the different editing options available according to the status of the unit.

Table 4‒12: Editing options available for units according to status

Edit operation			Unit status
			Wait for prev. to end/Wait for start time	Running	Ended
Editing a unit	Adding a unit		--	--	--
	Deleting a unit		Y	N	Y
Editing a relation line	Adding a relation line		Y	Y	Y
	Deleting a relation line		Y	Y	Y
Editing a wait condition	Changing units whose end is being waited for	Adding	Y#1	Y#1	Y#1
		Deleting	Y#1	Y#1	Y#1
	Changing the wait method		Y#1	Y#1	Y#1
	Changing the behavior if there is no generation to wait for		Y#1	Y#1	Y#1
Editing unit information	Changing a unit name	New unit	Y	--	Y
		Existing unit	N	N	N
	Changing a comment		Y	Y	Y
	Changing an execution host		Y	Y	Y
	Changing a definition		Y	Y	Y
	Changing the transfer file		Y	Y	Y
	Changing an attribute	Type	Y#1,#2	N	Y#1,#2
		Other attribute	Y	Y	Y
Other	Changing the map size (jobnet)		Y	Y	Y

Legend:

Y : Available

N : Not available

-- : Not applicable

#1

This edit operation can be performed during suspension.

#2

This edit operation can only be performed from JP1/AJS3 - View.

Table 4‒13: Editing options available according to start condition status

Edit operation			Status of start condition
			No start condition	Waiting for prev. to end	Monitoring	Ended
Start condition	Setting a start condition		Y	--	--	--
	Deleting a start condition		--	Y	--	Y
Editing a unit	Adding a unit		Y	Y	--	Y
	Deleting a unit		Y	Y	--	Y
Editing unit information	Changing a unit name	New unit	Y	Y	--	Y
		Existing unit	--	N	--	N
	Changing a comment		Y	Y	--	Y
	Changing an execution host		Y	Y	--	Y
	Changing a definition		Y	Y	--	Y
	Changing an attribute		Y	Y	--	Y
Other	Changing the map size		Y	Y	--	Y

Legend:

Y : Available

N : Not available

-- : Not applicable

(a) Basic procedure for editing definitions

Follow this basic procedure to change a definition below a root jobnet that is registered for execution.

To change a definition below a root jobnet that is registered for execution:

1. Suspend the root jobnet that is registered for execution.

2. Edit the definition below the root jobnet

3. Release the suspension

To edit a definition that is monitoring for a start condition, you must kill the jobs that are monitoring for a start condition before suspending the root jobnet. Follow this procedure to edit a definition that is monitoring for a start condition.

To edit a definition that is monitoring for a start condition:

1. Kill the jobs that are monitoring for a start condition.

2. Suspend the root jobnet.

3. Edit the definition.

4. Release the suspension.

5. Execute the root jobnet by adding a schedule.

(b) Activating the suspend function

Before you can suspend a job or jobnet, you must activate the suspend function in advance by running the ajssetup command. For the command syntax, see ajssetup in 2. Commands Used during Setup in the manual JP1/Automatic Job Management System 3 Command Reference.

To activate the suspend function, execute the command as follows:

ajssetup -F scheduler-service-name -m

You can enable the suspend function without stopping JP1/AJS3 services or scheduler services. The setting takes effect immediately. However, after you enable the suspend function, you will need to log in to JP1/AJS3 - View before you can perform operations in JP1/AJS3 - View.

Cautionary note

Once you activate the suspend function using the ajssetup -m command, the setting is permanent.

(a) Executing the suspend function

You can suspend a root jobnet using either the JP1/AJS3 - View window or the appropriate command.

Conditions required for suspension

The following conditions must be met before you can suspend a root jobnet:

• The JP1/AJS3 service is running

• There are no generations monitoring for a start condition (the status of the start condition is waiting or ended)

• The user who executes the command has the required permission

Accessing the suspend function from the JP1/AJS3 - View window

In the JP1/AJS3 - View window, from the Operations menu choose Suspension and then Suspend.

Accessing the suspend function using a command

Execute the ajssuspend command, specifying the -S option.

When you execute the suspend function, you can specify whether to suspend the jobnet if a unit is executing.

(b) Checking the suspension status

To check whether the root jobnet is suspended, use the JP1/AJS3 - View window or the appropriate command.

Using the JP1/AJS3 - View window

An icon indicating the suspension status is displayed in the list area of the JP1/AJS3 - View window.

Using a command

Execute the ajsshow command with the -i option, and specify the 2-byte format indicator %SP.

The command format is as follows.

ajsshow -i %SP

For details on the ajsshow command, see the description of ajsshow in 3. Commands Used for Normal Operations in the manual JP1/Automatic Job Management System 3 Command Reference.

(c) Releasing the suspension

You can release a suspended root jobnet using the JP1/AJS3 - View window, or an appropriate command.

Conditions for releasing suspension

The following conditions must be met before you can release a suspended root jobnet:

• The JP1/AJS3 service is running.

• The user has the appropriate permission to perform the operation.

• The target is not being edited exclusively elsewhere.

Releasing suspension using the JP1/AJS3 - View window

In the JP1/AJS3 - View window, from the Operations menu choose Release Suspension.

Releasing suspension using a command

Execute the ajssuspend command, specifying the -C option.

If you cold-start the JP1/AJS3 service, suspension is released automatically, and execution registration is also canceled automatically.

(d) Behavior of added units after suspension is released

When you release the suspension, you can specify the behavior of units added under a running jobnet. However, this does not apply to units added under a remote jobnet.

You can specify one of the following three options. The name of the option, and the behavior of the unit after suspension is released are described in the paragraphs below.

Execute

This option executes the added units.

When you release the suspension, units added directly below a running jobnet enter the Waiting for prev. to end status. These units are executed as soon as the previous unit ends. If all preceding units have already ended normally when you release the suspension, then the added units are executed immediately.

This option is assumed if you execute the command without specifying an option.

Do not execute (stop)

This option cancels execution of the added units.

When you release the suspension, execution of the units that were added directly under a running jobnet is canceled. The units then have the status Bypassed.

Hold

This option temporarily changes the status of the added units to Held.

When you release the suspension, the units that were added directly under a running jobnet temporarily change to Held status.

The status of an added unit when you release the suspension with one of these options specified, depends on the status of the unit one level above the added unit. The following table shows the relationship between the status of the upper-level unit and the status of the added unit.

Table 4‒14: Status of added unit when suspension is released with specified option

Status of unit one level above added unit	Option
	Execute or no option specified	Do not execute (stop)	Hold
Running	Waiting for previous unit to end (changes to Now running when the previous unit ends normally)	Bypassed	Waiting for previous unit to end (changes to Being held when the previous unit ends normally)
Waiting	Waiting for previous unit to end	Waiting for previous unit to end	Waiting for previous unit to end
Ended	Bypassed	Bypassed	Bypassed

Cautionary note

If a unit that was added during suspension is bypassed, the plan change for that unit is set to Execution prohibited. It you need to execute the unit (by rerunning it, for example), you can add an execution schedule by changing the time (only applies if the unit is a jobnet), or releasing the changes made by the change plan.

(a) Status change of suspended jobs

The status of a suspended job changes as follows:

• A job that is already running when the root jobnet is suspended continues to run. When the timeout period of the job expires, the job no longer executes. When the job finishes executing, its status changes to Ended. Delay monitoring also continues. When the delay time arrives, the job enters Delayed status, but upper-level units are not affected. The status of upper-level units changes when suspension is released. The following figure shows the suspension of a job in Now running status.

  Figure 4‒50: Status change of suspended job 1 (in "Now running" status)

• Units under the suspended root jobnet will not be executed again.

  The following figure shows the suspension of a job in Waiting for previous to end status.

  Figure 4‒51: Status change of suspended job 2 (in "Waiting for previous to end" status)

(b) Status change in suspended jobnets (excluding remote jobnets)

• A jobnet (excluding remote jobnets) that has the Now running status when the root jobnet is suspended retains that status even if all lower-level units have ended. In addition, delays and timeout periods (skipping) are not monitored.

  The following figure shows the suspension of a jobnet in Now running status.

  Figure 4‒52: Status change of suspended jobnet (in "Now running" status)

(c) Status change in suspended remote jobnets

When you suspend the root jobnet, only the status of a remote jobnet that is running changes. The statuses of succeeding jobs and upper-level units do not change.

(d) Status change when the JP1/AJS3 service is hot-started during suspension

If the JP1/AJS3 service stops while the root jobnet is suspended and is then hot-started, jobs with the Now running status continue to execute. However, the status of such jobs does not change to ended when the jobs finish executing. The status of the jobs only changes to ended when you release the suspension.

The following figure shows the status change when the JP1/AJS3 service is hot-started during suspension.

Figure 4‒53: Status change when the JP1/AJS3 service is hot-started during suspension

Assume that you hot-start the JP1/AJS3 service while the root jobnet is suspended. Assume that you then add a unit as a preceding unit to a running unit, and specify the Execute option when you release suspension of the root jobnet. The status of the unit that was running changes to Ended after the unit you added terminates.

The following figure shows the status change when the JP1/AJS3 service is hot-started during suspension.

Figure 4‒54: Status change when the JP1/AJS3 service is hot-started during suspension (Execute option specified)

(e) Status change when the JP1/AJS3 service is warm-started during suspension

If the JP1/AJS3 service stops while the root jobnet is suspended and is then warm-started, the root jobnet maintains its suspended status. However, the status of running jobs changes to Unknown end status, the status of running jobnets changes to Interrupted, and the status of units added below a running jobnet changes to Bypassed.

An end delay is not detected if the delay monitor time is reached for a unit during suspension.

The following figure shows the status change when the JP1/AJS3 service is warm-started during suspension.

Figure 4‒55: Status change when the JP1/AJS3 service is warm-started during suspension

(f) Notes on restarting the JP1/AJS3 service with a cold-start during suspension

If the JP1/AJS3 service stops while the root jobnet is suspended, and you restart it with a cold-start, the unit records deleted during the suspension remain in the database as invalid records. In such a case, execute the following command on all root jobnets to delete the invalid records.

ajssuspend -U -R -T / 

(g) Status change when the JP1/AJS3 service is disaster-recovery-started during suspension

If the JP1/AJS3 service stops while the root jobnet is suspended and is then disaster-recovery-started, the root jobnet maintains its suspended status. However, the status of running jobs changes to Unknown end status, the status of running jobnets changes to Interrupted, and the status of units added below a running jobnet changes to Bypassed.

An end delay is not detected if the delay monitor time is reached for a unit during suspension.

After the service is restarted by disaster recovery start, job execution is suppressed. For the jobs to run, cancel suppression of execution.

The following figure shows the status change when the JP1/AJS3 service is disaster-recovery-started during suspension.

Figure 4‒56: Status change when the JP1/AJS3 service is disaster-recovery-started during suspension

(a) Allocating a schedule when the suspension is released

The allocation of a schedule to a unit after the suspension is released is described below, according to the category of execution registration that applies to the unit.

When the root jobnet is registered for immediate execution or fixed execution with a specified date

As is normal with immediate execution registration and fixed execution registration with a specified date, the date specified in the fixed execution registration time is allocated as the scheduled start time. However, if the upper-level jobnet does not have an execution schedule (execution is prohibited), then the scheduled start time of the added jobnet becomes None, since although the scheduled start time of the added jobnet is allocated as above, the upper-level jobnet does not have a scheduled start time.

The following example shows an example of suspending the root jobnet and adding units.

Figure 4‒59: Example of adding units to a root jobnet that is registered for immediate execution

The following table shows how the schedule is allocated after releasing suspension.

Table 4‒15: Schedule after releasing suspension (for immediate execution registration and fixed execution registration with a specified date)

Unit	11/30	12/1	12/2	12/3
A	--	12:00	--	--
B	--	12:00	--	--
C	--	12:00	--	--
D	--	12:00	--	--
E	--	12:00	--	--

Legend:

-- : Does not apply

When the root jobnet is registered for planned execution

Schedules are recalculated for all jobnets in waiting generations whose root jobnet has not been rerun. Schedules are recalculated only for those jobnets added to jobnets in generations whose root jobnet is running or being rerun. The exclusive schedule of the uppermost added jobnet becomes invalid.

The following figure shows an example of adding units after suspending the root jobnet that is registered for planned execution.

Figure 4‒60: Adding units to a root jobnet registered for planned execution

Imagine the current date is December 1 (Friday), and you change the configuration of the application before it starts on December 1 (Friday). The application for November 30 (Thursday) is rerunning, and jobnet B is currently running. Based on this information, the following schedule is allocated after the suspension is released.

Table 4‒16: Schedule after suspension is released (when registered for planned execution)

Jobnet	11/24 (Fri)	11/25 (Sat)	11/26 (Sun)	11/27 (Mon)	11/28 (Tue)	11/29 (Wed)	11/30 (Thu)	12/1 (Fri)	12/2 (Sat)
A	EN	EN	EN	EN	EN	EN	NR	(WS)	WS
B	BP	BP	BP	BP	BP	BP	NR	(WP)	NS
C	BP	BP	BP	BP	BP	BP	(WP)	(WP)	WP
D	BP	BP	BP	BP	BP	BP	(NS)	(WP)	NS
E	EN	BP	BP	BP	BP	BP	(WP)	(NS)	NS

Legend:

EN : Ended normally

BP : Bypassed

NR : Now running

WS : Waiting for start time

WP : Waiting for prev. to end

NS : Not sched. to exe.

( ) : Recalculated schedule

In this example, the schedule for November 30 is recalculated for jobnet C, and for the jobnets below jobnet C (D and E). Also, the exclusive schedule of jobnet B and jobnet C becomes invalid. On December 12, the exclusive schedule is valid, since the schedule is recalculated from the uppermost jobnet.

When the root jobnet is registered for fixed execution

Schedules are recalculated only for those jobnets added to jobnets whose root jobnet is waiting or running. Also, the exclusive schedule of the added uppermost jobnet becomes invalid.

The following figure shows an example of adding units after suspending a root jobnet that is registered for fixed execution.

Figure 4‒61: Adding units to a root jobnet registered for fixed execution

Imagine the current date is December 1 (Friday), and you change the configuration of the application before it starts on December 1 (Friday). The application for November 30 (Thursday) is rerunning, and jobnet B is currently running. Based on this information, the following schedule is allocated after the suspension is released. Assume that the root jobnet is registered for fixed execution until December 6.

Table 4‒17: Schedule after suspension is released (when registered for fixed execution)

Jobnet	11/29 (Wed)	11/30 (Thu)	12/1 (Fri)	12/2 (Sat)	12/3 (Sun)	12/4 (Mon)	12/5 (Tue)	12/6 (Wed)
A	EN	NR	WS	WS	WS	WS	WS	WS
B	BP	NR	WP	NS	NS	NS	NS	NS
C	BP	(WP)	(WP)	(WP)	(WP)	(WP)	(WP)	(WP)
D	BP	(NS)	(WP)	(NS)	(NS)	(NS)	(NS)	(NS)
E	BP	(WP)	(NS)	(NS)	(NS)	(NS)	(NS)	(NS)

Legend:

EN : Ended normally

BP : Bypassed

NR : Now running

WS : Waiting for start time

WP : Waiting for prev. to end

NS : Not sched. to exe.

( ) : Recalculated schedule

When a jobnet is registered for fixed execution over a specified period, the schedules of existing generations are not recalculated when the suspension is released. In the above example, schedules are recalculated for jobnet C and the jobnets (D and E) below it, and the exclusive schedules defined for jobnet B and jobnet C become invalid. When a jobnet is registered for fixed execution with the number of future generations, schedules are recalculated from the uppermost jobnet of the jobnets in the generations created after the suspension is released, and exclusive schedules become valid.

(b) Execution schedules after suspension is released

When you register a jobnet for planned execution or fixed execution with a specific number of future generations, JP1/AJS3 assigns a new generation each time the jobnet is executed. Therefore, when you display past results and future plans using the Monthly Schedule or Daily Schedule window, or the ajsshow command, the execution schedules shown below are created by schedule simulation.

• When the jobnet is scheduled for planned execution

  Execution schedules are created for the generation after next, and succeeding generations.

• When the jobnet is scheduled for fixed execution with a specific number of future generations

  Execution schedules created for generations after the specified number of future generations.

Therefore, if the suspension is not released before the next scheduled execution of the root jobnet, the execution schedule of the jobnet may be affected by events like the skipping process that occurs when suspension is released. For this reason, try to ensure that the suspend operation does not last for more than one generation.

The following table shows an example of a jobnet that was registered for planned execution on June 12.

Table 4‒18: Jobnet registered for planned execution on June 12

	6/10	6/11	6/12	6/13	6/14	6/15	6/16	6/17	6/18	6/19	6/20
Jobnet	EN	EN	EN	SN	SS	SS	SS	SS	SS	SS	SS

Legend:

EN : Ended normally

SN : Scheduled next

SS : Schedule simulation

The JP1/AJS3 database stores information for the above jobnet that was registered on June 12, about the generation scheduled to execute on June 13. Unless you suspend this jobnet when it finishes executing on June 12, and release the suspension only after June 14, the schedule for June 13 remains. It will then be subjected to the skipping process after the suspension is released. In this case, a Skipped so not executed generation may be created, or an execution schedule may be skipped.