@Birgitta
Bei DDS-Dateien erfolgt in COBOL mit Native-IO auch keine Prüfung auf ungültige Inhalte!
Die Schrottdaten die ich geschrieben habe bekomme ich beim Lesen genauso zurück.

Bei SQL-Tables darf ich auch in COBOL keine ungültigen Daten schreiben, das ist korrekt.
Der Unterschied zwischen COBOL und RPG ist i.W. der, dass COBOL mit den originären Dateipuffern arbeitet, währen RPG zusätzliche Moves von/zum Puffer einbaut.

Betrachte ich nun die Validierungsebenen so erhalte ich in RPG mehr als in COBOL.
RPG Lesen:
Chain/Read in internen Puffer ohne Validierung
Übertragung in Programmvariablen mit Validierung
RPG Schreiben:
Übertragung Programmvariablen in Dateipuffer mit Validierung
WRITE/UPDATE in internen Puffer ohne Validierung

COBOL Lesen:
Read in internen Puffer ohne Validierung
Eine Übertragung in Programmvariablen erfolgt erst gar nicht
COBOL Schreiben:
Eine Übertragung aus Programmvariablen erfolgt erst gar nicht
Write aus internem Puffer ohne Validierung

Bei embedded SQL habe ich sowohl in RPG als auch in COBOL grundsätzlich eine automatische Validierung, da die SQL's ja in Call's und Moves aufgelöst werden.
D.h., dass der Precompiler zusätzliche Variablen entsprechend der SQL-Definition generiert und beim Select/Fetch aus diesen in die Hostvariablen überträgt und eben beim Insert/Update aus den Host- wieder in die automatischen Variablen.
Neben der Validierung durch SQL selber erfolgt ja auch bei diesen Moves quasi schon eine Validierung, die eben durch die SQL-Schicht noch mal durchgeführt wird.

(Für jeden Move/Eval wird ja en MI-Befehl generiert und Dezimalbefehle prüfen generell auf gültige Feldinhalte, die ich aber mit IGNDECERR ausschalten kann).

Es gibt bei COBOL mit SQL keinen Geschwindigkeitsvorteil mehr gegenüber RPG mit SQL, da ja nun in beiden Fällen mit zusätzlichen Moves gearbeitet wird.