On 26 April 2012 22:46, Jon Perryman <[email protected]> wrote: > > 1. Create a control block. > 2. Attach a task and pass the control block. > 2b. New task waits on ECB in the control block. > 3. Init transaction / query > 4. save query-id in the control block. > 5. Create stimerx with id. > 6. start transaction / query. > 7. if stimerx pops, then post the ECB in the control block. > 7b. The attached task can do a CANCEL QUERY with the saved queryid in the > control block > 7c. go back to wait or do what you want > 8. If transaction ends and stimerx did not pop, then cancel the stimerx. > 9. post the ecb in the control block to terminate the attached task. > > Nice theory, but completely the wrong way to deal with a DB2 timeout/deadlock.
What you need to do is look at the SQL, look at the access path, look at the indexes used. Work out with the DB2 DBA why you have two threads in DB2 that are conflicting, why you have SQL programmers who are writing bad SQL. Almost all deadlocks (sqlcode911n -911/ sqlcode913n -913) are written by the SQL programmer. Sqlcode904n -904s are a different beast. The old rules still hold true: 1. don't get a lock before you need it, 2. get your locks in the same order in all programs that are likely to content for resources, 3. try to avoid user created monotinic ascending sequence numbers (use the built-in DB2 facility) and 4. Use the right isolation level, and lock size. For SQL coming in from DRDA clients we have some ZPARMs that can be used to control them. Doing your stuff is a) unlikely to work, b) likely to shoot DB2 dead, c) will compromise data integrity or d) adversely affect performance. Just my humble opinion, of course, with my DB2 specialist hat on. You may want to take the discussion to DB2-L since this is way off topic for assembler-list. -- http://twitter.com/DougieLawson
