Eginhard, Thank you very much for your reply.
You are correct, I'm looking at strictly collecting data for capacity planning. The data will be fed into MXG which runs on a z/OS 1.7 host. We've tried feeding the perf toolkit trend files into MXG however we have been told MXG will only process raw MONITOR data (4096 records)...that's what I have been told. As for the data collection I've gone ahead and turned off most of the event data collection and will focus on the sample data. I have also changed the sample interval to 5 mins. Thanks again Brian -----Original Message----- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Eginhard Jaeger Sent: Wednesday, March 12, 2008 4:09 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: MONWRITE files Brian, the 'Q MONITOR' output you included appears to be just the information related to 'event' data, i.e. data collected by the monitor whenever a specific event occurs, as opposed to 'sample' data which is collected at fixed time intervals, and whose domain status would have been shown on the following lines. I don't know MXG, but I doubt that it will need a lot of event data for your purpose (which I assume to be just collecting data for management reports and/or capacity planning). Capacity planning is mainly based on sample data. Beware especially of enabling SCHEDULER data for all users: that will generate a tremendous amount of data that will take up a LOT of space on your disks, but that nobody is likely to ever look at except in very special cases. (While PerfKit will use the data for its 'User Transaction Details' report, that displays information only for a single user at a time, and SCHEDULER event data collection should be activated only for that specific user while it is needed.) The amount of disk space needed for the MONWRITE file will depend largely on the number of users and disks you collect data for. So if your VM system has access to lots of DASD that belong to other LPARs either set them offline in your system, or at least disable monitor data collection for them. Only the owning LPARs should collect data for DASD. And the amount of disk space needed is proportional to the time you collect data for. You can get away with less disk space if you close the monitor file every few hours and then start a new one while the previous one can be processed and then deleted. But if all you need is summary data for capacity planning, PerfKit can provide that information in its trend file, without the need to collect raw monitor data on disk ... Eginhard Jaeger ----- Original Message ----- >From: "Hamilton, Brian" <[EMAIL PROTECTED]> >To: <IBMVM@LISTSERV.UARK.EDU> >Sent: Tuesday, March 11, 2008 11:57 PM >Subject: Re: MONWRITE files >Thanks again... >And ideal on the amount of data were talking here on a typical day? >Typical mini disk size's??? 500 cyls, full 3390 mod 3, multiple >mod-3's... >This is currently what is being actively monitored >MONITOR DOMAIN ENABLED >PROCESSOR DOMAIN DISABLED >STORAGE DOMAIN ENABLED >SCHEDULER DOMAIN ENABLED > ALL USERS ENABLED >SEEKS DOMAIN DISABLED >USER DOMAIN DISABLED >I/O DOMAIN ENABLED > ALL DEVICES ENABLED >APPLDATA DOMAIN DISABLED >MONITOR SAMPLE ACTIVE > INTERVAL 1 MINUTES > RATE 2.00 SECONDS
