Also, please consider system maintenance.  TSM is usually maintained during
the day when backups are not running.
Ask you newby architect if you can take this system down during the day for
OS maintenance/problems/etc.


ROBERT R. PRICE
TSM Administrator
CSC
Phone: 412-342-1947
Fax: 412-342-1755
rprice28 AT csc DOT com

This is a PRIVATE message. If you are not the intended recipient, please
delete without copying and kindly advise us by e-mail of the mistake in
delivery.
NOTE: Regardless of content, this e-mail shall not operate to bind CSC to
any order or other contract unless pursuant to explicit written agreement
or government initiative expressly permitting the use of e-mail for such
purpose.



             Wanda Prather
             <wprather AT JASI DOT CO
             M>                                                         To
             Sent by: "ADSM:           ADSM-L AT VM.MARIST DOT EDU
             Dist Stor                                                  cc
             Manager"
             <[email protected]                                     Subject
             .EDU>                     Re: TSM architecture


             09/18/2009 12:05
             PM


             Please respond to
             "ADSM: Dist Stor
                 Manager"
             <[email protected]
                   .EDU>






FWIW,
When you upgrade to 6.1, your TSM server will be running Websphere (for the
ISC) and DB2, plus TSM.

I think your current way of "stacking" via LPARs is a better choice.

W


On Fri, Sep 18, 2009 at 12:01 PM, Shawn Drew <
shawn.drew AT americas.bnpparibas DOT com> wrote:

> All of this depends on the amount of data involved, not the number of
> nodes.  We have some TSM instances with 50 nodes that finish their
backups
> by 3AM or so.  and all the house-keeping finishes by 6AM.
>
>
> Regards,
> Shawn
> ________________________________________________
> Shawn Drew
>
>
>
>
>
> Internet
> rrhodes AT FIRSTENERGYCORP DOT COM
>
> Sent by: ADSM-L AT VM.MARIST DOT EDU
> 09/18/2009 11:49 AM
> Please respond to
> ADSM-L AT VM.MARIST DOT EDU
>
>
> To
> ADSM-L
> cc
>
> Subject
> Re: [ADSM-L] TSM architecture
>
>
>
>
>
>
> Our TSM servers are busy around the clock.  In fact, 6am-noon is some of
> the busiest with migrations going on.
>
>
>
>
>
>
>
>
>             "Haberstroh,
>             Debbie (IT)"
>             <HABERDE@VOUGHTAI                                          To
>             RCRAFT.COM>               ADSM-L AT VM.MARIST DOT EDU
>             Sent by: "ADSM:                                            cc
>             Dist Stor
>             Manager"                                              Subject
>             <[email protected]         TSM architecture
>             .EDU>
>
>
>             09/18/2009 11:36
>             AM
>
>
>             Please respond to
>             "ADSM: Dist Stor
>                 Manager"
>             <[email protected]
>                   .EDU>
>
>
>
>
>
>
> Hi All,
>
> My current environment is TSM 5.5.3, 1 library manager, 3 database
> servers.
> These are installed on a P550 AIX 5.3 system in separate LPAR's.  We have
> 355 clients, 200 + are active.  My current TSM databases are 100GB,
65-82%
> utilized.  We are going to be doing a large  business object installation
> which will add 30-50 new clients including multiple Oracle databases.
Our
> proposal was to add an additional TSM server to handle the new
> requirements.
>
> We have a new "architect" that is not very familiar with TSM and his
> proposal is to "stack" TSM on another server that is running a different
> application.  His argument is that TSM does most of it's work at night
and
> the application (which one is TBD) does most of it's work during the day.
> From what I know, due to TSM's resource utilization, it should be on it's
> own hardware.
>
> Has anyone tried to do this and what were your results?  I would love to
> get some good arguments to take back that would support our original
> position to install on separate hardware.  Thanks to everyone for your
> ideas.
>
> Debbie Haberstroh
> TSM Server Administration
>
>
> -----------------------------------------
> 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 message and any attachments (the "message") is intended solely for
> the addressees and is confidential. If you receive this message in error,
> please delete it and immediately notify the sender. Any use not in accord
> with its purpose, any dissemination or disclosure, either whole or
partial,
> is prohibited except formal approval. The internet can not guarantee the
> integrity of this message. BNP PARIBAS (and its subsidiaries) shall
(will)
> not therefore be liable for the message if modified. Please note that
> certain
> functions and services for BNP Paribas may be performed by BNP Paribas
RCC,
> Inc.
>