Hi Jerry,

The reason that TSM works this way is to help ensure that when restoring
deleted files, at least the most recent directory for those files will
still be available.

For example, suppose you had a directory structure like this:

c:\mydir\file1
c:\mydir\file2

Suppose you have two management classes, A and B. A is the default, and
has a RETONLY setting of 10 days. B has a RETONLY setting of 30 days.

Now suppose (for whatever reason) you decide to bind file2 to management
class B. If TSM did not behave as I describe, then you have this:

c:\mydir bound to A
c:\mydir\file1 bound to A
c:\mydir\file2 bound to B

Next, you delete the c:\mydir directory (and its files, of course). The
next incremental backup detects that these files are deleted, and marks
the backup versions inactive. In 10 days, the backups for c:\mydir and
c:\mydir\file1 will be deleted from TSM's inventory. In 30 days, the
backup for c:\mydir\file2 will be deleted from TSM's inventory.

Now suppose it is 15 days later and you wish to restore c:\mydir\file2.
The following would be true:

You won't be able to restore via the GUI, because using the GUI to
navigate to c:\mydir\file2 means that you need to be able to first
navigate to c:\mydir. Since no backups exist for c:\mydir, you will not be
able to navigate to it, and thus you will not be able to navigate to
c:\mydir\file2.

You can restore c:\mydir\file2 via the command line, but the c:\mydir
will be created with default attributes vs. restored from TSM's inventory
with its original attributes (because no backup for it exists).

So this is why we make TSM behave the way it does.

You could use DSM_DIR to tell TSM to bind the directories to your STANDARD
management class, but I would not recommend it unless you have a very
controlled environment, and you understand and are willing to accept the
ramifications as I have described above. Note that the /logs directory and
its subdirectories will also be bound to the STANDARD management class
(the DSM_DIR option is absolute, and the INCLUDE statement binds only the
*files* to the specified management class), so you could run into the
problems I describe above.

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.ibm DOT com

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




Jerry Caupain <j.caupain AT ONL.PINKROCCADE DOT NL>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
10/26/2001 06:52
Please respond to "ADSM: Dist Stor Manager"


        To:     ADSM-L AT VM.MARIST DOT EDU
        cc:
        Subject:        Re: Strange behaviour????



But why EVERY directory of EVERY system, even the ones that have nothing
to do with this managementclass?

Why don't all other systems just use the default managementclass?
Do I really need to specify a dirmc for every system in order to get the
policy I need?

Regards,

Jerry Caupain




>>> Rene.Lambelet AT NESTLE DOT COM 10/26/01 12:05PM >>>
hi,

it will be used for directories if the retonly value is the highest in
this
DOMAIN,



> -----Original Message-----
> From: Jerry Caupain [SMTP:j.caupain AT ONL.PINKROCCADE DOT NL]
> Sent: Friday, October 26, 2001 11:12 AM
> To:   ADSM-L AT VM.MARIST DOT EDU
> Subject:      Strange behaviour????
>
> Hello everyone,
>
> I have noticed something strange. In my policy domain I have two
> management classes. One is called STANDARD and the other is called
> LOG_POLICY-MC. I want to use the last one only for my log server so I
> included the following line in my include/exclude file:
> INclude         /logs/.../*     log_policy-mc
>
> Managementclass STANDARD is the default managementclass.
>
> Why is it that all my other systems also use the LOG_POLICY-MC
> managementclass?  It seems that the directories on my other systems are
> all bound to this managementclass. This can't be normal............can
> it???
>
> Jerry Caupain