par Brian R. Smith
Un nouveau RedBook révèle une profusion de techniques de programmation en RPG IV
De temps à autres, on a la chance de travailler sur un projet vraiment d'actualité. Ce fut le cas en juillet de l'année dernière lorsque j'ai collaboré avec cinq co-auteurs à la rédaction d'un Redbook à propos de la programmation en RPG IV, juste au moment où Roger Pence publiait son article " It's Time for IBM to Pull the Plug on RPG " (Il est temps pour IBM de débrancher la prise du RPG, NEWS/400, juillet 1999). Comme notre ouvrage souligne que le RPG IV est un langage moderne et dynamique pour le développement d'applications au 21e siècle, c'est avec surprise que nous avons lu que le RPG est " en état de coma profond dont il ne sortira pas ".
A notre avis, le RPG est comme le vin rouge : il se bonifie avec l'âge. Notre livre commence par une section Questions/Réponses regroupant un panel de six programmeurs RPG éminents venus du monde entier (y compris Bryan Meyers, rédacteur technique de NEWS/400). Quand nous leur avons demandé " le RPG est-il mort ? ", ils ont répondu d'une seule voix " Non ! " En fait, bien que tous les membres à une exception près aient récemment entrepris des projets Java, C ou C++, tous s'en tiennent au RPG IV comme langage principal.
Même si le RPG n'est pas le plus beau langage au monde, son adaptabilité et son utilité prolongeront sa présence dans l'environnement AS/400 pendant de nombreuses années. Nous avons écrit notre livre à l'intention des programmeurs système AS/400 cherchant à justifier le passage du RPG/400 au RPG IV. Il est plein de petites merveilles que même les programmeurs RPG IV chevronnés apprécieront.
Une nouvelle avancée pour le RPG
Quand nous avons demandé à notre panel » Quel est le plus gros problème résolu par le RPG IV que vous n’auriez pas pu résoudre avec ses anciennes versions ? « , ils ont répondu en choeur : » Les sous-procédures ! »
Les sous-procédures ne sont pas une nouveauté. Le RPG IV est devenu capable de définir des procédures multiples par module dans les versions V3R2 et V3R6. Alors pourquoi sont-elles autant d’actualité ? La réponse est que les sous-procédures permettent l’encapsulation c’est à dire l’occultation de données délimitées localement derrière la transmission de paramètres, ce qui permet aux programmeurs de créer des routines effectuant des tâches spécifiques, puis de coder d’autres programmes qui appellent ces routines si nécessaire (au lieu de dupliquer la logique des sous-procédures dans de multiples programmes). En éliminant la plupart des effets secondaires qu’entraîne le changement des variables globales, l’encapsulation simplifie la maintenance.
Le point fort de l’encapsulation est la capacité de prototyper l’interface (c’est-à -dire les paramètres transmis) entre une sous-procédure appelée et le programme appelant. Cette pratique permet au compilateur de vérifier le nombre et le type des paramètres du programme appelant et permet aux sous-procédures de détecter les erreurs à la compilation plutôt qu’à l’exécution.
Le Redbook s’intéresse longuement au coding des sous-procédures en RPG IV. Il fournit bien sûr de nombreux exemples de programmation, mais décrit également les quatre étapes de transformation des sous-routines en sous-procédures :
1. Retirer les instructions BEGSR/ENDSR de la sous-routine et indiquer la valeur de retour en Facteur2.
2. Ajouter les cartes P de la procédure de début et de fin et l’interface de procédure.
3. Définir le prototype.
4. Remplacer l’instruction EXSR de la procédure principale par l’appel de la sous-procédure.
Téléchargez cette ressource
Guide de Sécurité IA et IoT
Compte tenu de l'ampleur des changements que l'IA est susceptible d'entraîner, les organisations doivent élaborer une stratégie pour se préparer à adopter et à sécuriser l'IA. Découvrez dans ce Livre blanc Kaspersky quatre stratégies efficaces pour sécuriser l'IA et l'IoT.
