Not having been with IBM at the time TSM came out, I do not know off-hand
what the original intended purpose of multiple policy sets was/is.
However, the value that is immediately apparent to me is:

- Changes to the policy set do not go "live" until the policy set is
activated. This gives you the opportunity to review your changes before
activating them (i.e., "whoooops, I meant to say VEREXISTS=99, not 9").

- Allowing multiple "non-active" policy sets means that when you want to
change a policy set, you can make a copy of that policy set before making
the changes, so that you do not lose the old settings in case you change
your mind after making the changes, i.e.:

   1) COPY POLICYSET STANDARD STANDARD STANDARD_BKUP
   2) <make various changes to policy set STANDARD>
   3) <decide that changes are no good, you want to reinstate the old
policy>
   4) COPY POLICYSET STANDARD STANDARD_BKUP STANDARD

Regards,

Andy

Andy Raibeck
IBM Software Group
Tivoli Storage Manager Client Development
Internal Notes e-mail: Andrew Raibeck/Tucson/IBM@IBMUS
Internet e-mail: storman AT us.eyebm DOT com (change eye to i to reply)

The only dumb question is the one that goes unasked.
The command line is your friend.
"Good enough" is the enemy of excellence.




"William F. Colwell" <bcolwell AT DRAPER DOT COM>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
05/23/2003 06:31
Please respond to "ADSM: Dist Stor Manager"


        To:     ADSM-L AT VM.MARIST DOT EDU
        cc:
        Subject:        Re: Question on  defeating TSM strengths: due to budget 
constraints <<
solved



At 08:08 PM 5/22/2003, you wrote:
>On Friday 23 May 2003 07:41, William F. Colwell wrote:
>
>No, no, no! This is _so_ wrong I don't know where to begin... :)
Steve,

Needless to say, I disagree with your disagreement, but I do agree
there are other ways to solve Ken's issue, I just think this is the
best, simplest & cheapest.

My take on the policy constructs is that domains are for management by
departments, policysets are for management by time, and management
classes are for management by file type/location.

TSM doesn't really lend itself to time based management
(for instance, a full backup on the first day of the month) and most
of us think it should be a thing of the past, but convincing management
of that isn't easy.


>> I think this is one of the rare cases where policysets are useful.
>> Policysets can implement time based policies.
>> Just copy your STANDARD policyset to WEEKLY.  Edit the
>> STANDARD mgmtclas (copygroup) to have the new parameters, i.e.
>> mode=absolute.
>
>Although multiple policy sets are *sometimes* useful, this isn't one of
those
>occasions.
>
>Muliple policy sets are only useful when you are using the configuration
>manager to replicate a policy domain to another TSM server. You could
then
>define two different policy sets on the configuration manager, replicate
the
>policy domain, and then activate a different policy set on each TSM
server.


Policysets were in the product from version 1, r 1.  The configuration
manager
didn't arrive until v3, so there must have been some other reason for
policysets.

It might help if IBM were to explain what they thought they were providing
us when they designed policysets.


>> Now setup  an admin schedule to activate the WEEKLY policyset at the
right
>> time, and another to activate STANDARD.  This works because the client
>> queries the server for policy information at the start of each backup,
>> which is different for the problems the scheduler has with
include/exclude
>> lists which need a scheduler restart to take effect.
>
>If you activate a different policy set, then the management class/copy
group
>parameteres in *THAT* policy set will control how the data is retained.
Only
>the policy set which is active at the time *EXPIRE INVENTORY* is run will
>control whether the data is retained or expired. It doesn't matter (much)
>which policy set was active at the time of the client backup.


Yes, I understand about the expiration issue, and my directions to Ken
avoided it.  I said to only change the mode in the copygroup(s). Therefore
there would not be any rebinding on the client, and expiration would not
be
affected.

Rebinding only occurs if the name of the management class is changed.


>> >Ken_Sedlacek AT KYRUS DOT COM said...
>
>> >I was saying my rosary this morning, and by divine revelation (so to
>> >speak), just realized that all I need to do is make a schedule with
the
>> >new mgmt class. This is so simple, I could just spit!
>
>Remember, if you change the management class being used for backup
objects it
>will rebind all the existing backup objects to the new management class.
>
>> >1) How do I get the client servers to execute this FULL_Backup Mgmt
class
>> >on a weekend schedule, while maintaining the STANDARD Mgmt class for
M-F?
>
>There are several ways to do something like this. The simplest is
probably to
>just define two client accounts per node. Create two client scedules
>(possibly in different policy domains...) and backup the node (using the
>"normal" management class) every day, and backup the "other" node (using
the
>"special" management class once per week (or so).
>
>You *really* need to buy a second tape drive. :)
>
>PS/ You *REALLY* need to buy a second tape drive. :)
>
>Regards,
>Steven P.
>
>--
>Steven Pemberton                                      Mobile: +61 4 1833
5136
>Innovative Business Knowledge                   Office: +61 3 9820 5811
>Senior Enterprise Management Consultant    Fax: +61 3 9820 9907

----------
Bill Colwell
C. S. Draper Lab
Cambridge Ma.