How exactly did you 'steal' it from server A to B? I always thought it was the responsibility of the library manager component in the 3494 to handle who owns what. Maybe you should be looking at the code level in the 3494 library manager?? You might want to check out the library manager logs for around the time when you 'steal' this volume.
Whenever I share a 3494 between multiple TSM servers, I use different volume numbering schemes and the CHECKIN command for each server is defined in a server script with the appropriate VOLRANGE= specified. This is then scheduled to run daily with an admin command schedule. Then I educate the client that they should only checkin volumes using the RUN command for the script I created, or better yet just let the schedule command do it for them. Bill Boyer DSS, Inc. -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED]]On Behalf Of Orville L. Lantto Sent: Monday, March 18, 2002 11:53 AM To: [EMAIL PROTECTED] Subject: Re: 3494 Volume Stealing No, I tested with a verified scratch volume from Server A (had Server A's scratch category, verified with mtlib) and "stole" it directly into Server B (resulting in Server B's scratch category on the tape). This should not happen and it is the responsibility of the "host" software to prevent it. In this case TSM has a flaw. My customer has opened a PMR and we are pursuing it through Tivoli support. 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 Allen Barth <[EMAIL PROTECTED]> Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> 03/18/02 10:09 AM Please respond to "ADSM: Dist Stor Manager" To: [EMAIL PROTECTED] cc: Subject: Re: 3494 Volume Stealing It wasn't stolen. I have seen where the 3494 will eject a cart all on its own for various reasons. This action is not sent to TSM. Perhaps the operators saw the tape in the IO door and just pulled it out and put it back in without letting anyone know. Mine have done that several times, the volume is then in FF00 category (free for all). In your case another TSM could have claimed this tape, and a later AUDIT LIBRARY on the rightful owner would leave the 3494 and the TSM's in the state you mention. "Orville L. Lantto" <[EMAIL PROTECTED]> Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> 03/15/02 04:43 PM Please respond to "ADSM: Dist Stor Manager" To: [EMAIL PROTECTED] cc: Subject: Re: 3494 Volume Stealing 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] ******************* PLEASE NOTE ******************* This message, along with any attachments, may be confidential or legally privileged. It is intended only for the named person(s), who is/are the only authorized recipients. If this message has reached you in error, kindly destroy it without review and notify the sender immediately. Thank you for your help. **********************************************************
