Les sous-procédures tirent vraiment profit d’ILE en RPG. Dans ILE, on veut une vraie modularisation, et les sous-procédures la rendent possible en RPG.
En ILE, plus c’est petit, mieux c’est. A mon avis, il faut que toutes les specs de calcul d’une sous-procédure soient visibles dans une fenêtre
Tout est une question de sous-procédures
de RSE (c’est-à-dire, 35 à 40 lignes de code). Considérez une sous-procédure comme un « programme » appelable et testable. Il est plus facile de modifier et de tester un programme de 40 lignes que de modifier et tester une sous-routine dans un programme de 1 000 lignes. La réduction du code en unités aussi petites demande une certaine habitude et est en tout cas très éloignée de notre pratique habituelle en programmation RPG classique. La sous-procédure présente aussi un autre aspect intéressant. Après l’écriture des sous-procédures, il faut apprendre à les utiliser. Pour travailler dans un environnement de développement ILE, il faut vraiment y croire. Le code source de vos applications actuelles est à la disposition de tous et, quand vous ne savez pas vraiment comment un programme fonctionne, il suffit d’examiner le source. Rien de tel dans le monde de ILE ! Dans l’environnement ILE, vous écrivez de multiples sous-procédures appelables et vous devez considérer que ces sous-procédures sont toutes des BIF (built-in functions) d’applications. De la même manière que vous ne vous intéressez pas au code derrière l’une des BIF du langage (par exemple %SUBST), vous ne devriez pas vous intéresser au code derrière une BIF d’application. C’est l’une des choses les plus difficiles à assimiler par les programmeurs RPG, et c’est l’essentiel de l’apprentissage et du désapprentissage.
Une application ILE est constituée de procédures appelables (programmes RPG, sous-procédures RPG, fonctions C, par exemple). Comment le programmeur que vous êtes peut-il savoir quelles procédures sont disponibles et quels paramètres sont requis ? La fonctionnalité de RSE (comme on le voit dans les figures 1, 2 et 3) vous aide à déterminer la manière d’utiliser une procédure, mais pas à en choisir une. Il vous faut un mécanisme permettant de documenter toutes les procédures qui peuvent être appelées à partir d’une autre procédure (c’est-à-dire des programmes ou des sous-procédures exportées).
Téléchargez cette ressource

État des lieux de la sécurité cloud-native
L’État des lieux de la sécurité cloud-native vous offre une analyse complète des problématiques, des tendances et des priorités qui sous-tendent les pratiques de sécurité cloud-native dans le monde entier. Une lecture indispensable pour renforcer votre stratégie de sécurité dans le cloud. Une mine d’infos exclusives pour élaborer votre stratégie de sécurité cloud-native.
Les articles les plus consultés
Les plus consultés sur iTPro.fr
- Les risques liés à l’essor fulgurant de l’IA générative
- Pourquoi est-il temps de repenser la gestion des vulnérabilités ?
- Reporting RSE : un levier d’innovation !
- De la 5G à la 6G : la France se positionne pour dominer les réseaux du futur
- Datanexions, acteur clé de la transformation numérique data-centric
