Tom,

What is the reclaim value for the storagepool of the volume you
are deleting?  If it is less than 100%, maybe reclaim is trying to
work on the volume when it is half way thru the delete.  If so, set
the reclaim to 100% before starting the delete.

You say "... every few days".  Are you deleting volumes every
few days?  With 'discarddata=yes'?  I am curious why you
are doing this.

--
--------------------------
--------------------------
Bill Colwell
Bill Colwell
C. S. Draper Lab
Cambridge, Ma.
bcolwell AT draper DOT com
--------------------------
In <H000132102f90b83@MHS>, on 10/04/99
In <H000132102f90b83@MHS>, on 10/04/99
   at 04:39 PM, Thomas Denier <Thomas.Denier AT MAIL.TJU DOT EDU> said:

>I have been seeing sequences of messages similar to the following every few
>days:

>10/01/1999 15:17:29  ANR0390W A server database deadlock situation has been
>                      encountered: lock request for transaction 0:5336084 will
>                      be denied to resolve the deadlock.
>10/01/1999 15:17:29  ANR9999D ASUTIL(706): Lock acquisition (ixLock) failed
>                    for volume root.
>10/01/1999 15:17:29  ANR1181E ASTXN348: Data storage transaction 0:5336084 was
>                      aborted.
>10/01/1999 15:17:29  ANR2183W ADMDVOL1807: Transaction 0:5336084 was aborted.
>10/01/1999 15:17:29  ANR1160W Transaction was aborted for volume 600052.
>10/01/1999 15:17:29  ANR0986I Process 227 for DELETE VOLUME (DISCARD DATA)
>                      running in the FOREGROUND processed 179 items for a
>                    total of 12,172,611 bytes with a completion state of
>                  FAILURE at 15:17:29.

>As far as I can tell, there were no node sessions in progress when the failure
>occurred, and no administrative processes other than process 227 itself. I
>find it difficult to imagine why ADSM would have any trouble with database
>contention under those circumstances. We are running a 3.1.2.20 server under
>MVS. Does anyone recognize this as a know problem?