I'm reposting the following message as I never saw it appear in the digest
version of ADSM-L when originally submitted on 8/24/99:

To John Schneider et al,

Back on 6/23/99 I wrote the following:

"Our storage migration thresholds for our diskpool are set to 25 and 10 with
numpr=3.  We do not use colocation.  When migration (disk to tape) runs, the
process will start, process 1 small file, then finish with a completion state
of success.  Then, a few seconds later, another migration will process 1 small
file and finish.  And on ad infinitum.  Sometimes a migration process will
actually do a bunch of files where bunch is a number like 20 or 50 comprising a
total of a whopping 1MB.  We're on 3.1.2.20 on AIX 4.3.1, but we also saw this
pattern on 3.1.1.5.  This pattern of behavior is not consistent with my reading
in the manual.  Can anyone shed some light on this?"

I'd like to now add that our disk pool too, like John's, shoots up to 99% and
stays there due migration's inability to return the disk pool to the low
threshold.  This of course causes other problems such as backups being forced
to go to the next storage pool (tape), so now you get backups and migrations
competing for drives.  Further, even though I have numpr=3, I usually only see
one migration process fire up at a time.

John, it looks like our experience on AIX mirrors your Solaris situation.
Another reader said this is normal for cached systems.  This is not correct.
Our system is cached and PCT UTIL (from QUERY STGPOOL) always shows numbers in
the high 90's.   But we don't care about PCT UTIL; our concern is ADSM's
failure to bring PCT MIGR back down to the low threshold.  Another reader
suggested we time our migrations to occur after all backups are done.  At our
site, this is not practical.  Our backups are taking place around the clock, so
migrations need to be able to work around the clock.  I also agree it would be
nice if our disk storage pool was large enough to handle all our backups for a
given day, but this too is not practical in our installation.

IBM, this migration behavior is strange to say the least, and disruptive to
operations to say the worst.  Please comment.

Bob Brazner