Greetings, We have a configuration with 7 TSM servers all sharing the same library using TSM Library sharing, where one instance is the Master, and the others all view the library as owned by the Master, and appeal to it for tape mounts, etc. This configuration has worked fine, but there is one problem with it that I wish I could easily solve. I could write a script to solve it, but before I do I thought I would appeal to the list to see if there is something in the native functionality to solve it.
Every now and then, like this last week when we added tape drives to the library, a circumstance forces us to completely delete the paths, the drives, then the library, and recreate them in order to pick up the changed/new element numbers in the library. We have macros in place to make this relatively painless to execute, so that is not the problem. After we redefine the library, the library inventory is cleared and we have to check all the private and scratch tapes back in. Still no big deal. But when we do that, all the tapes ownership disappears. Before the upgrade, a 'query libvolume' shows: SUN1018 100120L4 Private MDCTSM03 Data 1,145 LTO SUN1018 100121L4 Private MDCTSM03 Data 1,146 LTO SUN1018 100122L4 Private MDCTSM03 Data 1,147 LTO SUN1018 100123L4 Private MDCTSM02 Data 1,148 LTO SUN1018 100124L4 Private MDCTSM03 Data 1,149 LTO SUN1018 100125L4 Private MDCTSM01 Data 1,150 LTO SUN1018 100126L4 Private MDCTSM01 Data 1,151 LTO SUN1018 100127L4 Private MDCTSM04 Data 1,152 LTO SUN1018 100128L4 Private MDCTSM05 Data 1,153 LTO But afterward it shows: SUN1018 100120L4 Private 1,145 LTO SUN1018 100121L4 Private 1,146 LTO SUN1018 100122L4 Private 1,147 LTO SUN1018 100123L4 Private 1,148 LTO SUN1018 100124L4 Private 1,149 LTO SUN1018 100125L4 Private 1,150 LTO SUN1018 100126L4 Private 1,151 LTO SUN1018 100127L4 Private 1,152 LTO SUN1018 100128L4 Private 1,153 LTO This does not seem to cause any misbehavior on TSM's part. It apparently knows which tapes are owned by which instance, and one by one over the course of time the TSM instances will ask to have these tapes mounted, and when they do, the ownership gets assigned back. But why doesn't the ownership get assigned correctly by TSM when they get checked back in? If we try to check them in search=yes as scratch tapes, TSM will tell us that they can't be assigned a status of scratch, so he knows they are owned by a TSM instance. So why can't TSM assign the ownership at checkin if it knows who the owner is? Is there some way to force this behavior? I am thinking about writing a script which will go through the library volumes one at a time and compare it to the volumes and drm lists from each instance, and issue a 'update libv ... owner=' to put the ownership back the way it belongs. It wouldn't be much to write, but I am still surprised it needs to be done at all. We are running TSM 5.3.5.1 on AIX, in case it matters. Best Regards, John D. Schneider Sr. System Administrator - Storage Sisters of Mercy Health System 3637 South Geyer Road St. Louis, MO. 63127 Email: [EMAIL PROTECTED] Office: 314-364-3150, Cell: 314-486-2359