ADSM-L

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

2009-03-03 09:36:25
Subject: Re: [ADSM-L] NTUTIL Erase Tape causes an error after checkin and labeling the tape.
From: Richard Sims <rbs AT BU DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Tue, 3 Mar 2009 09:34:21 -0500
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