Job Hierarchy

Jobs are built on a hierarchy of job and job group ownership. A jobgroup 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.

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.

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.

Dependencies

Dependencies are prerequisite conditions that must be met before a job can run.

Date and Time Dependencies

The most common dependency is the date and time when Tidal Automation executes a job.

Example: You can schedule a job to run every Tuesday after 6:00 pm, except on holidays when it is not to run. Date dependencies are built using calendars. Time dependencies are specified within a job’s definition.

Job Dependencies

Jobs can also depend on other jobs reaching a particular status.

Example: You can run Job51 after Job101 and Job207 have reached the status of Completed Normally. During the job’s life cycle, Tidal Automation recognizes the current status of a job, such as:

Status	Description
Waiting on Dependencies	The job is waiting on Date, Time, Job, and File dependencies.
Waiting on Resource	The job is waiting for an execution slot. All Dependencies have been met.
Waiting on Operator	All the job’s dependencies are met and the job is waiting for the operator to release it.
Active	The job is actively running in the Production Schedule.
Completed Normally	The job completed normally.
Completed Abnormally	The job completed abnormally.
Error Occurred	An internal error occurred which prevented the job from running.

Note: This is a partial list of common job statuses. See the “Job and Job Group Statuses” in the Tidal Automation User Guide for a complete list with descriptions.

FileDependencies

A job can also depend on the status of a file. The state, size, creation or modification date of the file can all be taken into consideration.

You can run Job101 if the file C:\payroll\data\trandata:

Has been modified in the last twelve hours.
Has a file size greater than 1024KB.

VariableDependencies

A job can also depend on the value of a user-defined variable. Tidal Automation has a repository of user-defined variables that can be updated or incremented either manually or through an action associated with a job event or system event.

You can set a job to run when:

Variable Printer Online is set to Yes. The Printer Online variable could be set by a job that changes printer settings and then issues an action changing the variable from No to Yes.
Variable Payroll Jobs is incremented to 15 by another job that increments the variable each time it runs.

Calendars

Calendars are used to determine what days to run the jobs. Calendars let you schedule jobs to run on a periodic yet intelligent basis.

Example: Labor Day in the United States is celebrated on the first Monday in September which falls on a different date each year. By defining Labor Day as the first Monday in September, you avoid the need to manually redefine it every year.

You can also define calendar groups that combine individual calendars.

Example: The 1st Half Holidays calendar group can include the New Year’s Day, President’s Day, and Memorial Day calendars.

Job Instances

A job instance is a specific, scheduled run of a job definition (job) by Tidal Automation. One job can create many instances.

For example, if a job is defined to run every Monday, Wednesday and Friday, then Tidal Automation creates one instance for Monday, one for Wednesday, one for Friday, one for the next instance of Monday and so on. These instances can be viewed in the Job Activity pane.

Jobs can enter the production schedule on a scheduled or unscheduled basis. For example, you may have some jobs you expect to run at the end of each month, and other jobs that you run only on demand.

Production Schedule

The production schedule is the time line TA uses to manage instances. You control the span of time covered by the production schedule, typically between a few days and several weeks. Job instances are displayed in the Job Activity pane.

Past job instances remain available for a user-defined period of time.
Present job instances and their statuses (for example, Waiting, Active, Completed Normally, etc.) are displayed in the Job Activity pane default view.
Future job instances defined in the production span appear on the future dates in the Job Activity pane.

As time progresses, the production schedule is recorded, and automatically updates job instances for the defined number of days for the past, current and future runs. The concepts of time offsets and basing the production schedule times on agent time zones are explored in Understanding Offset Concepts.

Events and Actions

Tidal Automation monitors jobs throughout their life cycle for predefined events – such as when the job launches, when it completes, if it fails and many others. You configure an exception condition called an event to automatically respond when the event is detected by triggering an action.

When you configure an event, you specify:

System conditions that will trigger the event
One or more actions to take in response
Jobs to which the event applies (for job events)
A schedule of time intervals when the event is active (file, email and variable events)

Events can be internally generated by conditions within the system (job and system events) or they can be generated by conditions that are outside the system (file, email and variable events). To detect external conditions, you must create an event monitor to watch for those defined conditions.

Job events combine event triggers with actions such as stopping or restarting a job while in production.

Common eventtriggers include abnormal termination, excessive run time and failure to complete by a specific time.

You can take these actions:

