Hi,
I am having a CICS-DB2 module which is triggered via MQ through a transaction. Module first searches the row in database with some criteria and then do Insert if the row does not exist or update if the row exists. The module is doing this Insert/Update for 816 rows sequentially in one call.
When multiple requests(Multiple transactions triggered through CICS at the same time) with 816 rows in each transaction request then for 2 requests in parallel the program is working fine but for the other requests it throws SQLCODE -911 with reason code C90088(Deadlock).
There is only one DB2 table in the module where update/Inserts are performed and i am using intermediate Syncpoints after every 50 Inserts in database to release the lock in DB2. Even with this the program is giving -911 for other requests in parallel. Lockrule on tablespace is set to 'R' (Row level) so it should not acquire lock.
Can someone please suggest some resolution for this.
Receiving SQLCODE -911 for CICS-DB2 module
Moderators: Kalicharan, Moderator Group
-
- Member
- Posts: 1
- Joined: Sun Oct 26, 2014 1:52 pm
- dbzTHEdinosauer
- Moderator
- Posts: 981
- Joined: Mon Oct 02, 2006 8:31 pm
are you also performing a syncpoint after the updates?
the inserts will not give you a deadlock, but the updates in one task could cause a dealock for the updates in a second.
have you considered running only one task?
have you considered running this process in batch. what you are describing is 'batch work'.
have a batch started task continually read the mq queue, and process what it finds.
you can have set a delay on the mq read to wait for time before returning a no-message response.
by using the delay, you have a permanent running job (that should run as a started task), that drains the queue. by running in batch, you do away with the added overhead from cics to start and manage a task evertime some message hits the queue.
since it is db2, there is no need to run this process in cics.
the inserts will not give you a deadlock, but the updates in one task could cause a dealock for the updates in a second.
have you considered running only one task?
have you considered running this process in batch. what you are describing is 'batch work'.
have a batch started task continually read the mq queue, and process what it finds.
you can have set a delay on the mq read to wait for time before returning a no-message response.
by using the delay, you have a permanent running job (that should run as a started task), that drains the queue. by running in batch, you do away with the added overhead from cics to start and manage a task evertime some message hits the queue.
since it is db2, there is no need to run this process in cics.
Dick Brenholtz
JCL, SQL and code in programs have an irritating habit of doing what you say,
not what you meant.
JCL, SQL and code in programs have an irritating habit of doing what you say,
not what you meant.
FREE TUTORIALS
Tutorials
Free tutorials from mainframegurukul
- JCL Tutorial
Covers all important JCL concepts. - Cobol Tutorial
This tutorials covers all Cobol Topics from STRING to COMP-3. - DB2 Tutorial
DB2 Tutorial focuses on DB2 COBOL Programming. - SORT Tutorial
This Tutorial covers all important aspects of DFSORT with examples - CICS Tutorial
This CICS tutorial covers CICS concepts and CICS Basics, CICS COBOL Programming.
Interview
Mainframe Interview questions
- Cobol Interview Questions
50+ Interview Questions - JCL Interview Questions
50+ Interview Questions - DB2 Interview Questions
100+ Interview Questions - CICS Interview Questions
70+ Interview Questions - VSAM Interview Questions
27 Interview Questions
Other References
Mainframe Tools and others
- XPEDITER Reference
Explains how we can debug a program - FILEAID Reference
Explains how to browse , edit and delete datasets - Change Man Reference
Quick Start tutorial on Changeman - Abend Reference
Important Abend codes explained - FaceBook Page
MainframeGurukul FaceBook Page - LinkedIn Page
MainframeGurkul Linkedin Page