"Soweit ich weiß, wurde der SELECT * schon immer zur Compile-Zeit aufgelöst.
Das ist nämlich einer der Gründe warum von einem SELECT * immer abgeraten wird."

Nun, das kann ich auch nicht so stehen lassen!
Der "Select *" wird gar nicht (mehr?) zur Compilezeit aufgelöst!!!
Entscheidend sind nämlich hier 2 ganz andere Dinge:

1. Select .... Into ....
2. Fetch ... Into ...

D.h., der Compiler analysiert die Zielvariablen, generiert daraus seine SQLnnn-Variablen und Aufrufstrukturen, internes SQL-Paket usw.
Zur Laufzeit erst wird dann der Select von der SQL-Runtime aufgelöst und der Fetch/Select Into prüft dann, ob die Zielvariablen zum Ergebnis passen.

Beweis:
Mach mal einen dynamischen SQL mit Statement-Cursor und Prepare und anschließendem statischen Fetch in Variablen. Dies funktioniert obwohl der SQL-Compiler den Select gar nicht kennen kann.
Bei meinen ArdGate-Programmen passiert nämlich genau dieses. Dynamisches prepare, statisches Fetch, da klappt sogar dann ein "Into : MyDs".

"Die Empfehlung beim Prüfen des SQLCODE lautet entweder auf 100 (nicht gefunden) oder auf < 0 (Fehler abzufragen), jedoch nicht auf SQLCODE = 0. Diese Empfehlung wird spätestens seit Release V5R1 ausgesprochen, als für einige Situationen Warnungen ausgesprochen wurden, die zuvor akzeptiert wurden."

Und was die Abfrage des SQL-Codes nach einem Fetch angeht, so habe ich mir angewöhnt, und ich kann es nur jedem empfehlen, grundsätzlich nur Status 0 zu verarbeiten. Dies gilt ebenso bei NULL-Flags.

Begründung:
Zwar sind SQLCOD's > 0 und <> 100 nur Warnungen aber wer sagt denn, dass diese Warnungen zu vollständigen und richtigen Daten führen?
Hier ist es besser, die Daten lieber nicht zu verarbeiten, ggf. Meldungen zu produzieren oder was immer man will.
Es gibt genug PTF's die mir irgendeine SQL-Modi bringen, die ich nach Birgittas Empfehlung nie gemerkt hätte. So erhielt ich eben die Nachricht, dass eine Verarbeitung nicht läuft, konnte u.U. mit dem Kunden auch schon die eine oder andere Meldung an IBM abgeben die den Fehler dann áuch schnell beheben konnte oder den Fehler durch SQL-Anpassung beheben.
Z.B. wurde durch den Optimizer mal die Reihenfolge von Ausführungen geändert, so dass eine Datumkonvertierung plötzlich NULL ergab, was vorher nicht passierte. Hätte ich die Daten da weiterverarbeitet wären ganz andere Probleme entstanden.

Und warum soll für SQL anderes gelten als für native IO?
Beim Zugriff mittels (E)-Erweiterung frage ich ja auch nur %error() ab und nicht zusätzlich die Details der SDS? Nur bei SQL ist eben die (E)-Erweiterung ständig eingeschaltet.

Auch ein NULL-Flag -2 sollte die Verarbeitung nicht unbedingt fortsetzen, immerhin sind dann zwar Daten da, aber eben nicht vollständig (meist abgeschnitten, Ziel zu klein).
Bei native Dezimalarithmetik gibts einen MCH wenn das Ziel zu klein ist. Wer fängt sowas wirklich immer mit Monitor ab?