Satzsperre

[BenderD]

Hallo Birgitta,

ich habe auch mal RPG II programmiert (und COBOL auf Mainframe und das ist noch übler).
Zu dem SQL und dem einfach:
90 Prozent der Programme (und alle typischen Dialogprogramme sind mit SQL einfacher abzubilden. Begründung: 2/3 der Logik beschäftigen sich mit Daten zusammen grabschen und das kann durch ein SQL Statement ersetzt werden.
30 Prozent der Programme fallen bei der Umstellung auf SQL weg, da sie sich nur in der Sortierfolge, oder ähnlichem von einem anderen Programm unterscheiden.
Es bleibt ein kleiner Rest, der sauberes umgehen mit SQL erfordert - in diese Ecke gehört auch Transaktions Sicherheit (was die meisten RPG Rekord Löffel Exzess Programme nicht sind).
Ein Satz noch zu Schichtentrennung:
Die Steuerung eines Batch Jobs ist Business Logik, die Datenbankzugriffsschicht sagt nach der Verarbeitung jedes Satzes Commit, wo ist da das Problem? Gerade durch saubere Schichtentrennung wird das einfacher (bis auf den Krampf mit den Activation Groups, weil man nur einmal Connecten darf- aber das ist ein völlig anderes Thema).

Dieter

[B.Hauser]

Hallo Birgitta,

ich habe auch mal RPG II programmiert (und COBOL auf Mainframe und das ist noch übler).
Zu dem SQL und dem einfach:
90 Prozent der Programme (und alle typischen Dialogprogramme sind mit SQL einfacher abzubilden. Begründung: 2/3 der Logik beschäftigen sich mit Daten zusammen grabschen und das kann durch ein SQL Statement ersetzt werden.
30 Prozent der Programme fallen bei der Umstellung auf SQL weg, da sie sich nur in der Sortierfolge, oder ähnlichem von einem anderen Programm unterscheiden.
Es bleibt ein kleiner Rest, der sauberes umgehen mit SQL erfordert - in diese Ecke gehört auch Transaktions Sicherheit (was die meisten RPG Rekord Löffel Exzess Programme nicht sind).
Ein Satz noch zu Schichtentrennung:
Die Steuerung eines Batch Jobs ist Business Logik, die Datenbankzugriffsschicht sagt nach der Verarbeitung jedes Satzes Commit, wo ist da das Problem? Gerade durch saubere Schichtentrennung wird das einfacher (bis auf den Krampf mit den Activation Groups, weil man nur einmal Connecten darf- aber das ist ein völlig anderes Thema).

Dieter

Hallo Dieter,

ich habe ja auch nichts gegen embedded SQL gesagt! Und mit einfach habe ich eigentlich nur gemeint, dass man einigermaßen wissen sollte, wie SQL funktionniert, auch wenn die Entscheidungen des Optimizers nicht immer nachvollziehbar sind.

Wenn es nach mir ginge, gäbe es keine F-Bestimmungen mehr in den RPG-Programmen. Durch geschickte Views könnten selbst etwas weniger versionierte RPG-Programmierer embedded SQL einsetzen. Vermutlich würden hunderte von Zugriffs-Wegen (bzw. logische Dateien) überflüssig werden, die heute alle mit Zugriffs-Pfadwartung *IMMED erstellt sind, da ein Unique Key auf der Datei liegt. Nur leider kann man nicht von heute auf morgen hunderte Programme (die problemlos laufen) auf embedded SQL umstellen. Performance hin oder her.

Ich würde noch viel weiter gehen und viel mehr Funktionalität, z.B. über Referentielle Integritäten und Trigger in die Datenbank packen. Am liebsten würde ich die komplette Datei-Verarbeitung direkt in SQL programmieren und als Stored Procedures aufrufen. Das RPG (oder was auch immer)-Programm würde nur noch steuern, also nur noch aus Programm- und Prozedur-Aufrufen bestehen.

Aber man gerät leider immer noch sehr oft an recht konservative Ansichten, die teilweise sogar soweit gehen, warum RPGIV in RPGIII geht doch alles.

Birgitta