Fellow ADSM/TSM admins:

We've reached the milestone of 1000 (pc,mac,unix) workstation clients
on our 3466 (circa 1998.)  And now I'm  told I maybe taking on all the
(equivalent) backup chores of our failing Legato system. Which is about
the same amount of data but with only a handful (100) server-clients.

Originally a C10 with two 7373 DLT's its now a 'virtual' C00 with a 'third
party' 3494 (1 frame 222 slots) & 2 3590 drives.  Our database is hovering
around 70% utilization at 30 Gigs.  And I was planning some expansion
before the more-work news.

Now I'm concerned about the database getting any larger.  I'm seeing
increase wall clock time to run Expire Inventory and full database backups
(from 1 1/2 & 1 hour to 2 1/2 & 1 3/4 hours)

Is it true about *SM hiting a dog-leg in the performance curve after the
data base has exceeded 30 gigs????  We are at CE15 for 3466's (TSM 3.7.2)

The tape media move is a no-brainer for me: buy a second frame (260 more slots)
 with 2 more drives.  (But I do maintain my onsite tapepool at 60 Filling
average with collocation.)

What would you do:

1) buy a second 3466 to use with the same 3494 but with a second frame
  added.

2) Add a second server image on the current 3466 duplicating the critical
   resourses (with cpu, memory and SSA add-ons) to it. (if permitted by
   licensing)

3) buy a bigger 3466 and use the current one  as 'trade-in' ?


I think the prospect of having redundancy through two 'full' boxes is
'cancelled out' by the greater cost of getting a second C00 instead
of adding more SSA, memory and CPUs.  So for me the question is keep one
server and let it double its growth (to 60GIG DB, etc) or run a
second image in the same box. But I may be wrong.
I see the second image dedicated to backing up server-clients as a good
direction to go in.  Although *SM has always been robust about
accomadating small and large clients together.  A few of my current
customers are larger NT or Unix boxes.

I'd love to hear from one and all with your thoughts and especially anyone
that has also faced this 'fork' in the *SM growth road.

thanks in advance. and cheers!

                              ... joe.f.



Joseph A Faracchio,  Systems Programmer, UC Berkeley