I've been having some discussions/arguments with co-workers (and myself at times!) over this. The schedules for the TDP agents are ACTION=COMMAND with an OBJECT of the command script that runs to start the TDP agent. What get's run in the script has nothing to do with the nodename that you used to start the scheduled command. You could actually just run a script file that has NOTHING to do at all with TSM on a client. Just to use it as a scheduling service. The script turns around and runs the TDP agent that points to its own DSM.OPT file, different from the B/A client's DSM.OPT file.
Now for backups, the scheduler service is going to run using the DSM.OPT file specified when you started the scheduler. This allowed me to not have to "clone" scheduler services all over my nodes just to run a command script to start a TDP backup. I just set up a DB2 backup this way. I use the nodename for the B/A client on that server (AIX) to schedule a shell script that in turns runs the BACKUP DB...USE TSM command for all the databases. There are currently 4 different instances, each instance has it's own nodename. The shell script ends up doing backups to TSM using 4 different nodenames, that are totally different than the nodename that was used to start the shell script. None of it's related. The only real caveat that I can see is you need to make sure the schedules don't overlap. You can't start 2 schedules to the same node at the same time. You can run into the position of a "miss" is the other schedule runs longer than the DURation of the other schedule. So far (knock on wood!) I haven't gotten bit by that one. I'm actually thinking of doing this same type of configuration for all my TDP nodes. Would save configuration and resources on the client not having multiple scheduler services running. Just my $.02 worth...and most times it's overpriced! Bill Boyer DSS, Inc. "There are 10 kinds of people in the world those who understand binary and those who don't." - ?? -----Original Message----- From: ADSM: Dist Stor Manager [mailto:ADSM-L@;VM.MARIST.EDU]On Behalf Of Joshua Bassi Sent: Wednesday, October 30, 2002 7:21 PM To: [EMAIL PROTECTED] Subject: Re: Automating RMAN Backup Through TSM Is it possible to run both a B-A client and a TDP client on the same machine both listening on port 1501? Can I have the dsmcad process listening for 2 different schedules (an incremental backup and a command execution) and start the "TSM Client Schedulers" at different times? -- Joshua S. Bassi IBM Certified - AIX 4/5L, SAN, Shark Tivoli Certified Consultant - ADSM/TSM eServer Systems Expert -pSeries HACMP AIX, HACMP, Storage, TSM Consultant Cell (831) 595-3962 [EMAIL PROTECTED] -----Original Message----- From: ADSM: Dist Stor Manager [mailto:ADSM-L@;VM.MARIST.EDU] On Behalf Of Jin Bae Chi Sent: Wednesday, October 30, 2002 9:21 AM To: [EMAIL PROTECTED] Subject: Re: Automating RMAN Backup Through TSM When using the TSM scheduler to automate the TDP Oracle backups, the differences in how these two clients work must be taken into account. - The scheduler runs as root and would need passwordaccess generate. - The TDP Oracle backup runs as an Oracle user and need passwordaccess prompt. In this one dsm.sys file, there will normally be more than one ServerName stanza when using the TDP Oracle on the same machine. One ServerName stanza for the filesystem backups and another ServerName stanza for the TDP Oracle backups (which need passwordaccess prompt). To assist with setting up the TSM Scheduler for the TDP Oracle node, you would need to create a third ServerName stanza in this dsm.sys file. In general, the dsm.sys file would be similar to the following: servername TSMbackup COMMMETHOD tcpip TCPServeraddress xxx.xxx.xxx.xxx TCPPORT 1500 NODENAME Client PASSWORDACCESS generate servername TSMOracle COMMMETHOD tcpip TCPServeraddress xxx.xxx.xxx.xxx TCPPORT 1500 PASSWORDACCESS prompt servername TDPSched COMMMETHOD tcpip TCPServeraddress xxx.xxx.xxx.xxx TCPPORT 1500 NODENAME TDPNode PASSWORDACCESS generate You would have three dsm.opt files. One for the Backup/Archive client that would normally be located in the /opt/tivoli/tsm/client/ba/bin directory. Based on the dsm.sys example above, this would contain the line: servername TSMbackup There would be a second dsm.opt file (which could have a different filename, such as dsmoracle.opt) for the TDP for Oracle. Based on the dsm.sys example this user option file for the Oracle client would contain the line: servername TSMOracle and would have passwordaccess prompt. There would be a third dsm.opt file (which could have a different filename, such as dsmsched.opt) for the TDP for Oracle scheduler. Based on the dsm.sys example this user option file for the Oracle client would contain the line: servername TDPSched and would have passwordaccess generate and have the NodeName for the TDP Oracle client specified. Environment variables would need to be utilized with the Oracle backup to point to the user option file. This would be specified in the TDPO_OPTFILE with the DSMI_ORC_CONFIG variable. For example: DSMI_ORC_CONFIG /opt/tivol/tsm/client/oracle/bin/dsmoracle.opt When starting the TSM Scheduler for the TDP Oracle backups, you will need to use the -SErvername parameter and specify which stanza should be used. Based on the example dsm.sys the scheduler command would be such as: dsmc sched -SE=TDPSched Neil Rasmussen Software Development TDP for Oracle [EMAIL PROTECTED]
