SQL Fenced oder NOT Fenced

[Fuerchau]

Daher sollte man SQL-Functions/Proceduren in einem Service-Programm nicht mit anderen Nicht-SQL-Prozeduren mischen.

Gliedere die Funktion besser in ein eigenes Serviceprogramm aus.

[dabeda]

So, hab das jetzt versucht mit THREAD(*SERIALIZE) aber das wars nicht. Wieder ein Absturz der UDF.
Die Maschine behauptet "Zeiger für angegebene Position nicht gesetzt", aber es sind alle Parameter gefüllt.
Habs mir im Debugmodus angeschaut, sobald die Funktion aufgerufen wird crashed das Programm und nimmt gleich noch alles im Aufrufstapel mit.

Nochmal der Ablauf:

In der Kundenstammwartung wird auf den Kundenstamm geschrieben, ein Trigger wird ausgelöst, darin wird mittels SQL-Cursor eine Datei gelesen in der die aufzurufenden Triggerprogramme stehen. Das erste Programm wird aufgerufen und sieht in einer Steuerungsdatei nach ob gewissen Dinge zu tun sind oder nicht. Das geschieht mittels eines Prozeduraufrufs an ein Serviceprogramm das wiederum eine UDF enthält die die Datei liest und den gewünschten Wert zurückgibt.

Da die UDF in anderen Programmen, Views und dergleichen auch genutzt wird, dort aber direkt angesprochen wird, macht mir das schon Kopfzerbrechen wenn ich NOT FENCED angeben muß. Weiß ja nicht wie sich das auswirken kann.

[dabeda]

Also laut IBM Handbuch ist NOT FENCED nur ein Vorschlag an die Datenbank, die dann wieder selbst entscheidet ob es auch so gemacht wird.
Denke ich lass das jetzt mal so laufen und beobachte es ein bißchen.

[Fuerchau]

NOT FENCED ist eine Prozedur/Funktions-Deklaration und wird nur von SQL verwendet.
Rufst du eine Servicefunktion native auf, interressiert sich keiner für diese Deklaration.

Wichtig ist halt nur die ACTGRP.
Ich habe mir daher ein 2-stufiges Konzept angewöhnt:
1. SQL-Funktion/Prozedure in eigenem Programm als reiner Rahmen
2. Aufruf der verarbeitenden OPM/ILE-Programme über Schnittstellen