Hi, we just had to fix a drive sensor problem, symptom was "tape
write-protected".

In fact the tapes were all right, only the sensor in the drive was in error
(hardware),

I'm not sure if this is related to your problem, just in case...

                René LAMBELET
                NESTEC  SA
                GLOBE - Global Business Excellence
                Central Support Center
                SD/ESN
                Av. Nestlé 55  CH-1800 Vevey (Switzerland) 
                tél +41 (0)21 924'35'43   fax +41 (0)21 924'45'89   local
REL-5 01
                mailto:rene.lambelet AT nestle DOT com

                This message is intended only for the use of the addressee
                and may contain information that is privileged and
confidential.


-----Original Message-----
From: Bos, Karel [mailto:Karel.Bos AT ATOSORIGIN DOT COM]
Sent: Tuesday,20. July 2004 13:50
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Write Protected tapes not set to ReadO - and Mounted Again
and Again....


Hi Richard,

There where plenty of other scratch tapes available for use, so it seems to
be an other issue. We will contact Tivoli support to report this behavior.

Thanx,

Karel

-----Original Message----- 
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU]On Behalf Of
Richard Sims
Sent: dinsdag 20 juli 2004 13:37
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Write Protected tapes not set to ReadO - and Mounted Again
and Again....


>One of the tapes needed for back-up stg Tape to Copy appeared to be set
>to write protect. I expected ITSM to set the tape to READO and never ask
>for it again as long as it wasn't fixed. To my surprise ITSM didn't set
>the tape to READO and tried to write to it again, again failing the
>process and not setting the tape to READO.
...

Hi, Karel:

As you say, that behavior certainly doesn't make a lot of sense.  The
Messages
manual fails to specify how TSM treats the tape after the ANR8463E message
which
acknowledges TSM's understanding that the volume is write-protected, and I
don't
see any items on the IBM site addressing the behavior except for a 2002 APAR
IC35232 which says that the code was fixed to handle your case, of a library
manager failing to report the tape's status to the library client.
Question on context:  Was it the case at the time that TSM was short on
tapes,
which *might* have incited it to keep trying the bogey?

>Question: Is it working as designed?

If it is, then certainly redesign is in order.  In any case, this is worth
reporting to TSM Support.

   Richard Sims