On 20/08, Loon, EJ van - SPLXM wrote:
> Hi KM!
> I already tried the delete object command. In fact, the objectid is in
> the error itself:
>
> ANR9999D imutil.c(7001): ThreadId <51> unexpected rc=87 from bfDestroy
> for objId=0.106696510
>
> So when I issue a delete object 0 106696510 the same error is returned.
> However, you might have put me on the right track:
>
> show bfo 0 1066965103:
>
> Bitfile Object: 0.1066965103
> **Sub-bitfile 0.1066965103 is stored in the following aggregate(s)
>   Super-bitfile: 0.1086967169, Offset: 0.0, Length 0.717
>
> show bfo 0 1086967169:
>
> Bitfile Object: 0.1086967169
> **Super-bitfile 0.1086967169 contains following aggregated bitfiles
>   0.1066965103
>
> **Archival Bitfile Entry
>   Bitfile Type: PRIMARY  Storage Format: 22
>   Bitfile Size: 0.781  Number of Segments: 1
>   Storage Pool ID: 6  Volume ID: 539755  Volume Name: L0301QL4
> **Archival Bitfile Entry
>   Bitfile Type: COPY  Storage Format: 22
>   Bitfile Size: 0.781  Number of Segments: 1
>   Storage Pool ID: -1  Volume ID: 540025  Volume Name: L041LLL4
> **Archival Bitfile Entry
>   Bitfile Type: COPY  Storage Format: 22
>   Bitfile Size: 0.781  Number of Segments: 1
>   Storage Pool ID: -2  Volume ID: 505610  Volume Name: *unknown*
>
> Aha!!! There seems to be an orphaned entry to a second copypool! And
> yes, we moved to new hardware about a month ago by starting a backup
> stgpool to the new copypool. When it was in sync, I deleted all volumes
> to the old copypool and deleted this pool. I guess this wasn't handled
> correctly by the TSM server.
> Kind regards,
> Eric van Loon
> KLM Royal Dutch Airlines

OK, so thats the problem.

I believe this should give you the object id of the alias (copy)
aggregate(s):

sho aggr 0 1086967169

Then you might be able to delete the alias aggregate/objects.

-km