Well David,

TSM will always choose the node with the most data to migrate first, and
won't check again till that is done.  If you have one node with much
more data than any other, that could explain why the lowmig value
appears to have little effect.

Regards

Steve

Steven Harris
AIX and TSM admin
Brisbane, Australia

David Bronder wrote:

Allen S. Rout wrote:

This used to be the only way to accomplish this effect, and it's still
what I do now. But When I Get Around To It, I'm going to change to the
somewhat new

migrate stgpool [yadda] lowmig=0 duration=[minutes]

which has the advantage that you don't have to actually change the
stgpool settings, thus protecting you against all sorts of odd
failures resulting in stgpools with wrong configuration.

I recently changed to this for my (twice) daily full migration, now
that I'm at TSM 5.3.

Since some of my disk pools are just a little tight, I set those pools'
LOWMIG to 79 (HIGHMIG=80), hoping to get TSM to migrate "just enough"
to buy space/time until the morning processing kicks in.  However, the
automated migrations seem to not be very sensitive to the LOWMIG value
(I've been moving it closer to HIGHMIG but the migrations still keep
on running).

I also wish they'd included a "migrate stgpool" override for MIGPROCESS
as well, which would have allowed further fine-tuning of the behavior.


--
Hello World.                                    David Bronder - Systems Admin
Segmentation Fault                                     ITS-SPA, Univ. of Iowa
Core dumped, disk trashed, quota filled, soda warm.   david-bronder AT uiowa 
DOT edu