There are two distinct system VSE CPU percentage variables provided by the Explore Report Writer.
Article ID: 109011
Explore Performance Management for z/VSE
There are two distinct system VSE CPU percentage variables provided by the Explore Report Writer.:
Release: Component: EXPLVS
There are two distinct system VSE CPU percentage variables provided by the Explore Report Writer:
VSE CPU %BUSYR – the percentage of the real processor
VSE CPU %BUSYV – the percentage calculated using the CPU timer.
To illustrate the difference, imagine you have a VM system under which 2 VSE systems are running. Assume that in one minute both VSE systems use 30 cpu seconds, giving a total of 60 seconds for the minute. From a VM perspective the system is 100% busy. The value CPU %BUSYR divides the 30 seconds for each VSE system by elapsed timed 60 seconds) to give 50% busy for both systems, so:
VM TOTAL 100%
There is however another way of visualising the data. A value of 50% cpu activity for VSEA may lead someone to think that the virtual machine is only running at half its capacity, and that there are plenty of resources availabe for increased work loads. However we know that VM is running at 100%, so any increase in the workload for VSE will result in CPU contention. This is why some users of Explore/VSE prefer to use the %BUSYV value. In this case the denominator we use is not the elapsed time, but the cpu timer value, in effect the amount of time that this virtual machine was dispatched by VM. In this case we assume that both VSE systems had the same priority and both were dispatched for 30 seconds each. This gives 30 divided by 30:
This makes less sense from the overall VM perspective, but indicates more clearly, that the VSE systems are running at full capacity, which may explain any performance bottlenecks. I would not suggest that either %BUSYR or %BUSYV is the one you must use, both are valid, and the one you select will depend on your requirements.
In addition to these system values we also provide the VSE STEP variable VSE STEP %TCPU. This variable uses the %BUSYV method of calculating the CPU percentage. This is why in your report the system VSE %BUSYR looked correct, but the VSE STEP %TCPU for the CICS partition appeared to be too high. Unfortunately we do not have a %BUSYR type version of VSE STEP %TCPU, but as you have seen you can calculate this yourself by dividing the CPU seconds used by the elapsed time.
The calculation of CPU percentage gets more complicated when you have more than 1 cpu processor. With two CPUs for example you could theoretically use 120 cpu seconds in 1 minute. This raises the question of what to use as the denominator when calculating the CPU percentage. If you use wall time (60 seconds) you could see a cpu percentage for your VSE system of 200%. Alternatively you can multiply wall time by number of processors so that the maximum percentage can not exceed 100%. Again both approaches are valid. In the EVSESMCP display which you posted CPU 00 used 17.7%, CPU 01, which was quiesced, used 0%. Explore displayed a total cpu% of 8.8%, because we multiply the denominator by the number of processors to indicate that you are using 8.8% of the total system.
The report writer also provides a variable class of MCPU that you can use in a multiprocessor environment. You can report on VSE MCPU by cpu processor ID. Whereas the CPU %BUSYR value uses the wall time as the denominator, the MCPU %BUSR value uses the wall time * number of processors as the denominator, so you can choose which representation you prefer.
One idea to keep in mind is that the CPU seconds that we report are an absolute value, whereas the %BUSY values are a way of visualizing that value in a way that lets you know what the value represents in relation to the whole system.
You could also direct the output of the report to a SAM dataset and then ftp the file to another platform for incorporating in a spreadsheet.
// JOB TRISERV
// DLBL RPTOUT,'EXPRPT.OUTFILE'
// EXEC EXPRPT,SIZE=EXPRPT
FROM -0 DAYS AT 01:00:00
TO -0 DAYS AT 05:00:00
EACH 30 MINUTES
TAB DATETIME ,
VSE CPU %BUSYR AND ,
VSE CPU %BUSYV AND ,
VSE STEP %TCPU AND ,
VSE CPU BUSYV AND ,
VSE STEP TCPU
The output file contains just the data, the columns are separated by blanks. Unfortunately there is currently no support for formatting this file as a CSV dataset.
As an illustration here is a report I ran. It covers the period when a cpu intensive job was running. I have two processors defined to this VSE system and one was quiesced.
MCPU %BUSYR = MCPU BUSYV / (3600 * 2) - we are using 14% of the total system (where max usage is 100%)
CPU %BUSYR = CPU BUSYV / 3600 – we are running 28% CPU busy (where a max usage could be 200%)
MCPU %BUSYV = MCPU BUSYV / (cputimer*2) – we are using 50% CPU (1 of 2 processors fully loaded)
CPU %BUSY = CPU BUSYV / (cputimer*2) - This appears to be inconsistent – we should probably have used CPU BUSYV / cputimer
STEP %TCPU = STEP TCPU / (cputimer * 2)
FROM -0 DAYS AT 01:00:00
TO -0 DAYS AT 05:00:00
EACH 1 HOUR
TITLE2 REPORT TO ILLUSTRATE DIFFERENT CPU USE VARIABLES
HEADER(20,38) ----------- CPU PERCENTAGE -----------
HEADER(64,22) ------ CPU SECS ------
TAB DATETIME , REPORT 1
VSE MCPU %BUSYR HDR1(MCPU) HDR2(%BUSYR) AND ,
VSE CPU %BUSYR HDR1(CPU) HDR2(%BUSYR) AND ,
VSE MCPU %BUSYV HDR1(MCPU) HDR2(%BUSYV) AND ,
VSE CPU %BUSYV HDR1(CPU) HDR2(%BUSYV) AND ,
VSE STEP %TCPU HDR1(STEP) HDR2(%TCPU) AND ,
VSE CPU BUSYV HDR1(CPU) HDR2(BUSYV) AND ,
VSE MCPU BUSYV HDR1(MCPU) HDR2(BUSYV) AND ,
VSE STEP TCPU HDR1(STEP) HDR2(TCPU)
FROM 19/07/2018 01.00.00 REPORT 1 PAGE 1
TO 19/07/2018 05.00.00 REPORT TO ILLUSTRATE DIFFERENT CPU USE VARIABLES REPORT DATE 19/07/18 13.45.09
EACH 1 HOUR
PERIOD NONE ----------- CPU PERCENTAGE ----------- ------ CPU SECS ------
MCPU CPU MCPU CPU STEP CPU MCPU STEP
DATE TIME %BUSYR %BUSYR %BUSYV %BUSYV %TCPU BUSYV BUSYV TCPU
If the processor were stopped and inactive we would not consider it when calculating CPU%. A quiesced CPU is however different. If you use the SYSDEF TD,INTQ and SYSDEF TD,THRQ commands to implement CPU balancing then a Quiesced processor may be started when the threshold is reached and then quiesced again when the cpu usage falls below the threshold, so in this case it is always available for work. For this reason the choice was made to include it in the CPU% calculation. Again, I would propose that there is no right or wrong way to do this, and I can see that you would have preferred us not to include quiesced processors when determining CPU%, but we had to make a choice when designing the display. I still believe that the value we display is valid.