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.

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.

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.

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.

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:

• Das Lademodul FEJJMON, das sich standardmäßig in der Ladebibliothek FEK.SFEKAUTH befindet, muss für APF autorisiert sein.
• RSE und JES Job Monitor müssen dieselbe Anwendungs-ID (APPLID) verwenden. Als Anwendungs-ID wird von beiden Servern standardmäßig FEKAPPL verwendet. Dies kann jedoch durch die Anweisung der Anwendungs-ID in rsed.envvars für RSE und in FEJJCNFG für JES Job Monitor geändert werden.

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.

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.

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.

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.

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

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.

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.

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

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

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

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.

1. RACF überprüft, ob das Zertifikat in der DIGTCERT-Klasse definiert ist. Falls dies der Fall ist, gibt RACF die Benutzer-ID zurück, die diesem Zertifikat beim Hinzufügen zur RACF-Datenbank zugeordnet wurde.
   Zertifikate werden mithilfe des RACDCERT-Befehls in RACF definiert, wie das folgende Beispiel zeigt:

   RACDCERT ID(userid) ADD(dsn) TRUST WITHLABEL('Bezeichnung')

2. Wenn das Zertifikat nicht definiert ist, überprüft RACF, ob ein entsprechender Zertifikatsnamensfilter in den Klassen DIGTNMAP oder DIGTCRIT definiert ist. Wenn dies der Fall ist, gibt es die Benutzer-ID zurück, die dem passendsten Filter zugeordnet ist.
   Anmerkung: Es wird empfohlen, für Zertifikate, die von Developer for System z verwendet werden, keine Namensfilter zu verwenden, da diese Filter alle Zertifikate einer einzigen Benutzer-ID zuordnen. Dies bedeutet, dass sich alle Benutzer von Developer for System z mit derselben Benutzer-ID anmelden.
3. Wenn kein passender Namensfilter vorhanden ist, sucht RACF die HostIdMappings-Zertifikatserweiterung und extrahiert die eingebettete Benutzer-ID und das Hostnamenspaar. Wenn er jedoch gefunden und überprüft wird, gibt RACF die Benutzer-ID zurück, die in der HostIdMappings-Erweiterung definiert ist.
   Die Benutzer-ID und das Hostnamenspaar sind gültig, wenn alle folgenden Bedingungen wahr sind:

   • Das CA-Zertifikat, das zur Unterzeichnung dieses Zertifikats verwendet wird, ist in der DIGTCERT-Klasse als HIGHTRUST markiert.
   • Die in der Erweiterung gespeicherte Benutzer-ID besitzt eine gültige Länge (1 bis 8 Zeichen).
   • Die dem RSE-Dämon zugeordnete Benutzer-ID verfügt für das IRR.HOST.hostname-Profil in der SERVAUTH-Klasse über (mindestens) LESEBERECHTIGUNG, wobei der hostname dem in der Erweiterung gespeicherten Hostnamen entspricht. Hierbei handelt es sich normalerweise um einen Domänennamen, wie CDFMVS08.RALEIGH.IBM.COM.
   Die Definition der HostIdMappings-Erweiterung lautet in ASN.1-Syntax:

   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
    }

   Anmerkung: Eine HostIdMappings-Erweiterung wird nicht berücksichtigt, wenn die Zielbenutzer-ID nach Beginn des Gültigkeitszeitraums des Zertifikats erstellt wurde, das die HostIdMappings-Erweiterung enthält. Stellen Sie daher sicher, dass Sie beim Erstellen von Benutzer-IDs speziell für Zertifikate mit HostIdMappings-Erweiterungen die Benutzer-IDs erstellen, bevor die Zertifikatsanforderungen übergeben werden.

   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.

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.

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.

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

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.

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

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:

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

• SETROPTS RACLIST(STARTED) REFRESH

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

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.

• RDEFINE FACILITY BPX.SERVER UACC(NONE)
• PERMIT BPX.SERVER CLASS(FACILITY) ACCESS(UPDATE) ID(STCRSE)
• PERMIT BPX.SERVER CLASS(FACILITY) ACCESS(UPDATE) ID(STCDBM)
• SETROPTS RACLIST(FACILITY) 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 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.

