Hallo Forum
vielleicht hat einer von euch eine Alternative für mich.

Ich "darf" auf einer 520 ein neues ERP Testsystem aufbauen (Basis sind Livedaten), dabei muss ich in ca. 390 Mio Datenrecords die Firmennummer abändern. Bei durchschnittlich 14ooRec/sec mit embedded SQL geht mir da natürlich voraussichtlich das Wochende aus .
Die Maschine dümpelt zwar nur mit 27% Prozent in der Gegend rum, aber über diese 1400 Rec komm ich nun mal nicht drüber. ( um die Frage gleich zu beantworten, nein kein paral...SQL Feature! ).

Was passiert..
Die Routine ermittelt dynamisch Datei und Feldname und erzeugt einen angepassten SQL Updatebefehl der dann submitted wird. Die größte Datei (52 Mio) benötigte dann fasst 19 Stunden.
Das Verteilen auf paralelle Jobs half natürlich auch nicht. ( ganz einfach -> 1400/sec durch Anzahl der Jobs ).

Mein Plan ist nun, diese Langläufer durch ein RPG Programm mit READ-UPDAT zu ändern, was (hoffentlich) deutlich schneller sein sollte. Das Problem ist aber das fixe Satzformat in RPG.

Idee 1 (RPG): Neue Programmhülle..
a) Dateiname, Satzformat und Feldname ermitteln.
b) mit diesen Werten eine nue freeRPG Source automatisch anpassen.
c) Das Programm automatisch compilieren lassen.
d) neues Program submitten...
e) und weiter mit a)---

/free
read $FILE$;
dow not %EOF();
$FELD$ = $WERT$;
update $FORMAT$;
read $FILE$;
enddo;
*INLR = *on;
/end-free

Idee 2 : (immer noch RPG ) Wer kennt noch WRKDBF? Ich hab mich schon immer gefragt wie die das realisiert haben. Denn offensichtlich exitieren kein SQLRPG... Programme in dessen Bibliothek. Also gibt es vielleicht einige passende API's von IBM ?

Idee 3 : Wenn ich diese Dateien mit dem AS400 C oder C++ Compiler angreife, habe ich da vielleicht eine Möglichkeit die festen Formate zu umgehen?

Idde 4 : Java habe ich erst gar nicht in Erwägung gezogen. Da benütze ich JTOpen und das ist ja wieder SQL ?

Gibt es noch eine andere Möglichkeiten ?

Der Ideentopf ist eröffnet.
Lösungen und Vorschläge sind herzlich willkommen