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.