You need to update the storage pool for more parallel migration
processes. Look at this below:

>>-UPDate STGpool---pool_name----------------------------------->

>-----+------------------------------+-------------------------->
      '-DESCription--=--description--'

>-----+-----------------------------+--------------------------->
      '-ACCess--=--+-READWrite---+--'
                   +-READOnly----+
                   '-UNAVailable-'

>-----+------------------------------------+-------------------->
      '-MAXSIze--=--+-maximum_file_size-+--'
                    '-NOLimit-----------'

>-----+----------------------------+---+----------------------+->
      '-NEXTstgpool--=--pool_name--'   '-HIghmig--=--percent--'

>-----+---------------------+---+--------------------+---------->
      '-LOwmig--=--percent--'   '-CAChe--=--+-Yes-+--'
                                            '-No--'

>-----+------------------------+---+--------------------+------->
      '-MIGPRocess--=--number--'   '-MIGDelay--=--days--'

>-----+--------------------------+-----------------------------><
      '-MIGContinue--=--+-No--+--'
                        '-Yes-'


MIGPRocess
     Specifies the number of processes that are used for migrating files
     from this storage pool. This parameter is optional. You can specify
an
     integer from 1 to 999.

     During migration, these processes are performed in parallel to
provide
     the potential for improved migration rates.

I believe the migration process will default to >1< for a storage pool
if you do not force it to a higher number.

         Al

Alan Davenport
Selective Insurance
alan.davenport AT selective DOT com




donavart AT yahoo DOT com wrote:
>
> From: donavart AT YAHOO DOT COM
> To: ADSM-L AT VM.MARIST DOT EDU
> Date: Tue, 17 Apr 2001 07:33:31 -0700
> Subject: HSM Migration Processes
>
> Our TSM server (RS6000 S7A) is attached to an STK silo
> with 22 tape drives.  The problem that we are
> experiencing, beyond library and drive reliability, is
> with the apparent migration and recall process.
> Because we have many tape drives, we have dedicated 8
> drives to HSM only.  We have two HSM enabled
> filesystems, /hsmprod and /hsmuser which are local to
> the TSM server.  The filesystem of most concern is
> /hsmprod (production).  This filesystem is 200GB and
> has 90GB written to it nightly.
>
> The problem we are encountering is if we miss a backup
> or two the filesystem is full.  The backup process is
> relatively fast, we write to disk and to multiple tape
> drives.  However, the migration process is extremely
> slow.  It appears that this process will only mount
> one tape drive for migration.  Yet when users try to
> recall data, it will mount multiple tapes and spawn up
> to 20 recall processes (as per maxrecalldaemons=20).
> Are there any settings to increase the number of
> sessions or daemons the migration process will spawn.
>
> Thanks in Advance
>
> Don Avart
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Auctions - buy the things you want at great prices
> http://auctions.yahoo.com/