#SCC statements can optionally be scheduled using the #JI or #JO techniques. If the #JI or #JO are used, different #SCC statements can be used per SCHID.
#SCC statements cannot be scheduled using #XI or #XO and cannot be added to JCL in the queue.
Multiple #SCC statements are allowed for each job step name.
A #SCC test for a step name of * (asterisk) can be used by itself to apply to each step in the job. If used in combination with a #SCC for a specific job step, the condition code returned by that step is validated against both #SCC condition code tests.
The RO value on the job definition panel must be set to #S or all #SCC statements are ignored. If job-level condition code testing is wanted, the job definition panel must be used and the RO value is any other valid value (other than #S). In this way #SCC statements can still be in the JCL for future use, but are ignored.
Since CA WA CA 7 Edition only regains control of a job at job completion time, #SCC tests cannot be used to bypass execution of job steps.
Failure of any condition code test, either at step level or job level, causes the job to be returned to the request queue and flagged with a restart requirement.
#SCC statements can be located anywhere in the JCL following the JOB statement, but should be positioned in step execution sequence for user readability.
Overhead for a job-level condition code test as defined on the job definition panel is less than using the #SCC statements and should be considered before implementing #SCC tests. For most jobs, the job definition panel option probably can be used.
SMF step termination records cause a job step to be tested against all #SCC tests defined for that step. No tests are made to ensure that a step exists with the name defined in #SCC statements.
