# COBOL

COBOL analysis is available starting in [Enterprise Edition](https://www.sonarsource.com/plans-and-pricing/enterprise/) and is supported by [https://app.gitbook.com/s/6LPRABg3ubAJhpfR5K0Y/vs-code/getting-started/requirements/#cobol-analysis](https://app.gitbook.com/s/6LPRABg3ubAJhpfR5K0Y/vs-code/getting-started/requirements/#cobol-analysis "mention") and [https://app.gitbook.com/s/6LPRABg3ubAJhpfR5K0Y/eclipse/team-features/connected-mode](https://app.gitbook.com/s/6LPRABg3ubAJhpfR5K0Y/eclipse/team-features/connected-mode "mention") when running in Connected Mode.

### Language-specific properties <a href="#language-specific-properties" id="language-specific-properties"></a>

You can discover and update the COBOL-specific [analysis-parameters](https://docs.sonarsource.com/sonarqube-server/10.5/analyzing-source-code/analysis-parameters "mention") in: **Administration** > **General Settings** > **Languages** > **COBOL**

### Source code extraction <a href="#source-code-extraction" id="source-code-extraction"></a>

In order to analyze your source code with SonarQube you need to first extract it onto a filesystem. You can use your own tool or an open-source tool; SonarSource does not provide any connectors or source code extraction tools.

### Advanced configuration <a href="#advanced-configuration" id="advanced-configuration"></a>

#### Defining source code format <a href="#defining-source-code-format" id="defining-source-code-format"></a>

The supported source code formats are:

* Fixed format
* Free format
* Variable format

To set the format, go to **Administration > General Settings > COBOL** and set the "Source format" property.

The fixed format has three main areas:

```css-79elbk
Area1 | Area2                                           | Area3
000100* MY COMMENT
000100 IDENTIFICATION DIVISION.
000200 PROGRAM-ID. HELLOWORLD.                          *xxx
100000 PROCEDURE DIVISION.                              *yyy
100100
100200 START.
100400 DISPLAY "HELLO COBOL !" LINE 42 POSITION 12.
100500 STOP RUN.
```

Areas #1 and #3 contain non-significant characters. Area #2 contains the source code. The first character of Area #2 is the Indicator Area, which has a special meaning (for instance `*` means that the line is a comment line, `D` means that the line is only taken into account in debug mode, etc.).

The free format:

```css-79elbk
Area1 | Area2
      * MY COMMENT
       IDENTIFICATION DIVISION.
         PROGRAM-ID. HELLOWORLD.
       PROCEDURE DIVISION.
         DISPLAY "HELLO COBOL !" LINE 42 POSITION 12.
         STOP RUN.
```

The Indicator Area that has a special meaning (for instance `*` means that the line is a comment line, `D` means that the line is only taken into account in debug mode, etc.) is located at column 0. The size of the source code area is not limited.

Variable format is also supported: it’s similar to the fixed format but without Area #3.

#### Defining COBOL dialect <a href="#defining-cobol-dialect" id="defining-cobol-dialect"></a>

Go to **Administration > General Settings > COBOL** and set the "Dialect" property.

COBOL analysis supports the following dialects:

* `bull-gcos-cobol`
* `hp-tandem-cobol`
* `ibm-os/vs-cobol`
* `ibm-ile-cobol`
* `ibm-cobol/ii`
* `ibm-cobol/400`
* `ibm-enterprise-cobol`
* `microfocus-cobol`
* `microfocus-acucobol-gt-cobol`
* `opencobol/cobol-it`

#### Making copybooks available to the analysis <a href="#making-copybooks-available-to-the-analysis" id="making-copybooks-available-to-the-analysis"></a>

Copybooks are, by definition, COBOL files that are not syntactically valid by themselves. However, copybooks are usually needed to properly parse COBOL programs. Thus, paths to the copybooks must be listed through the `sonar.cobol.copy.directories` property.

#### Raising issues against copybooks <a href="#raising-issues-against-copybooks" id="raising-issues-against-copybooks"></a>

To have copybooks imported into a project, and issues logged against them, the copybook directories must be added to `sonar.sources` AND the copybook file suffixes must be added to `sonar.cobol.file.suffixes`. E.G.:

```css-79elbk
sonar.sources=cobol,copy1,commonCopy
sonar.cobol.file.suffixes=cbl,cpy
sonar.cobol.copy.suffixes=cpy
sonar.cobol.copy.directories=copy1,commonCopy
```

In the case where a number of projects share a common set of copybooks, it may not be desirable to increment each project’s technical debt with the issues from the common copybooks. In such cases, the directory holding the common copybooks should be listed in `sonar.cobol.copy.directories` (as before) but left out of sonar.sources, E.G.:

```css-79elbk
sonar.sources=cobol,copy1
sonar.cobol.file.suffixes=cbl,cpy
sonar.cobol.copy.suffixes=cpy
sonar.cobol.copy.directories=copy1,commonCopy
```

#### Analyzing without file suffixes <a href="#analyzing-without-file-suffixes" id="analyzing-without-file-suffixes"></a>

Note that it is possible to analyze a COBOL project without file suffixes. To do this, remove the two suffix-related properties from your configuration and substitute the following setting for `sonar.lang.patterns.cobol`:

`sonar.lang.patterns.cobol=**/*`

#### Switching off Issues <a href="#switching-off-issues" id="switching-off-issues"></a>

There are three ways to switch off issues:

* Flagging issues as [issues](https://docs.sonarsource.com/sonarqube-server/10.5/user-guide/issues "mention")
* [analysis-scope](https://docs.sonarsource.com/sonarqube-server/10.5/project-administration/analysis-scope "mention")
* Using the `NOSONAR` tag. To switch off an issue, place the `NOSONAR` tag in a comment line located right before the line containing the issue. Example:

```css-79elbk
* NOSONAR, in such case call to GO TO is tolerated, blabla...
 GO TO MY_PARAGRAPH.
```

#### ACUCOBOL-GT source code control directives <a href="#acucobolgt-source-code-control-directives" id="acucobolgt-source-code-control-directives"></a>

COBOL analysis supports the ACUCOBOL-GT’s Source Code Control directives. This mechanism allows you to conditionally modify the program at compile time by excluding or including lines. This can be used to maintain different versions of the program, perhaps to support different machine environments.

The `-Si` (include) flag controls the actions of the source code control system. It must be followed by an argument that specifies a pattern that the compiler will search for in the Identification Area of each source line. If the pattern is found, then the line will be included in the source program, even if it is a comment line. However, if the pattern is immediately preceded by an exclamation point, then the line will be excluded from the source (i.e., commented out).

The `-Sx` (exclude) flag works the same way except that its meaning is reversed (lines with the pattern will be commented out and lines with a preceding exclamation point will be included).

For example, suppose a program is being maintained for both the UNIX and VMS environments. The following piece of code is in the program:

```css-79elbk
MOVE "SYS$HELP:HELPFILE" TO FILE-NAME.  VMS
*MOVE "/etc/helpfile" TO FILE-NAME.     UNX
OPEN INPUT HELP-FILE.
```

This program fragment is ready to be compiled for the VMS system. If a UNIX version is desired, then the following flags will correct the source during compilation:

```css-79elbk
-Si UNX -Sx VMS
```

Please consult the ACUCOBOL-GT documentation for more on the mechanism.

There are two ways in SonarQube to specify the list of ACUCOBOL-GT flags to be used in order to preprocess the source code. The first option is to define a list of global flags which will be used to preprocess all source files. This can be done in the **Administration > General Settings > COBOL > Preprocessor**.

The second option is to provide a list of relative paths (with help of the ‘sonar.cobol.acucobol.preprocessor.directives.directories’ property) which contain the list of flags to be used for each COBOL source file. Let’s take a simple example. If a file ‘MY*PROGRAM.CBL’ is going to be processed, the SonarQube ACUCOBOL-GT preprocessor, will try to find a file ‘MY*PROGRAM.CMD’. If this file is found, then the flags contained in this file is going to be used to preprocess the program ‘MY*PROGRAM.CBL’. If the file ‘MY*PROGRAM.CMD’ doesn’t exist, then the preprocess will use the content of the file ‘DEFAULT.CMD’ if exists.

#### Microfocus compiler constants <a href="#microfocus-compiler-constants" id="microfocus-compiler-constants"></a>

If your code takes advantage of conditional compilation features provided by Microfocus, you may have to configure compiler constants for your analysis.

For example, if your COBOL code looks like this:

```css-79elbk
       IDENTIFICATION DIVISION.
      $IF myconstant DEFINED
       PROGRAM-ID. x.
      $END
      $IF otherconstant DEFINED
       PROGRAM-ID. y.
      $END
```

Go to Project **Administration > General Settings > COBOL** and declare each constant by name with associated value.

Defining the constant via `sonar.cobol.compilationConstant.[constant name here]` in sonar-project.properties is deprecated since version 4.5 of the COBOL analyzer.

```css-79elbk
sonar.cobol.compilationConstant.myconstant=myvalue // deprecated
```

### Database Catalog (DB2) <a href="#database-catalog" id="database-catalog"></a>

COBOL analysis offers rules which target embedded SQL statements and require the analyzer to have knowledge of the database catalog (E.G. the primary key column(s) of a given table). These rules will raise issues only if the database catalog is provided to the analysis. For the moment, this is available only for IBM DB2 (z/OS) catalogs, and the catalog must be provided via a set of CSV ("Comma Separated Values") files.

These rules rely on two analysis properties:

|                                         |                                                                                  |
| --------------------------------------- | -------------------------------------------------------------------------------- |
| **Key**                                 | **Description**                                                                  |
| `sonar.cobol.sql.catalog.csv.path`      | relative path of the directory containing CSV files for the database catalog     |
| `sonar.cobol.sql.catalog.defaultSchema` | comma-separated list of default database schemas used in embedded SQL statements |

`sonar.cobol.sql.catalog.csv.path` should define a directory that contains 8 CSV files. Each of these CSV files contains data for a specific DB2 catalog table and is named after it. The following table lists the required files and their respective mandatory columns. Additional columns may be listed, but will be ignored:

|                        |                     |                                                                                        |
| ---------------------- | ------------------- | -------------------------------------------------------------------------------------- |
| **Table**              | **File name**       | **Required Columns**                                                                   |
| `SYSIBM.SYSCOLUMNS`    | `SYSCOLUMNS.csv`    | `TBNAME`,`TBCREATOR`,`NAME`,`PARTKEY_COLSEQ`,`DEFAULT`,`NULLS`,`DEFAULTVALUE`          |
| `SYSIBM.SYSINDEXES`    | `SYSINDEXES.csv`    | `NAME`,`CREATOR`,`TBNAME`,`TBCREATOR`,`UNIQUERULE`,`INDEXTYPE`                         |
| `SYSIBM.SYSINDEXPART`  | `SYSINDEXPART.csv`  | `IXNAME`,`IXCREATOR`,`PARTITION`                                                       |
| `SYSIBM.SYSKEYS`       | `SYSKEYS.csv`       | `IXNAME`,`IXCREATOR`,`COLNAME`,`COLSEQ`                                                |
| `SYSIBM.SYSSYNONYMS`   | `SYSSYNONYMS.csv`   | `NAME`,`CREATOR`,`TBNAME`,`TBCREATOR`                                                  |
| `SYSIBM.SYSTABLES`     | `SYSTABLES.csv`     | `NAME`,`CREATOR`,`TYPE`,`PARTKEYCOLNUM`,`TSNAME`,`DBNAME`,`TBNAME`,`TBCREATOR`,`CARDF` |
| `SYSIBM.SYSTABLESPACE` | `SYSTABLESPACE.csv` | `NAME`,`DBNAME`,`PARTITIONS`                                                           |
| `SYSIBM.SYSVIEWS`      | `SYSVIEWS.csv`      | `NAME`,`CREATOR`,`STATEMENT`                                                           |

The CSV format is the following:

* Each file must be named for the table it represents.
* The first line must contain the exact names of the columns.
* The order of the columns is not meaningful.
* Fields are comma-delimited.
* If a field contains a comma, then its value must be surrounded by double quotes (").
* If a field that is surrounded by double quotes contains a double quote character ("), then this character must be doubled ("").

Example for `SYSVIEWS.csv`:

```css-79elbk
CREATOR,NAME,STATEMENT
USER1,VIEW1,select x from table1
USER1,VIEW2,"select x, y from table1"
USER1,VIEW3,"select x, ""y"" from table1"
```

The `UNLOAD` DB2 utility with the `DELIMITED` option should produce the required files except for the column names on the first line.

### Custom rules <a href="#custom-rules" id="custom-rules"></a>

#### Overview <a href="#overview" id="overview"></a>

The COBOL analyzer parses the source code, creates an Abstract Syntax Tree (AST) and then walks through the entire tree. A coding rule can subscribe to be notified every time a node of a certain type is visited.

As soon as the coding rule is notified, it can navigate the tree around the node and raise issues if necessary.

#### Writing a plugin <a href="#writing-a-plugin" id="writing-a-plugin"></a>

Writing new COBOL coding rules is a six-step process:

* Create a standard SonarQube plugin.
* Attach this plugin to the SonarQube COBOL analyzer (see the `pom.xml` file of the provided sample plugin project).
* Create as many custom COBOL coding rules as required by extending `com.sonarsource.api.ast.CobolCheck` and add them to the previous repository.
* Generate the SonarQube plugin (jar file).
* Place this jar file in the `<sonarqubeHome>/extensions/plugins` directory.
* Restart the SonarQube server.

#### Plugin project sample <a href="#plugin-project-sample" id="plugin-project-sample"></a>

To get started, clone the sample plugin project and follow the steps below:

* Install Maven
* Build the plugin by running `mvn install` from the project directory. This will generate a SonarQube plugin jar file in the target directory.
* Add your newly created jar into the `<sonarqubeHome>/extensions/plugins` directory
* Restart the SonarQube server

If you now look at the COBOL quality profiles, you will find the new coding rule ("Sample check"). Don’t forget to activate it. Run an analysis of a COBOL project, and you will find that an issue was logged at line 5 on every file.

#### Subscribing to a NodeType <a href="#subscribing-to-a-nodetype" id="subscribing-to-a-nodetype"></a>

Very often when writing a coding rule, you will want to subscribe to a NodeType. A NodeType can be either a rule of the grammar or a keyword of the language. As an example, here is the code of the implementation of the "Avoid using Merge statement" coding rule:

```css-79elbk
public class MergeStatementUsageCheck extends CobolCheck {

  public void init() {
    subscribeTo(getCobolGrammar().mergeStatement);
  }

  public void visitNode(AstNode node) {
    reportIssue("Avoid using MERGE statement.").on(node);
  }
}
```

Note that CICS and SQL grammars can be accessed using `getCicsGrammar()` and `getSqlGrammar()`.

#### Coding rule lifecycle <a href="#coding-rule-lifecycle" id="coding-rule-lifecycle"></a>

A coding rule can optionally override six methods inherited from the CobolCheck class. Those methods are called sequentially in the following order:

* `public void init() {…}`: This method is called only once and should be used to subscribe to one or more NodeType(s).
* `public void visitFile(AstNode astNode) {…}`: This method is called on each file before starting the parsing.
* `public void visitNode(AstNode astNode) {…}`: This method is called when an AstNode matches a subscribed NodeType (see Subscribing to a NodeType) and before analyzing its content.
* `public void leaveNode(AstNode astNode) {…}`: This method is called when an AstNode matches a desired NodeType (see Subscribing to a NodeType) and after analyzing its content.
* `public void leaveFile(AstNode astNode) {…}`: This method is called before exiting a file.
* `public void destroy() {…}`: This method is called before shutting down the coding rule.
* The `reportIssue(…)` method, used to log an issue, should be called only inside the `visitFile(…)`, `visitNode(…)`, `leaveNode(…)` and `leaveFile(…)` methods. Indeed, the file context isn’t known when the `init()` and `destroy()` methods are called, so the issue can’t be associated to a file.

More advanced features are documented in the API [Javadoc](https://javadocs.sonarsource.org/?prefix=cobol/apidocs).

#### Navigating the AST (Abstract Syntax Tree) with the SSLR COBOL toolkit <a href="#navigating-the-ast-abstract-syntax-tree-with-the-sslr-cobol-toolkit" id="navigating-the-ast-abstract-syntax-tree-with-the-sslr-cobol-toolkit"></a>

When starting to write a new COBOL coding rule, the main difficulty is to understand the COBOL AST in order to know which NodeType(s) need to be visited. This can be achieved by using the [SSLR COBOL Toolkit](https://binaries.sonarsource.com/?prefix=CommercialDistribution/sslr-cobol-toolkit/), a Swing application that enables loading a COBOL file and displaying its representation as an Abstract Syntax Tree.

Each node in the AST is a COBOL grammar rule and each leaf in the AST is a COBOL token. Let’s say you want to visit the node `ifStatement`. In this case, the `init()` method of your COBOL coding rule must contain the following statement: `subscribeTo(getCobolGrammar().ifStatement);`

#### Configuring plugins for analyzer loading optimization <a href="#configuring-plugins-for-analyzer-loading-optimization" id="configuring-plugins-for-analyzer-loading-optimization"></a>

By default, the loading of analyzers is optimized (see [improving-performance](https://docs.sonarsource.com/sonarqube-server/10.5/instance-administration/improving-performance "mention")), SonarQube will only download analyzers and third-party plugins for the detected languages before running an analysis.&#x20;

When creating custom plugins, to prevent errors when projects are analyzed, you must use the `requiredForLanguages` property in your plugin’s `pom.xml` file to specify the languages your plugin supports. Without this property, your plugin will be executed unconditionally during analysis, even when its language-specific dependencies are unavailable. See [plugin-basics](https://docs.sonarsource.com/sonarqube-server/10.5/extension-guide/developing-a-plugin/plugin-basics "mention") for details on this behavior and the `requiredForLanguages` property.

```css-79elbk
<configuration>
   [...]
   <requiredForLanguages>COBOL</requiredForLanguages>
</configuration>
```

#### API changes <a href="#api-changes" id="api-changes"></a>

*Since 4.0* A new API is available to write the rules but also to implement the tests.

Custom rules should now extend `CobolCheck` (`CobolAstCheck` is deprecated) and issues should be logged using the `reportIssue(...)` method.\
Tests on custom rules should now use `CobolCheckVerifier`: the assertions about issues should now be added as comments inside COBOL test files.\
Custom rules should be listed in an implementation of `CobolCheckRepository` (`CobolAstCheckRepository` is now deprecated) and metadata should be loaded by implementing `RulesDefinitionExtension`.\
You can now store your custom rules into a dedicated rule repository by implementing SonarQube’s `RulesDefinition`: in that case, you don’t need to implement `RulesDefinitionExtension`.

{% hint style="warning" %}
For users who already have custom rules in production: existing issues will be closed and re-opened because the internal keys of the rules are changing. If you wrote a custom plugin against version 3.x of the COBOL analyzer, it should still be compatible at runtime with version 4.0.
{% endhint %}

To migrate to the new API ([full example on GitHub](https://github.com/SonarSource/sonar-custom-rules-examples/pull/14)):

* First, migrate tests without modifying rule classes. That mainly requires moving assertions from java test classes to comments inside test COBOL files ([see an example on GitHub](https://github.com/SonarSource/sonar-custom-rules-examples/commit/c95b6a84b6fd1efc832a46cd5e1101ee51e6268e)).
* Update check classes to replace the calls to deprecated methods with the new methods which create issues ([see an example on GitHub](https://github.com/SonarSource/sonar-custom-rules-examples/commit/d6f6ef7457d99e31990fa64b5ff9cc566775af96)).
* Implement `CobolRulesDefinitionExtension` and `CobolCheckRepository`, remove the class extending `CobolAstCheckRepository` ([see an example on GitHub](https://github.com/SonarSource/sonar-custom-rules-examples/commit/ea15f07ce79366a08fee5b60e9a93c32a4625918)).
* Update check classes to extend `CobolCheck` instead of `CobolAstCheck` to stop using deprecated APIs ([see an example on GitHub](https://github.com/SonarSource/sonar-custom-rules-examples/commit/8e1d746900f5411e9700fea04700cd804e45e034)).

To move your custom rules to a dedicated rule repository, see [an example on GitHub](https://github.com/SonarSource/sonar-custom-rules-examples/commit/16ad89c4172c259f15bce56edcd09dd5b489eacd).

### Related pages <a href="#related-pages" id="related-pages"></a>

* [adding-coding-rules](https://docs.sonarsource.com/sonarqube-server/10.5/extension-guide/adding-coding-rules "mention")
