Key-Tabelle oder SQL-Sequence?

[Allrounder]

das ganze muss unter Commit laufen (was es bei mir immer tut), dann bleibt der Satz gesperrt bis zum Ende der Transaktion. Wenn du in der Applikation kein Commit hast, kannst du das auch als Service Programm mit embedded SQL bauen, dem Service Programm eine eigene benamte ACTGRP verpassen und in der Function selber commit sagen.
Das schreiben vor dem lesen ist ein einfacher Weg um einen Deadlock durch die Eskalation von Sperren zu vermeiden.

B*D
Die Tabelle ist erstellt, die UDF auch. Ein direkter erster Testaufruf der UDF embedded SQL aus RPG(OPM) hat prima funktioniert, die ID wird fortgeschrieben. Sorgen macht mir nur noch der Härtetest, mehrere zeitgleiche Zugriffe.

Als UDF-Neuling weiß ich nicht, ob die UDF in einer Transaktion läuft. Das Commit am Ende der UDF wird vom Navigator abgeblockt. Service-Programme habe ich bisher vermieden, weil ich noch keine Erfahrung damit habe. Würde eine eigene ACTGRP heißen, dass die UDF immer höchstens einmal aktiv ist?

[BenderD]

Hallo,

die Variante mit Blockweisem ziehen der Keynummern (immer 50 auf einmal hochaddieren) ist im absoluten Highperformance Test bewährt (bis zu 30 Batchjobs laufen parallel und bringen die Kiste mit allen Prozessoren zum qualmen.
So wie das jetzt erstellt ist, läuft die UDF in der Transaktion des aufrufenden Programmes, sprich: wenn selbiges ohne Commit arbeitet, funzt das nicht (dann bleibt der Satz gesperrt und es kann nur einer und am Ende des Jobs kommt dann ein Rollback.
Bei der Serviceprogramm Variante bewirkt die benamte Activation Group, dass das SRVPGM einen eigenen Commit Scope bekommt und dann macht man in dem SRVPGM den Commit und das drumherumliegende Programm hat da nichts mit zu tun.

D*B


Die Tabelle ist erstellt, die UDF auch. Ein direkter erster Testaufruf der UDF embedded SQL aus RPG(OPM) hat prima funktioniert, die ID wird fortgeschrieben. Sorgen macht mir nur noch der Härtetest, mehrere zeitgleiche Zugriffe.

Als UDF-Neuling weiß ich nicht, ob die UDF in einer Transaktion läuft. Das Commit am Ende der UDF wird vom Navigator abgeblockt. Service-Programme habe ich bisher vermieden, weil ich noch keine Erfahrung damit habe. Würde eine eigene ACTGRP heißen, dass die UDF immer höchstens einmal aktiv ist?

[Allrounder]

Erst einmal vielen Dank für die umfangreiche Hilfe. Jetzt hab ich's wohl kapiert. *CALLER macht in dem Fall wirklich keinen Sinn. Leider lässt sich mit UPDSRVPGM die Aktivierungsgruppe der UDF nicht ändern: "Programm oder Serviceprogramm verfügt nicht über eine benannte Aktivierungsgruppe." Ich muss wohl ein RPG-Serviceprogramm mit eigener Aktivierungsgruppe erstellen, dass die UDF embedded aufruft, ein Commit absetzt und die ID zurückgibt. Richtig? ... Hoffentlich ;-)

[Allrounder]

Es läuft!!! Habe eine RPG-Prozedur geschrieben, den Code der UDF in die Prozedur kopiert (embedded). Die Prozedur bekommt Tabellenname und Feld und gibt die ID zurück incl. commit. Das ganze ist jetzt eingebunden in einem Service-Programm mit eigener Aktivierungsgruppe. Wenn die letzten Tests noch erfolgreich sind, kann ich zum 2.1. damit in Echtbetrieb gehen. Vielen Dank B*D!