Hitachi

JP1 Version 12 JP1/Automatic Job Management System 3 Overview


4.1.1 Methods of registering a jobnet for execution

JP1/AJS3 begins processing a defined jobnet when you have registered it for execution. Registration is an operation performed on the root jobnet. When you register the root jobnet, all lower units are also registered.

JP1/AJS3 provides three methods of registering a jobnet for execution:

The following table summarizes the features of each registration method.

Table 4‒1: Methods of registering a jobnet for execution

Registration method

Features

Immediate execution

Execution timing:

The jobnet is executed as soon as it is registered, regardless of the calendar information and the schedule information set for the jobnet.

Modifying the calendar information or schedule:

Not applicable. The calendar information and jobnet schedule information are not referenced.

Temporarily rescheduling the jobnet (by menu option or command):

Not applicable. There is no execution schedule.

Other features:

You cannot restrict the number of executions. However, if you set a start condition for the jobnet, you can set an execution count or a start-condition monitoring time.

Examples of usage:

Mainly used for jobnets that are started manually or by command.

Examples are a jobnet executed immediately at user request, a jobnet executed from a user program, and a jobnet executed in response to a processing result from an external program such as file transfer software.

Planned execution

Execution timing:

The jobnet is scheduled and executed according to the calendar information and the schedule information set for the jobnet. The calculated schedule is treated as a dummy schedule (simulated execution schedule).

Modifying the calendar information or schedule:

If you change the calendar information or redefine the jobnet's schedule information, JP1/AJS3 reschedules the jobnet based on the new information.

Temporarily rescheduling the jobnet (by menu option or command):

No temporary changes can be made to a schedule calculated when the jobnet is registered (rescheduling is invalid because the schedule is simulated, not fixed). However, because the next dummy schedule will be fixed once the jobnet starts execution, you can make a temporary change to the next execution schedule.

Examples of usage:

Mainly used when changes to calendar information or schedule information may be necessary in the future, and for jobnets that never need to be temporarily rescheduled.

This registration method lets you modify calendar information and schedule information without canceling the registration: for example, when open/closed days need to be redefined for the next business year, or when a jobnet schedule changes.

Fixed execution

Execution timing:

The jobnet is executed for a specified period or for a specified number of generations. The schedule based on the specified period or generation count is calculated and fixed from the calendar information and the schedule information set for the jobnet.

Modifying the calendar information or schedule:

Changes to the calendar information or jobnet's schedule information take effect after the jobnet has run for the specified period or number of generations. To apply schedule changes, you must cancel and then re-register the jobnet.

Temporarily rescheduling the jobnet (by menu option or command):

Temporary changes can be made to a fixed schedule.

Adding execution dates (from a menu or command):

Execution dates can be added.

Examples of usage:

Mainly used for jobnets that run for a set period or for a set number of executions, and for jobnets with a fixed schedule that may require a temporary addition, change, or suspension. For example, you can change the execution schedule for a specified date, or suspend execution, without canceling the jobnet registration.

The following pages describe jobnet behavior under each of these registration methods. Choose a method appropriate for your purposes, based on the features of each registration method. To register jobnets for execution, use JP1/AJS3 - View, the Web GUI, the API, or commands. For details about execution registration procedures, see the relevant sections in the following manuals:

For details on redefining or rescheduling a registered jobnet, see 4.5 Operations on registered jobnets.

Supplementary notes
  • If a jobnet for which a planned execution was performed has the status Not sched. to exe., an execution schedule with the status Not sched. to exe. is created as the next execution schedule. However, if a jobnet for which immediate execution or fixed execution was performed has the status Not sched. to exe., an execution schedule with the status Not sched. to exe. is not created.

  • When you re-register a jobnet that has been registered for execution, the execution-registration type of the newly-created execution schedule is the type that you select during that re-registration process. However, a jobnet that was registered for planned execution can be re-registered for execution when the status of the jobnet is Not sched. to exe.. If you do this, the execution schedule with the Not sched. to exe. status is deleted, and an execution schedule that has the registration type that you selected during the re-registration process is created.

Organization of this subsection

(1) Immediate execution

When you register a jobnet for immediate execution, it is executed once only at the time of registration, regardless of the schedule definition and calendar definitions. The jobnet is executed immediately even if you have set schedule information.

Supplementary note

In JP1/AJS3, if a jobnet is not scheduled to be executed again, you can register that jobnet for execution multiple times. A jobnet registered for immediate execution is not scheduled to be executed again, so you can re-register the jobnet for execution even if the jobnet has already been registered for immediate execution.

