On Tue, Jan 10, 2012 at 1:18 AM, Michael Harding <[email protected]> wrote:
> I'm not discarding them, ESAWRITE <grin> is still capturing them. I was > just playing with getting my own look. > Yes, I've added the pick already, but if starmon will ignore the unwanted > ones on my behalf, that should save a good many trips through pipelines' > dispatching mechanism. You could also have ESAWRITE trace a particular subset of the records, if you want. I looked again at the starmon stage with the book handy, and it *does* seem to work. But slightly different. The z/VM monitor provides a "heads-up" bitmap to indicate what domain is in a particular monitor buffer. CMS Pipelines uses that to decide whether it will deblock or discard the entire buffer. When the buffer is deblocked, no further filtering is done on the domain of individual records. Whether this saves a lot in real life is to be seen. The sample data is presented as a single buffer, so you get it all. The event data is normally a mix of user events (queue drop and dispatch), seek data and applmon events (if enabled). I could imagine CMS Pipelines might use the mask also to filter after deblocking, but you may not notice the difference with discarding them early in the pipeline. It should be no surprise that my deblocking routine for monitor data uses a "lookup" stage to select the record domain/types that I care about... Rob
