> ## Documentation Index
> Fetch the complete documentation index at: https://docs.codeant.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Pli

> [accordion] END; statements should have the same indentation level as their matching PROCEDURE, SELECT, and DO statements
>
> 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.
>
> ```pli Bad theme={"theme":"css-variables"}
> 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 */
> ```
>
> ```pli Fix theme={"theme":"css-variables"}
> foo: proc options(main);
> declare i fixed decimal init (0);
>
> do i = 0 to 9;
> if i = 0 then do;
>   put list ('Initialization...');
>   put list ('i = 0');
> end; /* This end's alignment is not verified by this rule */
> end; /* Compliant */
> end; /* Compliant */
> ```

> [accordion] INONLY or NONASSIGNABLE parameters should not be written to
>
> 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.
>
> ```pli Bad theme={"theme":"css-variables"}
> 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;
> ```
>
> ```pli Fix theme={"theme":"css-variables"}
> ```

> [accordion] Parentheses should be used in factored variable declarations
>
> When multiple variables are `DECLARE`d 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.
>
> ```pli Bad theme={"theme":"css-variables"}
> DECLARE X,Y FIXED BIN(15);
> ```
>
> ```pli Fix theme={"theme":"css-variables"}
> DECLARE (X,Y) FIXED BIN(15);
> ```

> [accordion] String constants should not span multiple lines
>
> 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.
>
> ```pli Bad theme={"theme":"css-variables"}
> foo: proc options(main);
> put list ('Hello,      /* Noncompliant; trailing space is not readable and may be stripped */
> world');
> end;
> ```
>
> ```pli Fix theme={"theme":"css-variables"}
> foo: proc options(main);
> put list ('Hello, ' ||
> 'world');
> end;
> ```

