Dieses Handbuch wendet sich an Systemprogrammierer, die IBM Rational Developer for z Systems Version 9.5.1 konfigurieren und optimieren.

Während die eigentlichen Konfigurationsschritte in einer anderen Veröffentlichung beschrieben werden, werden in dieser Veröffentlichung verschiedene zugehörige Themen (wie Optimierung, Sicherheitskonfiguration usw.) ausführlich aufgelistet. Voraussetzung für die Verwendung dieses Handbuchs ist, dass Sie mit z/OS UNIX System Services und MVS-Hostsystemen vertraut sind.

In diesem Abschnitt werden die Änderungen für IBM Rational Developer for z Systems Version 9.5.1 Hostkonfigurationsreferenz, SC43-2898-00 (Aktualisierung vom Dezember 2015) zusammengefasst.

Technische Änderungen oder Zusätze zum Text und den Abbildungen sind durch eine vertikale Linie auf der linken Seite der Änderung angegeben.

Neue Informationen:

• Verwwenden Sie die neuen MVS-Datensatznamen und z/OS UNIX-Pfade

Entfernte Informationen:

In Version 9.5.1 wurden die zu RSE und JES Job Monitor gehörigen Funktionen von IBM Rational Developer for z Systems in ein anderes Produkt (IBM Explorer for z/OS) verschoben. Dies gilt auch für die zugehörige Dokumentation.

• Daten, die sich auf RSE beziehen, werden aus allen Kapiteln entfernt.
• Daten, die sich auf JES Job Monitor beziehen, werden aus allen Kapiteln entfernt.
• Daten, die sich auf den TSO-Befehlsservice beziehen, werden aus allen Kapiteln entfernt.
• Push-to-client-Daten für das Konfigurations- und Versionsmanagement wurden aus allen Kapiteln entfernt
• Dokumentation zur Einrichtung von TCP/IP wurde entfernt

Dieses Dokument enthält Informationen, die bisher im Handbuch IBM Rational Developer for z Systems Version 9.5 Hostkonfigurationsreferenz (IBM Form SC12-4489-09) enthalten waren.

Neue Informationen:

• Dokumentierte Sicherheitsprüfungen für die neue Funktion zum Senden von Nachrichten. Siehe Sicherheit beim Senden von Nachrichten
• Zusätzliche Details zu verwendeten JES-Bedienerbefehlen. Siehe Aktionen für Beschränkungen der Jobausführung
• Zusätzliche Informationen zu Begrenzungen für Push-to-Client-Gruppennamen. Siehe Einschränkungen für Gruppennamen
• Zusätzliche Informationen zu SYSPLEX-Einschränkungen. Siehe SYSPLEX
• Zusätzliche Informationen für das Verwalten von Verschlüsselungsprotokollen und Verschlüsselungen. Siehe Verschlüsselungsprotokolle und Verschlüsselungswerte verwalten
• Zusätzliche Anweisungen für eine einfache Konfiguration mit mehreren Servern. Siehe Identischer Software-Level, verschiedene Konfigurationsdateien

Entfernte Informationen:

• Application Deployment Manager wird nicht mehr bereitgestellt. Daher wurden sämtliche zugehörigen Informationen entfernt.

Dieses Dokument enthält Informationen, die bisher im Handbuch IBM Rational Developer for System z Version 9.1.1 Hostkonfigurationsreferenz (IBM Form SC12-4489-08) enthalten waren.

Dieses Dokument enthält Informationen, die bisher im Handbuch IBM Rational Developer for System z Version 9.1.1 Hostkonfigurationsreferenz (IBM Form SC12-4489) enthalten waren.

Dieses Dokument enthält Informationen, die bisher im Handbuch IBM Rational Developer for System z Version 9.0.1 Hostkonfigurationsreferenz (IBM Form SC12-4489-06) enthalten waren.

Dieses Dokument enthält Informationen, die bisher im Handbuch IBM Rational Developer for System z Version 9.0.1 Hostkonfigurationsreferenz (IBM Form SC12-4489-05) enthalten waren.

Neue Informationen:

Dieses Dokument enthält Informationen, die bisher im Handbuch IBM Rational Developer for System z Version 8.5.1 Hostkonfigurationsreferenz (IBM Form SC12-4489-03) enthalten waren.

Dieses Dokument enthält Informationen, die bisher im Handbuch IBM Rational Developer for System z Version 8.5 Hostkonfigurationsreferenz (IBM Form SC12-4489-02) enthalten waren.

In diesem Abschnitt werden die in diesem Dokument enthaltenen Informationen zusammengefasst.

Abbildung 1. Komponentenübersicht

Abbildung 1 zeigt eine allgemeine Übersicht des kombinierten Layouts von z/OS Explorer und Developer for z Systems auf Ihrem Hostsystem.

• Remote Systems Explorer (RSE) stellt Kernservices wie den Verbindungsaufbau vom Client zum Host und das Starten anderer Server für bestimmte Services bereit. RSE umfasst zwei logische Einheiten:
  • RSE-Dämon (RSED), der den Verbindungsaufbau verwaltet. Der RSE-Dämon ist auch für die Ausführung im Einzelservermodus verantwortlich. Um dies zu erreichen, erstellt der RSE-Dämon mindestens einen untergeordneten Prozess, auch als RSE-Thread-Pool(s) (RSEDx) bekannt.
  • RSE-Server für die einzelnen Clientanforderungen. Ein RSE-Server ist innerhalb eines RSE-Thread-Pools als Thread aktiv.
