IBM Z and LinuxONE IBM Z

 View Only

 Metric data from IDz

John Malczyk's profile image
John Malczyk posted Fri June 06, 2025 10:34 AM

What Metrics data is available from IDz?  Where can I extract this data related to the following.

Define Objectives

  1. Identify Key Goals: Determine what you aim to achieve with these tools. Common objectives might include:

    • Improved developer productivity

    • Enhanced code quality

    • Reduced time to market

    • Better resource utilization

  2. Performance Metrics:

    • Response Time: How quickly the IDE responds to user actions.

    • CPU Usage: The amount of CPU resources consumed by IDz during various operations.

    • Memory Usage: The amount of RAM used by IDz.

  3. Usage Metrics:

    • Number of Active Users: How many developers are using IDz.

    • Session Duration: Average time spent by users in the IDE.

    • Feature Usage: Which features or tools within IDz are most frequently used.

  4. Development Metrics:

    • Code Quality: Metrics related to code quality, such as error rates or adherence to coding standards.

    • Build Success Rates: How often builds are successful versus failing.

    • Deployment Frequency: How often applications developed in IDz are deployed.

  5. Support and Maintenance Metrics:

    • Issue Resolution Time: How quickly issues reported by users are resolved.

    • Update Frequency: How often IDz is updated with new features or bug fixes.

 

Andrew Tram's profile image
Andrew Tram

Hi John, I'll try to answer as best as I can...

Response Time...
Client side... 

You can track slow UI events using Eclipse’s built-in tracing:

Turn on responsiveness logging:

Edit the developer_for_zos.ini file and add:
-debug
-consoleLog

In the same directory as developer_for_zos.ini, create a .options file with this content:
org.eclipse.ui/trace/UiResponsiveness=true
org.eclipse.ui/trace/UiEventTiming=true

Restart IDz.

Eclipse will now log any UI freeze or delay (typically if it takes longer than 0.5 seconds) to the Console or .metadata/.log file in your workspace. This helps detect slowdowns in things like opening editors or switching views.

CPU Usage...
Client side...

You can observe CPU usage using system tools or Java profilers:

- Simple option: Use your OS task manager.

  • Windows: Open Task Manager > “Details” tab > find developer_for_zos.exe > check CPU column.
  • macOS: Open Activity Monitor > find IDz > check CPU%.
  • Linux: Run top or htop and filter for IDz.

- Advanced option: Use JVisualVM (comes with most JDKs).

  • Run Eclipse as usual.
  • Open JVisualVM and attach to the Eclipse process.
  • View live CPU usage, thread activity, and method-level profiling.

Host side...

Customers can use operator commands to monitor RSE daemon activity...

To view the number of currently active users:

F RSED,APPL=DISPLAY PROCESS,DETAIL

See more here - https://www.ibm.com/docs/en/explorer-for-zos/3.4.0?topic=f-rse-daemon

To check current CPU usage per thread:

F RSED,APPL=DISPLAY PROCESS,CPU

This displays CPU usage per thread. By reviewing the thread tags, customers can often make educated guesses about the type of work each thread is performing.

We do not audit CPU usage directly, as many short-lived threads are started by external components, making it difficult to manage. For deeper performance analysis, customers can use specialized tools such as IBM Application Performance Analyzer.

Additionally, when a thread pool ends, usage statistics are printed to the system log. While these are primarily intended to help tune system limits, customers may find other value in this data.

Memory Usage...
Client side...

- Easiest: Turn on Eclipse’s heap monitor.

  • Go to: Window > Preferences > General > Check “Show heap status”.
  • This shows a memory usage bar in the status area of Eclipse.
  • You can click it to trigger garbage collection (free unused memory).

- System view: Use your operating system’s task manager (same steps as CPU).

- Detailed analysis:

  • Use JVisualVM to monitor heap and non-heap memory.
  • Take a heap dump and analyze with Eclipse Memory Analyzer Tool (MAT) for memory leaks or unusually large objects.

Information on CPU, memory, and response time on IDz can be further investigated by looking into the same against Eclipse since it's the base IDE that IDz is built off of.

Number of Active Users and Session Duration...

Enabling audit logging generates detailed log files that users can post-process as needed for their specific requirements. For more information, see the official documentation: https://www.ibm.com/docs/en/explorer-for-zos/3.4.0?topic=considerations-audit-logging

Build Success Rates and Deployment Frequency...

IDz submits batch jobs for builds, and these activities should be visible in the audit logs if auditing is enabled. For teams using Dependency Based Build (DBB), build activity can also be tracked through DBB's metadata, which provides a searchable history of build executions.

IDz itself does not handle deployments. However, Wazi Deploy, which is included with IDz Enterprise Edition (IDzEE), provides deployment capabilities. Logging behavior for Wazi Deploy is separate, and we recommend consulting the Wazi Deploy documentation or support team for details on what is logged and where those logs are stored.


Code Quality...
IDz has code metrics and analysis built in... further details are mentioned here - https://www.ibm.com/docs/en/developer-for-zos/17.0.x?topic=eclipse-gathering-reporting-metrics-cobol-pli-programs

Issue Resolution Time...

This is a key internal metric for our team and a top priority in our day-to-day work. When a user opens a case that results in an APAR, we immediately prioritize it and focus on delivering a resolution as quickly and efficiently as possible.

Update Frequency...

While we can’t share internal timelines, historically IDz follows a general pattern: the current major release typically receives three to four updates per year, while the previous major release (n-1) sees about two to three updates annually until that EOS. These numbers are based on past trends and are subject to change.


May I ask what’s driving these inquiries?