ADSM-L

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

2005-03-16 19:30:35
Subject: Re: Tape went back to private without reason (2)
From: John Monahan <JMonahan AT COMPURES DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Wed, 16 Mar 2005 18:37:20 -0600
First let me say that this message mostly applies to SCSI tape libraries,
typically 3494 shops are sharing the library and will have a different
procedure for labeling/checking in tapes, due to category assignments,
volser ranges, etc.

TSM still protects you from overwriting a label and losing data, even if
you choose "label libv overwrite=yes".

>From "help label libv"

OVERWRITE

Specifies whether the server attempts to overwrite existing labels.  This
parameter is optional. The default is NO. Possible values are:

No

Specifies that the server only labels unlabeled volumes. For StorageTek
VolSafe volumes, you must specify NO.

Yes

Specifies that the server overwrites existing labels only if both the
existing label and the prompted or bar code label are not already defined
in either the server storage pool or volume history list.



How you checkin tapes is a matter of personal preference - like most things
in TSM there is more than one way to accomplish the same task.  Using label
libv to checkin tapes will work just fine because it won't overwrite labels
for tapes that exist in a storage pool or in the volume history file.  It
will also catch any new tapes that are added to the scratch pile in the
future (without them being labeled first).  Additionally, it will not
accidentally checkin private tapes as scratch giving you the standard error
message as if you were trying to do a "checkin libv status=scratch" on a
private tape.  i.e. if someone puts a valid private tape in the I/O door
and runs the "label libv checkin=scratch overwrite=yes ......" it will not
overwrite the label because the volume exists in a storage pool or volhist
file, and it will not checkin the tape as scratch for the same reason.
This is also from "help label libv":

CHECKIN

Specifies whether the server checks in the volume. This parameter is
optional.  The following are possible values:

SCRatch

Specifies that the server checks in the volumes and adds them to the
library's scratch pool. If a volume has an entry in volume history, you
cannot check it in as a scratch volume.



The addition of "autolabel yes" in more recent versions of TSM basically
handles the cases of brand new unlabeled tapes that was only solved in
earlier versions of TSM by checking in all tapes using "label libv" (unless
you wanted the pain of manually labeling all new tapes).  I have used the
label libv checkin method for several years and have never lost data.  In
my experience, most of my customers with SCSI libraries will have a box
full of scratch tapes.  They replace the same amount of tapes that were
checked out that day with an equal number from this scratch box, and these
will be checked in later in the day (the library is kept full).  When the
scratch box starts to get empty they order more tapes and throw them in the
box.  With label libv checkin method, they didn't have to worry about ever
manually labeling tapes or which ones were new vs old, etc. etc. - all they
needed to do was take out tapes and replace with same amount from scratch
box - simple and easy.

______________________________
John Monahan
Senior Consultant Enterprise Solutions
Computech Resources, Inc.
Office: 952-833-0930 ext 109
Cell: 952-221-6938
http://www.computechresources.com



                                                                       
             "Prather, Wanda"                                          
             <Wanda.Prather@JH                                         
             UAPL.EDU>                                                  To
             Sent by: "ADSM:           ADSM-L AT VM.MARIST DOT EDU            
             Dist Stor                                                  cc
             Manager"                                                  
             <[email protected]                                     Subject
             .EDU>                     Re: Tape went back to private   
                                       without reason (2)              
                                                                       
             03/16/2005 11:48                                          
             AM                                                        
                                                                       
                                                                       
             Please respond to                                         
             "ADSM: Dist Stor                                          
                 Manager"                                              
             <[email protected]                                         
                   .EDU>                                               
                                                                       
                                                                       




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

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

<Prev in Thread] Current Thread [Next in Thread>