I am finding frequent deadlocks between two instances of a online COBOL code. The deadlocks occur at a DML statement (ERASE or MODIFY). The control goes well into the deadlock handling paragraph and the deadlock recovery for one of the task is also successful.
Two DC001000 messages are written into the logs (One for each task in deadlock). And subsequently one of the task is rolled back.
Could any one please help? Can I avoid these messages getting written into the logs and the transaction getting rolled back?
Many thanks for your reply!
MODIFY or ERASE I am talking about is an IDMS data modification statement.
I am not using CICS. The program is a IDMS-DC online COBOL program that is using backend as IDMS and the DC storage variables.
Hope I made it clear this time. Please give me a shout if some thing is unclear or required.
Joined: 23 Nov 2006 Posts: 19270 Location: Inside the Matrix
Two DC001000 messages are written into the logs (One for each task in deadlock). And subsequently one of the task is rolled back
Can I avoid these messages getting written into the logs and the transaction getting rolled back?
Unfortunately, i don't speak IDMS either, but i believe the following may relate to your situation.
When you say "deadlock", is this the same as a "fatal embrace"?
To reach this impasse one task "locks" a resource in tableA and another task "locks" a resource in tableB. Then the first task tries to lock the resource already held by the second task. So far, so good. So far, no deadlock. The deadlock occurs when the second task tries to lock the resource already being held by the first task.
Most often this is caused by the tasks locking resources in different sequences. I'd suggest you look at the problem program(s) and see if there are multiple processes that would lock resources in multiple sequences.
Something i've seen multiple places is when code needs to lock "header" and "detail" data and one process locks the header first and another process locks the detail first. This is a deadlock just waiting to happen. Usually, it will happen when transaction volumes are increasing or when the system becomes bottlenecked and locks are not freed quickly enough.