Nous avons vu la semaine dernière ce qu’il fallait savoir en matière de Mainframe-Cobol, avant de se présenter dans une réunion avec les spécialistes de cette technologie et préparer un processus d’analyse avec Sonar.

Nous allons maintenant examiner les questions à poser afin d’organiser les analyses avec Sonar (que nous verrons dans un prochain article).

Ces questions vous permettront également de préciser les règles de livraison du code source.

Vous avez déjà expliqué à vos interlocuteurs du monde Mainframe que vous allez travailler avec les programmes Cobol et les Copys. La première question sera : oui, mais quel Cobol ?

Quel Cobol ?

Il existe toutes sortes de plates-formes Mainframe-Cobol : IBM z/OS, IBM AS/400, Bull GCOS (7 et 8), Tandem, Unisys et même Unix (Microfocus, notamment). Le Cobol z/OS est le plus répandu. Il est basé sur la norme ANSI 85, celui que vous rencontrerez le plus souvent. Les autres Cobol sont très proches mais peuvent avoir quelques variantes de langages qui peuvent gêner voire bloquer un parser.

Donc la 1ère question est : quel Cobol ? Et peut-on l’analyser avec Sonar ? Le plus simple, pour le savoir : allez vérifier sur cette page http://www.sonarsource.com/products/plugins/languages/cobol/.

Quelles applications ?

Nous avons vu que la notion d’applications n’avait pas vraiment d’intérêt pour les cobolistes. Néanmoins, comme pour toute autre technologie, vous souhaitez organiser le dashboard Sonar en fonction des différents modules applicatifs, afin de pouvoir répondre à des questions telles que :

• Quelle application est la plus volumineuse ? La plus complexe ?
• Où trouve-t-on le plus de défauts ? Quelle application présente le plus de risques pour les utilisateurs ? Quelles applications sont les plus difficiles et donc les plus coûteuses à maintenir ?
• Quelle application présente une dette technique importante ? Quelles sont les applications candidates à un refactoring ?
• Quelle est la qualité du code fourni par mes outsourceurs ?
• Etc.

Afin de présenter un dashboard Sonar qui réponde à ces questions, il vous faut analyser le code de chaque application, et donc organiser sa livraison en différents répertoires correspondant à chaque application. Le code Cobol est géré sur le mainframe dans des bibliothèques (équivalent des répertoires de votre ordinateur), selon une arborescence en modules applicatifs. Donc, il suffit habituellement d’extraire chaque bibliothèque dans un répertoire de livraison distinct, pour chaque application.

Demandez à ce que le code correspondant à chaque module applicatif soit livré dans un unique répertoire. Vérifiez avec vos interlocuteurs et les futurs utilisateurs du dashboard Sonar comment ils veulent organiser les différentes applications.

Quelles règles de nommage ?

En Java, vous aurez généralement une classe nommée en fonction de l’entité métier correspondante. Par exemple, la classe ‘Client’ pour gérer les clients, la classe ‘Connexion’ pour gérer une connexion, etc. Rien de tout cela en Cobol. Les noms de fichiers sont tout ce qu’il y a d’ésotérique. Mais en fait, c’est très bien organisé.

Un fichier Cobol obéit quasi systématiquement à des règles de nommage sur 8 caractères. Le plus souvent, les 2 ou 3 premières lettres d’un programme Cobol correspondent au module applicatif auquel il appartient.

Voici un exemple de règles de nommages : AAAnnnnX avec

• AAA pour identifier le module.
• nnnn : 4 chiffres composant un identifiant unique.
• X : suffixe précisant le type de programme. Par exemple, (B) pour Batch ou (T) pour TP (transactionnel). Ou encore (P)résentation, logique (M)étier ou (D)ata (accès aux données en database).

Vous rencontrerez bien d’autres types de nommage, ce n’est qu’un exemple. Mais les éléments de nomenclature sont bien souvent les mêmes, et comportent presque toujours un identifiant applicatif.

Demandez à vous faire préciser les règles de nommage. Ces règles doivent vous permettre de vérifier que la livraison est correcte. Par exemple, les fichiers commençant par ‘AAA’ correspondent au module applicatif AAA et sont livrés dans un répertoire unique AAA.
Vous aurez fréquemment d’autres fichiers que ‘AAA’ dans ce répertoire, mais ils seront néanmoins peu nombreux. L’important, vous l’avez compris, est de ne pas avoir tous les fichiers ‘AAA’ dans un répertoire ‘ZZZ’ Sinon, vous allez avoir un problème, notamment dans le suivi historique des versions. Il suffit d’une petite erreur dans le batch d’extraction du code source, qui peut survenir lorsque celui-ci est modifié, par exemple pour ajouter une nouvelle application dans le dashboard Sonar.

Code généré

Il existe des générateurs de code Cobol. Par exemple, un outil va permettre de dessiner simplement un écran et génèrera ensuite le code des programmes destinés à gérer celui-ci, pour l’affichage ou la saisie de données.
Evidemment, il n’y a aucun intérêt à analyser du code généré. D’abord, vous vous intéressez aux ‘bad practices’ des programmeurs. Et même si vous décidez de corriger des défauts dans du code généré, la correction effectuée disparaîtra à la prochaine re-génération du programme.

Vérifiez s’il existe un générateur de code. Si oui, faites vous préciser quelles règles de nommage permettent d’identifier ces programmes afin de les écarter des analyses. Si possible, faites vous livrer les modules applicatifs sans ces objets.

Format de fichier

Les mainframes possèdent leur propre format de fichier, et ce n’est pas de l’ASCII. Or, il nous faut bien évidemment des fichiers dans ce format. La personne en charge de l’extraction devra donc effectuer cette conversion. Rien de bien compliqué, il y a plein d’utilitaires qui font cela.

