Hello,
in the meantime I upgraded to 5.1.1.6. With this level I could delete the
filespace without problem.
However, I couldn't resist to try "cleanup backupgroup" again. Under 5.1.1.4
it worked. It only seemed strange that it obviously didn't finish its work,
as Joel described:
> On 5.1.1.4, I did the CLEANUP BACKUPGROUP and I still could not delete the
> system objects.  I reran the cleanup command numerous times and
> each time it
> reported inspecting and deleting fewer objects than the previous run.

On 5.1.1.6 cleanup backupgroup stopped immediately with return code 4. In
the activity log I found the following messages:
09/24/02 10:31:51     ANR2017I Administrator GERHARD issued command: CLEANUP
                       BACKUPGROUPS
09/24/02 10:31:51     ANR9999D imutil.c(6663): ThreadId<67> Failure deleting
                       member 0 585368742 for group 1637 3 - encountered
                       repeatedly in loop.
09/24/02 10:31:51     ANR9999D imutil.c(3931): ThreadId<67> Error 19
deleting
                       dependents for node 0 fs 0 and leader 1637 3.
Now I'm little bit concerned. Is cleanup backupgroup broken or is it my
database?

> My suggestion to all TSM admins is to do a
>    QUERY OCCUPANCY * "SYSTEM OBJECT"
> to verify that you do not have excessive copies.
>
How can you tell from the output of the q occ command how many excessive
copies you have?


BTW, I cannot confirm that system objects are not expired. I used the
following SQL statement in the middle and at the end of an expiration
process:
select sum(num_files) from occupancy where filespace_name='SYSTEM OBJECT'
The first number I got was 1043479, the last 1012998. So I got rid of at
least 30481 files.

Best regards
Gerhard
---
Gerhard Rentschler            email:g.rentschler AT rus.uni-stuttgart DOT de
Regional Computing Center     tel.   ++49/711/685 5806
University of Stuttgart       fax:   ++49/711/682357
Allmandring 30a
D 70550
Stuttgart
Germany