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:[email protected]] On Behalf Of David E Ehresman Sent: Thursday, September 24, 2009 2:27 PM To: [email protected] 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" <[email protected]> 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
