Hi, David -
That QuickFacts entry harks back to sharing via physical library partitioning. I'll update that to be more in tune with current regimens.
Looking through various TSM manuals and redbooks over time shows them generally recommending not using MOUNTLimit=DRIVES; rather, the number of drives should be explicitly coded. (One reference is redbook "Using Tivoli Storage Manager in a SAN Environment".) From a systems programmer perspective I wholeheartedly agree with explicit specification, given the number of times I've seen technologies get numbers wrong in discovery processes.
I'm not sure what you mean by "locally allocated"...which may imply that you have more going on there than I first thought in terms of library management. Here's a quote from the Admin Guide which may relate to a more complex environment:
"For environments in which devices are shared across storage applications, the MOUNTRETENTION setting should be carefully considered. This parameter determines how long an idle volume remains in a drive. Because some media managers will not dismount an allocated drive to satisfy pending requests, you might need to tune this parameter to satisfy competing mount requests while maintaining optimal system performance."
Richard Sims
On Apr 5, 2005, at 8:19 AM, David Nicholson wrote:
Thanks for the reply Rich...
I am curious about the following from Quick Facts
In a library shared by multiple servers, you need to define the number of drives actually allocated to each server; otherwise, if you let DRIVES prevail, each server may think it should have access to all the drives in the library.
This is a library sharing environment and devclass's on both servers are set to MOUNTL=DRIVES. This is the way I have had it set up for a couple years and I have not noticed it being a problem before. Actually, I thought it was recommended to use MOUNTL=DRIVES...but Quick Facts says otherwise. Far be it from me to question a quick fact........buuuuttttt it seems lowering the MOUNTL to something less than "drives" would somewhat defeat the idea of library sharing. Does a pre-empt of MOUNTRETENTION only apply if the "idle" drive was locally allocated?
Thanks in advance
David R. Nicholson
Richard Sims <[EMAIL PROTECTED]> Sent by: "ADSM: Dist Stor Manager" <[email protected]> 04/05/2005 07:39 AM Please respond to "ADSM: Dist Stor Manager"
To: [email protected] cc: Subject: Re: ANR8447E .. Mount failed even though several drives in "idle" status
Mount retention is pre-empted to gain access to a drive, providing that no process or session is engaged to use the drive and media. See that msg in http://people.bu.edu/rbs/ADSM.QuickFacts for reasons we have experienced. Check your Devclass MOUNTLimit as the most common cause, plus your Activity Log for accompanying messages.
Richard Sims
On Apr 5, 2005, at 7:23 AM, David Nicholson wrote:
All,
TSM Server 5.2.4.0 (AIX 5.3) 3494 library w/ (15) 3590E
Suddenly (I think) I am getting a LOT of ANR8447E messages. A "q mount" shows several drives in an "idle" state. My mount retention is set to '3'. I thought that the mount retention would be preempted if there was a need to mount a new tape. Can someone confirm or deny this for me? I am finding if I manually "dismount vol xxxxxx" the problem goes away for a bit until I get several "idle" drives again.
