Thanks Richard

I can confirm that the files and dirs are bound to the correct policy
values and that we do not have a DIRMc setting in place.

Thanks for your help and I'll have a look at that technote now.

Regards

Farren


|-----------------------------+-------------------------------------------|
|   Richard Sims <rbs AT BU DOT EDU> |                                          
 |
|   Sent by: "ADSM: Dist Stor |                                           |
|   Manager"                  |                                         To|
|   <ADSM-L AT VM.MARIST DOT EDU>    |                     ADSM-L AT VM.MARIST 
DOT EDU  |
|                             |                                         cc|
|   27/01/2006 14:07          |                                           |
|                             |                                    Subject|
|         Please respond to   |                     Re: [ADSM-L] Mac      |
|         "ADSM: Dist Stor    |                     Client 5.2.3.12 point |
|             Manager"        |                     in time problem       |
|      <ADSM-L AT VM.MARIST DOT EDU> |                                          
 |
|                             |                                           |
|                             |                                           |
|                             |                                           |
|                             |                                           |
|                             |                                           |
|-----------------------------+-------------------------------------------|






On Jan 27, 2006, at 8:36 AM, Farren Minns wrote:

> Hi Richard
>
> Well, looking at the dirs and files I can see the following :-
>
> 'Files' are bound to the following backup copy group.
>
> Version Data Exists        -        3
> Versions Data Deleted        -        1
> Retain Extra Versions        -        180
> Retain Only Version        -        60
>
> 'Dirs' are bound to the following (this backup copy group was
> created for
> something else but as far as I'm aware dirs automatically bind to the
> backup copy group with the highest retention settings).

...unless instructed otherwise via DIRMc, per client manual and Admin
Guide.

>
> Version Data Exists        -        3
> Versions Data Deleted        -        1
> Retain Extra Versions        -        180
> Retain Only Version        -        751
>
> So, looking at the above I can see no reason why there would ever be a
> situation where a required dir would not exist for a required file
> as we
> always keep the only last remaining copy for 751 days.
>
> Also, when using the GUI, I can still see the files when viewing
> active/inactive, just not when adding in the point in time too.

Adding PIT makes the operation much more restrictive, and requires
existence of the directory instance which matches that time period.
Irregularities can screw this arrangement up, as for example system
clock values having been incorrect at backup time.

Rather than inspecting current policy values and what you think
should have happened, you need to inspect the actual assignments of
the (surviving) directory objects in TSM storage. Current policy
values are just that: changes to policies over time, and unexpected
bindings, can be the cause of expired objects.

Have a look at Technote 1162784 as well, where IBM lays out the issue.

   Richard Sims


######################################################################
The information contained in this e-mail and any subsequent 
correspondence is private and confidential and intended solely 
for the named recipient(s).  If you are not a named recipient, 
you must not copy, distribute, or disseminate the information, 
open any attachment, or take any action in reliance on it.  If you 
have received the e-mail in error, please notify the sender and delete
the e-mail.  

Any views or opinions expressed in this e-mail are those of the 
individual sender, unless otherwise stated.  Although this e-mail has 
been scanned for viruses you should rely on your own virus check, as 
the sender accepts no liability for any damage arising out of any bug 
or virus infection.
######################################################################