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