Send email messages
Control a job instance in the Job Activity window
Alert an operator to a job condition
Send SNMP messages
Launch an unscheduled job (new job action)
Issue a log message
Update a user defined variable

Example: You can define a job event that is triggered every time a job is canceled by an operator. When a job cancellation occurs, you can have an email sent to you and a message sent to your SNMP management software noting this event.

A system event operates identically to a job event, except that the master originates the event rather than a job. System events define global conditions versus a job event defining conditions that affect jobs. For example, if an agent shuts down, a system event can be triggered to notify users of the problem.

An email event is the detection of a specified text string in an email that arrives at a designated email account on an designated Exchange server. An email monitor is created to watch for the specified email.

A file event is the detection of a file on an agent reaching a specified state. A file monitor is created to watch for a file the matches the specified conditions.

A variable event is the detection of a variable reaching a specified value, whether the variable is on a local or remote master. A variable monitor is created to watch for the variable to reach the desired value.

Queues

Queues let you optimize throughput and allocate system resources for scheduled and unscheduled jobs. The Tidal Automation queue manager assigns jobs to queues when all their dependencies have been met, and decides when to launch jobs based upon the available system resource slots. The maximum number of slots available is determined either by the limit that you set in the system queue, the sum of each queue’s limit, or the sum of each licensed agent’s job limit.

Queues can limit the number of jobs running on a computer or a network of computers at a given time.

If the system is not running at its capacity, a job can run immediately provided that all of its dependencies are met.

If the system is running at its capacity, the Tidal Automation Queue Manager decides which jobs launch based on a priority structure that includes these in order of importance:

Status	Description
Queue priority levels	Jobs in active and open queues at higher priority levels run first.
Queue limits	Only jobs in queues not running at their allowable limit can be launched.
Agent job limits	Only jobs assigned to agents not running at their allowable limit can be launched.
Job priority levels	Jobs with the highest priority (assigned in the job definition) in the queue are run first.

Queues are displayed in a hierarchy. Each item in the hierarchy is a queue and can contain jobs. You define the queue limit to set the number of jobs that can launch from any individual queue. You also define a priority for each queue.

Queue Filters

Jobs are directed to a queue based on the queue filters that you define. These filters describe the job properties that must exist for the queue manager to assign a job to a particular queue.

Some examples of the queue filters that direct jobs to queues are:

Job class
Job name
Job owner
Job estimated runtime

Agent Lists

Tidal Automation extends its capability for automatic job management through agent lists. An agent list describes a set of nodes on your network available to run jobs. Agent lists designate nodes as primary or alternate nodes for job submission, and allow jobs to be broadcast across all available nodes. Workload balancing algorithms can distribute jobs evenly among all available nodes.

Security Policies

Security policies restrict access to certain Tidal Automation functions. The defined access rights can be saved as a security policy, and then assigned to one user or multiple users.

There might be different sets of users who:

Administer Tidal Automation.
Create and schedule jobs for themselves and others.
Operate the job schedule.

Using security policies, the users that create and schedule jobs can be restricted from modifying the schedules. Likewise, the operators can be restricted from creating jobs.

Tidal Automation includes default security policy templates that can be modified to create your own security policies. Each user within the supplied working model has a defined set of Tidal Automation functions. When all the default security policies are in use, all aspects of scheduling are covered and available.

These table lists the system features available for each of the default security templates:

Default Security Policy	Available System Features
Scheduler_Administrator	The default for new installations. This includes all available functions.
Administrator	Configures users.
User	Creates, edits, and submits jobs. Creates workgroups and user-defined variables.
Scheduler	Edits and tests job schedules.
Operator	Runs and controls jobs. Responds to alerts that jobs may issue.
Inquiry	Views jobs and resources. Cannot perform modification.

Logs and Reports

Tidal Automation includes a logging mechanism that keeps track of all user edits, job status information, and error messages. In the Logs pane, you can view, filter and search all messages for a specific time frame.

Example: If you want to see who modified Job A recently, you can go to the Logs pane, search on Job A and view all instances when the job was edited.

Tidal Automation also supports numerous reports, such as:

Data displayed in every window
Operator alerts and responses
Job statuses
Event history
Dependency cross-references
Production schedule summary

Note: For troubleshooting issues deeper than those gathered in the operations logs, gather the logs located in the Log directory of the installation of each TA component (Master, Client Manager, Fault Monitor, and so on). The .out file is the output of the process, while the .log files are the logs generated.