Mitigating the using of an unusually large amount of CPU by CA OPS/MVS OPSOSF servers.

Document ID : KB000016760
Last Modified Date : 14/02/2018
Show Technical Document Details

We just had an incident on a Production system where a repeating CICS transaction abend was causing our automation to trigger many iterations of a REXX program that runs in an OSF server. We have throttling code in effect, but need to deploy it more strategically to mitigate this kind of issue. Doing that will be our most immediate response.

Our Performance people were seeing OPSOSF using an unusually large amount of CPU. We don't currently use pre-compiled REXX.
That is certainly an option, but from experience I know it causes some additional complications.

We need to figure out what else to look at to improve this processing... Obviously, an approach would be to rewrite the REXX code to make it more efficient.

Is there another recommended approach we're not thinking of ?


(1) Is there a way to tell how much CPU is being used to compile a REXX vs. how much is used to execute it?
(2) Is there a way to have selected REXX programs loaded into memory and stored (similar to Enabled rules)? 


We do not have any benchmarks on CPU consumption between compiling and execution. But in general, the execution of code consumes more CPU than compiling it. You can pre-compile REXX exec's, the same as using pre-compiled rules, but REXX execs are not stored in memory like AOF rules are.

Additional Information:

Options to control the running of these Rexx Programs




How to Maintain REXX Source Programs (Option 2.4)