Comment comprendre un programme COBOL inconnu

Situer le programme avant de l'ouvrir

Un programme COBOL ne s'exécute jamais seul : il est lancé par un JCL, appelé par un autre programme, ou déclenché par une transaction. Identifier qui l'appelle en dit souvent plus long sur sa fonction que ses trois cents premières lignes.

Trois questions avant d'ouvrir le source. Est-il en batch ou en transactionnel ? S'il est en batch, quel JCL l'exécute, à quelle étape, et qu'est-ce qui tourne avant et après lui dans la même chaîne ? S'il est appelé par un autre programme, que reçoit-il en LINKAGE SECTION ?

Cette dernière question est décisive. La LINKAGE SECTION est le contrat d'interface du programme : elle dit ce qu'il attend, ce qu'il renvoie, et donc à quoi il sert. Un programme dont la linkage contient un code retour et un message est presque toujours un module de validation ou de calcul, pas un traitement de bout en bout.

Lire l'en-tête sans lui faire confiance

Les commentaires de l'IDENTIFICATION DIVISION décrivent l'intention d'origine, pas le comportement actuel. Sur un programme modifié pendant vingt ans, ils documentent souvent une version qui n'existe plus.

Ce qui reste utile : le nom du programme, la date de création, et surtout l'historique des modifications quand il est tenu. Une ligne de commentaire datée près d'un bloc de code indique presque toujours une exception métier ajoutée après coup — c'est-à-dire exactement le genre de règle qui n'est écrite nulle part ailleurs.

Commencer par les entrées et les sorties

Avant de lire une seule instruction de traitement, listez tout ce que le programme lit et tout ce qu'il écrit. Les noms de fichiers physiques et de tables sont rédigés dans le vocabulaire de l'entreprise, alors que les variables de travail sont rédigées dans celui du développeur.

Quatre endroits à relever, dans cet ordre :

• SELECT … ASSIGN TO … dans la FILE-CONTROL : le lien entre le nom logique utilisé dans le code et le fichier réel
• FD dans la FILE SECTION : la structure de chaque enregistrement
• EXEC SQL : les tables lues, insérées, modifiées ou supprimées, et les curseurs déclarés
• OPEN / READ / WRITE / REWRITE dans la PROCEDURE DIVISION : le sens réel de chaque flux

Un détail qui fait gagner du temps : un fichier ouvert en I-O plutôt qu'en INPUT signale un programme qui modifie des données existantes, donc un programme dont une erreur ne se rattrape pas simplement en relançant.

Ici, trois informations en cinq lignes : la donnée manipulée est le client, l'accès se fait par clé, et le programme surveille le statut de chaque opération — signe d'un code défensif, donc probablement critique.

Relever les structures de données

Les COPYBOOKS et les niveaux 01 de la WORKING-STORAGE SECTION décrivent le modèle de données du traitement. Un COPYBOOK partagé est aussi le principal vecteur d'impact : le modifier affecte tous les programmes qui l'incluent, souvent bien plus qu'on ne l'imagine.

Trois éléments à ne pas manquer dans la DATA DIVISION :

• Les COPY : notez chaque copybook, il faudra les récupérer pour comprendre les champs
• Les niveaux 88 : ce sont des noms de conditions, et donc du vocabulaire métier directement exploitable — 88 CLIENT-INACTIF VALUE "I" "F" vous apprend une règle sans lire une ligne de traitement
• Les REDEFINES : le même emplacement mémoire interprété de deux façons, souvent le signe d'un champ dont le sens dépend d'un contexte non documenté

Cartographier les paragraphes avant de lire le code

Relevez d'abord la liste des paragraphes et les PERFORM qui les relient, sans lire leur contenu. Cette carte tient sur une page et donne la structure du traitement en quelques minutes, là où une lecture linéaire prend des heures et fait perdre le fil.

Concrètement : notez chaque nom de paragraphe, puis pour chacun quels autres paragraphes il appelle. Vous obtenez un arbre. Le paragraphe racine — celui que personne n'appelle — est le point d'entrée. Les feuilles sont les traitements élémentaires. Les paragraphes appelés depuis plusieurs endroits sont les plus sensibles : ce sont eux qu'une modification impacte le plus largement.

Les noms de paragraphes en COBOL sont souvent numérotés par ordre d'exécution (1000-INIT, 2000-TRAITEMENT, 9000-FIN). Quand la numérotation est respectée, elle donne gratuitement la séquence. Quand elle ne l'est plus, c'est le premier indice qu'on est devant un programme qui a beaucoup évolué.

Isoler les règles métier

Les règles métier d'un programme COBOL se concentrent dans trois types d'instructions : les conditions (IF, EVALUATE), les calculs (COMPUTE, ADD, MULTIPLY) et les codes retour. Tout le reste est de la plomberie : ouverture de fichiers, boucles de lecture, déplacements de champs.

La bonne unité de travail n'est pas l'instruction mais le bloc : une condition et le calcul qu'elle gouverne forment une règle. Pour chaque règle trouvée, notez systématiquement quatre choses — l'énoncé en français, l'emplacement exact, la donnée d'entrée qui la déclenche, et l'effet observable.

Règle : la prime est majorée de 10 % au-delà de dix ans d'ancienneté. Deux questions restent ouvertes, et il faut les écrire plutôt que de les combler : l'ancienneté est-elle exprimée en années révolues, et pourquoi 10 % — texte réglementaire, accord d'entreprise, ou décision dont plus personne n'a la trace ?

Les codes retour méritent une attention particulière. Un MOVE 04 TO RETURN-CODE en fin de traitement ne dit rien par lui-même, mais le JCL appelant, lui, teste cette valeur pour décider si l'étape suivante s'exécute. La règle métier est donc répartie entre deux fichiers, et elle est invisible si on ne lit que le COBOL.

Chercher les valeurs codées en dur

Tout littéral numérique dans la PROCEDURE DIVISION est une décision métier figée dans le code. Un taux, un seuil, un plafond, une date pivot : ce sont les éléments les plus susceptibles de devoir changer, et les plus difficiles à retrouver ensuite.

Où regarder : les clauses VALUE de la WORKING-STORAGE, les littéraux dans les COMPUTE et les IF, et les tables internes définies avec OCCURS et remplies par des MOVE successifs — un barème entier peut y être dissimulé.

Pour chaque valeur trouvée, la question utile n'est pas « que vaut-elle » mais « qui décide de la changer et selon quelle source ». C'est la réponse à cette question qui manque presque toujours, et c'est elle qui bloque le jour où le taux évolue.

Écrire ce qu'on n'a pas pu déterminer

La dernière étape est celle qu'on saute, et c'est la plus utile. Une documentation qui délimite honnêtement ses angles morts vaut mieux qu'une documentation complète en apparence, parce qu'elle indique où il reste dangereux de modifier.

Quatre catégories à lister explicitement :

• Les COPYBOOKS référencés mais absents des sources fournies
• Les CALL dont la cible est une variable, donc non résolus statiquement
• Les valeurs en dur dont l'origine métier est inconnue
• Les dépendances hors code : tables de paramétrage, définitions de transactions, conventions d'exploitation

Pour chacune, notez qui pourrait répondre. C'est ce croisement — la question ouverte et la personne capable d'y répondre — qui mesure réellement la fragilité d'un système, bien plus que le nombre de lignes ou l'âge du code.