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

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:

Depending on the method you select, the following settings are displayed:

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:

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.