We have seen last week what you need to know about Mainframe-Cobol, before going into a meeting with the specialists of this technology and prepare a process of Cobol application analysis with Sonar.
We will now examine the questions you need to ask in order to organize these analysis (that we will present in a future article).
These questions also allow you to specify the rules for the delivery of the Cobol source code.
You have already explained to your audience that you will work with Cobol programs and Copys. The first question is: yes, but what Cobol?
What Cobol?
There are all kinds of mainframe-Cobol platforms: IBM z/OS, IBM AS/400, Bull GCOS (7 and 8), Tandem, Unisys and even Unix (Microfocus, for example). The Cobol z/OS is the most common. It is based on the ANSI 85 standard, the one you will most frequently encounter. Other Cobol languages are very close but may have some variations of syntax that can generate analysis errors, or even block a parser.
So the first question is what Cobol? And can we analyze it with Sonar? The easiest way to find out: go check it on this page http://www.sonarsource.com/products/plugins/languages/cobol/.
Which applications ?
We have seen that the notion of application is not really of interest for Cobol-ers. However, as with any technology, you want to organize the Sonar dashboard according to different application modules, in order to answer questions such as:
- Which application is the largest? The more complex?
- Which application has the most defects? The applications with the highest risk for users? Which applications are the most difficult and therefore the most expensive to maintain?
- Which application presents a significant technical debt? Which applications are candidates for refactoring?
- What is the quality of the code provided by my outsourcers?
- Etc.
In order to present a Sonar dashboard that answers these questions, you need to analyze the code of each application, and then arrange a delivery in different directories for each application. Cobol code is managed on the mainframe with libraries (equivalent to the directories on your computer), according to application modules. Therefore, you just have to ask an extraction of every library in a separate directory for each application.
Ask that the code for each application module is delivered into a single directory. Check with the future users of the Sonar dashboard how they want to organize the various applications.
Which naming conventions?
In Java, you will usually have a class named accordingly to the corresponding business entity. For example, the class ‘Customer’ to manage customers, the class ‘Connexion’ to manage a connexion, etc. None of this with Cobol. The file names are … shall we say esoteric? Well, in fact it is very well organized.
Cobol file repects almost systematically consistent naming convention for the 8 characters of the filename. Most often, the first 2 or 3 letters correspond to the application module to which it belongs.
An example of naming rules: AAAnnnnX with
- AAA to identify the module.
- nnnn: 4 digits for a unique object identifier.
- X: suffix indicating the type of program. For example, (B) for Batch or (T) for TP (transactionnal). Or (P)resentation, business (L)ogic or (D)ata (database access).
You will find many other types of naming conventions, this is just one example. But the elements of nomenclature are often the same, and almost always involve an application identifier.
Ask which are the naming rules. These rules should allow you to check that the delivery is correct. For example, files beginning with ‘AAA’ correspond to the application module AAA and are delivered into a single directory AAA.
You will frequently find files other than ‘AAA’ in this directory, but they will nonetheless be limited. The important thing, as you can guess, is not having all the files ‘AAA’ in directory ‘ZZZ’. Otherwise, you will have a problem, especially in the version history tracking. This might be caused by a small error in the batch extraction of the source code, which may arise when it is changed, while adding a new application in the Sonar dashboard.
Generated code
There exist Cobol code generators. For example, a tool will allow to design one screen and then generate the code of different programs to manage it, for display or data entry.
Obviously, there is no interest in analyzing the generated code. First you’re interested in programmer’s ‘bad practices’. And would you decide to correct defects in the generated code that the correction would disappear with the next re-generation of the program.
Check if there is a code generator. If so, ask which naming rules are used to identify these programs and remove them from your analysis. If possible, ask for a delivery without these objects.
File format
Mainframes have their own file format, and it’s not ASCII. However, we must of course get files with this format. The person in charge of the extraction will have to perform the conversion. Nothing complicated, there are plenty of utilities that do this.
We also need a file by component, that is to say, for every program and Copy-book. This seems obvious, but I happened to receive a single (very large) file with all programs.
Similarly, the filename must be equal to the name of the program or Copy-book. Again, this seems obvious, but I already got programs with names like ‘MP38.PROG (MP8239XZ)’. The person in charge of the extraction thought it would be better creating files with the name of the library (MP238) and the program name MP8239XZ inside brackets. I had to develop a program to put it again correctly. Don’t even imagine such a step in your analysis process.
Something about that, that could be of help. A Cobol program consists of different mandatory parts, called ‘Division’, in order to regroup different pieces of identical code. For example, the ‘DATA DIVISION’ defines data structures and logical instructions are required to be written in the ‘PROCEDURE DIVISION’.
However, any program Cobol necessarily begins with an ‘IDENTIFICATION DIVISION’ on the first line followed by a line with the program name, using the following syntax: PROGRAM-ID. <program name>.
So if you have a file that does not start with these first two lines, or if you have multiple IDENTIFICATION DIVISION and PROGRAM-ID in your file, or if the PROGRAM-ID does not match the file name, then it is that the previous rules were not followed and you have potentially a problem.
Finally, ask that the files for Cobol programs have the extension ‘.cob’ and Copy-books an extension ‘.cpy’. It is not mandatory, especially since you can set this element with Sonar, but it’s not complicated to extract the code with respect to this rule.
In summary, specify to the person in charge of extracting the source code which are the rules of delivery:
- ASCII file.
- One file per program.
- The filename is the name of the program.
- If possible, extension .cob for Cobol programs, and .cpy for Copy-books.
Keep it easy and simple. Do not create unnecessary steps of re-processing the source code. Make sure it is in a format that allows its analysis: simplify your process, this is essential in order to automate it and avoid additional, potentially error-prone tasks.
The last questions are the settings required for the parser, for code analysis.
Position indicator: code Cobol is aligned on the same column. In other words, all instructions will begin at the same position. By default, a program is aligned with a position indicator, equal to 7.
In the following example, the first 6 digits correspond to a line number (note that they are not sequential, in order to be able to introduce new lines). But again, the code starts at the position/column 7.
You can set this indicator position with Sonar, but better verify it before discovering it on a parse error.
Other settings you can adjust with Sonar, and again, do not hesitate to ask:
- Tab: as with any language, a Cobol programmer will use the ‘Tab’ key to align its code. A tab can represent a different size depending on the mainframe or the Cobol used.
- Length of the line of code: any ASCII file contains a line of 80 characters. Minus the starting position but also the end position beyond which you will not find more code. But possibly a comment. By default, the code area is equal to 66.
There are other parameters used with Sonar, but in most cases you will not need to know of them. Because in most cases, you will analyze IBM z/OS Cobol code with the default settings.
It sounds complicated? It is not. I’ve listed the questions in order of importance so all you have to remember is that:
- You will analyze Cobol programs and copy-books. Explain that early in the meeting.
- You must arrange delivery in different directories for different application modules that your users want to see in the Sonar dashboard. So one directory = one application.
- Ask what are the rules for naming Cobol files. Each file has an identifier which is typically the application module. Check the delivery, especially for the first versions, when you implement your analysis process.
- A program filename that is the name of the program, with a .cob extension, and a Copy-book with a .cpy extension. Keep it simple.
- Check that there is no Cobol generator. If this is the case, keep the generated programs apart of the delivery.
- Check the default settings, including the position indicator.
These questions will not raise any discussion during the meeting. In fact, your audience will be happy to see that you address these points. They will be happy to see that you ask the right questions. And you will see: Cobol-ers are extremely nice people.
Coming soon: setting an analysis Cobol with Sonar. In the meantime, feel free to ask questions.