Yes, the limit is per DD model.  The model we are using are DD880's.

According to the admin guide, the smallest box has a limit of 16 sessions
up to the biggest box, DD880 which has 180.  Yea, sorry I misspoke - it's
180 sessions, not 150.

Rick



From:   "Hart, Charles A" <charles_hart AT UHC DOT COM>
To:     ADSM-L AT VM.MARIST DOT EDU
Date:   03/22/2011 11:42 AM
Subject:        Re: draining a diskpool when using a DD and no copypool
Sent by:        "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>



"There is a limit to the number of sessions the DD can handle
concurrently (150)"

Is this limit based on a particular model of DD?  Seems a bit
constrictive for anything larger than a SMB.

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Richard Rhodes
Sent: Tuesday, March 22, 2011 10:25 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] draining a diskpool when using a DD and no
copypool

"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> wrote on 03/22/2011
10:25:00 AM:

> From: "Prather, Wanda" <wPrather AT ICFI DOT COM>
> To: ADSM-L AT VM.MARIST DOT EDU
> Date: 03/22/2011 10:25 AM
> Subject: Re: draining a diskpool when using a DD and no copypool Sent
> by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
>
> Curious as to why you are using the disk pool with migration to DD
> instead of having your backups write directly to the DD.
>
> Wanda

1) We're still trying to make this puppy work (right now having problems
getting 10g direct connects to the TSM servers working).

2) For initial implementation we want to make as few changes as
possible.

3) But the real reason is that we really like having backups buffered
before the next pool.  This is especially true for Oracle archive
logging.
 We're thinking this is especially true for the DD which only has a
single head - nonredundant.

Now, we think we will send more directly to DD, just not at the start.
And then it will probably be via a limit on file size of the diskpool.
That way it's less playing with nodes and management classes. There is a
limit to the number of sessions the DD can handle concurrently (150),
which includes backup, restore, and replication sessions, and this limit
is shared between two TSM instances.  We want to wait and see this all
looks like before we jump too deep into other changes.  It seems best at
the start to just change out tapepool for filepool (with the required
migration), see how it works, then see what else to change to make
things better.

 . . . at least that's the plan . . .

Rick


-----------------------------------------
The information contained in this message is intended only for the
personal and confidential use of the recipient(s) named above. If the
reader of this message is not the intended recipient or an agent
responsible for delivering it to the intended recipient, you are hereby
notified that you have received this document in error and that any
review, dissemination, distribution, or copying of this message is
strictly prohibited. If you have received this communication in error,
please notify us immediately, and delete the original message.

This e-mail, including attachments, may include confidential and/or
proprietary information, and may be used only by the person or entity
to which it is addressed. If the reader of this e-mail is not the intended
recipient or his or her authorized agent, the reader is hereby notified
that any dissemination, distribution or copying of this e-mail is
prohibited. If you have received this e-mail in error, please notify the
sender by replying to this message and delete this e-mail immediately.