High z/OS CPU utilisation for Gen action blocks generated with trace
search cancel

High z/OS CPU utilisation for Gen action blocks generated with trace


Article ID: 227365


Updated On:




Recently experienced excessive CPU use on z/OS with a developer tracing in DTF.
Subsequent tests revealed that after generating and building only 8 action blocks in trace CPU time increased from 1.75 sec to 443 sec, a mere 25,000% increase in round figures or better than 2 orders of magnitude, for the same workload without executing in trace.
While the former execution consumed less than 50% of two processors, significant in itself, the latter consumed 100% of both processors for the entire duration. That makes nearly 8 minutes when nothing else happened on the LPAR.  

Analysis of a STROBE report suggests the time is spent in the PARA-0000000000-TRACE of only one of the action blocks.  It was not in calling TIRTRCE, but in preparing for the call and dealing with the response.

Is Broadcom aware of this behaviour?  Does Broadcom have any solutions or recommendations on how to deal with it?


Release : 8.6

Component : CA Gen Run Time, Blockmode


Gen Engineering don't recall a performance complaint of this magnitude ever being reported.
Of course, most customers probably do not run code generated for trace in their production environment so they might not have noticed it occurring in a lesser impact environment or if they did notice it were not concerned enough to report it.

Engineering doesn't believe the generated code in this area or TIRTRCE has changed in a very long time, so this is not likely to be a new problem.
After looking at the generated code in the PARA-0000000000-TRACE paragraph, they can see there is logic to deal with the views before and after the call to TIRTRCE. So they could see how an Action Diagram that had many views and many PAD statements could spend an awful lot of time in the PARA-0000000000-TRACE paragraph since it is called for every PAD statement.
They suspect there are performance improvements that could be made in this area, but that would require an enhancement request. 
Therefore Engineering is suggesting the creation of an Idea on the Ideas Community. That would also be useful to gauge how many customers might have seen this behaviour before and not bothered reporting it, but would now vote for such an idea.

In the meantime, the only recommendation Engineering can make is a little counter-intuitive. If High Performance View Passing (HPVP) is turned off on the affected Action Blocks, then the generated code would not have to execute the existing logic to deal with the views before/after the call to TIRTRCE. So this would likely greatly improve performance of these Action Blocks when generated for Trace. The downside is that turning off HPVP on these Action Blocks could potentially hurt performance whenever these Action Blocks are called when not generated for Trace. However, Engineering suspect that when generated for Trace, the performance with HPVP turned off should be better.

Additional Information

Using the Toolset > Properties for Action Diagram/Operation
External Action Blocks in HE > Create the Calling Procedure Step or Action Block

NOTE: Per the above pages, the disablement of HPVP cannot be used as a workaround if the common action block (CAB) in question is a Component CAB being used in Component Based Development (CBD).
A Component CAB is an internal Action Block in the component model and an External Action Block (EAB) in the consuming model. That means if turn off HPVP in the component model, then it must also be turned off in the EAB in the consuming model i.e. the call signatures must match.
However, when HPVP is turned off for an EAB it only gets the PSMGR-EAB-DATA section of GLOBDATA (instead of all of GLOBDATA). That is not sufficient if the component needs to access a database since the component may be setting fields in the PSMGR-DASG-DATA section of GLOBDATA. Thus HPVP must remain on for a Component CAB.