ADSM-L

Re: [ADSM-L] Dealloc prohibited - transaction failed

2009-08-21 03:02:55
Subject: Re: [ADSM-L] Dealloc prohibited - transaction failed
From: "Loon, EJ van - SPLXM" <Eric-van.Loon AT KLM DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Fri, 21 Aug 2009 09:02:19 +0200
Hi KM!

sho aggr 0 1086967169:

AggrId: 0.1086967169, AggrSize: 0.717, LogSize: 0.717, NumFiles: 1.
Aliases: None. 

I guess I have to parc the undeletable nodes somewhere until the TSM
server is upgraded to a supported level...
Kind regards,
Eric van Loon
KLM Royal Dutch Airlines

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
km
Sent: donderdag 20 augustus 2009 19:16
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Dealloc prohibited - transaction failed

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
**********************************************************************
For information, services and offers, please visit our web site:
http://www.klm.com. This e-mail and any attachment may contain
confidential and privileged material intended for the addressee
only. If you are not the addressee, you are notified that no part
of the e-mail or any attachment may be disclosed, copied or
distributed, and that any other action related to this e-mail or
attachment is strictly prohibited, and may be unlawful. If you have
received this e-mail by error, please notify the sender immediately
by return e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries
and/or its employees shall not be liable for the incorrect or
incomplete transmission of this e-mail or any attachments, nor
responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal
Dutch Airlines) is registered in Amstelveen, The Netherlands, with
registered number 33014286 
**********************************************************************