There are two distinct system VSE CPU percentage variables provided by the Explore Report Writer.

Document ID : KB000109011
Last Modified Date : 01/08/2018
Show Technical Document Details
Issue:
There are two distinct system VSE CPU percentage variables provided by the Explore Report Writer.: 
 
Resolution:
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:

VSEA          50%

VSEB          50%

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:

VSEA           100%

VSEB           100%

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.

 
Example:

// JOB TRISERV                   

// DLBL RPTOUT,'EXPRPT.OUTFILE' 

// EXEC EXPRPT,SIZE=EXPRPT      

INPUT(EVSEFBK)                  

OUTPUT(RPTOUT,DATA,NOHDR,NODICT)

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              

END                             

RUN                             

/*                              

/&                              

 

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) 

 

INPUT(EVSEFBK)                                                                                 

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)                                                      

END                                                                                            

RUN                                                                               
                                                                                                                                           



                                                                                                                                  

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

SHIFT  NONE                                                                                                                       

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                                              

-------- ----- 
-------- -------- -------- -------- -------- -------- -------- --------                                            

19/07/18 01.00   
14.4     28.9     49.8    
49.8     49.8     1039    
1039     1039                                              

19/07/18 02.00   
14.4     28.8     50.0    
50.0     50.0     1037    
1037     1037                                              

19/07/18 03.00   
14.4     28.8     50.0    
50.0     50.0     1036    
1036     1036                                              

19/07/18 04.00   
13.3     26.6     38.7    
38.7     38.6    957.5   
957.5    957.5                                              

-------- ----- 
-------- -------- -------- -------- -------- -------- --------
--------                                            

PERIOD           
14.1     28.3     46.7    
46.7     46.7     4070    
4070     4070                                              

-------- ----- 
-------- -------- -------- -------- -------- -------- --------
--------                                            

 



 

 

 

 

 

 

 

 

 
Additional Information:
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.