SQL Update

[Fuerchau]

Ausserdem muss man bei RPG/LE noch bedenken, dass der Compiler implizit Feldprüfungen sowieso einbaut.
Dadurch, dass RPG/LE nicht direkt mit den Satzpuffern arbeitet werden intern MOVE-Befehle zwischen Datenfeld und Dateipuffer generiert.
Wenn dabei was nicht stimmt (ins besonders Dezimalfelder) gibts halt MCH-Fehler.
Auch wenn man sich die Auflösung der SQL's im Spool ansieht, sieht man eine Vielzahl von Move's, die ja auch bei Dezimalfeldern durch MI geprüft werden (dies läßt sich auch nicht abschalten).

Einzig wenn man Dateien nicht als extern, sondern intern beschrieben verarbeitet, also quasi Satz- und nicht Feldweise, kommt es bei DDS-Dateien weder beim Lesen noch beim Schreiben (Ausnahme Key's und Integritätsbedingungen) zu Fehlern, nur bei SQL-Dateien wird eben mehr geprüft.

COBOL-Leute wissen das meistens, da COBOL grundsätzlich mit den Satzpuffern direkt arbeitet.
Beim Lesen und Schreiben erfolgen nämlich keine MOVE's mehr.
Dadurch erklärt sich auch (mehr aus der Vergangenheit) die etwas bessere Performance bei Datei-IO als bei RPG/LE.

Beispiel:
Häufig werden in RPG/LE von einer Datei nicht alle Felder bearbeitet.
Man findet aber auch dann diese Kombination:

FDATEI UF E K DISK
EDATEI E DS
IDATEI

Beim Lesen werden alle Dateifelder in die DS übertragen, beim schreiben alle wieder zurück.
Läßt man die DS-Struktur weg, generiert der Compiler ausschließlich die MOVE's der verwendeten Felder (das erklärt auch, warum im Debugger ggf. Felder nicht angezeigt werden können).

Bei Massenupdates (Batch) werden eben 100.000de oder Millionen von unnötigen Moves ausgeführt um vielleicht nur 1 Feld einer Datei zu ändern.

Bei COBOL werden aber keine zusätzlichen Moves generiert, die Laufzeit ist also besser.

Man kann also unabhängig vom Dateisystem (DDS/SQL) nicht unerhebliche Performance-Verbesserungen erreichen, wenn man das berücksichtigt.

[BenderD]

... das Alter erzieht da zu Pessismismus: ich habe im Verlaufe meines Berufslebens zuviele Programme gesehen, wo der Programmierer vor lauter Performance Optimierung die Stellen übersehen hat, wo er/sie das 10 fache wieder weggegeben hat, was er wo anders mit Mühe eingespart hat. Wer da Ideen braucht, wie man sowas macht:
- sequentielles lesen gelöschter Sätze
- Hundertfach denselben Satz lesen
- update von Hunderttausenden ungeänderter Sätze
- Millionenfaches Konvertieren des heutigen Datums
- weitere Ideen findet man in historisch geschrumpften Anwendungen

Konsequenz: simple ist meist gut!

D*B

Man kann also unabhängig vom Dateisystem (DDS/SQL) nicht unerhebliche Performance-Verbesserungen erreichen, wenn man das berücksichtigt.