> Tech > Adopter ILE

Adopter ILE

Tech - Par Renaud ROSSET - Publié le 24 juin 2010
email

Le deuxième commandement du style RPG IV est, « RPG IV et ILE sont inextricablement liés entre eux et ne doivent jamais être séparés ».

Je grogne en silence chaque fois qu’un programmeur RPG (ou pis encore, un manager ou un consultant), me dit « J’utilise RPG IV, mais

Adopter ILE

sans trop m’occuper de tout cette liaison ». La syntaxe RPG IV, en même temps que ILE (Integrated Language Environment), encourage une approche modulaire de la programmation applicative. La modularité offre un moyen d’organiser une application, de faciliter la maintenance des programmes, de cacher la logique complexe et de réutiliser le code efficacement en cas de besoin.

Isoler le code réutilisable dans une procédure.Au lieu de monstres polyvalents et monolithiques, écrivez des unités de compilation monofonction plus petites et liez-les aux programmes qui en ont besoin. Eliminez toute duplication de code, même par petits morceaux : votre devise doit être « Une fois et une fois seulement ».

Reléguer tout code mystérieux dans une procédure bien nommée et bien documentée.Malgré tous vos efforts, il vous arrivera, dans de très rares occasions, de ne pas pouvoir expliquer clairement la signification d’un fragment de code, sans recourir à d’abondants commentaires. En séparant un tel code, amplement documenté et bien testé, dans une procédure, vous éviterez aux futurs programmeurs de maintenance la corvée de déchiffrer et de se colleter au code inutilement.

Utiliser les répertoires liants de manière homogène.Un répertoire liant est un objet qui aide à organiser les « morceaux » nécessaires pour créer un programme. L’utilisation d’un répertoire liant pour lister les modules ou les programmes de service souvent réutilisés empêchera un travail fastidieux et des erreurs, en vous permettant de faire référence au répertoire ou aux répertoires liants plutôt que de lister explicitement les composants nécessaires quand vous liez un programme avec la commande CRTPGM (Create Program) ou CRTSRVPGM (Create Service Program). Pour bien utiliser les répertoires liants, une stratégie homogène s’impose. La plus judicieuse serait peut-être d’avoir un répertoire liant générique qui fasse référence au code réutilisable qui traverse les applications, en même temps qu’un répertoire liant spécifique aux applications pour ce code, qui ne concerne qu’une application.

Packager dans des programmes de service, les procédures souvent réutilisées.Le programme de service est un moyen élégant de réutiliser des procédures sans les copier physiquement dans chaque programme qui en a besoin. En règle générale, si une procédure est amenée à apparaître dans plus d’un ou deux programmes, il faut la packager dans un programme de service.

Utiliser le langage binder pour contrôler la signature d’un programme de service. Il est tentant de laissant le binder traiter la signature du programme de service, en spécifiant EXPORT(*ALL) sur la commande CRTSRVPGM. Mais, à long terme, cette façon de faire fera de la maintenance un cauchemar. Le source du langage binder vous permettra de contrôler explicitement la signature d’un programme de service et, plus important, permettra à celuici de maintenir de multiples signatures. Grâce à cela, vous pourrez apporter des changements importants à un programme de service – en ajoutant, changeant et supprimant des procédures – sans jamais toucher aux programmes qui utilisent le programme de service.

Utiliser les possibilités de prototypage du RPG IV pour définir les paramètres et les interfaces de procédure. Les prototypes (définitions PR) et les interfaces de procédure (définitions PI) présentent de nombreux avantages quand on transmet des données entre des modules et des programmes. Ainsi, ils évitent des erreurs d’exécution en donnant au compilateur la possibilité de vérifier le type de données et le nombre de paramètres. Les prototypes vous permettent aussi de coder des littéraux et des expressions comme des paramètres, de déclarer des listes de paramètres (même la *ENTRY PLIST) dans les D-specs, et de transmettre des paramètres par valeur et par référence lecteur seule, ainsi que par référence.

Stocker les prototypes dans des membres /COPY.Pour chaque module, codez un membre /COPY contenant le prototype de procédure pour chaque procédure exportée dans ce module. Puis incluez une référence à ce module /COPY dans chaque module qui se réfère aux procédures dans le module appelé. Cette pratique vous évite de taper les prototypes chaque fois que vous en avez besoin et réduit les erreurs. Plutôt que d’avoir beaucoup de petits membres /COPY, songez à un membre /COPY qui contiendra les prototypes pour toutes vos procédures réutilisables ou pour la plupart d’entre elles.

Vous pourriez aussi explorer les directives de compilation conditionnelle du RPG, afin de pouvoir utiliser le prototype de la source de procédure actuelle au lieu d’utiliser un membre /COPY universel. Cette technique évitera d’introduire des prototypes non utilisés dans le processus de compilation (même si la présence de prototypes inutilisés pendant la compilation n’entraîne pas de pénalités à l’exécution).

Inclure des déclarations constantes pour un module dans le même membre /COPY que les prototypes pour ce module.Si vous référencez ensuite le membre /COPY dans l’un des modules qui fait référence au module appelé, vous avez en fait « globalisé » les déclarations de ces constantes.

Utiliser IMPORT et EXPORT uniquement pour des éléments de données globaux.Les mots-clés IMPORT et EXPORT permettent de partager des données entre les procédures d’un programme sans passer explicitement les données en tant que paramètres. Autrement dit, elles fournissent une « interface cachée » entre les procédures. Limitez l’utilisation de ces mots-clés aux éléments de données qui sont vraiment globaux dans le programme : généralement des valeurs définies une fois puis jamais changées.

Téléchargez cette ressource

Guide de Sécurité IA et IoT

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.

Tech - Par Renaud ROSSET - Publié le 24 juin 2010