To control more precisely when and how your schedules run, you can specify values for schedule parameters instead of accepting the defaults when you define or update schedules.
You can specify a start time, such as 6 p.m. with the STARTTIME parameter.
You can also specify the day of the week on which the startup window begins with the DAYOFWEEK parameter. If the start date and start time fall on a day that does not correspond to your value for the day of the week, the start date and time are shifted forward in 24-hour increments until the day of the week is satisfied.
If you select a value for the day of the week other than ANY, then depending on the values for PERIOD and PERUNITS, schedules may not be processed when you expect. Use the QUERY EVENT command to project when schedules will be processed to ensure that you achieve the desired result.
Make the window duration long enough so that all client nodes scheduled for that window have a chance to start the operation. You may have to set the window to a longer period if the number of client nodes processing the schedule is greater than the number of available scheduled sessions.
If the schedule does not start during the startup window, the server records this as a missed event in the database. To identify any schedules that may have been missed, you can get an exception report from the server for events. For more information, see "Querying Event Records".
Restrictions: | Not all clients can run all scheduled operations, even though ADSM allows you to define the schedule on the server and associate it with the client. For example, a Windows 3.1 client cannot run a schedule when the action is to restore or retrieve files, issue a command, or run an executable script. A Macintosh client cannot run a schedule when the action is to restore or retrieve files, or run an executable script. |
For selective backup, archive, restore, and retrieve operations, you must specify the files to process. You can use wildcard characters to select multiple files. The file spaces and file names must follow the naming conventions of the client node. Therefore, you may need to define different schedules for different platforms.
If you are scheduling a command, you must specify the entire command.
If you are scheduling the running of an executable script, you must specify the executable script file name.
When applicable, these options override the options specified by a client node after it has successfully contacted the server.
Do not include the following options because they have no effect on the execution of the scheduled command:
To help you decide which client options and which file names or file spaces to specify when defining or updating a schedule, you can try them out during an unscheduled operation from the client node. For information about client options, refer to ADSM Using the Backup-Archive Client for the appropriate client.
You can define a new schedule for backing up or archiving client nodes in a specified policy domain. When you define a schedule, you assign it to a specific policy domain. You can define more than one schedule for each policy domain.
To define a schedule for incremental backups for clients in the ENGPOLDOM policy domain, enter:
define schedule engpoldom engweekly action=incremental period=1 perunits=weeks
This command sets the frequency for schedule ENGWEEKLY to one week. This frequency for scheduled incremental backups matches the backup copy group frequency of the management class in the STANDARD policy set of the ENGPOLDOM policy domain.
You can update an existing client schedule for backing up or archiving client nodes in a specified policy domain.
To update the ENGWEEKLY client schedule, enter:
update schedule engpoldom engweekly period=5 perunits=days
The ENGWEEKLY schedule is updated so that the incremental backup period is now every five days.