The VMRSM program was designed to operate in a
CMS environment as a Realtime Performance Monitor for zVM
hypervisors. This monitor is designed for use as a on-site or remote
systems programming analysis and diagnostic tool in evaluating
current VM system activity, CPU and Memory resource consumption and
I/O loads. It also lends itself as a monitoring facility to the
Manager of Information Systems by providing the ability to easily
interpret how their VM system is performing with the hardware
resources and peripheral equipment deployed in the environment.
The
VMRSM monitor is not designed nor is it recommended to be used for
long-term capacity planning or for charting resource consumption
trends. The monitor is for very short-term "as it's happening"
capture of system performance data and presenting an accurate picture
of resource use and allocation to the Systems Programmer.
The
functions of long-trend data accumulation and reduction for capacity
planning purposes are better served by collection of VM Monitor
records as input into a data analysis program. In CP's opinion, IBM's
VM Performance Kit is currently the best and most cost-effective
product for performing long-term analysis. VMRSM is, however, the
most valuable tool in establishing requirements for additions to (or
removal from) your current resource configuration.
One of
the greatest benefits of the VMRSM performance monitor is its ability
to reliably observe in an interactive environment the resource
"spikes" and "valleys" as they occur in the
environment. There is no long term smoothing of data that may tend to
suppress problem alerts. Sampling is done in short time intervals (a
few seconds) to be able to capture all relevant data pertaining to
the operation of the VM system. Long term monitors tend to lose some
very important performance data because of their infrequent sampling
and data smoothing. Some problem areas may never rear their heads
with long term sampling.
VMRSM has been designed and
continues to be engineered to place as little a load on the VM system
as is statistically feasible during its monitoring activity. Unlike
other products, VMRSM will NOT become your performance problem. VMRSM
consumes a minimum of resources and therefore will not bias the
system or significantly consume resource through the act of
monitoring. Its overhead may be slightly different for each display
facility. The least resource drain is associated with the VMSYSTEM
display; the greatest is the VMUSERs where the overhead is
proportional to the number of logged on users.
All data
is collected directly from sampling real storage of CP data
structures using the Diagnose x'04' instruction.
There
are no DCSS's or NSS needed, no DATA BUFFERING, no "AGENTS",
no COLLECTION POINTS, no other SERVERS or connections between
them,...NO KNOWN SIDE EFFECTS. The monitor's only resource
dependencies are CPU, the VM dispatcher and possibly some
insignificant amount of paging should the system be short on storage.
Other than these, no other tasks in the system should affect the
correctness of the monitor itself.
VMRSM display field
names very often are selected directly from the CP Data Areas and
Control Blocks manuals for the zVM product.
The performance of a VM system is determined by
the operation and the management of the each of the elements that
contribute to the system. Performance changes result from the
alteration and consumption of one or more of the contributing
elements or from the lack of or the addition of system resources.
These elements are: Input/Output performance, CPU processing and
Memory availability. And of course tuning expertise.
Powerful
hardware can be brought to its knees by inefficient software,
excessive workload, a single resource bottleneck or inexperienced
systems programming. Similarly all the tuning in the world can not
take the place of faster and more efficient hardware after a certain
critical point has been reached. The objective of performance
management is to achieve optimal efficiency with the hardware you
have before procuring more expensive equipment. This VM Monitor is
only a tool to help simplify the process of performance management by
permitting its user to easily identify factors affecting performance
and the resource demands placed upon a system by the various guest
operating environments, virtual service machines and CMS users.
Function Transition Commands and PF Keys
These commands can be entered from any display (unless noted) and they will cause a change in display function.
General System diagnostics.
CPU Engines. Selectable only from the VMSYSTEM CPU Activity line.
Users and their operating characteristics.
Display of a particular logged on user. The initial user being examined will always be the one running the monitor. To examine any other user, simply enter the name in the command area and depress the enter key.
Display of all active real peripheral devices.
Display of a given real device. The first terminal RDEV data structure found will be the initial device monitored. To switch monitoring to another device, just enter the address of the device in the command area.
Display of all virtual peripheral devices. Selectable only from the VMGUEST VDEVS field.
Display of a given virtual device. The first terminal VDEV data structure found will be the initial device monitored. To switch monitoring to another device, just enter the address of the device in the command area. Command is issued from VMGUEST display.
Display of all 256 possible channel paths utilization.
Display of REAL memory utilizations and assignments.
Display of LIVE Real Memory. View updates on set time interval. Certain areas are blocked by CP, such as VM Directory storage.
This will display the
MENU/HELP screen that will outline all the major monitoring options.
You can select a monitoring display from here with just a
cursor select or mouse clicking.
The MENU is the root of the
display function tree.
This will cause a CP READ to occur. Becomes useful if you wish to execute a CP Command.
Note: Entering the CP Command EXT (for external interrupt) will terminate the monitor at next cycle.
Will halve the interval time between samplings when depressed. This increases overhead since more sampling is occurring.
Will double the interval time between samplings when depressed. Less overhead, since less sampling.
This key will percolate back through prior tree branches to the MENU Screen, and finally exit.
Reserved for Backward and Forward scroll action for displays that may contain more data than can be accommodated on a single screen.
Clears the Command area and resets the cursor to HOME. No erase/rewrite of the display.
Resets the terminal device.
Erase/rewrite the screen, Clears the Command are and resets the cursor to HOME.
Hit PA1 to enter a CP READ state, then Enter #CP EXT to generate a virtual external interrupt. The monitor interrupt handlers will sense and cause the program to end on the next cycle.
Secondary Transition Commands and Subcommand functions
These commands can be entered at the ==> of the following displays and this will cause a change in monitor objective.
Below are the major Command Functions with their Scope:
VMUSERS Subcommands: ALL | ANY | CPU | IO | ACTIVE ...
This will display virtual machines (users) with their operating characteristics.
To change execution viewing objectives simply enter one of the above options on the command line and hit ENTER.
ALL or ANY = show virtual
machines without regard to activity.
CPU = show virtual machines
that are consuming CPU resources.
IO = show virtual machines
that are performing I/O.
ACTIVE = show machines that have I/O or
consume CPU.
VMGUEST Subcommands: Guest Name | VDEV | VDEVMI
The VMGUEST display will initially select the monitor user as the object for diagnostic display. To change objectives simply enter the name of a logged on user on the command line home position and depress ENTER. Will retain the last monitored guest during the VMRSM session.
VDEVMI Subcommands: CCUU
Virtual Device Microscope
Only used from the VMGUEST screen.
The VDEV display will request a virtual device to be selected as the object for monitoring. To change objectives simply enter the name of another virtual device on the command line home position and press ENTER. All PFkeys will bring you back to the owning VMGUEST display.
VDEV Subcommands: ALL | ACTIVE
Virtual Device Configuration for this guest. Only used from the VMGUEST screen. The VDEVMI display will show a list of all virtual devices for this virtual machine along with general status. PF8/PF7 will advance/retreat the display of devices. All other PFkeys will bring you back to the owning VMGUEST display.
RDEV Subcommands: CCUU
The RDEV display will request a real device to be selected as the object for monitoring. To change objectives simply enter the name of another real device on the command line and depress ENTER. Will retain the last monitored device during the VMRSM session.
VMDEVICE Subcommands: virtual CCUU | ALL | ACTIVE
The VMDEVICE logic will initially post statistics for active DASD as the objects for monitoring. To change objectives simply enter the name of a class of devices. The device class will appear in the display heading.
Classes
are:
TAPE tape devices
DASD CKD disk devices
FBA
Fixed-Block Architecture devices
SPEC Special devices include
FCP, CTCA, 3088, OSA, etc
OSA and HiperSockets QDIO devices
CTCA
Channel-to-Channel adapters
FCP Fiber Channel Protocol adapters
SPOL Unit Record PRT PUN RDR
TERM Bisync lines
GRAF
Graphic and terminals
CTCA Channel-to-Channel Adapter
SWCH
Switches
SVCM Simulated Devices
ALL or ANY = show all
devices without regard to activity.
ACTIVE = show devices that
are performing I/O.
REFRESH command will cause a rediscovery of
RDEV addresses from the radix chain.
VMCHANS Subcommands: ALL | ACTIVE
Channel Path Utilization (CHPIDS). This panel will show up to 256 channel paths. Excessive utilization of greater than 50 percent will be shown with a associated graph of +50<<<<<<.
ALL
or ANY = show all CHPIDS without regard to activity.
ACTIVE =
show CHPIDS with activity for the interval.
VMEMORY Subcommands: hhhhhhhh ,where h is any valid hexadecimal digit
Live Real Memory. This panel shows real address, followed by 4 words of formatted storage. The right side will display the EBCDIC character display of the 4 words.
CPU Activity
Percent of time that CPU utilization, averaged over all CPs, is active in the Supervisor or Problem State.
(Emulation time( a.k.a Problem time) + User_CP_Service time + CP_Supervisory Overhead time (aka System time) ) / Time Interval
The number is smoothed over N intervals. This is a selectable field that will bring you to a display showing each CP engine's utilization.
CP Supervisor
Percent of time that CPU, averaged over all CPs, is processing in the real Supervisor state, CP processing for system scheduling, resource allocation, storage management, etc, and for work on behalf of the guests, but not chargeable.
User CP Service
Percent of time, averaged over all CPs that the hypervisor is performing privileged instruction processing on Guests' behalf because these instructions are not permitted by the architecture to be executed directly by the guest which runs in the real problem state. Chargeable to the guest. The percent of time that the guest operates in the virtual supervisor state, that is the guest's virtual PSW shows supervisor mode.
Emulation State
Percent of time, averaged over all CPs, that CPU is running guest task work, unprivileged instruction sequences that do not require CP interception. The percent of time that the guest operates in the real problem state.
System Wait
Voluntary System Wait Time. Percent of the total time spent, averaged over all CPs, waiting for I/O, paging events or Timer expiration events. No tasks currently in a ready-to-run dispatchable state.
External Wait
Percent of total time that is "unaccounted" or uncaptured. Also known as "Involuntary Wait". Time used by external sources or VM waiting for external re-dispatch.
For second-level VM systems or VM systems running in an LPAR, this indicates the percentage of time the CPU has dispatchable ready-tor-run work but is unable to execute because the upper level hypervisor is not dispatching this VM system. (LPAR overhead + other LPARs). This WAIT denotes that more CPU could be consumed if it became available.
100% Clock Time = Emulation Time + System Wait + User CP Service + CP Supervisor Time + External Wait
This measure, called "External Wait" time, deserves greater explanation:
External Wait can be better understood by taking another look at the breakdown described above. Recorded for each logical PU is the amount of time the logical PU spends in the states z/VM running in an LPAR or as a Guest itself can see: the three distinct kinds of running, and time spent with a wait PSW loaded, and time spent parked. The counters might not add up to 100%. In other words, time appears to be missing. The reason is that z/VM measures those values using a System z facility called the "CPU timer". Logical PU's CPU timer doesn't advance when the logical PU is not dispatched. So, the logical PU's undispatched time isn't recorded in any z/VM data structure time field. External Wait is defined as 100% minus what the z/VM time accounted. No CP Monitor counter or Data Structures directly reports External Wait. It is derived by starting with 100% and subtracting out what the z/VM time fields in its PFXPG data structures account for it. To appreciate the significance of External Wait, we need to examine the reasons why PR/SM would decline to dispatch a logical PU. The logical PU was ready to run, but PR/SM couldn't find a place to run it, because all physical PUs of the matching type were busy. In other words, you might need a bigger machine. The logical PU did something that induced PR/SM overhead, and PR/SM responded, running its own instructions and charging them to the logical PU. In other words, overhead is accruing. The logical PU invoked some PR/SM function that resulted in the logical PU becoming temporarily non-dispatchable. For example, the logical PU issued a Diag x'44' to give up its PR/SM time slice. The logical PU is running in a capped partition and the partition has used its entitlement. Sometime soon the logical PU will get to run, but right now PR/SM has applied the brakes by suspending the LPAR. When this is happening you will see that the partition is capped because the partition has used its entitlement.
VM performance reporting products used to call "External Wait" by other terms: "Suspend Time", "Involuntary Wait".
Storage Utilized
Percent of page frames used by PROBLEM tasks.
(Sum of the In-Queue Working Sets + CP Nucleus + Free Pages + Locked + Shared) / (Number of pages available at IPL)
Paging I/O
Smoothed paging rate calculated by the Control Program (CP).
Spool Space
Percent of SPOOL space currently used. This consists of an accumulation of reader, Saturation punch and printer spool files, and NSS space.
Page Steals
Percent of DPA and XSTORE of reserved and referenced pages being stolen from in-queue users. Pages are stolen from "never idling" users or virtual machines versus active users. CP attempts to determine which machines are in an "active wait" with no work to do.
SIEs Intercepted
Percent of time that CP intercepts a SIE execution.
Users Logged
The number of local users using system.
Users Dialed
Number of users attaching themselves to guest systems via the DIAL command.
Users Net
Number of users entering local system via SNA Virtual Service Machine (VSM). Outboard VM consoles controlled by VTAM. (not TCP/IP)
Free Storage Extended
Extent of FREE STORAGE taken by CP thru stealing page frames from the Dynamic Paging Area (DPA).
Logons
The number of logons that have occurred since IPL.
NSS
The number of active Named Saved Segments.
DCSS
Number of active DCSS, NSS and SSP segments.
DPA
The number of page frames in the Dynamic Paging Area.
Avail
The number of page frames in the DPA remaining available
Lock
The number of page frames in the DPA locked for users.
Resvd
Number of page frames in the DPA reserved for users.
Shared
Number of page frames in the DPA shared by users.
Nucl
Number of page frames occupied by the resident part of the CP Nucleus program.
Core
Number of real page frames in the zVM system.
SPOOL
The number of SPOOL files created since last IPL.
The number of SPOOL files purged since last IPL.
Interactive
Q0 Number of active QUICKDSP users in queue
Q1 Number of active INTERACTIVE users in queue
EQ0 Number of users eligible for QUICKDSP queue
EQ1 Number of users eligible for interactive queue
Computation
Q2 Number of active COMPUTE users in queue
Q3 Number of active INTENSIVE users in queue
EQ2 Number of users eligible for COMPUTE queue
EQ3 Number of users eligible for INTENSIVE e queueTheir working-set requirement forces EQ users to wait until storage is freed when some user is Q-dropped.
Note: Eligible users move to Qx when their working-set sizes contract or can be accommodated.
PgReads
Page frames read into main storage in last interval.
PgWrits
Page frames written to aux storage in last interval. Notice more page reads occur than page writes due to the fact that if a page in memory has remained unchanged since pagein then it is not necessary to refresh the copy on the paging DASD.
SIExecs
SIE executions occuring in the last interval.
SIEcept
SIE interceptions handled by CP in the last interval.
Interval
Duration of last sample time interval.
Lag
Part of last interval that can be attributed to wait for re-dispatching of monitor due to system load and data transmission time, and channel/device-ends.
Monitor OVH
Measure of CPU seconds consumed by the monitor per cycle (overhead plus the amount of time taken by CP to re-dispatch the program immediately following its 'sleep' interval, and minus the time charged by CP to service the virtual machine interval timer).
Active CP
Number of active CPs running.
WorkingSet Sums
Sum of the working sets (in pages) of the current in-queue users for the last sampling interval.
SSCHs
Interval count of all real I/O Starts.
RSCHs
Interval count of all real I/O Resumes.
Intrpts
Interval count of all real I/O Interrupts.
Nuc
Number of page frames occupied by the resident part of the CP Nucleus program.
Elapsed Time since IPL
Shows the elapsed time in days, hours, minutes and seconds since CP was last initialized.
IPL
Shows the CCUU from where the IPL occurred.
SYSRES
The VOLSER name of the device that VM was IPL'd from.
TOD Clock
Current 24-hr Time-of-Day Clock appears on top of display.
Total Aggregate
The summed contribution of the utilization of each CPU (scaled by a factor of 10 for readability).
CPU Utilization
The percent of time the CPU(s) are found busy, smoothed over N intervals.
CP nn type
Percent of time that CPU engine number nn is processing (scaled up by a factor of 10). The number is smoothed over N intervals.
The type of CPU real processor is indicated by the following codes:
CP indicates the
processor is a central processor (that is, a general-purpose
processor).
IFL indicates the processor is an IBM
Integrated Facility for Linux processor.
ZAAP indicates
the processor is an IBM zEnterprise® Application Assist
Processor.
ZIIP indicates the processor is an IBM z
Integrated Information Processor.
ICF indicates the
processor is an Internal Coupling Facility processor.
Resource Service Level
A measure of the ability of the VM system to provide CPU service to the active users on the system. This is the ratio of the average in-queue users during the sampled interval to the number of users plus CP System, that used CPU service for that same interval.
.99 is optimal
.01 is
poor
Virtual-to-Real Storage
A ratio of the total sum of the virtual storage used by running virtual machines divided by the real memory configured on the system.
1.00 or less generally indicate "swimming" in storage.
3.00 is probably a nominal number
The greater this number becomes the more important to keep an eye on your paging volume service times, paging rates, page steals, working-set sizes, and eligible lists.
User
Name of user currently logged on to zVM. Select or Click the userid will present the Guest Microscope for this virtual machine.
Run State
Current or last sampled running status posted for this user by CP.
Running. A user that is in the running state is actually using a real processor. This is roughly equivalent to time running under emulation. Some processor time charged to a virtual machine while CP is running for it is in the simulation wait, I/O wait, and console function wait states.
CPU Wait. A user ID is in this state when it is found waiting to run on a real processor. High CPU wait time indicates a bottleneck in processor resources.
I/O Wait. This state indicates that the guest is waiting for completion of an I/O and thus is prevented from running. High I/O wait time indicates that you should check the effectiveness of minidisk cache, virtual disk in storage, and the I/O hardware configuration.
Simulation Wait. When CP is simulating a hardware function such as instructions, interrupts, timer updates, or unique z/VM functions such as IUCV, the virtual processor is prevented from running and is in this state. High simulation wait time could indicate performance problems in connectivity functions, loss of hardware assists, or other simulation related bottlenecks.
Page Wait. A virtual machine enters page wait state when it references a page which is not present in host storage and must be brought in from auxiliary storage. This state reflects time waiting for page reads from DASD. High page wait time indicates the storage and paging subsystem need evaluation. If key server virtual machines are in page wait, you might want to consider reserving pages for these machines.
Console Function Wait. Certain functions in CP are serialized by a state called console function mode. While in this wait state, the virtual processor is not permitted to run. This may include such things as certain CP commands. High console function wait could indicate problems in the network, excessive CP command usage, and possibly master processor contention.
Test Idle. This is the state where CP may place a user who has just gone idle or is waiting for what is expected to be a short term wait. While in test idle, the user is still in the dispatch list. This state can last up to approximately 300 milliseconds. If no new work arrives for the virtual machine during the test idle period, the virtual machine is dropped from the dispatch list and added to the dormant list. Using this approach, much of the overhead of dropping and adding users to the dispatch list can be avoided. A high amount of time in test idle is not necessarily bad. There are actually two types of test idle states. One where the user has an outstanding communication with another virtual machine (SVM wait) and one where there is not an SVM wait.
Dormant. The user is in the dormant list.
I/O Active. A virtual processor is in the I/O active state if there is an asynchronous I/O outstanding causing the user to be in the dispatch list, but not prevented from running. It is normal for some virtual machines to have very high I/O active wait times in cases where they use continuous channel programs. This can be the case with some network related machines. Virtual machines with increased I/O active wait time can indicate performance problems in networks or other I/O done asynchronously.
Active Page Wait. This is similar to active I/O wait, except instead of an outstanding asynchronous I/O, there is an outstanding page fault which the virtual machine was prepared to handle asynchronously.
Limit List Wait. If a user is ready to run but has exceeded the maximum share setting, the user may be placed on the limit list for a period of time. During that time, the user will be in the limit list wait state.
Dispatch
Current or last sampled dispatcher status posted.
RAI
Resource Availability Index simulation for this user.
BCPU
Percent of the real CPU resource used by this user's BASE CP for the last sampling period. (TTIME). If this virtual machine employs multiple CPs then you must refer to the Guest Microscope that will examine up to the maximum of allocated CPs
PgSec
Paging rate in pages per second for this VM user for the last sampling period. (READS and WRITES)
Queue
Dispatching queue currently assigned to by VM. INTERACTIVE (Q1) COMPUTE-BOUND (Q2) or INTENSIV (Q3).
WkSet
Number of real pages inclusive of locked and reserved pages currently posted by CP a being resident. (Number of Core Pages - Nucleus Pages)
PgWt
Page wait count. Times that virtual machine was found to be in a page wait condition.
Share
The specified share or CPU resources granted to this virtual machine.
I/O Count
Total of SPOOLED and non-SPOOLED I/O s Starts initiated by this virtual machine since LOGON time.
CPU Total VTime
Actual time and the Percent of time that CPU utilization, averaged over all CPs, is active.
CPU Supervisor Mode
Actual time and the Percent of time that CPU, averaged over all virtual CPUs, is processing in the virtual Supervisor state, CP processing for system scheduling, resource allocation, storage management, etc, and for work on behalf of the applications, but not chargeable.
CPU Problem State
Actual time and the Percent of time, averaged over all CPUs that the guest supervisor is performing privileged instruction processing on applications' behalf because these instructions are not permitted by the architecture to be executed directly by the guest which runs in the real problem state. Chargeable to the application.. The percent of time that the application uses virtual supervisor state services, that is the guests virtual PSW shows virtual supervisor mode.
Processing State
V=V
V=R
Architectural Mode
32 or 64 Bit
IPL Address
Address from which guest is IPL'd.
LoadParm
The Lload Parameter, if any, last IPL'd with.
nCPU
The number of virtual CPU engines.
Total I/O Count
The total start subchannel commands since IPL.
CPU Share
The number of virtual CPU engines.
PFaults
The total number of page faults incurred over the last samping interval.
DPA
The number of guest pages resident in the Dynamic Paging Area.
Projected Working Set Size
The expected working set size of the guest after locality trimming.
Resvd
The number of pages marked reserved for this guest by CP.
Locked
The number of pages fixed in real memory for this guest by CP.
SCIF
Secondary Console User, if any.
Spooling
The number of spooled I/Os in the last sampling interval for this guest.
Priv Class
The privilege classes assigned for this virtual machine.
VMDBK
The address of the VMDBK in real storage. This field is selectable. I will take you to a display of real memory.
VDEVS
This selectable field will take you to a display of all the virtual I/O devices defined under this guest.
Last CP Command
The last CP command executed by this virtual machine.
Diag+GuestOpts
The Diagnose and Guest Options fields of the VMDBK shown in displayable hex.
User General Registers
Shows the contents of the low-order 4 bytes of each general purpose register for this guest.
User Control Registers
Shows the contents of the low-order 4 bytes of the first four control registers for this guest.
PSW
Shows the full Program Status Word for this guest in displayable hex.
VMDVDISK
The virtual I/O count for VDISK areas.
VMDCTPWT
The machine paging wait count.
Storage Utilized
Percent of page frames used
by PROBLEM tasks.
(Sum of the In-Queue Working Sets + CP
Nucleus + Free Pages + Locked + Shared) / (Number of pages available
at IPL)
Minidisk Caching
Percent of storage allocated for minidisk caching being used. This is your minidisk cache hit ratio.
Smoothed Page Rate
The calculate smoothed paging rate over a series of recent intervals.
Paging Rate
The instantaneous paging rate for the interval.
Paging Load
***Not Yet Activated****
Non_Pageable
Number of page frames locked in real storage by CP, (ie. locked for I/O processing)
Pages Shared
The number of page frames in real storage marked as being used by Discontiguous Shared Segments.
Pages Reserved
The number of page frames in real storage marked as being reserved for particular virtual machines.
Nuc
Number of page frames in real storage used by the resident VM Control Program nucleus.
Storage Utiliz
Percent of page frames used
by PROBLEM tasks.
(Sum of the In-Queue Working Sets + Reserved
Frames + Shared Pages)/(Number of real page frames)
Paging Slots
Available slots for VM Paging.
Paging Cyls
Number of VM Paging disk cylinders in use.
Free Storage Extended
Current number of FREE STORAGE pages extended into the Dynamic Paging Area.
Page Reads
Page frames read into main storage in last interval.
Page Writes
Page frames written to aux
storage in last interval.
Note that more page reads occur than
page writes due to the fact that if a page in memory has remained
unchanged since its pagein operation then it is not necessary to
refresh the copy on the paging device.
Dynamic Paging
Number of available page frames in the DPA.
Memory Size
Real memory size.
Interval
Duration of last sample interval.
Working Set Sums
Sum of the working sets of the current in-queue users for the last sampling interval.
VOLSER
Volume serial if device is a DASD.
Subchan Addr
Subchannel designation assigned by CP. Select or Click the userid will present the Guest Microscope for this virtual machine.
CCUU-Address
Logical channel.channel.unit.unit CCUU address of primary I/O path assigned by CP
Device
Type of peripheral device.
I/O Count
Number of I/O Starts to this device since ONLINE.
CylAddr
Current cylinder address of DASD as posted by VM at last sampling interval.
IntervalI/O
Number of Input Reads and Output Writes to this device last interval.
%DevIO
Ratio of I/Os to this device versus total I/O to all devices in the last sampling interval expressed as a percent.
CCUU-Address
Virtual channel.channel.unit.unit CCUU address of primary. I/O path assigned by VM Directory or CP ATTACH command. Select or Click the userid will present the Guest Microscope for this virtual machine.
SubChan Addr
Virtual Subchannel designation assigned sequentially by CP
Device Class
Device Class, including virtual simulated devices.
Volser
The volume serial identity of the real DASD device.
BegCyl
Beginning cylinder of the minidisk.
EndCyl
Last cylinder of the minidisk.
NCyl
Current cylinder address of DASD as posted by VM at last sampling interval.
I/O Count
Number of I/O Starts to this device since ONLINE.
IntervalI/O
Number of I/O to this device last interval.
Device Status
Current device status posted at time of sampling.
Device
System Control Program device address selected for monitoring.
VOLSER
If a DASD, this shows the volume serial. Volser is ...... for FCP connection.
PAV
Below the VOLSER will be an indicator if this device is a PAV Base, PAV Alias, HyperPAV Base or HyperPAV Alias, or non-PAV
Device Type and Model
The type and model of Real Device.
CU Type and Model
The type of Control Unit to which the device is connected and model of the control unit.
Utilization
Percent of time device
selected is busy with work.
K * (Connect + Disconnect +
Function_Pending) / Interval
Connect
Percent of time device
selected is connected to the subchannel. Connect time per I/O is the
amount of time an I/O actually uses the physical connection. It is
measured from the beginning of the first packet to the end of the
last packet. In usual situations, one has very little influence over
connect time.
K * Connect / Interval
Disconnect
Percent of time device
selected is disconnected while the subchannel is active. Disconnect
time per I/O is a measure of controller duress. The controller
disconnects when it cannot immediately satisfy the I/O by using its
cache.
K * Disconnect / Interval
Func Pending
Percent of time device
selected is in function_pending state while the subchannel is active.
(possibly shared with other system). Pending time per I/O is the time
it takes the System z channel subsystem to find a chpid to use for
the I/O, plus the amount of time it takes the DASD subsystem to
return an initial response indicating that it has received the
channel program.
K * FuncPending / Interval
Note
service time per I/O is just the sum of pending time, disconnect
time, and connect time.
RDEV
Shows the address of the real device block data structure in memory. Select or Click will present the active real memory information.
Path Interface
I/O Subsystem CHPID assignment. 'O' indicates path is ONLINE.
I/O
Interval and Cummulative counts for start subchannel, solicited, unsolicited and missing interrupts and the number of I/Os queued.
I/O Rate
Current sampled rate of I/Os
being performed per sec.
Service Time -- Calculation of the
time required to perform a single I/O. T = difference(Conn + Disc +
FuncPend)/Interval
DEVICE FLAG
Current disposition of device.
CYL Address
If DASD, the current cylinder address at last SEEK.
Granted Lock
Reserve LOCK count granted for device
Defered Lock
Deferred LOCK count for the device.
RDEVAFLG -- *
RDEVDFLG -- *
RDEVRFLG -- *
Reconfig
States of Hyperswap activity if present.
Device CCUU
Virtual Users device address selected for monitoring.
RDEVBLOK
Real address of the Real Device Block data structure (selectable field) for this virtual device.
VDEVBLOK
Real address of the Virtual Device Block data structure. (selectable field).
RDEV CCUU
Device real address.
I/O
Interval and Cumulative counts for Actual I/Os performed by CP, I/O initiated by the Guest and I/Os that were unneeded due to residency in the minidisk caching system, and I/Os that were split into multiple I/Os by CP.
I/O Rate
Current sampled rate of I/Os being performed per sec.
Device Class
IBM device designation
CYL Address
If DASD, the virtual cylinder address at last SEEK.
Head Address
If DASD, the virtual head address at last SEEK.
Chpid
Channel Path Number (0 to 255)
Percent
Percentage of Time that CHPID is utilized or busy. Note that graph depicts up to 50 percent, but this field shows entire percentage.
Use PF7/PF8 to scroll backward and forward to view all possible 256 chpids.
R-Addr -- Real Address (range 0 to 2G)
+0 -- Zero displacement from selected real storage address.
+4 -- Four byte displacement from selected real storage address.
+8 -- Eight byte displacement from selected real storage address.
+C -- Twelve byte displacement from selected real storage address.
EBCDIC Chars -- Character translation of the prior 4 words of storage.
Use PF7/PF8 to scroll backward and forward in real memory.
Use 'T' or 't' to toggle between memory display formats.
Command Line will accept any valid hexadecimal number or a function switch command (like HELP or VMSYSTEM).
The
MENU screen is eventually returned to, by default, when using the PF3
key from any monitoring function.
The highlighted WHITE
fields are selectable using either by using the ENTER Key or a Double
Mouse Click.
The listed functions in BLUE are selectable
ONLY from the VMGUEST function display.
VMEMORY
[real-address] may fail because CP Diagnose x'04' returned a
addressing exception for a page that is invalid or protected by CP.
Calculation of time displacements are done by the monitor
on a strictly cyclic basis using timer information presented by VMCP.
However, VMCP does not necessarily update the virtual timers on a
strict cyclic basis that is synchronized with the monitor task's
sampling. Certain interrupts and PRIV OPS force virtual timer
updating when the machine is re-dispatched. Therefore, virtual states
in excess of 100 percent may occur due to the timers being refreshed
with a displacement that exceeds the sampling interval displacement.
This problem will appear in the VMUSERS display where the total CPU
Usage for all the machines MAY EXCEED 100 Percent, and in the VMDBK
display where virtual problem state exceeds virtual CPU active state.
FBA DASD devices in the VMDEVICE display show Cylinder
Location instead Block Location of the R/W Head. This is what appears
in the Real Device Block information.
Channel (CHPID)
utilization is presented to be balanced over all online channel paths
marked available by the Real Device Logical Path Mask.
The
VMUSERS display is dependent on VM's designation of some user as the
OPERATOR. If no OPERATOR is present this routine may enter a loop or
terminate.
This program supports up to 1024 devices per
device class.
The VMUSERS supports up to 1200 virtual
machines.
[Return to Index]
[Return to Cullen Programming Home Page]
|
Copyright © Cullen Programming 1987, 2023 All Rights Reserved |
