Techniques avancées
Code réutilisable
Nous avons vu qu’il est important de ne pas répéter des lignes de code, dés que cela est possible, avec l’emploi des modules appelés via PERFORM. La portée de cette modularisation reste cependant limitée puisque la réutilisation se fait à l’intérieur d’un seul et même programme. Lorsque plusieurs programmes ont du code identique, il existe deux autres possibilités, à exploiter sans retenue :
-
les modules COPY, qui permettent de mutualiser du code où qu’il se trouve dans le programme,
-
les sous-programmes qui permettent de :
-
démultiplier la puissance de développement d’une application,
-
fiabiliser l’applicatif par isolement dans des sous-programmes des fonctions fréquemment utilisées, que ces fonctions soient d’ordre technique ou fonctionnel.
-
1. Modules COPY
Dans la première version de COBOL l’instruction prévue était l’instruction INCLUDE. Elle a ensuite été remplacée par l’instruction COPY mais l’instruction originelle INCLUDE a depuis été réutilisée, dans un autre contexte que nous verrons un peu plus loin.
Un module COPY contient des portions de code générique. Ce sont des instructions regroupées dans des fichiers sources à joindre avec le programme au moment de la compilation.
Syntaxe
----+----1----+----2----+----3----+----4----+----5----+----6----+
COPY Nom-Module-Copy
REPLACING ==:PREFIX:== BY ==Préfixe==
Le code générique des COPY peut être dans :
-
la DATA DIVISION :
-
FILE SECTION,
-
WORKING-STORAGE SECTION,
-
LINKAGE SECTION.
-
-
la PROCEDURE DIVISION.
a. Pour les déclarations
L’utilisation la plus courante des modules COPY concerne la déclaration des enregistrements des fichiers. Cette modularisation permet d’assurer la cohérence entre les différents programmes qui utilisent les mêmes fichiers quant à la structure de ces fichiers.
Exemple en environnement grand système IBM :
IDENTIFICATION DIVISION.
PROGRAM-ID. BC9000B.
ENVIRONMENT DIVISION.
CONFIGURATION SECTION.
SPECIAL-NAMES. DECIMAL-POINT IS COMMA.
INPUT-OUTPUT SECTION.
FILE-CONTROL.
*----Fichier en ENTREE-------------------------------------*
SELECT CHEWBACA ASSIGN TO CHEWBACA
FILE STATUS IS WS-FILE-STATUS-CHEWBACA....
Entrées-sorties
1. Appareillage
Pour d’importantes volumétries, comme c’est souvent le cas en environnement grand système, il faut toujours étudier la possibilité de mettre en place un traitement séquentiel performant : un appareillage entre fichiers, y compris en lieu et place de requêtes SQL d’accès à des bases de données.
Un appareillage peut être effectué entre deux fichiers ou plus, mais pour pouvoir être appareillés les fichiers doivent être triés sur le même critère : c’est sur ce critère que s’effectue leur rapprochement. Alors que dans un traitement standard il n’y a qu’un seul fichier maître, dans un appareillage il est possible que les différents fichiers appareillés soient des fichier maîtres. Au-delà de deux fichiers maîtres le code devient souvent trop complexe.
a. Cas pratique
Nous allons produire le code du module principal permettant de rapprocher deux fichiers ABT et CNN. Le critère de rapprochement se nomme REGUL pour le fichier ABT et TARIF pour le fichier CNN. Le fichier produit est appelé REQ.
L’appareillage à mettre en place est l’équivalent d’une jointure externe complète (FULL OUTER JOIN) : ne sont reconduites en sortie que les données des enregistrements dont les critères correspondent.
Codons tout d’abord le premier appel du module de lecture de chaque fichier :
PERFORM LECTURE-ABT
PERFORM LECTURE-CNN
Les deux fichiers sont des fichiers maîtres : si l’un ou l’autre est vide il n’y a pas de traitement.
Il faut ensuite coder la boucle de traitement : tant que ce n’est pas la fin de ABT ni de CNN...
PERFORM UNTIL FIN-ABT
OR FIN-CNN
[...]
END-PERFORM
Dans cette boucle de traitement il faut tester si :
-
REGUL et TARIF sont égaux, alors :
-
le fichier en sortie peut être écrit
-
il faut ensuite relire ABT et CNN
-
-
REGUL est supérieur à TARIF, alors :
-
pas de traitement : il faut relire CNN
-
-
REGUL est inférieur à TARIF, alors :
-
pas de traitement : il faut relire ABT
-
Module principal :
* Premières lectures
PERFORM LECTURE-ABT
PERFORM LECTURE-CNN
* Tant que non fin des fichers
PERFORM UNTIL FIN-ABT
OR FIN-CNN
EVALUATE TRUE
WHEN ABT-REGUL = CNN-TARIF
PERFORM ECRITURE-REQ
PERFORM LECTURE-CNN...
Mise en forme des données
1. Fonctions intrinsèques
Les fonctions intrinsèques ont été amenées par la version ISO 1989:1985 de 1989. Elles permettent de simplifier certaines opérations communes à tout type de traitement. Il y en a environ 42 (il y a de petites différences de nombre en fonction des compilateurs), réparties en 5 grandes familles fonctionnelles :
Le résultat de la fonction intrinsèque vient remplacer l’appel de la fonction à son emplacement occupé dans l’instruction COBOL.
Syntaxe :
FUNCTION Nom-de-la-fonction (Arguments)
C’est à l’exécution de l’instruction la contenant que la fonction est résolue : son résultat vient en lieu et place de son appel. Elles ne sont donc utilisables que dans des instructions compatibles avec le format du résultat qu’elles retournent :
-
une fonction retournant un résultat numérique ne peut être utilisée qu’avec des instructions de manipulation de zones numériques (la modification de référence est par exemple impossible),
-
une fonction retournant un résultat alphanumérique ne peut être utilisée qu’avec des instructions de manipulations de chaîne (un COMPUTE est impossible).
Pour certaines fonctions intrinsèques, c’est la forme des arguments passés en entrée qui détermine le format du résultat en sortie.
-
Fonctions de type numérique
Elles ne sont utilisables que dans une expression arithmétique.
Exemple : détermination du N° de jour (ou jour absolu) :
01 WS-DATE-AAAAMMJJ PIC 9(8).
01 WS-DT-INT PIC S9(9).
[...]
MOVE 20100701 TO WS-DATE-AAAAMMJJ
* Récupération du jour absolu
COMPUTE WS-DT-INT = FUNCTION
INTEGER-OF-DATE (WS-DATE-AAAAMMJJ)
La variable WS-DATE-AAAAMMJJ est valorisée avec 20100701 (1er juillet 2010) et le jour absolu sera récupéré dans la variable WS-DT-INT.
La date de référence par rapport à laquelle est calculé le nombre de jours est définie par le compilateur. Ce peut être le 31 décembre 1600, le 1er janvier 1601, le 15 octobre 1582…
Cela permet d’effectuer ensuite des calculs : ajouter...
COBOL et le transactionnel (CICS)
1. Présentation
Alors qu’en environnement PC les instructions ACCEPT et DISPLAY permettent à un programme COBOL d’être interactif, en environnement grand système IBM cette interaction est plus complexe. Historiquement le grand système n’est pas prévu pour avoir une interface graphique aussi élaborée qu’en environnement micro. L’interface homme-machine est un écran (généralement noir) en mode caractères d’une vingtaine de lignes sur environ 80 colonnes…
Le besoin d’interaction existe depuis longtemps c’est pourquoi IBM a mis au point dès 1969 son moniteur transactionnel CICS.
L’utilisateur, au travers d’un menu affiché à l’écran, peut choisir une transaction lui permettant d’effectuer les différentes opérations relatives à son activité : cela peut aller de la consultation de données à leur mise à jour. Il n’a cependant à disposition que cette notion de transaction : le/les programme(s) reste(nt) pour lui transparents. Lorsque le choix de la transaction est fait, CICS détermine le programme correspondant, le charge en mémoire et démarre une unité de traitement (Unit of Work) respectant les règles ACID :
-
A pour Atomicity : un traitement ne peut se terminer que dans deux états : OK, complètement bon ou KO : un problème est rencontré, aucune mise à jour n’est faite,
-
C pour Consistency : les modifications interviennent sur des données cohérentes et les laissent dans un état cohérent,
-
I pour Isolation : aucune interférence n’est possible entre une transaction et une autre,
-
D pour Durability : l’ensemble des mises à jour effectuées doit résister à un incident. Le résultat doit être définitif et visible de l’extérieur.
Il y a ensuite deux possibilités de traitement interactif :
-
Le mode conversationnel, particulièrement déconseillé : le programme envoie l’écran à afficher, se met en attente de la réponse, réceptionne celle-ci pour la traiter avant de renvoyer à nouveau...
En conclusion
COBOL n’est plus limité en aucune sorte : il évolue avec son temps, s’ouvre au monde, établit le lien entre passé, présent et futur. Le but recherché par Grace HOPPER était de rendre l’informatique, la programmation, accessible à toutes et à tous. Certes sa mise en œuvre en environnement grand système n’est pas aussi intuitive ni aussi rapide qu’en environnement PC, mais la situation est en train d’évoluer et COBOL reste un langage qui permet de produire des applications fiables et pérennes. La démarche d’un programmeur COBOL est spécifique : structurer sa pensée pour pouvoir structurer son programme est un exercice difficile mais au combien satisfaisant lorsqu’il est réussi. La recherche de la simplicité dans la forme doit être le maître mot : c’est la garantie d’un code durable. Mais plus le fond est complexe, plus cette simplicité est difficile à atteindre : COBOL, aujourd’hui, s’interconnecte avec tous les autres langages, sur toutes les plates-formes matérielles, avec tous les SGBD, avec toutes les couches du système d’information… Ce sont chaque jour de nouveaux défis que doivent relever les éditeurs logiciels, les constructeurs et les développeurs COBOL :
"Be innovative, open minded...