|
Re: [ADSM-L] How do tapes get assigned to proper owneship in TSM Library Sharing?
2007-09-24 11:24:24
Another way to sync up the owner list
is to go to each library client and run an audit libr libname checkl=barcode.
That forces each library client to go to the library manager and
in turn the library manager will update the owner list.
|
Wachovia Confidential: The information
transmitted is intended only for use by the addressee and may contain confidential
and/or privileged material. Any review, re-transmission, dissemination
or other use of it, or the taking of any action in reliance upon this information
by persons and/or entities other than the intended recipient is prohibited.
If you received this in error, please inform the sender and/or addressee
immediately and delete the material. |
"Schneider, John"
<schnjd AT STLO.MERCY DOT NET>
Sent by: "ADSM: Dist Stor Manager"
<ADSM-L AT VM.MARIST DOT EDU>
09/24/2007 11:02 AM
|
Please respond to
"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> |
|
|
To
| ADSM-L AT VM.MARIST DOT EDU
|
|
cc
|
|
|
Subject
| [ADSM-L] How do tapes get assigned to
proper owneship in TSM Library Sharing? |
|
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: schnjd AT stlo.mercy DOT net
Office: 314-364-3150, Cell: 314-486-2359
|
|
|
