J’ai fait quelques posts il y a quelques mois (Sonar – Analyse Cobol avec Jenkins, Open Source & code Legacy) dans le but de montrer que, contrairement à une idée assez répandue, il n’est pas nécessaire d’être un gourou J2EE ou un expert Open Source pour analyser du code Legacy d’applications Cobol (ou ABAP) avec Sonar et Jenkins.

Et je vois pas mal de visiteurs consulter ces pages sur mon blog, ce qui dénote l’intérêt certain pour ce sujet.

Mais quelqu’un m’a dit récemment : « Nous effectuons régulièrement et avec succès des analyses Sonar pour du code J2EE. Nous envisageons également de mettre les applications Cobol dans Sonar et Jenkins, mais je ne connais pas le monde Mainframe ».

Ainsi, ce post (et les suivants) aura pour objectif d’aider à la mise en place d’un processus d’analyse de code Cobol avec Sonar et Jenkins.

Je ne vais pas faire un cours de Mainframe-Cobol, je suppose que cela doit probablement se trouver facilement sur Internet, et il faudrait plusieurs posts.

Non. L’idée est la suivante: vous devez mettre en place ce processus d’analyse de code Cobol. Une réunion est prévue avec quelques représentants du monde Mainframe, de votre entreprise. Afin de préparer cette réunion :

• Que vous faut-il savoir ?
• Quelles sont les questions que vous devez poser ?

Vous devez savoir : ce que vous allez analyser.

Les composants Cobol

En Java, vous travaillez avec des classes, des méthodes, des librairies (.jar), etc. Ce sont les objets du langage Java. En Cobol, les types de composants à connaître sont les suivants :

• Programme Cobol : un fichier d’instructions Cobol, qui sera compilé en un exécutable.
• Copy-book : un fichier d’instructions Cobol, utilisé comme un Include. Equivalent d’un composant réutilisable. Encore appelé ‘Copys’, tout simplement parce que l’appel à ce fichier se fait à l’aide d’une instruction COPY.

Par exemple, le programme suivant fait appel à la ligne 65 au Copy-book ‘MYCOPY’ :

que j’ai créé moi-même, avec le code suivant :

Lorsque le programme est compilé (en l’occurrence ici, analysé), on peut voir que le code du Copy-book a été inséré dans le programme à l’endroit où il était appelé :

J’ai volontairement induit une erreur afin de montrer dans la log d’erreur que le code du Copy-book est ‘expanded’ au sein du programme Cobol.

Les Copy-books sont l’équivalent de composants réutilisables, très utiles. Par exemple, les déclarations de structures de tables de bases de données sont effectuées dans un Copy-book. De cette manière, chaque programme réalisant un traitement sur la table (ré-)utilisera le Copy-book. Toute modification de la structure de la table se fera au travers de celui-ci, ce qui évitera de devoir rechercher et modifier tous les programmes qui font appel à lui.

Vous comprenez donc que programmes et Copys sont les deux composants comportant le code Cobol dont nous souhaitons évaluer la qualité.

Les autres types d’objets Mainframe à connaître :

• Transaction CICS – prononcez ‘KiKs’ pour faire connaisseur 🙂 : fichier utilisé par le serveur de transactions sur les mainframes IBM. Lorsque vous effectuez une transaction bancaire, comme un retrait de votre compte en banque, il est probable que plusieurs milliers de personnes soient en train d’effectuer la même opération en même temps que vous. C’est le rôle du serveur de transactions CICS de gérer ces milliers de transactions (et bien d’autres) en parallèle.
• JCL : un fichier batch. Le JCL est un langage (Job Control Language) spécifique, assez abscons. Une fois votre opération bancaire effectuée, il faudra enregistrer une écriture comptable, par exemple. Mais inutile d’effectuer cette opération en ‘direct live’, et d’utiliser inutilement de la ressource ordinateur (CPU, mémoire) alors que ce traitement peut être effectué durant la nuit. Ce sera le rôle d’un batch JCL.

Il n’existe pratiquement pas de normes de qualité pour les transactions CICS ou les fichiers JCL, et ce ne sont pas des règles critiques, donc nous éviterons l’effort d’extraire et analyser ces fichiers.

Il existe d’autres types d’objet et d’autres types de code (Assembleur, PL1, …) dans le monde Mainframe, mais personne ne vous en voudra si vous ne savez pas ce dont il s’agit. Tout ce que vous avez besoin de retenir, c’est que nous allons analyser des composants à base de langage Cobol, donc des programmes et des Copy-books. Et d’être capable de dire lors de votre réunion que le JCL et le ‘KiKs’ ne sont pas vraiment intéressants pour estimer la qualité d’applications Mainframe.

Les applications Cobol

Tiens, en parlant d’applications Mainframe, autre chose à savoir.

Une banque moyenne doit avoir autour de 20 millions de lignes de Cobol, environ. Donc vous n’allez pas tout analyser d’un seul coup, vous allez commencer par les applications les plus critiques. Le problème : la notion d’application n’a pas de sens en Cobol.

Il s’agit de systèmes Legacy, qui existent depuis des dizaines d’années, et sont fortement imbriqués. Par exemple, le code Cobol qui vous permet d’effectuer votre opération bancaire va probablement utiliser quelques Copy-books qui seront également nécessaires au système comptable, qui utilisera un batch afin d’enregistrer l’écriture correspondant à votre retrait. A quelle application appartiennent ces Copy-books ? Pour les cobolistes, cela n’a pas vraiment d’importance.

Par contre, il est bien évident que tous les fichiers constitutifs de ces millions de lignes de code ne vont pas se trouver tous groupés dans un seul et unique emplacement. Un mainframe est un ordinateur avec un file-system et les fichiers seront organisés en ‘bibliothèques’ ou librairies, tous comme les répertoires de votre propre ordinateur personnel. Ce que nous allons analyser, c’est le contenu d’un directory, que l’on va extraire et downloader depuis le mainframe jusqu’à notre plateforme Sonar / Jenkins.

Donc ne vous étonnez pas si dans votre réunion, certains parlent de ‘modules’ au lieu d’applications. Dans tous les cas, ce qui vous intéresse, c’est de savoir comment organiser les différents ensembles de fichiers en différentes analyses, que celles-ci portent sur des applications, des modules ou tout autre appellation qu’on voudra bien leur donner.

Ces simples notions sont le minimum nécessaire à connaître afin de savoir de quoi l’on parle dans la réunion qui vous attend.

Il vous reste maintenant à savoir quelles sont les questions à poser. Ce que nous verrons dans notre prochain post.

 

Cette publication est également disponible en Leer este articulo en castellano : liste des langues séparées par une virgule, Read that post in english : dernière langue.