John,

I usually hate replies, that don't answer the question, but instead state: why 
don't you try it this way. However, this time I would like to ask some 'what 
are you doing' questions, in spite of your last remark.

1. The product that produces the CMFCPU13/14/15 messages also produces your RMF 
72 records. From those I produce all my statistics on quarterly or hourly 
intervals, be it through CA MICS, but you can do it also via SAS / MXG (or some 
RMF reporting tool I believe). You can even download the SMF records to your 
Linux or Windows system and process them with SAS or a similar product. Did you 
try this?

2. What conclusions do you want to pull out of the figures? You know, that 
these 'LPAR is capped' figures have only a slight relation with the performance 
of those LPARs. If you have a road sign stating there is a speed limit of 100 
m/h, that road is 'capped', but the capping won't hardly create performance 
problems.

Kees.


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf 
Of John McKown
Sent: Friday, June 20, 2014 14:42
To: [email protected]
Subject: How to? Designing a "graph" of information

We use PR/SM Group Capacity to regulate our aggregate MSUs from two LPARs on a 
single CEC. This is for cost containment. We have a product which runs on both 
z/OS images on the LPARs which produce messages similar to:

N 4020000 LIH1     14169 22:07:51.36 STC16813 00000090  CMFCPU15 LPAR NO
LONGER SOFT CAPPED BY WLM; CAPPED DURATION WAS
S                                                       00.02.00

I have a program, on Linux, which takes this and produces lines like:

LPAR LIH1 was capped starting at Mon 2014-06-16 21:52:41 until Mon
2014-06-16 21:55:31 for a duration of 00.02.50

I can the process this information in another program which puts the
fields: LPAR (LIH1 above), the started date & time (2014-06-15 21:52:41 &
2014-06-16 21:55:31) into a relational table. From this I can generate another 
table which has a row for each minute within the interval. Each row contains 
the date/time column & a column for each z/OS Image. The z/OS image either 
contains a " " or a "*" depending on whether that z/OS is WLM capped any time 
during that minute. Thing of the columns like: date/time @ minute resolution; 
is LPAR#1 capped?; Is LPAR#2 capped?. Now what I want to do is create a "time 
graph". The X axis is the date / time. Each point on the Y axis is for a given 
LPAR. The intersection (plot) is either "*" if that LPAR is capped at that time 
or a blank. This is to show, along a time sequence how each LPAR is being 
"capped" and "uncapped".

Ex:

LIH1 capped|     *             |   *              |
DEV1 capped|                   |   *              |
Date/Time  |  yyyy-mm-dd hh:mm | yyyy-mm-dd hh:mm |


Hopefully you get the idea. And see at least one problem. There are 1400 
minutes in a single day. Way too many to plot even a single day. So I though, 
why not summarize, perhaps on an hourly basis. Where each "point"
in the plot is the sum of the number of minutes in which the LPAR was capped. 
This would be easy to do with SQL if I changed the " " & "*" for not 
capped/capped to 0 and 1 instead. Which I can easily do. Then use SQL to 
consolidate each hour. Again, easy. But what I'd like is something more 
"visual" than just putting out what would look like a spread sheet with 
numbers. What I would like is a true graph where for each DateTime / LPAR 
"point", I would plot a "bar" whose thickness is relative to the number.
I.e. if a particular LPAR, during a particular hour had been capped 60 times 
(max # of minutes), then I'd have a 100% full vertical "bar" at that point. If 
it had been capped 30 times, then a 50% full bar. This way, the eye can easily 
scan along the X axis getting an "intuitive" grasp of how the LPARs are being 
impacted by the WLM capping.

First, does the above information sound useful to others? I mean what I'm 
trying to convey (how WLM capping is possibly affecting turn around).
Secondly, is the method (the "bars" varying in height) a good "intuitive"
way to display the information to management (who simply adore graphs, with 
colors!). Third, most difficult, how do I create that graph from the 
information. My original data source is the SYSLOG that we unload to a disk 
data set. I was going to go into a lot of what I have done, but have decided 
that it likely isn't necessary.

Thanks for thoughts. The ones about my lack of sanity are already well known! 
<grin/>

--
There is nothing more pleasant than traveling and meeting new people!
Genghis Khan

Maranatha! <><
John McKown

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
[email protected] with the message: INFO IBM-MAIN
********************************************************
For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt. 
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286
********************************************************
                        


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

Reply via email to