The previous posts about the preparation and analysis of Cobol code with Sonar and Jenkins drew some anxious comments about the results of the analysis and the rules available in the Sonar dashboard.

Do these results allow an evaluation of the quality of Cobol applications? What value do we deliver to teams, stakeholders and management? And for those who are not familiar with the Mainframe world, what are the ‘best / bad practices’ in terms of Cobol code?

Many questions, and we’re not going to answer all of them in one post. This one will be dedicated to the presentation of different rules and quality defects, frequently encountered in Cobol applications.

The objective is: you have made an analysis, the results appear in the Sonar dashboard. Now, where to start?

Blockers

The first ‘blocking’ rule you’ll encounter will probably surprise you: ‘Avoid use of SQL’. What? It is not possible to program SQL queries in Cobol code? In fact, it is completely prohibited in some organizations that have implemented reusable components to support access to the data layer.

The reason is simple: if each developer adds its own SQL whenever it needs to access a table, the links with the database are increasing over time. Cobol applications are the oldest that you can encounter, and over the years if not decades, ‘update / insert / delete’ have proliferated. So, any change in the data structure of a table requires modifying dozens of redundant SQL queries in different programs, which represents a very important maintenance effort and a high risk of forgetting a program and creating a bug.

However, to reserve the access to the data layer to a set of reusable components requires a team dedicated to maintaining these programs, and process requests for changes from other teams. Quite heavy, time consuming, so the ban to SQL programmation does not occur in all companies.

This explains why this metric is optional and disabled by default (on this topic, see our previous post Quality Profiles). So check with the Cobol teams if they apply or not this ‘best practice’, as to whether or not you should enable this metric.

Otherwise, you may encounter the following case:

Showing a dashboard with 18 000 ‘blockers’ banning SQL queries may create some misunderstanding on the part of the Cobol team.

Other blockers :

A STOP RUN is simply a program interruption. Everything stops, programs installed in memory are deleted from it, files are closed, direct return to the OS. This instruction should be used with caution (or even prohibited). And there can not be any code after a STOP RUN since this code is not executed.

I found 4 of these blockers in this application:

You can easily imagine that this time your audience will be very glad that you did identify these four defects in more than 2 million lines, of which nearly 1 .5 ​​million of lines of code (the rest is commentary). This alone justifies completely your analytical work.

I also found in this application 10 recursive Performs.

Cobol code is organized in a program as a sequence of paragraphs that are equivalent to procedures or functions (to say it simply, we will not start a course of Cobol in these pages). A recursive Perform is equivalent to calling a procedure recursively.

Sonar shows us the line where we can find this bad practice:

As we can see in this example, a recursive Perform is generally found in a complex code full of nested IFs, and here in an ELSE. So if any of the above conditions is never verified, the risk is important to be in an infinite recursive loop. Moreover, it greatly complicates the understanding of the code, so further increases the risk of introducing an error when the developer makes a change. It is dangerous and every Cobol programmer knows it (except the ones who consider themselves geniuses and want to prove it with recursive programmation).

A last blocker that you will probably not see very often:

A ‘Perform Thru’ is a sequential execution of different paragraphs. For example, imagine three consecutive paragraphs A, B, C, and an instruction ‘Perform A thru C’, then paragraphs A then B then C will be executed. Problem: if B is defined before A, then only A and C will be executed, which is not the objective.
Again, it is not frequent to encounter this type of fault.

Critical

Here are the ‘Critical’ violations for this same application:

A defect that you will encounter in all applications: an IF that does not end with an END-IF. And how does it end? With a period. Yes, a ‘.’ A tiny and easily overlooked period. Any fly dung on the screen and you can be sure to get an error. You can not imagine the thousands of hours lost debugging Cobol programs because of this damned period.

All programmers know this ‘best practice’ and everyone respects it nowadays, but it was not always the case. In fact, the older the application, the more you encounter this defect. This may justify to degrade the severity of this rule from ‘Critical’ to ‘Major’. They are often too numerous to be corrected. And do not demoralize Cobol teams presenting a dashboard with thousands of critical defects that were in the code before they were born.

Some of these rules are easy to understand for non Cobol-ers, as the initialization of the data passed as parameters with a CALL, or embedded SQL queries or using dynamic SQL (this last one not very common among Cobol developers) . Others seem more esoteric, but are still fairly simple.

The Linkage Section defines data that can be shared between programs. As for SQL queries, if each developer begins to change this data structure, the risk is that other programs will no longer work. So it would be desirable to define these data in a Copy-Book. But as for SQL statements, this requires a certain organization to manage these Copys, therefore this rule does not apply very often.

Reason why this rule is deactivated in the Sonar default Quality Profile, as the rule about initializing the parameters of a CALL. This explains the number of violations found in this application for these two rules. So again, check with the team if they apply these Cobol best practices and eventually turn them off. Personally, I would put their severity to (for) ‘Info’.

A SORT is a sorting instruction, unfortunately very costly in performance. The rule prohibiting its use can also be raised to ‘Critical’, except possibly in the case of batch applications. But everyone will agree if you recommend to correct these defects.

A GOTO is a shift in the program logic to another paragraph. Better known as the symbol of spaghetti code. For example, if during a ‘Perform A Thru C’, paragraph B contains a GOTO Paragraph D, the sequence originally defined is not performed as paragraph C will not be executed, sometimes with unpredictable consequences.

So a quick review of these ‘Blockers’ and ‘Critical’ rules already allows a first evaluation of the quality of the code of this application and a first draft of an action plan:

• Disable the rule prohibiting the use of SQL: it does not apply here.
• Correct ASAP the 4 STOP RUN and the 10 recursive Performs.
• The IF without END-IF will surely raise sighs of resignation from your Cobol audience, but without a complete refactoring of the application, they are certainly here to stay. However, you can propose to try to correct them while implementing changes in the code. Sonar helps the developer by showing the line of code where they are present.
• Also deactivate the rules about parameters or the Linkage Section, obviously not used by this Cobol team.
• Other defects must be corrected. You could raise the rule prohibiting the use of the SORT to ‘Critical’.

You already have enough infos to make some kind of Quality Gate and ask a provider to implement the corrections mentioned above.

We will continue the evaluation of the quality of Cobol code in a future post, with yet more rules. Until then, have fun analyzing Cobol.

This post is also available in Leer este articulo en castellano and Lire cet article en français.