View previous topic :: View next topic
|
Author |
Message |
sourabh jain
New User
Joined: 29 Feb 2008 Posts: 27 Location: Pune
|
|
|
|
Hi all,
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? |
|
Back to top |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008 Posts: 2501 Location: Atlanta, Georgia, USA
|
|
|
|
I'm going to take a SWAG and assume this is a CICS problem?
If this is CICS, there is a keyword ERASE for several BMS commands, but I'm not familiar with a MODIFY command nor keyword.
Please elaborate....
Regards,
Bill |
|
Back to top |
|
|
sourabh jain
New User
Joined: 29 Feb 2008 Posts: 27 Location: Pune
|
|
|
|
Bill,
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. |
|
Back to top |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008 Posts: 2501 Location: Atlanta, Georgia, USA
|
|
|
|
Unfortunately, I don't speak IDMS and perhaps one of the other members may have an opinion regarding this problem.
Regards,
Bill |
|
Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006 Posts: 19244 Location: Inside the Matrix
|
|
|
|
Hello,
Quote: |
Two DC001000 messages are written into the logs (One for each task in deadlock). And subsequently one of the task is rolled back |
Quote: |
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. |
|
Back to top |
|
|
|