JCC message tables

The JCC uses the CHKCLASS keyword you specified on the JCCOPTS statement (see ***) to decide which SYSOUT classes to scan for each ending job. You determine how the SYSOUT data is to be scanned by creating JCC message tables. Each record in a SYSOUT data set is treated as a message. The JCC message tables determine which character string to search for in each message and what to do if the string is found. You define each message table as a member in the EQQJCLIB library.

The JCC uses two types of message tables:

When the JCC starts to process the output for a job, the EQQJCLIB is searched to determine if a job-specific message table is available for the job. If a job-specific message table is found, it is used in conjunction with the general message table. Each SYSOUT record is evaluated against the message tables in isolation, starting with the first record. The job-specific message table is used first, followed by the general message table. The SYSOUT record is evaluated against EVERY condition defined in the message table, as long as the CA= does not stop checking.

If a match is found and the checking action specifies STOP or ESTOP, no further JCC processing occurs for the job. If the matching criteria is started by a MULTSTA and a match is found against the MULTSTA, JCC does not treat this as a match until a match has been found for the same SYSOUT record on a subsequent MULTMSG. If the MULTSTA matches but no matching MULTMSG is found, the JCC takes the action defined in the corresponding MULTEND entry. If a MULTSTA M= value has been matched, no subsequent MULTSTA M= with the same M= value will be used, regardless of whether the checking action specified STOP or ESTOP.

If a match is found and the checking action permits processing to continue, or if no match is found in either the job-specific or general tables, the JCC takes the action defined in the ENDTAB entry. If there is no ENDTAB entry, JCC continues to process the SYSOUT from the next record.

When there is a match with a NORMMSG or a MULTSTA, the SYSOUT record is consumed. This means that no further processing occurs for that SYSOUT record. Therefore, if there is a match in a job-specific table, processing for that SYSOUT record stops immediately, and the general table is not searched. Processing will continue at the next SYSOUT record only if the CA= allows checking to continue.

A SYSOUT data set is created by the z/OS system or by a user program. All records are checked in SYSOUT data sets created by the z/OS system. The value of the USYSOUT keyword of JCCOPTS determines if a user SYSOUT data set is checked. The value of the UMAXLINE keyword determines how many lines of a user SYSOUT data set are checked.

All records in all SYSOUT data sets are passed to the tracker exit, EQQUX005 (the SYSOUT archiving exit). You can use this exit to copy SYSOUT data sets to a data set that resides on a disk or tape.

Notes:
  1. The JCC is a tracker function and is, therefore, independent of the contents of the controller current-plan data set. The JCC processes all jobs for which a job termination (3P) event is created in the event data set, regardless of whether the job is defined in the current plan. To prevent the JCC from processing a job or a class of jobs, you must use the tracker event-filtering exit, EQQUX004.
  2. Because it is possible to send JES2 job SYSOUT, or parts of the SYSOUT, to several NJE nodes, more than one job termination (A3P) event could be produced for the same job. Each event could also have different job-completion-code information, depending on the output sent to a particular node and the checking that the JCC performs at that node. The status assigned to the operation depends on which of the A3P events is first processed by the controller. You should ensure, therefore, that the value FINAL is used for the OUTPUTNODE keyword of the JTOPTS statement. FINAL is the default value. If the JESYSMSG part (previously $SYSMSGS, DSID=4) of SYSOUT is copied to several final destination nodes where the JCC is active, or you specify the value ANY for OUTPUTNODE, the resulting status of the corresponding operation will be unpredictable. The OUTPUTNODE keyword is described on page ***.
  3. The technique described in note 2 is not used in a JES3 environment. If you send the output from a JES3 job to different NJE nodes where the JCC is active, the JCC should perform the same checking at each node. Otherwise, the resulting status of the corresponding operation will be unpredictable.