Siehst du, geht doch alles.
Und wieso 16MB-Grenze?
Wenn du auf *TERASPACE gehst, in der gesamten Prozesskette, kannst du Speicher bis 2Tera ansprechen. Da platzt dir wahrscheinlich eher die Platte.
Im Service erbst du das Speichermodell und der Rufer gibt sein Speichermodell vor. Alles sehr flexibel.
Je ACTGRP kann ein anderes Speichermodell gewählt werden.

Vorteil von SQL:
Alle möglichen String-Funktionen können verwendet werden.
Alle CCSID's können verwendet werden.
Automatische CCSID-Wandlung inclusive.

Wenn du mein Beispiel siehst, nehme ich als Ziel DBCLOB, das ist UCS2-Code. Im Singlestorage max. 8 MB. Aber so große Dateien habe ich im Schnittstellenbereich nicht gehabt, und dann gibts ja noch Birgittas Hinweise.

Ich nehme af diesem Weg z.B. EDI-Dateien auseinander. Für EDI-XML's definiere ich passende Strukturen und verwende dann den XML-INTO.
Übrigens generell in UCS2/UTF16, da schon mal gerne der Job auf 65535 belassen wird.

Nachtrag:
Da ein Service ja von verschiedenen Programmteilen aufgerufen werden kann, muss man sich natürlich Zerstückelungslogiken sehr genau überlegen. Nicht dass während der Verarbeitung einer dazwischen grätscht.
Interessant sind Ansätze wie CALLBACK-Verarbeitung (Procedurpointer). In diesem Fall ist ein Service auch Rekursiv benutzbar.
Oder man generiert sich einen "FileControlBlock" (kennt man irgendwoher), der relevante Stati festhält. Da könnte man auch Repositionierungen durchführen und viele Dateien gleichzeitig bearbeiten. SQL hält die Datei nämlich nicht geöffnet.