Thanks for your comments Joerg

Yes we did have enough scratch tapes available at the time and yes we did
have a next migration storage pool.

Even though migration threshold exceeded 70% query process did not show any
migration occurring.

Definitely a weird one.

Thanks for your help

> -----Original Message-----
> From: Joerg Nouvertne [SMTP:joerg.nouvertne AT WTAL DOT DE]
> Sent: Wednesday, February 07, 2001 12:01 PM
> To:   ADSM-L AT VM.MARIST DOT EDU
> Subject:      Re: Migration did not occur
>
> On Wednesday 07 February 2001 11:00, you wrote:
> > Hello ADSM co-workers
>
> Hello Neil,
>
> > I am running ADSM 3.1.2.2 on a NSM C00. We have a disk storage pool
> called
> > INCDISK with the high threshold set to 70 and the low set to 30. Our
> main
> > clients are SQL servers. All clients backup to the SQLFLAT backup copy
> > group which is tied to the INCDISK storage pool. The INCDISK storage
> pool
> > will migrate to the INCTAPE storage pool when necessary.
> >
> > The issue that I have observed is that when the %utilised went over the
> 70%
> > high threshold then migration did not kick in. I waited until the
> %utilised
> > reached 92% and still migration did not occur. Query mount showed all
> > drives had tapes mounted, but when I queried the activity log to try and
> > understand what had mounted these volumes I could not come to and solid
> > conclusion.
>
> What is the activity log telling you? Maybe you should lower the HI
> migration
> threshold to force migration and have a look to the actlog afterwards.
> Possible reasons why the migration does not kick in are e.g. Not enough
> scratch tapes available in the destination pool, no migration pool at all,
> etc.
>
> > However I do suspect that restore operations where the culprit.
> > This was further backed up by entries informing me that earlier
> migration
> > processes had been pre-empted. I eventually dismounted the volumes half
> > expecting migration to kick in, but it didn't.
>
> Even if all tape drives are in use by other processes, migration should
> kick
> in, but would wait for a mount device, and you should see it in the
> process
> list.
>
> > I eventually got migration
> > to work by lowering both thresholds to 0.
>
> This would force it. You can also move the data manually via "move data
> DISKPOOL stgpool=MIGRATIONPOOL wait=no".
>
> >
> > What I am not too sure about is whether migration is actually pre-empted
> by
> > a restore operation. If this is the case then surly this is wrong.
> Surely
> > migration is more important as this is the safety valve before the
> storage
> > pool reaches 100%. Does anybody know the order of precedence for
> > pre-emption?
> >
> > Can anybody confirm or add to me conclusions. Thanks for your time.
> >
> > Neil Sharp
> > Merrill Lynch ADSM/TSM Administrator
> > Work : 020-7573-0469
> > Mobile : 07769-741612
> > Pager : 01893-038277
> > e-mail : neil_sharp AT ml DOT com
>
> Regards
>
> --
> Joerg Nouvertne
> ... who still runs ADSM 3.1, but who will take the new adventure TSM 4.1
> soon.