Cursor With Hold

Shauna Hadden

Cursor With Hold
We have a client server application that uses VB (ADO) to perform upates on
one specific table. This table is partitioned and set at page level locks
(OS/390 v6.1)

The developer says he is not coding Cursor with hold....that DB2 Connect is
(Windows v7 EE).

The problem is that the thread is returned to the inactive thread pool and
is then promptly snapped up by another application and then another and
then another....locks and all. It eventually seems to release the
lock...sometimes 20-30 minutes down the road...after the pager has gone off
a few times and everyone is lining up outside my office.

My question(s) is/are:
1. What finally releases the locks on that wandering thread?
2. What makes it escalate to an x lock on the partition?
3. Is there anything I can do as a DBA to alleviate this problem? Other
than call the person with the userid associated with the thread and ask
them to backout of their application or end up kill the thread. I would
prefer to be proactive rather than reactive.

I understand why this is happening, but am not totally sure what I can do
about it.

Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at From that page select "Join or Leave the list". If you will be out of the office, send the SET DB2-L NOMAIL command to [login to unmask email] The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at