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?