On Tue, Apr 22, 2003 at 03:19:25PM +0200, Karel Bos wrote:

> If you have the Scratch Volume set to no, the volume will be part of the
> defined storage pool even if it is empty. It will not return to the scratch
> pool.

I know, this is the intended behaviour in this case. The problem is that
TSM decided that it is a scratch tape anyway, and now the tape is both
scratch and defined in primary pool PRIM03.

> However, I don't think that is the reason of the drive errors. I would do an
> audit vol fix=yes (should be fast because the volume is empty), delete

I did a DELETE VOLUME, so it was removed from PRIM03. It remained scratch.
I then did a BACKUP DATABASE on that tape, and that failed with the same
error. I checked out the volume, and used LABEL LIBVOLUME to check it back
in (overwrite=yes). The label libvolume also failed, so there is something
physically wrong with 659ACP after all.



However, this doesn't explain why the volume was both scratch and private
to a storage pool. I used that storage pool a test for the new 5.1 feature
of writing directly to both primary and copypool, so this might have
something to do with it. I contacted IBM Support, which resulted in a fix
of the symptom, but not the root cause.


--
Jurjen Oskam

PGP Key available at http://www.stupendous.org/