On Tue, 28 Oct 1997, ALLEN BARTH wrote:
> Tom,
>
> If I understand you correctly, you'd like to see the tape
> rewound/unloaded and the drive freed. I think that would be a very
> BAD design, operationally speaking. One must remember that ADSM is
> 24x7 software. Hence, it is entirely possible that while doing a move
> data tape->disk, one or more disk pool volumes could be deleted. That
> being the case, files that *would* have fit in the diskpool won't
> anymore, and must go to the next stgpool. If that next stgpool is
> tape and it got demounted after the first file got moved, there is a
> possibility that another subtask will allocate that drive, holding up
> the move data task. Even if another task didn't allocate the drive,
> the amount of time it takes to mount/locate...write...rewind/unload is
> comparatively large and non productive.
>
> Just my thoughts,
> Al Barth
> Zurich Kemper Investments
>
>
Thanks for your answer/thougts..
I've been thinking the same way. However, if this is the idea begind the
design I still have some problems whith this thought.
The volumes from which I move data are non-collocated. The
target-disk-pool is collocated. (Well.. it's next stg pool is a collocated
tapepool).
Then, if another file from another client on the same input-volume has to
go directly tape, most likely another output-volume will be needed
(because of the collocation). And this volume and tapedrive should be
locked for the rest of the process. What would happen then if more
output-volumes are needed than the number of drives in the library?
Since this is not what happens I have dropped my thougs on this.
What happens, is that if another outputvolume is needed, the previous
volume is dismounted and the new volume is mounted. And the last mounted
volume (if any) stays mounted for the rest of the process.....
The only good reason for this design I can think of is for saving
time om dismount/mounting the same tape-volume if most or several files
from the same client wont fit in the diskpool. This har not been the case
for any of the volumes I have "moved" so far...
(I know this move-operations are not neccessary to migrate from a
non-collocated to a collocated tapepool. This could be done automagically
by reclamation over time..
Our problem is that we have a corrupted database-page. We know which
client and files this page "pints to", byt not exactly which tapes in the
storagepool these files are located. The storagepool has about 200 volumes
defined in it, and reclamation is set to 100% to avoit "touching" the bad
page. This happened nearly one year ago, and now we are running out of
free slots in the library. Since IBM so far has not been able to solve the
problem I have now started to move data "by hand" from the volumes which
do not contain files/directories "pointed to" in the bad page..)
|
