La jungle du tableau noir

verra quand il sera invoqué
dans un tableau noir. Le trigger peut aussi placer des données que l’application
verra à  la fin de l’exécution du trigger dans le tableau noir (la figure 1 illustre
le concept du tableau noir.)

Un tableau noir utilise les exportations de données d’un programme de service
(procédures et données mises à  la disposition des programmes qui utilisent un
programme de service) pour exporter uniquement des données. Tous les programmes
d’une pile d’appels qui accèdent à  un programme de service donné ont accès aux
mêmes données exportées. Un programme RPG référence les données exportées à  partir
d’un programme de service en les définissant dans en cartes D, exactement comme
elles sont définies dans le programme de service, excepté l’utilisation du mot
clé Import (le programme de service définit les mêmes données, mais il utilise
le mot clé Export.)

Les tableaux noirs ne sont pas le seul moyen de communiquer des informations supplémentaires
entre une application et un trigger. On peut aussi utiliser une zone de données
par exemple, ou une file d’attente de données, voire un fichier base de données
normal. Mais ces méthodes n’ont ni la simplicité ni l’élégance d’un tableau noir.
De plus, elles sont plus lentes parce qu’il leur faut un certain type de service
pour obtenir l’accès.

Ainsi, si l’on met en oeuvre la communication application/programme avec une zone
de données, il faut utiliser l’instruction RPG In. Le RPG doit donc extraire la
valeur courante de la zone de données (la situation est la même avec une file
d’attente de données, une file d’attente utilisateur, ou même un fichier base
de données.) Tandis qu’avec un tableau noir, l’application et le trigger accèdent
aux données du tableau noir aussi rapidement que s’il s’agissait de leurs propres
données locales.