Replying to: David Cannon <cannon AT US.IBM DOT COM> (Mon, 5 Jan 1998 12:16:46
-0500)
I *know* that there is a problem whith volume 1588U6. What I wasn't
I *know* that there is a problem whith volume 1588U6. What I wasn't
expecting was that ADSM would keep on trying to use a tape that it had
prevoiusly marked READONLY due to writing errors. I consider this behavior
quite unacceptable.

In this case, we had a nightly backup failure due to ADSM spending more than
4 hour trying to use a bad tape. I think it's a bit strange to have the
whole backup depending on a tape failure...

IMHO, ADSM should never release a bad tape to scratch without confirmation
from an operator.

>> During an archive,
>> 1. - Volume 1588MK reaches EOV
>> 2. - SCRATCH volume 1588U6 is mounted and defined to the storage pool
>> 3. - About 2 minutes later and error is found on volume 1588U6
>> 4. - Volume 1588U6 is dismounted and marked readonly
>
>> Now for the strange bit:
>
>> 5. - Volume 1588U6 is deleted (and thus returned to SCRATCH)
>> 6. - Volume 1588MK is mounted again
>
>> And it loops to 1. and keeps repeating this over and over and over...
>
>The server writes to 1588MK until it reaches EOV, and then continues
>with scratch volume 1588U6.  When it encounters the error on 1588U6, it
>rolls back the transaction so 1588MK is left in Filling state and
>1588U6 is returned to scratch.  Because the transaction is rolled back,
>the database has no history that this has occurred.
>
>> Does anybody know if it can be worked around by seting REUSEDELAY?
>
>I don't think that REUSEDELAY will help.  The root cause of the problem is
>the recurring error on 1588U6.  Either resolve the problem with that volume
>or eliminate the volume.
>
>Dave Cannon
>ADSM Development


--
Rui Malheiro,
Rui Malheiro,
6 Mil - Tecnologias de Informacao
URL: <http://www.6mil.pt/>