FAIL – Action to take with return codes

In normal use, Workload Automation Programming Language is expected to fail with non-zero return codes in the event of errors being found. However, during parallel testing when migrating from an alternative workload automation product to IBM Z Workload Scheduler, it is normal to send commands to IBM Z Workload Scheduler first, then to the alternative product that is controlling the workload. This enables IBM Z Workload Scheduler to be in the correct state to track events from the alternative product.

The following values are valid for FAIL:
YES
Default. Workload Automation Programming Language flushes commands after the OPTIONS STOPRC return code is issued, and returns the highest return code back to the running job.
NO
Workload Automation Programming Language continues processing commands even if the OPTIONS STOPRC return code has been reached, and in most circumstances ends with return code zero. Severe syntax issues causes the Workload Automation Programming Language step to fail, but these should be eliminating in testing before parallel running. All error messages will be echoed to the SYSLOG to be collected as part of the parallel testing process.
QUIET
Workload Automation Programming Language continues processing commands, even if the OPTIONS STOPRC return code has been reached, and in most circumstances ends with return code zero. Severe syntax issues causes the Workload Automation Programming Language step to fail, but these should be eliminating in testing before parallel running. No error messages will be echoed to the SYSLOG.
Note: OPTIONS FAIL overrides any return codes from commands, including SETMAX, but is overridden if OPTIONS SPOOF is coded.