Get Started
- CodeAnt AI
- Control Center
- Pull Request Review
- IDE
- Compliance
- Anti-Patterns
- Code Governance
- Infrastructure Security Database
- Application Security Database
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.
foo: proc options(main);
declare i fixed decimal init (0);
do i = 0 to 9;
if i = 0 then /* The do was forgotten here */
put list ('Initialization...');
put list ('i = 0');
end; /* Non-Compliant - should be aligned with the DO statement */
end; /* Non-Compliant - should be aligned with the PROCEDURE statement */
/* The procedure's end seems to be missing */
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.
sum: PROC(a, b);
dcl a fixed dec(15,2) NONASSIGNABLE;
dcl b fixed dec(15,2) NONASSIGNABLE;
a = a + b; /* Noncompliant */
return (a);
end;
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.
DECLARE X,Y FIXED BIN(15);
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.
foo: proc options(main);
put list ('Hello, /* Noncompliant; trailing space is not readable and may be stripped */
world');
end;
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:
CHARACTER/CHAR
BINARY/BIN
DECIMAL/DEC
FLOAT
POINTER/PTR
OFFSET
dcl returnCodeOk fixed bin(15) static init (00); /* Noncompliant */
/* or */
dcl actions char(05) init('12345') static; /* Noncompliant */
dcl actions_in char(01);
....
valid_action = (verify(action_in, actions) = 0);
For better readability, it is preferable to use DECLARE instead of the unpronounceable DCL abbreviation.
foo: proc options(main);
dcl i fixed decimal init (0); /* Noncompliant */
end;
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.
declare total fixed dec(10);
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:
foo: proc options(main);
declare i fixed decimal init (0);
if i = 42 then
put list ('The answer is... '); /* Noncompliant */
put list ('42!');
end;
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.
dcl i int(2) init (0);
do i = 1 to 20 by 1;
...
end;
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.
foo: proc options(main);
declare if fixed decimal init (42); /* Non-Compliant */
if if = 42 then do; /* Cconfusing */
put list ('if = 42');
end;
go to goto; /* Confusing */
goto: /* Non-Compliant */
;
end;
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 EIBRESP=36 then /* Noncompliant */
end;
if EIBRESP=MAPFAIL then /* Noncompliant */
end;
select (EIBRESP);
when(36) ...; /* Noncompliant */
end;
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.
foo: proc options(main);
declare i fixed decimal init (42);
select (i); /* Non-Compliant - SELECT without OTHERWISE statement */
when (0) put list ('i = 0');
when (1) put list ('i = 1');
end;
put list ('Continuation'); /* This statement will not be executed */
end;
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}[]
foo: proc options(main);
declare i fixed decimal init(42); put list (i); /* Noncompliant - there are two statements */
end;
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.
foo: proc options(main);
declare bar# fixed decimal; /* Noncompliant */
end;
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.
foo: proc options(main);
declare i fixed decimal init (0);
loopLabel:
put list (i);
i = i + 1;
if i < 10 then go to loopLabel; /* Noncompliant - usage of the GO TO statement */
end;
Shared coding conventions allow teams to collaborate efficiently. This rule checks that all function names match a provided regular expression.
foo#: proc options(main); /* Non-Compliant */
end;
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.