• Debug Manager (DBGMGR) koordiniert Integrated Debugger-Aktivitäten.
• (z/OS Explorer) TSO Commands Service (TSO cmd) stellt eine batchähnliche Schnittstelle für TSO- und ISPF-Befehle bereit.
• (z/OS Explorer) JMON (JES Job Monitor) stellt alle Services mit Bezug zum JES bereit.
• Common Access Repository Manager (CARMA) bietet eine Schnittstelle für die Interaktion mit Software Configuration Managers (SCMs), beispielsweise CA Endevor.
• Es sind weitere Services verfügbar. Diese können von Developer for z Systems selbst oder von zusätzlich erforderlicher Software bereitgestellt werden.

Die Beschreibung im vorherigen Abschnitt und in der Liste verdeutlichen die zentrale Rolle von RSE. Mit ein paar wenigen Ausnahmen läuft jede Clientkommunikation über RSE ab. Dies ermöglicht eine sicherheitsbezogene Netzkonfiguration, da nur eine eingeschränkte Menge an Ports für die Kommunikation zwischen Client und Host verwendet wird.

RSE besteht aus einem Dämonadressbereich, der Thread-Pooling und Adressräume steuert, um die Verbindungen und die Arbeitslast der Clients zu verwalten. Der Dämon wird als Sammelpunkt für Verbindungs- und Verwaltungszwecke eingesetzt, während die Thread-Pools die Clientarbeitslast verarbeiten. Auf Basis der in der Konfigurationsdatei rse.env definierten Werte und der Summe aller Clientverbindungen können mehrere Adressräume von Thread-Pools durch den Dämon gestartet werden.

Abbildung 2. Taskeigner

Abbildung 2 zeigt eine Basisübersicht über die Eigner der Sicherheitsberechtigungsnachweise, die für verschiedene Tasks in z/OS Explorer und Developer for z Systems verwendet werden.

Das Eigentumsrecht an einer Task kann in zwei Abschnitte unterteilt werden. Gestartete Tasks gehören der Benutzer-ID, die der gestarteten Task in Ihrer Sicherheitssoftware zugewiesen wird. Alle anderen Tasks, mit Ausnahme der RSE-Thread-Pools (RSEDx), gehören der Client-Benutzer-ID.

Abbildung 2 zeigt die gestarteten Tasks in z/OS Explorer und Developer for z Systems (DBGMGR, JMON und RSED) sowie gestartete Beispieltasks und Beispielsystemservices, mit denen Developer for z Systems kommuniziert. Der USS REXEC-Tag stellt den z/OS UNIX-REXEC-Service (oder SSH-Service) dar.

Der RSE-Dämon erstellt für die Verarbeitung von Prozessclientanforderungen mindestens einen Adressraum der RSE-Thread-Pools (RSEDx). Jeder RSE-Thread-Pool unterstützt mehrere Clients und gehört demselben Benutzer wie der RSE-Dämon. Jeder Client verfügt über eigene Threads innerhalb eines Thread-Pools. Diese Threads gehören der Client-Benutzer-ID.

Abhängig von den vom Client ausgeführten Aktionen können für die Ausführung der angeforderten Aktion zusätzliche Adressräume gestartet werden. Diese gehören alle der Client-Benutzer-ID. Diese Adressräume können ein MVS-Batch-Job, eine APPC-Transaktion oder ein untergeordneter z/OS UNIX-Prozess sein. Beachten Sie, dass ein untergeordneter z/OS UNIX-Prozess in einem z/OS UNIX-Initiator (BPXAS) aktiv ist und als gestartete Task in JES angezeigt wird.

Die Erstellung dieser Adressräume wird in den meisten Fällen von einem Benutzerthread in einem Thread-Pool entweder direkt oder mithilfe von Systemservices wie ISPF ausgelöst. Der Adressraum kann aber auch von einem Fremdanbieter erstellt werden. Der z/OS UNIX-REXEC-Service oder der SSH-Service sind beim Starten von Builds in z/OS UNIX beteiligt.

Die benutzerspezifischen Adressräume werden bei Abschluss der Tasks oder bei Ablauf eines Inaktivitätszeitgebers beendet. Die gestarteten Tasks bleiben aktiv. Die in Abbildung 2 aufgeführten Adressräume bleiben für einen längeren Zeitraum im System sichtbar. Sie sollten allerdings beachten, dass z/OS UNIX so entwickelt wurde, dass es auch einige kurz andauernde, temporäre Adressräume gibt.

Abbildung 5. z/OS UNIX-Verzeichnisstruktur

Abbildung 5 liefert einen Überblick über die von Developer for z Systems verwendeten z/OS UNIX-Verzeichnisse. Die folgende Liste enthält nicht nur Informationen zu jedem von Developer for z Systems verwendeten Verzeichnis, sondern gibt auch an, wie die Position geändert werden kann und wer die darin enthaltenen Daten verwaltet.

