|
View previous topic :: View next topic
|
| Author |
Message |
AdrielGB
New User
Joined: 24 Mar 2014
Posts: 3
Location: Brazil
|
|
|
|
Hi Everybody.
I'm writing a rexx to extract SMF 70-1 and make a detailed report of every rmf interval "how much msu was consumed" (just for fun).
Just to make sure that what what im doing is correct:
1 - making a loop in prsm_logical_section reading all sections regarding the particular lpar (offset SMF70BVS) to summarize all SMF70PDT
offset = SMF70BVS+(SMF70BVL*SMF70BDS)
DO I = 0 TO SMF70BDN-1
SMF70PDT = SUBSTR(SMFREC,offset,8)
SMF70PDT = C2D(SMF70PDT)
SMF70PDT_T = SMF70PDT_T + SMF70PDT
offset = base+SMF70BVL
END
2- To calculate the msu consumed in the rmf interval (i've got this formula in the RMF User Guide - zOS 1.13)
NUM_MSU_CONSU = (SMF70PDT_T*3600*16)/(SMF70CPA*RMF_INT*1000000)
3- My LPAR have 4 logical pu, soo the looping is reading 4 times. the values i've obtained are below
SMF70PDT: 3340353721597952
SMF70PDT: 1407006640439552
SMF70PDT: 251842789888
SMF70PDT: 1252993307509505
SMF70PDT_TOTAL: 4747612204827392
SMF70CPA: 891
RMF_INT: 900.1 (already converted in sec)
Result: 383996086557.7216611487612487501388734585
Soo if i'm doing everything right my lpar consumed this much MSU in a 15min interval? |
|
| Back to top |
|
 |
Willy Jensen
Active Member
Joined: 01 Sep 2015
Posts: 734
Location: Denmark
|
|
|
|
| I think that the best conformation will be to compare against a RMF Partition Report for the period. |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8700
Location: Dubuque, Iowa, USA
|
|
|
|
I don't think your calculation is correct -- the sum seems to be missing the fourth value.
383 BILLION MSU? I don't care what you feed the hamster, the wheel just isn't going to spin that fast! The LSPR ITR web site lists 17170 MSU for a 3906-7H0 (z14 maximum), so your final value cannot exceed this.
What are the values of SMF70WLA and SMF70LAC from the CPU CONTROL section of the 70-1 record? WLA tells you the maximum value you can derive for MSU (taking into account any capping) while LAC gives you a 4-hour rolling average for that RMF interval. Both should give you a ballpark estimate for what your calculation should return. Also look at SMF70MSU in the PR/SM Partition Data Section for verification.
Have you removed the PHYSICAL LPAR records from your data? If not, you may need to consider the impact of those records on your calculation. SMF70CIX is the field to point to the CPU ID name. Is SMF70BDS equal to X'FFFF' (-1) for each of your records? This indicates the PU is dedicated to the LPAR but if not then you could be mis-allocating CPU time. |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8700
Location: Dubuque, Iowa, USA
|
|
|
|
Okay, I went back and checked my notes on the type 70 records. For you to properly do your calculation, here's the steps to follow:
Read the PR/SM Partition Data Section of the type 70 record.
Find the LPAR name you want to measure (this section includes PHYSICAL as well as coupling facilities, so you have to look at SMF70LPM to identify the LPAR). There will be one of these for each defined LPAR, coupling facility LPAR, and 1 for the PHYSICAL machine.
Keep the SMF70BDN, SMF70BDS fields from this record. For your LPAR, SMF70BDN tells you how many of these data sections belong to it, and SMF70BDS tells you the first PR/SM Logical Processor Data Section that belongs to your LPAR (the first one is offset zero, so if SMF70BDS is 4 you'll want the fifth and subsequent PR/SM Logical Processor Data Sections).
That gives you the data sections for which you want to accumulate the SMF70PDT values.
If you have zIIP/zAAP processors, they are counted in these data sections. To identify them, you use the CPU Identification Section which lists how many of each type of processor you have -- but you'd need to list them first as I'm not sure if the list is constant across all machines. And you would definitely want to treat them differently since they process at full speed no matter the machine type you have, so you typically have to convert zIIP/zAAP CPU seconds to CP seconds before doing the conversion to MSU. You definitely do NOT want to just grab sections willy-nilly as you most likely will be getting the wrong ones.
And check the SMF70PDT values you read from the record -- after dividing by 1000000, you should have data in the range of 0 to the interval seconds -- if not, there is something wrong. Confirm your data is right before you start converting to MSU. |
|
| Back to top |
|
|
AdrielGB
New User
Joined: 24 Mar 2014
Posts: 3
Location: Brazil
|
|
|
|
HI Robert. Thanks for the help
You asked my "numbers" so SMF70WLA is 71 and SMF70LAC is 36.
I have a ziip BUT i dont know which PDT number correspond to the ziip because my SMF70CIX is zero for all prsm logical sections.
I review the logic of my program and i was starting on the first section of prsm logical section (my SMF70BDS is zero), so if i understand what you explained i should start on the second section and keep reading the next 3 sections until the fifth (my SMF70BDN is 4).
Well from those number i pass back then the first one was skipped and now i have
1407006640439552
251842789888
1252993307509505
541979859484672
Summaryzing then i have 3202231650223617.
With these number i should calcule with that formula (SMF70PDT_T*3600*16)/(SMF70CPA*RMF_INT*1000000) ? |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8700
Location: Dubuque, Iowa, USA
|
|
|
|
Your SMF70PDT values do not look right -- are those the raw numbers, or after you've done the calculations on them? The raw SMF70PDT values should be in the range of 0000000 through 900100000 -- 0.0 through 900.1 seconds since the interval is 900.1 seconds. If those are the values after the calculation, you need to look at the values before the calculation to make sure they are being read correctly. If they are the raw data from the type 70 record, you need to review your input routine as those values are DEFINITELY not good values for CPU seconds. If this is true, one thing to look at is the input location -- the SMF records use offset from byte 0 (which means offsets 0 and 1 are the RDW and the actual record starts at offset 4). If your REXX code is reading by column and not offset, you need to subtract 3 from the offset to have the correct column. Based on your original post, it looks like you are using the offset. However, the first line you posted
| Code: |
| offset = SMF70BVS+(SMF70BVL*SMF70BDS) |
is garbage. What you should have is something like
run your loop through the number of data sections, and add SMF70BVL to offset (not base, whatever that is) in the loop. |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8700
Location: Dubuque, Iowa, USA
|
|
| Back to top |
|
|
|
|
