Quand l'information envoyée avec un buffer de trigger ne suffit pas, les programmes
de service de type "tableaux noirs" peuvent relayer des données supplémentaires
entre applications et programmes triggers
Avant les panneaux de messages et la diffusion de courriers électroniques, on
utilisait des tableaux noirs pour afficher les informations importantes sur les
lieux publics. Aujourd'hui encore, les professeurs utilisent des tableaux noirs
face à leurs élèves, et comment, sans eux, les bistrots annonceraient-ils leur
plat du jour ? Vous ne savez peut-être pas que ces applications et les programmes
triggers qu'elles invoquent peuvent aussi recourir à une technique que je baptise
tableau noir pour échanger des informations.
Si vous n'avez besoin (outre les informations contenues dans le buffer de trigger)
que du nom du programme applicatif ayant déclenché le trigger, un tableau noir
est peut-être superflu. Il existe un moyen plus simple d'obtenir le nom de l'application
: envoyer un message fictif du trigger à l'application, puis extraire le message.
Pour plus d'informations à ce sujet, lisez “ Offrez la présentation du numéro
à vos programmes ”, NEWSMAGAZINE, avril 1999. En revanche, s'il vous faut relayer
des informations supplémentaires entre une application et son trigger, un tableau
noir est peut être parfaitement indiqué.
Utilisation de tableaux noirs avec des programmes trigger
Commençons par un examen rapide des triggers AS/400. Un trigger (ou déclencheur)
est un programme écrit par vous, pour être invoqué (ou “ déclenché ” automatiquement
par DB2/400 quand une action — insertion, mise à jour ou suppression d’un enregistrement
— intervient dans la base de données. Avec la commande AddPFTrg (Add Physical
File Trigger), on définit l’invocation d’un trigger en combinant librement les
six situations : avant une insertion, avant une mise à jour, avant une suppression,
après une insertion, après une mise à jour et après une suppression.
DB2/400 transmet deux paramètres au programme trigger : le buffer de trigger et
sa longueur. Le buffer de trigger contient beaucoup d’informations utiles, dont
le nom et la bibliothèque du fichier, la situation (parmi les six indiquées ci-dessus)
ayant causé le déclenchement du trigger, l’information de contrôle d’activation,
et les images des anciens et nouveaux enregistrements. Mais parfois, cela ne suffit
pas, car on souhaite communiquer davantage d’informations que le buffer de trigger
ne le permet entre une application et un trigger. Voyons un exemple de ce type
de situation. (Pour plus d’informations sur les programmes trigger, voir notre
« Bibliographie ».)
Téléchargez cette ressource
Plan de sécurité Microsoft 365
Les attaquants savent comment prendre le contrôle de votre tenant Microsoft 365, et vous, savez-vous comment le reprendre en main ?
Les articles les plus consultés
Les plus consultés sur iTPro.fr
- Reprendre le contrôle de son SI : la clé d’un numérique à la fois souverain et responsable
- Splunk : vers un SOC agentique et de confiance
- Le trilemme de la souveraineté : le coût caché du cloud qui freine l’IA en Europe
- Moderniser le développement logiciel : de la fragmentation à l’intégration
Articles les + lus
Femmes et métiers de la tech : une attractivité réelle freinée par des stéréotypes persistants
Moderniser le développement logiciel : de la fragmentation à l’intégration
Analyse Patch Tuesday Mars 2026
Une nouvelle ère de la modernisation du mainframe
Communes, entreprises ? Non, face au RGAA 5, l’IA seule ne rendra pas vos sites accessibles
À la une de la chaîne Tech
- Femmes et métiers de la tech : une attractivité réelle freinée par des stéréotypes persistants
- Moderniser le développement logiciel : de la fragmentation à l’intégration
- Analyse Patch Tuesday Mars 2026
- Une nouvelle ère de la modernisation du mainframe
- Communes, entreprises ? Non, face au RGAA 5, l’IA seule ne rendra pas vos sites accessibles
