Tristen, Why not just configure the original storage pool to use the new storage pool as it's "next storage pool", then migrate the data rather than performing a "move data" on all the volumes?
For example: 1.Create the new storage pool 2. configure your backup copy groups the original stg pool to use the new stg pool. 2. update the old storage pool to use the new storage pool as it's "next storage pool". (update stg <old_stg_pool_name> next=<new_stg_pool_name>) 3. migrate all data from the old to new storage pool. (upd stg <old_stg_pool_name> lowmig=0) 4. once all data has migrated delete the old storage pool You may also need to update your maintenance script and any admin schedules that perform system maintenance such as backup storage pool, reclaims, etc. -Rick Adamson -----Original Message----- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Tristan Kelkermans Sent: Wednesday, October 09, 2013 12:19 PM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] Move data to another storage pool Hello all, I'm moving content from one storage pool to another one using command move data *volume_name *stg=*other_stg* * * Unfortunately, some volumes stay in 'Filling' status whereas the move data process completed successfully. When I try to move data from this volume again, nothing changes. Also, this volume can be move to another volume in the same storage pool but it takes a completely new scratch volume to do it. When I run an audit volume I can see there are some files in it, but none of these are damaged. A query content doesn't show anything... VOLUME_NAME: N:\TSM_SATA\000E1EF0.BFS STGPOOL_NAME: DISK_VM DEVCLASS_NAME: FILECLASS_SATA EST_CAPACITY_MB: 51200.0 SCALEDCAP_APPLIED: PCT_UTILIZED: 0.0 STATUS: FILLING ACCESS: READWRITE PCT_RECLAIM: 0.0 SCRATCH: YES ERROR_STATE: NO NUM_SIDES: 1 TIMES_MOUNTED: 4 WRITE_PASS: 1 LAST_WRITE_DATE: 2013-09-17 02:09:51.000000 LAST_READ_DATE: 2013-10-09 18:10:45.000000 PENDING_DATE: WRITE_ERRORS: 0 READ_ERRORS: 0 LOCATION: MVSLF_CAPABLE: No CHG_TIME: 2013-10-09 12:08:18.000000 CHG_ADMIN: TRISTAN BEGIN_RCLM_DATE: END_RCLM_DATE: VOL_ENCR_KEYMGR: BLOCK_PROTECT: No Any idea with this issue ? Thanks for you help Regards, *Tristan *
