Policy domains.  That way you won't have to use a bunch of includes.  Now,
that said, if only bits of the overall data are different on each system,
then management classes will work better.  If all the data on a system is
retained one way, and all the data on another client is managed differently:
different domains.

Kelly J. Lipp
Storage Solutions Specialists, Inc.
PO Box 51313
Colorado Springs, CO 80949
[EMAIL PROTECTED] or [EMAIL PROTECTED]
www.storsol.com or www.storserver.com
(719)531-5926
Fax: (240)539-7175


-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED]]On Behalf Of
Malbrough, Demetrius
Sent: Friday, March 01, 2002 8:59 AM
To: [EMAIL PROTECTED]
Subject: New Policy Domain vs. New Mgmtclass???


Morning, *SMers!

These NT 4.0 TSM 4.1.2.20 nodes have been backing up for years to policy
domain WINNTADSM (generic-not describing the application installed on the
node but only the platform). Now we have a need to change the retention for
all nodes by APPLICATION (SQL,OnDemand, etc) that meet the companies
requirements.

a) Should I create a new policy domain factoring in future add-ons which
will meet this policies criteria?

b) Should I create a new mgmt class with the backup/archive copygroup
retentions and update the dsm.opt files with the new mgmtclass which will
rebind all files to them?


My concerns:
We use a naming convention for all nodes by application as such:

NTSQL001
NTSQL002
NTSQLxxx

Therefore, all NTSQL xxx nodes that are added in the future will be assigned
to this mgmtclass or policy domain. The reason I want to add a new policy
domain is because
the name of the policy domain will reflect what type of application is on
this node
and the way the data is retained. But, the downfall is having to remove the
nodes
which means deleting all filespaces and that may be a little dangerous!

Any hints, tips, concerns are appreciated!

Thanks,

Demetrius Malbrough
UNIX/TSM Administrator

Reply via email to