The upgrade is on the books.  Was this fixed in 5.5?  Did you reset your 
storage pool volumes all at once like a script?  or one at a time?  Thanks for 
your response!
Brett

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of 
David E Ehresman
Sent: Thursday, September 24, 2009 2:27 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] discrepancy between primary pool and copy pool

Back when I was running a version of TSM with that bug, I did a reset on all 
storage pool volumes each day.  Fortunately, its been long fixed on supported 
versions of the server.  Upgrade!

David

>>> "Whitlock, Brett" <brett.whitlock AT COUNTRYFINANCIAL DOT COM> 9/24/2009
>>> 1:26 PM >>>
Friends of TSM,

I run scripts to compare the number of files and G in my primary pools and copy 
pools.  Sometimes they don't match up.  I run an extra backup stg and it says 
'no data to copy'.  The work around on this is to go through the primary pool 
volumes and do a Q CON volume COPIED=NO.  Once you find the volume in error you 
do a RESET BACKUPOPTIMIZATION volume and Re Run the backup stg again.   This is 
tedious and database intensive.  Luckily this was a small storage pool.   
Anybody come up with a select statement to search for  volumes with a copied=no 
status?  Also, I was wondering about just doing a reset backupoptimization on 
all the storage pool volumes??

TSM 5.3.4.2 server on Windows using server to server remote copy volumes.

Thanks,
Brett