ODBC/JDBC Fehlerkontrolle

[Fuerchau]

Hallo fans , ich hab da mal ne Frage:

Nun kann man ja bei ODBC/JDBC die Bibliotheksliste für die Verbindung setzen.
Leider gibt es darüber keine Fehlermeldung wenn der CHGLIBL auf der AS/400 fehlschlägt (Lib nicht da, keine Berechtigung).
In diesem Fall bleibt die Default-QUSRLIBL bestehen.

Dies ist noch nicht so schlimm, die Auswirkungen erfolgen dann später.

Nun wird mittels SQL-Select eine oder mehrere UDF's aufgerufen deren Ergebnis auch NULL sein darf.
Wenn nun irgendein DAU die Libl der Verbindung so ändert dass sie nicht gesetzt werden kann bzw. die Berechtigung auf der AS/400 ändert, läuft die UDF auf einen Fehler und SQL nimmt nun leider das NULL-Ergebnis an.
M.a.W, der SQL läuft einfach weiter, erzeugt viele Joblog-Nachrichten oder gar Programm-Dumps die das System in der CPU-Last schnell auf größer 90% bringt sowie auch den Speicher der 90%-Marke schnell näherbringt.

Das Problem ist aber, dass die ODBC-Anwendung das Ergebnis nun für richtig hält und damit dann auch weiterarbeitet.

Ich suche nun nach einer Lösung, den SQL abbrechen zu lassen, wenn UDF's auf Fehler laufen.
In CHGQRYA sowie in den QAQQINI-Einstellungen kann ich nichts finden (aktuell V6R1!).

Nun kann ich aber die ODBC-Anwendung nicht ändern. Der selbe Fehler kommt auch z.B. beim Ausführen von OpsNav-SQL-Scripts.

Weiß jemand Rat?

[mk]

Hi Baldur,

wenn möglich :
Ergebnis der UDF vor return auf null prüfen.

Wenn ja könnte man eine kleine Stored Procedure aufrufen (CL)
das einfach ein Object in der zu erwartenden Bibliothek prüft.
Wenn Objekt okay dann weiter
wenn nicht einfach einen ENDJOB ausführen

Ist vllt. nicht so elegant, könnte aber funktionieren.
Gruß
Michael

[Fuerchau]

Dazu müsste ich ja sämtliche UDF's (und das sind einige umschreiben.
Da dies normalerweise ja SQL-Style-UDF's sind kann man ja einen negativen SQLCODE zurückgeben.
Wenn der Kunde bezahlt mach ich das ja gerne.

Es gibt aber auch UDF's (und das sind auch einige) die nun mal nicht von mir sind.

Außerdem habe ich keinen Einfluss auf die ODBC-Anwendungen um denen die zusätzlichen Prüfungen aufs Auge zu drücken.

Ich möchte einfach, dass SQL bei Auftreten von CPF/MCH oder sonstigen Programmabbrüchen (nicht überwachten Nachrichten) nicht einfach weitermacht und so tut als ob nichts passiert wäre und einfach den NULL-Wert als Ergebnis setzt.

Bei embedded SQL gibts häufig was auf die Finger wenn man den NULL-Anzeiger vergisst, wenn man aber einen hat, gibts glaube ich einen negativen Wert von -2 statt -1.
Bei ODBC kann man das aber nicht vergessen da das der Treiber erledigt.
Und alles was im NULL-Anzeiger nicht 0 ist, wird eben zu NULL.

[Robi]

Mein ansatz wäre auch der von MK gewesen.
wenn du teilweise auf die UDF keine Zugriff hast, kannst du nicht eine neue schreiben, die nur die LIB prüft und im Fehlerfall ein 0 zurück gibt. Die SQL's müßten ein zus. Feld zurück geben und ...

Robi

[cbe]

Vielleicht ist eine Prüfung im Exit-Programm bei ODBC-Aufruf möglich?
Ich weiß allerdings nicht, ob man darin die LIB abfragen kann.
Und evtl. ist es auch zu imperformant.

[Fuerchau]

Das Exit-Programm weiß ja nicht, welche UDF denn als nächstes verwendet wird.
Außerdem wird dies ja bei jeder ODBC-Verbindung aufgerufen und darf nciht einfach die LIBL ändern, da die Umgebung ja Anwendungsspezifisch gesetzt wird.
Vielleicht wird ja gerade nur ein Excel-Import, 5250-Dateiübertragung oder ähnliches durchgeführt, wo das Problem keine Rolle spielt.

Es gibt auch einen Exit mit dem man die SQL's analysieren kann.
Man sucht die UDF's, ermittelt über die SYSFuncs/SYSProcs die dazugehörigen Programme.
Dann kann man mittles API-DSPPGMREF prüfen, ob alle Ressourcen in der Libl verfügbar sind, wobei man da nicht unbedingt alles erwischt, da embedded SQL's darüber nicht ermittelt werden können.
Hierfür braucht man dann das API für integrierte oder externe (also verwendete) SQLPKG's (analog PRTSQLINF) um die Ressourcen der dortigen SQL-Statements incl. der UDF's zu prüfen.
Wenn eine Ressource nicht ermittelt werden kann, wird der SQL mit Fehler abgewiesen.

Technisch machbar aber nicht bezahlbar.
Und die Laufzeit einer solchen "Automatik" ist auch nicht zu verachten.
Zumal das Ganze nur in 0,0000001% oder weniger aller Fälle, nähmlich falsche LIBL, sinnvoll währe.

Sonst noch einer eine Idee?
Sonst muss ich wohl oder übel in alle UDF's einen "monitor" einbauen.