A rule is known or it is not. A ‘best practice’ is applied or is not. But if it is not applied, is it because it is not applicable?
You must present the results of your initial Cobol analysis and of course, you want them to be as most relevant as possible in order to prove their value to the project teams, providers, stakeholders, etc.
This requires defining a Quality model – a set of rules and levels of severity – that allows the rapid identification of the most costly and dangerous ‘bad practices’. Obviously that would be a failure if you point at a violation to a ‘best practice’ which is not one – as for example, the use of SQL code (see our last post).
What are the rules you can use or not? What critical thresholds should you choose? How to adjust the Quality model in a Sonar Quality profile for your Cobol applications?
We will show in this post how to set up your own Quality model, using a Sonar View and a very useful widget.
Deliver the value
The analysis we did in our last post) display two different types of values when looking at the number of violations of a rule:
- A very large number, up to several thousands or tens of thousands: the rule is probably not applicable and you should probably exclude it from your Quality Model.
- A very low number: the rule is known and applied, but you can never completely avoid the lack of attention from developers, and these few flaws could generate very serious consequences for end users.
However, there are specific exceptions to Cobol standards, as the ‘IF without END-IF’ very old ‘bad practice’: current developers can not be held responsible for it. We have seen that in this case, we can reduce the severity of this rule.
We can also offer to enhance the severity of some other rules: for example, upgrade the rule prohibiting the SORT statement from ‘Critical’ to ‘Blocker’. This is where a code analysis tool shows all its benefits: in the automatic detection of a limited number of serious or critical defects that can be easily corrected. This is one of the best ways to transform your analysis results into value for your audience.
To build a model that maximizes the value of your quality measurements, you must make the right choices without knowing the ‘best practices’ in use. To discover these, you can:
- Ask the list of programming standards and other Cobol standards. Most often, there is not any document that describes them, and when there is, it wil be mostly outdated and unusable.
- List all the Cobol rules and organize meetings with the Cobol teams: you may spend much time explaining the rules that are not applicable and that you might not explain well if your knowledge of the Mainframe world is limited.
- Review the results of your analyzes to identify the rules that are applicable, and propose a Quality model.
Views plugin
We’ll create a view that includes all our Cobol analyzes, with the Views plugin. Simply log into Admin, and go to the menu ‘Configuration’ and ‘Views’.
I created a ‘Cobol View’ to which I assigned projects already analyzed. I must relaunch at least one of these projects to see my Cobol View in the Sonar dashboard. Here are the results:
As you can see, here we have a good interesting sample: applications of different sizes, representing over 5 million lines of Cobol with over 3.3 million lines of code in 6,714 files. Only one application is not in red, all others have a degree of compliance of Cobol standards close to an absolute zero.
The widget ‘Most violated rules’
As we are connected as ‘Admin’, we can add a widget that will be very useful.
Select the menu ‘Configure widgets’, then the following widget to your dashboard: the list of rules with the most violations.
The ‘Edit’ menu of the widget allows us to change its settings, for instance to show the 15 rules most frequently violated:
‘Save’ button to save these settings, then ‘Back to dashboard’ to see the 15 rules with the highest number of violations.
Now you understand why almost all applications are in red. If you show this dashboard to the project teams and to your audience, they will tell you that these analysis are worthless because they take into account rules that do not apply.
Rules selection
This widget is going to be very useful to identify the rules that we can immediately exclude from our Quality model:
- COMP (COMPUTATIONAL) is a data type that allows the compiler to choose the memory allocation of this data. As compilers vary among platforms, this clause can cause portability problems. But migration between different mainframes occurs very rarely, so this rule is not a concern. Moreover, this format is preferred by developers because more performant, since it is close to the compiler.
- ‘Magic Literal’ / ‘Magic Number’ are ‘best practices’ that promote the use of constants instead of values (numeric or alphanumeric) hard-coded into the code. These are not rules specific to Cobol, they exist in all languages, but they are not really implemented in the Mainframe world.
- ‘Using Paragraphs’, ‘Perform Paragraph / Section’. These are rules about structuring Cobol code. With more than 100,000 violations, they clearly do not apply here. Furthermore, they also are mutually exclusive from each other and should not be used at the same time.
Again, we will not begin here a course about Cobol language and explain all these rules. The objective is to show that with our Cobol View and this widget, we can quickly refine our own Quality model. The first 5 rules listed above can be disabled with no trouble.
Other advantages of the widget ‘Most Violated rules’:
- Select a level of severity in order to list the rules you want to exclude or to change their threshold.
Here we find again the three (first) critical rules that we noted to deactivate in our last post. We also said to raise the ‘Avoid using SORT statement’ to ‘Blocker’.
I will also downgrade the ‘Limit the number of lines in a WHERE clause’ and ‘Avoid nested SQL SELECT statements’ to ‘Major’ because these best practices, certainly critical to the readability and maintainability of the code, have no impact on users. And I want to focus the value of my Quality model on defects with the greatest risk for users, so best practices about reliability and performance. For example, I will probably raise the serverity of a few SQL rules.
- Select a rule and check what applications of our Cobol View apply it or not.
Here we can see that the rule prohibiting the use of SQL queries is not in use in four applications of the seven present in our Cobol View. We have here an example of a rule that will apply differently for different teams.
Your own Quality model
With a Sonar View and the widget ‘Most Violated rules’, you can easily define your own Quality model in less than one hour, even without being an expert of the Mainframe world.
You can clearly identify the rules that do not apply, given the large number of defects encountered. You can focus on those with few violations because they are certainly known and applied by the Cobol teams.
You need a large enough sample to get meaningful numbers of defects. Analyze multiple applications and aggregate them in a Sonar View.
Choose an axis of values for your audience:
- Reduce the risk of bugs for end-users: choose rules that affect reliability and performance.
- Reduce maintenance costs: focus on rules impacting maintainability and code readability.
More on this: What is the first question? and Best of both worlds. In order to emphasize certain rules, raise them to ‘Critical’ or ‘Blockers’.
Define a Quality profile for your new Quality model . Re-analyze the applications and see the results in the Sonar dashboard.
You immediately notice that you can now go straight to the most important in identifying the main causes of risks and costs. The more valuable will be your presentation of the Sonar dashboard.