Unless the objective is to have a program that will collect some of the
records for one reporting function and another instance of the program
collecting a different selection of the monitor records for a different
reporting function, why not just limit the amount of records written to
the monitor segment in the first place?
Jim
Thomas Kern wrote:
Maybe this is where we need a NEW utility program, since MONWRITE is doin=
g
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, w=
ill
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/O=
S
based capacity planning process.
/Tom Kern
On Tue, 18 Mar 2008 09:10:12 -0400, Hamilton, Brian <[EMAIL PROTECTED]
om>
wrote:
Hi Stefan,=20
In response to your statement,=20
* the old file is read by a rexx procedure and only a subset of the
monitoring records are selected from=20
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
--
Jim Bohnsack
Cornell University
(607) 255-1760
[EMAIL PROTECTED]
