Trigger Programm ändern

[svit]

Hallo *all,

besteht die Möglichkeit Bibliotheksname der Auslöser- bzw. Triggerprogramm zu ändern?

[B.Hauser]

Hallo *all,

besteht die Möglichkeit Bibliotheksname der Auslöser- bzw. Triggerprogramm zu ändern?

Reden wir über SQL oder System Trigger?

System Trigger Programme können natürlich geändert und ausgetauscht werden. Allerdings können diese nur dann ausgetauscht werden, wenn die Tabelle/Datei für die sie registriert sind nirgends im Zugriff sind, d.h. es werden Exklusiv-Rechte benötigt.

In SQL Triggern wird die Bibliothek (zumindest für den unqualifizierten Datenzugriff) zum Erstellungszeitpunkt ermittelt und in das Routine-Objekt integriert. Sofern Bibliotheken innerhalb der Quelle verändert werden müssen, muss der Trigger neu erstellt werden. Auch hierfür werden Exklusiv-Rechte benötigt.

Birgitta

[svit]

ich habe programmtrigger
in der Dateibeschreibung steht Bibliotheksname wo das Triggerprogramm stand. Jetzt möchte ich nur die Bibliotheksname ändern.

[svit]

...

vergesen

natürlich greift keiner auf die Dateien zu , ich habe alle rechte.

[B.Hauser]

...

vergesen

natürlich greift keiner auf die Dateien zu , ich habe alle rechte.

Darauf zugreifen, heißt, dass zu dem Zeitpunkt an dem das Trigger-Programm ausgetauscht wird kein anderer Job die Datei im Zugriff haben darf, d.h. es darf kein Programm laufen das die Datei verwendet, keine SQL-Abfrage ausgeführt werden, es darf noch nicht einmal ein ODP (Open Data Path) auf die Datei offen sein.

Du kannst ja mal versuchen ob Du Dir mit dem CL-Befehl ALCOBJ die Datei zur exklusiven Verwendung (Sperrstatus *EXCL) deinem Job zuordnen kannst.

... und Du kannst nur das "alte" Trigger-Programm abhängen (CL-Befehl RMVPFTRG) und das "neue" Trigger-Programm anhängen (CL-Befehl ADDPFTRG)

... dass das Ganze so kompliziert ist, ist gewollt so! Schließlich soll ein Trigger zur Datenkonistenz beitragen und wenn jeder Hinz- und Kunz zu jeder Zeit einen Trigger aktivieren, deaktivieren und austauschen könnte, wäre eben genau die Datenkonsistenz sonstwo!

Birgitta

[svit]

aktivieren und deaktivieren kann man jeder zeit(chgpftrg)
deswegen dachte ich auch libl-name zuändern wurde auch ohne abhängen und anhängen gehen.

[Fuerchau]

Das geht deswegen nicht, da der alte Trigger entfernt und der neue hinzugefügt werden muss.
Für das System ist das ja auch ein ganz anderes Programm.

[fabax]

Hallo svit,
es gibt für alles eine Lösung auch für dein Problem mit den Programmtriggern. Zumindest hab ich für mich eine Lösung gefunden.
Ich nenne das "indirektes Triggern" und funktioniert wenn man einige Dinge beachtet einwandfrei.

Im Prinzip geht das so.

• Es gibt nur ein einheitliches Programm für die Verarbeitung von Triggern. Dieses Programm dient als "Middleware", und löst damit das Problem des exlusiven Zugriffes bei Änderungen am Trigger. Da diesen nun die Middelware besitzt. Damit läßt sich der Trigger "an" und "aus"schalten. Mehr dazu später...

• Das Middlewareprogramm, das als Triggerprogramm an die physische Datei als angehängt ist, ermittelt aus der übergebenen Triggerstruktur den Dateinamen und die LIB der Physische Datei.

• mit diesen Werten wird dann ein gleichlautender Datenbereich geladen der das eigentliche Verhalten steuert (.. also *LIB/PFDateiname ==> *LIB/DTAARADateiname Inhalt in der Form "{1|0}{LIB}{PGM}

• {0|1} steuert ob der Trigger überhaupt aufgerufen wird
• {LIB} Bibliothek
• {PGM}Programmname

• an dieses Programm wird die komplette PF-Triggerdatenstruktur als Parameter übergeben. In diesem Prog kannst Du dann machen was Du willst. Das Programm läßt sich dadurch jederzeit An- und Abschalten oder auch Verändern und an neue Erfordernisse anpassen, ohne das Du das System exlusiv benötigst. Einfach TriggerDatenberisch auf "0", und das war's. Natürlich ist der eigentliche Trigger noch aktiv, aber er tut nichts mehr.

• Ich habe diese Vorgehensweise dann auch noch mit einer Datenwarteschlange gekoppelt. Ich verliere damit keine "Events" während mein Trigger "deaktiviert" ist.

Das System läuft "LIVE" auf mehreren ERP Systemen bei Kunden, die teilweise pro Tag 2Mio Transaktionen haben.

schönen Abend noch
FX

[fabax]

Hallo svit,
es gibt für alles eine Lösung auch für dein Problem mit den Programmtriggern. Zumindest hab ich für mich eine Lösung gefunden.
Ich nenne das "indirektes Triggern" und funktioniert wenn man einige Dinge beachtet einwandfrei.

Im Prinzip geht das so.

• an dieses Programm wird die komplette PF-Triggerdatenstruktur als Parameter übergeben. In diesem Prog kannst Du dann machen was Du willst. Das Programm läßt sich dadurch jederzeit An- und Abschalten oder auch Verändern und an neue Erfordernisse anpassen, ohne das Du das System exlusiv benötigst. Einfach TriggerDatenberisch auf "0", und das war's. Natürlich ist der eigentliche Trigger noch aktiv, aber er tut nichts mehr.

• Ich habe diese Vorgehensweise dann auch noch mit einer Datenwarteschlange gekoppelt. Ich verliere damit keine "Events" während mein Trigger "deaktiviert" ist.

Das System läuft "LIVE" auf mehreren ERP Systemen bei Kunden, die teilweise pro Tag 2Mio Transaktionen haben.

schönen Abend noch
FX

..noch was... dies geht natürlch nicht mit RPGdreiiiii wegen der Parameterlänge von Strings, aber das benützt ja eh keiner mehr laut EiBiÄm . nimm einfach freeRPG

[B.Hauser]

..noch was... dies geht natürlch nicht mit RPGdreiiiii wegen der Parameterlänge von Strings, aber das benützt ja eh keiner mehr laut EiBiÄm . nimm einfach freeRPG

Dass, das nicht mit RPGIII geht würde ich nicht so sehen (auch wenn man das heute nicht mehr verwenden sollte)! Auch bei RPGIII wird beim Programmaufruf nur Pointer übergeben werden. Wird ein Pointer auf den Trigger-Buffer übergeben und dieser an ein weiteres Programm übergeben, hat auch dieses Programm den Triggerbuffer im Zugriff. Mittels Substring und/und (externen) Datenstrukturen kann auf den Datensatz zugegriffen werden (zumindest haben wir das früher so bzw. so ähnlich gemacht!)

Birgitta