RMF PM allows you to monitor the performance of your z/OS or OS/390 host from a workstation through a TCP/IP interface to one or more z/OS or OS/390 sysplexes. You logon to any sysplex and you can monitor the resources in the corresponding sysplex.
RMF PM takes its input data from a single data server on one system in the sysplex, which gathers the data from the RMF Monitor III on each MVS image. Therefore, this is called the Distributed Data Server (or DDS). If you want to monitor several sysplexes, each one needs to have an active DDS.
RMF PM provides a selected subset of the information provided by the RMF Monitor III gatherer: general performance data, performance data for jobs, and for systems running in goal mode workload-related performance data like
You have the flexibility to create unique scenarios that monitor the performance of your system. You can sample real-time data as bar charts, combine data from different metrics, or resources together. Once you have created these scenarios, you can save them as PerfDesks.
With PerfDesks, you create a set of DataViews customized to your monitored system(s). DataViews sample performance data into one or more Series displayed as bar charts. You can reuse the DataViews any time. When you save a PerfDesk, all the actions required to produce its DataViews are saved. You can simply open the PerfDesk and start it whenever you want to view performance data in your monitored system again from the same angle.
Note: A saved PerfDesk does not contain any performance data. The PerfDesk samples new performance data each time it is opened and started. However, you can save the sampled data in spreadsheet files.
When you open RMF PM, you will find a list of Sysplexes in the resource view on the left side. Each sysplex comprises a hierarchy of Resources of your monitored system(s). Each Resource has a set of Metrics, which specify what is measured, for example, how the Resource is used or loaded with work.
All help information will be displayed using the Browser of your choice. Using the path View - Options - Help Browser..., use can select either the Netscape Navigator or the Microsoft Internet Explorer.
Here are the steps, to get RMF PM - Java Edition working.
RMF PM uses a server on the z/OS or OS/390 sysplex to retrieve its performance data. This server is called the RMF Distributed Data Server.
The DDS server code is
installed automatically during RMF installation.
Please, refer to the RMF User's Guide for a description how to
customize and to start the RMF Distributed Data Server.
If you are on z/OS or OS/390 Release 6 or higher, the code has to be
upgraded with PTFs to a recent level: see the
README for a recent list of PTFs necessary.
You can start the RMF DDS server with the
"START GPMSERVE" command from the MVS console.
Download the host server code from: "RMF Distributed Data Server (DDS)" After downloading the "gpmserve.zip" file to your workstation and extracting the file, read "readme.htm" with an ordinary web browser (Netscape, MS Internet Explorer, Opera ...) for installation instructions.
Make sure, that the following prerequisites are met on your z/OS or OS/390 host:
Remember the path where RMF PM has been installed (usually C:\Program Files\rmf\pm390).
Later on, you can define additional sysplexes using the New Sysplex dialog, or you can change the settings of the initial sysplex using the Change Sysplex dialog which has the same fields as the New Sysplex dialog.
For Linux users: download
the Linux version of RMF PM
Please install the downloaded package using
tar xvfz gpmlinpm.tgz; this gives you an rmfpm directory.
An IBM Java 2 Runtime Environment is included in this package.
In order to start RMF PM under Linux, just type
./rmfpm in the rmfpm directory.
From the taskbar, using the path Start - Programs - RMF Workstation
Products - RMF PM, you start RMF PM, and you get the main window of RMF PM:
There are two views:
In the initial setup of RMF PM, the PerfDesk Folder Samples containing the PerfDesk Sysplex-Overview has been defined to be started automatically when starting RMF PM. This PerfDesk is connected to the sysplex that you have defined during installation. Therefore, the Sysplex Logon dialog will now be started.
Logon to a sysplex requires a TSO User ID and a Password to establish a TCP/IP session to an z/OS or OS/390 host system.
The Logon dialog will pop up for each sysplex that you have defined with an Startup PerfDesks. Selecting Ok submits a logon request to the host. The request may take up to several minutes depending on how far the sysplex to be monitored is and how much it is loaded.
The user ID is preset in the Logon dialog but can be overwritten. You can change the preset user ID in the Change Sysplex dialog which has the same input fields as the New Sysplex dialog.
Note: If a Logon fails several times, an expired password may be the reason. You should logon as TSO user to the host session, and change the password there before returning to this dialog. You cannot change the passwort from RMF PM.
When the logon request has been completed successfully, the initial Perfdesk is loaded and started immediately.
With RMF PM, you can monitor the performance in one or more z/OS or OS/390 sysplexes. This section describes how to define a sysplex for monitoring and how to open and close a sysplex.
This dialog will pop up as a result of selecting File - New - Sysplex....
The areas in this dialog are:
Here you can enter a description of the sysplex.
The TCP/IP name of the host, which can be either:
Here, you should enter the port number of the RMF DDS Server on the host, 8801 is the default value. Your system administrator should be able to give you the number.
If you'd like to use the HTTP protocol to get the data from the z/OS or OS/390 sysplex, you can check the "Use HTTP" checkbox and type in the associated HTTP port number. Please note that this is normally port number 8803.
We'd like to remove the proprietary non-HTTP protocol in a future version of RMF PM.
Here, you can enter user id which appears preset in the Sysplex Logon dialog.
You may leave the default value of 180 seconds.
This field allows you to the select a GMT-Offset. If you never changed the selection, the locale GMT-Offset of your workstation should be shown selected.
Therefore, you only need to change it, if the host associated with the sysplex is so far remote, that it resides in a different Time-Zone . The GMT-Offset affects the time stamps in your DataViews.
Date/Time at sysplex must show the current wall clock time at the sysplex. If it is incorrect (for the remote sysplex), select a time-zone with a GMT-Offset, so that the correct Date/Time at sysplex is shown.
You should enter each DB/2 PM SSID locally configured on your Windows workstation and associated with the TSO User-ID given on this panel. If you later on start a DB/2 PM Module (Statistics, Threads, Exceptions) using Actions - DB/2 PM, RMF PM automatically uses the User ID/ password pair associated with this z/OS or OS/390 host.
Check this if you're using the same user ID and password for several sysplexes. RMF PM assumes you're using the same user ID and password combination for all sysplexes which have this checkbox selected, so you don't need to type in your password every time.
Push Buttons: Ok - Cancel - Help
Ok will cause the changes to be saved, the changes will be effective immediately.
Cancel ends the dialog without saving those changes which have been performed after the last Ok.
Help will cause the
New Sysplex dialog help to be shown.
An open sysplex is charaterized by the indicator [+] in front of its name. This indicator can be used to expand the sysplex into its resources.
Without this indicator, the sysplex is closed and needs to be opened to access its resources. To open a sysplex either double click on it, or select Open from its context menu. Then, the Sysplex Logon dialog will pop up.
To close a sysplex, select Close from its context menu. All contained resources will not be accessible until the sysplex is opened again.
You can also use the path File - Open/Close - Sysplex... to open or close a sysplex. This leads you to the Sysplex Selection dialog where you have to specify the name of the sysplex.
Using the path File - Delete - Sysplex..., you come to the same dialog. After the selection of the sysplex to be deleted, you will be prompted for a confirmation.
The [+] indicator before the sysplex means that you can expand it into its resources. Just click on the [+] and the resources should be listed indented below the sysplex.
[-]My Sysplex - PRODPLEX, Sysplex [+] SYS1, Image [+] SYS2, Image [+] CF1, Coupling Facility [+] CF2, Coupling Facility
The [-] before 'My Sysplex' means it is expanded into its Resources. You can collapse it by clicking on the [-].
Note: This will not close the sysplex, but will change only the graphical representation of the resource structures.
The [+] before a Resource means that you can expand it into its Resources. If you click on the [+], the contained Resources should be listed indented below the expanded Resource.
[-]My Sysplex - PRODPLEX, Sysplex [-] SYS1,Image [+] SYS1,I/O-Subsystem SYS1,Processor [+] SYS1,Storage SYS1,Enqueue SYS1,Operator [+] SYS1,S/W-Subsystem [+] SYS2,Image [+] CF1,Coupling Facility [+] CF2,Coupling Facility
A Resource without a [+] before its name means it does not have contained Resources.
To create a DataView from a Resource, select New DataView... from its the context menu. This leads you to the Creating a DataView dialog.
The PerfDesks notebook page allows you to manage your PerfDesks and DataViews from a central point:
A PerfDesk is a set of DataViews that can be created, saved, opened and started alltogether.
A PerfDesk Folder is a container for one or more PerfDesks.
Using File - New - PerfDesk Folder..., you can add very fast a new PerfDesk folder.
Using File - New - PerfDesk..., you start the Save PerfDesk dialog, which displays a list of all existing PerfDesk folders. Now, you can select one of these folders as container for the new PerfDesk, or you can create a new folder. In addition, you will specify the name of the new PerfDesk by overwriting the preset name New PerfDesk. With clicking on Save, you complete this process.
You can open a Perfdesk just by double-clicking or through its context menu. This will add a new tab to the right part of the window, called Open PerfDesks, and you will see all DataViews belonging to the PerfDesk. Using File - Open - PerfDesk... is another way for this task.
All containers in the PerfDesks Overview which are not empty, can be expanded very easily:
Example:
If a PerfDesk contains DataViews, you will see a [+] in front of its name:
If you click on the +, the PerfDesk will expand into its DataViews:[+]Sysplex-Overview
[-]Sysplex-Overview [+]Processor utilization of systems in Sysplex [+]Performance index of most important workloads [+]I/O: Volumes with highest activity in Sysplex [+]Users per image
In an Open PerfDesk:
Clicking on Start will start data sampling in all DataViews belonging to the PerfDesk, this is indicated by the Run Light of all DataViews which will turn to green. Clicking on Stop stops data collection.
Of course, you can also start or stop each DataView individually by clicking on the appropriate Run Light.
Before you save a Perfdesk make sure the name of the PerfDesk and its DataViews reflect what is sampled in its Series. Neither PerfDesk, nor one of its DataViews should be named 'New'. Clicking on Save... opens the Save PerfDesk dialog, here you have also to select a PerfDesk Folder, where you want to save the PerfDesk.
During Close you will be prompted whether you want to save any changes that you have performed to the PerfDesk.
Step all DataViews of this PerfDesk back one sample. If the data needed is not available, the affected DataViews are stopping.
Step all DataViews of this PerfDesk forward one sample. If the data needed is not available, the affected DataViews are stopping.
Open the following dialog:
You can specify a start date/time and a stop date/time. After you've pressed the "Ok" button, all available performance samples for all DataViews of this PerfDesks for the specified time range are automatically collected.
Please note that RMF PM gets its data from the z/OS host, meaning that all performance data has to be calculated by the z/OS RMF Monitor III. So if you're calculating the data for many different times, you can use some amount of CPU on the host.
All DataViews of this PerfDesk are synchronized to the time of the selected DataView.
If this checkbox is checked, this PerfDesk is automatically started each time you're starting RMF PM. Please note that you do not need to save the PerfDesk after changing the Startup attribute of a PerfDesk; it is directly written to the disk.
Context item New DataView.. is one way for Creating a DataView.
The context item Change Description... offers the function to change the name of the PerfDesk.
PerfDesk or DataView should be given names so that their purpose can be easily identified. PerfDesk names should sum up the purpose of its DataViews and DataView names should reflect what is sampled in their Series.
Names can contain alphanumeric characters and spaces.
The corresponding path is also available for changing the name of a PerfDesk folder.
If a DataView has been previously copied to the clipboard, it can be pasted to the selected PerfDesk.
A DataView displays the performance data currently sampled as so called Series.
For adding a DataView to a PerfDesk, you select New DataView... from the context menu either of an open PerfDesk in the PerfDesks notebook page or of a PerfDesk in the Open PerfDesks window. This will start the New DataView - Properties dialog, which offers you an input field to specify the Title of the DataView. Furthermore:
Clicking Ok leads you to the Series Definition dialog where you can define the metrics of the Series that you want to add to the DataView.
Using File - New - DataView... will also lead you to this process.
Note: For defining a Series, it is necessary that you have selected a resource in the Resources notebook page. If this is not the case, you will get the message Select a Resource of the correct type. Now, you have to Close the dialog and to select the resource of your interest in the Resources notebook page.
Having in mind the above note, you also can use a resource as starting point of the above described process:
Another function of this dialog is to display the properties of a specific resource.
Both ways will lead you to the New DataView - Properties dialog.
A DataView contains three areas:
The DataView has a Context Menu for actions applicable to the entire DataView as opposed to a single Series. This menu will pop up, if the right mouse button is selected in the background of the bar chart.
When creating a DataView, you specify whether you want to create a DataView with horizontal or vertical bars. All following descriptions refer to vertical bar charts.
The bars represent the value measured. A scale to the left gives an estimate of the highest value measured so far. The bars are colored so they can be identified in the legends. Left of the scale below the horizontal axis, date and time are shown.
There are two types of a bar chart:
Note: It is not possible to display a Single-Value and Value-list chart in the same DataView.
A single-value chart displays Series with one value per time-stamp, for example, % delay or # active users.
A value-list chart displays Series having for one metric (for example # active users) a list of values reported: # active users by MVS image.
Several actions can be applied to a bar in the chart:
If you see a value that could be an indicator for a performance problem, analysis might be useful. Selecting Analysis leads to the Analysis dialog which offers you other DataViews with Series related to the value which you want to analyze.
Selecting Find highest will search for the highest value in the Series and will display it.
Selecting Find lowest will search for the lowest value in the Series and will display it.
Selecting Series Settings leads to the Change Series dialog. Depending on the type of the Series, it will have up to three pages:
Will remove the Series from the DataView. Unless the PerfDesk is saved after the removal, the Series will be present the next time the PerfDesk is loaded.
Here, you can select that color for the Series that you would like to have.
A Legend is a description of the Series . It consists of four elements:
Except for 'Analysis', the same actions as in the Bar Chart Context Menu can be applied.
The Control Panel of a DataView allows you to control the sampling and display of the Series:
At the bottom of the DataView, you find a Position Indicator and a Time-Slider.
The position indicator shows two values:
Example: Sample: 34 Total: 105
The position of the first value in the DataView is 34 out of 105 values.
By moving the time-slider to the left or to the right, you will change the time frame for which the series will be displayed.
In the left lower corner of the panel, you see the Run Light which is also the Start/Stop Button. It indicates if the DataView is sampling:
Between the Start/Stop button and the time-slider you see the Plot/Save Button which leads you to the Plot/Save Series dialog with the capability to plot a Series or part of it, and to save the data to a .WK1 spreadsheet file.
You know the first page from this dialog, when you have specified the values while creating a new DataView. Now, the dialog has a second page Sampling. You see all details about the sampling for the series in this DataView, and you can change these settings, for example, the reporting interval.
Each Series is associated with a Series definition. Therefore, a Series Definition dialog will pop up to specify the Sysplex, Resource, Metric and other details.
This context item shows another way to the Plot/Save Series dialog.
Here, you can remove all values that have been gathered for the series belonging to the DataView.
If you want to copy a DataView into another PerfDesk, you call this function which copies the DataView into the clipboard. In the target PerfDesk, just call Paste to complete the task.
Here, you can print the selected DataView with the printer of your choice.
This dialog will pop up as a result of selecting Properties in the DataView's context menu. It allows you to modify sampling of the Series in several ways:
Lists the Series legend and the individual sample interval. If the interval is **:**:**, the interval could not be obtained.
If the checkbox is selected, the Common Interval is used. Initially, the spinbutton shows the least Common Interval of all Series, or what was previously adjusted. It allows you to adjust it to multiple of this least interval.
Selecting the checkbox, you can adjust to any time in the past or future, when sampling should be started. If the Sample To checkbox is not selected, it means "continue to sample until manually stopped".
Initially, the spinbutton shows the current time minus one hour, or what was set previously.
Selecting the checkbox, you can adjust to any time in the past or future, when sampling should be stopped. If the Sample From checkbox is not selected, it means "start sampling now" and stop when the Sample-To time is reached.
Initially, the spinbutton shows the current time, or what was set previously.
Note: The time-stamp is affected by the setting of the Time-zone. So, make sure the time-zone is set correctly.
This field shows the size of the wrap-around buffer, this is the maximal number of samples that can be available to be displayed.
Using the path View - Options - Set Time-Zone..., you get a panel where you can specify the time-zone, your sysplex belongs to.
A Series comprises:
The time-stamps are in the form HH:MM:SS, with HH in the 24-hour format. The date in MM/DD format is shown separately in front of the scale below the x-axis in the DataView.
Note: The time-stamp is affected by the setting of the Time-zone. So, make sure the time-zone is set correctly.
This dialog will pop up when you:
It basically allows you to add Series to a DataView. Here you specify all details which are required to sample data on the monitored system like the Sysplex, the Resource, or the Metric, to form a Series definition.
If you have selected a Resource in the Resources notebook page, all you need to select is a Metric, because the Resource is preselected. Otherwise, you will be prompted to select a Resource.
The areas in the dialog from top to bottom are:
Selection affects the type of Metrics shown in the Metrics list.
Contains the types of Metrics available for the Resource. Context item Description on a selected Metric or button Metric Help will pop up a description.
Push Buttons - Add - Done - Metric Help - Help
If a Metric is selected, clicking on Add causes the resulting Series to be added to the DataView. The dialog is not ended, thus allowing further selections.
The Done button ends the dialog.
Clicking on Metric help leads to an explanation of the selected Metric.
Clicking on Help displays general information about this dialog.
This dialog will pop up as a result of selecting Plot/Save Series... in the DataView's context menu, or by clicking the Plot/Save button. It allows you to view Series plots and save Series of a DataView in a selective way.
You can select:
The areas in the dialog from top to bottom are:
In this area, the values of Series are plotted over time. The parts in this area from top to bottom are:
The Control Panel allows to:
The areas from top to bottom are:
Besides the usual Cancel and Help buttons, there are the buttons Save... and Print....
Clicking on Save... leads to a Save Series dialog. A file dialog will pop up with a file wildcard of *.wk1, because the spreadsheet is stored in .WK1 format.
Clicking on Print... lets you print the plot on the printer of your choice.
This area on the top of the dialog informs you about the Resource and the Metric for which a filter can be specified in this panel.
A multi-valued metric consists of a list of name-value pairs, for example, "Response Time by Volume". A filter is provided to reduce the number of name-value pairs of a multi-valued metric, and to sort them by name or value.
Filtering is performed stepwise in the following sequence:
Optionally, one or more name patterns in the form of a simple expression
to be matched against the names in the list of name-value pairs of the
multi-valued metric can be entered in this field.
The following rules apply to this definition:
You have to specify in the entry field:
XJSMITH1|\*MASTER\*|BA??|CIC*|*HOT*
Note: The \ in '\*' means: take * as a character, and not as a character string of any length (wildcard).
A list of valid names to be used as patterns is provided. It may take some time for the program to bring up a long list of these names for the first time. When the selection list is available, the entry field can be filled in by selecting items from the list. Selected items are concatenated with | in the entry field. The entry field can be edited.
Clicking Refresh will get you from the host a refreshed selection list.
Optionally, an upper bound and a lower bound to be compared against the values in the list of name-value pairs of the multi-valued Metric can be entered. If both upper and lower bounds are specified, the upper bound must be greater than or equal to the lower bound.
All list elements with values higher than the specified upper bound, and all list elements with values lower than the specified lower bound, are discarded.
For ordering the values in the list of name-value pairs of the multi-valued metric, you must select one of the choices:
For restricting the length of the list of name-value pairs of the multi-valued metric, you must select one of the choices:
Note: This dialog is available only for systems running in goal mode.
This area informs you about the Resource and the Metric, for which a Work Scope name can be specified in this panel.
You have to select a work scope type:
For Work Scope Type = Total nothing has to be entered here.
For other work scope types, a list of valid names is provided. It may take some time to create a long list of these names for the first time. When the selection list has been filled, the entry field may be filled in by selecting an item from the list.
RMF PM
will remember the selection list and will display it again
the next time.
Refresh
can be used to get a refreshed selection
list.
The Title shows the sysplex for which analysis is intended.
Resource, Work Scope, Metric, Value, Name, and Sample Time
These fields inform you about the source of the analysis which is the context of the data point in the DataView that you clicked on. You can either have analysis based on
If the work scope field is empty, then the Metric is not for a specific work scope rather than global.
Analysis Type
This listbox allows you to select another PerfDesk as the next step of the analysis.
Each alternative is shown with the resource and its work scope (if
required) as the target for the analysis.
Close Previous PerfDesk(s)
The PerfDesks that were previously shown during the analysis process
can be closed to avoid a "messy" screen with too many DataViews. The selected
PerfDesks will be closed, when the checkbox is selected.
The following sections describe the objects involved in monitoring with
RMF PM.
In general, RMF PM
can monitor one or more sysplexes,
where each sysplex provides access to system management information for
a certain set of
resources.
A resource is any facility of a computing system or an operating system required by a job or task. This includes storage, processor, channels, volumes, or software subsystems. Resources are named according to the following naming conventions:
SYS1,Image
CF1A,Coupling Facility
SYS1,0020,Storage Subsystem
SYS1,0030,Storage SubsystemSYS1,TSO001,Volume
SYS1,TSO002,Volume
Sysplex
A sysplex consists of one or several
MVS images
.
You can either expand the sysplex to these images, or you can select
a new DataView. The available data is either
MVS Image
An MVS image consists of several resources to which it can be expanded:
I/O-Subsystem
You can either expand this resource to see the details of the I/O configuration:
Storage Subsystem (SSID)
You can either expand this resource to see SSIDs, or you can select a new
DataView with information about cache hits and misses by SSID.
In addition, details for an SSID (type, model, storage size, NVS) are available.
Logical Control Unit
You can either expand this resource to see all
LCUs, or you can select a new DataView with information belonging
to LCUs.
Channel
You can either expand this resource to see all channels, or you can select a new
DataView with information about the utilization of channel paths in the
system.
In addition, details for the channel (channel type) are available.
Volume
Due to the fact that typically the number of volumes in an installation is very high,
not all volumes will be shown when expanding this resource level, but ranges of volumes,
which can be expanded to single volumes with a second step.
You can select a new DataView with information belonging to specific
volumes.
In addition, details for the volume (device type, device address, CU
type) are available.
Processor
You can select a new DataView with information about the usage of the
processor and about delays for jobs waiting for the processor.
In addition, details for the processor (model and version) are available.
Storage
You can select a new DataView with information about the usage of storage
and about delays for jobs waiting for storage. The information is available
in some more detail for the different types of storage:
Central Storage
You can select a new DataView with information about the usage of central
storage and about delays for jobs waiting for storage. The information
is available in some more detail for the different areas of central storage:
CSA - Common System Area
You can select a new DataView with information about the usage of the
common system area.
ECSA - Extended Common System Area
You can select a new DataView with information about the usage of the
extended common system area.
SQA - System Queue Area
You can select a new DataView with information about the usage of the
system queue area.
ESQA - Extended System Queue Area
You can select a new DataView with information about the usage of the
extended system queue area.
Expanded Storage
You can select a new DataView with information about the usage of expanded
storage.
Auxiliary Storage
You can select a new DataView with information about the usage of auxiliary
storage slots.
Enqueue
You can select a new DataView with information about delays in the
system caused by usage of serially reusable resources.
Operator
You can select a new DataView with information about delays in the
system caused by jobs waiting for the operator to reply to a message or
mount a tape, or by address spaces that are quiesced by the operator.
SW-Subsystem
You can select a new DataView with information about delays in the
system caused by jobs waiting for service from
JES - Job Entry Subsystem
You can select a new DataView with information about delays in the
system caused by jobs waiting for service from JES.
HSM - Hierarchical Storage Manager
You can select a new DataView with information about delays in the
system caused by jobs waiting for service from HSM.
XCF - Cross-System Coupling Facility
You can select a new DataView with information about delays in the
system caused by jobs waiting for service from XCF.
Coupling Facility
You can select a new DataView with information about performance and
usage of Coupling Facilities installed in your Parallel Sysplex.
This resource type is only supported, if you have OS/390 V2R6 or later installed on your system.
CPC
CPC stands for "central processor complex". Resources from the CPC are LPARs (logical partitions). Apart from PR/SM LPAR partition details like "total physical utilization by partition", there are some metrics important for ILM (IBM License Manager) support. If you are interested in ILM data, you should also try out remaining time until capping in seconds (by partition) under the Sysplex resource.
This resource type is only supported, if you have at least z/OS V1R2 with SPE OW49807 installed on your system.
RMF PM has two formats for presenting performance data:
The unique indicator in the name of a Value-List Metric is the keyword by .
% channel path partition utilization
The channel path utilization percentage for an individual logical partition.
RMF uses the values provided by CPMF (Channel Path Measurement Facility).
In LPAR mode, the calculation is:
% partition utilization = (CBT / CET) * 100
In BASIC mode, blanks are shown.
% channel path total utilization
The channel path utilization percentage for the entire system during
an interval.
For shared channels in LPAR mode, or for all channels in BASIC mode
with CPMF not available, the calculation is:
% total utilization = (SCB / N) * 100
For unshared channels in LPAR mode, the value for total utilization
is the same as partition utilization.
For all channels in BASIC mode with CPMF available, the calculation
is:
% total utilization = (CBT / CET) * 100
% enqueue delay
The percentage of time during the report interval that the system or
job was waiting to use a serially reusable resource that another system
or job was using.
% HSM delay
The percentage of time during the report interval that the system or
job was waiting for services from the Hierarchical Storage Manager (HSM).
A
high HSM delay
value might be caused by one or more of the
following:
% JES delay
The percentage of time during the report interval that the system or
job was waiting for services from the Job Entry Subsystem (JES).
A
high JES delay
value might be caused by one or more of the
following:
% operator delay
The percentage of time during the report interval that the system or
job was waiting for the operator to reply to a message or mount a tape,
or the address space was quiesced by the operator.
% processor delay
The percentage of time during the report interval that the system or
job or enclave was waiting for a processor.
A
high processor using
value might be caused by one or more
of the following:
A
high processor delay
value might be caused by one or more
of the following:
% storage delay
The percentage of time during the report interval that the system or
job was waiting for a COMM, LOCL (both include shared pages), SWAP, or
VIO page, was on the out/ready queue, or was a result of a cross-memory
address space or standard hiperspace paging delay.
For enclaves, only COMM, cross-memory, and shared page delays apply.
A
high storage delay
value can be associated with common storage
paging (COMM), local storage paging (LOCL), swap-in delay (SWAP), swapped
out and ready delay (OUTR), and other delays (OTHR) which includes virtual
I/O paging and paging delays from cross-memory address spaces and standard
hiperspaces.
A high storage delay associated with
common storage paging
might
be caused by one or more of the following:
A high storage delay associated with
local storage paging
might
be caused by one or more of the following:
A high storage delay associated with
virtual I/O
might be
caused by one or more of the following:
A high storage delay associated with
swap-in
activity might
be caused by one or more of the following:
A high delay value for address spaces that are
swapped out and
ready
might be caused by one or more of the following:
Other
storage delays might be caused by one or more of the
following:
% subsystem delay
The percentage of time during the report interval that the system or
job was waiting for services from
% XCF delay
The percentage of time during the report interval that the system or
job was waiting for services from the Cross-System Coupling Facility (XCF).
A
high XCF delay
value might be caused by one or more of the
following:
% total delay
The percentage of time during the report interval that the job was
not using any resources and was delayed for at least one of the following
resources:
Note:
If a job with several tasks is simultaneously delayed
for more than one resource, RMF counts this job only once as delayed when
it calculates delay percentage.
% idle
The percentage of time during the report interval that the system or
job was idle.
RMF considers a job idle if it is in terminal wait, timer wait, or
is waiting to be selected by JES, and it is not using or waiting for any
resource that RMF monitors.
% using
The percentage of time during the report interval that the system or
job was using one or more processors or devices.
Note:
If a job with more than one task is simultaneously using
and delayed for the same resource, RMF counts the job once as using and
once as delayed (regardless of how many times it is found using and delayed).
If a job is delayed for more than one resource, it is counted once for
the overall delay and once for each resource causing a delay.
% workflow
Workflow percentage is the speed at which a job is moving through the
system in relation to the maximum speed at which it could move through
the system.
A low workflow percentage indicates that the job has few of the resources
it needs and is contending with other jobs for system resources. A high
workflow percentage indicates that the job has the resources it needs to
execute and is moving through the system at a relatively high speed.
For example, a job that could execute in one minute if all the resources
it needed were available, would have a workflow of 25 percent if it took
four minutes to execute.
% unknown
RMF considers the system or jobs that are not delayed for a monitored
resource, not using a monitored resource, or not in a monitored idle state
to be in an unknown state.
The value represents the percentage of time during the report interval
that the job was in the system, but not in any monitored state.
Examples of address spaces in an unknown state include those waiting
for devices other than DASD or tape and those that are waiting for work
(idle) using a method that RMF does not recognize. Started tasks (STCs)
are usually found in this category.
% connect time
The sum of the percentages of time during the report interval that
devices used by the job were connected to channel path(s) to transfer data
between the devices and central storage.
Because a job can be connected to more than one device at a time, the
value in connect time percentage can be greater than 100 %.
Note:
This can include devices other than DASD and tape; for
example, graphic displays.
% using
The percentage of time during the report interval that one job or all
jobs in a group or in the system were using one or more devices.
RMF considers a job to be using a device as soon as the job's I/O request
is queued in the channel for the device. Therefore, the using percentage
for a device includes both active time on the device and queuing delay
in the channel.
i/o activity rate
The rate per second that I/O instructions (SSCH, RSCH, and HSCH) to
a device completed successfully.
IOS queue time
The average number of milliseconds an I/O request must wait on an IOS
queue before an SSCH instruction can be issued. A delay occurs when a previous
request to the same subchannel is in progress.
response time
The average response time (in milliseconds) that the device required
to complete an I/O request.
i/o intensity
The product of the number of users and the time waiting in average
for a DASD device because of one of the following reasons:
There is no common name for I/O intensity in the literature. Other programs might use different names. The following terms are equivalent to I/O Intensity: DASD MPL, Response Time Volume.
% active time
The percentage of time during the report interval that the device was
active.
active time = connect time + disconnect time + pending time
% connect time
The percentage of time during the report interval that the device was
connected to a channel path.
% disconnect time
The percentage of time during the report interval that the device had
an active channel program, but was not connected to the channel.
Disconnect time includes seek time, normal rotational delay time, and
extra rotational delay time because the channel was busy.
% pending time
The percentage of time during the range period that I/O requests were
waiting in a channel queue before a path was available.
Pending time includes the time spent waiting for a device, a control
unit, a head of string, or a channel.
% I/O delay
The percentage of time during the report interval that the job is waiting
for any DASD or tape, or has an I/O request queued in the channel for a
device, but not transmitting data (for example, is being disconnected to
seek).
A
high device delay
value for a job usually means that another
job has a high using value for the same device. Use the Device Delay report
to determine what volume a job is waiting for; then use the Device Resource
Delay report to determine how the job using that volume is spending its
time.
General reasons for a
high device using
value might include:
Using time for a volume will approximately equal connect time (time
that the device was connected to a channel path). Using time does not include
disconnect time (time that the device had an active channel program but
was not connected to the channel) and pending time (time that I/O requests
were waiting in a channel queue before a path was available).
A high
connect percentage (CON %)
might be caused by one or
more of the following:
A high
disconnect percentage (DSC %)
might be caused by one
or more of the following:
A high
pending percentage (PND %)
might be caused by one
or more of the following:
% delay device busy
The percentage of time during the range period when there was an I/O
request delay because the device was busy. Device busy might mean that
another system is using the volume, another system reserved the volume,
or a head of string busy condition caused the contention.
% control unit busy
The percentage of time during the range period when there is an I/O
request delay because the control unit was busy. If the device is shared
at the control unit level, a sharing system might be using the device.
If the device is not shared at the control unit level, the contention is
the result of other activity to different devices over an alternate path
serviced by this control unit.
% director port busy
The percentage of time during the range period when there is an I/O
request delay because the ES Connection Director port was busy.
% using
The percentage of time during the report interval that the job was
using the volume.
RMF considers a job to be using a device as soon as the job's I/O request
is queued in the channel for the device. Therefore, the using percentage
for a device includes both active time on the device and queuing delay
in the channel.
% all channel paths busy
The percentage of time during the measurement interval when all channel
paths belonging to the LCU were busy at the same time.
Only channel paths that are both online to the system and connected
to a device are included in the calculation:
% all channel paths busy = CHPID0 * CHPID1 * CHPID2 * CHPID3
where CHPIDn = Percentage busy of each channel path involved
% control unit busy
This value shows for each channel path of the LCU the relationship
between requests deferred due to control unit busy and total successful
requests serviced by that path.
Each CHPID of the LCU measures the distribution of control unit contention.
The calculation is:
% control unit busy = ((CUB / (DPB + CUB + SUC)) * 100
% director port busy
This field indicates
director port contention
.
It is the number of times an I/O request was deferred because the director
port was busy during the measurement interval.
The calculation is:
% director port busy = ((DPB / (DPB + CUB + SUC)) * 100
% CHPID taken
The rate at which I/O requests to devices of this LCU are satisfied
by each CHPID during the interval.
By reviewing the rate at which each channel path of the LCU satisfies
I/O requests, you can see how evenly the work requests are distributed
among the available paths and how effectively those paths are arranged
for the LCU.
The calculation is:
% CHPID taken = (TO / SI) * 100
# delayed i/o requests
The average number of
delayed requests
on the control unit header
(CU-HDR).
Each time a request is enqueued from the CU-HDR, RMF counts the number
of requests remaining on the queue and adds that number to the accumulator.
The calculation is:
# delayed i/o requests = (AL - ER) / ER
delayed i/o request rate
The rate per second at which the IOP places delayed I/O requests on
the CU-HDR for this LCU. This is done when all paths to the subchannel
are busy and at least one path to the control unit is busy.
For devices with only one path, or for devices where multiple paths
exist and the busy condition is immediately resolved, the IOP does not
count the condition.
The calculation is:
delayed i/o request rate = ER / SI
% delay by volume
The percentage of delay caused because the job was waiting to use the
named volume.
% using
The percentage of time during the report interval that one job or all
jobs in a group or in the system were using one or more processors.
% TCB+SRB
The percentage of total processor time used by the job during the report
interval.
working set
The working set represents the (central or expanded) storage the user
has when a job is actually running. Shared page counts are not included
in the working set.
% delay for SWAP
The percentage that swap-in delays contributed to the delay of a job.
% delay for COMM
The percentage that common storage (common service area (CSA) or link
pack area (LPA)), including shared pages, contributed to the delay of a
job.
% delay for LOCL
The percentage that local (private) storage paging, including shared
pages contributed to the delay of a job.
% delay for OTHR
The percentage that various types of delays contributed to the delay
of a job.
This is the sum of:
% delay for OUTR
The percentage that swapped-out-and-ready delays contributed to the
delay of a job.
% available
The percentage of common storage (CSA, ECSA, SQA, or ESQA) available
for allocation at the end of the specified range period.
% not released
The percentage of allocated common storage (CSA, ECSA, SQA, or ESQA)
that was not released when a job ended.
% utilization
The percentage of common storage (CSA, ECSA, SQA, or ESQA) used during
the specified range period.
# frames not released
The amount of allocated common storage (CSA, ECSA, SQA, or ESQA) that
was not released when a job ended.
# frames used
The amount of common storage (CSA, ECSA, SQA, or ESQA) used during
the specified range period.
# frames defined
The amount of common storage (CSA, ECSA, SQA, or ESQA) defined to the
system at IPL.
# frames idle
The average number of frames held by a job while it was idle.
# frames total
The sum of the active and idle frames.
Note:
The shared page counts are not included in this value.
# frames active
The average number of frames held by a job while it was active.
# frames fixed
The average number of fixed frames a job was using during the report
interval including frames both above and below the 16 megabyte line.
A fixed frame is a frame that cannot be paged out of central storage.
# frames DIV
The DIV frame count represents the number of Data-in-virtual frames
in relation to the number of Data-in-virtual samples.
# slots
The total number of the auxiliary storage slots a job used, averaged
over the report interval.
es rate per residency time
The value is the rate of page-moves from expanded storage to central
storage per active second. This count is the total page-move count divided
by the time the user was swapped-in.
It includes single and blocked pages, but does not include shared,
hiperspace or VIO pages.
pgin rate
The rate at which pages are being read into central storage.
It is calculated by dividing the total page-in count (for the group)
by the resident time.
The address-space related shared storage page-ins are included in the
value.
migration age
Migration age is the average number of seconds a page resides on expanded
storage before it migrates to auxiliary storage.
unreferenced interval count
The average high unreferenced interval count (UIC) is an indicator
of central storage contention. A high UIC count indicates that storage
contention is low and you are not experiencing any storage problems.
% frames active
The percentage of storage allocated to jobs that are active.
% frames available
The percentage of available storage.
% frames idle
The percentage of storage allocated to jobs that are idle.
% frames CSA
The percentage of storage allocated to the common storage area (CSA).
% frames LPA
The percentage of storage allocated to the link pack area (LPA).
% frames NUC
The percentage of storage allocated to the nucleus (NUC).
% frames SQA
The percentage of storage allocated to the system queue area (SQA).
# delayed jobs for COMM
The average number of jobs in each group that are delayed for common
storage (common service area (CSA) or link pack area (LPA)), including
shared pages.
# delayed jobs
The average number of jobs in each group that are delayed for any of
the storage reasons COMM, LOCL, SWAP, OUTR, or OTHR.
# delayed jobs for OTHR
The average number of jobs in each group that are delayed for various
types of delays.
This is the sum of:
# delayed jobs for OUTR
The average number of jobs in each group with swapped-out-and-ready
delays.
# delayed jobs for LOCL
The average number of jobs in each group that are delayed for local
(private) storage paging, including shared pages.
# delayed jobs for SWAP
The average number of jobs in each group with swap-in delays.
pgin rate per residency time
The average number of page-ins per second for an address space.
The calculation is the total number of non-swap page-ins (including
VIO page-ins, hiperspace page-ins, page-ins caused by page faults, and
shared storage page-ins) during the range period divided by the total time
an address space was swapped-in (residency time).
execution velocity
The execution velocity of the MVS system, workload group, service class
or service class period being reported on. This value is calculated independent
of a specified goal.
The value for execution velocity is calculated as CPU using, divided
by the sum of CPU using and total delays gathered by WLM.
A high value indicates little workload contention while a low value
indicates that the requests for system resources are delayed.
response time
The average response time (in seconds) for all transactions of a job
class (*SYSTEM, *TSO, *BATCH, *STC, *ASCH or *OMVS), a WLM workload, or
WLM service or report class that ended during the range period.
The response time value is the sum of the queued time and the active
time for an average ended transaction.
transaction rate
The number of transactions per second for a job class (*SYSTEM, *TSO,
*BATCH, *STC, *ASCH or *OMVS), a WLM workload, or WLM service or report
class during the range period.
% partition utilization
MVS view of CPU utilization.
For example, if an MVS partition has 5% of the processor capacity and
the physical CPU utilization reported by RMF for the partition is 5%, this
indicates an MVS view of 100% CPU utilization.
This Metric is available in LPAR mode only, because in
Basic mode
(non-LPAR
mode) this value is shown in the
% total utilization
Metric.
% workflow
The average speed at which the jobs in the group are moving through
the system in relation to the maximum speed at which they could move through
the system.
A low workflow percentage indicates that jobs in the group have few
of the resources they need and are contending with other jobs for system
resources. A high workflow percentage indicates that jobs in the group
have the resources they need and are moving through the system at a relatively
high speed.
For example, jobs in a group that could process in four minutes if
all the resources that they needed were available, would have a workflow
of 25% if they took sixteen minutes to process.
% average CPU utilization
The average utilization percentage for all processors during the report
interval.
# active users
The average number of active users in the system or in a group of address
spaces.
Active users include those using a monitored resource, those delayed
for a monitored resource, and those doing activities that RMF does not
measure.
Each system user is either active, idle or unknown during a report
interval.
% SRB
The average percentage of SRB time used by the system.
% TCB
The average percentage of TCB time used by the system.
% TCB+SRB
The average percentage of processor time used by all address spaces
per processor.
# users
The average number of total users in the system or in a group of address
spaces.
# using jobs
Average number of users using devices.
# using jobs
Average number of users using the processor.
# processor online
The number of processors online during the range period.
% workflow
Workflow percentage with respect to the processor is the speed at which
one job or all jobs in a group or in the system are using the processor(s)
in relation to the maximum speed at which they could do this.
The calculation for this value is:
%workflow = (%using / (%using + %delay)) * 100
In this formula, the values of %using and %delay refer to the processor.
% workflow
Workflow percentage with respect to devices is the speed at which one
job or all jobs in a group or in the system are using the devices in relation
to the maximum speed at which they could do this.
The calculation for this value is:
%workflow = (%using / (%using + %delay)) * 100
In this formula, the values of %using and %delay refer to devices.
# using jobs
The average number of jobs using either the processor or devices during
the report interval.
# delayed jobs
The average number of jobs that are delayed during the report interval
because of at least one of the following reasons:
# delayed jobs for enqueue
The average number of jobs for each group that are waiting to use a
serially reusable resource that another system or job was using.
# delayed jobs for HSM
The average number of jobs for each group that are waiting for services
from the Hierarchical Storage Manager (HSM).
A
high HSM delay
value might be caused by one or more of the
following:
# delayed jobs for JES
The average number of jobs for each group that are waiting for services
from the Job Entry Subsystem (JES).
A
high JES delay
value might be caused by one or more of the
following:
# delayed jobs for operator
The average number of jobs for each group that are waiting for the
operator to reply to a message or mount a tape, or the address space was
quiesced by the operator.
# delayed jobs for subsystem
The average number of jobs for each group that are waiting for services
from
# delayed jobs for XCF
The average number of jobs for each group that are waiting for services
from the Cross-System Coupling Facility (XCF).
A
high XCF delay
value might be caused by one or more of the
following:
# delayed jobs for I/O
The average number of jobs for each group that are waiting for any
DASD or tape, or has an I/O request queued in the channel for a device,
but not transmitting data (for example, is being disconnected to seek).
A
high device delay
value for a job usually means that another
job has a high using value for the same device. Use the Device Delay report
to determine what volume a job is waiting for; then use the Device Resource
Delay report to determine how the job using that volume is spending its
time.
General reasons for a
high device using
value might include:
Using time for a volume will approximately equal connect time (time
that the device was connected to a channel path). Using time does not include
disconnect time (time that the device had an active channel program but
was not connected to the channel) and pending time (time that I/O requests
were waiting in a channel queue before a path was available).
A high
connect percentage (CON %)
might be caused by one or
more of the following:
A high
disconnect percentage (DSC %)
might be caused by one
or more of the following:
A high
pending percentage (PND %)
might be caused by one
or more of the following:
# delayed jobs for processor
The average number of jobs for each group that are waiting for a processor.
A
high processor using
value might be caused by one or more
of the following:
A
high processor delay
value might be caused by one or more
of the following:
# delayed jobs for storage
The average number of jobs for each group that are waiting for a COMM,
LOCL (both include shared pages), SWAP, or VIO page, was on the out/ready
queue, or was a result of a cross-memory address space or standard hiperspace
paging delay.
For enclaves, only COMM, cross-memory, and shared page delays apply.
A
high storage delay
value can be associated with common storage
paging (COMM), local storage paging (LOCL), swap-in delay (SWAP), swapped
out and ready delay (OUTR), and other delays (OTHR) which includes virtual
I/O paging and paging delays from cross-memory address spaces and standard
hiperspaces.
A high storage delay associated with
common storage paging
might
be caused by one or more of the following:
A high storage delay associated with
local storage paging
might
be caused by one or more of the following:
A high storage delay associated with
virtual I/O
might be
caused by one or more of the following:
A high storage delay associated with
swap-in
activity might
be caused by one or more of the following:
A high delay value for address spaces that are
swapped out and
ready
might be caused by one or more of the following:
Other
storage delays might be caused by one or more of the
following:
execution velocity goal
The target execution velocity for ended transactions that has been
in effect for the service class period during the reported range.
performance index
This index helps to compare goals. If, for example, several execution
velocity goals with the same importance are not met, this index helps you
decide which group was impacted the most.
RMF calculates the performance index depending on the type of goal:
In this context "actual" means the maximal response time that actually was reached for the percentage of the goal. To calculate this, perform the following 3 steps:
Note
Due to this methodology, the maximal value of the performance
index for this goal type is 4.
important service units (capacity) / transaction
Actual service rate (in unweighted CPU service units per second) as
consumed per transaction in a resource group with a high importance (1
or 2).
percentile achieving response time goal
The percentage of transactions that actually ended within the time
specified in the goal.
response time
Average response time for all transactions as reported by the CICS
TOR or IMS CTL region. However, for subsystem data, it is possible that
active time is greater than total time.
Note:
All of these response times are for ended transactions
only. Thus, if there is a problem where transactions are completely locked
out, either while queued or running, the problem will not be seen until
the locked-out transactions end.
queue time
Queue time is the difference between total and active time.
For
CICS
, this may be the queue time for transactions within
the TOR, AOR, and other regions, and also processing time within the TOR.
For
IMS
, this may be the queue time for transactions within
the MPR and also processing time within the CTL region.
In all other cases, this is the average time that transactions spent
waiting on a JES or APPC queue.
Note:
Queue time may not always be meaningful, depending on
how you schedule work. For example, jobs are submitted in hold status and
left until they are ready to be run, all of the held time counts as queued
time. This time may or may not represent a delay to the job.
transaction ended rate
The number of transactions ended per second.
active time
For
CICS
transactions, active time is the execution time in
AOR, only for routed transactions.
For
IMS
transactions, active time is the execution time within
the MPR.
For
Batch, TSO,
etc., active time is the average time that transactions
spent in execution.
service units (capacity) / transaction
Actual service rate (in unweighted CPU service units per second) as
consumed per transaction.
response time goal
The goal that has been in effect for the service class period during
the reported range:
response time goal percentile
The goal that has been in effect for the service class period during
the reported range:
service rate
The actual service rate, in unweighted CPU service units per second,
as consumed by that resource group.
processor utilization
Average value of processor utilizations within the coupling facility.
In case of a stand-alone coupling facility, the utilization of the individual CPs should be approximately the same. In a PR/SM environment where this CP is shared with other partitions, the utilization is the logical utilization of the CP (that is, only the utilization by the coupling facility).
If the average utilization is high, you can take the following actions:
For example, if a CFCC CEC contains 6 LPs, and the measured CF LPAR
has two logical processors and is limited at 5% the number of effective
LPs is 0.3.
total request rate
The sum of synchronous and asynchronous requests completed against
any structure within this coupling facility per second. This includes requests
that changed from synchronous to asynchronous.
# frames installed
The total amount of storage in the coupling facility, including both
allocated and available space.
# frames available
The amount of coupling facility space that is not allocated to any
structure and not allocated as dump space.
sync request rate (CF structure)
Number of hardware operations per second that started and completed
synchronously to the coupling facility on behalf of connectors to the structure.
async request rate (CF structure)
Number of hardware operations per second that started and completed
asynchronously to the coupling facility on behalf of connectors to the
structure.
sync service time (CF structure)
Average time in microseconds required to satisfy a synchronous coupling
facility request for this structure.
async service time (CF structure)
Average time in microseconds required to satisfy an asynchronous coupling
facility request for this structure. This value also includes operations
that started synchronously but completed asynchronously.
% subchannel delay
The percentage of all coupling facility requests MVS had to delay because
it found all coupling facility subchannels busy.
If this percentage is high, you should first ensure that sufficient subchannels are defined (see MAX field below).
If there are sufficient subchannels and this percentage is still high,
it indicates either a coupling facility path constraint or internal coupling
facility contention.
% path delay
The percentage of all coupling facility requests that were rejected
because all paths to the coupling facility were busy.
A high percentage results in elongated service times which is a reduction of the capacity of the sending processor. If coupling facility channels are being shared among PR/SM partitions, the contention could be coming from a remote partition.
Identifying Path Contention: There can be path contention even when this count is low. In fact, in a non-PR/SM environment where the subchannels are properly configured, Subchannel Busy, not Path Busy, is the indicator for path contention. If Path Busy is low but Subchannel Busy is high, it means MVS is delaying the coupling facility requests and in effect gating the workload before it reaches the physical paths. Before concluding you have a capacity problem, however, be sure to check that the correct number of subchannels is defined in the I/O gen (see Subchannel Max).
PR/SM Environment: If coupling facility channels are being shared among PR/SM partitions, Path Busy behaves differently. Potentially, you have many MVS subchannels mapped to only a few coupling facility command buffers. You could have a case where the subchannels were properly configured (or even under-configured), Subchannel Busy is low, but Path Busy is high. This means the contention is due to activity from a remote partition.
Possible actions: Dedicate the coupling facility links on the sending
processor or add additional links.
CF sync request rate (view from MVS image)
Number of hardware operations per second that started and completed
synchronously to the coupling facility on behalf of connectors from this
system.
CF async request rate (view from MVS image)
Number of hardware operations per second that started and completed
asynchronously to the coupling facility on behalf of connectors from this
system.
CF sync service time (view from MVS image)
Average time in microseconds required to satisfy a synchronous coupling
facility request.
CF async service time (view from MVS image)
Average time in microseconds required to satisfy an asynchronous coupling
facility request. This value also includes operations that started synchronously
but completed asynchronously.
% using for a dataset
Percentage of time when a job has had an I/O request accepted by the
channel for the volume on which the data set resides, but the request is
not yet complete.
% delay for a dataset
Percentage of time when a job was waiting to use the data set because
of contention for the volume where the data set resides.
i/o rate
Rate of I/O requests. The i/o rate is measured at the hardware level
and is the sum of the i/o activity of all systems attached to the volume
or ssid.
% cache read hits
Percentage of I/Os that where processed within the cache (cache hits)
based on the total number of I/Os.
% cache read misses
Percentage of I/Os that where NOT processed within the cache based
on the total number of I/Os.
Definition: % cache read misses = 100 - % cache read hits
% cache READ misses is the percentage for READ operations
% cache WRITE misses is the percentage for WRITE operations
% of read operations
Percentage of READ requests based on all READ and WRITE requests.
non-cache dasd i/o rate
I/O rate of all requests that accessed DASD. This is the sum of Stage
rates (normal or sequential I/O requests that accessed DASD) and other
request rates (inhibit cache load, DFW BYPASS, CFW BYPASS, DFW INHIBIT).
CPC capacity (MSU/h)
Processor capacity available to the Central
Processor Complex (CPC).
The data is in Millions of unweighted CPU service units per hour.
image capacity (MSU/h)
Defined MSU capacity limit for the partition.
No data are available, if the
partition is not under control of the License Manager.
The data is in Millions of unweighted CPU service units per hour.
% weigth of max
Average weighting factor in relation to the maximum defined
weighting factor for this partition.
% WLM capping
Percentage of time when WLM capped the partition because
the four-hours average MSU value exceeds the defined capacity limit.
four hour MSU average
The average CPU consumption of the partition over the last four
hours measured in millions of unweighted CPU
service units per hour (MSU/h).
four hour MSU maximum
The maximum CPU consumption of the partition over the last four
hours measured in millions of unweighted CPU
service units per hour (MSU/h).
This value can be greater than the defined capacity.
actual MSU
Actual MSU consumption of the image running in the specified partition.
Data is in millions of unweighted CPU service units per hour.
average number of logical processors
The average number of logical processors assigned to this partition.
% effective logical dispatch time
Average effective dispatch time as percentage of the total online time.
% total logical dispatch time
Average total dispatch time as percentage of the total online time.
% effective physical utilization (CPC)
The effective utilization of the physical processors by all
partitions running in the CPC.
This data is based on the total interval time
of all physical processors and does not include LPAR management time.
RMFPM gives you the ability to select between the sum of all CP partitions
and the sum of all ICF integrated Coupling Facility) or
IFL (Integrated Facility for Linux) partitions.
% effective physical utilization (partition)
The effective utilization of the physical processors by the
partition.
This data is based on the total interval time
of all physical processors and does not include LPAR management time.
RMFPM gives you the ability to differentiate between CP partitions
and ICF(integrated Coupling Facility) or IFL (Integrated Facility for Linux)
partitions.
% total physical utilization (CPC)
The total utilization of the physical processors by all
partitions running in the CPC.
This data is based on the total interval time
of all physical processors and includes LPAR management time.
RMFPM gives you the ability to select between the sum of all CP partitions
and the sum of all ICF integrated Coupling Facility) or IFL (Integrated Facility for Linux)
partitions.
% total physical utilization (partition)
The total utilization of the physical processors by the
partition.
This data is based on the total interval time
of all physical processors and includes LPAR management time.
RMFPM gives you the ability to differentiate between CP partitions
and ICF(integrated Coupling Facility) or IFL (Integrated Facility for Linux)
partitions.
% total LPAR management
The average LPAR management time percentage.
remaining time until capping in seconds (by partition)
The projected time until WLM soft capping will start. WLM soft capping
takes place to prevent you from using more than the defined capacity over a
long period of time. This is under the assumption you continue to use your
system as you have done in the immediate past.
A work scope is the specification of an entity of work. RMF PM supports the following work scopes:
Metrics with values for work scope instances are available in two
ways:
Work scopes are not modeled as resources showing up in a PM configuration
view, because frequently changing instances of jobs would flood the system
with configuration updates.
Whenever an important message has to be brought to the user's attention, the Message Browser will pop up (if not opened yet), and a message will be displayed emphasized by a short beep.
Each message has the following format:
The following actions are possible on the Message Browser:___________________ YYYY/MM/DD HH:MM:SS GPMxxxxI Message...... ......................
Using the path File - Save Messages ..., you can save the messages to a file. By convention all message files have a file extention of .msg.
To delete messages, simply select the part you would like to remove, and press the Delete key.
To query help for a messages, select it (at least the message-identifier) and press F1. You can also use the path Help - Message Help after having selected the message.
Use the File menu or double click on the Message Browser icon to close it. All messages will be lost. If a new message needs to be displayed, the Message Browser will pop up again.
5694-A01 (C) Copyright IBM Corporation 1998, 2001