View Full Version : SQL-Fehler in embedded SQL im aufrufenden Programm abfangen?
Liebe Gemeinde,
wie kann ich in einem aufgerufenen Programm bei Auftreten eines negativen SQL-Codes bewirken, dass mein aufrufendes Programm diesen Fehler im on-error monitor richtig interpretiert?
Beispiel:
Programm: XYZ
....
C monitor
C call 'SQLPGM' ---------------> SQLCOD < 0 im embedded SQL
C on-error
C eval w_err = *on
C leavesr ----------------------> oder anderes Fehlerhandling
C endmon
Was müsste ich in SQLPGM ausgeben/einstellen, damit der negative SQLCOD
in Programm XYZ den Monitor on-error auslöst?
Danke vorab für einen guten Tipp.
Die einzige Möglichkeit ist eine Prozedur zu schreiben, die nach dem SQL-Statement aufgerufen wird, die den SQLCODE prüft und bei einem negativen SQLCODE eine Abbruch-Nachricht schickt.
Birgitta
Wenn du das SQL-Programm "im Griff" hast (also die Source), dann erfinde einfach einen weiteren Aufrufparameter, der dir einen detailierten Fehlercode (nicht einfach den SQLCODE) zurück gibt.
Das macht mehr Sinn, als eine ESCAPE-Nachricht an den Aufrufer zu senden, da u.U. dies erst mal zu einer Antwort-Nachricht führen kann und der Prozess hängen bleibt.
Zumal du bei ILE nicht die "*PRV"-Ebene angeben kannst, da das immer noch das eigene Programm ist.
Zumal du bei ILE nicht die "*PRV"-Ebene angeben kannst, da das immer noch das eigene Programm ist.
Wenn Du eine (externe) Prozedur schreibst und die Escape-Message aus der Prozedur aufrufst, kommt diese sehr wohl in dem Programm an.
Wenn du das SQL-Programm "im Griff" hast (also die Source), dann erfinde einfach einen weiteren Aufrufparameter, der dir einen detailierten Fehlercode (nicht einfach den SQLCODE) zurück gibt.
Das macht mehr Sinn, als eine ESCAPE-Nachricht an den Aufrufer zu senden, da u.U. dies erst mal zu einer Antwort-Nachricht führen kann und der Prozess hängen bleibt.
Zumal du bei ILE nicht die "*PRV"-Ebene angeben kannst, da das immer noch das eigene Programm ist.
... ich bin da schon eher ein Anhänger der escape Message (analog zu throw in Java) und im ILE gibt extra noch *PGMBDY als Ziel, wenn man sich die Callstack Ebenen Zählerei ersparen will.
D*B
Vielen Dank für eure blitzschnellen Antworten.
Das SQLPGM wird ohne Parameter von vielen Programmen aufgerufen, es liest noch Daten aus der LDA.
Ich kann sowohl den SQLCODE in SQLPGM interpretieren als auch den Monitor im aufrufenden Programm ändern.
Was muss das Programm SQLPGM ausgeben, damit der Monitor on-error Alarm schlägt?
Eine Möglichkeit wäre den SQLCODE in die LDA zu schreiben, aber vielleicht gibt es etwas Eleganteres?
Eine Möglichkeit wäre den SQLCODE in die LDA zu schreiben, aber vielleicht gibt es etwas Eleganteres?
... solche Programme gehören ausgedruckt und dem Programmierer um die Ohren gehauen.
D*B
andreaspr@aon.at
26-03-20, 10:30
In den On-Error Block wird bei einer Escape Message gesprungen.
Was das betrifft bin ich Dieters Meinung. So wie im Java & Co via CATCH & THROW verwende ich auch in der RPG Welt die Escape Messages zum Werfen und Empfangen von Fehlern.
lg Andreas
Auch bei der Objektorientierung vermeide ich selber Throw/Catch, da die meisten Aufrufe durchaus mit einem Bool-Return einen OK-Status zurückgeben können.
Zumal das Fehlerhandling durch diese Methodik die Programmausführung bei häufigen "Fehlern" durchaus verlangsamt.
Hinzu kommt, dass jeder SNDPGMMSG/QMHSNDPM einen Joblog-Eintrag erzeugt. Auch dies ist bei häufigem Vorkommen verlangsamend zumal es zusätzlich unnötige Joblogs (WRAP) produziert.
*PGMBDY ist zwar eine Möglichkeit, da musst du aber sicher sein, dies in der Hauptprozedur durchzuführen. Befindest du dich in einer internen Unter-Procedur, schlägt das auf den Aufrufer des Programmes und nicht den Aufrufer der Prozedur durch. Damit können durchaus mehrere Aufrufebenen übersprungen werden.
Dies gilt auch für Service-Programme, die Aufrufe durchaus verschachteln können.
Eine saubere Schnittstellendefinition incl. Fehleraussage halte ich generell für besser.
Siehe auch SYSERR-Struktur bei API's.
Aber das ist halt alles Geschmackssache;-).
andreaspr@aon.at
26-03-20, 11:40
Naja, wenn Exceptions sind ja ... wie der Name es schon sagt ... Außnahmen.
Kommen diese oft oder regelmäßig vor, ist es eher ein Designfehler.
Exceptions im Joblog sind natürlich auch eine super Sache für Analysen (neben Logtabellen/Logfiles).