On Tue, 18 Mar 2008 09:41:24 -0500 =?ISO-8859-1?Q?Thomas_Kern?= said: >Maybe this is where we need a NEW utility program, since MONWRITE is doing >exactly the job it was written for (copying ALL monitor data to disk/tape?). >Perhaps a utility that when pointed at a selection criteria file and a >monwrite output file, will copy only those monitor records sellected. Or >when pointed at such a selection criteria file and the MONDCSS segment, will >connect to the MONDCSS segment and in real-time copy only those monitor >records selected, thereby reducing the amount of VM DASD needed for a z/OS >based capacity planning process.
Actually, there already is such a utility program, and it is shipped with every z/VM system. It's kept on the 190 or S-disk so you may not think to look there. It's called CMS Pipelines. There is a STARMON stage for reading data from the MONDCSS and *MONITOR IUCV service. There is a DEBLOCK MONITOR stage for reformating the headers, and there are LOCATE and other stages for selecting the records desired. (DFSORT or SYNCSORT is often used for selecting SMF records on MVS, when lots of SMF records are recorded, but not need for every process. Pipelines would be the corresponding tool) For more details, PIPE AHELP STARMON, and PIPE AHELP DEBLOCK. Also see http://www2.marist.edu/~pipeline/pipeline.news117 http://www2.marist.edu/~pipeline/pipeline.news1110 http://www2.marist.edu/~pipeline/bhelp/ACH0201.html /ahw >/Tom Kern >On Tue, 18 Mar 2008 09:10:12 -0400, Hamilton, Brian <[EMAIL PROTECTED]> >wrote: >>Hi Stefan, >> >>In response to your statement, >> >>* the old file is read by a rexx procedure and only a subset of the >>monitoring records are selected from >>it building a new file (about 10% of the original size), this reduced >>file is then send to z/OS by ftp for reporting. >> >>I'd be interested in what this rexx is extracting. Our intent is to >>produce reports on CPU and memory usage and I agree the data is huge. >> >>Thanks >>Brian
