Hitachi

JP1 Version 12 JP1/Automatic Job Management System 3 Overview


4.5.16 Displaying and re-executing temporary change operations for a job or jobnet

You can display information about Change Plan, Change Hold Attribute, and other operations performed on a job or jobnet in list format for checking purposes. This information is called temporary change information.

Also, you can select specific operations in the Temporary Changes list that is displayed, and re-execute those operations for the job or jobnet. The re-execution of a temporary change operation is called the re-execution of a temporary change.

Users are able to display temporary change information and perform re-execution of temporary changes by setting yes for the SAVEPLANINFO environment setting parameter. For details about the SAVEPLANINFO environment setting parameter, see 20.4 Setting up the scheduler service environment in the JP1/Automatic Job Management System 3 Configuration Guide.

Organization of this subsection

(1) Displaying temporary change information

You can display temporary change information in the Temporary Changes dialog box of JP1/AJS3 - View and output the displayed information to a CSV file or the standard output by using the ajsplanout command. For details about how to display temporary change information, see 9.17.1 Displaying temporary changes in the JP1/Automatic Job Management System 3 Operator's Guide. For details about the Temporary Changes dialog box, see 12.3.40 Temporary Changes dialog box in the JP1/Automatic Job Management System 3 Operator's Guide. For details about the ajsplanout command, see ajsplanout in 3. Commands Used for Normal Operations in the manual JP1/Automatic Job Management System 3 Command Reference.

(a) Operations saved as temporary change information

The following operations can be saved as temporary change information:

  • Change Plan operations (Change Time, Execute Immediately, Execution Prohibited, and Release Change)#

  • Change Hold Attribute operations (Hold and Hold-Release)#

  • Change Delay Monitor operations (Monitor start delay, Monitor end delay, and Monitor jobnet)#

  • Change Priority operations#

  • Change Execution Order Method operations (Synchro and Asynchro)#

  • Disabling a start condition, changing the time the system will wait for the start condition to be satisfied, and changing the number of times the system will wait for a start condition to be satisfied#

  • Temporary change operations for wait conditions (disabling and enabling a wait)#

  • Adding an execution schedule

  • Canceling registration by specifying the generation#

#

The execution registration number is saved as temporary change information even when the generation subject to an operation is specified by the execution ID or by the function for automatically determining the generation.

When a user performs a temporary change operation, the relevant temporary change information is saved in JP1/AJS3 - Manager. Note that the information is saved only when the temporary-change operation and management functionality is enabled by setting yes for the SAVEPLANINFO environment setting parameter. Information about temporary change operations performed before yes is set for SAVEPLANINFO is not displayed in the list.

Supplementary notes:
  • If a temporary change operation is performed for multiple units by a command in which multiple unit names are explicitly specified or with wildcard characters, temporary change information is saved separately for each unit.

  • If a temporary change operation is performed by the ajsplan command with a planning group specified, the temporary change information for the planning group is not saved. However, the temporary change information for the root jobnet automatically selected by the -x option is saved.

  • When a user requests the displaying of the temporary change information list for a unit, JP1/AJS3 checks whether the user has view permission for the root jobnet of the unit. The list is displayed only when the user has this permission. The permissions for the unit and its subordinate units are not checked.

  • When a user requests the displaying of the temporary change information list for a root jobnet registered for release, JP1/AJS3 checks whether the user has view permission for the root jobnet currently in use.

(b) Storage period for temporary change information

The following table describes how long the temporary change operations performed for a job or jobnet are saved as temporary change information.

Table 4‒9: Storage period for temporary change operations

No.

Temporary change category

Storage period

1

Change Plan operations

  • Change Time

    This item is saved until the scheduled start time existing before the change or the scheduled start time existing after the change, whichever is later.

  • Execute Immediately

    This item is saved until the scheduled start time of an execution schedule that is executed immediately.

  • Execution Prohibited

    For a root jobnet registered for planned execution, this item is saved until the scheduled start time of the next execution schedule, which is determined after execution is prohibited, arrives.#

    For other root jobnets, this item is saved until the scheduled start time of an execution schedule whose execution is prohibited arrives.

  • Release Change

    This item is saved until the storage period for the released temporary change operation expires.

2

Change Hold Attribute operations

This item is saved until the scheduled start time of a temporarily changed execution schedule arrives.

3

Change Delay Monitor operations

4

Change Priority operations

5

Change Execution Order Method operations

6

Disabling a start condition, changing the time the system will wait for a start condition to be satisfied, and changing the number of times the system will wait for a start condition to be satisfied

7

Temporary change operations for wait conditions

8

