How to reduced CPU overhead when using the CA Spool XFER SAPI interface?

How to reduced CPU overhead when using the CA Spool XFER SAPI interface?

Solution:

When looking at the JES2 CPU usage, it can be found that a high percentage of the workload happens in the SYSOUT Application Program Interface (SAPI).*

It might then be necessary to research all the products that uses SAPI and for each of them investigate how to reduce CPU usage. CA Spool uses SAPI services in the JESTOESF XFER transfer interface where SYSOUTS are being transferred from the JES Spool and written to CA Spool files.

To know the status of the XFER SAPI interface enter the CA Spool /DX command. When the SAPI interface is active, the output of the command shows:

Reducing the number of SAPI requests should help to reduce CPU consumption on both JES2 and CA Spool Address Spaces. It can be achieved by activating the SAPI threads feature available with JES (XFERSAPI=THREADS) and/or limiting the number of requests to JEx (XFERNODE= parameter on DEFNODE/NODE definitions).

Following is an excerpt from our manuals on a discussion about XFERSAPI=THREADS and XFERNODE usage:

When SAPI threads (XFER=YES, XFERSAPI=THREADS) is used, a thread is established for each request designated by the ESFPARM definitions when the interface is initialized. The JESx subsystem will post each thread when sysout is available that matches the selection criteria established when the thread was initialized. When XFERTIME expires, each thread is checked to determine if any new sysout is available, and if so, a request is made to transfer that sysout.

The benefit of SAPI threads is a reduction in CPU utilization. After the initialization process, there will be no further requests that result in no sysout being returned with some exceptions. If the JESTOESF interface or the XFER interface is halted, the thread is released and re-established when the interface is started again. In addition, if a REINIT command results in changes to the printer definitions such as adds, deletes or modifies, the threads are released and re-established. Printers that are added using Automatic Printer Definition will not have a thread added to them until a REINIT command is issued.

Each SAPI thread uses approximately 12K in SP230 storage (above the line), before SAPI threads is chosen as the XFER interface method, the storage used by SAPI threads should be calculated and analyzed to determine if the additional storage use makes sense in your current environment. To determine how many requests are being made by SAPI using your current ESFPARM files, specify XFEROPT=24 and XFERSAPI=YES and recycle. An ESF772 message will be issued at initialization stating the number of unique requests being made after each XFERTIME interval. To estimate the storage that will be used, multiply that number by 12K. The default maximum number of threads is 5000. That number can be changed using the XFERTHCT parameter. If the total number of threads ever exceeds the XFERTHCT value, threads will be turned off and processing will switch to XFERSAPI=YES.

If the SAPI thread count is too high to consider the move to threads processing, consider investigating the use of the node parameter XFERNODE. XFERNODE can be used to limit the number of requests/threads that are made by CA Spool. If there are nodes defined in ESFPARMS that will never have sysout transferred by the XFER interface, there is no need to have SAPI requests or threads for them. XFERNODE can be set to OFF to eliminate a node, NODE to request only the node name, or ALIAS to skip the node and request only ALIAS, if specified. The default is BOTH.

Although results may vary depending on the configuration, using XFERSAPI=THREADS and changing XFERTIME from 10 to 20 in an environment with less than 2000 NODEs each defined with an ALIAS name improved CPU usage in a ratio from 1 to 4.

* On an z/OS console, issue a JES2 command $D PERFDATA(CPUSTAT) and look for "PCE SPI" where SPI stands for the "SYSOUT Application Program Interface (SAPI).