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