On Nov 6, 2008, at 4:05 AM, Craig TSM wrote:

Interesting,  I am aware of the deactivation time you mentioned.
Now its been a while but from what I remember changing the policy
retention either by changing current or moving node to another, did
not
change this deactivation date, remembering this is what I found for
files which were already deleted from client , and expiration has run
across TSM DB.
So what your saying is certainly true for active / non deleted files
from client.
Of course the original issue raised I believe files were still on
client. So no concern.

The flagging of a file as deactivated is irrevocable.  Extending the
retention period can serve to extend the residency lifetime of
deactivated files, as qualified below.

Also I discovered even if Expiration processing is stopped (which I
don't recommend) once the Deactivation date is reached, you cannot
restore the file!!!

You're confusing deactivation with expiration.  A deactivated file is
one which has gone from Active to Inactive.  Inactive files can
certainly be restored, until...
Stored objects reach end of life either by being pushed out by
versions overflow or deactivation date + retention.  In the case of
end of life, TSM server internal periodic processing identifies client
objects whose time is up, and changes their deactivation date to a
"negative infinity" value to mark them as goners, and adds their
identity to the internal table called Expiring.Objects, whose contents
are processed by Expire Inventory.  A file thusly marked will no
longer be revealed in queries or restoration candidate lists.  It is a
deactivated file which is marked for elimination which cannot be
restored.

  Richard Sims   http://people.bu.edu/rbs