That was from years ago, before ESAWRITE wrote the configuration records for every hourly file. Both the hourly file and the configuration record in every one of them were for problems that we had at USAir, and originated out of the process that I implemented and shared with Barton. Since our configuration rarely changed, only once every IOCP/POR, copying the one record did no harm. In those days, MICS only accepted raw data from VM, and it ignored the configuration record after verifying its existence. Even if it did warp the data, that was no problem because the capacity planners never did use it; they simply ignored VM. The only systems they cared about were MVS and TPF.
Regards, Richard Schuh > -----Original Message----- > From: The IBM z/VM Operating System > [mailto:ib...@listserv.uark.edu] On Behalf Of Rob van der Heij > Sent: Thursday, January 15, 2009 1:54 PM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: Sorting monitor data? > > On Thu, Jan 15, 2009 at 7:01 PM, Schuh, Richard > <rsc...@visa.com> wrote: > > > IIRC, that is a configuration record that is written when > the monitor > > is initialized. It was required by MICS. ESAWRITE has the > ability to > > start each raw data file with one of these records. If you > don't have > > ESAWRITE, you can find a configuration record in any file, retain a > > copy of it and include it in the files processed by the program. > > Constructing you own raw monitor data out of snippets that > you have kept is probably not a good idea. The configuration > data provides the context for the subsequent sample data. > That's the reason programs that process monitor data need the > configuration records. Though borrowed data from somewhere > else may bypass the check that such a program does, it's > likely to affect the quality of your numbers. > > And since you mention ESAWRITE: apart from raw monitor data, > MXG also reads the history data format that ESAWRITE > produces. This is much smaller and probably makes the entire > problem go away. It also saves the staging disk space both on > VM and MVS, and uses less resources on MVS to process it. > > Rob > -- > Rob van der Heij > Velocity Software > http://www.velocitysoftware.com/ >
