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

Zitat Zitat von Allrounder Beitrag anzeigen
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?