> Oh yes, we see this from time to time.  We used to have a lot more of
> these sorts of errors, and have spent considerable time working with IBM
> on this sort of thing since moving to 3584 libraries.   Early on, a lot of
> tape drives were replaced; sometimes, having the drive calibrated seems to
> help.  We've got microcode upgrades scheduled soon, which I'm hoping
> helps, but that's still an open question.  There doesn't seem to be a good
> fix for this as yet; all we've been able to do is periodically check for
> these tapes and update them, and keep reporting problems to IBM.

I wouldn't hold out too much hope for microcode helping; I see this at
least once every couple of weeks, and it's been this way for many months.
We've got a 3584 with all LTO2 drives.  I upgraded in late August to
library firmware level 5360, drive firmware level 53Y2 and Atape level
9.5.2.0.  As far as I can tell, it hasn't helped (or hurt) in terms of
frequency of the 'failure'.  Went from TSM server 5.2.3.0 to 5.3.1.2, no
change.  Happens on all different drives, different tapes.

When I first started seeing this, I used to audit the tape (always came up
clean), then mark it read/write again.  Now I don't bother with that -
just mark 'em read/write as soon as I see the ANR8463E messages.

-Bill

Bill Kelly
Auburn University OIT
334-844-9917

>
> Hi All,
>   Wondering if anyone else has seen this yet?
>   Volumes scratch and private are being seen as write protected and either
> marked as unavailable (those with data) or private (scratch volumes) When
> I eject the tape its not write protected.  Its a 3584 tape library and I'm
> pretty sure both the gen 1 and gen 2 drives are doing this, but need to
> investigate details more.  All the media is gen 1.
>   TSM server 5.3.1.4 on AIX 5.3 connected via 3534 fiber switches.
>
> 10/13/05 04:04:39 ANR8463E LTO volume 894ACT is write protected.
> 10/13/05 04:04:57 ANR8778W Scratch volume 894ACT changed to Private Status
> to prevent re-access.