schedule

The scheduler relies on two data repositories:

• A database of tasks available for scheduling
• A database of jobs, or scheduled tasks

A task must be defined in the task database before you can schedule it. The task database is a single text file, task_registry. You can add task definitions to the task database by editing this file using a text editor. You must not change the definitions of standard tasks, but you can add your own task definitions at the end of the file. For more information, see Task definition syntax.

Standard tasks reside in the directory tasks. These tasks are not editable. Tasks that you define can reside anywhere in the file system, but the recommended location is the directory tasks. This directory contains a task, ccase_local_day, that is intended for user-defined operations to be run daily. The directory contains another task, ccase_local_wk, that is intended for user-defined tasks to be run weekly. You can customize these two tasks using a text editor or can create entirely new tasks.

The database of jobs is the file db. This is a binary file that you read and edit by using the schedule command. When you use the schedule command to change the job database, you use the job definition language described in Job definition syntax.

VersionVault installs a template for an initial task database, which contains definitions for standard tasks, as the file task_registry. The albd_server uses this template to create the first version of the actual task database, task_registry.

Templates are installed for two customized tasks, ccase_local_day and ccase_local_wk, in the directory templates. The albd_server uses these templates to create initial versions of these tasks in the directory tasks.

VersionVault installs an initial set of job definitions as the text file initial_schedule. These job definitions rely on task definitions in the task registry template. The albd_server uses these job definitions to create the first version of the job database, db.

When no job database exists, the albd_server uses the initial set of job definitions in the file initial_schedule to create a default schedule. This schedule consists of some jobs that are run weekly and other jobs that are run daily. Weekly jobs are run by default. Daily jobs are not run by default: you must explicitly enable them.

Daily jobs:

• Scrub cleartext and derived object storage pools of all local VOBs, using scrubber.
• Copy the VOB database for all local VOBs that are configured for snapshots, using vob_snapshot.
• Copy the VersionVault registry from the primary registry server host (when run on a backup registry server host), using rgy_backup.
• Run user-defined daily operations in ccase_local_day.
• Generate and cache data on disk space used by all local views, using space.
• Generate and cache data on disk space used by all local VOBs, using space.

Weekly jobs:

• Scrub some logs (see the Help).
• Scrub the databases of all local VOBs, using vob_scrubber.
• Run user-defined weekly operations in ccase_local_wk.
• Generate and cache data on disk space used by derived objects in all local VOBs, using dospace.

You can arrange for a job to run under a variety of schedules:

• Run daily or every n days, starting at a specified time of day and possibly repeating at a specified time interval during the day.
• Run weekly or every n weeks, on one or more days of each week, starting at a specified time of day and possibly repeating at a specified time interval during the day.
• Run monthly or every n months, on a specified day of the month, starting at a specified time of day and possibly repeating at a specified time interval during the day.
• Run immediately after another job finishes.

For daily, weekly, and monthly schedules, you can specify starting and ending dates for the job. To run a job one time, you can specify a daily schedule with identical start and end dates.

The –edit and –set options create or modify jobs by using a declarative job definition language. The –get option displays a textual representation of currently defined jobs using the same language.

The job definition language has the following general features:

