Anmerkung: Vor Verwendung dieser Informationen sollten die allgemeinen Informationen unter Bemerkungen gelesen werden.
|
Diese Ausgabe bezieht sich auf IBM® Rational Developer for System z Version 9.1.1 (Programmnummer 5724-T07) und alle nachfolgenden Releases und Modifikationen, bis dieser Hinweis in einer Neuausgabe geändert wird.
Diese Veröffentlichung ist eine Übersetzung des Handbuchs
IBM Rational Developer for System z Host Configuration Reference Guide,
IBM Form SC14-7290-08,
herausgegeben von International Business Machines Corporation, USA
(C) Copyright International Business Machines Corporation 2000, 2014
Informationen, die nur für bestimmte Länder Gültigkeit haben und für Deutschland, Österreich und die Schweiz nicht zutreffen, wurden in dieser Veröffentlichung im Originaltext übernommen.
Möglicherweise sind nicht alle in dieser Übersetzung aufgeführten Produkte in Deutschland angekündigt und verfügbar; vor Entscheidungen empfiehlt sich der Kontakt mit der zuständigen IBM Geschäftsstelle.
Änderung des Textes bleibt vorbehalten.
Herausgegeben von:
TSC Germany
Kst. 2877
Dezember 2014
Dieses Dokument enthält Hintergrundinformationen zu verschiedenen Konfigurationstasks von IBM Rational Developer for System z selbst sowie zu anderen z/OS-Komponenten und -Produkten (wie WLM und CICS).
Die Informationen in diesem Dokument gelten für alle Pakete von IBM Rational Developer for System z Version 9.1.1.
Die aktuellsten Versionen dieses Dokuments finden Sie im Handbuch IBM Rational Developer for System z Hostkonfigurationsreferenz (SC12-4489) unter 'http://www-05.ibm.com/e-business/linkweb/publications/servlet/pbi.wss?CTY=US&FNC=SRX&PBL=SC14-7290'.
Die aktuellsten Versionen der kompletten Dokumentation, einschließlich Installationsanweisungen, White Papers, Podcasts und Lernprogrammen, finden Sie auf der Bibliotheksseite der IBM Rational Developer for System z-Website (http://www-01.ibm.com/software/sw-library/en_US/products/Z964267S85716U24/).
Dieses Handbuch wendet sich an Systemprogrammierer, die IBM Rational Developer for System z Version
9.1.1 konfigurieren und optimieren.
Während die eigentlichen Konfigurationsschritte in einer anderen Veröffentlichung beschrieben werden, werden in dieser Veröffentlichung verschiedene zugehörige Themen (wie Optimierung, Sicherheitskonfiguration usw.) ausführlich aufgelistet. Voraussetzung für die Verwendung dieses Handbuchs ist, dass Sie mit z/OS UNIX System Services und MVS-Hostsystemen vertraut sind.
In diesem Abschnitt werden die Änderungen in der Veröffentlichung IBM Rational Developer for System z Version
9.1.1 Hostkonfigurationsreferenz (IBM Form SC12-4489-08) zusammengefasst (Aktualisierung vom Dezember
2014).
Technische Änderungen oder Zusätze zum Text und den Abbildungen sind durch eine vertikale Linie auf der linken Seite der Änderung angegeben.
Dieses Dokument enthält Informationen, die bisher im Handbuch IBM Rational Developer for System z Version 9.1.1 Hostkonfigurationsreferenz (IBM Form SC12-4489-07) enthalten waren.
Dieses Dokument enthält Informationen, die bisher im Handbuch IBM Rational Developer for System z Version 9.0.1 Hostkonfigurationsreferenz (IBM Form SC12-4489-06) enthalten waren.
Dieses Dokument enthält Informationen, die bisher im Handbuch IBM Rational Developer for System z Version 9.0.1 Hostkonfigurationsreferenz (IBM Form SC12-4489-05) enthalten waren.
Neue Informationen:
Dieses Dokument enthält Informationen, die bisher im Handbuch IBM Rational Developer for System z Version 8.5.1 Hostkonfigurationsreferenz (IBM Form SC12-4489-03) enthalten waren.
Dieses Dokument enthält Informationen, die bisher im Handbuch IBM Rational Developer for System z Version 8.5 Hostkonfigurationsreferenz (IBM Form SC12-4489-02) enthalten waren.
Dieses Dokument enthält Informationen, die bisher im Handbuch IBM Rational Developer for System z Version 8.0.3 Hostkonfigurationsreferenz (IBM Form SC12-4489-01) enthalten waren.
Dieses Dokument enthält Informationen, die bisher im Handbuch IBM Rational Developer for System z Version 8.0.1 Hostkonfigurationsreferenz (IBM Form SC12-4489-00) enthalten waren.
In diesem Abschnitt werden die in diesem Dokument enthaltenen Informationen zusammengefasst.
Der Host von Developer for System z umfasst einige interagierende Komponenten, damit der Client auf die Host-Services und -daten zugreifen kann. Wenn Sie das Design dieser Komponenten verstehen, können Sie die richtigen Konfigurationsentscheidungen treffen.
Developer for System z ermöglicht Benutzern einer Workstation den Zugriff auf Mainframe-Computer, wenn diese selbst kein Mainframe-Computer ist. Wichtige Aspekte bei der Produktkonfiguration sind deshalb das Prüfen von Verbindungsanforderungen, das Bereitstellen von sicherer Kommunikation zwischen dem Host und der Workstation sowie das Autorisieren und Protokollieren der Aktivitäten.
Developer for System z verwendet TCP/IP, um Benutzern einer Workstation den Zugriff auf Mainframe-Computer bereitzustellen, wenn diese selbst kein Mainframe-Computer ist. TCP/IP wird außerdem für die Datenübertragung zwischen verschiedenen Komponenten und anderen Produkten verwendet.
Im Gegensatz zu herkömmlichen z/OS-Anwendungen ist Developer for System z keine einzelne Anwendung, die von Workload Manager (WLM) auf einfache Weise erkannt wird. Developer for System z umfasst mehrere interagierende Komponenten, damit der Client auf die Host-Services und -daten zugreifen kann. Einige dieser Services sind in verschiedenen Adressräumen aktiv und werden somit verschiedenen WLM-Klassifikationen zugeordnet.
RSE (Remote Systems Explorer) ist ein zentraler Bestandteil von Developer for System z. RSE besteht aus einem Dämonadressbereich, der Thread-Pooling und Adressräume steuert, um die Verbindungen und die Arbeitslast der Clients zu verwalten. Der Dämon wird als Sammelpunkt für Verbindungs- und Verwaltungszwecke eingesetzt, während die Thread-Pools die Clientarbeitslast verarbeiten.
Dadurch wird RSE das Hauptziel für die Optimierung der Installation von Developer for System z. Wenn Sie allerdings Hunderte von Benutzern verwalten, die jeweils mindestens 17 Threads, eine bestimmte Speichermenge und mindestens einen Adressraum verwenden, müssen Developer for System z und z/OS richtig konfiguriert sein.
z/OS ist ein sehr anpassungsfähiges Betriebssystem, bei dem (manchmal kleine) Systemänderungen eine enorme Auswirkung auf die Gesamtleistung haben können. Dieses Kapitel hebt einige der Änderungen hervor, die zu einer Verbesserung der Leistung von Developer for System z führen können.
Dieses Kapitel enthält nützliche Informationen für CICS Transaction Server-Administratoren.
In diesem Kapitel finden Sie Informationen dazu, wie Sie Exitroutinen schreiben können, die Developer for System z funktional erweitern.
Dieses Kapitel soll Sie beim Imitieren einer TSO-Anmeldeprozedur durch das Hinzufügen von DD-Anweisungen und Dateien zur TSO-Umgebung in Developer for System z unterstützen.
In bestimmten Situationen, z. B. beim Testen eines Upgrades, kann die Ausführung mehrerer aktiver Instanzen von Developer for System z auf demselben System erwünscht sein. Manche Ressourcen können jedoch nicht gemeinsam genutzt werden, z. B. TCP/IP-Ports, sodass die Standardeinstellungen nicht immer anwendbar sind. Anhand der Informationen in diesem Kapitel können Sie die Koexistenz verschiedener Instanzen von Developer for System z planen, um sie dann gestützt auf dieses Konfigurationshandbuch anzupassen.
Dieser Abschnitt soll Sie bei einigen allgemeinen Problemen unterstützen, die beim Konfigurieren von SSL (Secure Sockets Layer) oder beim Überprüfen oder Modifizieren einer vorhandenen Konfiguration auftreten könnten. Dieser Abschnitt stellt auch eine Beispielkonfiguration zur Verfügung, um Benutzer zu unterstützen, die sich mit einem X.509-Zertifikat selbst authentifizieren.
Dieser Abschnitt soll Sie bei einigen allgemeinen Problemen unterstützen, die beim Konfigurieren von TCP/IP oder beim Überprüfen oder Modifizieren einer vorhandenen Konfiguration auftreten könnten.
Der Host von Developer for System z umfasst einige interagierende Komponenten, damit der Client auf die Host-Services und -daten zugreifen kann. Wenn Sie das Design dieser Komponenten verstehen, können Sie die richtigen Konfigurationsentscheidungen treffen.
Die Beschreibung im vorherigen Abschnitt und in der Liste verdeutlichen die zentrale Rolle von RSE. Mit ein paar wenigen Ausnahmen läuft jede Clientkommunikation über RSE ab. Dies ermöglicht eine sicherheitsbezogene Netzkonfiguration, da nur eine eingeschränkte Menge an Ports für die Kommunikation zwischen Client und Host verwendet wird.
RSE besteht aus einem Dämonadressbereich, der Thread-Pooling und Adressräume steuert, um die Verbindungen und die Arbeitslast der Clients zu verwalten. Der Dämon wird als Sammelpunkt für Verbindungs- und Verwaltungszwecke eingesetzt, während die Thread-Pools die Clientarbeitslast verarbeiten. Auf Basis der in der Konfigurationsdatei rsed.envvars definierten Werte und der Summe aller Clientverbindungen können mehrere Adressräume von Thread-Pools durch den Dämon gestartet werden.
Abbildung 2 zeigt eine grundlegende Sicht auf die Ressourcennutzung (Prozesse und Speicher) von RSE.
RSE ist eine Java™-Anwendung, das heißt, sie ist in der z/OS UNIX-Umgebung aktiv. Dies ermöglicht eine einfache Portierung auf verschiedene Hostplattformen und direkte Kommunikation mit dem Client von Developer for System z, der ebenfalls eine Java-Anwendung ist (auf dem Eclipse-Framework basierend). Deshalb ist grundlegendes Wissen zur Arbeitsweise von z/OS UNIX und Java sehr hilfreich, um Developer for System z zu verstehen.
In z/OS UNIX wird ein Programm in einem Prozess ausgeführt, der mithilfe einer Prozess-ID (PID) identifiziert wird. Da jedes Programm in seinem eigenen Prozess aktiv ist, wird beim Aufrufen eines anderen Programms ein neuer Prozess erstellt. Auf den Prozess, der für das Starten eines anderen Prozesses verantwortlich ist, wird mithilfe einer übergeordneten Prozess-ID (Parent PID, PPID) verwiesen. Der neue Prozess wird als untergeordneter Prozess bezeichnet. Der untergeordnete Prozess kann in demselben Adressraum ausgeführt oder in einem neuen Adressraum gestartet (erstellt) werden. Ein neuer Prozess, der in demselben Adressraum ausgeführt wird, kann mit der Ausführung eines Befehls in TSO verglichen werden. Der in einem neuen Adressraum gestartete Prozess ähnelt dem Übergeben eines Batch-Jobs.
Beachten Sie, dass ein Prozess ein Einzelthread- oder ein Multithreadprozess sein kann. In einer Multithreadanwendung (wie RSE) konkurrieren die verschiedenen Threads um die Netzressourcen, als wären sie separate Adressräume (mit weniger Aufwand).
RSE kann im 31-Bit- oder 64-Bit-Adressierungsmodus ausgeführt werden, was zu unterschiedlichen Speichergrenzen führt. Im 31-Bit-Modus ist der verfügbare Speicher auf 2 GB begrenzt, während es im 64-Bit-Modus keine Einschränkung gibt, sofern es nicht anders in SYS1.PARMLIB angegeben ist.
Java-Anwendungen, wie RSE, ordnen Speicher nicht direkt zu, sondern mithilfe von Java-Speicherverwaltungsservices. Diese Services umfassen Funktionen wie das Zuordnen und Freigeben von Speicher sowie eine Garbage-Collection und werden innerhalb der Grenzwerte des Java-Heapspeichers ausgeführt. Die minimale und maximale Größe des Heapspeichers wird während des Systemstarts von Java (implizit oder explizit) definiert. Bei der Ausführung im 64-Bit-Modus versucht Java, den Heapspeicher über der 2-GB-Grenze zuzuordnen, wodurch Speicher unterhalb der Grenze freigegeben wird.
Um eine optimale Nutzung der verfügbaren Adressraumgröße zu erreichen, sollte die Größe des Heapspeichers umfangreich sein, um z/OS ausreichend Platz für die Speicherung einer variablen Menge von Systemsteuerungsblöcken (abhängig von der Anzahl aktiver Threads) zu lassen.
Abbildung 3 zeigt eine Basisübersicht über die Eigner der Sicherheitsberechtigungsnachweise, die für verschiedene Tasks in Developer for System z verwendet werden.
Das Eigentumsrecht an einer Task kann in zwei Abschnitte unterteilt werden. Gestartete Tasks gehören der Benutzer-ID, die der gestarteten Task in Ihrer Sicherheitssoftware zugewiesen wird. Alle anderen Tasks, mit Ausnahme der RSE-Thread-Pools (RSEDx), gehören der Client-Benutzer-ID.
Abbildung 3 zeigt die gestarteten Tasks in Developer for System z (DBGMGR, JMON und RSED) sowie gestartete Beispieltasks und Beispielsystemservices, mit denen Developer for System z kommuniziert. Application Deployment Manager (ADM) ist innerhalb einer CICS-Region aktiv. Der USS REXEC-Tag stellt den z/OS UNIX-REXEC-Service (oder SSH-Service) dar.
Der RSE-Dämon erstellt für die Verarbeitung von Prozessclientanforderungen mindestens einen Adressraum der RSE-Thread-Pools (RSEDx). Jeder RSE-Thread-Pool unterstützt mehrere Clients und gehört demselben Benutzer wie der RSE-Dämon. Jeder Client verfügt über eigene Threads innerhalb eines Thread-Pools. Diese Threads gehören der Client-Benutzer-ID.
Abhängig von den vom Client ausgeführten Aktionen können für die Ausführung der angeforderten Aktion zusätzliche Adressräume gestartet werden. Diese gehören alle der Client-Benutzer-ID. Diese Adressräume können ein MVS-Batch-Job, eine APPC-Transaktion oder ein untergeordneter z/OS UNIX-Prozess sein. Beachten Sie, dass ein untergeordneter z/OS UNIX-Prozess in einem z/OS UNIX-Initiator (BPXAS) aktiv ist und als gestartete Task in JES angezeigt wird.
Die Erstellung dieser Adressräume wird in den meisten Fällen von einem Benutzerthread in einem Thread-Pool entweder direkt oder mithilfe von Systemservices wie ISPF ausgelöst. Der Adressraum kann aber auch von einem Fremdanbieter erstellt werden. Der z/OS UNIX-REXEC-Service oder der SSH-Service sind beim Starten von Builds in z/OS UNIX beteiligt.
Die benutzerspezifischen Adressräume werden bei Abschluss der Tasks oder bei Ablauf eines Inaktivitätszeitgebers beendet. Die gestarteten Tasks bleiben aktiv. Die in Abbildung 3 aufgeführten Adressräume bleiben für einen längeren Zeitraum im System sichtbar. Sie sollten allerdings beachten, dass z/OS UNIX so entwickelt wurde, dass es auch einige kurz andauernde, temporäre Adressräume gibt.
Die vorangegangene Beschreibung zeigt das threadorientierte Design von RSE. Anstelle des Startens eines Adressraums für jeden Benutzer nutzen mehrere Benutzer einen Adressraum mit Einzel-Thread-Pool. Innerhalb des Thread-Pools ist jeder Miner (benutzerspezifischer Service) in seinem eigenen Thread aktiv, dem der Sicherheitskontext des Benutzers zugeordnet ist, um eine sichere Konfiguration zu gewährleisten. Das Design ist für eine große Anzahl von Benutzern mit eingeschränkter Ressourcennutzung bestimmt, deren Clients jedoch jeweils mehrere Threads verwenden (abhängig von den ausgeführten Tasks sind es 17 oder mehr).
Die Verwendung von PassTickets für alle z/OS-Services, die eine Authentifizierung erfordern, ermöglicht Developer for System z das beliebige Aufrufen dieser Services, ohne ein Kennwort speichern oder den Benutzer fortwährend danach fragen zu müssen. Die Verwendung von PassTickets für alle z/OS-Services macht außerdem ein alternatives Authentifizierungsverfahren während der Anmeldung möglich, beispielsweise durch Kennwörter für einmalige Anmeldungen und X.509-Zertifikate.
Developer for System z unterstützt mehrere Methoden für den Start eines CARMA-Servers. Alle Methoden haben Vor- und Nachteile. Außerdem stellt Developer for System z mehrere Repository Access Manager (RAM) bereit, die in zwei Gruppen eingeteilt werden können: Produktions-RAM und Muster-RAM. Es sind verschiedene Kombinationen von RAM und Serverstartmethoden als vorkonfigurierte Installation verfügbar.
Alle Serverstartmethoden nutzen eine gemeinsame Konfigurationsdatei (CRASRV.properties), die unter anderem angibt, welche Startmethode verwendet wird.
Die Methode "CRASTART" startet den CARMA-Server als Subtask innerhalb von RSE. Bei dieser sehr flexiblen Konfiguration wird eine gesonderte Konfigurationsdatei verwendet, die für den Start eines CARMA-Servers erforderliche Dateizuordnungen und Programmaufrufe definiert. Mit dieser Methode wird die beste Leistung erreicht. Sie nutzt am wenigsten Ressourcen, erfordert jedoch, dass sich das Modul CRASTART im LPA befindet.
RSE ruft das Lademodul CRASTART auf, das ausgehend von den Definitionen in crastart*.conf eine gültige Umgebung für die Ausführung von TSO- und ISPF-Batchbefehlen erstellt. Developer for System z kann in dieser Umgebung den CARMA-Server CRASERV ausführen. Developer for System z stellt mehrere Dateien crastart*.conf bereit, die jeweils für einen bestimmten RAM vorkonfiguriert sind.
Die Methode der Batchübergabe startet den CARMA-Server durch Übergabe eines Jobs. Dies ist die in den bereitgestellten Beispielkonfigurationsdateien verwendete Standardmethode. Sie hat den Vorteil, dass in der Jobausgabe ohne großen Aufwand auf die CARMA-Protokolle zugegriffen werden kann. Bei dieser Methode kann jeder Entwickler auch eigene Server-JCL verwenden, die er selbst verwaltet. Allerdings wird bei dieser Methode pro Entwickler, der einen CARMA-Server startet, ein JES-Initiator verwendet.
RSE ruft dis CLIST CRASUB* auf, die wiederum eine eingebettete JCL übergibt, um eine gültige Umgebung für die Ausführung von TSO- und ISPF-Batchbefehlen zu erstellen. Developer for System z führt in dieser Umgebung den CARMA-Server (CRASERV) aus. Developer for System z stellt mehrere Member "CRASUB*" bereit, die jeweils für einen bestimmten RAM vorkonfiguriert sind.
Innerhalb der Einzelserverkonfiguration von Developer for System z, bei der mehrere Benutzer einem Adressraum mit Einzel-Thread-Pool zugeordnet werden, hat z/OS die Fähigkeit verloren, mit dem Bedienerbefehl DISPLAY GRS,RES=(*,dataset*) zu verfolgen, wer der Eigner einer Sperre für eine Datei oder ein Member ist. Systembefehle stoppen auf der Adressraumebene, die dem RSE-Thread-Pool entspricht.
Developer for System z spricht dieses Problem durch Bereitstellung des Bedienerbefehls MODIFY rsed APPL=DISPLAY OWNER,DATASET=dataset an. Eine entsprechende Beschreibung hierzu enthält das Kapitel "Operatorbefehle" im Handbuch Hostkonfiguration (IBM Form SC12-4062). Dieser Bedienerbefehl ist in der Lage, sämtliche von RSE-Benutzern verhängten Sperren für Dateien und Member aufzuheben sowie die von anderen Produkten (wie etwa ISPF) gesetzten Sperren zu lösen.
Normalerweise wird eine Datei oder ein Member gesperrt, sobald sie/es im Editiermodus geöffnet wird, und die Sperre aufgehoben, wenn der Client die Editiersitzung beendet.
Bestimmte Fehlerbedingungen können den ordnungsgemäßen Ablauf dieses Mechanismus beeinträchtigen. In diesem Fall kann der Benutzer, der Eigentümer der Sperre ist, mithilfe des RSE-Bedienerbefehls modify cancel abgebrochen werden, wie im Abschnitt "Bedienerbefehle" im Handbuch Hostkonfiguration (IBM Form SC12-4062) beschrieben. Während dieses Prozesses werden alle aktiven Sperren von Dateien aufgehoben, die mit diesem Benutzer verknüpft sind.
Abbildung 8 liefert einen Überblick über die von Developer for System z verwendeten z/OS UNIX-Verzeichnisse. Die folgende Liste enthält nicht nur Informationen zu jedem von Developer for System z verwendeten Verzeichnis, sondern gibt auch an, wie die Position geändert werden kann und wer die darin enthaltenen Daten verwaltet.
Die im Verzeichnis /var/rdz/pushtoclient/ enthaltenen Daten werden von Benutzern ohne Administratorrechte, beispielsweise von Projektmanagern, verwaltet. Diese Benutzer haben unter z/OS UNIX möglicherweise kaum Aktualisierungsberechtigungen. Daher ist es wichtig, zu verstehen, wie z/OS UNIX Zugriffsberechtigungen während der Dateierstellung festlegt, um sicherzustellen, dass Sie über eine betriebsfähige und gleichzeitig sichere Installation verfügen.
UNIX-Standards erfordern, dass Berechtigungen für drei Benutzertypen festgelegt werden können: Eigentümer, Gruppe und Sonstige. Lese-, Schreib- und Ausführungsberechtigungen können für jeden Typ individuell festgelegt werden.
Jeder Standort kann seine eigene standardmäßige Zugriffsberechtigungsmaske festlegen, eine allgemeine Maske gewährt dem Eigentümer jedoch Lese- und Schreibberechtigung und der Gruppe und Sonstigen Leseberechtigung.
Daten in /var/rdz/pushtoclient/ werden mithilfe der Zugriffsberechtigungsmaske erstellt, die in der Anweisung file.permission von pushtoclient.properties definiert ist. Der Standardwert gewährt dem Eigentümer und der Gruppe Lese- und Schreibberechtigung und Sonstigen Leseberechtigung. Alle verfügen über Ausführungsberechtigung. Die abschließenden Zugriffsberechtigungen sollten allen Benutzern Lese- und Ausführungsberechtigung und den Clientadministratoren von Developer for System z, die die Daten verwalten, Schreibberechtigung gewähren.
Die Daten im Verzeichnis /var/rdz/pushtoclient/projects/ werden ohne bestimmte Zugriffsberechtigungsmaske erstellt. Die abschließenden Zugriffsberechtigungen sollten allen Benutzern Leseberechtigung und den Projektmanagern, die die Daten verwalten, Schreibberechtigung gewähren.
ADDGROUP RDZPROJ OMVS(GID(1200))
CONNECT IBMUSER GROUP(RDZPROJ)
ALTUSER IBMUSER DFLTGRP(RDZPROJ)
ls -lR /var/rdz/pushtoclient/
chown –R IBMUSER /var/rdz/pushtoclient/
chgrp -R RDZPROJ /var/rdz/pushtoclient/
chmod -R 775 /var/rdz/pushtoclient/
Im folgenden Szenario erhalten alle Entwicklungsprojektmanager - ein aus drei Personen bestehendes Team - die Task, als Clientadministrator von Developer for System z zu fungieren.
# chmod 775 /var/rdz/pushtoclient
# ls -ld /var/rdz/pushtoclient
drwxrwxr-x 2 IBMUSER SYS1
/var/rdz/pushtoclient
# chgrp RDZPROJ /var/rdz/pushtoclient
# ls –ld /var/rdz/pushtoclient
drwxrwxr-x 2 IBMUSER RDZPROJ
/var/rdz/pushtoclient
Damit ist die Konfiguration abgeschlossen, die erforderlich ist, um Schreibberechtigungen für /var/rdz/pushtoclient auf den Systemprogrammierer (IBMUSER) und die Projektmanager (RDZPROJ) zu beschränken.
Developer for System z ermöglicht Benutzern einer Workstation den Zugriff auf Mainframe-Computer, wenn diese selbst kein Mainframe-Computer ist. Wichtige Aspekte bei der Produktkonfiguration sind deshalb das Prüfen von Verbindungsanforderungen, das Bereitstellen von sicherer Kommunikation zwischen dem Host und der Workstation sowie das Autorisieren und Protokollieren der Aktivitäten.
Die von den Servern und Services von Developer for System z verwendeten Sicherheitsmechanismen sind nur wirksam, wenn die zugrunde liegenden Dateisysteme geschützt sind. Dies impliziert, dass die Programmbibliotheken und Konfigurationsdateien nur von vertrauenswürdigen Systemadministratoren aktualisiert werden können.
Dieses Kapitel enthält die folgenden Abschnitte:
Lesen Sie Wissenswertes zu Developer for System z, um mehr über grundlegende Designkonzepte von Developer for System z zu erfahren.
Developer for System z unterstützt mehrere Möglichkeiten für die Authentifizierung einer Benutzer-ID, die von einem Client bei der Herstellung einer Verbindung bereitgestellt wurde.
Der Client stellt bei der Herstellung einer Verbindung die Benutzer-ID und das entsprechende Kennwort bereit. Die Benutzer-ID und das Kennwort werden verwendet, um den Benutzer mit Ihrem Sicherheitsprodukt zu authentifizieren.
Basierend auf einem eindeutigen Token kann ein Kennwort für einmaliges Anmelden durch ein Produkt eines anderen Anbieters generiert werden. Kennwörter für einmaliges Anmelden dienen zur Verbesserung Ihrer Sicherheitseinstellung, da ein eindeutiges Kennwort nicht kopiert und nicht ohne die Zustimmung des Benutzers verwendet werden kann. Darüber hinaus ist es unbrauchbar, wenn es abgefangen wird, da es nur einmalig gültig ist.
Bei der Herstellung einer Verbindung stellt der Client eine Benutzer-ID und ein Kennwort für einmaliges Anmelden zur Verfügung. Dieses wird von einem Fremdanbieter bereitgestellt und dient zur Authentifizierung der Benutzer-ID mit dem Sicherheitsexit. Dieser Sicherheitsexit sollte die PassTickets ignorieren, die während der normalen Verarbeitung die Authentifizierungsanforderungen erfüllen. Die PassTickets müssen von Ihrer Sicherheitssoftware verarbeitet werden.
Der Client stellt beim Herstellen einer Verbindung eine Benutzer-ID und eine entsprechende Kennphrase bereit. Die Benutzer-ID und die Kennphrase werden verwendet, um den Benutzer mit Ihrem Sicherheitsprodukt zu authentifizieren.
Ein Fremdanbieter kann ein oder mehrere X.509-Zertifikate bereitstellen, die zur Authentifizierung eines Benutzers verwendet werden. Wenn das X.509-Zertifikat auf geschützten Einheiten gespeichert ist, kombiniert es eine sichere Konfiguration mit einem hohen Bedienungskomfort, da weder eine Benutzer-ID noch ein Kennwort erforderlich ist.
Beim Herstellen der Verbindung stellt der Client ein ausgewähltes Zertifikat und optional eine ausgewählte Erweiterung bereit, die zur Authentifizierung der Benutzer-ID mit Ihrem Sicherheitsprodukt dient.
Die Clientauthentifizierung wird vom RSE-Dämon (oder REXEC/SSH) als Teil der Verbindungsanforderung des Clients vorgenommen. Sobald der Benutzer authentifiziert ist, werden selbsterstellte PassTickets für alle zukünftigen Authentifizierungsanforderungen verwendet, einschließlich des automatischen Anmeldens beim JES Job Monitor.
JES Job Monitor muss für die Überprüfung von PassTickets berechtigt sein, damit eine Überprüfung durch JES Job Monitor für die vom RSE übermittelten Benutzer-IDs und PassTickets möglich ist. Dies impliziert Folgendes:
Die Clientauthentifizierung wird vom RSE-Dämon (oder REXEC/SSH) als Teil der Verbindungsanforderung des Clients vorgenommen. Sobald der Benutzer authentifiziert ist, werden selbsterstellte PassTickets für alle zukünftigen Authentifizierungsanforderungen verwendet, einschließlich des automatischen Anmeldens beim Debug Manager.
Debug Manager muss für die Überprüfung von PassTickets berechtigt sein, damit eine Überprüfung durch Debug Manager für die vom RSE übermittelten Benutzer-IDs und PassTickets möglich ist. Das Lademodul AQEZPCM, das sich standardmäßig in der Ladebibliothek FEK.SFEKAUTH befindet, muss deshalb für APF-autorisiert sein.
Wenn eine clientbasierte Debug-Engine eine Verbindung zu Debug
Manager herstellt, muss sie ein gültiges Sicherheitstoken für die Authentifizierung vorlegen.
Developer for System z basiert auf Produkten eines Drittherstellers (z. B. TN3270-Server), um einige Services bereitzustellen. Informationen zu den Verbindungssicherheitsoptionen finden Sie in der entsprechenden Produktdokumentation.
Der Systemprogrammierer kann die Ports angeben, über die der RSE-Server mit dem Client kommunizieren kann. Standardmäßig kann jeder verfügbare Port verwendet werden. Dieser Portbereich steht nicht in Verbindung mit dem Port des RSE-Dämons.
Alle externen Datenströme von Developer for System z, die den RSE-Server passieren, können mit SSL (Secure Sockets Layer) oder TLS (Transport Layer Security) verschlüsselt werden. Die Verwendung der verschlüsselten Kommunikation wird von den Einstellungen in der Konfigurationsdatei ssl.properties gesteuert. Lesen Sie hierzu die Beschreibung im Abschnitt Mit SSL/TLS verschlüsselte Kommunikation. Die Variable DSTORE_SSL_ALGORITHM in der Anweisung _RSE_JAVAOPTS von rsed.envvars ermöglicht Ihnen, zwischen SSL und dem Nachfolgeprotokoll TLS als Verschlüsselungsmethode zu wählen. Dies wird im Abschnitt "Zusätzliche Java-Startparameter mit _RSE_JAVAOPTS definieren" im Handbuch Hostkonfiguration (IBM Form SC12-4062) dokumentiert.
Die Integrated Debugger-Engine des Clients wird mit dem Debug Manager des Hosts verbunden. Die Verwendung von SSL oder TLS wird von einer AT-TLS-Richtlinie (Application Transparent Transport Layer Security) gesteuert.
Der Host-Connect-Emulator auf dem Client stellt eine Verbindung zu einem TN3270-Server auf dem Host her. Die Verwendung von SSL oder TLS wird von TN3270 gesteuert. Diese Art der Verwendung ist im Handbuch Communications Server IP Configuration Guide (IBM Form SC31-8775) dokumentiert.
Ferne (hostbasierte) Aktionen in z/OS UNIX-Unterprojekten verwenden einen REXEC- oder SSH-Server auf dem Host. Die SSH-Kommunikation wird immer mit SSL verschlüsselt.
Die Clientkomponente von Application Deployment Manager ruft mit dem CICS-TS-Web-Service bzw. der RESTful-Schnittstelle die Hostservices von Application Deployment Manager auf. Die Verwendung von SSL wird von CICS-TS gesteuert. Diese Art der Verwendung ist im Handbuch RACF Security Guide for CICS TS dokumentiert.
Developer for System z unterstützt die Prüfung des Eingangsports, die eine Beschränkung des Hostzugriffs auf anerkannte TCP/IP-Adressen ermöglicht. Die Verwendung des Eingangsports wird von der Definition bestimmter Profile in Ihrer Sicherheitssoftware sowie von der Anweisung enable.port.of.entry in rsed.envvars gesteuert. Eine diesbezügliche Beschreibung finden Sie unter Eingangsport (POE) überprüfen.
Die Aktivierung des Eingangsports wirkt sich auch auf andere TCP/IP-Anwendungen aus, die die Überprüfung des Eingangsports unterstützen, wie z. B. auf INETD.
Nach der Anmeldung kann mit PassTickets innerhalb des RSE-Servers die Threadsicherheit gewährleistet werden. Dieses Feature kann nicht inaktiviert werden. PassTickets sind vom System generierte Kennwörter mit einer Lebensdauer von ca. 10 Minuten. Die generierten PassTickets basieren auf den DES-Verschlüsselungsalgorithmen, der Benutzer-ID, der Anwendungs-ID, einer Zeitmarke und einem geheimen Schlüssel. Dieser geheime Schlüssel ist eine 64-Bit-Zahl (16 Hexadezimalzeichen), die für Ihre Sicherheitssoftware definiert werden muss. Um die Sicherheit zu erhöhen, verarbeitet die Sicherheitssoftware von z/OS PassTickets standardmäßig als einmal verwendbare Kennwörter.
Das eigentliche Kennwort des Clients wird nach der ersten Authentifizierung nicht mehr benötigt, da die mit SAF kompatiblen Sicherheitsprodukte sowohl PassTickets als auch reguläre Kennwörter überprüfen. Der RSE-Server generiert jedes Mal, wenn ein Kennwort erforderlich ist, ein PassTicket und verwendet dieses, sodass das Kennwort für den Client nur temporär gültig ist.
Durch die Verwendung von PassTickets kann RSE eine beliebige benutzerspezifische Sicherheitsumgebung einrichten, ohne dabei alle Benutzer-IDs und Kennwörter in einer Tabelle speichern zu müssen, was zu einer Beeinträchtigung führen könnte. Außerdem werden Clientauthentifizierungen ermöglicht, die keine wiederverwendbaren Kennwörter verwenden, wie X.509-Zertifikate.
Für Sicherheitsprofile in den Klassen APPL und PTKTDATA ist es erforderlich, PassTickets verwenden zu können. Diese Profile sind anwendungsspezifisch und haben daher keine Auswirkung auf Ihre aktuelle Systemkonfiguration.
Als Voraussetzung für anwendungsspezifische PassTickets müssen sowohl RSE als auch JES Job Monitor die gleiche Anwendungs-ID (APPLID) verwenden. Als Anwendungs-ID wird von beiden Servern standardmäßig FEKAPPL verwendet. Dies kann jedoch durch die Anweisung der APPLID in rsed.envvars für RSE und in FEJJCNFG für JES Job Monitor geändert werden.
Sie sollten OMVSAPPL nicht als Anwendungs-ID verwenden, da diese ID den geheimen Schlüssel zu den meisten z/OS UNIX-Anwendungen entschlüsselt. Sie sollten ebenso nicht die standardmäßige MVS-Anwendungs-ID (MVS gefolgt von der SMF-ID des Systems) verwenden, da diese ID den geheimen Schlüssel zu den meisten MVS-Anwendungen (einschließlich Benutzer-Batch-Jobs) entschlüsselt.
Die kleinste Einheit einer PassTicket-Zeitmarke ist 1 Sekunde. Das bedeutet, dass alle PassTickets, die innerhalb einer Sekunde von der gleichen Anwendung für dieselbe Benutzer-ID generiert werden, identisch sind. Dies sowie die Behandlung von PassTickets durch die Sicherheitssoftware von z/OS als nur einmal verwendbare Kennwörter stellt für Developer for System z ein Problem während der Anmeldung dar, da innerhalb einer Sekunde mehrere PassTickets erforderlich sind. Daher muss für Developer for System z in den Definitionen von PassTickets ein Flag (Markierung) gesetzt werden, das die generierten PassTickets als wiederverwendbar deklariert.
Achtung: Die Clientverbindungsanforderung schlägt fehl, wenn PassTickets nicht richtig konfiguriert sind.
|
Developer for System z unterstützt die Prüfprotokollierung für Aktionen, die vom RSE-Dämon verwaltet werden. Die Prüfprotokolle werden als Textdateien im CSV-Format (Comma Separated Value) im Dämonprotokollverzeichnis gespeichert.
Mit dem Bedienerbefehl modify switch kann manuell zu einer neuen Prüfprotokolldatei gewechselt werden (siehe Abschnitt "Bedienerbefehle" im Handbuch Hostkonfiguration (IBM Form SC12-4062)).
Wenn im Dateisystem mit den Prüfprotokolldateien nur noch ein kleiner freier Speicherbereich verfügbar ist, wird eine Warnung an die Konsole gesendet. Diese Konsolennachricht (FEK103E) wird immer wieder angezeigt, bis das Speicherproblem gelöst ist.
Nach einer vordefinierten Zeit oder nach dem Absetzen des Bedienerbefehls modify switch wird eine neue Prüfprotokolldatei begonnen. Die alte Protokolldatei wird unter dem Namen audit.log.jjjjmmdd.hhmmss gespeichert. Der Abschnitt jjjjmmdd.hhmmss steht hier für die Datums-/Zeitmarke der Schließung dieses Protokolls. Die der Datei vom System zugeordnete Datums-/Zeitmarke (Datum und Uhrzeit) zeigt an, dass es sich um eine archivierte Protokolldatei handelt. Aus der Kombination der Zeitmarken zweier aufeinanderfolgender Prüfprotokolldateien können Sie den von der älteren Datei abgedeckten Zeitraum ersehen.
Mit den audit.action*-Direktiven in rsed.envvars können Sie einen Benutzerexit (z/OS UNIX-Shell-Script, z/OS UNIX-REXX oder z/OS UNIX-Programm) angeben, der beim Schließen eines Prüfprotokolls von RSE aufgerufen wird. Dieser Benutzerexit kann dann den Inhalt des Prüfprotokolls verarbeiten.
Prüfprotokolldateien haben die Berechtigungsbitmaske 640 (-rw-r-----), sofern dies nicht in rsed.envvars durch die Direktive audit.log.mode geändert wurde. Dies bedeutet, dass der Eigner (z/OS UNIX-Benutzer-ID des RSE-Dämons) Lese- und Schreibzugriff auf die Dateien und die Standardgruppe des Eigners Lesezugriff hat. Alle anderen Zugriffsversuche werden zurückgewiesen, sofern sie nicht von einem Superuser (UID 0) oder einer Person mit entsprechenden Berechtigungen für das Profil SUPERUSER.FILESYS der Sicherheitsklasse UNIXPRIV unternommen werden.
yyyy/mm/dd hh:mm:ss.sss,userid,action,dataset_name[,returncode]
[,additional_information]]
yyyy/mm/dd hh:mm:ss.sss,userid,action,dataset_name,returncode,create%nmodify%n…
Developer for System z ermöglicht Clients den Zugriff auf die JES-Spooldatei über JES Job Monitor. Der Server etabliert Basiszugriffsbeschränkungen, die Sie mit den Standardschutzfeatures für die Spooldatei in Ihrem Sicherheitsprodukt erweitern können. Bedieneraktionen für Spooldateien (Hold, Release, Cancel und Purge) werden über die EMCS-Konsole ausgeführt, für die bedingte Berechtigungen konfiguriert werden müssen.
JES Job Monitor ermöglicht Benutzern von Developer for System z keinen umfassenden JES-Spoolzugriff. Es stehen nur die Befehle 'Hold', 'Release', 'Cancel' und 'Purge' zur Verfügung und dies standardmäßig nur für Spooldateien, deren Eigner der Benutzer ist. Die Befehle werden durch Auswahl der entsprechenden Option in der Clientmenüstruktur abgesetzt (keine Eingabeaufforderung). Mit Sicherheitsprofilen, die definieren, für welche Jobs die Befehle verfügbar sind, kann der Geltungsbereich der Befehle ausgedehnt werden.
Ähnlich wie das SDSF-Aktionszeichen SJ unterstützt auch JES Job Monitor den Befehl 'JCL anzeigen', um die JCL abzurufen, die die ausgewählte Jobausgabe erstellt hat. Diese wird in einem Editierfenster angezeigt. JES Job Monitor ruft die JCL von JES ab. Dies ist eine hilfreiche Funktion in Situationen, in denen das ursprüngliche JCL-Member nicht einfach auffindbar ist.
Aktion | JES2 | JES3 |
---|---|---|
Hold | $Hx(jobid) x = {J, S oder T} |
*F,J=jobid,H |
Release | $Ax(jobid) x = {J, S oder T} |
*F,J=jobid,R |
Cancel | $Cx(jobid) x = {J, S oder T} |
*F,J=jobid,C |
Purge | $Cx(jobid),P x = {J, S oder T} |
*F,J=jobid,C |
JCL anzeigen | Nicht zutreffend | Nicht zutreffend |
Die verfügbaren JES-Befehle, die in Tabelle 1 aufgelistet sind, sind standardmäßig auf Jobs beschränkt, deren Eigner der Benutzer ist. Dies kann mit der Anweisung LIMIT_COMMANDS geändert werden (siehe Abschnitt "FEJJCNFG (JES Job Monitor-Konfigurationsdatei)" im Handbuch Hostkonfiguration (IBM Form SC12-4062)).
Jobeigner | ||
---|---|---|
LIMIT_COMMANDS | Benutzer | Anderer Eigner |
USERID (Standard) | Zulässig | Nicht zulässig |
LIMITED | Zulässig | Zulässig, wenn die Berechtigung explizit in den Sicherheitsprofilen erteilt wird |
NOLIMIT | Zulässig | Zulässig, wenn die Sicherheitsprofile die Berechtigung enthalten oder die JESSPOOL-Klasse nicht aktiv ist |
Für den Schutz von SYSIN/SYSOUT-Dateien verwendet das JES die Klasse JESSPOOL. Ähnlich wie SDSF, wendet JES Job Monitor die Klasse JESSPOOL auch auf den Schutz von Jobressourcen an.
Befehl | JESSPOOL-Profil | Erforderlicher Zugriff |
---|---|---|
Hold | nodeid.userid.jobname.jobid | ALTER |
Release | nodeid.userid.jobname.jobid | ALTER |
Cancel | nodeid.userid.jobname.jobid | ALTER |
Purge | nodeid.userid.jobname.jobid | ALTER |
JCL anzeigen | nodeid.userid.jobname.jobid.JCL | READ |
Knoten-ID | NJE-Knoten-ID des Ziel-JES |
Benutzer-ID | Lokale Benutzer-ID des Jobeigners |
Jobname | Name des Jobs |
Job-ID | JES-Job-ID |
Wenn die Klasse JESSPOOL nicht aktiv ist, bewirken die Werte LIMITED und NOLIMIT für LIMIT_COMMANDS ein unterschiedliches Verhalten (siehe "Matrixtabelle LIMIT_COMMANDS mit Befehlsberechtigungen" in "FEJJCNFG (JES Job Monitor-Konfigurationsdatei)" in Hostkonfiguration (IBM Form SC12-4062)). Das Verhalten beider Werte ist identisch, wenn JESSPOOL aktiv ist, denn die Klasse verweigert den Zugriff standardmäßig, wenn ein Profil nicht definiert ist.
Nachdem die zulässigen Ziele angegeben sind, besteht die zweite Phase der Befehlssicherheit für JES-Spoolprogramme aus den Berechtigungen, die für das tatsächliche Ausführen des Bedienerbefehls erforderlich sind. Die Sicherheitsprüfungen für z/OS und JES erzwingen diese Ausführungsberechtigungen.
Beachten Sie, dass der Befehl 'JCL anzeigen' kein Bedienerbefehl wie die anderen JES Job Monitor-Befehle (Hold, Release, Cancel und Purge) ist. Daher finden die Beschränkungen in der nachfolgenden Liste keine Anwendung, denn es findet keine weitere Sicherheitsprüfung statt.
JES Job Monitor setzt alle von einem Benutzer angeforderten JES-Bedienerbefehle über eine erweiterte MCS-Konsole (EMCS) ab, deren Bezeichnung durch die Anweisung CONSOLE_NAME gesteuert wird, wie im Abschnitt "FEJJCNFG (JES Job Monitor-Konfigurationsdatei)" in Hostkonfiguration (IBM Form SC12-4062) dokumentiert.
Mit JES Job Monitor können Sie definieren, wieviel Berechtigung der EMCS-Konsole gemäß der Richtlinie LIMIT_CONSOLE gewährt wird, wie in "FEJJCNFG, JES Job Monitor-Konfigurationsdatei" im Handbuch Hostkonfiguration (SC12-4062) dokumentiert.
LIMIT_CONSOLE | Aktives Profil in der Klasse OPERCMDS | Kein aktives Profil in der Klasse OPERCMDS |
---|---|---|
LIMITED (Standardwert) | Zulässig, wenn durch Sicherheitsprofil zugelassen | Nicht zulässig |
NOLIMIT | Zulässig, wenn durch Sicherheitsprofil zugelassen | Zulässig |
Ihre Sicherheitssoftware verhindert, dass ein Benutzer in einer TSO-Sitzung eine Konsole JMON erstellt, weil er sich so als JES Job Monitor-Server ausgeben könnte. Auch wenn die Konsole erstellt werden kann, unterscheidet sich der Eingangsport (JES Job Monitor oder TSO). Von dieser Konsole abgesetzte JES-Befehle werden jedoch nicht die Sicherheitsprüfung bestehen, wenn Ihre Sicherheitssoftware wie in dieser Veröffentlichung beschrieben konfiguriert und der Benutzer nicht autorisiert ist, JES-Befehle über andere Mechanismen zu verwenden.
Weitere Informationen zum Bedienerbefehlsschutz finden Sie im Security Server RACF Security Administrator's Guide (IBM Form SA22-7683).
JES Job Monitor erlaubt standardmäßig die Anzeige aller Spooldateien. Dies kann mit der Anweisung LIMIT_VIEW geändert werden (siehe Abschnitt "FEJJCNFG (JES Job Monitor-Konfigurationsdatei)" im Handbuch Hostkonfiguration (IBM Form SC12-4062)).
Jobeigner | ||
---|---|---|
LIMIT_VIEW | Benutzer | Anderer Eigner |
USERID | Zulässig | Nicht zulässig |
NOLIMIT (default) | Zulässig | Zulässig, wenn die Sicherheitsprofile die Berechtigung enthalten oder die JESSPOOL-Klasse nicht aktiv ist |
Wenn Benutzer nur ihre eigenen JES-Spool-Jobs anzeigen können sollen, definieren Sie in der Konfigurationsdatei von JES Job Monitor (FEJJCNFG) die Anweisung "LIMIT_VIEW=USERID". Falls Benutzer auf weitere Jobs zugreifen müssen, jedoch nicht auf alle Jobs, können Sie die Standardschutzfeatures für Spooldateien verwenden, beispielsweise die Klasse JESSPOOL.
Denken Sie beim Definieren weiterer Schutzmaßnahmen daran, dass JES Job Monitor für den Zugriff auf Spooldateien (die SYSOUT-Anwendungsprogrammierschnittstelle) SAPI verwendet. Damit ist impliziert, dass der Benutzer für Spooldateien (selbst zum Anzeigen) zumindest die Berechtigung UPDATE haben muss. Diese Voraussetzung gilt nicht unter z/OS ab Version 1.7 (für JES3 unter z/OS ab Version 1.8). Für Anzeigefunktionen ist die Berechtigung READ ausreichend.
Weitere Informationen zum Schutz von JES-Spooldateien finden Sie im Security Server RACF Security Administrator's Guide (IBM Form SA22-7683).
Die externe Kommunikation (Client-Host) mit RSE kann mit SSL (Secure Socket Layer) oder TLS (Transport Layer Security) verschlüsselt werden. Dieses Feature ist standardmäßig inaktiviert und wird von den Einstellungen in ssl.properties gesteuert. Weitere Informationen hierzu finden Sie im Abschnitt "ssl.properties, RSE-SSL-Verschlüsselung (optional)" im Handbuch Hostkonfiguration (IBM Form SC12-4062).
Aufgrund unterschiedlicher Architektur unterstützen der RSE-Dämon und der RSE-Server verschiedene Mechanismen zum Speichern von Zertifikaten. Dies impliziert, dass für den RSE-Dämon sowie den RSE-Server SSL-Definitionen und -Zertifikate erforderlich sind. Ein gemeinsam genutztes Zertifikat kann verwendet werden, wenn der RSE-Dämon und der RSE-Server dieselbe Zertifikatsverwaltungsmethode verwenden.
Zertifikatsspeicher | Erstellt und verwaltet von | RSE-Dämon | RSE-Server |
---|---|---|---|
Schlüsseldatei | SAF-konformes Sicherheitsprodukt | unterstützt | unterstützt |
Schlüsseldatenbank | z/OS UNIX gskkyman | unterstützt | / |
Keystore | Java-Keytool | / | unterstützt |
SAF-konforme Schlüsseldateien können den privaten Schlüssel eines Zertifikats entweder in der Sicherheitsdatenbank oder mithilfe von ICSF (Integrated Cryptographic Service Facility) speichern, der Schnittstelle für Verschlüsselungshardware von System z.
ICSF wird für die Speicherung von privaten Schlüsseln für digitale Zertifikate empfohlen, da diese Methode sicherer als andere Lösungen zur Verwaltung von privaten Schlüsseln ohne ICSF ist. Mit ICSF wird sichergestellt, dass private Schlüssel unter dem ICSF-Masterschlüssel verschlüsselt werden und dass der Zugriff auf diese Schlüssel von allgemeinen Ressourcen in den Sicherheitsklassen CSFKEYS und CSFSERV gesteuert wird. Außerdem bietet ICSF eine bessere Betriebsleistung, da bei dieser Methode die Hardware Cryptographic Coprocessor verwendet. Weitere Informationen zu ICSF und zur Steuerung der Verwendung von Verschlüsselungsschlüsseln und Verschlüsselungsservices finden Sie im Handbuch Cryptographic Services ICSF Administrator's Guide (IBM Form SA22-7521).
Zum Verwalten von Kommunikation, die mit SSL verschlüsselt ist, verwendet der RSE-Dämon System SSL-Funktionen. Dies impliziert, dass SYS1.SIEALNKE von Ihrer Sicherheitssoftware programmgesteuert und RSE über LINKLIST oder die STEPLIB-Anweisung in rsed.envvars verfügbar sein muss.
Die Variable DSTORE_SSL_ALGORITHM in der Anweisung _RSE_JAVAOPTS von rsed.envvars ermöglicht Ihnen, zwischen SSL Nachfolgeprotokoll TLS als Verschlüsselungsmethode zu wählen. Dies wird im Abschnitt "Zusätzliche Java-Startparameter mit _RSE_JAVAOPTS definieren" im Handbuch Hostkonfiguration (IBM Form SC12-4062) dokumentiert.
Weitere Details zur Aktivierung von SSL für Developer for System z finden Sie in SSL- und X.509-Authentifizierung konfigurieren.
Standardmäßig greift der RSE-Dämon für unterstützte Verschlüsselungsprotokolle und Cipher-Suite-Definitionen auf System SSL-Standardwerte zurück. Sie können diese Standardwerte ändern, indem Sie die Umgebungsvariablen GSK_PROTOCOL_* und GSK_V3_CIPHER_SPECS* in rsed.envvars angeben. Informationen zu diesen Umgebungsvariablen finden Sie unter Cryptographic Services System SSL Programming (SC24-5901).
TTLSRule RDz_Debug_Manager
{
LocalPortRange 5335
Direction Inbound
TTLSGroupActionRef grp_Production
TTLSEnvironmentActionRef RDz_Debug_Manager
}
TTLSEnvironmentAction RDz_Debug_Manager
{
HandshakeRole Server
TTLSKeyRingParms
{
Keyring dbgmgr.racf # Keyring must be owned by the Debug Manager
}
}
TTLSGroupAction grp_Production
{
TTLSEnabled On
Trace 2
}
Mit einem X.509-Zertifikat unterstützt der RSE-Dämon die eigene Authentifizierung der Benutzer. Voraussetzung hierfür ist die Verwendung der mit SSL verschlüsselten Kommunikation, da dies eine Erweiterung der Hostauthentifizierung mit einem in SSL verwendeten Zertifikat ist.
Der RSE-Dämon startet den Prozess zur Clientauthentifizierung mit der Prüfung des Clientzertifikats. Einige wichtige Aspekte, die geprüft werden, sind die Gültigkeitsdaten des Zertifikats und die Vertrauenswürdigkeit der Zertifizierungsstelle (CA), die das Zertifikat unterzeichnet hat. Optional kann auch eine Zertifikatswiderrufsliste (CRL) eines anderen Anbieters zu Rate gezogen werden.
Nachdem der RSE-Dämon das Zertifikat geprüft hat, ist es zur Authentifizierung bereit. Das Zertifikat wird an Ihr Sicherheitsprodukt zur Authentifizierung weitergegeben, sofern die rsed.envvars-Anweisung enable.certificate.mapping nicht auf false gesetzt ist. In diesem Fall führt der RSE-Dämon die Authentifizierung durch.
Bei erfolgreicher Authentifizierung legt der Authentifizierungsprozess die in dieser Sitzung zu verwendende Benutzer-ID fest. Diese wird dann vom RSE-Dämon getestet, um sicherzustellen, dass sie für das Hostsystem, auf dem der RSE-Dämon aktiv ist, verwendbar ist.
In der letzten Überprüfung (die nicht nur bei Authentifizierungsverfahren mit X.509-Zertifikaten durchgeführt wird, sondern bei allen Verfahren) wird die Berechtigung der Benutzer-ID für die Verwendung von Developer for System z überprüft.
Wenn Sie mit den von TCP/IP verwendeten SSL-Sicherheitsklassifikationen vertraut sind: Die Kombination dieser Überprüfungsschritte entspricht den Spezifikationen der Stufe 3 der Clientauthentifizierung (höchste verfügbare Stufe).
Ein Bestandteil des Zertifikatsüberprüfungsprozesses besteht in der Prüfung, ob das Zertifikat von einer vertrauenswürdigen Zertifizierungsstelle (CA) unterschrieben wurde. Um dies ausführen zu können, muss der RSE-Dämon Zugriff auf ein Zertifikat haben, das die CA identifiziert.
Wenn für Ihre SSL-Verbindung die gskkyman-Schlüsseldatenbank verwendet wird, muss das CA-Zertifikat der Schlüsseldatenbank hinzugefügt werden.
Weitere Informationen zum RACDCERT-Befehl enthält die Veröffentlichung Security Server RACF Command Language Reference (IBM Form SA22-7687).
Achtung: Wenn zur Authentifizierung eines Benutzers der RSE-Dämon anstelle Ihrer Sicherheitssoftware zugrunde gelegt wird, müssen Sie darauf achten, in der SAF-Schlüsseldatei bzw. der gskkyman-Schlüsseldatenbank die CAs mit den TRUST- und HIGHTRUST-Status nicht zu vermischen. Der RSE-Dämon kann zwischen diesen beiden Status nicht unterscheiden. Daher sind Zertifikate, die von einer CA mit TRUST-Status unterschrieben wurden, zur Authentifizierung der Benutzer-ID gültig. |
Weitere Informationen zu diesen und weiteren Umgebungsvariablen, die von z/OS System SSL verwendet werden, finden Sie in der Veröffentlichung Cryptographic Services System Secure Sockets Layer Programming (IBM Form SC24-5901).
RACF führt verschiedene Überprüfungen zum Authentifizieren eines Zertifikats aus und gibt die zugeordnete Benutzer-ID zurück. Beachten Sie, dass andere Sicherheitsprodukte dies anders handhaben können. Weitere Informationen zur initACEE-Funktion, die für die Authentifizierung (Abfragemodus) verwendet wird, finden Sie in der Dokumentation Ihres Sicherheitsprodukts.
RACDCERT ID(userid) ADD(dsn) TRUST WITHLABEL('Bezeichnung')
id-ce-hostIdMappings OBJECT IDENTIFIER::= {1 3 18 0 2 18 1}
HostIdMappings::= SET OF HostIdMapping
HostIdMapping::= SEQUENCE{
hostName IMPLICIT[1] IA5String,
subjectId IMPLICIT[2] IA5String,
proofOfIdPossession IdProof OPTIONAL
}
IdProof::= SEQUENCE{
secret OCTET STRING,
encryptionAlgorithm OBJECT IDENTIFIER
}
Weitere Informationen zu X.509-Zertifikaten und ihrer Verwaltung in RACF sowie zur Vorgehensweise der Definition von Zertifikatsnamensfiltern finden Sie in der Veröffentlichung Security Server RACF Security Administrator’s Guide (IBM Form SA22-7683). Weitere Informationen zum RACDCERT-Befehl enthält die Veröffentlichung Security Server RACF Command Language Reference (IBM Form SA22-7687).
Developer for System z kann eine grundlegende X.509-Zertifikatsauthentifizierung durchführen, ohne dazu auf Ihr Sicherheitsprodukt zurückzugreifen. Für die Authentifizierung durch den RSE-Dämon sind eine Benutzer-ID und ein Hostname erforderlich, die in der Zertifikatserweiterung definiert sein müssen. Die Authentifizierung ist nur dann aktiviert, wenn in der Datei rsed.envvars die Anweisung enable.certificate.mapping auf FALSE gesetzt ist.
Diese Funktion ist vorgesehen, falls Ihr Sicherheitsprodukt keine Benutzerauthentifizierung unterstützt, die auf einem X.509-Zertifikat basiert, oder falls Ihr Zertifikat die von Ihrem Sicherheitsprodukt durchgeführten Tests nicht bestehen würde (z. B. wenn das Zertifikat für die HostIdMappings-Erweiterung über eine falsche ID verfügt und kein Namensfilter oder keine Namensdefinition in DIGTCERT festgelegt wurde).
Der Client fragt den Benutzer nach der zu verwendenden Objektkennung (OID). Standardmäßig wird die HostIdMappings-OID verwendet {1 3 18 0 2 18 1}.
Der RSE-Dämon extrahiert davon die Benutzer-ID und den Hostnamen. Dabei wird das Format der HostIdMappings-Erweiterung verwendet. Dieses Format ist im Abschnitt Authentifizierung durch Ihre Sicherheitssoftware beschrieben.
Achtung: Der Sicherheitsadministrator muss sicherstellen, dass alle dem RSE-Dämon bekannten CAs sehr vertrauenswürdig sind, da der RSE-Dämon nicht überprüfen kann, ob der Unterzeichner des Clientzertifikats sehr vertrauenswürdig oder nur vertrauenswürdig ist. Weitere Informationen zu zugänglichen CA-Zertifikaten enthält der Abschnitt Prüfung der Zertifizierungsstelle (CA).
|
Weitere Informationen zur Kontrolle des Netzzugriffs durch die Eingangsportüberprüfung enthält die Veröffentlichung Communications Server IP Configuration Guide (IBM Form SC31-8775).
Developer for System z-Clients der Version 8.5.1 und höher können die Zugriffsberechtigung auf SAF-Sicherheitsprofile überprüfen und auf der Basis des Ergebnisses die zugehörige Funktion für den Benutzer aktivieren oder inaktivieren.
Developer for System z überprüft Zugriffszulassungen auf die Profile, die in Tabelle 7 aufgeführt sind, um festzustellen, welche Optionen für den Benutzer aktiviert oder inaktiviert werden sollen.
FACILITY-Profil | Feste Länge | Erforderlicher Zugriff | Ergebnis |
---|---|---|---|
FEK.USR.OFF.REMOTECOPY.MVS.sysname | 27 | READ | Client inaktiviert Kopierfunktionen und zugehörige Funktionen für MVS-Dateien |
Der Wert von sysname ist der Systemname des Zielsystems.
In der Spalte "Feste Länge" ist die Länge des festen Teils des zugehörigen Sicherheitsprofils angegeben.
Developer for System z erwartet standardmäßig, dass FEK.*-Profile der Sicherheitsklasse FACILITY angehören. Für Profile der Klasse FACILITY gilt eine Beschränkung auf 39 Zeichen. Falls die Länge des festen Profilteils (FEK.USR.<key>) und die Länge des standortspezifischen Profilteils (sysname) in der Summe diesen Wert überschreiten, können Sie die Profile in einer anderen Klasse speichern und Developer for System z dazu anweisen, diese Klasse zu verwenden. Dazu müssen Sie in rsed.envvars das Kommentarzeichen vor _RSE_FEK_SAF_CLASS entfernen und den Namen der gewünschten Klasse angeben.
RDEFINE FACILITY (FEK.USR.OFF.REMOTECOPY.MVS.CDFMVS08) -
UACC(NONE) DATA('RATIONAL DEVELOPER FOR SYSTEM Z - CLIENT CONTROL')
PERMIT FEK.USR.OFF.REMOTECOPY.MVS.CDFMVS08 CLASS(FACILITY) -
ID(RESTRICT) ACCESS(READ)
SETROPTS RACLIST(FACILITY) REFRESH
Wenn Benutzer über Lesezugriff auf das Profil FEK.USR.OFF.REMOTECOPY.MVS.sysname verfügen, inaktivieren ihre Developer for System z-Clients der Version 8.5.1 und höher Aktionen vom Typ 'Ziehen', 'Kopieren', 'Speichern unter' und 'Offline arbeiten' für MVS-Dateien. Daraus folgt, dass die Benutzer zwar auf die Dateien auf diesem System zugreifen können, sie aber keine lokale Kopie einer Datei auf ihren Workstations erstellen können. Dadurch wird Weitergabe von vertraulichen Informationen verhindert, falls die lokale Workstation verlorengeht oder gestohlen wird.
Developer for System z-Clients ab Version 8.0.1 können beim Verbindungsaufbau Konfigurationsdateien und Produktaktualisierungsdaten im Pull-Verfahren vom Host abrufen. Dadurch wird sichergestellt, dass alle Clients über die gleichen Einstellungen verfügen und auf dem neuesten Stand sind.
Ab Version 8.0.3 kann der Clientadministrator mehrere Clientkonfigurationssätze und Clientaktualisierungsszenarien für die Anforderungen verschiedener Entwicklergruppen erstellen. Dadurch erhalten Benutzer eine angepasste Konfiguration, die auf Kriterien wie LDAP-Gruppenzugehörigkeit oder Zulassung zu einem Sicherheitsprofil basiert.
Wenn Definitionen Ihrer Sicherheitsdatenbank als Auswahlmechanismus verwendet werden (der SAF-Wert wird für Direktiven in pushtoclient.properties angegeben), überprüft Developer for System z die Zugriffserlaubnis auf die in Tabelle 8 aufgelisteten Profile, um festzustellen, zu welchen Entwicklergruppen ein Benutzer gehört und ob der Benutzer Aktualisierungen zurückweisen darf.
FACILITY-Profil | Feste Länge | Erforderlicher Zugriff | Ergebnis |
---|---|---|---|
FEK.PTC.CONFIG.ENABLED. |
23 | READ | Der Client akzeptiert Konfigurationsaktualisierungen für die angegebene Gruppe. |
FEK.PTC.PRODUCT. |
24 | READ | Der Client akzeptiert Produktaktualisierungen für die angegebene Gruppe. |
FEK.PTC.REJECT.CONFIG. |
30 | READ | Der Benutzer kann Konfigurationsaktualisierungen zurückweisen. |
FEK.PTC.REJECT.PRODUCT. |
31 | READ | Der Benutzer kann Produktaktualisierungen zurückweisen. |
Der Wert von devgroup ist der Gruppenname, der einer Entwicklergruppe zugewiesen ist. Dieser Gruppenname ist auf Developer for System z-Clients sichtbar.
Der Wert von sysname ist der Systemname des Zielsystems.
In der Spalte 'Feste Länge' ist die Länge des festen Teils des zugehörigen Sicherheitsprofils angegeben.
Developer for System z erwartet standardmäßig, dass FEK.*-Profile der Sicherheitsklasse FACILITY angehören. Für Profile der Klasse FACILITY gilt eine Beschränkung auf 39 Zeichen. Falls die Länge des festen Profilteils (FEK.PTC.<key>) und die Länge des standortspezifischen Profilteils (sysname oder sysname.devgroup) in der Summe diesen Wert überschreiten, können Sie die Profile in einer anderen Klasse speichern und Developer for System z dazu anweisen, diese Klasse zu verwenden. Dazu müssen Sie in rsed.envvars das Kommentarzeichen vor _RSE_FEK_SAF_CLASS entfernen und den Namen der gewünschten Klasse angeben.
Nur Clientadministratoren, die in der Zugriffsliste der FEK.PTC.*.ENABLED.*-Profile aufgeführt sind, können die zugehörigen Push-to-Client-Metadaten definieren und verwalten. Dies bedeutet, dass in den Profilen zumindest der Clientadministrator in der Zugriffsliste definiert sein muss, damit Push-to-Client mit Gruppenunterstützung implementiert werden kann.
Weitere Informationen zur Aktivierung der Unterstützung für mehrere Gruppen finden Sie im Abschnitt '(Optional) pushtoclient.properties, Hostbasierte Clientsteuerung' im Handbuch Hostkonfiguration (IBM Form SC12-4062). Weitere Informationen zu den Konzepten und der Implementierung von Push-to-Client finden Sie im Abschnitt Push-to-Client-Aspekte.
Die von Developer for System z erstellten Protokollverzeichnisse und -dateien verfügen standardmäßig über sichere Zugriffsberechtigungen, in deren Rahmen nur der Eigentümer Zugriff (Lese- und Schreibzugriff) hat. Für Serverprotokolle (und Prüfprotokolle) hat der Eigentümer die Benutzer-ID der gestarteten RSED-Task. Für Benutzerprotokolle ist der Eigentümer die während der Anmeldung durch den Endbenutzer bereitgestellte Benutzer-ID. Die Direktive log.file.mode in rsed.envvars kann zum Festlegen verschiedener Zugriffsberechtigungen verwendet werden. Beachten Sie, dass die Zugriffsberechtigungen für Prüflistendateien separat gesteuert werden und mit der Direktive audit.log.mode in rsed.envvars festgelegt werden.
Vor dem Schreiben in ein Protokollverzeichnis überprüft Developer for System z das Dateieigentumsrecht. Wenn die Datei einem anderen Benutzer gehört, schlägt der Schreibvorgang fehl. Dieses Verhalten ist neu in Version 9.1.0. Sie müssen daher ihre bereits vorhandene Protokolldateistruktur möglicherweise ändern. Mit der Direktive log.secure.mode in rsed.envvars kann die Überprüfung des Eigentumsrechts inaktiviert werden.
Mit der Beispiel-JCL FEKPBITS können die Zugriffsberechtigungen und das Eigentumsrecht einer vorhandenen Protokolldateiinfrastruktur umgewandelt werden. FEKPBITS befindet sich in FEK.#CUST.JCL, sofern Sie bei der Anpassung und Übergabe des Jobs FEK.SFEKSAMP(FEKSETUP) keine andere Position angegeben haben. Weitere Informationen finden Sie unter "Anpassungskonfiguration" im Handbuch Hostkonfiguration (IBM Form SC12-4062).
Die gestartete RSED-Task unterstützt den Bedienerbefehl MODIFY LOGS, um Hostprotokolle und Konfigurationsdaten von Developer for System z zu erfassen. Die erfassten Daten werden in eine z/OS UNIX-Datei namens $TMPDIR/feklogs%sysname.%jobname eingefügt, wobei $TMPDIR der Wert der Anweisung TMPDIR in rsed.envvars ist (standardmäßig /tmp), %sysname Ihr z/OS-Systemname ist und %jobname der Name der gestarteten RSED-Task ist.
Developer for System z fragt Ihr Sicherheitsprodukt nach Zugriffsberechtigungen für FEK.CMD.LOGS.**-Profile ab, um zu bestimmen, ob der Anforderer die angegebenen Protokolle erfassen darf. Standardmäßig handelt es sich bei dem Anforderer um die Benutzer-ID der gestarteten RSED-Task, es sei denn, die Option OWNER ist angegeben. Nur der Anforderer hat Zugriff auf die Datei mit den erfassten Daten.
FACILITY-Profil | Feste Länge | Erforderlicher Zugriff | Ergebnis |
---|---|---|---|
FEK.CMD.LOGS.AUDIT.jobname | 19 | READ | Der Anforderer kann Prüfprotokolle von 'jobname' erfassen |
FEK,CMD.LOGS.SERVER.jobname | 20 | READ | Der Anforderer kann Serverprotokolle von 'Jobname' erfassen |
FEK,CMD.LOGS.USER.userid | 18 | READ | Der Anforderer kann Benutzerprotokolle von 'userid' erfassen |
FEK,CMD.LOGS.OWNER.userid | 19 | READ | Der Anforderer wird von der Benutzer-ID der gestarteten RSED-Task in 'userid' geändert. |
Der Wert von jobname stimmt mit dem Namen der gestarteten RSED-Task überein. Der Wert von userid stimmt mit einer gültigen Benutzer-ID überein.
In der Spalte 'Feste Länge' ist die Länge des festen Teils des zugehörigen Sicherheitsprofils angegeben.
Developer for System z erwartet standardmäßig, dass FEK.*-Profile der Sicherheitsklasse FACILITY angehören. Für Profile der Klasse FACILITY gilt eine Beschränkung auf 39 Zeichen. Falls die Länge des festen Profilteils (FEK.CMD.LOGS.<key>) und die Länge des standortspezifischen Profilteils (jobname oder userid) in der Summe diesen Wert überschreiten, können Sie die Profile in einer anderen Klasse speichern und Developer for System z anweisen, diese Klasse zu verwenden. Dazu müssen Sie in rsed.envvars das Kommentarzeichen vor _RSE_FEK_SAF_CLASS entfernen und den Namen der gewünschten Klasse angeben.
Unberechtigte Zugriffe werden in der Konsolennachricht FEK302E dokumentiert.
Die folgenden Beispielsicherheitsdefinitionen ermöglichen allen Benutzern, Hostprotokolle zu erfassen, aber nur die Gruppe SYSPROG kann Prüfdaten erfassen:
RDEFINE FACILITY (FEK.CMD.LOGS.**) UACC(READ) -
DATA('RATIONAL DEVELOPER FOR SYSTEM Z - LOGS OPERATOR COMMAND')
RDEFINE FACILITY (FEK.CMD.LOGS.AUDIT.**) UACC(NONE) –
DATA('RATIONAL DEVELOPER FOR SYSTEM Z - LOGS OPERATOR COMMAND')
PERMIT FEK.CMD.LOGS.AUDIT.** CLASS(FACILITY) -
ID(SYSPROG) ACCESS(READ)
SETROPTS RACLIST(FACILITY) REFRESH
Der Bedienerbefehl MODIFY LOGS verwendet die Benutzer-ID der gestarteten RSED-Task, um Hostprotokolle und Konfigurationsdaten zu erfassen, und standardmäßig werden Benutzerprotokolldateien mit Berechtigungen für einen sicheren Dateizugriff (nur der Eigner hat Zugriff) erstellt. Damit sichere Benutzerprotokolldateien erfasst werden können, muss die Benutzer-ID der gestarteten RSED-Task über eine Leseberechtigung verfügen.
Das Argument OWNER des Bedienerbefehls MODIFY LOGS führt dazu, das die angegebene Benutzer-ID zum Eigner der erfassten Daten wird. Um das Eigentumsrecht zu ändern, muss die Benutzer-ID der gestarteten RSED-Task über die Berechtigung verfügen, den z/OS UNIX-Dienst CHOWN zu verwenden.
Es gibt drei Arten, wie diese Berechtigungen für die Benutzer-ID der gestarteten RSED-Task bereitgestellt werden können. In bevorzugter Reihenfolge sind dies:
Die Klasse UNIXPRIV enthält Profile, mit denen ein Sicherheitsadministrator selektiv spezielle z/OS UNIX-bezogene Genehmigungen ausgeben kann, statt alle z/OS UNIX-bezogenen Genehmigungen als Superuser zu erteilen.
Profil | Genehmigung | Ergebnis |
---|---|---|
SUPERUSER.FILESYS | READ | Der Benutzer verfügt über Lesezugriff für alle Dateien und Verzeichnisse. |
SUPERUSER.FILESYS.ACLOVERRIDE | READ | Die Genehmigung ist nur erforderlich, wenn 'ACLOVERRIDE' bereits definiert ist. Sie räumt dem Benutzer unabhängig von ACL-Definitionen Lesezugriff für alle Dateien und Verzeichnisse ein. |
SUPERUSER.FILESYS.CHOWN | READ | Der Benutzer darf den Eigentümer von Dateien oder Verzeichnissen ändern. |
Wenn für die Benutzer-ID der gestarteten RSED-Task in der Klasse FACILITY eine Leseberechtigung (READ) für das Profil BPX.SUPERUSER angegeben ist, kann sie sich temporär zu einem z/OS UNIX-Superuser machen, für den z/OS UNIX-Dateizugriffsberechtigungen nicht zählen.
Wenn für die Benutzer-ID der gestartete RSED-Task im OMVS-Segment 'UID 0' angegeben ist, handelt es sich um einen z/OS UNIX-Superuser, für den z/OS UNIX-Dateizugriffsberechtigungen nicht zählen. Dieser Ansatz wird jedoch nicht empfohlen, da 'UID 0' wahrscheinlich eine gemeinsam genutzte UID ist. Der gestarteten RSED-Task sollte jedoch aufgrund anderer genehmigten Berechtigungen für diese ID eine eindeutige UID zugewiesen werden. (Beispielsweise ist für z/OS UNIX-Administratoren für einige Systemverwaltungstasks die Benutzer-ID 'UID 0' erforderlich.)
Für die optionale Komponente Integrated Debugger ist es erforderlich, dass Benutzer
über ausreichende Zugriffsberechtigungen für angegebene Sicherheitsprofile verfügen.
Wenn der Benutzer nicht über die erforderliche Berechtigung verfügt, wird die Debugsitzung
nicht gestartet.
Developer for System z überprüft den Zugriff auf die Profile, die in Tabelle 10 aufgeführt sind, um festzustellen, welche Debugberechtigungen erteilt wurden.
FACILITY-Profil | Erforderlicher Zugriff | Ergebnis |
---|---|---|
AQE.AUTHDEBUG.STDPGM | READ | Benutzer kann ein Debugging für Anwendungen mit Fehlerstatus durchführen |
AQE.AUTHDEBUG.AUTHPGM | READ | Benutzer kann ein Debugging für Anwendungen mit Fehlerstatus sowie für berechtigte Anwendungen durchführen |
RDEFINE FACILITY (AQE.AUTHDEBUG.STDPGM) -
UACC(NONE) DATA('RATIONAL DEVELOPER FOR SYSTEM Z – DEBUG PROBLEM-STATE')
PERMIT AQE.AUTHDEBUG.STDPGM CLASS(FACILITY) -
ID(RDZDEBUG) ACCESS(READ)
SETROPTS RACLIST(FACILITY) REFRESH
Mit dem optionalen Integrated Debugger kann ein Debugging von CICS-Transaktionen durchgeführt werden. Ausführliche Informationen hierzu enthält der Abschnitt CICS-Transaktionsdebugging.
Developer for System z ermöglicht CICS-Administratoren über Application Deployment Manager die für den Entwickler editierbaren CICS-Ressourcendefinitionen, deren Standardwerte sowie die Anzeige einer CICS-Ressourcendefinition mithilfe des CICS Resource Definition-Servers (CRD) zu steuern. Weitere Informationen zu den erforderlichen CICS-TS-Sicherheitsdefinitionen enthält CICSTS-Aspekte.
Die VSAM-Datei für das CRD-Server-Repository enthält alle Standardressourcendefinitionen und muss daher vor Aktualisierungen geschützt werden. Entwickler müssen jedoch die Möglichkeit haben, die hier gespeicherten Werte zu lesen.
Developer for System z stellt mehrere Transaktionen bereit, die der CRD-Server beim Definieren und Abfragen von CICS-Ressourcen verwendet. Wenn die Transaktion zugeordnet wird, stellt die Sicherheitsprüfung für CICS-Ressourcen (sofern aktiviert) sicher, dass die Benutzer-ID berechtigt ist, die Transaktions-ID zu verwenden.
Die Clientkomponente von Application Deployment Manager ruft mit CICS-TS-Web-Services oder der RESTful-Schnittstelle den CRD-Server auf. Die Verwendung von SSL für diese Kommunikation wird von der CICS-TS-Definition TCPIPSERVICE gesteuert. Diese Art der Verwendung ist im RACF Security Guide for CICS TS dokumentiert.
SCLM Developer Toolkit stellt optionale Sicherheitsfunktionen für die Builderstellung, die Umstufung und das Deployment bereit.
Wenn ein SCLM-Administrator die Sicherheit für eine Funktion aktiviert hat, wird SAF aufgerufen, um zu überprüfen, ob die geschützte Funktion mit der ID des Aufrufenden oder einer Ersatzbenutzer-ID ausgeführt werden darf.
Weitere Informationen zu den erforderlichen SCLM-Sicherheitsdefinitionen enthält der SCLM Developer Toolkit Administrator’s Guide (IBM Form SC23-9801).
Wenn ein Adressraum RACF erstmals anweist, auf eine Ressourcenklasse zuzugreifen, die sich nicht in RACLIST befindet, also nicht im Speicher gespeichert ist, wie es beispielsweise bei der Klasse DATASET der Fall ist, so ruft RACF alle zugehörigen generischen Profile des Benutzers ab und speichert diese im Adressraum in einer als GATE (Generic Anchor Table Entry) bezeichneten Liste. Bis z/OS 1.12 pflegt RACF vier generische Anker für jeden Adressraum und vier für jeden MVS-TCB (Task Control Block), der über ein ACEE (Accessor Environment Element) verfügt. Sind alle vier belegt, ersetzt RACF denjenigen, der die längste Zeit nicht referenziert wurde, sobald ein neuer eintrifft.
Wenn Ihre Benutzer häufig auf mehr als vier übergeordnete Qualifikationsmerkmale für Daten zugreifen, tritt in den RSE-Thread-Pools (die mehrere Benutzer unter Verwendung von Threads mit benutzerspezifischen ACEEs bedienen) unter Umständen eine GATE-Überlastung (Thrashing) auf, denn RACF muss neue Einträge anhand der verfügbaren Ankerslots rollieren.
Mit z/OS 1.12 hat RACF die Option GENERICANCHOR des Befehls SET eingeführt, die Ihnen ermöglicht, die Tabelle zu vergrößern. Diese Vergrößerung kann systemweit definiert oder für jeden Jobnamen festgelegt werden.
Developer for System z verwendet z/OS UNIX-Kernelservices wie pthread_security_np() und __passwd(), die ihrerseits auf den Sicherheitsservice InitACEE zurückgreifen. Dadurch ergeben sich verwaltete ACEE-Sicherheitssteuerungsblöcke. Ein verwaltetes ACEE (Accessor Environment Element) wird von Ihrem Sicherheitsprodukt zwischengespeichert. Solange das Zeitlimit des Cache nicht abläuft, werden bestimmte Änderungen (beispielsweise Kennwortänderungen außerhalb von Developer for System z) von Ihrem Sicherheitsprodukt ignoriert. (Das Zeitlimit kann einige Minuten betragen.)
Nach Sicherheitsänderungen muss der verwaltete ACEE-Cache daher aktualisiert werden, damit sichergestellt wird, dass Developer for System z die neuen Daten verwendet.
RACF kann ACEEs (Accessor Environment Elements) mithilfe von VLF (Virtual Lookaside Facility) speichern und sie für die spätere Verwendung abrufen. Developer for System z fordert Ihre Sicherheitssoftware zum Erstellen mehrerer Sicherheitsumgebungen (ACEEs) für denselben Benutzer (einer für jeden benutzerspezifischen Thread im RSE-Thread-Pool) auf und kann so vom ACEE-Caching profitieren.
Weitere Informationen zum ACEE-Caching finden Sie unter "ACEEs and VLF considerations" im Dokument Security Server RACF System Programmer's Guide (IBM Form SA22-7681).
Es gibt mehrere Konfigurationsdateien für Developer for System z, deren Anweisungen Auswirkungen auf die Sicherheits- und Prüfkonfiguration haben. Auf der Basis der Informationen in diesem Kapitel können der Sicherheitsadministrator und Systemprogrammierer entscheiden, welche Einstellungen für die folgenden Anweisungen verwendet werden sollten.
Definieren, welche Jobaktionen durchgeführt werden können (mit Ausnahme von 'Durchsuchen' und 'Übergeben'). Weitere Informationen enthält der Abschnitt Aktionen für Beschränkungen der Jobziele.
Definieren der Berechtigungsstufe der zum Ausführen von Aktionen verwendeten EMCS-Konsole. Weitere Informationen enthält der Abschnitt Aktionen für Beschränkungen der Jobziele.
Definieren, welche Spooldateien durchsucht werden können. Weitere Informationen enthält der Abschnitt Zugriff auf Spooldateien.
Definieren, ob der Zugriff auf JES Job Monitor auch außerhalb dieses z/OS-Systems möglich ist. Weitere Informationen enthält der Abschnitt FEJJCNFG (Konfigurationsdatei für JES Job Monitor) im Kapitel Basisanpassung des Handbuchs Hostkonfiguration (IBM Form SC12-4062).
Die Anwendungs-ID, die zum Erstellen/Überprüfen von PassTicket verwendet wird. Weitere Informationen enthält der Abschnitt PassTickets verwenden.
Sicherheitsklassen mit FEK.**-Profilen. Weitere Informationen finden Sie im Abschnitt Push-to-Client-Entwicklergruppen und im Abschnitt Clientfunktionen ändern.
Lehnen Sie das Speichern von Hostkennwörtern auf dem Client seitens der Benutzer ab. Weitere Informationen enthält der Abschnitt "Zusätzliche Java-Startparameter mit _RSE_JAVAOPTS definieren" in Hostkonfiguration (IBM Form SC12-4062).
Zeitgeber zum Trennen der Verbindung inaktiver Clients. Weitere Informationen enthält der Abschnitt "Zusätzliche Java-Startparameter mit _RSE_JAVAOPTS definieren" in Hostkonfiguration (IBM Form SC12-4062).
Die Anwendungs-ID, die zum Erstellen/Überprüfen von PassTicket verwendet wird. Weitere Informationen enthält der Abschnitt PassTickets verwenden.
Aktivieren der Überprüfung des Eingangsports. Weitere Informationen enthält der Abschnitt Eingangsport (POE) überprüfen.
Wählen Sie SSL oder TLS als Verfahren für die Verschlüsselung der Kommunikation aus. Weitere Informationen enthält der Abschnitt Mit SSL/TLS verschlüsselte Kommunikation.
Verwenden Sie Ihr Sicherheitsprodukt zum Authentifizieren der Benutzer mit einem X.509-Zertifikat. Weitere Informationen enthält der Abschnitt Clientauthentifizierung unter Verwendung von X.509-Zertifikaten.
GSK_LDAP_SERVER=*
GSK_LDAP_PORT={389 | *}
GSK_LDAP_USER=*
GSK_LDAP_PASSWORD=*
Zusätzliche Sicherheitsprüfungen für die Authentifizierung von X.509. Weitere Informationen enthält der Abschnitt Zertifikatswiderrufsliste (CRL) abfragen (optional).
Maske für Dateizugriffsberechtigungen der Hostprotokolldateien und Verzeichnisse.
Zusätzliche Sicherheitsprüfungen (wie Eigentumsrecht) für Hostprotokolldateien und Verzeichnisse.
Pfad zu den Prüfprotokolldateien. Weitere Informationen enthält der Abschnitt Prüfprotokollierung.
Maske für Dateizugriffsberechtigungen der Prüfprotokolldateien. Weitere Informationen enthält der Abschnitt Prüfprotokollierung.
(_RSE_JAVAOPTS) -Daudit.action.id=<Benutzer-ID>
z/OS UNIX-basierte Benutzerexit, der Prüfprotokolle verarbeitet. Weitere Informationen enthält der Abschnitt Prüfprotokollierung.
Position des RSE-Dämonzertifikats. Weitere Informationen enthält der Abschnitt Mit SSL/TLS verschlüsselte Kommunikation.
Name des RSE-Dämonzertifikats. Weitere Informationen enthält der Abschnitt Mit SSL/TLS verschlüsselte Kommunikation.
Position des RSE-Serverzertifikats. Weitere Informationen enthält der Abschnitt Mit SSL/TLS verschlüsselte Kommunikation.
Name des RSE-Serverzertifikats. Weitere Informationen enthält der Abschnitt Mit SSL/TLS verschlüsselte Kommunikation.
Verwendeter Keystoretyp (Java-Keystore oder SAF-Schlüsseldatei). Weitere Informationen enthält der Abschnitt Mit SSL/TLS verschlüsselte Kommunikation.
reject.config.updates={true | false | SAF | LDAP}
Hostbasierte Steuerung der Clientkonfigurationsdateien für Developer for System z. Weitere Informationen enthält der Abschnitt Push-to-Client-Aspekte.
reject.product.updates={true | false | SAF | LDAP}
Hostbasierte Steuerung der Clientproduktaktualisierungen für Developer for System z. Weitere Informationen enthält der Abschnitt Push-to-Client-Aspekte.
Passen Sie das Beispielmember FEKRACF an, das RACF- und z/OS UNIX-Beispielbefehle enthält, und übergeben Sie es, um die Basissicherheitsdefinitionen für Developer for System z zu erstellen.
FEKRACF befindet sich in FEK.#CUST.JCL, sofern Sie bei der Anpassung und Übergabe des Jobs FEK.SFEKSAMP(FEKSETUP) keine andere Position angegeben haben. Weitere Informationen finden Sie in 'Anpassungskonfiguration' im Handbuch IBM Rational Developer for System z-Hostkonfiguration.
Weitere Informationen zu RACF-Befehlen finden Sie in der Veröffentlichung RACF Command Language Reference (IBM Form SA22–7687).
In den folgenden Abschnitten werden die erforderlichen Schritte, die optionale Konfiguration und mögliche Alternativen beschrieben.
Beschreibung |
|
Wert |
---|---|---|
Übergeordnetes Qualifikationsmerkmal für Developer for System z-Produkt |
|
|
Übergeordnetes Qualifikationsmerkmal für Developer for System z-Anpassung |
|
|
Name der gestarteten Task von Integrated Debugger |
|
|
Name der gestarteten Task von JES Job Monitor |
|
|
Name der gestarteten Task des RSE-Dämons |
|
|
Anwendungs-ID |
|
Achtung: Wenn "WHEN PROGRAM" aktiv ist, müssen einige Produkte (beispielsweise FTP) programmgesteuert sein. Testen Sie eine solche Programmsteuerung, bevor Sie sie auf einem Produktionssystem aktivieren. |
Für jeden Benutzer von Developer for System z muss ein RACF-OMVS-Segment oder eine funktionale Entsprechung definiert werden, das eine gültige z/OS UNIX-Benutzer-ID (UID, ungleich null) angibt. Darüber hinaus müssen für jeden Benutzer ein Ausgangsverzeichnis und ein Shellbefehl definiert werden. Für die Standardgruppe eines jeden Benutzers ist ebenfalls ein OMVS-Segment mit einer Gruppen-ID erforderlich.
Wenn Integrated Debugger (optional) verwendet wird, benötigen die Benutzer-ID, unter der die Anwendung, für die ein Debugging ausgeführt ist, aktiv ist, sowie die Standardgruppe auch ein gültiges RACF OMVS-Segment oder ähnliches.
Ersetzen Sie in den folgenden RACF-Beispielbefehlen die Platzhalter #userid, #user-identifier, #group-name und #group-identifier durch tatsächliche Werte:
ALTUSER #userid
OMVS(UID(#user-identifier) HOME(/u/#userid) PROGRAM(/bin/sh) NOASSIZEMAX)
Die folgenden RACF-Beispielbefehle erstellen die gestarteten Tasks DBGMGR, JMON und RSED mit der ihnen jeweils zugeordneten geschützten Benutzer-ID (STCDBM, STCJMON und STCRSE) und der Gruppe STCGROUP. Ersetzen Sie die Platzhalter #group-id und #user-id-* durch gültige OMVS-IDs.
ADDGROUP STCGROUP OMVS(AUTOGID)
DATA('GROUP WITH OMVS SEGMENT FOR STARTED TASKS')
ADDUSER STCDBM DFLTGRP(STCGROUP) NOPASSWORD NAME('RDZ – DEBUG MANAGER')
OMVS(AUTOUID HOME(/tmp) PROGRAM(/bin/sh) )
DATA('RATIONAL DEVELOPER FOR SYSTEM Z')
ADDUSER STCJMON DFLTGRP(STCGROUP) NOPASSWORD NAME('RDZ - JES JOBMONITOR')
OMVS(AUTOUID HOME(/tmp) PROGRAM(/bin/sh) )
DATA('RATIONAL DEVELOPER FOR SYSTEM Z')
ADDUSER STCRSE DFLTGRP(STCGROUP) NOPASSWORD NAME('RDZ - RSE DAEMON')
OMVS(AUTOUID HOME(/tmp) PROGRAM(/bin/sh) ASSIZEMAX(2147483647) )
DATA('RATIONAL DEVELOPER FOR SYSTEM Z')
RDEFINE STARTED DBGMGR.* DATA('RDZ – DEBUG MANAGER')
STDATA(USER(STCDBM) GROUP(STCGROUP) TRUSTED(NO))
RDEFINE STARTED JMON.* DATA('RDZ - JES JOBMONITOR')
STDATA(USER(STCJMON) GROUP(STCGROUP) TRUSTED(NO))
RDEFINE STARTED RSED.* DATA('RDZ - RSE DAEMON')
STDATA(USER(STCRSE) GROUP(STCGROUP) TRUSTED(NO))
ALTUSER STCRSE RESTRICTED
Um sicherzustellen, dass eingeschränkte Benutzer nicht über die 'anderen' Zugriffsbits Zugriff auf z/OS UNIX-Dateisystemressourcen erlangen, ist es erforderlich, das Profil RESTRICTED.FILESYS.ACCESS in der Klasse UNIXPRIV mit UACC(NONE) zu definieren. Weitere Informationen zur Einschränkung von Benutzer-IDs finden Sie im Security Server RACF Security Administrator's Guide (SA22-7683).
Achtung: Wenn Sie Zugriffseinschränkungen für Benutzer-IDs festgelegt haben, müssen Sie die Berechtigung für den Zugriff auf eine Ressource explizit mit dem TSO-Befehl PERMIT oder dem z/OS UNIX-Befehl setfacl hinzufügen.
Die Ressourcen schließen auch solche Ressourcen ein, bei denen die Dokumentation von Developer
for System z UACC verwendet, wie etwa das Profil ** in der Klasse PROGRAM, oder bei denen allgemeine z/OS UNIX-Konventionen gelten, wie zum Beispiel, dass jeder die Lese- und Ausführungsberechtigung für Java-Bibliotheken besitzt.
Testen Sie den Zugriff vor der eigentlichen Aktivierung auf einem Produktionssystem.
|
RSE benötigt die Zugriffsberechtigung UPDATE für das Profil BPX.SERVER, um die Sicherheitsumgebung für den Client-Thread erstellen oder löschen zu können. Wenn dieses Profil nicht definiert ist, muss für RSE UID(0) verwendet werden. Dieser Schritt ist erforderlich, damit Clients die Verbindung herstellen können.
Integrated Debugger benötigt die Zugriffsberechtigung UPDATE für das Profil BPX.SERVER, um die Sicherheitsumgebung für den Debug-Thread erstellen oder löschen zu können. Wenn dieses Profil nicht definiert ist, muss für die Benutzer-ID der gestarteten STCDBM-Task UID(0) verwendet werden. Diese Genehmigung ist nur erforderlich, wenn das optionale Integrated Debugger-Feature verwendet wird.
Achtung: Mit dem Definieren des Profils BPX.SERVER wechselt z/OS UNIX vollständig von der Sicherheit auf UNIX-Ebene zur Sicherheit auf z/OS UNIX-Ebene, die bedeutend sicherer ist. Möglicherweise hat dieser Wechsel Auswirkungen auf andere z/OS UNIX-Anwendungen und -Operationen. Testen Sie die Sicherheit vor der eigentlichen Aktivierung auf einem Produktionssystem. Weitere Informationen zu den verschiedenen Sicherheitsebenen enthält die Veröffentlichung
UNIX System Services Planning (IBM Form GA22-7800).
|
Server mit der Berechtigung für BPX.SERVER müssen in einer sauberen, programmgesteuerten Umgebung ausgeführt werden. Diese Anforderung impliziert, dass alle von RSE aufgerufenen Programme ebenfalls programmgesteuert sein müssen. Die Programmsteuerung von MVS-Ladebibliotheken wird von Ihrer Sicherheitssoftware verwaltet. Dieser Schritt ist erforderlich, damit Clients die Verbindung herstellen können.
Zur Unterstützung optionaler Services müssen die folgenden zusätzlich vorausgesetzten Bibliotheken programmgesteuert sein. Diese Liste enthält keine Dateien, die für ein Produkt spezifisch sind, mit dem Developer for System z interagiert, beispielsweise IBM File Manager.
Das Kennwort des Clients (oder andere Identifikationsmittel, wie ein X.509-Zertifikat) wird nur verwendet, um die Identität bei der Verbindungsherstellung zu überprüfen. Danach wird die Threadsicherheit mit PassTickets verwaltet. Dieser Schritt ist erforderlich, damit Clients die Verbindung herstellen können.
RDEFINE PTKTDATA FEKAPPL UACC(NONE) SSIGNON(KEYMASKED(key16))
APPLDATA('NO REPLAY PROTECTION – DO NOT CHANGE')
DATA('RATIONAL DEVELOPER FOR SYSTEM Z')
RDEFINE PTKTDATA IRRPTAUTH.FEKAPPL.* UACC(NONE)
DATA('RATIONAL DEVELOPER FOR SYSTEM Z')
PERMIT IRRPTAUTH.FEKAPPL.* CLASS(PTKTDATA) ACCESS(UPDATE) ID(STCRSE)
SETROPTS RACLIST(PTKTDATA) REFRESH
RSE unterstützt die Verwendung von anderen Anwendungs-IDs als FEKAPPL. Entfernen Sie in rsed.envvars die Kommentarzeichen vor der Option 'APPLID=FEKAPPL' und passen Sie die Option an, um sie zu aktivieren. Lesen Sie hierzu die Informationen im Abschnitt 'Zusätzliche Java-Startparameter mit _RSE_JAVAOPTS definieren' im Handbuch IBM Rational Developer for System z Hostkonfiguration. Die Klassendefinition PTKTDATA muss mit der eigentlichen, von RSE verwendeten Anwendungs-ID übereinstimmen.
Achtung: Die Clientverbindungsanforderung schlägt fehl, wenn PassTickets nicht ordnungsgemäß konfiguriert sind.
|
Der Bedienerbefehl MODIFY LOGS verwendet die Benutzer-ID der gestarteten RSED-Task, um Hostprotokolle und Konfigurationsdaten zu erfassen. Standardmäßig werden Benutzerprotokolldateien mit Berechtigungen für einen sicheren Dateizugriff (nur der Eigner hat Zugriff) erstellt. Damit sichere Benutzerprotokolldateien erfasst werden können, muss die Benutzer-ID der gestarteten RSED-Task über eine Leseberechtigung verfügen.
Das Argument OWNER des Bedienerbefehls MODIFY LOGS führt dazu, das die angegebene Benutzer-ID zum Eigner der erfassten Daten wird. Um das Eigentumsrecht zu ändern, muss die Benutzer-ID der gestarteten RSED-Task über die Berechtigung verfügen, den z/OS UNIX-Dienst CHOWN zu verwenden.
Beachten Sie, dass wenn das Profil SUPERUSER.FILESYS.ACLOVERRIDE definiert ist, die in der Zugriffskontrollliste (ACL - Access Control List) definierten Zugriffsberechtigungen Vorrang vor den durch SUPERUSER.FILESYS genehmigten Berechtigungen haben. Die Benutzer-ID der gestarteten RSED-Task benötigt eine READ-Zugriffsberechtigung auf das Profil SUPERUSER.FILESYS.ACLOVERRIDE, um ACL-Definitionen zu umgehen.
Während der Clientanmeldung prüft der RSE-Dämon, ob ein Benutzer die Anwendung verwenden darf.
RDEFINE APPL FEKAPPL UACC(READ) DATA('RATIONAL DEVELOPER FOR SYSTEM Z')
SETROPTS RACLIST(APPL) REFRESH
Server mit der Berechtigung für BPX.SERVER müssen in einer sauberen, programmgesteuerten Umgebung ausgeführt werden. Diese Anforderung impliziert, dass alle von RSE aufgerufenen Programme ebenfalls programmgesteuert sein müssen. Die Programmsteuerung für z/OS UNIX-Dateien wird mit dem Befehl extattr verwaltet. Für die Ausführung dieses Befehls benötigen Sie die Zugriffsberechtigung READ für BPX.FILEATTR.PROGCTL in der Klasse FACILITY oder die UID(0).
$ ls -Eog /usr/lib/libIRRRacf*.so
-rwxr-xr-x aps- 2 69632 Oct 5 2007 /usr/lib/libIRRRacf.so
-rwxr-xr-x aps- 2 69632 Oct 5 2007 /usr/lib/libIRRRacf64.so
JES Job Monitor setzt alle von einem Benutzer angeforderten JES-Bedienerbefehle über eine erweiterte MCS-Konsole (EMCS) ab, deren Bezeichnung durch die Anweisung CONSOLE_NAME gesteuert wird, wie im Abschnitt 'FEJJCNFG, JES Job Monitor-Konfigurationsdatei' im Handbuch IBM Rational Developer for System z Hostkonfiguration dokumentiert.
RDEFINE OPERCMDS MVS.MCSOPER.#console UACC(READ)
DATA('RATIONAL DEVELOPER FOR SYSTEM Z')
RDEFINE OPERCMDS JES%.** UACC(NONE)
PERMIT JES%.** CLASS(OPERCMDS) ACCESS(UPDATE) WHEN(CONSOLE(JMON)) ID(*)
SETROPTS RACLIST(OPERCMDS) REFRESH
Achtung: Wenn Sie in Ihrer Sicherheitssoftware die JES-Befehle mit dem universellen Zugriffsrecht NONE definieren, kann sich das negativ auf andere Anwendungen und Operationen auswirken. Testen Sie die Sicherheit vor der eigentlichen Aktivierung auf einem Produktionssystem.
|
In Tabelle 12 und Tabelle 13 sehen Sie die Bedienerbefehle, die für JES2 und JES3 abgesetzt werden, sowie die eigenständigen Sicherheitsprofile zu deren Schutz.
Aktion | Befehl | OPERCMDS-Profil | Erforderlicher Zugriff |
---|---|---|---|
Hold | $Hx(jobid) x = {J, S oder T} |
|
UPDATE |
Release | $Ax(jobid) x = {J, S oder T} |
|
UPDATE |
Cancel | $Cx(jobid) x = {J, S oder T} |
|
UPDATE |
Purge | $Cx(jobid),P x = {J, S oder T} |
|
UPDATE |
Aktion | Befehl | OPERCMDS-Profil | Erforderlicher Zugriff |
---|---|---|---|
Hold | *F,J=jobid,H |
|
UPDATE |
Release | *F,J=jobid,R |
|
UPDATE |
Cancel | *F,J=jobid,C |
|
UPDATE |
Purge | *F,J=jobid,C |
|
UPDATE |
Ihre Sicherheitssoftware verhindert, dass ein Benutzer in einer TSO-Sitzung eine Konsole JMON erstellt, weil er sich so als JES Job Monitor-Server ausgeben könnte. Auch wenn die Konsole erstellt werden kann, unterscheidet sich der Eingangsport, zum Beispiel JES Job Monitor im Gegensatz zu TSO. Von dieser Konsole abgesetzte JES-Befehle werden jedoch nicht die Sicherheitsprüfung bestehen, wenn Ihre Sicherheitssoftware wie in dieser Veröffentlichung beschrieben konfiguriert ist und der Benutzer nicht autorisiert ist, die JES-Befehle über andere Mechanismen zu verwenden.
Benutzer müssen über einen Lesezugriff auf eines der aufgelisteten AQE.AUTHDEBUG.*-Profile verfügen, um Integrated Debugger für die Fehlerbehebung bei Programmen mit Problemstatus einsetzen zu können. Benutzer mit einer Berechtigung für das Profil AQE.AUTHDEBUG.AUTHPGM sind auch zur Fehlerbehebung bei Programmen mit APF-Berechtigung autorisiert. Ersetzen Sie den Platzhalter #apf durch gültige Benutzer-IDs oder RACF-Gruppennamen für die Benutzer, die die Fehlerbehebung bei berechtigten Programmen durchführen dürfen:
RDEFINE FACILITY AQE.AUTHDEBUG.STDPGM UACC(NONE)
PERMIT AQE.AUTHDEBUG.STDPGM CLASS(FACILITY) ACCESS(READ) ID(*)
RDEFINE FACILITY AQE.AUTHDEBUG.AUTHPGM UACC(NONE)
PERMIT AQE.AUTHDEBUG.AUTHPGM CLASS(FACILITY) ACCESS(READ) ID(#apf)
SETROPTS RACLIST(FACILITY) REFRESH
Für die meisten Dateien von Developer for System z ist das Zugriffsrecht READ für Benutzer und ALTER für Systemprogrammierer ausreichend. Ersetzen Sie den Platzhalter #sysprog durch gültige Benutzer-IDs oder RACF-Gruppennamen. Erkundigen Sie sich außerdem bei dem Systemprogrammierer, der das Produkt installiert und konfiguriert hat, nach den korrekten Dateinamen. Das während der Installation verwendete übergeordnete Qualifikationsmerkmal (High Level Qualifier, HLQ) ist FEK. Das standardmäßige übergeordnete Qualifikationsmerkmal für Dateien, die während des Anpassungsprozesses erstellt werden, ist FEK.#CUST.
ADDGROUP (FEK) OWNER(IBMUSER) SUPGROUP(SYS1)
DATA('RATIONAL DEVELOPER FOR SYSTEM Z - HLQ STUB')
ADDSD 'FEK.*.**' UACC(READ)
DATA('RATIONAL DEVELOPER FOR SYSTEM Z')
PERMIT 'FEK.*.**' CLASS(DATASET) ACCESS(ALTER) ID(#sysprog)
SETROPTS GENERIC(DATASET) REFRESH
ADDSD 'FEK.#CUST.LSTRANS.*.**' UACC(UPDATE)
DATA('RATIONAL DEVELOPER FOR SYSTEM Z - SCLMDT')
PERMIT 'FEK.#CUST.LSTRANS.*.**' CLASS(DATASET) ACCESS(ALTER) ID(#sysprog)
SETROPTS GENERIC(DATASET) REFRESH
ADDSD 'FEK.#CUST.CRA*.**' UACC(READ)
DATA('RATIONAL DEVELOPER FOR SYSTEM Z - CARMA')
PERMIT 'FEK.#CUST.CRA*.**' CLASS(DATASET) ACCESS(ALTER) ID(#sysprog)
PERMIT 'FEK.#CUST.CRA*.**' CLASS(DATASET) ACCESS(UPDATE) ID(#ram-developer)
SETROPTS GENERIC(DATASET) REFRESH
ADDSD 'FEK.#CUST.ADNREP*.**' UACC(READ)
DATA('RATIONAL DEVELOPER FOR SYSTEM Z - ADN')
PERMIT 'FEK.#CUST.ADNREP*.**' CLASS(DATASET) ACCESS(ALTER) ID(#sysprog)
PERMIT 'FEK.#CUST.ADNREP*.**' CLASS(DATASET) ACCESS(UPDATE) ID(#cicsadmin)
SETROPTS GENERIC(DATASET) REFRESH
ADDSD 'FEK.#CUST.ADNMAN*.**' UACC(UPDATE)
DATA('RATIONAL DEVELOPER FOR SYSTEM Z - ADN')
PERMIT 'FEK.#CUST.ADNMAN*.**' CLASS(DATASET) ACCESS(ALTER) ID(#sysprog)
SETROPTS GENERIC(DATASET) REFRESH
ADDGROUP (FEK)
DATA('RATIONAL DEVELOPER FOR SYSTEM Z - HLQ STUB')
OWNER(IBMUSER) SUPGROUP(SYS1)"
ADDSD 'FEK.*.**' UACC(NONE)
DATA('RATIONAL DEVELOPER FOR SYSTEM Z')
ADDSD 'FEK.SFEKAUTH' UACC(NONE)
DATA('RATIONAL DEVELOPER FOR SYSTEM Z')
ADDSD 'FEK.SFEKLOAD' UACC(NONE)
DATA('RATIONAL DEVELOPER FOR SYSTEM Z')
ADDSD 'FEK.SFEKLMOD' UACC(NONE)
DATA('RATIONAL DEVELOPER FOR SYSTEM Z')
ADDSD 'FEK.SFEKPROC' UACC(NONE)
DATA('RATIONAL DEVELOPER FOR SYSTEM Z')
ADDSD 'FEK.#CUST.PARMLIB' UACC(NONE)
DATA('RATIONAL DEVELOPER FOR SYSTEM Z')
ADDSD 'FEK.#CUST.CNTL' UACC(NONE)
DATA('RATIONAL DEVELOPER FOR SYSTEM Z')
ADDSD 'FEK.#CUST.SQL' UACC(NONE)
DATA('RATIONAL DEVELOPER FOR SYSTEM Z')
ADDSD 'FEK.#CUST.LSTRANS.*.**' UACC(NONE)
DATA('RATIONAL DEVELOPER FOR SYSTEM Z - SCLMDT')
ADDSD 'FEK.#CUST.CRA*.**' UACC(NONE)
DATA('RATIONAL DEVELOPER FOR SYSTEM Z - CARMA')
ADDSD 'FEK.#CUST.ADNREP*.**' UACC(NONE)
DATA('RATIONAL DEVELOPER FOR SYSTEM Z - ADN')
ADDSD 'FEK.#CUST.ADNMAN*.**' UACC(NONE)
DATA('RATIONAL DEVELOPER FOR SYSTEM Z - ADN')
PERMIT 'FEK.*.** CLASS(DATASET) ACCESS(ALTER) ID(#sysprog)
PERMIT 'FEK.SFEKAUTH CLASS(DATASET) ACCESS(ALTER) ID(#sysprog)
PERMIT 'FEK.SFEKLOAD CLASS(DATASET) ACCESS(ALTER) ID(#sysprog)
PERMIT 'FEK.SFEKLMOD CLASS(DATASET) ACCESS(ALTER) ID(#sysprog)
PERMIT 'FEK.SFEKPROC CLASS(DATASET) ACCESS(ALTER) ID(#sysprog)
PERMIT 'FEK.#CUST.PARMLIB CLASS(DATASET) ACCESS(ALTER) ID(#sysprog)
PERMIT 'FEK.#CUST.CNTL CLASS(DATASET) ACCESS(ALTER) ID(#sysprog)
PERMIT 'FEK.#CUST.SQL CLASS(DATASET) ACCESS(ALTER) ID(#sysprog)
PERMIT 'FEK.#CUST.LSTRANS.*.**' CLASS(DATASET) ACCESS(ALTER) ID(#sysprog)
PERMIT 'FEK.#CUST.CRA*.**' CLASS(DATASET) ACCESS(ALTER) ID(#sysprog)
PERMIT 'FEK.#CUST.ADNREP*.**' CLASS(DATASET) ACCESS(ALTER) ID(#sysprog)
PERMIT 'FEK.#CUST.ADNMAN*.**' CLASS(DATASET) ACCESS(ALTER) ID(#sysprog)
PERMIT 'FEK.SFEKAUTH' CLASS(DATASET) ACCESS(READ) ID(*)
PERMIT 'FEK.SFEKLOAD' CLASS(DATASET) ACCESS(READ) ID(*)
PERMIT 'FEK.SFEKPROC' CLASS(DATASET) ACCESS(READ) ID(*)
PERMIT 'FEK.#CUST.CNTL' CLASS(DATASET) ACCESS(READ) ID(*)
PERMIT 'FEK.#CUST.SQL' CLASS(DATASET) ACCESS(READ) ID(*)
PERMIT 'FEK.SFEKAUTH' CLASS(DATASET) ACCESS(READ) ID(STCJMON)
PERMIT 'FEK.#CUST.PARMLIB' CLASS(DATASET) ACCESS(READ) ID(STCJMON)
PERMIT 'FEK.#CUST.LSTRANS.*.**' CLASS(DATASET) ACCESS(UPDATE) ID(*)
PERMIT 'FEK.#CUST.CRA*.**' CLASS(DATASET) ACCESS(UPDATE) ID(#ram-developer)
PERMIT 'FEK.#CUST.ADNREP*.**' CLASS(DATASET) ACCESS(READ) ID(*)
PERMIT 'FEK.#CUST.ADNREP*.**' CLASS(DATASET) ACCESS(UPDATE) ID(#cicsadmin)
PERMIT 'FEK.#CUST.ADNMAN*.**' CLASS(DATASET) ACCESS(UPDATE) ID(*)
PERMIT 'FEK.SFEKLOAD' CLASS(DATASET) ACCESS(READ) ID(#cicsts)
PERMIT 'FEK.SFEKLMOD' CLASS(DATASET) ACCESS(READ) ID(#cicsts)
PERMIT 'FEK.SFEKLMOD' CLASS(DATASET) ACCESS(READ) ID(#ims)
PERMIT 'FEK.SFEKLMOD' CLASS(DATASET) ACCESS(READ) ID(#batch)
SETROPTS GENERIC(DATASET) REFRESH
Verwenden Sie die folgenden Beispielbefehle, um die Ergebnisse Ihrer Anpassungen in Bezug auf die Sicherheit anzuzeigen.
Developer for System z verwendet TCP/IP, um Benutzern einer Workstation den Zugriff auf Mainframe-Computer bereitzustellen, wenn diese selbst kein Mainframe-Computer ist. TCP/IP wird außerdem für die Datenübertragung zwischen verschiedenen Komponenten und anderen Produkten verwendet.
Beachten Sie, dass die meisten Funktionen von Developer for System z auf z/OS UNIX basieren und TCP/IP daher die z/OS UNIX-Suchreihenfolge verwendet, um nach den entsprechenden Konfigurationsdateien zu suchen. Weitere Informationen finden Sie im Abschnitt TCP/IP konfigurieren.
Abbildung 10 stellt die TCP/IP-Ports dar, die mit Developer for System z verwendet werden können. Die Pfeilspitzen deuten an, welcher Teilnehmer für die Bindung (Pfeilspitzenseite) verantwortlich ist und welcher die Verbindung herstellt.
Wenn Sie in PROFILE.TCPIP die Anweisung PORT oder PORTRANGE verwenden, um die von Developer for System z verwendeten Ports zu reservieren, erfolgen zahlreiche Bindungen durch Threads, die im RSE-Thread-Pool aktiv sind. Der Jobname des RSE-Thread-Pools lautet RSEDx, wobei RSED der Name der gestarteten RSE-Task und x eine zufällige Ziffer ist. Daher sind in der Definition Platzhalter erforderlich.
PORT 4035 TCP RSED ; Developer for System z - RSE daemon
PORT 6715 TCP JMON ; Developer for System z - JES job monitor
PORT 5335 TCP DBGMGR ; Developer for System z – Integrated
Debugger
PORT 5336 TCP DBGMGR ; Developer for System z – Integrated
Debugger
PORTRange 8108 11 TCP RSED* ; Developer for System z - _RSE_PORTRANGE
;PORTRange 5227 100 TCP RSED* ; Developer for System z - CARMA
CARMA (Common Access Repository Manager) wird für den Zugriff auf einen hostbasierten Software Configuration Manager (SCM) verwendet, beispielsweise CA Endevor® SCM. In den meisten Fällen, beispielsweise bei einem RSE-Dämon, bindet ein Server an einen Port und wartet auf Verbindungsanforderungen. CARMA verwendet eine andere Methode, da der CARMA-Server während des Initialisierens der Verbindungsanforderung durch den Client noch nicht aktiv ist.
Wenn der Client eine Verbindungsanforderung sendet, forder der CARMA-Miner, der als Benutzerthread in einem RSE-Thread-Pool aktiv ist, einen ephemeren Port an oder sucht in dem Bereich, der in der Konfigurationsdatei CRASRV.properties angegeben ist, nach einem freien Port und bindet an diesen Port. Der Miner startet anschließend den CARMA-Server und übergibt die Portnummer, sodass der Server eine Verbindung zu dem entsprechenden Port herstellen kann. Wenn der Server mit dem Port verbunden ist, kann der Client Anforderungen an den Server senden und Ergebnisse empfangen.
Aus Sicht des TCP/IP ist also RSE (über den CARMA-Miner) der Server, der an einen Port bindet, und der CARMA-Server der Client, der eine Verbindung mit dem Server herstellt.
Wenn Sie die Anweisung PORT oder PORTRANGE in PROFILE.TCPIP verwenden, um den Portbereich zu reservieren, der von CARMA verwendet wird, beachten Sie, dass der CARMA-Miner in einem RSE-Thread-Pool aktiv ist. Der Jobname des RSE-Thread-Pools lautet RSEDx, wobei RSED der Name der gestarteten RSE-Task und x eine zufällige Ziffer ist. Daher sind in der Definition Platzhalter erforderlich.
PORTRange 5227 100 RSED* ; Developer for System z - CARMA
Durch verzögertes ACK wird die Empfangsbestätigung (ACK) eines TCP-Pakets um bis zu 200 ms verzögert. Diese Verzögerung erhöht die Chance, dass die ACK zusammen mit der Antwort zum empfangenen Paket gesendet werden kann. Bezweckt wird damit eine Reduzierung des Netzverkehrs. Wenn der Absender allerdings vor dem Versenden eines neuen Pakets auf die ACK wartet (z. B. aufgrund der Implementierung des Nagle-Algorithmus) und auf das gerade gesendete Paket keine Antwort eingeht (z. B. weil es Teil einer Dateiübertragung ist), wird die Kommunikation unnötig verzögert.
Die Verzögerung der ACK kann in Developer for System z inaktiviert werden. Auf dem Host erfolgt dies, wie im Handbuch Hostkonfiguration (IBM Form SC23-7658) beschrieben, in rsed.envvars mit der Direktive DSTORE_TCP_NO_DELAY.
Mit z/OS Communication Server können auf einem einzelnen System mehrere TCP/IP-Stacks aktiv sein. Dies wird CINET-Konfiguration genannt.
Wenn Developer for System z im Standardstack nicht aktiv ist, schlagen bestimmte Developer for System z-Funktionen möglicherweise fehl. Die Verwendung von Stackaffinität ist eine sichere Möglichkeit, dieses Problem zu lösen. Stackaffinität weist Developer for System z an, statt jeden verfügbaren TCP/IP-Stack (Standardeinstellung für die gestarteten Tasks) nur einen bestimmten TCP/IP-Stack zu verwenden.
Stackaffinität wird für die gestartete RSED-Task festgelegt, indem das Kommentarzeichen vor der Anweisung _BPXK_SETIBMOPT_TRANSPORT in der Konfigurationsdatei rsed.envvars entfernt und die Anweisung angepasst wird. Weitere Informationen zur Anpassung dieser Konfigurationsdatei finden Sie im entsprechenden Abschnitt in 'Kapitel 2. Basisanpassung' im Handbuch Hostkonfiguration (IBM Form SC12-4062).
CARMA (Common Access Repository Manager) wird für den Zugriff auf einen hostbasierten Software Configuration Manager (SCM) verwendet, beispielsweise CA Endevor® SCM. Dazu startet CARMA einen benutzerspezifischen Server, der eine zusätzliche Konfiguration erfordert, um Stackaffinität umzusetzen.
Ähnlich den gestarteten Developer for System z-Tasks wird Stackaffinität für einen CARMA-Server mit der Variable _BPXK_SETIBMOPT_TRANSPORT festgelegt, die an LE (Language Environment) weitergegeben werden muss. Dies erfolgt durch Anpassung des Startbefehls in der aktiven Konfigurationsdatei crastart*.conf oder CRASUB*.
... PARM(&CRAPRM1. &CRAPRM2.)
... PARM(ENVAR("_BPXK_SETIBMOPT_TRANSPORT=TCPIP") / &CRAPRM1. &CRAPRM2.)
... PARM(&PORT &TIMEOUT)
... PARM(ENVAR("_BPXK_SETIBMOPT_TRANSPORT=TCPIP") / &PORT &TIMEOUT)
Mit der verteilten DVIPA (Dynamic Virtual IP Addressing, dynamische virtuelle IP-Adressierung) können Sie gleichzeitig zwei verschiedene Konfigurationen von Developer for System z auf unterschiedlichen Systemen in Ihrem Sysplex ausführen und die Clientverbindungen (mit optionaler Unterstützung durch WLM) über TCP/IP auf diese Systeme aufteilen.
Aus diesem Grund ist in Developer for System z die Definition von SYSPLEXPORTS in der Anweisung VIPADISTRIBUTE erforderlich, um sicherzustellen, dass die von den RSE-Server-Threads verwendeten Ports im Sysplex eindeutig sind.
JES Job Monitor, CARMA und weitere Server von Developer for System z interagieren nur mit dem lokalen RSE. Daher ist keine DVIPA-Konfiguration erforderlich.
Integrated Debugger interagiert nur mit dem lokalen RSE. Daher ist keine DVIPA-Konfiguration erforderlich. Um sicherzustellen, dass Debugsitzungen mit dem korrekten Host kommunizieren, wird mit Debug Manager der Client festgelegt, dessen TCP/IP-Adresse verwendet werden muss. Daher ist keine DVIPA-Konfiguration erforderlich.
Verteilte DVIPA werden in Ihrem TCP/IP-Profil im Block VIPADynamic durch die Schlüsselwörter VIPADEFine und VIPABackup definiert. Mit dem Schlüsselwort VIPADISTribute werden die erforderlichen Sysplex Distributor-Definitionen hinzugefügt. Bei der verteilten DVIPA ist es erforderlich, dass alle teilnehmenden Stacks sysplexfähig sind. Dies wird in Ihrem TCP/IP-Profil im Block IPCONFIG mit den Schlüsselwörtern SYSPLEXRouting und DYNAMICXCF festgelegt. Weitere Details zu diesen Anweisungen finden Sie im Handbuch Communications Server: IP Configuration Reference (IBM Form SC31-8776).
Weitere Informationen zum Einrichten der EZBEPORTS-Struktur in Ihrer Coupling-Facility finden Sie in MVS Setting Up a Sysplex (IBM Form SA22-7625) und Communication Server: SNA Network Implementation Guide (IBM Form SC31-8777).
Die Syntax von SYSPLEXPORTS setzt voraus, dass TCP/IP einen ephemeren Port für die sekundäre Verbindung auswählt. Ein ephemerer Port ist ein beliebiger freier Port, der nicht reserviert ist. Die Verwendung eines ephemeren Ports kollidiert mit den bewährten Verfahren für Firewalls zur Einschränkung der Ports, die für die Kommunikation geöffnet werden, da nicht bekannt ist, welcher Port verwendet wird.
Sie können dieses Problem umgehen, indem Sie Developer for System z dazu zwingen, für die sekundäre Verbindung bekannte Ports zu verwenden; hierbei wird ein eindeutiger _RSE_PORTRANGE für jedes System definiert und sichergestellt, dass die verwendeten Portbereiche für die Verwendung von Developer for System z auf allen Systemen reserviert werden. Beachten Sie, dass für diese Umgehung der TCP/IP-APAR PM63379 erforderlich ist.
Um sicherzustellen, dass TCP/IP die sekundäre Verbindung an das richtige System weiterleitet, muss Developer for System z einen eindeutigen Portbereich auf jedem System verwenden. Dies impliziert, dass Sie keinen gemeinsamen, identischen Setup für die Systeme verwenden können, da _RSE_PORTRANGE in rsed.envvars eindeutig sein muss. Informationen zur Einrichtung mehrerer Server mit unterschiedlichen Konfigurationsdateien bei der Verwendung desselben Codes finden Sie im Abschnitt zu Identische Softwareversionen mit unterschiedlichen Konfigurationsdateien in Ausführung mehrerer Instanzen. Sie sollten eine Masterkopie von rsed.envvars und ein Script verwenden, um die Datei anzupassen und auf ein systemspezifisches Setup zu kopieren, um sicherzustellen, dass die Datei auf den unterschiedlichen Systemen identisch bleibt.
$ oedit /etc/rdz/rsed.envvars
-> add the following at the END:
# -- NEEDED TO FIND THE REMAINING CONFIGURATION FILES
CFG_BASE=/etc/rdz
CLASSPATH=.:$CFG_BASE:$CLASSPATH
# --
$ oedit /etc/rdz/update.sh
$ chmod 755 /etc/rdz/update.sh
#! /bin/sh
# Licensed materials - Property of IBM
# 5724-T07 Copyright IBM Corp. 2012
# clone rsed.envvars and set PORTRANGE for use with RDz & DDVIPA
file=rsed.envvars #; echo file $file
sys=${1:-$(sysvar SYSNAME)} #; echo sys $sys
dir=$(dirname $0) #; echo dir $dir
# if sysname has a special char, precede it with \ (eg. SYS\$1)
case "$sys" in # #### CUSTOMIZE THIS SECTION ####
"SYS1") range=8108-8118;;
"SYS2") range=8119-8129;;
esac #; echo range $range
echo "setting port range $range for $sys using $dir/$file"
if test ! $range ; then
echo ERROR: no port range defined for $sys ; exit 12 ; fi
if test ! -e $dir/$file ; then
echo ERROR: file $dir/$file does not exist ; exit 12 ; fi
if test ! -d $dir/$sys ; then
echo ERROR: directory $dir/$sys does not exist ; exit 12 ; fi
mv $dir/$sys/$file $dir/$sys/prev.$file 2>/dev/null
sed="/_RSE_PORTRANGE/s/.*/_RSE_PORTRANGE=$range/"
sed "$sed" $dir/$file > $dir/$sys/$file
if test ! -s $dir/$sys/$file ; then
echo ERROR creating $dir/$sys/$file, restoring backup
mv $dir/$sys/prev.$file $dir/$sys/$file ; exit 8 ; fi
$ mkdir /etc/rdz/SYS1 /etc/rdz/SYS2
$ /etc/rdz/update.sh SYS1
setting port range 8108-8118 for SYS1 using
/etc/rdz/rsed.envvars
$ /etc/rdz/update.sh SYS2
setting port range 8119-8129 for SYS2 using
/etc/rdz/rsed.envvars
// CNFG='/etc/rdz/&SYSNAME.'
PORTRange 8108 22 RSED* ; 8108-8129 - Developer for System z
; - secondary connection
Wie in Verbindungsflow beschrieben, kann der Portbereich in _RSE_PORTRANGE schmal sein. Der RSE-Server muss den Port nicht exklusiv für die Dauer der Clientverbindung benötigen. Es kann sich nur während der Serverbindung an den Port und des Verbindungsaufbaus des Clients kein anderer RSE-Server an den Port binden. Das bedeutet, dass für die meisten Verbindungen der erste Port des Portbereichs verwendet wird, die restlichen Ports des Bereichs also nur als Puffer für den Fall dienen, dass mehrere Anmeldungen gleichzeitig erfolgen.
Die folgende Musterkonfiguration enthält zwei z/OS-Systeme, SYS1 und SYS2, die Teil eines Sysplex sind. System "SYS1" ist als das System definiert, das gewöhnlich Sysplex Distributor für die verteilte DVIPA von Developer for System z bereitstellt.
Nachdem die verteilte DVIPA definiert wurde, kann Developer for System z auf den Systemen gestartet werden, um den Lastausgleich für Clientverbindungen zwischen den Systemen zu ermöglichen. JES Job Monitor interagiert nur mit dem lokalen RSE. Daher ist keine DVIPA-Konfiguration erforderlich. Clients stellen eine Verbindung mit Port 4035 für die IP-Adresse 10.10.10.1 her.
IPCONFIG
SYSPLEXRouting
; SYSPLEXROUTING is required as this stack needs sysplex communication
DYNAMICXCF 9.9.9.1 255.255.255.0 1
; DYNAMICXCF defines device/link with home address 9.9.9.1 as needed
IGNORERedirect
VIPADYNAMIC
VIPADEFINE 255.255.255.0 10.10.10.1
; VIPADEFINE defines 10.10.10.1 as main DVIPA on SYS1 for RDz
VIPADISTRIBUTE DEFINE
; VIPADISTRIBUTE makes 10.10.10.1 a distributed DVIPA, must match SYS2
SYSPLEXPORTS ; RDz prereq
DISTMETHOD BASEWLM ; BASEWLM or ROUNDROBIN
10.10.10.1 ; DVIPA address used by RDz clients
PORT 4035 ; port used by RDz clients
DESTIP 9.9.9.1 9.9.9.2 ; RDz active on SYS1 and SYS2
ENDVIPADYNAMIC
IPCONFIG
SYSPLEXRouting
; SYSPLEXROUTING is required as this stack needs sysplex communication
DYNAMICXCF 9.9.9.2 255.255.255.0 1
; DYNAMICXCF defines device/link with home address 9.9.9.2 as needed
IGNORERedirect
VIPADYNAMIC
VIPABACKUP 255.255.255.0 10.10.10.1
; VIPABACKUP defines 10.10.10.1 as backup DVIPA on SYS2 for RDz
VIPADISTRIBUTE DEFINE
; VIPADISTRIBUTE makes 10.10.10.1 a distributed DVIPA, must match SYS1
SYSPLEXPORTS ; RDz prereq
DISTMETHOD BASEWLM ; BASEWLM or ROUNDROBIN
10.10.10.1 ; DVIPA address used by RDz clients
PORT 4035 ; port used by RDz clients
DESTIP 9.9.9.1 9.9.9.2 ; RDz active on SYS1 and SYS2
ENDVIPADYNAMIC
Im Gegensatz zu herkömmlichen z/OS-Anwendungen ist Developer for System z keine einzelne Anwendung, die von Workload Manager (WLM) auf einfache Weise erkannt wird. Developer for System z umfasst mehrere interagierende Komponenten, damit der Client auf die Host-Services und -daten zugreifen kann. Wie in Wissenswertes zu Developer for System z beschrieben, sind einige dieser Services in verschiedenen Adressräumen aktiv und werden somit verschiedenen WLM-Klassifikationen zugeordnet.
Abbildung 13 zeigt eine Basisübersicht über die Subsysteme, über die die Informationen zu den Verarbeitungsprozessen von Developer for System z an WLM weitergegeben werden.
Application Deployment Manager (ADM) ist innerhalb einer CICS-Region aktiv und befolgt deshalb die CICS-Klassifikationsregeln in WLM.
Der RSE-Dämon (RSED), Debug Manager (DBGMGR) und JES Job Monitor (JMON) sind gestartete Tasks in Developer for System z (oder lang laufende Batch-Jobs) mit individuellen Adressräumen.
Wie in RSE als Java-Anwendung dokumentiert, startet der RSE-Dämon für jeden RSE-Thread-Pool-Server (der eine variable Anzahl von Clients unterstützt) einen untergeordneten Prozess. Jeder Thread-Pool ist (mithilfe eines z/OS UNIX-Initiators, BPXAS) in einem separaten Adressraum aktiv. Da es sich hierbei um gestartete Prozesse handelt, werden diese nach den WLM-OMVS-Klassifikationsregeln und nicht nach den Klassifikationsregeln für gestartete Tasks klassifiziert.
Abhängig von den Aktionen der Benutzer können die Clients, die in einem Thread-Pool aktiv sind, eine Vielzahl anderer Adressräume erstellen. Abhängig von der Konfiguration von Developer for System z, können einige Verarbeitungsprozesse, wie TSO Commands Service (TSO cmd) oder CARMA, in anderen Subsystemen ausgeführt werden.
Die in Abbildung 13 aufgeführten Adressräume bleiben für einen längeren Zeitraum im System sichtbar. Sie sollten allerdings beachten, dass z/OS UNIX so entwickelt wurde, dass es auch einige kurz andauernde, temporäre Adressräume gibt. Diese temporären Adressräume sind im OMVS-Subsystem aktiv.
Während die RSE-Thread-Pools dieselbe Benutzer-ID und einen ähnlichen Jobnamen wie der RSE-Dämon verwenden, gehören alle von einem Thread-Pool gestarteten Adressräume der Client-Benutzer-ID, die die Aktion anfordert. Die Client-Benutzer-ID wird außerdem als Teil des Jobnamens für alle vom Thread-Pool gestarteten OMVS-basierten Adressräume verwendet.
Weitere Adressräume werden von anderen Services erstellt, die Developer for System z verwendet, wie File Manager (FMNCAS) oder z/OS UNIX-REXEC (USS-Build).
WLM verwendet Klassifikationsregeln, um im System eingehende Arbeit einer Serviceklasse zuzuordnen. Diese Klassifikation basiert auf Qualifikationsmerkmalen für Arbeit. Das erste (verbindliche) Merkmal ist der Subsystemtyp, der die Verarbeitungsanforderung empfängt. In Tabelle 14 werden die Subsystemtypen aufgeführt, die Verarbeitungsanforderungen von Developer for System z empfangen können.
Subsystemtyp | Beschreibung der Arbeit |
---|---|
ASCH | Die Verarbeitungsanforderungen umfassen alle APPC-Transaktionsprogramme, die von dem von IBM gelieferten APPC/MVS-Transaktionsscheduler (ASCH) geplant werden. |
CICS | Die Verarbeitungsanforderungen umfassen alle Transaktionen, die von CICS verarbeitet werden. |
JES | Die Verarbeitungsanforderungen umfassen alle Jobs, die von JES2 oder JES3 initialisiert werden. |
OMVS | Die Verarbeitungsanforderungen umfassen Arbeit, die in verzweigten untergeordneten Adressräumen von z/OS UNIX System Services verarbeitet wird. |
STC | Die Verarbeitungsanforderungen umfassen Arbeit, die von den Befehlen 'START' und 'MOUNT' initialisiert wird. STC umfasst außerdem Adressräume der Systemkomponente. |
Tabelle 15 listet zusätzliche Merkmale auf, die für die Zuordnung von Verarbeitungsprozessen zu einer bestimmten Serviceklasse verwendet werden können. Weitere Details zu den aufgelisteten Merkmalen enthält MVS Planning: Workload Management (IBM Form SA22-7602).
ASCH | CICS | JES | OMVS | STC | ||
---|---|---|---|---|---|---|
AI | Accountinformationen | |||||
LU | LU-Name (*) | |||||
PF | Ausführung (*) | |||||
PRI | Priorität | |||||
SE | Name der Terminierungsumgebung | |||||
SSC | Objektgruppenname des Subsystems | |||||
SI | Subsysteminstanz (*) | |||||
SPM | Subsystemparameter | |||||
PX | Sysplex-Name | |||||
SY | Systemname (*) | |||||
TC | Transaktions-/Jobklasse (*) | |||||
TN | Transaktions-/Jobname (*) | |||||
UI | Benutzer-ID (*) |
Wie unter Klassifikation für Verarbeitungsprozesse dokumentiert, erstellt Developer for System z unterschiedliche Typen von Verarbeitungsprozessen auf Ihrem System. Diese verschiedenen Tasks kommunizieren miteinander. Dafür ist die eigentliche Antwortzeit wichtig, um Zeitüberschreitungsprobleme bezüglich der Verbindungen zwischen den Tasks zu vermeiden. Deshalb sollten Tasks in Developer for System z in leistungsfähige Serviceklassen oder in Serviceklassen mit mittlerer Leistung mit hoher Priorität eingeordnet werden.
Es wird daher eine Überarbeitung und gegebenenfalls eine Aktualisierung Ihrer aktuellen WLM-Ziele empfohlen. Dies gilt insbesondere für herkömmliche MVS-Unternehmen, für die zeitkritische OMVS-Verarbeitungsprozesse neu sind.
In Tabelle 16 werden die Adressräume aufgelistet, die von Developer for System z verwendet werden. z/OS UNIX ersetzt den Wert "x" in der Spalte "Taskname" durch eine zufällige einstellige Zahl.
Beschreibung | Taskname | Verarbeitungsprozess |
---|---|---|
Debug Manager | DBGMGR | STC |
JES Job Monitor | JMON | STC |
RSE-Dämon | RSED | STC |
RSE-Thread-Pool | RSEDx | OMVS |
ISPF Client Gateway (TSO Commands Service und SCLMDT) | <Benutzer-ID>x | OMVS |
TSO Commands Service (APPC) | FEKFRSRV | ASCH |
CARMA (batch) | CRA<Port> | JES |
CARMA (crastart) | <Benutzer-ID>x | OMVS |
CARMA (ISPF-Client-Gateway) | <Benutzer-ID> und <Benutzer-ID>x | OMVS |
MVS-Build (Batch-Job) | * | JES |
z/OS UNIX-Build (Shellbefehle) | <Benutzer-ID>x | OMVS |
z/OS UNIX-Shell | <Benutzer-ID> | OMVS |
Application Deployment Manager | CICSTS | CICS |
Alle gestarteten Tasks von Developer for System z (RSE-Dämon und JES Job Monitor) bedienen Echtzeit-Clientanforderungen.
Beschreibung | Taskname | Verarbeitungsprozess |
---|---|---|
JES Job Monitor | JMON | STC |
Debug-Manager | DBGMGR | STC |
RSE-Dämon | RSED | STC |
JES Job Monitor stellt alle Services mit Bezug zu JES bereit. Diese schließen das Übergeben von Jobs, das Durchsuchen von Spooldateien und das Ausführen von JES-Bedienerbefehlen ein. Sie sollten ein leistungsfähiges Geschwindigkeitsziel für einen Zeitraum angeben, da die Task WLM keine einzelnen Transaktionen zurückmeldet. Die Ressourcennutzung hängt im großen Maße von den Benutzeraktionen ab und kann deshalb schwanken. Es ist jedoch zu erwarten, dass sie minimal bis mäßig ist.
Debug-Manager bietet Services zur Herstellung einer Verbindung von Programmen, deren Debug ausgeführt wird, mit den Clients, die das Debugging ausführen. Sie sollten ein leistungsfähiges Geschwindigkeitsziel für einen Zeitraum angeben, da die Task WLM keine einzelnen Transaktionen zurückmeldet. Die Ressourcennutzung hängt im großen Maße von den Benutzeraktionen ab und kann deshalb schwanken. Es ist jedoch zu erwarten, dass sie minimal ist.
Der RSE-Dämon führt die Clientanmeldung und -authentifizierung aus und verwaltet die verschiedenen RSE-Thread-Pools. Sie sollten ein leistungsfähiges Geschwindigkeitsziel für einen Zeitraum angeben, da die Task WLM keine einzelnen Transaktionen zurückmeldet. Es wird eine mäßige Ressourcennutzung mit einem Spitzenwert zu Beginn des Arbeitstages erwartet.
Die OMVS-Verarbeitungsprozesse können in zwei Gruppen unterteilt werden: RSE-Thread-Pools und alle anderen Verarbeitungsprozesse. Dies hat zur Ursache, dass alle Verarbeitungsprozesse, außer RSE-Thread-Pools, die Client-Benutzer-ID als Grundlage für den Adressraumnamen verwenden. (z/OS UNIX ersetzt den Wert "x" in der Spalte "Taskname" durch eine zufällige einstellige Zahl.)
Beschreibung | Taskname | Verarbeitungsprozess |
---|---|---|
RSE-Thread-Pool | RSEDx | OMVS |
ISPF Client Gateway (TSO Commands Service und SCLMDT) | <Benutzer-ID>x | OMVS |
CARMA (crastart) | <Benutzer-ID>x | OMVS |
CARMA (ISPF-Client-Gateway) | <Benutzer-ID> und <Benutzer-ID>x | OMVS |
z/OS UNIX-Build (Shellbefehle) | <Benutzer-ID>x | OMVS |
z/OS UNIX-Shell | <Benutzer-ID> | OMVS |
Ein RSE-Thread-Pool ist das Herzstück von Developer for System z. Beinahe alle Daten fließen durch diesen Pool und die Miners (benutzerspezifische Threads) innerhalb des Thread-Pools steuern die Aktionen der meisten anderen Tasks in Bezug auf Developer for System z. Sie sollten ein leistungsfähiges Geschwindigkeitsziel für einen Zeitraum angeben, da die Task WLM keine einzelnen Transaktionen zurückmeldet. Die Ressourcennutzung hängt im großen Maße von den Benutzeraktionen ab und kann deshalb schwanken. Es ist jedoch zu erwarten, dass sie erheblich ist.
Die restlichen Verarbeitungsprozesse werden alle aufgrund einer allgemeinen Namenskonvention für Adressräume derselben Serviceklasse zugeordnet. Für diese Serviceklasse sollten Sie ein Ziel für mehrere Zeiträume angeben. Für die ersten Zeiträume sollten Sie leistungsfähige Perzentilantwortzeitziele und für den letzten Zeitraum ein Geschwindigkeitsziel mit mittlerer Leistung angeben. Einige Verarbeitungsprozesse, wie das ISPF-Client-Gateway, melden WLM einzelne Transaktionen zurück.
Das ISPF-Client-Gateway ist ein ISPF-Service, der von Developer for System z aufgerufen wird, um nicht interaktive TSO- und ISPF-Befehle auszuführen. Dies schließt sowohl vom Client ausgegebene, explizite Befehle als auch von Developer for System z ausgegebene, implizite Befehle ein, z. B. das Abrufen einer PDS-Memberliste. Die Ressourcennutzung hängt im großen Maße von den Benutzeraktionen ab und kann deshalb schwanken. Es ist jedoch zu erwarten, dass sie minimal ist.
CARMA ist ein optionaler Developer for System z-Server, der für die Interaktion mit hostbasierten Software Configuration Managers (SCMs), wie CA Endevor® SCM, verwendet wird. Developer for System z lässt verschiedene Startmethoden für einen CARMA-Server zu. Einige davon werden als OMVS-Verarbeitungsprozess gehandhabt. Die Ressourcennutzung hängt im großen Maße von den Benutzeraktionen ab und kann deshalb schwanken. Es ist jedoch zu erwarten, dass sie minimal ist.
Wenn ein Client einen Build für ein z/OS UNIX-Projekt initialisiert, startet die z/OS UNIX-REXEC (oder SSH) eine Task, die zur Ausführung des Builds eine Reihe von z/OS UNIX-Shellbefehlen ausführt. Die Ressourcennutzung hängt im großen Maße von den Benutzeraktionen ab und kann deshalb schwanken. Es ist jedoch zu erwarten, dass sie mäßig bis erheblich ist (abhängig von der Größe des Projekts).
Bei dieser Workload werden vom Client ausgegebene z/OS UNIX-Shellbefehle verarbeitet. Die Ressourcennutzung hängt im großen Maße von den Benutzeraktionen ab und kann deshalb schwanken. Es ist jedoch zu erwarten, dass sie minimal ist.
JES-verwaltete Batchprozesse werden von Developer for System z auf verschiedene Weisen verwendet. Die bekannteste Nutzung ist für MVS-Builds, für die ein Job übergeben und überwacht wird, um sein Ende zu bestimmen. Developer for System z kann jedoch auch einen CARMA-Server mit Batchübergabe starten und mit ihm über TCP/IP kommunizieren.
Beschreibung | Taskname | Verarbeitungsprozess |
---|---|---|
CARMA (batch) | CRA<Port> | JES |
MVS-Build (Batch-Job) | * | JES |
CARMA ist ein optionaler Developer for System z-Server, der für die Interaktion mit hostbasierten Software Configuration Managers (SCMs), wie CA Endevor® SCM, verwendet wird. Developer for System z lässt verschiedene Startmethoden für einen CARMA-Server zu. Einige davon werden als JES-Verarbeitungsprozess gehandhabt. Sie sollten ein leistungsfähiges Geschwindigkeitsziel für einen Zeitraum angeben, da die Task WLM keine einzelnen Transaktionen zurückmeldet. Die Ressourcennutzung hängt im großen Maße von den Benutzeraktionen ab und kann deshalb schwanken. Es ist jedoch zu erwarten, dass sie minimal ist.
In den aktuellen Versionen von Developer for System z wird das ISPF-Client-Gateway verwendet, um nicht interaktive TSO- und ISPF-Befehle auszuführen. Aus historischen Gründen unterstützt Developer for System z die Ausführung dieser Befehle auch über eine APPC-Transaktion. Sie sollten beachten, dass die APPC-Methode nicht weiter unterstützt wird.
Beschreibung | Taskname | Verarbeitungsprozess |
---|---|---|
TSO Commands Service (APPC) | FEKFRSRV | ASCH |
TSO Commands Service kann von Developer for System z als APPC-Transaktion gestartet werden, um nicht interaktive TSO- und ISPF-Befehle auszuführen. Dies schließt sowohl vom Client ausgegebene, explizite Befehle als auch von Developer for System z ausgegebene, implizite Befehle ein, z. B. das Abrufen einer PDS-Memberliste. Für diese Serviceklasse sollten Sie ein Ziel für mehrere Zeiträume angeben. Für die ersten Zeiträume sollten Sie leistungsfähige Perzentilantwortzeitziele angeben. Für den letzten Zeitraum sollten Sie ein Geschwindigkeitsziel mit mittlerer Leistung angeben. Die Ressourcennutzung hängt im großen Maße von den Benutzeraktionen ab und kann deshalb schwanken. Es ist jedoch zu erwarten, dass sie minimal ist.
Application Deployment Manager ist ein optionaler Developer for System z-Server, der innerhalb einer CICS Transaction Server-Region aktiv ist.
Beschreibung | Taskname | Verarbeitungsprozess |
---|---|---|
Application Deployment Manager | CICSTS | CICS |
Der optionale Application Deployment Manager-Server, der innerhalb einer CICSTS-Region aktiv ist, ermöglicht Ihnen das sichere Auslagern ausgewählter CICSTS-Verwaltungstasks an Entwickler. Die Ressourcennutzung hängt im großen Maße von den Benutzeraktionen ab und kann deshalb schwanken. Es ist jedoch zu erwarten, dass sie minimal ist. Der zu verwendende Serviceklassentyp hängt von den anderen in dieser CICS-Region aktiven Transaktionen ab und ist deshalb nicht im Detail beschrieben.
Das Ziel ist auf eine Serviceklasse festgelegt, die die CICS-Adressräume verwaltet. Für diese Serviceklasse können Sie nur ein Ziel für die Ausführungsgeschwindigkeit festlegen. WLM verwendet für die Adressräume die JES- oder STC-Klassifikationsregeln. Es verwendet jedoch nicht die CICS-Subsystemklassifikationsregeln für Transaktionen.
Ein Antwortzeitziel kann in einer Serviceklasse festgelegt werden, die einer einzelnen Transaktion oder einer Gruppe von Transaktionen zugewiesen ist. WLM verwendet für die Adressräume die JES- oder STC-Klassifikationsregeln und die CICS-Subsystemklassifikationsregeln für Transaktionen.
Wie in Wissenswertes zu Developer for System z erklärt wird, ist RSE (Remote Systems Explorer) der zentrale Bestandteil von Developer for System z. RSE besteht aus einem Dämonadressbereich, der Thread-Pooling und Adressräume steuert, um die Verbindungen und die Arbeitslast der Clients zu verwalten. Der Dämon wird als Sammelpunkt für Verbindungs- und Verwaltungszwecke eingesetzt, während die Thread-Pools die Clientarbeitslast verarbeiten.
Dadurch wird RSE das Hauptziel für die Optimierung der Installation von Developer for System z. Wenn Sie allerdings Hunderte von Benutzern verwalten, von denen jeder einzelne mindestens 17 Threads, eine bestimmte Speichermenge und möglicherweise einen oder mehr Adressräume verwendet, so müssen sowohl Developer for System z als auch z/OS ordnungsgemäß konfiguriert sein.
Verwenden Sie die Informationen in diesem Abschnitt, um Schätzwerte für die normale und maximale Ressourcennutzung von Developer for System z zu berechnen und Ihre Systemkonfiguration entsprechend planen zu können.
Wenn Sie die in diesem Abschnitt vorhandenen Zahlen und Formeln verwenden, um die Grenzwerte für das System zu definieren, achten Sie darauf, dass Sie mit relativ präzisen Schätzwerten arbeiten. Planen Sie beim Festlegen der Begrenzungen für das System ausreichend Spielraum ein, um die Ressourcennutzung für temporäre oder andere Tasks sowie für Benutzer zu ermöglichen, die sich mehrfach gleichzeitig am Host anmelden (beispielsweise über RSE und TN3270).
Gestartete Task | Adressräume | Prozesse | Threads |
---|---|---|---|
JMON | 1 | 1 | 3 |
DBGMGR | 1 | 1 | 4 |
RSED | 1 | 3 | 16 |
RSEDx | (a) 1 + 2 | 1 + 3 | 1 + 14 |
Vorausgesetzte Software | Adressräume | Prozesse | Threads |
---|---|---|---|
ISPF Client Gateway | 1 | 2 | 4 |
APPC-Administrator | 1 | 1 | 2 |
Benutzeraktion | Adressräume Benutzer-ID |
Prozesse Benutzer-ID |
Threads |
||
---|---|---|---|---|---|
Anmelden | - | - | - | 17 | 1 |
Zeitgeber für Inaktivitätszeitlimit | - | - | - | 1 | - |
Suchen | - | - | - | 1 | - |
Komprimierung für PDS(E) aufheben | ISPF | ISPF | ISPF | - | - |
Datei öffnen | ISPF | ISPF | ISPF | 1 | - |
TSO-Befehl | ISPF | ISPF | ISPF | - | - |
z/OS UNIX-Shell | 1 | 1 | 1 | 6 | - |
MVS-Build | 1 | - | - | - | - |
z/OS UNIX-Build | 3 | 3 | 3 | - | - |
CARMA (batch) | 1 | 1 | 2 | 1 | - |
CARMA (crastart) | 1 | 1 | 2 | 1 | - |
![]() ![]() |
![]() ![]() |
![]() ![]() |
![]() ![]() |
![]() ![]() |
![]() ![]() |
CARMA (ispf) | 4 | 4 | 7 | 5 | - |
SCLMDT | ISPF | ISPF | ISPF | - | - |
Anzahl | Beschreibung | Taskname | Gemeinsame Nutzung | Endet nach |
---|---|---|---|---|
1 | JES Job Monitor | JMON | Ja | Nie |
1 | Debug Manager | DBGMGR | Ja | Nie |
1 | RSE-Dämon | RSED | Ja | Nie |
1 | RSE-Dämon, APF-autorisiert | RSEDx | Ja | Nie |
(a) | RSE-Thread-Pool | RSEDx | Ja | Nie |
(a) | RSE-Thread-Pool, APF-autorisiert | RSEDx | Ja | Nie |
1u | ISPF Client Gateway (TSO Commands Service und SCLMDT) | <Benutzer-ID>x | Nein | 15 Minuten oder Abmeldung des Benutzers |
1u | TSO Commands Service (APPC) | FEKFRSRV | Nein | 60 Minuten oder Abmeldung des Benutzers |
1u | CARMA (batch) | CRA<Port> | Nein | 7 Minuten oder Abmeldung des Benutzers |
1u | CARMA (crastart) | <Benutzer-ID>x | Nein | 7 Minuten oder Abmeldung des Benutzers |
![]() ![]() |
![]() ![]() |
![]() ![]() |
![]() ![]() |
![]() ![]() |
4u | CARMA (ispf, nicht weiter unterstützt) | (1)<Benutzer-ID> oder (3)<Benutzer-ID>x | Nein | 7 Minuten oder Abmeldung des Benutzers |
(b) | Simultane Verwendung von ISPF Client Gateway von 1 Benutzer | <Benutzer-ID>x | Nein | Fertigstellung der Task |
1u | MVS-Build (Batch-Job) | * | Nein | Fertigstellung der Task |
3u | z/OS UNIX-Build (Shellbefehle) | <Benutzer-ID>x | Nein | Fertigstellung der Task |
1u | z/OS UNIX-Shell | <Benutzer-ID> | Nein | Abmeldung des Benutzers |
X | SCLMDT | TSO über Client-Gateway | TSO über APPC |
---|---|---|---|
1 | Nein | Nein | Ja |
1 | Nein | Ja | Nein |
1 | Ja | Ja | Nein |
Y | |
---|---|
0 | Kein CARMA |
1 | CARMA (batch) |
1 | CARMA (crastart) |
![]() ![]() |
![]() ![]() |
4 | CARMA (ispf, nicht weiter unterstützt) |
Position | Begrenzung | Beeinträchtigte Ressourcen |
---|---|---|
rsed.envvars | maximum.threadpool.process | Begrenzt die Anzahl von RSE-Thread-Pools |
IEASYMxx | MAXUSER | Begrenzt die Anzahl von Adressräumen |
ASCHPMxx | MAX | Begrenzt die Anzahl von APPC-Initiatoren für TSO Commands Service (APPC) |
Prozesse | Adressräume | Beschreibung | Benutzer-ID |
---|---|---|---|
1 | 1 | JES Job Monitor | STCJMON |
1 | 1 | Debug-Manager | STCDBM |
3 | 1 | RSE-Dämon | STCRSE |
1 | 1 | RSE-Dämon, APF-autorisiert | STCRSE |
2 | (a) | RSE-Thread-Pool | STCRSE |
1 | (a) | RSE-Thread-Pool, APF-autorisiert | STCRSE |
2 | (b) | ISPF Client Gateway (TSO Commands Service und SCLMDT) | <Benutzer-ID> |
2 | (a) | RSE-Thread-Pool | STCRSE |
1 | 1u | TSO Commands Service (APPC) | <Benutzer-ID> |
1 | 1u | CARMA (batch) | <Benutzer-ID> |
1 | 1u | CARMA (crastart) | <Benutzer-ID> |
![]() ![]() |
![]() ![]() |
![]() ![]() |
![]() ![]() |
1 | 1u | CARMA (ispf, nicht weiter unterstützt) | <Benutzer-ID> |
1 | 3u | z/OS UNIX-Build (Shellbefehle) | <Benutzer-ID> |
1 | 1u | z/OS UNIX-Shell | <Benutzer-ID> |
(5) | (u) | SCLM Developer Toolkit | <Benutzer-ID> |
X | SCLMDT | TSO über Client-Gateway | TSO über APPC |
---|---|---|---|
1 | Nein | Nein | Ja |
2 | Nein | Ja | Nein |
7 | Ja | Ja | Nein |
Y | |
---|---|
0 | Kein CARMA |
1 | CARMA (batch) |
1 | CARMA (crastart) |
![]() ![]() |
![]() ![]() |
4 | CARMA (ispf, nicht weiter unterstützt) |
Position | Begrenzung | Beeinträchtigte Ressourcen |
---|---|---|
BPXPRMxx | MAXPROCSYS | Begrenzt die Gesamtzahl von Prozessen |
BPXPRMxx | MAXPROCUSER | Begrenzt die Anzahl von Prozessen pro z/OS UNIX-Benutzer-ID |
OMVS-Segment | PROCUSERMAX | Begrenzt die Anzahl von Prozessen für eine Benutzer-ID |
Threads |
Benutzer-ID | Beschreibung | ||
---|---|---|---|---|
RSEDx | Aktiv | Booten | ||
- | (f) 3 + 1u | - | STCJMON | JES Job Monitor |
- | 4 | - | STCDBM | Debug Manager |
- | 14 | 2 | STCRSE | RSE-Dämon |
- | 1 | - | STCRSE | RSE-Dämon, APF-autorisiert |
(a,g) 12 + 8u | - | (a) 1 | STCRSE | RSE-Thread-Pool mit Einzelthread-Miners |
(a,g) 12 + 19u | - | (a) 1 | STCRSE | RSE-Thread-Pool, mit Multithread-Miners |
- | (a) 1 | - | STCRSE | RSE-Thread-Pool, APF-autorisiert |
- | (b) 4u | (b) 1u | <Benutzer-ID> | ISPF Client Gateway (TSO Commands Service und SCLMDT) |
- | 2u | - | <Benutzer-ID> | TSO Commands Service (APPC) |
1u | 2u | - | STCRSE und <Benutzer-ID> | CARMA (batch) |
![]() ![]() |
2u | - | STCRSE und <Benutzer-ID> | CARMA (crastart) |
![]() ![]() ![]() ![]() |
![]() ![]() |
![]() ![]() |
![]() ![]() |
![]() ![]() |
5u | 4u | 3u | STCRSE und <Benutzer-ID> | CARMA (ispf, nicht weiter unterstützt) |
- | (c) 1u | 2u | <Benutzer-ID> | z/OS UNIX-Build (Shellbefehle) |
6u | 1u | - | STCRSE und <Benutzer-ID> | z/OS UNIX-Shell |
(d) 1 | - | - | STCRSE | Herunterladen |
(e) 1 | - | - | STCRSE | Suchen |
- | (5) | - | <Benutzer-ID> | SCLM Developer Toolkit |
1u | - | - | STCRSE | Zeitgeber für Inaktivitätszeitlimit |
X | SCLMDT | TSO über Client-Gateway | TSO über APPC | Zeitlimit |
---|---|---|---|---|
0 | Nein | Nein | Ja | Nein |
0 | Nein | Ja | Nein | Nein |
0 | Ja | Ja | Nein | Nein |
1 | Nein | Nein | Ja | Ja |
1 | Nein | Ja | Nein | Ja |
1 | Ja | Ja | Nein | Ja |
Y | |
---|---|
0 | Kein CARMA |
1 | CARMA (batch) |
![]() ![]() |
CARMA (crastart) |
![]() ![]() ![]() ![]() |
![]() ![]() |
5 | CARMA (ispf, nicht weiter unterstützt) |
Position | Begrenzung | Beeinträchtigte Ressourcen |
---|---|---|
OMVS-Segment | THREADSMAX | Begrenzt die Anzahl von Threads für eine Benutzer-ID |
BPXPRMxx | MAXTHREADS | Begrenzt die Anzahl von Threads in einem Prozess |
BPXPRMxx | MAXTHREADTASKS | Begrenzt die Anzahl von MVS-Tasks in einem Prozess |
BPXPRMxx | MAXASSIZE | Begrenzt die Größe des Adressraums und damit den verfügbaren Speicher für threadbezogene Steuerblöcke |
rsed.envvars | Xmx | Legt die maximale Größe des Java-Heapspeichers fest. Dieser Speicher ist reserviert und deshalb nicht mehr für threadbezogene Steuerblöcke verfügbar. |
rsed.envvars | maximum.clients | Begrenzt die Anzahl von Clients (und damit ihre Threads) in einem RSE-Thread-Pool |
rsed.envvars | maximum.threads | Begrenzt die Anzahl von Client-Threads in einem RSE-Thread-Pool |
FEJJCNFG | MAX_THREADS | Begrenzt die Anzahl von Threads in JES Job Monitor |
Die in den vorigen Abschnitten dokumentierte Ressourcennutzung ist permanent für die Lebensdauer von Developer for System z oder semipermanent für bestimmte benutzerspezifische Tasks.
Threads |
Benutzer-ID | Beschreibung | ||
---|---|---|---|---|
RSEDx | Aktiv | Booten | ||
- | (f) 3 + 1u | - | STCJMON | JES Job Monitor |
- | 4 | - | STCDBM | Debug Manager |
- | 14 | 2 | STCRSE | RSE-Dämon |
- | 1 | - | STCRSE | RSE-Dämon, APF-autorisiert |
(a,g) 12 + 8u | - | (a) 1 | STCRSE | RSE-Thread-Pool mit Einzelthread-Miners |
(a,g) 12 + 19u | - | (a) 1 | STCRSE | RSE-Thread-Pool, mit Multithread-Miners |
- | (a) 1 | - | STCRSE | RSE-Thread-Pool, APF-autorisiert |
- | (b) 4u | (b) 1u | <Benutzer-ID> | ISPF Client Gateway (TSO Commands Service und SCLMDT) |
- | 2u | - | <Benutzer-ID> | TSO Commands Service (APPC) |
1u | 2u | - | STCRSE und <Benutzer-ID> | CARMA (batch) |
![]() ![]() |
2u | - | STCRSE und <Benutzer-ID> | CARMA (crastart) |
![]() ![]() ![]() ![]() |
![]() ![]() |
![]() ![]() |
![]() ![]() |
![]() ![]() |
5u | 4u | 3u | STCRSE und <Benutzer-ID> | CARMA (ispf, nicht weiter unterstützt) |
- | (c) 1u | 2u | <Benutzer-ID> | z/OS UNIX-Build (Shellbefehle) |
6u | 1u | - | STCRSE und <Benutzer-ID> | z/OS UNIX-Shell |
(d) 1 | - | - | STCRSE | Herunterladen |
(e) 1 | - | - | STCRSE | Suchen |
- | (5) | - | <Benutzer-ID> | SCLM Developer Toolkit |
1u | - | - | STCRSE | Zeitgeber für Inaktivitätszeitlimit |
X | SCLMDT | TSO über Client-Gateway | TSO über APPC | Zeitlimit |
---|---|---|---|---|
0 | Nein | Nein | Ja | Nein |
0 | Nein | Ja | Nein | Nein |
0 | Ja | Ja | Nein | Nein |
1 | Nein | Nein | Ja | Ja |
1 | Nein | Ja | Nein | Ja |
1 | Ja | Ja | Nein | Ja |
Y | |
---|---|
0 | Kein CARMA |
1 | CARMA (batch) |
![]() ![]() |
CARMA (crastart) |
![]() ![]() ![]() ![]() |
![]() ![]() |
5 | CARMA (ispf, nicht weiter unterstützt) |
Position | Begrenzung | Beeinträchtigte Ressourcen |
---|---|---|
OMVS-Segment | THREADSMAX | Begrenzt die Anzahl von Threads für eine Benutzer-ID |
BPXPRMxx | MAXTHREADS | Begrenzt die Anzahl von Threads in einem Prozess |
BPXPRMxx | MAXTHREADTASKS | Begrenzt die Anzahl von MVS-Tasks in einem Prozess |
BPXPRMxx | MAXASSIZE | Begrenzt die Größe des Adressraums und damit den verfügbaren Speicher für threadbezogene Steuerblöcke |
rsed.envvars | Xmx | Legt die maximale Größe des Java-Heapspeichers fest. Dieser Speicher ist reserviert und deshalb nicht mehr für threadbezogene Steuerblöcke verfügbar. |
rsed.envvars | maximum.clients | Begrenzt die Anzahl von Clients (und damit ihre Threads) in einem RSE-Thread-Pool |
rsed.envvars | maximum.threads | Begrenzt die Anzahl von Client-Threads in einem RSE-Thread-Pool |
FEJJCNFG | MAX_THREADS | Begrenzt die Anzahl von Threads in JES Job Monitor |
RSE ist eine Java-Anwendung, was bedeutet, dass bei der Planung der Speicherbelegung für Developer for System z zwei Speicherzuordnungsbegrenzungen berücksichtigt werden müssen: eine für die Größe des Java-Heapspeichers und eine für die Größe der Adressräume.
Java bietet viele Services für die einfache Durchführung von Codierungsaufgaben für Java-Anwendungen an. Einer dieser Services betrifft die Speicherverwaltung.
Die Speicherverwaltung von Java reserviert große Speicherblöcke und verwendet diese für Speicheranforderungen der Anwendung. Dieser von Java verwaltete Speicher wird als Java-Heapspeicher bezeichnet. Die periodische Garbage-Collection (Defragmentierung) gibt nicht verwendeten Speicherplatz im Heapspeicher wieder frei und reduziert die Größe des Heapspeichers. Beachten Sie, dass zur Speicherung von CPU-Zyklen die Garbage-Collection tendenziell wartet, bis der belegte Speicher tatsächlich gebraucht wird; daher bleibt Speicher, der nicht mehr verwendet wird, länger zugeordnet als absolut notwendig (und wird somit ausgelagert).
Die maximale Größe des Java-Heapspeichers wird in rsed.envvars mit der Anweisung Xmx definiert. Wenn diese Anweisung nicht angegeben ist, verwendet Java eine Standardgröße von 512 MB. Sie müssen einen Wert von 256 MB oder höher angeben. Bei der Ausführung im 64-Bit-Modus versucht Java, den Heapspeicher über der 2-GB-Grenze zuzuordnen, wodurch Speicher unterhalb der Grenze freigegeben wird.
Jeder RSE-Thread-Pool (der die Clientaktionen bedient) ist eine separate Java-Anwendung und verfügt deshalb über einen eigenen Java-Heapspeicher. Beachten Sie, dass alle Thread-Pools dieselbe Konfigurationsdatei rsed.envvars verwenden und deshalb dieselbe Begrenzung für die Größe des Java-Heapspeichers gilt.
Die Belegung des Java-Heapspeichers durch den Thread-Pool hängt stark von den Aktionen der verbundenen Clients ab. Eine regelmäßige Überwachung der Belegung des Heapspeichers ist erforderlich, um die optimale Begrenzung der Größe des Heapspeichers festlegen zu können. Verwenden Sie den Bedienerbefehl modify display process, um die Belegung des Java-Heapspeichers durch die RSE-Thread-Pools zu überwachen.
Alle z/OS-Anwendungen, einschließlich Java-Anwendungen sind innerhalb eines Adressraums aktiv und deshalb an die Begrenzungen für die Adressraumgröße gebunden.
RSE-Thread-Pools übernehmen die Begrenzungen für die Adressraumgröße von dem RSE-Dämon. Die Adressraumgröße muss für den Java-Heapspeicher, für Java selbst, allgemeine Speicherbereiche und alle Steuerblöcke ausreichen, die das System zur Unterstützung der Thread-Pool-Aktivität erstellt, beispielsweise ein Tasksteuerblock (TBC) pro Thread. Beachten Sie, dass einige dieser Speicher nur 16 MB groß sind. Bei der Ausführung im 64-Bit-Modus versucht Java, den Heapspeicher über der 2-GB-Grenze zuzuordnen, wodurch Speicher unterhalb der Grenze freigegeben wird.
Sie sollten die eigentliche Adressraumgröße überwachen, bevor Sie Änderungen an Einstellungen vornehmen, die diese Größe beeinflussen. Dazu gehört beispielsweise das Ändern der Größe des Java-Heapspeichers oder das Ändern der Anzahl der Benutzer, die durch einen Einzel-Thread-Pool unterstützt werden. Verwenden Sie Ihre normale Systemüberwachungssoftware, um die eigentliche Speicherbelegung von Developer for System z zu verfolgen. Wenn Sie über kein zugeordnetes Überwachungstool verfügen, können Basisinformationen mit Tools wie der SDSF DA-Ansicht oder TASID (Systeminformationstool ohne Wartung (auf "as-is"-Basis), über die ISPF-Webseite "Support and downloads" verfügbar) zusammengestellt werden.
Beachten Sie, dass RSE die aktuelle Größe des Java-Heapspeichers und des Adressraums während des Systemstarts in der Konsolennachricht 'FEK004I' anzeigt.
Als Referenz sehen Sie in Tabelle 33 die Werte, die von aktuellen Developer for System z-Kunden für die zentralen rsed.envvars-Einstellungen verwendet werden, die sich auf die Speicherbelegung auswirken.
xmx (maximaler Java-Heapspeicher) | maximum.clients | Primärtyp der Entwicklung |
---|---|---|
512 MB | 30 | PL/I |
512 MB | 10 | COBOL |
384 MB | 12 | COBOL |
800 MB (64-Bit) | 20 | Keine Angabe |
Max Heap Size=10MB and private AS Size=1,959MB
startup
BPXM023I (STCRSE)
ProcessId(268 ) Memory Usage(7%) Clients(0)
Jobname Cpu time Storage EXCP
-------- ----------- ------- ----------
JMON 0.01 2740 72
RSED 4.47 32.8M 15910
RSED8 1.15 27.4M 12612
logon 1
BPXM023I (STCRSE)
ProcessId(268 ) Memory Usage(13%) Clients(1)
Jobname Cpu time Storage EXCP
-------- ----------- ------- ----------
JMON 0.01 2864 81
RSED 4.55 32.8M 15980
RSED8 3.72 55.9M 24128
logon 2
BPXM023I (STCRSE)
ProcessId(268 ) Memory Usage(23%) Clients(2)
Jobname Cpu time Storage EXCP
-------- ----------- ------- ----------
JMON 0.02 2944 86
RSED 4.58 32.9M 16027
RSED8 4.20 57.8M 25205
logon 3
BPXM023I (STCRSE)
ProcessId(268 ) Memory Usage(37%) Clients(3)
Jobname Cpu time Storage EXCP
-------- ----------- ------- ----------
JMON 0.02 3020 91
RSED 4.60 32.9M 16076
RSED8 4.51 59.6M 26327
logon 4
BPXM023I (STCRSE)
ProcessId(268 ) Memory Usage(41%) Clients(4)
Jobname Cpu time Storage EXCP
-------- ----------- ------- ----------
JMON 0.02 3108 96
RSED 4.61 32.9M 16125
RSED8 4.77 62.3M 27404
logon 5
BPXM023I (STCRSE)
ProcessId(268 ) Memory Usage(41%) Clients(4)
ProcessId(33554706) Memory Usage(13%) Clients(1)
Jobname Cpu time Storage EXCP
-------- ----------- ------- ----------
JMON 0.03 3184 101
RSED 4.64 32.9M 16229
RSED8 4.78 62.4M 27413
RSED9 4.60 56.6M 24065
Max Heap Size=10MB and private AS Size=1,959MB
startup
BPXM023I (STCRSE)
ProcessId(212 ) Memory Usage(7%) Clients(0)
Jobname Cpu time Storage EXCP
-------- ----------- ------- ----------
JMON 0.01 2736 71
RSED 4.35 32.9M 15117
RSED8 1.43 27.4M 12609
logon
BPXM023I (STCRSE)
ProcessId(212 ) Memory Usage(13%) Clients(1)
Jobname Cpu time Storage EXCP
-------- ----------- ------- ----------
JMON 0.01 2864 80
RSED 4.48 33.0M 15187
RSED8 3.53 53.9M 24125
expand large MVS tree (195 data sets)
BPXM023I (STCRSE)
ProcessId(212 ) Memory Usage(13%) Clients(1)
Jobname Cpu time Storage EXCP
-------- ----------- ------- ----------
JMON 0.01 2864 80
RSED 4.58 33.1M 16094
RSED8 4.28 56.1M 24740
expand small PDS (21 members)
BPXM023I (STCRSE)
ProcessId(212 ) Memory Usage(13%) Clients(1)
Jobname Cpu time Storage EXCP
-------- ----------- ------- ----------
IBMUSER2 0.22 2644 870
JMON 0.01 2864 80
RSED 4.61 33.1M 16108
RSED8 4.40 56.2M 24937
open medium sized member (86 lines)
BPXM023I (STCRSE)
ProcessId(212 ) Memory Usage(13%) Clients(1)
Jobname Cpu time Storage EXCP
-------- ----------- ------- ----------
IBMUSER2 0.22 2644 870
JMON 0.01 2864 80
RSED 4.61 33.1M 16108
RSED8 8.12 62.7M 27044
Die meisten Daten mit Bezug auf Developer for System z, die nicht in eine DD-Anweisung geschrieben werden, werden in einer z/OS UNIX-Datei gespeichert. Der Systemprogrammierer steuert, welche Daten an welcher Position gespeichert werden. Er hat allerdings keine Kontrolle über die gespeicherte Datenmenge.
Standardmäßig werden nur Fehlernachrichten und Warnungen in den Protokollen gespeichert. Bei einem ordnungsgemäßen Betrieb sollten diese Verzeichnisse also nur leere oder beinahe leere Dateien enthalten. (Prüfprotokolle werden dabei nicht berücksichtigt.)
Sie können das Protokollieren von Informationsnachrichten aktivieren (am besten nur auf Anweisung des IBM Support Center), wodurch die Größe der Protokolldateien deutlich zunimmt.
startup
$ ls -l /var/rdz/logs/server
total 144
-rw-rw-rw- 1 STCRSE STCGRP 33642 Jul 10 12:10 rsedaemon.log
-rw-rw-rw- 1 STCRSE STCGRP 1442 Jul 10 12:10 rseserver.log
logon
$ ls -l /var/rdz/logs/server
total 144
-rw------- 1 STCRSE STCGRP 36655 Jul 10 12:11 rsedaemon.log
-rw------- 1 STCRSE STCGRP 1893 Jul 10 12:11 rseserver.log
$ ls -l /var/rdz/logs/IBMUSER
total 160
-rw------- 1 IBMUSER SYS1 3459 Jul 10 12:11 ffs.log
-rw------- 1 IBMUSER SYS1 0 Jul 10 12:11 ffsget.log
-rw------- 1 IBMUSER SYS1 0 Jul 10 12:11 ffsput.log
-rw------- 1 IBMUSER SYS1 303 Jul 10 12:11 ffslock.log
-rw------- 1 IBMUSER SYS1 7266 Jul 10 12:11 rsecomm.log
logoff
$ ls -l /var/rdz/logs/server
total 80
-rw------- 1 STCRSE STCGRP 36655 Jul 10 12:11 rsedaemon.log
-rw------- 1 STCRSE STCGRP 2208 Jul 10 12:11 rseserver.log
$ ls -l /var/rdz/logs/IBMUSER
total 296
-rw------- 1 IBMUSER SYS1 6393 Jul 10 12:11 ffs.log
-rw------- 1 IBMUSER SYS1 0 Jul 10 12:11 ffsget.log
-rw------- 1 IBMUSER SYS1 0 Jul 10 12:11 ffsput.log
-rw------- 1 IBMUSER SYS1 609 Jul 10 12:11 ffslock.log
-rw------- 1 IBMUSER SYS1 45157 Jul 10 12:11 rsecomm.log
stop
$ ls -l /var/rdz/logs/server
total 80
-rw------- 1 STCRSE STCGRP 36655 Jul 10 12:11 rsedaemon.log
-rw------- 1 STCRSE STCGRP 2490 Jul 10 12:12 rseserver.log
Mit Ausnahme von Prüfprotokollen werden Protokolldateien bei jedem Neustart (bei der gestarteten RSE-Task) oder bei jeder Anmeldung (bei einem Client) überschrieben. Dadurch wird die Gesamtgröße begrenzt. Prüfprotokolle werden nach Ablauf des in audit.retention.period angegebenen Intervalls entfernt. Durch die Anweisung keep.last.log in rsed.envvars wird dies geringfügig geändert. Aufgrund dieser Anweisung kann RSE eine Kopie der vorherigen Protokolle beibehalten. Ältere Kopien werden immer gelöscht.Wenn die Direktive keep.all.logs in rsed.envvars aktiviert ist, wird allen Protokollnamen eine Zeitmarke angehängt und die Dateien werden nach Ablauf des in log.retention.period angegebenen Intervalls entfernt.
Wenn im Dateisystem mit den Protokolldateien nur noch ein kleiner freier Speicherbereich verfügbar ist, wird eine Warnung an die Konsole gesendet. Diese Konsolennachricht (FEK103E) wird immer wieder angezeigt, bis das Speicherproblem gelöst ist. Wenn für das Dateisystem der Speicherplatz zu gering wird, versucht RSE, vorhandene Protokolldateien zu löschen, um Speicherplatz freizugeben. Prüfprotokolle sind von diesem Prozess nicht betroffen.
Position | Anweisung | Funktion |
---|---|---|
resecomm.properties | debug_level | Standardprotokolldetailstufe festlegen |
rsecomm.properties | BENUTZER | Einstellung 'debug_level 2' für angegebene Benutzer aktivieren |
rsed.envvars | keep.all.logs | Eine Kopie der vorherigen Protokolle vor Start/Anmeldung beibehalten |
rsed.envvars | keep.last.log | Eine Kopie der vorherigen Protokolle vor Start/Anmeldung beibehalten |
rsed.envvars | enable.audit.log | Prüftrace der Clientaktionen beibehalten |
rsed.envvars | enable.standard.log | Datenströme 'stdout' und 'stderr' des (bzw. der) Thread-Pools in eine Protokolldatei schreiben |
rsed.envvars | DSTORE_TRACING_ON | DataStore-Aktionsprotokollierung aktivieren |
rsed.envvars | DSTORE_MEMLOGGING_ON | DataStore-Protokollierung der Speicherbelegung aktivieren |
Bedienerbefehl | modify rsecommlog <Stufe> | Die Protokolldetailstufe von rsecomm.log dynamisch ändern |
Bedienerbefehl | modify rsedaemonlog <Stufe> | Die Protokolldetailstufe von rsedaemon.log dynamisch ändern |
Bedienerbefehl | modify rseserverlog <Stufe> | Die Protokolldetailstufe von rseserver.log dynamisch ändern |
Bedienerbefehl | modify rsestandardlog {on|off} | Die Aktualisierung von std*.*.log dynamisch ändern |
Bedienerbefehl | modify trace {on|off} USER=userid | Einstellung 'debug_level 2' für angegebene Benutzer aktivieren |
Bedienerbefehl | modify trace {on|off} SERVER=pid | Einstellung 'debug_level 2' für angegebene Benutzer aktivieren |
Bedienerbefehl | modify trace clear | Trace-Konfiguration inaktivieren |
Bedienerbefehl | modify logs | Hostprotokolle und Konfigurationsdaten erfassen |
rsed.envvars | daemon.log | Ausgangspfad für gestartete RSE-Task und Prüfprotokolle |
rsed.envvars | user.log | Ausgangspfad für Benutzerprotokolle |
rsed.envvars | CGI_ISPWORK | Ausgangspfad für Protokolle von ISPF Client Gateway |
rsed.envvars | TMPDIR | Verzeichnis für IVP-Protokolle und Bedienerbefehl modify logs |
rsed.envvars | _CEE_DMPTARG | Verzeichnis für Java-Speicherauszüge |
Zusammen mit vorausgesetzter Software wie dem ISPF-Client-Gateway schreibt Developer for System z auch temporäre Daten in /tmp und /var/rdz/WORKAREA. Das hier geschriebene Datenvolumen ist unvorhersehbar. In den Dateisystemen, in denen sich diese Verzeichnisse befinden, sollten Sie daher ausreichend freien Speicherbereich haben.
Developer for System z versucht stets, diese temporären Dateien zu bereinigen. Eine manuelle Bereinigung, wie im Abschnitt "Bereinigung von WORKAREA und /tmp (optional)" in the Hostkonfiguration (IBM Form SC12-4062) dokumentiert, kann jedoch quasi jederzeit durchgeführt werden.
Position | Anweisung | Funktion |
---|---|---|
rsed.envvars | CGI_ISPWORK | Ausgangspfad für temporäre Daten |
rsed.envvars | TMPDIR | Verzeichnis für temporäre Daten |
Die in rsed.envvars definierten Umgebungsvariablen werden von RSE, Java und z/OS UNIX verwendet. Die mit Developer for System z gelieferte Beispieldatei ist für kleine bis mittlere Installationen gedacht, für die keine der optionalen Komponenten von Developer for System z benötigt werden. Im Abschnitt "rsed.envvars (RSE-Konfigurationsdatei)" im Handbuch Hostkonfiguration (IBM Form SC12-4062) werden alle Variablen beschrieben, die in der Beispieldatei definiert sind. Bei den folgenden Variablen müssen Sie allerdings besonders vorsichtig sein:
RSE ist eine Java-Anwendung, das heißt, sie ist in der z/OS UNIX-Umgebung aktiv. Auf diese Weise wird BPXPRMxx ein entscheidendes PARMLIB-Member, weil es die Parameter enthält, mit denen die z/OS UNIX-Umgebung und die Dateisysteme gesteuert werden. BPXPRMxx wird in MVS Initialization and Tuning Reference (IBM Form SA22-7592) beschrieben. Die folgenden Anweisungen wirken sich bekannterweise auf Developer for System z aus:
Wertebereich: 'nnnnn' ist ein Dezimalwert zwischen 5 und 32767.
Standardwert: 900
Wertebereich: 'nnnnn' ist ein Dezimalwert zwischen 3 und 32767.
Standardwert: 25
Wertebereich: 'nnnnnn' ist ein Dezimalwert zwischen 0 und 100.000.
Standardwert: 200
Wertebereich: 'nnnnn' ist ein Dezimalwert zwischen 0 und 32768.
Standardwert: 1000
Wertebereich: 'nnnnn' ist ein Dezimalwert zwischen 1 und 32767.
Standardwert: 200
Wertebereich: 'nnnnn' ist ein Dezimalwert zwischen 10.485.760 (10 Megabyte)
und 2.147.483.647 (2 Gigabyte).
Standardwert: 209.715.200 (200 Megabyte)
Wertebereich: 'nnnnnn' ist ein Dezimalwert zwischen 3 und 524.287.
Standardwert: 64000
Wertebereich: 'nnnnn' ist ein Dezimalwert zwischen 1 und 16.777.216.
Standardwert: 40960
Verwenden Sie den Bedienerbefehl SETOMVS oder SET OMVS, um den Wert einer beliebigen genannten BPXPRMxx-Variablen dynamisch (bis zum nächsten einleitenden Programmladen) zu erhöhen oder zu verringern. Wenn Sie eine permanente Änderung wünschen, bearbeiten Sie das BPXPRMxx-Member, das für IPLs verwendet wird. Weitere Informationen zu diesen Bedienerbefehlen enthält die Veröffentlichung MVS System Commands (IBM Form SA22-7627).
Die folgenden Definitionen sind Subparameter der Anweisung NETWORK.
Wertebereich: 'nnnnnnnn' ist ein Dezimalwert zwischen 0 und 16.777.215.
Standardwert: 100
Wertebereich: 'nnnn' ist ein Dezimalwert zwischen 1 und 4000.
Standardwert: Wenn weder INADDRANYPORT noch INADDRANYCOUNT
angegeben wurde, ist der Standardwert für INADDRANYCOUNT 1000.
Andernfalls werden keine (0) Ports reserviert.
Die folgenden Definitionen sollten der EXEC-Karte in der JCL des Servers für Developer for System z hinzugefügt werden.
Die in FEJJCNFG definierten Umgebungsvariablen werden von JES Job Monitor verwendet. Die mit Developer for System z gelieferte Beispieldatei ist für kleine bis mittlere Installationen gedacht. Im Abschnitt "FEJJCNFG (JES Job Monitor-Konfigurationsdatei)" im Handbuch Hostkonfiguration (IBM Form SC12-4062) werden alle Variablen beschrieben, die in der Beispieldatei definiert sind. Bei den folgenden Variablen müssen Sie allerdings besonders vorsichtig sein:
IEASYSxx wird in MVS Initialization and Tuning Reference (IBM Form SA22-7592) beschrieben. Die folgenden Anweisungen wirken sich bekannterweise auf Developer for System z aus:
Wertebereich: 'nnnnn' ist ein Dezimalwert zwischen 0 und 32767. Beachten Sie, dass
die Summe der für die Systemparameter MAXUSER, RSVSTRT
und RSVNONR angegebenen Werte 32767 nicht übersteigen kann.
Standardwert: 255
IVTPRMxx legt Parameter für den Kommunikationsspeichermanager (Communication Storage Manager, CSM) fest und wird in MVS Initialization and Tuning Reference (IBM Form SA22-7592) beschrieben. Die folgenden Anweisungen wirken sich bekannterweise auf Developer for System z aus:
Wertebereich: 'maxfix' ist ein Wert zwischen 1024K und 2048M.
Standardwert: 100M
Wertebereich: 'maxecsa' ist ein Wert zwischen 1024K und 2048M.
Standardwert: 100M
Das PARMLIB-Member ASCHPMxx enthält Planungsinformationen für den Transaktionsscheduler ASCH und wird in MVS Initialization and Tuning Reference (IBM Form SA22-7592) beschrieben. Die folgenden Anweisungen wirken sich bekannterweise auf Developer for System z aus:
Wertebereich: 'nnnnn' ist ein Dezimalwert zwischen 1 und 64000.
Standardwert: 1
Da sich der Bedarf an Systemressourcen durch die Benutzerarbeitslast ändern kann, sollte das System regelmäßig überwacht werden, um die Ressourcennutzung zu messen. So können Rational Developer for System z und die Systemkonfiguration entsprechend Ihren Benutzeranforderungen angepasst werden. Als Unterstützung bei diesem Überwachungsprozess können die folgenden Befehle verwendet werden.
FEK004I RseDaemon: Max Heap Size=65MB and private AS Size=1,959MB
f rsed,appl=d p
BPXM023I (STCRSE)
ProcessId(16777456) Memory Usage(33%) Clients(4) Order(1)
f rsed,appl=d p,detail
BPXM023I (STCRSE)
ProcessId(33555087) ASId(002E) JobName(RSED8) Order(1)
PROCESS LIMITS: CURRENT HIGHWATER LIMIT
JAVA HEAP USAGE(%) 10 56 100
CLIENTS 0 25 30
MAXFILEPROC 83 103 64000
MAXPROCUSER 97 99 200
MAXTHREADS 9 14 1500
MAXTHREADTASKS 9 14 1500
f rsed,appl=d p,cpu
BPXM023I (STCRSE)
ProcessId(33555087) ASId(002E) JobName(RSED8) Order(1)
USERID THREAD-ID TCB@ ACC_TIME TAG
STCRSE 0EDE540000000000 005E6B60 822 1/ThreadPoolProcess
STCRSE 0EDE870000000001 005E69C8 001
STCRSE 0EDE980000000002 005E6518 1814
STCRSE 0EDEBA0000000003 005E66B0 2305
STCRSE 0EDECB0000000004 005E62F8 001
STCRSE 0EDEDC0000000005 005E60D8 001
STCRSE 0EDF860000000006 005C2BF8 628 6/ThreadPoolMonitor$Memory
UsageMonitor
STCRSE 0EDF970000000007 005C2D90 003 7/ThreadPoolMonitor
IBMUSER 0EE2C70000000024 005C08B0 050 38/JESMiner
IBMUSER 0EE2B60000000026 005C0690 004 40/FAMiner
IBMUSER 0EE30B0000000027 005C0250 002 41/LuceneMiner
IBMUSER 0EE31C0000000028 005C0030 002 42/CDTParserMiner
IBMUSER 0EE32D0000000029 005BDE00 002 43/MVSLuceneMiner
IBMUSER 0EE33E000000002A 005BDBE0 002 44/CDTMVSParserMiner
Die meisten z/OS UNIX-Begrenzungen, die für Developer for System z wichtig sind, können mithilfe von Bedienerbefehlen angezeigt werden. Mit einigen Befehlen wird sogar die aktuelle Verwendung und die obere Grenze für einen bestimmten Grenzwert angezeigt. Weitere Informationen zu diesen Befehlen enthält die Veröffentlichung MVS System Commands (IBM Form SA22-7627).
d omvs,o
BPXO043I 13.10.16 DISPLAY OMVS 066
OMVS 000D ETC/INIT WAIT OMVS=(M7)
CURRENT UNIX CONFIGURATION SETTINGS:
MAXPROCSYS = 256 MAXPROCUSER = 16
MAXFILEPROC = 256 MAXFILESIZE = NOLIMIT
MAXCPUTIME = 1000 MAXUIDS = 200
MAXPTYS = 256
MAXMMAPAREA = 256 MAXASSIZE = 209715200
MAXTHREADS = 200 MAXTHREADTASKS = 1000
MAXCORESIZE = 4194304 MAXSHAREPAGES = 4096
IPCMSGQBYTES = 2147483647 IPCMSGQMNUM = 10000
IPCMSGNIDS = 500 IPCSEMNIDS = 500
IPCSEMNOPS = 25 IPCSEMNSEMS = 1000
IPCSHMMPAGES = 25600 IPCSHMNIDS = 500
IPCSHMNSEGS = 500 IPCSHMSPAGES = 262144
SUPERUSER = BPXROOT FORKCOPY = COW
STEPLIBLIST =
USERIDALIASTABLE=
SERV_LINKLIB = POSIX.DYNSERV.LOADLIB BPXLK1
SERV_LPALIB = POSIX.DYNSERV.LOADLIB BPXLK1
PRIORITYPG VALUES: NONE
PRIORITYGOAL VALUES: NONE
MAXQUEUEDSIGS = 1000 SHRLIBRGNSIZE = 67108864
SHRLIBMAXPAGES = 4096 VERSION = /
SYSCALL COUNTS = NO TTYGROUP = TTY
SYSPLEX = NO BRLM SERVER = N/A
LIMMSG = NONE AUTOCVT = OFF
RESOLVER PROC = DEFAULT
AUTHPGMLIST = NONE
SWA = BELOW
d omvs,l
BPXO051I 14.05.52 DISPLAY OMVS 904
OMVS 0042 ACTIVE OMVS=(69)
SYSTEM WIDE LIMITS: LIMMSG=SYSTEM
CURRENT HIGHWATER SYSTEM
USAGE USAGE LIMIT
MAXPROCSYS 1 4 256
MAXUIDS 0 0 200
MAXPTYS 0 0 256
MAXMMAPAREA 0 0 256
MAXSHAREPAGES 0 10 4096
IPCMSGNIDS 0 0 500
IPCSEMNIDS 0 0 500
IPCSHMNIDS 0 0 500
IPCSHMSPAGES 0 0 262144 *
IPCMSGQBYTES --- 0 262144
IPCMSGQMNUM --- 0 10000
IPCSHMMPAGES --- 0 256
SHRLIBRGNSIZE 0 0 67108864
SHRLIBMAXPAGES 0 0 4096
Wenn zusätzlich das Schlüsselwort PID=processid angegeben wird, zeigt der Befehl die oberen Grenzen und die aktuelle Verwendung für einen einzelnen Prozess an.
d,omvs,l,pid=16777456
BPXO051I 14.06.28 DISPLAY OMVS 645
OMVS 000E ACTIVE OMVS=(76)
USER JOBNAME ASID PID PPID STATE START CT_SECS
STCRSE RSED8 007E 16777456 67109106 HF---- 20.00.56 113.914
LATCHWAITPID= 0 CMD=java -Ddaemon.log=/var/rdz/logs -
PROCESS LIMITS: LIMMSG=NONE
CURRENT HIGHWATER PROCESS
USAGE USAGE LIMIT
MAXFILEPROC 83 103 256
MAXFILESIZE --- --- NOLIMIT
MAXPROCUSER 97 99 200
MAXQUEUEDSIGS 0 1 1000
MAXTHREADS 9 14 200
MAXTHREADTASKS 9 14 1000
IPCSHMNSEGS 0 0 500
MAXCORESIZE --- --- 4194304
MAXMEMLIMIT 0 0 16383P
d omvs,p
BPXO046I 14.35.38 DISPLAY OMVS 092
OMVS 000E ACTIVE OMVS=(33)
PFS CONFIGURATION INFORMATION
PFS TYPE DESCRIPTION ENTRY MAXSOCK OPNSOCK HIGHUSED
TCP SOCKETS AF_INET EZBPFINI 50000 244 8146
UDS SOCKETS AF_UNIX BPXTUINT 64 6 10
ZFS LOCAL FILE SYSTEM IOEFSCM
14:32.00 RECYCLING
HFS LOCAL FILE SYSTEM GFUAINIT
BPXFTCLN CLEANUP DAEMON BPXFTCLN
BPXFTSYN SYNC DAEMON BPXFTSYN
BPXFPINT PIPE BPXFPINT
BPXFCSIN CHAR SPECIAL BPXFCSIN
NFS REMOTE FILE SYSTEM GFSCINIT
PFS NAME DESCRIPTION ENTRY STATUS FLAGS
TCP41 SOCKETS EZBPFINI ACT CD
TCP42 SOCKETS EZBPFINI ACT
TCP43 SOCKETS EZBPFINI INACT SD
TCP44 SOCKETS EZBPFINI INACT
PFS PARM INFORMATION
HFS SYNCDEFAULT(60) FIXED(50) VIRTUAL(100)
CURRENT VALUES: FIXED(55) VIRTUAL(100)
NFS biod(6)
d omvs,pid=16777456
BPXO040I 15.30.01 DISPLAY OMVS 637
OMVS 000E ACTIVE OMVS=(76)
USER JOBNAME ASID PID PPID STATE START CT_SECS
STCRSE RSED8 007E 16777456 67109106 HF---- 20.00.56 113.914
LATCHWAITPID= 0 CMD=java -Ddaemon.log=/var/rdz/logs -
THREAD_ID TCB@ PRI_JOB USERNAME ACC_TIME SC STATE
0E08A00000000000 005E6DF0 OMVS .927 RCV FU
0E08F00000000001 005E6C58 .001 PTX JYNV
0E09300000000002 005E6AC0 7.368 PTX JYNV
0E0CB00000000008 005C2CF0 OMVS 1.872 SEL JFNV
0E192000000003CE 005A0B70 OMVS IBMUSER 14.088 POL JFNV
0E18D000000003CF 005A1938 IBMUSER .581 SND JYNV
In Developer for System z werden z/OS UNIX-Dateisysteme verwendet, um verschiedene Datentypen (beispielsweise Protokolle und temporäre Dateien) zu speichern. Mit dem z/OS UNIX-Befehl df können Sie anzeigen, wie viele Dateideskriptoren noch verfügbar sind und wie viel freier Speicherbereich vor der Erstellung der nächsten Erweiterung der zugrunde liegenden HFS- oder zFS-Datei verfügbar ist.
$ df
Mounted on Filesystem Avail/Total Files Status
/tmp (OMVS.TMP) 1393432/1396800 4294967248 Available
/u/ibmuser (OMVS.U.IBMUSER) 1248/1728 4294967281 Available
/usr/lpp/rdz (OMVS.LPP.FEK) 3062/43200 4294967147 Available
/var (OMVS.VAR) 27264/31680 4294967054 Available
Developer for System z versucht standardmäßig, 30 Benutzer zu einem einzigen Thread-Pool hinzuzufügen. In den Anforderungen ist allerdings angegeben, dass die Zeitlimitüberschreitung aufgrund von Inaktivität aktiv ist. In Tabelle 31 sehen Sie, dass daher pro verbundenem Client ein Thread hinzugefügt wird. Dieser Thread ist ein Zeitgeberthread und somit ständig aktiv. So wird verhindert, dass RSE 30 Benutzer einem einzigen Thread-Pool hinzufügt (10+30*(17+1)=550) und maximum.threads ist standardmäßig auf 520 gesetzt.
Es wäre möglich, maximum.threads zu erhöhen. Weil laut Anforderung allerdings pro Benutzer ein durchschnittlicher Java-Heapspeicher von 20 MB bereitgestellt werden soll, wird maximum.clients auf 25 (10+25*18 = 460) verringert. Auf diese Weise (20*25 = 500) wird die standardmäßige maximale Größe des Java-Heapspeichers (512 MB) beachtet.
Mit 25 Clients pro Thread-Pool und der Anforderung zur Unterstützung von 500 Verbindungen werden somit 20 Thread-Pool-Adressräume benötigt.
3 + 2*A + N*(x + y + z) + (2 + N*0.01)
3 + 2*20 + 500*1 + 200*1 + 300*1 + (2 + 500*0.01) = 1050
x + y + z
1 + 1 + 1 = 3
6 + 3*A + N*(x + y + z) + (10 + N*0.05)
6 + 3*20 + 500*2 + 200*1 + 300*0 + (10 + 500*0.05) = 1591
4 + 3*A
4 + 3*20 = 64
(x + y + z) + 5*s
(2 + 1 + 0) + 5*0 = 3
12 + N*(19 + x + y + z) + (20 + N*0.1)
12 + 25*(19 + 1 + 4 + 0) + (20 + 25*0.1) = 635
3 + N+ (20 + N*0.1)
3 + 500+ (20 + 500*0.1) = 573
4
4
500 + 3 = 503
Die 3 zusätzlichen Benutzer-IDs werden für STCJMON, STCDBM und STCRSE benötigt, die Benutzer-IDs der gestarteten Developer for System z-Task.
nicht geändert
nicht geändert
Diese Änderung ist optional. RSE startet neue Thread-Pools, wenn erforderlich.
mindestens 1591, zusätzliche Puffer für Tasks hinzugefügt, die nicht zu
Developer
for System z
mindestens 64, zusätzliche Puffer hinzugefügt, falls die RSE-Thread-Pools weniger als die geplanten 25 Clients unterstützen
mindestens 573 (für JES Job Monitor), wenn THREADSMAX im OMVS-Segment der Benutzer-ID 'STCRSE' verwendet wird, um die Begrenzung für RSE festzulegen
(mindestens 635)
mindestens 573 (für JES Job Monitor), wenn THREADSMAX im OMVS-Segment der Benutzer-ID 'STCRSE' verwendet wird, um die Begrenzung für RSE festzulegen
(mindestens 635)
mindestens 503, zusätzliche Puffer für Tasks hinzugefügt, die nicht zu
Developer
for System z
nicht geändert (Systemstandardwert: 200 MB), ASSIZEMAX im OMVS-Segment
der Benutzer-ID 'STCRSE' wird verwendet
mindestens 1050, zusätzliche Puffer für Tasks hinzugefügt, die nicht zu
Developer
for System z
2 GB
Nachdem Sie die Systemgrenzwerte wie unter Grenzwerte definieren dokumentiert aktiviert haben, kann die Überwachung der Ressourcennutzung durch Developer for System z starten, um zu ermitteln, ob die Anpassung von Variablen erforderlich ist. Abbildung 31 zeigt die Ressourcennutzung, nachdem sich 499 Benutzer angemeldet haben. (Das Beispiel in der Abbildung zeigt nur die Anmeldung. Es sind keine Benutzeraktionen angegeben.)
F RSED,APPL=D P
BPXM023I (STCRSE)
ProcessId(83886168) Memory Usage(17%) Clients(25) Order(1)
ProcessId(91 ) Memory Usage(17%) Clients(25) Order(2)
ProcessId(122 ) Memory Usage(17%) Clients(25) Order(3)
ProcessId(16777348) Memory Usage(17%) Clients(25) Order(4)
ProcessId(16777358) Memory Usage(17%) Clients(25) Order(5)
ProcessId(16777368) Memory Usage(17%) Clients(25) Order(6)
ProcessId(16777378) Memory Usage(17%) Clients(25) Order(7)
ProcessId(16777388) Memory Usage(17%) Clients(25) Order(8)
ProcessId(16777398) Memory Usage(17%) Clients(25) Order(9)
ProcessId(33554622) Memory Usage(17%) Clients(25) Order(10)
ProcessId(16777416) Memory Usage(17%) Clients(25) Order(11)
ProcessId(16777426) Memory Usage(17%) Clients(25) Order(12)
ProcessId(16777436) Memory Usage(9%) Clients(25) Order(13)
ProcessId(16777446) Memory Usage(17%) Clients(25) Order(14)
ProcessId(16777456) Memory Usage(17%) Clients(25) Order(15)
ProcessId(16777466) Memory Usage(17%) Clients(25) Order(16)
ProcessId(16777476) Memory Usage(17%) Clients(25) Order(17)
ProcessId(16777487) Memory Usage(17%) Clients(25) Order(18)
ProcessId(16777497) Memory Usage(17%) Clients(25) Order(19)
ProcessId(16777507) Memory Usage(16%) Clients(24) Order(20)
F RSED,APPL=D P,D
BPXM023I (STCRSE)
ProcessId(83886168) ASId(0022) JobName(RSED857 ) Order(1)
PROCESS LIMITS: CURRENT HIGHWATER LIMIT
JAVA HEAP USAGE(%) 17 17 100
CLIENTS 25 25 25
MAXFILEPROC 365 366 64000
MAXPROCUSER 64 64 100
MAXTHREADS 362 363 1500
MAXTHREADTASKS 363 363 1500
TASID
Jobname Cpu time Storage EXCP
-------- ----------- ------- ----------
JMON 0.00 1780 73
RSED 5.88 95.2M 41958
RSED1 8.26 190.1M 58669
RSED1 8.17 187.0M 58605
RSED2 8.06 185.3M 58653
RSED2 8.19 183.1M 60209
RSED3 8.12 189.1M 58650
RSED3 8.03 186.7M 58590
RSED4 8.15 188.2M 58646
RSED4 5.50 182.5M 58585
RSED5 7.72 184.4M 58631
RSED5 7.82 184.1M 58576
RSED6 7.14 184.1M 58622
RSED6 6.27 186.9M 58583
RSED7 5.17 185.1M 58804
RSED7 6.57 185.2M 58621
RSED7 5.86 182.8M 58565
RSED8 0.36 1560 2459
RSED8 7.94 184.1M 58615
RSED8 7.45 181.8M 58548
RSED9 8.16 190.6M 58802
RSED9 7.62 183.8M 58610
RSED9 7.36 177.7M 57478
z/OS ist ein sehr anpassungsfähiges Betriebssystem, bei dem (manchmal kleine) Systemänderungen eine enorme Auswirkung auf die Gesamtleistung haben können. Dieses Kapitel hebt einige der Änderungen hervor, die zu einer Verbesserung der Leistung von Developer for System z führen können.
Weitere Informationen zur Systemoptimierung finden Sie im MVS Initialization and Tuning Guide (IBM Form SA22-7591) sowie in der Veröffentlichung UNIX System Services Planning (IBM Form GA22-7800).
Wenn Sie mehr über das zFS erfahren möchten, lesen Sie die Veröffentlichung UNIX System Services Planning (IBM Form GA22-7800).
Jeder z/OS UNIX-Prozess mit einer STEPLIB, die vom übergeordneten Element zum untergeordneten Element oder über eine Exec weitergegeben wird, belegt einen erweiterten allgemeinen Speicherbereich (ECSA, Extended Common Storage Area) von ca. 200 Bytes. Wenn die Umgebungsvariable STEPLIB nicht oder mit STEPLIB=CURRENT definiert ist, gibt z/OS UNIX alle aktiven TASKLIB-, STEPLIB- und JOBLIB-Zuordnungen während einer Funktion fork(), spawn() oder exec() weiter.
In rsed.envvars ist die Standardeinstellung für Developer for System z mit STEPLIB=NONE codiert. Lesen Sie hierzu die Beschreibung in der Konfigurationsdatei rsed.envvars. Aus den zuvor genannten Gründen sollten Sie diese Anweisung nicht ändern und die resultierenden Dateien stattdessen in die LINKLIST oder den LPA (Link-Pack-Bereich) stellen.
Bestimmte Systembibliotheken und Lademodule werden von z/OS UNIX und Aktivitäten der Anwendungsentwicklung besonders häufig verwendet. Wenn Sie den Zugriff auf diese Bibliotheken und Module verbessern, indem Sie sie beispielsweise zum Link-Pack-Bereich (LPA) hinzufügen, können Sie die Systemleistung steigern. Weitere Informationen zu den nachfolgend beschriebenen SYS1.PARMLIB-Membern enthält die Veröffentlichung MVS Initialization and Tuning Reference (IBM Form SA22-7592).
Wenn C-Programme (einschließlich der z/OS UNIX-Shell) ausgeführt werden, verwenden sie häufig Routinen aus der LE-Laufzeitbibliothek (Language Environment). Für jeden Adressraum, der ein LE-fähiges Programm ausführt, werden ungefähr 4 MB der Laufzeitbibliothek in den Speicher geladen und in jede Verzweigung kopiert.
CEE.SCEELPA
Die Datei CEE.SCEELPA enthält eine Untergruppe der LE-Laufzeitroutinen, die besonders oft von z/OS UNIX verwendet werden. Sie sollten diese Datei zu SYS1.PARMLIB(LPALSTxx) hinzufügen, um einen maximalen Leistungsgewinn zu erzielen. Wenn Sie dieser Empfehlung folgen, werden die Module nur einmal von der Platte gelesen und an einer gemeinsam genutzten Position gespeichert.
LPA ADD MASK(*) DSNAME(CEE.SCEELPA)
Außerdem sollten Sie die LE-Laufzeitbibliotheken CEE.SCEERUN und CEE.SCEERUN2 in die LINKLIST stellen, indem Sie die Dateien zu SYS1.PARMLIB(LNKLSTxx) oder SYS1.PARMLIB(PROGxx) hinzufügen. Auf diese Weise entfällt der z/OS UNIX-Systemaufwand für die STEPLIB und das Ein-/Ausgabevolumen verringert sich infolge der Verwaltung durch LLA und VLF oder ähnliche Produkte.
Wenn Sie sich entschließen, diese Bibliotheken nicht in die LINKLIST zu stellen, müssen Sie in der Datei rsed.envvars die entsprechende STEPLIB-Anweisung konfigurieren. Lesen Sie hierzu die Beschreibung in der Konfigurationsdatei rsed.envvars. Obwohl diese Methode immer zusätzlichen virtuellen Speicher verwendet, können Sie die Leistung verbessern, indem Sie die LE-Laufzeitbibliotheken für LLA oder ein ähnliches Produkt definieren. Dadurch werden die Ein-/Ausgaben reduziert, die für das Laden der Module erforderlich sind.
Auf Systemen, deren primäre Aktivität die Anwendungsentwicklung ist, kann auch eine Leistungsverbesserung erreicht werden, wenn der Linkage-Editor in den dynamischen LPA gestellt wird. Hierfür müssen die folgenden Zeilen zu SYS1.PARMLIB(PROGxx) hinzugefügt werden:
LPA ADD MODNAME(CEEBINIT,CEEBLIBM,CEEEV003,EDCZV) DSNAME(CEE.SCEERUN)
LPA ADD MODNAME(IEFIB600,IEFXB603) DSNAME(SYS1.LINKLIB)
Für die C/C++-Entwicklung können Sie außerdem die Compilerdatei CBC.SCCNCMP zu SYS1.PARMLIB(LPALSTxx) hinzufügen.
Die vorangehenden Anweisungen sind Beispiele für mögliche LPA-Kandidaten. Die Anforderungen an Ihrem Standort können jedoch andere Maßnahmen erfordern. Informationen zur Aufnahme anderer LE-Lademodule in den dynamischen LPA enthält die Veröffentlichung Language Environment Customization (IBM Form SA22-7564). Wie Lademodule von C/C++-Compilern in den dynamischen LPA gestellt werden, erfahren Sie in der Veröffentlichung UNIX System Services Planning (IBM Form GA22-7800).
An jedem Standort gelten ganz bestimmte Anforderungen. Das Betriebssystem z/OS kann so angepasst werden, dass die verfügbaren Ressourcen optimal genutzt werden, um diese Anforderungen zu erfüllen. Bei der Auslastungsverwaltung definieren Sie Leistungsziele und ordnen jedem dieser Ziele eine geschäftliche Bedeutung zu. Sie definieren Arbeitsziele mit Geschäftsbegriffen, und das System entscheidet, wie viele Ressourcen (z. B. CPU und Speicher) der Arbeit zugeordnet werden müssen, um das angestrebte Ziel zu erreichen.
Indem Sie für die Prozesse von Developer for System z die richtigen Ziele festlegen, können Sie für eine ausgeglichene Leistung des Produkts sorgen. Nachfolgend sind dazu einige allgemeine Richtlinien aufgelistet.
Weitere Informationen zu diesem Thema finden Sie in der Veröffentlichung MVS Planning Workload Management (IBM Form SA22-7602).
Bei einem Heapspeicher fester Größe gibt es keine Erweiterung oder Verkleinerung, was in bestimmten Situationen zu einer deutlichen Leistungssteigerung führen kann. Generell ist die Verwendung eines Heapspeichers mit fester Größe jedoch keine gute Idee, weil sie den Start der Garbage-Collection hinauszögert, bis der Heapspeicher voll ist. Die dann ausgeführte Garbage-Collection ist dementsprechend umfangreich. Außerdem steigt das Fragmentierungsrisiko, sodass eine Heapkomprimierung erforderlich ist. Heapspeicher mit fester Größe sollten Sie daher nur nach gründlichen Tests bzw. unter Anleitung des IBM Support Center verwenden. Weitere Informationen zu Heapgrößen und Garbage-Collections enthält der Java Diagnostics Guide (IBM Form SC34-6650).
Die anfängliche und die maximale Größe des Heapspeichers einer z/OS Java Virtual Machine (JVM) können mit den Java-Befehlszeilenoptionen -Xms (Anfangsgröße) und -Xmx (maximale Größe) gesetzt werden.
In Developer for System z sind Java-Befehlszeilenoptionen in der Steueranweisung _RSE_JAVAOPTS der Datei rsed.envvars definiert. Eine diesbezügliche Beschreibung finden Sie im Abschnitt "Zusätzliche Java-Startparameter mit _RSE_JAVAOPTS definieren" in Hostkonfiguration (IBM Form SC12-4062).
#_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Xms128m -Xmx128m"
Mit der Option -Xquickstart kann die Startzeit einiger Java-Anwendungen verbessert werden. -Xquickstart bewirkt die teiloptimierte Ausführung des JIT-Compilers und ermöglicht so eine schnelle Kompilierung. Durch diese schnelle Kompilierung wird wiederum die Startzeit verkürzt.
Die Option '-Xquickstart' ist für Anwendungen geeignet, die eine kurze Laufzeit haben, insbesondere für jene, bei denen sich die Ausführungszeit nicht nur auf einige Methoden konzentriert. Die Option -Xquickstart kann den Durchsatz verringern, wenn sie für Anwendungen genutzt wird, die eine lange Laufzeit haben und häufig verwendete Methoden enthalten.
_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Xquickstart"
Die IBM Java Virtual Machine (JVM) bietet ab Version 5 die Möglichkeit, dass JVMs die Bootstrap-Klassen und Anwendungsklassen gemeinsam nutzen können, indem sie sie in einem Cache innerhalb des gemeinsam genutzten Speichers ablegt. Bei der gemeinsamen Nutzung von Klassen verwenden mehrere JVMs einen Cache gemeinsam, sodass insgesamt weniger virtueller Speicher belegt wird. Die gemeinsame Klassennutzung verkürzt außerdem die Startzeit für eine JVM, nachdem der Cache erstellt wurde.
Der Cache für gemeinsam genutzte Klassen ist von den aktiven JVMs unabhängig und bleibt über die Lebensdauer der JVM hinweg bestehen, die den Cache erstellt hat. Da der Cache für gemeinsam genutzte Klassen länger bestehen bleibt als jede JVM, wird er durch dynamische Aktualisierungen an alle Änderungen angepasst, die ggf. an JARs oder Klassen im Dateisystem vorgenommen wurden.
Der Systemaufwand für das Erstellen eines neuen Cache und das Füllen des Cache mit Daten ist minimal. Das Starten einer einzelnen JVM dauert im Vergleich zur gemeinsamen Nutzung von Klassen in der Regel 0 bis 5 % länger. Der genaue Unterschied im Zeitaufwand hängt davon ab, wie viele Klassen geladen werden. Bei einem mit Daten gefüllten Cache verkürzt sich die Startzeit für eine JVM im Vergleich zu einem System ohne gemeinsame Klassennutzung normalerweise um 10 bis 40 %. Die tatsächliche Beschleunigung ist vom Betriebssystem und von der Anzahl der geladenen Klassen abhängig. Bei mehreren gleichzeitig aktiven JVMs macht sich die Reduzierung der Gesamtstartzeit deutlicher bemerkbar.
Wenn Sie mehr über die gemeinsame Nutzung von Klassen erfahren möchten, lesen Sie den Java SDK and Runtime Environment User Guide.
_RSE_CLASS_OPTS=-Xshareclasses:name=RSE,groupAccess,nonFatal
#_RSE_CLASS_OPTS="$_RSE_CLASS_OPTS -Xscmx6m
_RSE_JAVAOPTS="$_RSE_JAVAOPTS $_RSE_CLASS_OPTS"
Die theoretische maximale Größe des gemeinsam genutzten Cache liegt bei 2 GB. Die Cachegröße, die Sie angeben können, wird durch den auf dem System verfügbaren physischen Hauptspeicher und den verfügbaren Auslagerungsspeicher begrenzt. Da der virtuelle Adressraum eines Prozesses sowohl vom Cache für gemeinsam genutzte Klassen als auch vom Java-Heapspeicher verwendet wird, führt eine Erhöhung der maximalen Java-Heapgröße dazu, dass Sie einen entsprechend kleineren Cache für gemeinsam genutzte Klassen erstellen können.
Der Zugriff auf den Cache für gemeinsam genutzte Klassen wird durch Berechtigungen des Betriebssystems und Java-Sicherheitsberechtigungen beschränkt.
Standardmäßig wird für die Erstellung von Klassencaches die Sicherheit auf Benutzerebene verwendet, sodass nur der Benutzer, der den Cache erstellt hat, auf den Cache zugreifen kann. Unter z/OS UNIX gibt es die Option groupAccess, die allen Benutzern Zugriff gewährt, die zur Primärgruppe des Benutzers gehören, der den Cache erstellt hat. Zerstört werden kann ein Cache unabhängig von der verwendeten Zugriffsebene nur von dem Benutzer, der ihn erstellt hat, oder von einem Benutzer 'root' (UID 0).
Wenn Sie mehr über zusätzliche Sicherheitsoptionen bei Verwendung eines Java-Sicherheitsmanagers erfahren möchten, lesen Sie den Java SDK and Runtime Environment User Guide.
Diese Einstellungen beeinflussen, wie viele gemeinsam genutzte Speicherseiten der JVM zur Verfügung stehen. Für einen z/OS UNIX-System Service (31 Bit) hat die gemeinsam genutzte Seite eine feste Größe von 4 KB. Gemeinsam genutzte Klassen versuchen standardmäßig, einen Cache mit einer Größe von 16 MB zu erstellen. Sie sollten IPCSHMMPAGES deshalb auf einen Wert größer als 4096 setzen.
Wenn Sie die Cachegröße mit -Xscmx festlegen, rundet die JVM den Wert auf das nächste volle Megabyte auf. Berücksichtigen Sie dies, wenn Sie IPCSHMMPAGES auf Ihrem System setzen.
Diese Einstellungen beeinflussen, wie viele Semaphore für UNIX-Prozesse zur Verfügung stehen. Gemeinsam genutzte Klassen verwenden für die Kommunikation zwischen JVMs IPC-Semaphore.
Der Cache für gemeinsam genutzte Klassen benötigt zum Speichern von Kennungsdaten der auf dem System vorhandenen Caches Plattenspeicherplatz. Diese Daten werden unter /tmp/javasharedresources gespeichert. Wenn das Verzeichnis mit den Kennungsdaten gelöscht wird, kann die JVM nicht die gemeinsam genutzten Klassen auf dem System identifizieren und muss den Cache neu erstellen.
$ java -Xshareclasses:listAllCaches
Shared Cache OS shmid in use Last detach time
RSE 401412 0 Mon Jun 18 17:23:16 2007
Could not create the Java virtual machine.
$ java -Xshareclasses:name=RSE,printStats
Current statistics for cache "RSE":
base address = 0x0F300058
end address = 0x0F8FFFF8
allocation pointer = 0x0F4D2E28
cache size = 6291368
free bytes = 4355696
ROMClass bytes = 1912272
Metadata bytes = 23400
Metadata % used = 1%
# ROMClasses = 475
# Classpaths = 4
# URLs = 0
# Tokens = 0
# Stale classes = 0
% Stale classes = 0%
Cache is 30% full
Could not create the Java virtual machine.
$ java -Xshareclasses:name=RSE,destroy
JVMSHRC010I Shared Cache "RSE" is destroyed
Could not create the Java virtual machine.
Developer for System z-Clients ab Version 8.0.1 können beim Verbindungsaufbau Konfigurationsdateien und Produktaktualisierungsdaten im Pull-Verfahren vom Host abrufen. Dadurch wird sichergestellt, dass alle Clients über die gleichen Einstellungen verfügen und auf dem neuesten Stand sind.
Ab Version 8.0.3 kann der Clientadministrator mehrere Clientkonfigurationssätze und Clientaktualisierungsszenarien für die Anforderungen verschiedener Entwicklergruppen erstellen. Dadurch erhalten Benutzer eine angepasste Konfiguration, die auf Kriterien wie LDAP-Gruppenzugehörigkeit oder Zulassung zu einem Sicherheitsprofil basiert.
z/OS-Projekte können einzeln auf dem Client in der Perspektive für z/OS-Projekte erstellt werden. Sie können aber auch zentral auf dem Host erstellt werden, in welchem Fall sie auf Benutzerbasis auf den Client repliziert werden. Solche hostbasierten Projekte sind hinsichtlich Aussehen und Funktionsweise mit auf dem Client definierten Projekten identisch. Die Struktur, die Member und die Eigenschaften dieser Projekte können jedoch nicht vom Client geändert werden und sind nur bei bestehender Verbindung mit dem Host verfügbar.
pushtoclient.properties entnimmt der Client, ob diese Funktionen aktiviert sind und wo die zugehörigen Daten gespeichert werden. Weitere Informationen hierzu finden Sie im Abschnitt '(Optional) pushtoclient.properties, Hostbasierte Clientsteuerung' im Handbuch Hostkonfiguration (IBM Form SC23-7658).
Details zur Durchführung der zugewiesenen Aufgaben durch den Clientadministrator und den Manager für Entwicklungsprojekte finden Sie im Information Center für Developer for System z unter http://www-01.ibm.com/support/knowledgecenter/SSQ2R2_9.1.0/com.ibm.etools.getstart.wsentdev.doc/kc_version_welcome_rdz.html.
Push-to-Client sieht vor, dass systemspezifische Daten auf den einzelnen Systemen verbleiben, während allgemeine bzw. globale Daten auf einem zentralen System, dem primären System, verwaltet werden. Dadurch reduziert sich der Verwaltungsaufwand. Das primäre System wird in pushtoclient.properties durch die Direktive primary.system festgelegt. Die Standardeinstellung ist false.
Wichtig ist, dass nur ein System als primäres System definiert ist. Die Administratoren der Developer for System z-Clients können nur dann globale Konfigurationsdaten exportieren, wenn es sich beim Zielsystem um ein primäres System handelt. Sind allerdings mehrere primäre Systeme konfiguriert und deren Konfigurationen nicht synchronisiert, kann es auf den Developer for System z-Clients beim Verbindungsaufbau mit diesen Systemen zu Fehlern kommen.
Mehrere primäre Systeme können nur dann verwendet werden, wenn diese eine gemeinsame Developer for System z-Konfiguration (/etc/rdz) und gemeinsame Push-to-Client-Metadaten (/var/rdz/pushtoclient) verwenden. Da die Konfiguration in diesem Fall gemeinsam verwendet wird, gelten alle beteiligten Systeme als ein zusammengehöriges primäres System. So lange aber alle Systeme die gleichen Metadaten verwenden, ist diese Duplizierung kein wirkliches Thema.
Die Direktive pushtoclient.folder in pushtoclient.properties legt das Basisverzeichnis fest, in dem die Push-to-Client-Metadaten gespeichert werden. Die Standardeinstellung ist /var/rdz/pushtoclient.
Das Basisverzeichnis enthält die Push-to-Client-Stammkonfigurationsdatei keymapping.xml. Alle anderen Metadaten werden in den Unterverzeichnissen gespeichert.
Die meisten Unterverzeichnisse werden dynamisch erstellt, wenn der Clientadministrator die Push-to-Client-Arbeitsbereichskonfiguration exportiert. Die Metadaten werden in diesen Unterverzeichnissen nach Inhalt (z. B. Zuordnungen und Benutzervorgaben) unterteilt. Je mehr Developer for System z-Clientkomponenten durch Push-to-Client verwaltet werden, desto mehr Unterverzeichnisse werden dynamisch erstellt. Welche Metadaten in diesen Unterverzeichnissen gespeichert werden, entnehmen Sie den Konfigurationsdateien, die Sie im Exportassistenten des Developer for System z-Clients mit der Befehlsfolge Datei > Exportieren > Rational Developer for System z > Konfigurationsdateien öffnen können.
Weitere Informationen zur Erstellung dieser Unterverzeichnisse finden Sie im Abschnitt 'Anpassungskonfiguration' im Kapitel 'Basisanpassung' des Handbuchs Hostkonfiguration (IBM Form SC23-7658).
Standardmäßig (siehe Direktive file.permission in pushtoclient.properties) erhalten alle Dateien und Verzeichnisse im Basisverzeichnis die Berechtigungsbitmaske 775 (rwxrwxr-x), durch die der Eigentümer und die Standardgruppe des Eigentümers Lese- und Schreibzugriff auf die Verzeichnisstruktur und die darin enthaltenen Dateien erhalten. Alle anderen Benutzer und Gruppen haben nur Lesezugriff auf die Verzeichnisstruktur und deren Inhalt.
Vor der Konfiguration der Push-to-Client-Funktion muss für diese Verzeichnisse die UID (Benutzer-ID) und GID (Gruppen-ID) des Eigentümers festgelegt werden.
ADDGROUP RDZADMIN OWNER(IBMUSER) SUPGROUP(SYS1) –
DATA('RATIONAL DEVELOPER FOR SYSTEM Z - CLIENT ADMIN')
ALTGROUP RDZADMIN OMVS(GID(2))
CONNECT RDZADM1 GROUP(RDZADMIN) AUTH(USE)
ALTUSER RDZADM1 DFLTGRP(RDZADMIN) OMVS(UID(6))
chown –R rdzadm1:rdzadmin /var/rdz/pushtoclient
chmod –R 775 /var/rdz/pushtoclient
Weitere Informationen zu RACF-Beispielbefehlen finden Sie in der Veröffentlichung Security Server RACF Command Language Reference (IBM Form SA22-7687). Weitere Informationen zu z/OS UNIX-Beispielbefehlen finden Sie in der Veröffentlichung UNIX System Services Command Reference (IBM Form SA22-7802). Weitere Informationen finden Sie im Abschnitt z/OS UNIX-Verzeichnisstruktur.
Die Push-to-Client-Metadaten benötigen unter z/OS UNIX nur wenig Plattenspeicher, da der größte Teil der Metadaten als UTF-8-codierte XML-Dateien vorliegt. Zudem kann der Produktcode für die Clientaktualisierungsszenarien überall im Netz gespeichert werden. Eine Speicherung unter z/OS UNIX ist nicht erforderlich, da die zugehörigen Push-to-Client-Metadaten (Antwortdateien) den Client auf die richtige Speicherposition verweisen.
Beim Verbindungsaufbau eines Developer for System z-Clients (ab Version 8.0.1) mit dem Host liest der Client die Definitionen in pushtoclient.properties. Wenn die Direktive config.enabled aktiviert ist, vergleicht der Client seine aktuelle Konfiguration mit den Definitionen der Push-to-Client-Metadaten. Bei Abweichungen startet der Client einen Assistenten, der die erforderlichen Daten extrahiert und die Konfiguration nach Vorgabe durch Push-to-Client aktiviert.
Die Direktive reject.config.updates in pushtoclient.properties steuert, ob ein Benutzer die von Push-to-Client bereitgestellten Konfigurationsaktualisierungen zurückweisen darf.
Ein Developer for System z-Client (ab Version 8.0.1) stellt einen Assistenten bereit, mit dem der Clientadministrator die aktuelle Konfiguration exportieren kann, die dann wiederum mittels Push-to-Client von allen Developer for System z-Clients importiert wird. Da diese Funktion auf allen Clients verfügbar ist, sollten Sie sicherstellen, dass nur Clientadministratoren Schreibberechtigung für z/OS UNIX-Verzeichnisse haben, die Push-to-Client-Metadaten enthalten (/var/rdz/pushtoclient).
Zur Aktivierung der Unterstützung für Gruppen ist, wie in Abschnitt Mehrere Entwicklergruppen beschrieben, sowohl auf dem Client als auch auf dem Host Version 8.0.3 oder höher erforderlich.
Beim Verbindungsaufbau eines Developer for System z-Clients (ab Version 8.0.1) mit dem Host liest der Client die Definitionen in pushtoclient.properties. Wenn die Direktive product.enabled aktiviert ist, vergleicht der Client seine aktuelle Produktversion mit den Definitionen der Push-to-Client-Metadaten. Bei Abweichungen startet der Client einen Assistenten, der die erforderlichen Daten extrahiert und die Konfiguration nach Vorgabe durch Push-to-Client aktiviert.
Die Direktive reject.product.updates in pushtoclient.properties steuert, ob ein Benutzer die von Push-to-Client bereitgestellten Produktaktualisierungen zurückweisen darf.
Zur Aktivierung der Unterstützung für Gruppen ist, wie in Abschnitt Mehrere Entwicklergruppen beschrieben, sowohl auf dem Client als auch auf dem Host Version 8.0.3 oder höher erforderlich.
Ab Version 8.0.3 kann der Clientadministrator mehrere Clientkonfigurationssätze und Clientaktualisierungsszenarien für die Anforderungen verschiedener Entwicklergruppen erstellen. Dadurch erhalten Benutzer eine angepasste Konfiguration, die auf Kriterien wie LDAP-Gruppenzugehörigkeit oder Zulassung zu einem Sicherheitsprofil basiert.
Unterstützung für mehrere Entwicklergruppen, jede mit eigener Clientkonfiguration und Clientaktualisierungsanforderungen, aktivieren Sie, wie in Tabelle 36 gezeigt, durch die Zuweisung des gewünschten Werts zu den jeweiligen Direktiven (config.enabled und product.enabled) in der Datei pushtoclient.properties.
Wert von '*.enabled' | Funktion aktiviert? | Mehrere Gruppen unterstützt? |
---|---|---|
False | Nein | Nein |
True | Ja | Nein |
LDAP | Ja | Ja, basierend auf Zugehörigkeit der LDAP-Gruppen in FEK.PTC.*.ENABLED.sysname.devgroup |
SAF | Ja | Ja, basierend auf Zulassung zu Sicherheitsprofilen in FEK.PTC.*.ENABLED.sysname.devgroup |
Wenn die Funktion aktiviert ist (dies schließt den Wert TRUE ein), sind Entwickler immer Mitglied einer Standardgruppe. Zusätzlich kann ein Entwickler Mitglied keiner, einer oder mehrerer anderer Gruppen sein.
Die Zurückweisung von Aktualisierungen kann auch, wie in Tabelle 37 gezeigt, bedingt festgelegt werden.
Wert von 'reject.*.updates' | Funktion aktiviert? |
---|---|
False | Nein |
True | Ja |
LDAP | Abhängig von LDAP-Gruppenzugehörigkeit in FEK.PTC.REJECT.*.UPDATES.sysname.** |
SAF | Abhängig von Zulassung zu Sicherheitsprofil in FEK.PTC.REJECT.*.UPDATES.sysname.** |
Die Direktiven in pushtoclient.properties sind unabhängig voneinander. Sie können jeder Direktive jeden unterstützten Wert zuweisen. Die Einstellungen müssen nicht gleich sein.
Informationen zur erforderlichen Konfiguration der jeweiligen Funktion finden Sie in den Abschnitten LDAP-basierte Gruppenauswahl und SAF-basierte Gruppenauswahl. Weitere Informationen zur Aktivierung der Unterstützung für mehrere Gruppen finden Sie im Abschnitt '(Optional) pushtoclient.properties, Hostbasierte Clientsteuerung' im Handbuch Hostkonfiguration (IBM Form SC23-7658).
Wenn eine *.enabled-Funktion in pushtoclient.properties aktiviert ist (dies schließt den Wert TRUE ein), sind Entwickler für die jeweilige Funktion immer Mitglied einer Standardgruppe. Zusätzlich kann ein Entwickler Mitglied keiner, einer oder mehrerer anderer Gruppen sein.
Damit die Anwendung von Änderungen, die in mehreren Gruppen definiert sind, nicht zu komplex wird, grenzt Developer for System z auf Basis einer vom Benutzer getroffenen Auswahl ein, welche Definitionen verwendet werden.
Zusätzliche Gruppen | Verwendete Definitionen |
---|---|
Keine | Standard |
Eine | Standard oder (Standard + Gruppe) |
Mehrere | Standard oder (Standard + 1 Gruppe) |
Ein Entwickler kann mehreren Gruppen angehören, sein aktiver Arbeitsbereich nicht. Um Konfigurations- oder Produktaktualisierungen zu erhalten, muss der aktive Arbeitsbereich an eine bestimmte Konfigurationsgruppe (beispielsweise die Standardgruppe) oder an eine bestimmte Produktgruppe (beispielsweise die Standardgruppe) gebunden sein. Eine einmal erfolgte Bindung kann nicht mehr rückgängig gemacht werden. Falls eine neue Gruppenbindung erforderlich wird, muss ein neuer Arbeitsbereich erstellt werden.
Wenn ein Arbeitsbereich, der noch an keine Konfigurationsgruppe gebunden ist, eine Verbindung zum Host herstellt und config.enabled angibt, dass Push-to-Client aktiv ist, fragt Developer for System z alle Konfigurationsgruppen ab, um festzustellen, zu welchen Gruppen der Benutzer gehört. Aus diesen Gruppen muss der Benutzer eine Gruppe auswählen. Bei nachfolgenden Verbindungen wird nur noch die ausgewählte Gruppe abgefragt, um festzustellen, ob die Gruppenzugehörigkeit noch gültig ist.
config.enabled | Der Arbeitsbereich ist an diese Konfigurationsaktualisierungsgruppe gebunden. |
---|---|
False | Keine |
True | Standard |
LDAP | Standard oder Gruppe (nach Aufforderung) |
SAF | Standard oder Gruppe (nach Aufforderung) |
Wenn ein Arbeitsbereich, der noch an keine Produktgruppe gebunden ist, eine Verbindung zum Host herstellt und product.enabled angibt, dass Push-to-Client aktiv ist, fragt Developer for System z alle Produktgruppen ab, um festzustellen, zu welchen Gruppen der Benutzer gehört. Aus diesen Gruppen muss der Benutzer eine Gruppe auswählen. Bei nachfolgenden Verbindungen wird nur noch die ausgewählte Gruppe abgefragt, um festzustellen, ob die Gruppenzugehörigkeit noch gültig ist.
product.enabled | Der Arbeitsbereich ist an diese Produktaktualisierungsgruppe gebunden. |
---|---|
False | Keine |
True | Standard |
LDAP | Standard oder Gruppe (nach Aufforderung) |
SAF | Standard oder Gruppe (nach Aufforderung) |
Die Direktiven des Typs reject.*.updates funktionieren mit oder ohne Gruppendefinitionen. Wenn Gruppen für 'reject.*.updates' verwendet werden, wird die Gruppenbindung der zugehörigen Direktive des Typs *.enabled verwendet. Bei Vorliegen einer Aktualisierung stellt Developer for System z lediglich fest, ob der Benutzer die Aktualisierung zurückweisen darf, und handelt entsprechend.
Die Gruppenunterstützung für die Direktiven des Typs reject.*.updates ist neu in Version 9.1.0 und erfordert, dass sowohl Host und Client von Developer for System z die Version 9.1.0 oder höher aufweisen. Die Unterstützung ändert die Verarbeitungsweise der Schlüsselwörter 'LDAP' und 'SAF'.
Vor Version 9.1.0 war es ausreichend, auf der Zugriffsliste für FEK.PTC.REJECT.*.UPDATES.sysname zu sein, um unabhängig von einer Arbeitsbereichsgruppenbindung eine Aktualisierung zurückzuweisen. Ab Version 9.1.0 wird FEK.PTC.REJECT.*.UPDATES.sysname nur verwendet, um Aktualisierungen von Arbeitsbereichen zurückzuweisen, die an die Standardgruppe gebunden sind. Für an eine Gruppe gebundene Arbeitsbereiche müssen Sie auf der Zugriffsliste für FEK.PTC.REJECT.*.UPDATES.sysname.groupname sein, um Aktualisierungen zurückweisen zu können.
Bei der anfänglichen Produktanpassung wird das Verzeichnis 'grouping/' unter '/var/rdz/pushtoclient/' erstellt. Der Clientadministrator muss die <devgroup>/-Verzeichnisse zu /var/rdz/pushtoclient/grouping/ hinzufügen.
Die Verzeichnisse projects/, install/ und install/responsefiles/ werden bei der anfänglichen Produktanpassung in /var/rdz/pushtoclient/ erstellt. Sollten gruppenspezifische Produktaktualisierungsszenarien oder gruppenspezifische hostbasierte Projekte erforderlich sein, muss der Clientadministrator diese Verzeichnisse auch in /var/rdz/pushtoclient/grouping/<devgroup>/ erstellen.
Folgende z/OS UNIX-Befehlsfolge zeigt, wie die Unterverzeichnisse mit der richtigen Berechtigungsbitmaske erstellt werden. Zur Vermeidung von Eigentumskonflikten sollten die Befehle nur vom Clientadministrator ausgeführt werden.
saved_umask=$(umask)
umask 0000
cd /var/rdz/pushtoclient/grouping/
mkdir –m775 <devgroup>
cd <devgroup>
mkdir –m775 install
mkdir –m775 install/responsefiles
mkdir –m775 projects
umask $saved_umask
Weitere Informationen zu z/OS UNIX-Beispielbefehlen finden Sie in der Veröffentlichung UNIX System Services Command Reference (IBM Form SA22-7802).
/var/rdz/pushtoclient/grouping/<devgroup>
für jede Push-to-Client-Gruppe.LDAP (Lightweight Directory Access Protocol) ist zwar der Name eines TCP/IP-basierten Protokolls, häufig wird es aber zur Beschreibung einer Gruppe von Services für verteilte Verzeichnisse verwendet. Bei einem Verzeichnis handelt es sich um eine strukturierte Sammlung von Datensätzen vergleichbar mit einer Datenbank. Developer for System z kann einen LDAP-Server als einfache hierarchische Datenbank verwenden, in der Gruppen ein oder mehrere Mitglieder enthalten.
Wenn Definitionen Ihres LDAP-Servers als Auswahlmechanismus verwendet werden (der LDAP-Wert wird für Direktiven in pushtoclient.properties angegeben), überprüft Developer for System z die Zugehörigkeit der in Tabelle 41 aufgelisteten Gruppennamen, um festzustellen, zu welchen Entwicklergruppen ein Benutzer gehört und ob der Benutzer Aktualisierungen zurückweisen darf.
Gruppenname (cn=) | Ergebnis |
---|---|
FEK.PTC.CONFIG.ENABLED.sysname.devgroup | Der Client akzeptiert Konfigurationsaktualisierungen für die angegebene Gruppe. |
FEK.PTC.PRODUCT.ENABLED.sysname.devgroup | Der Client akzeptiert Produktaktualisierungen für die angegebene Gruppe. |
FEK.PTC.REJECT.CONFIG.UPDATES.sysname | Der Benutzer kann Konfigurationsaktualisierungen ablehnen, wenn der Arbeitsbereich an die Standardgruppe gebunden ist. |
FEK.PTC.REJECT.CONFIG.UPDATES.sysname.devgroup | Der Benutzer kann Konfigurationsaktualisierungen ablehnen, wenn der Arbeitsbereich an die angegebene Gruppe gebunden ist. |
FEK.PTC.REJECT.PRODUCT.UPDATES.sysname | Der Benutzer kann Produktaktualisierungen ablehnen, wenn der Arbeitsbereich an die Standardgruppe gebunden ist. |
FEK.PTC.REJECT.PRODUCT.UPDATES.sysname.devgroup | Der Benutzer kann Produktaktualisierungen ablehnen, wenn der Arbeitsbereich an die angegebene Gruppe gebunden ist. |
Der Wert von devgroup ist der Gruppenname, der einer Entwicklergruppe zugewiesen ist. Dieser Gruppenname ist auf Developer for System z-Clients sichtbar.
Der Wert von sysname ist der Systemname des Zielsystems.
Ein Benutzer kann einen Arbeitsbereich an die Standardgruppe für Konfigurationsaktualisierungen binden, wenn config.enabled in pushtoclient.properties auf SAF oder LDAP gesetzt ist. Ist config.enabled auf TRUE eingestellt, wird der Arbeitsbereich automatisch an die Standardgruppe gebunden.
Ein Benutzer kann einen Arbeitsbereich an die Standardgruppe für Produktaktualisierungen binden, wenn product.enabled in pushtoclient.properties auf SAF oder LDAP gesetzt ist. Ist product.enabled auf TRUE eingestellt, wird der Arbeitsbereich automatisch an die Standardgruppe gebunden.
Die Gruppenunterstützung für die Direktiven des Typs reject.*.updates ist neu in Version 9.1.0 und ändert die Verarbeitungsweise der Schlüsselwörter 'LDAP' und 'SAF'.
Abbildung 32 zeigt eine LDAP-Musterdefinition für eine Gruppe und einen Benutzer im LDIF-Format.
# Group Definition
dn: cn=FEK.PTC.CONFIG.ENABLED.CDFMVS08.GROUPA,o=PTC,c=DeveloperForZ
objectClass: groupOfUniqueNames
objectClass: top
cn: FEK.PTC.CONFIG.ENABLED.CDFMVS08.GROUPA
description: Project A
uniqueMember: uid=mborn,ou=Users,dc=example,dc=com
# User Definition
dn: uid=mborn,ou=Users,dc=example,dc=com
objectClass: organizationalPerson
objectClass: person
objectClass: inetOrgPerson
objectClass: uidObject
objectClass: top
cn: May Born
sn: Born
uid: mborn
facsimiletelephonenumber: +1 800 982 6883
givenname: May
mail: mborn@example.com
ou: Users
Ihnen steht eine große Auswahl an kommerziellen und kostenlosen LDAP-Servern zur Verfügung, beispielsweise IBM Tivoli Directory Server (http://www-01.ibm.com/software/tivoli/products/directory-server/). Auch Befehlszeilen- und grafisch orientierte Tools für die Verwaltung eines LDAP-Servers werden in Hülle und Fülle angeboten.
Wie im Abschnitt LDAP-Schema erwähnt, muss jeder Benutzer für den LDAP-Server definiert sein. Zur Reduzierung der Verwaltung empfiehlt es sich, das Push-to-Client-Schema auf einem LDAP-Server einzurichten, der bereits Zugriff auf die Benutzerdefinitionen hat. Sie können zum Beispiel IBM Tivoli Directory Server unter z/OS mit einer SDBM-Datenbank verwenden (die SDBM-Datenbank fungiert als Wrapper für Ihre Sicherheitsdatenbank).
Je nach standortspezifischen Richtlinien kann das Push-to-Client-Schema auf einem LDAP-Server auch vom Clientadministrator verwaltet werden. Dieses Arrangement würde Absprachen zwischen Verantwortungsbereichen und damit einhergehende Verzögerungen und Kommunikationsfehler reduzieren.
Für die LDAP-Verwaltung durch den Clientadministrator spricht, dass das Push-to-Client-Schema keine vertraulichen oder sicherheitsrelevanten Daten enthält. Wenn die Benutzerdefinitionen dem LDAP-Server bereits durch andere Schemas vorliegen, bestimmen die LDAP-Objekte von Developer for System z lediglich, welche Optionen ein Entwickler bei der Auswahl des Arbeitsbereichslayouts und bei automatischen Produktaktualisierungen für den Developer for System z-Client hat.
Jeder Datenbankserver, der das LDAP-Protokoll unterstützt, kann das Push-to-Client-Schema von Developer for System z bereitstellen. Daher können Sie die Informationen zum Verbindungsaufbau mit dem LDAP-Server in Developer for System z angeben. Auch das Suffix, das die Datenbank auf dem LDAP-Server eindeutig kennzeichnet, kann angegeben werden.
rsed.envvars-Direktive | Standard |
---|---|
_RSE_LDAP_SERVER | Lokales Hostsystem |
_RSE_LDAP_PORT | 389 |
_RSE_LDAP_PTC_GROUP_SUFFIX | "O=PTC,C=DeveloperForZ" |
Developer for System z wird in einem Unternehmen auf einem System namens CDFMVS08 ausgeführt. Als LDAP-Server wird IBM Tivoli Directory Server, das auch auf CDFMVS08 ausgeführt wird, verwendet. Der LDAP-Server ist konfiguriert, wie in Push-to-Client-Back-End zu LDAP hinzufügen beschrieben.
Jede Entwicklergruppe benötigt spezielle Clientkonfigurationsdateien, alle Entwickler unterliegen aber der gleichen Clientversionssteuerung. Im Gegensatz zu Clientadministratoren dürfen Entwickler die von Push-to-Client bereitgestellten Änderungen nicht zurückweisen.
Der Client- und der LDAP-Administrator einigen sich für Konfigurationsaktualisierungen auf die Gruppennamen BANKING und INSURANCE.
# filename ds.conf
# restart GLDSRV started task to pick up changes
# global section
adminDN "cn=LDAP admin"
adminPW password
listen ldap://:389
schemaPath /etc/ldap
# SDBM back-end section (RACF)
database SDBM GLDBSD31/GLDBSD64
suffix "cn=RACF,o=IBM,c=US"
# LDBM back-end section (z/OS UNIX files)
database LDBM GLDBLD31/GLDBLD64 LDBM-RDZ
suffix "o=PTC,c=DeveloperForZ"
databaseDirectory /var/ldap/ldbm/rdz
mkdir -p /var/ldap/ldbm/rdz
ldapmodify -D "cn=LDAP admin" -w password -f
/usr/lpp/ldap/etc/schema.user.ldif
ldapmodify -D "cn=LDAP admin" -w password -f
/usr/lpp/ldap/etc/schema.IBM.ldif
ldapadd -D "cn=LDAP admin" -w password -f
/u/ibmuser/ptc_root.ldif
Dabei enthält /u/ibmuser/ptc_root.ldif Folgendes:dn: o=PTC,c=DeveloperForZ
objectclass: top
objectclass: organization
o: PTC
Fügen Sie die einzelnen LDAP-Gruppenobjekte zum Schema hinzu und fügen Sie den Clientadministrator danach zu jedem Gruppenobjekt hinzu. Die Benutzerdefinition für die Benutzer-ID RDZADM1 wird mittels Pull-Verfahren aus dem RACF-Schema entnommen.
ldapadd -D "cn=LDAP admin" -w password -f /u/ibmuser/ptc_setup.ldif
# banking workspace configuration
dn: cn=FEK.PTC.CONFIG.ENABLED.CDFMVS08.BANKING,o=PTC,c=DeveloperForZ
objectclass: groupOfUniqueNames
cn: FEK.PTC.CONFIG.ENABLED.CDFMVS08.BANKING
description: Developer for System z push-to-client
# give client administrator access
uniqueMember: racfID=RDZADM1,profileType=user,cn=RACF,o=IBM,c=US
# insurance workspace configuration
dn: cn=FEK.PTC.CONFIG.ENABLED.CDFMVS08.INSURANCE,o=PTC,c=DeveloperForZ
objectclass: groupOfUniqueNames
cn: FEK.PTC.CONFIG.ENABLED.CDFMVS08.INSURANCE
description: Developer for System z push-to-client
# give client administrator access
uniqueMember: racfID=RDZADM1,profileType=user,cn=RACF,o=IBM,c=US
# reject configuration updates
dn: cn=FEK.PTC.REJECT.CONFIG.UPDATES.CDFMVS08,o=PTC,c=DeveloperForZ
objectclass: groupOfUniqueNames
cn: FEK.PTC.REJECT.CONFIG.UPDATES.CDFMVS08
description: Developer for System z push-to-client
# give client administrator access
uniqueMember: racfID=RDZADM1,profileType=user,cn=RACF,o=IBM,c=US
# reject product updates
dn: cn=FEK.PTC.REJECT.PRODUCT.UPDATES.CDFMVS08,o=PTC,c=DeveloperForZ
objectclass: groupOfUniqueNames
cn: FEK.PTC.REJECT.PRODUCT.UPDATES.CDFMVS08
description: Developer for System z push-to-client
# give client administrator access
uniqueMember: racfID=RDZADM1,profileType=user,cn=RACF,o=IBM,c=US
Entwickler werden den LDAP-Gruppenobjekten hinzugefügt. Die Benutzerdefinitionen für die Benutzer-IDs werden mittels Pull-Verfahren aus dem RACF-Schema entnommen.
ldapmodify -D "cn=LDAP admin" -w password -f /u/ibmuser/ptc_add.ldif
Dabei enthält /u/ibmuser/ptc_add.ldif Folgendes:# banking workspace configuration
dn: cn=FEK.PTC.CONFIG.ENABLED.CDFMVS08.BANKING,o=PTC,c=DeveloperForZ
changeType: modify
add: uniqueMember
uniqueMember: racfID=BNK010,profileType=user,cn=RACF,o=IBM,c=US
uniqueMember: racfID=BNK011,profileType=user,cn=RACF,o=IBM,c=US
uniqueMember: racfID=BNK012,profileType=user,cn=RACF,o=IBM,c=US
uniqueMember: racfID=BNK013,profileType=user,cn=RACF,o=IBM,c=US
uniqueMember: racfID=BNK014,profileType=user,cn=RACF,o=IBM,c=US
# insurance workspace configuration
dn: cn=FEK.PTC.CONFIG.ENABLED.CDFMVS08.INSURANCE,o=PTC,c=DeveloperForZ
changeType: modify
add: uniqueMember
uniqueMember: racfID=INS010,profileType=user,cn=RACF,o=IBM,c=US
uniqueMember: racfID=INS011,profileType=user,cn=RACF,o=IBM,c=US
uniqueMember: racfID=INS012,profileType=user,cn=RACF,o=IBM,c=US
uniqueMember: racfID=INS013,profileType=user,cn=RACF,o=IBM,c=US
uniqueMember: racfID=INS014,profileType=user,cn=RACF,o=IBM,c=US
# BANKING and INSURANCE have different configuration needs
config.enabled=LDAP
# everyone receives product updates
product.enabled=TRUE
# only RDZADMIN can reject configuration updates
reject.config.updates=LDAP
# only RDZADMIN can reject product updates
reject.product.updates=LDAP
Da keine individuellen Produktaktualisierungsszenarien vorliegen, braucht der Clientadministrator die Unterverzeichnisse install/ und install/responsefiles/ in /var/rdz/pushtoclient/grouping/<devgroup> weder zu erstellen noch zu aktualisieren.
Der Clientadministrator muss die für Produktaktualisierungen erforderlichen Antwortdateien im Verzeichnis /var/rdz/pushtoclient/install/responsefiles/ der Standardgruppe erstellen.
SAF (Security Access Facility) ist eine Schnittstelle, über die auf jedes z/OS-Sicherheitsprodukt zugegriffen werden kann. Developer for System z kann diese Schnittstelle für die Abfrage Ihres Sicherheitsprodukts und das Abrufen Push-to-Client-relevanter Informationen verwenden.
Wenn Definitionen Ihrer Sicherheitsdatenbank als Auswahlmechanismus verwendet werden (der SAF-Wert wird für Direktiven in pushtoclient.properties angegeben), überprüft Developer for System z die Zugriffserlaubnis auf die in Tabelle 42 aufgelisteten Profile, um festzustellen, zu welchen Entwicklergruppen ein Benutzer gehört und ob der Benutzer Aktualisierungen zurückweisen darf.
FACILITY-Profil | Feste Länge | Erforderlicher Zugriff | Ergebnis |
---|---|---|---|
FEK.PTC.CONFIG.ENABLED. |
23 | READ | Der Client akzeptiert Konfigurationsaktualisierungen für die angegebene Gruppe. |
FEK.PTC.PRODUCT.ENABLED. |
24 | READ | Der Client akzeptiert Produktaktualisierungen für die angegebene Gruppe. |
FEK.PTC.REJECT.CONFIG. |
30 | READ | Der Benutzer kann Konfigurationsaktualisierungen ablehnen, wenn der Arbeitsbereich an die Standardgruppe gebunden ist. |
FEK.PTC.REJECT.CONFIG. UPDATES.sysname.devgroup | 30 | READ | Der Benutzer kann Konfigurationsaktualisierungen ablehnen, wenn der Arbeitsbereich an die angegebene Gruppe gebunden ist. |
FEK.PTC.REJECT.PRODUCT. |
31 | READ | Der Benutzer kann Produktaktualisierungen ablehnen, wenn der Arbeitsbereich an die Standardgruppe gebunden ist. |
FEK.PTC.REJECT.PRODUCT. UPDATES.sysname.devgroup | 31 | READ | Der Benutzer kann Produktaktualisierungen ablehnen, wenn der Arbeitsbereich an die angegebene Gruppe gebunden ist. |
Der Wert von devgroup ist der Gruppenname, der einer Entwicklergruppe zugewiesen ist. Dieser Gruppenname ist auf Developer for System z-Clients sichtbar.
Der Wert von sysname ist der Systemname des Zielsystems.
Ein Benutzer kann einen Arbeitsbereich an die Standardgruppe für Konfigurationsaktualisierungen binden, wenn config.enabled in pushtoclient.properties auf SAF oder LDAP gesetzt ist. Ist config.enabled auf TRUE eingestellt, wird der Arbeitsbereich automatisch an die Standardgruppe gebunden.
Ein Benutzer kann einen Arbeitsbereich an die Standardgruppe für Produktaktualisierungen binden, wenn product.enabled in pushtoclient.properties auf SAF oder LDAP gesetzt ist. Ist product.enabled auf TRUE eingestellt, wird der Arbeitsbereich automatisch an die Standardgruppe gebunden.
In der Spalte 'Feste Länge' ist die Länge des festen Teils des zugehörigen Sicherheitsprofils angegeben.
Developer for System z erwartet standardmäßig, dass FEK.*-Profile der Sicherheitsklasse FACILITY angehören. Für Profile der Klasse FACILITY gilt eine Beschränkung auf 39 Zeichen. Falls die Länge des festen Profilteils (FEK.PTC.<key>) und die Länge des standortspezifischen Profilteils (sysname oder sysname.devgroup) diesen Wert überschreiten, können Sie die Profile in einer anderen Klasse speichern und Developer for System z anweisen, diese Klasse zu verwenden. Dazu müssen Sie in rsed.envvars das Kommentarzeichen vor _RSE_FEK_SAF_CLASS entfernen und den Namen der gewünschten Klasse angeben.
Jede Entwicklergruppe benötigt spezielle Clientkonfigurationsdateien, alle Entwickler unterliegen aber der gleichen Clientversionssteuerung. Im Gegensatz zu Clientadministratoren dürfen Entwickler die von Push-to-Client bereitgestellten Änderungen nicht zurückweisen. Diese Zurückweisungsregel wurde als Vorbereitung auf künftige Erweiterungen für alle Systeme eingeführt.
Der Client- und der Sicherheitsadministrator einigen sich für Konfigurationsaktualisierungen auf die Gruppennamen BANKING und INSURANCE.
# allow RDZADMIN and DEVBANK to select push-to-client group BANKING
RDEFINE XFACILIT (FEK.PTC.CONFIG.ENABLED.CDFMVS08.BANKING) –
UACC(NONE) DATA('RATIONAL DEVELOPER FOR SYSTEN Z - PUSH-TO-CLIENT')
PERMIT FEK.PTC.CONFIG.ENABLED.CDFMVS08.BANKING CLASS(XFACILIT) –
ID(RDZADMIN DEVBANK) ACCESS(READ)
# allow RDZADMIN and DEVINSUR to select push-to-client group INSURANCE
RDEFINE XFACILIT (FEK.PTC.CONFIG.ENABLED.CDFMVS08.INSURANCE) –
UACC(NONE) DATA('RATIONAL DEVELOPER FOR SYSTEN Z - PUSH-TO-CLIENT')
PERMIT FEK.PTC.CONFIG.ENABLED.CDFMVS08.INSURANCE CLASS(XFACILIT) –
ID(RDZADMIN DEVINSUR) ACCESS(READ)
# RDZADMIN can reject configuration updates on any system and for any group
RDEFINE XFACILIT (FEK.PTC.REJECT.CONFIG.UPDATES.**) –
UACC(NONE) DATA('RATIONAL DEVELOPER FOR SYSTEN Z - PUSH-TO-CLIENT')
PERMIT FEK.PTC.REJECT.CONFIG.UPDATES.** CLASS(XFACILIT) –
ID(RDZADMIN) ACCESS(READ)
# RDZADMIN can reject product updates on any system system and for any group
RDEFINE XFACILIT (FEK.PTC.REJECT.PRODUCT.UPDATES.**) –
UACC(NONE) DATA('RATIONAL DEVELOPER FOR SYSTEN Z - PUSH-TO-CLIENT')
PERMIT FEK.PTC.REJECT.PRODUCT.UPDATES.** CLASS(XFACILIT) –
ID(RDZADMIN) ACCESS(READ)
# activate changes
SETROPTS RACLIST(XFACILIT) REFRESH
# BANKING and INSURANCE have different configuration needs
config.enabled=SAF
# everyone receives product updates
product.enabled=TRUE
# only RDZADMIN can reject configuration updates
reject.config.updates=SAF
# only RDZADMIN can reject product updates
reject.product.updates=SAF
_RSE_FEK_SAF_CLASS=XFACILIT
Da keine individuellen Produktaktualisierungsszenarien vorliegen, braucht der Clientadministrator die Unterverzeichnisse install/ und install/responsefiles/ in /var/rdz/pushtoclient/grouping/<devgroup>/ weder zu erstellen noch zu aktualisieren.
Der Clientadministrator muss die für Produktaktualisierungen erforderlichen Antwortdateien im Verzeichnis /var/rdz/pushtoclient/install/responsefiles/ der Standardgruppe erstellen.
Stellen Sie sich vor, dass während der Verwendung der Musterkonfiguration ein Developer for System z-Fixpack mit wichtigen Programmkorrekturen verfügbar wird, der Zeitplan eines Finanzprojekts aber derart kritisch ist, dass einige Entwickler zu diesem Zeitpunkt nur ungern Änderungen an ihren Workstations vornehmen wollen.
Dieses Problem kann der Sicherheitsadministrator ganz einfach lösen, indem er zum Beispiel allen DEVBANK-Entwicklern eine Karenzzeit einräumt, innerhalb der sie die Aktualisierung verschieben (also zunächst zurückweisen) können.
# start of grace period
PERMIT FEK.PTC.REJECT.PRODUCT.UPDATES.** CLASS(XFACILIT) –
ID(DEVBANK) ACCESS(READ)
# activate changes
SETROPTS RACLIST(FACILITY) REFRESH
# end of grace period
PERMIT FEK.PTC.REJECT.PRODUCT.UPDATES.** CLASS(XFACILIT) –
ID(DEVBANK) DELETE
# activate changes
SETROPTS RACLIST(FACILITY) REFRESH
z/OS-Projekte können einzeln auf dem Client in der Perspektive für z/OS-Projekte erstellt werden. Sie können aber auch zentral auf dem Host erstellt werden, in welchem Fall sie auf Benutzerbasis auf den Client repliziert werden. Solche hostbasierten Projekte sind hinsichtlich Aussehen und Funktionsweise mit auf dem Client definierten Projekten identisch. Die Struktur, die Member und die Eigenschaften dieser Projekte können jedoch nicht vom Client geändert werden und sind nur bei bestehender Verbindung mit dem Host verfügbar.
Das Basisverzeichnis für hostbasierte Projekte wird vom Clientadministrator in /var/rdz/pushtoclient/keymapping.xml definiert. Standardmäßig lautet es /var/rdz/pushtoclient/projects.
Hostbasierte Projekte können auch in die im Abschnitt Mehrere Entwicklergruppen beschriebene Konfiguration für mehrere Gruppen integriert werden. Dies bedeutet, dass hostbasierte Projekte auch in /var/rdz/pushtoclient/grouping/<devgroup>/projects/ definiert werden können.
Wenn ein Arbeitsbereich an eine bestimmte Gruppe gebunden ist und für einen Benutzer dieser Gruppe und in der Standardgruppe Projektdefinitionen vorliegen, erhält der Benutzer die Projektdefinitionen sowohl aus der Standardgruppe als auch aus der spezifischen Gruppe.
Developer for System z unterstützt diesen Ansatz insofern, als CICS-Administratoren die Möglichkeit haben, die Standardwerte für CICS-Ressourcendefinitionen zu kontrollieren und die Anzeigemerkmale von CICS-Ressourcendefinitionsparametern mithilfe des CICS Resource Definition (CRD)-Servers zu steuern, der Teil von Application Deployment Manager ist.
Der CICS-Administrator kann beispielsweise bestimmte Parameter für CICS-Ressourcendefinitionen bereitstellen, die nicht vom Anwendungsentwickler aktualisiert werden können. Andere Parameter für CICS-Ressourcendefinitionen können mit oder ohne Vorgabe von Standardwerten zur Aktualisierung freigegeben werden. Der CICS-Ressourcendefinitionsparameter kann auch ausgeblendet werden, um unnötige Komplexität zu vermeiden.
Sobald der Anwendungsentwickler mit den CICS-Ressourcendefinitionen zufrieden ist, können sie in der aktiven CICS-Testumgebung installiert werden. Sie können die Definitionen aber auch zur weiteren Bearbeitung und zur Genehmigung durch einen CICS-Administrator in ein Manifest exportieren. Der CICS-Administrator kann Änderungen an Ressourcendefinitionen mit dem Verwaltungsdienstprogramm (Batchdienstprogramm) oder dem Manifestverarbeitungstool implementieren.
Weitere Informationen zu den erforderlichen Schritten für die Konfiguration von Application Deployment Manager auf Ihrem Hostsystem enthält "Application Deployment Manager (optional)" in Hostkonfiguration (IBM Form SC12-4062).
Zum CICS Resource Definition (CRD)-Server von Application Deployment Manager gehören der Server selbst, ein CRD-Repository, die zugehörigen CICS-Ressourcendefinitionen, Bindungsdateien für Web-Services (sofern die Web-Service-Schnittstelle verwendet wird) und ein Beispielhandler für Pipelinenachrichten. Der CRD-Server muss in einer Webverwaltungsregion (WOR, Web Owning Region) ausgeführt werden, die in der Dokumentation zu Developer for System z als 'primäre CICS-Verbindungsregion' bezeichnet wird.
Weitere Informationen zu den Application Deployment Manager-Services, die im aktuellen Release von Developer for System z enthalten sind, finden Sie im Information Center für Developer for System z (http://www-01.ibm.com/support/knowledgecenter/SSQ2R2_9.1.0/com.ibm.etools.getstart.wsentdev.doc/kc_version_welcome_rdz.html).
CICS Transaction Server stellt ab Version 4.1 Unterstützung für eine HTTP-Schnittstelle zur Verfügung, die mithilfe von RESTful-Prinzipien (Representational State Transfer) entworfen wurde. Diese RESTful-Schnittstelle ist jetzt die strategische CICSTS-Schnittstelle, die von Clientanwendungen verwendet wird. Die ältere Web-Service-Schnittstelle wurde eingefroren. Erweiterungen werden nur für die RESTful-Schnittstelle entwickelt.
Application Deployment Manager hält diese Absichtserklärung ein. Für alle Services, die ab Developer for System z Version 7.6 neu sind, ist der RESTful-CRD-Server erforderlich.
Falls gewünscht, können die RESTful- und Web-Service-Schnittstellen gleichzeitig in einer CICS-Region aktiv sein. In diesem Fall sind in der Region zwei CRD-Server aktiv. Beide Server verwenden gemeinsam dasselbe CRD-Repository. Beachten Sie, dass CICS einige Warnungen zu doppelten Definitionen ausgibt, wenn die zweite Schnittstelle in der Region definiert wird.
Eine CICS-Testumgebung kann aus mehreren MRO-Verbindungsregionen (Multi-Region Option) bestehen. Für diese Regionen haben sich im Laufe der Zeit inoffizielle Bezeichnungen eingeschlichen. So werden sie unter anderem als Terminalverwaltungsregion, Webverwaltungsregion, Anwendungsverwaltungsregion und Datenverwaltungsregion bezeichnet.
In einer Webverwaltungsregion wird die Unterstützung für CICS-Web-Services implementiert. In dieser Region muss der CICS Resource Definition (CRD)-Server von Application Deployment Manager ausgeführt werden. Für Application Deployment Manager ist dies die primäre CICS-Verbindungsregion. Der CRD-Client implementiert eine Web-Service-Verbindung zur primären CICS-Verbindungsregion.
Nicht primäre CICS-Verbindungsregionen sind alle anderen Regionen, für die der CRD-Server Services bereitstellen kann. Zu diesen Services gehört die Anzeige von Ressourcen im IBM CICS-Explorer und das Definieren von Ressourcen mit dem Editor für CICS-Ressourcendefinitionen.
Wenn CICS-Ressourcendefinitionen der primären CICS-Verbindungsregion mit dem CICSPlex SM Business Application Services (BAS) verwaltet wird, kann der CRD-Server auch für alle anderen von den BAS verwalteten CICS-Regionen Services bereitstellen.
Nicht von den BAS verwaltete CICS-Regionen erfordern zusätzliche Änderungen, um Services vom CRD-Server nutzen zu können.
Aktionen, die der CRD-Server für die CICS-Ressourcen ausführt, werden in der CICS-CSDL-TD-Warteschlange protokolliert, die in der Regel auf DD MSGUSR in Ihrer CICS-Region zeigt.
Wenn Ihre CICS-Ressourcendefinitionen mit den CICSPlex SM Business Application Services (BAS) verwaltet werden, muss die EYUPARM-Anweisung BASLOGMSG von CICSPlex SM auf (YES) gesetzt sein, damit die Protokolle erstellt werden.
Die VSAM-Datei für das CRD-Server-Repository enthält alle Standardressourcendefinitionen und muss daher vor Aktualisierungen geschützt werden. Entwickler müssen jedoch die Möglichkeit haben, die hier gespeicherten Werte zu lesen. Beispiele für RACF-Befehle zum Schützen des CRD-Repositorys enthält der Abschnitt Dateiprofile definieren.
Wenn CICS eine SOAP-Nachricht empfängt, wird sie von einer Pipeline verarbeitet. Eine Pipeline ist eine Gruppe von Nachrichtenhandlern, die nacheinander ausgeführt werden. CICS liest die Pipelinekonfiguration, um festzustellen, welche Nachrichtenhandler in der Pipeline aufgerufen werden sollen. Ein Nachrichtenhandler ist ein Programm, in dem Web-Service-Anforderungen und -Antworten auf spezielle Weise verarbeitet werden können.
Application Deployment Manager stellt ein Beispiel für eine Pipelinekonfigurationsdatei bereit, das Aufrufe für einen Nachrichtenhandler und ein Verarbeitungsprogramm für den SOAP-Header enthält.
Der Pipelinenachrichtenhandler (ADNTMSGH) wird für die Sicherheit verwendet. Er verarbeitet die Benutzer-ID und das Kennwort im SOAP-Header. ADNTMSGH wird von der Beispielpipelinekonfigurationsdatei referenziert und muss deshalb in die CICS-RPL-Kette gestellt werden.
Eine von einer Pipeline aufgerufene Anwendung wird standardmäßig unter der Transaktions-ID CPIH ausgeführt. CPIH wird normalerweise gesetzt, wenn ein Mindestmaß an Berechtigungen erforderlich ist.
Developer for System z stellt mehrere Transaktionen bereit, die der CRD-Server beim Definieren und Abfragen von CICS-Ressourcen verwendet. Die Transaktions-IDs legt der CRD-Server je nach angeforderter Operation fest. Weitere Informationen zur Anpassung von Transaktions-IDs finden Sie im Abschnitt "Application Deployment Manager (optional)" im Handbuch Hostkonfiguration (IBM Form SC12-4062).
Transaktion | Beschreibung |
---|---|
ADMS | Für Änderungen an CICS-Ressourcen, die vom Manifestverarbeitungstool angefordert werden. Diese Transaktion ist normalerweise für CICS-Administratoren bestimmt. Diese Transaktion erfordert eine hohe Berechtigungsstufe. |
ADMI | Für Anforderungen, die CICS-Ressourcen definieren, installieren oder deinstallieren. Diese Transaktion kann je nach Standortrichtlinien eine mittlere Berechtigungsstufe erfordern. |
ADMR | Für alle anderen Anforderungen, die CICS-Umgebungsinformationen oder -Ressourceninformationen abrufen. Diese Transaktion kann je nach Standortrichtlinien ein Mindestmaß an Berechtigungen erfordern. |
Einige oder alle der hier genannten Ressourcendefinitionsanforderungen der CRD-Servertransaktionen sollten geschützt werden. Sie sollten zumindest die Aktualisierungsbefehle schützen (Aktualisierung der Standard-Web-Service-Parameter, der Standarddeskriptorparameter und der Bindung zwischen Dateinamen), damit diese Befehle für das Definieren globaler Standardwerte für Ressourcen ausschließlich von CICS-Administratoren abgesetzt werden können.
Wenn die Transaktion zugeordnet wird, stellt die Sicherheitsprüfung für CICS-Ressourcen (sofern aktiviert) sicher, dass die Benutzer-ID berechtigt ist, die Transaktions-ID zu verwenden.
Die Ressourcenüberprüfung wird von der Option RESSEC der aktiven Transaktion, dem Systeminitialisierungsparameter RESSEC und - für den CRD-Server - vom Systeminitialisierungsparameter XPCT gesteuert.
Die Ressourcenüberprüfung findet nur statt, wenn der Systeminitialisierungsparameter XPCT einen anderen Wert als NO hat und die Option RESSEC der Definition TRANSACTION auf YES oder der Systeminitialisierungsparameter RESSEC auf ALWAYS gesetzt ist.
RALTER GCICSTRN SYSADM UACC(NONE) ADDMEM(ADMS)
PERMIT SYSADM CLASS(GCICSTRN) ID(#cicsadmin)
RALTER GCICSTRN DEVELOPER UACC(NONE) ADDMEM(ADMI)
PERMIT DEVELOPER CLASS(GCICSTRN) ID(#cicsdeveloper)
RALTER GCICSTRN ALLUSER UACC(READ) ADDMEM(ADMR)
SETROPTS RACLIST(TCICSTRN) REFRESH
Die SSL-Verschlüsselung des Datenstroms wird unterstützt, wenn der Application Deployment Manager-Client die Web-Service-Schnittstelle verwendet, um den CRD-Server aufzurufen. Die Verwendung von SSL für diese Kommunikation wird durch das Schlüsselwort SSL(YES) in der CICSTS-Definition TCPIPSERVICE gesteuert, wie in RACF Security Guide for CICSTS dokumentiert.
CICSTS stellt die Funktionalität zur Verfügung, Ressourcen und die Befehle für die Bearbeitung zu schützen. Bestimmte Application Deployment Manager-Aktionen (beispielsweise Berechtigungen zum Bearbeiten neuer Ressourcentypen erteilen) schlagen möglicherweise fehl, wenn die Sicherheit aktiv ist, aber nicht vollständig konfiguriert ist.
Prüfen Sie bei einem Funktionsfehler in Application Deployment Manager das CICS-Protokoll auf Nachrichten wie die folgende. Ergreifen Sie Maßnahmen zur Fehlerbehebung, die im RACF Security Guide for CICSTS dokumentiert sind.
DFHXS1111 %date %time %applid %tranid Security violation by user
%userid at netname %portname for resource %resource in class
%classname. SAF codes are (X'safresp',X'safreas'). ESM codes are
(X'esmresp',X'esmreas').
Mit dem von Developer for System z bereitgestellten Verwaltungsdienstprogramm können CICS-Administratoren die Standardwerte für CICS-Ressourcendefinitionen vorgeben. Diese Standardwerte können schreibgeschützt oder für den Anwendungsentwickler editierbar sein.
Das Verwaltungsdienstprogramm wird vom Beispieljob ADNJSPAU in der Datei FEK.#CUST.JCL aufgerufen. Für die Verwendung dieses Dienstprogramms ist das Zugriffsrecht UPDATE für das CRD-Repository erforderlich.
ADNJSPAU ist in FEK.#CUST.JCL enthalten, sofern der z/OS-Systemprogrammierer während der Anpassung und Übergabe des Jobs FEK.SFEKSAMP(FEKSETUP) keine andere Position angegeben hat. Weitere Details hierzu finden Sie in "Angepasstes Setup" in Hostkonfiguration (IBM Form SC12-4062).
UPDATE | Auf dieses Schlüsselwort folgende Attribute können von einem Anwendungsentwickler mit Developer for System z aktualisiert werden. Dieses Schlüsselwort wird standardmäßig für übergangene Attribute verwendet. |
PROTECT | Auf dieses Schlüsselwort folgende Attribute werden angezeigt, können jedoch nicht von einem Anwendungsentwickler mit Developer for System z aktualisiert werden. |
HIDDEN | Auf dieses Schlüsselwort folgende Attribute werden nicht angezeigt und können nicht von einem Anwendungsentwickler mit Developer for System z aktualisiert werden. |
Sehen Sie sich das folgende Codebeispiel für ADNJSPAU an.
//ADNJSPAU JOB <JOB-PARAMETER>
//*
//ADNSPAU EXEC PGM=ADNSPAU,REGION=1M
//STEPLIB DD DISP=SHR,DSN=FEK.SFEKLOAD
//ADMREP DD DISP=OLD,DSN=FEK.#CUST.ADNREPF0
//SYSPRINT DD SYSOUT=*
//SYSIN DD *
*
* CICSPlex-SM-Parameter
*
DEFINE CPSMNAME( )
*DEFINE STAGINGGROUPNAME(ADMSTAGE)
*
* Manifestexportregel
*
DEFINE MANIFESTEXPORTRULE(installOnly)
*
* Standardwerte für CICS-Ressourcendefinitionen
* Für übergangene Attribute wird standardmäßig UPDATE verwendet.
*
* Standardattribute für DB2TRAN
*
DEFINE DB2TRAN()
UPDATE DESCRIPTION()
ENTRY()
TRANSID()
*
* Standardattribute für DOCTEMPLATE
*
DEFINE DOCTEMPLATE()
UPDATE DESCRIPTION()
TEMPLATENAME()
FILE() TSQUEUE() TDQUEUE() PROGRAM() EXITPGM()
DDNAME(DFHHTML) MEMBERNAME()
HFSFILE()
APPENDCRLF(YES) TYPE(EBCDIC)
*
* Standardattribute für FILE
*
DEFINE FILE()
UPDATE DESCRIPTION()
RECORDSIZE() KEYLENGTH()
RECORDFORMAT(V) ADD(NO)
BROWSE(NO) DELETE(NO) READ(YES) UPDATE(NO)
REMOTESYSTEM() REMOTENAME()
PROTECT DSNAME() RLSACCESS(NO) LSRPOOLID(1) STRINGS(1)
STATUS(ENABLED) OPENTIME(FIRSTREF)
DISPOSITION(SHARE) DATABUFFERS(2) INDEXBUFFERS(1)
TABLE(NO) MAXNUMRECS(NOLIMIT)
READINTEG(UNCOMMITTED) DSNSHARING(ALLREQS)
UPDATEMODEL(LOCKING) LOAD(NO)
JNLREAD(NONE) JOURNAL(NO)
JNLSYNCREAD(NO) JNLUPDATE(NO)
JNLADD(NONE) JNLSYNCWRITE(YES)
RECOVERY(NONE) FWDRECOVLOG(NO)
BACKUPTYPE(STATIC)
PASSWORD() NSRGROUP()
CFDTPOOL() TABLENAME()
*
* Standardattribute für MAPSET
*
DEFINE MAPSET()
UPDATE DESCRIPTION()
PROTECT RESIDENT(NO) STATUS(ENABLED)
USAGE(NORMAL) USELPACOPY(NO)
** Standardattribute für PROCESSTYPE
*
DEFINE PROCESSTYPE()
UPDATE DESCRIPTION()
FILE(BTS)
PROTECT STATUS(ENABLED)
AUDITLOG() AUDITLEVEL(OFF)
*
* Standardattribute für PROGRAM
*
DEFINE PROGRAM()
UPDATE DESCRIPTION()
CEDF(YES) LANGUAGE(LE370)
REMOTESYSTEM() REMOTENAME() TRANSID()
PROTECT API(CICSAPI) CONCURRENCY(QUASIRENT)
DATALOCATION(ANY) DYNAMIC(NO)
EXECKEY(USER) EXECUTIONSET(FULLAPI)
RELOAD(NO) RESIDENT(NO)
STATUS(ENABLED) USAGE(NORMAL) USELPACOPY(NO)
HIDDEN JVM(NO) JVMCLASS() JVMPROFILE(DFHJVMPR)
*
* Standardattribute für TDQUEUE
*
DEFINE TDQUEUE()
UPDATE DESCRIPTION()
TYPE(INTRA)
* Partitionsexterne Parameter
DDNAME() DSNAME()
REMOTENAME() REMOTESYSTEM() REMOTELENGTH(1)
RECORDSIZE() BLOCKSIZE(0) RECORDFORMAT(UNDEFINED)
BLOCKFORMAT() PRINTCONTROL() DISPOSITION(SHR)
* Partitionsinterne Parameter
FACILITYID() TRANSID() TRIGERRLEVEL(1)
USERID()
* Indirekte Parameter
INDIRECTNAME()
PROTECT WAIT(YES) WAITACTION(REJECT)
* Partitionsexterne Parameter
DATABUFFERS(1)
SYSOUTCLASS() ERROROPTION(IGNORE)
OPENTIME(INITIAL) REWIND(LEAVE) TYPEFILE(INPUT)
* Partitionsinterne Parameter
ATIFACILITY(TERMINAL) RECOVSTATUS(NO)
*
* Standardattribute für TRANSACTION
*
DEFINE TRANSACTION()
UPDATE DESCRIPTION()
PROGRAM()
TWASIZE(0)
REMOTESYSTEM() REMOTENAME() LOCALQ(NO)
PROTECT PARTITIONSET() PROFILE(DFHCICST)
DYNAMIC(NO) ROUTABLE(NO)
ISOLATE(YES) STATUS(ENABLED)
RUNAWAY(SYSTEM) STORAGECLEAR(NO)
SHUTDOWN(DISABLED)
TASKDATAKEY(USER) TASKDATALOC(ANY)
BREXIT() PRIORITY(1) TRANCLASS(DFHTCL00)
DTIMOUT(NO) RESTART(NO) SPURGE(NO) TPURGE(NO)
DUMP(YES) TRACE(YES) CONFDATA(NO)
OTSTIMEOUT(NO) WAIT(YES) WAITTIME(00,00,00)
ACTION(BACKOUT) INDOUBT(BACKOUT)
RESSEC(NO) CMDSEC(NO)
TRPROF()
ALIAS() TASKREQ()
XTRANID() TPNAME() XTPNAME()
*
* URDIMAP-Attribute
*
DEFINE URIMAP()
UPDATE USAGE(CLIENT)
DESCRIPTION()
PATH(/required/path)
TCPIPSERVICE()
TRANSACTION()
PROGRAM()
PROTECT ANALYZER(NOANALYZER)
ATOMSERVICE()
CERTIFICATE()
CHARACTERSET()
CIPHERS()
CONVERTER()
HFSFILE()
HOST(host.mycompany.com)
HOSTCODEPAGE()
LOCATION()
MEDIATYPE()
PIPELINE()
PORT(NO)
REDIRECTTYPE(NONE)
SCHEME(HTTP)
STATUS(ENABLED)
TEMPLATENAME()
USERID()
WEBSERVICE()
*
* Optionaler Dateiname für die Bindung von Dateinamen an VSAM-Dateinamen
*
*DEFINE DSBINDING() DSNAME()
/*
Die Unterstützung von UIRIMAP wurde dem Verwaltungsdienstprogramm in Developer for System z Version 7.6.1 hinzugefügt. Um die Unterstützung von URIMAP verwenden zu können, muss der VSAM-Datei des CRD-Repositorys eine maximale Satzgröße von 3000 zugeordnet werden. Bis zur Version 7.6.1 von Developer for System z verwendet der Zuordnungsjob des CRD-Beispielrepositorys eine maximale Satzgröße von 2000.
Das Verwaltungsdienstprogramm setzt die folgenden Nachrichten an die DD-Karte SYSPRINT ab. Die Nachrichten CRAZ1803E, CRAZ1891E, CRAZ1892E und CRAZ1893E enthalten Dateistatuscodes, VSAM-Rückkehrcodes, VSAM-Funktionscodes und VSAM-Rückkopplungscodes. Rückkehr-, Funktions- und Rückkopplungscodes für VSAM sind in der Veröffentlichung DFSMS Macro Instructions for Data Sets (IBM Form SC26-7408) dokumentiert. Dateistatuscodes sind in der Veröffentlichung Enterprise COBOL for z/OS Language Reference (IBM Form SC27-1408) dokumentiert.
Erläuterung: Das Verwaltungsdienstprogramm für Systemprogrammierer wurde erfolgreich beendet.
Benutzeraktion: Keine
Erläuterung: Das Verwaltungsdienstprogramm für Systemprogrammierer wurde mit Warnungen beendet, die während der Verarbeitung von Steueranweisungen festgestellt wurden.
Benutzeraktion: Überprüfen Sie die weiteren Warnungen.
Erläuterung: Das Verwaltungsdienstprogramm für Systemprogrammierer hat einen schwerwiegenden Fehler festgestellt.
Benutzeraktion: Überprüfen Sie die weiteren Warnungen.
Erläuterung: Das Verwaltungsdienstprogramm für Systemprogrammierer hat einen schwerwiegenden Fehler beim Öffnen des CRD-Repositorys festgestellt.
Benutzeraktion: Überprüfen Sie die VSAM-Statuscodes, -Rückkehr-, -Funktions- und -Rückkopplungscodes.
Erläuterung: Das Verwaltungsdienstprogramm für Systemprogrammierer hat eine nicht erkannte Eingabesteueranweisung gefunden.
Benutzeraktion: Überprüfen Sie, ob auf einen Befehl DEFINE ein Leerzeichen und dann das Schlüsselwort CPSMNAME, STAGINGGROUPNAME, MANIFESTEXPORTRULE, DSBINDING, DB2TRAN, DOCTEMPLATE, FILE, MAPSET, PROCESSTYPE, PROGRAM, TDQUEUE oder TRANSACTION folgt.
Erläuterung: Das Verwaltungsdienstprogramm für Systemprogrammierer verarbeitet die Eingabesteueranweisung (Schlüsselwort DEFINE).
Benutzeraktion: Keine
Erläuterung: Das Verwaltungsdienstprogramm für Systemprogrammierer hat eine ungültige Manifestexportregel gefunden.
Benutzeraktion: Überprüfen Sie, ob der Wert des Schlüsselworts MANIFESTEXPORTRULE 'installOnly', 'exportOnly' oder 'both' lautet.
Erläuterung: Das Verwaltungsdienstprogramm für Systemprogrammierer hat eine Steueranweisung DEFINE DSBINDING verarbeitet, bei der das Schlüsselwort DSNAME fehlt.
Benutzeraktion: Überprüfen Sie, ob die Steueranweisung DEFINE DSBINDING das Schlüsselwort DSNAME enthält.
Erläuterung: Das Verwaltungsdienstprogramm für Systemprogrammierer hat eine Steueranweisung DEFINE verarbeitet und für das benannte Schlüsselwort einen ungültigen Wert festgestellt.
Benutzeraktion: Überprüfen Sie, ob die Länge und der Wert des benannten Schlüsselworts korrekt ist.
Erläuterung: Das Verwaltungsdienstprogramm für Systemprogrammierer hat eine Steueranweisung DEFINE verarbeitet und für ein Schlüsselwort oder den Wert eines Schlüsselwortes einen Syntaxfehler festgestellt.
Benutzeraktion: Überprüfen Sie, ob der Wert des Schlüsselworts in runde Klammern eingeschlossen ist und unmittelbar auf das Schlüsselwort folgt. Das Schlüsselwort und der zugehörige Wert müssen sich in derselben Zeile befinden.
Erläuterung: Das Verwaltungsdienstprogramm für Systemprogrammierer hat beim Schreiben in das CRD-Repository einen doppelt vorhandenen Schlüssel gefunden. Dies ist ein Fehler.
Benutzeraktion: Überprüfen Sie die VSAM-Statuscodes, -Rückkehr-, -Funktions- und -Rückkopplungscodes.
Erläuterung: Das Verwaltungsdienstprogramm für Systemprogrammierer hat beim Schreiben in das CRD-Repository einen schwerwiegenden Fehler festgestellt.
Benutzeraktion: Überprüfen Sie die VSAM-Statuscodes, -Rückkehr-, -Funktions- und -Rückkopplungscodes.
Erläuterung: Das Verwaltungsdienstprogramm für Systemprogrammierer hat einen schwerwiegenden Fehler beim Lesen des CRD-Repositorys festgestellt.
Benutzeraktion: Überprüfen Sie die VSAM-Statuscodes, -Rückkehr-, -Funktions- und -Rückkopplungscodes.
Definieren Sie den Debugger für eine CICS-Region, wie im Beispiel-CSD-Aktualisierungsjob AQECSD dokumentiert. AQECSD befindet sind in FEK.#CUST.JCL, sofern der z/OS-Systemprogrammierer nicht eine andere Position angegeben hat, als er den Job FEK.SFEKSAMP(FEKSETUP) angepasst und übergeben hat. Weitere Informationen finden Sie unter "Anpassungskonfiguration" im Handbuch Hostkonfiguration (IBM Form SC12-4062).
In diesem Kapitel finden Sie Informationen dazu, wie Sie Exitroutinen schreiben können, die Developer for System z funktional erweitern.
Developer for System z stellt Exitpunkte für ausgewählte Developer for System z-Ereignisse bereit. Ein Exitpunkt ist ein bestimmter Punkt in der Verarbeitung einer Funktion, an dem die Funktion eine Exitroutine aufruft, sofern eine solche vorhanden ist. Sie können eine Exitroutine schreiben, um eine zusätzliche Verarbeitung auszuführen.
Beachten Sie, dass es bei Developer for System z-Exitpunkten anders als bei den meisten üblichen Exitpunkten nicht zulässig ist, das Verhalten der Funktion zu ändern. Falls eine Exitroutine vorhanden ist, wird diese asynchron aufgerufen, nachdem die Funktion beendet wurde. Die Verarbeitung von Developer for System z wartet nicht auf das Beenden der Exitroutine, auch wird der Fertigstellungsstatus nicht überprüft.
#_RSE_JAVAOPTS="$_RSE_JAVAOPTS -D<exit_point>.action=<user_exit>"
#_RSE_JAVAOPTS="$_RSE_JAVAOPTS -D<exit_point>.action.id=<userid>"
Die dem RSE-Dämon zugeordnete Benutzer-ID wird standardmäßig zum Ausführen der bereitgestellten Exitroutine verwendet. Entfernen Sie die Kommentarzeichen und geben Sie eine Benutzer-ID an, um die angegebene Benutzer-ID zum Ausführen des Benutzerexits zu verwenden. Sie müssen kein Kennwort angeben, da RSE ein PassTicket erstellt, das beim Wechsel zur angegebenen Benutzer-ID als Kennwort verwendet wird.
Benutzerexitroutinen werden als z/OS UNIX-Shellbefehl mit mindestens einem Argument aufgerufen. Dies bedeutet, dass die von Ihnen entwickelte Exitroutine über die z/OS UNIX-Befehlszeile ausführbar sein muss. Zu den üblichen Codierungsverfahren gehören das z/OS UNIX-Shell-Script und die z/OS UNIX-REXX-Exec, aber auch kompilierter Code wie C/C++ ist möglich.
Im Benutzerhandbuch UNIX System Services User's Guide (IBM Form SA22-7801) finden Sie weitere Informationen zu z/OS UNIX-Shell-Scripts. Weitere Informationen zu z/OS UNIX-spezifischen Erweiterungen der REXX-Sprache enthält die Dokumentation Using REXX and z/OS UNIX System Services (IBM Form SA22-7806).
$ chmod 755 process_logon.sh
$ ls -l process_logon.sh
-rwxr-xr-x 1 IBMUSER SYS1 2228 Feb 28 23:44 process_logon.sh
Definitionen in rsed.envvars stehen der Benutzerexitroutine als Umgebungsvariablen zur Verfügung.
RSE ruft die Benutzerexitroutine mithilfe einer einzelnen Argumentenfolge auf. Die Argumentenfolge kann aus einem einzigen Wert oder einer einzelnen Zeichenfolge bestehen, die mehrere leere Schlüsselwörter und Werte mit Begrenzern enthält. Ausführliche Informationen hierzu enthält der Abschnitt Verfügbare Exitpunkte.
Developer for System z verwendet die Konsolennachricht-ID FEK910I, um Daten anzuzeigen, die zu Benutzerexits zugehörig sind.
FEK910I <EXIT_POINT> EXIT: invoking <exit_point> processing exit
in thread <thread_id>
FEK910I <EXIT_POINT> EXIT: <message>
FEK910I <EXIT_POINT> EXIT: completed <exit_point> processing exit
in thread <thread_id>
Developer for System z ermöglicht Ihnen, eine Exitroutine sowohl mithilfe der Benutzer-ID der gestarteten Task als auch mit einer angegebenen Benutzer-ID auszuführen. Möglicherweise möchten Sie jedoch einige Aktionen in der Exitroutine mithilfe einer weiteren Benutzer-ID ausführen, wie z. B. der Client-Benutzer-ID in der Exitroutine 'logon'. Führen Sie dies aus, indem Sie die z/OS UNIX-Standardservices verwenden, wie in den folgenden Beispielen gezeigt.
#! /bin/sh
myID=ibmuser
echo a $(id)
echo 'echo b $(id)' | su -s $myID
echo "echo c \$(id)" | su -s $myID
cat /u/ibmuser/iefbr14
echo "submit /u/ibmuser/iefbr14" | su -s $myID
Dieser Beispielexit 'logon', der von der Benutzer-ID der gestarteten Task ausgeführt wurde, führt zur Ausgabe der folgenden Konsolennachricht:
+FEK910I LOGON EXIT: invoking logon processing exit in thread 411
+FEK910I LOGON EXIT: a uid=8(STCRSE) gid=1(STCGROUP)
+FEK910I LOGON EXIT: b uid=1(IBMUSER) gid=0(SYS1)
+FEK910I LOGON EXIT: c uid=1(IBMUSER) gid=0(SYS1)
+FEK910I LOGON EXIT: //IEFBR14 JOB CLASS=A,MSGCLASS=A,MSGLEVEL=(1,1)
+FEK910I LOGON EXIT: //IEFBR14 EXEC PGM=IEFBR14
$HASP100 IEFBR14 ON INTRDR FROM STC03919
IBMUSER
IRR010I USERID IBMUSER IS ASSIGNED TO THIS JOB.
+FEK910I LOGON EXIT: JOB JOB03926 submitted from path '/u/ibmuser/iefbr14'
ICH70001I IBMUSER LAST ACCESS AT 00:46:13 ON MONDAY, MARCH 19, 2012
$HASP373 IEFBR14 STARTED - INIT 2 - CLASS A - SYS CD08
IEF403I IEFBR14 - STARTED - TIME=00.46.14
+FEK910I LOGON EXIT: completed logon processing exit in thread 411
IEFBR14 IEFBR14 IEFBR14 0000
IEF404I IEFBR14 - ENDED - TIME=00.46.14
$HASP395 IEFBR14 ENDED
$HASP309 INIT 2 INACTIVE ******** C=BA
/* rexx */
myID='ibmuser'
say userid()
address SYSCALL 'getpwnam' myID 'pw.'
say pw.1 pw.2 pw.3 pw.4 pw.5
address SYSCALL 'seteuid' pw.2 /* PW_UID = 2 */
say retval errno errnojr
say userid()
Dieser Beispielexit 'logon', der von der Benutzer-ID der gestarteten Task ausgeführt wurde, führt zur Ausgabe der folgenden Konsolennachricht:
+FEK910I LOGON EXIT: invoking logon processing exit in thread 515
+FEK910I LOGON EXIT: STCRSE
+FEK910I LOGON EXIT: IBMUSER 1 0 / /bin/sh
+FEK910I LOGON EXIT: 0 0 0
+FEK910I LOGON EXIT: IBMUSER
+FEK910I LOGON EXIT: completed logon processing exit in thread 515
Der Benutzerexit 'audit' wird aufgerufen, wenn die aktive Prüfprotokolldatei geschlossen ist. (Die Prüfung wird fortgeführt, da RSE zu einer neuen Prüfprotokolldatei gewechselt hat.)
/usr/lpp/rdz/samples/process_audit.rex
Dieses Beispiel für einen z/OS UNIX-REXX-Exec erstellt einen Batch-Job, der das geschlossene Prüfprotokoll verarbeiten wird.
Der Benutzerexit 'logon' wird aufgerufen, wenn ein Benutzer den Anmeldeprozess abgeschlossen hat.
/usr/lpp/rdz/samples/process_logon.sh
Mit diesem Beispiel für ein z/OS UNIX-Shell-Script wird eine Anmeldenachricht an die Konsole geschrieben.
Dieses Kapitel soll Sie beim Imitieren einer TSO-Anmeldeprozedur durch das Hinzufügen von DD-Anweisungen und Dateien zur TSO-Umgebung in Developer for System z unterstützen.
TSO Commands Service ist die Komponente von Developer for System z, mit der TSO-Befehle und ISPF-Befehle (Batchbefehle) ausgeführt werden und die das Ergebnis an den anfordernden Client zurückgibt. Diese Befehle können implizit vom Produkt oder explizit vom Benutzer angefordert werden.
Die im Lieferumfang von Developer for System z enthaltenen Beispielmember erstellen eine minimale TSO/ISPF-Umgebung. Falls die Entwickler in Ihrem Unternehmen den Zugriff auf angepasste Bibliotheken oder auf Bibliotheken anderer Anbieter benötigen, muss der z/OS-Systemprogrammierer zur Umgebung von TSO Commands Service die erforderlichen DD-Anweisungen und Bibliotheken hinzufügen. Die zugrunde liegende Logik ist identisch mit der des TSO-Anmeldeverfahrens, auch wenn die Implementierung in Developer for System z eine andere ist.
Die Konfigurationsdatei ISPF.conf (standardmäßig im Verzeichnis /etc/rdz/) definiert die von Developer for System z verwendete TSO/ISPF-Umgebung. Es gibt nur eine aktive Konfigurationsdatei ISPF.conf, die alle Benutzer von Developer for System z verwenden.
sysproc=ISP.SISPCLIB,FEK.SFEKPROC
ispmlib=ISP.SISPMENU
isptlib=ISP.SISPTENU
ispplib=ISP.SISPPENU
ispslib=ISP.SISPSLIB
ispllib=ISP.SISPLOAD
myDD=HLQ1.LLQ1,HLQ2.LLQ2
#_RSE_ISPF_OPTS="$_RSE_ISPF_OPTS&ISPPROF=&SYSUID..ISPPROF"
Entfernen Sie das Kommentarzeichen für die Anweisung (indem Sie das Nummernzeichen (#) vor der Anweisung entfernen) und geben Sie den vollständig qualifizierten Dateinamen des vorhandenen ISPF-Profils an, um diese Funktion zu nutzen.
*allocjob = ISP.SISPSAMP(ISPZISP2)
ISPF.conf unterstützt nur den Aufruf einer Zuordnungs-Exec. Für Aufrufe weiterer Execs von dieser Exec aus gibt es jedoch keine Begrenzung. Die Benutzer-ID des Clients, die als Parameter übergeben wird, ermöglicht den Aufruf personalisierter Zuordnungs-Execs. Sie können beispielsweise prüfen, ob das Member USERID’.EXEC(ALLOC)’ vorhanden ist, und dieses ggf. ausführen.
Falls die zuvor beschriebenen Szenarien mit Zuordnungs-Execs Ihren Anforderungen nicht genügen, können Sie andere Instanzen des RSE-Kommunikationsservers von Developer for System z erstellen, wobei jede Instanz ihre eigene ISPF.conf-Datei verwendet. Die folgende Methode hat im Wesentlichen den Nachteil, dass die Benutzer von Developer for System z eine Verbindung zu verschiedenen Servern auf demselben Host herstellen müssen, um die gewünschte TSO-Umgebung zu erhalten.
$ cd /etc/rdz
$ mkdir /etc/rdz/tso2
$ cp rsed.envvars /etc/rdz/tso2
$ cp ISPF.conf /etc/rdz/tso2
$ ls /etc/rdz/tso2
ISPF.conf rsed.envvars
$ oedit /etc/rdz/tso2/rsed.envvars
-> change: _RSE_RSED_PORT=4037
-> change: CGI_ISPCONF=/etc/rdz/tso2
-> ändern: -Ddaemon.log=/var/rdz/logs/tso2
-> ändern: -Duser.log=/var/rdz/logs/tso2
-> am ENDE hinzufügen:
# -- NEEDED TO FIND THE REMAINING CONFIGURATION FILES
CFG_BASE=/etc/rdz
CLASSPATH=.:$CFG_BASE:$CLASSPATH
# --
$ oedit /etc/rdz/tso2/ISPF.conf
-> ändern: nach Bedarf ändern
Mit den Befehlen im vorherigen Beispiel werden die Konfigurationsdateien für Developer for System z, die geändert werden müssen, in ein neu erstelltes Verzeichnis tso2 kopiert. Die Variable CGI_ISPCONF in rsed.envvars muss aktualisiert werden, damit sie das neue Ausgangsverzeichnis in ISPF.conf definiert. Außerdem müssen daemon.log und user.log aktualisiert werden, um eine neue Protokollposition zu definieren. (Die Position wird automatisch erstellt, wenn sie nicht vorhanden ist.) Mit der Aktualisierung von _RSE_RSED_PORT wird sichergestellt, dass der vorhandene und der neue RSE-Dämon eindeutige Portnummern verwenden. Mit der Aktualisierung von CLASSPATH wird sichergestellt, dass RSE die Konfigurationsdateien auffindet, die nicht nach tso2 kopiert wurden. Die Datei ISPF.conf selbst können Sie entsprechend Ihren Anforderungen aktualisieren. Beachten Sie, dass der ISPF-Arbeitsbereich (Variable CGI_ISPWORK in rsed.envvars) von beiden Instanzen gemeinsam genutzt werden kann.
Jetzt müssen Sie nur noch eine neue gestartete Task für RSE erstellen, die eine neue Portnummer und die neuen Konfigurationsdateien in /etc/rdz/tso2 verwendet. Wenn _RSE_RSED_PORT nicht in rsed.envvars geändert wird, muss die neue gestartete Task einen neuen Port als Startargument angeben.
Weitere Informationen zu den zuvor in diesem Abschnitt beschriebenen Aktionen finden Sie im Handbuch IBM Rational Developer for System z Hostkonfiguration (IBM Form SC12-4062).
In bestimmten Situationen, z. B. beim Testen eines Upgrades, kann die Ausführung mehrerer aktiver Instanzen von Developer for System z auf demselben System erwünscht sein. Manche Ressourcen können jedoch nicht gemeinsam genutzt werden, z. B. TCP/IP-Ports, sodass die Standardeinstellungen nicht immer anwendbar sind. Anhand der Informationen in diesem Abschnitt können Sie die Koexistenz verschiedener Instanzen von Developer for System z planen, um sie dann gestützt auf dieses Konfigurationshandbuch anzupassen.
Die gemeinsame Nutzung bestimmter Komponenten von Developer for System z durch zwei (oder mehr) Instanzen ist zwar möglich, wird jedoch NUR empfohlen, wenn die Softwareversionen identisch sind und es außer Änderungen an Konfigurationsmembern keine weiteren Änderungen gibt. Developer for System z bietet genug Anpassungsspielraum für die Erstellung mehrerer Instanzen ohne Überschneidung. Wir raten Ihnen dringend, diese Anpassungsfeatures zu nutzen.
Unter ganz bestimmten Umständen können Sie (fast) alle anpassbaren Komponenten gemeinsam nutzen. Eines der Beispiele ermöglicht für die Nutzung vor Ort den Zugriff ohne SSL und für die Nutzung an einem anderen Standort die mit SSL verschlüsselte Kommunikation.
Achtung: Mit der gemeinsam genutzten Konfiguration ist es NICHT möglich, ein Wartungsrelease, eine technische Vorschau oder ein neues Release sicher zu testen.
|
Wenn Sie eine andere Instanz einer aktiven Installation von Developer for System z konfigurieren möchten, führen Sie erneut die Anpassungsschritte für die Komponenten aus, die unterschiedlich sind. Verwenden Sie dazu verschiedene Dateien, Verzeichnisse und Ports, um Überschneidungen mit der aktuellen Konfiguration zu vermeiden.
In dem vorangegangenen SSL-Beispiel kann die aktuelle RSE-Dämonkonfiguration geklont werden. Im Anschluss daran können Sie die geklonte Konfiguration aktualisieren. Als Nächstes können Sie die JCL für den RSE-Dämonstart klonen und dann durch Angabe eines neuen TCP/IP-Ports und der Position der aktualisierten Konfigurationsdateien anpassen. Die MVS-Anpassungen (JES Job Monitor usw.) können von SSL-Instanzen und Nicht-SSL-Instanzen gemeinsam genutzt werden. Dies würde die folgenden Aktionen erforderlich machen:
$ cd /etc/rdz
$ mkdir /etc/rdz/ssl
$ cp rsed.envvars /etc/rdz/ssl
$ cp ssl.properties /etc/rdz/ssl
$ ls /etc/rdz/ssl/
rsed.envvars ssl.properties
$ oedit /etc/rdz/ssl/rsed.envvars
-> ändern: _RSE_RSED_PORT=4047
-> ändern: -Ddaemon.log=/var/rdz/logs/ssl
-> ändern: -Duser.log=/var/rdz/logs/ssl
-> am ENDE hinzufügen:
# -- NEEDED TO FIND THE REMAINING CONFIGURATION FILES
CFG_BASE=/etc/rdz
CLASSPATH=.:$CFG_BASE:$CLASSPATH
# --
$ oedit /etc/rdz/ssl/ssl.properties
-> ändern: nach Bedarf ändern
Mit den Befehlen im vorherigen Beispiel werden die Konfigurationsdateien für Developer for System z, die geändert werden müssen, in ein neu erstelltes Verzeichnis ssl kopiert. Die Variablen daemon.log und user.log in rsed.envvars muss aktualisiert werden, um eine neue Protokollposition zu definieren. (Die Position wird automatisch erstellt, wenn sie noch nicht vorhanden ist.) Mit der Aktualisierung von CLASSPATH wird sichergestellt, dass RSE die Konfigurationsdateien finden kann, die nicht nach ssl kopiert wurden. Die Datei ssl.properties selbst können Sie entsprechend Ihren Anforderungen aktualisieren.
Jetzt müssen Sie nur noch eine neue gestartete Task für RSE erstellen, die eine neue Portnummer und die neuen Konfigurationsdateien in /etc/rdz/ssl verwendet.
Weitere Informationen zu den zuvor in diesem Abschnitt beschriebenen Aktionen enthalten die entsprechenden Abschnitte im Handbuch IBM Rational Developer for System z Hostkonfiguration (IBM Form SC12-4062).
In dem vorangegangenen SSL-Beispiel sind die Änderungen zwischen dem RSE-Dämon mit SSL-Aktivierung und dem RSE-Dämon ohne SSL minimal. Dies ermöglicht eine Automatisierung der Schritte für die Synchronisierung der entsprechenden rsed.envvars-Dateien. Hierdurch wird der Service-Rollout vereinfacht, da nur eine Datei rsed.envvars gepflegt und verwaltet werden muss.
Im folgenden Beispiel wird die RSED-Portnummer zu den Protokollverzeichnisnamen hinzugefügt. Außerdem wird der CLASSPATH aktualisiert, sodass Klone die übrigen Konfigurationsdateien finden können. Dann führt das Beispiel eine Erweiterung für die JCL der gestarteten Task des RSE-Dämons mit SSL-Aktivierung durch, um beim Startvorgang die Datei rsed.envvars des RSE-Dämons ohne SSL zu klonen und dabei die Portnummer zu aktualisieren. Da die Portnummer im Protokollverzeichnisnamen eingebettet ist, weicht sie für die beiden Dämonen jeweils ab.
$ oedit /etc/rdz/rsed.envvars
-> Ändern: -Ddaemon.log=/var/rdz/logs/$RSE_RSED_PORT
-> Ändern: -Duser.log=/var/rdz/logs/$RSE_RSED_PORT
-> Am ENDE anfügen:
# -- WIRD VON KLONEN BENÖTIGT, UM DIE ÜBRIGEN KONFIGURATIONSDATEIEN ZU FINDEN
CFG_BASE=/etc/rdz
CLASSPATH=.:$CFG_BASE:$CLASSPATH
# --
$ mkdir /etc/rdz/ssl
$ cp /etc/rdz/ssl.properties /etc/rdz/etc/rdz/ssl
$ oedit /etc/rdz/ssl/ssl.properties
-> Ändern: nach Bedarf ändern
//*
//* RSE-DÄMON - SSL
//*
//RSED PROC IVP=, * 'IVP' für einen IVP-Test
// HOME='/usr/lpp/rdz',
// CNFG='/etc/rdz/ssl'
//*
// SET SED='"/RSED_PORT/s/4035/4034/"'
// SET FILE='rsed.envvars'
//*
//* Kopieren von /etc/rdz/rsed.envvars nach /etc/rdz/ssl/rsed.envvars
//* und Ändern von RSED_PORT
//*
//CLONE EXEC PGM=BPXBATCH,REGION=0M,COND=(4,LT),
// PARM='SH cd &CNFG;sed &SED ../&FILE>&FILE'
//STDOUT DD SYSOUT=*
//STDERR DD SYSOUT=*
//*
//* Starten von RSED mit der neu erstellten Datei rsed.envvars
//*
//RSED EXEC PGM=BPXBATSL,REGION=0M,TIME=NOLIMIT,COND=(4,LT),
// PARM='PGM &HOME./bin/rsed.sh &IVP -C&CNFG'
//STDOUT DD SYSOUT=*
//STDERR DD SYSOUT=*
// PEND
//*
Wenn Codeänderungen vorgenommen werden müssen (Wartungsrelease, technische Neuentwicklungen, neues Release) oder Ihre Änderungen ziemlich komplex sind, sollten Sie Developer for System z neu installieren. In diesem Abschnitt sind mögliche Konfliktpunkte zwischen den verschiedenen Installationen beschrieben.
Die folgende Liste gibt Ihnen einen kurzen Überblick über die Elemente, die bei den Instanzen von Developer for System z unbedingt verschieden sein sollten oder müssen:
Die einzelnen Elemente sind in der folgenden Übersicht detaillierter beschrieben.
In der Veröffentlichung Developer for System z Messages and Codes (IBM Form SC14-7497) werden Nachrichten und Rückkehrcodes dokumentiert, die von Developer for System z-Komponenten generiert wurden. Developer for System z Antworten auf gängige Fragen der Hostkonfiguration und -wartung (IBM Form SC12-4724) beschreibt verschiedene Problemszenarien und die Lösungen dazu.
Weitere Informationen sind im Bereich "Support" der Website zu Developer for System z (http://www-03.ibm.com/software/products/us/en/developerforsystemz/) verfügbar. Dort finden Sie die aktuellsten technischen Hinweise (Technotes) des Unterstützungsteams.
Die aktuellste Version der Dokumentation zu Developer for System z einschließlich White Papers finden Sie im Abschnitt "Library" der Website (http://www-01.ibm.com/support/docview.wss?uid=swg27038517).
Im Information Center für Developer for System z (http://www-01.ibm.com/support/knowledgecenter/SSQ2R2_9.1.0/com.ibm.etools.getstart.wsentdev.doc/kc_version_welcome_rdz.html) ist der Developer for System z-Client und seine Interaktion mit dem Host (aus der Sicht des Clients) dokumentiert.
Wertvolle Informationen enthält auch die z/OS-Internetbibliothek mit der Adresse http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/.
https://www.ibm.com/developerworks/support/rational/rfe/
Die gestartete RSED-Task unterstützt den Bedienerbefehl MODIFY LOGS, um Hostprotokolle und Konfigurationsdaten von Developer for System z zu erfassen. Die erfassten Daten werden in eine z/OS UNIX-Datei namens $TMPDIR/feklogs.%sysname.%jobname eingefügt, wobei $TMPDIR der Wert der Direktive TMPDIR in rsed.envvars ist (standardmäßig /tmp), %sysname Ihr z/OS-Systemname ist und %jobname der Name der gestarteten RSED-Task ist.
Standardmäßig werden nur die Serverprotokolle erfasst. Befehlsoptionen ermöglichen es Ihnen, verschiedene Protokolle zu erfassen:
USER | Erfassen Protokolldateien für die angegebenen Benutzer-IDs. |
AUDIT | Erfassen Prüfprotokolle. |
NOSERVER | Erfassen keine Serverprotokolle. |
Developer for System z fragt Ihr Sicherheitsprodukt nach Zugriffsberechtigungen für FEK.CMD.LOGS.**-Profile ab, um zu bestimmen, ob der Anforderer die angegebenen Protokolle erfassen darf. Standardmäßig handelt es sich bei dem Anforderer um die Benutzer-ID der gestarteten RSED-Task, es sei denn, die Option OWNER ist angegeben. Nur der Anforderer hat Zugriff auf die Datei mit den erfassten Daten.
Zum Erfassen von Daten, bevor die gestartete RSED-Task gestartet werden kann, stellt Developer for System z einen Beispieljob namens FEKLOGS bereit, der alle z/OS UNIX-Protokolldateien sowie alle Developer for System z-Installations- und -Konfigurationsdaten zusammenstellt.
Der Beispieljob FEKLOGS ist in FEK.#CUST.JCL enthalten, sofern Sie während der Anpassung und Übergabe des Jobs FEK.SFEKSAMP(FEKSETUP) keine andere Position angegeben haben. Weitere Details hierzu finden Sie in "Angepasstes Setup" in Hostkonfiguration (IBM Form SC12-4062).
Die Anpassung von FEKLOGS wird in der JCL beschrieben. Die Anpassung schließt die Bereitstellung einiger Schlüsselvariablen ein.
Developer for System z erstellt Protokolldateien, die Sie und das IBM Support Center bei der Feststellung und Lösung von Problemen unterstützen können. Nachfolgend sind die Protokolldateien, die auf Ihrem z/OS-Hostsystem erstellt werden können, übersichtlich aufgelistet. Überprüfen Sie neben diesen produktspezifischen Protokollen stets, ob das SYSLOG zugehörige Nachrichten enthält.
Nach MVS-basierten Protokollen kann über die entsprechende DD-Anweisung gesucht werden. z/OS UNIX-basierte Protokolldateien befinden sich in den folgenden Verzeichnissen:
Benutzerspezifische Protokolldateien werden in userlog/$LOGNAME gespeichert. Dabei ist userlog der kombinierte Wert der Anweisungen user.log und DSTORE_LOG_DIRECTORY in rsed.envvars und $LOGNAME ist die Anmeldebenutzer-ID (in Großbuchstaben). Wenn die Anweisung user.log in Kommentarzeichen gesetzt wurde oder nicht vorhanden ist, wird der Ausgangspfad des Benutzers verwendet. Der Ausgangspfad ist im OMVS-Sicherheitssegment der Benutzer-ID definiert. Wenn die Anweisung DSTORE_LOG_DIRECTORY in Kommentarzeichen gesetzt wurde oder nicht vorhanden ist, wird .eclipse/RSE/ an den Wert von user.log angehängt.
Die Protokolldateien des RSE-Dämons und des RSE-Thread-Pools befinden sich in daemon-home/server. Dabei steht daemon-home für den Wert der Anweisung daemon.log in rsed.envvars. Wenn die Anweisung daemon.log in Kommentarzeichen gesetzt wurde oder nicht vorhanden ist, wird der Ausgangspfad der Benutzer-ID verwendet, die der gestarteten Task RSED zugeordnet ist. Das Ausgangsverzeichnis ist im Segment für die OMVS-Sicherheit der Benutzer-ID definiert.
IVP-spezifische Protokolldateien (Installation Verification Program, Installationsprüfprogramm) befinden sich in dem Verzeichnis, das von TMPDIR referenziert wird, wenn diese Variable in rsed.envvars definiert ist. Wenn die Variable nicht definiert ist, werden die Dateien im Verzeichnis /tmp erstellt. Der Bedienerbefehl MODIFY LOGS für die gestartete RSED-Task erstellt seine Ausgabe auch in diesem Verzeichnis.
Trace-Protokollierung und Protokollierung normaler Operationen. Der Standardwert in der Beispiel-JCL FEK.#CUST.PROCLIB(DBGMGR) ist SYSOUT=*.
Es werden normale Operationen protokolliert. Der Standardwert in der Beispiel-JCL FEK.#CUST.PROCLIB(JMON) ist SYSOUT=*.
Trace-Protokollierung. Der Standardwert in der Beispiel-JCL FEK.#CUST.PROCLIB(JMON) ist SYSOUT=*. Der Trace wird mit dem Parameter –TV aktiviert. Weitere Details hierzu enthält der Abschnitt JES Job Monitor, Traceerstellung.
Umgeleitete Daten von der Java-Standardausgabe stdout des RSE-Dämons. Der Standardwert in der Beispiel-JCL FEK.#CUST.PROCLIB(RSED) ist SYSOUT=*.
Umgeleitete Daten von der Java-Standardfehlerausgabe stderr des RSE-Dämons. Der Standardwert in der Beispiel-JCL FEK.#CUST.PROCLIB(RSED) ist SYSOUT=*.
Die Protokolldateien des RSE-Dämons und des RSE-Thread-Pools befinden sich in daemon-home. Dabei steht daemon-home für den Wert der Anweisung daemon.log in rsed.envvars. Wenn die Anweisung daemon.log in Kommentarzeichen gesetzt wurde oder nicht vorhanden ist, wird der Ausgangspfad der Benutzer-ID verwendet, die der gestarteten Task RSED zugeordnet ist. Das Ausgangsverzeichnis ist im Segment für die OMVS-Sicherheit der Benutzer-ID definiert.
Die RSE-bezogenen Komponenten erstellen diverse Protokolldateien. Alle Dateien werden in userlog/$LOGNAME gespeichert. Dabei ist userlog der kombinierte Wert der Anweisungen user.log und DSTORE_LOG_DIRECTORY in rsed.envvars und $LOGNAME ist die Anmeldebenutzer-ID (in Großbuchstaben). Wenn die Anweisung user.log in Kommentarzeichen gesetzt wurde oder nicht vorhanden ist, wird der Ausgangspfad des Benutzers verwendet. Der Ausgangspfad ist im OMVS-Sicherheitssegment der Benutzer-ID definiert. Wenn die Anweisung DSTORE_LOG_DIRECTORY in Kommentarzeichen gesetzt wurde oder nicht vorhanden ist, wird .eclipse/RSE/ an den Wert von user.log angehängt.
Protokollierung der Kommunikation für SCLM Developer Toolkit. Dabei ist userlog der kombinierte Wert der Anweisungen user.log und DSTORE_LOG_DIRECTORY in rsed.envvars und $LOGNAME ist die Anmeldebenutzer-ID (in Großbuchstaben). Wenn die Anweisung user.log in Kommentarzeichen gesetzt wurde oder nicht vorhanden ist, wird der Ausgangspfad des Benutzers verwendet. Der Ausgangspfad ist im OMVS-Sicherheitssegment der Benutzer-ID definiert. Wenn die Anweisung DSTORE_LOG_DIRECTORY in Kommentarzeichen gesetzt wurde oder nicht vorhanden ist, wird .eclipse/RSE/ an den Wert von user.log angehängt.
Wenn Sie über die Batchschnittstelle eine Verbindung zu CARMA öffnen, startet FEK.#CUST.SYSPROC(CRASUBMT) einen Server-Job CRAport (mit der Benutzer-ID als Eigner). Die Angabe port im Namen steht hier für den verwendeten TCP/IP-Port.
Wenn in der ausgewählten CARMA-Startmethode die DD-Anweisung CARMALOG angegeben ist, wird die CARMA-Protokollierung an diese DD-Anweisung im Server-Job umgeleitet. Andernfalls ist sie auf der SYSPRINT-Karte enthalten.
Die SYSPRINT DD-Karte des Server-Jobs enthält die CARMA-Protokollierung, sofern nicht die DD-Anweisung "CARMALOG" definiert ist.
Die SYSTSPRT DD-Karte des Server-Jobs enthält die Systemnachrichten (TSO) für den Star t des CARMA-Servers.
Protokollierung der CARMA-Kommunikation. Dabei ist userlog der kombinierte Wert der Anweisungen user.log und DSTORE_LOG_DIRECTORY in rsed.envvars und $LOGNAME ist die Anmeldebenutzer-ID (in Großbuchstaben). Wenn die Anweisung user.log in Kommentarzeichen gesetzt wurde oder nicht vorhanden ist, wird der Ausgangspfad des Benutzers verwendet. Der Ausgangspfad ist im OMVS-Sicherheitssegment der Benutzer-ID definiert. Wenn die Anweisung DSTORE_LOG_DIRECTORY in Kommentarzeichen gesetzt wurde oder nicht vorhanden ist, wird .eclipse/RSE/ an den Wert von user.log angehängt.
Der Befehl fekfivpc (zu CARMA gehörender IVP-Test) erstellt die Datei fekfivpc.log, um die Kommunikation zwischen RSE und CARMA zu dokumentieren. Das Protokoll wird in dem Verzeichnis erstellt, das von TMPDIR referenziert wird, wenn diese Variable in rsed.envvars definiert ist. Wenn die Variable nicht definiert ist, wird die Datei im Verzeichnis /tmp erstellt.
Ausgabe des Befehls fekfivpi -file (zu TSO/ISPF-Client-Gateway gehörender IVP-Test). Das Protokoll wird in dem Verzeichnis erstellt, das von TMPDIR referenziert wird, wenn diese Variable in rsed.envvars definiert ist. Wenn die Variable nicht definiert ist, wird die Datei im Verzeichnis /tmp erstellt.
Ausgabe des Befehls fekfivps -file (zu SCLMDT gehörender IVP-Test). Das Protokoll wird in dem Verzeichnis erstellt, das von TMPDIR referenziert wird, wenn diese Variable in rsed.envvars definiert ist. Wenn die Variable nicht definiert ist, wird die Datei im Verzeichnis /tmp erstellt.
Das Element SYSTSPRT DD des Schritts, mit dem die Codeüberprüfungsprozedur aufgerufen wird, enthält die Nachrichten des Front-Ends, das den Codeanalyseprozess vorantreibt.
Das Element WORKSPCE DD des Schritts, mit dem die Codeüberprüfungsprozedur aufgerufen wird, enthält die Protokollnachrichten vom Eclipse-Arbeitsbereich des Codeanalyseprozesses.
Das Element ERRMSGS DD des Schritts, mit dem die Codeüberprüfungsprozedur aufgerufen wird, enthält die stderr-Ausgabe des Codeanalyseprozesses.
Das Element SYSTSPRT DD des Schritts, mit dem die Codeüberprüfungsprozedur aufgerufen wird, enthält die Nachrichten des Front-Ends, das den Codeanalyseprozess vorantreibt.
Das Element WORKSPCE DD des Schritts, mit dem die Codeüberprüfungsprozedur aufgerufen wird, enthält die Protokollnachrichten vom Eclipse-Arbeitsbereich des Codeanalyseprozesses.
Das Element ERRMSGS DD des Schritts, mit dem die Codeüberprüfungsprozedur aufgerufen wird, enthält die stderr-Ausgabe des Codeanalyseprozesses.
Wenn ein Produkt anormal beendet wird, wird ein Speicherauszug zur Unterstützung der Fehlerbestimmung erstellt. Verfügbarkeit und Position dieser Speicherauszüge hängen in hohem Maße von standortspezifischen Einstellungen ab. Eventuell werden die Speicherauszüge gar nicht oder nicht an den in den folgenden Abschnitten beschriebenen Positionen erstellt.
Wenn das Programm unter MVS ausgeführt wird, überprüfen Sie die Systemspeicherauszugsdateien und Ihre JCL (je nach Produkt) auf die folgenden DD-Anweisungen:
Weitere Informationen zu diesen DD-Anweisungen sind in den Veröffentlichungen MVS JCL Reference (IBM Form SA22-7597) und Language Environment Debugging Guide (IBM Form GA22-7560) enthalten.
Unter z/OS UNIX werden die meisten Speicherauszüge von Developer for System z durch die Java Virtual Machine (JVM) gesteuert.
Die JVM erstellt während ihrer Initialisierung eine Gruppe von Speicherauszugsagenten (SYSTDUMP und JAVADUMP). Sie können diese Speicherauszugsagenten mit der Umgebungsvariablen JAVA_DUMP_OPTS sowie in der Befehlszeile mit -Xdump außer Kraft setzen. JVM-Befehlszeilenoptionen sind in der Anweisung _RSE_JAVAOPTS der Datei rsed.envvars definiert. Ändern Sie die Speicherauszugseinstellungen nur auf Anweisung des IBM Support Center.
Der Speicherauszug wird in eine sequenzielle MVS-Datei geschrieben, deren Name standardmäßig die Form %uid.JVM.TDUMP.%job.D%y%m%d.T%H%M%S hat oder von der Umgebungsvariablen JAVA_DUMP_TDUMP_PATTERN bestimmt wird.
Variable | Verwendung |
---|---|
%uid | Benutzer-ID |
%job | Jobname |
%y | Jahr (2-stellig) |
%m | Monat (2-stellig) |
%d | Tag (2-stellig) |
%H | Stunde (2-stellig) |
%M | Minute (2-stellig) |
%S | Sekunde (2-stellig) |
Der Speicherauszug wird in eine z/OS UNIX-Datei mit dem Namen CEEDUMP.yyyymmdd.hhmmss.pid geschrieben. Dabei stehen yyyymmdd für das aktuelle Datum, hhmmss für die aktuelle Uhrzeit und pid für die ID des aktuellen Prozesses. Die möglichen Positionen dieser Datei sind im Abschnitt Positionen für z/OS UNIX-Speicherauszüge beschrieben.
Der Speicherauszug wird in eine z/OS UNIX-Datei mit dem Namen HEAPDUMP.yyyymmdd.hhmmss.pid.TXT geschrieben. Dabei stehen yyyymmdd für das aktuelle Datum, hhmmss für die aktuelle Uhrzeit und pid für die ID des aktuellen Prozesses. Die möglichen Positionen dieser Datei sind im Abschnitt Positionen für z/OS UNIX-Speicherauszüge beschrieben.
Beachten Sie, dass Developer for System z einen Bedienerbefehl bereitstellt, um diesen Speicherauszug auszulösen. Weitere Details finden Sie im Kapitel zu den Bedienerbefehlen in der Veröffentlichung Hostkonfiguration (IBM Form SC12-4062).
Der Speicherauszug wird in eine z/OS UNIX-Datei mit dem Namen JAVADUMP.yyyymmdd.hhmmss.pid.TXT geschrieben. Dabei stehen yyyymmdd für das aktuelle Datum, hhmmss für die aktuelle Uhrzeit und pid für die ID des aktuellen Prozesses. Die möglichen Positionen dieser Datei sind im Abschnitt Positionen für z/OS UNIX-Speicherauszüge beschrieben.
Beachten Sie, dass Developer for System z einen Bedienerbefehl bereitstellt, um diesen Speicherauszug auszulösen. Weitere Details finden Sie im Kapitel zu den Bedienerbefehlen in der Veröffentlichung Hostkonfiguration (IBM Form SC12-4062).
Weitere Informationen zu JVM-Speicherauszügen enthält der Java Diagnostic Guide (IBM Form SC34-6358). LE-spezifische Informationen finden Sie im Language Environment Debugging Guide (IBM Form GA22-7560).
Die JVM überprüft alle nachfolgend angegebenen Positionen auf ihr Vorhandensein und auf die Schreibberechtigungen. An der ersten verfügbaren Position werden die CEEDUMP-, HEAPDUMP- und JAVADUMP-Dateien gespeichert. Denken Sie daran, dass genug freier Plattenspeicherplatz vorhanden sein muss, damit die Speicherauszugsdatei ordnungsgemäß geschrieben werden kann.
Die Debug-Manager-Traceerstellung wird, wie im Abschnitt "Bedienerbefehle" im Handbuch Hostkonfiguration (IBM Form SC12-4062) beschrieben, vom Systembediener gesteuert.
Die Traceerstellung für JES Job Monitor wird, wie im Abschnitt "Bedienerbefehle" im Handbuch Hostkonfiguration (IBM Form SC12-4062) beschrieben, vom Systembediener gesteuert.
Die RSE-bezogenen Komponenten erstellen diverse Protokolldateien. Die meisten Dateien werden in userlog/$LOGNAME gespeichert. Dabei ist userlog der kombinierte Wert der Anweisungen user.log und DSTORE_LOG_DIRECTORY in rsed.envvars und $LOGNAME ist die Anmeldebenutzer-ID (in Großbuchstaben). Wenn die Anweisung user.log in Kommentarzeichen gesetzt wurde oder nicht vorhanden ist, wird der Ausgangspfad des Benutzers verwendet. Der Ausgangspfad ist im OMVS-Sicherheitssegment der Benutzer-ID definiert. Wenn die Anweisung DSTORE_LOG_DIRECTORY in Kommentarzeichen gesetzt wurde oder nicht vorhanden ist, wird .eclipse/RSE/ an den Wert von user.log angehängt.
Das in ffs*.log und rsecomm.log geschriebene Datenvolumen wird durch den Bedienerbefehl modify rsecommlog oder von der Einstellung debug_level in rsecomm.properties gesteuert. Weitere Details finden Sie im Abschnitt "Bedienerbefehle" im Handbuch Hostkonfiguration (IBM Form SC12-4062) und im Abschnitt "RSE-Traceerstellung (optional)" im Handbuch Hostkonfiguration (IBM Form SC12-4062).
Die Erstellung der .dstore*-Protokolldateien wird von den Java–DDSTORE_*-Startoptionen gesteuert. Lesen Sie hierzu die Informationen im Abschnitt "Zusätzliche Java-Startparameter mit _RSE_JAVAOPTS definieren" im Handbuch Hostkonfiguration (IBM Form SC12-4062).
Die Protokolldateien des RSE-Dämons und des RSE-Thread-Pools befinden sich in daemon-home. Dabei steht daemon-home für den Wert der Anweisung daemon.log in rsed.envvars. Wenn die Anweisung daemon.log in Kommentarzeichen gesetzt wurde oder nicht vorhanden ist, wird der Ausgangspfad der Benutzer-ID verwendet, die der gestarteten Task RSED zugeordnet ist. Das Ausgangsverzeichnis ist im Segment für die OMVS-Sicherheit der Benutzer-ID definiert.
Das in rsedaemon*.log und rseserver.log geschriebene Datenvolumen wird durch die Bedienerbefehle modify rsedaemonlog und modify rseserverlog oder von der Einstellung debug_level in rsecomm.properties gesteuert. Weitere Details finden Sie im Abschnitt "Bedienerbefehle" im Handbuch Hostkonfiguration (IBM Form SC12-4062) und im Abschnitt "RSE-Traceerstellung (optional)" im Handbuch Hostkonfiguration (IBM Form SC12-4062).
Die Dateien serverlogs.count, stderr.*.log und stdout.*.log werden nur erstellt, wenn die Anweisung enable.standard.log in rsed.envvars aktiv ist oder wenn die Funktion mit dem Bedienerbefehl modify rsestandardlog on dynamisch aktiviert wurde.
Den Umfang der von einem CARMA-Server generierten Trace-Informationen kann der Benutzer steuern,
indem er auf dem Client auf der Eigenschaftenregisterkarte der CARMA-Verbindung die
'Tracestufe' definiert. Folgende Optionen sind für die Tracestufe verfügbar:
Fehler
Weitere Informationen zur Position der Protokolldateien enthält der Abschnitt Protokolldateien.
Der z/OS-Systemprogrammierer kann den Umfang der von der
Startmethode CRASTART von CARMA generierten Traceinformationen durch Festlegen von
crastart.syslog in der Datei CRASRV.properties
und durch Festlegen der Debugstufe für 'rsecomm.log' in der Datei rsecomm.properties
oder über einen Bedienerbefehl steuern.
//COBOL EXEC PGM=IGYCRCTL,REGION=2048K,
//* PARM=('EXIT(ADEXIT(ELAXMGUX))',
// PARM=('EXIT(ADEXIT(''MAXTRACE'',ELAXMGUX))',
// 'ADATA',
// 'LIB',
// 'TEST(NONE,SYM,SEP)',
// 'LIST',
// 'FLAG(I,I)'&CICS &DB2 &COMP)
ABOUT TOO OPEN SIDEFILE1 - NAME = 'uid.DT021207.TT110823.M0000045.C0000000'
SUCCESSFUL OPEN SIDEFILE1 - NAME = 'uid.DT021207.TT110823.M0000045.C0000000'
ABOUT TOO OPEN SIDEFILE2 - NAME = 'uid.DT021207.TT110823.M0000111.C0000001'
SUCCESSFUL OPEN SIDEFILE2 - NAME = 'uid.DT021207.TT110823.M0000111.C0000001'
ABOUT TOO OPEN SIDEFILE3 - NAME = 'uid.DT021207.TT110823.M0000174.C0000002'
SUCCESSFUL OPEN SIDEFILE3 - NAME = 'uid.DT021207.TT110823.M0000174.C0000002'
ABOUT TOO OPEN SIDEFILE4 - NAME = 'uid.DT021207.TT110823.M0000236.C0000003'
SUCCESSFUL OPEN SIDEFILE4 - NAME = 'uid.DT021207.TT110823.M0000236.C0000003'
22 //COBOL.WSEDSF1 DD DISP=MOD,
// DSN=uid.ERRCOB.member.SF.Z682746.XML
23 //COBOL.WSEDSF2 DD DISP=MOD,
// DSN=uid.ERRCOB.member.SF.Z682747.XML
Developer for System z erfordert, dass für das z/OS UNIX-Dateisystem und einige z/OS UNIX-Dateien bestimmte Berechtigungsbits gesetzt sind.
Remote Systems Explorer (RSE) ist die Komponente von Developer for System z, die Kernservices wie die Verbindung vom Client zum Host bereitstellt. Diese Komponente muss in der Lage sein, Tasks wie die Erstellung der Sicherheitsumgebung für den Benutzer auszuführen.
Ähnliche Fehler (wie beispielsweise die Nachrichten BPXP014I und BPXP015I) können auftreten, wenn die Dateisysteme, auf denen sich die Java- oder z/OS UNIX-Binärdateien befinden, mit dem Parameter NOSETUID angehängt werden.
Mit dem TSO-Befehl ISHELL können Sie den aktuellen Status des Bits SETUID anzeigen. Wählen Sie in der ISHELL-Anzeige File_systems > 1. Mount table... aus, um die angehängten Dateisysteme aufzulisten. Mit dem Zeilenbefehl a können Sie die Attribute für das ausgewählte Dateisystem anzeigen. Das Feld “Ignore SETUID” sollte auf 0 gesetzt sein.
Remote Systems Explorer (RSE) ist die Komponente von Developer for System z, die Kernservices wie die Verbindung vom Client zum Host bereitstellt. Für die Ausführung von Tasks, z. B. die Umschaltung auf die Benutzer-ID des Clients, muss die Komponente programmgesteuert ausgeführt werden.
Während der SMP/E-Installation wird das z/OS UNIX-Programmsteuerungsbit dort gesetzt, wo es erforderlich ist, außer für die Java-Schnittstelle zu Ihrem Sicherheitsprodukt. Lesen Sie hierzu die Informationen unter Sicherheitsaspekte. Dieses Berechtigungsbit könnte verloren gehen, wenn Sie es nicht in einer manuell erstellten Kopie der Verzeichnisse von Developer for System z gesichert haben.
Verwenden Sie den z/OS UNIX-Befehl ls –E, ph>, um die erweiterten Attribute aufzulisten, in denen das Programmsteuerungsbit mit dem Buchstaben p markiert ist. Sehen Sie sich dazu das folgende Beispiel an ($ ist die z/OS UNIX-Eingabeaufforderung):
$ cd /usr/lpp/rdz
$ ls -E lib/fekf*
-rwxr-xr-x -ps- 2 user group 94208 Jul 8 12:31 lib/fekfdir.dll
$ cd /usr/lpp/rdz
$ su
# extattr +p lib/fekf*
# exit
$ ls -E lib/fekf*
-rwxr-xr-x -ps- 2 user group 94208 Jul 8 12:31 lib/fekfdir.dll
Remote Systems Explorer (RSE) ist die Komponente von Developer for System z, die Kernservices wie die Verbindung vom Client zum Host bereitstellt. Für die Ausführung von Tasks, wie das Anzeigen detaillierter Informationen zur Prozessressourcennutzung, muss die Komponente APF-autorisiert ausgeführt werden.
Das z/OS UNIX-APF-Bit wird während der SMP/E-Installation gesetzt, wo es erforderlich ist. Dieses Berechtigungsbit könnte verloren gehen, wenn Sie es nicht in einer manuell erstellten Kopie der Verzeichnisse von Developer for System z gesichert haben.
Verwenden Sie den z/OS UNIX-Befehl ls -E, um die erweiterten Attribute aufzulisten, in denen das APF-Bit mit dem Buchstaben a markiert ist. Sehen Sie sich hierzu das folgende Beispiel an ("$" ist die z/OS UNIX-Eingabeaufforderung):
$ cd /usr/lpp/rdz
$ ls -E bin/fekfrivp
-rwxr-xr-x aps- 2 user group 114688 Sep 17 06:41 bin/fekfrivp
Verwenden Sie den z/OS UNIX-Befehl extattr +a, um das APF-Bit manuell zu setzen. Sehen Sie sich hierzu das folgende Beispiel an ("$" und "#" sind die z/OS UNIX-Eingabeaufforderungen):
$ cd /usr/lpp/rdz
$ su
# extattr +a bin/fekfrivp
# exit
$ ls -E bin/fekfrivp
-rwxr-xr-x aps- 2 user group 114688 Sep 17 06:41 bin/fekfrivp
Einige der optionalen Services von Developer for System z erfordern, dass MVS-Lademodule für z/OS UNIX zur Verfügung stehen. Deshalb wird in z/OS UNIX ein Stub (eine Pseudodatei) mit aktiviertem 'Sticky Bit' erstellt. Wenn der Stub ausgeführt wird, sucht z/OS UNIX nach einem MVS-Lademodul mit demselben Namen und führt dieses anstelle des Stubs aus.
Das Sticky Bit für z/OS UNIX wird während der SMP/E-Installation gesetzt, wo es erforderlich ist. Derartige Berechtigungsbits können verloren gehen, wenn Sie sie nicht in einer manuell erstellten Kopie der Verzeichnisse von Developer for System z gesichert haben.
$ cd /usr/lpp/rdz
$ ls -l bin/CRA*
-rwxr-xr-t 2 user group 71 Jul 8 12:31 bin/CRASTART
$ cd /usr/lpp/rdz
$ su
# chmod +t bin/CRA*
# exit
$ ls -l bin/CRA*
-rwxr-xr-t 2 user group 71 Jul 8 12:31 bin/CRASTART
Mit dem Befehl netstat (TSO oder z/OS UNIX) können Sie eine Übersicht der zurzeit verwendeten Ports aufrufen. Die Ausgabe dieses Befehls sieht in etwa wie das folgende Beispiel aus. Die letzte Zahl in der Spalte Local Socket (nach '..') gibt die verwendeten Ports an. Da diese Ports bereits genutzt werden, können sie nicht für die Konfiguration von Developer for System z verwendet werden.
MVS TCP/IP NETSTAT CS VxRy TCPIP Name: TCPIP 16:36:42
User Id Conn Local Socket Foreign Socket State
------- ---- ------------ -------------- -----
BPXOINIT 00000014 0.0.0.0..10007 0.0.0.0..0 Listen
INETD4 0000004D 0.0.0.0..512 0.0.0.0..0 Listen
RSED 0000004B 0.0.0.0..4035 0.0.0.0..0 Listen
JMON 00000038 0.0.0.0..6715 0.0.0.0..0 Listen
MVS TCP/IP NETSTAT CS VxRy TCPIP Name: TCPIP 12:46:25
User Id Conn State
------- ---- -----
BPXOINIT 00000018 Listen
Local Socket: 0.0.0.0..10007
Foreign Socket: 0.0.0.0..0
INETD4 00000046 Listen
Local Socket: 0.0.0.0..512
Foreign Socket: 0.0.0.0..0
RSED 0000004B Listen
Local Socket: 0.0.0.0..4035
Foreign Socket: 0.0.0.0..0
JMON 00000037 Listen
Local Socket: 0.0.0.0..6715
Foreign Socket: 0.0.0.0..0
Eine andere bestehende Einschränkung sind reservierte TCP/IP-Ports. Es gibt die beiden folgenden allgemeinen Bereiche, in denen TCP/IP-Ports reserviert werden:
Auf diese Datei verweist die DD-Anweisung PROFILE der gestarteten TCP/IP-Task, die oft den Namen SYS1.TCPPARMS(TCPPROF) hat.
Weitere Informationen zu diesen Anweisungen finden Sie im Communications Server: IP Configuration Guide (IBM Form SC31-8775).
Diese reservierten Ports können mit dem Befehl netstat portl (TSO oder z/OS UNIX) aufgelistet werden. Die erstellte Ausgabe entspricht in etwa dem folgenden Beispiel:
MVS TCP/IP NETSTAT CS VxRy TCPIP Name: TCPIP 17:08:32
Port# Prot User Flags Range IP Address
----- ---- ---- ----- ----- ----------
00007 TCP MISCSERV DA
00009 TCP MISCSERV DA
00019 TCP MISCSERV DA
00020 TCP OMVS D
00021 TCP FTPD1 DA
00025 TCP SMTP DA
00053 TCP NAMESRV DA
00080 TCP OMVS DA
03500 TCP OMVS DAR 03500-03519
03501 TCP OMVS DAR 03500-03519
Weitere Informationen zum Befehl NETSTAT enthält die Veröffentlichung Communications Server: IP System Administrator’s Commands (IBM Form SC31-8781).
Der RSE-Dämon ist ein z/OS UNIX-Java-Prozess und erfordert für die Ausführung seiner Funktionen eine große Regionsgröße. Deshalb ist es wichtig, dass für OMVS-Adressräume große Speichergrenzen festgelegt werden.
Der RSE-Dämon wird über JCL mit BPXBATSL gestartet. Die Regionsgröße von BPXBATSL muss gleich null sein.
Setzen Sie MAXASSIZE in SYS1.PARMLIB(BPXPRMxx) (zum Definieren der Standardregionsgröße bzw. -prozessgröße für den OMVS-Adressraum) auf mindestens 2G. Dies ist die zulässige Maximalgröße. Dieser Grenzwert gilt systemweit. Er ist daher für alle z/OS UNIX-Adressräume aktiv. Wenn Sie dies nicht wünschen, können Sie in Ihrer Sicherheitssoftware den Grenzwert auch nur für Developer for System z festlegen.
Überprüfen Sie ASSIZEMAX im OMVS-Segment der Dämonbenutzer-ID und setzen Sie das Feld auf 2147483647 oder vorzugsweise auf NONE, damit der Wert SYS1.PARMLIB(BPXPRMxx) verwendet wird.
Stellen Sie sicher, dass Regionsgrößen des OMVS-Adressraums nicht von den Systemexits IEFUSI oder IEALIMIT gesteuert werden. Eine Möglichkeit, dies zu erreichen, ist die Verwendung des Codes SUBSYS(OMVS,NOEXITS) in SYS1.PARMLIB(SMFPRMxx).
Das Schlüsselwort MEMLIMIT in SYS1.PARMLIB(SMFPRMxx) legt fest, wie viel virtuellen Speicher eine 64-Bit-Task oberhalb der Grenze von 2GB zuweisen darf. Im Gegensatz zu dem Parameter REGION in JCL bedeutet MEMLIMIT=0M, dass der Prozess keinen virtuellen Speicher oberhalb der Grenze verwenden darf.
Wenn MEMLIMIT nicht in SMFPRMxx angegeben wird, ist der Standardwert 0M, das heißt, dass Tasks an die 2 GB (31 Bit) unterhalb der Grenze gebunden sind. Der in z/OS 1.10 auf 2G geänderte Standard ermöglicht 64-Bit-Tasks die Verwendung von bis zu 4 GB (2 GB unterhalb der Grenze und 2 GB durch MEMLIMIT).
MEMLIMIT kann auch als Parameter auf der EXEC-Karte in JCL angegeben werden. Wenn der Parameter MEMLIMIT nicht angegeben ist, ist der Standard der in SMF definierte Wert. Dies gilt nicht, wenn REGION=0M angegeben ist. In diesem Fall ist der Standardwert NOLIMIT.
Wenn ein Benutzer Fehlerrückmeldungen während einer Kompilierungsaktion auswählt, werden von Developer for System z mehrere temporäre Dateien erstellt. Wenn für eine dieser Dateien der Speicherplatz zu gering wird, enden die Kompilierungsjobs mit einem Fehler "B37-04", das heißt einem Abbruch aufgrund fehlenden Speicherplatzes.
Wenn dieser Fehler bei Ihren Benutzern auftritt, passen Sie die Speicherplatzzuordnung in FEK.SFEKPROC(FEKFERRF) an. Der Standardwert ist SPACE(200,40) TRACKS.
SYS1.PARMLIB(BPXPRMxx) definiert viele z/OS UNIX-bezogene Begrenzungen, die erreicht werden können, wenn mehrere Clientkomponenten von Developer for System z aktiv sind. Die meisten BPXPRMxx-Werte können mit den Konsolbefehlen SETOMVS und SET OMVS dynamisch geändert werden.
Verwenden Sie den Konsolbefehl SETOMVS LIMMSG=ALL, damit unter z/OS UNIX Konsolennachrichten (BPXI040I) angezeigt werden, wenn Grenzwerte für BPXPRMxx annähernd überschritten werden.
Dieser Abschnitt soll Sie bei einigen allgemeinen Problemen unterstützen, die beim Konfigurieren von SSL (Secure Sockets Layer) oder beim Überprüfen oder Modifizieren einer vorhandenen Konfiguration auftreten könnten. Dieser Abschnitt stellt auch eine Beispielkonfiguration zur Verfügung, um Benutzer zu unterstützen, die sich mit einem X.509-Zertifikat selbst authentifizieren.
Sichere Kommunikation bedeutet, dass Ihr DFV-Partner derjenige ist, der er zu sein vorgibt, und dass Informationen in einer Weise übertragen werden, die es anderen erschwert, die Daten abzufangen und zu lesen. SSL bietet diese Fähigkeiten für ein TCP/IP-Netz an. SSL verwendet digitale Zertifikate für Ihre Identifikation und ein Protokoll mit öffentlichen Schlüsseln, um die Kommunikation zu verschlüsseln. Weitere Informationen zu digitalen Zertifikaten und zu dem von SSL verwendeten Protokoll mit öffentlichen Schlüsseln finden Sie im Security Server RACF Security Administrator's Guide (IBM Form SA22-7683).
Welche Aktionen erforderlich sind, um die SSL-Kommunikation für Developer for System z zu konfigurieren, hängt von den genauen Anforderungen am jeweiligen Standort, vom verwendeten RSE-Kommunikationsverfahren und von den am Standort verfügbaren Ressourcen ab.
In diesem Abschnitt werden Sie die aktuellen RSE-Definitionen klonen, damit Sie eine zweite RSE-Dämonverbindung haben, die SSL verwendet. Außerdem werden Sie Ihre eigenen Sicherheitszertifikate erstellen, die von den verschiedenen Teilnehmern der RSE-Verbindung verwendet werden.
Für einige der in den folgenden Abschnitten beschriebenen Tasks wird vorausgesetzt, dass Sie aktivierter z/OS UNIX-Benutzer sind. Zum Aktivieren können Sie den TSO-Befehl OMVS absetzen. Mit dem Befehl exit können Sie zu TSO zurückkehren.
Die Variable DSTORE_SSL_ALGORITHM in der Anweisung _RSE_JAVAOPTS von rsed.envvars ermöglicht Ihnen, zwischen SSL und dem Nachfolgeprotokoll TLS (Transport Layer Security) als Verschlüsselungsmethode zu wählen. Dies wird im Abschnitt "Zusätzliche Java-Startparameter mit _RSE_JAVAOPTS definieren" im Handbuch Hostkonfiguration (IBM Form SC12-4062) dokumentiert.
Die von SSL verwendeten Identitätszertifikate und Schlüssel für die Verschlüsselung/Entschlüsselung werden in einer Schlüsseldatei gespeichert. Die jeweiligen Implementierungen dieser Schlüsseldatei sind vom Anwendungstyp abhängig.
Alle Implementierungen folgen jedoch dem gleichen Prinzip. Ein Befehl generiert ein Schlüsselpaar (einen öffentlichen Schlüssel und einen zugehörigen privaten Schlüssel). Anschließend wird der öffentliche Schlüssel in ein selbst signiertes Zertifikat (X.509) eingeschlossen, das als Zertifikatskette mit einem Element gespeichert wird. Diese Zertifikatskette und der private Schlüssel werden als ein (mit einem Aliasnamen bezeichneter) Eintrag in einer Schlüsseldatei gespeichert.
Zertifikatsspeicher | Erstellt und verwaltet von | RSE-Dämon | RSE-Server |
---|---|---|---|
Schlüsseldatei | SAF-kompatibles Sicherheitsprodukt | unterstützt | unterstützt |
Schlüsseldatenbank | z/OS UNIX gskkyman | unterstützt | / |
Keystore | Java-Keytool | / | unterstützt |
STEPLIB=$STEPLIB:SYS1.SIEALNKE
Weitere Informationen zu RACF und digitalen Zertifikaten finden Sie im Security Server RACF Security Administrator’s Guide (IBM Form SA22-7683). Die Dokumentation zu gskkyman ist in der Veröffentlichung System SSL Programming (IBM Form SC24-5901) enthalten. Die Dokumentation zu keytool ist unter http://java.sun.com/j2se/1.5.0/docs/tooldocs/solaris/keytool.html verfügbar.
Führen Sie diesen Schritt nicht aus, wenn Sie gskkyman zum Erstellen der RSE-Dämonschlüsseldatenbank und keytool zum Erstellen des RSE-Server-Keystores verwenden.
Der Befehl RACDCERT installiert und verwaltet private Schlüssel und Zertifikate in RACF. RACF unterstützt die Verwaltung mehrerer privater Schlüssel und Zertifikate in einer Gruppe. Diese Gruppen werden als Schlüsseldateien bezeichnet.
Zertifikate können selbst signiert oder von einer Zertifizierungsstelle (CA) signiert sein. Bei einem von einer CA signierten Zertifikat garantiert die CA, dass der Eigner des Zertifikats derjenige ist, der er zu sein vorgibt. Durch den Signierungsprozess werden Ihrem Zertifikat die Berechtigungsnachweise der CA hinzugefügt (hierbei handelt es sich auch um ein Zertifikat). Dadurch wird es zu einer mehrteiligen Zertifikatskette.
Wenn Sie ein Zertifikat verwenden, das von einer Zertifizierungsstelle signiert wurde, können Sie Fragen zur Vertrauensprüfung durch den Client von Developer for System z vermeiden, wenn der Client der Zertifizierungsstelle bereits vertraut.
Details zum Befehl RACDCERT enthält die Veröffentlichung Security Server RACF Command Language Reference (IBM Form SA22-7687).
# permit RSE daemon to access certificates
RDEFINE FACILITY IRR.DIGTCERT.LIST UACC(NONE)
RDEFINE FACILITY IRR.DIGTCERT.LISTRING UACC(NONE)
PERMIT IRR.DIGTCERT.LIST CLASS(FACILITY) ACCESS(READ) ID(stcrse)
PERMIT IRR.DIGTCERT.LISTRING CLASS(FACILITY) ACCESS(READ) ID(stcrse)
# refresh to make the changes visible
SETROPTS RACLIST(FACILITY) REFRESH
# create self-signed certificate
RACDCERT ID(stcrse) GENCERT SUBJECTSDN(CN('rdz rse ssl') +
OU('rdz') O('IBM') L('Raleigh') SP('NC') C('US')) +
NOTAFTER(DATE(2017-05-21)) WITHLABEL('rdzrse') KEYUSAGE(HANDSHAKE)
# (optional) additional steps required to use a signed certificate
# 1. create a signing request for the self-signed certificate
RACDCERT ID(stcrse) GENREQ (LABEL('rdzrse')) DSN(dsn)
# 2. send the signing request to your CA of choice
# 3. check if the CA credentials (also a certificate) are already known
RACDCERT CERTAUTH LIST
# 4. mark the CA certificate as trusted
RACDCERT CERTAUTH ALTER(LABEL('CA cert')) TRUST
# or add the CA certificate to the database
RACDCERT CERTAUTH ADD(dsn) WITHLABEL('CA cert') TRUST
# 5. add the signed certificate to the database;
# this will replace the self-signed one
RACDCERT ID(stcrse) ADD(dsn) WTIHLABEL('rdzrse') TRUST
# Do NOT delete the self-signed certificate before replacing it.
# If you do, you lose the private key that goes with the certificate,
# which makes the certificate useless.
RACDCERT ID(stcrse) ADDRING(rdzssl.racf)
RACDCERT ID(stcrse) CONNECT(LABEL('rdzrse') RING(rdzssl.racf) +
DEFAULT USAGE(PERSONAL))
# additional step required to use a signed certificate
# 6. add CA certificate to key ring
RACDCERT ID(stcrse) CONNECT(CERTAUTH LABEL('CA cert') +
RING(rdzssl.racf))
# refresh to make the changes visible
SETROPTS RACLIST(DIGTCERT) REFRESH
Das vorangehende Beispiel beginnt mit der Erstellung der notwendigen Profile und dem Berechtigen der Benutzer-ID STCRSE für den Zugriff auf die Schlüsseldateien und auf Zertifikate, deren Eigner diese Benutzer-ID ist. Die Benutzer-ID muss mit der für die Ausführung des SSL-RSE-Dämons verwendeten Benutzer-ID übereinstimmen. Der nächste Schritt ist die Erstellung eines neuen, selbst signierten Zertifikats mit der Bezeichnung rdzrse. Es ist kein Kennwort erforderlich. Dieses Zertifikat wird dann einer neu erstellten Schlüsseldatei (rdzssl.racf) hinzugefügt. Für die Schlüsseldatei ist ebenso wie für das Zertifikat kein Kennwort erforderlich. Die Schritte, die für die Verwendung eines signierten Zertifikats erforderlich sind, werden ebenfalls angegeben.
Es kann auch vorkommen, dass das zur Signierung Ihres Zertifikats verwendete CA-Zertifikat von einem anderen, höheren CA-Zertifikat signiert worden ist. In diesem Fall muss dieses höhere CA-Zertifikat ebenfalls zur Schlüsseldatei hinzugefügt werden. Dies trifft auf sämtliche Ebenen der zur Signierung des Zertifikats verwendeten CA-Zertifikate bis zum Root-CA-Zertifikat zu, das auf jeden Fall ein selbst signiertes Zertifikat ist.
Das Ergebnis können Sie mit den folgenden Optionen list und listring überprüfen:
RACDCERT ID(stcrse) LIST
Digital certificate information for user STCRSE:
Label: rdzrse
Certificate ID: 2QjW1OXi0sXZ1aaEqZmihUBA
Status: TRUST
Start Date: 2007/05/24 00:00:00
End Date: 2017/05/21 23:59:59
Serial Number:
>00<
Issuer's Name:
>CN=my CA.OU=rdz.O=IBM.L=Raleigh.SP=NC.C=US<
Subject's Name:
>CN=rdz rse ssl.OU=rdz.O=IBM.L=Raleigh.SP=NC.C=US<
Private Key Type: Non-ICSF
Private Key Size: 1024
Ring Associations:
Ring Owner: STCRSE
Ring:
>rdzssl.racf<
RACDCERT ID(stcrse) LISTRING(rdzssl.racf)
Digital ring information for user STCRSE:
Ring:
>rdzssl.racf<
Certificate Label Name Cert Owner USAGE DEFAULT
-------------------------------- ------------ -------- -------
rdzrse ID(STCRSE) PERSONAL YES
CA cert CERTAUTH CERTAUTH NO
In diesem Schritt wird eine neue Instanz der RSE-Konfigurationsdateien erstellt, damit die SSL-Konfiguration parallel mit den vorhandenen Instanzen ausgeführt werden kann. Bei den folgenden Beispielbefehlen wird davon ausgegangen, dass sich die Konfigurationsdateien im Verzeichnis /etc/rdz/ befinden. Dies ist die im Abschnitt "Angepasstes Setup" im Handbuch Hostkonfiguration (IBM Form SC12-4062) verwendete Standardposition.
$ cd /etc/rdz
$ mkdir ssl
$ cp rsed.envvars ssl
$ cp ssl.properties ssl
$ ls ssl
rsed.envvars ssl.properties
Die im vorangehenden Beispiel aufgeführten z/OS UNIX-Befehle erstellen ein Unterverzeichnis mit der Bezeichnung ssl und füllen es mit den Konfigurationsdateien, für die Änderungen erforderlich sind. Die anderen Konfigurationsdateien, das Installationsverzeichnis und die MVS-Komponenten können gemeinsam genutzt werden, weil sie nicht SSL-spezifisch sind.
Indem die meisten vorhandenen Konfigurationsdateien wiederverwendet werden, kann der Fokus auf die Änderungen gelegt werden, die zur Konfiguration von SSL tatsächlich erforderlich sind. Außerdem kann eine erneute vollständige RSE-Konfiguration vermieden werden. (Beispielsweise muss für ISPF.conf keine neue Position definiert werden.)
Bisher sind die Definitionen eine exakte Kopie der aktuellen Konfiguration. Dies impliziert, dass die Protokolle des neuen RSE-Dämons die aktuellen Serverprotokolldateien überschreiben. RSE muss auch die Positionen kennen, an denen die Konfigurationsdateien auffindbar sind, die nicht in das ssl-Verzeichnis kopiert wurden. Beide Probleme könnnen sie durch geringfügige Änderungen an rsed.envvars lösen.
$ oedit /etc/rdz/ssl/rsed.envvars
-> ändern: _RSE_RSED_PORT=4047
-> ändern: -Ddaemon.log=/var/rdz/logs/ssl
-> ändern: -Duser.log=/var/rdz/logs/ssl
-> am ENDE hinzufügen:
# -- NEEDED TO FIND THE REMAINING CONFIGURATION FILES
CFG_BASE=/etc/rdz
CLASSPATH=.:$CFG_BASE:$CLASSPATH
# --
Die im vorangegangenen Beispiel beschriebenen Änderungen definieren eine neue Protokollposition. (Wenn die Protokollposition nicht vorhanden ist, wird diese vom RSE-Dämon erstellt.) Durch die Änderungen wird auch der CLASSPATH aktualisiert, sodass die SSL-RSE-Prozesse zunächst das aktuelle Verzeichnis (/etc/rdz/ssl) und dann das Ursprungsverzeichnis (/etc/rdz) nach Konfigurationsdateien durchsucht.
Durch die Aktualisierung der Datei ssl.properties wird RSE angewiesen, die Kommunikation mit SSL zu verschlüsseln.
$ oedit /etc/rdz/ssl/ssl.properties
-> ändern: enable_ssl=true
-> Kommentarzeichen entfernen und ändern: daemon_keydb_file=rdzssl.racf
-> Kommentarzeichen entfernen und ändern: daemon_key_label=rdzrse
-> Kommentarzeichen entfernen und ändern: server_keystore_file=rdzssl.racf
-> Kommentarzeichen entfernen und ändern: server_keystore_label=rdzrse
-> Kommentarzeichen entfernen und ändern: server_keystore_type=JCERACFKS
Die im vorangegangenen Beispiel beschriebenen Änderungen aktivieren SSL und teilen dem RSE-Dämon und RSE-Server mit, dass ihr (gemeinsam genutztes) Zertifikat in der Schlüsseldatei rdzssl.racf unter der Bezeichnung rdzrse gespeichert ist. Mit dem Schlüsselwort JCERACFKS wird dem RSE-Server mitgeteilt, dass eine SAF-kompatible Schlüsseldatei als Schlüsselspeicher verwendet wird.
System SSL (vom Dämon verwendet) verwendet sofern verfügbar immer ICSF, die Schnittstelle zur Verschlüsselungshardware von System z. Für die gemeinsame Verwendung der Dämondefinitionen mit dem Server bei der Verwendung von ICSF muss der Server-Keystore-Typ JCECCARACFKS angegeben sein. Als Keystore für öffentliche Schlüssel wird hier auch eine SAF-konforme Schlüsseldatei verwendet, der private Schlüssel wird aber in ICSF gespeichert. Zur Steuerung der Verwendung von Verschlüsselungsschlüsseln und Verschlüsselungsservices verwendet ICSF, wie im Handbuch Cryptographic Services ICSF Administrator's Guide (IBM Form SA22-7521) beschrieben, Profile der Sicherheitsklassen CSFKEYS und CSFSERV.
//RSEDSSL JOB CLASS=A,MSGCLASS=A,MSGLEVEL=(1,1),USER=STCRSE
//*
//* RSE-DÄMON - SSL
//*
//RSED PROC TMPDIR=,
// PORT=,
// IVP=, * 'IVP' für einen IVP-Test
// CNFG='/etc/rdz/ssl',
// HOME='/usr/lpp/rdz'
//*
//RSED EXEC PGM=BPXBATSL,REGION=0M,TIME=NOLIMIT,
// PARM='PGM &HOME./bin/rsed.sh &IVP -C&CNFG -P&PORT -T&TMPDIR'
//STDOUT DD SYSOUT=*
//STDERR DD SYSOUT=*
// PEND
//*
//RSED EXEC RSED
//*
Die SSL-Hostkonfiguration ist vollständig, und der RSE-Dämon für SSL kann mit der Übergabe des zuvor erstellten Jobs FEK.#CUST.PROCLIB(RSEDSSL) gestartet werden.
Die neue Konfiguration kann jetzt getestet werden, indem eine Verbindung mit dem Client mit Developer for System z hergestellt wird. Da Sie für SSL eine neue Konfiguration (durch Klonen der vorhandenen Konfiguration) erstellt haben, müssen Sie nun auf dem Client eine neue Verbindung mit dem Port 4047 für den RSE-Dämon konfigurieren.
Wenn die Verbindung hergestellt ist, beginnen Host und Client mit dem Handshakeverfahren, um einen sicheren Pfad einzurichten. Im Rahmen dieses Handshakeverfahrens werden Zertifikate ausgetauscht. Wenn der Developer for System z-Client das Hostzertifikat oder die signierende CA nicht erkennt, fragt der Developer for System z-Client beim Benutzer an, ob dieses Zertifikat vertrauenswürdig ist.
Der Benutzer kann dieses Zertifikat als vertrauenswürdig akzeptieren, indem er auf die Schaltfläche 'Finish' klickt. Danach wird die Verbindungsinitialisierung fortgesetzt.
Wenn der Client ein Zertifikat einmal anerkannt hat, wird dieser Dialog nicht mehr angezeigt. Die Liste vertrauenswürdiger Zertifikate kann verwaltet werden. Wählen Sie dazu Fenster > Benutzervorgaben > Ferne Systeme > SSL aus, um den folgenden Dialog aufzurufen:
Wenn die SSL-Kommunikation fehlschlägt, gibt der Client eine Fehlernachricht zurück. Weitere Informationen sind in den verschiedenen Server- und Benutzerprotokolldateien verfügbar. Lesen Sie die diesbezüglichen Beschreibungen in den Abschnitten Protokollierung des RSE-Dämons und des Thread-Pools und RSE-Benutzer, Protokollierung.
Mit einem X.509-Zertifikat unterstützt der RSE-Dämon die eigene Authentifizierung der Benutzer. Voraussetzung hierfür ist die Verwendung der mit SSL verschlüsselten Kommunikation, da dies eine Erweiterung der Hostauthentifizierung mit einem in SSL verwendeten Zertifikat ist.
Es gibt mehrere Wege zur Zertifikatsauthentifizierung für einen Benutzer. Lesen Sie hierzu den Abschnitt Clientauthentifizierung unter Verwendung von X.509-Zertifikaten. Die folgenden Schritte dokumentieren die Konfiguration, die zur Unterstützung der Methode erforderlich ist, bei der Ihre Sicherheitssoftware das Zertifikat unter Verwendung der HostIdMappings-Zertifikatserweiterung authentifiziert.
RACDCERT CERTAUTH ALTER(LABEL('HighTrust CA')) HIGHTRUST
RACDCERT ID(stcrse) CONNECT(CERTAUTH LABEL('HighTrust CA') +
RING(rdzssl.racf))
Dies beendet die Konfiguration der Sicherheitssoftware für das CA-Zertifikat.
RDEFINE SERVAUTH IRR.HOST.CDFMVS08.RALEIGH.IBM.COM UACC(NONE)
PERMIT IRR.HOST.CDFMVS08.RALEIGH.IBM.COM CLASS(SERVAUTH) +
ACCESS(READ) ID(stcrse)
SETROPTS CLASSACT(SERVAUTH) RACLIST(SERVAUTH)
oder
SETROPTS RACLIST(SERVAUTH) REFRESH
Dies beendet die Konfiguration der Sicherheitssoftware für die HostIdMappings-Erweiterung.
Führen Sie diesen Schritt nicht aus, wenn Sie eine SAF-kompatible Schlüsseldatei für die Schlüsseldatenbank des RSE-Dämons verwenden.
gskkyman ist ein shellbasiertes, menügeführtes z/OS UNIX-Programm, das eine z/OS UNIX-Datei erstellt, mit Daten füllt und verwaltet. Diese Datei enthält private Schlüssel, Zertifikatanforderungen und Zertifikate und wird als Schlüsseldatenbank bezeichnet.
PATH=$PATH:/usr/lpp/gskssl/bin
export NLSPATH=/usr/lpp/gskssl/lib/nls/msg/En_US.IBM-1047/%N:$NLSPATH
export STEPLIB=$STEPLIB:SYS1.SIEALNKE
$ cd /etc/rdz/ssl
$ gskkyman Database Menu
1 - Create new database
Enter option number: 1
Enter key database name (press ENTER to return to menu): rdzssl.kdb
Enter database password (press ENTER to return to menu): rsessl
Re-enter database password: rsessl
Enter password expiration in days (press ENTER for no expiration):
Enter database record length (press ENTER to use 2500):
Key database /etc/rdz/ssl/rdzssl.kdb created.
Press ENTER to continue.
Key Management Menu
6 - Create a self-signed certificate
Enter option number (press ENTER to return to previous menu): 6
Certificate Type
5 - User or server certificate with 1024-bit RSA key
Select certificate type (press ENTER to return to menu): 5
Enter label (press ENTER to return to menu): rdzrse
Enter subject name for certificate
Common name (required): rdz rse ssl
Organizational unit (optional): rdz
Organization (required): IBM
City/Locality (optional): Raleigh
State/Province (optional): NC
Country/Region (2 characters - required): US
Enter number of days certificate will be valid (default 365): 3650
Enter 1 to specify subject alternate names or 0 to continue: 0
Please wait .....
Certificate created.
Press ENTER to continue.
Key Management Menu
0 - Exit program
Enter option number (press ENTER to return to previous menu): 0
$ ls -l rdzssl.*
total 152
-rw------- 1 IBMUSER SYS1 35080 May 24 14:24 rdzssl.kdb
-rw------- 1 IBMUSER SYS1 80 May 24 14:24 rdzssl.rdb
$ chmod 644 rdzssl.*
$ ls -l rdzssl.*
-rw-r--r-- 1 IBMUSER SYS1 35080 May 24 14:24 rdzssl.kdb
-rw-r--r-- 1 IBMUSER SYS1 80 May 24 14:24 rdzssl.rdb
Das vorangegangene Beispiel beginnt mit der Erstellung der Schlüsseldatenbank rdzssl.kdb mit dem Kennwort rsessl. Wenn die Datenbank vorhanden ist, wird sie mit Daten gefüllt. Dazu wird ein neues selbst signiertes Zertifikat erstellt, das für ca. 10 Jahre gültig ist (ohne Berücksichtigung des zusätzlichen Tages in Schaltjahren). Das Zertifikat wird unter der Bezeichnung rdzrse und mit dem bereits für die Schlüsseldatenbank verwendeten Kennwort (rsessl) gespeichert. (Dies ist eine RSE-Anforderung.)
gskkyman legt die Schlüsseldatenbank mit einer (sehr sicheren) Bitmaske (600 Berechtigungsbits) an, die nur dem Eigner Zugriff gewährt. Die Berechtigungen müssen weniger restriktiv gesetzt werden, sofern der Dämon nicht dieselbe Benutzer-ID wie der Ersteller der Schlüsseldatenbank verwendet. 644 (Eigner mit Lese-/Schreibzugriff; Lesezugriff für alle übrigen Benutzer) ist eine verwendbare Maske für den Befehl chmod.
Das Ergebnis können Sie wie folgt überprüfen, indem Sie im Untermenü Manage keys and certificates die Option Show certificate information auswählen:
$ gskkyman
Database Menu
2 - Open database
Enter option number: 2
Enter key database name (press ENTER to return to menu): rdzssl.kdb
Enter database password (press ENTER to return to menu): rsessl
Key Management Menu
1 - Manage keys and certificates
Enter option number (press ENTER to return to previous menu): 1
Key and Certificate List
1 - rdzrse
Enter label number (ENTER to return to selection menu, p for previous list): 1
Key and Certificate Menu
1 - Show certificate information
Enter option number (press ENTER to return to previous menu): 1
Certificate Information
Label: rdzrse
Record ID: 14
Issuer Record ID: 14
Trusted: Yes
Version: 3
Serial number: 45356379000ac997
Issuer name: rdz rse ssl
rdz
IBM
Raleigh
NC
US
Subject name: rdz rse ssl
rdz
IBM
Raleigh
NC
US
Effective date: 2007/05/24
Expiration date: 2017/05/21
Public key algorithm: rsaEncryption
Public key size: 1024
Signature algorithm: sha1WithRsaEncryption
Issuer unique ID: None
Subject unique ID: None
Number of extensions: 3
Enter 1 to display extensions, 0 to return to menu: 0
Key and Certificate Menu
0 - Exit program
Enter option number (press ENTER to return to previous menu): 0
Das folgende Beispiel für ssl.properties zeigt, dass die Anweisungen daemon_* sich von dem zuvor aufgeführten Beispiel für eine SAF-Schlüsseldatei unterscheiden.
$ oedit /etc/rdz/ssl/ssl.properties
-> ändern: enable_ssl=true
-> Kommentarzeichen entfernen und ändern: daemon_keydb_file=rdzssl.kdb
-> Kommentarzeichen entfernen und ändern: daemon_keydb_password=rsessl
-> Kommentarzeichen entfernen und ändern: daemon_key_label=rdzrse
-> Kommentarzeichen entfernen und ändern: server_keystore_file=rdzssl.racf
-> Kommentarzeichen entfernen und ändern: server_keystore_label=rdzrse
-> Kommentarzeichen entfernen und ändern: server_keystore_type=JCERACFKS
Die oben beschriebenen Änderungen aktivieren SSL und teilen dem RSE-Dämon mit, dass das Zertifikat in der Schlüsseldatei rdzssl.kdb unter der Bezeichnung rdzrse mit dem Kennwort rsessl gespeichert ist. Der RSE-Server verwendet weiterhin eine SAF-konforme Schlüsseldatei.
Führen Sie diesen Schritt nicht aus, wenn Sie eine SAF-kompatible Schlüsseldatei für den Keystore des RSE-Servers verwenden.
Alle Informationen können als ein Parameter übergeben werden. Durch die Längenbeschränkung der Befehlszeile sind jedoch folgende Interaktionen erforderlich:
$ cd /etc/rdz/ssl
$ keytool -genkey -alias rdzrse -validity 3650 -keystore rdzssl.jks -storepass
rsessl -keypass rsessl
What is your first and last name?
[Unknown]: rdz rse ssl
What is the name of your organizational unit?
[Unknown]: rdz
What is the name of your organization?
[Unknown]: IBM
What is the name of your City or Locality?
[Unknown]: Raleigh
What is the name of your State or Province?
[Unknown]: NC
What is the two-letter country code for this unit?
[Unknown]: US
Is CN=rdz rse ssl, OU=rdz, O=IBM, L=Raleigh, ST=NC, C=US correct? (type "yes"
or "no")
[no]: yes
$ ls -l rdzssl.*
-rw-r--r-- 1 IBMUSER SYS1 1224 May 24 14:17 rdzssl.jks
Das im vorangegangenen Beispiel erstellte, selbst signierte Zertifikat ist für ca. 10 Jahre gültig (ohne Berücksichtigung des zusätzlichen Tages in Schaltjahren). Es wird in /etc/rdz/ssl/rdzssl.jks mit dem Aliasnamen rdzrse gespeichert. Das Kennwort (rsessl) stimmt mit dem Keystore-Kennwort überein. Dies ist eine RSE-Anforderung.
Das Ergebnis können Sie wie folgt mit der Option -list überprüfen:
$ keytool -list -alias rdzrse -keystore rdzssl.jks -storepass rsessl -v
Alias name: rdzrse
Creation date: May 24, 2007
Entry type: keyEntry
Certificate chain length: 1
Certificate 1¨:
Owner: CN=rdz rse ssl, OU=rdz, O=IBM, L=Raleigh, ST=NC, C=US
Issuer: CN=rdz rse ssl, OU=rdz, O=IBM, L=Raleigh, ST=NC, C=US
Serial number: 46562b2b
Valid from: 5/24/07 2:17 PM until: 5/21/17 2:17 PM
Certificate fingerprints:
MD5: 9D:6D:F1:97:1E:AD:5D:B1:F7:14:16:4D:9B:1D:28:80
SHA1: B5:E2:31:F5:B0:E8:9D:01:AD:2D:E6:82:4A:E0:B1:5E:12:CB:10:1C
Das folgende Beispiel für ssl.properties zeigt, dass die Anweisungen server_* sich von dem zuvor aufgeführten Beispiel für eine SAF-Schlüsseldatei unterscheiden.
$ oedit /etc/rdz/ssl/ssl.properties
-> ändern: enable_ssl=true
-> Kommentarzeichen entfernen und ändern: daemon_keydb_file=rdzssl.racf
-> Kommentarzeichen entfernen und ändern: daemon_key_label=rdzrse
-> Kommentarzeichen entfernen und ändern: server_keystore_file=rdzssl.jks
-> Kommentarzeichen entfernen und ändern: server_keystore_password=rsessl
-> Kommentarzeichen entfernen und ändern: server_keystore_label=rdzrse
-> Kommentarzeichen entfernen und ändern (optional): server_keystore_type=JKS
Die oben beschriebenen Änderungen aktivieren SSL und teilen dem RSE-Server mit, dass das Zertifikat in der Schlüsseldatei rdzssl.jks unter der Bezeichnung rdzrse mit dem Kennwort rsessl gespeichert ist. Der RSE-Dämon verwendet immer noch eine SAF-kompatible Schlüsseldatei.
Dieser Abschnitt ist zur Unterstützung bei einigen allgemeinen Problemen vorgesehen, die beim Konfigurieren von Application Transparent Transport Layer Security (AT-TLS) oder beim Überprüfen oder Ändern einer bestehenden Konfiguration auftreten können.
Das TLS-Protokoll (Transport Layer Security), das in RFC 2246 definiert wird, bietet Datenschutz für die Kommunikation im Internet. Ähnlich wie sein Vorgänger Secure Socket Layer (SSL) ermöglicht es dieses Protokoll Client- und Serveranwendungen, auf eine Art und Weise zu kommunizieren, die das Ausspionieren, die Manipulation und das Fälschen von Nachrichten verhindert. Application Transparent Transport Layer Security (AT-TLS) konsolidiert die TLS-Implementierung für z/OS-basierte Anwendungen an einer einzigen Position, sodass alle Anwendungen die TLS-basierte Verschlüsselung unterstützen können, ohne das TLS-Protokoll zu kennen. Weitere Informationen zu AT-TLS enthält das Dokument Communications Server IP Configuration Guide (IBM Form SC31-8775).
Integrated Debugger in IBM Rational Developer for System z benötigt AT-TLS für die verschlüsselte Kommunikation mit dem Client, da die Daten für die Debugsitzung nicht durch dieselbe Pipe geleitet werden wie die übrige Client-Host-Kommunikation in Developer for System z.
Welche Aktionen für die Konfiguration von AT-TLS erforderlich sind, hängt von den genauen Anforderungen am jeweiligen Standort und von den am Standort verfügbaren Ressourcen ab.
Für einige der in den folgenden Abschnitten beschriebenen Tasks wird vorausgesetzt, dass Sie aktivierter z/OS UNIX-Benutzer sind. Zum Aktivieren können Sie den TSO-Befehl OMVS absetzen. Verwenden Sie den Befehl oedit, um Dateien unter z/OS UNIX zu bearbeiten. Mit dem Befehl exit können Sie zu TSO zurückkehren.
In der TCP/IP-Dokumentation wird empfohlen, Policy Agent-Nachrichten in syslog unter z/OS UNIX zu schreiben, nicht in die Standardprotokolldatei. AT-TLS schreibt Nachrichten stets in syslog unter z/OS UNIX.
Für diesen Zweck muss der Dämon von syslog unter z/OS UNIX, syslogd, konfiguriert und aktiv sein. Außerdem benötigen Sie einen Mechanismus zum Steuern der Größe der Protokolldateien, die durch syslogd erstellt werden.
syslog 514/udp
# /etc/syslog.conf - control output of syslogd
# 1. all files with will be printed to /tmp/syslog.auth.log
auth.* /tmp/syslog.auth.log
# 2. all error messages printed to /tmp/syslog.error.log
*.err /tmp/syslog.error.log
# 3. all debug and above messages printed to /tmp/syslog.debug.log
*.debug /tmp/syslog.debug.log
# The files named must exist before the syslog daemon is started,
# unless -c startup option is used
# Start the SYSLOGD daemon for logging
# (clean up old logs)
sed -n '/^#/!s/.* \(.*\)/\1/p' /etc/syslog.conf | xargs -i rm {}
# (create new logs and add userid of message sender)
_BPX_JOBNAME='SYSLOGD' /usr/sbin/syslogd -cuf /etc/syslog.conf &
sleep 5
Die AT-TLS-Unterstützung wird über den Parameter TTLS in der Anweisung TCPCONFIG in der Datei PROFILE.TCPIP aktiviert. AT-TLS wird von Policy Agent verwaltet. Policy Agent muss aktiv sein, damit die AT-TLS-Richtlinie erzwungen werden kann. Da Policy Agent warten muss, bis TCP/IP aktiv ist, ist die Anweisung AUTOSTART in PROFILE.TCPIP eine gute Position zum Auslösen des Starts dieses Servers.
TCPCONFIG TTLS ; Required for AT-TLS
AUTOLOG
PAGENT ; POLICY AGENT, required for AT-TLS
ENDAUTOLOG
//PAGENT PROC PRM='-L SYSLOGD' * '' or '-L SYSLOGD'
//*
//* TCP/IP POLICY AGENT
//* (PARM) (envar)
//* default cfg file: /etc/pagent.conf (-C) (PAGENT_CONFIG_FILE)
//* default log file: /tmp/pagent.log (-L) (PAGENT_LOG_FILE)
//* default log size: 300,3 (3x 300KB files) (PAGENT_LOG_FILE_CONTROL)
//*
//PAGENT EXEC PGM=PAGENT,REGION=0M,TIME=NOLIMIT,
// PARM='ENVAR("TZ=EST5DST")/&PRM'
//SYSPRINT DD SYSOUT=*
//SYSOUT DD SYSOUT=*
//*
#
# TCP/IP Policy Agent configuration information.
#
TTLSConfig /etc/pagent.ttls.conf
# Specifies the path of a TTLS policy file holding stack specific
# statements.
#
#TcpImage TCPIP /etc/pagent.conf
# If no TcpImage statement is specified, all policies will be installed
# to the default TCP/IP stack.
#
#LogLevel 31
# The sum of the following values that represent log levels:
# LOGL_SYSERR 1
# LOGL_OBJERR 2
# LOGL_PROTERR 4
# LOGL_WARNING 8
# LOGL_EVENT 16
# LOGL_ACTION 32
# LOGL_INFO 64
# LOGL_ACNTING 128
# LOGL_TRACE 256
# Log Level 31 is the default log loglevel.
#
#Codepage IBM-1047
# Specify the EBCDIC code page to be used for reading all configuration
# files and policy definition files. IBM-1047 is the default code page.
Diese Beispielkonfigurationsdatei gibt an, wo Policy Agent die TTLS-Richtlinie finden kann. Für andere Anweisungen werden Standardwerte von Policy Agent verwendet.
Mithilfe einer TTLS-Richtlinie werden die gewünschten AT-TLS-Regeln beschrieben. Entsprechend der Definition in der Policy Agent-Konfigurationsdatei befindet sich die TTLS-Richtlinie in der Datei /etc/pagent.ttls.conf. Die erforderlichen Definitionen in Ihrer Sicherheitssoftware werden später erläutert.
##
## TCP/IP Policy Agent AT-TLS configuration information.
##
##-----------------------------
TTLSRule RDz_Debug_Manager
{
LocalPortRange 5335
Direction Inbound
TTLSGroupActionRef grp_Production
TTLSEnvironmentActionRef act_RDz_Debug_Manager
}
##-----------------------------
TTLSEnvironmentAction act_RDz_Debug_Manager
{
HandshakeRole Server
TTLSKeyRingParms
{
Keyring dbgmgr.racf # Keyring must be owned by the Debug Manager
}
TTLSEnvironmentAdvancedParms
{
## TLSV1.2 only for z/OS 2.1 and higher
# TLSV1.2 On # SSLv3, TLSv1 & TLSv1.1 are on by default
}
}
##-----------------------------
TTLSRule RDz_Debug_Probe-Client
{
RemotePortRange 8001
Direction Outbound
TTLSGroupActionRef grp_Production
TTLSEnvironmentActionRef act_RDz_Debug_Probe-Client
}
##-----------------------------
TTLSEnvironmentAction act_RDz_Debug_Probe-Client
{
HandshakeRole Client
TTLSKeyRingParms
{
Keyring *AUTH*/* # virtual key ring holding CA certificates
}
TTLSEnvironmentAdvancedParms
{
## TLSV1.2 only for z/OS 2.1 and higher
# TLSV1.2 On # SSLv3, TLSv1 & TLSv1.1 are on by default
}
}
##-----------------------------
TTLSGroupAction grp_Production
{
TTLSEnabled On
## TLSv1.2zOS1.13 only for z/OS 1.13
TTLSGroupAdvancedParmsRef TLSv1.2zOS1.13
Trace 3 # Log Errors to syslogd & IP joblog
#Trace 254 # Log everything to syslogd
}
##-----------------------------
TTLSGroupAdvancedParms TLSv1.2zOS1.13
{
Envfile /etc/pagent.ttls.TLS1.2zOS1.13.env
}
Eine TTLS-Richtlinie ermöglicht eine große Bandbreite an Filtern, um anzugeben, in welchen Fällen eine Regel zutrifft.
Debug Manager ist ein Server, der am Port 5335 für eingehende Verbindungen von der Debug-Engine empfangsbereit ist. Diese Informationen werden in der Regel RDz_Debug_Manager erfasst.
Da für SSL und TLS die Nutzung eines Serverzertifikats erforderlich ist, müssen Sie angeben, dass Policy Manager die Zertifikate der Schlüsseldatei dbgmgr.racf verwenden muss, deren Eigner die Benutzer-ID für die gestartete Task des Debug-Managers ist. Standardmäßig ist die Unterstützung für TLS V1.2 inaktiviert, also wird sie durch diese Richtlinie explizit aktiviert.
Wenn der Debug-Testmonitor mit der Option TEST(,,,TCPIP&&ipaddress%8001:*) für die Language Environment (Language Environment - LE) gestartet wird, wird er angewiesen, den Debug-Manager nicht zu verwenden, sondern den Developer for System z-Client am Port 8001 direkt zu kontaktieren. Aus einer TCP/IP-Perspektive bedeutet dies, dass der hostbasierte Debug-Testmonitor ein Client ist, der einen Server (die Debugbenutzerschnittstelle) im Developer for System z-Client kontaktiert. Diese Informationen werden in der Regel RDz_Debug_Probe-Client erfasst.
Da der Host ein TCP/IP-Client ist, benötigt der Richtlinienmanager eine Methode zum Validieren der von der Debugbenutzerschnittstelle bereitgestellten Serverzertifikate. In diesem Fall wird keine einheitlich benannte Schlüsseldatei für alle Benutzer verwendet, für die möglicherweise eine verschlüsselte Debugsitzung erforderlich wäre; stattdessen wird die virtuelle Schlüsseldatei (*AUTH*/*) der RACF-CERTAUTH verwendet. Diese virtuelle Schlüsseldatei enthält die öffentlichen Zertifikate von Zertifizierungsstellen (Certificate Authorities - CAs) und kann verwendet werden, wenn die Debugbenutzerschnittstelle ein von einer der akzeptierten CAs unterzeichnetes Serverzertifikat bereitstellt.
Beachten Sie, dass Sie für komplexere Richtlinien den IBM Konfigurationsassistenten für z/OS Communications Server verwenden sollten. Dabei handelt es sich um ein grafisch orientiertes Tool mit einer geführten Schnittstelle für die Konfiguration von auf Richtlinien basierenden TCP/IP-Netzfunktionen, das als Task in IBM z/OS Management Facility (z/OSMF) sowie als eigenständige Workstationanwendung verfügbar ist.
Die Unterstützung für TLS V1.2 ist ab z/OS 2.1 verfügbar und ist standardmäßig inaktiviert. Diese Richtlinie enthält den Befehl (TLSV1.2 On) zur expliziten Aktivierung der Unterstützung. Dieser Befehl ist jedoch auf Kommentar gesetzt, da das Zielsystem z/OS 1.13 verwendet.
#
# Add TLSv1.2 support to AT-TLS
# requires z/OS 1.13 with OA39422 and PM62905
#
GSK_RENEGOTIATION=ALL
GSK_PROTOCOL_TLSV1_2=ON
Für Ihre Sicherheitskonfiguration sind mehrere Updates erforderlich, damit AT-TLS ordnungsgemäß funktioniert. Dieser Abschnitt enthält RACF-Beispielbefehle für die Ausführung der erforderlichen Konfiguration.
# define started task user ID
# BPX.DAEMON permit is required for non-zero UID
ADDUSER PAGENT DFLTGRP(SYS1) OMVS(UID(0) SHARED HOME('/')) +
NAME('TCP/IP POLICY AGENT') NOPASSWORD
# define started task
RDEFINE STARTED PAGENT.* STDATA(USER(PAGENT) GROUP(SYS1)) +
DATA('TCP/IP POLICY AGENT')
# refresh to make the changes visible
SETROPTS RACLIST(STARTED) REFRESH
# restrict startup of policy agent
RDEFINE OPERCMDS MVS.SERVMGR.PAGENT UACC(NONE) +
DATA('restrict startup of policy agent')
PERMIT MVS.SERVMGR.PAGENT CLASS(OPERCMDS) ACCESS(CONTROL) ID(PAGENT)
# refresh to make the changes visible
SETROPTS RACLIST(OPERCMDS) REFRESH
# block stack access between stack and AT-TLS availability
# SETROPTS GENERIC(SERVAUTH)
# SETROPTS CLASSACT(SERVAUTH) RACLIST(FACILITY)
RDEFINE SERVAUTH EZB.INITSTACK.** UACC(NONE)
# Policy Agent
PERMIT EZB.INITSTACK.** CLASS(SERVAUTH) ACCESS(READ) ID(PAGENT)
# OMPROUTE daemon
PERMIT EZB.INITSTACK.** CLASS(SERVAUTH) ACCESS(READ) ID(OMPROUTE)
# SNMP agent and subagents
PERMIT EZB.INITSTACK.** CLASS(SERVAUTH) ACCESS(READ) ID(OSNMPD)
PERMIT EZB.INITSTACK.** CLASS(SERVAUTH) ACCESS(READ) ID(IOBSNMP)
# NAME daemon
PERMIT EZB.INITSTACK.** CLASS(SERVAUTH) ACCESS(READ) ID(NAMED)
# refresh to make the changes visible
SETROPTS RACLIST(SERVAUTH) REFRESH
# restrict access to pasearch command
# RDEFINE SERVAUTH EZB.PAGENT.** UACC(NONE) +
# DATA('restrict access to pasearch command')
# PERMIT EZB.PAGENT.** CLASS(SERVAUTH) ACCESS(READ) ID(tcpadmin)
# refresh to make the changes visible
# SETROPTS RACLIST(SERVAUTH) REFRESH
# permit Debug Manager to access certificates
#RDEFINE FACILITY IRR.DIGTCERT.LIST UACC(NONE)
#RDEFINE FACILITY IRR.DIGTCERT.LISTRING UACC(NONE)
PERMIT IRR.DIGTCERT.LIST CLASS(FACILITY) ACCESS(READ) ID(stcdbm)
PERMIT IRR.DIGTCERT.LISTRING CLASS(FACILITY) ACCESS(READ) ID(stcdbm)
# refresh to make the changes visible
SETROPTS RACLIST(FACILITY) REFRESH
# create self-signed certificate
RACDCERT ID(stcdbm) GENCERT SUBJECTSDN(CN('RDz Debug Manager') +
OU('RTP labs') O('IBM') L('Raleigh') SP('NC') C('US')) +
NOTAFTER(DATE(2015-12-31)) KEYUSAGE(HANDSHAKE) WITHLABEL('dbgmgr')
# (optional) additional steps required to use a signed certificate
# 1. create a signing request for the self-signed certificate
RACDCERT ID(stcdbm) GENREQ (LABEL('dbgmgr')) DSN(dsn)
# 2. send the signing request to your CA of choice
# 3. check if the CA credentials (also a certificate) are already known
RACDCERT CERTAUTH LIST
# 4. mark the CA certificate as trusted
RACDCERT CERTAUTH ALTER(LABEL('CA cert')) TRUST
# or add the CA certificate to the database
RACDCERT CERTAUTH ADD(dsn) WITHLABEL('CA cert') TRUST
# 5. add the signed certificate to the database;
# this will replace the self-signed one
RACDCERT ID(stcdbm) ADD(dsn) WTIHLABEL('dbgmgr') TRUST
# Do NOT delete the self-signed certificate before replacing it.
# If you do, you lose the private key that goes with the certificate,
# which makes the certificate useless.
# create key ring
RACDCERT ID(stcdbm) ADDRING(dbgmgr.racf)
# add certificate to key ring
RACDCERT ID(stcbm) CONNECT(LABEL('dbgmgr') +
RING(dbgmgr.racf) USAGE(PERSONAL) DEFAULT)
# additional step required to use a signed certificate
# 6. add CA certificate to key ring
RACDCERT ID(stcdbm) CONNECT(CERTAUTH LABEL('CA cert') +
RING(dbgmgr.racf))
# refresh to make the changes visible
SETROPTS RACLIST(DIGTCERT) REFRESH
# check if the CA credentials (also a certificate) are already known
RACDCERT CERTAUTH LIST
# mark the CA certificate as trusted
RACDCERT CERTAUTH ALTER(LABEL('CA cert')) TRUST
# or add the CA certificate to the database
RACDCERT CERTAUTH ADD(dsn) WITHLABEL('CA cert') TRUST
# refresh to make the changes visible
SETROPTS RACLIST(DIGTCERT) REFRESH
# verify started task setup
LISTGRP SYS1 OMVS
LISTUSER PAGENT OMVS
RLIST STARTED PAGENT.* ALL STDATA
# verify Policy Agent startup permission
RLIST OPERCMDS MVS.SERVMGR.PAGENT ALL
# verify initstack protection
RLIST SERVAUTH EZB.INITSTACK.** ALL
# verify pasearch protection
RLIST SERVAUTH EZB.PAGENT.** ALL
# verify certificate setup
RACDCERT CERTAUTH LIST(LABEL('CA cert'))
RACDCERT ID(stcdbm) LIST(LABEL('dbgmgr'))
RACDCERT ID(stcdbm) LISTRING(dbgmgr.racf)
TCPCONFIG TTLS
V TCPIP,,OBEY,TCPIP.TCPPARMS(OBEY)
EZZ4249I stackname INSTALLED TTLS POLICY HAS NO RULES
S PAGENT
EZD1586I PAGENT HAS INSTALLED ALL LOCAL POLICIES FOR stackname
P DBGMGR
S DBBMGR
Dieser Abschnitt soll Sie bei einigen allgemeinen Problemen unterstützen, die beim Konfigurieren von TCP/IP oder beim Überprüfen oder Modifizieren einer vorhandenen Konfiguration auftreten könnten.
Zusätzliche Informationen zur TCP/IP-Konfiguration finden Sie im Communications Server: IP Configuration Guide (IBM Form SC31-8775) und in der Veröffentlichung Communications Server: IP Configuration Reference (IBM Form SC31-8776).
Wenn Sie APPC für TSO Commands Service verwenden, ist Developer for System z bei der Initialisierung darauf angewiesen, dass TCP/IP mit dem richtigen Hostnamen konfiguriert ist. Dies impliziert, dass die verschiedenen TCP/IP- und Resolverkonfigurationsdateien ordnungsgemäß definiert sein müssen.
Sie können Ihre TCP/IP-Konfiguration mit dem Installationsprüfprogramm fekfivpt testen. Der Befehl sollte eine Ausgabe wie im folgenden Beispiel zurückgeben ($ ist die z/OS UNIX-Eingabeaufforderung):
$ fekfivpt
Wed Jul 2 13:11:54 EDT 2008
uid=1(USERID) gid=0(GROUP)
using /etc/rdz/rsed.envvars
-------------------------------------------------------------
TCP/IP resolver configuration (z/OS UNIX search order):
-------------------------------------------------------------
Resolver Trace Initialization Complete -> 2008/07/02 13:11:54.745964
res_init Resolver values:
Global Tcp/Ip Dataset = None
Default Tcp/Ip Dataset = None
Local Tcp/Ip Dataset = /etc/resolv.conf
Translation Table = Default
UserId/JobName = USERID
Caller API = LE C Sockets
Caller Mode = EBCDIC
(L) DataSetPrefix = TCPIP
(L) HostName = CDFMVS08
(L) TcpIpJobName = TCPIP
(L) DomainOrigin = RALEIGH.IBM.COM
(L) NameServer = 9.42.206.2
9.42.206.3
(L) NsPortAddr = 53 (L) ResolverTimeout = 10
(L) ResolveVia = UDP (L) ResolverUdpRetries = 1
(*) Options NDots = 1
(*) SockNoTestStor
(*) AlwaysWto = NO (L) MessageCase = MIXED
(*) LookUp = DNS LOCAL
res_init Succeeded
res_init Started: 2008/07/02 13:11:54.755363
res_init Ended: 2008/07/02 13:11:54.755371
************************************************************************
MVS TCP/IP NETSTAT CS V1R9 TCPIP Name: TCPIP 13:11:54
Tcpip started at 01:28:36 on 06/23/2008 with IPv6 enabled
-------------------------------------------------------------
host IP address:
-------------------------------------------------------------
hostName=CDFMVS08
hostAddr=9.42.112.75
bindAddr=9.42.112.75
localAddr=9.42.112.75
Success, addresses match
Der Resolver arbeitet für Programme als ein Client, der für die Auflösung von Namen in Adressen oder von Adressen in Namen auf Namensserver zugreift. Für die Anforderung eines aufrufenden Programms kann der Resolver auf verfügbare Namensserver zugreifen, lokale Definitionen verwenden (z. B. /etc/resolv.conf, /etc/hosts, /etc/ipnodes, HOSTS.SITEINFO, HOSTS.ADDRINFO oder ETC.IPNODES) oder eine Kombination aus beiden Möglichkeiten anwenden.
Beim Starten des Adressraums des Resolvers wird eine optionale Resolverkonfigurationsdatei gelesen, auf die die DD-Karte SETUP in der JCL-Prozedur des Resolvers zeigt. Wenn die Konfigurationsdaten nicht zur Verfügung stehen, greift der Resolver auf die anwendbare native MVS- oder z/OS UNIX-Suchreihenfolge ohne Angaben von GLOBALTCPIPDATA, DEFAULTTCPIPDATA, GLOBALIPNODES, DEFAULTIPNODES oder COMMONSEARCH zurück.
Es ist wichtig, dass Sie die von TCP/IP-Funktionen verwendete Suchreihenfolge für Konfigurationsdateien verstehen und wissen, wann Sie die Standardsuchreihenfolge mit Umgebungsvariablen, JCL oder anderen von Ihnen angegebenen Variablen außer Kraft setzen können. Ausgehend von diesen Kenntnissen können Sie Ihre Benennungsstandards für lokale Dateien und HFS-Dateien anpassen. Außerdem ist es bei der Fehlerdiagnose hilfreich zu wissen, welche Konfigurationsdatei oder HFS-Datei verwendet wird.
Ein anderer wichtiger Punkt ist, dass die Suche bei Anwendung einer Suchreihenfolge für Konfigurationsdateien bei der ersten gefundenen Datei beendet wird. Wenn Sie Konfigurationsdaten in eine Datei stellen, die nie gefunden wird, weil es in der Suchreihenfolge vorher eine andere Datei gibt oder die Datei nicht von der Suchreihenfolge, die die Anwendung gewählt hat, erfasst wird, kann es daher zu unerwarteten Ergebnissen kommen.
Bei der Suche nach Konfigurationsdateien können Sie TCP/IP mit DD-Anweisungen in den JCL-Prozeduren oder durch das Setzen von Umgebungsvariablen explizit mitteilen, wo sich die meisten Konfigurationsdateien befinden. Sie können TCP/IP die Position der Konfigurationsdateien aber auch dynamisch auf der Grundlage der Suchreihenfolgen ermitteln lassen. Diese Suchreihenfolgen sind im Communications Server: IP Configuration Guide (IBM Form SC31-8775) dokumentiert.
Während der Initialisierung des TCP/IP-Stacks verwendet die Konfigurationskomponente des TCP/IP-Stacks TCPIP.DATA, um den HOSTNAME des Stacks zu ermitteln. Zum Abrufen des Wertes wird die Suchreihenfolge für die z/OS UNIX-Umgebung verwendet.
Die Datei oder Tabelle, nach der gesucht wird, kann eine MVS-Datei oder eine HFS-Datei sein. Dies hängt von den Einstellungen in der Resolverkonfiguration und dem Vorhandensein bestimmter Dateien im System ab.
Die Basiskonfigurationsdatei des Resolvers enthält TCPIP.DATA-Anweisungen. Diese Datei wird wegen der enthaltenen Resolveranweisungen referenziert, aber auch, weil sie unter anderem das Dateipräfix (Wert der Anweisung DATASETPREFIX) für den Zugriff auf die in diesem Abschnitt genannten Konfigurationsdateien enthält.
Für den Zugriff auf die Basiskonfigurationsdatei des Resolvers wird diese Suchreihenfolge verwendet:
Wenn der Wert der Konfigurationsanweisung GLOBALTCPIPDATA für den Resolver definiert ist, wird er verwendet. (Lesen Sie hierzu auch den Abschnitt Wissenswertes zu Resolvern.) Es wird weiter nach einer zusätzlichen Konfigurationsdatei gesucht. Die Suche endet mit der nächsten gefundenen Datei.
Der Wert der Umgebungsvariablen wird verwendet. Die Suche scheitert, wenn die Datei nicht vorhanden ist oder anderweitig exklusiv zugeordnet ist.
Die dem DD-Namen in SYSTCPD zugeordnete Datei wird verwendet. In der z/OS UNIX-Umgebung hat ein untergeordneter Prozess keinen Zugriff auf die DD-Anweisung SYSTCPD. Dies ist darauf zurückzuführen, dass bei fork()- oder exec-Funktionsaufrufen die SYSTCPD-Zuordnung nicht vom übergeordneten Prozess übernommen wird.
USERID ist die Benutzer-ID, die der aktuellen Sicherheitsumgebung (Adressraum, Task oder Thread) zugeordnet ist.
JOBNAME ist der in der JCL-Anweisung JOB angegebene Name für Batch-Jobs oder der Prozedurname für eine gestartete Prozedur.
Wenn der Wert der Konfigurationsanweisung DEFAULTTCPIPDATA für den Resolver definiert ist, wird er verwendet. (Lesen Sie hierzu auch den Abschnitt Wissenswertes zu Resolvern.)
Die Umsetztabellen (EBCDIC zu ASCII und ASCII zu EBCDIC) werden referenziert, um die zu verwendenden Umsetzungsdateien zu ermitteln. Für den Zugriff auf diese Konfigurationsdatei wird die folgende Suchreihenfolge verwendet (die Suche endet mit der ersten gefundenen Datei):
USERID ist die Benutzer-ID, die der aktuellen Sicherheitsumgebung (Adressraum oder Task/Thread) zugeordnet ist.
JOBNAME ist der in der JCL-Anweisung JOB angegebene Name für Batch-Jobs oder der Prozedurname für eine gestartete Prozedur.
HLQ repräsentiert den Wert der Anweisung DATASETPREFIX in der Basiskonfigurationsdatei des Resolvers, der verwendet wird, wenn er aufgefunden wird. Andernfalls wird der Standard-HLQ TCPIP verwendet.
Standardmäßig versucht der Resolver zuerst, konfigurierte Domänennamensserver für Auflösungsanforderungen zu verwenden. Falls die Auflösungsanforderung nicht erfüllt werden kann, werden lokale Hosttabellen genutzt. Das Verhalten des Resolvers wird von TCPIP.DATA-Anweisungen gesteuert.
Die TCPIP.DATA-Resolveranweisungen definieren, ob und ggf. wie Domänennamensserver zu verwenden sind. Außerdem kann mit der Anweisung LOOKUP TCPIP.DATA gesteuert werden, wie Domänennamensserver und lokale Hosttabellen verwendet werden sollen. Weitere Informationen zu TCPIP.DATA-Anweisungen finden Sie in der Veröffentlichung Communications Server: IP Configuration Reference (IBM Form SC31-8776).
Der Resolver verwendet die spezifische Suchreihenfolge für Sitenamen von IPv4 uneingeschränkt für getnetbyname-API-Aufrufe. Die spezifische Suchreihenfolge für Sitenamen von IPv4 ist wie folgt. Die Suche endet mit der ersten gefundenen Datei:
Der Wert der Umgebungsvariable ist der Name der Informationsdatei HOSTS.SITEINFO, die mit dem TSO-Befehl MAKESITE erstellt wurde.
Dies ist der Name der mit dem TSO-Befehl MAKESITE erstellten Informationsdatei HOSTS.ADDRINFO.
USERID ist die Benutzer-ID, die der aktuellen Sicherheitsumgebung (Adressraum oder Task/Thread) zugeordnet ist.
JOBNAME ist der in der JCL-Anweisung JOB angegebene Name für Batch-Jobs oder der Prozedurname für eine gestartete Prozedur.
HLQ repräsentiert den Wert der Anweisung DATASETPREFIX in der Basiskonfigurationsdatei des Resolvers, der verwendet wird, wenn er aufgefunden wird. Andernfalls wird der Standard-HLQ TCPIP verwendet.
Wie bereits erwähnt, ist Developer for System z bei der Initialisierung davon abhängig, dass TCP/IP mit dem richtigen Hostnamen konfiguriert ist, wenn Sie APPC verwenden. Dies impliziert, dass die verschiedenen TCP/IP- und Resolverkonfigurationsdateien ordnungsgemäß definiert sein müssen.
Im folgenden Beispiel geht es hauptsächlich um einige Konfigurationstasks für TCP/IP und den Resolver. Beachten Sie, dass es sich nicht um eine komplette Konfiguration für TCP/IP oder den Resolver handelt. Das Beispiel hebt nur einige wichtige Aspekte hervor, die auf Ihren Standort anwendbar sein könnten.
//TCPIP PROC PARMS=’CTRACE(CTIEZB00)’,PROF=TCPPROF,DATA=TCPDATA
//*
//* TCP/IP NETWORK
//*
//TCPIP EXEC PGM=EZBTCPIP,REGION=0M,TIME=1440,PARM=&PARMS
//PROFILE DD DISP=SHR,DSN=SYS1.TCPPARMS(&PROF)
//SYSTCPD DD DISP=SHR,DSN=SYS1.TCPPARMS(&DATA)
//SYSPRINT DD SYSOUT=*,DCB=(RECFM=VB,LRECL=132,BLKSIZE=136)
//ALGPRINT DD SYSOUT=*,DCB=(RECFM=VB,LRECL=132,BLKSIZE=136)
//CFGPRINT DD SYSOUT=*,DCB=(RECFM=VB,LRECL=132,BLKSIZE=136)
//SYSOUT DD SYSOUT=*,DCB=(RECFM=VB,LRECL=132,BLKSIZE=136)
//CEEDUMP DD SYSOUT=*,DCB=(RECFM=VB,LRECL=132,BLKSIZE=136)
//SYSERROR DD SYSOUT=*
; HOSTNAME gibt den TCP-Hostnamen dieses Systems an. Wenn kein
; Wert angegeben ist, wird für HOSTNAME standardmäßig der im PARMLIB-Member
; IEFSSNxx angegebene Knotenname verwendet.
;
; HOSTNAME
;
; DOMAINORIGIN gibt den Domänenursprung an, der an Hostnamen angehängt wird,
; die an den Resolver übergeben werden. Enthält ein Hostname
; Punkte, wird der Wert von DOMAINORIGIN nicht
; an den Hostnamen angehängt.
;
DOMAINORIGIN RALEIGH.IBM.COM
;
; NSINTERADDR gibt die IP-Adresse des Namensservers an.
; LOOPBACK (14.0.0.0) gibt Ihren lokalen Namensserver an. Wenn kein
; Namensserver verwendet wird, codieren Sie keine Anweisung NSINTERADDR.
; (Setzen Sie die folgende Zeile NSINTERADDR auf Kommentar, wenn alle
; Namen durch eine Suche in der Standorttabelle aufgelöst werden sollen.)
;
; NSINTERADDR 14.0.0.0
;
; TRACE RESOLVER bewirkt, dass ein vollständiger Trace für alle Abfragen an den
; Namensserver oder an Standorttabellen und alle entsprechenden Antworten auf die
; Benutzerkonsole geschrieben werden. Der Befehl ist nur für Debugzwecke bestimmt.
;
; TRACE RESOLVER
//RESOLVER PROC PARMS=’CTRACE(CTIRES00)’
//*
//* RESOLVER FÜR IP-NAMEN – BEGINN MIT SUB=MSTR
//*
//RESOLVER EXEC PGM=EZBREINI,REGION=0M,TIME=1440,PARM=&PARMS
//*SETUP DD DISP=SHR,DSN=USER.PROCLIB(RESSETUP),FREE=CLOSE
TCPIPJOBNAME TCPIP
DomainOrigin RALEIGH.IBM.COM
HostName CDFMVS08
Wie im Abschnitt Suchreihenfolgen in der z/OS UNIX-Umgebung erwähnt, enthält die Basiskonfigurationsdatei TCPIP.DATA-Anweisungen. Wenn der Systemname CDFMVS08 lautet, sehen Sie, dass /etc/resolv.conf mit SYS1.TCPPARMS(TCPDATA) synchron ist. (TCPDATA gibt an, dass der Systemname als Hostname verwendet werden soll.) Es liegen keine DNS-Definitionen vor, sodass die Standorttabellen durchsucht werden.
# Resolver /etc/hosts-Datei cdfmvs08
9.42.112.75 cdfmvs08 # CDFMVS08 Host
9.42.112.75 cdfmvs08.raleigh.ibm.com # CDFMVS08 Host
127.0.0.1 localhost
Der minimale Inhalt dieser Datei bezieht sich auf das aktuelle System. Im vorangegangenen Beispiel ist sowohl cdfmvs08 als auch cdfmvs08.raleigh.ibm.com als gültiger Name für die IP-Adresse des z/OS-Systems definiert.
Wenn ein Domänennamensserver (DNS) verwendet werden würde, würde der DNS die /etc/hosts-Informationen enthalten und /etc/resolv.conf und SYS1.TCPPARMS(TCPDATA) würden Anweisungen enthalten, die den DNS für das System identifizieren.
Um Unklarheiten zu vermeiden, sollten die Konfigurationsdateien für TCP/IP und den Resolver synchron sein.
Beschreibung des Dateityps | Betroffene APIs | Mögliche Dateien |
---|---|---|
Basiskonfigurationsdateien des Resolvers | Alle APIs |
|
Umsetztabellen | Alle APIs |
|
Lokale Hosttabellen | endhostent |
IPV4
IPV6
|
clientip(0.0.0.0) <> callerip(<Host-IP-Adresse>)
Resolver Trace Initialization Complete -> 2008/07/02 13:11:54.745964
res_init Resolver values:
Global Tcp/Ip Dataset = None
Default Tcp/Ip Dataset = None
Local Tcp/Ip Dataset = /etc/resolv.conf
Translation Table = Default
UserId/JobName = USERID
Caller API = LE C Sockets
Caller Mode = EBCDIC
Vergewissern Sie sich, dass die Definitionen in der von “Local Tcp/Ip Dataset” referenzierten Datei stimmen.
Wenn Sie für die IP-Resolver-Datei keinen Standardnamen verwenden, bleibt dieses Feld leer (bei Verwendung der z/OS UNIX-Suchreihenfolge). Fügen Sie in dem Fall die folgende Anweisung zu rsed.envvars hinzu. <Resolver-Datei> bzw. <Resolver-Daten> repräsentieren hier den Namen Ihrer IP-Resolver-Datei:
RESOLVER_CONFIG=<Resolver-Datei>
oder
RESOLVER_CONFIG='<Resolver-Daten>'
In diesem Dokument werden die folgenden Veröffentlichungen referenziert:
Titel der Veröffentlichung | Formnummer | Bezug | Referenzwebsite |
---|---|---|---|
Program Directory for IBM Rational Developer for System z | GI11-8298 | Developer for System z | http://www-01.ibm.com/support/docview.wss?uid=swg27038517 |
Program Directory for IBM Rational Developer for System z Host Utilities | GI13-2864 | Developer for System z | http://www-01.ibm.com/support/docview.wss?uid=swg27038517 |
IBM Rational Developer for System z Voraussetzungen | SC23-7659 | Developer for System z | http://www-01.ibm.com/support/docview.wss?uid=swg27038517 |
IBM Rational Developer for System z Leitfaden für den Schnelleinstieg in die Hostkonfiguration | GI11-3191 | Developer for System z | http://www-01.ibm.com/support/docview.wss?uid=swg27038517 |
IBM Rational Developer for System zHostkonfiguration | SC12-4062 | Developer for System z | http://www-01.ibm.com/support/docview.wss?uid=swg27038517 |
IBM Rational Developer for System zHostkonfigurationsreferenz | SC12-4489 | Developer for System z | http://www-01.ibm.com/support/docview.wss?uid=swg27038517 |
IBM Rational Developer for System z Host Configuration Utility | SC14-7282 | Developer for System z | http://www-01.ibm.com/support/docview.wss?uid=swg27038517 |
IBM Rational Developer for System z Messages and Codes | SC14-7497 | Developer for System z | http://www-01.ibm.com/support/docview.wss?uid=swg27038517 |
IBM Rational Developer for System z - Antworten auf gängige Fragen der Hostkonfiguration und -wartung | SC12-4724 | Developer for System z | http://www-01.ibm.com/support/docview.wss?uid=swg27038517 |
IBM Rational Developer for System z Common Access Repository Manager Developer's Guide | SC23-7660 | Developer for System z | http://www-01.ibm.com/support/docview.wss?uid=swg27038517 |
IBM Rational Developer for System z Voraussetzungen | SC23-7659 | Developer for System z | http://www.ibm.com/software/rational/products/developer/systemz/library/index.html |
IBM Rational Developer for System z Leitfaden für den Schnelleinstieg in die Hostkonfiguration | GI11-3191 | Developer for System z | http://www.ibm.com/software/rational/products/developer/systemz/library/index.html |
SCLM Developer Toolkit Administrator's Guide | SC23-9801 | Developer for System z | http://www-01.ibm.com/support/docview.wss?uid=swg27038517 |
Using APPC to provide TSO command services | SC14-7291 | White Paper | http://www-01.ibm.com/support/docview.wss?uid=swg27038517 |
Using ISPF Client Gateway to provide CARMA services | SC14-7292 | White Paper | http://www-01.ibm.com/support/docview.wss?uid=swg27038517 |
Communications Server IP Configuration Guide | SC31-8775 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Communications Server IP Configuration Reference | SC31-8776 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Communications Server IP Diagnosis Guide | GC31-8782 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Communications Server IP System Administrator's Commands | SC31-8781 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Communications Server SNA Network Implementation Guide | SC31-8777 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Communications Server SNA Operations | SC31-8779 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Cryptographic Services System SSL Programming | SC24-5901 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
DFSMS Macro Instructions for Data Sets | SC26-7408 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
DFSMS Using data sets | SC26-7410 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Language Environment Customization | SA22-7564 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Language Environment Debugging Guide | GA22-7560 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
MVS Diagnosis: Tools and Service Aids | GA22-7589 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
MVS Initialization and Tuning Guide | SA22-7591 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
MVS Initialization and Tuning Reference | SA22-7592 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
MVS JCL Reference | SA22-7597 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
MVS Planning: APPC/MVS Management | SA22-7599 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
MVS Planning Workload Management | SA22-7602 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
MVS System Commands | SA22-7627 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Security Server RACF Command Language Reference | SA22-7687 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Security Server RACF Security Administrator's Guide | SA22-7683 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
TSO/E Customization | SA22-7783 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
TSO/E REXX Reference | SA22-7790 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
UNIX System Services Command Reference | SA22-7802 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
UNIX System Services Planning | GA22-7800 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
UNIX System Services User's Guide | SA22-7801 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Using REXX and z/OS UNIX System Services | SA22-7806 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Java™ Diagnostic Guide | SC34-6650 | Java 6.0 | http://www.ibm.com/developerworks/java/jdk/diagnosis/ |
Java SDK and Runtime Environment User Guide | / | Java 6.0 | http://www-03.ibm.com/servers/eserver/zseries/software/java/ |
Resource Definition Guide | SC34-6430 | CICS TS 3.1 | http://www-03.ibm.com/systems/z/os/zos/bkserv/zapplsbooks.html |
Resource Definition Guide | SC34-6815 | CICSTS 3.2 | http://www-03.ibm.com/systems/z/os/zos/bkserv/zapplsbooks.html |
Resource Definition Guide | SC34-7000 | CICSTS 4.1 | https://publib.boulder.ibm.com/infocenter/cicsts/v4r1/index.jsp?topic=/com.ibm.cics.ts.home.doc/library/library_html.html |
Resource Definition Guide | SC34-7181 | CICSTS 4.2 | https://publib.boulder.ibm.com/infocenter/cicsts/ v4r2/index.jsp?topic=/com.ibm.cics.ts.home.doc/ library/library_html.html |
RACF Security Guide | SC34-6454 | CICS TS 3.1 | http://www-03.ibm.com/systems/z/os/zos/bkserv/zapplsbooks.html |
RACF Security Guide | SC34-6835 | CICSTS 3.2 | http://www-03.ibm.com/systems/z/os/zos/bkserv/zapplsbooks.html |
RACF Security Guide | SC34-7003 | CICSTS 4.1 | https://publib.boulder.ibm.com/infocenter/cicsts/v4r1/index.jsp?topic=/com.ibm.cics.ts.home.doc/library/library_html.html |
RACF Security Guide | SC34-7179 | CICSTS 4.2 | https://publib.boulder.ibm.com/infocenter/cicsts/v4r2/index.jsp?topic=/com.ibm.cics.ts.home.doc/library/library_html.html |
Language Reference | SC27-1408 | Enterprise COBOL für z/OS | http://www-03.ibm.com/systems/z/os/zos/bkserv/zapplsbooks.html |
Beschreibung | Referenzwebsite |
---|---|
Developer for System z IBM Knowledge Center | http://www-01.ibm.com/support/knowledgecenter/SSQ2R2_9.1.0/com.ibm.etools.getstart.wsentdev.doc/kc_version_welcome_rdz.html |
Developer for System z Library | http://www-01.ibm.com/support/docview.wss?uid=swg27038517 |
Homepage von Developer for System z | http://www-03.ibm.com/software/products/en/developerforsystemz/ |
Developer for System z Recommended service | http://www-01.ibm.com/support/docview.wss?rs=2294&context=SS2QJ2&uid=swg27006335 |
Verbesserungsvorschlag für Developer for System z | https://www.ibm.com/developerworks/support/rational/rfe/ |
z/OS-Internetbibliothek | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
CICSTS IBM Knowledge Center | https://publib.boulder.ibm.com/infocenter/cicsts/v4r1/index.jsp |
IBM Tivoli Directory Server | http://www-01.ibm.com/software/tivoli/products/directory-server/ |
Plug-ins für Tools zur Fehlerbestimmung | http://www-01.ibm.com/software/awdtools/deployment/pdtplugins/ |
Informationen zur Java-Sicherheit | http://www.ibm.com/developerworks/java/jdk/security/ |
Download von Apache Ant | http://ant.apache.org/ |
Java-Keytool-Dokumentation | http://java.sun.com/j2se/1.5.0/docs/tooldocs/solaris/keytool.html |
Homepage der CA-Unterstützung | https://support.ca.com/ |
Titel der Veröffentlichung | Formnummer | Bezug | Referenzwebsite |
---|---|---|---|
ABCs of z/OS System Programming Volume 9 (z/OS UNIX) | SG24-6989 | Redbook | http://www.redbooks.ibm.com/ |
System Programmer’s Guide to: Workload Manager | SG24-6472 | Redbook | http://www.redbooks.ibm.com/ |
TCPIP Implementation Volume 1: Base Functions, Connectivity, and Routing | SG24-7532 | Redbook | http://www.redbooks.ibm.com/ |
TCPIP Implementation Volume 3: High Availability, Scalability, and Performance | SG24-7534 | Redbook | http://www.redbooks.ibm.com/ |
TCP/IP Implementation Volume 4: Security and Policy-Based Networking | SG24-7535 | Redbook | http://www.redbooks.ibm.com/ |
Tivoli Directory Server for z/OS | SG24-7849 | Redbook | http://www.redbooks.ibm.com/ |
© Copyright IBM Corporation 1992, 2013.
Die vorliegenden Informationen wurden für Produkte und Services entwickelt, die auf dem deutschen Markt angeboten werden.
Möglicherweise bietet IBM die in dieser Dokumentation beschriebenen Produkte, Services oder Funktionen in anderen Ländern nicht an. Informationen über die gegenwärtig im jeweiligen Land verfügbaren Produkte und Services sind beim zuständigen IBM Ansprechpartner erhältlich. Hinweise auf IBM Lizenzprogramme oder andere IBM Produkte bedeuten nicht, dass nur Programme, Produkte oder Services von IBM verwendet werden können. Anstelle der IBM Produkte, Programme oder Services können auch andere, ihnen äquivalente Produkte, Programme oder Services verwendet werden, solange diese keine gewerblichen oder anderen Schutzrechte von IBM verletzen. Die Verantwortung für den Betrieb von Produkten, Programmen und Services anderer Anbieter liegt beim Kunden.
Für in diesem Handbuch beschriebene Erzeugnisse und Verfahren kann es IBM Patente oder Patentanmeldungen geben. Mit der Auslieferung dieses Handbuchs ist keine Lizenzierung dieser Patente verbunden. Lizenzanforderungen sind schriftlich an folgende Adresse zu richten (Anfragen an diese Adresse müssen auf Englisch formuliert werden):
IBM Director of Licensing
IBM Europe, Middle East & Africa
Tour Descartes
2, avenue Gambetta
92066 Paris La Defense
France
Trotz sorgfältiger Bearbeitung können technische Ungenauigkeiten oder Druckfehler in dieser Veröffentlichung nicht ausgeschlossen werden. Die Angaben in diesem Handbuch werden in regelmäßigen Zeitabständen aktualisiert. Die Änderungen werden in Überarbeitungen oder in Technical News Letters (TNLs) bekannt gegeben. IBM kann ohne weitere Mitteilung jederzeit Verbesserungen und/oder Änderungen an den in dieser Veröffentlichung beschriebenen Produkten und/oder Programmen vornehmen.
Verweise in diesen Informationen auf Websites anderer Anbieter werden lediglich als Service für den Kunden bereitgestellt und stellen keinerlei Billigung des Inhalts dieser Websites dar. Das über diese Websites verfügbare Material ist nicht Bestandteil des Materials für dieses IBM Produkt. Die Verwendung dieser Websites geschieht auf eigene Verantwortung.
Werden an IBM Informationen eingesandt, können diese beliebig verwendet werden, ohne dass eine Verpflichtung gegenüber dem Einsender entsteht.
Lizenznehmer des Programms, die Informationen zu diesem Produkt wünschen mit der Zielsetzung: (i) den Austausch von Informationen zwischen unabhängigen, erstellten Programmen und anderen Programmen (einschließlich des vorliegenden Programms) sowie (ii) die gemeinsame Nutzung der ausgetauschten Informationen zu ermöglichen, wenden sich an folgende Adresse:
Intellectual Property Dept. for Rational Software
IBM Corporation
Silicon Valley Lab
555 Bailey Avnue
San Jose, CA 95141-1003
U.S.A.
Die Bereitstellung dieser Informationen kann unter Umständen von bestimmten Bedingungen - in einigen Fällen auch von der Zahlung einer Gebühr - abhängig sein.
Die Lieferung des im Dokument aufgeführten Lizenzprogramms sowie des zugehörigen Lizenzmaterials erfolgt auf der Basis der IBM Rahmenvereinbarung bzw. der Allgemeinen Geschäftsbedingungen von IBM, der IBM Internationalen Nutzungsbedingungen für Programmpakete oder einer äquivalenten Vereinbarung.
Alle in diesem Dokument enthaltenen Leistungsdaten stammen aus einer kontrollierten Umgebung. Die Ergebnisse, die in anderen Betriebsumgebungen erzielt werden, können daher erheblich von den hier erzielten Ergebnissen abweichen. Einige Daten stammen möglicherweise von Systemen, deren Entwicklung noch nicht abgeschlossen ist. Eine Gewährleistung, dass diese Daten auch in allgemein verfügbaren Systemen erzielt werden, kann nicht gegeben werden. Darüber hinaus wurden einige Daten unter Umständen durch Extrapolation geschätzt. Die tatsächlichen Ergebnisse können davon abweichen. Benutzer dieses Dokuments sollten die entsprechenden Daten in ihrer spezifischen Umgebung prüfen.
Alle Informationen zu Produkten anderer Anbieter stammen von den Anbietern der aufgeführten Produkte, deren veröffentlichten Ankündigungen oder anderen allgemein verfügbaren Quellen. IBM hat diese Produkte nicht getestet und kann daher keine Aussagen zu Leistung, Kompatibilität oder anderen Merkmalen machen. Fragen zu den Leistungsmerkmalen von Produkten anderer Anbieter sind an den jeweiligen Anbieter zu richten.
Die oben genannten Erklärungen bezüglich der Produktstrategien und Absichtserklärungen von IBM stellen die gegenwärtige Absicht von IBM dar, unterliegen Änderungen oder können zurückgenommen werden und repräsentieren nur die Ziele von IBM.
Diese Veröffentlichung enthält Beispiele für Daten und Berichte des alltäglichen Geschäftsablaufs. Sie sollen nur die Funktionen des Lizenzprogramms illustrieren; sie können Namen von Personen, Firmen, Marken oder Produkten enthalten. Alle diese Namen sind frei erfunden; Ähnlichkeiten mit tatsächlichen Namen und Adressen sind rein zufällig.
Diese Veröffentlichung enthält Musteranwendungsprogramme, die in Quellensprache geschrieben sind und Programmiertechniken in verschiedenen Betriebsumgebungen veranschaulichen. Sie dürfen diese Musterprogramme in beliebiger Form kopieren, ändern und verteilen, ohne dass dafür Zahlungen an IBM anfallen, wenn dies zu dem Zweck geschieht, Anwendungsprogramme zu entwickeln, zu verwenden, zu vermarkten oder zu verteilen, die mit der Anwendungsprogrammierschnittstelle für die Betriebsumgebung konform sind, für die diese Musterprogramme geschrieben werden. Diese Beispiele wurden nicht unter allen denkbaren Bedingungen getestet. Daher kann IBM die Zuverlässigkeit, Wartungsfreundlichkeit oder Funktion dieser Programme weder zusagen noch gewährleisten. Die Beispielprogramme werden auf der Grundlage des gegenwärtigen Zustands (auf "as-is"-Basis) und ohne Gewährleistung zur Verfügung gestellt. IBM haftet nicht für Schäden, die durch Verwendung oder im Zusammenhang mit den Beispielprogrammen entstehen.
Kopien oder Teile der Musterprogramme bzw. daraus abgeleiteter Code müssen folgenden Copyrightvermerk beinhalten:
© (Name Ihrer Firma) (Jahr). Teile des vorliegenden Codes wurden aus Musterprogrammen der IBM Corp. abgeleitet. © Copyright IBM Corp. 1992, 2013.
Wird dieses Buch als Softcopy (Book) angezeigt, erscheinen keine Fotografien oder Farbabbildungen.
IBM Softwareprodukte, einschließlich Software as a Service-Lösungen ("Softwareangebote"), können Cookies oder andere Technologien verwenden, um Informationen zur Produktnutzung zu erfassen, die Endbenutzererfahrung zu verbessern und Interaktionen mit dem Endbenutzer anzupassen oder zu anderen Zwecken. In vielen Fällen werden von den Softwareangeboten keine personenbezogenen Daten erfasst. Einige der IBM Softwareangebote können Sie jedoch bei der Erfassung personenbezogener Daten unterstützen. Wenn dieses Softwareangebot Cookies zur Erfassung personenbezogener Daten verwendet, sind nachfolgend nähere Informationen über die Verwendung von Cookies durch dieses Angebot zu finden.
Dieses Softwareangebot verwendet keine Cookies oder andere Technologien zur Erfassung personenbezogener Daten.
IBM, das IBM Logo und ibm.com sind Marken oder eingetragene Marken der International Business Machines Corp. Weitere Produkt- und Servicenamen können Marken von IBM oder anderen Unternehmen sein. Eine aktuelle Liste der IBM Marken finden Sie auf der Webseite "Copyright and trademark information" unter www.ibm.com/legal/copytrade.shtml.
Anwendbarkeit
Diese Bedingungen sind eine Ergänzung der Nutzungsbedingungen auf der IBM Website.
Persönliche Nutzung
Sie dürfen diese Veröffentlichungen für Ihre persönliche, nicht kommerzielle Nutzung unter der Voraussetzung vervielfältigen, dass alle Eigentumsvermerke erhalten bleiben. Sie dürfen diese Veröffentlichungen oder Teile der Veröffentlichungen ohne ausdrückliche Genehmigung des Herstellers weder weitergeben oder anzeigen noch abgeleitete Werke davon erstellen.
Kommerzielle Nutzung
ie dürfen diese Veröffentlichungen nur innerhalb Ihres Unternehmens und unter der Voraussetzung, dass alle Eigentumsvermerke erhalten bleiben, vervielfältigen, weitergeben und anzeigen. Sie dürfen diese Veröffentlichungen oder Teile der Veröffentlichungen ohne ausdrückliche Genehmigung des Herstellers außerhalb Ihres Unternehmens weder vervielfältigen, weitergeben oder anzeigen noch abgeleitete Werke davon erstellen.
Berechtigungen
Abgesehen von den hier gewährten Berechtigungen werden keine weiteren Berechtigungen, Lizenzen oder Rechte (veröffentlicht oder stillschweigend) in Bezug auf die Veröffentlichungen oder darin enthaltene Daten, Software oder geistiges Eigentum gewährt.
IBM behält sich das Recht vor, die hierin gewährten Berechtigungen nach eigenem Ermessen zurückzuziehen, wenn sich die Nutzung der Veröffentlichungen für IBM als nachteilig erweist oder wenn die obigen Nutzungsbestimmungen nicht genau befolgt werden.
Sie dürfen diese Informationen nur in Übereinstimmung mit allen anwendbaren Gesetzen und Vorschriften, einschließlich aller US-amerikanischen Exportgesetze und Verordnungen, herunterladen und exportieren.
IBM übernimmt keine Gewährleistung für den Inhalt dieser Veröffentlichungen. Diese Veröffentlichungen werden auf der Grundlage des gegenwärtigen Zustands (auf "as-is"-Basis) und ohne jede Gewährleistung für die Handelsüblichkeit, die Verwendungsfähigkeit für einen bestimmten Zweck oder die Freiheit von Rechten Dritter zur Verfügung gestellt.
Diese Veröffentlichung enthält Musteranwendungsprogramme, die in Quellensprache geschrieben sind und Programmiertechniken in verschiedenen Betriebsumgebungen veranschaulichen. Sie dürfen diese Musterprogramme kostenlos kopieren, ändern und verteilen, wenn dies zu dem Zweck geschieht, Anwendungsprogramme zu entwickeln, zu verwenden, zu vermarkten oder zu verteilen, die mit der Anwendungsprogrammierschnittstelle für die Betriebsumgebung konform sind, für die diese Musterprogramme geschrieben werden. Diese Beispiele wurden nicht unter allen denkbaren Bedingungen getestet. Daher kann IBM die Zuverlässigkeit, Wartungsfreundlichkeit oder Funktion dieser Programme weder zusagen noch gewährleisten. Die Beispielprogramme werden auf der Grundlage des gegenwärtigen Zustands (auf "as-is"-Basis) und ohne Gewährleistung zur Verfügung gestellt. IBM haftet nicht für Schäden, die durch Verwendung oder im Zusammenhang mit den Beispielprogrammen entstehen.
IBM, das IBM Logo und ibm.com sind Marken oder eingetragene Marken der International Business Machines Corp. Weitere Produkt- und Servicenamen können Marken von IBM oder anderen Unternehmen sein. Eine aktuelle Liste der IBM Marken finden Sie im Web unter www.ibm.com/legal/copytrade.shtml.
Adobe und PostScript sind Marken von Adobe Systems Incorporated.
Cell Broadband Engine - Sony Computer Entertainment Inc.
Rational ist eine Marke der International Business Machines Corporation und der Rational Software Corporation in den USA und/oder anderen Ländern.
Intel, Intel Centrino, Intel SpeedStep, Intel Xeon, Celeron, Itanium und Pentium sind Marken der Intel Corporation in den USA und/oder anderen Ländern.
IT Infrastructure Library ist eine Marke der Central Computer and Telecommunications Agency.
ITIL ist eine Marke des Cabinet Office (The Minister for the Cabinet Office).
Linear Tape-Open, LTO und Ultrium sind Marken von HP, IBM Corp. und Quantum.
Linux ist eine Marke von Linus Torvalds.
Microsoft, Windows und das Windows-Logo sind Marken oder eingetragene Marken der Microsoft Corporation in den USA und/oder anderen Ländern.
Java und alle Java-basierten Marken und Logos sind Marken oder eingetragene Marken von Sun Microsystems, Inc. in den USA und/oder anderen Ländern.
UNIX ist eine eingetragene Marke von The Open Group in den USA und anderen Ländern.