In certain situations it is preferable to have more than one scheduled activity for each client system.
Normally, you can do this by associating a node with more than one schedule definition. This is the standard method of running multiple schedules on one system.
You must ensure that the schedule windows for each schedule do not overlap. A single client scheduler process is not capable of executing multiple scheduled actions simultaneously, so if there is overlap, the second schedule to start is missed if the first schedule does not complete before the end of the startup window of the second schedule.
Suppose that most of the file systems on your client system must be backed up daily, and that one file system containing critical data must be backed up hourly. In this case, you would need to define two schedules to handle this requirement. To avoid conflict between the hourly and daily backup schedule, the starttime of each schedule needs to be varied.
Suppose that most of the drives on your client system must be backed up daily, and that one drive containing critical data must be backed up hourly. In this case, you would need to define two schedules to handle this requirement. To avoid conflict between the hourly and daily backup schedule, the starttime of each schedule needs to be varied.
In certain cases, it is necessary to run more than one scheduler process on a system. Multiple processes require a separate options file for each process and must contain the following information:
The advantages of using multiple schedule processes:
The disadvantages of using multiple schedule processes:
Multiple schedule processes can run on UNIX and Linux platforms with either the client acceptor daemon-managed method, or the traditional method of running the scheduler. In either case, there are certain setup requirements:
You must start each dsmc sched command or instance with the -servername option to reference its unique stanza name in dsm.sys. For dsmcad, it is necessary to define the environment variable DSM_CONFIG for each instance of dsmcad to reference its unique option file.
servername tsm1_sched1
nodename aixsvt01_sched1
tcpserv firebat
tcpclientport 1507
passwordaccess generate
domain /svt1
schedmode prompted
schedlogname /tsm/dsmsched1.log
errorlogname /tsm/dsmerror1.log
managedservices schedule
servername tsm1_sched2
nodename aixsvt01_sched2
tcpserv firebat
tcpclientport 1508
passwordaccess generate
domain /svt1
schedmode prompted
schedlogname /tsm/dsmsched2.log
errorlogname /tsm/dsmerror2.log
managedservices schedule
Contents of /test/dsm.opt1:
servername tsm1_sched1
Contents of /test/dsm.opt2:
servername tsm1_sched2
Open two shell command windows:
export DSM_CONFIG=/test/dsm.opt1
sudo dsmcad
export DSM_CONFIG=/test/dsm.opt2
sudo dsmcad
Note: You should enter these commands into a shell script if you intend to have the dsmcad processes started directly from /etc/inittab so that the proper DSM_CONFIG variable can be set prior to launching dsmcad.
dsmcutil inst /name:"TSM Client Scheduler1" /optfile:"c:\tsm\dsm.opt1"
/node:tsmcli_sched1 /password:secret /autostart:no /startnow:no
dsmcutil inst CAD /name:"TSM Client Acceptor1" /optfile:"c:\tsm\dsm.opt1"
/cadschedname:"TSM Client Scheduler1" /node:tsmcli_sched1 /password:secret
/autostart:yes
dsmcutil inst /name:"TSM Client Scheduler2" /optfile:"c:\tsm\dsm.opt2"
/node:tsmcli_sched2 /password:secret /autostart:no /startnow:no
dsmcutil inst CAD /name:"TSM Client Acceptor2" /optfile:"c:\tsm\dsm.opt2"
/cadschedname:"TSM Client Scheduler2" /node:tsmcli_sched2 /password:secret
/autostart:yes
tcps tsmserv1.storage.sanjose.ibm.com
nodename tsmcli_sched1
passwordaccess generate
schedlogname c:\tsm\dsmsched1.log
errorlogname c:\tsm\dsmerror1.log
schedmode prompted
tcpclientport 1507
domain h:
managedservices schedule
tcps tsmserv1.storage.sanjose.ibm.com
nodename tsmcli_sched2
passwordaccess generate
schedlogname c:\tsm\dsmsched2.log
errorlogname c:\tsm\dsmerror2.log
schedmode prompted
tcpclientport 1508
domain i:
managedservices schedule