> Tech > Programmes de service

Programmes de service

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

par Brad Behle, Mis en ligne le 29/03/2006 - Publié en Octobre 2005

Vous vous interrogez peut-être sur la nécessité des programmes de service. En effet, vous pouvez facilement écrire des programmes offrant les mêmes prestations que les procédures présentes dans les programmes de service.Certaines raisons relèvent de la simple commodité :

  • des programmes de service, on a moins de soucis avec les listes de bibliothèques pour appeler des programmes.
  • Avec des programmes de service, on peut avoir un seul objet avec des milliers de procédures plutôt qu’une bibliothèque avec des milliers de programmes.
  • Avec des programmes de service, on a plus de liberté pour concevoir l’interface vers les routines (programmes ou procédures). On peut transmettre les paramètres par valeur et par valeurs de renvoi, de préférence à des paramètres de sortie.
  • Avec des programmes de service, si l’on change l’interface de manière incompatible, on peut faire en sorte que les programmes créés avec l’ancienne interface ne puissent pas fonctionner correctement. (Heureusement, c’est très rare.)
Quant à moi, je considère que le principal avantage des programmes de service est qu’ils donnent le moyen de tenir certaines choses privées. Je ne parle pas des données privées qu’il faut protéger contre l’accès non autorisé. Mais plutôt des interfaces de paramètres et des structures de données réservées à un petit ensemble de routines. S’il n’y a qu’une poignée de routines utilisant des interfaces de paramètres, les programmeurs peuvent les changer en toute liberté.

En revanche, si les routines sont des programmes, ces derniers peuvent être appelés par des acteurs non prévus. Il est difficile d’estimer s’il est prudent de changer les paramètres ou les structures de données, si l’on ne sait pas exactement qui appelle le programme. Si les routines sont des procédures dans un programme de service, vous pouvez empêcher physiquement quiconque se trouve à l’extérieur du programme de service, d’appeler vos procédures « internes ».

Quand on crée un programme de service, on indique au système quelles procédures devraient être exportées à partir du programme de service. Les éventuelles procédures non exportées explicitement sont invisibles à quiconque se trouve hors du programme de service. On ne peut même pas les voir à l’aide de la commande DSPS RVPGM (Display Service Program).

A titre d’exemple, supposons plusieurs programmes qui calculent l’intérêt par des règles différentes. Ces programmes utilisent tous un programme d’aide pour traiter les calculs principaux, en utilisant une structure de données pour transmettre les contrôles de calcul. A l’exception des programmes de calcul d’intérêt, il n’est pas prévu qu’un autre programme appelle le programme d’aide. Mais, un beau jour, un programmeur de maintenance en perdition aura peut-être la brillante idée de corriger un problème à la hâte, en appelant le programme d’aide directement.

Résultat : une dépendance cachée sur votre interface qui ne change pas. Au lieu de cela, si vous aviez toutes ces routines sous forme de procédures dans un programme de service, vous pourriez empêcher l’accès indésirable par le simple fait de ne pas exporter la procédure d’aide depuis le programme de service.

Pour cet exemple, les procédures seront plutôt simples et nous pourrons nous concentrer sur le programme de service lui-même. Celui-ci offre certaines procédures permettant d’ajouter des valeurs à des nombres.

Pour commencer, nous allons créer la version initiale du programme de service MATHUTIL avec deux modules appelés ADD et HDLERR. ADD a deux procédures exportées qui ont pour mission d’ajouter (respectivement) 1 et 5 à une valeur. (L’une des procédures contient une erreur volontaire : résistez à la tentation de la corriger pour l’instant.) HDLERR a une procédure exportée unique qui signale des erreurs. Les figures 1-4 montrent les fichiers /COPY et le source module pour ces modules.