Adding an execution schedule

This item is saved until the scheduled start time of the added execution schedule arrives.

9

Canceling registration by specifying the generation

This item is saved until the scheduled start time of an execution schedule whose execution registration is canceled arrives.

#

For a root jobnet registered for release, if execution of the execution schedule immediately before a release is prohibited, temporary change information is saved until the scheduled start time of the execution schedule whose execution is prohibited arrives.

However, the storage period for temporary change information changes depending on whether the schedule of the root jobnet is based on 24-hour system or 48-hour system.

  • For a schedule based on 24-hour system

    Temporary change information is saved for 24 hours beginning with the base time for the storage period for temporary change information (if the base time is 0:00:00, the information is saved until 23:59:59).

  • For a schedule based on 48-hour system

    Temporary change information is saved for 48 hours beginning with the base time for the storage period for temporary change information (if the base time is 0:00:00, the information is saved until 47:59:59).

If multiple temporary change operations have been performed for a temporarily changed execution schedule, temporary change information is saved until all the storage periods for these operations have expired.

(c) Notes

  • Be careful if the local time for the scheduler service has been changed by using the ajslocaldate command. If the time has been changed, the temporary change information output by the ajsplanout command and the information displayed by choosing Temporary Changes in the JP1/AJS3 - View window or another window might be different.

    The current time used as the base for the start date when the ajsplanout command is executed without the -b option specified differs from the current time used as the base when Temporary Changes is chosen. The following describes the differences:

    • When the ajsplanout command is executed without the -b option specified

      The current time is the local time of the scheduler service that manages the specified jobnet.

    • When Temporary Changes is chosen

      The current time is the time of the system in which JP1/AJS3 - View is running.

    The Temporary Changes dialog box can simultaneously display the temporary change information for multiple scheduler services. The system time is used so that the base time does not depend on the scheduler service.

  • Temporary change information is data that is stored in a directory for job error information. The required space increases every time a temporary change operation is performed. Note that when a root jobnet and its lower units have expired temporary change information saved, and on that jobnet, you perform an operation that was saved as temporary change information, the expired temporary change information is automatically deleted. For details about how to estimate required disk space, see 3.2.4 Estimating disk capacity in the JP1/Automatic Job Management System 3 System Design (Configuration) Guide.

(2) Re-execution of a temporary change

The temporary change operations selected in the Temporary Changes dialog box can be re-executed by clicking the Re-execute button. Re-execution of a temporary change is useful when a jobnet definition that will be switched by the jobnet release function has been temporarily changed before release of the jobnet definition is registered (release entry). In such cases, the temporary changes can be re-applied to the jobnet after the release entry has been performed.

The following figure shows an example in which temporary changes made before release entry are re-applied after release entry.

Figure 4‒45: Example of re-applying temporary changes after release entry

[Figure]

For details about the procedure for re-executing temporary change operations, see 9.17.2 Re-executing temporary changes in the JP1/Automatic Job Management System 3 Operator's Guide.

(a) Execution schedule for which temporary change operations are re-executed

In JP1/AJS3, when changing a jobnet definition temporarily, the target execution schedule can be specified by any of the following:

  • Execution ID

  • Automatic determination

  • Execution registration number

However, when re-applying the temporary changes, regardless of how the generation to which the changes were originally made was specified, the execution registration number is always used to specify the re-application target generation. Even if the generation to which temporary changes were originally made is specified by the execution ID or is determined automatically, the generation's execution registration number is obtained by translation. This number becomes the basis for specifying the generation to which temporary changes are re-applied.

The reason for this is that the following problems would arise if the target generation were specified by the execution ID or were determined automatically.

If the target generation were specified by the execution ID

When the jobnet definition of an execution schedule is switched by the jobnet release function, a new execution schedule is created with the new definition and is assigned a new execution ID.

If a new execution ID is assigned, the new execution schedule no longer has the execution ID that was specified when a temporary change operation was performed. Consequently, the execution schedule to which temporary changes are to be re-applied can no longer be determined.

If the target generation were determined automatically

The automatic generation determination function uses the current status of the execution schedule as the basis for determinations. If the jobnet definition of an execution schedule is switched by the jobnet release function, the status of the execution schedule changes. Accordingly, an unintended execution schedule might be automatically determined as the target for re-applying temporary changes after the jobnet definition is switched (release entry).

The following figure describes how the execution schedule to which temporary changes will be re-applied is determined.

Figure 4‒46: How the execution schedule to which temporary changes will be re-applied is determined

[Figure]

