On Sep 26, 2006, at 7:58 AM, Adrian Compton wrote:

To keep Tivoli running we have had to exclude this FS (/backup/) from
mounting, but are now running without the DISKPOOL. Hence my
question about
the OVERFLOW storage pool automatically becoming the recipient in
place of
the DISKPOOL without having to change any parameters.

If your TSM server came up, it should see all the DISKPOOL volumes
missing, and so all incoming data should then go to the next level of
the storage pool hierarchy, assuming that's in writable condition and
has space.  You might formally perform an Update Stgpool to mark it
Unavailable until such time as its original volumes are returned to
service, or (RLV) substitutes might be put into place.  The more
awkward situation is outgoing data, which is to say that any data
which arrived in the backup disk pool but which is not represented in
the overflow area is unavailable for restorals - something which
needs to be publicized to the affected client community before they
attempt to restore data and find some or all of it missing.

   Richard Sims