In addition to using the Job Scheduler GUI, developers can also write XML files to schedule and trigger jobs to run when triggered by specific events. These files are designated using the .sched and .trig extensions. and can be included as part of the job archive file (.job) or deployed separately.
Everything that you do manually in the Job Scheduler can be automated by creating a .sched or .trig XML script as part of a job. The XML files enable you to package system and job scheduling logic without using the GUI. This includes setting up cron triggers (for example, running a job at specified intervals) and other triggers that respond to built-in system events, such as resource startup, user startup (that is, login), or user-defined events that trigger on a rule.
For example, the osInfo discovery job, which probes a resource for its operating system information, is packaged with a schedule file, as shown in the Schedule File Examples. See also Section 8.2.2, Trigger File XML Examples.
This section includes the following information:
A schedule file (.sched) can be packaged either within a .job archive alongside the .jdl file or independently deployed using the zosadmin command line utility. Because the XML file defines the job schedule programatically outside of the Orchestrate Development Client, packaging these scripts into jobs is typically a developer task.
This section includes the following information:
The osinfo.sched file is packaged with the osInfo discovery job, which is deployed as part of the base server. Its purpose is to trigger a run of the osInfo job on a resource when the resource comes on line as it logs into the server.
The following shows the syntax of the schedule file that wraps the job:
1 <schedule name="osInfo" description="Discover OS info on resources." active="true"> 2 <runjob job="osInfo" user="zosSystem" priority="high" /> 3 <triggers> 4 <trigger name="RESOURCE_ONLINE" /> 5 </triggers> 6 </schedule>
Line 1: Defines a new schedule named osinfo, which is used to schedule a run of the job osInfo. If the job (in this case, osinfo) is not deployed, the deployment returns a “Job is not deployed” error.
Line 2: Instructs the schedule to run the named job (osinfo) by the named user (zosSystem) using a defined priority (high). If the user (in this case, zosSystem) does not exist, the deployment returns a “...” error.
NOTE:Only the PlateSpin Orchestrate users belonging to the administrator group can assign priorities higher than medium. Assigning a higher priority than specified by the user.priority.max fact defaults to a priority equal to user.priority.max when the job runs.
Line 3-5: Defines the triggers (in this case only one trigger, an event, RESOURCE_ONLINE) that initiates the job.
A schedule can include one or more triggers. The following example shows the syntax of a schedule file that has two cron triggers for scheduling a job:
1 <schedule name="ReportTwice" active="true"> 2 <runjob job="jobargs" user="JohnD" priority="medium" /> 3 <triggers> 4 <trigger name="DailyReportTrigger" /> 5 <trigger name="NightlyReportTrigger" /> 6 </triggers> 7 </schedule>
Line 1: Defines the schedule name, deployed condition, and description (if any).
Line 2: Instructs the schedule to run the named job (jobargs) by the named user (JohnD) using a defined priority (medium).
Lines 3-6: Defines the triggers (in this case two occurring time triggers) that initiate the job.
Trigger files define when a job and how often schedule fires. This can happen when a defined event occurs, when a defined amount of time passes, or when a given point in time is reached. so that one or more triggers can be associated with a job schedule (.sched). You can create these triggers yourself in XML format and deploy them, or you can edit and choose them in the Job Scheduler, which automatically deploys them. This section includes examples to show you the syntax of different trigger files.
An event trigger starts a job when a defined event occurs. Several built-in event triggers (such as events that occur when a managed object comes online or offline or has a health status change) are available in the Trigger chooser of the Job Scheduler along with any user-defined Events:
RESOURCE_ONLINE
RESOURCE_OFFLINE
USER_ONLINE
USER_OFFLINE
RESOURCE_HEALTH
USER_HEALTH
VMHOST_HEALTH
REPOSITORY_HEALTH
When deployed as triggers in a schedule, built-in events do not generate a .trig file, as other triggers do.
You can also associate an Event object with a job schedule (see Event Triggers
in The PlateSpin Orchestrate Job Scheduler
in the PlateSpin Orchestrate 2.0 Development Client Reference). You can define an Event object in an XML document, deploy it to a server, and then manage it with the PlateSpin Orchestrate Development Client.
The following example, PowerOutage.trig shows the XML format for a trigger that references an event object.
1 <trigger name="PowerOutage" description="Fires when UPS starts at power outage"> 2 <event value="UPS_interrupt"/> 3 </trigger>
Line 1: Defines the trigger name and description.
Line 2: Defines the event object chosen for the trigger.
For more information about events, see Section 7.14, Using an Event Notification in a Job.
The following example, EveryMin1Hr.trig shows the XML format for a trigger that uses the system clock to define (in seconds) how soon the schedule is to start, how often the schedule is to repeat, and how many times the schedule is to be repeated:
1 <trigger name="EveryMin1Hr" description="Fires every minute for one hour"> 2 <interval startin="600" interval="60" repeat="60"/> 3 </trigger>
Line 1: Defines the trigger name and description.
Lines 2-3: Defines how soon the schedule is to start, how often the schedule is to repeat, and how many times the schedule is to be repeated
The following example, NoonDaily.trig shows the XML format for a trigger that uses a Quartz Cron expression to precisely define when an event is to fire.
1 <trigger name="NoonDaily" description="Fires every day at noon"> 2 <cron value="0 0 12 * * ?"/> 3 </trigger>
Line 1: Defines the trigger name and description.
Lines 2-3:
Defines the cron expression to be used by the schedule. Cron expressions are used to precisely define the future point in time when the schedule is to fires. For more information, see Understanding Cron Syntax in the Job Scheduler
in The PlateSpin Orchestrate Job Scheduler
in the PlateSpin Orchestrate 2.0 Development Client Reference.