Runtime Page
This page is available for executable objects. Here you specify the behavior of a task runtime.
A large amount of runtime data is required for the various planning and monitoring functions. This data is collected from Real Runtime information; based on this information, the estimated runtime can be calculated.
The Real Runtime (RRT) is the lapse between the start and the end of a task. The last 25 real runtimes of each executable object are saved with the object data; this is then used as basis for the calculation of the Estimated Runtime (ERT), whereby only the runs that ended with ENDED_OK status are considered.
The Estimated Runtime (ERT) is the expected runtime for the next execution of a task. This is a key value for dynamic runtime monitoring and forecast calculations, as well as for calculating the most recent ending of a task. The ERT is calculated immediately after a task run.
The way CA Automic Workload Automation calculates runtimes is defined in this page.
To Define the Runtime Settings
-
Enter the return code. A task will be evaluated as ended normally (ENDED_OK) if its return code is below or equal to the maximum return code entered here:
The following applies to Job objects only:
-
Windows: If the return code has been set to "-1" in Windows, the job is considered as ENDED_OK only if the return code equals "0".
This allows you to react to protection faults in Windows jobs (for example, return code -1073741819).
-
z/OS: The return code is specified as a decimal. Alternatively in z/OS the return code of each step can be compared with an entry in a step list. As result of this checks the job will be evaluated as ended normal or aborted.
-
Activate the Action check box to open the Select Object dialog. Here you can define the alternative object that should be executed if the task ends with a return code that does not meet the requirements specified above.
Note: The status of the file transfer does not affect its return code. If for any reason a file transfer fails, the return code is still 0.
Select the Calculation method to be used to estimate the runtime. The options are:
-
Method as set in UC_CLIENT_SETTINGS
Select this option if you want to apply the method and parameters that your system administrator has specified in the UC_CLIENT_SETTINGS variable using the ERT_METHOD and other ERT-relevant keys to calculate the estimated runtime for this object.
When defining a new object, no past runs are available for calculating the ERT. In this case, the Current/Fallback ERT fields are enabled to allow you to enter a suggestion you can use if necessary; this can be the case for forecast purposes, for example.
As soon as the object has been executed, these fields are disabled and display the current, real values. Of course, you can reset them (click the Reset Values button below the Runtime Statistics graphic), which enables these fields again.
If parameters are missing, hard-coded fallback values will be applied.
-
Fixed value
Select this option if you want to specify a static value as estimated runtime. If you do so, make sure that you review this setting from time to time to make sure that it still meets all your requirements.
The Current ERT fields are disabled when the duration is saved.
-
Dynamic method
The following dynamic methods are available:
| Dynamic method |
Description |
| Adaptive |
This method calculates the ERT proactively (machine learning-based) considering various factors and runtime parameters from previous runs.
Since this method relies on statistical data, a rEReorganization of the database will affect it. Also, sufficient statistical data must be available for this method to work efficiently.
For the same reason, if you create new Jobs or change existing ones in your system, the adaptive ERT calculation will only be performed, after those Jobs have run repeatedly. Approximately 30 runs will be necessary, until a re-calculation is performed.
-
At least 1 Java-based work process (JWP) must be available.
Only JWPs can calculate the adaptive ERT. If no JWP is available, an alternative calculation method (UC_CLIENT_SETTINGS - ERT_ADAPTIVE_FALLBACK_METHOD) will be used for all tasks where this method has been selected
-
Adaptive ERT calculation must be activated in the UC_CLIENT_SETTINGS variable (ERT_ADAPTIVE="Y").
The ERT is not calculated until the JWP is running. This may take a while.
Tasks that are waiting for adaptive ERT calculation have the "Waiting for ERT" status. For example, this applies to tasks for which the minimum or maximum runtime is calculated depending on the ERT.
In ERT_ADAPTIVE_JWP_TIMEOUT (UC_SYSTEM_SETTINGS) the system administrator defines how long the system will wait for the JWP after starting, before an alternative method should be used.
|
| Linear regression |
This method puts emphasis on runtime increases or decreases.
To avoid the evaluation of extreme deviations, a maximum deviation level in percent can be set. If the RRT exceeds this limit, it will not be taken into account in the calculation of the ERT. Additionally, the number of runs to be used can also be specified.
|
| Average |
Calculation of the average ERT based on the last RRTs of a task. You define here the number of RRTs to be considered.
Please take the following into account:
- If the number of RRTs is too low, the ERT will follow any existing tendency in runtime behavior.
- If the number of RRTs is too large, extreme deviations with RRTs are not emphasized.
To preserve a distance between ERT and RRT, it is possible to specify a correction value in percent This value is added to the ERTs. This ensures that the ERT follows the EET of a task at the specified distance.
To avoid the evaluation of extreme deviations, a maximum deviation level in percent can be set. If the RRT exceeds this limit, it will not be taken into account in the calculation of the ERT. Additionally, the number of runs to be used can also be specified.
|
| Maximal value |
This method considers the highest value from the list of RRTs to calculate the ERT.
If a large number of runs is to be calculated, the ERT immediately adjusts to increasing runtimes. However, if the RRT decreases, this results in a slow adjustment.
For the decreasing tendencies to be recognized more quickly, the number of runs to be calculated can be reduced.
To preserve a distance between ERT and RRT, a correction value in percent can be defined. This value is added to the ERTs. This allows the setting of an alarm only with extreme increases in runtime.
|
Depending on the method you select, the following settings are displayed:
-
Fallback ERT
Hard-coded values that are used in case of missing parameters in variables and for the Adaptive method.
- Current ERT
The next estimated runtime (ERT) of the task. If you enter a particular ERT here, this value applies until an ERT is calculated after the next run.
- No. of past runs
The number of past runs used to calculate the ERT calculation
- +ERT Correction
The value for an upward ERT correction (%).
- Ignore deviations
Select this options to define the limits for runtime deviations:
- Deviation extent: If this limit (in %) of the actual runtime is exceeded, the estimated runtime is ignored.
- Min. runs: Number of past runs to be considered regardless of deviations. Allowed values: 0 to 25.
When duplicating and transporting objects, the settings in this page are also taken over.
This section provides a graphical interpretation of the real (in blue) and of the estimated (in green) runtimes that help understand the relationship between both. You can display both at a time, which allows you to compare their behavior, or you can disable one of them by clicking on the corresponding area of the box below the chart.
Activate Monitor MRT and/or Monitor SRT if you want to monitor the maximum and/or the minimum runtime. The following calculation methods are available:
- Fixed value
Select this option to display the input fields in which you can enter a fixed duration.
- ERT + additional duration/ERT - additional duration
Select this option to add or subtract the ERT duration time and enter the correction time in %.
The value you enter here is added to (for max. duration) or subtracted from (for min. duration) the estimated run time
- Real date + additional duration (for the maximum runtime only)
You can define a particular time until which the task must be finished.
You can combine the following options:
- The number of days in the Additional Duration field
- A specific time in the Finish Time input fields
- A Time Zone object
If you define a maximum or minimum runtime, you can define an action to be executed in case the runtime exceeds the maximum or falls below the minimum.
You can either cancel or quit, and/or you can specify an object to be executed.
As an alternative, use Service Level Objective Object (SLO) to monitor runtimes and trigger actions in case of deviations.
Select here the end status that a task should return in case of forecast calculations.
You can also define runtime monitoring for tasks that are part of a workflow or are activated by a Schedule object in the Runtime page of the affected Workflow or Schedule objects. These definitions then override the settings of the tasks.
If no runtime definition exist for Workflow or Schedule objects, the task settings apply.
The quality of the ERT calculation depends on the available data. For example, if you clean up your database, calculations might not be accurate due to the available data sets being too few.
If you enable this function, the system reads a great amount of data from the system. Therefore, do not activate this function client-wide, but only for individual objects.
The UC_JOB_CHECKINTERVAL variable defines the interval that is applied system-wide for checking times; this is necessary when time dependencies are defined in objects.
Take this interval into account when defining the MRT settings.
See UC_JOB_CHECKINTERVAL - Periodic Time Check in the Automation Engine.
Estimated Runtime (ERT) Section
