As a general rule I agree with you. I have had instances where a tape
needed to be relabeled (with overwrite=yes) to make it work again.
Basically, with tapes that start causing weird I/O errors and stuff, or
error out from some reason early on after the tape's been loaded (usually
with an actlog message about not being able to real the label, but not
always). The tape wasn't bad as much as something caused the orginal label
to get corrupt or something. I've never figure it out as to the root
cause. But after relabeling it all was fine with that tape from then on.
Usually I have between 2-6 tapes like that a year.
David N. Reiss
UNIX/TSM Systems Engineer
(309)/494-3749
"Prather, Wanda"
<Wanda.Prather@JH
UAPL.EDU>
Sent by: "ADSM: To
Dist Stor To
Manager" ADSM-L AT VM.MARIST DOT EDU
<[email protected] cc
.EDU>
03/16/2005 11:48
AM
Subject
Re: Tape went back to private
Please respond to without reason (2)
"ADSM: Dist Stor
Manager"
<[email protected]
.EDU>
Caterpillar: Confidential Green Retain Until: 04/15/2005
Retention Category: G90 -
General
Matters/Administration
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
----------------------------------------------------------------------
|
