Allerdings sollte man bei SQL-Tables beachten:
Der Formatname ist mit dem Dateinamen identisch !
Bei Native-IO ist also eine Umbenennung des Formatnamens erforderlich.
Bei SQL interessiert der Formatname natürlich nicht.
Seit Release V5R4 kann direkt beim Erstellen einer Tabelle über das Schlüssel-Wort RCDFMT direkt ein abweichender Format-Name festgelet werden. (Ebenso kann auch bei einer SQL-View ein abweichender Format-Name angegeben werden.)

Auch vor Release V5R4 waren abweichende Format-Namen möglich (allerding benötigte man dazu 2 Schritte)
1. Erstellung einer Tabelle mit dem Format-Namen als Tabellen-Name
2. Umbenennung der Tabelle auf den eigentlichen Tabellen-Namen. (Der Format-Name wird nicht unbenannt!)

Ein gewaltiger Vorteil von SQL-Tabellen gegenüber DDS beschriebenen physischen Dateien ist, dass selbst mit CPYF und *NOCHK keine ungültigen Daten übernommen werden können, d.h. alpha in numerische Felder kopieren geht nicht!
Innerhalb der SQL-Tabellen wird beim Schreiben der Daten auf Gültigkeit beprüft. Bei DDS beschriebenen physischen Dateien erfolgt die Prüfung beim Lesen.

Mit Create Index kann ich eine LF erstellen (für SQL nur Zugriffsweg), die ich mit Native-IO natürlich direkt nutzen kann.
... auf eine SQL-Tabelle können natürlich auch DDS-beschriebene logische Dateien gelegt werden.

Ein Index erhält das Format der zugrundeliegenden Tabelle (oder DDS beschriebenen physischen Datei) erst ab Release V6R1 wird es möglich sein auch in Indices einen abweichenden Format-Namen anzugeben.