Several years ago, Dave Day realized that a great deal of information was available in the System Trace Table under z/OS. While some trace table entries are commonly included in dumps, the sheer volume of data cycling through the Trace Table causes it to wrap many times per second. However, within explicit and implicit Trace Table entries you can find a great deal of information that relates to the activities within an address space. This gave rise to Dave Day's creation of z/XPF, a modern-day profiler that serves the industry as an "Event" profiler. By contrast, legacy profilers such as STROBE, Tritune and IBM's APA all use "State" profiling technology. By this, we mean that you can direct these products to suspend the target address space a certain number of times per second to gather data - capturing the "State" of the address space.
State profilers are wonderful, mature tools, but because of their design they CAN NOT gather some information. They cannot, for example give you the elapsed time for a Supervisor Call (SVC), or elapsed time for an I/O operation, or memory management events (GETMAIN/FREEMAIN, STORAGE OBTAIN/RELEASE), or many other things. State Profilers can't report on SRB activity, nor can they detect system LOCKS.
Further, State profilers directly affect what they seek to measure by stopping/starting the address space. And, with a limit of 1000 intervals per second, there is a consequential limit on the amount of data that State profilers can provide to the user. Event profilers do not affect the target address space in any way. In fact, there are no "hooks" to the OS in any sense. State profilers monitor the target address space at the processor level from OUTSIDE the address space. This allows State profilers to capture more events. And, since an Event profiler isn't limited to a certain number of samples per second, you can obtain MILLIONS of events for any address space. This sheer volume of data gives rise to far greater granularity in a State profiler's reports, and therefore greater accuracy.
State profilers are mature, useful tools. Event profilers, on the other hand, offer the opportunity to capture more data on more events with greater volume of data and greater granularity in reporting."