(2) Planned execution

In planned execution, the jobnet is scheduled based on its schedule definition and the calendar information set for the job group to which the jobnet belongs.

When you register a jobnet for planned execution, only its first execution is fixed, and subsequent executions are treated as dummy runs (simulated schedules). For details on dummy runs, see 4.4.2(1) Schedule simulation. The jobnet's next run is finalized when the current run starts.

The following figure shows generation of the next run when a jobnet is registered for planned execution.

Figure 4‒1: Generation of the next execution schedule at registration for planned execution

[Figure]

A jobnet registered for planned execution can be re-registered when the execution schedule of the root jobnet is in Not scheduled to execute status.

Also, once you have registered a jobnet for planned execution, if you then redefine its schedule rule or change the calendar of the job group to which the jobnet belongs, JP1/AJS3 immediately reschedules the jobnet according to the new settings. If you change the schedule rule of a jobnet that has an exclusive schedule, JP1/AJS3 will reschedule other jobnets on the same hierarchical level as that jobnet according to the new schedule rule settings. Note that changes to the schedule definition or calendar definition apply to the next scheduled generation. They do not affect the generation now running (zero or positive jobnet generation number). For details on jobnet generation numbers, see 4.2.2 Jobnet generation number.

Cautionary note

Do not change the base time of a jobnet that has been registered for execution because it would complicate the schedule calculations. Also, depending on what time you set and when you make the change, the jobnet might be scheduled on that day and execute immediately. If you need to change the base time, unregister the jobnet first.

Supplementary note

While an application is running in a jobnet registered for planned execution, if the schedule definition of the jobnet is changed, JP1/AJS3 immediately recalculates the next execution time based on the new schedule definition. Depending on the change, JP1/AJS3 may create a schedule that executes the jobnet immediately, on the same day the change was made and the new schedule was calculated. The following figure shows examples of changing the schedule definition for a jobnet.

Figure 4‒2: Examples of changing the schedule definition

[Figure]

In these examples, the jobnet start time of 8:00 set in the schedule definition is changed to (a) 7:00, (b) 9:00, and (c) 11:00.

(a) Start time is changed to 7:00

The 8:00 run has already finished. No further runs will be created for that day.

(b) Start time is changed to 9:00

The 8:00 run has already finished. Because there is no execution schedule at 9:00 on that day, a 9:00 run is generated. The start time was changed at 10:00, so the jobnet is executed immediately.

(c) Start time is changed to 11:00

As in (b), an 11:00 run is generated. The start time was changed at 10:00, so the jobnet will be executed at 11:00.

As described above, depending on the change to the schedule definition, JP1/AJS3 may create a schedule for execution prior to the current time, and may execute it immediately. If you want to avoid executing the new schedule on the same day the changes were made, as in examples (b) and (c), set a later start day when changing the schedule definition.

In the same way as the change to the schedule definition, if the calendar definition is changed, the schedule of jobnets registered for planned execution is re-calculated. Depending on the change, JP1/AJS3 may create a schedule that executes the jobnet on the same day, executing the jobnet immediately. The following figure shows examples of changing the calendar definition for a jobnet.

Figure 4‒3: Examples of changing the calendar definition

[Figure]

In these examples, August 2 is set in the jobnet's calendar definition as an open day, and August 1 is set as a closed day. Changing the open day to August 1 will have the following effects on the jobnet schedule:

(a) August 1 is changed to an open day (scheduled start time is after the calendar change)

Because there is no execution schedule on August 1, an execution schedule is created as the next run. The jobnet will be executed on August 1 at the 8:00 start time set in the schedule definition.

(b) August 1 is changed to an open day (scheduled start time is before the calendar change)

Because there is no execution schedule on August 1, an execution schedule is created as the next run. The 8:00 start time set in the schedule definition is already past, so the jobnet is executed as soon as the calendar definition is changed.

(c) August 3 is changed to an open day (the execution schedule on August 2 is after the calendar change)

Because the next run is scheduled for August 2, the execution schedule on August 3 is created as a dummy run. Once the jobnet starts execution on August 2, the dummy run on August 3 will become the next run and the jobnet will be executed at 8:00 on that date.

(3) Fixed execution

There are three ways of registration for fixed execution: specifying a fixed schedule period; specifying the number of future generations (number of executions); and specifying a specific date and time in addition to the schedule definition for the jobnet.

Specifying a fixed schedule period

JP1/AJS3 creates fixed execution schedules within the specified period, based on the jobnet schedule definition and the calendar information set for the job group to which the jobnet belongs.

