We used to do this by starting a move data on volume XXX, then looking in
the activity log for messages like "Volume 12345 is expected to be mounted".
Those messages listed the OTHER volumes that held pieces of files from
volume XXX.
Ugly... worked, though.

> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU]On Behalf Of
> Thomas Denier
> Sent: Monday, September 10, 2001 1:57 PM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: space reclamation question
>
>
> Quoting Zlatko Krastev/ACIT <acit AT ATTGLOBAL DOT NET>:
>
> > the one which is below the reclamation threshold (the source) -
> > look at "q vol"
> > and a scratch or private volume for the stg pool (the destination) -
> > "def vol" or "upd stg maxscratch=<nnn>"
>
> Backup files are sometimes segmented and spread across two or more
> storage pool volumes. If a volume below the reclamation threshold
> contains one segment of such a file the volumes containing the
> other seqments will also be required as input volumes for reclamation.
> I don't know of any elegant way to identify the other volumes in such
> cases. The ugly way I am aware of starts by running a pair of "query
> content" commands with "count=1" and "count=-1" against the below
> threshold volume to find out whether that volume starts or ends with
> a segmented file. If it does, one can run similar commands against
> the other volumes in the same storage pool and look for matching
> file names.
>