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 AT VM.MARIST DOT EDU]On Behalf Of
Joshua Bassi
Sent: Wednesday, October 30, 2002 7:21 PM
To: ADSM-L AT VM.MARIST DOT EDU
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
jbassi AT ihwy DOT com


-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Jin Bae Chi
Sent: Wednesday, October 30, 2002 9:21 AM
To: ADSM-L AT VM.MARIST DOT EDU
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
rasmussn AT us.ibm DOT com