Schedule Name

When you create a new schedule, the unique name you specify is displayed in this field. If you select a schedule from the Job Schedules Table, the name of the schedule is displayed in this field. The field is not editable, because schedules cannot be renamed after they are created. (You can use a copy if this is required.)

Job

When you create a new schedule, you need to associate a deployed job with it. You can select the job you want to run from this drop-down list.

If you want to use a previously created schedule to run a different job, you can change the job here.

User

When you create a new schedule, you need to associate a user with it. The user represents the user for whom the job will run. The choice of user might affect the permissions, privileges and constraints of the job. You can select the user from this drop-down list.

If you want a different user to run a job on a previously created schedule, you can change the user here.

If you decide to change the user who runs the job, check the Priority field to make sure that the priority you want is selected.

Priority

When you create a new schedule and associate a job and a user with it, a list of possible run priorities becomes available in this drop-down list. The list of priorities varies, depending on the user that is specified in the previous field. In this field, you select the priority of the job that is to be run so that if other jobs are to start concurrently or are competing for resources, the Orchestrator can determine which job takes priority.

Description

For predeployed jobs, this field contains a default description of what the job’s schedule does. The field is editable, so you can enter a description of your own for job schedules that you create.

Matching Resources

This button displays a list of resources where the job runs now or where it could run. This list is useful for checking the context of constraints that might have been affected by a choice of user or by manually specifying additional constraints under the Policy tab. The list is also useful to verify that a discovery job (that is, one that is triggered by the Run on Resource Start option) runs on the preferred set of machines.

Test Schedule Now

Click this button to test the new or modified schedule you are working with. The test runs the new or modified schedule without permanently saving the current configuration of the schedule or recording statistics. This control differs from the Run Now control in the Job Schedules Table, which runs a saved (persisted) schedule, disregarding any unsaved modifications that have been made to it in the Job Schedule Editor.

Job Arguments

This tab displays an area (in the lower left corner of the Job Schedule Editor) where possible job arguments are listed. If you select an existing schedule in the Job Schedules Table, any optional job arguments (jobargs) for the associated job are displayed in this area.

Figure 1-5 The Job Arguments Area of the Job Scheduler View

The jobargs are defined by the deployed job. Some jobs might already have a default value displayed, but others must have values specified in order for the job to be able to run.

A job argument defines the values that can be passed in when a job is invoked. These values let you statically define and control job behavior. To learn more about each job argument, mouse over each jobarg line to display tool tip text.

The Job Scheduler uses the values you enter into the fields of this area to build a jobargs namespace in the policy for this job.

Each job argument has an accompanying Lock check box. When Lock is not selected, the accompanying job argument uses the default value specified in the job’s policy. When Lock is selected, the value specified in the field is locked down and overrides the default value in the policy. A locked value continues to be used even if the policy value is modified.

You can click Restore Jobargs to restore job arguments to the values specified in the job policy. This function removes any changes you might have specified in the Job Scheduler and deselects all Lock check boxes.

For more information, see Job Arguments and Parameter Lists in the Novell ZENworks Orchestrator 1.2 Developer Guide and Reference.

User Environment

This tab displays an area (in the lower left corner of the Job Schedule Editor) that includes the Pass User Environment check box. Select this check box if you want to pass the assigned user’s environment variables to the job when it runs. When environment variables are recorded on the user account, selecting the Pass User Environment check box makes those environment variables available to the job and joblet.

A user’s environment is recorded under the user.env fact on his or her account. This fact can be set when a user logs in to the Orchestrator and is persisted until changed. A user’s environment variables can be uploaded with the zos command line tool at login time in one of two variations:

Constraints

This tab displays a constraint editor that you can use to create additional constraints for the job being scheduled. Typically, additional “resource constraints” (such as “start”) are useful to delay the start of a job when it is triggered.

Event Triggers

An event trigger is the signal to the Job Scheduler to initiate, or “fire” a job when a given event occurs. An event trigger can be used in conjunction with a time trigger to allow flexibility in scheduling the job application for maximum effectiveness or convenience.

The Job Scheduler has three possible event triggers: Run on Resource Start, Run on Server Start, and Run on Agent Version Mismatch. The first two triggers are self-explanatory. The third trigger, Run on Agent Version Mismatch, triggers the job when an Orchestrator Agent of an incompatible version attempts to connect to this Orchestrator Server. It is used to initiate a configuration management tool for an agent software update. Jobs triggered by Agent Version Mismatch must specify a job argument (jobarg) named “resource.id” as in the following example:

	<jobargs>
          <fact name="resource.id"
              type="String"
              description="The id of the mismatched resource"
              value=""
              visible="true" />
          <fact name="resource.ip"
              type="String"
              description="IP address of the mismatched resource"
              value=""
              visible="true" />
	</jobargs>

You can select any combination of these event triggers.

Time Triggers

A time trigger is the signal to the Job Scheduler to initiate, or “fire” a job at a given point (or points) in time. A time trigger can be used in conjunction with an event trigger to allow flexibility in scheduling the job application for maximum effectiveness or convenience.

When you click Triggers in the Job Scheduler view, the following dialog box opens:

Figure 1-6 The Time Trigger Dialog Box

In this dialog box, you can define the time triggers you want to associate with the launching of your jobs. You can create as many time triggers as you want to meet any scheduling situation you might have. Multiple time triggers can be associated with a given schedule and multiple schedules can use a given time trigger.

The time triggers you create are retained by the Job Scheduler for you to choose from when you create a schedule for a job. These are displayed in the list with the name and the description of the trigger.

The following controls and information are available in the dialog box:

Choose Triggers

Opens a dialog box where you can choose the predefined time triggers you want to associate with this job schedule.

Figure 1-7 Choose Triggers Dialog Box

In this dialog box, you can click Add to move a selected trigger to the active, scheduled time triggers that are to be associated with this job schedule. You can also click Remove to unassociate a trigger.

When a trigger is moved to the scheduled list, it becomes associated to the job schedule and it is displayed in the Job Scheduler view.