SQL Fenced oder NOT Fenced

[dabeda]

Hallo Forum!

Ich hab eine UDF die aus einer Datei einen Wert ausliest und den zurück gibt. Diese hab ich in ein Serviceprogramm gepackt das bis vor kurzem noch in einer benannten Aktivierungsgruppe gelaufen ist. Hab das ändern müssen weil ich da drinnen auch QCMDEXC laufen hab das OVRDBF und dergleichen machen muß.

In einem Trigger wird diese Funktion aus RPG aus aufgerufen. Hat bis jetzt immer klaglos funktioniert, aber nachdem ich das Serviceprogramm als ACTGRP(*CALLER) kompiliert hab, stürzt die UDF mit Bomben und Granaten ab. Wenn ich sie online aufrufe gehts aber.
Die UDF hab ich dann auf NOT FENCED geändert und jetzt läuft es wieder.

Im Internet lese ich aber Horrormeldungen dass NOT FENCED UDFs die Datenbank zum crashen bringen können.

Eine FENCED UDF wird in einem eigenen Thread ausgeführt, die NOT FENCED nicht, oder hab ich da was falsch verstanden?

Mir ist nicht klar warum die UDF als FENCED abstürzt wenn das Serviceprogramm ACTGRP(*CALLER) hat.

Hat da jemand Erfahrungen damit??

Mfg Peter

[andreaspr@aon.at]

Hallo Peter,

Richtig: bei fenced arbeitet die function in einem seperatem thread.
bei not fenced nicht. dies kann zur performance-optimierung verwendet werden, da kein eigener thread erstellt werden muss.
jedoch muss bei not fenced darauf geachtet werden, dass beim arbeiten mit cursor keine überschneidungen stattfinden, da bei not fenced der cursor offen bleiben kann und es darf der name cursor in der UDF nicht gleich sein wie im PGM welches das UDF aufruft.

mein tipp: not fenced NUR verwenden, wenn in der function nicht mit cursor gearbeitet wird.

lg andreas

[dabeda]

Cursor ist keiner in der UDF, aber ich versteh nicht warum die Funktion abstürzt wenn ich FENCED, das ja default ist, benutze.
Es wird einfach aus einem Table ein Feld ausgelesen, das sollte ja nicht allzu kompliziert sein.

Ich hab prinzipiell kein Problem damit die UDF mit NOT FENCED zu erstellen, aber das "warum" interessiert mich sehr.

[andreaspr@aon.at]

... stürzt die UDF mit Bomben und Granaten ab ...

kannst du die genaue fehlermeldung posten?

[B.Hauser]

m.E. ist das Problem die Aktivierungsgruppe *CALLER (mit einer benannten Aktivierungsgruppe hat es ja funktioniert!). Wenn die Funktion in einem eigenen Thread aufgerufen wird, gibt es in diesem Thread keine rufende Aktivierungsgruppe.
Die Overrides u.ä. führen in einem separaten Thread ebenfalls zu Problemen. RPG ist nun mal nicht Thread Safe!

Versuch mal das folgene:
Füge in die H-Bestimmungen das Schlüsselwort Thread(*SERIALIZE) ein. Dies sollte bewirken, dass in einer multi-threaded Umgebung kein neuer Thread eröffnet wird und die Funktion im gleichen Thread läuft.
Die Funktion anschließend wieder mit FENCED registrieren und ausprobieren.

Birgitta

[dabeda]

Werde das heute gleich mal testen.
Das Problem ist, dass in diesem Serviceprogramm viele Prozeduren drinnen sind, hoffe nur es wirkt sich sonst auf keine aus. Sind aber alle RPG und eben nur diese eine SQL.

@andreas
Die Fehlermeldung hab ich nicht mehr, finde nur mehr einen Satz im Joblog: "Der Symptomzeichenfolge wurde ein ungültiges Symptom hinzugefügt". Hört sich an wie beim Arzt ...

[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