Cobol
File-Codes should comply with a naming convention
File-Codes should comply with a naming convention
Shared coding conventions allow teams to collaborate efficiently. This rule checks that file-code names conform to a specified regular expression.
Cursors should not be closed inside loops
Cursors should not be closed inside loops
You should avoid closing a CURSOR inside a PERFORM statement, because it could impact performance or lead to unexpected behavior if the cursor was not opened in the same loop.
Sections and paragraphs should not perform more than one SQL operation
Sections and paragraphs should not perform more than one SQL operation
To improve source code readability and reusability, SQL operations should be located in dedicated procedures (sections or paragraphs) and should not be mixed with other SQL requests.
Ending words should be aligned with what they close
Ending words should be aligned with what they close
Aligning opening and ending words of statements is critical to keep the code readable, especially when blocks contain nested statements.
For IF statements, this rule also checks the alignment of the ELSE word.
For fixed size sequential files, FD section should contain clause BLOCK CONTAINS 0 RECORDS
For fixed size sequential files, FD section should contain clause BLOCK CONTAINS 0 RECORDS
TO BE TRANSLATED :
L’objectif est de laisser la détermination taille des blocs physiques de fichier au niveau des JCL plutôt que de l’imposer par programme. Cela permet d’optimiser cette taille sans avoir à recompiler/livrer le programme
Que doit-on contrôler?
La présence de BLOC CONTAINS 0 RECORDS (ou BLOC 0, BLOC CONTAINS 0, etc)
Obsolete keywords should not be used
Obsolete keywords should not be used
To ensure future code portability, obsolete keywords should not be used. The following keywords were declared obsolete in the COBOL ANSI-85 standard and removed in the ISO/IEC 1989:2002 standard:
Paragraphs: `AUTHOR, INSTALLATION, DATE-WRITTEN, DATE-COMPILED, SECURITY
Clauses: DATA RECORD(S), LABEL RECORD(S), MEMORY SIZE, MULTIPLE FILE (TAPE), RERUN, VALUE OF, CODE SEGMENT-LIMIT
Statements: ALTER, ENTER, STOP literal, GO TO without an argument
Phrases: REVERSED phrase of the OPEN statement
Special registers: DEBUG-ITEM
Sections: Debugging sections
Declarative: USE FOR DEBUGGING
The following keywords were declared obsolete in the ISO/IEC 1989:2002 standard:
Phrase: DEBUGGING MODE
Clause: PADDING CHARACTER`
Copybooks should be used to share data structures, not procedural logic
Copybooks should be used to share data structures, not procedural logic
GO TO statements should not transfer control outside their modules
GO TO statements should not transfer control outside their modules
GO TO should not be used to transfer control outside the current module, because any implied EXIT points will then be ignored. A module is either a section, a paragraph, or a set of paragraphs called with the PERFORM … THRU … statement.
ACCEPT statements should be avoided
ACCEPT statements should be avoided
The ACCEPT statement causes data entered at the console or provided by the operating system to be made available to the program in a specific data element, without any validation or sanitization.
Thus, if this data is accepted in a particular format and used by other procedures, the system is vulnerable to attack or malfunction.
Cursors should not be opened inside loops
Cursors should not be opened inside loops
You should avoid opening a cursor inside a PERFORM statement because doing so could impact performance, or lead to unexpected behavior if the the closing of the cursor is not defined in the same loop.
Text conversion functions should not be used
Text conversion functions should not be used
According to the IBM documentation,
To aid in migrations to IBM Enterprise COBOL 5.x, this rule raises an issue when UPPER-CASE, LOWER-CASE, or NATIONAL-OF` is used.
DISPLAY should not be used
DISPLAY should not be used
The DISPLAY statement outputs data to standard out or some other destination and could reveal sensitive information. Therefore, it should be avoided.
Conditions should not use too many distinct data items
Conditions should not use too many distinct data items
The number of distinct data items used in a condition (IF, EVALUATE, …) should not exceed a defined threshold.
OCCURS 1 should not be used on data items
OCCURS 1 should not be used on data items
The use of an array structure is useless when the array only has one element. Using an array structure anyway can impact performance and decrease the readability of the source code.
Level 77 should not be used
Level 77 should not be used
Level 77 identifies data items that are not subdivisions of other items, and that have no subdivisions. They are atomic by declaration. To make future subdivision possible, level 01 should be used instead of level 77.
Sections should be documented
Sections should be documented
Every section should be commented to explain its goal and how it works. This comment can be placed either just before or just after the section label.
PERFORM calls should not be nested too deeply
PERFORM calls should not be nested too deeply
Call stacks containing lot of PERFORM statements is a key ingredient for making what’s known as “Spaghetti code”.
Such code is hard to read, refactor and therefore maintain.
This rule supports both sections and paragraphs.
SQL statements should not use CAST(... AS CHAR/VARCHAR)
SQL statements should not use CAST(... AS CHAR/VARCHAR)
CAST(… AS CHAR/VARCHAR) can be a source of incompatibilities between database versions: the behavior of CAST may not be the same depending on the version of the database system. Such incompatibilities can cause unexpected output from applications that CAST decimal data to CHAR or VARCHAR, it’s therefore best to avoid using CAST(… AS CHAR/VARCHAR).
Cursors should not be declared inside loops
Cursors should not be declared inside loops
You should avoid declaring a cursor inside a PERFORM statement because doing so could impact performance. It could also lead to unexpected behavior if the opening and closing of the cursor are not defined in the same loop.
PERFORM calls should not be recursive
PERFORM calls should not be recursive
Most COBOL environments do not support recursive PERFORM calls, since they can cause unpredictable results. This rule raises an issue when recursive PERFORM calls are used.
Selects should include null indicators for nullable columns
Selects should include null indicators for nullable columns
When a `SELECT returns null from a nullable column, the relevant host variable isn’t updated; it simply retains its previous value. The only way you’ll ever know the column value was null is to check the relevant null indicator included in the SELECT for a negative (null) value.
This rule raises an issue when a SELECT omits a null` indicator for a nullable column.
Note that this rule raises issues only when a database catalog is provided during the SonarQube analysis.
CICS DUMP and DUMP TRANSACTION should not be used
CICS DUMP and DUMP TRANSACTION should not be used
The use of DUMP and DUMP TRANSACTION, while potentially useful during development and debugging, could expose system information to attackers and should not be used in production.
BINARY variables should be used to declare variable-length table sizes
BINARY variables should be used to declare variable-length table sizes
When the size of a variable-length table is DEPENDING ON a non-BINARY/COMP variable, use of that table is inefficient because a conversion must be done every time the table is used.
Error conditions should not be ignored
Error conditions should not be ignored
When error conditions occur, it is usually a bad idea to simply ignore them. Instead, it is better to handle them properly, or at least to log them.
Data item levels should be incremented consistently
Data item levels should be incremented consistently
Shared coding conventions allow teams to collaborate efficiently. This rule checks that data item levels are incremented according to the configured values.
Using the default configuration:
Default column values should not be set explicitly in inserts
Default column values should not be set explicitly in inserts
There’s no point in including the default value of a column in an insert statement. It simply clutters the code to no additional benefit.
Note that this rule raises issues only when a database catalog is provided during the SonarQube analysis.
Collapsible IF statements should be merged
Collapsible IF statements should be merged
Merging collapsible IF statements increases the code’s readability.
Code like
Data items should be initialized with data of the correct type
Data items should be initialized with data of the correct type
Initializing a data item with a value of the wrong type will lead to runtime errors. The rule checks that numeric data items are not initialized with alphanumeric/alphabetic values and that alphanumeric /alphabetic data items are not initialized with numeric values.
SQL CURSOR should always be declared with the WITH HOLD clause
SQL CURSOR should always be declared with the WITH HOLD clause
Pour des traitements effectuant des COMMITs réguliers et afin de conserver la position du CURSOR lors de lecture ou de mises à jour, il est impératif que les DECLARE CURSOR soient codés avec l’option WITH HOLD
The return codes of CICS commands with RESP or NOHANDLE conditions should be tested
The return codes of CICS commands with RESP or NOHANDLE conditions should be tested
After calling CICS commands with the RESP or NOHANDLE options, the return code should be tested.
Conditional variables should not be compared with literals
Conditional variables should not be compared with literals
88-level variables, also known as “condition name” variables, each have a name, a value or set of values, and a “parent” variable. Those parent variables are called “conditional variables”.
Each 88-level variable can be seen as a short-cut conditional for testing the value of the parent: IF MY-88 will intrinsically return true if the parent value matches MY-88’s value, and false if it does not.
Thus, testing a conditional variable against a literal value is redundant and confusing. Just use the 88-levels instead.
Paragraphs should be documented
Paragraphs should be documented
Every paragraph should be commented to explain its goal and how it works. This comment can be placed either just before or just after the paragraph label. Moreover paragraphs used to close a module can be left uncommented.
GOBACK should be used instead of STOP RUN
GOBACK should be used instead of STOP RUN
When using some transaction managers like IBM IMS, each COBOL program is in fact considered a sub-program by the transaction manager. The GOBACK statement returns control to the transaction manager, but using STOP RUN might cause unpredictable results or abnormal termination.
Track uses of forbidden statements
Track uses of forbidden statements
This rule allows banning certain statements.
Identical expressions should not be used on both sides of a binary operator
Identical expressions should not be used on both sides of a binary operator
Using the same value on either side of a binary operator is almost always a mistake. In the case of logical operators, it is either a copy/paste error and therefore a bug, or it is simply wasted code, and should be simplified. In the case of arithmetic operators, having the same value on both sides of an operator yields predictable results, and should be simplified.
Conditions in related IF/ELSE IF statements and WHEN clauses in EVALUATE statements should not have the same condition
Conditions in related IF/ELSE IF statements and WHEN clauses in EVALUATE statements should not have the same condition
WITH DEBUGGING MODE should not be used
WITH DEBUGGING MODE should not be used
Debug statements (ones with ‘D’ or ‘d’ in the indicator area) should not be executed in production, but the WITH DEBUGGING MODE clause activates all debug lines, which could expose sensitive information to attackers. Therefore the WITH DEBUGGING MODE clause should be removed.
GO TO DEPENDING ON should not be used
GO TO DEPENDING ON should not be used
This rule is a more precise version of S1308 preventing the use of GO TO. The flow of a program is already complicated to understand with simple GO TOs. It’s even worse when a GO TO is executed conditionally like this is the case with GO TO DEPENDING ON.
Limited dependence should be placed on operator precedence
Limited dependence should be placed on operator precedence
The rules of operator precedence are complicated and can lead to errors. For this reason, parentheses should be used for clarification in complex statements.
This rule raises an issue when more than the allowed number of non-like operators are used in a statement without parentheses to make execution order explicit.
CALL programs should be specified dynamically
CALL programs should be specified dynamically
Because statically-called programs must be relinked before they reflect changes in the code, it makes sense to prefer dynamic calls instead. Further, since statically-called programs are included in the caller’s load module, those modules could require more main storage than if the calls were dynamic, and the called programs could reside in memory multiple times - one for each caller.
While static calls are faster, their other disadvantages make dynamic calls the preferred method. Thus, this rule raises an issue when the program to CALL is hard-coded, rather than specified in a variable.
Condition names should be named for their conditional variables
Condition names should be named for their conditional variables
88-level variables, also known as “condition name” variables, represent possible values of the “conditional variables” they’re tied to. Because a condition name can be used to test the value of its conditional variable without any other contextual references to the conditional variable being tested, it makes the code easier to understand if the name of the 88-level variable references its conditional variable.
This rule raises an issue when the name of an 88-level variable does not start with the first characters of the name of its conditional variable.
Open files should be closed explicitly
Open files should be closed explicitly
Even though closing an open file isn’t always mandatory (for instance when stopping the execution of a COBOL program with the STOP RUN statement), it’s good coding practice to always explicitly close any open files. This rule checks that for every OPEN statement there is a corresponding CLOSE statement somewhere in the program.
Paragraphs and statements should be indented consistently
Paragraphs and statements should be indented consistently
Paragraphs, sections and statements must be correctly indented for better code readability.
FOR READ ONLY or FOR UPDATE should be specified for DB2 cursors
FOR READ ONLY or FOR UPDATE should be specified for DB2 cursors
Explicitly defining a cursor as read-only can improve performance by avoiding table locking. This allows other SQL requests to execute in parallel. Therefore when a cursor will only be used to read data, without modifying anything, the `FOR READ ONLY clause or its synonyn, FOR FETCH ONLY, should be used.
Conversely when a cursor will modify data, that too should be specified using the FOR UPDATE clause.
In short, it’s better to always explicitly define the purpose of the cursor with help of the FOR READ ONLY, FOR FETCH ONLY or FOR UPDATE` clauses.
Queries that use FETCH FIRST should have an ORDER BY
Queries that use FETCH FIRST should have an ORDER BY
Using FETCH FIRST n ROWS ONLY in a SELECT without ordering the results from which the “n first” results are chosen will return a seemingly random set of rows, and is surely a mistake.
Arithmetic expressions and scalar functions should not be used in WHERE conditions
Arithmetic expressions and scalar functions should not be used in WHERE conditions
Using a scalar function or an arithmetic expression in a WHERE condition can prevent the database from using indexes on the relevant column(s), and could therefore lead to performance issues.
EXIT PROGRAM should be the last statement of a sequence
EXIT PROGRAM should be the last statement of a sequence
There should not be any statements after EXIT PROGRAM. Such statements cannot be reached, and are therefore dead code. Dead code makes a program more complex and therefore more difficult to maintain.
The OS/VS NOTE statement should not be used
The OS/VS NOTE statement should not be used
OS/VS COBOL accepted the NOTE statement, but IBM Enterprise COBOL does not. Therefore all NOTE statements should be replaced by standard comment lines.
Logical files should follow a naming convention
Logical files should follow a naming convention
Shared coding conventions allow teams to collaborate efficiently. This rule checks that logical file names conform to a provided regular expression.
Paragraphs should not contain a PERFORM to themselves
Paragraphs should not contain a PERFORM to themselves
Using recursion with paragraphs is not a problem in itself but it potentially exposes the software to endless loop. This is the case when there is no condition to end the recursion or when this condition is always false.
This rule raises an issue when a paragraph contains a PERFORM to itself to warn the developer that there is a risk of endless loop. This rule can also be used to fully prevent recursion to be used.
PERFORM statements should not be deeply nested
PERFORM statements should not be deeply nested
TODO
Nested SQL SELECT statements should not be used
Nested SQL SELECT statements should not be used
Having several levels of nested SQL SELECT statements makes the code difficult to read and should therefore be avoided.
Control flow statements should not be nested too deeply
Control flow statements should not be nested too deeply
Nested control flow statements IF, PERFORM, EVALUATE and others are often key ingredients in creating
what’s known as “Spaghetti code”. This code smell can make your program difficult to understand and maintain.
When numerous control structures are placed inside one another, the code becomes a tangled, complex web. This significantly reduces the code’s readability and maintainability, and it also complicates the testing process.
Fetches should not select more columns than their cursors
Fetches should not select more columns than their cursors
The number of columns in a FETCH statement should match the number actually selected in the relevant cursor. Use more columns in the FETCH than the cursor, and you’ve got a data problem, because the variables you expect to be updated by the cursor are never actually touched, and neither are their null indicators. Instead, they retain whatever value they had before the fetch. Meaning you’re operating with bad data.
Packed numeric fields should be defined with odd length
Packed numeric fields should be defined with odd length
The storage of a packed numeric field is most efficient when you code an odd number of digits in the PICTURE description, so that the leftmost byte is fully used. Packed-decimal items are handled as fixed-point numbers for arithmetic purposes.
SELECT statements should not lead to full table scans
SELECT statements should not lead to full table scans
There can’t be any good reason to do a full table scan on large database tables due to the cost of such operation and the scalability issue that might raise. This rule raises an issue when a SELECT statement doesn’t use at least one indexed column in its WHERE clause.
Note That this rule raises issues only when a database catalog is provided during the SonarQube analysis.
The OS/VS ON statement should not be used
The OS/VS ON statement should not be used
OS/VS COBOL accepted the ON statement, but IBM Enterprise COBOL does not accept it anymore. The ON statement allows the selective execution of statements it contains. Similar functions are provided in Enterprise COBOL by EVALUATE and IF
OCCURS DEPENDING ON should not be used
OCCURS DEPENDING ON should not be used
OCCURS DEPENDING ON clauses are complicated to use correctly and do not provide any benefits with regard to memory consumption. It is best to avoid them.
Mass insert operation with the SQL statement INSERT / SELECT should not be done
Mass insert operation with the SQL statement INSERT / SELECT should not be done
L’instruction INSERT/SELECT correspond à des mises à jour de masse sans possibilité de prendre des commits intermédiaires. Ce qui est très dommageable en terme d’accès concurrents sur des environnements 24/24 7/7.
OCCURS DEPENDING ON should be used with a minimum value
OCCURS DEPENDING ON should be used with a minimum value
Some COBOL compilers such as IBM one will assume that the minimum value of `OCCURS DEPENDING ON is 1 but nothing is enforcing that and this behaviour can change or be different when using another compiler.
Setting the minimum value of OCCURS DEPENDING ON` makes the code more readable, and less dependent on compiler.
When calling a subprogram, the data item containing the name of the subprogram to be called should not be programmatically updated
When calling a subprogram, the data item containing the name of the subprogram to be called should not be programmatically updated
Defining a subprogram to be called at runtime is possible but ill-advised. This extremely powerful feature can quite easily be misused, and even when used correctly, it highly increases the overall complexity of the program, and makes it impossible before runtime to know exactly what will be executed. Therefore defining the subprogram to be called at runtime is a feature that should be avoided.
Data value clauses should not be used in linkage sections
Data value clauses should not be used in linkage sections
Using a data value clause in the LINKAGE SECTION can lead to unexpected behavior at runtime.
Data used in a LINKAGE should be defined in a COPYBOOK
Data used in a LINKAGE should be defined in a COPYBOOK
The `LINKAGE section describes data made available from another program through the CALL statement. The data structure defined in a LINKAGE section should be located in a COPYBOOK. Otherwise, at runtime multiple COBOL programs may try to share data structures which are not similar.
First level data items can also be defined in the main program as long as there are no structural pieces of information attached to this first level like the length, the format, and so on.
This rule raises an issue only on the first invalid data item of a LINKAGE` section.
OPEN should not be used inside a loop
OPEN should not be used inside a loop
Using the OPEN file statement is costly, and therefore be avoided inside loops. Instead, the file can be saved into a buffer to increase performance.
INSERT statements should not set the values of identity columns
INSERT statements should not set the values of identity columns
While it is possible to manually set a primary key value, doing so almost guarantees a key clash at some point. Instead, primary key values should be set by (in descending order of desirability):
automatic generation by the database via a column definition such as `PROD_ID INT NOT NULL GENERATED ALWAYS AS IDENTITY (START WITH 1, INCREMENT BY 1, NO CACHE)
the Generate_Unique() function
a value pulled directly from a sequence, like so: nextval for SEQ_PRODUCT
This rule raises an issue when an INSERT` statement assigns values to identity columns that are configured to always generate their values.
Note That this rule raises issues only when a database catalog is provided during the SonarQube analysis.
Binary variables should be used for table subscript access
Binary variables should be used for table subscript access
In general, the clause INDEXED BY should be used whenever possible when handling COBOL tables. If it’s not possible, then avoid using a numeric display variable to access the table’s elements. Instead, use a BINARY/COMP variable, which the processor can handle more efficiently.
Untrusted data should be escaped before being saved into HTTP or JSP classes
Untrusted data should be escaped before being saved into HTTP or JSP classes
In cross-site scripting attacks, attackers insert attack scripts into your pages. Because no system is fool-proof, it may not be enough to screen the data that’s submitted to an application. You should also escape any content sent to the user so that any malicious code that may have escaped your input screening is neutralized. Specifically, the characters crucial to forming HTML must be escaped:
||turn||into||
|&|&|
|<|<|
|>|>|
|“|"|
|’|'|
|/|/|
This rule raises an issue for anything sent to WEB.
Paragraphs should follow a naming convention
Paragraphs should follow a naming convention
Shared coding conventions allow teams to collaborate efficiently. This rule checks that paragraph names match a provided regular expression.
EXEC SQL INCLUDE statements should be closed with periods
EXEC SQL INCLUDE statements should be closed with periods
COBOL programs that include EXEC SQL INCLUDE statements must be pre-processed with an IBM DB2 precompiler or coprocessor before compilation. The precompiler does not require a period after the closing END-EXEC, but the coprocessor does. For portability, a period should always be used.
UPDATE and DELETE statements should not impact multiple rows
UPDATE and DELETE statements should not impact multiple rows
Since databases don’t offer “Are you sure?” dialogs, it’s best to be very certain of what you’re changing before you do it. `UPDATE and DELETE statements that don’t precisely limit their effects to single rows risk changing more than was intended. That’s why they should be reviewed carefully.
This rule raises an issue when an UPDATE or DELETE statement’s WHERE clause does not use precisely either a unique index or all parts of the table’s primary key. That includes both cases where they are omitted in whole or in part, and when they are used but could still describe multiple rows. E.G. WHERE AGE = 34, and WHERE TABLE_ID > 0 AND TABLE_ID < 40`.
Note That this rule raises issues only when a database catalog is provided during the SonarQube analysis.
Variables of different numeric formats should not be compared
Variables of different numeric formats should not be compared
The comparison of numeric values of different formats is inefficient. For instance, comparing a `COMP-3 with a COMP-4 causes a performance drag because conversions are required under the covers before the comparison.
This rule raises an issue when variables with different USAGE` clauses, or different numbers of decimal places are compared.
DISPLAY UPON CONSOLE should not be used
DISPLAY UPON CONSOLE should not be used
The rule S1279 (“DISPLAY” should not be used) is fully preventing the usage of the DISPLAY statement whereas in same cases it may be useful to output some data to SYSOUT. However, the output of a call to DISPLAY UPON CONSOLE is unlikely to be viewed by someone because the output is displayed on the console and nowadays no one is in front of the console to see if something is happening.
Strings should only be moved to variables large enough to hold them without truncation
Strings should only be moved to variables large enough to hold them without truncation
Moving a large string into a small field will result in data truncation with data lost from the right side of the string.
Copybooks should not contain keywords relating to the nature or structure of a program
Copybooks should not contain keywords relating to the nature or structure of a program
Copybooks should be used only to share data definitions or logic. The following keywords relate to the nature or structure of a COBOL program, and should be defined directly in the source code of the COBOL program:
`IDENTIFICATION DIVISION.
PROGRAM-ID xxxxxxxx.
AUTHOR. yyyyyyyyyyy.
INSTALLATION. zzzzzz.
DATE-WRITTEN. zzzzzz.
DATE-COMPILED. zzzzzz.
ENVIRONNEMENT DIVISION.
CONFIGURATION SECTION.
SOURCE-COMPUTER. xxxxxx.
OBJECT-COMPUTER. xxxxxx.
SPECIAL-NAMES. DECIMAL-POINT IS COMMA.
I-O CONTROL.
FILE-CONTROL.
DATA DIVISION.
FILE SECTION.
WORKING-STORAGE SECTION.
SCREEN.
REPORT.
INPUT-OUTPUT SECTION.
LINKAGE SECTION.
PROCEDURE DIVISION.`
SQL UPDATE statements should not change primary key values
SQL UPDATE statements should not change primary key values
A primary key uniquely identifies a row in a database table, and should be considered immutable. Primary key values may be used in foreign keys in other tables, as well as in external systems. Changing such a value, even with the best of motivations, is likely to wreak havoc on the system’s data integrity and potentially across other systems as well.
Note That this rule raises issues only when a database catalog is provided during the SonarQube analysis.
READ statements should have an AT END or an INVALID KEY clause if FILE-STATUS is not defined
READ statements should have an AT END or an INVALID KEY clause if FILE-STATUS is not defined
When the FILE STATUS is not specified on a file, any read operations on the file should handle the “AT END” or “INVALID KEY” conditions.
Fetches should use all of the columns selected in their cursors
Fetches should use all of the columns selected in their cursors
There’s no point in selecting columns in a cursor that aren’t actually referenced in the relevant FETCH statement. Instead, either pare down the cursor to select only what you actually need, or FETCH the other columns.
Programs should begin with titles
Programs should begin with titles
Program/file names offer only very limited space for indicating program function, which is why you should take advantage of the ability to specify a program `TITLE. Omitting the TITLE statement will result in a default, uncommunicative TITLE value being printed at the top of each page of the source listing. Instead, you should write an expressive title that gives a clear impression of the program’s function.
This rule raises an issue when a there is no TITLE before the IDENTIFICATION DIVISION. Ideally, TITLE` will be the first line of a program, but it cannot be placed before compiler options.
0 RECORDS should be specified for BLOCK CONTAINS
0 RECORDS should be specified for BLOCK CONTAINS
The number of RECORDS or CHARACTERS specified in a BLOCK CONTAINS clause is used to determine block size. Specify 10 RECORDS, and the block will be exactly 10x the length of the record. But that may not be the right size, depending on the environment. Instead, it is considered a best practice to specify 0 RECORDS, so the block size will be calculated automatically.
The second procedure of a PERFORM THRU statement should be defined after the first procedure
The second procedure of a PERFORM THRU statement should be defined after the first procedure
If the second procedure of a PERFORM THRU is not defined after the first one, the source code is semantically incorrect and the program doesn’t behave as expected.
Unused data item blocks should be removed
Unused data item blocks should be removed
An unused data item block is dead code. Such data item blocks should be removed to increase the maintainability of the program.
All branches in a conditional structure should not have exactly the same implementation
All branches in a conditional structure should not have exactly the same implementation
Having all branches of an EVALUATE or IF chain with the same implementation indicates a problem.
In the following code:
Unused TABLE declarations should be removed
Unused TABLE declarations should be removed
If a SQL TABLE is declared but not used in the program, it can be considered dead code and should therefore be removed. This will improve maintainability because developers will not wonder what the variable is used for.
Alphanumeric values should not be moved to numeric fields
Alphanumeric values should not be moved to numeric fields
An alphanumeric value should not be moved to a numeric field. Because alphanumeric values are stored differently than numeric values, simply moving the bits from one field to the other will yield strange results at best, and crashes at worst.
Instead, NUMVAL should be used to explicitly convert the alphanumeric value to a numeric one.
Track uses of disallowed modules
Track uses of disallowed modules
This rule allows banning some modules.
COPY SUPPRESS should not be used
COPY SUPPRESS should not be used
COPY … SUPPRESS suppresses the inclusion of the copybook contents from the source listing, making it very difficult to gain a complete understanding of what’s happening in the code. This could hinder both maintenance and debugging.
Data item declarations should be aligned
Data item declarations should be aligned
Shared coding conventions allow teams to collaborate efficiently. For maximum readability, this rule checks that the levels, names and PICTURE clauses for all items of the same level and which are subordinate to the same item start in the same column.
Math should only be performed on computational variables
Math should only be performed on computational variables
Performing math on variables that are declared - explicitly or implicitly - as `DISPLAY or NATIONAL is much less efficient than on COMPUTATIONAL, COMP, or BINARY variables. That’s because COMP variables, for instance, are defined for binary storage, which makes math on them more efficient. That’s why values that are going to be used primarily for math should be declared with a math type. When math isn’t a primary use, it may not make sense to change the declared type, but MOVEing the value to a COMP variable and performing the math on it instead would.
It is important to note however, that COMPUTATIONAL, COMP, and BINARY` formats should be used with caution if the variable will be passed to other systems which may not use the same storage format.
On SQL SELECT statements, clauses WITH RR/RS/CS should not be used
On SQL SELECT statements, clauses WITH RR/RS/CS should not be used
Afin de ne pas perturber via la programmation, les paramètres positionnés sur les BIND PACKAGE pour des environnements de type 24/24 7/7, il est important de vérifier que les ordres de SELECT simples ou dans les DECLARE CURSOR que les mots clés WITH RR, WITH RS er WITH CS ne soient pas positionnés. Le seul mot clé accepté est WITH UR.
S’assurer que sur les ordres de SELECT (simple ou mis dans des DECLARE CURSOR) que les mots clés WITH RR, WITH RS er WITH CS ne soient pas positionnés.
Implicit casting should not be used in WHERE clauses
Implicit casting should not be used in WHERE clauses
There is such a thing as software that’s too helpful, and that’s the case with DB2’s implicit casting of host variables used in `WHERE clauses. If for instance you compare a varchar column with the value of a numeric host variable, starting with version 10, DB2 will silently convert the numeric value to a string - at a potentially huge performance cost.
This rule raises an issue when the type of a variable used with a SQL WHERE` clause does not match the underlying type of the column to which it is compared.
Data items should never be accessed using more than one OF clause
Data items should never be accessed using more than one OF clause
Using more than one OF clause to access a data item can quickly decrease the readability of the source code. Either some OF clauses are optional and should be removed, or there are too many intersections between several data structures and those intersections should be removed.
Sections should end with an empty paragraph
Sections should end with an empty paragraph
It is fairly normal for COBOL development teams to decide to work either with sections or with paragraphs and to make this choice a standard.
When sections are used, it is also normal to define another standard: “End every section definition with an empty paragraph definition, or a paragraph containing only a terminating statement”.
This empty paragraph can then be jumped to with a `GO TO statement to stop the execution of a section.
Accepted terminating statements in the otherwise-empty ending paragraph are: EXIT, EXIT PROGRAM, STOP RUN, and GO BACK`.
Host variable formats should match the types of the relevant columns
Host variable formats should match the types of the relevant columns
Host variables are used for passing data back and forth from the database to a COBOL program via SQL. In order to keep that transmission clear and free of errors, the format of each host variable should match its corresponding database column type.
This rule raises an issue when column and corresponding host variable don’t match in terms of numeric vs character data, and when the host variable is smaller than the column width.
Unused condition names should be removed
Unused condition names should be removed
88-level variables, also known as “condition name” variables, represent possible values of the “conditional variables” they’re tied to. An unused “condition name” variable is dead code. Such variables should be removed to increase the maintainability of the program.
STOP RUN or GOBACK should be the last statement of a sequence
STOP RUN or GOBACK should be the last statement of a sequence
Any statement after a STOP RUN or GOBACK is unreachable and therefore dead code which should be removed.
FILE STATUS should be checked after IO operations when it is available
FILE STATUS should be checked after IO operations when it is available
When a FILE STATUS is declared on a file, it should be tested immediately after IO operations.
Paragraphs should not be left uncommented
Paragraphs should not be left uncommented
Every paragraph should be commented to explain its goal and how it works. This comment can be placed either just before or just after the paragraph label. Moreover paragraphs used to close a module can be left uncommented.
TO keywords should be aligned in a sequence of MOVE statements
TO keywords should be aligned in a sequence of MOVE statements
Aligning common keywords in a series of statements makes the code easier to read. therefore, it is better to align the TO keywords in a series of successive MOVE statements.
Paragraphs used by a PERFORM statement should not contain GO TO
Paragraphs used by a PERFORM statement should not contain GO TO
PERFORM is used to execute a paragraph located somewhere in the program and then, once executed, the execution flow will continue on the line following the PERFORM statement. This is the expected behaviour that can be broken if a GO TO is added in the called paragraph. When mixing PERFORM and GO TO you can quickly be lost on the execution flow and finally don’t get the one you expect. For this reason, calling PERFORM with paragraphs that used GO TO should be avoided.
Paragraphs should not be redefined
Paragraphs should not be redefined
Having two paragraphs with the same name in the same section or in no section at all is bad practice. At best, each copy contains the same code, and the redefinition is simply useless, duplicated code. At worst, the paragraphs contain different logic, potentially leading to confusion and unexpected results as a programmer who was aware of the first paragraph definition inadvertently invokes the second. For these reasons, paragraphs with duplicated names should be either removed or renamed.
System dates should not be used directly: ACCEPT DATE or CURRENT DATE
System dates should not be used directly: ACCEPT DATE or CURRENT DATE
TODO
Permettre une gestion standardisée de la gestion des dates dans les traitements. Tous les traitements doivent utiliser le module MGDATR03 s’ils ont besoin d’utiliser la date du jour.
Disallowed characters should not be used in identifiers
Disallowed characters should not be used in identifiers
Portability issues may restrict which characters should be used in an identifier.
This rule checks identifier names against a regular expression of disallowed characters. Due to a technical limitation, the COBOL analyzer is not able for the time-being to differentiate lowercase from uppercase characters.
First level data items should follow a naming convention
First level data items should follow a naming convention
Shared coding conventions allow teams to collaborate efficiently. This rule checks that first level data item names match a provided regular expression.
EVALUATE structures should end with WHEN OTHERS clauses
EVALUATE structures should end with WHEN OTHERS clauses
The EVALUATE statement allows implementing case structures in Cobol. Each case is managed by a WHEN phrase activated by specific test of a variable.The WHEN OTHER phrase allows managing all the cases which have not been taken into account by the previous WHEN phrases. If the variable to be tested contains a new value that is not currently managed then the absence of the WHEN OTHER phrase will lead a situation in which no process will be performed for this value and the program may have uncontrolled or undefined behavior.
Sections should not be empty
Sections should not be empty
There is no good reason to keep an empty and therefore valueless section. Such sections should be removed.
Numbers should only be moved to variables large enough to hold them without truncation
Numbers should only be moved to variables large enough to hold them without truncation
Moving a large number into a small field will result in data truncation. Generally, numeric values are truncated from the left. However, in the case of floating point values, when the target field has too little precision to hold the value being moved to it, decimals will be truncated (not rounded!) from the right.
In any case, data loss is always the result when too-large values are moved to too-small fields.
COMMAREA length should be specified in CICS Link and CICS Xctl commands
COMMAREA length should be specified in CICS Link and CICS Xctl commands
When using CICS XCTL or CICS LINK, it is a bad practice not to specify the length of the communication area.
Closable statements with nested statements should be closed
Closable statements with nested statements should be closed
When a closable statement contains nested statements, it can quickly become difficult to see which statements are nested and which are not. That’s why ending a list of nested statements with END-${STATEMENT-NAME} is advised.
OS/VS EXHIBIT should not be used
OS/VS EXHIBIT should not be used
OS/VS COBOL accepted the EXHIBIT statement, but IBM Enterprise COBOL does not. With IBM Enterprise COBOL, the DISPLAY statement must be used instead.
Binary search should be used for large tables
Binary search should be used for large tables
The binary algorithm used by `SEARCH ALL is far more efficient for large tables than the one used by SEARCH. While it’s not always possible to use SEARCH ALL, it should be the preferred algorithm.
This rule raises an issue when tables with more than the specified number of possible entries are searched using SEARCH`.
Comments should not contain passwords
Comments should not contain passwords
Statements should be on separate lines
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}[]
Expressions should not be too complex
Expressions should not be too complex
The complexity of an expression is defined by the number of &&, || and condition ? ifTrue : ifFalse operators it contains.
A single expression’s complexity should not become too high to keep the code readable.
DDL statements should not be used
DDL statements should not be used
Allowing an application to dynamically change the structure of a database at runtime is very dangerous because the application can become unstable under unexpected conditions. Best practices dictate that applications only manipulate data.
Delivering code in production with debug features activated is security-sensitive
Delivering code in production with debug features activated is security-sensitive
Development tools and frameworks usually have options to make debugging easier for developers. Although these features are useful during development, they should never be enabled for applications deployed in production. Debug instructions or error messages can leak detailed information about the system, like the application’s path or file names.
Magic numbers should not be used
Magic numbers should not be used
Magic numbers make the code more complex to understand as it requires the reader to have knowledge about the global context to understand the number itself. Their usage may seem obvious when writing the code, but it may not be the case for another developer or later once the context faded away. -1, 0, and 1 are not considered magic numbers.
SQL EXISTS subqueries should not be used
SQL EXISTS subqueries should not be used
SQL queries that use EXISTS subqueries are inefficient because the subquery is re-run for every row in the outer query’s table. There are more efficient ways to write most queries, ways that do not use the EXISTS condition.
Having SQL SELECT statements without WHERE conditions is security-sensitive
Having SQL SELECT statements without WHERE conditions is security-sensitive
Although the WHERE condition is optional in a SELECT statement, for performance and security reasons, a WHERE clause should always be specified to prevent reading the whole table.
Track lack of copyright and license headers
Track lack of copyright and license headers
Each source file should start with a header stating file ownership and the license which must be used to distribute the application.
This rule must be fed with the header text that is expected at the beginning of every file.
Redundant pairs of parentheses should be removed
Redundant pairs of parentheses should be removed
The use of parentheses, even those not required to enforce a desired order of operations, can clarify the intent behind a piece of code. However, redundant pairs of parentheses could be misleading and should be removed.
Conditionally executed code should be reachable
Conditionally executed code should be reachable
Conditional expressions which are always true or false can lead to unreachable code.
Variables should not be self-assigned
Variables should not be self-assigned
There is no reason to re-assign a variable to itself. Either this statement is redundant and should be removed, or the re-assignment is a mistake and some other value or variable was intended for the assignment instead.
String literals should not be duplicated
String literals should not be duplicated
Duplicated string literals make the process of refactoring complex and error-prone, as any change would need to be propagated on all occurrences.
Columns to be read with a SELECT statement should be clearly defined
Columns to be read with a SELECT statement should be clearly defined
SELECT * should be avoided because it releases control of the returned columns and could therefore lead to errors and potentially to performance issues.
Track uses of TODO tags
Track uses of TODO tags
NULL should not be compared directly
NULL should not be compared directly
In a Zen-like manner, “NULL” is never equal to anything, even itself. Therefore comparisons using equality operators will always return `False, even when the value actually IS NULL.
For that reason, comparison operators should never be used to make comparisons with NULL; IS NULL and IS NOT NULL should be used instead. This extends as well to empty string (""), which is equivalent to NULL` for some database engines.
Hard-coded credentials are security-sensitive
Hard-coded credentials are security-sensitive
Because it is easy to extract strings from an application source code or binary, credentials should not be hard-coded. This is particularly true for applications that are distributed or that are open-source.
In the past, it has led to the following vulnerabilities:
Credentials should be stored outside of the code in a configuration file, a database, or a management service for secrets.
This rule flags instances of hard-coded credentials used in database and LDAP connections. It looks for hard-coded credentials in connection strings, and for variable names that match any of the patterns from the provided list.
It’s recommended to customize the configuration of this rule with additional credential words such as “oauthToken”, “secret”, …
Boolean expressions should not be gratuitous
Boolean expressions should not be gratuitous
Control flow constructs like if-statements allow the programmer to direct the flow of a program depending on a boolean expression. However, if the condition is always true or always false, only one of the branches will ever be executed. In that case, the control flow construct and the condition no longer serve a purpose; they become gratuitous.
SQL statements should not contain dynamic clauses
SQL statements should not contain dynamic clauses
SQL statements should not contain dynamic clauses
Two branches in a conditional structure should not have exactly the same implementation
Two branches in a conditional structure should not have exactly the same implementation
Having two WHEN clauses in the same EVALUATE statement or two branches in the same IF structure with the same implementation is at best duplicate code, and at worst a coding error.
Credentials should never be included in comments. Doing so means that anyone who has access to the code also has access to the database.
This rule flags each instance of “password” in a comment