Blog ENI : Toute la veille numérique !
-25€ dès 75€ sur les livres en ligne, vidéos... avec le code FUSEE25. J'en profite !
Accès illimité 24h/24 à tous nos livres & vidéos ! 
Découvrez la Bibliothèque Numérique ENI. Cliquez ici
  1. Livres et vidéos
  2. Programmer en COBOL
  3. Techniques avancées
Extrait - Programmer en COBOL Développement et Maintenance de programmes
Extraits du livre
Programmer en COBOL Développement et Maintenance de programmes
5 avis
Revenir à la page d'achat du livre

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 :

05CBL15.png

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…

La déclaration de la zone réceptrice dépend également du compilateur.

Cela permet d’effectuer ensuite des calculs : ajouter...

COBOL et le transactionnel (CICS)

1. Présentation

CICS n’est pour l’instant pas compatible avec le COBOL Objet.

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…

05cbl07.png

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...