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.