Jcl

In JCL, the COND code is used to control the execution of job steps based on the completion codes of previous steps. Omitting the COND code in a subsequent step will lead to the execution of the step even when previous steps have failed. This can result in unnecessary resource usage, potential data corruption, and can make debugging more difficult.

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.

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.

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

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

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:

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

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

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

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.

This rule allows banning usage of certain statement parameters.

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

For example, this code:

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

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:

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.