The old query content command can provide information which could give the answer if properly massaged. I can get the information but I am weak on the massaging.
This macro will generate another macro to issue query content commands with count=1 and count=-1 parameters which say to report on the first and last file on the tape. set sqldisplaymode w commit select cast('q con '||volume_name||' count=1' as char(80)) as cmd - from volumes - where stgpool_name='TP1_COPY2' and status in ('FULL', 'FILLING') > qcon2 select cast('q con '||volume_name||' count=-1' as char(80)) as cmd - from volumes - where stgpool_name='TP1_COPY2' and status in ('FULL', 'FILLING') >> qcon2 then edit qcon2 to remove the headers and run it as a macro, redirecting to a 3rd file - tsm: LIBRARY_MANAGER>macro qcon2 > qcon3 Output of command redirected to file 'QCON3' Massage qcon3 and sort it to find duplicate names which indicate a tape chain. The thing that needs to be massaged is to put the volume name on the output line and unwrap long filenames. Hope this helps, Bill Colwell At 03:28 PM 2/23/2005, you wrote: >On Wed, 23 Feb 2005 [EMAIL PROTECTED] wrote: > >> In order to reclaim a given volume, you really need three different ones: The >> target volume, and the volumes "adjacent" to the target: The one with the >> other half of the aggregate which comes first on the target volume, and the >> one with the other half of the aggregate that comes last. >> >> I don't think I've been able to find a way to find which volumes these are >> without actually running the expiration or move data and failing the mount. >> Is there a good way to find this information out? > >If I understand your scenario correctly, then I think I've run into this. > >My not-so-elegant solution was to start an 'audit volume' on the tape that >I intend to run a 'move data' against. If it's the only tape needed, then >the audit will start up okay and can be cancelled; if there's at least one >other tape needed, audit will complain that a required volume is offsite, >specify the needed volume, then terminate. Unfortunately, audit only >specifies *one* required offsite volume, so you have to do another audit >after the needed volume is marked onsite in order to see if a 2nd offsite >volume is needed. > >I thought about trying to script this to the point where you could at >least know all of the volumes needed before ever inserting any tapes; that >way you could make only one 'offsite trip'. I think that would involve >marking a volume onsite before inserting it, attempting the audit, >capturing the needed volume name if the audit fails, cancelling the audit >if it doesn't (and maybe dealing with a failed mount?), etc. I never >actually spent any time coding/testing this, though. > >This is admittedly very ugly; I tried getting IBM to give me some SQL that >could *quickly* determine the needed volumes, but was told it's not >possible. I'm not sure why...presumably it has to do with the "it's not >really a relational db, and the SQL interface is only a convenience good >for some things" business; all I know is that audit knows *immediately* >which other volume is needed. > >Fortunately for me at least, I no longer have a need to do this sort of >thing. > >Regards, >Bill > >Bill Kelly >Auburn University ---------- Bill Colwell C. S. Draper Lab Cambridge Ma.