Theoretisch ist das unkritisch solange man an den ACTGRP's und LIBL nicht rumspielt.
Der 1. Open erfolgt automatisch und es bleibt bis zum Jobende auf.
Machst du aber z.B. einen RCLACTGRP wird die Datei vom System geschlossen.
Beim erneuten Aufruf des Serviceprogrammes bekommst du nun einen MCH36-Fehler (Speicherzugriff) da der Dateizeiger geschlossen wurde aber der Open nicht erneut durchlaufen wird.
Dies liegt daran, dass die Laufzeit ein internes Flag setzt, und den Open nicht wiederholt.
Ein USROPN hilft hier ebenso wenig, da der manuelle Open wiederum das interne Flag prüft und da dies ja noch gesetzt ist, den Open mit Fehler oder BZ = *on ablehnt.
Das ständige Open/CLose kann allerdings auch wesentlich zur Verlangsamung beitragen.

Aktuell bei einem anderen Kunden gibt es noch folgendes Problem:
Es wird eine LIBL per CHGLIBL gesetzt und anschließend diverse Programme aufgerufen. Dabei werden auch Dateien in Serviceprogrammen verwendet.
Nun wird nach erledigter Arbeit die LIBL wiederum mit CHGLIBL angepasst.
Nun arbeiten aber die Service-Programme mit den zuerst geöffneten Dateien weiter, da sie ja noch geöffnet sind.
Das Chaos ist vorprogrammiert.

D.h., dass man bestimmte Dinge dafür nun mal nicht machen kann.
Bei SQL wird dies ggf. noch gravierender, da man hier auf den realen Open nicht einwirken kann.
Aber vielleicht ist SQL da etwas intelligenter, da hier u.U. durch die LIBL oder besser Current Collection eben die korrekte Tabellen geöffnet werden und somit die Tabelle aus beiden Libs geöffnet ist.

Ein RCLACTGRP verbietet sich da nach meiner persönlichen Erfahrung.