RUWAPOOL must work for DPLed (Distributed Program Linked) programs

Specifying RUWAPOOL=YES in the SIT gives an installation the chance to reduce the number of CICS GETMAINs and FREEMAINs thus reducing overhead and therefore saving cpu cycles.

The “System Initialization Parameter Reference” book states the following:

“For RUWAPOOL=YES CICS creates a pool of storage the first time a program invoked by Language Environment runs in a task. This provides an available storage pool that reduces the need to GETMAIN and FREEMAIN run-unit work areas (RUWAs) for every EXEC CICS LINK request.”

This only works for local transactions or for transactions routed by traditional transaction routing.

For transactions started by DPL or EXCI the RUWAPOOL mechanism does not work and a RUWAPOOL is not being created. This results in CICS GETMAINs and FREEMAINs for all Language Enclaves which are called under that transaction. An LE enclave is being created for every EXEC CICS LINK into a program invoked by LE.

In CICS case TS008340980 IBM Hursley confirmed this wrong behaviour and states that the reason for not allocation a RUWAPOOL is because the first program for DPL and EXCI is DFHMIRS and not the user program.

RUWAPOOL=YES must work for every kind of program call. There must not be difference handling local program calls, transaction routing, DPL, EXCI etc.

RUWAPOOL is a CICS performance option for many years now. Many CICS installations rely on this option as a tuning knob reducing CPU cycles by reducing the number of CICS GETMAINs and FREEMAINs. The implementation is easy and never at no point in the CICS documentation there are hints about any limits of the usage of RUWAPOOLs.

In our installation around 95 percent of 40 million transactions per day are being executed under DPLed programs. Therefore we do not have any benefit from the RUWAPOOL option at the moment.