Expiration and object deactivation dates

Answer

1) Tivoli Storage Manager doesn't expire an active object. Hence to expire an object it has to be inactive.
2) An object becomes inactive such as on the next incremental. The deactivation date is set to the date when the incremental was run. This date is used to compare against policy. (see example #1 below)
3) On a subsequent backup if the number of objects exceeds policy. then the oldest object can be immediately marked for expiration by changing the deactivation date (see example #2 below).
4) Once an object is past retention policy the Deactivation date is changed to "Deactivated 1900-01-01 00:00:00.000000" (example #2).

The next time expiration runs an object with a 1900-01-01 type deactivation date is immediately removed without comparing against policy. The objects marked with this type deactivation date are no longer restorable.

Example of 2 different deactivation dates:
1) Deactivated 12/05/11 18:00:26
2) Deactivated 1900-01-01 00:00:00.000000

The Show Versions command can be used to see the deactivation date of objects on the server.
Syntax: Show Versions nodename filespace_name HL_name LL_name
(note the HL_name and LL_nam are optional - these represent the directory path and filename)

Example: Show Versions output for an NDMP backup:

/abc_enterprise_level : /NAS/ IMAGE (MC: FILESERVER_CLASS)
Inactive, Inserted 12/04/11 07:00:15, Deactivated 12/05/11 18:00:26
ObjId: 0.941332014, GroupMap 00050000, objType 0x0b, bypassRecogToken
NULL
Attr Group Leader, GroupId: 0.941332014
Delta Group Leader, GroupId: 0.941332014 <---- full backup (note: a Delta Group Member is a differential)