> [accordion] VALUE should be preferred to STATIC with INIT
>
> Identifiers declared with [\`STATIC](https://www.ibm.com/support/knowledgecenter/en/SSY2V3_5.1.0/com.ibm.ent.pl1.zos.doc/lr/value.html) 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](https://www.ibm.com/docs/en/cics-ts/5.6?topic=applications-multithreading-reentrant-quasi-reentrant-threadsafe-programs). It is safer to declare the value as [a named constant](https://www.ibm.com/support/knowledgecenter/en/SSY2V3_5.1.0/com.ibm.ent.pl1.zos.doc/lr/value.html) (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:
>
> <ul>
>   <li>
>     CHARACTER/CHAR
>   </li>
>
>   <li>
>     BINARY/BIN
>   </li>
>
>   <li>
>     DECIMAL/DEC
>   </li>
>
>   <li>
>     FLOAT
>   </li>
>
>   <li>
>     POINTER/PTR
>   </li>
>
>   <li>
>     OFFSET
>   </li>
> </ul>
>
> ```pli Bad theme={"theme":"css-variables"}
> 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);
> ```
>
> ```pli Fix theme={"theme":"css-variables"}
> dcl returnCodeOk fixed bin(15) value (00);
> /* or */
> dcl actions char(05) value('12345');
> dcl actions_in char(01);
> ....
> valid_action = (verify(action_in, actions) = 0);
> ```

> [accordion] Comments should not be nested
>
> 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.
>
> ```pli Bad theme={"theme":"css-variables"}
> /*
> This is a comment block, for which the ending tag was omitted
> It may be difficult to figure out that the following line of code is actually commented
>
>
> variable = function_call();
> /* variable contains the result, this is not allowed, as it is an attempt to create an inner comment */
> ```
>
> ```pli Fix theme={"theme":"css-variables"}
> ```

> [accordion] The DCL abbreviation should not be used
>
> For better readability, it is preferable to use `DECLARE instead of the unpronounceable DCL` abbreviation.
>
> ```pli Bad theme={"theme":"css-variables"}
> foo: proc options(main);
> dcl i fixed decimal init (0); /* Noncompliant */
> end;
> ```
>
> ```pli Fix theme={"theme":"css-variables"}
> foo: proc options(main);
> declare i fixed decimal init (0); /* Compliant */
> end;
> ```

> [accordion] FIXED DECIMAL declarations should be defined with odd length
>
> 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.
>
> ```pli Bad theme={"theme":"css-variables"}
> declare total fixed dec(10);
> ```
>
> ```pli Fix theme={"theme":"css-variables"}
> declare total fixed dec(9);
> ```

> [accordion] IF / ELSE statements should use DO ... END structures
>
> 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:
>
> ```pli Bad theme={"theme":"css-variables"}
> foo: proc options(main);
> declare i fixed decimal init (0);
>
> if i = 42 then
> put list ('The answer is... '); /* Noncompliant */
> put list ('42!');
> end;
> ```
>
> ```pli Fix theme={"theme":"css-variables"}
> foo: proc options(main);
> declare i fixed decimal init (0);
>
> if i = 42 then do;
> put list ('The answer is... ');
> put list ('42!');
> end;
> end;
> ```

> [accordion] FIXED BIN should be preferred to INT
>
> `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`.
>
> ```pli Bad theme={"theme":"css-variables"}
> dcl i int(2) init (0);
> do i = 1 to 20 by 1;
> ...
> end;
> ```
>
> ```pli Fix theme={"theme":"css-variables"}
> dcl i fixed bin(31) init (0);
> do i = 1 to 20 by 1;
> ...
> end;
> ```

> [accordion] Keywords should not be used as variable names
>
> 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.
>
> ```pli Bad theme={"theme":"css-variables"}
> 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;
> ```
>
> ```pli Fix theme={"theme":"css-variables"}
> ```

> [accordion] DFHRESP should be used to check EIBRESP values
>
> 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.
>
> ```pli Bad theme={"theme":"css-variables"}
> if EIBRESP=36 then /* Noncompliant */
> end;
>
> if EIBRESP=MAPFAIL then /* Noncompliant */
> end;
>
> select (EIBRESP);
> when(36) ...;  /* Noncompliant */
> end;
> ```
>
> ```pli Fix theme={"theme":"css-variables"}
> if EIBRESP=DFHRESP(36) then
> end;
>
> if EIBRESP=DFHRESP(MAPFAIL) then
> end;
>
> select (EIBRESP);
> when(DFHRESP(MAPFAIL)) ...;
> end;
> ```

> [accordion] SELECT statements should end with OTHERWISE statements
>
> 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.
>
> ```pli Bad theme={"theme":"css-variables"}
> 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;
> ```
>
> ```pli Fix theme={"theme":"css-variables"}
> foo: proc options(main);
> declare i fixed decimal init (42);
>
> select (i); /* Compliant */
> when (0) put list ('i = 0');
> when (1) put list ('i = 1');
> otherwise; /* No operation */
> end;
>
> put list ('Continuation'); /* This statement will be executed */
> end;
> ```

> [accordion] Statements should be on separate lines
>
> 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}\[]
>
> ```pli Bad theme={"theme":"css-variables"}
> foo: proc options(main);
> declare i fixed decimal init(42); put list (i); /* Noncompliant - there are two statements */
> end;
> ```
>
> ```pli Fix theme={"theme":"css-variables"}
> foo: proc options(main);
> declare i fixed decimal init(42);
> put list (i);
> end;
> ```

> [accordion] Variable names should comply with a naming convention
>
> 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.
>
> ```pli Bad theme={"theme":"css-variables"}
> foo: proc options(main);
> declare bar# fixed decimal; /* Noncompliant */
> end;
> ```
>
> ```pli Fix theme={"theme":"css-variables"}
> foo: proc options(main);
> declare bar fixed decimal;  /* Compliant */
> end;
> ```

> [accordion] GO TO statements should not be used
>
> `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.
>
> ```pli Bad theme={"theme":"css-variables"}
> 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;
> ```
>
> ```pli Fix theme={"theme":"css-variables"}
> foo: proc options(main);
> declare i fixed decimal init (0);
>
>
> do i = 0 to 9;   /* Compliant */
> put list (i);
> end;
> end;
> ```

> [accordion] Procedure names should comply with a naming convention
>
> Shared coding conventions allow teams to collaborate efficiently. This rule checks that all function names match a provided regular expression.
>
> ```pli Bad theme={"theme":"css-variables"}
> foo#: proc options(main); /* Non-Compliant */
> end;
> ```
>
> ```pli Fix theme={"theme":"css-variables"}
> foo: proc options(main);  /* Compliant */
> end;
> ```


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.