Steve,

The only options available from the GUI are /SQLSERVER,
/CONFIGFILE, and /TSMOPTFILE.

1. You cannot specify a node name override for the GUI.
   The only way is to point to a different
   TSM options file with the different NODENAME in it.
   Your idea of the single NODENAME would solve this problem
   and your idea for the scheduling will work as well.
   The only disconnect will be that the data itself
   won't be stored under the NODENAME that is scheduled.
   If that is understood by your admin team, it is
   probably fine.

2. You can specify the /SQLSERVER= option and that tells
   DP/SQL which SQL Server to talk to, i.e. that is the
   SQL Server where your restored databases will go for
   that invocation.

3. You do not need to specify the /FROMSQLSERVER on the GUI
   because the GUI will automatically look for all backups
   for all SQL servers backed up under that nodename.

As far as "foolproof"... haha... not sure there is such a thing,
but... your method is probably a good one to test and implement.

Thanks,

Del

----------------------------------------------------

"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> wrote on 12/21/2005
06:36:45 AM:

> Del,
>
> I was hoping to setup a centralized script that I could update rather
> than have to maintain scores of opt/cfg files (currently a dozen
> machines with 3 instances per machine - and growing)...
>
> So, could I accomplish the same thing by doing:
> TDPSQL -NODENAME=<node> -SQLSERVER=<sql_instance>
> -FROMSQLSERVER=<sql_instance>
>
> I was originally thinking that if the backup data was all under one
> nodename, I would not have to ever specify the -NODENAME and
> -FROMSQLSERVER parms, but perhaps this is incorrect?  I would actually
> still define individual nodenames for scheduling purposes, but in the
> script I would override the nodename to send the data to the "generic"
> one.
>
> Basically I need a "foolproof" method of allowing the SQL admin to use
> the gui without shooting himself or me in the foot:
> 1. Backup databases from any instance on a machine
> 2. Restore databases from any other machine & instance to any instance
> on the current machine
> 3. NOT overlaying the opt/cfg files in the process
>
> -steve
>