JCCOPTS

Purpose

The JCCOPTS statement defines run-time options to the job-completion-checker task. This statement is used by a tracker when OPCOPTS JCCTASK (YES) is specified.

JCCOPTS is defined in the member of the EQQPARM library as specified by the JCCPARM parameter in the OPCOPTS statement.

Format

Parameters

CHKCLASS(SYSOUT classes|A)

Defines the SYSOUT classes that HCL Workload Automation for Z uses to check whether SYSOUT is available. You can specify a maximum of 16 SYSOUT classes. The SYSOUT classes are defined as a character string of valid SYSOUT classes, one character for each SYSOUT class. SYSOUT selection is also influenced by the value of the SYSOUTDISP keyword.

Any SYSOUT class can be specified in a JES2 system. In a JES3 system, you must define any SYSOUT class that is to be processed by the job completion checker:

As an external-writer SYSOUT class
As HOLD=EXTWTR and TYPE=PRINT in the JES3 SYSOUT initialization statement
If you define the SYSOUT CLASS as TYPE=DSISO, HCL Workload Automation for Z will be able to process only SYSTEM SYSOUT data sets. For both JES2 and JES3, the sysout classes defined by CHKCLASS cannot be used by a sysout archival product, or JES offload, or any other process which could delete the output before the JCC has processed it.
For example when you need to have a configuration with the data store subsystem and the tracker with the JCC task active on the same z/OS® system image, there could be compatibility problems if the JCC task options ask HCL Workload Automation for Z to delete the sysout output data sets after the usual analysis. This is because the JCC task might also delete the duplicated sysout copy created for the data store before it has been successfully stored. In this specific configuration, to avoid this problem and to improve the JCC performance (that would be scanning the same sysout data sets twice), you need to provide a JES class associated to the tracker destination, to be used for the JCC processing of the sysout data sets, in CHKCLASS option of JCCOPTS. The mandatory requirement is that it must not be one of the sysout classes specified in the RCLOPTS parameter keyword DSTCLASS. In this way the JCC task will never process the output data sets meant for data store processing. For more information, see DTCLASS.

No more than one JCC task can process a particular SYSOUT class.

Note: The keyword value is valid even if HCL Workload Automation for Z or the JCC subtask is stopped. It is not changed until you specify a different value and restart HCL Workload Automation for Z or the JCC subtask.

INCDSN(incident file dsname)

Defines the name of the incident log data set. This must be a cataloged, sequential data set on a direct access storage device (DASD). Several HCL Workload Automation for Z and OPC/A systems can use the same data set. Non-HCL Workload Automation for Z functions can update or reallocate the data set while HCL Workload Automation for Z is running.

JCCQMAX(maximum queue size | 112)

Defines the maximum number of 3P (job termination) event records that the JCC queue can hold. The default value is 112. If the value that you specify is not a multiple of 16, then it is rounded to the next multiple of 16.

If message EQQZ035E is issued on a system where the JCC is used, consider increasing the value of JCCQMAX. Refer to message EQQZ035E in Messages and Codes for more information.

JCCREQUD(JCC requested delay | 0)

Defines (in hundredths of seconds) how long the job completion checker (JCC) waits before issuing the request specified in SYSOUTDISP to JES. The maximum allowed value is 500 (5 seconds); any value exceeding this limit is automatically reset to 500.

Consider that high values can delay operations' tracking, therefore you might want to use the lowest working value or the default (0).

JCSAMECHK(same sysout check limit | 10)

Defines the number of consecutive times that the job completion checker (JCC) can accept the same data set name as the next data set to be read from the spool, before detecting a loop situation. A loop situation occurs when, for example, the data set is stored damaged in the JES spool. When a loop situation is detected, the JCC performs the following actions:

Stops processing the current and remaining data sets for the job being processed.
Applies the actions set in the SYSOUTDISP parameter, if possible.
Issues the message EQQW902E to notify the problem occurred to the job being processed: the job is set to error code JCCE, unless the system already set another error status for that job.
Switches to process the next job in the JCC queue.

The value 0 means that no loop detection is performed.

JCWAIT(wait limit | 4)

Defines how long the JCC waits (in seconds) before rechecking with JES to see if the SYSOUT for a job is available. Rechecking can continue for the time specified by the MAXDELAY keyword.

MAXDELAY(delay limit | 200)

Defines how long the JCC should try to retrieve SYSOUT from JES when JES indicates that the job does not have SYSOUT in any of the classes checked by the JCC. The MAXDELAY value is specified in seconds. If the delay limit is reached, the operation is set to ended-in-error.

SYSOUTDISP(SYSOUT disposition | blank)

Defines the action to be taken with SYSOUT data sets that have been processed. You can select one of these values:

blank: It represents a blank space. No disposition is specified. The JCC selects only nonheld SYSOUT, and the SYSOUT data sets are deleted after processing.
D: Disposition is delete. The JCC selects only held SYSOUT, and the SYSOUT data sets are deleted after processing.
Hx: Disposition is requeued and held. The JCC selects only held SYSOUT, and the SYSOUT data sets are requeued to SYSOUT class x after processing. Requeued data sets are held in the new SYSOUT class x.
R: Disposition is process, no requeue. The JCC selects only held SYSOUT, and the SYSOUT data sets remain in hold status after processing.
Rx: Disposition is requeued. The JCC selects only held SYSOUT, and the SYSOUT data sets are requeued to SYSOUT class x after processing. Requeued data sets are not held in the new SYSOUT class x.

Notes:

The keyword value is valid even if HCL Workload Automation for Z or the JCC subtask is stopped. It is not changed until you specify a different value and restart HCL Workload Automation for Z or the JCC subtask. If the data store is used, no requeue will be done.
When blank or D is specified, this keyword affects the restart and cleanup functions and RCLOPTS DSTCLASS keyword should be specified. See RCLOPTS statement for details.

UMAXLINE(number of lines | 50)

Defines how many lines to scan in each user SYSOUT data set. You can specify 0 through 2 147 328 000 lines. The value 0 requests the scanning of all lines.

If you write system dumps to SYSOUT, ensure dump records are not scanned.

USYSOUT(ALWAYS | NEVER | JOB)

Requests scanning of user SYSOUT data sets:

ALWAYS: User SYSOUT data sets are always scanned.
NEVER: User SYSOUT data sets are never scanned.
JOB: User SYSOUT data sets are scanned only if there is a job-specific message table. See JCC message tables for information about message tables.

 JCCOPTS CHKCLASS(CDEQ)   1
         JCWAIT(5)        2
         SYSOUTDISP(RA)   3
         UMAX(1000)       4

In this example of a JCCOPTS statement:

1: The JCC checks SYSOUT classes C, D, E, and Q for SYSOUT data sets.
2: If the output processing of a job is delayed, the JCC waits 5 seconds before rechecking the output queue for the SYSOUT for that job.
3: If a SYSOUT data set is found, it is processed according to the message tables and requeued to class A.
4: The JCC scans up to 1000 lines in user SYSOUT data sets.