View Full Version : Trigger auf S36 Datei
Hi *all,
S36 ist schon etwas länger her, und m.e gab es da auch noch keine Trigger.
Evtl. muß ich auf einer V5R3 Kiste, die im 36 er Mode läuft
einige anpassungen machen. Idealer Weise würde ein Trigger die Aufgaben erledigen. Daher folgende Frage: Kann ich auf eine 36 er Datei (ich glaube das ist die Lib QS36F) einen Trigger legen der z.b. in eine andere Lib Teile der Daten in eine DB2 schreibt? Muß das OPM sein oder geht ILE. Sind die Trigger Parameter bei 36 er Dateien anders?
danke
Robi
Trigger sollten in ILE geschrieben sein, da du nur hier mit Pointern arbeiten kannst.
Die Übergabe für Trigger ist immer identisch, allerdings solltest du die Puffer-Adressen nicht statisch verwenden sondern dynamisch errechnen. Dies ist dann Releaseunabhängig.
ILE ist deshalb besser, da du hier eine eigene ACTGRP definieren kannst um mit *INLR = *OFF den Trigger nicht ständig zu initialisieren.
Hey Klasse, wenn ich die Antwort richtig interpretiere ist es der Kiste egal ob es eine 36 er Datei oder eine DB2 ist. Warsch. macht das Os400 da nicht mal einen Unterschied.
Und ILE ist eh die erste Wahl, wuste nur nicht ob ILE Programme im 36 mode laufen.
Also nochmal Danke
Robi
Hallo,
ILE ist deshalb besser, da du hier eine eigene ACTGRP definieren kannst um mit *INLR = *OFF den Trigger nicht ständig zu initialisieren.
Trigger (egal ob extern oder SQL) sollten niemals in einer eigenen/benannten Aktivierungsgruppe, sondern immer in Aktivierungsgruppe *CALLER laufen!
Grund ist Commitment Control und Transaktions-Sicherheit.
Ein Trigger hängt direkt an einer physischen Datei oder Tabelle (oder seit V5R4 an einer View). Es erfolgt ein Update in einem Programm in Aktivierungsgruppe X. Der Update aktiviert den Trigger in einer eigenen Aktivierungsgruppe Y. Update und Trigger-Aktion gehören zusammen, d.h. Update und Trigger müssen beide ausgeführt werden oder keines von beiden. Die Commitment-Steuerung ist mit Standard-Werten (also Commitment Scope *ACTGRP) gestartet.
Und jetzt ist ein Rollback erforderlich.
.... und der funktioniert nur innerhalb der Aktivierungsgruppe, in der er abgesetzt wurde!
... schade aber auch!
Auszug aus Redbook: Stored Procedures, Triggers and User Defined Functions (Kapitel 11.3.1. Commitment Control and Triggers):
To ensure the best level of data consistency, use commitment control in your applications. If your database design includes triggers, be aware of the implications of using commitment control for the resources accessed by the trigger programs. To avoid data integrity potential exposures, triggers and applications should share the same commitment definition. In this case, all the changes performed by triggers are committed or rolled back by the application
itself. The safest way to ensure that this happens is by compiling your triggers with ACTGRP(*CALLER). Triggers and applications should also share the same lock level.
If triggers run in a separate commitment control definition, they must commit or roll back their changes, since the application cannot do that. There are potential record-locking and consistency exposures in this situation. If the trigger terminates normally without committing its changes, the application cannot release the locks on those records.
Birgitta
Ich verwende auch Trigger in Alt-Anwendungen ohne Journalisierung (hängt nun mal vom Design ab).
Da hat es sich herausgestellt, dass in diesem Fall eine eigene Aktivierungsgruppe performanter ist.
Die Altanwendung arbeitet häufig mit RCLRSC/RCLACTGRP für die eigene, so dass die Triggerprogramme aktiv bleiben.
Es hängt nun mal vom Design ab.
Sicherlich ist das mit der Journalisierung korrekt, aber wenn die Zieldateien in einer anderen Lib mit einem anderen Journal stehen muss ich ja auch eine eigene Aktivierungsgruppe verwenden, damit dies überhaupt möglich ist (Anwendungsverknüpfung, Schnittstellen).
Beim Rollback müsste doch eigentlich genauso der Trigger mit umgekehrten Funktionen (Insert statt Delete, Before/After-Immage vertauscht usw.) aufgerufen werden um eben die nötigen Aktionen dann auch zurückzusetzen.
Das Problem ist sicherlich, dass der Trigger kein Commit/Rollback selber machen darf (oder geht das in einer eigenen Aktivierungsgruppe doch ?).
Es gibt ja auch Designlösungen, dass die Trigger nur Daten an DTAQ's für wartende Batchprogramme abgeben (eben aus Performancegründen).
Auch hier müsste ja ein Rollback korrekt abgehandelt werden können.