Let’s continue our serie about the analysis of Cobol code, with the objective to demonstrate that it is simple and easy to initiate a process of evaluation of the quality of this Legacy code, without being a Mainframe expert.
You already have a platform of code analysis with Sonar and Jenkins. If this is not the case, an earlier serie of posts will explain you how to install these tools:
in our environement.
You are used to analyze Java code or .NET with this platform and you got the idea, or you were asked, to do the same for Cobol applications. The problem: you know nothing of the Mainframe world.
Don’t panic. Our two previous posts explained:
- What you need to know before to meet cobol-ers.
- What you need to ask in this meeting in order to prepare the delivery of Cobol source code.
Now is time to implement the process of analysis in our platform Sonar-Jenkins. Let’s play.
Validation of the delivery
The first step of our process is to verify that the delivery of the code is correct, according to the rules presented in our previous post. If you do not have Cobol code, Sonar offers you to download some files, in order to make your first steps, in this page: Sonar Project Examples.
This page lists a set of files for different technologies. Click on the link ‘Cobol’ and you will be redirected to a page with a button ‘Downloads’ which will allow you to retrieve a compressed file containing a directory ..\projects\languages\ with different source code samples, including one in a subdirectory ‘cobol’. Let’s have a look at it:
- A Cobol program ‘Custmnt2.cbl’ in a directory ‘src’.
- Some .cpy files in a directory ‘copybooks’.
Fine. The rules for delivery in our previous post are met:
- We will analyze a Cobol program and various Copy-books, delivered in a specific directory and with the extensions .cbl. and .cpy .
A quick glance in the Cobol program to verify that the code starts at position 7, which is the default setting in Sonar. No special configuration to do.
Delivery validated. We can proceed to the analysis.
Setting the analysis
We will perform our analysis with Jenkins, without presenting the details of its creation since you are already used to do this for your Java applications. Otherwise, here’s how to do it: Sonar – Cobol analysis with Jenkins.
In this example, the analysis was based on a configuration file ‘MyAppCobol.properties’ containing the different parameters to consider. This time, we will work without this file, specifying the settings directly into Jenkins. But these parameters, what are they?
In the directory ..\projects\languages\cobol\ with the source code sample that we downloaded, we can find also a file ‘sonar-project.properties’ with the configuration for a Cobol analysis.
We need to define some generic parameters such as the project name or version, of course the language and finally, the location of the Cobol files:
- sources=src
- sonar.cobol.copy.directories=copybooks
But something is missing: how Sonar can find these directories? I copied them in my analysis environment in C:\SRC\Mainframe\SonarCobol\Source. So I need to indicate to Sonar to search the source code from this directory. This is what I will do with the following parameters:
project.home=C:\SRC\Mainframe\SonarCobol\Source.
Here are all the parameters I used with Jenkins :
We can now start our analysis and verify the results.
Checking the log
Checking the log of the analysis is a required step in the process that we have implemented. Especially with Cobol source code. Why?
First to check the success of our analysis:
Then, even if everything went well, we can note the following warning:
The Cobol file we have analyzed has a call (at line 53) to a Copy-book DFHAID. But this file DFHAID.CPY is not present in the delivery.
This is something that will happen quite often. As we saw in the first post of this serie, the notion of application has not much sense in the Mainframe world. The Copy-books can be used by many other programs, and located in another module. So this does not mean that the delivery is incorrect.
But it is important to identify these missing Copy-books in order to inform the person in charge of the extraction and delivery of the code. For information only. This Copy-book does not necessarily pertain to the module analyzed, so do not expect a new delivery. But don’t be surprised if additional deliveries occur regularly, it is quite common when you analyze Cobol code.
You now can check in Sonar the results of our initial analysis:
And the presence of defects in the code:
We have seen all the steps in a process of analysis for Cobol source code, with Sonar and Jenkins:
- Validation of the delivery: check that it matches the rules decided during the kick-off meeting. This step is necessarily manual, but once delivery and analysis processes are automated, you should be able to avoid repeating this step. However, if you need to analyze 60 millions lines of Cobol code, you should take some time to complete this step.
- Setting the analysis: to be performed only the first time. However, you may have to modify your configuration when the setup of the delivery has changed, for example, when the source code directories have been modified. Check it while looking at the delivery.
- Checking the log:
- A new file with an incorrect syntax or not recognized by the parser of analysis can block it. Verify that the analysis is ‘Successfull’.
- Check for warnings and list missing Copy-books. Inform that these items are missing, but do not wait for another delivery to publish the results in the Sonar dashboard.
There is one – possibly – last step: do a presentation of these results with a code quality assessment and an action plan. This will be the subject of a future post.
This post is also available in Leer este articulo en castellano and Lire cet article en français.