JESTOESF

The JESTOESF interface automatically converts JES2 or JES3 SYSOUT data sets into CA Spool files and retains the attributes of the original files.

Selected or all non-held SYSOUT data sets resulting from job execution can be queued for automatic transfer to CA Spool. When the transfer is complete, the transferred data sets are purged from the JES2 or JES3 spool.

When the XFER interface is used and the XFERTIME interval expires, CA Spool requests the output for the appropriate destinations and classes based on parameters such as XFERDEST, XFERCLAS and XFEROPT in the ESFPARM files. For example, if XFERDEST=FORCE is specified, there can be one, two or four requests for each node defined in your ESFPARM files. You can specify the node name for various requests such destination, writer name, alias name.

After specifying the node, CA Spool begins to make the required requests. The request process continues till there is one complete pass of all of the required requests and it returns no sysout files. The process begins again when XFERTIME next expires.

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 ESFTOJES 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 for 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 need to 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.