Hi Gretchen,

I am not aware of any problems with expiration in this regard, and for
that matter, it is controlled by the client.

The key things to check are:

- Are you doing full incrementals of the file spaces, as opposed to
incremental by date or incremental of specific files/directories?

- Did you verify correctness of the include/exclude list? What does your
"dsmc query inclexcl" output show?

It should be easy enough to do a simple test:

1) From an OS prompt, cd to the root of C: and issue the following:

   md myshare\testdir

2) Populate myshare\testdir with two or three files.

3) Create a share for myshare, then net use to it (note that my machine
name is storman, substitute your machine name instead):

   net share myshare=c:\myshare
   net use t: \\storman\myshare

4) From a TSM admin, create a node named TEST

5) Create a simple dsm.opt file to back up T:, like this:

   commmethod tcpip
   tcpserveraddress your.tsm.server.address
   nodename test
   domain t:

6) Do an incremental backup of T: and watch your files get backed up:

   dsmc i t:

7) From the admin, define a client option set named TEST and associate
with node TEST:

   def clo test
   def cliento test inclexcl "exclude.dir t:\testdir"
   upd n test clo=test

8) Repeat step 6. This time files should be expired.

What do you see?

When you are done testing, you can remove the share:

   net use t: /delete
   net share myshare /delete
   rd /s /q c:\myshare

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.



"Gretchen L. Thiele" <gretchen AT PRINCETON DOT EDU>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
02/12/2004 10:00
Please respond to
"ADSM: Dist Stor Manager"


To
ADSM-L AT VM.MARIST DOT EDU
cc

Subject
Re: Client/Server Expiration Problem (long post)






Hi Andy,

That's what I'm doing, but I'm not seeing the results that you are.
I do notice that there is a difference in the servers we are both
using, yours is v5.2.0.0 (Windows) and mine is v5.2.2.1 (AIX).

What your output shows is exactly what I want to happen... either
a problem with the platform or the version?

Andrew Raibeck wrote:

> OK, I'm probably missing something in what you are saying, but I still
> don't understand. Excluded files are expired during regular (full)
> incremental backup processing. Nothing has changed in that regard. Using
> EXPIRE has the same effect as EXCLUDE: The files are expired on the TSM
> server and managed per criteria as deleted files (i.e. subject to
> VERDELETED, RETEXTRA, and RETONLY).
>
> I've attached sample data for directory c:\amrtest. The steps I
performed
> are as follows:
>
> a) Ran QUERY BACKUP to show the existing active and inactive versions.
>
> b) Defined a client option set that contains an EXCLUDE.DIR statement
for
> c:\amrtest (not shown here).
>
> c) Ran INCREMENTAL. Note the expiring files.
>
> d) Repeat (a) above. This time note that there are fewer versions
(VERE=5,
> VERD=2). All versions are inactive and will expire per management class
> criteria.
>
> Is there anything here that does not accomplish what you wish? By the
way,
> the EXPIRE command would do the same thing: leave the 2 versions due to
> VERDELETED, which will expire based on RETEXTRA and RETONLY value.

Gretchen Thiele
Princeton University