Beat, unfortunately it is upto us as TSM admins to manage our mountpoint utilization. Thus, in the specific situation of clients backing-up straight to tape, you have to coordinate the scheduling of clients going straight to tape and control (defeat) automatic uses of tape during those periods.
Steffan ----- Original Message ----- From: "Beat Largo" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, March 04, 2002 4:04 AM Subject: Documentation about Mountpoints, the maxnummp parameter and parallel session handling > We get often problems with db2 and oracle db backups being interrupted by > the API because the session was too long in a state of waiting for > mountpoints. We took several measures like increasing the number of > mountpoints in the maxnummp parameter of the node definition. > IBM recommends that you shouldn't define more mountpoints in the node > definition than you actually got. Now we don't understand what exactly is > the meaning of mountpoints. If a mountpoint is a tape drive than we could > define only 4 mountpoints because we got 4 drives for the primary storage > pool. If we would have two clients we could define for each node 2 > mountpoints in the maxnummp parameter. But having approximatively 30 > clients how many mountpoints in the maxnummp parameter should we define? > Also we found that the space reclamation process is mounting files on a > mountpoint giving sometimes the message 'Waiting for mountpoint(s)'. Though > a mountpoint doesn't have to be a tape drive but can also be a file in the > temporary space reclamation disk pool. > In consideration of all those facts we would really be interested in a > extensive documentation about the handling of mountpoints, the maxnummp > parameter and parallel sessions in the TSM environment. > If anyone could help us we would be greatly thankful! > > Regards, > Beat Largo > > Zurich Switzerland > IT SC - Shared Service Center > Storage Management, IFS > > > > > > > > > ******************* PLEASE NOTE ******************* > This message, along with any attachments, may be confidential or legally > privileged. It is intended only for the named person(s), who is/are the > only authorized recipients. If this message has reached you in error, > kindly destroy it without review and notify the sender immediately. Thank > you for your help. > **********************************************************
