A Better Way to Collect Performance Data


Collecting system performance data on an OS/400* V5R1 system isn't like it used to be. Collection Services is now the only way to collect performance data from iSeries system resources.

You might have discovered this when attempting to collect some initial performance data on your V5R1 system. You entered the STRPFRMON command to start the Performance Monitor and were greeted with Diagnostic Message CPD0030: "Command STRPFRMON in library *LIBL not found." That was followed by message CPF0001: "Error found on STRPFRMON command." Your first reaction was probably, "Where in the world did the Performance Monitor go? Did IBM really get rid of it? How can I manage the performance of my system without it?"

Yes, IBM really did get rid of the Performance Monitor. It is now in the proverbial software graveyard. It has been replaced by an OS/400 system function called Collection Services. Like the Performance Monitor, Collection Services collects performance data from many system resources including jobs, disk units, I/O processors, buses, pools and communication lines. Available since V4R4, Collection Services has been used by many to collect performance data on systems. The Performance Monitor remained on the system through V4R5 to give customers time to switch over to the new Collection Services function.

The iSeries Performance Management development team has gone to great lengths to ensure that existing performance tools work with the new collector. Even your own queries against the QAPM* performance database files will continue to work because Collection Services provides a way to generate the same database files as the Performance Monitor. Thus, you can still manage the performance of your system with the same tools you have always used. Only the engine that collects system performance data has been replaced.

Why Replace Performance Monitor?
The Performance Monitor was designed in the System/38 days using PL/MI data structures and ported to OS/400 with V1R1. This was a time when a large and fully utilized system had a couple hundred jobs. As the AS/400 and then iSeries continued to get bigger and faster, Performance Monitor could no longer scale to handle the thousands of jobs and threads that became common in modern computing environments. Those designing the PL/MI data structures couldn't anticipate the tremendous growth in system resources and workloads that was to occur over time. As a result, many patches had to be added to the code to keep it working in these growth environments. This made the code inefficient and difficult to maintain.

A second limitation in the Performance Monitor was that the collection of performance data and storage of the data in database files was designed as a single procedure. This worked fine in the early days of AS/400, but as workloads increased, the amount of performance data to be collected increased, and it became too time-consuming to store the data in the database files.


Keith Zblewski is a senior Power Systems consultant at Meridian IT.



2018 Solutions Edition

A Comprehensive Online Buyer's Guide to Solutions, Services and Education.

Configuring AEM to Monitor Power Usage

How to better utilize your available power

Handling Your Sticky Situations

Gain knowledge and save time with iDoctor Situational Analysis

IBM Systems Magazine Subscribe Box Read Now Link Subscribe Now Link iPad App Google Play Store
IBMi News Sign Up Today! Past News Letters