• Alternative REXX-Laufzeitbibliothek für SCLM Developer Toolkit
  • REXX.*.SEAGALT
• Systemladebibliothek für SSL-Verschlüsselung
  • SYS1.SIEALNKE
• Developer for System z-Bibliothek, für Integrated Debugger
  • FEK.SFEKAUTH

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.

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.

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.

• RDEFINE UNIXPRIV SUPERUSER.FILESYS UACC(NONE) DATA('OVERRIDE UNIX FILE ACCESS RESTRICTIONS')
• RDEFINE UNIXPRIV SUPERUSER.FILESYS.CHOWN UACC(NONE) DATA('OVERRIDE UNIX CHANGE OWNER RESTRICTIONS')
• PERMIT SUPERUSER.FILESYS CLASS(UNIXPRIV) ACCESS(READ) ID(STCRSE)
• PERMIT SUPERUSER.FILESYS.CHOWN CLASS(UNIXPRIV) ACCESS(READ) ID(STCRSE)
• SETROPTS RACLIST(UNIXPRIV) REFRESH

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

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.

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.

jesname.MODIFYHOLD.BAT
jesname.MODIFYHOLD.STC
jesname.MODIFYHOLD.TSU

jesname.MODIFYRELEASE.BAT
jesname.MODIFYRELEASE.STC
jesname.MODIFYRELEASE.TSU

jesname.CANCEL.BAT
jesname.CANCEL.STC
jesname.CANCEL.TSU

jesname.CANCEL.BAT
jesname.CANCEL.STC
jesname.CANCEL.TSU

jesname.MODIFY.JOB

jesname.MODIFY.JOB

jesname.MODIFY.JOB

jesname.MODIFY.JOB

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

Verwenden Sie die folgenden Beispielbefehle, um die Ergebnisse Ihrer Anpassungen in Bezug auf die Sicherheit anzuzeigen.

• Sicherheitseinstellungen und -klassen
  • SETROPTS LIST
• OMVS-Segment für Benutzer
  • LISTUSER #userid NORACF OMVS
  • LISTGRP #group-name NORACF OMVS
• Gestartete Tasks
  • LISTGRP STCGROUP OMVS
  • LISTUSER STCDBM OMVS
  • LISTUSER STCJMON OMVS
  • LISTUSER STCRSE OMVS
  • RLIST STARTED DBGMGR.* ALL STDATA
  • RLIST STARTED JMON.* ALL STDATA
  • RLIST STARTED RSED.* ALL STDATA
• RSE als sicherer z/OS UNIX-Server
  • RLIST FACILITY BPX.SERVER ALL
• Programmgesteuerte MVS-Bibliotheken für RSE
  • RLIST PROGRAM ** ALL
• PassTicket-Unterstützung für RSE
  • RLIST PTKTDATA FEKAPPL ALL SSIGNON
  • RLIST PTKTDATA IRRPTAUTH.FEKAPPL.* ALL
• Anwendungsschutz für RSE
  • RLIST APPL FEKAPPL ALL
• z/OS UNIX-Dateizugriffsberechtigung für RSE
  • RLIST UNIXPRIV SUPERUSER.FILESYS ALL
  • RLIST UNIXPRIV SUPERUSER.FILESYS.CHOWN ALL
• JES-Befehlssicherheit
  • RLIST CONSOLE JMON ALL
  • RLIST OPERCMDS MVS.MCSOPER.JMON ALL
  • RLIST OPERCMDS JES%.** ALL
• Integrated Debugger-Zugriff
  • RLIST FACILITY AQE.** ALL
  
• Dateiprofile
  • LISTGRP FEK
  • LISTDSD PREFIX(FEK) ALL

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.

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

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.

1. Richten Sie Developer for System z unter SYS1 wie eine Einzelsystemkonfiguration ein; stellen Sie aber sicher, dass sich /usr/lpp/rdz und /etc/rdz auf einem gemeinsam genutzten Dateisystem befinden. Alle MVS-basierten Teile müssen auch mit SYS2 gemeinsam genutzt werden.
2. Verwenden Sie die Datei /etc/rdz/rsed.envvars als Masterkopie und fügen Sie einen Verweis auf /etc/rdz am Ende der Datei hinzu, damit die systemspezifischen Kopien die übrigen Konfigurationsdateien aufnehmen können.

   $ 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
        # --

