REXX and DB2: Intermittent Connection Pool Exhaustion Diagnosis

REXX and DB2: Intermittent Connection Pool Exhaustion Diagnosis

When a REXX program that connects to DB2 via DSNREXX or RRSAF terminates, the address space sometimes retains idle DB2 threads that are not reclaimed until the TSO session ends. The threads remain in an “in‑doubt” state if the script opens a WITH HOLD cursor and exits without an explicit COMMIT or ROLLBACK. The DSNREXX interface does not automatically commit on EXIT, so the thread can stay active for the duration of the address‑space idle timeout (IDTHTOIN). This behavior is documented in the DB2 manual under “Thread Reuse and Connection Management” and in the DSNREXX reference under “EXECSQL CONNECT”.

Because the thread exhaustion appears intermittently, it is unclear whether the root cause is the uncommitted WITH HOLD cursor, the DSNREXX thread‑reuse policy, or a combination of both. Determining the exact trigger is essential for designing a robust connection‑pooling strategy that avoids resource leaks.

To clarify the situation, I need to answer the following:

• When a REXX program exits without COMMIT, does DSNREXX always leave the thread in an idle state until IDTHTOIN expires?
• Does the presence of a WITH HOLD cursor guarantee that the thread will not be eligible for reuse even after a COMMIT?
• What is the documented interaction between DSNREXX’s thread‑reuse flag (CMTSTAT=INACTIVE) and DB2’s plan bind option RELEASE(COMMIT) in preventing thread exhaustion?