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
