The only good reasons I see to having more than one domain are:
1.  Getting different default management classes.
2.  Delegating policy administration to different administrators.

In large environments, it is often desirable to allow system admins to do
TSM policy administration for their systems, since they are closest to the
environment.  This is the real value of domains.



_____________________________
William Mansfield
Senior Consultant
Solution Technology, Inc




                    "Seay, Paul"
                    <seay_pd@NAPT        To:     ADSM-L AT VM.MARIST DOT EDU
                    HEON.COM>            cc:
                    Sent by:             Subject:     Re: Domains Question
                    "ADSM: Dist
                    Stor Manager"
                    <ADSM-L AT VM DOT MA
                    RIST.EDU>


                    11/26/2001
                    10:40 PM
                    Please
                    respond to
                    "ADSM: Dist
                    Stor Manager"






Actually, a domain has nothing specifically to do with a storage pool.  The
deal is the clients are using a default policy domain management class.
This management class has a backup group associated with it which can only
go to one primary storage pool, maybe a next pool, etc.  Multiple
management
classes could be put under the current policy domain with a new management
class (at least in V4 you can do this).  But, this requires the dsm.opt
file
on each client to specify management classes, which is probably not what
you
want.

If you change the policy domain of the clients to new ones with different
storage pools you can move the data to the new storage pools and a rebind
to
the new management class will occur on the first backup.  I recommend you
setup a little test server to test out everything before you try this on a
production server.

Now for your real question.  How many policy domains?  Policy domains
relate
to your business objectives and need to separate data into default
management classes easily.  Some of the TDPs (Oracle, Exchange, SQL Server,
DB2, etc) require/recommend separate policy domains from the client backup
which you probably do not have implemented.

I will give you an example.  Say you have three areas of business:
        Office Automation
        Manufacturing
        Engineering

These could have the same or different server platforms but are distinct
business entities.  It would probably be prudent to separate them into
separate policy domains and storage pools for recovery purposes.  You may
want to break them down further.  As technicians we think in server OS
terms
AIX, IRIX, Windows, Netware, Solaris, etc., but that is not necessarily the
right business model because many times an environment crosses many
platforms.

The other example that may seem dumb is we use AIX/Windows TSM servers.  We
send them to their own storage pools just to isolate the restore tapes
easily for disaster recovery reasons.  Which ultimately, is how your policy
organization may come out for your business.

The technical reason for several policy domains is TSM administration
security.  You can segment who can touch what and do to what by policy
domain.

The TSM Administrator's guide makes a real good book to put you to sleep at
night.  You should use it for about a week.  It will really help you get a
handle on the reasons for policy domains and storage pools.

In the end, your real question has to do with how many storage pools do you
need.  That is where you categorize your data by whether collocation makes
sense, reclamation makes sense, etc.  This is a balancing act.  The more
storage pools you have the more you have to manage.  Pick the proper
granularity.

In my case I have about 5 primary disk pools, 15 primary tape pools, and 15
copy tape pools, but I have a 40TB, 250+ many platform server environment,
with requirements to segregate customer data and all sorts of requirements.
Some of my tape pools are the primary and there are no disk pools in the
middle.  We use a lot of SAN managed tape.