• /usr/lpp/ibm/rdz/ ist der Stammverzeichnispfad für den Produktcode von Developer for z Systems. Die eigentliche Position ist in der Konfigurationsdatei rdz.env angegeben (Variable RDZ_HOME). Die enthaltenen Dateien werden von SMP/E verwaltet.
• Developer for z Systems stellt Dateien in /usr/lpp/ibm/zexpl/bin - dem Verzeichnis für Binärdateien von z/OS Explorer. Die eigentliche Position ist in der z/OS Explorer-Konfiguration angegeben. Die enthaltenen Dateien werden von SMP/E verwaltet.
• /etc/zexpl/ beinhaltet die Konfigurationsdateien von z/OS Explorer und Developer for z Systems. Die eigentliche Position ist in der gestarteten Task RSED angegeben (Variable CNFG). Die enthaltenen Dateien werden vom Systemprogrammierer verwaltet.
• /tmp/ wird vom Legacy ISPF Gateway zum Speichern von temporären Daten verwendet. Einige IVPs speichern ihre Ausgabe hier. Die enthaltenen Dateien werden von ISPF und IVPs verwaltet. Die eigentliche Position kann mit der Variablen TMPDIR in der Datei rse.env angepasst werden. Das Verzeichnis ist außerdem die Standardposition für Java™-Speicherauszugsdateien, die mit der Variable _CEE_DUMPTARG in rse.env angepasst werden kann.
  Anmerkung: /tmp/ erfordert die Berechtigungsbitmaske 777, um jedem Client das Erstellen von temporären Daten zu ermöglichen.
• /var/zexpl/WORKAREA/ wird vom Legacy ISPF Gateway und SCLMDT verwendet, um Daten zwischen z/OS UNIX und MVS-basierten Adressräumen zu übertragen. Die eigentliche Position ist in rse.env angegeben (Variable CGI_ISPWORK). Die enthaltenen Dateien werden von ISPF und SCLMDT verwaltet.
  Anmerkung: /var/zexpl/WORKAREA/ erfordert die Berechtigungsbitmaske 777, um jedem Client das Erstellen von temporären Daten zu ermöglichen.
  Developer for z Systems schreibt Protokollnachrichten in die Protokolldateien von z/OS Explorer, die sich in /var/zexpl/zexpl/logs/$LOGNAME befinden. Die eigentliche Position ist in der z/OS Explorer-Konfiguration angegeben. Die darin enthaltenen Dateien werden vom Produktcode von z/OS Explorer und Developer for z Systems verwaltet.
• /var/rdz/sclmdt/CONFIG/ sperrt allgemeine SCLMDT-Konfigurationsdateien. Die eigentliche Position ist in rdz.env angegeben (Variable SCLMDT_CONF_HOME). Die enthaltenen Dateien werden vom SCLM-Administrator verwaltet.
• /var/rdz/sclmdt/CONFIG/PROJECT/ sperrt SCLMDT-Projektkonfigurationsdateien. Die eigentliche Position ist in rdz.env angegeben (Variable SCLMDT_CONF_HOME). Die enthaltenen Dateien werden vom SCLM-Administrator verwaltet.
• /var/rdz/sclmdt/CONFIG/script/ sperrt SCLMDT-bezogene Scripts, die von anderen Produkten verwendet werden können. Die eigentliche Position ist nirgendwo angegeben. Die enthaltenen Dateien werden vom SCLM-Administrator verwaltet.
• /var/rdz/pushtoclient/ enthält Clientkonfigurationsdateien, Update-Informationen zum Clientprodukt und hostbasierte Projektinformationen, die bei der Verbindung mit dem Host mittels Push auf den Client übertragen werden. Die eigentliche Position ist in pushtoclient.properties angegeben (Variable pushtoclient.folder). Die darin enthaltenen Dateien werden von einem Clientadministrator von Developer for z Systems verwaltet.
• /var/rdz/pushtoclient/projects/ enthält die hostbasierten Projektdefinitionsdateien. Die tatsächliche Position wird in der Datei /var/rdz/pushtoclient/keymapping.xml angegeben, die von einem Administrator der Developer for z Systems-Clients erstellt und verwaltet wird. Die enthaltenen Dateien werden von einem Projektleiter oder einem leitenden Entwickler verwaltet.

CARMA-Authentifizierung

Die Clientauthentifizierung wird vom RSE-Dämon als Teil der Verbindungsanforderung des Clients vorgenommen. CARMA wird von einem benutzerspezischen aus gestartet und übernimmt die Sicherheitsumgebung des Benutzers, wodurch die Notwendigkeit einer zusätzlichen Authentifizierung umgangen wird.

SCLM Developer Toolkit-Authentifizierung

Die Clientauthentifizierung wird vom RSE-Dämon als Teil der Verbindungsanforderung des Clients vorgenommen. SCLMDT wird von einem benutzerspezischen aus gestartet und übernimmt die Sicherheitsumgebung des Benutzers, wodurch die Notwendigkeit einer zusätzlichen Authentifizierung umgangen wird.

Die Hostkommunikation zwischen dem Developer for z Systems-Client und dem Host geht über RSE: daduch wird die Verbindungssicherheit verwendet, die in z/OS Explorer bereitgestellt wird.

Einige Developer for z Systems-Services verwenden einen separaten, externen Kommunikationspfad (Client-Host):

• Die Integrated Debugger-Engine des Clients wird mit dem Debug Manager des Hosts verbunden. Die Verschlüsselungsdetails werden von einer AT-TLS-Richtlinie (Application Transparent Transport Layer Security) gesteuert.
• Ferne (hostbasierte) Aktionen in z/OS UNIX-Unterprojekten verwenden einen REXEC- oder SSH-Server auf dem Host. Die SSH-Kommunikation ist stets verschlüsselt.

Für die optionale Komponente Integrated Debugger ist es erforderlich, dass Benutzer über ausreichende Zugriffsberechtigungen für angegebene Sicherheitsprofile verfügen. Wenn der Benutzer nicht über die erforderliche Berechtigung verfügt, wird die Debugsitzung nicht gestartet.

