Also bei der Sicherung sollte man sich genau überlegen, welche Bibliotheken zu sichern sind.
In der QUSRSYS werden normalerweise nur OUTQ's abgestellt, der Rest sind wiederung Systemobjekte. OUTQ's können nicht gesichert werden (ausser als Objekt selbst), da sie nur Spools verwalten.
Remote-Outq's verwalten halt nur Spools von Netzdruckern. Die Spools selbst (QSPL) kann sowieso nicht gesichert werden.
Da diese Outq's nun mal durch Spool-Jobs belegt sind, können diese halt nicht gesichert werden ausser man beendet mit ENDWTR *ALL und ENDSBS QSPL.
QUSRSYS sollte also nur gesichert werden (wenn überhaupt), wenn in den USER-Objekten gravierende Änderungen stattfinden.
Das gilt nun mal leider auch für QGPL. Wenn man mit Netzverteilungen (SND-Befehle) arbeitet, sind alle dazu benötigten Einträge in den QAO*-Dateien zu finden. Wenn als QSNADS aktiv ist, gibts auch Probleme beim Sichern von QGPL.

Also was soll man sichern ?

Bei der täglichen Sicherung sollte man AUSSCHLIEßLICH Anwendungs-DATEN-Bibliotheken und bestimmte IFS-System sichern.
Programm-Bibliotheken, die sich eigentlich nicht ständig ändern, sollten einmalig nach jeder Änderung separat gesichert werden (also nicht in der täglichen).
Und natürlich das System incl. Lic-Pgm's nach jedem PTF-Update.

Nun noch mal zum "Sichern im aktiven Zustand" !

Hierzu gibt das Handbuch "Work-Management-Guide" eigentlich sehr gute Auskunft
(Siehe meine Beschreibung oben).
Durch die Definition des Synchronisationspunktes (*LIB, ...) werden alle sog. Datenobjekte (im wesentlichen PF's, LF's) sozusagen gleichzeitig gegen Änderungen gesperrt. Damit die Anwendungen nix merken, werden Lesezugriffe erlaubt, Schreibzugriffe aber in einem temporären Bereich durchgeführt solange die Sicherung läuft. Sobald die Sicherung die Sperren aufhebt, werden die Änderungen aus den temporären Bereichen in die Original-Objekte übertragen und die Objekte tatsächlich freigegeben.

Warum also eine Wartezeit definieren ?
Das kann ich auch nicht beantworten, wie oben gesagt, mit einer Zeit von 0 Sekunden sichert man sehr schnell ohne auf das Freiwerden von Objekten warten zu müssen.
Datenobjekte werden auf jeden Fall korrekt gesichert. Im Joblog findet man genau, welche Objekte nicht gesichert wurden. Und das sind genau die, die auch bei langer Wartezeit (solange halt die belegenden Jobs aktiv sind) nie gesichert werden.

Besonders ist noch zu beachten, wenn man mit Journalisierung fährt. Soweit ich mich erinnere, werden Journale NIE gesichert, wenn noch offene Commit's aktiv sind. Bei einer normalen Applikation (insbesonders bei Batchverbuchern wie bei SAP) ist ständig ein Commit geöffnet, denn jeder Commit/Rollback eröffnet ein neues Commit. Erst wenn der Job beendet wird bzw. ENDCMTCTL ausgeführt ist, wird das Journal von diesem Job freigegeben.
Deswegen muss man hier bei der Datensicherung besonderes Augenmerk auf die Planung werfen, z.B.: 1x die Woche Datensicherung der kompletten Datenbank, täglich oder häufiger die Sicherung der Journale.

Dies kann man, wenn man genug Platz hat, auch mit manuellen SAV-Befehlen in eine SAVF testen oder auch halt auf Band wenn man genug Zeit hat.

Viel Spaß beim ausprobieren.