View Full Version : QSYSLIBL und QUSRLIBL
loeweadolf
28-02-20, 23:43
Hi,
WRKSYSVAL: mit QSYSLIBL ordne ich ja die Bibliotheken zu, die dann wohl ständig im Zugriff sind.
Mit QUSRLIBL ordne ich die Anwendungs-Bibliothken zu, die dann ebenfalls dem User zur Verfügung stehen, es sei denn, ich rufe bei einzelnen Usern ein Anfangs-CL auf, welches die Bibl.-Liste für den User ändert.
In der System-Lib-Liste stehen bei mir QSYS, QSYS2, QHLPPSYS und QUSRSYS
Mit EDTLIBL kann ich die Systembibliothken allerdings nicht sehen und nicht entfernen.
Meine Frage: Können in der System-Bibl.-Liste auch weitere Bibliotheken zugerdnet werden, z.B. QGPL und QTEMP, die eigentlich auch immer im Zugriff sein sollen ? Dann bräuchte ich diese in der User-Bibl.-Liste nicht besondes aufzuführen und bei Änderung der User-Bibl.-Liste nicht zu berücksichtigen ?
camouflage
29-02-20, 07:34
ja, wrksysval qsyslibl oder chgsysval qsyslibl, wobei die SYSLIBL an den Anfang der Library-List gestellt wird. Persönlich ziehe ich ein eigenes "Management" (je nach Anwendung) der Library-List vor.
loeweadolf
29-02-20, 17:56
Danke für die Antwort. Das bedeutet doch auch, dass theoretisch sogar Benutzerbibliotheken in der SYSLIBL aufgenommen werden könnten.
Das ist korrekt.
Dies gilt jedoch nur für JOBD's, die auf *SYSVAL verweisen.
Es ist jedoch besser, in geeigneten JOBD's die benötigten Libs aufzuführen, was häufig der Fall ist.
Achtung bei SBMJOB.
Der Default für USRLIBL ist hier *current, ebenso z.B. auch CURLIB.
Wenn ein Job also einen CHGLIBL/CHGCURLIB macht und dann einen SBMJOB wird dessen USRLIBL übernommen.
Erst wenn hier auf *JOBD oder *SYSVAL verwiesen wird, ändert sich die USRLIBL des neuen Jobs.
SYSLIBL bleibt jedoch meist stabil.
Zusätzlich kann man jedoch jedem SUBSYSTEM noch eine eigene SYSLIBL zuordnen. Z.B. für Sprachumgebungen eine QSYS29xx, die der SYSLIBL vorangestellt wird.
Es gibt gar garstig viele Möglichkeiten.
loeweadolf
29-02-20, 23:02
Danke für die Ausführungen
Es gibt gar garstig viele Möglichkeiten.
... chgsyslibl nicht zu vergessen.
Eine eigene Lib gehört allerdings sogar vor die QSYS, für alle geänderten Systemobjekte.
D*B
@D*B
Was bei fast jedem Release-Wechsel/Update oder MA-Wechsel immer wieder gerne zu Problemen führt.
holgerscherer
01-03-20, 18:42
... chgsyslibl nicht zu vergessen.
Eine eigene Lib gehört allerdings sogar vor die QSYS, für alle geänderten Systemobjekte.
D*B
Das würde ich absolut NICHT tun. Erstens wird beim Releasewechsel der Müll gern vergessen und produziert Probleme, nächstens muss man dann auf Security penibel achten, und wiedernächstens sollte man Systemobjekte lieber nicht so häufig ändern.
... ich habe noch kein System ohne Anpassungen gesehen (CHGCMDDFT, Änderungen PRTFs, etc..) Mit der eigenen Lib lässt man das System eben gerade völlig ohne jegliche Anpassungen. Dokumentiert werden diese alle mit einem CL, das nach Release Wechsel läuft. Natürlich braucht diese Lib denselben Schuth wie alle anderen Libs im SYSLIBL (da ändert sich qualitativ nix).
D*B
holgerscherer
02-03-20, 14:31
... ich habe noch kein System ohne Anpassungen gesehen (CHGCMDDFT, Änderungen PRTFs, etc..) Mit der eigenen Lib lässt man das System eben gerade völlig ohne jegliche Anpassungen. Dokumentiert werden diese alle mit einem CL, das nach Release Wechsel läuft. Natürlich braucht diese Lib denselben Schuth wie alle anderen Libs im SYSLIBL (da ändert sich qualitativ nix).
D*B
Das CL kann überall liegen, notfalls in der QGPL. Da braucht es keine eigene Lib für eigene Objekte.