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 dl...@theabfm.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 dl...@theabfm.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:ads...@vm.marist.edu] On Behalf Of Richard Sims Sent: Tuesday, March 03, 2009 9:34 AM To: ADSM-L@VM.MARIST.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
