Todd,

may I correct you. In TSM it is called "rebinding":
- you have several backups made using one class (be it default or not)
- somehow (dsm.sys/dsm.opt, optionset) you change include/exclude list and
a object (in TSM terms - file, TDP stream, SystemObject, etc.) is now
bound to another class
- TSM server on first backup after the change "re-binds" ALL versions
(retro-active) of that object
- on next expiration new class' vere/verd/rete/reto settings are honoured

Example 1:
previous class was with 60 days retention, new class is with 7 days (as in
Kevin's case):
- system objects back to 60 days ago
- after Wanda's suggested change system object is rebound
- next expiration ought to remove all system objects older than 7 days
(disclaimer: on version without System Object expiration bug)

Example 2:
old class with 5 versions, new class with 12 versions
- 5 versions are kept and each 6-th old is expired
- a file is rebound to new class
- new backup will notify server about rebind and will create 6-th version
- until 7 new versions are backed up (for total of 12) no version will be
expired despite the fact the oldest versions were created when limit was
only 5.

I hope this helps

Zlatko Krastev
IT Consultant






Todd Lundstedt <Todd_Lundstedt AT VIA-CHRISTI DOT ORG>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
23.10.2002 20:11
Please respond to "ADSM: Dist Stor Manager"


        To:     ADSM-L AT VM.MARIST DOT EDU
        cc:
        Subject:        Re: System Object / Mgmt. Classes / Policy Sets / 
Backup Groups - - Wh
at's the best way??


Correct me if I am wrong, but this will only change the management class
for the backups after the changes are made.  All of the other
systemobjects
that exist in the database that are managed by the old management class
will be retained for their 60 days.  In order to facilitate the move to
the
new management class, you will want to rename the systemobject filespace
on
each server (for instance, systemobject.old), then perform your backups
for
8-9 days, making sure the new systemobject only has data stored for 7
days,
and only in the new management class.  Then, it will be safe to delete
systemobject.old, and recover that database space prior to your upgrade.
Todd



|--------+-------------------------->
|        |          "Prather, Wanda"|
|        |          <Wanda.Prather@J|
|        |          HUAPL.EDU>      |
|        |          Sent by: "ADSM: |
|        |          Dist Stor       |
|        |          Manager"        |
|        |          <[email protected]|
|        |          T.EDU>          |
|        |                          |
|        |                          |
|        |          10/23/2002 11:48|
|        |          AM              |
|        |          Please respond  |
|        |          to "ADSM: Dist  |
|        |          Stor Manager"   |
|        |                          |
|--------+-------------------------->

>----------------------------------------------------------------------------------------------------------------------------|
  |                                                     |
  |      To:     ADSM-L AT VM.MARIST DOT EDU                 |
  |      cc:                                                     |
  |      Fax to:                                                     |
  |      Subject:     Re: System Object / Mgmt. Classes / Policy Sets /
Backup Groups - - Wh         at's the best way??       |

>----------------------------------------------------------------------------------------------------------------------------|




Hi Kevin,

Most people have only 2 policy sets for each policy domain - the acitve
and
the inactive one.
I suggest you make a new management class:

*       In the NOCODOM policy domain, create a new management class, for
example call it SYSOBJ_MAN
*       Edit the BACKUP COPY GROUP for that new management class to set
your
retention to 7 instead of 60.
*       ACTIVATE the policy set for that domain; that makes the changed
version active.
*       Pick a Win2K client in the NOCODOM domain to test.
*       In the dsm.opt file of that client, put an include statement to
cause TSM to bind the systemobject to the new management class:
              include.systemobject SYSOBJ_MAN

*       Start the backup client and backup the system object
*       Now pretend you are going to restore the system object:
                start the client
                click RESTORE
                expand SYSTEM OBJECT
                click on one of the components (like registry)
                scroll to the right, you should see the time and
management
class of the last backup
                if it says SYSOBJ_MAN instead of DEFAULT, it's working
*       Now you have to figure out how you are going to make this happen
on
ALL the clients in the NOCODOM domain.
*       You can either use sneakernet and add this to the dsm.opt file of
all the affected clients, or
        create a clientoptionset on the server with this include statement
(certainly easier to do!)



-----Original Message-----
From: Thach, Kevin [mailto:KThach AT COVHLTH DOT COM]
Sent: Monday, October 21, 2002 3:54 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: System Object / Mgmt. Classes / Policy Sets / Backup Groups --
Wh at's the best way??


Hi,

I've been designated the TSM administrator here at my workplace, and I'm
trying to educate myself as I go without making a mess of things.  Our IBM
partner came in and installed the server and a few clients, and handed it
over to me.  I now have about 200 Win2K clients, 40 AIX Clients, and about
5
Linux Clients.

My question is this:

The person that installed our environment basically set up 6 Policy
Domains:
Colodom, Exchange, Lanfree, MSSQL, Nocodom, and Oracle.

99% of the clients are in the Nocodom (non-collocated) domain, which has
one
policy set, and one management class which has one backup copy group with
retention policies set to NOLIMIT, 3, 60, 60.

So, my problem is this.  It turns out that in trying to upgrade from
4.2.2.3
to 5.1.X we ran into the problem with System Objects BIGTIME.  We are
retaining 60 days worth of System Object files for about 200 Win2K
clients,
which translates to about 29,000,000 System Object files, and about 55% of
our TSM database (36 GB).

What we've decided to do before upgrading to 5.1.X is to upgrade to 4.2.3
and lessen the retention for the System Objects.  However, I have no
experience in setting up Mgmt classes, policy sets, etc, and I'm not sure
what I need to do in that arena.

What I'd like to get to is this:

1) System Objects retained for 7 days
2) Everything else retained for 60 days

How do I set up an additional policy set for just the System Object stuff?

Thanks in advance!
-Kevin


This E-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended only
for the use of the Individual(s) named above.  If you are not the intended
recipient of this E-mail, or the employee or agent responsible for
delivering it to the intended recipient, you are hereby notified that any
dissemination or copying of this E-mail is strictly prohibited.  If you
have
received this E-mail in error, please immediately notify us at (865)
374-4900 or notify us by E-mail at hdesk AT covhlth DOT com.