Il nous faut également un fichier par composant, c’est-à-dire pour chaque programme et chaque Copy-book. Cela paraît évident, mais il m’est arrivé de recevoir un seul et unique (très gros) fichier avec tous les programmes.

De même, le nom du fichier doit être équivalent au nom du programme ou du Copy-book. Là encore, cela paraît évident, mais j’ai déjà reçu des programmes avec des noms comme ‘MP238.PROG(MP8239XZ)’. La personne en charge de l’extraction a cru bien faire en créant des fichiers avec le nom de la bibliothèque (MP238) et le nom du programme MP8239XZ entre parenthèses.

Un truc, à ce sujet. Un programme Cobol se compose de différentes parties obligatoires, appelées ‘Division’, et chargées de regrouper différents éléments de code. Par exemple, la ‘DATA DIVISION’ permet de définir les structures de données, et les instructions logiques doivent obligatoirement s’écrire dans la ‘PROCEDURE DIVISION’.
Or, tout programme Cobol débutera forcément à la première ligne par une ‘IDENTIFICATION DIVISION’’ suivi ensuite d’une ligne avec le nom du programme, selon la syntaxe suivante : PROGRAM-ID. <nom du programme>.

Donc si vous avez un fichier qui ne commence pas avec ces deux premières lignes, ou si vous avez plusieurs IDENTIFICATION DIVISION et PROGRAM-ID dans votre fichier, ou si le PROGRAM-ID ne correspond pas au nom du fichier, alors c’est que les règles précédentes n’ont pas été respectées et vous avez potentiellement un problème.

Enfin, demandez à ce que les fichiers pour les programmes Cobol aient une extension ‘.cob’ et les Copy-books une extension ‘.cpy’. Ce n’est pas obligatoire, d’autant que vous pouvez paramétrer cet élément avec Sonar, mais ce n’est pas compliqué d’extraire le code selon cette règle.

En résumé, précisez à la personne en charge de l’extraction du code source les règles de livraison de celui-ci :

• Fichier au format ASCII.
• Un fichier par programme.
• Le nom du fichier correspond au nom du programme.
• Si possible. extension .cob pour les programmes Cobol, et .cpy pour les Copy-books.

Simplifiez vous la vie. Evitez de vous créer des étapes supplémentaires avec des opérations de transformation du code source. Faites en sorte que celui-ci soit dans un format qui permette son analyse : vous simplifiez votre processus, ce qui est primordial afin de pouvoir automatiser celui-ci et vous évitez des tâches supplémentaires, potentiellement sources d’erreurs.

Les dernières questions à poser correspondent à des paramètres nécessaires au parser, pour l’analyse du code.

Indicateur de position : le code d’un programme Cobol est aligné sur la même colonne. En d’autres termes, toutes les instructions vont commencer à la même position. Par défaut, un programme est aligné sur un indicateur de position, égal à 7 par défaut.

Dans l’exemple suivant, les 6 premiers caractères correspondent à un numéro de ligne (notez qu’ils ne sont pas séquentiels, afin de pouvoir introduire de nouvelles lignes). Mais là encore, le code commence à la position/colonne 7.

Vous pouvez paramétrer cet indicateur de position avec Sonar, mais autant s’en assurer auparavant avant de tomber sur une erreur de parser.

Autres paramètres que vous pouvez ajuster avec Sonar, et là encore, n’hésitez pas à demander :

• Tabulation : comme avec tout langage, un programmeur Cobol va utiliser la touche ‘Tab’ pour aligner son code. Une tabulation peut représenter une taille en caractères différente selon le type de mainframe ou de cobol.
• Longueur de la ligne de code : tout fichier ASCII comporte une ligne de 80 caractères. Moins la position de départ mais aussi la position de fin au-delà de laquelle on ne trouvera plus de code. Mais éventuellement un commentaire. Par défaut, la ‘zone’ de code est égale à 66.

Il existe d’autres paramètres utilisables avec Sonar, mais dans la plupart des cas, vous n’aurez pas besoin de les connaître. Parce que dans la plupart des cas, vous allez analyser du code Cobol de mainframe IBM avec les paramètres par défaut.

Cela semble compliqué ? Cela ne l’est pas. J’ai listé les questions à poser par ordre d’importance donc tout ce que vous avez à vous rappeler, c’est que :

1. Vous allez analyser des programmes Cobol et des Copy-books. Expliquez bien cela en début de réunion.
2. Vous devez organiser la livraison en différents répertoires correspondant aux différents modules applicatifs que vos utilisateurs veulent voir dans le dashboard Sonar. Donc un répertoire = une application.
3. Demandez quelles sont les règles de nommage des fichiers Cobol. Chaque fichier aura un identifiant qui correspond généralement au module applicatif. Vérifiez la livraison, notamment pour les premières versions, lorsque vous implémentez votre processus d’analyse.
4. Un fichier par programme, correspondant au nom du programme, avec une extension .cob, et par Copy-book avec une extension .cpy. Facilitez vous la vie.
5. Vérifiez qu’il n’y a pas de générateur de Cobol. Si c’est le cas, écartez ces programmes générés de la livraison.
6. Vérifiez les paramètres par défaut, notamment l’indicateur de position.

Ces questions ne donneront pas lieu à discussion en réunion. En fait, vos interlocuteurs seront contents de vous voir aborder ces points. Ils seront satisfaits de vous voir poser les bonnes questions. Et puis vous verrez : les cobolistes sont des gens extrêmement gentils.

Prochainement : le paramétrage d’une analyse Cobol avec Sonar. Dans l’attente, n’hésitez pas à poser vos questions.

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.