```jcl Bad theme={null} //MYJOB JOB ,MSGLEVEL=1 //STEP1 EXEC PGM=FIRSTPGM //STEP2 EXEC PGM=SECONDPGM //STEP3 EXEC PGM=THIRDPGM ``` ```jcl Fix theme={null} //MYJOB JOB ,MSGLEVEL=1 //STEP1 EXEC PGM=FIRSTPGM //STEP2 EXEC PGM=SECONDPGM //STEP3 EXEC PGM=THIRDPGM,COND=(4,LT) ```

Having too many steps in a single job or procedure makes it harder to understand and maintain. It can also mean that it is aggregating too many responsibilities and should be split.

```jcl Bad theme={null} //MYJOB JOB //STEP01 EXEC PGM=DOTHING //STEP02 EXEC PGM=DOTHING //STEP03 EXEC PGM=DOTHING //STEP04 EXEC PGM=DOTHING <-- Noncompliant ``` ```jcl Fix theme={null} //MYJOB JOB //STEP01 EXEC PGM=DOTHING //STEP02 EXEC PGM=DOTHING //STEP03 EXEC PGM=DOTHING ```

Earlier versions of z/OS and certain installations do not support in-stream data in procedures. This can lead to inconsistencies within the codebase and compatibility issues.

```jcl Bad theme={null} //MYPROC PROC //STEP1 EXEC PGM=DOTHING //SYSIN DD * Input data /* // PEND //* Call procedure //CALLPRC EXEC PROC=MYPROC ``` ```jcl Fix theme={null} //MYPROC PROC //STEP1 EXEC PGM=DOTHING //SYSIN DD DUMMY // PEND //* Call procedure //CALLPRC EXEC PROC=MYPROC //STEP1.SYSIN DD * Input data /* ```

Shared naming conventions allow teams to collaborate efficiently. This rule checks that all job names match a provided regular expression.

```jcl Bad theme={null} //* Noncompliant //$JOB01 JOB ``` ```jcl Fix theme={null} //JOB01 JOB ```

JCL requires positional parameters to be specified before any keyword parameters. Having keyword parameters defined before a positional parameter will trigger a JCL error.

```jcl Bad theme={null} //MYJOB JOB CLASS=X,'TRIGGER' ``` ```jcl Fix theme={null} //MYJOB JOB 'TRIGGER',CLASS=X ```

Shared naming conventions allow teams to collaborate efficiently.

This rule raises an issue when a procedure name does not match a provided regular expression.

For example, with the default provided regular expression ^\[A-Z]\[A-Z0-9]\*\$, the procedure:

```jcl Bad theme={null} //* Noncompliant //$PROC1 PROC ``` ```jcl Fix theme={null} //PROC1 PROC ```

This rule allows banning the usage of certain data set names.

```jcl Bad theme={null} //EXEC PGM=SORT //SORTOUT DD DSN=AB.FOOBAR.XYZ ``` ```jcl Fix theme={null} //EXEC PGM=SORT //SORTOUT DD DSN=AB.FOOBAR.DEF ```

In JCL, it is expected for a PROC statement inside of a job stream to have a name.

```jcl Bad theme={null} //MYJOB JOB DXXX // PROC //STEP1 EXEC PGM=MYPGM // PEND ``` ```jcl Fix theme={null} //MYJOB JOB DXXX //TRPOC PROC //STEP1 EXEC PGM=MYPGM // PEND ```

This rule allows banning the use of some programs or procedures.

```jcl Bad theme={null} //EXEC PGM=SORT //EXEC PROC=SORT //EXEC SORT ``` ```jcl Fix theme={null} ```

The DD DATA statement continues reading in-stream data until it reaches the end delimiter (/\* or the delimiter specified by the DLM parameter) or until it hits the end-of-file. This can lead to other JCL statements being mistakenly included in the data stream.

```jcl Bad theme={null} //STEP1 EXEC PGM=DOTHING //SYSIN DD DATA //ALPHA JOB ,MSGLEVEL=(1,1) //NOPE EXEC PGM=IEFBR14 //STEP2 EXEC PGM=IEFBR14 //* End of file ``` ```jcl Fix theme={null} //STEP1 EXEC PGM=DOTHING //SYSIN DD DATA,DLM='><' //ALPHA JOB ,MSGLEVEL=(1,1) //NOPE EXEC PGM=IEFBR14 >< //STEP2 EXEC PGM=IEFBR14 //* End of file ```

This rule allows banning usage of certain statement parameters.

```jcl Bad theme={null} //OUTPUT1 INCLUDE MEMBER=FOOBAR ``` ```jcl Fix theme={null} //OUTPUT1 INCLUDE MEMBER=HELLO ```

This behavior is implicit and may lead to confusion or unexpected behavior.

For example, this code:

```jcl Bad theme={null} //MYDD DD DSN=TEST Some in-stream data // DD DSN=CONCAT-DD ``` ```jcl Fix theme={null} //MYDD DD DSN=TEST //SYSIN DD * Some in-stream data // DD DSN=CONCAT-DD ```

If a statement name exceeds the maximum size, it will trigger an error and prevent the program from being executed.

```jcl Bad theme={null} //MYEXPORTLAB EXPORT SYMLIST=(TEST) //MYEXECPROG.PROG EXEC PGM=ABC //EXEC.MYPROGRAM EXEC PGM=ABC ``` ```jcl Fix theme={null} //MYEXPORT EXPORT SYMLIST=(TEST) //MYEXECPR.PROG EXEC PGM=ABC //EXEC.MYPRG EXEC PGM=ABC ```

An empty \{operationName} is generally considered bad practice and can lead to confusion, readability, and maintenance issues. Empty \{operationName}s bring no functionality and are misleading to others as they might think the \{operationName} implementation fulfills a specific and identified requirement.

There are several reasons for a \{operationName} not to have a body:

It is an unintentional omission, and should be fixed to prevent an unexpected behavior in production.
It is not yet, or never will be, supported. In this case an exception should be thrown.
The method is an intentionally-blank override. In this case a nested comment should explain the reason for the blank override.

```jcl Bad theme={null} //MYPROC PROC // PEND ``` ```jcl Fix theme={null} //MYPROC PROC //RUN EXEC PGM=MYPROG // PEND ```

A typical code smell known as unused function parameters refers to parameters declared in a function but not used anywhere within the function’s body. While this might seem harmless at first glance, it can lead to confusion and potential errors in your code. Disregarding the values passed to such parameters, the function’s behavior will be the same, but the programmer’s intention won’t be clearly expressed anymore. Therefore, removing function parameters that are not being utilized is considered best practice.

```jcl Bad theme={null} //MYPROC PROC NAME1=SYS1,NAME2=SYS2,NAME3=SYS3 <--- Noncompliant //STEP1 EXEC PGM=DOTHING //THEFILE DD DSN=&N1..INFILE,DISP=SHR // DD DSN=&N2..INFILE,DISP=SHR // PEND ``` ```jcl Fix theme={null} //MYPROC PROC NAME1=SYS1,NAME2=SYS2 //STEP1 EXEC PGM=DOTHING //THEFILE DD DSN=&N1..INFILE,DISP=SHR // DD DSN=&N2..INFILE,DISP=SHR // PEND ```