CL en version 5

Comme on le voit en A et B de la figure 9, cette amélioration permet au développeur CL de déclarer et d’initialiser directement les variables binary/integer &Len_SBSI et &EC_Byt-Prv, simplifiant ainsi les DCL en A et B de la figure 9 et dispensant d’utiliser les CHGVAR en C de la figure 9.

(((IMG6711)))
Figure 9 : Appeler l’API QWDRSBSD et traiter les données caractères et binaires en utilisant les possibilités CL 5.3

Sans relation directe avec cet article, signalons aussi que la i 5.3 prend en charge les commandes DOFOR, DOWHILE, et DOUNTIL. En C de la figure 10, vous voyez comment DOUNTIL peut dispenser du label LOOP et de la commande GOTO associée que l’on trouvait dans les versions antérieures du CPP DSPSBSDFN.

Dans la foulée de cette amélioration 5.3, la i 5.4 a changé la manière dont les données peuvent être déclarées avec CL—il s’agit du stockage *DEFINED. Son impact apparaît dans la figure 10.

(((IMG6715)))
Figure 10 : Appeler l’API QWDRSBSD et traiter les données caractères et binaires en utilisant les possibilités CL 5.4

Le stockage Defined permet de définir des sous-champs d’une variable plus grande, de la même manière que vous pouvez définir des structures de données RPG ou des éléments de données subordonnés COBOL. Dans ce cas, A dans la figure 11 montre comment redéfinir l’information renvoyée par l’API QWDRSBSD dans la variable réceptrice &SBSI0100, comme des variables CL distinctes. Par exemple, le sous-champ (ou sous-variable) &SBS_Name est défini comme démarrant à l’emplacement 9 de la variable &SBSI0100 et représente une variable *CHAR de longueur 10. C’est l’équivalent du champ nom de description Subsystem que l’on voit dans la figure 6. L’intérêt de cette redéfinition est l’élimination des built-ins %sst et %bin en B de la figure 11 lors du traitement des résultats de l’appel de l’API QWDRSBSD. Les commandes IF et CHGVAR en B de la figure 11 sont, selon moi, plus simples et plus rapides à comprendre (et moins sujettes à erreur) que les méthodes %sst et %bin utilisées avant la 5.4. Bien que les noms et les emplacements dans le mot-clé DEFVAR des souschamps *DEFINED soient la même information que vous fournissez avec les built-ins %sst et %bin, ils se trouvent tous désormais dans les DCL du programme et non plus disséminés dans sa logique de traitement. Autre avantage : l’utilisation des variables *DEFINED avec CHGVAR est un peu plus rapide que l’usage des built-ins %sst ou %bin. Cet ensemble de caractéristiques—plus facile à lire, plus facile à déboguer (par exemple, eval du sous-champ &SBS_Cur-Job plutôt que &SBSI0100 quand on utilise la fonction debug du système), et plus rapide à exécuter —montre tout l’intérêt du stockage*DEFINED.

Quelles que soient les qualités du stockage *DEFINED, il faut souligner que les built-ins %sst et %bin gardent toute leur place dans votre outillage de développement. Le stockage *DEFINED vous oblige à connaître, au moment de la compilation, l’emplacement du sous-champ dans la variable CL plus grande. En revanche, les built-ins vous permettent de spécifier l’emplacement d’une variable CL où la valeur est déterminée à l’exécution. Dans bien des cas, comme pour le paramétrage et les variables réceptrices API, vous connaîtrez l’emplacement à l’avance. Mais pour certains types d’applications, vous ne le connaîtrez qu’au moment où vous traiterez réellement le contenu de la variable CL plus grande.