3. Erstellen Sie das Shell-Script /etc/rdz/update.sh, mit dem die Masterdatei rsed.envvars kopiert und _RSE_PORTRANGE angepasst wird.

   $ oedit /etc/rdz/update.sh
   $ chmod 755 /etc/rdz/update.sh

   Abbildung 11. update.sh - DDVIPA-Setup mit einer Firewall unterstützen

   #! /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   

4. Erstellen Sie die Verzeichnisse /etc/rdz/SYS1 und /etc/rdz/SYS2 und führen Sie /etc/rdz/update.sh aus, um die Verzeichnisse zu füllen.

   $ 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

5. Stellen Sie sicher, dass die gestarteten Task RSED auf /etc/rdz/&SYSNAME verweist.

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

Abbildung 12. Beispiel für eine verteilte dynamische VIPA

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.

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

Alle gestarteten Tasks von Developer for System z (RSE-Dämon und JES Job Monitor) bedienen Echtzeit-Clientanforderungen.

• JES Job Monitor

  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

  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.

• RSE-Dämon

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

• RSE-Thread-Pool

  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.

• ISPF Client Gateway

  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

  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.

• z/OS UNIX-Build

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

• z/OS UNIX-Shell

  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.

• CARMA

  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.

• MVS-Build
  Wenn ein Client einen Build für ein MVS-Projekt initialisiert, startet Developer for System z zur Ausführung des Builds einen Batch-Job. 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). Abhängig von Ihren lokalen Bedingungen können verschiedene Zielstrategien mit mittlerer Leistung sinnvoll sein.

  • Sie können ein Ziel für mehrere Zeiträume angeben: Für den ersten Zeitraum legen Sie ein Perzentilantwortzeitziel und für den zweiten Zeitraum ein Geschwindigkeitsziel fest. In diesem Fall sollten Ihre Entwickler hauptsächlich dieselbe Buildprozedur und Eingabedateien ähnlicher Größe verwenden, um Jobs mit einheitlichen Antwortzeiten zu erstellen. Damit WLM ein Antwortzeitziel erfolgreich steuern kann, muss auch eine stetige Jobrate eingehen (mindestens 10 Jobs in 20 Minuten).
  • Ein Geschwindigkeitsziel ist für die meisten Batch-Jobs am besten geeignet, da dieses Ziel stark schwankende Ausführungszeiten und Eingangsraten handhaben kann.

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.

• TSO Commands Service

  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.

• Application Deployment Manager

  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.

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.

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.

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_JAVAOPTS="$_RSE_JAVAOPTS -Xms128m -Xmx512m"

Festlegen der anfänglichen Heapgröße (Xms) und der maximalen Heapgröße (Xmx). Die Standardwerte sind jeweils 128M und 512M. Ändern Sie diese, um die gewünschten Werte der Heapgröße zu erzwingen. Wenn diese Anweisung in Kommentarzeichen gesetzt ist, werden die Java-Standardwerte verwendet. Diese sind 4M beziehungsweise 512M.

#_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Dmaximum.clients=30"

Maximale Anzahl der Clients, die ein Thread-Pool bedienen kann. Die Standardeinstellung ist 30. Entfernen Sie das Kommentarzeichen und passen Sie die Option an, um die Anzahl der Clients pro Thread-Pool zu begrenzen. Beachten Sie, dass andere Grenzwerte möglicherweise verhindern, dass RSE diese Begrenzung erreicht.

#_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Dmaximum.threads=520"

Maximale Anzahl von aktiven Threads in einem Thread-Pool, um neue Clients zuzulassen. Die Standardeinstellung ist 520. Entfernen Sie das Kommentarzeichen und passen Sie den Wert an, um die Anzahl der Clients pro Thread-Pool auf Basis der Threads in Gebrauch zu begrenzen. Beachten Sie, dass jede Clientverbindung mehrere Threads (17 oder mehr) verwendet und dass andere Grenzwerte verhindern können, dass RSE diese Begrenzung erreicht.

Anmerkung: Dieser Wert muss kleiner als die Einstellungen MAXTHREADS und MAXTHREADTASKS in SYS1.PARMLIB(BPXPRMxx) sein.

