Hi Dynatrace Community,
I’m investigating a mainframe performance issue where two CICS transactions (referred to here as UP08 and UP29) contended on the same DB2 table, resulting in high lock‑waits and deadlocks. I’m looking for best‑practice guidance on configuring Dynatrace to surface DB2 contention metrics and transaction‑level CICS services for alerting and correlation.
What I’ve observed so far:
- Under Settings ▸ Preferences ▸ OneAgent features, several z/OS CICS/DB2 options appear available but disabled.
- I’d like to confirm the correct steps for enabling DB2 metrics collection (Opt‑in) and ensuring CICS transactions appear as distinct services.
Questions:
Is the z/OS DB2 Metrics Collection (Opt‑in) feature still the correct switch to expose DB2 metrics such as deadlocks, timeouts, and lock‑waits in Data Explorer?
For clearer CICS transaction visibility, is it recommended to enable “Create CICS services based on transaction IDs” so each transaction (e.g., UPxx) becomes its own service for baselines and anomaly detection?
To analyse log‑based contention patterns (e.g., “DEADLOCK”, “LOCK WAIT”) using DQL in Notebooks, is enabling z/OS log ingestion via the built‑in rules the appropriate approach?
Once metrics become available, are there recommended alert thresholds for:
- DB2 deadlock rate
- DB2 lock‑wait %
- p95 response time for key CICS transactions
(Looking for commonly used defaults or tuning guidance.)
Environment notes:
- No RUM/frontend involved — analysis is focused on mainframe backend and DB2 behaviour.
- Permissions are restricted, so I can request enablement but cannot toggle features directly.
Goal:
To establish early, reliable detection of DB2 contention and improve correlation between CICS transaction behaviour and DB2 performance indicators.
Any best‑practice advice, examples, or tuning recommendations would be greatly appreciated. Thanks!
