ADSM-L

Re: [ADSM-L] NTUTIL Erase Tape causes an error after checkin and labeling the tape.

2009-03-03 10:44:08
Subject: Re: [ADSM-L] NTUTIL Erase Tape causes an error after checkin and labeling the tape.
From: Daniel Lane <dlane AT THEABFM DOT ORG>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Tue, 3 Mar 2009 10:41:11 -0500
Richard,

Thank you for the information.  

We are erasing the tapes because clients were writing to the tapes and the data 
was unencrypted.  We verified the data was unencrypted by using DD and NTUTIL 
being able to read data off of the tapes.  Tivoli unfortunately does not allow 
us to erase the tape only delete the reference of the data on whatever tape 
from its database.  Not exactly a delete! Our only option was an erase of the 
tapes using a long erase to verify the unencrypted data was truly gone.

We had done a degauss of two tapes and tested them. You are right in that if 
you degauss a LT0-3 or newer tape the eprom will be erased. The data is gone 
though! Thus why we decided it was MUCH slower but better to erase the tapes as 
to not damage a 100 dollar tape times 300.00.  Although we are having this 
issue of TSM not reading the tapes even though they were not degaussed but only 
erased.  These tapes all functioned before the erasure.

We are using a 3494 tape library with three drives.



Thank You,
Dan Lane
Systems Administrator
The American Board of Family Medicine, Inc.
(859) 269-5626 - Ext. 293
(859) 338-8734 - Cell Phone
dlane AT theabfm DOT org - Email
"This email message and any attachments are confidential and may be privileged. 
If you are not the intended recipient, please notify the American Board of 
Family Medicine immediately -- by replying to this message or by sending an 
email to dlane AT theabfm DOT org. If you are not the intended recipient, you 
must immediately destroy all copies of this message and any attachments without 
reading or disclosing their contents. Thank you.
For more information regarding the American Board of Family Medicine, please 
visit us at https://www.theabfm.org/.";


-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of 
Richard Sims
Sent: Tuesday, March 03, 2009 9:34 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] NTUTIL Erase Tape causes an error after checkin and 
labeling the tape.

On Mar 3, 2009, at 8:45 AM, Daniel Lane wrote:

> Richard,
>
> I cannot seem to find the tech note you are speaking of.

Using a Web browser, navigate to HTTP://www.ibm.com
There, you will find a Search box.
Enter the IBM document number, 1193760, and click on Search.

>
> When labeling the tapes does it not write it to the volume itself?

Yes...it tries to, ultimately depending upon the tape drive to do the
deed.  If the tape drive fails to do that, then there will be no label
on the tape.  TSM depends upon the tape drive, through the device
driver, to feed back accurate results regarding the instructed
operation.  Assure having current microcode levels on the drives and
current driver levels to assure full compatibility and best results.
And, of course, the tape-protect toggle on the cartridge needs to
allow writing.  Also, most modern tapes should not be degaussed, if
they are to be later used, as that will destroy the servo track on
359x and similar tape types.

>  When TSM uses the volumes does it not read the barcode?  Is there a
> way for it to AUTO use the barcode?  It seems as if the label is not
> written to the tape itself. Some of the tapes are used the first
> time after the erase and when TSM goes to use it again it fails to
> read the volume marking it unavailable.

We know, certainly by virtue of error messages, that TSM wants to
verify media labels, to assure that the correct volume is in use.
Stickers are not the most solid means of validating volume identity.
Having trouble reading tape labels is very unusual, and may reflect
faulty hardware and/or software, or invalid procedures.

You haven't revealed why you are performing the erasures, which is an
unusual and time-consuming operation to perform on tapes.  If there
isn't a good reason, don't do that.

>
> I did look into the actlog and tsm loads the tape into the drive it
> needs and then fails when reading the label. The actlog also shows
> the labeling of the tape as being successful.

You need to pursue evidence and isolate the problem cause, beginning
with inspecting the tapes for labels.  (In ADSM QuickFacts, under
"Tape labels, verify", I show how to do this using tapeutil in a Unix
environment.)  I'd suggest freshly labeling a tape via Label
Libvolume, verifying that it has internal labels, and if so then go on
to try TSM operations with it.  If that works, track the tape over
time to see if there are any later problems.  As per my previous
posting, make sure that no extraneous activity in your environment is
writing over the tapes.  If labeling fails, you have a clear-cut case
to follow, via ntutil and similar tape testing.

You might also look into the AUTOLabel parameter of DEFine LIBRary as
an alternate method to label tapes.  In a somewhat older TSM server,
you could employ the dsmlabel command to label tapes, at least as
verification that the drive and tape are cooperating to do this.

In some environments, it may be the case that encryption is in effect
to encrypt everything that is written to the tape.  If a tape is
prepared that way, and then subject to use in a non-encryption manner,
there will certainly be problems trying to read it.

    Richard Sims