Use the appropriate interface when bringing SYSOUT files under CA Spool control. There are four different CA Spool SYSOUT input interfaces to choose from; one or a combination will be the best practice for your site. Use the guidance supplied in the Additional Considerations section to evaluate the impact of each interface and to determine the most productive and advantageous configuration.
Business Value:
CA Spool efficiency is directly related to the type of input interface(s) that you choose to implement. The methods by which CA Spool collects input data have a significant impact on processing speed and system resources.
Additional Considerations:
To gain the most control over when CA Spool processes reports, you can choose to have the SYSOUT written to JES first and then transferred to CA Spool using the NJE interface or the XFER SAPI interface.
If you want to avoid double spooling first in JES and then in CA Spool, you can use the DD SUBSYS interface or the SYSOUT Allocation Intercept interface. This requires CA Spool to be running on the system where the SYSOUT is generated.
The SYSOUT input interfaces, in order of best performance are:
The allocation request is passed directly to the specified CA Spool subsystem causing the SYSOUT to be written directly into a CA Spool file.
CA Spool will look at SYSOUT allocation requests and decide if requests should be rerouted to CA Spool.
When an NJE node has a SYSOUT ready it will start sending immediately. Up to seven SYSOUT and seven JOB streams can be sent and received in parallel between two NJE nodes. All SYSOUT attributes are preserved. It is the preferred interface to interconnect CA Spool systems. Using the NJE interface to receive SYSOUT from JES2 or JES3/BDT you either have to change your JCL to specify a DEST equal to the CA Spool NJE node name or with JES2, add DESTID definitions for all printers to route output to the CA Spool NJE node.
Every time the XFERTIME timer expires the SAPI interface wakes up and makes the specified SAPI queries for SYSOUT against JES until there is no more SYSOUT to retrieve.
There are four different ways to use the SAPI interface with increasing CA Spool and JES overhead:
This provides minimal overhead but requires JCL changes.
This provides minimal overhead and requires no JCL changes if all SYSOUT in specific output classes can be picked up by CA Spool.
This requires no JCL changes but creates extra CA Spool and JES overhead because 1-4 SAPI queries are processed per defined printer every time the XFER timer expires.
With many printers defined this may cause a noticeable CPU overhead. XFERDEST=YES may help reduce the queries to only JES defined printers and XFERDEST=DEST | WRITER may be used to halve the number of queries. The use of the printer node XFERNODE= BOTH | NODE | ALIAS | OFF may further help fine-tune the number of SAPI queries.
This may dramatically reduce the CPU overhead with the expense of about 12K virtual storage per thread in the CA Spool region.
When XFERSAPI=THREADS is used, a thread is established for each request designated by the ESFPARM definitions when the interface is initialized. The JES subsystem will post each thread when a 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.
|
Copyright © 2011 CA.
All rights reserved.
|
|