z/XPF is a totally new approach in profiling technology. Instead of gathering data from within an address space, z/XPF captures its data from OUTSIDE the address space at the processor level, giving you far more information – without affecting the target address space in ANY way!

We call this methodology “Event profiling”. It allows us to present information you could not see before.

Now you can:

  • Measure SVC counts, and elapsed time;
  • Measure I/O response times;
  • Measure memory management events;
  • See locks and latches;
  • Measure TCB AND SRB-mode code;
  • Measure Program Calls;
  • Track events across address spaces;
  • Exploit SLIP and PER trace facilities for extremely fine measurement of events;
  • Analyze Page faults;
  • Analyze Locks and Latches.

Event profiling shows you MORE information, but it also has a very small “foot-print”.

  • z/XPF works without ANY system hooks.
  • It has no affect on the target address space.
  • z/XPF’s server address space consumes only a tiny segment of system resources because z/OS does most of the work!

The three steps to using z/XPF are:

Create your Data Capture session

Tell z/XPF how and when to start your data capture session. You can start immediately, at a future date or time or whenever a job or job-step begins.

Run your Data Capture session

z/XPF monitors your program’s execution. It “sees” everything without affecting your program’s address space. It gathers and collates a HUGE amount of information. Legacy profilers can capture up to 1000 samples per second. In the same run, z/XPF might capture 1,000,000 events or MORE. Which method of data capture is more granular? Which might be more accurate?

Filter and review your reports

Allocate your report dataset, and z/XPF will show you:

  • “Hot-spots” in CPU consumption;
  • How your program uses its own code paths;
  • Contention analysis;
  • Wait-time analysis;
  • Where you’re spending the most time;
  • Where you’re wasting resources.

You can “slice and dice” your reports to get down to an incredible level of detail – right down to the instruction level.

z/XPF has DB2 “awareness” built in. It tracks and reports on SRB-mode code (absolutely unique)! Soon, z/XPF will have CICS-awareness as well!

 

 

 




 


z/XPF, being an “Event-driven” profiler can do a lot of interesting things.

z/XPF captures SVC counts and TRUE elapsed times. It can compute average and total elapsed times.

z/XPF can “see” the time it takes for I/O to complete.


z/XPF can “see” I/O and external interrupts that occur in the target profile address space that are caused by code executing in ANOTHER address space.

z/XPF can “see” WAIT/POST times in an I/O module and can differentialte between self-induced wait times from contention-induced wait times.

z/XPF can “see” CPU contention by identifying loss of processor after an interrupt.

z/XPF can “see” LOCK suspend contention.

z/XPF can “see” LATCH suspend contention.

z/XPF can “see” execution counts for memory management events (such as GETMAIN/FREEMAIN, Storage OBTAIN, IARV64).

z/XPF can “see” execution counts for all Program CALL/Program RETURN/Program RETURN sequences, down to within a few milliseconds.

z/XPF can “see” Count and elapsed timings for DASD ant Tape devices, and shows the actual response time that the device presents to the I/O sub-system.

z/XPF can “see” the number and percent of total events where the application is executing code in another address space.

z/XPF works effectively with SLIP and PER trace records for Instruction Trace or Branch Trace.

z/XPF can show not only the the location for the PSW for a event, but the PSW’s state as well. Combined with SLIP/PER records, it is possible to follow execution logic.

z/XPF can do all this. z/XPF is unique among profilers.