Groupes d’activation et programmes de services

manière que les autres. Par conséquent, les groupes d’activation ne sont pas abordés pareillement dans les deux cas.

Comme les programmes de service sont toujours utilisés comme des « sous-programmes » qui fournissent quelques fonctions utilitaires à une routine appelante, je suggère de toujours utiliser ACTGRP(*CALLER) pour un programme de service. Seule exception : quand on a des programmes dans de multiples groupes d’activation qui doivent partager une copie d’un programme de service. Dans ce cas, il vaut mieux choisir un groupe d’activation nommé mais, d’après mon expérience, c’est un cas peu fréquent.
ACTGRP(*NEW) n’est jamais un bon choix pour un programme de service, donc la commande CRTSRVPGM ne vous permet pas de spécifier *NEW pour le paramètre ACTGRP.

Bien qu’il soit techniquement possible d’utiliser le cycle RPG dans un programme de service, je n’ai jamais vu personne le faire. Dans la pratique, les programmes de service sont écrits comme un ensemble de sous-procédures réutilisables et ils n’ont pas de procédure principale. Sans procédure principale, pas de cycle RPG. Il s’en suit que le fait d’activer l’indicateur LR ne ferme pas les fichiers dans le programme de service. Ils ne sont pas non plus ouverts automatiquement au démarrage du programme.
Il est une bonne utilisation des groupes d’activation :
pour fermer automatiquement les fichiers dans votre programme de service. Vous pouvez même utiliser une API pour enregistrer une sous-procédure qui sera appelée quand un groupe d’activation se terminera, et utiliser cette sousprocédure pour accentuer le nettoyage.

Le code d’un programme de service appelé ITEMS (figure 3) fournit des utilitaires pour travailler avec les articles que votre société pourrait vendre. J’ai converti le code du programme GETDESC (figure 2) en une sousprocédure appelée items_getDesc() dans le programme de service (A en figure 3). Il y a aussi une routine appelée items_getInventory() (en B) qui compte la quantité en stock d’un article donné.

Le programme de service ITEMS contient deux autres sous-procédures. L’une s’appelle items_open() (en C) ; elle ouvre tous les fichiers qu’utilise le programme de service ITEMS. Une autre est appelée items_close() (en E) ; elle ferme ces fichiers.

Chaque fois que l’une des routines items_getDesc() ou items_getInventory() est appelée, elle appelle items_open() pour s’assurer que les fichiers sont ouverts. De sorte que le programme appelant n’a pas besoin d’appeler directement items_open().

La routine items_open() appelle l’API Register Activation Group Exit Procedure (CEE4RAGE) pour dire au système qu’elle veut que la sous-procédure items_close() soit appelée quand le groupe d’activation est récupéré (en D). Ce faisant, le programme appelant n’a jamais besoin d’appeler directement items_close(), lui non plus. Du fait que les fichiers sont fermés dès la fin du programme de service, il est inutile (strictement parlant) de fermer les fichiers avec le code opération CLOSE quand le groupe d’activation se termine. De toute façon, j’aime les fermer explicitement pour rendre plus clair ce que fait le programme.

Les routines items_open() et items_close() font un bon travail pour tout ce que vous voulez faire automatiquement quand un programme de service démarre et quand il se termine.