Developer for z Systems überprüft den Zugriff auf die Profile, die in Tabelle 1 aufgeführt sind, um festzustellen, welche Debugberechtigungen erteilt wurden.

RDEFINE FACILITY (AQE.AUTHDEBUG.STDPGM) -
  UACC(NONE) DATA('RATIONAL DEVELOPER FOR Z SYSTEMS – DEBUG PROBLEM-STATE')
PERMIT AQE.AUTHDEBUG.STDPGM CLASS(FACILITY) -
  ID(RDZDEBUG) ACCESS(READ)
SETROPTS RACLIST(FACILITY) REFRESH

Mit dem optionalen Integrated Debugger kann ein Debugging von CICS-Transaktionen durchgeführt werden. Ausführliche Informationen hierzu enthält der Abschnitt CICS-Transaktionsdebugging.

SCLM Developer Toolkit stellt optionale Sicherheitsfunktionen für die Builderstellung, die Umstufung und das Deployment bereit.

Wenn ein SCLM-Administrator die Sicherheit für eine Funktion aktiviert hat, wird SAF aufgerufen, um zu überprüfen, ob die geschützte Funktion mit der ID des Aufrufenden oder einer Ersatzbenutzer-ID ausgeführt werden darf.

Weitere Informationen zu den erforderlichen SCLM-Sicherheitsdefinitionen enthält der SCLM Developer Toolkit Administrator’s Guide (IBM Form SC23-9801).

Passen Sie den Beispieljob FELRACF an, der RACF-Beispielbefehle enthält, und übergeben Sie ihn, um die Basissicherheitsdefinitionen für Developer for z Systems zu erstellen. Passen Sie den Beispieljob AQERACF an, der RACF-Beispielbefehle enthält, und übergeben Sie ihn, um die Sicherheitsdefinitionen für Integrated Debugger zu erstellen.

FELRACF und AQERACF befinden sich in FEL.#CUST.JCL, sofern sie bei der Anpassung und Übergabe des Jobs FEL.SFELSAMP(FELSETUP) keine andere Position angegeben haben. Weitere Informationen finden Sie im Abschnitt "Anpassungskonfiguration" im Handbuch Rational Developer for z Systems Hostkonfiguration.

Weitere Informationen zu RACF-Befehlen finden Sie in der Veröffentlichung RACF Command Language Reference (IBM Form SA22–7687).

Abbildung 7. TCP/IP-Ports

Abbildung 7 stellt die TCP/IP-Ports dar, die mit z/OS Explorer und Developer for z Systems verwendet werden können. Die Pfeilspitzen deuten an, welcher Teilnehmer für die Bindung (Pfeilspitzenseite) verantwortlich ist und welcher die Verbindung herstellt.

Abbildung 8. WLM-Klassifikation

Abbildung 8 zeigt eine Basisübersicht über die Subsysteme, über die die Informationen zu den Verarbeitungsprozessen von z/OS Explorer und Developer for z Systems an WLM weitergegeben werden.

Der RSE-Dämon (RSED), Debug Manager (DBGMGR) und JES Job Monitor (JMON) sind gestartete Tasks in z/OS Explorer and Developer for z Systems (oder lang laufende Batch-Jobs) mit individuellen Adressräumen.

Der RSE-Dämon startet für jeden RSE-Thread-Pool-Server (der eine variable Anzahl von Clients unterstützt) einen untergeordneten Prozess. Jeder Thread-Pool ist (mithilfe eines z/OS UNIX-Initiators, BPXAS) in einem separaten Adressraum aktiv. Da es sich hierbei um gestartete Prozesse handelt, werden diese nach den WLM-OMVS-Klassifikationsregeln und nicht nach den Klassifikationsregeln für gestartete Tasks klassifiziert.

Abhängig von den Aktionen der Benutzer können die Clients, die in einem Thread-Pool aktiv sind, eine Vielzahl anderer Adressräume erstellen. Abhängig von der Konfiguration von Developer for z Systems, können einige Verarbeitungsprozesse, wie TSO Commands Service (TSO cmd) oder CARMA, in anderen Subsystemen ausgeführt werden.

Die in Abbildung 8 aufgeführten Adressräume bleiben für einen längeren Zeitraum im System sichtbar. Sie sollten allerdings beachten, dass z/OS UNIX so entwickelt wurde, dass es auch einige kurz andauernde, temporäre Adressräume gibt. Diese temporären Adressräume sind im OMVS-Subsystem aktiv.

Während die RSE-Thread-Pools dieselbe Benutzer-ID und einen ähnlichen Jobnamen wie der RSE-Dämon verwenden, gehören alle von einem Thread-Pool gestarteten Adressräume der Client-Benutzer-ID, die die Aktion anfordert. Die Client-Benutzer-ID wird außerdem als Teil des Jobnamens für alle vom Thread-Pool gestarteten OMVS-basierten Adressräume verwendet.

Weitere Adressräume werden von anderen Services erstellt, die Developer for z Systems verwendet, zum Beispiel z/OS UNIX-REXEC (USS-Build).

Wie unter Klassifikation für Verarbeitungsprozesse dokumentiert, erstellt Developer for z Systems unterschiedliche Typen von Verarbeitungsprozessen auf Ihrem System. Diese verschiedenen Tasks kommunizieren miteinander. Dafür ist die eigentliche Antwortzeit wichtig, um Zeitüberschreitungsprobleme bezüglich der Verbindungen zwischen den Tasks zu vermeiden. Deshalb sollten Tasks in Developer for z Systems in leistungsfähige Serviceklassen oder in Serviceklassen mit mittlerer Leistung mit hoher Priorität eingeordnet werden.

