z/XPF Features and Benefits:
Why, in a mature market, would anyone consider z/XPF? Because it's better! How do we defend THAT statement?
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/XPC 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.
So, z/XPF can do all this. What does that mean to YOU?
|
 |