PDA

View Full Version : sicherstellen das ein Trigger enabled wurde



cimbala
04-01-06, 13:01
Hallo,

ich, ein Nachwuchs RPG- Programmierer ;-) habe die Aufgabe ein CL zu schreiben welches einen Trigger abhängt, ein RPG aufruft und den Trigger anschließend wieder abhängt.
So weit so gut. Das CL war fertig und ich habe es aufgerufen.
Leider hat in der Zeit in der mein RPG lief jemande auf die Tabelle zugegriffen und das CL hat den Trigger nicht wieder angehängt.
Gibts es eine Möglichkeit im CL zu kontrollieren bzw. dafür zu sorgen das der Trigger wirklich wieder angehängt wird !?

Danke für eure Hilfe,
André

Fuerchau
04-01-06, 13:05
Beim ADDPFTRG mittels MONMSG feststellen, dass der Trigger angehängt wurde.
Um sicherzustellen, dass kein Programm mit der Datei arbeiten kann wenn solche Aktionen ausgeführt werden, per ALCOBJ die Datei vorher exclusiv sperren und hinterher per DLCOBJ wieder freigeben.
Allerdings stürzen dann andere Programme beim Zugriff auf die Datei ggf. ab !!!

VisioX
04-01-06, 13:10
Was du versuchen koenntest.... (habe es nicht getestet)

Nach dem ADDPFTRG mit MONMSG MSGID(CPF0000) die fehlermeldung abfangen, einen kleinen jobdelay einbauen und wieder vor den ADDPFTRG springen.

also z.B. so

TRG1: ADDPFTRG FILE(TESTLIB/TESTPF) TRGTIME(*BEFORE) +
TRGEVENT(*INSERT) PGM(TRGLIB/TRGPRG)
MONMSG MSGID(CPF0000) EXEC(DO)
DLYJOB DLY(60)
GOTO TRG1

mfg
Guido

cimbala
04-01-06, 13:12
Danke für deine Antwort.
Bei der MONMSG kann ich einfach die CPF32C6 abfragen und dann evtl. neu versuchen den Trigger anzuhängen, oder?

Fuerchau
04-01-06, 13:25
Stimmt, aber der Trigger hat ja eine spezielle Aufgabe und der Zugriff auf die Datei sollte verweigert werden, solange der Trigger eben nicht angehängt ist.
Mittels ALCOBJ und MONMSG kannst du prüfen, ob die Datei verwendet wird und eben solange sperren, bis deine Aktion abgeschlossen ist.
Je nach dem, wie die Datei verwendet wird oder wie lange sie noch bearbeitet wird, kann das Anhängen des Triggers eben dauern und solange wird die Datei eben nicht überwacht.

VisioX
04-01-06, 13:25
So in etwa war es geplant :-)

cimbala
04-01-06, 13:35
Das sind die 3 Befehle aus meinem CL.

CHGPFTRG FILE(LIB/FILE) TRG(*ALL) STATE(*DISABLED)
RUNSQLSTM SRCFILE(LIB/FILE) SRCMBR(SQLFILE) COMMIT(*NONE)
CHGPFTRG FILE(LIB/FILE) TRG(*ALL) STATE(*ENABLED)


und so könnte es aussehen damit es klappt, oder?
also einfach nur abfragen, ob ein Fehler aufgetreten ist und wenn ja dann nochmal versuchen den Trigger anzuhängen...

CHGPFTRG FILE(LIB/FILE) TRG(*ALL) STATE(*DISABLED)
RUNSQLSTM SRCFILE(LIB/FILE) SRCMBR(SQLFILE) COMMIT(*NONE)
TRG1:
CHGPFTRG FILE(LIB/FILE) TRG(*ALL) STATE(*ENABLED)
MONMSG MSGID(CPF0000) EXEC(GOTO TRG1)

Das Ding ist wir kopieren am Wochenende immer einige Umgebungen von uns mit Hilfe von CL´s und ständig sind dann montag morgen irgendwelche trigger nicht wieder angehängt... das soll vermieden werden !


Danke für eure Hilfe...

Fuerchau
04-01-06, 15:04
Wenn du so verfährst, könnte es sein, dass die Programme übers WE nicht fertig werden !!!!
Sie warten ja ständig auf Freigabe des Objektes.
Übrigens auch der 1. CHGPFTRG kann fehlschlagen, wenn die Datei bereits offen ist !!!

Mach dir lieber nochmal Gedanken zum Konzept mit ALCOBJ/DLCOBJ ;););)