NOTE: The HFS TSM Client no longer uses the DSMCAD module. Instead it loads the Scheduler in 'standalone' mode via 'LOAD DSMC SCHED'. Please note the IBM recommendation at the foot of section 2.
In order for the TSM client to perform a scheduled backup, the TSM Scheduler must be running on the client machine during the allotted scheduled window. As all scheduled windows occur overnight, between 18:00 and 06:00, this means that the client machine must be running the TSM scheduler and the machine left switched on overnight on the night(s) of the schedule window.
Running the TSM Scheduler process causes output to be written to two log files:
dsmerror.log. These, by default, are located
in the TSM installation folder.
2. Running Scheduled Backups
In order to run automatic scheduled backups unattended the TSM password, the Netware password to login to the NDS tree and the Netware password to login to the Server need to be stored encrypted locally on the disk. The procedure for ensuring this is detailed in the instructions for installing and running the HFS TSM Client for Netware. If you can run the queries detailed in that section without being prompted for a TSM or Netware password, then these passwords have been correctly stored in encrypted form to disk.
To run the TSM Scheduler simply run the following:
LOAD DSMC SCHED
After a small delay, the TSM Scheduler will have written an entry in the
similar to below.
These 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 either the node name and/or the password have been incorrectly entered or the
password has expired. You will need to start the TSM client (LOAD DSMC) manually and enter the correct
password, or obtain a new password from IT Services Registration if yours has expired,
before restarting the TSM Scheduler. Further help on reasons
for the TSM Scheduler failing to start can be found by examining the
The TSM Scheduler wil start at a time within its allotted schedule window overnight and
report the results in the schedule log
dsmsched.log. This should be examined as
in the Checking the Scheduled Backups section.
The TSM Scheduler process will not stop once a scheduled backup has been performed but will continue to count down to the next schedule window. To stop it, just run:
UNLOAD DSMC SCHED
Note that IBM recommend that clients restart the scheduler periodically to free system resources previously used by system calls.
3. Checking the Scheduled Backups
The TSM Scheduler writes 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. To do this open the
dsmsched.log file and scroll to the end of the
file. 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
program. 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
dsm.opt options 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 HFS 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.opt 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.