Job/Job Group Definition Dialog

The Job Definition and Job Group Definition dialogs appear when you add or edit a job or job group from the Jobs pane. These dialogs are used to define the properties of each job and group that is scheduled

Common to All Tabs

  • Job Name or Job Group Name – The name you choose for your job or job group, limited to 256 characters. The name must be unique within a group.

    Note: Do not use the text characters of ", / or = in the name that you assign to a job.

  • Parent Group – The name of the job group to which the job or job group belongs. By default, a job inherits certain properties of its parent group. When a job group is added to the production schedule, all of its jobs are added automatically. Note that job groups are created using the Job Group Definition dialog.

    Note: You can clear the Parent Group list by right-clicking it and selecting Clear Selection from the context menu or by pressing the DELETE key.

  • Job Class – The job’s or job group’s job class. Classes help categorize the job or job group.

    Example: You can have a classification for all Payroll jobs, or all Accounting jobs.

    Queues can be set up with queue filters to accept jobs of a particular classification or a set of classifications.

    Note: You can clear the Job Class list by right-clicking it and selecting Clear Selection from the context menu or by pressing the DELETE key.

  • Owner – The owner of the job or job group. This can be an individual user or a TA workgroup. Every job and job group must have an Owner.

    If you are nesting a job group within another job group, it is recommended to use the same owner for all the jobs within the nested job groups. A job filter may have difficulty viewing the job groups correctly.

  • Enabled – Clear the Enabled option to deactivate the job or job group definition. When a job definition is Enabled (active), it can be added to the production schedule. When a job is not Enabled (inactive), it will not be added to the production schedule during compilation.

    Note: If the job has been previously submitted to the production schedule, and if the job is presently in a pre-launch status, clearing this flag will remove the job from the production schedule. Furthermore, if the job had dependents, those dependencies are released.

  • Tags – Click this dropdown to display these options:

    • Edit Business Activity Tags – Choose this option to display the Business Activity Tags dialog.

    • Edit Filter Tags – Choose this option to display the Filter Tags dialog.

    With the Business Activity tags and Filter tags:

    • A user can tag one or more job definitions.

    • If multiple job definitions are selected, then the tags in the Selected area will be a union of all assigned tags.

    • If one or more new tags are moved from Available to Selected in the Tags dialog, they are added to all the selected job definition objects.

    • If one or more existing tags are moved from Selected to Available in the Tags dialog, they are only removed for the specific job definition objects that they were assigned to.

Note: Adding new tags is additive in nature (Tags get added to all job definition objects that are selected). Removing tag mappings is subtractive in nature (Tags get removed only from the specific job definition object that they were assigned to).

Note: If a tag is disabled, its previous tag mappings to job definitions are retained. Disabled Tags previously mapped will show up in the Selected area of the Tags dialog. If a user tries to assign a disabled tag to one or more job definitions, an error message Cannot assign a disabled tag is thrown. However, a user can remove (move tag from Selected to Available) a disabled tag that was previously selected.

  • Last Modified Date – If you are editing the job or job group, on the bottom right of the Job/Group Definition dialog is the last modification date of the job. Click OK for this date and time to reflect the last time you saved the data provided in the Job/Group Definition dialog.

Program Tab

The Program tab displays in the Job Definition dialog. On this tab you specify the parameters and directories to be used as the command designated in the job runs.

