This chapter should be read very carefully. It deals with performance considerations for managing large volumes of SYSOUTs. Although Control-V can be implemented effectively using the conventional "job writes reports to spool" method, it is possible to improve the efficiency of the data center by writing reports directly to compressed datasets.
Control-V can use two report processing techniques. The basic technique does not require any JCL changes and can be implemented immediately on any given report. The following diagram shows the basic report processing workflow:
Control-D monitor reads the reports from the spool.
Control-D monitor writes the reports to compressed datasets while deleting the original copy from the JES spool.
The decollating process is carried out while the reports are moved from the spool to the compressed datasets.
This type of process is reliable and is used by many report management systems. However, it is not the best solution in terms of overall system performance. The inherent problems of this method are:
Redundant write operations. The same report is written to the spool, then it is read from the spool and (again) written to compressed datasets. The writing of the report to the spool is redundant because the report finally resides on compressed datasets.
Use of the JES spool. This method is inefficient because:
The JES spool is a large pre-allocated DASD space. It must be large enough to contain many of the largest reports. Since it is a pre-allocated area, that area cannot be used for other purposes (for example, sort work areas) even when spool utilization is low.
The data on the spool is not compressed and is not structured efficiently. This results in a waste of space. A significant portion of the spool is full of blanks.
A sysout on the spool can be deleted (purged) very easily by indirect commands (for example, an operator may delete the entire sysout output class). Therefore, reports can disappear from the spool before they are printed and a rerun of the job is required to recreate the report.
Most security products have serious problems protecting data on the spool. Consequently, the spool is a potential security leak and sysouts on spool are not protected using conventional security methods.
Although 100% spool utilization must be avoided at all costs, this situation can occur very easily when many reports and dumps are written to the spool.
The JES spool is one of the most highly used components of the operating system. Programmers access the spool frequently to scan the JES queues using SDSF, FLASHER, ISPF, and TSO OUTPUT commands. The overhead for this activity depends on the number for outputs on the spool. If the spool contains unnecessary data, system overhead is unnecessarily increased.
The Compressed Dataset Access Method (CDAM) solves all of these problems. It also has other benefits:
Reports are written directly to compressed sysout. They do not pass through the spool, thereby avoiding redundant write operations.
The elapsed time of jobs which create large reports is reduced by 10% or more.
Since CDAM sysouts are written to specified units, there is no need for pre-allocated space. The CDAM allocates space only when it is actually needed and unused space is released for general use at the end of the job. There is no danger of a SB37 abend (space shortage) unless the specified unit is completely full. It is possible to define the entire free area in all the disks in the data center as one large potential "spool" for CDAM.
The CDAM performs report compression. The compression rate is 30% to 70% depending on the type of data.
A report stored in a compressed dataset is subject to all the security rules of the installation since it is a regular sequential dataset. Multi-user access to a compressed report is available only via the Control-V Online interface, and only to authorized users using regular dataset protection. The compression routine also acts as an encryption mechanism.
The danger of 100% spool utilization is greatly reduced because large reports and dumps (for example, from CICS) are no longer written to the spool.
Using CDAM, the number of sysouts on the spool is reduced; therefore, the overhead related to spool operations is reduced.
The following diagram shows the report workflow using the Compressed Dataset Access Method:
Figure 456 Control-V Report Workflow Using the Compressed Dataset Access Method
The recommended report processing workflow is:
Jobs write reports to compressed datasets.
Control-D monitor reads the reports from the compressed datasets and decollates them.
The Control-D monitor uses compressed reports in both workflows. The means by which Control-V (or the user) can create and read compressed reports is called the Compressed Dataset Access Method (CDAM).
CDAM is a general access method by which sysouts (reports) can be written to compressed datasets. To invoke CDAM, the user must modify the JCL of the job so that the reports are written to compressed datasets and not to the spool. There is no need to change the application program which produces the reports.
