Actually, Nick we think there really is a bug. I saw something similar once on Netbackup. Essentially, the 3494 inventory count got off from the actual number of entries presented in the SEARCH=YES type CHECKIN equivalent in NetBackup. After we ran a full offline inventory of the library the problem went away for a week or two and would come back. Eventually, we got a LM code level that apparently fixed the corruption problem. Have not seen it for a long time.
-----Original Message----- From: Nicholas Cassimatis [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 19, 2002 10:07 AM To: [EMAIL PROTECTED] Subject: Re: 3494 Volume Stealing This falls under the old "Measure twice, cut once" rule. If you're sharing a library and NOT doublechecking yourself, you're asking for trouble. Plain and simple. Don't describe a "defect" to something that is working at the level it's designed to. The nice thing about a shared library is you can have a pool of "spare" tape to assign to any server you want to, as needed. Checkout and checkin of tape can be a destructive process, and shouldn't be taken too lightly. Nick Cassimatis [EMAIL PROTECTED] Today is the tomorrow of yesterday. "Orville L. Lantto" To: [EMAIL PROTECTED] <orville.lantto@D cc: TREND.COM> Subject: Re: 3494 Volume Stealing Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED] .EDU> 03/15/2002 05:43 PM Please respond to "ADSM: Dist Stor Manager" The volume which was "stolen" was checked in to another TSM server with that server's scratch category code (verified by mtlib). Yes, this is very disturbing! Orville L. Lantto Datatrend Technologies, Inc. (http://www.datatrend.com) 121 Cheshire Lane #700 Minnetonka, MN 55305 Email: [EMAIL PROTECTED] V: 952-931-1203 F: 952-931-1293 C: 612-770-9166 "Seay, Paul" <[EMAIL PROTECTED]> Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> 03/15/02 03:15 PM Please respond to "ADSM: Dist Stor Manager" To: [EMAIL PROTECTED] cc: Subject: Re: 3494 Volume Stealing Yes and no. Once a tape is ejected from the library, when it is reinserted, it is anybody's game because it does not belong to a specific TSM server. It is in FF00 status. So, if you do a checkin command with a range, search=yes, another TSM Server could get it. This is why I do checkin commands with a specific volume id when I checkin each tape. At Share we have asked for a function to be added in general to setup an include table for each TSM server. This include table would limit what ranges of tapes are allowed to be picked up by that TSM server instance. Now, if the tapes are already in the library and assigned a scratch or private category and the tapes can be stolen, that is a major problem that support needs to know about. I have never tried to see if I can cause one TSM to steal tapes from another TSM server this way. -----Original Message----- From: Orville L. Lantto [mailto:[EMAIL PROTECTED]] Sent: Friday, March 15, 2002 2:51 PM To: [EMAIL PROTECTED] Subject: 3494 Volume Stealing I just tested a problem brought to me by one of my clients. They have one 3494 library shared by four TSM Servers. Using 4.2.1 TSM, properly configured with different 3494 Categories, it is possible for one TSM server to steal a volume that is checked in to another TSM server. This behavior is not exhibited by 3.7.3. Has anyone seem this? Orville L. Lantto Datatrend Technologies, Inc. (http://www.datatrend.com) 121 Cheshire Lane #700 Minnetonka, MN 55305 Email: [EMAIL PROTECTED]
