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.