8.2 Schedule Files

In addition to using the Job Scheduler GUI, developers can also write XML files to schedule jobs to run when triggered by specific events.These files are designated using the .sched extension and can be included as part of the job archive file.

Everything that you do manually in the Job Scheduler can be automated by creating a .sched XML script as part of a job. The XML file enables 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 system events, such as startup (login).

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 osInfo.sched Example. See also Section 8.2.2, Cron Trigger Example.

8.2.1 osInfo.sched Example

A schedule file can be packaged with a job in a .job file or independently deployed to a Orchestrator server. Because the XML file defines the job Schedule programatically outside of the Orchestrator console, packaging these scripts into jobs is typically a developer task.

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>
2     <job name="osinfo" job="osInfo" user="zosSystem" priority="high" >
3        <resourcediscovery/>
4        <active/>
5        <runonresourcestart/>
6        <runoneachresource/>
7    </job>
8 </schedule>

NOTE:The XML descriptor, which is written against the schedule DTD, is documented in Section C.0, Orchestrator Job Scheduling DTD.

Line 1: Starts the new schedule definition.

Line 2: 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. The user parameter identifies what user to run the osinfo job, while priority specifies a priorty at which to run the job.

Line 3: Instructs the schedule to run the job as a resource discovery job.

Line 4: Activates the job after it is deployed. The schedule default is not active.

Line 5: Runs osInfo job when the resource logs into the server.

Line 6: Specifies to run a single joblet on each resource.

8.2.2 Cron Trigger Example

The following example shows the syntax of a schedule file that has two cron triggers for scheduling a job:

1<schedule>
2    <trigger name="NightlyReportTrigger" description="CRON fire at 4 am every day">
       <cron value="0 0 4 * * ?" />
    </trigger>
3    <trigger name="DailyReportTrigger" description="CRON fire at 4 pm every day">
       <cron value="0 0 16 * * ?" />
    </trigger>
4    <job name="Report" job="ReportJob" user="manager">
5        <jobargs>
            <fact name="fullreport" type="Boolean" value="false" />
        </jobargs>
6       <active/>
7       <triggers value="NightlyReportTrigger" />
8       <triggers value="DailyReportTrigger" />
9    </job>
10 </schedule>

Line 1: Starts the new schedule definition..

Lines 2-3: Defines two new triggers to fire at 4 a.m. and 4 p.m. every day.

Line 4: Defines a new scheduled task named Report that is used to schedule a run of the job ReportJob.

Line 5: Specifies the job parameters for the scheduled job.

Line 6: Activates the job after it is deployed. The schedule default is not active.

Lines 7-8: Defines that the schedule uses the two specified triggers.

A schedule file can be packaged either within a .job archive alongside the .jdl file or independently deployed using the zosadmin command line utility.