Nun werden hier mehrere Themen durcheinander geworfen:

1. Der Standard-Default für CRTDSPF ist RSTDSP(*YES) zumindest auf allen Systemen die ich kenne.
Wenn er anders ist, gibt's aus irgendwelchen Gründen einen CHGCMDDFT.
Ein RSTDSP(*NO) führt mitunter zu seltsamen Verhalten. Wenn eine Programm an Stelle von EXFMT nur Write/Read's verwendet (in COBOL geht das gar nicht anders), kann es mitunter vorkommen, dass bei "Unterbrechungen" der Bildschirm nicht korrekt wiederhergestellt wird. Das Programm wartet auf einem READ aber man kann keine Eingabe mehr tätigen, nochnicht mal F-tasten werden akzeptiert.
RSTDSP(*YES) verhindert dies.

2. ASSUME war schon immer nötig, wenn ein Programm ausschließlich ein Fenster mit Window bedient.
Jeder Open einer DSPF prüft, ob es bereits eine geöffnete DSPF im Callstack übergeordnet gibt. Dieser Inhalt wird beim Open gesichert und beim Close wiederhergstellt falls RSTDSP(*YES) im übergeordneten DSPF angegeben ist.
Dies führt daher zu dem Verhalten, dass die 1. Anzeige des Fensters klappt, ab der 2. Anzeige meistens nicht. Hier hilft mitunter ein USROPN, so dass ich eben OPEN/CLOSE durchführen muss.
Noch komplexer wird es dann mit mehreren Ebenen die alle nur Fenster verwenden.

3. SQL und Native-IO haben nichts gemeinsam. Ein SQL-Connect hat ausschließlich für SQL Bedeutung, normale Datei-Befehle merken davon nichts. Früher (funktioniert heute auch noch) verwendete man im Einzelnen DDMF's mit OVRDBF. Allerdings ist hier die Grenze bei 16 gleichzeitigen Open's und die Voraussetzung SNAoverIP.