#_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Dminimum.threadpool.process=1"

Minimale Anzahl aktiver Thread-Pools. Die Standardeinstellung ist 1. Entfernen Sie das Kommentarzeichen und passen Sie die Option an, damit mindestens die angegebene Anzahl von Thread-Pool-Prozessen gestartet wird. Thread-Pool-Prozesse werden für die Lastverteilung der RSE-Server-Threads verwendet. Weitere neue Prozesse werden bei Bedarf gestartet. Wenn die neuen Prozesse vorab gestartet werden, werden Verzögerungen bei Verbindungen verhindert. Das System verwendet in Leerlaufzeiten allerdings mehr Ressourcen.

Anmerkung: Wenn die Anweisung single.logon aktiv ist, werden mindestens zwei Thread-Pools gestartet, selbst wenn minimum.threadpool.process auf "1" festgelegt ist. Die Standardeinstellung für single.logon in rsed.envvars ist aktiv.

#_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Dmaximum.threadpool.process=100"

Maximale Anzahl aktiver Thread-Pools. Die Standardeinstellung ist 100. Entfernen Sie das Kommentarzeichen und passen Sie die Option an, um die Anzahl der Thread-Pool-Prozesse zu begrenzen. Thread-Pool-Prozesse werden für die Lastverteilung der RSE-Server-Threads verwendet. Eine Begrenzung ihrer Anzahl bedeutet demzufolge eine Beschränkung der Anzahl aktiver Clientverbindungen.

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:

MAXPROCSYS(nnnnn)

Gibt die maximal zulässige Anzahl von Prozessen im System an.

Wertebereich: 'nnnnn' ist ein Dezimalwert zwischen 5 und 32767.
Standardwert: 900

MAXPROCUSER(nnnnn)

Gibt die maximale Anzahl von Prozessen an, die für eine einzelne z/OS UNIX-Benutzer-ID gleichzeitig aktiv sein dürfen. Dabei spielt es keine Rolle, wie die Prozesse erstellt wurden.

Wertebereich: 'nnnnn' ist ein Dezimalwert zwischen 3 und 32767.
Standardwert: 25

Anmerkung:

• Alle RSE-Prozesse verwenden dieselbe z/OS UNIX-Benutzer-ID (die des Benutzers, der dem RSE-Dämon zugeordnet ist), weil alle Clients als Threads in den RSE-Prozessen ausgeführt werden.
• Dieser Wert kann auch mit der Variablen PROCUSERMAX im OMVS-Sicherheitsprofilsegment des Benutzers festgelegt werden, der der gestarteten RSED-Task zugeordnet ist.

MAXTHREADS(nnnnnn)

Gibt die maximale Anzahl von pthread_created-Threads (einschließlich aktiver Threads, Threads in der Warteschlange und beendeter, aber nicht freigegebener Threads) an, die für einen einzelnen Prozess gleichzeitig aktiv sein können. Wenn Sie den Wert '0' angeben, können Anwendungen 'pthread_create' nicht verwenden.

Wertebereich: 'nnnnnn' ist ein Dezimalwert zwischen 0 und 100.000.
Standardwert: 200

Anmerkung:

• Jeder Client verwendet mindestens 17 Threads im RSE-Thread-Pool-Prozess. Im Prozess sind mehrere Clients aktiv.
• Dieser Wert kann auch mit der Variablen THREADSMAX im OMVS-Sicherheitsprofilsegment des Benutzers festgelegt werden, der der gestarteten RSED-Task zugeordnet ist. Sofern er festgelegt ist, wird der Wert von THREADSMAX für MAXTHREADS und MAXTHREADTASKS verwendet.

MAXTHREADTASKS(nnnnn)

Gibt die maximale Anzahl der MVS-Tasks an, die für einen einzelnen Prozess für pthread_created-Threads gleichzeitig aktiv sein können.

Wertebereich: 'nnnnn' ist ein Dezimalwert zwischen 0 und 32768.
Standardwert: 1000

Anmerkung:

