Re: Tape went back to private without reason (2)

I use the AUTOLABEL=YES on the library definition. Saves me the headache
when operations puts new tapes in without telling they got new tapes!

I did find that if a Storage Agent mounts a tape that isn't label'd it will
reject it even though AUTOLABEL=YES is turned on for the library.

It's still a good practice to LABEL LIBV new tapes, but AUTOLABEL=YES has
saved my bacon on a few occasions.

I also don't like OVERWRITE=YES. If there's a label on the tape I want to
know about it and check it myself. Even though TSM is doing that for
me...call me a control-freak, but all it takes is one little APAR where TSM
fails to check that the tape can be re-label'd and my data is gone. So far I
haven't opened an APAR on myself for that function. I use OVERWRITE=YES only
when I'm sure.

Bill Boyer
DSS, Inc.

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Prather, Wanda
Sent: Wednesday, March 16, 2005 12:49 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Tape went back to private without reason (2)

I agree that this should be done with NEW tapes, but I disagree with using
OVERWRITE=YES as a standard practice.

To review:

Tape libraries require bar code "labels" on the OUTSIDE of the tapes.
TSM ALSO requires an internal "label", written at the beginning of the tape.
The internal label must match the external bar code.

Every time TSM mounts a tape, it checks the internal label to make sure it
is using the correct tape.
It also checks its data base, to make sure that tape is SUPPOSED to be
written on.
This is MAJOR feature of TSM in safeguarding your data.

The purpose of the LABEL LIBV command, is to create the intenal label on the
tape.
So as Richard says, the FIRST TIME you use a NEW TAPE, you must run LABEL
LIBV to create the internal bar code.

You may also specify CHECKIN on the LABEL LIBV command, so that you don't
have to run a separate CHECKIN.

You only use LABEL LIBV the FIRST TIME.  
Once the tape has the internal label, you should NOT try to rewrite it. 
If there is data on a tape,  running LABEL LIBV on the tape with
OVERWRITE=YES will destroy the data.
OVERWRITE=YES is not needed, if the tape hasn't already been labelled.

You should NEVER have to run LABEL LIBV a second time, just to check in
scratch tapes.  (If so, there is something wrong with your procedures.)  And
if you specify OVERWRITE=YES, you disable TSM's ability to protect you from
overwriting good data.

The only time you need to use OVERWRITE=YES, is if for some reason you need
to change the barcode on the OUTSIDE of the tape.  Then you must use
OVERWRITE=YES and recreate the internal label so that it matches the new
barcode, AFTER you have removed all good data from the tape using RECLAIM or
MOVE DATA.

Wanda Prather
"I/O, I/O, It's all about I/O"  -(me)


 
 



-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Richard van Denzel
Sent: Wednesday, March 16, 2005 5:47 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Tape went back to private without reason (2)


Mark,

This is not the way to check in new scratch tapes, this should be done by 
using the command:

LABEL LIBV <library> SEARCH=YES LABELS=BAR CHECKIN=SCR OVERWRITE=YES

Richard.





Mark Strasheim <ms AT DEFINITIV-BA DOT DE>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
16-03-2005 11:46
Please respond to "ADSM: Dist Stor Manager"
 
        To:     ADSM-L AT VM.MARIST DOT EDU
        cc: 
        Subject:        Tape went back to private without reason (2)


Aloha

Sorry i forgot to say:
I checked the actlog, and took the error code ANR8355E, which i allso look 
up.
What is ment by prelabeled? I use barcode which are sticked onto the tape.
I check them in, with checkin libvolume with search=yes. I'm pretty sure,
that i check in the first tapes the same way.

 
>>i have put 10 new Tape into the Library. I marked them with scratch. 
After 2 days
>>they all went back to private, so i change them back to scratch ... this 
"game"
>>i am playing for one week now, and i am tried. I can't see any reason 
why this happens. 
>>Maybe anyone of you can make some sence of it. 


with regards

Mark Stasheim

----------------------------------------------------------------------

                 definitiv! business applications GmbH & Co. KG
                 Fresnostrasse 14 - 18 · DE-48159 Münster
                 Tel. +49 (0) 251 21092 - 23 · Fax +49 (0) 251 21092 - 29
                 <mailto:ms AT definitiv-ba DOT de> mailto:ms AT definitiv-ba 
DOT de ·
                 <http://www.definitiv-ba.de/> http://www.definitiv-ba.de

----------------------------------------------------------------------