Es wird daher eine Überarbeitung und gegebenenfalls eine Aktualisierung Ihrer aktuellen WLM-Ziele empfohlen. Dies gilt insbesondere für herkömmliche MVS-Unternehmen, für die zeitkritische OMVS-Verarbeitungsprozesse neu sind.

In Tabelle 7 werden die Adressräume aufgelistet, die von z/OS Explorer und Developer for z Systems. verwendet werden. z/OS UNIX ersetzt den Wert "x" in der Spalte "Taskname" durch eine zufällige einstellige Zahl.

Tabelle 7. WLM-Verarbeitungsprozesse

Beschreibung	Taskname	Verarbeitungsprozess
Debug Manager	DBGMGR	STC
(z/OS Explorer) JES Job Monitor	JMON	STC
(z/OS Explorer) RSE-Dämon	RSED	STC
(z/OS Explorer) RSE-Thread-Pool	RSEDx	OMVS
(ISPF) Interactive ISPF Gateway (TSO-Befehlsservice)	<Benutzer-ID>	JES
(ISPF) Legacy ISPF Gateway (TSO-Befehlsservice und SCLMDT)	<Benutzer-ID>x	OMVS
(z/OS Explorer) TSO Commands Service (APPC)	FEKFRSRV	ASCH
CARMA (batch)	CRA<Port>	JES
CARMA (crastart)	<Benutzer-ID>x	OMVS
CARMA (ISPF-Client-Gateway)	<Benutzer-ID> und <Benutzer-ID>x	OMVS
MVS-Build (Batch-Job)	*	JES
z/OS UNIX-Build (Shellbefehle)	<Benutzer-ID>x	OMVS
z/OS UNIX-Shell	<Benutzer-ID>	OMVS

Clients von Developer for z Systems können beim Verbindungsaufbau Clientkonfigurationsdateien und Informationen zu Produktaktualisierungen vom Host abrufen. Dadurch wird sichergestellt, dass alle Clients über die gleichen Einstellungen verfügen und auf dem neuesten Stand sind.

Der Clientadministrator kann mehrere Clientkonfigurationssätze und Clientaktualisierungsszenarios für die Anforderungen verschiedener Entwicklergruppen erstellen. Dadurch erhalten Benutzer eine angepasste Konfiguration, die auf Kriterien wie LDAP-Gruppenzugehörigkeit oder Zulassung zu einem Sicherheitsprofil basiert.

z/OS-Projekte können einzeln auf dem Client in der Perspektive für z/OS-Projekte erstellt werden. Sie können aber auch zentral auf dem Host erstellt werden, in welchem Fall sie auf Benutzerbasis auf den Client repliziert werden. Solche hostbasierten Projekte sind hinsichtlich Aussehen und Funktionsweise mit auf dem Client definierten Projekten identisch. Die Struktur, die Member und die Eigenschaften dieser Projekte können jedoch nicht vom Client geändert werden und sind nur bei bestehender Verbindung mit dem Host verfügbar.

Manager für Entwicklungsprojekte definieren ein Projekt und weisen ihm Entwickler zu.

Details zur Durchführung der zugewiesenen Aufgaben durch den Manager für Entwicklungsprojekte finden Sie im Developer for z Systems IBM Knowledge Center.

z/OS-Projekte können einzeln auf dem Client in der Perspektive für z/OS-Projekte erstellt werden. Sie können aber auch zentral auf dem Host erstellt werden, in welchem Fall sie auf Benutzerbasis auf den Client repliziert werden. Solche hostbasierten Projekte sind hinsichtlich Aussehen und Funktionsweise mit auf dem Client definierten Projekten identisch. Die Struktur, die Member und die Eigenschaften dieser Projekte können jedoch nicht vom Client geändert werden und sind nur bei bestehender Verbindung mit dem Host verfügbar.

Das Basisverzeichnis für hostbasierte Projekte wird vom Clientadministrator in /var/rdz/pushtoclient/keymapping.xml definiert. Standardmäßig lautet es /var/rdz/pushtoclient/projects.

Hostbasierte Projekte können auch in die Konfiguration für mehrere Gruppen integriert werden. Dies bedeutet, dass hostbasierte Projekte auch in /var/rdz/pushtoclient/grouping/<devgroup>/projects/ definiert werden können.

Wenn ein Arbeitsbereich an eine bestimmte Gruppe gebunden ist und für einen Benutzer dieser Gruppe und in der Standardgruppe Projektdefinitionen vorliegen, erhält der Benutzer die Projektdefinitionen sowohl aus der Standardgruppe als auch aus der spezifischen Gruppe.

Weitere Informationen zur Unterstützung bidirektionaler Sprachen finden Sie im Abschnitt "Unterstützung bidirektionaler Sprachen für CICS" im Kapitel "Weitere Anpassungstasks" des Handbuchs Rational Developer for z Systems Hostkonfiguration (SC43-2896).

Weitere Informationen zu IRZ-Diagnosenachrichten für Enterprise Service Tools finden Sie im Abschnitt "IRZ-Diagnosenachrichten für Enterprise Service Tools" im Kapitel "Weitere Anpassungstasks" im Handbuch Rational Developer for z Systems Hostkonfiguration (SC43-2896).

