> Tech > Prototyper tous les appels

Prototyper tous les appels

Tech - Par iTPro - Publié le 24 juin 2010
email

Vous devriez prototyper tous les appels, qu’ils soient dynamiques ou statiques. C’est-à-dire remplacer toutes les opérations CALL et CALLB par des opérations CALLP. Le prototypage présente plusieurs avantages : une interface standard pour tous les appels, un moyen de valider les paramètres, et des facilités (valeurs de constantes et expressions,

par exemple) qui ne se trouvent pas dans les listes de paramètres standard.

Les sources de tous les modules d’une application devraient contenir une directive copy unique pour inclure tous les prototypes pour toutes les procédures pouvant être appelées à partir d’une autre procédure (c’est-àdire les programmes ou sous-procédures exportées), et ce quels que soient les prototypes nécessaires. Le fait qu’une compilation puisse inclure un millier de prototypes non utilisés est sans importance. En effet, un prototype n’est utilisé que par le compilateur et ne demande ni stockage ni code d’exécution. Il se traduira par un plus long listing de compilation, mais qui donc lit un listing de compilation quand RSE est utilisé ?

Il faut savoir qu’une application peut aboutir à des milliers de prototypes et qu’un seul membre source contenant tous les prototypes de l’application deviendra rapidement ingérable. Le point important est que tous les programmes ne devraient avoir qu’une directive copy pour inclure tous les prototypes. Les directives copy imbriquées simplifient la maintenance des prototypes. Le membre copy dans toute source contient des directives copy pour inclure les membres suivants :

• un membre copy contenant des prototypes pour tous les appels dynamiques
• un membre copy par programme de service contenant des prototypes pour toutes les procédures exportées depuis le programme de service
• pour de très grands programmes de service, un membre copy par module dans le programme de service et un membre copy pour le programme de service qui contient des directives copy pour tous les membres prototypes du module

La figure 7 montre un exemple de membre copy (PROTOTYPE) inclus dans chaque membre source. PROTOTYPE contient des directives copy pour les autres membres. PROTOFILE et PROTOMSG concernent les prototypes dans les programmes de service et ont une directive copy par module dans le programme de service. Chacun de ces membres copy (c’est-à-dire PFILE01A, PFILE02A, PFILE03A, PMSG01A, PMSG02A) contient les prototypes des procédures exportées à partir du module.

On a alors un double avantage : une seule directive copy est nécessaire pour inclure tous les prototypes, mais les prototypes eux-mêmes sont stockés dans de multiples membres faciles à gérer.

Mais pourquoi s’arrêter aux prototypes ? Pourquoi ne pas inclure des membres copy contenant les définitions standard des structures de données et des constantes nommées ? Tout cela peut être inclus avec une directive copy seulement

Téléchargez gratuitement cette ressource

IBMi et Cloud : Table ronde Digitale

IBMi et Cloud : Table ronde Digitale

Comment faire évoluer son patrimoine IBMi en le rendant Cloud compatible ? Comment capitaliser sur des bases saines pour un avenir serein ? Faites le point et partagez l'expertise Hardis Group et IBM aux côtés de Florence Devambez, DSI d'Albingia.

Tech - Par iTPro - Publié le 24 juin 2010