This tab contains these elements:

  • Command/Parameters – The absolute path and filename of the command, script, batch file or executable that you want the job to run, from the perspective of the agent that it runs on. Do not use a mapped drive in the pathname. Follow UNC conventions when entering the pathname. Notice that there is a separate field for command parameters that is below the Command field. Do not add parameters to your command in the Command field.

    Note: you can view and edit the contents of command files by right-clicking the file from the Select Program dialog, then selecting Edit from the context menu.

    You should specify the full path to the file you want to run. The format is \\<computer name>\<folder name>\<file name> or <drive>:\<folder name>\<file name>. You will only need the computer name if the job is running on a different computer from the TA Web Client. To insert a variable into your path specification, click Variables and then select the variable you want to use.

    Another way to specify this command would be to define a variable called paydir whose value is the Payroll Executables directory. Then, you could specify your command line like this: <paydir>\payrolldat.exe. If the location of the payroll executables ever changes, you would need only to update the definition of the paydir variable for all the jobs using the paydir variable (rather than the literal location of the directory) to be updated.

    TA runs any command that is an executable such as files with the extensions .exe, .bat and .cmd or script files on the Unix platform.

  • Command Parameters – Command parameters supply essential information that the command requires to run, and are passed to it when it is executed. Command parameters are appended to the command exactly as entered. This field will accept up to 1,024 characters.

    Command parameters allow a single command file to be used for multiple purposes.

    Note: A command that processes data from a certain file could be given the file’s name as a command parameter. You can type all your parameters on a single line. TA will wrap the text display so that it is easier to read.

    TA uses the standard MS-DOS command syntax for command parameters. The command parameters are substituted into a command file containing the variable names %1, %2, etc. When the command is issued, command parameters are passed exactly as you specify them. You should separate each parameter value with a space so that the first value replaces %1, the second value replaces %2 when the batch file is executed.

    Note: Any argument that either explicitly has a space in it or could have a space in the argument should be enclosed in quotation marks; otherwise, the argument is returned as separate arguments wherever the spaces occur.

    Example: A job called Section 59 Tally would be returned as separate arguments, "Section", "59", and "Tally". Similarly, if a variable like <jobname> could return an argument containing a space, it also should be enclosed in quotation marks.

    The batch file is an example of how Windows accepts and handles command parameters. Listed below are the contents of the Argdemo batch file, found in the TA Agent Tutorial directory.

    @ECHO OFF
    title ArgDemo.bat
    ECHO This job will run the sleep program for 60 seconds ECHO then echo back the first three job parameters
    %Tidal%\agent\tutorial\SLEEP.EXE 60
    echo Program Parameter 1 = %1
    echo Program Parameter 2 = %2
    echo Program Parameter 3 = %3 ECHO done
    ocsexit 0

    Note: variables will be replaced by actual values when the command runs. If the variable is used with a repeating job, the value of the variable assigned the first time that the job runs remains the value each time the job runs. Since the variable values are determined as when the command runs, do not use job runtime variables in the command parameters. The true value for variables like Start Time and Finish Time cannot be determined until after the job completes.

    You can type in command parameters or specify Job, System, Public or user-defined variables. For convenience, you can right-click inside the Command Parameters field to display a context menu. This menu offers these options to manipulate text: Undo, Cut, Copy, Paste, Delete and Copy All.

  • Environment File Name – In this field, type the directory path to a file containing a list of environment variables and their values for the job. The format of the file must be specified in name=value pairs.

    Example: variable1=<its value>, variable2=<its value>.

    This field is optional.

  • Working Dir – In this field, a directory can be specified for a program or script to run in. Type the pathname for the directory that the program or script specified in the Command field should execute in. If this field is left blank, the default is for the script or program to run in the same directory that it is located in (unless the script or program automatically changes to a different directory).

  • Capture Alternate Output File – If a file is specified in this field, the agent looks for the output file in the location specified and reads it as text, returning that text as the output of the job instead of gathering the job process’s standard output. A job process’s "standard output" is the text that would be returned to the screen if you were to run the process manually via a command line interface. However, some applications do not return any "standard output", resulting in a blank Output tab in the Job Details dialog if run by TA.

    Example: If your job produces a small report in plain text format, you can specify that file’s pathname here. (Refer to the Load URL feature on the Runbook or Notes tab for details on presenting a non-text file for viewing via TA. If this field is not used, TA provides the default standard output file produced by the process launched on the agent.

  • Variables – Click this to display a context menu of variables categorized according to Job, System, Public or specific to a remote Master that can be used with the command. There may be several remote Masters with their own variables. You can use these variables in the Command, Command Parameters, Environment File Name and Output File Name fields.

Schedule Tab

This job definition tab determines when and how often a scheduled job will run by controlling its calendar and time window.

Calendar Section

You can specify the days and times when the job will run and any calendar offset.

  • Inherited – When selected, all properties on this tab, except those in the Repeats section, are inherited. If you want to explicitly set these properties, clear the Inherited option (which only appears when there is a Parent Group specified in the definition).

  • Calendar Name – The calendar or calendar group indicating which days the job should run. You must select a calendar for the job to be scheduled automatically. Select the Calendar Name from the drop-down menu. A calendar can encompass one or more days. You do not need to select a calendar if you plan to use this as an unscheduled job.

    Note: You can clear a calendar by right-clicking the Calendar field and selecting Clear from the context menu, or by pressing the DELETE key.

  • From – The earliest date that the job should run. The job will run starting with the first date in the calendar that is on or after this date. You can choose a date using the built-in calendar dialog by clicking the drop-down next to the field.

  • To – The last date the job can run based on the calendar. If not specified, and your calendar includes repetitive dates, your job will run indefinitely. You can choose a date using the built-in calendar dialog by clicking the drop-down next to the field.

  • Offset – The job will run a given number of days before or after every day in the calendar. Each day in the calendar is adjusted by the offset you provide.

    Example: If the job is using the Fiscal Month End calendar with an offset of 2, the job will be inserted into the schedule 2 days after Fiscal Month End date.

  • Forecast – Click this to display the Calendar Forecast dialog for the selected calendar (adjusted by offset, if provided) showing all the dates for which the job will be scheduled.

Time Window Section

  • Timezone – The time zone for the job or job group.

    You can configure time zones where target application environments are based to schedule a job or job group across multiple time zones. If a job or job group definition does not specify a time zone value, the Master defaults to the Master time zone.

  • Only start the job between the hours of – Based on the time zone used, specifies the time of the day during which the job must run. The job must run on or after the first mentioned hour (first time field) of the day and on or before the last mentioned hour (second time field) of the day. The first and the second time fields display the time format determined by the region settings on Windows Control Panel. A job launches based on one of the time specifications below:

    • If you do not specify a value in the first time field, the time defaults to either the start of the production day or end of the production day.

    • If you specify a value in the first time field and the second time field, for example, 2:00 PM and 11:00 AM, the job launches between 2:00 PM on the same day and 11:00 AM on the following day.

    • If you specify a value only in the first time field, for example, 5:00 PM, the job launches between 5:00 PM and 11:59 PM on the same day.

    • If you specify a value only in the second time field, for example, 3:00 PM, the job launches between 12:00 AM and 3:00 PM on the same day.

Start Hour Window Specifications for Job Groups and Child Jobs

You must specify the start hour for any child job within the start hour window of its parent job group. If you select the Inherited option for a child job, the child job inherits its parent job group’s start hour window specifications. If you do not select the Inherited option and do not specify the child job’s start hour window, the parent job group’s start hour window specifications becomes the child job’s default start hour window specifications. If you specify the child job’s start hour window, the start hour of the child job should not exceed its parent group’s start hour window. Irrespective of whether the child job’s start hour is same or within the parent group’s start hour window, the time zone could be different.

  • If not ready by end of time window – Displays the options below.

    Do not timeout – This option displays only if you have specified a value in the first time field and second time field or only in the second time field of Only start the job between the hours of time window. Choose this option if the job should not timeout even if the job does not start by the end of the Only start the job between the hours of time window.

    Run again tomorrow – Choose this option if the job has not run by the end of the Only start the job between the hours of time window and you want to carry it forward to the next day. After this time window, the job status changes to Timed Out For Day. If you select this option, the job is eligible to run on each subsequent day, until it runs. You can set up a job action to notify you if your job has not run as scheduled.

    TA can determine a job status based on the Do not timeout and Run again tomorrow field combinations below:

    If you do not select Do not timeout and Run Again Tomorrow, the job times out at the end of the Only start the job between the hours of time window.

    If you select only Do not timeout and not Run Again Tomorrow, the job status is not set to Timeout. However, any job events running based on the end of the Only start the job between the hours of time window are triggered at the end of the Only start the job between the hours of time window.

    If you select Do not timeout and Run Again Tomorrow, the job status is set to Timed Out For Day and the job runs on the following day.

    Note: Each instance of the job that is scheduled through the Repeats section rechecks the dependencies of the original job. For more information, see Dependencies Tab.

SLA Window Section

  • Track Critical Path for Job – This indicates whether the job is critical or not.

  • SLA At Risk between the hours of – The time (in hours) during which an SLA will be at risk if the associated job did not complete within the stipulated time. Events are triggered for jobs that did not complete within their SLA risk window.

    Enter the Offset for the SLA to run a given number of days before or after the at-risk window.

    Example: If you set the offset as 2, the SLA will run 2 days after the at-risk window.

  • SLA Breached between the hours of – The time (in hours) during which an SLA breach will occur if the associated job did not complete within the stipulated time. Events are triggered for jobs that did not complete within their SLA breach window.

    Enter the Offset for the SLA to run a given number of days before or after the breach window.

    Note: If you set the offset as 2, the SLA will run 2 days after the breach window.

Repeats Section

After job execution:

  • Do not repeat – Only one instance of the job will be compiled for each production day that the job is scheduled to run.

  • Run new occurrence every X minutes up to Y times

    • X – The interval between consecutive job start times in minutes relative to the beginning of the time window.

    • Y – The number of instances to create for the job. A job will not launch after the end of its time window. If this field is left blank, the job continually repeats until the end of the time range specified above, or if the time window is omitted, until 11:59 PM of that day.

    These rules govern this function:

    • If the job is defined to run at specific intervals relative to a time window, the resultant run times are fixed.

      Example: If a job’s time window begins at 12:00 PM, and the job is defined to run every hour for 4 times, the job will run at 12:00 PM, 1:00 PM, 2:00 PM and 3:00 PM. If the Create Schedule command occurs at 1:30 PM, this job will run twice, first at 2:00 PM and next at 3:00 PM (unless the Start today’s repeating jobs now option is selected in the Effective Date dialog).

    • If no time window is supplied, the job will begin at 12:00 AM and will repeat the number of times specified.

    • If you change the job definition while one of the repeat jobs is running, and the repeat count is changed, all job instances in pre-launch statuses will be removed from the production schedule, and the number of job instances added will be equal to the total number of instances specified minus the number of job instances that have already launched.

      Example: If you specify that Job A runs 4 times, and the 2nd instance has started, then you change the repeat count to 5, the 2 instances that already ran will remain in the schedule, the 2 jobs that have not run yet will be removed, and 3 jobs will be added to run in sequence after the 2nd instance finishes.

      Note: The Run new occurrence every... minutes up to... times option is ignored for jobs manually added to the schedule. Only one instance of the job will be scheduled.

      Note: If the job is manually added to the schedule, and other jobs depend on the last instance of this job, the dependencies will be updated to reflect the new instance.

  • Rerun same occurrence after execution every ... minutes up to... times – This option is similar to the one above with a few exceptions. Only one instance of the job is created. Rather than creating a new job instance, the same job instance will rerun after X number of minutes up to the prescribed number of times. X is the interval between completion of the previous run and the beginning of the next one. This means that the actual rerun frequency is X plus the actual job runtime interval.

    Note: The total number of runs is the sum of the initial run and any reruns.

    The Rerun same occurrence after execution every ... minutes up to... times option also applies to repeating jobs that are manually added to the schedule from the Insert Job into Schedule context menu option.

    Jobs dependent on a job using the Rerun same occurrence after execution every ... minutes up to... times option may or may not have their dependency satisfied, even if it should be, yielding potentially inconsistent results. Setting job dependency this way is not recommended.

    Instead:

    • Create the jobs under the same group.

    • Choose the Rerun same occurrence after execution every... minutes up to... times option on the Schedule tab of the Job Group Definition dialog for the group.

    • Click the Do not Repeat option on the Schedule tab of the Job Definition dialog for each job for each job.

    Note: If you do not specify how many times a job should repeat, it will repeat throughout the day at the designated interval. The option to begin today’s repeating jobs when the job is submitted is not offered in the Effective Date dialog.

  • Rerun same occurrence with custom start times (H:mm,H:mm) – Start times indicate when the same job instance will initially run and rerun. Enter a comma-separated list of job start times in the text box displayed.

    Example: Entering "5:50,10:26,18:01" as custom start times results in the job instance being scheduled to run first at 5:50 AM, then rerun at 10:26 AM, and finally rerun at 6:01 PM.

    If the job runs past any start time in the list, that time is skipped and the nearest future start time is used for the next rerun. If the production day has no future start times remaining, the job completes and does not rerun again. As a result, the job does not compile any instances for the current production day; all start times listed are in the past.

  • Rerun same occurrence with Minutes after hour (mm,mm) – Enter a comma-separated list of designations by minute (ranging from 0 to 59) in the text box displayed to indicate when the same job instance will run initially and then will rerun.

    Example: Entering "25,35,45" minutes with the job's time window starting at midnight results in the job instance being scheduled to run first at 12:25 AM, and then rerun at 12:35 AM, 12:45 AM, 1:25 AM, 1:35 AM, 1:45 AM, and so on. If the job runs past any start time in the list, that time is skipped and the nearest future start time is used for the next rerun. If the production day has no future start times remaining, the job completes and does not rerun again. As a result, the job does not compile any instances for the current production day; all start times listed are in the past.

  • Run new occurrence with custom start times (H:mm,H:mm) – Start times indicate when a new job instance will run. Enter a comma-separated list of job start times in the text box displayed.

    Example: Entering "5:50,10:26,18:01" as custom start times results in a new job instance being scheduled to run each at 5:50 AM, 10:26 AM, and 6:01 PM.

  • Run new occurrence with Minutes after hour (mm,mm) – Enter a comma-separated list of designations by minute (ranging from 0 to 59) in the text box displayed to indicate when a new job instance will run.

    Example: Entering "25,35,45" minutes with the job's time window starting at midnight results in a new job instance being scheduled to run at 12:25 AM, 12:35 AM, 12:45 AM, 1:25 AM, 1:35 AM, 1:45 AM and so on.

    Note: If a job group configured with the rerun same occurrence option has already completed some jobs, do not modify its definition. Modifying the parameters of the job group after some of its jobs complete will result in some jobs not rerunning as they should.

Run Tab

The Run tab of the Job Definition dialog manages where the job will run, the duration of the job and how to determine if the job completes successfully. The Run tab for a job group definition does not have a Tracking section to determine a job’s successful completion.

Note: If the job exists under a parent group, by default, all properties in the Agent Information section are inherited from its parent job group. If you want to override any one of these properties, clear the Inheritance option.

Agent/Adapter Information Section

  • Agent/Adapter Name – The agent machine on which the program or script runs. You must use an agent that corresponds to the platform where your program or script can run. This value defaults to the agent name specified in the System Configuration dialog, Defaults tab. Note that if you select an agent name, the Agent List Name field is reset.

    Note: The TA Agent for Unix runs as the agent owner with the same security rights as its owner. By default, the agent does not have access to all of the dependent files, scripts and environment variables it may need. A Unix job cannot complete successfully unless you ensure that the agent has the proper access rights to all of the files needed during the processing of a job.

  • Agent List Name – An agent list is a set of agents that can run the program or script, or the agent machines on which you want the program or script to run. Agent lists allow for workload balancing, broadcasting, and dynamic rerouting. You must select an agent list for the platform on which your program or script can run. Note that if you select an agent list, the Agent Name field is reset.

  • Runtime User – The logon name of the user under whose account the program or script needs to run. If you are creating the job for another user and you are authorized to do so, you can select the user for this field from the drop-down. If the user does not appear on the drop-down menu, the user needs to be added to your list of Runtime Users in your User Definition.

    Note: If you are selecting a runtime user for an agent list, the user must exist on all agents in the agent list. The job will fail if it runs on an agent where the user is not defined.

  • Use Password to Run Windows Jobs – It is applicable only for Windows Agent. It enables to run the Windows jobs with or without authentication. You can select System Configuration, Yes, or No from the drop-down. If you select System Configuration, the jobs are executed in the agent machine based on the Use Password To Run Windows Jobs option set in the System Configuration screen. If you select Yes, the jobs are executed, only when the runtime user is authenticated. If you select No, the jobs are executed without requiring the user authentication.

    Note: You can clear the above fields by right-clicking them, and selecting Clear from the context menu or by pressing the DELETE key.

Tracking Section (job only, does not apply to job group)

  • Exit Code – The job completion status is determined by the job’s exit code. An exit code of 0 sets the job status to Completed Normally. Any other exit code sets the job status to Completed Abnormally.

    The exit code of a job is set depending on the type of agent and script you are using. The exit code is determined by using the ocsexit command at the end of the batch or command file run by a job. The exit code value be any integer value.

  • External – Selecting this option means that the status of a completed job is determined externally by a user or program. TA will set the job status to Externally Defined when the job completes. You can then have the active job completion status set through an action, or use the Set command from the Job Activity pane context menu.

  • Exit code of cmd pipe – Choose this option if you want to pipe the output of your job as input to a command and use the exit code of the last command in the pipe to determine the success of the job. This scanning of output is case-sensitive unless the master.props file is modified to make scanning insensitive to case. Refer to the Parameters chapter for more information.

    Note: You cannot reference the output from the command pipe in the same job that creates it. Only a different job can use the current job’s output.

    This allows you to use output analysis tools to determine the job status. If you use this option, type the command pipe in the associated field.

    Note: A maximum of 1024 characters of output can be piped to another command.

  • Scan Output: Normal String – Choose this option if you want a particular text string in the output from a job to determine that a job completed normally. In the associated field, type the text string that will signify "normal". To use the text string as a whole, enclose the text in quotation marks; otherwise, TA treats the text string as a list of random words and any single word of the text signals "normal".

  • Scan Output: Abnormal String – Choose this option if you want a particular text string in the output from a job to determine that a job completed abnormally. In the associated field, type the text string that will signify "abnormal". To use the text string as a whole, enclose the text in quotation marks; otherwise, TA treats the text string as a list of random words and any single word of the text signals "abnormal".

    Note: You can scan job output for multiple strings. Listing multiple text strings separated by commas means any one of the listed text strings can signal that the job completed normally or abnormally. Listing text strings separated by plus signs means all of the text strings must appear in the job output to determine if the job completed normally or not. If the text strings contain commas or pluses, enclose the text string in quotation marks. You cannot mix commas and pluses together as separators.

Duration (in minutes) Section

  • Estimated – The estimated duration for the job specified in minutes, or a fraction thereof. The estimated run time is used to create the forecast shown in the Job Activity pane. It is also referenced by the Job finished later than expected job event trigger. You can use the Estimated Duration field to monitor jobs that run for a shorter or longer time than expected.

    Example: You could set up a job event triggered by Job finished later than expected, with an associated email action that will notify you when a certain job that normally runs for 5 minutes, runs for more than one hour.

  • Minimum – The minimum duration that you expect your job to run. You can create a job event to monitor and perform an action if the job completes in less than the minimum time.

    Example: You could set up a job event and job action that would run a diagnostic tool if it completes in less than the Minimum time.

  • Maximum – The maximum duration that you expect your job to run. You can create a job event to monitor and perform an action if the job runs over the maximum time.

    Example: You could setup a job event and job action to stop the job if it runs past the Maximum time.

  • Exclude Completed Abnormally – Prior to TA 6.0, the calculation of the Estimated Duration of time that a Job should run includes the previous execution time for both Jobs that completed normally and abnormally. Selecting this option allows you to control which Jobs are included in that calculation.

Using Local System Accounts for Windows Jobs

Usually, jobs running on a Windows agent use the user account configured for that agent. Jobs can also be run under specific runtime user accounts using Windows passwords if configured on the Master tab of the System Configuration dialog. An alternate method is to use runtime Local System accounts for some or all Windows jobs that are generic by nature and do not require a password. Using the Domain field, you can make Local System available globally or restrict its use to specific machines or some combination of both.

To use a local system account:

  1. Click Administration > Users on the Navigation pane to display the Users pane.

  1. Click Add or right-click and select Add User from the context menu to display the User Definition dialog.

  1. Type LocalSystem in the User Name field.

  1. Type LocalSystem in the Full Name field. This name is used in TA reports and some dialogs.

    Note: If you wish the Local System account to be available to all machines, leave the Domain field blank; otherwise, type the name of the machine.

  1. Click the Runtime User Only option.

    The Runtime Users, Workgroups and Other tabs of the User Definition dialog disappear when the Runtime User Only option is selected, since this user is only launching jobs, not logging in to use TA.

  1. After creating the Local System account, you need to grant or deny each user the right to use the Local System runtime user account.

    1. Click Administration > Users on the Navigation pane to display the Users pane.

    2. Double-click each user account to open the User Definition dialog and click the Runtime Users tab.

    3. Click the Local System option and click OK.

    Now authorized users can run jobs without passwords using the local system account if the user has that runtime user right.

Dependencies Tab

The Dependencies tab of a job definition manages a job’s interaction between the various job, file and variable dependencies that a job may require to run to completion.

Note: Each instance of the job will include the dependencies you define on the Dependencies tab.

This tab contains these elements:

  • Dependency Name Column – The name of the job, group, file or variable dependency.An intermaster variable displays in the following format, variable name@Master. If the connection to the remote Master is lost then the variable shows a current value of Unavailable though the value is updated as soon as the connection is restored. An intermaster variable deleted from the remote Master or no longer published has a value of Not Published.

  • Type Column – The type of dependency.

  • All must be met – Choose this option so that all the dependencies in the above list must be met before the job can run. This option does not include time dependencies. All must be met means that each dependency condition must be met at the same time for the job’s dependencies to be satisfied.

    If a dependency’s state changes from met to not met while other dependencies are still not met, and the other dependencies subsequently change state from not met to met, the All must be met condition option is still not satisfied. All dependencies must be in the met state simultaneously.

  • At least one must be met – Choose this option so that the job runs when any one of the dependencies in the above list is met. This option does not include time dependencies. Time dependencies are set using the time window section on the Schedule tab.

  • Compound – Selecting this option enables the text field. Entering a Boolean expression in the text field specifies the logical expression of listed dependencies. Jobs run based on this logical expression.

    The Index column lists the count of dependencies starting from 1. While entering the Boolean expression, you can refer to a specific dependency in the list by entering the index value associated with the dependency. To create a compound expression, use AND, OR, and parentheses. In the place of AND, you can use &. In the place of OR, use|. You can also use TRUE and FALSE as constants.

    Example: You can enter these expression in the text field to run the job if either the first and second dependencies or the second and third dependencies in the list are met. (1 AND 2) OR (2 AND 3)

    While saving the job, the UI converts the relative indexes into actual job dependency ids that are stored in the database.

  • Rerun each time dependencies are met – The job runs every time all its dependencies are met, with these exceptions:

    • The Rerun each time dependencies are met option cannot be used in conjunction with the Rerun same occurrence... option on the Schedule tab of the Job Definition dialog.

    • If your job is dependent on a job with multiple instances, the dependency is set only to the first instance. The Rerun each time dependencies are met option will only be triggered if the first instance of the dependency is rerun.

    If the Master goes down (or fails over if running in a fault tolerance configuration) while a job with this option runs, the job will run again after the Master restarts provided that all of the job’s dependencies are still met. To prevent the job from rerunning when the Master restarts, modify one of the dependencies to keep it from being met.

    Example: Delete a file if the job has a job dependency so that only a new file will meet the job’s dependency.

    Jobs dependent on a job using the Rerun same occurrence after execution every ... minutes up to... times option will never be satisfied.

    Instead:

    1. Add both jobs under the same group.

    2. Click the Rerun same occurrence after execution every... minutes up to... times option for the group on the Schedule tab of the Job Group Definition dialog.

    3. Click the Do not Repeat option for each job on the Schedule tab of the Job Definition dialog.

  • Force rerun if file dependencies are still met – Choose this option to enforce a job rerun as long as the job’s file dependencies with conditions still true are being met.

    Example: When some of the files are processed once the dependency is met, whereas some other files arrive only after the job becomes active, then the job should rerun. This option is enabled only if you select the Rerun each time dependencies are met option.

  • Add – Click this to display a drop-down menu for you to add a job, file, variable or z/OS JES dependency.

  • Edit – Click this to edit the selected job, file, variable or z/OS JES dependency.

  • Delete – Click this to delete the selected job, file, variable or z/OS JES dependency.

  • Clear – Click this to delete all of the listed dependencies regardless of type.

Setting Dependencies on a Job

The TA Agent for Unix runs as the agent owner with the same security rights as its owner. By default, the agent does not have access to all of the dependent files, scripts and environment variables it may need. A Unix job cannot complete successfully unless you ensure that the agent has the proper access rights to all of the files needed during the processing of a job.

Resources Tab

The Resources tab is available in the Job Definition dialog and the Job Group Definition dialog. The Virtual or System resources for a job or a job group are added and edited from this tab.

Virtual resources are resources that already exist. By adding an existing resource to the Resources tab, you are able to manage the use of the resource by TA users.

System resources are either Published or Custom. Agents that support published system resources provide information about those resources when a connection is established. You can create custom system resource definitions by specifying commands that will periodically run on an agent machine to obtain the resource values.

System resource definitions are automatically created for published resources if they do not already exist for that connection type and the Published command is displayed.

Because a resource can be quantified, resource sharing can be limited to a designated number. A resource can be either a software resource such as a database or network or it can be a hardware resource like a machine. The job or the job group will not run until all of the resources listed on this tab are available for the job or the job group when it runs. A job or a job group can still use a resource that is not listed on this tab, but if a resource is listed on this tab of a job's definition or a job group’s definition, it creates a "reservation" for the job or the job group to use a set amount of the resource.

This tab contains these elements:

  • Virtual Resources – You can add, edit, and delete virtual resources from this tab.

    Resource – Displays the name of the virtual resources associated with the job or the job group.

    Amount Required – Displays the amount of the resource that the job or job group requires. This amount is defined in the Resource Requirement Definition dialog.

    Exclusive Use – Displays Yes if the Exclusive Use option in the Resource Requirement Definition dialog is selected. Displays No if the Exclusive Use option in the Resource Requirement Definition dialog is not selected.

    Add – Click this to display a Resource Requirement Definition dialog to associate an existing resource to this job or the job group.

    Edit – Click this to display the Resource Requirement Definition dialog of the selected resource to edit it.

    Delete – Click this to delete the selected resource.

    Clear – Click this to delete every resource listed for the job definition or the job group definition.

  • System Resources – You can add, edit, and delete system resources from this tab.

  • Resource – Displays the name of the system resources associated with the job or the job group.

  • Condition – Contains the conditional operators depending on the data type of the resource.

    Here are the conditions that are supported by Integers and Strings:

    Data Type

    Supported Conditions

    Integers and Strings

    Equals (=)

    Does Not Equal (<>)

    Greater Than (>)

    Greater Than Or Equal To (>=)

    Less Than (<)

    Less Than Or Equal To (<=)

    Only Strings

    Contains

    Does Not Contain

    Matches Pattern

    Does Not Match Pattern

    Matches Regular Expression

    Does Not Match Regular Expression

  • Value – Contains the value for the condition.

  • Add – Click this to display a System Resource Requirement Definition dialog to associate an existing system resource to this job or the job group.

  • Edit – Click this to display the System Resource Requirement Definition dialog of the selected system resource to edit it.

  • Delete – Click this to delete the selected system resource.

  • Clear – Click this to delete every system resource listed for the job definition or the job group definition.

Published Resource Definition Dialog (read-only)

System resources are either Published or Custom. This dialog displays the name, data type and operating system of a Published resource and is read-only. Agents that support published system resources provide information about those resources when a connection is established.

Resource Requirement Definition Dialog

When you click Add on the Resources tab of the Job Definition dialog or the Job Group Definition dialog, the Resource Requirement Definition dialog is displayed.

The Resource Requirement Definition dialog > Resources tab is used to add a new resource to a job or a job group or edit an existing resource for a job or a job group. You can specify the resource and how much of the resource that a job or a job group requires. This dialog contains these fields:

  • Resource – Displays a list of the existing resource names. Only the resource definitions that are enabled are listed in the field. Once the resource is selected, its maximum limit displays beside the Amount Required field.

  • Amount Required – Specifies the number of resources a job or a job group requires. This value should not exceed the resource’s maximum limit which is displayed beside this field.

  • Exclusive Use – Enable this checkbox if you want the job or job group to lock the resource for exclusive use. When you select this option, the Job or job group runs only when no other job uses the resource.

  • Amount Required field is disabled.

System Resource Requirement Definition Dialog

When you click Add on the Resources tab’s System Resources section of the Job Definition dialog or the Job Group Definition dialog, the System Resource Requirement Definition dialog displays.

The System Resource Requirement Definition dialog is used to add or edit an existing system resource to a job or a job group from the Resources tab. From this dialog, you specify which resource and how much of the resource is needed by a job or a job group. If the Enabled option is not selected in the resource's definition, then the resource does not display in the dropdown list.

This dialog contains these fields:

  • System Resource – The name of the defined resource. Only resources that are enabled are available from this field. Once the resource is selected, its maximum limit displays beside the Amount Needed field.

  • Operator – Choose the conditional operator depending on the data type of the resource.

  • Value – Enter the value for the selected resource.

For more information about defining a resource, refer to Resources in TA.

Variables Tab

The Variables tab displays the variables that a job/job group uses. Use this tab to add, edit, and view variables for the jobs/job groups. When multiple instances of a job/job group using global variables run concurrently, data values cannot be preserved since the variable value changes as each job/job group instance runs.

Local Job Variables

The variables defined using the Variables tab in the Job Definition dialog are called Local Job Variables. These variables are unaffected by any changes to their values that occur outside of current job and its parent job group.These variables can be either variables with specific hard-coded values or global variables from the Variables menu. A regularly scheduled production job uses default values for its variables.

Note: For agent jobs, the TA Master passes the variable-related information to the agents.

To define a local job variable:

  1. Click a job from the Jobs pane to display the Job Definition dialog.

  1. Click the Variables tab.

  1. Click Add to display the Local Job Variable dialog.

  1. Enter a name in the Variable Name field.

  1. Enter a value in the Variable Value field or select a value from the Variables dropdown list.

  1. Click OK.

The defined variable is displayed in the Local Job Variables grid in the Job Definition dialog.

To modify a variable value from the grid:

  1. Click on a value in the Local Job Variables grid.

  1. Change the value.

  1. Click OK to save the changes.

To modify a variable name or variable value using the Edit button:

  1. Select a record from the grid.

  1. Click Edit.

  1. Change the variable name/variable value in the Local Job Variable dialog.

  1. Click OK.

The modified variable name/value appears in the Local Job Variables grid.

After defining local job variables, you can insert the job into the schedule. Once scheduled, the local job variables related to the scheduled job are displayed in the Variables tab of the Job Details dialog. For more information, see Job Details – Variables Tab.

Local Group Variables

The variables defined using the Variables tab in the Job Group Definition dialog are Local Group Variables. These variables are unaffected by any changes to their values that occur outside of current job group and its parent or child groups. These variables can be either variables with specific hard-coded values or global variables from the Variables menu. The child groups have access to parent group variables through the Variables menu.

A job group manually inserted into the schedule can specify values, which a particular job group run uses. The manually inserted job group instance and any child job groups associated with it will use the variable values specified during group insertion regardless of other occurrences of the same job group that may be running and using a different set of variable values.

To define a local group variable:

  1. Choose a job group from the Jobs pane to display the Job Group Definition dialog.

  1. Open the Variables tab.

  1. Click Add to display the Local Group Variable dialog.

  1. Enter a name in the Variable Name field.

  1. Enter a value in the Variable Value field or select a value from the Variables dropdown menu.

  1. Click OK.

The defined variable is displayed in the Local Group Variables grid in the Job Group Definition dialog.

To modify a variable value from the grid:

  1. Click on a value in the Local Group Variables grid.

  1. Change the value.

  1. Click OK to save the changes.

To modify a variable name or variable value using the Edit button:

  1. Choose a record from the grid.

  1. Click Edit.

  1. Change the variable name/variable value in the Local Group Variable dialog.

  1. Click OK.

The modified variable name/value appears in the Local Group Variables grid.

Right-click a job group variable and select the Where Used option to display the child jobs/job groups where the selected job group variable is used.

After defining local group variables, you can insert the job group into the schedule. Once scheduled, the local group variables related to the scheduled job group are displayed in the Variables tab of the Job Group Details dialog. For more information, see Job Details – Variables Tab.

Job Events Tab

This tab is used to assign predefined job events to a job and to arrange the job events into a desired sequence. You can only associate predefined job events to a job from this tab. To create or modify a job event, you need to open the job event’s definition in the Job Events pane.

This tab contains these elements:

  • Event Name column – The name assigned to the job event.

  • Event Trigger column – The condition that triggers the associated job event.

  • Insert – Click this to display the Select Job Event dialog where you can select one or more predefined job events to assign to your job. Job events are created from the Job Events pane

  • Edit – Click this to display the Job Event Definition dialog of the job event that was selected to modify the event.

    Note: Any changes you make to a job event from the Job Events tab of the Job or Job Group Definition dialogs affect all jobs to which the event is assigned, not just the current job or group.

  • Delete – Click this to remove the selected job event from the list.

    Note: When you assign a job event to your job, the job event no longer appears in the Select Job Event dialog. When you delete a job event from the Job Events tab, the job event returns to the Select Job Event dialog.

  • Clear – Click this to delete all of the defined job events clearing the tab.

  • Move Up – Click this to move the selected job event up in the sequence of job events.

  • Move Down – Click this to move the selected job event down in the sequence of job events.

Job Events That Apply to All Jobs

This section is read-only. These are the events that apply to all jobs, all groups, or all jobs and groups. They are not individually assigned. You can only change a system-wide job event from the Job Event Definition dialog.

  • Event Name column – The name assigned to the job event.

  • Event Trigger column – The condition that triggers the associated job event.

Select Job Event Dialog

When you click Insert from the Job Events tab of the Job or Job Group Definition dialogs, the Select Job Event dialog displays.

This dialog shows the available job events you can assign to your job. Visible are all the job events you own, and the ones owned by workgroups of which you are a member.

The Select Job Event dialog contains these columns:

  • Event Name – The name(s) of the job events you can associate to the job.

  • Event Trigger – The job event triggers that issue the job events. You can select more than one event. After you click OK, each selected event is added to the job event list.

When you click Edit from the Job Events tab of the Job or Job Group Definition dialogs, the Job Event Definition dialog appears.

Group’s Events Tab

The Group’s Events tab is only displayed in the Job Group Definition dialog. This tab lists job events that are designated to be inherited by the children of the job group. The job events that are associated with the job group can be configured to occur either before or after the job events assigned to each individual child job occur.

This tab contains these elements:

  • Before tab – Lists the job events that must occur before the job instance’s own job events. You arrange the order of the job events listed here to specify the sequence that the job events should follow.

  • After tab – Lists the job events that must occur after the job instance’s own job events. You arrange the order of the job events listed here to specify the sequence that the job events should follow.

  • Event Name column – The name assigned to the job event.

  • Event Trigger column – The condition that triggers the associated job event.

  • Level column – The generations of job children that will inherit the listed job event. This is specified by clicking in the field and entering the number of the child generation. Level 1 events are only triggered for up to the child job/group. Level 2 events are triggered for grandchild job/group as well as child job/group.

Example: If a Job Group is set up this way: A1: Parent. A2: Job whoseparent is A1. B1: Subgroup whose parent is A1. B2: Job whose parent is B1. In this scenario, Level 1 would be B2, and Level 2 would be A2/B1. If B2 fails with the Event on Level 1, there will be 1 event triggered on B2. If B2 fails with the Event on Level 2, there will be 2 events triggered - one on B1, and B2.

  • Insert button – Displays the Select Job Event dialog where you can select one or more predefined job events to assign to the job class. Job events are created from the Job Events pane.

  • Edit button – Displays the Job Event Definition dialog to modify the selected job event.

  • Delete button – Removes the selected job event from the list.

  • Clear button – Deletes all of the defined job events clearing the field.

  • Move Up button – Moves the selected job event up in the sequence of job events.

  • Move Down button – Moves the selected job event down in the sequence of job events.

Job Definition – Options Tab

The Options tab provides fields that enable individual job instances to override various global settings that control a job's properties such as output handling, history retention, carryover, priority and operator control. The Options tab for a job group does not have all of the fields that are available for a job definition.

This tab contains these elements:

  • Job Alias – A short one- to eight-character identifier for this job or job group. For convenience, many of the commands in the command-line interface refer to the job or job group using its alias name.

  • If Job is currently running (Job Definition dialog only) – Determines what to do to if a job is ready to launch and an instance of the same job is already running:

    • Run Anyway – Runs a new instance of the job even though a previous instance is already running.

    • Skip – Skips the job if a previous instance of the job is already running. This setting will not run the job when the prior instance finishes. A skipped job cannot be rerun.

    • Defer until normal – Runs the job or job group only after the previous instance of the job or job group completes with a Completed Normally status. If the previous instance does not complete normally, this job or job group will not run.

    • Defer until complete – Runs the job or job group only after the previous instance completes regardless of the final status of the previous job or job group.

  • Base time needed to run job on – Sets the default basis for evaluating whether jobs will complete before a scheduled outage. Whether jobs have adequate time to run can be based on either of these factors:

    • Estimated Duration – The estimated duration for the command or executable as specified in the job definition. If the job has run more than once with the same command or executable, the estimated duration is the historical average of the job’s previous run times. You can also manually set the estimated duration time of a job in its definition.

    • Maximum Duration – The maximum duration for the command or executable as specified in the job definition. If the job has run more than once with the same command or executable, the estimated duration is the historical average of the job’s previous run times. You can also manually set the estimated duration time of a job in its definition.

  • If not enough time before outage – Sets the default action for occasions when a job may run into an outage window as based on the evaluation option set in the Base time needed to run jobs on text field. There are three options:

    • Run Anyway – Run the job instance even at the risk that the job may not complete before the outage window.

    • Skip – Do not run the job instance if it may run into an outage window.

    • Defer – Wait to run the job until after the outage window has ended.

  • Save Output Option (Job Definition dialog only) – Specifies what will happen to the job’s output. If you save the output, you can view it by double-clicking the completed job in the Job Activity pane. The Job Details dialog appears, displaying the output text.

    • Discard – To Discard is the TA default setting for job output. Output is not saved for viewing after the job runs.

    • Append – Saves the output of the job in the Master database, adding to the first output file every time the job runs.

    • Replace – Saves the output of the job in the Master database, overwriting the existing output file with a current one every time the job runs.

    Note: Standard output and standard error output are combined in TA job output files. You cannot separate stdout and stderr.

  • Job Priority – The priority of the job within its assigned queue. The job priority determines which job runs first within a queue, when the queue limit only permits launching of one additional job. Queue priorities determine which queues get preference. The larger the priority number, the higher the actual priority.

    Example: A job with a priority of 75 would run before a job with a priority of 50.

    After a job enters the Ready state, the priority of the job is changed (increased or decreased) by 1 point at a specified interval (X minutes) as follows:

    • Increase – Increases the job priority every X minutes.

    • Decrease – Decreases the job priority every X minutes.

    • Every – Interval (in minutes) at which the job priority is increased or decreased.

  • Allow Unscheduled – Enables the job to be inserted into the production schedule on an as-needed basis. The default is that unscheduled instances are allowed. If you do not want the job to run on an ad hoc basis, you can clear this option to prevent non-scheduled submissions.

  • Require Operator Release – Holds the job from running until an operator releases it. When all the job dependencies are met and the job is ready to run, the job status is Waiting On Operator. The information in the Operator Instructions field in the Run Book tab of the Job Definition dialog can inform the operator of any external requirements that need to be met before the job is released.

  • Allow operator rerun – Allows the operator to rerun a job. The default is allow operator reruns (box checked).

  • Disable carryover – Disables the job carry forward feature that appends the jobs that did not run in the current production schedule to the next day's production schedule. Any job from the current production schedule that is not in an Active or a Launched status when the next production day starts, will not be carried over to the next production day. The default is to enable job carry forward (unchecked).

  • For Unix, source user’s profile – Allows you to execute Unix user profiles. This option provides for the execution of all variables in a Unix user’s profile. Without this option, Unix user profile variables that are referenced by scripts are not being executed, causing errors in TA.

  • Terminate parent on – For the job/job group, when you select the option:

    • Error – The job sends a terminate request to its immediate parent if an error occurred during the jobrun.

    • Abnormal Completion – The job sends a terminate request to its immediate parent if the job completed abnormally.

    • Abort – The job sends a terminate request to its immediate parent if the job was aborted.

  • On Terminate request – A job/job group acts as follows on receiving a terminate request.

    When a job group receives a terminate request from a child, a parent, or the user, then the group processes the terminate request in one of these ways:

    • Ignores the terminate request based on one of these conditions:

      If the Ignore option is selected in the On Terminate request section on the Options tab of the job group definition.

      If the group is in a Done state.

    • Sends a terminate request to all of its immediate children. The children process the terminate request immediately unless they are configured to ignore terminate requests. The child Terminator jobs that have not run are immediately set to a Terminated status.

      If any child ignores the terminate request and the group's dependencies are not met, the group changes to Terminate Waiting status until its dependencies are met.

      If any child ignores the terminate request and the group's resources are not available, the group changes to Terminate Ready status until its resources can be acquired.

      If the group is active, it changes to Terminating status. The group remains in a Terminating status until all of its immediate children reach a Done state. If the group has a child Terminator job whose status is not Terminated, the group’s status is updated with that child's status. If there are multiple non-Terminated child Terminator jobs, the one with the highest priority determines the group's status. Finally, if there are multiple non-Terminated child Terminator jobs with the highest priority, the job that ran most recently is used to update the group status.

    • Sends a terminate request to its immediate parent if the Terminate parent option is selected in the On Terminate request section on the Options tab of the job group definition.

      When a job receives a terminate request:

      The job ignores the terminate request based on one of these conditions:

    If the Ignore option is selected in the On Terminate request section on the Options tab of the job definition.

    If the job is in a Done state.

    If the job is in a Running state and the On Terminate request option, Abort if active is not selected.

    If the job is in a Waiting state, the job is immediately set to a Terminated status.

    The job is aborted if the selected On Terminate request option is Abort if active. An abort message is sent to the agent/adapter, which will then update the job with its final status.

    Note: All jobs waiting on dependencies/resources are terminated on receiving a terminate request.

    Note: You can configure the Terminator job options from the Activities > System Configuration > Defaults tab.

  • History Retention (in days) – The retention of the job history data, including job output. Use this field to adjust the job history data displayed on the History tab of the definition dialog. TA will automatically purge all job instance history older than this retention history setting if the Automatic Daily History Cleanup option is enabled on the Master tab of the System Configuration dialog.

Run Book Tab

The Run Book tab provides a place in the job definition to display operator instructions pertaining to running the job. provides a place for instructions or information pertaining to the job. Text instructions can be provided but a Web page can also be loaded and displayed. A page on your company's intranet with relevant information or a PeopleSoft login page could be displayed.You can also enter a pathname to a directory on the network to display the directory’s contents to verify that a file exists in the directory.

This tab contains these elements:

  • Operator Instructions – A free text field where you can type any instructions for the operator, up to 255 characters long or type a web address that provides relevant information about the job. If you choose the Require operator release option on the Options tab, you could use this field for detailed reminders about the circumstances under which to run this job with the Require operator release option selected. While text instructions can be provided, a web page can also be loaded and displayed.

  • Load URL – First, type a web URL in the Operator Instructions field and then select this option. This Web address can be for an internet/intranet site or a directory on the network. This can be very useful if information pertaining to a job is stored on a company intranet or a login page must be accessed.

    In order to use Load URL feature to load contents of files, located on the network Windows shares, the rules should be utilized:

    • You will need to supply file:// as the protocol indicator.

      Example: file:///\\<yourcomputer>/Share_here/<JobID>.txt

    • Loading the content through file:// protocol works without any intervention from Internet Explorer. However, Firefox, by default, does not allow the browser to load content from local system for security reasons. Modify the Firefox browser setting to allow it.

  • Variables – The drop-down list available from this button provides access to these three job variables for customizing TA to your application:

    • Job Name – The name of the job.

    • Job Alias – The alias of the job.

    • Job Run ID – The job run ID of the job.

If your application uses other files with its jobs, using one of these variables in the file name can provide access to the file from the Job Activity pane. Enter the network pathname of the file on this tab and select the Load URL option.

Example: Entering file://\<JobID>.txt on this tab will display the contents of this file on the Runbook tab of the Job Details dialog.

Job Definition – Notes Tab

The Notes tab is very similar to the Run Book tab. This tab provides a space to display additional information about a job, either as written text or as a Web page.

This tab contains these elements:

  • Other Notes – A free text field where you can type any instructions for the operator, up to 255 characters long or type a web address that provides relevant information about the job. While text instructions can be provided, a web page can also be loaded and displayed. A page on your company's intranet with relevant information or a PeopleSoft login page could be displayed. You can also enter a pathname to a directory on the network to display the directory's contents to verify that a file exists in the directory.

  • Load URL – First, type an internet or network directory URL in the Other Notes field and then select this option. This Web address can be for an internet/intranet site or a directory on the network. This can be very useful if information pertaining to a job is stored on a company intranet or a login page must be accessed

    In order to use Load URL feature to load contents of files, located on the network Windows shares, following rules should be utilized:

    • You will need to supply file:// as the protocol indicator.

    Example: file:///\\<yourcomputer>/Share_here/<JobID>.txt

    • Loading the content through file:// protocol works without any intervention from Internet Explorer. However, Firefox, by default, does not allow the browser to load content from local system for security reasons. Modify the Firefox browser setting to allow it.

  • Variables – The drop-down list available from this button provides access to these three job variables for customizing TA to your application:

    • Job Name – The name of the job.

    • Job Alias – The alias of the job.

    • Job Run ID – The job run ID of the job.

    If your application uses other files with its jobs, using one of these variables in the file name can provide access to the file from the Job Activity pane. Enter the network pathname of the file on this tab and select the Load URL option.

    Note: Entering file://\<JobID>.txt on this tab will display the contents of this file on the Run Book tab of the Job Details dialog.

History Tab

The History tab displays status changes using history data for the job as far back as the retention period allows, sorted by job start time with the most recent first. It also shows scheduled jobs that have not run yet. If the job definition is new and the job has not ever run, then there is no History tab because there is no job history yet.

This tab contains these elements:

  • SLA Status – Indicates the SLA status for each job instance based on one of these SLA levels the job instance reaches during its life cycle.

    None – This level is assigned to a job instance without an SLA Time window.

    On Time/Met – This level is assigned to a job instance when it completes on time.

    At Risk – This level is assigned to an in-progress job instance which is at the risk of violating the SLA Time window.

    May Breach – This level is assigned to an in-progress job instance which may breach the SLA Time window.

    In Risk – This level is assigned to a job instance that completes within the SLA Risk window.

    In Breach – This level is assigned to a job instance when the job instance completes within the SLA Breach window or beyond the SLA Risk window in the absence of SLA Breach window.

    Breached –This level is assigned to a job instance that completed beyond the SLA Breach window.

    Note: All the job instances assigned with the SLA status At Risk or higher level are marked as Critical.

  • Job No. – The job number is the instance identification number of the job occurrence. Each occurrence or instance of a job is assigned a unique tracking number when it is added to the schedule to distinguish it from any other occurrences of the job. It is possible that the same job may run several times during a day. When you click the particular job instance number, you can view the details of the job in the Job Activity pop-up window in read-only mode. You cannot edit the job details.

  • Date – The production date of the job instance.

  • Status – The status of the job instance.

  • Est Start – For job instances that have already run or are running, the estimated start time that was predicted before the job or job group became active. For jobs that have not yet run, the estimated time that the job will become active.

  • Ready – The time when the job was ready to run.

  • Launch – The time when the job was launched.

  • Wait Duration – The duration the job waited (between the Ready time and the Launch time) before it ran.

  • Act Start – For job instances that have already run, or are running, the time the job or job group became active. For jobs that have not yet run, this field is empty.

  • Act End – For job instances that have already run or are running, the time that the job or job group ended.

  • Duration – The runtime duration of the job in minutes. For job groups, the duration reflects the duration from the time the first job started to the time the last job ended.

  • Reruns – The number of times that the job has run.

  • Command – The command, program or script that was run.

  • Priority – The priority assigned to the job.

Job Last Run Status

The Last Run Status section displays the job's last run data. While these fields are read-only, they are editable using the Edit Last Run Status option in the Jobs Pane Context Menu.

  • Job No. – The last run id of the job.

  • Status – The last run status of the job.

  • Run Date – The date/time that the job ran last.

  • Exit Code – The exit code based on the job’s completion status.

SLA History Tab

The SLA History tab displays history for the SLA related to a job sorted by Create Time.

This tab contains these elements:

  • Create Time – The date and time when the SLA History record is created.

  • Job No. – The unique job ID.

  • SLA Policy – The SLA Policy the job was associated with.

  • SLA Rule – The SLA Rule defined as part of the SLA Policy that the job was associated with.

  • Date – The date when the related job instance was scheduled to run.

  • Run Date – The date when the related job instance was run.

  • SLA Event – The event that was triggered for a job SLA or system-wide SLA.

  • Ready Time – The date and time when the job was available to run.

  • Active Time – The date and time when the related job instance was active.

  • Wait Duration – The duration (in minutes and seconds) the job waited before it ran.

  • Agent – The agent under which the related job instance was scheduled to run.

Images Tab

The Images tab of the Job Definition dialog allows for the selection of an alternative icon for a job or group. This image is displayed on the Jobs pane or Business Views window. See also Images Repository Interface.