|
View previous topic :: View next topic
|
| Author |
Message |
ramvivek
New User
Joined: 23 Oct 2006
Posts: 13
|
|
|
|
Hi,
I have a deadlock problem in CICS. Two files are being read with update option in two diff pgms. So I am running into a deadlock situation.Is there any way to handle this ?
Thanks,
Ramkumar M. |
|
| Back to top |
|
 |
Earl
Active User
Joined: 17 Jun 2007
Posts: 148
Location: oklahoma
|
|
|
|
| yes, review EXEC CICS ENQ and EXEC CICS DEQ commands, |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hello,
You may need to change one of the programs so that locking will be in the same order as the "other" program. This may cause things to slow down, but will prevent the deadlock. |
|
| Back to top |
|
|
Earl
Active User
Joined: 17 Jun 2007
Posts: 148
Location: oklahoma
|
|
|
|
enq
read update
rewrite
deq
is the normal suggested method to prevent deadlock's |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hello,
If there is a separate enq/deq placed around each of the updates (2 different files), will there still not be a deadlock?
Is the enq mechanism "smart enough" to abend the transaction that issues the 4th enq that would cause the deadlock? |
|
| Back to top |
|
|
Earl
Active User
Joined: 17 Jun 2007
Posts: 148
Location: oklahoma
|
|
|
|
only 1 enq / deq for multiple files, use in both of the problem programs.
ENQ
read file ('file1') update
rewrite
read file ('file2') update
rewrite
read file ('file3') update
rewrite
read file ('file4') update
rewrite
DEQ
normally for deadlock, different tasks trying to update the same file and program logic is performing other long running process in between EXEC CICS UPDATE and EXEC CICS REWRITE.
enq/deq will force program logic in both programs to in effect' go single thread, first come, first service.
1st task that enq's on a resource owns it, and any other task that enq's on the same resource will wait until the resource has been deq'd. |
|
| Back to top |
|
|
Earl
Active User
Joined: 17 Jun 2007
Posts: 148
Location: oklahoma
|
|
|
|
can you explain logic of problem programs a little more.
you should be able to update the same file with 2 different programs, without using enq/deq.
the deadlock could be caused from some other logic problem .
is either of the programs trying to read or browse the same file in between the
exec cics read update
and
exec cics rewrite
??? |
|
| Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne
|
|
|
|
Can't remember, but does not VSAM provide a return which can be interpreted as a deadlock situation?
In DB2, if a task receives notification of timeout or deadlock, we do a rollback to allow the other task to complete, WAIT a few seconds then RESTART the Unit of Work. Yeah, I know, gotta keep track, so you can restart. AND these are not two instances of the same program.
If multiple instances of the same program are causing deadlocks, you have a design problem. |
|
| Back to top |
|
|
Earl
Active User
Joined: 17 Jun 2007
Posts: 148
Location: oklahoma
|
|
|
|
no return code from vsam (that I know of , indicating deadlock).
DINO, is correct, could be some design issues here. |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hello,
Yes, one issue is that one program reads file1 for update and the other reads file2 for update (at pretty much the same time). Then program1 tries to read what program2 has already read for update. Finally (again, at the same time) program2 needs to read what program1 has already "locked" - hence the deadlock (or deadly embrace). All good database systems terminate the last process that would have completed the ermbrace. With vsam, they lock.
As Earl has mentioned, all of the processing could be serialized, but the backup in the processes may not be acceptable.
If one or the other program was changed to lock in the same order as the other, it would be a degredation, but hopefully, not as severe as completely single-threading. |
|
| Back to top |
|
|
Earl
Active User
Joined: 17 Jun 2007
Posts: 148
Location: oklahoma
|
|
|
|
no wonder there is deadlock.
read for update puts an exclusive hold on the record until
exec cics rewrite
exec cics delete
exec cics release
or
task ends (normally or abnormally)
which is why IBM
recommends:
the only thing that should logically follow a "read for update"
is moving the changed record to the buffer,
and
then exec cics rewrite.
looks like a design problem, put in extra reads (without read for update). |
|
| Back to top |
|
|
|
|
