We've implemented following within an ADS dialog to manage index deadlock situations where updates are occurring on a particular record type (PT-PK-SGNOUT-REC) owned by 5 system owned indexes (don't ask)
ACCEPT DB-KEY INTO PT-WK-D431-DBKEY
FROM PT-PK-SGNOUT-REC CURRENCY.
MODIFY PT-PK-SGNOUT-REC ALLOWING (DB-DEADLOCK).
SNAP RECORD (PT-PK-SGNOUT-REC)
TITLE 'PTELD431 - DEADLOCK MESSAGE'.
FIND PT-PK-SGNOUT-REC DB-KEY IS PT-WK-D431-DBKEY.
The SNAP message is going to the log but the second MODIFY also seems to succumb to an '0829' error (and abort)
- delay the second MODIFY in order to give more time to the competing transaction to complete
- make repeated attempts (for a fixed number of times)
- is the 'COMMIT ALL' insufficient in releasing enought of the resources to allow the competing transaction to complete
From perusing the journal recs (with jreport8), when 2 transactions deadlock, the process is successful.
The failures are occurring when more than 2 trans are locked (as many as 7 a couple of days ago)
At this stage, I'm thinking of adding code to re-attempt a few times (not sure how many but at least 6 or 7)
If the transaction also uses DC-Queue resources then you will want to use COMMIT TASK ALL - which I would try regardless - since some retrieval locks are left intact with only using COMMIT ALL - and this may be sufficient to cause the deadlocking?
COMMIT TASK ALL
If that fails then introducing a WAIT and retry on the first nn29 may be useful - it has worked for us in the past.
HTH - cheers - GaryC