Monitor DB2 threads

What thread monitoring answers

When response time spikes, DDF connections pile up, or a job appears hung, thread displays are the first live view. You want connection name, authorization ID, plan or package context, status codes, tokens, and for distributed work the LUWID and conversation state. DETAIL adds conversation and distributed server information that helps separate a Db2 wait from a network wait.

Thread monitoring does not replace accounting and statistics traces, but it is the right tool for immediate operational questions. Pair it with DISPLAY LOCATION, DISPLAY DDF, and your online monitor when you need historical or aggregated CPU and wait profiles.

Prerequisites

You need authority to issue DISPLAY THREAD. Basic displays typically require DISPLAY privilege or higher. Keywords such as TYPE, LOCATION, DETAIL, and LUWID require SYSOPR or higher. Know the command prefix for the target member, and in data sharing decide whether you need SCOPE(LOCAL) or SCOPE(GROUP).

Have a filter strategy before you flood the console. The default output LIMIT is 512 lines; use connection name, LOCATION, LUWID, or TYPE to narrow results. Agree with operations on when CANCEL THREAD is allowed and what evidence you collect first.

• Command prefix and member identity known
• DISPLAY (and SYSOPR if using DETAIL/LOCATION/LUWID)
• Understanding of ACTIVE, INACTIVE, INDOUBT, POSTPONED
• Console or SDSF capture for evidence

Steps: display and filter threads

Start broad, then narrow. DISPLAY THREAD(*) TYPE(ACTIVE) shows work currently in Db2. Add DETAIL when you need conversation status for distributed threads. Use TYPE(INACTIVE) for pooled or inactive DBATs, TYPE(INDOUBT) after coordinator failures, and TYPE(PROC) when focusing on stored-procedure related threads.

Filter by connection name for CICS or batch attach names, by LOCATION for a remote partner, or by LUWID/token when following one distributed unit of work. In a data sharing group, repeat on each member or use SCOPE(GROUP) when appropriate so you do not miss work on another member.

1
2
3
4
5
-DISPLAY THREAD(*) TYPE(ACTIVE)
-DISPLAY THREAD(*) TYPE(ACTIVE) DETAIL
-DISPLAY THREAD(*) LOCATION(*) DETAIL
-DISPLAY THREAD(*) TYPE(INDOUBT)
-DISPLAY THREAD(cicsconn) TYPE(ACTIVE) DETAIL

Steps: interpret status and act

Learn the common status indicators: allied thread established, distributed requestor or server roles, parallel task (PT) rows under an originating thread, SP for stored-procedure execution, and queue indicators when MAX DBAT or similar limits are reached. If DETAIL timestamps or conversation states do not change across repeated displays, the thread may be stuck outside Db2 or waiting on a resource.

For sustained remote-thread control, use profile tables with MONITOR THREADS / MONITOR ALL THREADS and -START PROFILE so Db2 warns or rejects when thresholds are exceeded. That complements DISPLAY THREAD rather than replacing it.

Verify results

After a change—raising MAXDBAT, recycling a CICS connection, or cancelling a runaway thread—reissue the same DISPLAY THREAD filter and confirm counts and statuses moved as expected. Cross-check DDF with DISPLAY DDF and DISPLAY LOCATION. For cancelled work, confirm the application saw the expected SQLCODE and that no indoubt threads remain.

Keep before/after console output in the incident ticket. Verification is not only “the command worked”; it is proof that the operational symptom cleared.

Common errors

Authorization failures mean your ID lacks DISPLAY or SYSOPR for the keywords used. Truncated output means you hit LIMIT—tighten filters or raise LIMIT deliberately. Misreading inactive DBATs as a problem, or cancelling an indoubt thread without recovery awareness, can make outages worse.

In data sharing, monitoring only one member misses peer work. For distributed hangs, skipping DETAIL and LOCATION often leads to blaming Db2 when the conversation is waiting on the network or partner. Correlate with accounting data when you need CPU, class 2/3 waits, and package-level detail after the live incident.