OVR's sind tatsächlich ein Problem, zumal diese gerne in einem CLP statt CLLE gemacht werden. Durch den Default ACTGRP wird das dann in der DFTACTGRP statt in der eigenen durchgeführt.
SHARE(*YES) musste ich für eine Anwendung explizit per OVRDBF wieder auf SHARE(*NO) ändern. Die Anwendung macht den SHARE(*YES), weil die Programmierer die Übersicht verloren hatten wann eine Datei nur I oder eben auch mit U geöffnet wurde.
Die SHARE-Option wirkt tatsächlich nicht auf SQL.

Ein OVRDBF wirkt allerdings auch auf SQL!
Hier scheitert dann manche "Sicherheitssoftware", die über die REGINF sich in die SQL-Überwachung reinhängt um SQL's zu analysieren, dabei aber das "Umleiten" per OVRDBF oder "CREATE ALIAS" vergessen.
Möchte man sich den OVRDBF in SQL sparen, so sind hier die Möglichkeiten eher eingeschränkt.
Entweder man arbeitet mit ALIAS-Tabellen oder mit dynamischem SQL, wobei hier Parameter wieder komplizierter sind.
Da ist ILERPG flexibler, da ich den Datei- und sogar den Teildateinamen in einer Variablen definieren kann.

Was den Druckoutput angeht, so gibt es hier nur geringe Alternativen.
Der OVRPRTF hat sich da i.W. durchgesetzt, da in einer Anwendung hier sehr viele Möglichkeiten definiert werden können (Output-Management) die sich anders nicht lösen lassen.
Im Gegensatz zur DB gibt es auch einige Formulareinstellungen die man anders nicht dynamisieren kann.
Hier sollte man halt generell mit OVRSCOPE(*JOB) arbeiten, da eine PRTF doch sehr programmspezifisch ist, ist das im Sinne der ACTGRP's eher unkritisch.