No schedule information is generated after the fixed schedule period. (No dummy runs are generated either.)

However, you can register the same jobnet multiple times for period-based fixed execution, even if the periods overlap. If multiple schedules are generated for exactly the same time, the jobnet runs the number of times it was registered.

Specifying the number of future generations

JP1/AJS3 creates fixed schedules for the specified number of generations, based on the jobnet schedule definition and the calendar information set for the job group to which the jobnet belongs.

Dummy runs (simulated schedules) are created for each generation after the specified generation count. For details on dummy runs, see 4.4.2(1) Schedule simulation. JP1/AJS3 continues to fix the execution schedules for the specified number of generations. At the same time, as each succeeding generation starts execution, a new execution schedule is created, the next dummy run is changed into a firm schedule. For details on generations, see 4.2 Managing jobnet generations.

Specifying a specific date and time

JP1/AJS3 adds a schedule for a jobnet to be executed on the specified date and time, regardless of the schedule definition for the jobnet.

For details, see 4.5.2 Adding an execution schedule to a jobnet.

Unlike planned execution, a jobnet registered for fixed execution is not immediately rescheduled if you redefine the jobnet's schedule rule or change the calendar information set for the job group to which the jobnet belongs.

The following figure illustrates the difference between fixed execution and planned execution.

Figure 4‒4: Difference between fixed execution and planned execution

[Figure]

When a jobnet is registered for planned execution, the schedule is recalculated as soon as any change is made to the schedule rule or calendar definitions. In the above example, the changes made after the second run are immediately applied to the third run. In the case of the jobnet registered for fixed execution, however, the execution schedules are fixed for the set period (Fixed schedule period) or for the set number of generations (Future generation), so those execution schedules are not recalculated.

When fixed execution is specified by generation count, JP1/AJS3 continues fixing each succeeding execution schedule up to the specified number. When the first generation starts running, a new execution schedule is generated (fixed). In the above example, 2 is set in Future generation. This means that the third execution schedule is generated when the first starts running, and the fourth is generated when the second starts running. Each new execution schedule is based on the schedule information and calendar definition current at the time at which that schedule was generated. Therefore, in this example, the new schedule information affects the fifth and subsequent runs. In contrast, when fixed execution is specified by period, because there are no scheduled runs after that specified period, any changes to the schedule information take effect the next time the jobnet is registered for execution.

Cautionary notes
  • If you set both Fixed schedule period and Future generation when registering a jobnet for fixed execution, the period setting applies if there are more generations during that period than the specified generation count, but the generation count applies if there are fewer generations than specified during the set period. Dummy runs are generated for executions after the end of the specified period or generation count. These dummy runs become fixed schedules in the same way as when Future generation only is set.

  • Suppose that you register a jobnet for fixed execution by specifying the number of future generations, and then you change the schedule definition without releasing the jobnet registration. Dummy schedules are created with the changed schedule definition starting from a date and time later than the start time of the fixed execution schedule. Accordingly, after you change the start time, both the execution schedule with the pre-change start time and the execution schedule with the post-change start time might be performed on the same day. If you change the start time, also specify the start year, month, and day, and make sure that the execution schedule is specified as you intended. If an execution schedule or dummy schedule that does not need to be executed exists, cancel it.

    The following figure shows an example of changing the start time of the schedule definition.

    Figure 4‒5: Example of changing the start time of the schedule definition

    [Figure]

    In this example, a jobnet is registered for fixed execution with 2 specified as the number of future generations, and the execution schedules for 9:00 on August 1 and for 9:00 on August 2 are fixed.

    Suppose that, before 9:00 on August 1, you change the start time of the jobnet from 9:00 to 10:00. Because the execution schedules for 9:00 on August 1 and 9:00 on August 2 are fixed, the change to the schedule rule is not applied. However, a dummy schedule is created at 10:00 on August 2, which is later than the start time of the fixed execution schedule.

    After the schedule for 9:00 on August 1 is executed, the dummy schedule for 10:00 on August 2 becomes a fixed schedule because the number of future generations is set to 2.

    When you change the schedule so that the jobnet is executed at 9:00 until August 2 and at 10:00 then from August 3, set Start year and month and Start day of the schedule rule to August 3, and set Start time to 10:00.

  • You can increase the number of scheduled generations after registering a jobnet for fixed execution. To do so, you must first cancel registration, change the Future generation setting, and then re-register the jobnet for fixed execution.

  • Use the same JP1 user when registering a jobnet for fixed registration that specifies both number of future generations and then registering a jobnet for fixed registration that specifies a fixed period or time.

    When the number of future generations is specified, new execution schedules will be generated when, for example, jobnet execution starts. When a new execution schedule is generated, the registering entity in the previous execution result becomes the registering entity in the new execution schedule. Accordingly, if different users specify the number of generations and a period or time, the registering entity in a newly generated execution schedule might change depending on who registered the previous execution result.

    For details about the registering entity (user who registered), see 7.2.3 Setting the Executed by attribute.

  • After the status of a jobnet that is registered for fixed execution and that has the number of future generations specified changes to Not sched. to exe., if you register the jobnet for fixed execution by specifying a fixed schedule period or by specifying a specific date and time, the specified number of future generations is no longer in effect and the jobnet is treated as a jobnet that is registered for fixed execution with either a fixed schedule period or a specific date and time specified.

  • After the status of a jobnet that is registered for fixed execution and that has the number of future generations specified changes to Not sched. to exe., if you change the schedule definition or calendar definition, no execution schedule is created. To change the schedule definition or calendar definition to create an execution schedule, re-register the jobnet for execution.

  • If an invalid unit (non-existent unit, for example) is specified in an exclusive schedule or in a job group that references the calendar information, the schedules after the specified generation count will not be generated.

  • When different schedules are set for the root jobnet and for a nested jobnet, the nested jobnet's start time is automatically changed to the root jobnet's start time only if the root jobnet is rescheduled to a different day.

  • When you register a jobnet for fixed execution by using the ajsentry command, JP1/AJS3 - View, the Web GUI, or the API, a large amount of memory might be needed under certain conditions. For example, a large amount of memory is needed if the jobnet for fixed execution contains many units or has many generations. If registration of a jobnet requires too much memory, reduce the number of units in the jobnet, shorten the fixed schedule period, or reduce the number of future generations to reduce the scale of processing. See the Release Notes for details on how to estimate memory requirements.

