Pli

For better readability, `END statements must have the same indentation level as their matching opening PROCEDURE, SELECT, and DO statements.

This rule does not verify the alignment of the compound statements DO … END; (type 1) and BEGIN … END;. They are mostly used together with the IF and ON` statements and are subject to different indentation rules.

Parameters that are declared as “INONLY” or “NONASSIGNABLE” are flagged as non-assignable by the compiler.

This rule raises an issue when a non-assignable parameter is written to.

When multiple variables are DECLAREd in a single statement, parentheses must be used around the variable list to ensure the variable attributes in the statement are applied to all the variables in the declaration. Without parentheses, the attributes are applied only to the last variable in the list.

String literals written on multiple lines should not be used, especially since the new line characters are not part of the string anyway. The concatenation operator || should be used instead. Moreover, if trailing comments are present, they can be automatically removed by text editors and lead to unexpected results.

Identifiers declared with `STATIC and INIT are initialized only once and may be later modified. Modifying such an identifier will fail at runtime when a CICS application is executed as reentrant. It is safer to declare the value as a named constant (using the keyword VALUE) because any modification will be reported at compilation time.

This rule raises an issue when an identifier is declared as STATIC with INIT or INITIAL` and has one of the following types:

Defining a nested single-line comment within a multi-line comment invites errors. It may lead a developer to wrongly think that the lines located after the single-line comment are not part of the comment.

For better readability, it is preferable to use DECLARE instead of the unpronounceable DCL abbreviation.

The storage of a FIXED DECIMAL is most efficient when you use an odd number of digits, so that the leftmost byte is fully used.

While not technically incorrect, the omission of `DO … END can be misleading and may lead to the introduction of errors during maintenance.

In the following example, the two commands seem to be attached to the IF statement, but only the first one is, and put list (‘42!‘)` will always be executed:

fixed bin(31) type has been optimized to run faster than int especially when used in loops. For this reason, fixed bin(31) should be preferred to int.

PL/I, unlike many other programming languages, does not reserve any word’s usage.

This implies that it is syntaxically valid to use the keyword IF as variable names for instance.

But doing so results in confusing code which is hard to read, especially in editors without proper PL/I syntax highlighting support.

Whenever a CICS command is used with a `NOHANDE or RESP option, the default CICS exception handling is disabled. The correct approach then is to ensure that every possible exception is handled correctly directly in the code and to do this, you need to examine the RESP value or the EIBRESP field value.

It is possible to compare the RESP and EIBRESP field values to hard-coded numbers or variables containing numeric values; however, this makes the code difficult to read and maintain. It is recommended to use instead the DFHRESP built-in translator function, which enables the use of the equivalent symbolic values.

This rule raises an issue when the EIBRESP field is compared directly to a variable or hard-coded numeric value that is not wrapped in the DFHRESP function.

This rule does not handle RESP` values for now.

If every WHEN test of a SELECT statement fails, an ERROR condition is raised if the OTHERWISE statement is omitted. This can lead to the unexpected termination of the program.

Putting multiple statements on a single line lowers the code readability and makes debugging the code more complex.

Unresolved directive in <stdin> - include::{noncompliant}[]

Write one statement per line to improve readability.

Unresolved directive in <stdin> - include::{compliant}[]

Sharing some naming conventions is a key point to make it possible for a team to efficiently collaborate. This rule allows to check that all variable names match a provided regular expression.

goto is an unstructured control flow statement. It makes code less readable and maintainable. Structured control flow statements such as if, for, while, continue or break should be used instead.

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