RCVMSG aus einer ILE RPG Prozedur

[Gorden858]

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)

[Fuerchau]

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.

[Gorden858]

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.

[Fuerchau]

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.

[Gorden858]

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.

[B.Hauser]

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

[Fuerchau]

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.

[tarkusch]

D  MsgText               91    170    
D  MsgTextKurz           91    140    

Monitor;                                 
  CHAIN(NE) (PENR:ARTN) FILE;     
ON-Error *ALL;                           
  EXSR SubChain;                  
EndMon;    

BEGSR SubChain;                                 
  If %status = 1218; // Satz gelockt                   
     //Window  MsgTextKurz;                              
     Par_RtnCode = 'L';                                
  ElseIf %error; // sonstiger Fehler                   
     Par_RtnCode = 'E';                                
  ElseIf Not %Found(FILE); //Nicht gefunden         
     Par_RtnCode  = 'N';                               
  Else; // Satz vorhanden + frei                       
     Par_RtnCode = ' ';                                
  endIf;                                               
EndSr;

Also ich habe leider wie immer nicht ganz den Durchblick, aber bekomme ich die Satzsperre so angezeigt wie im Code oberhalb?

[B.Hauser]

Dadurch, dass Du den Fehler über die Erweiterung (E) abgefangen hast, kommst Du nie in den ON-ERROR-Zweig.

Monitor ist außerdem eine Stufe über dem %ERROR, d.h. eine die Fehlermeldung "Satzsperre" kann mit %ERROR abgefangen werden. Bei der Monitor-Group wird der Fehler intern um ein Level weitergereicht und eine andere Meldung ausgegeben.

  Monitor;
    Chain MyKey MyFileF;
  On-Error 1218  // Record Lock
     Unlock MyFile;   //entspricht (N)
     //Mach was immer Du willst
  On-Error *ALL;
     //Alle anderen Fehler
  EndMon;

Birgitta

[Fuerchau]

Allerdings muss dann "CHAIN(E)" ausgeführt werden da CHAIN(N) keine Sperre verlangt und somit der Satz gelesen wird.

[B.Hauser]

... 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

[tarkusch]

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