Remove JCLERR= from the JOBDEF initialization statement
Description
Before z/OS V2R1, for JCL job card errors that were detected during the input phase that the converter also detected, you could either have JES2 fail the job during input phase (JCLERR=YES) and the job never was sent to conversion, or you could have JES2 ignore the errors (JCLERR=NO) and send the job to the conversion phase where the converter could detect them. Starting with z/OS V2R1, input phase still detects errors, but jobs are always queued to the conversion phase and the input errors are added to those found by conversion and reported in the same way. The message id associated with the message indicates where the error occurred.
In z/OS V2R2, JES2 ignores any specifications of the JCLERR= parameter. If an error on the JOB card is encountered during the INPUT phase, the job is sent to the converter for INPUT phase error message processing. You can no longer use JCLERR=YES to specify for the job to be failed under these conditions.
Table 1 provides more details about this migration action. Use this information to plan your changes to the system.
| Element or feature: | z/OS JES2. |
|---|---|
| When change was introduced: | z/OS V2R1. |
| Applies to migration from: | z/OS V1R13. |
| Timing: | Before the first IPL of z/OS V2R2. |
| Is the migration action required? | No, but recommended to keep your initialization deck clean of outdated and obsolete specifications. |
| Target system hardware requirements: | None. |
| Target system software requirements: | None. |
| Other system (coexistence or fallback) requirements: | None. |
| Restrictions: | None. |
| System impacts: | None. |
| Related IBM Health Checker for z/OS check: | None. |
Steps to take
- Check the JOBDEF statement in the JES2 initialization deck for JCLERR= specifications.
- Remove any JCLERR= specifications from the JOBDEF statement.
- With JES2 APAR OA41881, the output message $HASP835 from $DJOBDEF command no longer displayd the JCLERR=YES or JCLERR=NO value.
- With JES2 APAR OA46199, JES2 now checks the value of a NOTIFY=&SYSUID specification on a JOB statement. If &SYSUID translates to what JES2 considers to be a special local route code (values of the form Unnnn), JES2 generates a JCL error, causing the job to fail. Prior to the APAR, JES2 did not check whether the &SYSUID variable resolved to a special local route code. The specification was accepted, but ignored. No notification was generated and the error was not flagged.