Tony,
As I said in an earlier post, everything is a tradeoff, isn't it. If
the profiler code is actually running inside the target address space, and
it prevents the target from running while it gathers its data, it has the
ability to run data chains and such without a lot of interference. But, it
also will distort the target address space by its presence. My approach
does nothing to alter the target address space, other than having another
adress space active on the system at the same time as the target. I use
access registers to get at the target address space when it is necessary.
But because I pick up and process the trace entry some milliseconds after it
is made, it is impossible for me to run some data chains and get good data.
An example of that is register save area chaining. If the profiler has the
target stopped, this chain can be run, and caller information can be
acquired to know what module called the current one, from what offset and
such. As far as I know, that is the only advantage that methodology has
over my approach.
Using trace table data provides statistics on quite a lot of activity
that the other methodology misses. Most of the events recorded have a
timestamp, so elapsed times and execution counts can be computed. Program
Call and Program Return are recorded, so I can report on those. The number
of PSWs my code gets to look at compared to the other methodology is
significant. One of the other profilers may run at a sampling rate of say
1000 per minute(that seems to be somewhat common when we are talking to
potential customers, who usually are a user of one of the others). I believe
that comes out to about 1 psw every 16 milliseconds. When z/OS gives
control to a task or srb to run, it sets a timer. The length of the time is
the time slice. On my machine at the IBM Dallas RDP system, that time slice
was very short. I originally thought what I was seeing with these CPU timer
interrupts had to do with PR/SM, but Peter Relson set me straight on that.
If I remember correctly, it was something like 41 microseconds. Means there
was close to 25000 external interrupts just for the CPU timer being written
to the trace table every second. Add in all the other activity, from SVC's,
I/O interrupts, Start Sub-channel, Dispatch, Lock Suspend...a lot of 'stuff'
in the trace table to tell my code what the application is doing, and what
is happening to it. An active application will usually generate millions of
events in a fairly short period of time. The winner so far that I have seen
has been 52 million in just over two minutes. If you compare that to one of
the others running at say 1000 per minute sampling, my code looks at 52
million events, and there code looks at 2000.
No, there are no programming interfaces to get this data, as far as I
know. I have been asked by a number of people why I didn't hook one of the
IBM routines that process trace table entries. I just didn't want to go
that route. I wanted code that was as passive as possible. There are no
hooks at all using z/XPF, and yet the code can give elapsed times and counts
on all manner of events happening whithin an application.
--Dave
----- Original Message -----
From: "Tony Harminc" <[email protected]>
Newsgroups: bit.listserv.ibm-main
To: <[email protected]>
Sent: Tuesday, January 03, 2012 3:35 PM
Subject: Re: Question on adding an SVC routine dynamically to a running
system
On 3 January 2012 14:33, Dave Day <[email protected]> wrote:
I have a software offering that Dave Cole markets. You can go to his
website, and take a look at z/XPF. It competes in a niche market on z/OS,
application profiling. What makes mine different from the other guys in
this
arena is the approach I use to get the profiling data. Instead of
establishing tasks or running srb's into an address space, my code
scrapes
the system trace table for entries that are related to the target address
space.
It's an interesting approach, and I must say I'd be just as happy not
to see that extra baggage from other products that clutters dumps and
makes one wonder if it really, truly, doesn't change anything in the
environment my code runs in.
Are there Programming Interfaces to reading/scraping this trace table
data? In my experience, access to the trace data is something that has
broken more often than anything else when there is an IPCS to system
level mismatch. I assume for your sort of product you would need
access on the live system with reasonable performance, rather than
post processing through IPCS.
Tony H.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
