Pages

    Understanding CICS performance on z/OS

     Check out https://www.youtube.com/playlist?list=PLezLS0Tuqb-5vZaePphy1MMyOTBUINqpn

    Vides with following title can be found in the above link

    CICS Performance 101: Introduction

    CICS Performance 101: Session 1 - Making Sense of MIPS

    CICS Performance 101: Session 2 - Making Sense of MSUs and SUs

    CICS Performance 101: Session 3 - Making Sense of ITR



    IBM Z Software Pricing

     Checkout https://www.youtube.com/playlist?list=PLezLS0Tuqb-4GIwmKe7pOUU8AT4h7v-ul

    Below topics are covered

    zSoftware Licensing Terms and Conditions
    IPLA Software Terms and Conditions
    Multi-Version Measurement (MVM)
    Parallel Sysplex Aggregation
    On/Off Capacity On Demand (OOCoD)
    Backup, Disaster Recovery, and Capacity Backup Upgrade
    zNALC and MzNALC
    VUE Program Licensing Calculations
    Cross Systems Waivers
    Per Payments Pricing on z/OS
    Container Pricing for IBM Z
    Mobile Workload Pricing
    Country Multiplex Pricing
    z/VM and Distributed Linux Middleware on Z
    Defined Capacity and Group Capacity Limits
    Sub-Capacity and Rolling 4 Hour Average
    Reading the SCRT Report
    Workload Pricer Support for S&S Anniversary Dates
    Advanced Entry Workload Pricing

    How Tivoli Decision Support for Z/OS reports 4HRA

     Tivoli Decision Support for Z/OS leverages the SMF data to provide a variety of reports for various components of System Z. TDS maintains a database for different SMF record types which can be queried using QMF to provide reports on the fly. One such report is the monthly 4 hour rolling average report for each LPAR in the CEC. TDS provides ‘MVSPM_SYSTEM_H’ and ‘MVSPM_LPAR_H’ tables which contains the ‘MSU_4HRA’ (SMF70LAC) for each LPAR in the CEC. The below section establishes a reporting technique which will align with the SCRT report.

    USING MVSPM_LPAR_H 

    ‘MVSPM_LPAR_H’ provides hourly statistics on logical partitions and processor activity in a PR/SM environment. It contains data from SMF type 70. The ‘MSU_4HRA’ column contains the 4-hour rolling average for each logical partition. This value ‘MSU_4HRA’ in table ‘MVSPM_LPAR_H’ is the last effective 4 hour rolling average for the hourly interval (. MSU_4HRA = LAST (V_MSU_4HRA). For example, if your recording interval is 15 minutes then the ‘MSU_4HRA’ value reported for 20th hour in TDS will be the value which occurred at 20:45(the last effective 4HRA value for that hour). This is the reason your ‘MSU_4HRA’ value would not match with your SCRT value.

    LPAR NameSMF interval15 min interval MSU 4HRA1 Hour interval data in MVSPM_LPAR_H at 01:00:00
    A01:00:0035
    A01:15:0035
    A01:30:0036
    A01:45:0035TDS Value : 35(Last Effective 4HRA)
    LPAR NameSMF interval15 min interval MSU 4HRA1 Hour interval data in MVSPM_LPAR_H at 03:00:00
    A03:00:0033
    A03:15:0033
    A03:30:0034
    A03:45:0034TDS Value : 34(Last Effective 4HRA)
    LPAR NameSMF interval15 min interval MSU 4HRA1 Hour interval data in MVSPM_LPAR_H at 20:00:00
    A20:00:0053
    A20:15:0053
    A20:30:0052
    A20:45:0050TDS Value : 50(Last Effective 4HRA)

    USING MVSPM_SYSTEM_H

    MVSPM_SYSTEM_H also contains the ‘MSU_4HRA’ (SMF70LAC) for each LPAR However, the value of MSU_4HRA reported in this table is the average (MSU_4RHA = Avg (SMF70LAC, INPUT_RECORDS) of SMF70LAC SMF interval records. The MSU_4HRA values reported in this table always matches your SCRT report because SCRT uses the mean of SMF interval records to aggregate an hourly record. For example, if your SMF recording interval is 15 minutes then the MSU_4HRA value reported for 20th hour will be the average of SMF interval records (In this case AVG (20:00,20:15,20:30,20:45).

    LPAR NameSMF interval15 min interval MSU 4HRA1 Hour interval data in MVSPM_LPAR_H at 01:00:00
    A01:00:0035
    A01:15:0035
    A01:30:0036
    A01:45:0035TDS Value : 35.25(Average 4HRA)
    LPAR NameSMF interval15 min interval MSU 4HRA1 Hour interval data in MVSPM_LPAR_H at 03:00:00
    A03:00:0033
    A03:15:0033
    A03:30:0034
    A03:45:0034TDS Value : 33.5(Average4HRA)
    LPAR NameSMF interval15 min interval MSU 4HRA1 Hour interval data in MVSPM_LPAR_H at 20:00:00
    A20:00:0053
    A20:15:0053
    A20:30:0052
    A20:45:0050TDS Value : 52(Average 4HRA)

    Tivoli Decision Support for Z/OS provides the functionality to track the last effective 4 Hour Rolling Average and Mean 4 Hour Rolling Average. It is very important to understand the context of each of these values while reporting. The ‘MVSPM_SYSTEM_H’ should be used as a baseline while comparing your results with SCRT. However, to keep track of the last effective 4 HRA in an hour ‘MVSPM_LPAR_H’ becomes an ideal choice.

    How SCRT Reports the 4 Hour Rolling Average?

    The Detail LPAR Data (N5) section of the SCRT report shows the interval (date and hour) during the month for each LPAR on a CPC when the LPAR reached a maximum rolling 4-hour average utilization value (in MSUs). It also shows the interval in which the sum of all the LPARs reached a maximum rolling 4-hour average value. The SMF Recording interval varies from site to site based on the installation needs. The SCRT algorithm calculates 4HRA values at the hourly interval by taking an hourly average of 4HRA values at each of the LPAR SMF intervals. In the below example the SMF recording interval for LPAR A is 15 minutes and the peak reported in SCRT occurred at 20:00, so SCRT here has taken the mean of all the 4 intervals of 20th hour. 

    LPAR NameSMF interval15 min interval SMF70LAC valuesSCRT value reported in N5 section at 20th hour
    A20:00:0053
    A20:15:0053
    A20:30:0052
    A20:45:0050Calculated value: AVG(20:00,20:15,20:30,20:45) 52 MSUs


    RMF Workload Activity and CPC activity report

    ====================================================================
          RMF WORKLOAD REPORT:                                            
    ====================================================================

          REPORT BY: POLICY=OWL        WORKLOAD=CSSDDF                    
          TRANSACTIONS    ---SERVICE----  SERVICE TIMES  ---APPL %---     
          AVG      0.23   IOC         0   CPU    392.9   CP      4.98     
          MPL      0.23   CPU      3931K  SRB      0.0   AAPCP   0.00     
          ENDED      51   MSO         0   RCT      0.0   IIPCP   0.07     
          END/S    0.01   SRB         0   IIT      0.0                    
          #SWAPS      0   TOT      3931K  HST      0.0   AAP      N/A     
          EXCTD       0   /SEC      1092  AAP      N/A   IIP     2.67     
          AVG ENC  0.23                   IIP     96.1                    
    ====================================================================

    Under "SERVICE TIMES", the RMF "CPU" value of 392.9 seconds is the total of the real CPU time on CP engines, plus the NORMALIZED CPU time on the zIIP and zAAP engines; it is NOT the CPU "TCB" time.  
    But also under "SERVICE TIMES", the RMF "IIP" (zIIP) value of 96.1 seconds is the UN-NORMALIZED, raw, seconds on the zIIP engine. And the RMF "AAP" value for zAAPs is also the UN-NORMALIZED value.
    And under "SERVICE", the RMF "CPU" value of 3931K is the TOTAL SERVICE units from CPs, zIIPs, and zAAPs.                         

    In the RMF WLMGL Report, the field APPL% CP is the sum of the cpu times (tcb, srb, rct, iit, hst) divided by the reporting interval. An engine can theoretically be dispatched for the entire interval, so this is like saying the percentage of an engine.  For example, if APPL% CP is 324.9,  that's like saying 3 and a quarter of engine's
    worth of cpu resource.



                     C P U  A C T I V I T Y 
                                                                                  
                z/OS V2R1                SYSTEM ID TRX1             DATE 09/28/2013            INTERVAL 15.00.037
                                         RPT VERSION V2R1 RMF       TIME 16.45.00              CYCLE 1.000 SECONDS
      
    CPU        2827   CPC CAPACITY   869        SEQUENCE CODE 0000000000089F25               
    MODEL      609    CHANGE REASON=NONE        HIPERDISPATCH=YES                               
    H/W MODEL  H66                                                                            

    ---CPU---    ---------------- TIME % ----------------   --- MT % ----   LOG PROC      --I/O INTERRUPTS--
    NUM  TYPE    ONLINE    LPAR BUSY    MVS BUSY   PARKED   PROD   UTIL     SHARE %       RATE     % VIA TPI 
     0    CP     100.00     4.46         4.41        0.00   ------ ------    13.6  MED    30.65     0.20
     1    CP     100.00     0.00        -----      100.00   ------ ------     0.0  LOW     0.00     0.00
     2    CP     100.00     0.19         0.19        0.00   ------ ------     0.0  LOW     0.00     0.00
     3    CP      30.27     0.00        -----      100.00   ------ ------     0.0  LOW     0.08     0.00


    MVS BUSY is a totally different view of cpu utilization from LPAR BUSY (and it can be a little confusing at first), so LPAR BUSY and MVS BUSY values won't necessarily match. The MVS BUSY is the percentage of time this z/OS did not go into a wait state.  So MVS BUSY represents how busy the LPAR was, but it doesn't show how much the LPAR has consumed its online logical engines.  You would look at the LPAR BUSY to determine this. The LPAR BUSY is the percentage of this LPAR's online logical CPs that the LPAR actually consumed.  If the number of logical CPs for an LPAR is equal to the number of physical CPs for the box,  
    then LPAR BUSY is like saying what percentage of the box the LPAR
    is using.                                                        
                                                                          
    LPAR BUSY being less than MVS BUSY means that MVS dispatched work onto one of its logical CPs, but PR/SM took away that physical engine away from the logical engine to give to another LPAR.  Therefore MVS still thinks it has a logical engine (MVS BUSY clock keeps ticking) but PR/SM knows that LPAR is no longer
    running on a physical engine (LPAR BUSY clock is no longer ticking).

    How rolling four hour average is calculated

    WLM is responsible for sampling the MSU Utilization for each LPAR every 10 seconds. Every 5 minutes, WLM documents the highest observed MSU utilization sample from the 10 second bucket. This process keeps a track of the past 48 updates sampled for each LPAR. When the 49th observation is recorded, the 1st observation is discarded, and so on. These 48 observations of 5 minutes each represent a total of 5 minutes * 48 = 240 minutes or the past 4 hours rolling average (R4HA). WLM stores the average of these 48 values in the WLM control block RCT.RCTLACS. Every time RMF creates a Type 70 record, the current 4 hour rolling average from RCT.RCTLACS is populated in the SMF70LAC field representing the 4hour rolling average at the time of cut. This way we have the “4 Hour Rolling Average” being recorded as SMF70LAC for every Type70 record. 

    The below example shows how 4HRA is calculated. In this example the 4HRA at 04:00 is 271 MSUs which is average of all the 48 intervals of 5 minutes each from 00:00-4:00

    OBSTIMEMSU/Hr
    100:00220
    200:05259
    300:10278
    400:15262
    500:20312
    600:25225
    700:30234
    800:35289
    900:40285
    1000:45262
    1100:50283
    1200:55310
    1301:00302
    1401:05289
    1501:10263
    1601:15213
    1701:20241
    1801:25173
    1901:30169
    2001:35233
    2101:40279
    2201:45303
    2301:50328
    2401:55313
    2502:00319
    2602:05319
    2702:10280
    2802:15280
    2902:20307
    3002:25293
    3102:30289
    3202:35301
    3302:40249
    3402:45304
    3502:50273
    3602:55277
    3703:00301
    3803:05249
    3903:10211
    4003:15234
    4103:20241
    4203:25278
    4303:30304
    4403:35273
    4503:40277
    4603:45307
    4703:50229
    4803:55304
    4904:00271