#1 limiting factor:  Communication bandwidth/availability
     #2 limiting factor:  User's file size
         1,048,576-1KB files =/= 1024-1MB files =/= 1-1GB file for
     any/and|or/all adsm operations... so you can't say "I can take in x
     bytes" or "I can have y concurrent sessions" or "I can back up z
     files" in a given time frame.  Being truely honest I haven't come up
     with a valid way to size things.  General observations tells me I
     don't want to take in more than 210 GB /night on any one server with
     my current environment.  With the number of files and their sizes I
     can still take in that much, migrate it to tape, backup the DB,
     recycle tapes, perform expiration, AND even let users restore a few
     files now and then....   YOU HAVE TO ALLOW FOR ALL TASKS, some can
     float for a day or two but...

     Here is a short story that shows how one little thing can greatly hurt
     your ability to take in backups...
     Two adsm servers both RS/6000's (59H & 591), both hook to 3494 ATLs w/
     three 3590 drives (each), one has 240 GB diskpool, the other HAD 160
     GB diskpool but in a few minutes will be @230 GB's.
     In December 1996 EACH server took in 4.5 terabytes of backups and
     archives... Starting in Jan '97 our server with the 160GB diskpool
     started having about 200 GB's dumped to it nightly (and was I told to
     expect this increase? na...) anyway when the diskpool high was hit
     migration kicked in BUT the 40-50 sessions were still dumping faster
     than 2 processes could bleed it off, then when it hit 100% the backups
     rolled to the one open tape drive (NOT A PRETTY SIGHT, 40ish processes
     fighting over one tape drive) then backups were running to tape while
     the diskpool should have been migrating, when backups were finished we
     started migrating the diskpool while reclamation should have been
     running, expiration (ha ha ha), THEN we would hit the next round of
     backups (200GB =-> 160GB diskpool) before the diskpool was drained.
     OUCH oh OUCH !  The last 10 days have been......
     Anyway, while this one was falling on its face daily the other with
     the 240 GB diskpool was going strong NO PROBLEM with an equal
     workload.  Its a simple case of 70GB of diskpool makes a BIG
     difference... a shocking difference with the snowball factor added in.

     later
          Dwight