Weitere Informationen zum CICS-Transaktionsdebugging finden Sie im Abschnitt "CICS-Aktualisierungen für Integrated Debugger" im Kapitel "Integrated Debugger (optional)" des Handbuchs IBM Rational Developer for z Systems Hostkonfiguration (SC12-4062).

In der TCP/IP-Dokumentation wird empfohlen, Policy Agent-Nachrichten in syslog unter z/OS UNIX zu schreiben, nicht in die Standardprotokolldatei. AT-TLS schreibt Nachrichten stets in syslog unter z/OS UNIX.

Für diesen Zweck muss der Dämon von syslog unter z/OS UNIX, syslogd, konfiguriert und aktiv sein. Außerdem benötigen Sie einen Mechanismus zum Steuern der Größe der Protokolldateien, die durch syslogd erstellt werden.

Die AT-TLS-Unterstützung wird über den Parameter TTLS in der Anweisung TCPCONFIG in der Datei PROFILE.TCPIP aktiviert. AT-TLS wird von Policy Agent verwaltet. Policy Agent muss aktiv sein, damit die AT-TLS-Richtlinie erzwungen werden kann. Da Policy Agent warten muss, bis TCP/IP aktiv ist, ist die Anweisung AUTOSTART in PROFILE.TCPIP eine gute Position zum Auslösen des Starts dieses Servers.

TCPCONFIG TTLS         ; Required for AT-TLS
AUTOLOG
  PAGENT               ; POLICY AGENT, required for AT-TLS
ENDAUTOLOG

#
# TCP/IP Policy Agent configuration information.
#
TTLSConfig /etc/pagent.ttls.conf
# Specifies the path of a TTLS policy file holding stack specific
# statements.
#
#TcpImage TCPIP /etc/pagent.conf
# If no TcpImage statement is specified, all policies will be installed
# to the default TCP/IP stack.
#
#LogLevel 31
# The sum of the following values that represent log levels:
#  LOGL_SYSERR     1
#  LOGL_OBJERR     2
#  LOGL_PROTERR    4
#  LOGL_WARNING    8
#  LOGL_EVENT     16
#  LOGL_ACTION    32
#  LOGL_INFO      64
#  LOGL_ACNTING  128
#  LOGL_TRACE    256
# Log Level 31 is the default log loglevel.
#
#Codepage IBM-1047
# Specify the EBCDIC code page to be used for reading all configuration
# files and policy definition files. IBM-1047 is the default code page.

Diese Beispielkonfigurationsdatei gibt an, wo Policy Agent die TTLS-Richtlinie finden kann. Für andere Anweisungen werden Standardwerte von Policy Agent verwendet.

Mithilfe einer TTLS-Richtlinie werden die gewünschten AT-TLS-Regeln beschrieben. Entsprechend der Definition in der Policy Agent-Konfigurationsdatei befindet sich die TTLS-Richtlinie in der Datei /etc/pagent.ttls.conf. Die erforderlichen Definitionen in Ihrer Sicherheitssoftware werden später erläutert.

In diesem Beispiel wird eine recht einfache, aus zwei Regeln bestehende Richtlinie beschrieben, mit der Unterstützung für SSL v3 inaktiviert und die Unterstützung für TLS v1, TLS v1.1 und TLS v1.2 für beide von Developer for z Systems Integrated Debugger, Debug Manager und Probe-Client unterstützten Kommunikationspfade aktiviert wird. Entsprechend der Definition in der Policy Agent-Konfigurationsdatei befindet sich die TTLS-Richtlinie in der Datei /etc/pagent.ttls.conf.

