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 asr AT ufl DOT edu 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.
|
