QSYSLIBL und QUSRLIBL

[loeweadolf]

Danke für die Antwort. Das bedeutet doch auch, dass theoretisch sogar Benutzerbibliotheken in der SYSLIBL aufgenommen werden könnten.

[Fuerchau]

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]

Danke für die Ausführungen

[BenderD]

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

[Fuerchau]

@D*B
Was bei fast jedem Release-Wechsel/Update oder MA-Wechsel immer wieder gerne zu Problemen führt.

[holgerscherer]

... 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.

[BenderD]

... 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]

... 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.

[BenderD]

... in die lib gehören die geänderten System-Objekte!!! (CRTDUPOBJ QSYS/XXX in die eigene und dann ändern)

D*B

[Fuerchau]

Statt der eigenen Systemlib mach ich mit demselben CLP lieber den CHGCMDDFT direkt an den Originalen. Die eigene Systemlib macht mehr Probleme als es hilft.
Aber wie immer: das ist schließlich Geschmacksache.

[loeweadolf]

Wie kann ich in einem CL abfragen, ob eine bestimmte Bibliothek in der LibListe in der SYSLIBL liegt ?

[malzusrex]

CL fällt mir jetzt nix ein.

Aber wie wärs mit SQL

SELECT ORDINAL_POSITION AS POS,                         
         SYSTEM_SCHEMA_NAME AS LIBRARY,                 
         TYPE,                                          
         CAST(TEXT_DESCRIPTION AS CHAR(50)) AS TEXT     
   FROM QSYS2.LIBRARY_LIST_INFO 

Da hast die Lib-Liste des Jobs. Und da kannst du ja schauen, ob deine Lib in der Systemliste mit dabei ist.

Gruß
Ronald

https://www.rpgpgm.com/2016/02/retri...using-sql.html