----- Original Message -----
From: "Kris Buelens" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Tuesday, July 04, 2006 5:14 PM
Subject: Re: Performance Toolkit Tables
On Fri, 16 Jun 2006 07:12:09 -0400, [EMAIL PROTECTED] wrote:
The PIPE VMC would work great if it could return more than 101 lines. If
I could do something like PIPE VMC PTK NEXT,
that could work -- although they would have to change the performance
toolkit to make it work right. I have tried that,
and it doesn't seem to work the same twice. Sometimes it gives the
"second page" of userids, other times it gives the
"first page" again......
Setting the limits does merit some thought -- that could just work!
Thanks for the idea -- Paul.
I'm converting from RTM too and I struggle with the same problems.
- "PIPE VMC PERFSVM xxx" should always start at TOP,
So now I do issue a VMC PERFSVM TOP before the command I want and
that helps.
Well, where display should start depends on the display type:
- Displays with a list of users or whatever should initially show the top,
the assumption being that the user sorted them so as to show the stuff
he's interested in at the top.
- 'By time' logs should initially show the bottom, on the assumption that
the retriever is interested in the most recent data.
This should be the behaviour whenever you select a **new** screen.
Remember, however, that you're using an interface built for interactive
data retrieval. This means that PerfKit must remember, for each data
retriever, which part of the data had last been selected. While it should
automatically revert to top or bottom when a new (different) screen
is selected, it must **not** change the relative position as long as the
user keeps asking for the same kind of data. This is, after all, what you
probably would expect to happen in a normal native monitoring session.
I assume that your failure to consistently receive the data you expect
is due to PerfKit trying to provide this 'session' feeling. Submitting
a TOP command for each new cycle is the correct answer in that case.
But if your problem is something else then it may be a bug.
- There is also no indication that the VMC output is incomplete.
So I issue VMC PERFSVM NEXT and compare its last line with
what I previously collected. If it is the same, I'm ready. But,
one also must compare the header to verify that PERFSVM is still
reporting about the same period, if not: restart the whole thing.
Is the same period really so important? Are you retrieving data then
for ALL sample intervals? If so, you can try to synchronize your retrieval
actions with the CP Monitor cycle.
Or is the problem simply that you cannot rely on obtaining data for
ALL users or I/O devices otherwise because they may be in a completely
different order for the next interval, so that after a NEXT some may have
disappeared? That problem could be overcome by setting a sorting
sequence that doesn't change with load, i.e. sort for userid or device
number.
Did I overlook something, or this this "an area for improvement"?
P.S. I'm still using VMPTK that comes with z/VM 4.4
Kris Buelens
It certainly is an area that could be improved. In fact, the limitation
of the amount of data that could be passed back via PIPE VMC was
something we once had on the list of things to do. Unfortunately, as the
documentation says, it is not just something to be changed in PerfKit:
the current limitation is, as far as I remember, a documented restriction
of the PIPE VMC interface that is limited to retrieving a maximum of 8k.
So this is the first thing that would have to be extended, and that's where
the decision was made that it would have to wait. But if enough people
keep complaining Endicott may listen ..
(As an alternative I once had planned to just write an assembler module
that would retrieve the data and place the information either in the stack
or into some REXX variable. Wouldn't take much time doing that.
But when I knew Endicott was going to take over I decided to avoid this
awkward additional interface and place all my bets on PIPE instead.)
But a very simple solution could also be to just use the PRINT command,
e.g. 'PIPE VMC PERFSVM PRINT USER (TO BUELENS'
and then read the spool file to disk and process it. Not as nice as getting
the information in machine readable format right away, but depending
on what exactly you intend to do with the data it could be an alternative.
Eginhard Jaeger
