No, that is not what I meant. I realize I will eventually need to reconfigure all of the TSM servers. I just wanted to reconfigure in an optimal way or was hoping to not have to drag drives from one library manager to another and possibly back and forth, if needed.
As I mentioned, I was hoping for some "smart" sharing of devices since TSM does manage the drive usage. As for the 6/8 volsers, I am just letting the new LM server reinitialize the tapes as 8-chars. Stuart Lamble <[EMAIL PROTECTED]> Sent by: "ADSM: Dist Stor Manager" <[email protected]> 07/26/2007 08:13 PM Please respond to "ADSM: Dist Stor Manager" <[email protected]> To [email protected] cc Subject Re: [ADSM-L] Sharing a 3583 library On 27/07/2007, at 1:43 AM, Zoltan Forray/AC/VCU wrote: > Thanks for the reply. I already have things configured like this. > > What I was hoping for was zOS/MVS sysplex sharing smarts (for you > mainframe folks). With a properly configured sysplex, the drives are > configured and online to all systems at the same time and the OS > figures > out which drive is in use by which system and which drives are > available > and choses acordingly, not stepping on any other system. I was > hoping the > SAN type libraries were smarter and that multiple TSM library > managers > could just figure out what drives are available and use them > accordingly. > > I wanted to avoid an all-or-nothing reconfiguration since I need to > move > library management/ownership to my new TSM server (phasing out the > old AIX > server currently owning the 3583's) and having to reconfigure all TSM > servers that currently share the libraries. So if I understand you correctly, you will eventually be moving the library management completely to the new server, but you want to avoid reconfiguring all the existing TSM instances? I've just completed moving two library managers from one TSM instance to another (the "new" manager is dedicated solely to library and configuration management, where the "old" managers also served backup duties.) It turned out to be remarkably easy: * Delete the old paths, drive definitions and library definition on the old library manager (and the new library manager if it's currently a library client). * Define the library, drives, and paths on the new library manager (setting the drives to offline, so no tapes are accessed until you're finished.) * Checkin the libvols on the new library manager (CHECKIN LIBVOL X search=yes stat=scratch checkl=barcode) * Update the old library clients (UPDATE LIBRARY X PRIM=new_lib_manager on all instances) * Create a library definition on the old library managed (of type shared, pointing at the new library manager.) * Run an AUDIT LIBRARY on the library clients (including the old library manager). * Set the drives to online, and you're away. The audit on each client will set tapes with data to private status, owned by the relevant client. If you're paranoid about this, check them in as private, owned by the new library manager, and make a note of the scratch volumes known by the old library manager before deleting the library definition (query libvol). The audit will update the ownership to the correct node, you can manually update the remaining volumes to be scratch, and chase up the remaining volumes owned by the new library manager (assuming it didn't own any volumes beforehand) as potentially orphaned - we found some 30 tapes that should have been returned to scratch by the clients, but the library manager hadn't updated them for some reason so they were still marked as being private. As for the 6/8 character volume label: I can't speak for a 3583, but we're using a pair of 3584 libraries. In the web-based management system, there's a section for "Library", "Logical Libraries"; have a look at the "modify volser reporting" option - it might help. Note that this will likely affect *all* volumes, so if you have data stored on volumes with a mix of 8/6 volume serial numbers, you're in trouble ... Hope this helps.
