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