I did some posts some months ago (Sonar – Cobol analysis with Jenkins, Open Source & Legacy code) with the idea to to show that you don’t need to be a J2EE guru or an Open Source expert to analyze Legacy code like Cobol (or ABAP) with Sonar and Jenkins.

And I see people going to my blog to look at these pages, which show some interest for this subject.

Now, as someone said recently: “We’ve got Sonar analysis well under way there. We’re contemplating putting Cobol under analysis as well, but I don’t understand the mainframe side and the Cobol-ers don’t understand the Jenkins & Sonar side”.

So, let’s try to help. This post (and following ones) has the objective to describe what you should know to implement a process of Cobol code analysis with Sonar and Jenkins.

I will not do a presentation of what is Mainframe-Cobol or a training about it, I guess you can find this probably on Internet, and it would take several posts.

No. The idea is: you must set up this process of analysis of Cobol code. A meeting is planned with some people of the Mainframe world. To prepare for this meeting:

• What you need to know?
• Which questions should you ask?

You need to know: what you can analyze.

Cobol components

You know about classes, methods, libraries (. Jar), etc. These are the objects of the Java language. Cobol components you need to know are:

• Cobol program: a file of Cobol instructions, which will be compiled into an executable.
• Copy-book: a file of Cobol instructions, used as an Include. Equivalent of a reusable component. Also called ‘Copys’, simply because the call to this file is using a COPY statement.

For example, the following program calls the Copy-book ‘MYCOPY’ at line 65 :

I created this Copy with the following source code:

When this program is compiled, or analyzed, as in the following example, we can see that the code of the Copy-book has been inserted into the Cobol program, at the line it was called:

I deliberately induced an error in order to stop the analysis and show the error log so that you can see that the code of the Copy-book is ‘expanded’ in the Cobol program.

Copy-books are the equivalent of reusable components, very useful. For example, statements about structures of database tables are made in a Copy-book. In this way, each program working with the table (re-)use the Copy-book. Any change in the structure of the tables will be done through it and reused by the Cobol programs, which avoid having to find and change all these programs.

So you understand that programs and Copys are the two components with Cobol code that we want to analyze.

Other types of Mainframe objects to know:

• CICS transactions – pronounce ‘KIKS’ to look as a connoisseur :): file used by the transaction server on IBM mainframes. When you make a bank transaction, as a withdrawal from your bank account, it is likely that several thousands people are currently performing the same operation at the same time as you. This is the role of the CICS Transaction Server to handle these thousands transactions (and others) in parallel.
• JCL: a batch file. The JCL is a specific language (Job Control Language), somewhat tricky. Once you achieve your banking transaction, an accounting entry will be recorded, for example. But no need to do this ‘online and alive’, and use computer resources (CPU, memory) that is necessary to compute current transactions when this treatment can be done overnight. This will be the role of a JCL batch.

There is virtually no quality standards for CICS transactions or JCL files, and the few existing ones are not critical, so we will avoid the effort to extract and analyze these files.

There are other object types and other types of code (Assembler, PL1, …) in the Mainframe world, but nobody will criticize you if you do not know what it is (furthermore, Mainframe people are nice people). All you need to remember is that we will analyze the components based on Cobol code, programs and Copy-books. And being able to say at your meeting that the JCL and the ‘KiKs’ are not really interesting to evaluate the quality of Mainframe applications.

Cobol applications

Hey, speaking of Mainframe applications, another thing to know.

A bank must have an average of 20 millions of lines of Cobol, approximately. So you will not analyze all of them at first, you will start with the most critical applications. The problem is that the notion of application does not make sense in Cobol.

These are Legacy systems, which have existed for decades, and are very intertwined. For example, the Cobol code that allows you to perform your banking transactions will probably use some Copy-books which are also required to the accounting system that will use a batch to save writing for your withdrawal. In what application these Copy-books belong? For Cobolers, it does not really matter.

Obviously, all these files and all these millions of lines of code are not found in a single location. A mainframe is a computer with a file-system and the files will be organized into ‘libraries’, or some kind of directories as on your own personal computer. What we will analyze is the content of a directory, that we will extract and download from the mainframe to our Sonar / Jenkins platform.

So do not be surprised if in your meeting, some say “modules” or “libraries” instead of applications. In any case, what you are looking for is how to organize the different sets of files in different analyzes, whatever you want tho name them: applications, modules or anything else.

These simple concepts are the minimum you need to know in order to understand Mainframe people in the meeting that awaits you.

Now you will need to know what questions to ask. That we shall see in our next post.

 

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