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/[EMAIL PROTECTED] Internet e-mail: [EMAIL PROTECTED] 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" <[EMAIL PROTECTED]> Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> 02/12/2004 10:00 Please respond to "ADSM: Dist Stor Manager" To [EMAIL PROTECTED] 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