Notons que le fichier /COPY pour HDLERR (figure 2) a le prototype protégé par /IF DEFINED(MATHUTIL_PRIVATE et que ADD et HDLERR (figures 3 et 4) définissent tous deux MATHUTIL_ PRIVATE. Si chaque module dans MATHUTIL définit MATHUTIL_PRIVATE et si aucun autre module qui n’est pas dans MATHUTIL ne le définit, alors les prototypes privés ne seront visibles qu’aux modules qui seront capables d’appeler les procédures privées.

Notons également le mot-clé EXPORT sur la P-spec pour les procédures ; ce mot-clé EXPORT détermine si la procédure est exportée, ou non, depuis le module. Seules les procédures qui sont exportées depuis un module sont candidates pour être exportées depuis un programme de service.

L’étape suivante consiste à créer le programme de service lui-même. Cela demande un nouveau membre source de type BND. La figure 5 montre la première version du source de liage (binder source). Il est judicieux de garder ce source dans un fichier source appelé QSRVSRC.

Trois commandes sont utilisées dans le source binder : STRPGMEXP. La commande Start Program Export List est utilisée pour spécifier la signature du programme de service. Je reviendrai sur les signatures, mais, pour l’instant, nous utiliserons le nom du programme de service (‘MATHUTIL’) comme signature.

EXPORT. La commande Export a Program Symbol est utilisée pour afficher la liste des noms que l’on veut exporter depuis le programme de service. Dans le cas présent, nous voulons que nos utilisateurs puissent appeler les procédures ADD_1 et ADD_5, mais nous ne voulons pas qu’ils puissent appeler la procédure math_error. La commande EXPORT est similaire au mot-clé EXPORT sur la P-spec. Le mot-clé P-spec contrôle quelles procédures sont exportées depuis le module ; la commande EXPORT dans le source binder contrôle lesquelles de ces procédures exportées depuis les modules sont aussi exportées depuis le programme de service. Les noms exportés sont sensibles à la casse (majuscules/ minuscules). Il faut donc coder le nom exactement tel qu’il apparaît dans les exports de module. Le nom que vous avez entré dans votre source est peut-être différent ; par défaut, RPG met en majuscules les noms des procédures. Si vous utilisez DSPMOD DETAIL (*PROCEXP) sur votre module ADD, vous verrez que les procédures exportées sont nommées ADD_1 et ADD_5. Si vous aviez spécifié EXTPROC(‘add_1’), DSPMOD montrerait ADD_1 et vous spécifieriez EXPORT SYMBOL(‘add_1’) au lieu de EXPORT SYMBOL(‘ADD_1’). ENDPGMEXP. La commande End Program Export List termine la liste des exportations.

Ensuite, créez un programme CL pour créer votre programme de service. La figure 6 montre le source pour le programme CL. Nommez le membre source CL MATHUTIL afin que le programme chargé de créer le programme de service et le programme de service lui-même portent tous deux le même nom. Cela s’avèrera très commode par la suite.

A première vue, il semble que la création d’un programme CL séparé pour créer votre programme de service, demande plus de travail que la simple entrée de la commande CRTS RVPGM (Create Service Program), mais vous constaterez que la commande CRTSRVPGM demande beaucoup de frappe même s’il n’y a qu’un module. La raison principale d’utiliser un programme CL pour créer le programme de service est que ce dernier sera ainsi toujours créé correctement, sans que l’on doive deviner quels modules il faut inclure, quels programmes de service il faut lier, quels répertoires de liens il faut référencer et quel groupe d’activation il faut utiliser. Le programme suppose que le source et les modules pour votre programme de service se trouvent dans la bibliothèque SRCLIB. Un paramètre du programme permet de spécifier la bibliothèque qui contiendra votre programme de service. Il peut être aussi utile d’inclure les commandes CRTRPGMOD (Create RPG MODULE) pour votre programme de service dans le cadre du programme CL qui crée le programme de service.

A noter que la commande SRTSRVPGM spécifie explicitement le groupe d’activation. Par conséquent, le programme de service sera créé correctement même si quelqu’un change la valeur par défaut de la commande pour le paramètre ACTGRP.

Ensuite, appelez le programme CL pour créer votre programme de service. Affichez le programme de service en utilisant la commande DSPSRVPGM. Sur la première page DETAIL=* BASIC de l’information, on peut voir la signature du programme de service. Par défaut, la signature est affichée en hexadécimal pour le cas où elle contiendrait des caractères illisibles. Pour voir la signature sous forme de caractères, appuyez sur F11.

Appuyez sur Entrée jusqu’à atteindre la page DETAIL=*MODULE d’information. Sur cette page, avec l’option 5, vous pouvez voir des informations sur chaque module du programme de service, y compris le fichier source et le membre à partir duquel il a été construit.

Appuyez à nouveau sur Entrée pour atteindre la page DETAIL=* PROCEXP d’information. Vous pouvez voir les deux procédures ADD_1 et ADD_5. Pour qu’il soit commode d’appeler les procédures dans votre programme de service sans obliger les appelants à savoir exactement dans quels modules se trouvent les procédures, il est judicieux de fournir un fichier /COPY unique avec les prototypes pour toutes les procédures dans le programme de service. La figure 7 montre le fichier /COPY pour le programme de service MATHUTIL. Il a une instruction /COPY pour ADD et HDLERR. Comme ce fichier /COPY ne définit pas MATHUTIL_PRIVATE, les clients du programme de service MATHUTIL ne pourront pas « voir » le prototype pour la procédure privée math_error.

Pour qu’il soit commode à utiliser, votre programme de service doit se trouver dans un répertoire de liens. Si vous n’utilisez pas un répertoire binding, le programme de service doit être spécifié explicitement sur la commande CRTPGM (Create Program) pour chaque programme qui l’utilise. Si vous utilisez un répertoire binding, le mot-clé BNDDIR peut être utilisé dans la H-spec de tout module qui en a besoin. A titre d’exemple, voir le programme de test de la figure 8.

Si vous utilisez vos procédures de programme de service avec des langages comme C ou Cobol, qui n’ont pas le moyen de spécifier le répertoire binding dans le source, il est quand même bon de spécifier un répertoire binding unique plutôt que de spécifier plusieurs programmes de service sur la commande CRTPGM.

Si vous n’utilisez aucun répertoire binding, vous devez spécifier explicitement chaque programme de service dont vous avez besoin sur le paramètre BNDSRVPGM de CRTPGM. En mettant tous vos programmes de service dans le même répertoire binding, vous pouvez grandement simplifier la création de vos programmes, puisqu’il vous suffira alors de spécifier une valeur unique sur le paramètre BNDDIR de vos commandes CRTPGM, CRTBNDRPG (Create Bound RPG Program), CRTRPGMOD et CRTB NDCL (Create Bound CL Program).

La figure 9 montre les commandes permettant de créer le répertoire binding UTIL et d’ajouter le programme de service au répertoire binding.

Revenons maintenant à la figure 8 qui montre un exemple de membre source, pour tester le nouveau programme de service. Vous pouvez créer le programme en utilisant CRTBNDRPG, puisque le mot-clé BNDDIR dans la H-spec sera utilisé pour trouver le programme de service. Il n’est pas strictement nécessaire de spécifier ces mots-clés sur la H-spec, mais si vous n’avez pas utilisé de mots-clés H-spec, vous (et tous les autres) devront penser à spécifier les options à chaque utilisation de la commande CRTRPGMOD et CRTBNDRPG.

Après avoir créé le programme, vous pouvez utiliser la commande DSPPGM (Display Program) avec DETAIL (*SRVPGM) pour voir que le programme utilise le programme de service MATHUTIL avec la signature MATHUTIL ; là encore, appuyez sur F11 pour voir les signatures sous forme de caractères.

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.fr - Publié le 24 juin 2010