I agree with Rick and the others - use multiple mgclasses in one domain.
But I wonder what the alledged expert was worrying about as to know what
mgclass a file is in.  Why does he think it is important to know that?
And when you find out, what can you do with the information? (You do need
to check things after the first backup to verify that the include
statements are coded correctly).
Not only is the expert confused about the answers, he doesn't even ask the
right questions!

--
--------------------------
--------------------------
Bill Colwell
Bill Colwell
C. S. Draper Lab
Cambridge, Ma.
bcolwell AT draper DOT com
--------------------------
In <862568B8.00515EEC.00 AT nsbq6k2.statefarm DOT com>, on 04/05/00
In <862568B8.00515EEC.00 AT nsbq6k2.statefarm DOT com>, on 04/05/00
   at 03:53 PM, Rick Smith <richard.smith.hs45 AT STATEFARM DOT COM> said:

>Rick,

>I would have to disagree with the local expert also.  As already
>mentioned in some of the other responses, you can tell what files belong
>to what management classes.  You are correct in your assumption that
>multiple policy domains would require multiple clients installed on a
>single machine, as a node can only belong to one policy domain.

>I think that using one Policy Domain and policy set only would work.
>You'd just have to have an all inclusive include statement, on all
>clients that should not use the default management class, that points all
>the client files to the proper management class.  I think that in some
>cases, even though it is not necessary, it is easier to create separate
>policy domains for like clients (at a high level like Servers and
>workstations).  Then use different Management classes to distinguish
>differences within those domains (such as file/print servers vs. e-mail
>servers).

>Rick Smith
>ADSM LTSB Team
>State Farm Insurance
>309-735-3086




>From:
>O1=INET00/C=US/A=IBMX400/P=STATEFARM/DD.RFC-822=ADSM-L\@VM.MARIST.EDU on
>04/05/2000 08:50:37 AM
>To:   ADSM-L
>cc:
>Subject:  Re: Management Classes

>Type "dsmc query backup <filespace>", and you'll see what management
>class
>each file is bound to.

>I have to strongly disagree with your local expert.

>I go the OPPOSITE route, i.e, have one policy domain for everything, and
>use
>the include-exclude list to set management classes as needed on each node
>or filespace or directory.  I do this for simplicity - I have seen ADSM
>setups with a bewildering array of policy domains and policy sets, for no
>good reason.

>If users will do archiving, then you'll need some different management
>classes
>anyway, to give them options like 90-day archive, 180-day, 3-year, etc.
>(otherwise the user has to ask that a new MC be set up every time they
>want
>to archive something with a different retention length.)

>Since we have to have different management classes anyway, why not use
>them for
>everything, and not use policy domains at all?  (I mean, just have one
>policy domain and one policy set.)  I think the domain-set-MC-copygroup
>structure is overly complex.  Maybe it's useful in some rare situations,
>but most installations don't need all that.

>Debate welcome....

>> Subject: Management Classes
>>   Date: Tue, 4 Apr 2000 15:55:20 -5
>>   From: "Richard L. Rhodes" <rhodesr AT FIRSTENERGYCORP DOT COM>.
>>
>>
>>
>> WHile talking with our local IBM *SM expert, I told him (if we
>> purchase *SM) we would want to use multiple management classes (in
>> one domain) for the file systems from a host.  Each filesystem has
>> different policy needs.  He STRONGLY suggested that we NOT do this.
>> He said the problem is that, on the *SM server,  there is no way to
>> determine what management class a file belongs to, which will cause
>> great confusion.  He suggested that I use separate domains (with only
>> one management class - default) for each filesystem that needs
>> different policies.  And, to do this, will require separate *SM
>> clients on the computer per domain.
>>
>> Is this correct?  Thoughts?  Suggestions?
>>
>> THanks
>>
>> Rick
>--
>Mr. Lindsay Morris
>Gresham Enterprise Storage
>lmorris AT openmic DOT com
>606-253-8000