View Full Version : RCVMSG aus einer ILE RPG Prozedur
Hallo Forum,
ich nutze ein CL-PGM um Nachrichten aus einem RPG-PGM abzurufen.
In meinem Beispiel ist dies ein PGM welches aus anderen RPGs aufgerufen wird, wenn eine Satzsperre besteht, um per RCVMSG den sperrenden Job zu ermitteln und dem User so eine Nachricht überstellen zu können.
Befindet sich der READ/CHAIN allerdings in einem ILE-RPG in einer Prozedur funktioniert dies nicht (Die erhaltene Nachricht ist leer.)
Wie kann ich in dem RCVMSG-Befehl mitteilen, dass die Nachricht aus der MSGQ der Unterprozedur geholt werden soll?
Hier der Befehl wie er momentan aussieht:
RCVMSG PGMQ(*SAME (&PGRM)) MSGQ(*PGMQ) MSGTYPE(*PRV) MSGKEY(*NONE) WAIT(2) RMV(*NO) KEYVAR(&MKEY) MSG(&NACHR)
Du kannst nur dann Nachrichten der Prozedur empfangen, wenn diese dies selber durchführt.
Also die Prozedur muss dein RCVMSG-Prog aufrufen.
Ist die Prozedur verlassen, gibt es den Call-Stack ja nicht mehr, dann steht die Nachricht nur noch im Joblog und dafür gibts dann andere API's.
So habe ich es auch umgesetzt. Also die Prozedur ruft das CL per CALL auf, sobald eine Satzsperre festgestellt wird. Der Call-Stack sollte also noch vorhanden sein.
Bitte entschuldige, wenn meine erste Beschreibung nicht präzise genug war.
OK, dann debugge dein CLP und halte vor dem RCVMSG an.
Schau dir dann den Callstack an.
Du musst den Prozedurnamen genau (ggf. casesensitive) spezifizieren.
Dann prüfe auch, an wen die Nachricht, die du abholen willst gesendet wurde (F1->F9).
Welche Nachricht willst du überhaupt lesen ?
Bei Datei-Fehlern steht doch ggf. alles in der SDS bzw. INFDS.
... warum brauchst Du überhaupt einen RcvMsg, warum nimmst Du die Fehlermeldung nicht aus der Programm-Status-Datenstruktur (Position 91-170)?
Wenn Du die Satz-Sperre mit (E) abfängst und ggf. noch auf %Status 1218 prüfst, hast Du den Nachrichten Text in der Programm-Status-Datenstruktur.
D PGMSDS SDS Qualified
D MsgTxt 91 170
/Free
...
Chain(E) (MyKey1: MyKey2) MyUpdF;
If %Error();
Dsply PGMSDS.MsgTxt;
EndIf;
...
/End-Free
Funktioniert beim Read natürlich genauso.
Birgitta
Guten Morgen und vielen Dank für die schnelle Hilfe.
Ich habe nun die Variante mit dem SDS getestet und tatsächlich meine gewünschte Nachricht gefunden:
"Satz 1 wird von Job 323053/DFOCKEN/DV37956#BI benutzt."
Diese wurde sonst per RCVMSG abgerufen, um daraus den String nach den Jobinformationen zu durchsuchen. Vermutlich nicht die eleganteste Lösung aber ich wollte lieber den bestehenden Weg anpassen als etwas komplett neues zu entwickeln.
Morgen Birgitta,
wie verhält es sich eigentlich bei Satz-Sperre mit (N)?
bekomme ich genau so die gewünschte Nachricht welcher job sperrt?
Wann darf/soll ich eigentlich CHAIN(N) oder (E) nehmen?
Gruß
Tarki
Du kannst auch beides angeben
Chain (NE)
Gruß
Ronald
wie verhält es sich eigentlich bei Satz-Sperre mit (N)?
bekomme ich genau so die gewünschte Nachricht welcher job sperrt?
Wann darf/soll ich eigentlich CHAIN(N) oder (E) nehmen?
Die Erweiterung (N) bzw. der OpCode UNLOCK funktionieren nur, wenn die Verarbeitung nicht unter Commitment Control erfolgt.
Sofern ein Datensatz gesperrt ist und mit nur (E) abgefangen wird, wird der Satz (soweit ich mich erinnern kann) nicht empfangen.
Sofern ein Datensatz gesperrt ist und mit (N) abgefangen ist, wird er nach dem Einlesen freigegeben, unabhängig, ob er gesperrt war oder nicht.
Wurde ein Datensatz mit (N) oder Unlock freigegeben, kann er ohne erneutes Einlesen nicht fortgeschrieben werden.
Birgitta
Ein Chain(n) liest die Daten immer ohne Sperre (bei Update-Dateien, bei Input-Dateien gibts einen Compilerwarning).
Ist der Satz gesperrt bzw. unter Commit-Steuerung geändert erhält man den Inhalt trotzdem (bezeichnet als sog. Schmutzdaten).
Leider kann man sich dann auf die Daten nicht verlassen, sollte die ändernde Applikation einen Rollback veranlassen.
Das liegt halt so am Konzept.
Mittels Chain(e) wird halt %error() beim Lock ausgelöst (nach Satzwartezeit) und es werden keine Daten bereitgestellt.