Working with Job Search Dialog

Accessing the Job Search Dialog

The Job Search dialog is accessed from various dialogs by clicking Browse. Use the Job Search dialog to set the criteria used to find jobs.

Common to All Tabs

Find – Click this to search through all jobs for jobs matching the search criteria.

All – Click this to display all jobs regardless of the search criteria.

Clear – Click this to clear all of the previous search criteria.

Job Search Results – Displays the jobs that match the search criteria.

Job Search Criteria Tab

This tab contains these elements:

Name – Search for a job by the name of the job.

Owner – Search for jobs owned by a particular user.

User – Search for jobs that run as a particular user.

Agent – Search for jobs that run on a particular agent.

Class – Search for jobs that belong to a particular job class.

Select at least one of the checkboxes in these categories. You may also select both checkboxes to search in them:

Group(s) – Search by job group.
Job(s) – Search by jobs.

Select at least one of the checkboxes in these categories. You may also select both checkboxes to search in them:

Enabled – Search for jobs that are enabled.

Disabled – Search for jobs that are disabled.

Advanced Criteria Tab

This tab contains these elements:

Command – Use this field to search for a job that uses a particular script or executable.

Agent List – Use this field to search by the list of agents that can run the job.

Parent group – Use this field to search for jobs that are children to a particular group.

Requires operator release – Choose this option to search for jobs requiring operator release.

Does not require operator release – Choose this option to search for jobs that do not require operator release.

Unscheduled allowed – Choose this option to search for jobs that can be inserted into a schedule on an ad hoc basis.

Unscheduled not allowed – Choose this option to search for jobs that can only be run on a scheduled basis.

InterMaster Dependencies

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 Details dialog. An interMaster variable will show a value of Unavailable if the connection to the remote Master is lost.

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.

Example: Master2:JobB depends on Master1:JobA

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.
On Master1 create a linking job that runs on the agent installed on Master2 (or one of its TA 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 these:

In the Command field, type
```
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
```
Master2
```

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.
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.
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 TA API can also be used to set TA variables on any Master programmatically.