Sept éléments à  connaître sur l’écriture de programmes RPG modulaires

Des techniques standardisées sont souhaitables dans tout programme. Plus une application repose sur un code complexe et sortant de l’ordinaire, plus le programmeur de maintenance aura du mal à  comprendre la finalité du code. Si plusieurs programmes d’une application exécutent la même fonction, chacun avec son propre code, il est probable qu’un ou plusieurs d’entre eux connaîtront une défaillance ou produiront des résultats incohérents.
En principe, les programmes RPG isolent le code commun dans des sous-routines, utilisant parfois /COPY pour stocker le code commun dans des membres source distincts (mais souvent pas). En convertissant ces sous-routines communes en procédures, on garantit que les fonctions communes s’exécutent toujours à  partir du même code compilé, et renvoient toujours des résultats cohérents. Contrairement aux sous-routines, on peut profiter des procédures pour supporter des valeurs de renvoi, transmettre des paramètres à  des routines, et protéger des données dans des variables locales.
Les procédures permettent également d’externaliser toutes les fonctions d’I/O base de données présentes dans les applications. Au lieu de coder directement un READ, un CHAIN ou une autre opération à  chaque fois que le programme doit accéder à  la base de données, on peut exécuter une procédure chargée d’effectuer la fonction d’I/O de base de données. Cette technique présente un double avantage : elle facilite la gestion de modifications importantes de la base de données et offre une grande souplesse quant à  l’emplacement de la base de données dans un environnement client/serveur.
Mais ne perdez pas de vue que les procédures ne peuvent pas partager des curseurs SQL. De plus, les opérations d’I/O RPG sont simples à  coder, riches en fonctions et très efficaces. Il ne faut réserver l’externalisation des I/O qu’aux seuls cas où elle s’avère vraiment nécessaire, comme dans un environnement client/serveur.