Das Exit-Programm weiß ja nicht, welche UDF denn als nächstes verwendet wird.
Außerdem wird dies ja bei jeder ODBC-Verbindung aufgerufen und darf nciht einfach die LIBL ändern, da die Umgebung ja Anwendungsspezifisch gesetzt wird.
Vielleicht wird ja gerade nur ein Excel-Import, 5250-Dateiübertragung oder ähnliches durchgeführt, wo das Problem keine Rolle spielt.

Es gibt auch einen Exit mit dem man die SQL's analysieren kann.
Man sucht die UDF's, ermittelt über die SYSFuncs/SYSProcs die dazugehörigen Programme.
Dann kann man mittles API-DSPPGMREF prüfen, ob alle Ressourcen in der Libl verfügbar sind, wobei man da nicht unbedingt alles erwischt, da embedded SQL's darüber nicht ermittelt werden können.
Hierfür braucht man dann das API für integrierte oder externe (also verwendete) SQLPKG's (analog PRTSQLINF) um die Ressourcen der dortigen SQL-Statements incl. der UDF's zu prüfen.
Wenn eine Ressource nicht ermittelt werden kann, wird der SQL mit Fehler abgewiesen.

Technisch machbar aber nicht bezahlbar.
Und die Laufzeit einer solchen "Automatik" ist auch nicht zu verachten.
Zumal das Ganze nur in 0,0000001% oder weniger aller Fälle, nähmlich falsche LIBL, sinnvoll währe.

Sonst noch einer eine Idee?
Sonst muss ich wohl oder übel in alle UDF's einen "monitor" einbauen.