• Each statement must occupy a single line, though job descriptions and output messages can occupy more than one line.
• The language is case-insensitive.
• Leading white space, lines beginning with a number sign (#), and blank lines are ignored, except within job descriptions.
• The quotation character is double quote (").

A job definition file consists of a sequence of job definitions. Each job definition begins with the statement Job.Begin and ends with the statement Job.End. Between these statements are other statements that define job properties. A statement that defines a job property has the following form:

Some properties have fields. In this case the definition of a property consists of a sequence of statements, one for each field, with the following form:

Some fields themselves have subfields.

The value portion of some property definitions can contain a sequence of individual values separated by commas. No white space can appear before or after a comma that separates two values in a sequence. For the Args property, individual values are separated by white space.

Job properties are of two types:

• Editable. You can define or modify the property. Some properties and fields are required; others are optional and have default values. When you define or modify a property, you must specify fields and subfields of that property in the order listed in Table 1 and Table 2.
• Read-only. The scheduler defines the property, and you cannot define or modify it. When you create a job definition, the scheduler ignores all definitions of read-only properties. When you edit an existing job definition, the scheduler ignores all definitions of read-only properties except for Id. When you edit an existing job definition, the scheduler uses the Id, if present (and if not present, the Name), to identify the job to modify.

The following table lists editable job properties.

Table 2 lists fields of the Schedule property. Schedules are of two types:

• Periodic. The job runs on one or more days specified by the Monthly, Weekly, or Daily field.
• Sequential. The job runs following completion of another job specified by the Sequential field.

The Monthly, Weekly, Daily, and Sequential fields are mutually exclusive; each job must have one and only one of these fields.

The StartDate, LastDate, FirstStartTime, StartTimeRestartFrequency, and LastStartTime fields are optional. One or more of these fields can appear along with a Monthly, Weekly, or Daily field. StartDate and LastDate determine the first and last dates the job is eligible to run on its monthly, weekly, or daily schedule. FirstStartTime determines what time the job first runs on each day it is scheduled. StartTimeRestartFrequency specifies an interval to wait before running the job again. LastStartTime is meaningful only with StartTimeRestartFrequency; it determines the last time the job is eligible to run on each day it is scheduled. If StartTimeRestartFrequency is specified for a job, the job will run every StartTimeRestartFrequency (for example, every two hours) until midnight or LastStartTime, whichever is earlier.

All dates and times are local to the host on which the scheduler is running. Date outputs are displayed in ISO format regardless of any user-specified preference for the display format of dates.

Table 3 lists read-only job properties. For the LastCompletionInfo property, ExitStatus is the value returned by the wait() system call on UNIX® or Linux® or by the GetExitCodeProcess() function on Windows®. Only the first 511 bytes of standard output and error messages are displayed.

Following is an example definition the scheduler could display with the –get option for a job scheduled to run sequentially, including job properties defined by the scheduler:

A task must be defined in the task database before you can schedule the task. The task database is a text file, which you can edit using a text editor. The task database contains definitions that use a declarative task definition language similar to the job definition language.

The task definition language has the following general features:

• Each statement must occupy a single line.
• The language is case insensitive.
• Leading white space, lines beginning with a number sign (#), and blank lines are ignored.
• The quotation character is double quote (").

The task database file consists of a sequence of task definitions. Each task definition begins with the statement Task.Begin and ends with the statement Task.End. Between these statements are other statements that define task properties. A statement that defines a task property has the following form:

In the task database, definitions of standard tasks appear first. You must not change or delete any of these definitions. You can add task definitions of your own at the end of the task database file.

Table 4 lists task properties.

The scheduler uses the task Id property in a job definition to identify the task to run. If any scheduled jobs use a task Id, you must be careful not to change the task's Id property in the task database without also changing all references to that property in the database of scheduled jobs.

The optional UIInfo property describes the task's command-line interface, such as the types of arguments the task can take. This property is used internally by VersionVault; do not specify it for a user-defined task.

Following is an example read-only definition for a standard task:

Task.Begin
    Task.Id:       2
    Task.Name:     "View Space"
    Task.Pathname: view_space.sh
    Task.UIInfo:   "view-spec"
Task.End

Following is an example definition for a user-defined task:

Task.Begin
    Task.Id:       100
    Task.Name:     "Daily Local Tasks"
    Task.Pathname: ccase_local_day.sh
Task.End

Each task runs in a separate process started by the albd_server. A task has the following execution environment:

• The user identity of the task is the same as that of the albd_server (root on UNIX® or Linux®; for Windows®, look at the albd_server to see what user it is running as).
• The standard input stream is closed.
• Standard output and error messages are redirected to a file and captured by the scheduler as part of the job's LastCompletionInfo property.
• The current directory is undefined.
• Environment variables are those in effect for the albd_server. In addition, on Windows® systems, CLEARCASEHOME is set to versionvault-home-dir.

–hos/t hostname

Specifies the host whose schedule the command operates on. The default is the local host.

–f/orce

Suppresses all prompts to confirm changes. By default, the command asks for confirmation before changing a schedule or ACL.

–get [ –sch/edule ]

Displays currently scheduled jobs using the scheduler's job definition language. For more information, see Job definition syntax. This is the default action for the –get option.

–get –job job-id-or-name

Displays the currently scheduled job identified by job-id-or-name, which is either a number representing the job ID or a string representing the job name. The job display uses the scheduler's job definition language. For more information, see Job definition syntax.

–get –tas/ks

Displays the tasks defined in the task database using the scheduler's task definition language. For more information, see Task definition syntax.

–get –acl

Displays the scheduler's access control list (ACL) using the scheduler's ACL definition language. For more information, see Restrictions.

–edi/t [ –sch/edule ]

Opens in a text editor a schedule that contains definitions of currently scheduled jobs that use the scheduler's job definition language. You can use the editor to add, delete, or modify job definitions. When you are finished, save the modified schedule and quit the text editor. The scheduler then replaces the current schedule with the edited version. For more information, see Job definition syntax. This is the default action for the –edit option.

–edi/t –acl

Opens in a text editor a file that contains the current ACL entries that use the scheduler's ACL definition language. You can use the editor to add, delete, or modify ACL entries. When you are finished, save the modified ACL and quit the text editor. The scheduler then replaces the current ACL with the edited version. For more information, see Restrictions.

–set [ –sch/edule ] defn-file-pname

Replaces all currently scheduled jobs with the jobs defined in the file whose pathname is defn-file-pname. The definitions in the file use the scheduler's job definition language. For more information, see Job definition syntax. This is the default action for the –set option.

–set –acl defn-file-pname

Replaces the current ACL with the ACL defined in the file whose pathname is defn-file-pname. The definitions in the file use the scheduler's ACL definition language. For more information, see Restrictions.

–del/ete job-id-or-name

Deletes the scheduled job identified by job-id-or-name, which is either a number representing the job ID or a string representing the job name.

–run job-id-or-name

Immediately executes the scheduled job identified by job-id-or-name, which is either a number representing the job ID or a string representing the job name. Dependant jobs of job-id-or-name, if any, are not run. The job is run in the scheduler's job execution environment. For more information, see Job execution environment.

–wai/t job-id-or-name

Waits for completion and displays status of the scheduled job identifiedjob-id-or-name, which is either a number representing the job ID or a string representing the job name. This option has no effect if the job is not running.

–sta/tus job-id-or-name

Displays the status of the scheduled job identified by job-id-or-name, which is either a number representing the job ID or a string representing the job name. Displays the most recent process ID, start time, end time, and exit status for the job.