##
## TCP/IP Policy Agent AT-TLS configuration information.
##
##-----------------------------
TTLSRule                      RDz_Debug_Manager
{
 LocalPortRange           5335
 Direction                Inbound
 TTLSGroupActionRef       grp_Production
 TTLSEnvironmentActionRef act_RDz_Debug_Manager
}
##-----------------------------
TTLSEnvironmentAction         act_RDz_Debug_Manager
{
 HandshakeRole Server
 TTLSKeyRingParms
 {
  Keyring dbgmgr.racf     # Keyring must be owned by the Debug Manager
 }
 TTLSEnvironmentAdvancedParms
 {
## TLSV1.2 only for z/OS 2.1 and higher
# TLSV1.2 On               # TLSv1 & TLSv1.1 are on by default
  SSLV3 Off                # disable SSLv3 }
}
##-----------------------------
TTLSRule                      RDz_Debug_Probe-Client
{
 RemotePortRange          8001
 Direction                Outbound
 TTLSGroupActionRef       grp_Production
 TTLSEnvironmentActionRef act_RDz_Debug_Probe-Client
}
##-----------------------------
TTLSEnvironmentAction         act_RDz_Debug_Probe-Client
{
 HandshakeRole            Client
 TTLSKeyRingParms
 {
  Keyring *AUTH*/*         # virtual key ring holding CA certificates
 }
 TTLSEnvironmentAdvancedParms
 {
## TLSV1.2 only for z/OS 2.1 and higher
# TLSV1.2 On               # TLSv1 & TLSv1.1 are on by default
 }
}
##-----------------------------
TTLSGroupAction               grp_Production
{
 TTLSEnabled              On
## TLSv1.2zOS1.13 only for z/OS 1.13
 TTLSGroupAdvancedParmsRef TLSv1.2zOS1.13
 Trace                     3     # Log Errors to syslogd & IP joblog
#Trace                            254  # Log everything to syslogd
}
##-----------------------------
TTLSGroupAdvancedParms        TLSv1.2zOS1.13
{
 Envfile /etc/pagent.ttls.TLS1.2zOS1.13.env
}

Eine TTLS-Richtlinie ermöglicht eine große Bandbreite an Filtern, um anzugeben, in welchen Fällen eine Regel zutrifft.

Debug Manager ist ein Server, der am Port 5335 für eingehende Verbindungen von der Debug-Engine empfangsbereit ist. Diese Informationen werden in der Regel RDz_Debug_Manager erfasst.

Da für die verschlüsselte Kommunikation die Nutzung eines Serverzertifikats erforderlich ist, müssen Sie angeben, dass Policy Manager die Zertifikate des Schlüsselrings dbgmgr.racf verwenden muss, dessen Eigner die Benutzer-ID für die gestartete Task von Debug Manager ist. Standardmäßig ist die Unterstützung für TLS V1.2 inaktiviert, also wird sie durch diese Richtlinie explizit aktiviert. SSLv3.0 ist aufgrund bekannter Sicherheitslücken in diesem Protokoll explizit inaktiviert.

Wenn der Debug-Testmonitor mit der Option TEST(,,,TCPIP&&ipaddress%8001:*) für die Language Environment (Language Environment - LE) gestartet wird, wird er angewiesen, den Debug Manager nicht zu verwenden, sondern den Developer for z Systems-Client am Port 8001 direkt zu kontaktieren. Aus einer TCP/IP-Perspektive bedeutet dies, dass der hostbasierte Debug-Testmonitor ein Client ist, der einen Server (die Debugbenutzerschnittstelle) im Developer for z Systems-Client kontaktiert. Diese Informationen werden in der Regel RDz_Debug_Probe-Client erfasst.

Da der Host ein TCP/IP-Client ist, benötigt der Richtlinienmanager eine Methode zum Validieren der von der Debugbenutzerschnittstelle bereitgestellten Serverzertifikate. In diesem Fall wird kein einheitlich benannter Schlüsselring für alle Benutzer verwendet, für die möglicherweise eine verschlüsselte Debugsitzung erforderlich wäre; stattdessen wird der virtuelle Schlüsselring (*AUTH*/*) der RACF-CERTAUTH verwendet. Dieser virtuelle Schlüsselring enthält die öffentlichen Zertifikate von Zertifizierungsstellen (Certificate Authorities - CAs) und kann verwendet werden, wenn die Debugbenutzerschnittstelle ein von einer der akzeptierten CAs unterzeichnetes Serverzertifikat bereitstellt.

Beachten Sie, dass Sie für komplexere Richtlinien den IBM Konfigurationsassistenten für z/OS Communications Server verwenden sollten. Dabei handelt es sich um ein grafisch orientiertes Tool mit einer geführten Schnittstelle für die Konfiguration von auf Richtlinien basierenden TCP/IP-Netzfunktionen, das als Task in IBM z/OS Management Facility (z/OSMF) sowie als eigenständige Workstationanwendung verfügbar ist.

Für Ihre Sicherheitskonfiguration sind mehrere Updates erforderlich, damit AT-TLS ordnungsgemäß funktioniert. Dieser Abschnitt enthält RACF-Beispielbefehle für die Ausführung der erforderlichen Konfiguration.

#  define started task user ID
#  BPX.DAEMON permit is required for non-zero UID
 ADDUSER PAGENT DFLTGRP(SYS1) OMVS(UID(0) SHARED HOME('/')) +
   NAME('TCP/IP POLICY AGENT') NOPASSWORD

#  define started task
 RDEFINE STARTED PAGENT.* STDATA(USER(PAGENT) GROUP(SYS1)) +
   DATA('TCP/IP POLICY AGENT')

#  refresh to make the changes visible
 SETROPTS RACLIST(STARTED) REFRESH

#  restrict startup of policy agent
 RDEFINE OPERCMDS MVS.SERVMGR.PAGENT UACC(NONE) +
   DATA('restrict startup of policy agent')
 PERMIT MVS.SERVMGR.PAGENT CLASS(OPERCMDS) ACCESS(CONTROL) ID(PAGENT)

#  refresh to make the changes visible 
SETROPTS RACLIST(OPERCMDS) REFRESH 

Wie in Abschnitt AT-TLS-Konfiguration in PROFILE.TCPIP erwähnt, wird Policy Agent nach der Initialisierung von TCP/IP gestartet. Dies bedeutet, es gibt ein (kleines) Zeitfenster, in dem Anwendungen den TCP/IP-Stack ohne Erzwingen der TTLS-Richtlinie verwenden können. Definieren Sie das Profil EZB.INITSTACK.** in der Klasse SERVAUTH, um den Zugriff auf den Stack während dieses Zeitfensters zu verhindern. Ausgenommen hiervon sind Anwendungen mit Lesezugriff (READ) auf das Profil. Sie müssen eine begrenzte Menge an Verwaltungsanwendungen für das Profil zulassen, um die vollständige Initialisierung des Stacks sicherzustellen. Dies wird im Abschnitt “TCP/IP stack initialization access control” des Handbuchs Communications Server IP Configuration Guide (SC31-8775) beschrieben.

Anmerkung: Der Policy Agent gibt die Nachricht EZD1586I zurück, wenn alle Richtlinien aktiv sind.

#  block stack access between stack and AT-TLS availability
# SETROPTS GENERIC(SERVAUTH)
# SETROPTS CLASSACT(SERVAUTH) RACLIST(FACILITY)
 RDEFINE SERVAUTH EZB.INITSTACK.** UACC(NONE)
#  Policy Agent
 PERMIT EZB.INITSTACK.** CLASS(SERVAUTH) ACCESS(READ) ID(PAGENT)
#  OMPROUTE daemon
 PERMIT EZB.INITSTACK.** CLASS(SERVAUTH) ACCESS(READ) ID(OMPROUTE)
#  SNMP agent and subagents
 PERMIT EZB.INITSTACK.** CLASS(SERVAUTH) ACCESS(READ) ID(OSNMPD)
 PERMIT EZB.INITSTACK.** CLASS(SERVAUTH) ACCESS(READ) ID(IOBSNMP)
#  NAME daemon
 PERMIT EZB.INITSTACK.** CLASS(SERVAUTH) ACCESS(READ) ID(NAMED)

#  refresh to make the changes visible
 SETROPTS RACLIST(SERVAUTH) REFRESH

#  restrict access to pasearch command
# RDEFINE SERVAUTH EZB.PAGENT.** UACC(NONE) + 
#   DATA('restrict access to pasearch command')
# PERMIT EZB.PAGENT.** CLASS(SERVAUTH) ACCESS(READ) ID(tcpadmin)

#  refresh to make the changes visible
# SETROPTS RACLIST(SERVAUTH) REFRESH

Wie in Abschnitt AT-TLS-Richtlinie erwähnt, benötigt Debug Manger ein Zertifikat, damit AT-TLS verschlüsselte Kommunikation für Debug Manager konfigurieren kann. Die folgenden Beispielbefehle erstellen ein neues Zertifikat mit dem Namen dbgmgr, das in einem RACF-Schlüsselring mit dem Namen dbgmgr.racf gespeichert wird. Sowohl das Zertifikat als auch der Schlüsselring haben den Eigner STCDBM, die Benutzer-ID der gespeicherten Task des Debug Managers.

#  permit Debug Manager to access certificates
#RDEFINE FACILITY IRR.DIGTCERT.LIST     UACC(NONE)
#RDEFINE FACILITY IRR.DIGTCERT.LISTRING UACC(NONE)
 PERMIT IRR.DIGTCERT.LIST     CLASS(FACILITY) ACCESS(READ) ID(stcdbm)
 PERMIT IRR.DIGTCERT.LISTRING CLASS(FACILITY) ACCESS(READ) ID(stcdbm)

#  refresh to make the changes visible
 SETROPTS RACLIST(FACILITY) REFRESH

#  create self-signed certificate
 RACDCERT ID(stcdbm) GENCERT SUBJECTSDN(CN('RDz Debug Manager') +
   OU('RTP labs') O('IBM') L('Raleigh') SP('NC') C('US')) +
   NOTAFTER(DATE(2015-12-31)) KEYUSAGE(HANDSHAKE) WITHLABEL('dbgmgr')

#  (optional) additional steps required to use a signed certificate
#  1. create a signing request for the self-signed certificate
 RACDCERT ID(stcdbm) GENREQ (LABEL('dbgmgr')) DSN(dsn)
#  2. send the signing request to your CA of choice
#  3. check if the CA credentials (also a certificate) are already known
 RACDCERT CERTAUTH LIST
#  4. mark the CA certificate as trusted
 RACDCERT CERTAUTH ALTER(LABEL('CA cert')) TRUST
#     or add the CA certificate to the database
 RACDCERT CERTAUTH ADD(dsn) WITHLABEL('CA cert') TRUST
#  5. add the signed certificate to the database;
#     this will replace the self-signed one
 RACDCERT ID(stcdbm) ADD(dsn) WTIHLABEL('dbgmgr') TRUST
#     Do NOT delete the self-signed certificate before replacing it.
#     If you do, you lose the private key that goes with the certificate,
#     which makes the certificate useless.

#  create key ring
 RACDCERT ID(stcdbm) ADDRING(dbgmgr.racf)

#  add  certificate to key ring
RACDCERT ID(stcbm) CONNECT(LABEL('dbgmgr') +
   RING(dbgmgr.racf) USAGE(PERSONAL) DEFAULT)

#  additional step required to use a signed certificate
#  6. add CA certificate to key ring
RACDCERT ID(stcdbm) CONNECT(CERTAUTH LABEL('CA cert') +
   RING(dbgmgr.racf))

#  refresh to make the changes visible
 SETROPTS RACLIST(DIGTCERT) REFRESH

#  check if the CA credentials (also a certificate) are already known
 RACDCERT CERTAUTH LIST
#  mark the CA certificate as trusted
 RACDCERT CERTAUTH ALTER(LABEL('CA cert')) TRUST
#     or add the CA certificate to the database
 RACDCERT CERTAUTH ADD(dsn) WITHLABEL('CA cert') TRUST

#  refresh to make the changes visible
 SETROPTS RACLIST(DIGTCERT) REFRESH

#  verify started task setup
 LISTGRP SYS1 OMVS
 LISTUSER PAGENT OMVS
 RLIST STARTED PAGENT.* ALL STDATA

#  verify Policy Agent startup permission
 RLIST OPERCMDS MVS.SERVMGR.PAGENT ALL

#  verify initstack protection
 RLIST SERVAUTH EZB.INITSTACK.** ALL

#  verify pasearch protection
 RLIST SERVAUTH EZB.PAGENT.** ALL

#  verify certificate setup
 RACDCERT CERTAUTH   LIST(LABEL('CA cert'))
 RACDCERT ID(stcdbm) LIST(LABEL('dbgmgr'))
 RACDCERT ID(stcdbm) LISTRING(dbgmgr.racf)