In this example, the Jobnet A execution schedule to be executed on August 2 has execution ID @A102, and the Hold attribute is set for the generation as a temporary change by specifying the execution ID. When Jobnet A is registered for release and jobnet release is performed for the execution schedule on and after August 2, the execution ID is translated to the execution registration number. For this reason, if the execution ID for the execution schedule to be executed on August 2 changes from @A102 to @A103, the execution schedule is identified from the execution registration number as the target for re-applying temporary changes.

Note, however, that the intended execution schedule sometimes does not become the target for re-applying temporary changes even if the translated execution registration number is used. The following explains cases in which temporary changes are not re-applied to the intended execution schedule.

When the setting for treating the execution registration number as a calendar date is used

When the setting for treating the execution registration number as a calendar date is used, temporary changes might not be re-applied to the target execution schedule after release entry.

The following figure shows an example in which the execution registration number is treated as a calendar date and the temporary changes cannot be re-applied.

Figure 4‒47: Example in which the execution registration number is treated as a calendar date

[Figure]

In this example, the Jobnet A schedule is based on 24 hours and has a base time of 8:00. To allow the Jobnet A execution schedule to be executed on August 2, the Hold attribute is set as a temporary change by specifying the execution ID. When Jobnet A is registered for release and jobnet release is performed for the execution schedule on and after August 2, the execution ID is translated to the execution registration number. In this example, the translated execution registration number means the first execution schedule to be executed on August 2. However, because the new start time of the execution schedule on August 2 is 25:00, which is actually 1:00 on August 3, the temporary changes cannot be re-applied with the execution registration number treated as a calendar date.

In cases such as this, temporary changes can be re-applied by changing the setting so that the execution registration number is treated as an execution date.

The following figure shows an example in which the execution registration number is treated as an execution date.

Figure 4‒48: Example in which the execution registration number is treated as an execution date

[Figure]

If the execution registration number is treated as an execution date, 25:00 on August 2 is treated as a time on August 2, not a time on August 3. Accordingly, because an execution schedule to be executed at 25:00 on August 2 is treated as an execution schedule of August 2, temporary changes can be re-applied to the execution schedule after the jobnet definition is released.

Note that whether to treat the execution registration number as a calendar date or an execution date is set by using the EXECREGISTRATIONNUMBER environment setting parameter.

Notes on using the EXECREGISTRATIONNUMBER environment setting parameter
  • In JP1/AJS3 upgraded from version 09-10 or earlier, EXECREGISTRATIONNUMBER is set to calendar (calendar date) by default. We therefore recommend that you change the setting to execution (execution date).

  • If you change the setting of the EXECREGISTRATIONNUMBER environment setting parameter during JP1/AJS3 operation, cold-start the scheduler service. If you do not do this, there might be a mismatch between the execution registration numbers in the temporary change information displayed in JP1/AJS3 - View or by a command and the execution registration numbers that JP1/AJS3 holds. Any such mismatch prevents temporary change operations from being re-executed correctly.

When the order of execution schedules changes because of an addition or deletion

If the order of execution schedules is changed by adding or deleting execution schedules, you might not be able to re-apply temporary changes to the intended execution schedule.

The following figure shows an example in which addition or deletion changes the order of execution schedules changes.

Figure 4‒49: Example in which the order of execution schedules changes because of an addition or deletion

[Figure]

In this example, the Jobnet A execution schedule to be executed on August 2 has execution ID @A102, and the Hold attribute is set for the schedule as a temporary change. The execution ID is used to identify the execution schedule.

When Jobnet A is registered for release and a jobnet release is performed for the execution schedule on and after August 2, the execution ID is translated to the execution registration number. According to the execution registration number, the first execution schedule to be executed on August 2 becomes the target for re-applying temporary changes. However, if execution schedule @A104 is added, because its start time is earlier than the start time of execution schedule @A103, execution schedule @A104 becomes the first execution schedule to be executed on August 2. As a result, temporary changes are re-applied to execution schedule @A104 rather than @A103.

If you add or delete schedule rules after release entry, you must verify that temporary changes will be re-applied as you intend, and that no problems exist as a result of re-applying temporary changes.

(b) Notes

The notes below apply to re-execution of temporary changes. Before you re-execute temporary change operations from the Temporary Changes dialog box, read the notes and confirm that no problems will occur as a result of re-execution.

Note that if an error occurs during re-execution of temporary changes, the Temporary Change Re-execution Processing Results dialog box displays information about the error. For details about the Temporary Change Re-execution Processing Results dialog box, see 12.3.41 Temporary Change Re-execution Processing Results dialog box in the JP1/Automatic Job Management System 3 Operator's Guide.