Possible errors when registering a jobnet for execution

The following settings result in an error at jobnet registration:

  • Past date set as the start day, and no processing cycle set in the schedule rule.

  • Invalid date (for example, 2/30) set as the start day in the schedule rule.

  • Closed day set as the start day, but no closed day set in the calendar definition in the schedule rule.

  • Closed day set as the start day, but Do not execute set in Substitute schedule of closed day job in the schedule rule.

  • Do not execute set in Substitute schedule of closed day job, but a closed day set for every day in the calendar definition.

  • Schedule rule for the root jobnet also set for a jobnet specified as an exclusive schedule (all execution schedules will therefore be treated as exclusive schedules).

  • Definition such that the same execution date cannot be calculated from the schedule rule number set for the upper-level jobnet and the number of the corresponding schedule rule for the nested jobnet.

  • Invalid unit (non-existent unit, for example) specified in an exclusive schedule or in a job group that references the calendar information.

    In this case, the jobnet is placed in Shutdown status.

  • Jobnets scheduled close together.

    Under planned execution, schedules are adjusted dynamically according to their status and execution times. This might result in runs not being generated as scheduled.

When a schedule with any of the above settings is set for a nested jobnet, the jobnet will be placed in Not scheduled to execute status. You must temporarily reschedule the jobnet to execute it.

(4) Jobnet with a start condition

When a jobnet with a start condition is registered for planned or fixed execution, monitoring for the start condition begins at the start time specified in the schedule rule. If you register the jobnet for immediate execution, monitoring begins as soon as the jobnet is registered.

For details on the behavior of a jobnet with a start condition after it is registered, see 3.4 Defining a start condition.

(5) Setting a hold during registration for execution

You can set whether to hold the execution of a root jobnet when registering the root jobnet for execution. If you set a hold during registration for execution, you can hold the execution of the root jobnet that you register, even if a hold is not defined.

If you set a hold during registration for execution, the hold attribute is set for the first of the generations created during registration for execution. The following figure shows the generation for which the hold attribute is set during registration for planned execution or for fixed execution.

Figure 4‒6: Generation for which the hold attribute is set during registration for planned execution or for fixed execution

[Figure]

If you perform more than one registration for fixed execution for which the execution period is specified, the hold attribute is set for only the first generation created for each registration for execution. The following figure shows the generations for which the hold attribute is set when more than one registration for fixed execution for which the execution period is specified is performed.

Figure 4‒7: Generations for which the hold attribute is set when more than one registration for fixed execution for which the execution period is set is performed

[Figure]