Contents
The basic command for running the TSM Scheduler is to run , as the root user, dsmc schedule as a
background process with redirection of output, as below.
dsmc schedule > /dev/null 2>&1 & # for Bourne-like shells dsmc schedule >& /dev/null & # for C-like shells
More convenient, however, is to start the Scheduler at system boot time. If your flavour of Unix employs
the /etc/inittab file to launch processes at system start then add a line similar to
below to this file:
ds:2:respawn:/usr/bin/dsmc schedule > /dev/null 2>&1
For systems that start programs from init level command files, it is simplest to
add a command file that starts and stops the TSM Scheduler at the appropriate run levels ( probably 2 and 3 ). To
this end, OUCS includes a file called dsmschedthat can be directly copied to the
appropriate run-level directories. This file looks similar to this:
#! /sbin/sh
#
# Start stop script for TSM
#
killproc() {
pid=`/usr/bin/ps -ef |
/usr/bin/grep "$*" |
/usr/bin/awk '{printf $2}'`
[ "$pid" != "" ] && kill -TERM $pid
}
case "$1" in
'start')
killproc "[d]smc schedule"
if [ -x /usr/bin/dsmc ]; then
/usr/bin/dsmc schedule > /dev/null 2>&1 &
fi
;;
'stop')
killproc "[d]smc schedule"
;;
*)
echo "Usage: $0 {start|stop}"
;;
esac
This program can then be linked as a Start script to start it at run levels 2 and 3 - on Solaris in this example - by the following:
cd /etc/rc2.d ln -s /etc/init.d/dsmsched ./S95dsmsched
... and can be linked as a kill script to shut down the TSM Scheduler at run levels 0 and 1 and 6 - again on Solaris in this example - as follows:
cd /etc/rc0.d ln -s /etc/init.d/dsmsched ./K95dsmsched cd /etc/rc1.d ln -s /etc/init.d/dsmsched ./K95dsmsched cd /etc/rc6.d ln -s /etc/init.d/dsmsched ./K95dsmsched
2. Checking the Scheduled Backups
Once started, the TSM Scheduler will contact the TSM server for the next schedule window and count down to that. If the next schedule window is more than 24 hours away the process will count down for 24 hours and then re-contact the TSM server. This window can be checked manually by running the command:
dsmc query schedule
Output from the Scheduler process is written to the dsmsched.log file. Typical output
after starting the Scheduler will look similar to below.
The above lines show a connection to a TSM server and a query for the next scheduled backup window.
If there are lines similar to "ANS1029E Communications have been dropped" then it is likely that the configuration
in the dsm.sys file is faulty. Check that a manual backup is possible and check the latest
entries in the dsmerror.log for further help.
On running a scheduled backup the TSM Scheduler appends its output to the end of the dsmsched.log
file and any errors in the dsmerror.log file. It is important to regularly examine the schedule
log for details of the latest scheduled backups. The TSM Scheduler will have written summary information of the last
scheduled backup similar to below
It is important to determine if any files have failed to backup. If the number of objects listed as failed is
greater than zero then scroll up the file for the next occurrence of the word 'fail' to determine which file(s)
this affects. The most common reason for a file failing to be backed up is that it is held open (locked) by another
process. In this case, the choice is either to close the program before the backup, or exclude the file from the
backup process by adding it to the Exclude entries in the inclexcl file.
Other failures and errors will be accompanied by an error message and a corresponding entry in the
dsmerror.log file. Further help with any errors may be found using either the TSM Help facility
or the OUCS TSM Help pages.
Note that the schedule log file does not grow endlessly, but is pruned of entries older than the setting of the
SchedlogRetention option in the dsm.sys options file. By default this
is set to 30 days. See the entry in the client TSM online Help for possible values for this option.