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.
