Configuring the Jobstream Hierarchy

The Jobstream Hierarchy tab allows you to define or modify where the jobstream runs and which job runs are included in the jobstream. You do so by assigning the Jobstream to one or more Business Areas, defining which historical runs should be included and how long AAI should keep the runs in the server. You also have different advanced options, depending on the Target Job/Scheduler.

When adding a new Jobstream, the system automatically populates the Business Area with the one in which you are located. You can modify it, if needed.

This page includes the following:

You can assign one jobstream to one or more business areas.

Assigning jobstreams to business areas lets you group them logically in a way that makes sense for your enterprise. Business areas are most often organized around business units or application areas and they can have several levels of nesting. For more information, see Business Areas.

Define the period of time for which historical runs will be included in the jobstream. AAI uses the resulting historical runs for its calculations. You have the following options:

• Include all historical runs in the last 30 days (default)

• Include runs since, which allows you to modify the default by entering the date as of which the historical runs should be included in the jobstream.

If the end time of a jobstream run falls under the date that you have selected, the run is included in the count.

The jobstream's average end-time and duration are calculated from the included runs only. However, at job level, the duration and delay statistics always include all available runs.

Specify the number of days of run history that AAI should keep on the server.

You can either choose the Server Default option, or select Custom and enter a different number of days.

• AutoSys jobstreams have the following advanced options:

  • Maximum Jobstream Run Duration

    maximum jobstream run duration,AutoSys maximum run duration,AutoSys jobstream configuration,CA7 jobstream configuration,IWSd jobstream configuration,IWSz jobstream configuration,Tidal jobstream configuration

    Use this option to limit the job runs in a jobstream to those within a specific period (in hours and minutes) before the end of the Target Job run.

    There may be jobstreams in which job runs take place long before the target job runs. Including these runs may make for an unnecessarily complicated jobstream. If such runs occur early enough, you can exclude them from the jobstream.

  • Allow new run based on force started job

    allow new run based on force started job,AutoSys force started job,AutoSys jobstream configuration

    Force starting a job in AutoSys can cause the target job to run. AAI will see this as a new run of a jobstream, which is usually what you want to happen. If you do not want that to happen, deselect the option.

• CA7, IWSd, and IWSz jobstreams have the following advanced options:

  • Maximum Jobstream Run Duration

    maximum jobstream run duration,AutoSys maximum run duration,AutoSys jobstream configuration,CA7 jobstream configuration,IWSd jobstream configuration,IWSz jobstream configuration,Tidal jobstream configuration

    Use this option to limit the job runs in a jobstream to those within a specific period (in hours and minutes) before the end of the Target Job run.

    There may be jobstreams in which job runs take place long before the target job runs. Including these runs may make for an unnecessarily complicated jobstream. If such runs occur early enough, you can exclude them from the jobstream.

• Tidal jobstreams have the following advanced options:

  • Maximum Jobstream Run Duration

    maximum jobstream run duration,AutoSys maximum run duration,AutoSys jobstream configuration,CA7 jobstream configuration,IWSd jobstream configuration,IWSz jobstream configuration,Tidal jobstream configuration

    Use this option to limit the job runs in a jobstream to those within a specific period (in hours and minutes) before the end of the Target Job run.

    There may be jobstreams in which job runs take place long before the target job runs. Including these runs may make for an unnecessarily complicated jobstream. If such runs occur early enough, you can exclude them from the jobstream.

  • Allow group to start a jobstream,Tidal jobstream configuration

    Allow Group to Start a Jobstream

    By default, the start time of a jobstream run is the same as the start time of the earliest job or group run in that jobstream. In some scenarios, a container can start well before (potentially hours) any job of the batch actually runs. This can lead to situations where the container starts the jobstream, which then shows as having run for many hours before the first job runs, thus cluttering up monitor views and resulting in misleading statistics.

    Use these options to specify the jobstream behavior in these situations, whether a container start time should indicate the start of a jobstream run or not.

    • Server default

      This option is selected by default. The behavior of this option is determined by the value of client.allowGroupStartJobstreamRunthat is defined in the Config Tool.

      Deselect this option to be able to modify this behavior for this jobstream. In this case, the Allow option is enabled.

    • Allow

      If you select this option, parent group(s) start times are used as the start time of a jobstream run.

      If you do not select this option, parent group(s) runs will NOT be used as the start time for a jobstream run. Instead, the start time of the earliest non-group job is considered the start time of the jobstream run.

    Important!

    • The client.allowGroupStartJobstreamRun server parameter controls the default behavior of this functionality for all jobstreams. The default for the server can be modified through the Params tab of the Configuration Tool, see Configuration Tool - Params Tab. Changes to the default setting only take effect for future jobstream runs.

      If you must apply the changes to historical runs too, you have to rebuild the jobstream run history. To do so, make sure you select a date in the past while editing the jobstream.

    • Modifying the Allow option on a per jobstream basis will automatically take effect for both historical and future runs of the jobstream.

