ADSM-L

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

2005-03-16 12:50:40
Subject: Re: Tape went back to private without reason (2)
From: "Prather, Wanda" <Wanda.Prather AT JHUAPL DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Wed, 16 Mar 2005 12:48:39 -0500
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

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