I am not sure how you try to delete thoose volumes, but.

This should work.
Create a OS script with multiple lines like:
Dsmadsmc -id=x -password=y del vol xyz discarddata=yes wait=y
Dsmadsmc -id=x -password=y del vol zyx discarddata=yes wait=y
Etc.

If you create a script in TSM or run multiple del vol commands in a
macro you will get the deadlock you are seeing. Been there..



//Henrik





 

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Wanda Prather
Sent: den 2 april 2008 22:21
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] Delete volume problem

No good way around it, except to run your DELETE VOLUMES serially and
with NOTHING ELSE going on.  Or upgrade past the bug.  Search
www.ibm.com:
IC50659

On 4/2/08, David Longo <David.Longo AT health-first DOT org> wrote:
>
> I think there is an occasional problem with "Delete Volume"
> at that TSM server version that can hang things.
>
> I seem to recall is fixed in TSM 5.3.5.x or close.
>
> David Longo
>
> >>> Thomas Denier <Thomas.Denier AT JEFFERSONHOSPITAL DOT ORG> 4/2/2008 2:02 
> >>> PM
> >>>
> We have a 5.3.4.0 TSM server running under mainframe Linux. We are in 
> the process of migrating some of our offsite copies to newer tape 
> technology. Yesterday I finished backing up all the data in one of our

> primary tape pools to a new copy storage pool. This morning I started 
> deleting the volumes from the old copy storage pool previously used 
> for offsite copies of the same primary pool. The first couple of 
> 'delete volume' commands worked fine. The third one was running when 
> our automation started a snapshot database backup.
> The snapshot process froze with 0 of 0 pages backed up. The 'delete 
> volume' process froze. A number of migration processes running at the 
> time stopped moving data. Node sessions went into permanent run status

> and stopped moving data. I executed a 'cancel process' command for the

> 'delete volume' process. It had no visible effect. A little while 
> later I issued a 'cancel process' command for the snapshot process. It

> caused the status reported by 'query process' to change to 'Cancel 
> pending' but otherwise had no visible effect. I finally shut down the 
> TSM server. I then had to wait some minutes for a defunct dsmserv 
> process to go away before I could restart the TSM server.
>
> Later in the day our automation ran an incremental database backup.
> Once the backup process was safely under way I tried another 'delete 
> volume' command. The 'delete volume' process deleted a few hundred 
> files and then froze. Migration processes and node sessions stopped 
> moving data. The database backup continued to run until it had written

> all the necessary database pages and dismounted the output tape. It 
> then froze. I was once again unable to cancel either the database 
> backup or the 'delete volume' process. I had the same problem with a 
> defucnt dsmserv process when I stopped the server for the second time 
> that day.
>
> Are there any other TSM functions that cannot co-exist safely with 
> 'delete volume' processes? We are preparing to upgrade our TSM server 
> to 5.4.2.0. Will the de facto rules about when to run 'delete volume' 
> processes be different under this release?
>
>
>
> #####################################
> This message is for the named person's use only.  It may contain 
> private, proprietary, or legally privileged information.
> No privilege is waived or lost by any mistransmission.  If you receive

> this message in error, please immediately delete it and all copies of 
> it from your system, destroy any hard copies of it, and notify the 
> sender.  You must not, directly or indirectly, use, disclose, 
> distribute, print, or copy any part of this message if you are not the

> intended recipient.  Health First reserves the right to monitor all 
> e-mail communications through its networks.  Any views or opinions 
> expressed in this message are solely those of the individual sender, 
> except (1) where the message states such views or opinions are on 
> behalf of a particular entity;  and (2) the sender is authorized by 
> the entity to give such views or opinions.
> #####################################
>


-------------------------------------------------------------------
The information contained in this message may be CONFIDENTIAL and is
intended for the addressee only. Any unauthorised use, dissemination of the
information or copying of this message is prohibited. If you are not the
addressee, please notify the sender immediately by return e-mail and delete
this message.
Thank you.