Naja, schön ist alle Theorie.
Leider wird eben auch bei Client-Server-Anwendungen nicht mit App-Usern gearbeitet, da man die SQL-Funktion USER benötigt (Journale, Trigger, Prüfungen, Berechtigungen).

Daher ist gerade bei Client-Server-Anwendungen dem freien Zugriff per ODBC an der Anwendung vorbei Tür und Tor geöffnet.

Hier helfen selbst die API's nicht mehr, da nun mal der Clientuser ja für die Zugriffe berechtigt sein muss.

Die Anwendung an sich muss da schon generell anders konzipiert sein.
Um mit dem originären User auf der DB arbeiten zu können, muss der SQL-Job sich ja quasi ummelden (QSYSETPH), damit das USER-Register wieder korrekt gefüllt ist.

Allerdings meldet das API nun wieder den umgemeldeten User.

So richtig habe ich bei Client-Anwendungen keine Lösung, ODBC-Zugriffe ausserhalb der Anwendung zu sperren.

Standard-Objekt-/DB-Rechte ziehen da einfach nicht.

Generelle Konzepte mit Stored-Procedures, die Datenzugriffe grundsätzlich verbergen, finde ich da auch eher selten, obwohl mir das die einzige Lösung scheint.