Anmelden

View Full Version : Trigger Triggerprogramm Objektlock



kuempi von stein
25-02-05, 11:36
Hola,

mal wieder eine generelle Frage zur Triggerei für Alle...

Trigger ist gesetzt (sagen wir mal *INSERT und *UPDATE) und Triggerprogramm ist ein "einfaches" RPG-Programm welches bei bestimmten Konstellationen einen Eintrag in eine DTAQ sendet und sich ansonsten wieder schlafen legt.
Wenn ich nun versuche dieses Triggerprogramm zu wandeln bekomme ich ein CPF2143 weil es diverse Locks im System darauf gibt. Alles Programme die eben mit Update auf bewusste Datei einen Zugriff haben.

Was mir nicht klar ist dabei:
F1: Warum locken diese Programme alle zusätzlich das Triggerprogramm?
F2: Warum greift hier nicht die übliche QRPLOBJ-Logik? Das sollte doch machbar sein?

kuempi

B.Hauser
25-02-05, 12:15
Hola,

mal wieder eine generelle Frage zur Triggerei für Alle...

Trigger ist gesetzt (sagen wir mal *INSERT und *UPDATE) und Triggerprogramm ist ein "einfaches" RPG-Programm welches bei bestimmten Konstellationen einen Eintrag in eine DTAQ sendet und sich ansonsten wieder schlafen legt.
Wenn ich nun versuche dieses Triggerprogramm zu wandeln bekomme ich ein CPF2143 weil es diverse Locks im System darauf gibt. Alles Programme die eben mit Update auf bewusste Datei einen Zugriff haben.

Was mir nicht klar ist dabei:
F1: Warum locken diese Programme alle zusätzlich das Triggerprogramm?
F2: Warum greift hier nicht die übliche QRPLOBJ-Logik? Das sollte doch machbar sein?

kuempi

Ein Trigger-Programm hängt direkt an einer Datei und wird durch den Database Manager aktiviert, wenn eine bestimmte Aktion eintritt.
Wenn ein Trigger-Programm geändert werden muss, muss der Trigger zunächst abgehängt werden. Das geht jedoch nur wenn die Datei nirgends im Zugriff ist. Denn nur dann ist gewährleistet, dass keine Daten durch unvollendete Aktionen verloren gehen.

Deshalb gibt es auch Empfehlungen das eigentliche Verarbeitungs-Programm aus dem Trigger-Programm aufzurufen. In diesem Fall kann das Verarbeitungs-Programm geändert werden, ohne dass der Trigger abgehängt werden muss.

Birgitta

kuempi von stein
25-02-05, 12:37
Wenn ein Trigger-Programm geändert werden muss, muss der Trigger zunächst abgehängt werden.
Birgitta
hallo Birgitta,

bist du sicher?
ich habe das Triggerprogramm vorhin gewandelt OHNE den Trigger abzuhängen... Hat ohne Probleme funktioniert....
sowas..

werde gleich mal prüfen ob das Programm anspringt wenn ich nen Dateichange mache..

kuempi

Fuerchau
25-02-05, 12:47
Die QRPLOBJ funktioniert teilweise nicht bei ILE.

Aber Achtung:
Wenn das Programm ersetzt wird, rufen alle aktiven Job's noch das alte Programm auf.
Das Programm sollte normalerweise ja mit *INLR=*OFF verlassen werden. Wenn es aber im Job keinen RCLRSC/RCLACTGRP gibt, bleibt das alte Programm bis zum Jobende aktiv.

Bei ILE funktioniert die Ersetzung nur dann, wenn der Trigger nicht aktiv ist. Ein CHGPF ist nicht erforderlich.

kuempi von stein
25-02-05, 13:38
@Birgitta

also das Triggerprogramm ist sauber angesprungen. Keine Probleme. Habe vorsichtshalber sogar das alte Objekt aus QRPLOBJ gelöscht um ganz sicher zu gehen...

siehst Du da trotzdem Probleme?


@Fuerchau

nix ILE, ist noch gute alte Wertarbeit. :-)
Und Perfomance hin oder her, das Programm wird mit *INLR *ON beendet...
Da werden manchmal reichlich records hintereinander angesprochen, das scheint für die Performance nicht problematisch zu sein.

Meinst Du das sollte man ändern?

kuempi

Fuerchau
25-02-05, 15:06
Ggf. Ja !
Mach mal beim CRTRPGPGM einen GENOPT(*LIST). Du bekommst eine MI-Liste, in der du siehst was alles bem Start so durchläuft.
Das Programm muss ausserdem immer aktiviert und deaktiviert werden, Speicher zuordnen und freigeben usw. usw.
Mit *INLR=*OFF und RETRN kann man sich da einiges sparen.

kuempi von stein
28-02-05, 09:11
Ein Trigger-Programm hängt direkt an einer Datei und wird durch den Database Manager aktiviert, wenn eine bestimmte Aktion eintritt.
Wenn ein Trigger-Programm geändert werden muss, muss der Trigger zunächst abgehängt werden. Das geht jedoch nur wenn die Datei nirgends im Zugriff ist. Denn nur dann ist gewährleistet, dass keine Daten durch unvollendete Aktionen verloren gehen.

Deshalb gibt es auch Empfehlungen das eigentliche Verarbeitungs-Programm aus dem Trigger-Programm aufzurufen. In diesem Fall kann das Verarbeitungs-Programm geändert werden, ohne dass der Trigger abgehängt werden muss.

Birgitta
Hallo Birgitta,

da frage ich nochmal explizit nach. Gibt es da irgendwo in den Unterlagen eine Aussage von IBM drüber?
Ich habe wie schon geschrieben das Triggerprogramm neu gewandelt OHNE vorher einen RMVPFTRG durchzuführen.
Und es sieht so aus, als ob dies Problemlos verlaufen ist.
Trigger sprang danach an und hat seine Arbeit klaglos verrichtet.
Dies war jetzt auf einem Testrechner.
Und durch deine Aussage bin ich nun etwas verunsichert ob ich das auch auf nem Produktionsrechner so machen sollte...

kuempi

Fuerchau
28-02-05, 11:44
Auch da wirds funktionieren, da der ADDPFTRG nur einen Verweis auf das Programm einträgt und keine Sperre setzt.
Das problem beschränkt sich auf den Ersatz im laufenden Betrieb, wenn also das Programm durch einen Aufruf bereits aktiviert ist (s.o.).

fred_hanau
01-03-05, 12:41
Deshalb gibt es auch Empfehlungen das eigentliche Verarbeitungs-Programm aus dem Trigger-Programm aufzurufen. In diesem Fall kann das Verarbeitungs-Programm geändert werden, ohne dass der Trigger abgehängt werden muss.

Habe das auch immer so gehandhabt. Der echte Trigger war nur ein vorgeschaltetes "Durchreichprogramm".

Gruß aus Hanau