Decollating AFP Output

The following topics are covered in this chapter:

Output Decollating

Report decollating establishes report ownership. A report may belong either entirely to one user or to several users. Different pages of one report may belong to different users.

Output Retrieval

Control-D can retrieve output in one of two ways:

  • From the system spool.

  • Directly from Compressed Dataset Access Method (CDAM) compressed sysouts.

Control-D output retrieval is extremely flexible, allowing the exact requirements of each user to be met.

Control-D has the ability to decollate information that resides on a 32K column page.

The WHEN line and column range parameters specify the area on a report page in which the identifying character string is to be located.

The special line range 999-999 is used to describe decollation of the entire page as a stream of data. It is usually used when decollating a sysout in Page Mode. When a sysout is produced in Page Mode (as opposed to Line Mode), there are no real line numbers in the report (usually used for graphics). There is no way to check for line range. The search for the string is performed on the entire page.

The special column number 999 is used to describe decollation of aImplementing the "Direct to CDAM" Method/

The special column number 999 is used to describe decollation of an entire row. The string search is performed on the entire row (useful for AFP format lines that are longer than 998 characters).

Each report (on the JCL DD statement level) can be defined for retrieval by either of the two methods mentioned above. One job can produce two reports, one report being retrieved from the system spool and the other directly from CDAM.

Decollating from the System Spool

Decollating from the system spool does not require any JCL changes, and can be immediately implemented on any given report. Control-D can retrieve output from the system spool from any output class, held or not held. (On JES3, there are two different methods to handle outputs. For details, see the Control-D chapter in the INCONTROL for z/OS Installation Guide: Installing. The main difference between processing held and not held output is: With held output, Control-D copies the output and leaves the original output on the system spool. With not held output, Control-D moves the output, purging the output from the system spool after safely retrieving it. Held output retrieval is normally only used for initial implementation and testing of new reports in Control-D.

The work flow of output retrieval from the system spool is outlined below:

  • Jobs write reports to the system (JES) spool.

  • The Control-D monitor reads the reports from the system spool.

  • The Control-D monitor writes the reports to compressed datasets (CDAM), while deleting the original copy from the system spool (not held output).

  • The decollating process builds an index for all the reports.

Figure 3 Index Production During Decollation

There are two types of decollating missions:

  • A report decollating mission, that contains all instructions required for Control-D to process one job name, that is, one report decollating mission per job.

  • A generic decollating mission, that contains all instructions required for Control-D to process a selected group of output from one or more predefined classes, that is, one generic decollating mission for one or more jobs. A good example for the use of a generic decollating mission is decollating the MSGCLASS output from production jobs. Using this method, every job that produces output in the generic decollating (sysout) class is automatically decollated.

Decollating Directly from CDAM

Output retrieval directly from CDAM compressed sysouts is performed for jobs that write the reports directly to CDAM datasets, bypassing the system spool.

Figure 4 Decollating Directly from CDAM

This technique requires only minor JCL changes and provides many advantages. Listed below are several advantages of the CDAM technique:

  • The reports are written directly to compressed sysout; they do not pass through the system spool. Consequently, redundant read and write operations are eliminated and computer resources are conserved.

  • The elapsed time for jobs that create large reports is reduced by 10% or more.

  • The CDAM facility performs report compression. Depending on the type of data compressed, the compression rate is 30% – 70%. A significant amount of disk space is saved by this process.

  • Regular conventional security methods (for example, RACF, ACF2, TOP-SECRET) protect CDAM sysout (datasets).

  • The risk of 100% spool utilization is considerably reduced because the spool is minimally utilized.

  • There is no danger of SB37 abends due to insufficient disk space (for the compressed sysout).

AFP users can also specify PAGEDEF and FORMDEF parameters in the DD statement and not in the OUTPUT statement.

Implementing the "Direct to CDAM" Method

Examples of JCL writing directly to CDAM is provided below:

Example 1

Figure 5 Example JCL - Before CDAM

Copy 
//MYJOB   jobcard//STEP01  EXEC  PGM=MYPROG
//SYSUT1  DD    DSN=ABC.DEF
//SYSUT2  DD    SYSOUT=P,CHARS=(GS12,SR12),
//  DCB=OPTCD=J

Example 2

Figure 6 Example JCL - After CDAM

Copy 
//MYJOB   jobcard//STEP01  EXEC  PGM=MYPROG
//SYSUT1  DD    DSN=ABC.DEF
//SYSUT2  DD    SUBSYS=(CDAM,'SYSOUT=P,'
//  'CHARS=(GS12,SR12),OPTCD=J')

A JCL example of writing directly to CDAM using the FORMDEF and PAGEDEF parameters:

Example 3

Figure 7 Example JCL - Before CDAM with FORMDEF and PAGEDEF

Copy 
//MYJOB   jobcard//OUT1    OUTPUT   PAGEDEF=W240F2,FORMDEF=A11010
//STEP01  EXEC     PGM=MYPROG
//SYSUT1  DD       DSN=ABC.DEF
//SYSUT2  DD       SYSOUT=P,OUTPUT=*.OUT1

Example 4

Figure 8 Example JCL - After CDAM with FORMDEF and PAGEDEF

Copy 
//MYJOB   jobcard
//STEP01  EXEC  PGM=MYPROG
//SYSUT1  DD    DSN=ABC.DEF
//SYSUT2  DD    SUBSYS=(CDAM,'SYSOUT=P,'
//  'PAGEDEF=W240F2,FORMDEF=A11010')

All printing characteristics must be specified in the SUBSYS DD statement. There are certain situations that may require specification of some or all of the printing characteristics in other places for greater flexibility and additional capabilities. This is discussed in Category 3.

Output Produced by Dynamic Allocation

Certain data centers produce output using SVC99, or in other words, dynamic allocation. In these situations, there are no DD statements in the job’s JCL that represent the output. To have the output sent directly to CDAM, a modification in the dynamic allocation routine used in the data center is required to instruct the dynamic allocation routine to send the output to the CDAM subsystem instead of sending it to the system spool.

The problem that may arise when modifying the data center’s dynamic allocation program is that not all output produced by dynamic allocation should be sent directly to CDAM. This situation is especially obvious during the implementation process of Control-D. Control-D is usually implemented in stages. The implementation process does not take a long time, but it is still usually performed in stages.

A simple way of implementing the creation of output directly to CDAM when using dynamic allocation is to have the dynamic allocation program check if a specific DD statement appears in the job’s JCL. For example, the DD statement name can be CDAM and the DD statement could be a DD DUMMY statement. When a specific job (or job step) is required to produce output directly to CDAM, all that must be done is to add the special DD statement to the job’s JCL. The dynamic allocation program notices the special DD statement, and automatically perform the required modification. The required modification sends the output directly to the CDAM subsystem.

Using this method, the dynamic creation of output directly to CDAM can be on a job level (or even in specific job steps), while other output is sent to the system spool as before.