On Fri, Jun 20, 2014 at 8:29 AM, Elardus Engelbrecht < [email protected]> wrote:
> John McKown wrote: > > >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. > > >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. > > Rather, do your program 24 times instead of 1440 times. Combine the 60 > minutes into one number and pass that to your graphing program. You can > use different symbols for low capping (<15 minutes) or medium capping or > high capping for example. > Good idea. And easy to implement since the data is really in an PostgreSQL relational database. It is easy to consolidate by hour. > > Also consider using a CSV file and you can then import it in your > spreadsheet. After each import the graphs will updated automatically. > I will create an Excel <shudder/> spreadsheet from the hourly consolidated information and send it to a couple of people. They might give me some feed back on whether they are even interested. > > Alternatively: > > What you can do is, import your raw data (1440 rows) from CSV or text > file, then select for each columns the 60 minutes for an interval, say > B1-60. place the sum formula in D1. Then the sum of B61-B120 is in D2, etc. > > Now prepare the graph using D1-D24 as an axis. > > If you do it right, you should just re-import (refresh) from the CSV and > the graph will be redone with summing all and everything properly. > > > I would plot a "bar" whose thickness is relative to the number. > > Try height instead of width, then your graphs will stay more or less > consistent. (ratio of graphs fields against labels and axis headers) > That's what I meant, but my fingers are being contrary this morning. > > >First, does the above information sound useful to others? > > Indeed. Managers are more tolerant to graphs. :-) It is us lowly guys/gals > who had to create them > Right. And the problem is graphing software. I actually have two different possibilities. One is an Excel spreadsheet. The other is using the R language. This is a good excuse to learn more about R. R is to Linux/*IX as SAS is to z/OS. Without the cost. It is _libre_ software. > > Groete / Greetings > Elardus Engelbrecht > > -- 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