• Für jeden aktiven Thread gibt es eine MVS-Task (TCB, Task Control Block).
• Für jede gleichzeitig ablaufende MVS-Task ist zusätzlicher Speicher erforderlich. Ein Teil davon muss unter der 16-MB-Grenze liegen.
• Jeder Client verwendet mindestens 17 Threads im RSE-Thread-Pool-Prozess. Im Prozess sind mehrere Clients aktiv.
• Dieser Wert kann auch mit der Variablen THREADSMAX im OMVS-Sicherheitsprofilsegment des Benutzers festgelegt werden, der der gestarteten RSED-Task zugeordnet ist. Sofern er festgelegt ist, wird der Wert von THREADSMAX für MAXTHREADS und MAXTHREADTASKS verwendet.

MAXUIDS(nnnnn)

Gibt die maximale Anzahl von z/OS UNIX-Benutzer-IDs (UIDs) an, die gleichzeitig arbeiten können.

Wertebereich: 'nnnnn' ist ein Dezimalwert zwischen 1 und 32767.
Standardwert: 200

MAXASSIZE(nnnnn)

Gibt die Ressourcenwerte für RLIMIT_AS an, die als Anfangswerte für neue Prozesse festgelegt werden. RLIMIT_AS gibt die Regionsgröße des Adressraums an.

Wertebereich: 'nnnnn' ist ein Dezimalwert zwischen 10.485.760 (10 Megabyte)
                     und 2.147.483.647 (2 Gigabyte).
Standardwert: 209.715.200 (200 Megabyte)

Anmerkung:

• Dieser Wert sollte auf 2 GB gesetzt werden.
• Dieser Wert kann auch mit der Variablen ASSIZEMAX im OMVS-Sicherheitsprofilsegment des Benutzers festgelegt werden, der der gestarteten RSED-Task zugeordnet ist.

MAXFILEPROC(nnnnnn)

Gibt die maximale Anzahl der Deskriptoren für Dateien, Sockets, Verzeichnisse und andere Dateisystemobjekte an, die für einen einzelnen Prozess gleichzeitig aktiv oder zugeordnet sein können.

Wertebereich: 'nnnnnn' ist ein Dezimalwert zwischen 3 und 524.287.
Standardwert: 64000

Anmerkung:

• In einem Thread-Pool befinden sich alle zugehörigen Client-Threads in einem einzigen Prozess.
• Dieser Wert kann auch mit der Variablen FILEPROCMAX im OMVS-Sicherheitsprofilsegment des Benutzers festgelegt werden, der der gestarteten RSED-Task zugeordnet ist.

MAXMMAPAREA(nnnnn)

Gibt den Maximalwert für den Speicherbereich (in Seiten) im Datenraum an, der für Speicherzuordnungen von z/OS UNIX-Dateien zugewiesen werden kann. Der Speicher wird erst zugewiesen, wenn die Speicherzuordnung aktiv ist.

Wertebereich: 'nnnnn' ist ein Dezimalwert zwischen 1 und 16.777.216.
Standardwert: 40960

Anmerkung: Dieser Wert kann auch mit der Variablen MMAPAREAMAX im OMVS-Sicherheitsprofilsegment des Benutzers festgelegt werden, der der gestarteten RSED-Task zugeordnet ist.

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.

MAXSOCKETS(nnnnnnnn)

Gibt die maximale Anzahl von Sockets an, die von diesem Dateisystem für diese Adressfamilie unterstützt werden. Dieser Parameter ist optional.

Wertebereich: 'nnnnnnnn' ist ein Dezimalwert zwischen 0 und 16.777.215.
Standardwert: 100

INADDRANYCOUNT(nnnn)

INADDRANYCOUNT: Gibt die Anzahl der vom System reservierten Ports für die Bindung an PORT 0 mit INADDR_ANY an, einschließlich des mit dem Parameter INADDRANYPORT angegebenen Ports. Dieser Wert wird nur für CINET (mehrere TCP/IP-Stacks) benötigt.

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.

REGION=0M

REGION=0M wird für die gestarteten Tasks des RSE-Dämons und von JES Job Monitor (RSED bzw. JMON) empfohlen. Aufgrund dieser Angabe ist die Größe des Adressraums nur durch den verfügbaren privaten Speicher oder durch die Systemexits IEFUSI oder IEALIMIT begrenzt. Beachten Sie, dass IBM dringend empfiehlt, diese Exits nicht für z/OS UNIX-Adressräume zu verwenden, wie den RSE-Dämon.

