Wanda Prather said...
> Well, the straightforward TSM way to keep files in a diskpool, is to
> remove the NEXTSTGPOOL value from the definition of the
> storage pool (so
> that the files have no place to migrate to), or set the
> HIGHMIG stgpool
> pool property to 100%, so that migration will never start.

That's a possible but unlikely strategy, unless I can arrange to get that
data to tape in an alternate fashion for offsite storage.

> The most practical way to do that, is to split your storage pools so
> that the client data you want to stay to disk all goes to one
> disk pool,
> and the other clients go to another pool that DOES migrate.

Seems like segregating the storage pools by client is a good thing to do
regardless.

> You can split the clients up by putting them in different
> domains, or by
> using management classes.

Something to learn - I'll peruse the docs for that. I don't believe that
we're doing anything like that at the moment.

> If you don't want to do that, but you want to know when your disk pool
> is getting full, you can use TSM Operational Reporter.
> You can add a line to the custom summary to tell you the disk pool
> utilization, based on a select statement:
>
> select pct_utilized from stgpools where stgpool_name='BACKUPDISK'
>
> And you can set a threshold for that value so that TOR runs every nn
> minutes, and sends you an email if pct_utilized is greater than, say,
> 90%.

This does sound promising - more docs to read!

> Hope some of that is what you are looking for...

Definitely

> Wanda Prather
> "I/O, I/O, It's all about I/O"  -(me)


Thanks very much for taking the time. I'm sure I'll have more questions
later

Kurt