I'll see what I can get out of BMC's Mainview. It's really been a long while since I looked at what sort of reports it can produce.
On Fri, Jun 20, 2014 at 9:23 AM, Ken Porowski <ken.porow...@cit.com> wrote: > I use the RMF "CPU Activity" report "Partition Data Report" and strip out > Date, Time, LPAR, DEF and ACT MSU and capping %. > > Gives me a nice graph of MSU by interval and capping % if capped. You can > also show when the LPAR is using more than its defined capacity and why > soft capping is better than hard capping (FSVO better). > > > > > CIT | Ken Porowski | VP Mainframe Engineering | Information Technology | > +1 973 740 5459 (tel) | ken.porow...@cit.com > > > > > This email message and any accompanying materials may contain proprietary, > privileged and confidential information of CIT Group Inc. or its > subsidiaries or affiliates (collectively, “CIT”), and are intended solely > for the recipient(s) named above. If you are not the intended recipient of > this communication, any use, disclosure, printing, copying or distribution, > or reliance on the contents, of this communication is strictly prohibited. > CIT disclaims any liability for the review, retransmission, dissemination > or other use of, or the taking of any action in reliance upon, this > communication by persons other than the intended recipient(s). If you have > received this communication in error, please reply to the sender advising > of the error in transmission, and immediately delete and destroy the > communication and any accompanying materials. To the extent permitted by > applicable law, CIT and others may inspect, review, monitor, analyze, copy, > record and retain any communications sent from or received at this email > address. > > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of John McKown > Sent: Friday, June 20, 2014 8:42 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: [IBM-MAIN] 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
