JCC message tables
The JCC uses the CHKCLASS keyword you specified on the JCCOPTS statement (see CHKCLASS in the list of JCCOPTS Parameters) 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.
- Any job can have a job-specific message table. The member name in the EQQJCLIB library MUST be the same as the job name.
- The general message table is used for all jobs. The general message table must be located in the EQQGJCCT member of the EQQJCLIB library. JCC initialization will fail if the general table cannot be found.
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.
- 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.
- 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 in the list of JCCOPTS Parameters.
- 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.