Yes, that is the way it works. And it becomes even worse, because as an
ADSM admin you do not even know, whether a files space is dead or not,
since the "Last Backup Date" yielded by "query filespace" does not reflect
selective backups done by the client.

The way I am handling this situation is:
 - export the filespace into a file
 - archive this file
 - delete the filespace (type=backup !!!)
The filespace now does not occupy database space any more; it still
occupies pool space, but we can afford that.

Beach Shelby writes:
 > We have had several of our OS/2 clients re-label volumes which were being
 > backed up by ADSM. The result of this, as might be expected, is that ADSM
 > creates a new file space for the "new" volume and begins backing it up.
 > The question is, what happens with the files in the old file space (i.e.
 > the file space corresponding to the prior volume label). One would hope
 > that over time, based on the management class associated with those files,
 > that they would eventually expire. The longest retention period we have
 > specified for a backup copy group when the file is deleted is 60 days. Yet
 > we have had files which stick around in these "orphaned" file spaces for
 > over 200 days. It's as though the original files are not actually
 > considered deleted and hence the clock to expire them never starts
 > running.
 >
 > Our solution, of course, was to delete the file spaces. Is this the way it
 > is supposed to work? It seems a little bit nasty that our clients can
 > consume considerable backup pool space as well as database space simply
 > because they have re-labeled a volume. We can tell them not to do it, but
 > it doesn't mean that they won't.

--
Reinhard Mersch                     Westfaelische Wilhelms-Universitaet
Reinhard Mersch                     Westfaelische Wilhelms-Universitaet
Universitaetsrechenzentrum, Einsteinstrasse 60, 48149 Muenster, Germany
E-Mail: mersch AT uni-muenster DOT de                  Phone: +49(251)83-31583