Mitigating the using of an unusually large amount of CPU by OPS/MVS OPSOSF servers.
Article ID: 16760
Updated On:
Products
Issue/Introduction
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)?
Environment
OPS/MVS
Resolution
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
Feedback
