The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
A TES job is a set of instructions about how, when and where to perform an automated task. In the job definition, you can specify a short name for the job (job alias), a command or script to run, where to run the job (agent), the days and times to run the job, the dependencies that need to be satisfied before it can run, and other runtime criteria.
You can organize jobs into TES job groups, where each job in the group can inherit properties from its parent group. Job groups themselves can belong to other job groups. You can view the entire hierarchical structure of all defined jobs and job groups from the Jobs pane.
A job’s or job group’s definition can be added to the production schedule either manually on demand or automatically through a calendar. Each entry of the job into the production schedule is called a job instance; it is an instance of the job definition at a specific time. Job instance history can be reviewed for auditing purposes.
Jobs are built on a hierarchy of job and job group ownership. A job group is a container for a set of jobs, usually part of a common application or department. The job group has its own name and set of runtime instructions.
You can use job groups to submit jobs that either depend on each other, or should run together. For example, all the jobs in payroll can belong to a group called Payroll. The job group can provide default settings to all the child jobs that belong to it. Jobs and job groups are displayed in the Jobs pane. Job groups can save you the time it takes to set up job definitions because each job in the job group can inherit the characteristics of that job group. When you want to create several jobs with similar scheduling characteristics, you can define those jobs within a job group and set the scheduling characteristics in the job group definition. It is also possible to change scheduling characteristics at the job level even though the job belongs to a group.
For example, if a job group is defined to run every Friday, then every job in that job group is automatically defined to run on Friday. If one job in the job group must run on Saturday, then that one job can be changed to the proper run day without affecting the other jobs — as long as you disinherit the job group calendar and change the calendar from within that job.
The ultimate ownership of a job or job group belongs to either the user or a workgroup. A workgroup is a collection of users who can share access to the same jobs. Workgroups are displayed in the Workgroups pane.
You can organize related jobs into groups. Using job group inheritance saves you time and reduces the possibility for error by having jobs automatically inherit properties from the job group to which they belong. You need only change the job properties that are unique to each job. For example, if a job group is defined to run every Friday, then each job that belongs to the job group can inherit the job group’s calendar to run on Fridays as well. Note that when you schedule a job group, every job in the group is scheduled as well, unless you choose not to inherit the calendar property.
Note If a job within a job group does not inherit the parent group’s calendar (the Inherited option on the job’s Schedule tab is not selected), then the calendar assigned to the job must be a subset of the dates within the job group’s calendar. In other words, the job’s calendar cannot contain any dates that are not part of the job group’s calendar.
Each job is assigned one command or script file. The command can be an executable file, a shell script, a batch file, a command file or any other executable file available to the agent that will run the job. You can also specify parameters to be passed to the command. This allows you to create different variations of a definition, based on the parameters that you pass to it. You can even use system or user variables in the command name or parameters.
Y ou can choose which agent will run your job. You can run your job on a specific agent in your network or you can have TES pick an agent based on a list of agents called an agent list . By running jobs using an agent list, you can take advantage of workload balancing, broadcasting and dynamic rerouting.
Jobs and job groups can run either automatically on a regular schedule when you assign a calendar or on an unscheduled basis whether or not it has an associated calendar. For example, a job could run automatically on the 1st and 15th of every month. The job could also be inserted into the schedule as needed throughout the month. When a calendar is not assigned, the job will only run when you manually insert the job into the schedule. Calendars are created from th e Calendars pane an d can be applied to a job or job group from the Job Definition or Job Group Definition dialog.
You can create job dependencies, file dependencies, variable dependencies and time dependencies for a job or job group.
A job dependency is a dependency on another job reaching a certain status. For example, you can set a job to run only after a previous job has completed normally.
A file dependency is a dependency on the existence of a file, on whether or not a file has been modified, or on the size of a file. This feature ensures that your jobs run when the appropriate data is available.
A variable dependency is a dependency on the value of a variable. You can use a preset TES variable or define your own. Variables can be used to track resource usage and can be updated automatically using variable update actions. For more information about variable update actions, see “Actions and Alerts” section.
A time dependency sets a specific time window for the job to run.
You can implement intermaster dependencies by combining different TES tools and areas of functionality, such as job events. The methodology can be extended to apply to dependencies between any number of jobs on any number of masters. For more information on intermaster dependencies, see “Intermaster Dependencies” section .
Job and job group definitions can include exception-based actions triggered by job events. These actions can provide different types of notification as well as perform some additional task(s) in response to certain conditions. For example, a job event could be defined for a job that completes abnormally or when a job stops. You can associate one or more job events with a job. You can also assign multiple actions to each event. For more information about job events and actions, see “Actions and Alerts” section.
TES also watches for system events, such as when the master stops or when the production schedule finishes compiling. Job and system events can then trigger actions in response to the event condition . Job events can also be defined at a system level so that any job will trigger a set of actions when a particular job event occurs. For example, TES can email you if any job runs longer than a predefined maximum allowable time.
TES can respond to events using multiples and combinations of the following action types:
As part of scheduling a job, you can specify the following criteria, which further determine how your job will run:
TES shows all of your jobs in the Job Definition panes. A job consists of instructions that are associated with carrying out an automatic task such as running a script or program. Jobs and job groups can be owned by a user or workgroup. When you own a job, only you have access to its properties. No other user can edit or view your job. If a job is owned by a workgroup, anyone belonging to that workgroup has access to it, within the limits of their security policy. For more information about security policies, see “Security Policy Procedures” section .
As each job enters the production schedule, an instance of that job is created. TES allows you to view the history of each job instance. Job history lists the time and date when each instance ran and its resulting completion status. Job history can be retained for a specified length of time. For example, you could define your job to save the history of all its instances within the past 90 days. All instances that were run prior to this period are purged automatically.
While jobs can be added manually to a schedule that is running at the time, in an ad-hoc fashion, the more common method is to use automatic compilation. Automatic compilation works by assigning a calendar to a job to designate on which dates a job should run. This method creates a production schedule for each day by adding jobs and job groups according to the calendars associated with each job's definition.
The production schedule contains scheduling data for a limited number of future and past days. At midnight every night, TES automatically compiles the next leading day (day out) of the production schedule and purges data for the trailing day (the oldest date in the schedule). The purging is done on a different thread than the production work so that production can continue throughout the purging process. The production schedule date range is determined based on various settings found in the System Configuration and Job/Job Group Definition dialogs. These settings include:
When you create a job or job group with a calendar that specifies a date within the current production schedule range and click OK , the Effective Date dialog displays to choose the date to begin running the job or job group. Each day, the automatic compilation process compiles incrementally for the next leading day, checking the calendar information of each job or job group to see if it should run on that day.
Note Because only the leading date of the production schedule (or forecasted schedule) is compiled automatically, if you choose not to schedule a job or job group using the Effective Date dialog, the job or job group will only enter the schedule on the next compile. For example, if Job D is scheduled to run daily, you can choose Cancel from the Effective Date dialog, and if the production schedule presently spans11/1/04 to 11/5/04, the job or job group will be scheduled to run starting on 11/6/04.
If you want to remove the job from the production schedule, you can disable the job from the Jobs pane by right-clicking it and selecting the Enable option from the context menu. You can also right-click it from the Job Activity pane and select the Remove Job(s) from schedule option from the context menu.
A job is the set of rules that governs the running of an executable. A job group is a collection of jobs. The job group itself does not have an executable associated with it.
Because of the nature of jobs and job groups, the TES console pane that displays job and group definitions can be correctly referred to as either the Jobs pane.
From the Navigator pane, select Definitions>Jobs to display the Jobs pane.
Note The Jobs pane displays only those jobs that are owned by you or owned by a workgroup to which you belong.
You can change the sort order of the jobs display by clicking the head of the column that you want to use as a sort key. You can also re-order and select columns from the Preferences dialog.
The number of jobs and groups that are currently displayed (that you have access to) displays in the upper right corner of the Jobs pane. You can see at a glance the number of records without having to count each row. Note that a group will be counted as one record when it is collapsed, and as one plus each child within it when it is expanded.
The Jobs pane contains the following buttons:
Enter text that you want to search for within the columns displayed into this field.
Note This field at the top right of the grids will only search text columns that are not grayed out and are string-based. See “Searchable Columns” section.
The Jobs pane contains the following columns:
If you select Preferences from the View main menu while viewing the Jobs pane, the Jobs Preferences dialog displays.
From the Jobs Preferences dialog, you can select which columns are displayed in the Jobs pane and in what order they appear.
You can specify whether the default view shows job groups expanded for easy viewing or collapsed to save screen space. Click the Other tab and make the appropriate selection.
When you right-click in the Navigator pane while viewing the Jobs pane, the Navigator context menu displays.
The following describes the items in the Jobs pane Navigator context menu:
– Collapse All – Closes all of the job groups.
The Jobs context menu displays by right-clicking a job or job group record in the Jobs pane. The menu options may be different according to the user’s security policy.
This context menu contains the following options:
Note Some job options only display in the submenu if you are licensed for that adapter.
– Expand Selected – Expands the selected job groups to display the individual jobs.
– Collapse Selected – Closes the expanded job group that is selected.
– Collapse All – Closes all of the job groups.
Note To add a job to production with the Insert Into Schedule menu option, the Unscheduled Allowed option must be set in the job definition.
Each TES job instance has its own life cycle in the production schedule. The job’s current status indicates where it is in its life cycle. A typical life cycle is one where the job:
Each phase corresponds to the statuses Waiting On Dependencies , Waiting On Resource , Launched , Active and Completed Normally , respectively. Other statuses are also possible depending on certain conditions and exceptions.
Note For more information on error job conditions, see “Monitoring Production” section.
The following table describes the different job statuses that TES can assign to a job or job group:
The job was aborted and cannot be resumed. A job can be aborted if it is Active or Stopped status. |
||
At least one job in the group is active. If no jobs in the group are active and there are still jobs in the group that need to run, the status will be Waiting on Children . |
||
The agent where the job is supposed to run is not enabled, and the job cannot run. If a job is using an agent list, all agents in the agent list have been disabled. To allow the job to run, select an alternative agent override or enable the agent from the agent’s Connection Definition dialog ( Connections pane). |
||
The agent where the job is to run is not connected or is not running. If the job is using an agent list, all agents in the list are unavailable. To get the job to run on the agent, determine why the agent is not available and correct the problem. For information about making an agent available, see “Starting and Stopping TES Components” section . |
||
The job was canceled by an operator and cannot be resumed. A job can be canceled while it is waiting in the production schedule ( Waiting On Dependencies status) or in a queue ( Waiting On Resources status). |
The job group is canceled by an operator and cannot be resumed. Jobs in the group that were waiting were also canceled. Jobs in the group that were active were aborted, if possible. |
|
The job is canceled but its dependencies are released to run to completion. Once the dependencies are satisfied, the job status changes to Canceled Normally . If any of the dependencies do not complete, the job remains in the Canceled Pending status. This status only occurs from a user-initiated job control action or a job action. |
The job group is canceled but all of the dependencies placed on its child jobs are released. In essence, this status is like the Waiting on Dependencies status. Once the dependencies are satisfied, the jobs go to the Canceled Normally status. If any of the dependencies are not fulfilled, the job group remains in the Canceled Pending status. |
|
A job that was in the Canceled Pending status ends in the Canceled Normally status once the job’s dependencies are fulfilled. The job is considered to have completed normally. |
Any job in a job group that ends with a Canceled Normally status is treated as if the job completed normally. |
|
The job completed with a non zero exit code indicating abnormal operation. |
All jobs in the group ran and at least one job in the group completed abnormally. |
|
The job has completed abnormally but the job output is still being gathered and is not yet available. |
The job group remains in Active status until the output is posted. |
|
The job has completed normally but the job output is still being gathered and is not yet available. |
The job group remains in Active status until the output is posted. |
|
Another instance of this job was running when this instance was ready to launch, and the concurrency option for the job was set to Defer . This job instance will run after the previous instance completes. |
||
An error occurred when launching the job and it did not run. There is no exit code. The specific error can be viewed in the TES logs and will show in the Job Details dialog. For more information about logs, see “Monitoring Production” section . |
An error occurred for at least one job in the group. If another job has a Completed Abnormally status, the Error Occurred status will still be set at the group level. |
|
The job completion status is defined manually, and has not been set yet. |
||
The job status was determined by an external user or program and the job output is still being gathered and is not yet available. |
||
The job is restricted from running by an operator or an action. A job can be held up until the time it becomes active. |
All active jobs in the group have stopped, and all waiting jobs have been held. |
|
A request to launch the job has been sent to the agent, and is pending notification from the agent that the job has started executing. This state is between Waiting On Resource and Active . |
||
The agent on which the job was running is no longer in communication with the TES master. The master does not know its final status. The agent, network or master may be down. |
||
This is the initial status of a job when it is added to the schedule. If it is scheduled to run today, the job will enter either the Waiting On Resource , Waiting On Operator , or Waiting On Dependencies status, depending on the job’s properties. Otherwise, it will stay in the Scheduled status. A job also temporarily enters this status when it is released by the operator. |
This is the initial status of a group when it is added to the schedule. If it is scheduled to run today, the group will enter either the Waiting On Resource , Waiting On Operator , Waiting On Children or Waiting On Dependencies status, depending on the group’s properties. Otherwise, it will stay in the Scheduled status. A group also temporarily enters this status when it is released by the operator. |
|
Another instance of this job was running when this instance was ready to launch, and the concurrency option for the job is set to Skip . This job instance will never run. |
||
Execution of the job has been suspended. A job can enter Stopped status only when it was previously Active . |
||
The job missed its time window today. An attempt will be made to run the job tomorrow. A job cannot time out when it is in a queue ( Waiting On Resources ) or when it is Active . |
||
The job missed its date and time window. No attempt will be made to run the job tomorrow. A job cannot time out when it is in a queue ( Waiting On Resources ) or when it is Active . |
||
The group is waiting for its children’s dependencies to be met. |
||
The job is scheduled and it is waiting on job, file or variable dependencies to be met in order to run. |
The job is scheduled and it is waiting on job, file or variable dependencies to be met in order to run. |
|
All the job’s dependencies are met, and it is waiting for the operator to release it. |
All the group’s dependencies are met, and it is waiting for the operator to release it before its children can run. |
|
The status of a job group is determined by its children. The following table demonstrates the order of precedence and correlation between the status of a group and the status of its children. For more information on a particular status, see the table “Job and Job Group Statuses” section .
Note The final status of a job group is determined by the statuses of all of its children, whether the child job ran on the current day or started on another day as a carryover job. This means if a child job that started on the previous day completed abnormally and other child jobs ran on the current day and completed normally, the job group is considered to have completed abnormally.
TES lets jobs inherit properties from its parent job group. When you create a job group and add a job, key properties of the job will default to its parent group’s properties. You can then save time by changing only the individual job properties needed for each job.
For example, let’s say you have a job group called Payroll Jobs containing four jobs: one job collects wage data, one job formats the data into a management report, one job finalizes and registers the data in the payroll database and one job prints payroll checks. Since these jobs are similar, they can inherit many properties of the parent job group, Payroll Jobs , such as on which days to run and on what machine. All you need to do is specify each command to run, and their dependencies on each other. For example, Job 2 depends on the completion of Job 1 , and Job 3 depends on the completion of Job 2 , etc. Thus, by using inheritance, you save the time it takes to specify job data common between the jobs.
Note If a job is assigned a calendar that conflicts with its parent group's calendar, and the Inherited option on the Run tab is not selected, that job will NOT run.
Jobs can inherit a particular set of group properties. Not all properties are inherited. The following table shows which job properties can be inherited from the group:
TES allows you to make environment variables available to each job that you launch by entering the name of an environment file in the Job Definition dialog. For more information, see “Job/Job Group Definition Dialog” section . The file should be a plain text file and can have any name, as long as the correct path to the file is entered in the Environment File field of the Job Definition dialog. No commands are allowed in the file, only variable designations.
All environment variables are specified in the environment file in the following format:
Note Do not leave any space between the variable and its value. If you leave spaces, the variables will not be read correctly.
The following table lists available environment variables that you can use in your environment file:
Jobs and job groups are added to the production schedule in various ways:
If you assigned a calendar, the Effective Date dialog displays, under certain conditions as explained below.
Note The Effective Date dialog displays when first adding a job to the schedule or when modifying certain job parameters that affect how the job runs. Changing a job’s command, calendar or agent parameter displays the Effective Date dialog while changing the owner, job class or notes of the job does not.
If you did not assign a calendar, a dialog displays a message that the job can only be added manually to the production schedule.
The Effective Date dialog is only displayed when accepting scheduled jobs whose next scheduled calendar date falls within the production schedule range and only when the master is running.
For example, if the current production date range is 12/10 to 12/20, and the next calendar date to run the job is 12/30, the Effective Date dialog will NOT appear. However, the job will be added to the schedule automatically on 12/30 through the automatic compile feature.
You can choose the day that the first instance of the job should run by selecting from the Scheduled Dates list when the Effective Date dialog displays. The Scheduled Dates list only includes dates that are currently in the production schedule and match the job’s calendar.
Note • Any changes made to a job definition do not apply to the current production schedule if the job has already run, even if the current date is selected in the Effective Date dialog. The following examples help illustrate the circumstances where modifications to a job definition do not apply to the current production schedule:
– If the job being saved has already started to run (any status other than Scheduled , Waiting on Dependencies or Waiting on Resources ) or the job has completed.
– If the job being saved is a repeating job and has already run once.
– If the job being saved belongs to a job group where any of the other jobs of that job group have already started to run or have completed.
– If the job being saved belongs to a job group where any of the other jobs inside that job group are a repeating job and have already run once.
In these circumstances, to make the modified job definition run in the current day, you should use the Insert into Schedule option. Be aware that inserting the job manually will give the job a higher job instance number which may affect job dependencies within other job definitions.
If a job or job group repeats a specified number of times or if a job group contains jobs that repeat, the Start today’s repeating job(s) now option will appear in the Effective Date dialog. Selecting this option will create the first repeating instance now; otherwise, the instances will start at the beginning of the job’s time window. If you do not select this option, your job or group will enter the schedule on the date shown in the Effective Date dialog. If no time window is specified, it is assumed to be 12:00:00 AM to 11:59:59 PM. This may result in partial or even no scheduled instances of repeating jobs or groups if the current time is past the last repeat of the job.
If the master starts after the job has been created, the job will only enter the schedule on demand through the Effective Date dialog for the day or the next eligible day that is compiled.
If you submit a child job through the Effective Date dialog and the parent group is not in the production schedule, the parent group is automatically added as well.
Note The first selected job is the default for the Insert Into Schedule dialog. You can use this selection or select a different job using the Job Search dialog as explained in the Job Search dialog section.
Insert Into Schedule inserts one instance of the selected job or job group into the production schedule to run today, including its dependency criteria.
The job or job group must have the Unscheduled allowed option selected in its definition before the Insert Into Schedule method is available.
When a job group is selected to Insert Into Schedule , all of its members are also inserted. Only one instance will be added, even if the job or job group is defined to repeat during the day.
If a child job is added using Insert Into Schedule , the job will not have a parent group in the production schedule. If the parent already exists in the schedule, the Insert Into Schedule method will not associate the child job with it and will not reflect its duration and status. If the parent does not already exist in the production schedule, the Insert Into Schedule method will not include it.
If the job or job group already exists, a new instance will appear in the schedule, followed by a sequence number in parentheses, e.g., Job A (2) .
The Create Schedule method deletes all instances in the production schedule for the dates you specify, and recreates the schedule with qualifying jobs as determined by the rules defined in the Job Definitions pane. All completed, active and previously scheduled jobs are removed. Extreme caution should be used with this method to prevent the inadvertent deletion of critical jobs.
Jobs that are not enabled, do not have associated calendars, or whose time windows have passed are not included in the production schedule when you use the Create Schedule method. Also, all jobs that were added to the production schedule manually for the selected day(s) are lost and must be re-inserted.
If you select the S tart today’s repeating Job(s) now option with the Create Schedule method, the first instance of a repeating job will be the current time. Otherwise, they start according to their time window. If no time window is specified, it is assumed to be 12:00:00 AM to 11:59:59 PM. This may result in partial or no scheduled instances of repeating jobs or groups if the current time is past the last repeat of the job.
At midnight, a new day is automatically added to the end of the current production schedule (determined by the configuration of how many future days to include). Whether the new day compiled is “tomorrow” depends on your configuration of Future Days to Include in Schedule . For more information on compilation options, see Getting Started . Qualifying jobs are added for the new day and the oldest day of history is removed.
Note The parameters for compilation are determined by your job and job group definitions and System Configuration settings. For more information on automatic compilation, see “Defining Jobs” section
The new job action method is discussed in Actions and Alerts . The operation of this method is similar to using Insert Into Schedule , as described for Method 2.
Following are the ways to modify the properties of an existing job instance:
Jobs that have not run and whose properties were changed are replaced with the new instances of the job when they re-enter the schedule. If the job’s Enabled option or calendar is removed, the job will be deleted and not replaced. Changes do not affect jobs that are rerun.
Use the Job Detail dialog to override the Agent or Agent List , Queue , Job Priority , Command , Environment file or Output File Name of an individual instance. This is very useful when the job does not run correctly using the original parameters, and you want to adjust them and rerun the job or job group without affecting the original job definition.
Job definition is central to job scheduling. The job definition defines:
When you want to schedule a command to be executed, you use a job. Once a job is defined, you can keep the definition and run the job repetitively according to its specified calendar, or as needed.
Each job is assigned to only one command. The command can be an executable, a batch file (Windows only), a shell script, a command file or any other executable process. You can specify parameters to be passed to the command. This enables you to use one command in different ways, based upon the parameters that you pass to it.
For example, a job can back up files to tape, run a program to post transactions to a database or run a set of reports. In TES, you give each job a name, and, if the job is repetitive, a calendar by which it runs. You can also define dependencies that must be met before the command is executed. Using the calendar, TES automatically launches jobs each time they are scheduled to run, but only after all of their dependencies have been met.
All jobs are defined using the same basic Job Definition dialog. The standard Job Definition dialog can define the attributes of most scheduled jobs but some types of jobs have unique properties that require special fields to fully define what the job does. These jobs include FTP, MapReduce, SAP, PeopleSoft jobs and Oracle Application jobs. These jobs have their own page to define attributes unique to this type of job.
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.
Note Do not use the text characters of “, / or = in the name that you assign to a job.
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.
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.
Note 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.
Note that 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.
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 the following elements:
|
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. |
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 Tidal 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.
TES 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 allow a single command file to be used for multiple purposes. For example, 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. TES will wrap the text display so that it is easier to read.
TES 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. For 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 following 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 TES 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 the following options to manipulate text: Undo , Cut , Copy , Paste , Delete and Copy All .
For 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 TES. If this field is not used, TES provides the default standard output file produced by the process launched on the agent.
This tab of the job definition determines when and how often a scheduled job will run by controlling its calendar and time window.
You can specify the days and times when the job will run and any calendar offset.
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.
You can configure timezones where target application environments are based. This allows you to schedule a job or job group across multiple timezones. If a timezone value is not specified in a job or job group definition, the master will default to the master timezone.
– If only X (the first time value) is specified, for example 5:00 PM , the job can launch between 5:00 PM and 11:59 PM of the same day.
– If only Y (the second time value) is specified, for example 3:00 PM , the job can launch between 12:00 AM (midnight) and 3:00 PM of the same day.
The time window function is a little more complicated with job groups. The time window of any child job of a job group, must be confined within the time window of its parent job. By selecting the Inherited option in the Time Window section of a job within a job group, a child job would inherit the same time window as its parent job. Even if the child job does not inherit the time window of its parent than its default time window remains the time window of its parent job. The time window of a child job can be within than the time window of its parent but it cannot be larger than the time window of its parent job.
The time format that appears in these fields is determined by the settings in the Windows Control Panel , Regional Settings .
– Do not timeout – Select this option if you want to carry the job forward to the next day if it fails to start by the end of the time window specified.
– Run again tomorrow – Select this option if the job has not run by the end of the time window specified, and you want to carry it forward to the next day. After the time window has passed, the job has the status Timed Out For Day . With this option selected, the job is eligible to run on each subsequent day, until it does run. You can set up a job action to notify you if your job does not run on the originally scheduled day.
If Do not timeout and Run Again Tomorrow are both unchecked, the job will timeout at the end of the time window.
If Do not timeout is checked, but Run Again Tomorrow is unchecked, the status of the job will not be set to Timeout . However, any job events running that are based on the end of the time window are triggered at the end of the time window.
If Do not timeout and Run Again Tomorrow are both checked, the status is set to Timed Out For Day and the job carries over to the next day and run then.
Note Each instance of the job that is scheduled through the Repeats section will recheck the dependencies of the original job. For more information, see Dependencies Tab.
– 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 –
The following rules govern this function:
For example, if a job’s time window begins at 12:00 PM, and the job is defined to run every hour up to 4 times, the job will run 12:00 PM, 1:00PM, 2:00PM and 3:00PM. If the Create Schedule command occurs at 1:30PM, this job will run twice, once at 2:00 PM and once at 3:00 PM (unless the Start today’s repeating jobs now option is selected in the Effective Date dialog).
For 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.
– Rerun same occurrence after... 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 y 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. The Rerun same occurrence after... 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).
Note Jobs dependent on a job using the Rerun same occurrence after... 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:
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.
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.
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.
Note The Tidal 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.
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.
Note You can clear the above fields by right-clicking them, and selecting Clear from the context menu or by pressing the Delete key.
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 can range from 0 to 30,000.
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.
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.
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:
Step 1 From the Navigator pane, select Administration>Users to display the Users pane.
Step 2 Click the Add button or right-click and select Add User from the context menu to display the User Definition dialog.
Step 3 Type LocalSystem in the User Name field.
Step 4 Type LocalSystem in the Full Name field. This name is used in TES reports and some dialogs.
Step 5 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.
Step 6 Select 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 TES.
Step 7 After creating the Local System account, you need to grant or deny each user the right to use the Local System runtime user account.
a. From the Navigator pane, select Administration>Users to display the Users pane.
b. Double-click each user account to open the User Definition dialog and click the Runtime Users tab.
c. Select 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.
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 the following elements:
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.
– The Rerun each time dependencies are met option cannot be used in conjunction with the Rerun same occurrence... option on the Schedule tab, 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 when the master restarts if 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. For example, delete a file if the job has a job dependency so that only a new file will meet the job’s dependency.
Note Jobs dependent on a job using the Rerun same occurrence after... minutes up to... times option will never be satisfied.
Step 1 Put both jobs under the same group.
Step 2 For the group, select the Rerun same occurrence after... minutes up tINTERNET.. times option on the Schedule tab of the Job Group Definition dialog.
Step 3 For each job, select the No repeat option on the Schedule tab of the Job Definition dialog.
The Tidal 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.
Each type of dependency (Job Dependency Definition Dialog, Job Dependency Definition Dialog, Job Dependency Definition Dialog, and Job Dependency Definition Dialog) being set on a job has its own definition dialog.
The Resources tab appears in the Job Definition dialog but not in the Job Group Definition dialog since resources cannot be assigned to a job group. Resources for a job, Virtual or System , 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 TES 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 displays.
A resource can be quantified and the sharing of the resource can be limited to a designated number of shares. 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 will not run until all of the resources listed on this tab are available for the job when it runs. A job 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, it creates a “reservation” for the job to use a set amount of the resource.
This tab contains the following elements:
– Resource – Displays the name of the virtual resources associated with the job.
– Amount Required – Displays the amount of the resource needed by the job. This amount is defined in the Resource Requirement Definition dialog.
– Add – Click this button to display a Resource Requirement Definition dialog to associate an existing resource to this job.
– Edit – Click this button to display the Resource Requirement Definition dialog of the selected resource to edit it.
– Delete – Click this button to delete the selected resource.
– Clear – Click this button to delete every resource listed for the job definition.
– Resource – Displays the name of the system resources associated with the job.
– Condition – Contains the conditional operators depending on the data type of the resource.
For Integers, the conditions supported are:
Strings support all of the conditions above and the following:
– Value – Contains the value for the condition.
– Add – Click this button to display a System Resource Requirement Definition dialog to associate an existing system resource to this job.
– Edit – Click this button to display the System Resource Requirement Definition dialog of the selected system resource to edit it.
– Delete – Click this button to delete the selected system resource.
– Clear – Click this button to delete every system resource listed for the job definition.
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.
When you click Add on the Resources tab of the Job Definition dialogs, the Resource Requirement Definition dialog displays.
The Resource Requirement Definition dialog is used to add or edit an existing resource to a job from the Resources tab. From this dialog, you specify which resource and how much of the resource is needed by a job. If the Enabled option is not selected in the resource's definition, then the resource does not display in the drop-down list.
This dialog contains the following fields:
When you click Add on the Resources tab’s System Resources section of the Job Definition dialogs, 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 from the Resources tab. From this dialog, you specify which resource and how much of the resource is needed by a job. If the Enabled option is not selected in the resource's definition, then the resource does not display in the drop-down list.
This dialog contains the following fields:
For more information about defining a resource, refer to Resources Pane .
The Variables tab appears in the Job Group Definition dialog but not in the Job Definition dialog. This tab is used for specifying that a job group use certain variables instead of global variables. When multiple instances of a job group using global variables run concurrently, data values cannot be preserved since the variable value changes as each job group instance runs. By assigning variables to the Variables tab, the variable becomes “localized” or isolated from the changes that occur outside of the job group. These variables can be either variables hard-coded to specific values or global variables available from the Variables button menu. Child groups have access to parent group variables through the Variables button menu.
A job that is a regularly scheduled production job uses the default values for its variables. However, a job group inserted into the schedule manually can specify values to be used only by that run of the job group.
The ad hoc job group instance and any child job groups associated with it will use the variable values specified at insertion regardless of other occurrences of the same job group that may be running and using a different set of variable values.
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 the following elements:
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.
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.
This section is read-only. These are job events that apply to all jobs. They are not individually assigned. You can only change a system-wide job event from the Job Event Definition dialog.
When you click Insert from the Job Events tab of the Job or Job Group Definition dialogs, the Select Job Even t 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 the following columns:
When you click Edit from the Job Events tab of the Job or Job Group Definition dialogs, the Job Event Definition dialog displays.
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 the following elements:
If a Job Group is set up this way:
B1: Subgroup whose parent is A1.
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.
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 the following elements:
– 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 only after the previous instance of the job completes with a Completed Normally status. If the previous instance does not complete normally, this job will not run.
– Defer until Complete – Runs the job only after the previous instance completes regardless of the final status of the previous job.
– 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.
– 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.
– Discard – To Discard is the TES 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 TES job output files. You cannot separate stdout and stderr.
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 the following elements:
Note • 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.
For 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.
– 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. For example, entering file://\<JobID>.txt on this tab will display the contents of this file on the Runbook tab of the Job Details dialog.
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 the following elements:
Note • 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.
For 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.
– 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. For example, entering file://\<JobID>.txt on this tab will display the contents of this file on the Run Book tab of the Job Details dialog.
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 the following elements:
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.
For a remote FTP (File Transfer Protocol) to work, the following limitations apply:
Note Some FTP jobs may require that the domain name be part of the user name. If a FTP job requires the domain be part of the user name, before you can run the job you must modify the user name by adding the domain to the User field in the following format, domain\user.
When you select the Add FTP Job option, you will find that the FTP Job Definition dialog differs from the standard Job Definition dialog in two ways:
These two tabs with their differences are described below. The other tab and fields in the FTP Job Definition dialog are the same as the normal Job Definition dialog. For information on the other tabs and fields refer to the section on “Defining Jobs” section .
The FTP tab contains the following fields:
– FTP – The job will use the normal FTP protocol. No file encryption is used with this option.
– FTPS – The job will use FTPS or FTP Secure and FTP-SSL.
– SFTP – The job will use SFTP or Secure File Transfer Protocol. The file is encrypted when transferred between hosts using SSH2. SFTP can only use the binary format so the ASCII format is unavailable if this option is selected. The FTP Quote feature that assigns file formatting to a file being transferred between a mainframe and non-mainframe platform is unavailable with SFTP.
– PUT File – Copies the designated file from the agent to the FTP server.
– GET File – Copies the designated file from the FTP server to the agent.
– MPUT File – Copies multiple files using wildcards from the agent to the FTP server. (For more information on wildcards, refer to “Wildcards in File Dependencies” section .)
– MGET File – Copies multiple files using wildcards from the FTP server to the agent. (For more information on wildcards, refer to “Wildcards in File Dependencies” section .)
– RENAME File – Changes the name of the file on the FTP server.
– DELETE File – Removes the designated file from the FTP server.
– MDELETE File – Deletes files on remote computers.
– LIST Directory – Lists the files within a designated directory on the FTP server.
– MAKE Directory – Creates a designated directory on the FTP server.
– DELETE Directory – Deletes a designated directory on the FTP server.
The remaining fields on the FTP tab vary according to which FTP Operation option was selected.
– ASCII – This format maintains the line returns within a file but loses most other formatting. This format option is not available if the SFTP protocol option is selected.
– Binary – This format saves formatting within the file.
Any of these encryption methods may be used during the file transferal between two machines with the secure FTP procedure.
Like strangers traveling in a foreign land attempting to communicate with one another, server machines do not know which encryption “language” is being used by the other. TES will try each of the listed encryption protocols to establish a common encryption protocol. A user can configure the order that TES tries when it attempts to find the encryption protocol recognized by the other machine. If the user knows which encryption protocol is used by the other system, the user can select that protocol and click the up and down arrows to move it to the top of the list where it will be the first protocol attempted during file transferal. Moving the correct protocol to the top of the list will eliminate guesswork and save time during the FTP process.
– # of Files – Details the number of files transferred.
– # of Bytes – Details the size of the file (in bytes) that was transferred.
– # Skipped – Details the number of files within a designated directory that were not FTP’ed.
– Duration (Seconds) – Details how long (in seconds) that it took to perform the FTP operation.
In the Agent Information section you define the agent, the user account to be used and the FTP server information.
In the Tracking section, select a method to determine that a job has completed. Four options are available:
In the Duration section, specify the time parameters for job completion. These parameters are used to send an alert to the console if a job is not completing as expected.
The fields displayed on this tab depend on the Protocol selected, Hadoop or Amazon S3.
The Data Mover tab contains the following fields:
– Copy To Local File – select to copy a Hadoop Source file to a local destination file.
– Copy From Local File – select to copy a local source file to a Hadoop Source destination file.
– Local Source Files – the Local file(s) to be copied to the Hadoop file system. When copying multiple Local Source files, the failure of any file to be copied does NOT cause the entire copy to fail; an attempt is made to copy every file. When specifying multiple Local Source Files, use a comma separated list of file
– Hadoop Destination File – where the Local Source File(s) are copied. The Hadoop Destination File can specify a Hadoop directory. When multiple Local Source files are specified, the Hadoop Destination File must specify a Hadoop directory.
– Use Connection Details From – Select the predefined connection you want to use to pull connection details from.
– Name Node – Enter the HDFS node name.
|
When defining a DataMover Job using MapR Hadoop, set the Name Node field to “maprfs:///”. |
The Data Mover tab contains the following fields:
– GET OBJECT – retrieves objects from Amazon S3
– PUT OBJECT – adds an object to a bucket
– PUT MULTIPLE PARTS – adds multiple parts of an object to a bucket
Note The fields in this section change depending on which Amazon S3 Operation is selected.
For the GET and PUT operations:
– Bucket Name – Enter the name of an already existing bucket on Amazon S3 owned by the user identified by the Access Key and Secret Key provided on the Run page.
– Object Name – Enter the name of the object in the bucket that you want to retrieve/add.
– Local File – Enter the location and file name where you want to store the retrieved/added object.
For the PUT MULTIPLE PARTS operation:
– Bucket Name – Name of an already existing bucket on Amazon S3 owned by the user identified by the Access Key and Secret Key provided on the Run page.
– Object Name – Name of the Object in the Bucket that you wish to store the file as.
– Local File(s) – A comma separated list of the locations and file names that you would like to upload to the specified bucket and object. All of the files must be at least 5MB in size except for the last one.
Depending upon the selected AS3 operation selected on the Data Mover page, this dialog contains the following elements:
– AS3 Protocol – Select the protocol you want to use to communicate with Amazon server.
The default is HTTPS, but HTTP can be used.
– Maximum Connections – Enter the maximum number of allowed open HTTP connections.
– Maximum Retries – Enter the maximum number of retry attempts for failed retry-able requests.
– Maximum Timeout – Enter the amount of time to wait (in milliseconds) for data to be transferred over an established, open connection before the connection is timed out and closed.
Object Version – Enter the specific version of an object to be the target of the get operation.
Matching ETag(s) – Enter the MD5 hash of the object. It can be used to select a specific version of an object to be the target of the get operation.
Non Matching ETag(s) – Enter the MD5 hash of the object. It can be used to non-select or preclude a specific version of an object as the target of the get operation.
– PUT OBJECT & PUT MULTIPLE PARTS –
Target File Name – This is a way to set a ‘suggested’ filename for the contents of the transfer. There is no guarantee that the ‘request’ will be honored.
Expiration Rule Id – Enter the Bucket Configuration rule ID for this object's expiration.
Encoding – Select the content type from the drop down list if you desire to specify the content type.
Content Type – When uploading files, Amazon S3 will attempt to determine the correct content type if one hasn't been set yet. If no content type is provided and cannot be determined by the filename, the default content type “application/octet-stream” will be used.
Server Encryption – Select from the drop down list whether you want no Server Side Encryption or the object to be encrypted using AES-256 (the only encryption algorithm currently available from Amazon S3).
Expiration Time – If you want the object that is being uploaded to expire after a set time, provide the time delta here in milliseconds.
MD5 – Select whether you want an MD5 hash to be generated for the transfer for validation of the contents when received by the Server.
Custom Metadata – Specify name=value pairs that you want to attach to the object as metadata when it is uploaded. Click Add to add metadata via the Add Metadata dialog or edit to edit existing metadata via the Edit Metadata dialog.
– (Optional) Variables – Click to insert a predefined TES variable into a selected field.
In the Agent Information section you define the agent, the user account to be used and the FTP server information.
In the Tracking section, select a method to determine that a job has completed. Four options are available:
In the Duration section, specify the time parameters for job completion. These parameters are used to send an alert to the console if a job is not completing as expected.
Maximum – If the job completes after the specified number of minutes, an alert can be created to notify the operator.
The Effective Date dialog appears after either modifying the parameters of a job or job group contained in one of the compiled schedules or modifying a calendar used by one of the jobs contained in the compiled schedules. From this dialog, you specify the date when the changes should apply. The Effective Date dialog only appears if you are connected to the master.
This dialog contains the following elements:
Note Any instances of a job that has not yet run will be replaced.
If you create a repeating job without specifying how often the job should repeat, the Start today's repeating job(s) now option is not displayed in the Effective Date dialog. The job will be continually repeated at the designated intervals all day; thus, the job automatically starts at the beginning of the production day.
Click Cancel in the Effective Date dialog if you want your changes to take effect as of the next automatic or manual compile.configured.
Note The default beginning of the production day is midnight. This default can be changed in the System Configuration dialog. For more information, see Getting Started.
The Calendar Forecast dialog displays by clicking the Forecast button on the Schedule tab of the Job Definition or Job Group Definition dialog.
This dialog displays the dates the job will be scheduled to run based on the selected calendar, adjusted by the offset (if any).
The Insert Into Schedule dialog displays whenever you select the Insert Into Schedule option from the Jobs pane context menu or by selecting the Insert Into Schedule option from the Activities main menu.
The fields in this dialog vary slightly depending upon what is highlighted in the Jobs pane. The dialog for inserting individual jobs into the schedule has a Parameters field for modifying parameters of the job instance being inserted.
This dialog contains the following elements:
The dialog for inserting a job group has the same fields as the dialog for inserting individual jobs except the Parameter field is replaced with a Variables field that lists the name of the group variable listed on the Variables tab of the job group definition and its default value. The default values can be modified as needed when inserting the job group into the schedule.
The dialog for inserting multiple job/job group selections has the same basic fields as the other dialogs. However, instead of a Parameter or Variables field, the selections are listed. When inserting a multiple selection of jobs and/or job groups, the dialog displays the name and pathname of each selection to illustrate the parent-child nesting level. The selections cannot be modified from this dialog.
You can filter the jobs that appear in the Jobs pane to screen out the jobs that you do not want to see. The Job Rule Filter dialog provides various fields to filter out undesired jobs. The more fields used to filter the jobs displayed in the Jobs pane, the more specific the results.
The Job Rule Filter dialog displays in the Jobs pane when the Filter option is selected in that pane's context menu or the Filter button is clicked.
This dialog contains the following elements:
* (Asterisk) – The asterisk character masks any number of characters on and to the right of the location it is placed. For example, A* will match (allow in) AB, ABB, and ABBB.
? (Question Mark) – The question mark masks one character in the location it is placed. For example, A?A will match ABA and ACA, but not ABB or ABBA.
[x, y, z] – The brackets with commas let you specify a set of characters to filter in to that location in the string. For example, A[X,Y]B accepts AXB and AYB but not AAB.
[a–z] – You can also specify ranges within brackets. For example, A[X–Z]B filters in AXB, AYB, and AZB but not AWB.
Note The Show Groups option must be selected before you can use this field.
The Job Search dialog is accessed from various dialogs by clicking the Browse button. Use the Job Search dialog to set the criteria used to find jobs.
This tab contains the following elements:
You must select at least one of the check boxes in the following categories. You may also select both check boxes to search in both categories.
You must select at least one of the check boxes in the following categories. You may also select both check boxes to search in both categories.
This tab contains the following elements:
You can create jobs with variable dependencies that are determined by jobs processed on another master. A job with an intermaster dependency resides on a local master subscribing to a remote master that publishes the value of a variable.
For the purpose of an intermaster dependency, the local master becomes a type of client to the remote master. The variable is defined on the remote master and made available to other masters. The local master subscribes to a variable managed by another master by creating a special remote master connection. Because the local master is a client to the remote master, the communication port is the same one used by the client of the remote master. If the remote master is using fault tolerance than the connection is configured to automatically switch to the backup machine of the remote master if a failure occurs. This connection displays in the Connections pane as a Remote Master connection. The Connection Definition dialog also displays the variables that the remote master is publishing. These variables are regularly updated and cached on the local master and the actual variable values are published at the time required by the specific job.
When defining a variable dependency, you specify which master manages the variable. If no remote connections have been set up, then the local master is the default. If you selected a remote master, you can select a published variable from a drop-down list of variable names.
You control which variables are available for remote master use through the Variable Definition dialog. You can keep a variable for use only on the local master or publish the variable for use by remote masters. You can also elect to either publish the variable in unalterable form or allow others to modify the variable.
A system event can be created to notify a user if connection between the remote and local master is lost. A lost connection prevents a job from completing since the variable value cannot be determined. A user can also check on the status of an intermaster variable by studying the Dependencies tab of the Job Detail dialog. An intermaster variable will show a value of Unavailable if the connection to the remote master is lost.
Note It requires a separate license to use intermaster dependencies. You cannot define a remote master or publish intermaster variables without a license for intermaster dependencies.
The methodology described here can be extended to apply to dependencies between any number of jobs on any number of masters. In brief, the technique to implement intermaster dependencies uses a job event on one master to set a variable value on another master whose job(s) will depend on that variable.
For example: Master2:JobB depends on Master1:JobA
Step 1 Install an agent on the same machine as Master2 or one of its clients. This agent will service Master1 . (If there are cross-dependencies such that Master1:JobC depended on Master2:JobB , you would install an agent on the same machine as Master1 or one of its clients to service Master2 ). An agent is required for each unique intermaster relationship. Remember, more than one agent can be installed on a single machine to service multiple masters.
Step 2 On Master1 create a linking job that runs on the agent installed on Master2 (or one of its Tidal Web clients). This job will run the varset command from the client's command line interface to set the value of a variable on Master2 to indicate that the dependency has been met; for example, the job definition for the linking job would contain the following:
C:\Program Files\Tidal\TESCmdLine\bin\sacmd.bat
– In the Command Parameters field, type
varset –n master1_joba –v “normal”
– In the Agent Name field, type
Step 3 On Master2 , create a string variable called master1_joba and create a variable action to initialize it to blank whenever JobB is added to the schedule.
Step 4 On Master1 , associate the job created in step 2 with a job action, and associate that action with a job event triggered by JobA completing normally. To make it easier to work with multiple jobs, create one linking job as in step 2 and override the command parameters here.
Step 5 On Master2 , add a variable dependency to JobB so that JobB depends on master1_joba = “normal” .
When JobA completes normally, it triggers the linking job that sets the master1_joba variable value on the other master to satisfy JobB's dependency.
The actions and events used in this scenario can be defined generically for reuse in working with any number of jobs that have inter-master dependencies. The TES API can also be used to set TES variables on any master programmatically. For more information on the TES API, see the TES API Guide.
The Job Dependency Definition dialog displays when you add or edit a job dependency from the Dependencies tab of the Job or Job Group Definition dialogs.
Note For instructions on how to implement inter-master dependencies, see Intermaster Dependencies.
This dialog contains the following elements:
If you choose more than one job or job group, dependencies will be created for each one selected, and when you click OK , they appear on the Dependencies tab. You can then update individual job dependency criteria by double-clicking them from the Dependencies tab.
Note You cannot type a job or job group name in this field directly.
– Select First Occurrence when the first instance of the job should be used to satisfy the dependency.
– Select Last Occurrence when the last instance of the job should be used to satisfy the dependency.If the job does not repeat, the last instance of the job dependency is used. If the dependent job has more repeating instances, the last instance of the job dependency is used to satisfy the dependency for the trailing instances of the dependent job.
– Select Match Occurrence when both jobs (predecessor and successor) repeat within a day, and the instance of the job dependency should match the instance of the job that depends on it.
When set from the Last Occurrence setting, the dependency is met using the Last Occurrence – offset job instance. For example, if a job is repeated 10 times, and the offset is 1, then the dependency is met using the ninth instance.
Note The Offset option does not apply to Match Occurrence.
Note With repeating groups, this option should be selected most of the time.
The File Dependency Definition dialog displays when adding or editing a file dependency from the Dependencies tab of the Job or Job Group Definition dialogs.
This dialog contains the following elements:
Note If the job being defined uses an agent list, then the Inherit Agent from Job option is automatically selected and the agent list name displays in the Agent Name field.
If the job uses an agent list instead of a specified agent, the dependent file uses the first agent in the agent list unless the agent list is the broadcast type. (The order of the agents on the selected list is determined by the sequence they were added to the agent list.) If the agent list is a broadcast type, then the dependent file uses the same agent the job runs on.
The question mark (?) and the asterisk (*) are supported as wildcards in the filenames of file dependencies.
Note that if the Has Not Changed For or Stable For option is selected with a wildcard file dependency, a large match set may result, delaying the check for file dependencies for other jobs.
What are the benefits of using wildcards in file dependencies?
There are programs, applications, scripts and batch files that need to depend on the existence of a file. In some situations, the exact name of the file that the program depends is unknown. The filename may include a date or time stamp, or a sequence number may be appended to the filename at the time of creation of the file. For example, an order file might be named ORD<sequence_number>.RDY .
The wildcard enhancement makes it quick, easy and efficient to set up and manage file dependencies where the filename is not constant.
How are the wildcards structured?
Usage of wildcards in TES is consistent with the standard wildcard practice. A combination of the question mark ( ? ) and asterisk ( * ) can be used. For example, a file dependency can be set on any files meeting the following wildcard criteria, L??d?n*.dat. The file, London101.dat, would make this dependency true.
Can you use wildcards in the path as well as in the filename?
No. The path to the file must be known. The wildcard functionality does not support wildcards in the path to a file.
You should enter file dependencies in UNC format:
\\servername\directoryname\filename
\\bpssch2\bpapps\files\ord????.dat
as well as in the format of a mapped drive if on the same machine:
driveletter:\directoryname\filename
This gives you the flexibility to detect the existence of files on any shared server in the domain.
What is the logic applied in fulfillment of wildcard file dependencies?
Once a file arrives whose name qualifies based on the wildcards, the dependency is marked true and the job with the dependency is released. Wildcards are cleanly implemented with the Exists and Does Not Exist options as well as TES’s advanced file dependency features.
What if more than one file fulfills the dependency?
Multiple files may qualify for a wildcard file dependency. For example, the query ORD*.RDY may result in three files: ORD100.RDY , ORD105.RDY and ORD200.RDY . A dependency could be set on files that have changed in the last 30 minutes. ORD105.RDY might have changed in the last 30 minutes while the other two files did not. In this type of situation, if one file meets the condition, then the dependency has been met.
What happens when dependencies cross day boundaries?
A job can be scheduled to run daily depending on a file. You can use a wildcard in the file dependency to look for the file. For example, the job may need ORD9T.RDY on Tuesday and ORD10W.RDY on Wednesday. You can define this job to have a dependency on file ORD*.RDY. ORD*.RDY matches both ORD9T.RDY and ORD10W.RDY .
What if ORD9T.RDY arrives late, after the end of the day?
If Tuesday's job is set to carry over to the next day, both Tuesday’s and Wednesday's jobs will be looking for the existence of a file that matches ORD*.RDY . If ORD019.RDY arrives before ORD024.RDY , both jobs will launch on its arrival. To avoid this, you can set the job to reschedule itself when another file is found.
Can you have a dependency on a file that exists on a non-agent machine?
Yes. You are not limited to files on servers with active TES agents. If the agent machine can see and connect to another machine (the machine has a share), it can determine if a file exists on it.
Can we use the wildcard characters as literal characters?
No. TES will interpret the ? and * characters as wildcards.
Are wildcard file dependencies supported on all platforms?
No, currently this enhancement applies to Microsoft Windows and Unix systems only.
Are the wildcards supported from the TES command line and API?
Yes. The wildcard functionality is the same for the Tidal Web client, command line and the TES API. The ? and * characters can be typed at the command line or API and will be treated as wildcards.
The Variable Dependency Definition dialog displays when adding or editing a variable dependency from the Dependencies tab of the Job or Job Group Definition dialogs.
This dialog contains the following elements:
– Greater than or equal to (>=)
When text strings are used in comparison, higher letters of the alphabet are greater than lower letters. For example, A < Z . If the first letters of the string match, succeeding letters are used for comparison. For example, AA < AZ . The operation works similar to sorting strings.
The z/OS JES Dependency Definition dialog displays when adding or editing a z/OS JES dependency from the Dependencies tab of a job’s definition.
This dialog contains the following elements:
Since the TES job you select could run multiple times during the day, you must specify which job occurrence you are interested in.
Select this option if the dependency is critical to a specific instance of the job and there is any uncertainty about the exact instance number. The dependency cannot be met during the day if the z/OS job instance number is questionable.
In the Dependency Condition field, you specify the condition of the TES job or one of the job steps that comprise the job that will signal that the dependency is satisfied. The condition is based on the state or status of the TES job or job step. A variety of conditions can denote a satisfied dependency.
You can add a job or group rule and have it added to the production schedule simultaneously. Adding a job to the production schedule is optional. When jobs are added to groups, many properties can be inherited from the parent group.
Step 1 From the Navigator pane, select Definitions>Jobs to display the Jobs pane.
a. To add a job or job group under a job group, right-click the job group under which you want to add your job or job group.
b. To add a job or job group at the root level of the hierarchy, right-click a root-level job or on a white section of the pane.
Step 2 Select Add Job or Add Job Group from the context menu or click the Add Job o n the TES toolbar.
Step 3 Depending on your selection, the Job Definition or the Job Group Definition dialog appears. For more information on the definition dialogs, see “Jobs Pane Interface” section .
Jobs with associated calendars are automatically added to the production schedule through the TES automatic compilation process. Jobs with calendars are only added to the schedule for days that are in the set of days defined for the calendar. No intervention is necessary, but you can customize its operation to tailor compilation to your needs. For more information, see “Defining Jobs” section ). Another way of automatically adding jobs to the production schedule is through new job actions. For more information about new job actions, see Actions and Alerts .
Step 1 From the Navigator pane, select Definitions>Jobs to display the Jobs pane.
Step 2 Right-click the job or job group to add to the production schedule and select Insert Into Schedule from the context menu.
Or, select the job or job group to add to the production schedule, and from the Activities main menu select Insert Into Schedule .
The Insert Job Into Schedule dialog displays. The Job/Group field should contain the name of the job or group you right-clicked, and the Date field should contain the current date. If the job or group you selected has a time window, this will be displayed in the From and Until fields. Any parameters that were set in the job’s or group’s definition will be listed in the Parameters field. If the job or group has dependencies, you may want to select the Override job’s dependencies option so that your job or group will enter the schedule without checking for its dependencies.
Step 3 Click Yes at the confirmation dialog.
The job is added to today’s production schedule regardless of its calendar dates (if any). If the job is defined to repeat, only one instance of the job will be added to the schedule. Only jobs with the Unscheduled Allowed option selected (definition dialog, Options tab) can be added in this manner.
Jobs can depend on the status of other jobs and job groups. For example, you can set Job B to run when Job A completes normally using a job dependency for Job B .
To add a job or job group dependency:
Step 1 From the Navigator pane, select Definitions>Jobs to display the Jobs pane.
Step 2 Double-click the job or job group that you want to edit.
Step 3 Click the Dependencies tab.
Step 4 Click Add and select Add Job Dependency from the drop-down menu.
Step 5 In the Job/Group field, click the Browse button to open the Search dialog to search for the job that this job will depend on. You can also view a drop-down list of jobs by clicking the down-arrow button. If you used the Browse button to narrow your search for jobs, the drop-down list will be that job subset.
Step 6 In the Operator field, select whether the file dependency Equals or Does not equal the following status to satisfy the dependency. For example, you can set the job dependency to Equal the Completed Normally status.
Step 7 In the Status field, select the status to use to satisfy the dependency. You can choose between Active , Completed Abnormally , Completed Normally , Error Occurred , Externally Defined and Completed.
Note A job group becomes active when any of its associated jobs become active. If all jobs in a job group depend on the job group becoming active, no jobs will launch.
Step 8 If the job repeats during the day, select which instance of the job will trigger the dependency from the Occurrence drop-down menu.
a. Select First Occurrence if you want the first instance of the preceding job to match the status criterion.
b. Select Last Occurrence if you want the last instance of the preceding job to match the status criterion.
c. Select Match Occurrence when both jobs repeat during the day, and the dependency should match instance numbers.
There are two ways to apply the First/Last/Match dependency logic: by day instance or group instance.
Step 9 To specify an instance offset, you can do so in the Offset field. This field only applies to First Occurrence and Last Occurrence . When applied to First Occurrence , specifies which instance after the first to use in satisfying the dependency. When applied to Last Occurrence , specifies which instance from the last.
Step 10 If you want to specify an instance of a job that occurred a certain number of days in the past, go to the Date Offset field, and type the number of days in the past for the required job dependency. For example, if Job A repeats daily, but you want your job to be dependent on Job A’s instance 3 days ago, specify 3 in this field.
Step 11 Select Ignore this dependency if Job not in schedule if the dependency only applies when the job is part of the production schedule.
Step 12 Click OK to add the job dependency.
Note If your job has more than one dependency (file, job, variable or time), all dependencies must be satisfied for the job to run. It is possible for a dependency’s state to change from satisfied to unsatisfied. If this occurs, the job will only run when all dependencies have been satisfied at the same time.
You can have a job that depends on the status of a file on any system in your network. For example, Job A can be defined to run only when file data.txt exists in the c:\data directory.
To add a file dependency to a job:
Step 1 From the Navigator pane, select Definitions>Jobs to display the Jobs pane.
Step 2 Double-click the job or job group that you want to edit to display the Job or Job Group Definition dialog.
Step 3 Click the Dependencies tab.
Step 4 Click Add and select Add File Dependency from the dependency context menu to display the File Dependency Definition dialog.
Step 5 Type the path and filename for the required file or click the Browse button to select a file on the local Tidal Web client.
Click the Variables button to add System or Job variables as a file name.
Step 6 Select the agent where the file needs to exist.
Step 7 Select the dependency type for the file from the following options:
– Exists – The file exists at the path and on the agent specified.
– Does Not Exist – The file no longer exists, or is not found at the path or on the agent specified.
– Has Changed In DD:HH:MM – The file dependency is satisfied when the file changed within the specified time in days, hours, and minutes after the job entered the production schedule. For example, if the job entered the schedule at 1:00 PM, the period specified is 6 hours, and the file changed after 7:00 PM (or later), the dependency is met.
– Stable For DD:HH:MM – The file dependency is satisfied when the file size has not changed for the specified time in days, hours, and minutes from the present time. For example, if the file’s modified time is 1:00 PM, the period specified is 6 hours, and the job enters the schedule at 3:00 PM, the dependency is satisfied in 4 hours, i.e., 7:00 PM.
– Size >= – The size of the file is greater than or equal to the specified amount in bytes.
– Size <= – The size of the file is less than or equal to the specified amount in bytes.
Note If your job has more than one dependency (file, job, variable or time), all dependencies must be satisfied for the job to run. It is possible for a dependency’s state to change from satisfied to unsatisfied. If this occurs, the job will only run when all dependencies have been satisfied at the same time.
You can make a job depend on the value of a user-defined variable. For example, Job A should only run when the variable RunVar is equal to ten. For more information on variables, see Variables .
To add a variable dependency to a job:
Step 1 From the Navigator pane, select Definitions>Jobs to display the Jobs pane.
Step 2 Double-click the job or job group that you want to edit.
Step 3 Click the Dependencies tab from the Job Definition dialog.
Step 4 Click Add and select Add Variable Dependency from the drop-down menu to display the Variable Dependency Definition dialog.
Step 5 If you are creating an intermaster dependency, select from the Master drop-down list a master to manage the variable dependency. Leave the default field selection, if you are not creating an intermaster dependency.
Step 6 In the Variable Name field, choose a variable from the drop-down menu that the job or job group will depend on.
Step 7 In the Operator field, select from the drop-down list an operator to make the appropriate comparison to the value of the variable.
Step 8 When text strings are used in comparison, “lower” letters of the alphabet are of greater value than “higher” letters. For example, Z > A. If the first letters of the string match, succeeding letters are used for comparison. For example, AZ > AA. The operation works similar to sorting strings in ascending order. Upper versus lower case is not considered (i.e., a=A, b=B, etc.).
Step 9 In the Variable Value field, enter the value of the variable required for the dependency to be met. You can also select from a list of system , job , user-defined and public variables to which the variable should be compared. For example, suppose you are using a variable dependency to repeat a job a specific number of times, and this amount changes periodically. You can define how many times to repeat the job by changing its variable value instead of changing its job definition.
You can specify command parameters that are appended to the command when the command is run. Consult the author of the script or program or refer to documentation about the command you are running for specific information on the type of command parameters you can pass to it.
You can enter fixed parameters, or you can use system, job, public, and user variables using the Variables button. At runtime, the current variable values will be used.
Note Command parameters must be added to a job definition through the Command Parameters field on the of the Job Definition dialog. TES will not recognize any parameters appended to a command in the Command field. For more information about the Command Parameters field or the Command field, see Program Tab.
To add a parameter to a command:
Step 1 From the Navigator pane, select Definitions>Jobs to display the Jobs pane.
Step 2 Double-click the job you want to edit to open its Job Definition dialog.
Step 4 In the Command Parameters field, type the parameter text as it should appear in the command.
For every job or job group that you create, you can add notes on the Notes tab to describe the job or group. You can also add instructions intended for the operator during the execution of the job on the Runbook tab. This information has no direct effect on how the job or job group runs, but is for informational purposes only. The notes or instructions can be written text or can be a web page of information displayed from the internet or a company intranet.
To add a note or operator instruction to a job:
Step 1 From the Navigator pane, select Definitions>Jobs to display the Jobs pane.
Step 2 Double-click the job or job group that you want to edit.
Step 3 Click either the Runbook or the Notes tab.
a. To add text, type the information in the text field. The text can contain up to 255 characters.
b. To display a web page from the internet or a company intranet with information relevant to the job, type a web URL in the text field and select the Load URL option.
You can select an agent or an agent list to run your jobs but be sure to choose an agent or an agent list for a platform on which your command or batch file can run.
To assign an agent or agent list to a job:
Step 1 From the Navigator pane, select Definitions>Jobs to display the Jobs pane.
Step 2 Double-click the job or job group you want to edit to open its definition. Selecting an agent or agent list for a group results in assignment of the agent to the children that inherit this property.
Step 4 The default agent is the agent specified in the System Configuration dialog, Defaults tab. To change this agent, select either:
a. An agent from the Agent Name drop-down menu to run your job on a specific agent.
b. An agent list from the Agent List Name drop-down menu to run your job on one or more agents in the agent list, depending on the type of list. Note that agent lists allow you to do workload balancing, broadcasting, and dynamic rerouting.
Note If you select an agent list, make sure that the user has logon access to each agent in the agent list. If the job tries to run on an agent that the user cannot access the job will fail with an Error Occurred status.
You can assign predefined job events to jobs to notify the operator or take actions based on exception conditions. You can issue email, console alerts, SNMP traps, ITO messages, job control commands, or even run a new job through the job event’s associated actions.
To assign a job event to a job:
Step 1 From the Navigator pane, select Definitions>Jobs to display the Jobs pane.
Step 2 Double-click the job or job group that you want to edit.
Step 3 Click the Job Events tab.
Step 4 Click Insert and the Select Job Event dialog appears.
Step 5 Select the job event(s).
Step 6 Click OK to add the job event to the job or job group definition.
To create a job or job group that has many of the same properties as an existing job or job group, you can save time by copying the job or job group first, and then editing its properties.
Note Copying a job group will copy all the jobs and job groups belonging to that job group.
Step 1 From the Navigator pane, select Definitions>Jobs to display the Jobs pane.
Step 2 Right-click the job or job group to copy and select Copy Job/Group from the context menu.
Step 3 A copy of the definition of the job or job group you selected will appear. The properties will be the same except for the name, which will be prefaced with “Copy of” . Note that you should give each copy a new name.
To allow all users access to a job or job group, make the Owner field a public workgroup. A public workgroup is a workgroup that contains all TES users.
Step 1 Create a TES workgroup and add all users:
a. From the Navigator pane, select Administration>Workgroups to display the Workgroups pane.
b. Click the Add button on the TES toolbar to display the Workgroup Definition dialog.
c. In the Workgroup Name field, type Public (or whatever name you choose to use).
d. Click the Members tab and select all TES users to join the workgroup.
Step 2 To add a job or job group to the public workgroup:
a. From the Navigator pane, select Definitions>Jobs to display the Jobs pane.
b. Double-click the job or job group that you want to edit.
c. In the Owner field, select the public workgroup from the drop-down menu.
Job and job groups owned by the public workgroup will be available to all users of TES.
Note The members of the public workgroup should be kept updated as TES users are added or deleted.
Step 1 From the Navigator pane, select Definitions>Jobs to display the Jobs pane.
Note If you delete a job group, all child jobs and job groups that are under that job group are also deleted.
Step 2 Select the job or job group to delete and click the Delete button on the TES toolbar. You could also right-click the job or job group and select Delete Job/Group from the context men or select the job or job group to delete and press the Delete key on your keyboard.
To select multiple jobs or job groups, hold down either the Shift or the Ctrl key on your keyboard while you click your selections.
Step 3 Click Yes in the Confirmation dialog to delete the job or job group.
Step 1 From the Navigator pane, select Definitions>Jobs to display the Jobs pane.
Step 2 Double-click the job or job group that you want to edit.
Step 3 Click the Dependencies tab.
Step 4 Select the dependency and click Delete .
If you click the Delete button without selecting a dependency, then the last listed dependency is deleted.
Note Deleting a dependency from a job or job group definition does not delete the actual job, file or variable the dependency refers to. It only removes that dependency from the definition you are editing.
To delete a job event from a job:
Step 1 From the Navigator pane, select Definitions>Jobs to display the Jobs pane.
Step 2 Double-click the job or job group that you want to edit.
Step 3 Click the Job Events tab.
Step 4 Select the job event to remove.
Step 5 Click Delete . The job event is removed from the job or job group definition.
To determine the result from the exit code automatically:
Step 1 From the Navigator pane, select Definitions>Jobs to display the Jobs pane.
Step 2 Double-click the job you want to edit.
Step 4 In the Tracking section, select the Exit Code option.
The Job Activity pane displays the job’s completion status based on the job’s exit code.
To determine the completion status manually:
Step 1 From the Navigator pane, select Definitions>Jobs to display the Jobs pane.
Step 2 Double-click the job you want to edit.
Step 4 In the Tracking section, select the External option.
The Job Activity pane displays the job’s completion status as Externally Defined . Note that you will need to set the job’s status manually using the set status option, or the TES command line program jobset . For more information about jobset , see the TES Command Line Reference Guide.
To disable automatic job insertion:
Step 1 From the Navigator pane, select Definitions>Jobs to display the Jobs pane.
Step 2 Right-click the job and select Disable from the context menu or double-click the job that you want to edit, and remove its calendar or clear the Enabled option.
If the job is already in the schedule, but has not run yet, the job will be removed. If the job had dependents, the dependencies on the job are released. Jobs that are active or are completed cannot be removed in this fashion, and can only be removed using the normal purging process.
To edit a job event assigned to a job:
Step 1 From the Navigator pane, select Definitions>Jobs to display the Jobs pane.
Step 2 Double-click the job or job group that you want to edit.
Step 3 Click the Job Events tab.
Step 4 Double-click the job event that you want to edit .
Note When you edit a job event definition, all jobs that have been assigned to the job event are affected by the change.
You can edit any existing dependencies associated with jobs or job groups. Editing dependencies is similar to adding dependencies.
Step 1 From the Navigator pane, select Definitions>Jobs to display the Jobs pane.
Step 2 Double-click the job or job group that you want to edit.
Step 3 Click the Dependencies tab.
Step 4 Select the dependency and click Edit .
a. If you selected a job dependency, the Job Dependency Definition dialog appears.
b. If you selected a file dependency, the File Dependency Definition dialog appears.
c. If you selected a variable dependency, the Variable Dependency Definition dialog appears.
Step 5 Edit the values of the selected Dependency Definition dialog as described previously.
Step 6 Click OK to save the changes.
You can control how your job runs if a previous instance of it is already running. You can skip the job, defer it until after the other instance completes, or run it anyway.
Note The concurrency setting does not apply to job groups.
To manage simultaneous occurrences of the same job:
Step 1 From the Navigator pane, select Definitions>Jobs to display the Jobs pane.
Step 2 Double-click the job you want to edit.
Step 4 In the If Job is currently running section, select one of the following:
a. Run anyway – If a previous instance of the same job is already running, the job tries to launch and run it anyway. You may have two or more instances of the same job running at the same time.
b. Skip – If a previous instance of the same job is already running, the job is assigned the Skipped status and will not run.
c. Defer until Normal – If a previous instance of the same job is already running, the job is assigned the Deferred status until the previous instance completes with a Completed Normally status, at which time TES launches the job. The job will not run if the previous job instance does not complete normally.
d. Defer until Complete – If a previous instance of the same job is already running, the job is assigned a Deferred status until the previous instance completes, at which time TES launches the job.
You can override one or more dependencies when running a job instance. This is useful if you need to modify the parameters of a job for just one instance. Instead of creating a new job, you can select a job that closely matches the job required and override the dependencies until the job meets your requirements. The overridden job dependency only applies to that particular job instance. The job returns to its original dependencies after the modified job instance runs.
Step 1 From the Navigator pane, select Definitions>Jobs to display the Jobs pane.
Step 2 Double-click the job or job group that you want to edit.
Step 3 Click the Dependencies tab.
Step 4 Select each dependency you wish to override and right-click to display the context menu. There is only one context menu selection called Override .
As an alternative, you can use the shortcut, Ctl+O , to override the dependencies you selected.
You can prevent a job from being added manually into the production schedule.
To prevent a job from being submitted manually:
Step 1 From the Navigator pane, select Definitions>Jobs to display the Jobs pane.
Step 2 Double-click the job you want to edit.
Step 4 Clear the Unscheduled Allowed option.
There are several ways to remove a job and job group instances from the production schedule:
The Create Schedule option recreates the existing production schedule for the date(s) specified and creates new instances based on qualifying jobs. All jobs that were added manually are removed as well.
Each job and job group has a retention period, after which its job instances are automatically purged from history. The default retention period is set on the Defaults tab of the System Configuration dialog, but individual jobs can customize their retention period on the Options tab of the Job Definition dialog.
If the job (or job group) has a pre-launch status, disabling the job removes the job from the schedule. Job instances that are active or have completed already are not removed. If any jobs depend on the removed job, that dependency is no longer required.
If the job (or job group) has a pre-launch status, selecting Remove Job(s) from Schedule will remove the job from the schedule. You are prompted for whether you want to release the dependency from dependent jobs or job groups.
Select the job or job group, then click the Delete button on the TES toolbar or the Delete key on your keyboard. When the job or job group definition is deleted, all instances (past, present and future) of the job or job group are removed from the production schedule.
You can set a job so that an operator must release it before it runs. All dependencies must be satisfied before the job is made available for release. Before releasing the job, the operator can view instructions regarding it.
To set a job so that an operator must release it before it runs:
Step 1 From the Navigator pane, select Definitions>Jobs to display the Jobs pane.
Step 2 Double-click the job you want to edit.
Step 4 Select the Require operator release option.
Step 5 Click the Notes tab. Type any information and instructions the operator might need to see before releasing the job.
You can run a job using a specific user logon account by selecting the Runtime User in the Job or Job Group Definition dialog. When you specify a Runtime User , you must be authorized to do so. Your job has access to that user’s environment on the agent. This may be required for your job to run successfully.
To run a job for another user:
Step 1 From the Navigator pane, select Definitions>Jobs to display the Jobs pane.
Step 2 Double-click the job or job group you want to edit.
Step 4 In the Agent Information section, select the user name from the Runtime User drop-down menu. If the user name you need doesn’t appear, it must be added to your list of Runtime Users . For more information, see Users ..
Note If you select an agent list and a runtime user, make sure that the runtime user has logon access to each agent in the agent list. Otherwise, the job might fail with an Error Occurred status.
You also need to select the Use Passwords to Run Windows Jobs option on the Master tab of the System Configuratio n dialog. For more information, see System Configuration .
To schedule a job according to a calendar:
Step 1 From the Navigator pane, select Definitions>Jobs to display the Jobs pane.
Step 2 Double-click the job or job group you want to edit.
Step 3 Click the Schedule tab.
Step 4 If the job or job group has a parent job group:
a. To use a calendar other than the parent’s calendar, clear the Inherited option in the Calendar section.
b. From the Calendar Name drop-down menu, select the Calendar for the job.
c. To use the calendar assigned to the parent job group, select the Inherited option in the Calendar section.
Note A child job must use a calendar that is a subset of the parent job’s calendar. Any job assigned a run date that is outside of the date range of the parent job’s calendar cannot be scheduled.
Step 5 You can view the specific dates of the selected calendar by clicking the Forecast button.
Step 6 If you want to offset the dates specified in the calendar, you can type the offset in days next to the Calendar drop-down menu. For 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 from every date in the Fiscal Month End calendar.
Step 7 To specify the date pane during which the job should run, type dates in the from and to fields. You can leave either field blank. If you leave the from field blank, the Calendar takes effect immediately. When you leave the to field blank, the Calendar is effective indefinitely.
Step 8 You can use the built-in calendar context dialog to help you select dates. To use the calendar function, click the down-arrow button next to the from and to fields.
For more information about TES Calendars, see Controlling Production .
You can repeat your job or job group as many times as you like within the day that it is scheduled.
To schedule a job to repeat within a day:
Step 1 From the Navigator pane, select Definitions>Jobs to display the Jobs pane.
Step 2 Double-click the job or job group you want to edit.
Step 3 Click the Schedule tab.
Step 4 In the Repeats section, there are three options to choose from:
– 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 – Runs a new occurrence of the job after the number of minutes specified in the minutes field passes. In the up to field, specify the number of times to repeat the job. If this field is left blank, the job repeats until the end of the time window or until the end of the day, whichever occurs first.
– Rerun same occurrence – Run the same job instance after the number of minutes specified in the Repeat every field elapses. In the up to field, select the number of times to repeat this job instance. If this field is left blank, the job repeats until the end of the time window or until the end of the day, whichever occurs first.
The following rules govern this function:
– The interval always begins at the start of the time window (12:00 AM if blank).
For example, if a job’s time window begins at 12:00 PM, and the job is defined to run every hour up to four times, the job will run 12:00 PM, 1:00PM, 2:00PM and 3:00PM. If the create schedule command occurs at 1:30PM, this job will run twice, once at 2:00 PM and once at 3:00 PM, unless you choose to start repeating the jobs ASAP within the Create Schedule dialog, in which case the job would run at 1:30, 2:30, 3:30 and 4:30.
– If you change the job definition while one of the repeat jobs is running, and the repeat count is changed, all job instances that have not run yet will be removed from the Production Schedule. The number of job instances added will equal the total number of instances specified minus the number of job instances that have already run.
For example, if you define job A to run 4 times, and the 2nd instance has started, and then you change the definition so the repeat count is 5, the 2 jobs already launched will remain in the schedule, the 2 other jobs will be removed, and 3 jobs will be added to run in sequence after the 2nd instance finishes.
– When you manually insert a repeating job into the schedule (via the Insert Into Schedule menu item), only one instance of the job will run as soon as possible after insertion.
– If the job is manually added to the schedule (via the Insert Into Schedule menu item), and other jobs depend on the last instance of this job, the dependency will then reflect the added job.
– You can create a perpetual job by using the Rerun same occurrence, Repeat every... minutes up to... times option. The same job instance will be rerun after each interval, rather than a new instance of the job being run. Only one instance of the job will be displayed in the Job Activity pane, but the instance number will increment every time the job is run. The History console pane will also show every instance of the job and every status changes. For more information about the History pane, see Diagnostic Messages .
You can specify a job’s priority in the Job Definition dialog. The job’s priority value is relative to other jobs in the same queue, and not with all other scheduled jobs. When TES looks for the next job to run, it searches first for the queue with the highest priority, and then for the job with the highest priority in the queue. For more information, see Queues Pane .
To set a job or job group’s priority:
Step 1 From the Navigator pane, select Definitions>Jobs to display the Jobs pane.
Step 2 Double-click the job you want to edit.
Step 4 In the J ob Priority field, enter the job priority, from 0 for lowest priority to 100 for highest priority.
You can specify the time window during which your job or group is allowed to run. For example, you can specify that your job will run after regular business hours, an ideal time to run processor-intensive commands because it frees up system resources during the day.
To specify a time window for a job:
Step 1 From the Navigator pane, select Definitions>Jobs to display the Jobs pane.
Step 2 Double-click the job or job group you want to edit.
Step 3 Click the Schedule tab.
Step 4 Use the arrow buttons on each field in the Time window section to type the time window, or type the time in each field. If the job or job group has a parent job group, clear the Inherited option in the T ime window section to use a different time window.
Note If you leave the To and From fields blank, TES assumes 12:00 AM. You can use the From field alone to have your job run at the time specified. The time format can be changed in the Windows Regional Settings Control Panel.
Step 5 Click the option that indicates what to do if the job cannot run within the time window specified.
– Do not timeout – Select this option if you want to carry the job forward to the next day if it fails to start by the end of the time window specified.
– Run again tomorrow – Select this option if the job has not run by the end of the time window specified, and you want to carry it forward to the next day. With this option selected, the job is eligible to run on each subsequent day, until it does run. You can set up a job action to notify you if your job does not run on the originally scheduled day.
Note Using job events, you can be notified if your job does not run within the time window or if the duration exceeds its time window. For more information on job events, see Actions and Alerts.
You can configure timezones where target application environments are based. This allows you to schedule a job or job group across multiple timezones. For example, if the Master associated with your job is based in the PST timezone and you want the job to run in an alternative timezone, you can set the time differences between the timezones and the amount of time to be added to selected timezone if it is in DST (Daylight Savings Time) period.
To specify a timezone for a job:
Step 1 From the Navigator pane, select Definitions>Jobs to display the Jobs pane.
Step 2 Double-click the job or job group you want to specify the timezone for.
Step 3 Click the Schedule tab.
Step 4 From the Timezone list, select the appropriate timezone you defined in the System Configuration dialog.
See also, Timezone Tab
Each TES job runs a single executable, such as files with .exe , .cmd , and .bat extensions. You can also specify run parameters.
To specify a command or batch file:
Step 1 From the Navigator pane, select Definitions>Jobs to display the Jobs pane.
Step 2 Double-click the job you want to edit to open its Job Definition .
Step 4 In the Command field, type the path to the executable file.
– To specify a file on a remote agent:
If your job runs on a remote agent, you must specify the command from the perspective of the agent. You can use the following naming convention to specify the file you want to run:
\\<computername>\<shared-directory-name>\<filename>.
For example, if you want to run a command named payrolldat.exe that is located on the computer named accounting , in the shared directory Payroll , specify the command as follows:
\\accounting\Payroll\payrolldat.exe
You can also use the Variables button to insert a user-defined path variable.
Note Remote Windows agents must run under a user account and not as a system account. More information is available in the installation prerequisites for the Windows agent in the Installation and Configuration Guide.
Step 5 In the Command Parameters section, type the parameters to be used in running the command file. Note that TES appends command parameters, in the order that they appear on this list, separated by a space.
Step 6 In the Environment File section, specify the file containing environment variables for your job. Note that this option only applies to jobs run on Unix agents. For more information about environment files, see “Environment Files” section .
You can determine how to set the completion status of a job in one of the following ways:
You can specify minimum, maximum, and estimated durations for a job. You can also create job events to notify you if the job’s duration exceeds the maximum value, or if the job completes before its minimum value. Once the job has run, the estimated duration value reflects the average duration value based on the number of times the job has run. For more information, see Actions and Alerts .
To specify duration for a job:
Step 1 From the Navigator pane, select Definitions>Jobs to display the Jobs pane.
Step 2 Double-click the job you want to edit.
Step 4 Go to the Duration (in minutes) section and type the values for the Estimated , Minimum , and Maximum run times.
Step 1 From the Navigator pane, select Definitions>Jobs to display the Jobs pane.
Step 2 Double-click the job you want to edit to open its Job Definition .
Step 4 While in the field and at the point where you want to insert a TES variable, click Variables . From the drop-down menu, select the variable you want to use.
To use an external program to determine completion status:
Step 1 From the Navigator pane, select Definitions>Jobs to display the Jobs pane.
Step 2 Double-click the job you want to edit.
Step 4 In the Tracking section, select the Exit code of cmd pipe option.
Step 5 In the Scan Output section, select the option for a particular text string in the output from a job to determine that a job completed normally or abnormally.
Step 6 Specify the external command in the adjacent field. The final results are determined by the success of that command, and the exit code from the command displays in the Job Activity pane. For more information refer to the Tracking Section (job only, does not apply to job group) .
For example, if you type Find Passed in the Exit code of cmd pipe field for an Windows job, the output is passed to the Find command. If the text Passed is found in the output, Find returns an exit code of 0, and the job’s completion status will be Completed Normally . If Passed is not found, Find returns 1, and the job’s completion status is Completed Abnormally .
To view the properties of a job or job group:
Step 1 From the Navigator pane, select Definitions>Jobs to display the Jobs pane.
Step 2 Double-click a job or job group to view the Job Definition or Job Group Definition dialog.
To view the history of a job or job group:
Step 1 From the Navigator pane, select Definitions>Jobs to display the Jobs pane.
Step 2 Double-click the job or job group to view to display the Job Definition or Job Group Definition dialog.
Step 3 Click the History tab. The job’s or job group’s history displays.
Note For jobs only, you can change the number of days of history to retain using the Retention (in days) field on the Options tab when the definition dialog is in Edit mode.