• Automic jobstream configuration, Control-M jobstream configuration, ESP jobstream configuration,define jobstream run starting job

  Automic Automation, Control-M, and ESP have advanced options that specify how start jobs are determined in relation to container jobs.

  In Jobstream Run Starting Jobs you define which will be the first job in the jobstream using one of the following options:

  • Server default (can be any job or container)
  • Can be any job or container
  • Ignore if a container
  • Ignore if a outermost container

  By default, the start time of a jobstream run is the same as the start time of the earliest job or group run in that jobstream. In some scenarios, a container can start well before (potentially hours) any job of the batch actually runs. This can lead to situations where the container starts the jobstream, which then shows as having run for many hours before the first job runs, thus cluttering up monitor views and resulting in misleading statistics.

  Use these options to specify the jobstream behavior in these situations, whether a container start time should indicate the start of a jobstream run or not.

  Consider the following scenario:

  

  Where:

  • Workflow 1 starts at midnight

  • Workflow 2 starts at 8:00 am

  • Job 11 starts at 9:00 am

  • All jobs in Workflow 2 complete by 10:00 am, which causes Workflow 3 to start

  • Workflow 3 starts at 10:00

  • Job 1 starts at 11:00 am

  • You create a jobstream and identify job 7 as target job

  Depending on the option you select here, the following happens:

  • Can be any job or container

    Any job run for any job in the jobstream is a candidate to be the first job run in the jobstream. This is the default behavior.

    The universal.jobStreamRunStartingJobOption server parameter controls the default behavior of this functionality for all jobstreams. The default for the server can be modified through the Params tab of the Configuration Tool, see Configuration Tool - Params Tab.

    Considering our scenario, the run for the start of Workflow 1 comes in at 00:00. At this time a jobstream run is created with a start time of 00:00 and the run for Workflow 1 is added. The jobstream run will show up in monitoring with an actual start time for Workflow 1 and predictions for everything else in the jobstream. All other job runs will be added to the in-progress jobstream run until it completes.

  • Ignore if a container

    The first job in the jobstream run cannot be a container. In our scenario,

    • The run for the start of Workflow 1 comes in at 00:00 but since Workflow 1 is a container, no jobstream run is created.

    • The run for the start of Workflow 1 comes in at 08:00 am but since Workflow 1 is a container, no jobstream run is created.

    • The run for the start of Job 11 comes in at 09:00 am. Since Job 11 is NOT a container, jobstream run is created with start time 9:00 am.

    The runs for Workflow 1 and Workflow 2 are included in the jobstream run only so that the container can be drawn on the Gantt chart. Their start times on the Gantt chart are 9:00 am (the start time of Job 11).

  • Ignore if an outermost container

    The first job in the jobstream run cannot be an outermost container. Any container that does not itself have a container cannot start a jobstream run.

    In our scenario:

    • The run for the start of Workflow 1 comes in at 00:00. Since Workflow 1 does not have a container, no jobstream run is created.

    • The run for the start of Workflow 2 comes in at 8:00. Since Workflow 2 has a container, a jobstream run is created with start time 8:00.

    • The run for Job 11 comes in at 9:00. It is added to the existing jobstream run as are all other subsequent runs of the jobs in the jobstream.

    The run for Workflow 1 is included in the jobstream run only so that a container can be drawn on the Gantt chart. Its start time on the Gantt chart is 8:00 (the start time of Workflow 2).