TIME=NOLIMIT

TIME=NOLIMIT wird zur Verwendung mit allen Servern für Developer for System z empfohlen. Der Grund ist, dass die CPU-Zeiten aller Clients für Developer for System z in den Serveradressräumen zusammengefasst 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:

MAX_THREADS

Dies ist die maximale Anzahl Benutzer, die JES Job Monitor gleichzeitig benutzen können. Die Standardeinstellung ist 200. Der Maximalwert ist 2147483647. Wenn Sie diese Anzahl erhöhen, müssen Sie unter Umständen auch den Adressraum von JES Job Monitor vergrößern.

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:

MAXUSER=nnnnn

Dieser Parameter gibt einen Wert an, den das System in den meisten Fällen verwendet, um die Anzahl der Jobs und gestarteten Tasks zu begrenzen, die während eines bestimmten einleitenden Programmladens gleichzeitig ausgeführt werden können.

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:

FIXED MAX(maxfix)

Definiert den maximalen Speicherbereich, der festgelegten CSM-Puffern zugeordnet wird.

Wertebereich: 'maxfix' ist ein Wert zwischen 1024K und 2048M.
Standardwert: 100M

ECSA MAX(maxecsa)

Definiert den maximalen Speicherbereich, der ECSA-CSM-Puffern zugeordnet wird.

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:

MAX(nnnnn)

Ein optionaler Parameter der CLASSADD-Definition, der die maximale Anzahl von APPC-Transaktionsinitiatoren angibt, die für eine bestimmte Klasse von Transaktionsinitiatoren zulässig sind. Nachdem dieser Grenzwert erreicht wurde, werden keine neuen Adressräume erstellt. Eingehende Anforderungen werden in die Warteschlange gestellt und warten darauf, dass vorhandene Initiatoradressräume verfügbar werden. Der Wert sollte die maximal zulässige Anzahl von Adressräumen für Ihre Installation nicht überschreiten. Sie sollten auch an konkurrierende Produkte auf dem System denken, die ebenfalls Adressräume benötigen.

Wertebereich: 'nnnnn' ist ein Dezimalwert zwischen 1 und 64000.
Standardwert: 1

Anmerkung: Wenn Sie TSO Commands Service über APPC starten, muss die verwendete Transaktionsklasse genug Transaktionsinitiatoren haben, damit für jeden gleichzeitig angemeldeten Benutzer von Developer for System z ein Initiator verfügbar ist.

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

• Mit der Anweisung LIMMSG(ALL) in SYS1.PARMLIB(BPXPRMxx) zeigt z/OS UNIX Konsolennachrichten (BPXI040I) an, wenn ein beliebiger PARMLIB-Grenzwert annähernd überschritten wird. Der Standardwert für LIMMSG ist NONE. Damit wird die Funktion inaktiviert. Verwenden Sie den Bedienerbefehl SETOMVS LIMMSG=ALL, um diese Funktion dynamisch (bis zum nächsten einleitenden Programmladen) zu aktivieren. Weitere Informationen zu dieser Anweisung enthält die Veröffentlichung MVS Initialization and Tuning Reference (IBM Form SA22-7592).
• Mit dem Bedienerbefehl DISPLAY OMVS,OPTIONS werden die aktuellen Werte von z/OS UNIX-Anweisungen angezeigt, die dynamisch festgelegt werden können.

  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

• Mit dem Bedienerbefehl DISPLAY OMVS,LIMITS werden Informationen zu aktuellen z/OS UNIX System Services-PARMLIB-Begrenzungen, ihren oberen Grenzen und zur aktuellen Systembelegung angezeigt.

  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

• Mit dem Bedienerbefehl DISPLAY OMVS,PFS werden Informationen zu jedem physischen Dateisystem angezeigt, das derzeit Teil der z/OS UNIX-Konfiguration ist. Dies schließt die TCP/IP-Stacks ein.

  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)

• Mit dem Bedienerbefehl DISPLAY OMVS,PID=processid werden die Threadinformationen zu einem bestimmten Prozess angezeigt.

  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.

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

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

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.

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.

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.

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.

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.

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.

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.

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.

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

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