Canevas pour réussir la mise en oeuvre des triggers

mise à  jour, ou suppression)
portant sur un certain fichier physique.
Quand ladite transaction se produit, le
programme trigger est appelé (déclenché)
automatiquement. Bien entendu, le
concepteur du trigger peut préciser
les conditions qui déterminent si le programme trigger sera déclenché et
quand, mais les concepteurs d’applications
ne peuvent pas contourner le trigger.
Si les conditions qui ont été définies
pour lui sont remplies, le trigger se déclenchera
indépendamment de la cause
de l’événement original concernant la
base de données. Le trigger se comportera
de la même manière, d’où qu’il soit
lancé: un programme RPG, une application
Java, ou un utilitaire de maintenance
de fichiers.

Vous pouvez écrire un programme
trigger dans la plupart des langages: RPG,
Cobol et CL. Même si vous penchez pour
des triggers en RPG, vous constaterez
souvent qu’un programme CL produit le
meilleur design. L’écriture de triggers en
CL peut faire intervenir plusieurs aspects
dans la conception du trigger.
Premièrement, l’application qui a provoqué
le déclenchement du trigger sera
suspendue pendant le traitement de celui-
ci. Comme le programmeur qui a écrit
l’application entraînant le déclenchement
d’un trigger ne sait peut-être même
pas qu’un trigger existe, il peut s’en suivre
des problèmes et des retards de performances
inexplicables pour l’utilisateur
final. C’est pourquoi il est souvent judicieux
d’utiliser un programme trigger CL
pour lancer un processus batch.

IBM, par exemple, utilise fréquemment
une application qui imprime ou
faxe une confirmation de commande
pour illustrer la structure du trigger. Mais
il n’y a pas de raison de suspendre le lancement
de l’application pendant que la
confirmation de commande s’effectue. Il
est bien plus efficace d’utiliser un trigger
CL pour soumettre un job qui exécute
une application d’impression ou de télécopie.