Runtime Page

This page is available for executable objects. Here you specify the behavior of a task runtime.

This topic provides information on the following:

• Overview
• Return Code Handling Section
• Estimated Runtime (ERT) Section
• Runtime Statistics section
• Max and Min Runtime section
• Actions on Runtime Deviations section
• Forecast Settings section
• Runtime Monitoring for Tasks in A Workflow or Schedule
• Impact of the Check Interval in the MRT

Overview

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

Return Code Handling Section

1. 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:

   • :MODIFY_STATE for Job objects

   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.

2. 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.

Estimated Runtime (ERT) Section

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.

  Use Service Level Objective Object (SLO) objects to monitor runtimes and trigger actions in case of deviations.

• 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. Requirements to calculate ERT with this method 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"). One of the following: ERT_METHOD is set to ADAPTIVE in UC_CLIENT_SETTINGS and not other calculation method is selected in the Runtime tab of a particular job. Adaptive runtime estimation is selected as the calculation method in the Runtime tab of a particular task. The setting that you define in the Runtime tab of a task overrides the default setting of UC_CLIENT_SETTINGS. Additional information 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.

Runtime Statistics section

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.

Max and Min Runtime section

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 

See Impact of the Check Interval in the MRT.

Actions on Runtime Deviations section

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.

Alternatively, use Service Level Objective Object (SLO) to monitor runtimes and trigger actions in case of deviations.

Forecast Settings section

Select here the end status that a task should return in case of forecast calculations.

Runtime Monitoring for Tasks in A Workflow or Schedule

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.

Impact of the Check Interval in the MRT

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.