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.
|
