Troubleshooting your z/OS monitoring: Covering the basics

jellypuno — Wed, 25 Mar 2026 13:42:30 GMT

Summary

Is your Dynatrace z/OS monitoring not working as expected? Before opening a support ticket, it’s often helpful to perform an initial investigation yourself—but reading mainframe logs can feel overwhelming if you’re not sure where to start.

Don’t worry—I’ve got you covered. 😉

In this two‑part blog series, I’ll walk you through common z/OS monitoring issues I’ve encountered and explain how to troubleshoot them effectively.

In Part 1, we’ll cover the basics:

Which logs you need
How to download and extract them
How to identify the right log files
What critical information to check first

Downloading the Dynatrace z/OS Support Archive

The first step in any z/OS troubleshooting process is collecting logs. Whether the issue is related to zRemote, zLocal, or zDC, having full visibility is essential.

To download the Dynatrace z/OS OneAgent diagnostics logs, follow the instructions here:
👉 How to download the z/OS OneAgent diagnostics logs

How to Find the Logs Relevant to Your Issue

One of the biggest challenges is volume. Depending on your environment, the support archive can contain a large number of logs across multiple components.

Step 1: Identify Related zRemote and zLocal Logs

Search within the extracted archive for the keyword:

zRemoteAgent TimeStamp=YYYY-MM-DD

Then look for a log entry similar to this:

YYYY-MM-DD HH:MM:SS UTC �00000000] info �native] Log info data�zLocalAgent logfile=/location/zlocal.log, zRremoteAgent logfile=location/zremote.log, zRemoteAgentName=oneagentname, zRemoteAgent TimeStamp=YYYY-MM-DD HH:MM:SS]

This entry tells you the location of the zlocal agent logs and its accompanying zremote logs.

Why This Matters

In many environments, you’ll have multiple zRemotes, zDCs, and zLocals. Mapping the relationships between them helps you avoid mixing unrelated logs and saves a lot of investigation time.

Verifying Dynatrace z/OS Component Versions

Once you’ve identified the correct logs, the next critical step is checking version compatibility between your Dynatrace mainframe components.

zDC Version

In the zLocal log, search for:

ZDC Version=

This tells you which zDC version is installed on the mainframe.

zLocal Version

In the same log, search for:

The most recently installed zLocal version:

Example:

The most recently installed zLocal version: 7.2.29.1008

zRemote Version

You can find the zRemote version in:

The UI, Deployment Status> ActiveGate , or
The zRemote log file, by searching for the version string directly

Why Version Checks Are So Important

Many z/OS monitoring issues are resolved by upgrading components. The zDC, zLocal, and zRemote are interconnected, so version compatibility among these three components is critical.

Best practice:

zDC, zLocal, and zRemote should be on the same version, or
At most, within three versions of each other

⚠️ If zDC is on a higher version than zRemote, compatibility issues can occur.

What to Look for in Dynatrace z/OS Logs

Once versions are verified, the logs contain a wealth of diagnostic data.

Key Information in zRemote Logs

In the zRemote logs, you’ll typically find:

zRemote resource details
```
ZRemote number of cpus=n, total memory=nGB
```
For sizing guidance, see:
👉 zRemote hardware requirements

Build platform

Build platform .............. Linux x86 64-bit

Tenant ID information
Process group IDs
Server or collector IP addresses

Available physical memory

Physical memory limit: 99.99% available (nnnn of nnnn MB taken)

Active Sensors

ZDTP020I Active Sensors: MQ DB2 SOAP CTG DB2Fetch DLI HTTP ZCON

What You’ll Find in zLocal and zDC Logs

The zLocal and zDC logs provide deeper mainframe‑specific insights, including:

z/OS version
LPAR details
ZDCSYSIN configuration values
SMO information
Number of transactions processed

These details are often critical when diagnosing performance, connectivity, or data‑collection issues.

Final Thoughts

Before starting any deep investigation, these are the baseline checks I always perform:

Correct logs identified
Component versions verified
Resource and configuration details reviewed

Having this information upfront dramatically shortens troubleshooting time and leads to faster resolution.

👉 Next up (Part 2):
We’ll cover common Dynatrace z/OS monitoring problems and how to troubleshoot them step by step:
Troubleshooting your z/OS monitoring: Common Issues

Re: Troubleshooting your z/OS monitoring: Covering the basics

dannemca — Mon, 27 Mar 2023 18:16:44 GMT

Thank you, thank you so much for this!! Please keep it going!!! 😁

Re: Troubleshooting your z/OS monitoring: Covering the basics

jellypuno — Tue, 28 Mar 2023 09:38:37 GMT

@dannemca , thank you! 😄 Glad, I could help. If there are more mainframe topics that you would like me to write about, please let me know.

article Troubleshooting your z/OS monitoring: Covering the basics in Troubleshooting

Troubleshooting your z/OS monitoring: Covering the basics

Summary

Downloading the Dynatrace z/OS Support Archive

Step 1: Identify Related zRemote and zLocal Logs

Why This Matters

Verifying Dynatrace z/OS Component Versions

zDC Version

zLocal Version

zRemote Version

Why Version Checks Are So Important

What to Look for in Dynatrace z/OS Logs

Key Information in zRemote Logs

What You’ll Find in zLocal and zDC Logs

Final Thoughts

Related Reading

Re: Troubleshooting your z/OS monitoring: Covering the basics

Re: Troubleshooting your z/OS monitoring: Covering the basics