■ Notes on changing a jobnet definition

  • Do not change the name of a unit for which re-execution will be performed. If you do so, re-execution results in an error.

  • Do not delete a unit for which re-execution will be performed. If you do so, re-execution results in an error.

■ Notes on changing a schedule definition

  • Do not add or delete schedule rules for a jobnet for which re-execution will be performed. If you do so, re-execution of temporary changes will not be performed correctly or will result in an error.

  • Do not change the execution date in the schedule definition of a jobnet for which re-execution will be performed. If you do so, re-execution will not be performed correctly for the target execution schedule or will result in an error.

■ Notes on re-execution of a temporary change

  • If you make temporary changes to the jobnet definition of an execution schedule that has already been executed, do not use the temporary-change re-execution function. If you re-execute a temporary change for an execution generation that has been executed in the past, an error might occur.

  • If the immediate execution of a temporary change is re-executed, temporary changes are immediately re-applied.

  • If you make a time change to a different day that also spans the current time, do so manually without using re-execution of a temporary change. Re-execution of a temporary time change that spans the current time results in an error.

  • Operations for execution generations of a jobnet with a start condition are not saved.

  • Operations for generations whose status is Not sched. to exe are not saved.

  • For the execution schedules listed below, do not re-execute a temporary change. If you want to temporarily change these execution schedules, do so manually.

    • Execution schedules to be executed on the day specified as the release date for a jobnet registered for release by specifying a time other than the base time as the release time

    • (When the release entry of a jobnet registered for release by specifying a time other than the base time as the release time is canceled) Execution schedules to be executed on the day specified as the release date before the release entry is canceled

    For example, if the base time is 0:00 and a jobnet is registered for release by specifying 9:00 on July 10 as the release date, the execution schedule to be executed on July 10 applies. In this case, you cannot use re-execution of a temporary change for this execution schedule. To temporarily change this execution schedule, do so manually.

  • Do not perform re-execution of a temporary change for the same unit from multiple instances of JP1/AJS3 - View at the same time. If you do so, the same temporary changes will be re-applied more than once or temporary changes that were made into an unintended execution schedule will be re-applied.

  • When you use the ajsleave command to cancel registration, you can specify the target generation by using either the execution ID or the execution registration number. If you choose to use the execution registration number for specifying the target generation, you can use one of the following specification formats:

    • all

    • schedule

    • result

    • YYYYMMDD#

    • YYYYMMDDNNN#

    #

    YYYY: year, MM: month, DD: day, NNN: generation sequence number on the execution date

    If you specify all, schedule, or result, temporary change information will not be saved.

    If you specify a string in YYYYMMDD format, the temporary change information for all generations that are executed on the specified day is saved.

    Note that when you cancel registration from JP1/AJS3 - View, you can only perform the cancellation by specifying a period or by canceling all generations. Accordingly, temporary change information is not saved.

  • Temporary change information for the 1st to 999th generations of a jobnet can be saved for one day. If an attempt is made to save temporary change information for 1,000th and following generations, the KAVS4671-E message is output to the integrated trace log, and the temporary change information is not saved. Ensure that no more than 999 generations of a jobnet will be executed per day.

■ Other notes

  • Do not change the value of the TZ environment variable during JP1/AJS3 operation. If the time zone setting used when temporary change was performed and the time zone setting used when the temporary change is re-executed do not match, re-execution of a temporary change might be performed incorrectly or might result in an error.

  • Do not create execution schedules whose TZ environment variable values in the same root jobnet are different. If the execution dates of these execution schedules are the same, it might be difficult to guess their execution registration numbers because the time at which the day starts is not the same.

  • Do not change the base time during JP1/AJS3 operation. If the base time used when temporary change was performed and the base time used when the temporary change is re-executed do not match, re-execution of a temporary change might be performed incorrectly or might result in an error.

    If you need to change the base time during operation, make sure you cold-start the scheduler service.

  • Re-execution of a temporary change is performed as the JP1 user who performs the re-execution, not as the JP1 user who performed the temporary change. Therefore, before you re-execute a temporary change for a unit, make sure you are a JP1 user that has the appropriate permission for the unit. If you do not have required permission, re-execution will result in an error.

  • If the temporary change operations you are re-executing include the addition of a root jobnet execution schedule (the ajsentry command with the -d or -t option specified), pay careful attention to the OS user mapped to the JP1 user.

    If the execution-user type of a job that will be executed by an added execution schedule is User who registered, re-execution is performed as the OS user mapped to the JP1 user. Therefore, if the relevant OS user does not have required permission for OS resources such as executable files, an error occurs during execution of the job.