Vor Verwendung dieser Informationen sollten die allgemeinen Hinweise im Abschnitt Dokumentationshinweise für IBM Rational Developer for System z gelesen werden.
Diese Veröffentlichung ist eine Übersetzung des Handbuchs
IBM Rational Developer for System z Version 7.6.1 Host Configuration Guide,
IBM Form SC23-7658-04,
herausgegeben von International Business Machines Corporation, USA
© Copyright International Business Machines Corporation 2005, 2010
© Copyright IBM Deutschland GmbH 2010
Informationen, die nur für bestimmte Länder Gültigkeit haben und für Deutschland, Österreich und die Schweiz nicht zutreffen, wurden in dieser Veröffentlichung im Originaltext übernommen.
Möglicherweise sind nicht alle in dieser Übersetzung aufgeführten Produkte in Deutschland angekündigt und verfügbar; vor Entscheidungen empfiehlt sich der Kontakt mit der zuständigen IBM Geschäftsstelle.
Änderung des Textes bleibt vorbehalten.
Dieses Handbuch beschäftigt sich mit der Konfiguration der Funktionen von IBM Rational Developer for System z. Es enthält Konfigurationsanweisungen für IBM Rational Developer for System z Version 7.6.1 auf Ihrem z/OS-Hostsystem.
Im weiteren Verlauf dieses Handbuchs werden die folgenden Namen verwendet:
Die Konfigurationsdaten für frühere Versionen, einschließlich IBM WebSphere Developer for System z, IBM WebSphere Developer für zSeries und IBM® WebSphere Studio Enterprise Developer, sind in den Veröffentlichungen 'Hostkonfiguration' und 'Program Directory' der entsprechenden Releases enthalten.
Dieses Handbuch wendet sich an Systemprogrammierer, die IBM Rational Developer for System z Version 7.6.1, FMID HHOP760 auf ihrem z/OS-Hostsystem installieren und konfigurieren möchten.
Im vorliegenden Handbuch sind detailliert die verschiedenen Schritte für eine vollständige Konfiguration des Produkts sowie einige vom Standard abweichende Szenarien beschrieben. Voraussetzung für die Verwendung dieses Handbuchs ist, dass Sie mit z/OS UNIX System Services und den MVS-Hostsystemen vertraut sind.
In diesem Abschnitt werden die Änderungen für das Handbuch Rational Developer for System z Version 7.6.1 Hostkonfiguration (IBM Form SC12-4062-04) zusammengefasst (aktualisiert im Mai 2010).
Technische Änderungen oder Zusätze zum Text und den Abbildungen sind durch eine vertikale Linie auf der linken Seite der Änderung angegeben.
Dieses Dokument enthält Informationen, die bisher im Handbuch Rational Developer for System z Version 7.6 Hostkonfiguration (IBM Form SC12-4062-03) enthalten waren.
Neue Informationen:
In diesem Abschnitt werden die in diesem Dokument enthaltenen Informationen zusammengefasst.
Nutzen Sie für die Planung der Installation und des Deployments von Developer for System z die Informationen in diesem Kapitel.
Die folgenden Anpassungsschritte beziehen sich auf eine Basiskonfiguration von Developer for System z:
Common Access Repository Manager (CARMA) ist eine Produktivitätshilfe für Entwickler, die RAM (Repository Access Managers) erstellen. Ein RAM ist eine Anwendungsprogrammierschnittstelle (API) für z/OS-basierte SCMs (Software Configuration Managers).
Vom Benutzer geschriebene Anwendungen können einen CARMA-Server starten, der die RAM(s) lädt und eine Standardschnittstelle für den Zugriff auf den SCM bereitstellt.
Die Schnittstelle für CA Endevor® Software Configuration Manager in IBM® Rational® Developer for System z ermöglicht Clients mit Developer for System z direkten Zugriff auf CA Endevor® SCM.
Developer for System z verwendet bestimmte Funktionen von Application Deployment Manager als allgemeine Deploymentmethode für verschiedene Komponenten. Durch eine optionale Anpassung können weitere Funktionen von Application Deployment Manager aktiviert und der folgende Service zu Developer for System z hinzugefügt werden:
SCLM Developer Toolkit stellt die Tools bereit, mit denen das Leistungsspektrum von SCLM auch auf dem Client verfügbar gemacht werden kann. SCLM selbst ist ein hostbasierter Quellcodemanager, der im Lieferumfang von ISPF enthalten ist.
SCLM Developer Toolkit enthält ein auf Eclipse basierendes Plug-in mit Anbindung an SCLM, das den Zugriff auf alle SCLM-Prozesse für die herkömmliche Codeentwicklung ermöglicht. Das Plug-in unterstützt auch die vollständige Java- und J2EE-Entwicklung auf der Workstation. Dazu gehören die Synchronisation mit SCLM auf dem Mainframe-Computer sowie die Builderstellung, die Assemblierung und das Deployment des J2EE-Codes vom Mainframe-Computer.
In den folgenden Abschnitten ist eine Kombination optionaler Anpassungstasks beschrieben. Konfigurieren Sie den gewünschten Service gemäß den Anweisungen im jeweiligen Abschnitt.
Nach der vollständigen Produktanpassung können Sie die in diesem Kapitel beschriebenen IVPs (Installation Verification Programs) verwenden, um die erfolgreiche Konfiguration der zentralen Produktkomponenten zu überprüfen.
In diesem Kapitel erhalten Sie einen Überblick über die für Developer for System z verfügbaren Bedienerbefehle (oder Konsolbefehle).
Dieses Kapitel soll Sie bei einigen allgemeinen Problemen unterstützen, die beim Konfigurieren von Developer for System z auftreten könnten. Es enthält die folgenden Abschnitte:
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 umfasst mehrere 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.
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 16 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.
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 hebt die Installations- und Konfigurationsänderungen im Vergleich zu früheren Produktreleases hervor. Darüber hinaus finden Sie hier allgemeine Richtlinien für die Migration auf dieses Release. Weitere Informationen hierzu finden Sie in den entsprechenden Abschnitten dieses Handbuchs.
Dieser Anhang 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 Anhang stellt auch eine Beispielkonfiguration zur Verfügung, um Benutzer zu unterstützen, die sich mit einem X.509-Zertifikat selbst authentifizieren.
Dieser Anhang 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.
Dieser Anhang soll Sie bei einigen allgemeinen Problemen unterstützen, die beim Konfigurieren von INETD oder beim Überprüfen oder Modifizieren einer vorhandenen Konfiguration auftreten könnten. INETD wird von Developer for System z zur REXEC/SSH-Funktionalität verwendet.
Dieser Anhang soll Sie bei einigen allgemeinen Problemen unterstützen, die beim Konfigurieren von APPC (Advanced Program-to-Program Communication) oder beim Überprüfen oder Modifizieren einer vorhandenen Konfiguration auftreten könnten.
In diesem Anhang werden die Hostvoraussetzungen und die zusätzlich erforderliche Software für diese Version von Developer for System z aufgelistet.
Nutzen Sie für die Planung der Installation und des Deployment von Developer for System z die Informationen in diesem Kapitel und in Anhang E. Voraussetzungen. Die folgenden Themen werden beschrieben:
Leitfaden für die Migration beschreibt die Installations- und Konfigurationsänderungen im Vergleich zu früheren Produktreleases. Nutzen Sie diese Informationen für die Planung Ihrer Migration auf das aktuelle Release von Developer for System z.
Developer for System z besteht aus einem Client, der auf dem Personal Computer des Benutzers installiert ist, und einem Server, der auf mindestens einem Host installiert ist. Der Host ist in dieser Dokumentation ein z/OS-System. Andere Betriebssysteme, wie AIX und Linux® auf System z werden aber auch unterstützt.
Der Client stellt Entwicklern eine Eclipse-basierte Entwicklungsumgebung zur Verfügung, die eine einheitliche grafische Oberfläche für den Host ermöglicht. Unter anderem kann Arbeit vom Host auf den Client ausgelagert werden, wodurch Ressourcen auf dem Host gespart werden.
Die Hostkomponente besteht aus einigen ständig aktiven Tasks und Tasks, die ad-hoc gestartet werden. Diese Tasks ermöglichen es dem Client, mit den verschiedenen Komponenten Ihres z/OS-Hosts zu arbeiten, wie MVS-Dateien, TSO-Befehle, z/OS UNIX-Dateien und -Befehle, Jobübergabe und Jobausgabe.
Developer for System z kann auch mit Subsystemen und anderer Anwendungssoftware auf dem Host interagieren, wie CICS, Debug Tool und Software Configuration Managers (SCMs), wenn Developer for System z entsprechend konfiguriert ist und wenn diese (zusätzlich erforderlichen) Produkte verfügbar sind.
In Wissenswertes zu Developer for System z finden Sie Informationen zum grundsätzlichen Verständnis des Designs von Developer for System z.
Weitere Informationen zur Funktionalität, die in Developer for System z enthalten ist, finden Sie auf der Website für Developer for System z: http://www-01.ibm.com/software/awdtools/rdz/. Sie können sich auch an Ihren IBM Ansprechpartner wenden.
Für eine Hostinstallation von Developer for System z ist minimales Know-how für SMP/E for z/OS erforderlich.
Für die Konfiguration von Developer for System z ist mehr als die typischen Berechtigungen für Systemprogrammierer und deren übliches Fachwissen erforderlich. Es ist zu erwarten, dass Unterstützung von anderen notwendig sein wird. Die jeweiligen Administratoren für die erforderlichen und optionalen Anpassungstasks finden Sie in Tabelle 3 und in Tabelle 4 aufgelistet.
Die für die Installation und Konfiguration der Hostkomponenten von Developer for System z benötigte Zeit hängt von verschiedenen Faktoren ab. Beispiele:
Die Erfahrung hat gezeigt, dass der Installations- und Konfigurationsprozess für den Host von Developer for System z insgesamt einen Tag bis vier Tage dauert. Diese Zeitangabe gilt für eine reibungslose Installation, die durch einen erfahrenen Systemprogrammierer durchgeführt wird. Falls Probleme auftreten oder das erforderliche Know-how fehlt, dauert die Installation entsprechend länger.
Ausführliche Anweisungen zur SMP/E-Installation des Produkts enthält die Veröffentlichung Program Directory for IBM Rational Developer for System z (IBM Form GI11-8298).
Falls Sie planen, mehrere Instanzen von Developer for System z auszuführen, lesen Sie Mehrere Instanzen ausführen.
Developer for System z bietet Optionen für den Zugriff auf TSO Commands Service an. Sie müssen eine der nachfolgend aufgelisteten Methoden auswählen und konfigurieren:
Anhang E. Voraussetzungen enthält eine Liste vorausgesetzter Software, die installiert und betriebsbereit sein muss, damit Developer for System z funktioniert. Außerdem gibt es eine Liste zusätzlich erforderlicher Software zur Unterstützung bestimmter Features von Developer for System z. Zur Laufzeit muss diese zusätzlich erforderliche Software installiert und betriebsbereit sein, damit das entsprechende Feature ordnungsgemäß funktionieren kann.
Eine aktuelle Liste der Produkte, die für Ihre Version von Developer for System z vorausgesetzt werden bzw. zusätzlich erforderlich sind, enthält die Veröffentlichung Rational Developer for System z Prerequisites (IBM Form SC23-7659) in der Onlinebibliothek für Developer for System z unter http://www-01.ibm.com/software/awdtools/rdz/library/. Planen Sie vorausschauend, damit die vorausgesetzten Produkte rechtzeitig verfügbar sind. Dies kann je nach Geschäftspolitik an Ihrem Standort einige Zeit in Anspruch nehmen. Nachfolgend sind die wichtigsten Voraussetzungen für eine Basiskonfiguration aufgeführt:
Developer for System z erfordert die Reservierung der in Tabelle 1 aufgelisteten Systemressourcen. Die in Tabelle 2 aufgelisteten Ressourcen sind für Zusatzservices erforderlich. Planen Sie vorausschauend, damit diese Ressourcen rechtzeitig verfügbar sind. Die Bereitstellung kann je nach Geschäftspolitik an Ihrem Standort einige Zeit in Anspruch nehmen.
Ressource | Standardwert | Informationen |
---|---|---|
Datei mit APF-Berechtigung | FEK.SFEKAUTH | APF-Berechtigungen in PROGxx |
Gestartete Task | JMON, RSED und LOCKD | Hinweise zum Server |
Port für die hostinterne Verwendung | 6715 | Konfigurationsdatei für JES Job Monitor (FEJJCNFG) |
Port für die hostinterne Verwendung | 4036 | RSE-Konfigurationsdatei rsed.envvars |
Port für die Kommunikation zwischen Client und Host | 4035 | PROCLIB-Änderungen |
Portbereich für die Kommunikation zwischen Client und Host | Jeder verfügbare Port kann verwendet werden. | Für RSE-Server verfügbaren PORTRANGE definieren |
Definition der Anwendungssicherheit | Uneingeschränkter Lesezugriff auf FEKAPPL | Anwendungsschutz für RSE definieren |
PassTicket-Sicherheitsdefinitionen | Kein Standard | PassTicket-Unterstützung für RSE definieren |
Ressource | Standardwert | Informationen |
---|---|---|
LINKLIST-Datei | FEK.SFEKAUTH und FEK.SFEKLOAD | SCLM Developer Toolkit (optional) |
LPA-Datei | FEK.SFEKLPA | Common Access Repository Manager (optional) |
Portbereich für die hostinterne Verwendung | 5227-5326 (100 Ports) | Common Access Repository Manager (optional) |
Ports für die hostinterne Verwendung | Jeder verfügbare Port kann verwendet werden. | APPC-Transaktion für TSO Commands Service (optional) |
Port für die Kommunikation zwischen Client und Host | Kein Standard | Application Deployment Manager (optional) |
Aktualisierung für die CICS-Systemdefinition | Mehrere Werte | Application Deployment Manager (optional) |
Aktualisierung für CICS-JCL | FEK.SFEKLOAD |
Für die Konfiguration von Developer for System z ist mehr als die typischen Berechtigungen für Systemprogrammierer und deren übliches Fachwissen erforderlich. Es ist zu erwarten, dass ein gewisses Maß an Unterstützung von anderen notwendig sein wird. Die jeweiligen Administratoren für die erforderlichen und optionalen Anpassungstasks finden Sie in Tabelle 3 und in Tabelle 4 aufgelistet.
Administrator | Task | Informationen |
---|---|---|
Systemadministrator | Für alle Anpassungstasks sind typische Systemprogrammiereraktionen erforderlich. | Nicht zutreffend |
Sicherheitsadministrator |
|
Sicherheitsaspekte |
TCP/IP-Administrator | Neue TCP/IP-Ports definieren | TCP/IP-Ports |
WLM-Administrator | Ziele für gestartete Tasks für die Server und deren untergeordneten Prozesse zuordnen | Hinweise zu WLM |
Administrator | Task | Informationen |
---|---|---|
Systemadministrator | Für alle Anpassungstasks sind typische Systemprogrammiereraktionen erforderlich. | Nicht zutreffend |
Sicherheitsadministrator |
|
|
TCP/IP-Administrator | Neue TCP/IP-Ports definieren | TCP/IP-Ports |
SCLM-Administrator |
|
SCLM Developer Toolkit (optional) |
CICS-TS-Administrator |
|
|
DB2 | Gespeicherte DB2-Prozedur definieren | Gespeicherte DB2-Prozedur (optional) |
WLM-Administrator |
|
|
APPC-Administrator | APPC-Transaktion definieren | APPC-Transaktion für TSO Commands Service (optional) |
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. Hinweise zu WLM enthält Informationen, wie Sie Ihre WLM-Konfiguration entsprechend planen können.
Wenn Developer for System z aktiv ist, wird eine variable Anzahl von Systemressourcen wie Adressräume und z/OS UNIX-Prozesse und -Threads verwendet. Die Verfügbarkeit dieser Ressourcen ist durch verschiedene Systemdefinitionen begrenzt. Optimierungsaspekte enthält Informationen zum Abschätzen der Verwendung von wichtigen Ressourcen. Auf diese Weise können Sie Ihre Systemkonfiguration entsprechend planen.
Fragen Sie bei Ihrem MVS-Systemprogrammierer, beim Sicherheitsadministrator und beim TCP/IP-Administrator nach, ob die vorausgesetzten Produkte und die erforderliche Software installiert und getestet sind und funktionieren. Nachfolgend sind einige erforderliche Anpassungstasks aufgelistet, die leicht übersehen werden:
Die Benutzer-ID eines Benutzers von Developer for System z muss (mindestens) die folgenden Attribute haben:
Beispiel (Befehl LISTUSER userid NORACF OMVS):
USER=userid OMVS INFORMATION ---------------- UID= 0000003200 HOME= /u/userid PROGRAM= /bin/sh CPUTIMEMAX= NONE ASSIZEMAX= NONE FILEPROCMAX= NONE PROCUSERMAX= NONE THREADSMAX= NONE MMAPAREAMAX= NONE
Beispiel (Befehl LISTGRP group NORACF OMVS):
GROUP group OMVS INFORMATION ---------------- GID= 0000003243
Developer for System z umfasst drei permanent aktive Server, die gestartete Tasks oder Benutzerjobs sein können. Diese Server stellen selbst die erforderlichen Services bereit oder starten dafür andere Server (z. B. z/OS UNIX-Threads oder -Benutzerjobs).
JMON (JES Job Monitor) stellt alle Services mit Bezug zum JES bereit.
Remote Systems Explorer (RSE) ist die Komponente von Developer for System z, die Kernservices wie die Verbindung vom Client zum Host bereitstellt.
Zu bestimmten Hostservices (und somit zu den zugehörigen Ports) muss der Client, wie im Abschnitt TCP/IP-Ports beschrieben, eine Verbindung herstellen können. Diese Services und Ports müssen deshalb für die Firewall, die den Host schützt, definiert sein. An allen anderen von Developer for System z verwendeten Ports gibt es nur Hostdatenverkehr. Nachfolgend sind die Ports aufgelistet, die für eine Basiskonfiguration von Developer for System z notwendig sind.
Ab Version 7.6.1 stellt Developer for System z mit einer ISPF-Anzeigenanwendung eine alternative Methode zur Konfiguration der Hostseite des Produkts bereit. Damit stehen Ihnen die folgenden Methoden zur Auswahl:
Developer for System z unterstützt das Klonen einer Installation auf einem anderen System, sodass Sie nicht auf jedem System eine SMP/E-Installation durchführen müssen.
Für das Deployment auf anderen Systemen sind die nachfolgenden Dateien und Verzeichnisse obligatorisch. Falls Sie eine Datei an eine andere Position kopiert haben, muss die entsprechende Datei in den folgenden Listen durch Ihre angepasste Datei ersetzt werden.
Weitere Informationen zu den folgenden Beispielbefehlen für die Archivierung und Wiederherstellung des Installationsverzeichnisses von Developer for System z enthält die Veröffentlichung UNIX System Services Command Reference (IBM Form SA22-7802).
Benutzer der Clientkomponente von Developer for System z müssen das Ergebnis bestimmter Hostanpassungen, z. B. der TCP/IP-Portnummern, kennen, damit der Client fehlerfrei funktioniert. Verwenden Sie diese Prüflisten für die erforderlichen Informationen.
Die Prüfliste in Tabelle 5 enthält die erforderlichen Ergebnisse obligatorischer Anpassungsschritte. In Tabelle 6 sind die erforderlichen Ergebnisse optionaler Anpassungsschritte aufgelistet.
Anpassung | Wert |
---|---|
Portnummer des JES Job Monitor-Servers (Standard: 6715)
Lesen Sie die Beschreibung für SERV_PORT im Abschnitt Konfigurationsdatei für JES Job Monitor (FEJJCNFG). |
|
TCP/IP-Portnummer des RSE-Dämons (Standard: 4035)
Lesen Sie hierzu den Abschnitt RSE-Dämon. |
Anpassung | Wert |
---|---|
Position der ELAXF*-Prozeduren, falls sie nicht in einer Prozedurenbibliothek des Systems enthalten sind
Lesen Sie die Anmerkung zu JCLLIB im Abschnitt ELAXF*-Prozeduren für ferne Builderstellung. |
|
Namen der ELAXF*-Prozeduren oder der zugehörigen Prozedurschritte, sofern sie geändert wurden
Lesen Sie die Anmerkung zur Änderung der Namen im Abschnitt ELAXF*-Prozeduren für ferne Builderstellung. |
|
Name der gespeicherten DB2-Prozedur (Standard: ELAXMSAM)
Informationen zu gespeicherten DB2-Prozeduren finden Sie in Mehrere Instanzen ausführen. |
|
Position der gespeicherten DB2-Prozedur, sofern sie nicht in einer Prozedurenbibliothek des Systems enthalten ist:
Lesen Sie hierzu den Abschnitt Gespeicherte DB2-Prozedur (optional). |
|
TN3270-Portnummer für den Host-Connect-Emulator (zusätzlich erforderliche Software) (Standard: 23)
Lesen Sie hierzu Sicherheitsaspekte. |
|
REXEC- oder SSH-Portnummer (zusätzlich erforderliche Software) (Standard: 512 bzw. 22)
Lesen Sie hierzu den Abschnitt REXEC (oder SSH) verwenden (optional). |
|
Position der Datei server.zseries bei Verwendung der Verbindungsmethode mit REXEC/SSH
(Standard: /etc/rdz)
Lesen Sie hierzu den Abschnitt REXEC (oder SSH) verwenden (optional). |
|
Position der CRA#ASLM-JCL für das Anlegen von CARMA-SCLM-RAM-Dateien (Standard: FEK.#CUST.JCL)
Lesen Sie die Anmerkung zu CRA#ASLM im Abschnitt SCLM-RAM aktivieren. |
Die folgenden Anpassungsschritte beziehen sich auf eine Basiskonfiguration von Developer for System z. Informationen zu den Voraussetzungen für die Anpassung optionaler Komponenten finden Sie in den Kapiteln zu diesen Komponenten.
Für diese Anpassungstask, für die die folgenden Ressourcen und speziellen Anpassungstasks erforderlich sind, benötigen Sie die Unterstützung eines Sicherheitsadministrators und eines TCP/IP-Administrators:
Bevor Sie Developer for System z an Ihrem Standort verwenden können, müssen Sie die folgenden Tasks ausführen, um die Installation zu prüfen. Sofern nicht anders angegeben, sind alle Tasks obligatorisch.
Im Lieferumfang von Developer for System z sind verschiedene Beispielkonfigurationsdateien und Beispiel-JCL enthalten. Um das Überschreiben Ihrer Anpassungen bei einer Wartung zu vermeiden, sollten Sie alle diese Member und z/OS UNIX-Dateien an eine andere Position kopieren und die Kopie anpassen.
Einige Funktionen von Developer for System z erfordern, dass bestimmte Verzeichnisse in z/OS UNIX vorhanden sind. Diese Verzeichnisse müssen während der Anpassung des Produkts erstellt werden. Zur Vereinfachung der Installation steht der Beispieljob FEKSETUP bereit, mit dem Sie die Kopien und die erforderlichen Verzeichnisse erstellen können.
Passen Sie das Beispielmember FEKSETUP in der Datei FEK.SFEKSAMP an und übergeben Sie es, um anpassbare Kopien von Konfigurationsdateien und der Konfigurations-JCL sowie die erforderlichen z/OS UNIX-Verzeichnisse zu erstellen. Die notwendigen Anpassungsschritte sind innerhalb des Members beschrieben.
Dieser Job führt die folgenden Tasks aus:
mkdir /usr/lpp/rdz/cust ln -s /usr/lpp/rdz/cust /etc/rdz
Weitere Informationen zu den nachfolgend aufgelisteten PARMLIB-Definitionen enthält die Veröffentlichung MVS Initialization and Tuning Reference (IBM Form SA22-7592). Weitere Informationen zu den Beispielkonsolbefehlen enthält die Veröffentlichung MVS System Commands (IBM Form SA22-7627).
RSE (Remote Systems Explorer), mit dem Kernservices wie der Verbindungsaufbau vom Client zum Host bereitgestellt werden, ist ein auf z/OS UNIX basierender Prozess. Aus diesem Grund ist es wichtig, richtige Werte für die z/OS UNIX-Systemgrenzwerte in BPXPRMxx festzulegen. Diese basieren auf der Anzahl der gleichzeitig aktiven Benutzer in Developer for System z und auf ihrer durchschnittlichen Arbeitslast.
Weitere Informationen zu verschiedenen definierten BPXPRMxx-Grenzwerten und ihrer Auswirkung auf Developer for System z finden Sie in Optimierungsaspekte.
MAXASSIZE gibt die maximale Regionsgröße des Adressraums/Adressierungsprozesses an. Setzen Sie MAXASSIZE in SYS1.PARMLIB(BPXPRMxx) auf 2G. Dies ist der zulässige Maximalwert. Dieser Grenzwert gilt systemweit. Er ist daher für alle z/OS UNIX-Adressräume aktiv. Wenn Sie dies nicht wünschen, können Sie den Grenzwert in Ihrer Sicherheitssoftware auch nur für Developer for System z festlegen. Dies wird im Abschnitt Gestartete Tasks für Developer for System z definieren beschrieben.
MAXTHREADS gibt die maximale Anzahl der aktiven Threads für einen einzelnen Prozess an. Setzen Sie MAXTHREADS in SYS1.PARMLIB(BPXPRMxx) auf mindestens 1500. Dieser Grenzwert gilt systemweit. Er ist daher für alle z/OS UNIX-Adressräume aktiv. Wenn Sie dies nicht wünschen, können Sie den Grenzwert in Ihrer Sicherheitssoftware auch nur für Developer for System z festlegen. Dies wird im Abschnitt Gestartete Tasks für Developer for System z definieren beschrieben.
MAXTHREADTASKS gibt die maximale Anzahl der aktiven MVS-Tasks für einen einzelnen Prozess an. Setzen Sie MAXTHREADTASKS in SYS1.PARMLIB(BPXPRMxx) auf mindestens 1500. Dieser Grenzwert gilt systemweit. Er ist daher für alle z/OS UNIX-Adressräume aktiv. Wenn Sie dies nicht wünschen, können Sie den Grenzwert in Ihrer Sicherheitssoftware auch nur für Developer for System z festlegen. Dies wird im Abschnitt Gestartete Tasks für Developer for System z definieren beschrieben.
MAXPROCUSER gibt die maximale Anzahl der Prozesse an, die für eine einzelne z/OS UNIX-Benutzer-ID gleichzeitig aktiv sein dürfen. Setzen Sie MAXPROCUSER in SYS1.PARMLIB(BPXPRMxx) auf mindestens 50. Diese Einstellung wurde als systemweiter Grenzwert entwickelt, da er für alle Clients aktiv sein sollte, die Developer for System z verwenden.
Diese Werte können mit folgenden Konsolbefehlen überprüft und dynamisch (bis zum nächsten IPL) gesetzt werden:
Fügen Sie SYS1.PARMLIB(COMMANDxx) Startbefehle für die Server RSED, LOCKD und JMON von Developer for System z hinzu, damit sie beim nächsten Start über IPL automatisch gestartet werden.
Sobald die Server definiert und konfiguriert sind, können sie mit den folgenden Konsolbefehlen dynamisch (bis zum nächsten IPL) gestartet werden:
Der optionale Service von Common Access Repository Manager (CARMA) unterstützt alternative Methoden für den Serverstart, bei denen kein JES-Initiator erforderlich ist. Die flexibelste dieser Alternativen setzt voraus, dass sich das Modul CRASTART der Ladebibliothek FEK.SFEKLPA im Link-Pack-Bereich (LPA) befindet.
LPA-Dateien sind in SYS1.PARMLIB(LPALSTxx) definiert.
LPA-Definitionen können mit folgenden Konsolbefehlen dynamisch (bis zum nächsten IPL) gesetzt werden:
Das Modul FEJJMON in der Ladebibliothek FEK.SFEKAUTH und die LE-Laufzeitbibliotheken (Language Environment) (CEE.SCEERUN*) müssen für APF berechtigt werden, damit JES Job Monitor auf JES-Spooldateien zugreifen kann.
Das Modul BWBTSOW in der Ladebibliothek FEK.SFEKAUTH und die REXX-Laufzeitbibliothek (REXX.*.SEAGLPA) müssen für APF berechtigt werden, damit der optionale Service von SCLM Developer Toolkit funktioniert.
Damit das TSO/ISPF-Client-Gateway von ISPF erstellt werden kann, muss das Modul ISPZTSO in SYS1.LINKLIB für APF berechtigt werden. Das TSO/ISPF-Client-Gateway wird von TSO Commands Service, SCLM Developer Toolkit und optional von CARMA von Developer for System z verwendet.
Wenn Sie sich an Ihrem Standort nach den IBM Empfehlungen gerichtet haben, sind die APF-Berechtigungen in SYS1.PARMLIB(PROGxx) definiert.
APF-Berechtigungen können mit den folgenden Konsolbefehlen dynamisch (bis zum nächsten IPL) gesetzt werden, wobei volser für den Datenträger steht, auf dem sich die Datei befindet, sofern sie nicht von den SMS verwaltet wird:
LINKLIST-Definitionen für Developer for System z können in 3 Kategorien gruppiert werden:
Alle BWB*-Module in den Ladebibliotheken FEK.SFEKAUTH und FEK.SFEKLOAD müssen mithilfe von STEPLIB oder LINKLIST verfügbar gemacht werden, damit der (optionale) Service von SCLM Developer Toolkit funktioniert.
Wenn Sie sich für die Verwendung von STEPLIB entscheiden, müssen Sie die nicht über LINKLIST verfügbaren Bibliotheken in der Anweisung STEPLIB der RSE-Konfigurationsdatei rsed.envvars definieren. Beachten Sie jedoch Folgendes:
Wenn Sie sich an Ihrem Standort nach den IBM Empfehlungen gerichtet haben, sind die LINKLIST-Dateien in SYS1.PARMLIB(PROGxx) definiert.
Die erforderlichen Definitionen sehen wie folgt aus, wobei listname der Name der zu aktivierenden LINKLIST-Gruppe ist und volser für den Datenträger steht, auf dem sich die Datei befindet, sofern sie nicht im Masterkatalog katalogisiert ist:
LINKLIST-Definitionen können mit den folgenden Konsolbefehlen dynamisch (bis zum nächsten einleitenden Programmladen) erstellt werden. Dabei ist listname der Name der zu aktivierenden LINKLIST-Gruppe und volser steht für den Datenträger, auf dem sich die Datei befindet, sofern sie nicht im Masterkatalog katalogisiert ist:
Remote Systems Explorer (RSE) ist ein z/OS UNIX-Prozess, der auf die MVS-Ladebibliotheken zugreifen muss. Die folgenden (vorausgesetzten) Bibliotheken müssen über STEPLIB oder LINKLIST/LPALIB verfügbar sein:
Zur Unterstützung optionaler Services müssen die folgenden Bibliotheken über STEPLIB oder LINKLIST/LPALIB verfügbar sein. Diese Liste enthält keine Dateien, die für ein Produkt spezifisch sind, mit dem Developer for System z interagiert, z. B. für IBM Debug Tool.
Wenn Sie sich an Ihrem Standort nach den IBM Empfehlungen gerichtet haben, sind die LINKLIST-Dateien in SYS1.PARMLIB(PROGxx) definiert. LPA-Dateien sind in SYS1.PARMLIB(LPALSTxx) definiert.
Wenn Sie sich für die Verwendung von STEPLIB entscheiden, müssen Sie die nicht über LINKLIST/LPALIB verfügbaren Bibliotheken in der Anweisung STEPLIB der RSE-Konfigurationsdatei rsed.envvars definieren. Beachten Sie jedoch Folgendes:
Im Client von Developer for System z gibt es eine Codegenerierungskomponente mit der Bezeichnung 'Enterprise Service Tools' (EST). Alle IRZ*- und IIRZ*-Module in der Ladebibliothek FEK.SFEKLOAD müssen mithilfe von STEPLIB oder LINKLIST verfügbar gemacht werden, damit der generierte Code Diagnosefehlernachrichten ausgeben kann.
Wenn Sie sich an Ihrem Standort nach den IBM Empfehlungen gerichtet haben, sind die LINKLIST-Dateien in SYS1.PARMLIB(PROGxx) definiert.
Wenn Sie sich für die Verwendung von STEPLIB entscheiden, müssen Sie die nicht über LINKLIST verfügbaren Bibliotheken in der Anweisung STEPLIB der Task definieren, die den Code (IMS oder Batch-Job) ausführt. Beachten Sie dabei allerdings Folgendes:
Die gestartete Task und die Prozeduren für ferne Builds, die nachfolgend aufgelistet sind, müssen sich in einer für Ihr JES definierten Prozedurenbibliothek des Systems befinden. In den folgenden Anweisungen wird die Standardprozedurenbibliothek der IBM, SYS1.PROCLIB, verwendet.
Passen Sie das Beispielmember FEK.#CUST.PROCLIB(JMON) der gestarteten Task wie innerhalb des Members beschrieben an und kopieren Sie es in SYS1.PROCLIB. Sie müssen wie im nachstehenden Beispiel Folgendes angeben:
//*
//* JES JOB MONITOR
//*
//JMON PROC PRM=, * PRM='-TV' TO START TRACING
// LEPRM='RPTOPTS(ON)',
// HLQ=FEK,
// CFG=FEK.#CUST.PARMLIB(FEJJCNFG)
//*
//JMON EXEC PGM=FEJJMON,REGION=0M,TIME=NOLIMIT,
// PARM=('&LEPRM,ENVAR("_CEE_ENVFILE_S=DD:ENVIRON")/&PRM')
//STEPLIB DD DISP=SHR,DSN=&HLQ..SFEKAUTH
//ENVIRON DD DISP=SHR,DSN=&CFG
//SYSPRINT DD SYSOUT=*
//SYSOUT DD SYSOUT=*
// PEND
//*
Passen Sie das Beispielmember FEK.#CUST.PROCLIB(RSED) der gestarteten Task wie innerhalb des Members beschrieben an und kopieren Sie es in SYS1.PROCLIB. Sie müssen wie im nachstehenden Beispiel Folgendes angeben:
//* //* RSE-DÄMON //* //RSED PROC IVP='', * 'IVP' für einen IVP-Test // PORT=4035, // HOME='/usr/lpp/rdz', // CNFG='/etc/rdz' //* //RSE EXEC PGM=BPXBATSL,REGION=0M,TIME=NOLIMIT, // PARM='PGM &HOME/bin/rsed.sh &IVP &PORT &CNFG' //STDERR DD SYSOUT=* //STDOUT DD SYSOUT=* // PEND //*
Passen Sie das Beispielmember FEK.#CUST.PROCLIB(LOCKD) der gestarteten Task wie innerhalb des Members beschrieben an und kopieren Sie es in SYS1.PROCLIB. Sie müssen wie im nachstehenden Beispiel Folgendes angeben:
//* //* RSE LOCK DAEMON //* //LOCKD PROC HOME='/usr/lpp/rdz', // CNFG='/etc/rdz', // LOG=1 //* //LOCKD EXEC PGM=BPXBATSL,REGION=0M,TIME=NOLIMIT, PARM=PGM &HOME./bin/lockd.sh &CNFG &LOG' //STDOUT DD SYSOUT=* //STDERR DD SYSOUT=* // PEND //*
Die Länge der PARM-Variablen liegt bei maximal 100 Zeichen. Dies kann zu Problemen führen, wenn Sie benutzerdefinierte Verzeichnisnamen verwenden. Sie können dieses Problem mit einer der folgenden Methoden umgehen:
Für lange Verzeichnisnamen können symbolische Links als Kurzform verwendet werden. Der folgende z/OS UNIX-Beispielbefehl definiert einen symbolischen Link (/usr/lpp/rdz) zu einem anderen Verzeichnis (/long/directory/name/usr/lpp/rdz).
ln -s /long/directory/name/usr/lpp/rdz /usr/lpp/rdz
Wenn das PARM-Feld leer ist, startet BPXBATSL eine z/OS UNIX-Shell und führt das von STDIN bereitgestellte Shell-Script aus. Beachten Sie, dass STDIN eine (als ORDONLY angelegte) z/OS UNIX-Datei sein muss und dass bei Verwendung von STDIN die Verwendung von PROC-Variablen für den Port usw. inaktiviert wird. Beachten Sie auch, dass die Shell die Shellanmeldescripts /etc/profile und $HOME/.profile ausführt.
Wenn Sie diese Methode anwenden möchten, müssen Sie zunächst die Start-JCL aktualisieren, damit sie in etwa wie im folgenden Beispiel aussieht:
//* //* RSE-DÄMON - VERWENDUNG VON STDIN //* //RSED PROC CNFG='/etc/rdz' //* //RSE EXEC PGM=BPXBATSL,REGION=0M,TIME=NOLIMIT //STDOUT DD SYSOUT=* //STDERR DD SYSOUT=* //STDIN DD PATHOPTS=(ORDONLY),PATH='&CNFG./rsed.stdin.sh' //STDENV DD PATHOPTS=(ORDONLY),PATH='&CNFG./rsed.envvars' // PEND //*
Als Zweites müssen Sie das Shell-Script erstellen (in diesem Beispiel /etc/rdz/rsed.stdin.sh), das den RSE-Dämon startet. Der Inhalt dieses Scripts sieht etwa wie das folgende Beispiel aus:
/long/directory/name/usr/lpp/rdz/bin/rsed.sh 4035 /etc/rdz
Developer for System z stellt Beispiel-JCL-Prozeduren bereit, die für die JCL-Generierung, die Fernerstellung von Projektbuilds und die ferne Syntaxprüfung von CICS-BMS-Masken, IMS-MFS-Anzeigen sowie von COBOL-, PL/I-, Assembler- und C/C++-Programmen verwendet werden können. Diese Prozeduren ermöglichen Installationen, eigene Standards anzuwenden. Außerdem wird damit sichergestellt, dass die Entwickler dieselben Prozeduren mit denselben Compileroptionen und Compilerversionen verwenden.
Die Beispielprozeduren und ihre Funktionen sind in Tabelle 7 aufgelistet.
Member | Zweck |
---|---|
ELAXFADT | Beispielprozedur für die Assemblierung und das Debugging von High-Level-Assembler-Programmen |
ELAXFASM | Beispielprozedur für die Assemblierung von High-Level-Assembler-Programmen |
ELAXFBMS | Beispielprozedur für die Erstellung eines CICS-BMS-Objekts und des entsprechenden Copy-, Dsect- oder Include-Members |
ELAXFCOC | Beispielprozedur für COBOL-Kompilierung, integrierte CICS-Umsetzung und integrierte DB2-Umsetzung |
ELAXFCOP | Beispielprozedur für die DB2-Vorverarbeitung von "EXEC SQL"-Anweisungen, die in COBOL-Programmen eingebettet sind |
ELAXFCOT | Beispielprozedur für die CICS-Umsetzung von "EXEC CICS"-Anweisungen, die in COBOL-Programme eingebettet sind |
ELAXFCPC | Beispielprozedur für C-Kompilierungen |
ELAXFCPP | Beispielprozedur für C++-Kompilierungen |
ELAXFCP1 | Beispielprozedur für COBOL-Kompilierungen mit SCM-Vorprozessoranweisungen (-INC und ++INCLUDE) |
ELAXFDCL | Beispielprozedur für die Ausführung eines Programms im TSO-Modus |
ELAXFGO | Beispielprozedur für den GO-Schritt |
ELAXFLNK | Beispielprozedur für die Verknüpfung von C/C++-, COBOL-, PLI- und High-Level-Assembler-Programmen |
ELAXFMFS | Beispielprozedur für die Erstellung von IMS-MFS-Anzeigen |
ELAXFPLP | Beispielprozedur für die DB2-Vorverarbeitung von "EXEC SQL"-Anweisungen, die in PLI-Programme eingebettet sind |
ELAXFPLT | Beispielprozedur für die CICS-Umsetzung von "EXEC-CICS"-Anweisungen, die in PLI-Programme eingebettet sind |
ELAXFPL1 | Beispielprozedur für PL/I-Kompilierung, integrierte CICS-Umsetzung und integrierte DB2-Umsetzung |
ELAXFPP1 | Beispielprozedur für PL/I-Kompilierungen mit SCM-Vorprozessoranweisungen (-INC und ++INCLUDE) |
ELAXFTSO | Beispielprozedur für die Ausführung bzw. das Debugging von generiertem DB2-Code im TSO-Modus |
ELAXFUOP | Beispielprozedur für die Generierung des UOPT-Schritts beim Erstellen von Programmen, die in CICS- oder IMS-Subsystemen ausgeführt werden |
Die Namen der Prozeduren und der einzelnen Prozedurschritte stimmen mit den Standardmerkmalen des Clients von Developer for System z überein. Falls Sie den Namen einer Prozedur oder eines Prozedurschritts ändern möchten, sollten Sie auch die entsprechende Eigenschaftendatei auf allen Clients aktualisieren. Das Ändern der Namen von Prozeduren oder Prozedurschritten ist nicht zu empfehlen.
Passen Sie die Member der Build-Beispielprozeduren FEK.#CUST.PROCLIB(ELAXF*) wie in den Membern beschrieben an und kopieren Sie sie in SYS1.PROCLIB. Für andere Produktbibliotheken müssen Sie die korrekten übergeordneten Qualifikationsmerkmale angeben (siehe Tabelle 8).
Produkt | Standard-HLQ | Wert |
---|---|---|
Developer for System z | FEK | |
CICS | CICSTS32.CICS | |
DB2 | DSN910 | |
IMS | IMS | |
COBOL | IGY.V4R1M0 | |
PL/I | IBMZ.V3R8M0 | |
C/C++ | CBC | |
LE | CEE | |
LINKLIB des Systems | SYS1 | |
MACLIB des Systems | SYS1 |
Wenn die ELAXF*-Prozeduren nicht in eine Prozedurenbibliothek des Systems kopiert werden können, fordern Sie die Benutzer von Developer for System z auf, zu den Jobmerkmalen auf dem Client (direkt nach der JOB-Karte) eine JCLLIB-Karte hinzuzufügen.
//MYJOB JOB <Jobparameter> //PROCS JCLLIB ORDER=(FEK.#CUST.PROCLIB)
Passen Sie das Beispielmember FEKRACF in der Datei FEK.#CUST.JCL an und übergeben Sie es, um die Sicherheitsdefinitionen für Developer for System z zu erstellen. Der Benutzer, der diesen Job übergibt, muss die Zugriffsrechte eines Sicherheitsadministrators haben, z. B. RACF SPECIAL.
Die folgende Liste obligatorischer Sicherheitsdefinitionen für Developer for System z ist in Sicherheitsaspekte ausführlich erläutert. In diesem Kapitel sind auch allgemeine Sicherheitsaspekte von Developer for System z beschrieben, einschließlich der nicht vom Beispieljob FEKRACF abgedeckten Sicherheitsaspekte vorausgesetzter Produkte.
Achtung: Die Clientverbindungsanforderung schlägt fehl, wenn die Anwendungssicherheit und PassTickets nicht ordnungsgemäß konfiguriert sind. |
JMON (JES Job Monitor) stellt alle Services mit Bezug zum JES bereit. Das Verhalten des JES Job Monitor kann mit den Definitionen in FEJJCNFG gesteuert werden.
FEJJCNFG befindet sich in FEK.#CUST.PARMLIB, sofern Sie bei der Anpassung und Übergabe des Jobs FEK.SFEKSAMP(FEKSETUP) keine andere Position angegeben haben. Weitere Details hierzu enthält der Abschnitt Anpassungskonfiguration.
Passen Sie das Beispielkonfigurationsmember FEJJCNFG von JES Job Monitor wie im folgenden Beispiel an. Wenn eine US-Codepage verwendet wird, beginnen die Kommentarzeilen mit dem Nummernzeichen (#). Datenzeilen dürfen nur eine Anweisung und ihren zugeordneten Wert haben. Kommentare sind nicht in derselben Zeile zulässig.
SERV_PORT=6715
TZ=EST5EDT
#_BPXK_SETIBMOPT_TRANSPORT=TCPIP
#APPLID=FEKAPPL
#AUTHMETHOD=SAF
#CODEPAGE=UTF-8
#CONCHAR=$
#CONSOLE_NAME=JMON
#GEN_CONSOLE_NAME=OFF
#HOST_CODEPAGE=IBM-1047
#LIMIT_COMMANDS=NOLIMIT
#LIMIT_VIEW=USERID
#LISTEN_QUEUE_LENGTH=5
#MAX_DATASETS=32
#MAX_THREADS=200
#TIMEOUT=3600
#TIMEOUT_INTERVAL=1200
#SUBMITMETHOD=TSO
#TSO_TEMPLATE=FEK.#CUST.CNTL(FEJTSO)
Die Portnummer für den Hostserver mit JES Job Monitor. Der Standardport ist 6715. Eine Änderung wird angeraten, allerdings müssen die Client- und die Serverkomponente von Developer for System z mit derselben Portnummer konfiguriert werden. Wenn Sie die Server-Port-Nummer ändern, müssen alle Clients in der Ansicht 'Ferne Systeme' den JES Job Monitor-Port für dieses System ändern.
Folgende Definitionen sind optional. Wenn Sie diese Definitionen übergehen, werden die angegebenen Standardwerte verwendet.
Unabhängig vom verwendeten Konsolennamen wird die Benutzer-ID des Clients, der den Befehl anfordert, als die logische Einheit der Konsole verwendet und in den syslog-Nachrichten IEA630I und IEA631 aufgezeichnet.
IEA630I OPERATOR console NOW ACTIVE, SYSTEM=sysid, LU=id IEA631I OPERATOR console NOW INACTIVE, SYSTEM=sysid, LU=id
Diese Anweisung wird nur verwendet, wenn CONSOLE_NAME mit &SYSUID identisch ist und die Benutzer-ID nicht als Konsolenname verfügbar ist.
Wenn GEN_CONSOLE_NAME=ON ist, wird ein alternativer Konsolenname generiert, indem der Benutzer-ID eine einzelne Ziffer hinzugefügt wird. Dafür werden die Ziffern von 0 bis 9 versucht. Wenn keine verfügbare Konsole gefunden wird, scheitert der vom Client abgesetzte Befehl.
Wenn GEN_CONSOLE_NAME=OFF ist, scheitert der vom Client abgesetzte Befehl.
Ab Version 7.6.1 wird der hier angegebene Wert für HOST_CODEPAGE von Developer for System z-Clients ignoriert und die Codepage verwendet, die lokal in den Eigenschaften des "MVS Files"-Subsystems angegeben ist.
Jobeigner | ||
---|---|---|
LIMIT_COMMANDS | Benutzer | Anderer Eigner |
USERID (Standard) | Zulässig | Nicht zulässig |
LIMITED | Zulässig | Zulässig, wenn die Berechtigung explizit in den Sicherheitsprofilen erteilt wird |
NOLIMIT | Zulässig | Zulässig, wenn die Sicherheitsprofile die Berechtigung enthalten oder die JESSPOOL-Klasse nicht aktiv ist |
Der RSE-Sperrdämon und der RSE-Serverprozess (RSE-Dämon, RSE-Thread-Pool und RSE-Server) verwenden die Definitionen in rsed.envvars. Developer for System z und Services anderer Anbieter können in dieser Konfigurationsdatei auch Umgebungsvariablen zur eigenen Verwendung definieren.
RSE (Remote Systems Explorer) stellt Kernservices wie den Verbindungsaufbau vom Client zum Host und das Starten anderer Server für bestimmte Services bereit. Der Sperrdämon stellt Überwachungsservices für Dateisperren bereit.
Die Datei rsed.envvars befindet sich in /etc/rdz/, sofern Sie bei der Anpassung und Übergabe des Jobs FEK.SFEKSAMP(FEKSETUP) keine andere Position angegeben haben. Weitere Details enthält der Abschnitt Anpassungskonfiguration. Sie können die Datei mit dem TSO-Befehl OEDIT bearbeiten.
Die folgende Beispieldatei rsed.envvars muss an Ihre Systemumgebung angepasst werden. Wenn eine US-Codepage verwendet wird, beginnen die Kommentarzeilen mit dem Nummernzeichen (#). Datenzeilen dürfen nur eine Anweisung und ihren zugeordneten Wert haben. Kommentare sind nicht in derselben Zeile zulässig. Zeilenfortsetzungen und Leerzeichen vor und nach dem Gleichheitszeichen (=) werden nicht unterstützt.
#============================================================= # (1) erforderliche Definitionen JAVA_HOME=/usr/lpp/java/J5.0 RSE_HOME=/usr/lpp/rdz _RSE_LOCKD_PORT=4036 _RSE_HOST_CODEPAGE=IBM-1047 TZ=EST5EDT LANG=C PATH=/bin:/usr/sbin _CEE_DMPTARG=/tmp STEPLIB=NONE #STEPLIB=$STEPLIB:CEE.SCEERUN:CEE.SCEERUN2:CBC.SCLBDLL _RSE_SAF_CLASS=/usr/include/java_classes/IRRRacf.jar _RSE_JAVAOPTS="" _RSE_JAVAOPTS="$_RSE_JAVAOPTS -Xms1m -Xmx256m" _RSE_JAVAOPTS="$_RSE_JAVAOPTS -Ddaemon.log=/var/rdz/logs" _RSE_JAVAOPTS="$_RSE_JAVAOPTS -Duser.log=/var/rdz/logs" _RSE_JAVAOPTS="$_RSE_JAVAOPTS -DDSTORE_LOG_DIRECTORY=" #_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Dmaximum.clients=60" #_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Dmaximum.threads=1000" #_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Dminimum.threadpool.process=1" #_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Dmaximum.threadpool.process=100" #_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Dipv6=true" #_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Dkeep.last.log=true" #_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Denable.standard.log=true" #_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Denable.port.of.entry=true" #_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Denable.certificate.mapping=false" #_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Denable.automount=true" #_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Denable.audit.log=true" #_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Daudit.cycle=30" #_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Daudit.retention.period=0" #_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Ddeny.nonzero.port=true" #_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Dsingle.logon=false" #_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Dprocess.cleanup.interval=0" #_RSE_JAVAOPTS="$_RSE_JAVAOPTS -DAPPLID=FEKAPPL" #_RSE_JAVAOPTS="$_RSE_JAVAOPTS -DDENY_PASSWORD_SAVE=true" #_RSE_JAVAOPTS="$_RSE_JAVAOPTS -DHIDE_ZOS_UNIX=true" #_RSE_JAVAOPTS="$_RSE_JAVAOPTS -DDSTORE_IDLE_SHUTDOWN_TIMEOUT=3600000" #_RSE_JAVAOPTS="$_RSE_JAVAOPTS -DDSTORE_TRACING_ON=true" #_RSE_JAVAOPTS="$_RSE_JAVAOPTS -DDSTORE_MEMLOGGING_ON=true" #_RSE_JAVAOPTS="$_RSE_JAVAOPTS -DTSO_SERVER=APPC" #============================================================= # (2) erforderliche Definitionen für TSO/ISPF-Client-Gateway _CMDSERV_BASE_HOME=/usr/lpp/ispf _CMDSERV_CONF_HOME=/etc/rdz _CMDSERV_WORK_HOME=/var/rdz #STEPLIB=$STEPLIB:ISP.SISPLOAD:ISP.SISPLPA:SYS1.LINKLIB _RSE_CMDSERV_OPTS="" #_RSE_CMDSERV_OPTS="$_RSE_CMDSERV_OPTS&ISPPROF=&SYSUID..ISPPROF" #============================================================= # (3) erforderliche Definitionen für SCLM Developer Toolkit _SCLMDT_CONF_HOME=/var/rdz/sclmdt #STEPLIB=$STEPLIB:FEK.SFEKAUTH:FEK.SFEKLOAD #_SCLMDT_TRANTABLE=FEK.#CUST.LSTRANS.FILE #ANT_HOME=/usr/lpp/Apache/Ant/apache-ant-1.7.1 #============================================================= # (4) optionale Definitionen #_RSE_PORTRANGE=8108-8118 #_BPXK_SETIBMOPT_TRANSPORT=TCPIP #_FEKFSCMD_TP_NAME_=FEKFRSRV #_FEKFSCMD_PARTNER_LU_=lu_name #GSK_CRL_SECURITY_LEVEL=HIGH #GSK_LDAP_SERVER=ldap_server_url #GSK_LDAP_PORT=ldap_server_port #GSK_LDAP_USER=ldap_userid #GSK_LDAP_PASSWORD=ldap_server_password #=============================================================
# (5) nur auf Anweisung des IBM Support Center ändern _CEE_RUNOPTS="ALL31(ON) HEAP(32M,32K,ANYWHERE,KEEP,,) TRAP(ON)" _BPX_SHAREAS=YES _BPX_SPAWN_SCRIPT=YES JAVA_PROPAGATE=NO RSE_LIB=$RSE_HOME/lib PATH=.:$JAVA_HOME/bin:$RSE_HOME/bin:$_CMDSERV_BASE_HOME/bin:$PATH LIBPATH=$JAVA_HOME/bin:$JAVA_HOME/bin/classic:$RSE_LIB:$RSE_LIB/icuc LIBPATH=.:/usr/lib:$LIBPATH CLASSPATH=$RSE_LIB:$RSE_LIB/dstore_core.jar:$RSE_LIB/clientserver.jar CLASSPATH=$CLASSPATH:$RSE_LIB/dstore_extra_server.jar CLASSPATH=$CLASSPATH:$RSE_LIB/zosserver.jar CLASSPATH=$CLASSPATH:$RSE_LIB/dstore_miners.jar CLASSPATH=$CLASSPATH:$RSE_LIB/universalminers.jar:$RSE_LIB/mvsminers.jar CLASSPATH=$CLASSPATH:$RSE_LIB/carma.jar:$RSE_LIB/luceneminer.jar CLASSPATH=$CLASSPATH:$RSE_LIB/mvsluceneminer.jar:$RSE_LIB/cdzminer.jar CLASSPATH=$CLASSPATH:$RSE_LIB/mvscdzminer.jar:$RSE_LIB/jesminers.jar CLASSPATH=$CLASSPATH:$RSE_LIB/FAMiner.jar CLASSPATH=$CLASSPATH:$RSE_LIB/mvsutil.jar:$RSE_LIB/jesutils.jar CLASSPATH=$CLASSPATH:$RSE_LIB/lucene-core-2.3.2.jar CLASSPATH=$CLASSPATH:$RSE_LIB/cdtparser.jar CLASSPATH=$CLASSPATH:$RSE_LIB/wdzBidi.jar:$RSE_LIB/fmiExtensions.jar CLASSPATH=$CLASSPATH:$_RSE_SAF_CLASS CLASSPATH=.:$CLASSPATH _RSE_CMDSERV_OPTS="&SESSION=SPAWN$_RSE_CMDSERV_OPTS" _RSE_JAVAOPTS="$_RSE_JAVAOPTS -DISPF_OPTS='$_RSE_CMDSERV_OPTS'" _RSE_JAVAOPTS="$_RSE_JAVAOPTS -DA_PLUGIN_PATH=$RSE_LIB" _RSE_JAVAOPTS="$_RSE_JAVAOPTS -Xbootclasspath/p:$RSE_LIB/bidiTools.jar" _RSE_JAVAOPTS="$_RSE_JAVAOPTS -Dfile.encoding=$_RSE_HOST_CODEPAGE" _RSE_JAVAOPTS="$_RSE_JAVAOPTS -Dconsole.encoding=$_RSE_HOST_CODEPAGE" _RSE_JAVAOPTS="$_RSE_JAVAOPTS -DDSTORE_SPIRIT_ON=true" _RSE_JAVAOPTS="$_RSE_JAVAOPTS -DSPIRIT_EXPIRY_TIME=6" _RSE_JAVAOPTS="$_RSE_JAVAOPTS -DSPIRIT_INTERVAL_TIME=6" _RSE_JAVAOPTS="$_RSE_JAVAOPTS -Dcom.ibm.cacheLocalHost=true" _RSE_JAVAOPTS="$_RSE_JAVAOPTS -Duser.home=$HOME" _RSE_JAVAOPTS="$_RSE_JAVAOPTS -Dclient.username=$RSE_USER_ID" _RSE_JAVAOPTS="$_RSE_JAVAOPTS -Dlow.heap.usage.ratio=15" _RSE_JAVAOPTS="$_RSE_JAVAOPTS -Dmaximum.heap.usage.ratio=40" _RSE_JAVAOPTS="$_RSE_JAVAOPTS -DDSTORE_KEEPALIVE_ENABLED=true" _RSE_JAVAOPTS="$_RSE_JAVAOPTS -DDSTORE_KEEPALIVE_RESPONSE_TIMEOUT=30000" _RSE_JAVAOPTS="$_RSE_JAVAOPTS -DDSTORE_IO_SOCKET_READ_TIMEOUT=90000" _RSE_JAVAOPTS="$_RSE_JAVAOPTS -DRSECOMM_LOGFILE_MAX=0" _RSE_JAVAOPTS="$_RSE_JAVAOPTS -Dlock.daemon.port=$_RSE_LOCKD_PORT" _RSE_JAVAOPTS="$_RSE_JAVAOPTS -Dlock.daemon.cleanup.interval=1440" _RSE_JAVAOPTS="$_RSE_JAVAOPTS -showversion" _RSE_SERVER_CLASS=org.eclipse.dstore.core.server.Server _RSE_DAEMON_CLASS=com.ibm.etools.zos.server.RseDaemon _RSE_POOL_SERVER_CLASS=com.ibm.etools.zos.server.ThreadPoolProcess _RSE_LOCKD_CLASS=com.ibm.ftt.rse.mvs.server.miners.MVSLockDaemon _RSE_SERVER_TIMEOUT=120000 _SCLMDT_BASE_HOME=$RSE_HOME _SCLMDT_WORK_HOME=$_CMDSERV_WORK_HOME CGI_DTWORK=$_SCLMDT_WORK_HOME #============================================================= # (6) zusätzliche Umgebungsvariablen
Folgende Definitionen sind erforderlich:
Weitere Informationen hierzu finden Sie in der Veröffentlichung UNIX System Services Command Reference (IBM Form SA22-7802).
Sie können das Kommentarzeichen vor einer oder mehreren der folgenden STEPLIB-Anweisungen entfernen und die Anweisungen anpassen, wenn Sie die Bereitstellung von (erforderlichen) Bibliotheken in LINKLIST/LPALIB umgehen möchten. Weitere Informationen zur Verwendung der nachfolgend aufgelisteten Bibliotheken enthält der Abschnitt PARMLIB-Änderungen.
STEPLIB=$STEPLIB:CEE.SCEERUN:CEE.SCEERUN2:CBC.SCLBDLL STEPLIB=$STEPLIB:ISP.SISPLOAD:ISP.SISPLPA:SYS1.LINKLIB STEPLIB=$STEPLIB:FEK.SFEKAUTH:FEK.SFEKLOAD
Developer for System z verwendet standardmäßig das TSO/ISPF-Client-Gateway von ISPF für TSO Commands Service. Wenn die folgende _RSE_JAVAOPTS-Option nicht auf Kommentar gesetzt ist, wird stattdessen eine APPC-Transaktion verwendet:
RSE_JAVAOPTS="$_RSE_JAVAOPTS -DTSO_SERVER=APPC"
Die folgenden Definitionen sind erforderlich, wenn für TSO Commands Service, SCLM Developer Toolkit oder CARMA das TSO/ISPF-Client-Gateway von ISPF verwendet wird.
Anmerkungen:
Wenn SCLM Developer Toolkit verwendet wird, sind die folgenden Definitionen erforderlich.
Folgende Definitionen sind optional. Wenn Sie diese Definitionen übergehen, werden Standardwerte verwendet.
Der Hostname kann eine TCP/IP-Adresse oder eine URL sein. Jeder Hostname kann eine optionale Portnummer enthalten, die durch einen Doppelpunkt (:) von diesem getrennt ist.
Die folgenden Definitionen sind erforderlich und sollten nur auf Anweisung des IBM Support Center geändert werden:
Dieser Schritt gehört zur Anpassung der Datei rsed.envvars, die die Ports angibt, über die der RSE-Server mit dem Client kommunizieren kann. Dieser Portbereich steht nicht in Verbindung mit dem Port des RSE-Dämons.
Nachfolgend sehen Sie eine kurze Beschreibung des RSE-Verbindungsprozesses, die Ihnen helfen soll, die Portverwendung zu verstehen.
Wenn Sie den Portbereich für die Kommunikation des Clients mit z/OS angeben möchten, entfernen Sie das Kommentarzeichen aus der folgenden Zeile in rsed.envvars und passen Sie die Zeile an:
#_RSE_PORTRANGE=8108-8118
PORTRANGE hat folgendes Format: _RSE_PORTRANGE=min-max. (Die Angabe max gilt nicht einschließlich. Die Einstellung _RSE_PORTRANGE=8108-8118 bedeutet beispielsweise, dass die Portnummern von 8108 bis einschließlich 8117 verwendet werden können.) Die vom RSE-Server verwendete Portnummer wird wie folgt ermittelt:
Mit den verschiedenen _RSE_*OPTS-Anweisungen bietet die Datei rsed.envvars die Möglichkeit, zusätzliche Parameter für Java beim Start des RSE-Prozesses anzugeben. Die in rsed.envvars enthaltenen Beispieloptionen können durch Entfernen des Kommentarzeichens aktiviert werden.
_RSE_JAVAOPTS definiert RSE-spezifische Java-Optionen und Standard-Java-Optionen.
Die folgenden Anweisungen sind standardmäßig auf Kommentar gesetzt.
Mit den verschiedenen _RSE_*OPTS-Anweisungen bietet die Datei rsed.envvars die Möglichkeit, zusätzliche Parameter für Java beim Start des RSE-Prozesses anzugeben. Die in rsed.envvars enthaltenen Beispieloptionen können durch Entfernen des Kommentarzeichens aktiviert werden.
Die _RSE_CMDSERV_OPTS-Anweisungen sind RSE-spezifische Java-Optionen, die nur wirksam sind, wenn für Developer for System z das TSO/ISPF-Client-Gateway von ISPF verwendet wird. (Dies ist die Standardeinstellung.)
Im Dateinamen können die folgenden Variablen verwendet werden:
Das TSO/ISPF-Client-Gateway von ISPF erstellt ausgehend von den Definitionen in ISPF.conf eine gültige Umgebung für die Ausführung von TSO- und ISPF-Batchbefehlen. Developer for System z führt in dieser Umgebung einige MVS-basierte Services aus. Dazu gehören TSO Commands Service, der Service von SCLM Developer Toolkit und eine alternative CARMA-Startmethode.
Die Datei ISPF.conf befindet sich in /etc/rdz/, sofern Sie bei der Anpassung und Übergabe des Jobs FEK.SFEKSAMP(FEKSETUP) keine andere Position angegeben haben. Weitere Details enthält der Abschnitt Anpassungskonfiguration. Sie können die Datei mit dem TSO-Befehl OEDIT bearbeiten.
Wenn eine US-Codepage verwendet wird, beginnen Kommentarzeilen mit einem Stern (*). Datenzeilen dürfen nur eine Anweisung und ihren zugeordneten Wert haben. Kommentare sind nicht in derselben Zeile zulässig. Zeilenfortsetzungen werden nicht unterstützt. Wenn Sie Dateinamen verketten, fügen Sie die Namen in derselben Zeile hinzu und trennen Sie die einzelnen Namen jeweils durch ein Komma (,).
Sie müssen nicht nur die korrekten Namen für die ISPF-Dateien angeben, sondern auch den Dateinamen für TSO Commands Service, FEK.SFEKPROC, zur Anweisung SYSPROC oder SYSEXEC hinzufügen. Vergleichen Sie hierzu das folgende Beispiel.
* ERFORDERLICH:
sysproc=ISP.SISPCLIB,FEK.SFEKPROC
ispmlib=ISP.SISPMENU
isptlib=ISP.SISPTENU
ispplib=ISP.SISPPENU
ispslib=ISP.SISPSLIB
ispllib=ISP.SISPLOAD
* OPTIONAL:
*allocjob = FEK.#CUST.CNTL(CRAISPRX)
*ISPF_timeout = 900
Beispiel:
ISPTRACE=nullfile
Die oben angegebenen Anpassungsschritte beziehen sich auf eine Basiskonfiguration von Developer for System z. Informationen zu den Voraussetzungen für die Anpassung optionaler Komponenten finden Sie in den Kapiteln zu diesen Komponenten:
Eine Beschreibung der verschiedenen Installationsprüfprogramme (IVPs) finden Sie unter Installationsprüfung, da einige IVPs für optionale Komponenten gelten.
Common Access Repository Manager (CARMA) ist eine Produktivitätshilfe für Entwickler, die RAM (Repository Access Managers) erstellen. Ein RAM ist eine Anwendungsprogrammierschnittstelle (API) für z/OS-basierte SCMs (Software Configuration Managers).
Vom Benutzer geschriebene Anwendungen können einen CARMA-Server starten, der die RAM lädt und eine Standardschnittstelle für den Zugriff auf den SCM bereitstellt.
Developer for System z unterstützt mehrere Startmethoden für einen CARMA-Server, die jeweils spezielle Vor- und Nachteile haben.
Für diese Anpassungstask, für die die folgenden Ressourcen oder speziellen Anpassungstasks erforderlich sind, benötigen Sie die Unterstützung eines Sicherheitsadministrators und eines TCP/IP-Administrators:
Vor der Verwendung von CARMA an Ihrem Standort müssen Sie die folgenden Tasks ausführen. Sofern nicht anders angegeben, sind alle Tasks obligatorisch.
Die folgenden CARMA-Komponenten müssen unabhängig von der gewählten Startmethode angepasst werden. Die unten angegebenen Beispielmember befinden sich in FEK.#CUST.JCL, sofern Sie bei der Anpassung und Übergabe des Jobs FEK.SFEKSAMP(FEKSETUP) keine andere Position angegeben haben. Weitere Details hierzu enthält der Abschnitt Anpassungskonfiguration.
Developer for System z Version 7.6.1 unterstützt ein neues Datenstrukturlayout für die VSAM-Datei für angepasste CARMA-Informationen (CRASTRS), um Längenbeschränkungen für Nachrichten zu vermeiden.
Vor Developer for System z Version 7.6.1 waren Zeichenfolgen, die in VSAM-Dateien für angepasste CARMA-Informationen definiert werden, auf bestimmte vordefinierte Längen begrenzt. Diese Begrenzung zwingt RAM-Entwickler, beschreibende Zeichenfolgen zu kürzen oder clientseitige Plug-ins zu verwenden, um Zeichenfolgen in vollständiger Länge anzuzeigen.
Developer for System z Version 7.6.1 unterstützt ein neues Datenstrukturlayout mit variabler Länge für die VSAM-Datei für angepasste CARMA-Informationen (CRASTRS), bei dem Zeichenfolgen durch ein Begrenzungszeichen getrennt werden, anstatt einer festen Länge zu unterliegen.
Passen Sie die JCL FEK.SFEKSAMP(CRA#VS2) an und übergeben Sie sie, um Ihre vorhandene VSAM-Datei für angepasste CARMA-Informationen mit fester Länge (CRASTRS) in eine Datei mit neuem Format mit variabler Länge umzuwandeln.
Der CARMA-Server stellt für andere hostbasierte Produkte eine Standard-API für den Zugriff auf Software Configuration Manager (SCM) bereit. CARMA bietet jedoch keine Methoden für die direkte Kommunikation mit einem Client-PC an. Aus diesem Grund ist CARMA auf andere Produkte wie den RSE-Server angewiesen. Der RSE-Server verwendet die Einstellungen in CRASRV.properties zum Starten eines CARMA-Servers und für den Zugriff auf diesen Server.
Die Datei CRASRV.properties befindet sich in /etc/rdz/, sofern Sie bei der Anpassung und Übergabe des Jobs FEK.SFEKSAMP(FEKSETUP) keine andere Position angegeben haben. Weitere Details enthält der Abschnitt Anpassungskonfiguration. Sie können die Datei mit dem TSO-Befehl OEDIT bearbeiten.
# CRASRV.properties - CARMA-Konfigurationsoptionen # port.start=5227 port.range=100 startup.script.name=/usr/lpp/rdz/bin/carma.startup.rex clist.dsname='FEK.#CUST.CNTL(CRASUBMT)' crastart.stub=/usr/lpp/rdz/bin/CRASTART crastart.configuration.file=/etc/rdz/crastart.conf crastart.syslog=Partial crastart.timeout=420 #crastart.steplib=FEK.SFEKLPA #crastart.tasklib=TASKLIB
Die Standardeinstellung ist 'FEK.#CUST.CNTL(CRASUBMT)'. Diese CLIST startet mit der Batchübergabe einen CARMA-Server, wenn eine Verbindung geöffnet wird.
A (All) | Alle Trace-Informationen werden im SYSLOG ausgegeben. |
P (Partial) | Im SYSLOG werden nur Informationen zum Aufbau und zur Trennung von Verbindungen sowie Fehlerinformationen ausgegeben. |
Alle anderen Werte | Im SYSLOG werden nur Fehlerbedingungen ausgegeben. |
Diese Anweisung wird nur verwendet, wenn für die Anweisung clist.dsname der Wert *CRASTART angegeben ist.
In diesem Abschnitt ist die Konfiguration der Standardmethode von Developer for System z für das Starten eines CARMA-Servers beschrieben. Wenn Sie eine andere Startmethode verwenden, können Sie diesen Anpassungsschritt auslassen.
Developer for System z verwendet standardmäßig eine Batchübergabemethode für den CARMA-Serverstart, die nicht vom TSO/ISPF-Client-Gateway abhängt und bei der sich das Modul CRASTART nicht im LPA befinden muss. Die Methode übergibt den CARMA-Server als einen Batch-Job mit langer Laufzeit in Ihrem JES.
Der RSE-Server verwendet die Einstellungen in /etc/rdz/CRASRV.properties zum Starten eines CARMA-Servers und für den Zugriff auf diesen Server. Lesen Sie hierzu die Informationen unter RSE-Schnittstelle zu CARMA. Sie können die Datei mit dem TSO-Befehl OEDIT bearbeiten. RSE muss neu gestartet werden, damit diese Änderungen wirksam werden.
Setzen Sie den Wert der Anweisung clist.dsname wie im folgenden Beispiel auf den Datei- und Membernamen der CLIST CRASUBMT für den CARMA-Serverstart. Weitere Informationen zu den verschiedenen Anweisungen erhalten Sie unter RSE-Schnittstelle zu CARMA.
port.start=5227 port.range=100 startup.script.name=/usr/lpp/rdz/bin/carma.startup.rex clist.dsname='FEK.#CUST.CNTL(CRASUBMT)'
Passen Sie die CLIST CRASUBMT wie im folgenden Codebeispiel an. Anpassungsanweisungen finden Sie in der in CRASUBMT enthaltenen Dokumentation. Die CLIST CRASUBMT übergibt einen CARMA-Server.
CRASUBMT befindet sich in FEK.#CUST.CNTL, sofern Sie bei der Anpassung und Übergabe des Jobs FEK.SFEKSAMP(FEKSETUP) keine andere Position angegeben haben. Weitere Details hierzu enthält der Abschnitt Anpassungskonfiguration.
PROC 1 PORT TIMEOUT(420) SUBMIT * END($$) //CRA&PORT JOB CLASS=A,MSGCLASS=A,MSGLEVEL=(1,1) //RUN EXEC PGM=IKJEFT01,DYNAMNBR=25,REGION=1024K,TIME=NOLIMIT //STEPLIB DD DISP=SHR,DSN=FEK.SFEKLOAD //* DD DISP=SHR,DSN=FEK.#CUST.LOAD //CRADEF DD DISP=SHR,DSN=FEK.#CUST.CRADEF //CRAMSG DD DISP=SHR,DSN=FEK.#CUST.CRAMSG //CRASTRS DD DISP=SHR,DSN=FEK.#CUST.CRASTRS //*CRARAM1 DD DISP=SHR,DSN=FEK.#CUST.CRARAM1 //* //ISPPROF DD DISP=(NEW,DELETE,DELETE), // SPACE=(TRK,(1,1,5)),LRECL=80,RECFM=FB,UNIT=SYSALLDA //ISPMLIB DD DISP=SHR,DSN=ISP.SISPMENU //ISPPLIB DD DISP=SHR,DSN=ISP.SISPPENU //ISPSLIB DD DISP=SHR,DSN=ISP.SISPSENU //ISPTLIB DD DISP=SHR,DSN=ISP.SISPTENU //ISPEXEC DD DISP=SHR,DSN=ISP.SISPEXEC //SYSPROC DD DISP=SHR,DSN=ISP.SISPCLIB //* //CARMALOG DD SYSOUT=* //SYSTSPRT DD SYSOUT=* //SYSTSIN DD * ISPSTART PGM(CRASERV) PARM(&PORT &TIMEOUT) //* $$ EXIT CODE(0)
In diesem Abschnitt ist die Konfiguration einer alternativen Methode von Developer for System z für das Starten eines CARMA-Servers beschrieben. Wenn Sie eine andere Startmethode verwenden, können Sie diesen Anpassungsschritt auslassen.
Developer for System z unterstützt eine alternative Methode für den CARMA-Serverstart, die keinen JES-Initiator verwendet, um einen Server-Job zu übergeben. Diese Methode startet den CARMA-Server mit CRASTART als Subtask innerhalb von RSE und ist mit dem TSO/ISPF-Client-Gateway-Service vergleichbar.
Der RSE-Server verwendet die Einstellungen in /etc/rdz/CRASRV.properties zum Starten eines CARMA-Servers und für den Zugriff auf diesen Server. Lesen Sie hierzu die Informationen unter RSE-Schnittstelle zu CARMA. Sie können die Datei mit dem TSO-Befehl OEDIT bearbeiten. RSE muss neu gestartet werden, damit diese Änderungen wirksam werden.
Setzen Sie den Wert der Anweisung clist.dsname auf *CRASTART und geben Sie für die Anweisungen crastart.* die richtigen Werte an. Vergleichen Sie dazu das folgende Beispiel. Weitere Informationen zu den verschiedenen Anweisungen erhalten Sie unter RSE-Schnittstelle zu CARMA.
port.start=5227 port.range=100 startup.script.name=/usr/lpp/rdz/bin/carma.startup.rex clist.dsname=*CRASTART crastart.stub=/usr/lpp/rdz/bin/CRASTART crastart.configuration.file=/etc/rdz/crastart.conf crastart.syslog=Partial crastart.timeout=420 #crastart.steplib=FEK.SFEKLPA #crastart.tasklib=TASKLIB
Während dieses Anpassungsschrittes sollten Sie einen Ausdruck des angepassten Members SCRASUBMT als Referenz zur Hand haben. (Lesen Sie hierzu den Abschnitt CARMA-Serverstart mit Batchübergabe.) Auch wenn Sie das Member nicht angepasst haben, kann der Ausdruck von Vorteil sein.
CRASTART erstellt ausgehend von den Definitionen in crastart.conf eine gültige Umgebung für die Ausführung von TSO- und ISPF-Batchbefehlen. Developer for System z kann in dieser Umgebung den CARMA-Server CRASERV ausführen.
Die Datei crastart.conf befindet sich in /etc/rdz/, sofern Sie bei der Anpassung und Übergabe des Jobs FEK.SFEKSAMP(FEKSETUP) keine andere Position angegeben haben. Weitere Details enthält der Abschnitt Anpassungskonfiguration. Sie können die Datei mit dem TSO-Befehl OEDIT bearbeiten.
Die folgenden Anpassungsschritte sind erforderlich, um die Konfigurationsdatei wie im nachstehenden Beispiel anzupassen.
* crastart.conf - CARMA-Zuordnungsoptionen TASKLIB = FEK.SFEKLOAD CRADEF = FEK.#CUST.CRADEF CRAMSG = FEK.#CUST.CRAMSG CRASTRS = FEK.#CUST.CRASTRS *CRARAM1 = FEK.#CUST.CRARAM1 * CARMALOG = SYSOUT(H) SYSTSPRT = SYSOUT(H) SYSTSIN = DUMMY -COMMAND=ALLOC FI(SCRATCH) NEW DELETE DSORG(PS) RECFM(F,B) LRECL(80) UNIT(VIO) * PROGRAM=IKJEFT01 CRASERV &CRAPRM1. &CRAPRM2.
In der Konfigurationsdatei können die folgenden Variablen verwendet werden:
&CRAUSER. | Anmeldebenutzer-ID des Clients |
&CRADATE. | Aktuelles Datum im (siebenstelligen julianischen) Format Djjjjddd |
&CRATIME. | Aktuelle Zeit im Format Thhmmss (Stunden, Minuten und Sekunden) |
&CRAPRM3. bis &CRAPRM9. |
Zusätzliche Variablen mit benutzerdefinierten Werten. Wenn Sie diese Variablen verwenden, muss die von startup.script.name in der Datei CRASRV.properties referenzierte CARMA-Start-REXX angepasst werden. Wenn Sie diese Variablen verwenden, sollten Sie eine Kopie des Standardstarts REXX (/usr/lpp/rdz/bin/carma.startup.rex) anpassen und mit startup.script.name auf diese Kopie verweisen. Damit verhindern Sie den Verlust Ihrer Arbeitsergebnisse bei Wartungsaktualisierungen für den Standard-REXX. |
Systemsymbol | Jedes in SYS1.PARMLIB(IEASYMxx) definierte Symbol |
-<DD> | Ein bereits definierter DD-Name mit einem vorangestellten Bindestrich (-) fungiert in JCL als Rückbezug auf *.ddname. Die ursprüngliche DD muss mit der Anweisung -COMMAND zugeordnet werden. |
In diesem Abschnitt ist die Konfiguration einer alternativen Methode von Developer for System z für das Starten eines CARMA-Servers beschrieben. Wenn Sie eine andere Startmethode verwenden, können Sie diesen Anpassungsschritt auslassen.
Developer for System z unterstützt eine alternative Methode für den CARMA-Serverstart, die keinen JES-Initiator verwendet, um einen Server-Job zu übergeben, und bei der sich das Modul CRASTART nicht im LPA befinden muss. Die Methode nutzt das TSO/ISPF-Client-Gateway von ISPF und ist mit der Standardmethode für den Zugriff auf TSO Commands Service vergleichbar.
Der RSE-Server verwendet die Einstellungen in /etc/rdz/CRASRV.properties zum Starten eines CARMA-Servers und für den Zugriff auf diesen Server. Lesen Sie hierzu die Informationen unter RSE-Schnittstelle zu CARMA. Sie können die Datei mit dem TSO-Befehl OEDIT bearbeiten. RSE muss neu gestartet werden, damit diese Änderungen wirksam werden.
Setzen Sie den Wert der Anweisung clist.dsname wie im folgenden Beispiel auf *ISPF. Weitere Informationen zu den verschiedenen Anweisungen erhalten Sie unter RSE-Schnittstelle zu CARMA.
port.start=5227 port.range=100 startup.script.name=/usr/lpp/rdz/bin/carma.startup.rex clist.dsname=*ISPF
Während dieses Anpassungsschrittes sollten Sie einen Ausdruck des angepassten Members SCRASUBMT als Referenz zur Hand haben. (Lesen Sie hierzu den Abschnitt CARMA-Serverstart mit Batchübergabe.) Auch wenn Sie das Member nicht angepasst haben, kann der Ausdruck von Vorteil sein.
Das TSO/ISPF-Client-Gateway von ISPF erstellt ausgehend von den Definitionen in ISPF.conf eine gültige Umgebung für die Ausführung von TSO- und ISPF-Batchbefehlen. Developer for System z führt in dieser Umgebung den CARMA-Server aus.
Die Datei ISPF.conf befindet sich in /etc/rdz/, sofern Sie bei der Anpassung und Übergabe des Jobs FEK.SFEKSAMP(FEKSETUP) keine andere Position angegeben haben. Weitere Details enthält der Abschnitt Anpassungskonfiguration. Sie können die Datei mit dem TSO-Befehl OEDIT bearbeiten.
Die folgenden Anpassungsschritte sind erforderlich, um die Konfigurationsdatei wie im nachstehenden Beispiel anzupassen.
sysproc=ISP.SISPCLIB,FEK.SFEKPROC ispllib=FEK.SFEKLOAD ispmlib=ISP.SISPMENU isptlib=ISP.SISPTENU ispplib=ISP.SISPPENU ispslib=ISP.SISPSLIB CRADEF =FEK.#CUST.CRADEF CRAMSG =FEK.#CUST.CRAMSG CRASTRS=FEK.#CUST.CRASTRS *CRARAM1=FEK.#CUST.CRARAM1 allocjob=FEK.#CUST.CNTL(CRAISPRX)
Die DD-Anweisung CARMALOG verweist standardmäßig auf den Wert SYSOUT=*, der in ISPF.conf nicht zugeordnet werden kann. Eine direkte Zuordnung der DD-Anweisung zu einer Datei ist auch nicht möglich, da alle Benutzer von Developer for System z dieselbe Datei ISPF.conf verwenden.
Sie können jedoch ausgehend von der aktiven Benutzer-ID eine Datei anlegen. Verwenden Sie dazu eine Zuordnungs-Exec wie in TSO-Umgebung anpassen im Abschnitt Erweitert - Zuordnungs-Exec verwenden beschrieben. Im Beispielmember CRAISPRX der Datei FEK.#CUST.CNTL sehen Sie ein Beispiel für die Zuordnung der DD-Anweisung zum Dateinamen TSOPREFIX'.'USERID'.CRA.'TIMESTAMP'.CARMALOG'.
Repository Access Managers (RAM) sind vom Benutzer geschriebene APIs für die Anbindung an z/OS Software Configuration Manager (SCM). Führen Sie für die Beispiel-RAM, die Sie aktivieren möchten, die Anweisungen in den folgenden Abschnitten aus.
Weitere Informationen zu den bereitgestellten Beispiel-RAM und zum bereitgestellten Beispielquellcode finden Sie im Rational Developer for System z Common Access Repository Manager Developer's Guide (IBM Form SC23-7660).
Die unten angegebenen Beispielmember befinden sich in FEK.#CUST.JCL, sofern Sie bei der Anpassung und Übergabe des Jobs FEK.SFEKSAMP(FEKSETUP) keine andere Position angegeben haben. Weitere Details hierzu enthält der Abschnitt Anpassungskonfiguration.
Der PDS-RAM gibt eine Dateiliste ähnlich zu MVS-Dateien -> Meine Dateien in der Ansicht Ferne Systeme zurück. Der PDS-RAM verwendet standardmäßig die RAM-ID '0'.
Der SCLM-RAM gibt einen Basiseintrag in SCLM (Software Configuration Manager von ISPF) zurück. Der SCLM-RAM verwendet standardmäßig die RAM-ID '1'.
Der Skeleton-RAM gibt ein Skeleton-Gerüst zurück, das für die Entwicklung Ihrer eigenen RAMs verwendet werden kann. Der Skeleton-RAM verwendet standardmäßig die RAM-ID '3'.
Die Schnittstelle für CA Endevor® Software Configuration Manager in IBM® Rational® Developer for System z ermöglicht Clients mit Developer for System z direkten Zugriff auf CA Endevor® SCM. In diesem Handbuch wird die Schnittstelle für CA Endevor® in IBM® Rational® Developer for System z mit 'CA Endevor® SCM-RAM' (Repository Access Manager) abgekürzt.
Im Gegensatz zu den Beispiel-RAMs, die in dieser Veröffentlichung dokumentiert werden, ist CA Endevor® SCM RAM ein Produktions-RAM. Sie sollten nicht beide RAM-Typen in derselben Konfiguration aktivieren.
Achtung: Die zur Verfügung gestellten Konfigurationsjobs für den CA Endevor® SCM-RAM ersetzen die aktive CARMA-Konfiguration durch eine Konfiguration, die nur den CA Endevor® SCM-RAM enthält. |
Für diese Anpassungstask, für die die folgenden Ressourcen oder speziellen Anpassungstasks erforderlich sind, benötigen Sie die Unterstützung eines Sicherheitsadministrators und eines TCP/IP-Administrators:
Vor der Verwendung des CA Endevor® SCM-RAMs an Ihrem Standort müssen Sie die folgenden Tasks ausführen. Sofern nicht anders angegeben, sind alle Tasks obligatorisch.
Die folgenden CARMA-Komponenten müssen unabhängig von der gewählten Startmethode angepasst werden. Die unten angegebenen Beispielmember befinden sich in FEK.#CUST.JCL, sofern Sie bei der Anpassung und Übergabe des Jobs FEK.SFEKSAMP(FEKSETUP) keine andere Position angegeben haben. Weitere Details hierzu enthält der Abschnitt Anpassungskonfiguration.
Führen Sie diesen Schritt nicht aus, wenn Sie die Methode 'CRASTART' zum Starten des CARMA-Servers mit dem CA Endevor® SCM-RAM verwenden.
Developer for System z kann die Batchübergabemethode für den CARMA-Serverstart verwenden, um den CA Endevor® SCM-RAM zu starten. Die Methode übergibt den CARMA-Server als einen Batch-Job mit langer Laufzeit in Ihrem JES.
Weitere Informationen zur Startmethode mit Batchübergabe erhalten Sie unter CARMA-Serverstart mit Batchübergabe.
Der RSE-Server verwendet die Einstellungen in /etc/rdz/CRASRV.properties zum Starten eines CARMA-Servers und für den Zugriff auf diesen Server. Lesen Sie hierzu die Informationen unter RSE-Schnittstelle zu CARMA. Sie können die Datei mit dem TSO-Befehl OEDIT bearbeiten. RSE muss neu gestartet werden, damit diese Änderungen wirksam werden.
Setzen Sie den Wert für die Anweisung clist.dsname wie im folgenden Beispiel auf den Datei- und Membernamen der CLIST CRASUBCA für den CARMA-Serverstart. Weitere Informationen zu den verschiedenen Anweisungen erhalten Sie unter RSE-Schnittstelle zu CARMA.
port.start=5227 port.range=100 startup.script.name=/usr/lpp/rdz/bin/carma.startup.rex clist.dsname='FEK.#CUST.CNTL(CRASUBCA)'
Passen Sie die CLIST CRASUBCA wie im folgenden Codebeispiel an. Anpassungsanweisungen finden Sie in der in CRASUBCA enthaltenen Dokumentation. Die CLIST CRASUBCA übergibt einen CARMA-Server für CA Endevor® SCM.
CRASUBCA befindet sich in FEK.#CUST.CNTL, sofern Sie bei der Anpassung und Übergabe des Jobs FEK.SFEKSAMP(FEKSETUP) keine andere Position angegeben haben. Weitere Details hierzu enthält der Abschnitt Anpassungskonfiguration.
PROC 1 PORT TIMEOUT(420) SUBMIT * END($$) //CRA&PORT JOB CLASS=A,MSGCLASS=A,MSGLEVEL=(1,1) //RUN EXEC PGM=IKJEFT01,DYNAMNBR=125,REGION=0M,TIME=NOLIMIT, // PARM='%CRANDVRA NDVRC1 PGM(CRASERV) PARM(&PORT &TIMEOUT)' //STEPLIB DD DISP=SHR,DSN=FEK.SFEKLOAD // DD DISP=SHR,DSN=CA.NDVR.AUTHLIB // DD DISP=SHR,DSN=CA.NDVRU.AUTHLIB //CRADEF DD DISP=SHR,DSN=FEK.#CUST.CRADEF //CRAMSG DD DISP=SHR,DSN=FEK.#CUST.CRAMSG //CRASTRS DD DISP=SHR,DSN=FEK.#CUST.CRASTRS //* //SYSPROC DD DISP=SHR,DSN=ISP.SISPCLIB // DD DISP=SHR,DSN=FEK.SFEKPROC //ISPEXEC DD DISP=SHR,DSN=ISP.SISPEXEC //ISPMLIB DD DISP=SHR,DSN=ISP.SISPMENU //ISPPLIB DD DISP=SHR,DSN=ISP.SISPPENU //ISPSLIB DD DISP=SHR,DSN=ISP.SISPSENU //ISPTLIB DD DISP=SHR,DSN=ISP.SISPTENU //ISPCTL0 DD DISP=(NEW,DELETE,DELETE),UNIT=SYSALLDA, // SPACE=(TRK,(1,1)),LRECL=80,RECFM=FB //ISPCTL1 DD DISP=(NEW,DELETE,DELETE),UNIT=SYSALLDA, // SPACE=(TRK,(1,1)),LRECL=80,RECFM=FB //ISPPROF DD DISP=(NEW,DELETE,DELETE),UNIT=SYSALLDA, // SPACE=(TRK,(1,1,5)),LRECL=80,RECFM=FB //* //CARMALOG DD SYSOUT=* //SYSPRINT DD SYSOUT=* //SYSTSPRT DD SYSOUT=* //SYSTSIN DD DUMMY //* //CONLIB DD DISP=SHR,DSN=CA.NDVR.CONLIB //JCLOUT DD SYSOUT=(A,INTRDR),DCB=(LRECL=80,RECFM=F,BLKSIZE=80) //EXT1ELM DD DISP=(NEW,DELETE),UNIT=SYSALLDA, // RECFM=VB,LRECL=4096,BLKSIZE=27998,SPACE=(TRK,(5,5)) //EXT1DEP DD DISP=(NEW,DELETE),UNIT=SYSALLDA, // RECFM=VB,LRECL=4096,BLKSIZE=27998,SPACE=(TRK,(5,5)) //MSG3FILE DD DISP=(NEW,DELETE),UNIT=SYSALLDA, // RECFM=FB,LRECL=133,BLKSIZE=27930,SPACE=(TRK,(5,5)) //C1MSGS1 DD DISP=(NEW,DELETE),UNIT=SYSALLDA, // RECFM=FB,LRECL=133,BLKSIZE=27930,SPACE=(TRK,(5,5)) //C1EXMSGS DD DISP=(NEW,DELETE),UNIT=SYSALLDA, // RECFM=FB,LRECL=133,BLKSIZE=27930,SPACE=(TRK,(5,5)) //TYPEMAP DD DISP=SHR,DSN=FEK.#CUST.PARMLIB(CRATMAP) //SHOWVIEW DD DISP=SHR,DSN=FEK.#CUST.PARMLIB(CRASHOW) $$ EXIT CODE(0)
Führen Sie diesen Schritt nicht aus, wenn Sie die Batchübergabemethode zum Starten des CARMA-Servers mit dem CA Endevor® SCM-RAM verwenden.
Developer for System z kann die Methode 'CRASTART' für den CARMA-Serverstart verwenden, um den CA Endevor® SCM-RAM zu starten. Diese Methode startet den CARMA-Server mit CRASTART als Subtask innerhalb von RSE.
Weitere Informationen zur Startmethode mit CRASTART erhalten Sie unter Alternativer CARMA-Serverstart mit CRASTART (optional).
Der RSE-Server verwendet die Einstellungen in /etc/rdz/CRASRV.properties zum Starten eines CARMA-Servers und für den Zugriff auf diesen Server. Lesen Sie hierzu die Informationen unter RSE-Schnittstelle zu CARMA. Sie können die Datei mit dem TSO-Befehl OEDIT bearbeiten. RSE muss neu gestartet werden, damit diese Änderungen wirksam werden.
Setzen Sie den Wert der Anweisung clist.dsname auf *CRASTART und geben Sie für die Anweisungen crastart.* die richtigen Werte an. Vergleichen Sie dazu das folgende Beispiel. Weitere Informationen zu den verschiedenen Anweisungen erhalten Sie unter RSE-Schnittstelle zu CARMA.
port.start=5227 port.range=100 startup.script.name=/usr/lpp/rdz/bin/carma.startup.rex clist.dsname=*CRASTART crastart.stub=/usr/lpp/rdz/bin/CRASTART crastart.configuration.file=/etc/rdz/crastart.endevor.conf crastart.syslog=Partial crastart.timeout=420 #crastart.steplib=FEK.SFEKLPA #crastart.tasklib=TASKLIB
CRASTART erstellt ausgehend von den Definitionen in crastart.endevor.conf eine gültige (TSO/ISPF-)Umgebung, um CA Endevor® SCM aufzurufen. Developer for System z führt in dieser Umgebung den CA Endevor ® SCM-RAM aus.
crastart.endevor.conf befindet sich in /etc/rdz/, sofern Sie bei der Anpassung und Übergabe des Jobs FEK.SFEKSAMP(FEKSETUP) keine andere Position angegeben haben. Weitere Details enthält der Abschnitt Anpassungskonfiguration. Sie können die Datei mit dem TSO-Befehl OEDIT bearbeiten.
TASKLIB = FEK.SFEKLOAD,CA.NDVR.AUTHLIB,CA.NDVRU.AUTHLIB CRADEF = FEK.#CUST.CRADEF CRAMSG = FEK.#CUST.CRAMSG CRASTRS = FEK.#CUST.CRASTRS SYSPROC = ISP.SISPCLIB,FEK.SFEKPROC SYSEXEC = ISP.SISPEXEC ISPMLIB = ISP.SISPMENU ISPPLIB = ISP.SISPPENU ISPSLIB = ISP.SISPSENU -COMMAND=ALLOC FI(ISPCTL0) NEW DELETE DSORG(PS) RECFM(F,B) LRECL(80) BLKSIZE(6160) SPACE(2,2) TRACKS UNIT(SYSALLDA) -COMMAND=ALLOC FI(ISPCTL1) NEW DELETE DSORG(PS) RECFM(F,B) LRECL(80) BLKSIZE(6160) SPACE(2,2) TRACKS UNIT(SYSALLDA) -COMMAND=ALLOC FI(ISPPROF) NEW DELETE DSORG(PO) DIR(5) RECFM(F,B) LRECL(80) BLKSIZE(6160) SPACE(2,2) TRACKS UNIT(SYSALLDA) ISPTLIB = -ISPPROF,ISP.SISPTENU ISPTABL = -ISPPROF CARMALOG = SYSOUT(H) SYSPRINT= SYSOUT(H) SYSTSPRT = SYSOUT(H) SYSTSIN = DUMMY TYPEMAP = FEK.#CUST.PARMLIB(CRATMAP) SHOWVIEW= FEK.#CUST.PARMLIB(CRASHOW) CONLIB = CA.NDVR.CONLIB -COMMAND=ALLOC FI(JCLOUT) SYSOUT(A) WRITER(INTRDR) RECFM(F) LRECL(80) BLKSIZE(80) -COMMAND=ALLOC FI(EXT1ELM) NEW DELETE DSORG(PS) RECFM(V,B) LRECL(4096) BLKSIZE(27998) SPACE(5,5) TRACKS UNIT(SYSALLDA) -COMMAND=ALLOC FI(EXT1DEP) NEW DELETE DSORG(PS) RECFM(V,B) LRECL(4096) BLKSIZE(27998) SPACE(5,5) TRACKS UNIT(SYSALLDA) -COMMAND=ALLOC FI(MSG3FILE) NEW DELETE DSORG(PS) RECFM(F,B) LRECL(133) BLKSIZE(27930) SPACE(5,5) TRACKS UNIT(SYSALLDA) -COMMAND=ALLOC FI(C1EXMSGS) NEW DELETE DSORG(PS) RECFM(F,B) LRECL(133) BLKSIZE(27930) SPACE(5,5) TRACKS UNIT(SYSALLDA) -COMMAND=ALLOC FI(C1MSGS1) NEW DELETE DSORG(PS) RECFM(F,B) LRECL(133) BLKSIZE(27930) SPACE(5,5) TRACKS UNIT(SYSALLDA) PROGRAM=IKJEFT01 %CRANDVRA NDVRC1 PGM(CRASERV) PARM(&CRAPRM1. &CRAPRM2.)
Die Startmethoden mit Batchübergabe und mit CRASTART rufen beide die REXX-Exec CRANDVRA auf, um benutzerspezifische Dateien zuzuordnen, die vom CA Endevor® SCM-RAM verwendet werden.
DD-Anweisung | Dateiname | Typ |
---|---|---|
DEPEND | &SYSPREF..&SYSUID..&SYSNAME..CRA$NDVR.DEPEND | Permanent |
BROWSE | &SYSPREF..&SYSUID..&SYSNAME..CRA$NDVR.BROWSE | Temporär |
C1PRINT | &SYSPREF..&SYSUID..&SYSNAME..CRA$NDVR.LISTING | Temporär |
Sie können eine Kopie dieser Zuordnungs-REXX-Exec anpassen, falls bestimmte Standardwerte, wie der Dateiname, nicht den Standards Ihres Standorts entsprechen. CRANDVRA befindet sich in FEK.SFEKPROC, sofern Sie während der SMP/E-Installation von Developer for System z kein anderes übergeordnetes Qualifikationsmerkmal verwendet haben.
Anpassungsanweisungen finden Sie in der in CRANDVRA enthaltenen Dokumentation.
Die folgenden CARMA-Komponenten können unabhängig von der gewählten Startmethode angepasst werden. Die unten angegebenen Beispielmember befinden sich in FEK.#CUST.PARMLIB, sofern Sie bei der Anpassung und Übergabe des Jobs FEK.SFEKSAMP(FEKSETUP) keine andere Position angegeben haben. Weitere Details hierzu enthält der Abschnitt Anpassungskonfiguration.
CARMA lässt die Definition und gleichzeitige Ausführung mehrerer RAMs zu. Da jedoch auch bei mehreren RAMs nur ein CARMA-Server pro Benutzer aktiv ist, müssen möglicherweise einige Änderungen an der Konfiguration vorgenommen werden, damit sie funktioniert.
RAMs werden von einem RAM-Entwickler in der VSAM-Datei CRADEF in der CARMA-Konfiguration definiert. Während des Starts erkennt der CARMA-Server CRASERV alle definierten RAMs und übergibt die Informationen an den CARMA-Client. Der Benutzer kann dann einen oder mehrere RAMs auswählen, die in den CARMA-Server geladen werden.
Da RAMs als Plug-ins des CARMA-Servers aktiv sind, müssen Sie sicherstellen, dass alle Voraussetzungen (wie Dateizuordnungen) für jeden der RAMs im Adressraum des CARMA-Servers verfügbar sind. Dies kann Änderungen an den CARMA-Konfigurationsbeispielen, wie CRASUBMT oder crastart.conf, erfordern, die im Lieferumfang von Developer for System z enthalten sind.
Im folgenden Beispiel wird eine vorhandene Konfiguration des CA Endevor® SCM-RAMs mit der Startmethode 'CRASTART' gestartet und anschließend der Beispiel-PDS-RAM hinzugefügt.
Definitionen für den CA Endevor® SCM-RAM:
Definitionen für den PDS-RAM:
Als erstes sammelt der RAM-Entwickler alle Daten und Informationen, die der Systemprogrammierer benötigt, um die Konfiguration abzuschließen.
Der Systemprogrammierer verwendet diese Daten anschließend, um die aktualisierten CARMA-VSAM-Dateien zu erstellen. Mithilfe der Informationen zu den Voraussetzungen erstellt er eine CRASTART-Konfigurationsdatei, die beide RAMs unterstützt.
Der CA Endevor® SCM-RAM ist in einer ISPF-Umgebung aktiv, die voraussetzt, dass die vom PDS-RAM benötigte TSO-Umgebung ebenfalls verfügbar ist.
Falls der CARMA-Server mit TSO (IKJEFTxx) gestartet wird, können Probleme auftreten, wenn Ihre RAM Services aufrufen, die ihrerseits die REXX-Batchschnittstelle IRXJCL aufrufen. Zu diesen Problemen kann es kommen, wenn die von RAM zuvor aufgerufenen Prozessoren bisher ohne TSO oder nur in Online-TSO gearbeitet haben und DD-Anweisung SYSTSIN oder SYSTSPRT dynamisch zuordnen. Zur Umgehung dieses Problems wird das Beispielprogramm CRAXJCL bereitgestellt.
Ein Versuch Ihres Prozessors, die (für IRXJCL erforderliche) Anweisung SYSTSIN oder SYSTSPRT zuzuordnen, könnte scheitern, weil diese DD-Namen bereits von der (für CARMA erforderlichen) Komponente Batch-TSO zugeordnet und geöffnet wurden. Das Ersatzmodul CRAXJCL versucht eine Zuordnung von SYSTSIN und SYSTSPRT zu DUMMY, ignoriert jedoch die Fehler, die bei fehlgeschlagenen Zuordnungen auftreten.
Wenn Ihre Prozessoren in einer von TSO gestarteten CARMA-Umgebung arbeiten, stimmen die Zuordnungen von SYSTSIN und SYSTSPRT mit den von CARMA verwendeten überein. Arbeiten die Prozessoren außerhalb von TSO/CARMA, werden die SYSTSIN- und SYSTSPRINT-Zuordnungen von CRAXJCL erstellt. Ihre Prozessoren sind somit nicht auf den Inhalt der SYSTSIN zugeordneten Datei angewiesen.
Es wird vorausgesetzt, dass Aufrufe von IRXJCL für die Übergabe des REXX-Namens und der Startparameter das Feld PARM verwenden. Weitere Informationen erhalten Sie in TSO/E REXX Reference (IBM Form SA22-7790). SYSTSIN kann somit sicher von CARMA verwendet werden. Alle Ausgaben, die IRXJCL an SYSTSPRT sendet, erscheinen im CARMA-Protokoll.
Prozessoren, die das Ersatzmodul CRAXJCL aufrufen, sollten nicht versuchen, die DD-Anweisung SYSTSIN oder SYSTSPRT vor dem Aufruf von CRAXJCL zuzuordnen.
Das Ersatzmodul CRAXJCL wird im Quellenformat bereitgestellt, denn Sie müssen es an die spezifischen Zuordnungen anpassen, die Sie für SYSTSPRT verwenden möchten. SYSTSIN wird in der Regel einer Pseudodatei (DUMMY) zugeordnet.
Der Assemblerbeispielquellcode und der Beispieljob für Kompilierung/Bindung werden als FEK.#CUST.ASM(CRAXJCL) und FEK.#CUST.JCL(CRA#CIRX) bereitgestellt, sofern Sie beim Anpassen und Übergeben des Jobs FEK.SFEKSAMP(FEKSETUP) keine andere Position angegeben haben. Weitere Details hierzu enthält der Abschnitt Anpassungskonfiguration.
Passen Sie den Assemblerquellcode von CRAXJCL an Ihre Anforderungen an. Stützen Sie sich dabei auf die Dokumentation innerhalb des Members. Passen Sie dann die JCL CRA#CIRX an und übergeben Sie sie, um das Lademodul CRAXJCL zu erstellen. Anpassungsanweisungen finden Sie in der in CRA#CIRX enthaltenen Dokumentation.
Developer for System z verwendet bestimmte Funktionen von Application Deployment Manager als allgemeine Deploymentmethode für verschiedene Komponenten. Die in diesem Kapitel aufgelisteten Anpassungsschritte sind erforderlich, wenn Sie Entwickler sind und die folgenden Funktionen komplett oder teilweise nutzen:
Durch die Anpassung von Application Deployment Manager wird der CRD-Server (CICS Resource Definition) hinzugefügt, der als CICS-Anwendung unter z/OS ausgeführt wird, um die folgenden Funktionen zu unterstützen:
CICSTS-Aspekte enthält weitere Informationen für CICS-Administratoren zum CRD-Server.
Für diese Anpassungstask, für die die folgenden Ressourcen oder speziellen Anpassungstasks erforderlich sind, benötigen Sie die Unterstützung eines CICS-Administrators, eines TCP/IP-Administrators und eines Sicherheitsadministrators:
Vor der Verwendung von Application Deployment Manager an Ihrem Standort müssen Sie die folgenden Tasks ausführen. Sofern nicht anders angegeben, sind alle Tasks obligatorisch.
Passen Sie den Job ADNVCRD an und übergeben Sie ihn, um die VSAM-Datei für das CRD-Repository anzulegen und zu initialisieren. Anpassungsanweisungen finden Sie in der im Member enthaltenen Dokumentation.
ADNVCRD ist in FEK.#CUST.JCL enthalten, sofern Sie während der Anpassung und Übergabe des Jobs FEK.SFEKSAMP(FEKSETUP) keine andere Position angegeben haben. Weitere Details hierzu enthält der Abschnitt Anpassungskonfiguration.
Sie sollten für jede primäre CICS-Verbindungsregion ein gesondertes Repository erstellen. Eine gemeinsame Nutzung des Repostorys impliziert, dass alle zugehörigen CICS-Regionen dieselben im Repository gespeicherten Werte verwenden.
Benutzer müssen das Zugriffsrecht READ für das CRD-Repository haben und CICS-Administratoren das Zugriffsrecht UPDATE.
Mit dem von Developer for System z bereitgestellten Verwaltungsdienstprogramm können CICS-Administratoren die Standardwerte für CICS-Ressourcendefinitionen vorgeben. Diese Standardwerte können schreibgeschützt oder für den Anwendungsentwickler editierbar sein.
Das Verwaltungsdienstprogramm wird vom Beispieljob ADNJSPAU aufgerufen. Für die Verwendung dieses Dienstprogramms ist das Zugriffsrecht UPDATE für das CRD-Repository erforderlich.
ADNJSPAU befindet sich in FEK.#CUST.JCL, sofern Sie bei der Anpassung und Übergabe des Jobs FEK.SFEKSAMP(FEKSETUP) keine andere Position angegeben haben. Weitere Details hierzu enthält der Abschnitt Anpassungskonfiguration.
Weitere Informationen hierzu finden Sie in CICSTS-Aspekte.
CICS Transaction Server stellt ab Version 4.1 Unterstützung für eine HTTP-Schnittstelle zur Verfügung, die mithilfe von RESTful-Prinzipien (Representational State Transfer) entworfen wurde. Diese RESTful-Schnittstelle ist jetzt die strategische CICSTS-Schnittstelle, die von Clientanwendungen verwendet wird. Die ältere Web-Service-Schnittstelle wurde eingefroren. Erweiterungen werden nur für die RESTful-Schnittstelle entwickelt.
Application Deployment Manager hält diese Absichtserklärung ein. Für alle Services, die ab Developer for System z Version 7.6 neu sind, ist der RESTful-CRD-Server erforderlich.
Falls gewünscht, können die RESTful- und Web-Service-Schnittstellen gleichzeitig in einer CICS-Region aktiv sein. In diesem Fall sind in der Region zwei CRD-Server aktiv. Beide Server verwenden gemeinsam dasselbe CRD-Repository. Beachten Sie, dass CICS einige Warnungen zu doppelten Definitionen ausgibt, wenn die zweite Schnittstelle in der Region definiert wird.
Die Informationen in diesem Abschnitt beschreiben, wie Sie den CRD-Server definieren, der die RESTful-Schnittstelle für die Kommunikation mit dem Client von Developer for System z verwendet.
Falls gewünscht, können die RESTful- und Web-Service-Schnittstellen gleichzeitig in einer CICS-Region aktiv sein. In diesem Fall sind in der Region zwei CRD-Server aktiv. Beide Server verwenden gemeinsam dasselbe CRD-Repository. Beachten Sie, dass CICS einige Warnungen zu doppelten Definitionen ausgibt, wenn die zweite Schnittstelle in der Region definiert wird.
Der CRD-Server muss für die primäre Verbindungsregion definiert werden. Diese WOR (Web Owning Region) verarbeitet die Web-Service-Anforderungen von Developer for System z.
ADNCSDRS ist in FEK.#CUST.JCL enthalten, sofern Sie während der Anpassung und Übergabe des Jobs FEK.SFEKSAMP(FEKSETUP) keine andere Position angegeben haben. Weitere Details hierzu enthält der Abschnitt Anpassungskonfiguration.
CEDA INSTALL GROUP(ADNPCRGP)
Der CRD-Server kann auch mit zusätzlichen, nicht primären Verbindungsregionen verwendet werden. Dabei handelt es sich in der Regel um AOR-Regionen (Application Owning Regions).
ADNCSDAR ist in FEK.#CUST.JCL enthalten, sofern Sie während der Anpassung und Übergabe des Jobs FEK.SFEKSAMP(FEKSETUP) keine andere Position angegeben haben. Weitere Details hierzu enthält der Abschnitt Anpassungskonfiguration.
CEDA INSTALL GROUP(ADNARRGP)
Developer for System z stellt mehrere Transaktionen bereit, die der CRD-Server beim Definieren und Abfragen von CICS-Ressourcen verwendet.
Transaktion | Beschreibung |
---|---|
ADMS | Für Änderungen an CICS-Ressourcen, die vom Manifestverarbeitungstool angefordert werden. Diese Transaktion ist normalerweise für CICS-Administratoren bestimmt. |
ADMI | Für Anforderungen, die CICS-Ressourcen definieren, installieren oder deinstallieren. |
ADMR | Für alle anderen Anforderungen, die CICS-Umgebungsinformationen oder -Ressourceninformationen abrufen. |
Indem Sie die folgenden Schritte ausführen, können Sie die Transaktions-IDs ändern, damit sie mit den Standardwerten Ihres Standorts übereinstimmen:
Die Informationen in diesem Abschnitt beschreiben, wie Sie den CRD-Server definieren, der die Web-Service-Schnittstelle für die Kommunikation mit dem Client von Developer for System z verwendet.
Falls gewünscht, können die RESTful- und Web-Service-Schnittstellen gleichzeitig in einer CICS-Region aktiv sein. In diesem Fall sind in der Region zwei CRD-Server aktiv. Beide Server verwenden gemeinsam dasselbe CRD-Repository. Beachten Sie, dass CICS einige Warnungen zu doppelten Definitionen ausgibt, wenn die zweite Schnittstelle in der Region definiert wird.
Der Pipelinenachrichtenhandler (ADNTMSGH) wird für die Sicherheit verwendet. Er verarbeitet die Benutzer-ID und das Kennwort im SOAP-Header. ADNTMSGH wird von der Beispielpipelinekonfigurationsdatei referenziert und muss deshalb in die CICS-RPL-Kette gestellt werden. Weitere Informationen zum Handler für Pipelinenachrichten und die erforderliche Sicherheitskonfiguration enthält CICSTS-Aspekte.
Developer for System z stellt mehrere Transaktionen bereit, die der CRD-Server beim Definieren und Abfragen von CICS-Ressourcen verwendet. Die Transaktions-IDs legt ADNTMSGH je nach erforderlicher Operation fest. Für standortspezifische Anpassungen von ADNTMSGH steht COBOL-Beispielquellcode zur Verfügung.
Transaktion | Beschreibung |
---|---|
ADMS | Für Änderungen an CICS-Ressourcen, die vom Manifestverarbeitungstool angefordert werden. Diese Transaktion ist normalerweise für CICS-Administratoren bestimmt. |
ADMI | Für Anforderungen, die CICS-Ressourcen definieren, installieren oder deinstallieren. |
ADMR | Für alle anderen Anforderungen, die CICS-Umgebungsinformationen oder -Ressourceninformationen abrufen. |
Standardmodul verwenden:
ADNTMSGH anpassen:
Die Beispielmember ADNMSGH* befinden sich in FEK.#CUST.JCL und FEK.#CUST.COBOL, sofern Sie bei der Anpassung und Übergabe des Jobs FEK.SFEKSAMP(FEKSETUP) keine andere Position angegeben haben. Weitere Details hierzu enthält der Abschnitt Anpassungskonfiguration.
Der CRD-Server muss für die primäre Verbindungsregion definiert werden. Diese Region verarbeitet die Serviceanforderungen von Developer for System z.
ADNCSDWS ist in FEK.#CUST.JCL enthalten, sofern Sie während der Anpassung und Übergabe des Jobs FEK.SFEKSAMP(FEKSETUP) keine andere Position angegeben haben. Weitere Details hierzu enthält der Abschnitt Anpassungskonfiguration.
CEDA INSTALL GROUP(ADNPCRGP)
Der CRD-Server kann auch mit zusätzlichen, nicht primären Verbindungsregionen verwendet werden. Dabei handelt es sich in der Regel um AOR-Regionen (Application Owning Regions).
ADNCSDAR ist in FEK.#CUST.JCL enthalten, sofern Sie während der Anpassung und Übergabe des Jobs FEK.SFEKSAMP(FEKSETUP) keine andere Position angegeben haben. Weitere Details hierzu enthält der Abschnitt Anpassungskonfiguration.
CEDA INSTALL GROUP(ADNARRGP)
Developer for System z gibt Clients die Möglichkeit, Manifeste mit Beschreibungen ausgewählter CICS-Ressourcen anzuzeigen und ggf. zu ändern. Änderungen können je nach den vom CICS-Administrator festgelegten Berechtigungen direkt vorgenommen oder in das Manifestrepository zur weiteren Verarbeitung durch einen CICS-Administrator exportiert werden.
Passen Sie den Job ADNVMFST an und übergeben Sie ihn, um die VSAM-Datei für das Manifestrepository anzulegen und zu initialisieren und um diese Datei für die primäre CICS-Verbindungsregion zu definieren. Anpassungsanweisungen finden Sie in der im Member enthaltenen Dokumentation. Für jede primäre CICS-Verbindungsregion muss ein gesondertes Manifestrepository erstellt werden. Alle Benutzer benötigen das Zugriffsrecht UPDATE für das Manifestrepository.
ADNVMFST ist in FEK.#CUST.JCL enthalten, sofern Sie während der Anpassung und Übergabe des Jobs FEK.SFEKSAMP(FEKSETUP) keine andere Position angegeben haben. Weitere Details hierzu enthält der Abschnitt Anpassungskonfiguration.
SCLM Developer Toolkit stellt die Tools bereit, mit denen das Leistungsspektrum von SCLM auch auf dem Client verfügbar gemacht werden kann. SCLM selbst ist ein hostbasierter Quellcodemanager, der im Lieferumfang von ISPF enthalten ist.
SCLM Developer Toolkit enthält ein auf Eclipse basierendes Plug-in mit Anbindung an SCLM, das den Zugriff auf alle SCLM-Prozesse für die herkömmliche Codeentwicklung ermöglicht. Das Plug-in unterstützt auch die vollständige Java- und J2EE-Entwicklung auf der Workstation. Dazu gehören die Synchronisation mit SCLM auf dem Mainframe-Computer sowie die Builderstellung, die Assemblierung und das Deployment des J2EE-Codes vom Mainframe-Computer.
Für diese Anpassungstask, für die die folgenden Ressourcen und/oder speziellen Anpassungstasks erforderlich sind, benötigen Sie die Unterstützung eines SCLM-Administrators und ggf. eines Sicherheitsadministrators:
Vor der Verwendung von SCLM Developer Toolkit an Ihrem Standort müssen Sie die folgenden Tasks ausführen. Sofern nicht anders angegeben, sind alle Tasks obligatorisch.
Eine Liste der erforderlichen SCLM-Wartung finden Sie in Anhang E. Voraussetzungen.
In diesem Anhang sind auch die für JAVA/J2EE-Builds in SCLM Developer Toolkit notwendigen Ant-Spezifikationen dokumentiert.
Achtung: SCLM Developer Toolkit erfordert die Verwendung des TSO/ISPF-Client-Gateways von ISPF. Damit ist implizit z/OS ab Version 1.8 erforderlich. |
SCLM Developer Toolkit erfordert zusätzliche Anpassungsschritte für Systemeinstellungen. Lesen Sie hierzu die Beschreibung im Abschnitt PARMLIB-Änderungen. Einige der Änderungen sind:
Mit SDSF oder dem TSO-Befehl OUTPUT ruft SCLM Developer Toolkit den Fertigstellungsstatus von Jobs und Jobausgaben ab. Beide Methoden erfordern zusätzliche Aufmerksamkeit:
Benutzer müssen die Zugriffsrechte READ, WRITE und EXECUTE für die z/OS UNIX-Verzeichnisse /tmp/ und /var/rdz/WORKAREA/ haben. Das Verzeichnis WORKAREA/ ist in /var/rdz/ enthalten, sofern Sie während der Anpassung und Übergabe des Jobs FEK.SFEKSAMP(FEKSETUP) keine andere Position angegeben haben. Weitere Details hierzu enthält der Abschnitt Anpassungskonfiguration.
SCLM Developer Toolkit verwendet die ISPF/SCLM-Standard-Skeletons, um sicherzustellen, dass die Skeleton-Bibliothek ISP.SISPSLIB der ISPSLIB-Verkettung in ISPF.conf zugeordnet wird. Die Verwendung der Datei ISP.SISPSENU ist optional.
Die Datei ISPF.conf befindet sich in /etc/rdz/, sofern Sie bei der Anpassung und Übergabe des Jobs FEK.SFEKSAMP(FEKSETUP) keine andere Position angegeben haben. Weitere Details enthält der Abschnitt Anpassungskonfiguration. Sie können die Datei mit dem TSO-Befehl OEDIT bearbeiten.
Das folgende Beispiel zeigt die Datei ISPF.conf, die Sie an Ihre Systemumgebung anpassen müssen. Kommentarzeilen beginnen mit einem Stern (*). Fügen Sie Dateien zur Verkettung in derselben Zeile hinzu und trennen Sie die einzelnen Namen jeweils durch ein Komma (,). Weitere Details zur Anpassung von ISPF.conf enthält der Abschnitt Konfigurationsdatei TSO/ISPFISPF.conf des TSO/ISPF-Client-Gateways von ISPF.
* ERFORDERLICH: sysproc=ISP.SISPCLIB,FEK.SFEKPROC ispmlib=ISP.SISPMENU isptlib=ISP.SISPTENU ispplib=ISP.SISPPENU ispslib=ISP.SISPSLIB * OPTIONAL: *allocjob = FEK.#CUST.CNTL(CRAISPRX) *ISPF_timeout = 900
ispslib=hlq.USERSKEL,ISP.SISPSLIB
SCLM Developer Toolkit verwendet einige Anweisungen in rsed.envvars, um Dateien und Verzeichnisse zu finden.
Die Datei rsed.envvars befindet sich in /etc/rdz/, sofern Sie bei der Anpassung und Übergabe des Jobs FEK.SFEKSAMP(FEKSETUP) keine andere Position angegeben haben. Weitere Details enthält der Abschnitt Anpassungskonfiguration. Sie können die Datei mit dem TSO-Befehl OEDIT bearbeiten.
Das folgende Codebeispiel zeigt die SCLMDT-Anweisungen in rsed.envvars, die Sie an Ihre Systemumgebung anpassen müssen. Weitere Details zur Anpassung von rsed.envvars enthält der Abschnitt RSE-Konfigurationsdatei rsed.envvars.
_SCLMDT_CONF_HOME=/var/rdz/sclmdt #STEPLIB=$STEPLIB:FEK.SFEKAUTH:FEK.SFEKLOAD #_SCLMDT_TRANTABLE=FEK.#CUST.LSTRANS.FILE #ANT_HOME=/usr/lpp/Apache/Ant/apache-ant-1.7.1 _SCLMDT_BASE_HOME=$RSE_HOME _SCLMDT_WORK_HOME=$_CMDSERV_WORK_HOME CGI_DTWORK=$_SCLMDT_WORK_HOME
Vom SCLM Developer Toolkit aus können Sie Dateien mit langen Namen (mit mehr als acht Zeichen oder gemischter Groß-/Kleinschreibung) in SCLM speichern. Zu diesem Zweck wird eine VSAM-Datei verwendet, die die Zuordnung des langen Dateinamens zu dem in SCLM verwendeten und aus acht Zeichen bestehenden Membernamen enthält.
Passen Sie das Beispielmember FLM02LST in der ISPF-Beispielbibliothek ISP.SISPSAMP an und übergeben Sie es, um die VSAM für die Umsetzung langer/kurzer Namen zu erstellen. Bei den Konfigurationsschritten in dieser Veröffentlichung wird davon ausgegangen, dass Sie die VSAM wie in der folgenden Beispielkonfigurations-JCL FEK.#CUST.LSTRANS.FILE nennen.
//FLM02LST JOB <Jobparameter> //* //* ACHTUNG: Dies ist keine JCL-Prozedur und kein vollständiger Job. //* Vor Verwendung dieses Beispiels müssen Sie die folgenden //* Änderungen vornehmen: //* 1. Passen Sie die Jobparameter an Ihre Systemanforderungen an. //* 2. Ersetzen Sie ****** durch die Platteneinheit für die VSAM. //* 3. Ersetzen Sie alle Verweise auf FEK.#CUST.LSTRANS.FILE durch //* Ihre Namenskonvention für die SCLM-Umsetzungs-VSAM. //* //CREATE EXEC PGM=IDCAMS //SYSPRINT DD SYSOUT=* //SYSIN DD * DELETE FEK.#CUST.LSTRANS.FILE SET MAXCC=0 DEFINE CLUSTER(NAME(FEK.#CUST.LSTRANS.FILE) - VOLUMES(******) - RECORDSIZE(58 2048) - SHAREOPTIONS(3 3) - CYLINDERS(1 1) - KEYS(8 0) - INDEXED) - DATA (NAME(FEK.#CUST.LSTRANS.FILE.DATA)) - INDEX (NAME(FEK.#CUST.LSTRANS.FILE.INDEX)) /* ALTERNATIVEN INDEX MIT NICHT EINDEUTIGEN SCHLÜSSELN DEFINIEREN -> ESDS */ DEFINE ALTERNATEINDEX(- NAME(FEK.#CUST.LSTRANS.FILE.AIX) - RELATE(FEK.#CUST.LSTRANS.FILE) - RECORDSIZE(58 2048) - VOLUMES(******) - CYLINDERS(1 1) - KEYS(50 8) - UPGRADE - NONUNIQUEKEY) - DATA (NAME(FEK.#CUST.LSTRANS.FILE.AIX.DATA)) - INDEX (NAME(FEK.#CUST.LSTRANS.FILE.AIX.INDEX)) /* //* //PRIME EXEC PGM=IDCAMS,COND=(0,LT) //SYSPRINT DD SYSOUT=* //INITREC DD * INITREC1 /* //SYSIN DD * REPRO INFILE(INITREC) - OUTDATASET(FEK.#CUST.LSTRANS.FILE) IF LASTCC = 4 THEN SET MAXCC=0 BLDINDEX IDS(FEK.#CUST.LSTRANS.FILE) - ODS(FEK.#CUST.LSTRANS.FILE.AIX) IF LASTCC = 0 THEN - DEFINE PATH (NAME(FEK.#CUST.LSTRANS.FILE.PATH) - PATHENTRY (FEK.#CUST.LSTRANS.FILE.AIX)) /*
Entfernen Sie vor Verwendung der Umsetzung langer/kurzer Namen das Kommentarzeichen und setzen Sie die Umgebungsvariable _SCLMDT_TRANTABLE in rsed.envvars, damit der Name der VSAM für die Umsetzung langer Namen in Kurznamen übereinstimmt.
Die Datei rsed.envvars befindet sich in /etc/rdz/, sofern Sie bei der Anpassung und Übergabe des Jobs FEK.SFEKSAMP(FEKSETUP) keine andere Position angegeben haben. Weitere Details enthält der Abschnitt Anpassungskonfiguration. Sie können die Datei mit dem TSO-Befehl OEDIT bearbeiten.
Dieser Schritt ist nur erforderlich, wenn Sie in SCLM die JAVA/J2EE-Buildunterstützung verwenden möchten.
Apache Ant ist ein Open-Source-Build-Tool vonJava, das Sie von der Webseite http://ant.apache.org/ herunterladen können. Ant umfasst Textdateien und Scripts, die im ASCII-Format verteilt werden. Für die Ausführung unter z/OS UNIX ist daher eine ASCII-EBCDIC-Umsetzung erforderlich.
Führen Sie die folgenden Schritte aus, um Ant unter z/OS zu implementieren und für Developer for System z zu definieren:
JAVA_HOME=/usr/lpp/java/IBM/J5.0
ANT_HOME=/usr/lpp/Apache/Ant/apache-ant-1.7.1
Beispiel:
Testen Sie wie folgt, ob die Ant-Initialisierung erfolgreich war:
Beispiel:
export PATH=/usr/lpp/Apache/Ant/apache-ant-1.7.1/bin:$PATH export PATH=/usr/lpp/java/IBM/J5.0/bin:$PATH
Beispiel:
ant -version
SCLM selbst erfordert für eine Zusammenarbeit mit SCLM Developer Toolkit einige Anpassungsschritte. Weitere Informationen zu den erforderlichen Anpassungstasks enthält das Administratorhandbuch für SCLM Developer Toolkit (IBM Form SC12-4344-01):
Der SCLM-Administrator muss verschiedene anpassbare Werte von Developer for System z kennen, die in Tabelle 13 beschrieben sind, um die Anpassungs- und Projektdefinitionstasks ausführen zu können.
Beschreibung |
|
Wert |
---|---|---|
Beispielbibliothek von Developer for System z |
|
|
Beispielverzeichnis von Developer for System z |
|
|
Java-Verzeichnis bin |
|
|
Ant-Verzeichnis bin |
|
|
WORKAREA-Ausgangsverzeichnis |
|
|
Ausgangsverzeichnis für SCLMDT-Projektkonfigurationen |
|
|
VSAM für Umsetzung langer/kurzer Namen |
|
SCLM Developer Toolkit nutzt einen WORKAREA gemeinsam mit dem TSO/ISPF-Client-Gateway von ISPF. Daher könnte eine regelmäßige Bereinigung angezeigt sein. Weitere Informationen hierzu enthält der Abschnitt WORKAREA-Bereinigung (optional).
In den folgenden Abschnitten ist eine Kombination optionaler Anpassungstasks beschrieben. Konfigurieren Sie den gewünschten Service gemäß den Anweisungen im jeweiligen Abschnitt.
Für diese Anpassungstask, für die die folgenden Ressourcen oder speziellen Anpassungstasks erforderlich sind, benötigen Sie die Unterstützung eines WLM-Administrators und eines DB2-Administrators:
|
Developer for System z stellt ein Beispiel für eine gespeicherte DB2-Prozedur (Stored Procedure Builder für PL/I und COBOL) bereit, sodass Sie innerhalb des Clients von Developer for System z gespeicherte COBOL- und PL/I-Prozeduren erstellen können.
Ordnen Sie der JCL-Prozedur des WLM-Adressraums für den Stored Procedure Builder für PL/I und COBOL in den WLM-Anzeigen eine Anwendungsumgebung zu. Informationen hierzu finden Sie in der Veröffentlichung MVS Planning Workload Management (IBM Form SA22-7602).
Passen Sie die Task FEK.#CUST.PROCLIB(ELAXMSAM) der gespeicherten Beispielprozedur wie innerhalb des Members beschrieben an und kopieren Sie sie in SYS1.PROCLIB. Sie müssen wie im nachstehenden Codebeispiel Folgendes angeben:
//ELAXMSAM PROC RGN=0M, // NUMTCB=1, // APPLENV=#wlmwd4z, // DB2SSN=#ssn, // DB2PRFX='DSN810', // COBPRFX='IGY.V3R4M0', // PLIPRFX='IBMZ.V3R6M0', // LIBPRFX='CEE', // LODPRFX='FEK' //* //DSNX9WLM EXEC PGM=DSNX9WLM,REGION=&RGN,TIME=NOLIMIT,DYNAMNBR=10, // PARM='&DB2SSN,&NUMTCB,&APPLENV' //STEPLIB DD DISP=SHR,DSN=&DB2PRFX..SDSNEXIT // DD DISP=SHR,DSN=&DB2PRFX..SDSNLOAD // DD DISP=SHR,DSN=&LIBPRFX..SCEERUN // DD DISP=SHR,DSN=&COBPRFX..SIGYCOMP // DD DISP=SHR,DSN=&PLIPRFX..SIBMZCMP //SYSEXEC DD DISP=SHR,DSN=&LODPRFX..SFEKPROC //SYSTSPRT DD SYSOUT=* //CEEDUMP DD SYSOUT=* //SYSABEND DD DUMMY //SYSUT1 DD UNIT=SYSALLDA,SPACE=(CYL,(1,1)) //SYSUT2 DD UNIT=SYSALLDA,SPACE=(CYL,(1,1)) //SYSUT3 DD UNIT=SYSALLDA,SPACE=(CYL,(1,1)) //SYSUT4 DD UNIT=SYSALLDA,SPACE=(CYL,(1,1)) //SYSUT5 DD UNIT=SYSALLDA,SPACE=(CYL,(1,1)) //SYSUT6 DD UNIT=SYSALLDA,SPACE=(CYL,(1,1)) //SYSUT7 DD UNIT=SYSALLDA,SPACE=(CYL,(1,1)) //*
Passen Sie das Beispielmember ELAXMJCL in der Datei FEK.#CUST.JCL an und übergeben Sie es, um die gespeicherte Prozedur für DB2 zu definieren. Anpassungsanweisungen finden Sie in der im Member enthaltenen Dokumentation.
//ELAXMJCL JOB <Jobparameter> //JOBPROC JCLLIB ORDER=(#hlq.SDSNPROC) //JOBLIB DD DISP=SHR,DSN=#hlq.SDSNEXIT // DD DISP=SHR,DSN=#hlq.SDSNLOAD //* //RUNTIAD EXEC PGM=IKJEFT01,DYNAMNBR=20 //SYSTSPRT DD SYSOUT=* //SYSTSIN DD * DSN S(#ssn) R(1) T(1) RUN PROGRAM(DSNTIAD) PLAN(DSNTIAD) - LIB('#hlq.RUNLIB.LOAD') //SYSPRINT DD SYSOUT=* //SYSIN DD * CREATE PROCEDURE SYSPROC.ELAXMREX ( IN FUNCTION_REQUEST VARCHAR(20) CCSID EBCDIC , IN SQL_ROUTINE_NAME VARCHAR(27) CCSID EBCDIC , IN SQL_ROUTINE_SOURCE VARCHAR(32672) CCSID EBCDIC , IN BIND_OPTIONS VARCHAR(1024) CCSID EBCDIC , IN COMPILE_OPTIONS VARCHAR(255) CCSID EBCDIC , IN PRECOMPILE_OPTIONS VARCHAR(255) CCSID EBCDIC , IN PRELINK_OPTIONS VARCHAR(32672) CCSID EBCDIC , IN LINK_OPTIONS VARCHAR(255) CCSID EBCDIC , IN ALTER_STATEMENT VARCHAR(32672) CCSID EBCDIC , IN SOURCE_DATASETNAME VARCHAR(80) CCSID EBCDIC , IN BUILDOWNER VARCHAR(8) CCSID EBCDIC , IN BUILDUTILITY VARCHAR(18) CCSID EBCDIC , OUT RETURN_VALUE VARCHAR(255) CCSID EBCDIC ) PARAMETER STYLE GENERAL RESULT SETS 1 LANGUAGE REXX EXTERNAL NAME ELAXMREX COLLID DSNREXCS WLM ENVIRONMENT ELAXMSAM PROGRAM TYPE MAIN MODIFIES SQL DATA STAY RESIDENT NO COMMIT ON RETURN NO ASUTIME NO LIMIT SECURITY USER; COMMENT ON PROCEDURE SYSPROC.ELAXMREX IS 'PLI & COBOL PROCEDURE PROCESSOR (ELAXMREX), INTERFACE LEVEL 0.01'; GRANT EXECUTE ON PROCEDURE SYSPROC.ELAXMREX TO PUBLIC; //*
Für diese Anpassungstask benötigen Sie keine Unterstützung. Es sind auch keine speziellen Ressourcen oder Anpassungstasks erforderlich. |
Im Client von Developer for System z gibt es eine Codegenerierungskomponente mit der Bezeichnung 'Enterprise Service Tools' (EST). Abhängig vom generierten Codetyp liegen diesem Code Funktionen zugrunde, die durch die Hostinstallation von Developer for System z bereitgestellt werden. In den folgenden Abschnitten wird beschrieben, wie Sie diese Hostfunktionen verfügbar machen:
Für diese Anpassungstask, für die die folgenden Ressourcen oder speziellen Anpassungstasks erforderlich sind, benötigen Sie die Unterstützung eines CICS-Administrators:
|
Die Komponente Enterprise Service Tools (EST) von Developer for System z unterstützt verschiedene Formate für arabische und hebräische Schnittstellennachrichten und die bidirektionale Datendarstellung und -bearbeitung in allen Editoren und Ansichten. In Terminalanwendungen werden Anzeigen von links nach rechts und von rechts nach links sowie numerische Felder und Felder mit entgegengesetzter Anzeigeausrichtung unterstützt.
Zu den zusätzlichen bidirektionalen Features und Funktionen gehören unter anderem:
Von EST generierter Code kann die BIDI-Konvertierung auch in anderen Umgebungen als CICS SFR (Service Flow Runtime) unterstützen. Ein Beispiel sind Batchanwendungen. Sie können die EST-Generatoren veranlassen, alle Aufrufe bidirektionaler Umsetzungsroutinen aufzunehmen, indem Sie in den EST-Generierungsassistenten die entsprechenden BIDI-Konvertierungsattribute angeben und die generierten Programme mit der entsprechenden Bibliothek für bidirektionale Umsetzung (FEK.SFEKLOAD) verknüpfen.
Führen Sie die folgenden Tasks aus, um die Unterstützung bidirektionaler Sprachen für CICS zu aktivieren:
CEDA DEF PROG(FEJBDCMP) LANG(LE) G(xxx) CEDA DEF PROG(FEJBDTRX) LANG(LE) G(xxx)
Für diese Anpassungstask benötigen Sie keine Unterstützung. Es sind aber die folgenden Ressourcen oder speziellen Anpassungstasks erforderlich:
|
Im Client von Developer for System z gibt es eine Codegenerierungskomponente mit der Bezeichnung 'Enterprise Service Tools' (EST). Alle IRZ*- und IIRZ*-Module in der Ladebibliothek FEK.SFEKLOAD müssen dem generierten Code verfügbar gemacht werden, damit der von EST generierte Code Diagnosefehlernachrichten ausgeben kann. EST kann Code für die folgenden Umgebungen generieren:
Wenn der generierte Code in einer CICS-Transaktion ausgeführt wird, fügen Sie alle Module IRZ* und IIRZ* in FEK.SFEKLOAD zur DFHRPL-DD der CICS-Region hinzu. Zu diesem Zweck sollten Sie die Installationsdatei zur Kette hinzufügen, damit angewendete Wartungen automatisch für CICS verfügbar sind.
Machen Sie in allen anderen Situationen alle Module IRZ* und IIRZ* in der Ladebibliothek FEK.SFEKLOAD mithilfe von STEPLIB oder LINKLIST verfügbar. Zu diesem Zweck sollten Sie die Installationsdatei zur Kette hinzufügen, damit angewendete Wartungen automatisch für CICS verfügbar sind.
Wenn Sie sich für die Verwendung von STEPLIB entscheiden, müssen Sie die nicht über LINKLIST verfügbaren Module in der Anweisung STEPLIB der Task definieren, die den Code ausführt.
Wenn die Lademodule nicht verfügbar sind und durch den generierten Code ein Fehler festgestellt wird, wird die folgende Nachricht ausgegeben:
IRZ9999S Abruf des Texts der Laufzeitnachricht 'Language Environment' ist gescheitert. Überprüfen Sie, ob das Laufzeitnachrichtenmodul 'Language Environment' für Facility-IRZ in DFHRPL oder STEPLIB installiert ist.
Für diese Anpassungstask, für die die folgenden Ressourcen oder speziellen Anpassungstasks erforderlich sind, benötigen Sie die Unterstützung eines Sicherheitsadministrators:
|
Die externe Kommunikation (Client-Host) kann mit SSL (Secure Socket Layer) verschlüsselt werden. Dieses Feature ist standardmäßig inaktiviert und wird von den Einstellungen in ssl.properties gesteuert.
Die Datei ssl.properties befindet sich in /etc/rdz/, sofern Sie bei der Anpassung und Übergabe des Jobs FEK.SFEKSAMP(FEKSETUP) keine andere Position angegeben haben. Weitere Details enthält der Abschnitt Anpassungskonfiguration. Sie können die Datei mit dem TSO-Befehl OEDIT bearbeiten. RSE muss neu gestartet werden, damit diese Änderungen wirksam werden.
Der Client kommuniziert während des Verbindungsaufbaus mit dem RSE-Dämon und während der aktuellen Sitzung mit dem RSE-Server. Wenn SSL aktiviert ist, sind beide Datenströme verschlüsselt.
Aufgrund unterschiedlicher Architektur unterstützen der RSE-Dämon und der RSE-Server verschiedene Mechanismen zum Speichern von Zertifikaten. Dies impliziert, dass für den RSE-Dämon sowie den RSE-Server SSL-Definitionen erforderlich sind. Ein gemeinsam genutztes Zertifikat kann verwendet werden, wenn der RSE-Dämon und der RSE-Server dieselbe Zertifikatsverwaltungsmethode verwenden.
Zertifikatsspeicher | Erstellt und verwaltet von | RSE-Dämon | RSE-Server |
---|---|---|---|
Schlüsseldatei | SAF-kompatibles Sicherheitsprodukt | unterstützt | unterstützt |
Schlüsseldatenbank | gskkyman von z/OS UNIX | unterstützt | / |
Keystore | Java-Keytool | / | unterstützt |
Zum Verwalten von SSL verwendet der RSE-Dämon System SSL-Funktionen. Dies impliziert, dass SYS1.SIEALNKE von Ihrer Sicherheitssoftware programmgesteuert und RSE über LINKLIST oder die STEPLIB-Anweisung in rsed.envvars verfügbar sein muss.
Das folgende Codebeispiel zeigt die Datei ssl.properties, die Sie an Ihre Systemumgebung anpassen müssen. Wenn eine US-Codepage verwendet wird, beginnen die Kommentarzeilen mit dem Nummernzeichen (#). Datenzeilen dürfen nur eine Anweisung und ihren zugeordneten Wert haben. Kommentare sind nicht in derselben Zeile zulässig. Zeilenfortsetzungen werden nicht unterstützt.
# ssl.properties - SSL-Konfigurationsdatei enable_ssl=false # Dämonmerkmale #daemon_keydb_file= #daemon_keydb_password= #daemon_key_label= # Servermerkmale #server_keystore_file= #server_keystore_password= #server_keystore_label= #server_keystore_type=JCERACFKS
Die Dämon- und Servermerkmale müssen nur gesetzt werden, wenn Sie SSL aktivieren. Weitere Informationen zur SSL-Konfiguration enthält Anhang A. SSL- und X.509-Authentifizierung konfigurieren.
Schlüsselwort | Keystoretyp |
---|---|
JKS | Java-Keystore |
JCERACFKS | SAF-kompatible Schlüsseldatei, wobei der private Schlüssel des Zertifikats in der Sicherheitsdatenbank gespeichert ist |
JCECCARACFKS | SAF-kompatible Schlüsseldatei, wobei der private Schlüssel des Zertifikats mithilfe von ICSF gespeichert wird, der Schnittstelle zur Verschlüsselungshardware in System z |
security.provider.1=com.ibm.crypto.hdwrCCA.provider.IBMJCECCA
Die Ergebnisdatei sieht wie folgt aus:
security.provider.1=com.ibm.crypto.hdwrCCA.provider.IBMJCECCA security.provider.2=com.ibm.jsse2.IBMJSSEProvider2 security.provider.3=com.ibm.crypto.provider.IBMJCE security.provider.4=com.ibm.security.jgss.IBMJGSSProvider security.provider.5=com.ibm.security.cert.IBMCertPath security.provider.6=com.ibm.security.sasl.IBMSASL
Für diese Anpassungstask benötigen Sie keine Unterstützung. Es sind auch keine speziellen Ressourcen oder Anpassungstasks erforderlich. |
Developer for System z unterstützt zur Problemlösung verschiedene Tracestufen für den internen Programmablauf. RSE und einige von RSE aufgerufene Services ermitteln anhand der Einstellungen in rsecomm.properties den gewünschten Detaillierungsgrad der Ausgabeprotokolle.
Achtung: Änderungen an diesen Einstellungen können zu Leistungseinbußen führen und sollten nur auf Anweisung des
IBM Support Center vorgenommen werden. |
Die Datei rsecomm.properties befindet sich in /etc/rdz/, sofern Sie bei der Anpassung und Übergabe des Jobs FEK.SFEKSAMP(FEKSETUP) keine andere Position angegeben haben. Weitere Details enthält der Abschnitt Anpassungskonfiguration. Sie können die Datei mit dem TSO-Befehl OEDIT bearbeiten.
Das folgende Codebeispiel zeigt die Datei rsecomm.properties, die Sie an Ihre Trace-Anforderungen anpassen können. Wenn eine US-Codepage verwendet wird, beginnen die Kommentarzeilen mit dem Nummernzeichen (#). Datenzeilen dürfen nur eine Anweisung und ihren zugeordneten Wert haben. Kommentare sind nicht in derselben Zeile zulässig. Zeilenfortsetzungen werden nicht unterstützt.
# server.version - NICHT ÄNDERN! server.version=5.0.0 # Protokollstufe # 0 - Fehlernachrichten protokollieren # 1 - Fehlernachrichten und Warnungen protokollieren # 2 - Fehlernachrichten, Warnungen und Informationen protokollieren debug_level=1 # Protokollposition # Log_To_StdOut # Log_To_File log_location=Log_To_File
Gültige Werte sind:
0 | Nur Fehlernachrichten protokollieren |
1 | Fehlernachrichten und Warnungen protokollieren |
2 | Fehlernachrichten, Warnungen und Informationsnachrichten protokollieren |
Gültige Werte sind:
Log_To_File | Nachrichten werden an eine eigene Datei im Protokollausgabeverzeichnis gesendet.
|
Log_To_StdOut | Nachrichten werden an stdout gesendet.
|
daemonlog ist der Wert der Anweisung daemon.log in rsed.envvars. Wenn die Anweisung daemon.log auf Kommentar gesetzt oder nicht vorhanden ist, wird der Ausgangspfad der Benutzer-ID verwendet, die der gestarteten Task RSED zugeordnet ist. Der Ausgangspfad ist im OMVS-Sicherheitssegment der Benutzer-ID definiert.
Benutzerspezifische Protokolle werden in userlog/.eclipse/RSE/$LOGNAME gespeichert. Dabei ist userlog der Wert der Anweisung user.log in rsed.envvars und $LOGNAME ist die Anmeldebenutzer-ID (in Großbuchstaben). Wenn die Anweisung user.log in Kommentarzeichen gesetzt wurde oder nicht vorhanden ist, wird der Ausgangspfad des Benutzers verwendet. Der Ausgangspfad ist im OMVS-Sicherheitssegment der Benutzer-ID definiert.
Für diese Anpassungstask benötigen Sie keine Unterstützung. Es sind auch keine speziellen Ressourcen oder Anpassungstasks erforderlich. |
Die Clientkomponente von Developer for System z kann Eigenschaftsgruppen mit Standardwerten für mehrere Eigenschaften definieren (z. B. die bei der Kompilierung von COBOL-Quellcode zu verwendenden COBOL-Compileroptionen). In Developer for System z gibt es integrierte Standardwerte, aber auch die Möglichkeit, angepasste, systemspezifische Standardwerte zu definieren.
Die Position der Konfigurationsdateien mit benutzerdefinierten Eigenschaftsgruppen und Standardwerten ist in der Datei propertiescfg.properties festgelegt, die sich in /etc/rdz/ befindet, sofern Sie bei der Anpassung und Übergabe des Jobs FEK.SFEKSAMP(FEKSETUP) keine andere Position angegeben haben. Weitere Details enthält der Abschnitt Anpassungskonfiguration. Sie können die Datei mit dem TSO-Befehl OEDIT bearbeiten. RSE muss neu gestartet werden, damit diese Änderungen wirksam werden.
Das folgende Codebeispiel zeigt die Datei propertiescfg.properties, die Sie an Ihre Systemumgebung anpassen müssen. Wenn eine US-Codepage verwendet wird, beginnen die Kommentarzeilen mit dem Nummernzeichen (#). Datenzeilen dürfen nur eine Anweisung und ihren zugeordneten Wert haben. Kommentare sind nicht in derselben Zeile zulässig. Zeilenfortsetzungen werden nicht unterstützt.
# # Hostbasierte Eigenschaftsgruppen - Stammkonfigurationsdatei # ENABLED=FALSE RDZ-VERSION=7.5.0.0 PROPERTY-GROUP=/var/rdz/properties DEFAULT-VALUES=/var/rdz/properties
Im Information Center für Developer for System z (http://publib.boulder.ibm.com/infocenter/ratdevz/v7r6/index.jsp) finden Sie weitere Informationen zur Erstellung der Konfigurationsdatei für Eigenschaftsgruppen (propertygroups.xml) und der Konfigurationsdatei für Standardwerte (defaultvalues.xml).
Für diese Anpassungstask benötigen Sie keine Unterstützung. Es sind auch keine speziellen Ressourcen oder Anpassungstasks erforderlich. |
z/OS-Projekte können in der Perspektive für z/OS-Projekte auf dem Client einzeln definiert werden. Sie können z/OS-Projekte aber auch zentral auf dem Host definieren und dann benutzerabhängig auf dem Client replizieren. Solche hostbasierten Projekte sind vom Aussehen und von der Funktionsweise her 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.
Die Position der Projektdefinitionen ist in der Datei projectcfg.properties festgelegt, die sich in /etc/rdz/ befindet, sofern Sie bei der Anpassung und Übergabe des Jobs FEK.SFEKSAMP(FEKSETUP) keine andere Position angegeben haben. Weitere Details enthält der Abschnitt Anpassungskonfiguration. Sie können die Datei mit dem TSO-Befehl OEDIT bearbeiten. RSE muss neu gestartet werden, damit diese Änderungen wirksam werden.
Das folgende Codebeispiel zeigt die Datei projectcfg.properties, die Sie an Ihre Systemumgebung anpassen müssen. Wenn eine US-Codepage verwendet wird, beginnen die Kommentarzeilen mit dem Nummernzeichen (#). Datenzeilen dürfen nur eine Anweisung und ihren zugeordneten Wert haben. Kommentare sind nicht in derselben Zeile zulässig. Zeilenfortsetzungen werden nicht unterstützt.
# # Stammkonfigurationsdatei für hostbasierte Projekte # # WSED-VERSION - nicht ändern! WSED-VERSION=7.0.0.0 # Position der Definitionsdateien für das hostbasierte Projekt angeben PROJECT-HOME=/var/rdz/projects
Im Information Center für Developer for System z (http://publib.boulder.ibm.com/infocenter/ratdevz/v7r6/index.jsp) finden Sie weitere Informationen zu hostbasierten Projekten.
Für diese Anpassungstask, für die die folgenden Ressourcen oder speziellen Anpassungstasks erforderlich sind, benötigen Sie die Unterstützung eines Sicherheitsadministrators:
|
Developer for System z unterstützt den direkten Zugriff von einem Client auf eine begrenzte Gruppe von Funktionen von IBM File Manager für z/OS. IBM File Manager for z/OS stellt umfassende Tools für die Arbeit mit MVS-Dateien und z/OS UNIX-Dateien sowie mit DB2-, IMS- und CICS-Daten bereit. Zu diesen Tools gehören die bekannten Anzeige-, Bearbeitungs-, Kopier- und Druckdienstprogramme von ISPF, die erweitert wurden, um den Anforderungen von Anwendungsentwicklern besser gerecht zu werden. In der aktuellen Version von Developer for System z werden nur das Anzeigen und Bearbeiten von MVS-Dateien (einschließlich aller VSAM-Typen), das Erstellen und Bearbeiten von Schablonen für MVS-Dateien (einschließlich dynamischer Schablonen) sowie erweiterte Kopierprogramme unterstützt.
Beachten Sie, dass Sie das Produkt IBM File Manager for z/OS gesondert bestellen, installieren und konfigurieren müssen. Welche Version von File Manager für Ihre Version von Developer for System z erforderlich ist, können Sie der Veröffentlichung Rational Developer for System z Prerequisites (IBM Form SC23-7659) entnehmen. Die Installation und Anpassung dieses Produkts ist nicht in diesem Handbuch beschrieben.
Beachten Sie, dass Developer for System z und File Manger die Schnittstelle für Batchverarbeitung für den Zugriff auf File Manager-Services nicht mehr unterstützen. Sie müssen den File Manager-Listener verwenden.
Die von Developer for System z benötigten File Manager-Integrationsdefinitionen sind in der Datei FMIEXT.properties gespeichert, die sich in /etc/rdz/ befindet, sofern Sie bei der Anpassung und Übergabe des Jobs FEK.SFEKSAMP(FEKSETUP) keine andere Position angegeben haben. Weitere Details hierzu enthält der Abschnitt Anpassungskonfiguration. Sie können die Datei mit dem TSO-Befehl OEDIT bearbeiten. RSE muss neu gestartet werden, damit diese Änderungen wirksam werden.
Das folgende Codebeispiel zeigt die Datei FMIEXT.properties, die Sie an Ihre Systemumgebung anpassen müssen. Wenn eine US-Codepage verwendet wird, beginnen die Kommentarzeilen mit dem Nummernzeichen (#). Datenzeilen dürfen nur eine Anweisung und ihren zugeordneten Wert haben. Kommentare sind nicht in derselben Zeile zulässig. Zeilenfortsetzungen werden nicht unterstützt.
# Erweiterungsmerkmale für File Manager-Integration (FMI) # enabled=false fmlistenport=1960
Für diese Anpassungstask benötigen Sie keine Unterstützung. Es sind auch keine speziellen Ressourcen oder Anpassungstasks erforderlich. |
Einige Zeichen werden nicht richtig zwischen den Codepages des Hosts (EBCDIC-basiert) und den Client-Codepages (ASCII-basiert) umgesetzt. Der Editor der Clientkomponente von Developer for System z kann diese nicht editierbaren Zeichen anhand der Definitionen in der Datei uchars.settings identifizieren. Wenn beim Öffnen einer Datei ein Zeichen in uchars.settings identifiziert wird, erzwingt der Editor den schreibgeschützten Modus, damit die Datei durch Speichern nicht beschädigt werden kann.
Die Datei uchars.settings befindet sich in /etc/rdz/, sofern Sie bei der Anpassung und Übergabe des Jobs FEK.SFEKSAMP(FEKSETUP) keine andere Position angegeben haben. Weitere Details enthält der Abschnitt Anpassungskonfiguration. Sie können die Datei mit dem TSO-Befehl OEDIT bearbeiten. RSE muss neu gestartet werden, damit diese Änderungen wirksam werden. Es ist nicht ratsam, diese Datei zu modifizieren. Nehmen Sie Änderungen nur auf Anweisung des IBM Support Center vor.
# uchars.settings - Nicht editierbare Codepunkte # * * 0D 15 25; # DBCS (Japanisch, Koreanisch und Chinesisch) IBM-930 * 0D 15 1E 1F 25; IBM-933 * 0D 15 1E 1F 25; IBM-935 * 0D 15 1E 1F 25; IBM-937 * 0D 15 1E 1F 25; IBM-939 * 0D 15 1E 1F 25; IBM-1390 * 0D 15 1E 1F 25; IBM-1399 * 0D 15 1E 1F 25; IBM-1364 * 0D 15 1E 1F 25; IBM-1371 * 0D 15 1E 1F 25; IBM-1388 * 0D 15 1E 1F 25; # UNICODE UTF-8 * 0D 0A; UTF-16BE * 0D 0A; UTF-16LE * 0D 0A; UTF-16 * 0D 0A;
Die Datei besteht aus mehreren Einträgen im folgenden Format:
HOST-CODEPAGE LOKALE_CODEPAGE HEX-CODEPUNKTE ;
HEX-CODEPUNKTE steht hier für eine Liste von zweistelligen hexadezimalen Codepunkten, die jeweils durch ein Leerzeichen voneinander getrennt sind und die nicht editierbaren Zeichen bezeichnen. Die Liste muss mit einem Semikolon (;) enden.
Es gelten die folgenden Syntaxregeln:
Für diese Anpassungstask benötigen Sie keine Unterstützung. Es sind auch keine speziellen Ressourcen oder Anpassungstasks erforderlich. |
REXEC (Remote Execution) ist ein TCP/IP-Service, mit dem Clients einen Befehl auf dem Host ausführen können. SSH (Secure Shell) ist ein ähnlicher Service, bei dem jedoch die gesamte Kommunikation mit SSL (Secure Sockets Layer) verschlüsselt wird. Developer for System z nutzt beide Services für ferne (hostbasierte) Aktionen in z/OS UNIX-Unterprojekten.
Developer for System z kann auch für die Verwendung von REXEC (oder SSH) zum Starten eines RSE-Servers auf dem Host konfiguriert werden. Beachten Sie jedoch, dass jede auf diese Weise gestartete Verbindung in einem gesonderten RSE-Server mündet und jeder dieser Server einen gewissen Anteil an den Systemressourcen benötigt. Diese alternative Verbindungsmethode kann daher nur für eine kleine Anzahl von Verbindungen funktionieren.
Da die alternative Verbindungsmethode mit REXEC (oder SSH) den RSE-Dämon umgeht, kann sie nicht auf alle in dieser Veröffentlichung beschriebenen Services zugreifen, z. B. die Einzelserververarbeitung und -überprüfung. Informieren Sie sich bei der IBM Unterstützungsfunktion, ob ein bestimmter Hostservice von der alternativen Verbindungsmethode mit REXEC unterstützt wird.
Ferne (hostbasierte) Aktionen für z/OS UNIX-Unterprojekte erfordern, dass auf dem Host REXEC oder SSH aktiv ist. Wenn REXEC/SSH nicht für die Verwendung des Standardports konfiguriert ist, muss die Clientkomponente von Developer for System z den korrekten Port für z/OS UNIX-Unterprojekte definieren. Hierfür können Sie die Vorgabenseite Fenster >Benutzervorgaben... > z/OS-Lösungen >USS-Unterprojekte >Optionen für ferne Aktionen auswählen. Welcher Port verwendet wird, erfahren Sie im Abschnitt REXEC (oder SSH) konfigurieren.
Die Clientkomponente von Developer for System z muss die beiden folgenden Werte kennen, um über REXEC (oder SSH) eine RSE-Verbindung starten zu können:
Das Script server.zseries ist in /etc/rdz/ enthalten, sofern Sie bei der Anpassung und Übergabe des Jobs FEK.SFEKSAMP(FEKSETUP) keine andere Position angegeben haben. Weitere Details hierzu enthält der Abschnitt Anpassungskonfiguration.
cp /usr/lpp/rdz/bin/server.zseries /etc/rdz
Welcher Port verwendet wird, erfahren Sie im Abschnitt REXEC (oder SSH) konfigurieren.
Im Communications Server IP Configuration Guide (IBM Form SC31-8775) sind die erforderlichen Konfigurationsschritte für REXEC (oder SSH) beschrieben. Anhang C. INETD konfigurieren enthält Konfigurationshinweise für Developer for System z. (Spezifische Konfigurationsschritte für Developer for System z sind nicht erforderlich.)
Ein von REXEC verwendeter allgemeiner Port ist 512. Zur Verifizierung können Sie in /etc/inetd.conf und /etc/services die verwendete Portnummer überprüfen.
exec stream tcp nowait OMVSKERN /usr/sbin/orexecd rexecd -LV
exec 512/tcp #REXEC Befehlsserver
Dasselbe Prinzip gilt für SSH. Der allgemeine Port ist 22, und der Servername ist sshd.
Für diese Anpassungstask, für die die folgenden Ressourcen oder speziellen Anpassungstasks erforderlich sind, benötigen Sie die Unterstützung eines APPC-Administrators und eines WLM-Administrators:
|
TSO Commands Service kann als ein APPC-Transaktionsprogramm FEKFRSRV implementiert werden. Diese Transaktion fungiert als ein Hostserver, der die von der Workstation abgesetzten TSO- und ISPF-Befehle ausführt. Auf der Workstation ist APPC nicht erforderlich. Der Client kommuniziert über RSE mit FEKFRSRV. Jeder Client kann gleichzeitig eine aktive Verbindung zu mehreren Hosts haben.
/* REXX - APPC-Verwaltung in ISPF-Anzeigen*/ address ISPEXEC "LIBDEF ISPMLIB DATASET ID('ICQ.ICQMLIB') STACK" "LIBDEF ISPPLIB DATASET ID('ICQ.ICQPLIB') STACK" "LIBDEF ISPSLIB DATASET ID('ICQ.ICQSLIB') STACK" "LIBDEF ISPTLIB DATASET ID('ICQ.ICQTLIB') STACK" address TSO "ALTLIB ACT APPLICATION(CLIST)", "DSN('ICQ.ICQCCLIB') UNCOND QUIET" "SELECT CMD(%ICQASRM0) NEWAPPL(ICQ) PASSLIB" address TSO "ALTLIB DEACT APPLICATION(CLIST) QUIET" "LIBDEF ISPMLIB" "LIBDEF ISPPLIB" "LIBDEF ISPSLIB" "LIBDEF ISPTLIB" exit
Fachwissen | Erforderliche Informationen:
|
Wert |
---|---|---|
APPC-Administrator | Dateiname von TPDATA
|
|
APPC-Administrator | Zu verwendender Transaktionsname (möglicherweise nicht vorhanden)
|
|
APPC-Administrator | Zu verwendende APPC-Transaktionsklasse
|
|
WLM/SRM | TSO-Leistungsgruppe und -Domäne
|
|
RACF | Jeder Benutzer von Developer for System z hat Zugriff auf ein
OMVS-Segment. (Dies ist erforderlich.)
|
|
RACF | Jeder Benutzer von Developer for System z muss Lesezugriff (READ) auf
HLQ.SFEKPROC(FEKFRSRV) haben.
|
Weitere Informationen zur Verwaltung von WLM/SRM finden Sie in der Veröffentlichung MVS Planning Workload Management (IBM Form SA22-7602). Weitere Informationen zu OMVS-Segmenten und Profilen für Dateischutz enthält der Security Server RACF Security Administrator's Guide (IBM Form SA22-7683).
CLASSADD CLASSNAME(A) MAX(20) MIN(1) MSGLIMIT(200)
Sie können Ihre TCP/IP-Konfiguration testen, indem Sie den RSE-Dämon mit dem Parameter IVP=IVP starten oder das Installationsprüfprogramm fekfivpt verwenden. Lesen Sie hierzu Installationsprüfung.
Für diese Anpassungstask benötigen Sie keine Unterstützung. Es sind auch keine speziellen Ressourcen oder Anpassungstasks erforderlich. |
Das TSO/ISPF-Client-Gateway von ISPF und SCLM Developer Toolkit speichern im Verzeichnis WORKAREA temporäre Arbeitsdateien, die vor dem Schließen der Sitzung entfernt werden. Temporäre Ausgaben bleiben jedoch manchmal enthalten. Dies ist beispielsweise der Fall, wenn während der Verarbeitung ein Kommunikationsfehler auftritt. Sie sollten den Inhalt des Verzeichnisses WORKAREA deshalb von Zeit zu Zeit löschen.
z/OS UNIX stellt das Shell-Script skulker bereit, mit dem Sie Dateien ausgehend von dem Verzeichnis, in dem sie enthalten sind, und ausgehend von ihrem Alter löschen können. In Verbindung mit dem z/OS UNIX-Dämon cron, der Befehle an angegebenen Tagen und zu vorgegebenen Zeiten ausführt, können Sie ein automatisiertes Tool konfigurieren, das das Verzeichnis WORKAREA regelmäßig bereinigt. Weitere Informationen zum Script skulker und zum Dämon cron enthält die Veröffentlichung UNIX System Services Command Reference (IBM Form SA22-7802).
Nach der vollständigen Produktanpassung können Sie die in diesem Kapitel beschriebenen IVPs (Installation Verification Programs) verwenden, um die erfolgreiche Konfiguration der zentralen Produktkomponenten zu überprüfen.
Starten Sie die gestartete Task (bzw. den Benutzerjob) JMON. Die Startinformationen in DD STDOUT sollten mit der folgenden Nachricht enden:
JM200I Server initialization complete.
Falls der Job mit dem Rückkehrcode 66 endet, ist FEK.SFEKAUTH nicht für APF berechtigt.
Starten Sie die gestartete Task (bzw. den Benutzerjob) LOCKD. Der Sperrdämon gibt nach einem erfolgreichen Start die folgende Konsolnachricht aus:
FEK501I Lock daemon started, port=4036, cleanup interval=1440, log level=1
Starten Sie die gestartete Task (bzw. den Benutzerjob) RSED mit dem Parameter IVP=IVP. Bei Verwendung dieses Parameters wird der Server nach Ausführung einiger Installationsprüftests beendet. Die Ausgabe dieser Tests ist in DD STDOUT verfügbar. Bei bestimmten Fehlern sind auch in DD STDERR Daten verfügbar. Die STDOUT-Daten sollten wie im folgenden Beispiel aussehen:
FEK002I RseDaemon started. (port=4035)
RSE daemon IVP test Wed Jul 2 17:11:52 2008 UTC uid=8(STCRSE) gid=1(STCGROUP) RSE daemon port is 4035 RSE configuration files located in /etc/rdz ------------------------------------------------------------- current environment variables ------------------------------------------------------------- @="/usr/lpp/rdz/bin/rsed.sh" @[1]="4035" @[2]="/etc/rdz" CGI_DTCONF="/var/rdz/sclmdt" CGI_DTWORK="/var/rdz" CGI_TRANTABLE="FEK.#CUST.LSTRANS.FILE" CLASSPATH=".:/usr/lpp/rdz/lib:/usr/lpp/rdz/lib/dstore_core.jar:/usr/lpp/ ERRNO="0" HOME="/tmp" IFS=" " JAVA_HOME="/usr/lpp/java/J5.0" JAVA_PROPAGATE="NO" LANG="C" LIBPATH=".:/usr/lib:/usr/lpp/java/J5.0/bin:/usr/lpp/java/J5.0/bin/classi LINENO="66" LOGNAME="STCRSE" MAILCHECK="600" OLDPWD="/tmp" OPTIND="1" PATH=".:/usr/lpp/java/J5.0/bin:/usr/lpp/rdz/bin:/usr/lpp/ispf/bin:/bin:/ PPID="33554711" PS1="\$ " PS2="> " PS3="#? " PS4="+ " PWD="/etc/rdz" RANDOM="27298" RSE_CFG="/etc/rdz" RSE_HOME="/usr/lpp/rdz" RSE_LIB="/usr/lpp/rdz/lib" SECONDS="0" SHELL="/bin/sh" STEPLIB="NONE" TZ="EST5EDT" _BPX_SHAREAS="YES" _BPX_SPAWN_SCRIPT="YES" _CEE_DMPTARG="/tmp" _CEE_RUNOPTS="ALL31(ON) HEAP(32M,32K,ANYWHERE,KEEP,,) TRAP(ON)" _CMDSERV_BASE_HOME="/usr/lpp/ispf" _CMDSERV_CONF_HOME="/etc/rdz" _CMDSERV_WORK_HOME="/var/rdz" _RSE_CMDSERV_OPTS="&SESSION=SPAWN" _RSE_DAEMON_CLASS="com.ibm.etools.zos.server.RseDaemon" _RSE_DAEMON_IVP_TEST="1" _RSE_DAEMON_PORT="4035" _RSE_JAVAOPTS=" -DISPF_OPTS='&SESSION=SPAWN' -DA_PLUGIN_PATH=/usr/lpp/rd _RSE_POOL_SERVER_CLASS="com.ibm.etools.zos.server.ThreadPoolProcess" _RSE_PWD="/tmp" _RSE_SERVER_CLASS="org.eclipse.dstore.core.server.Server" _RSE_SERVER_TIMEOUT="120000" _SCLMDT_BASE_HOME="/usr/lpp/rdz" _SCLMDT_CONF_HOME="/var/rdz/sclmdt" _SCLMDT_TRANTABLE="FEK.#CUST.LSTRANS.FILE" _SCLMDT_WORK_HOME="/var/rdz" _SCLM_BASE="/var/rdz/WORKAREA" _SCLM_BWBCALL="/usr/lpp/rdz/bin/BWBCALL" _SCLM_DWGET="/var/rdz/WORKAREA" _SCLM_DWTRANSFER="/var/rdz/WORKAREA" _SCLM_J2EEPUT="/var/rdz/WORKAREA" ------------------------------------------------------------- java startup test... ------------------------------------------------------------- java version "1.5.0" Java(TM) 2 Runtime Environment, Standard Edition (build pmz31dev-2008031 IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 z/OS s390-31 j9vmmz3123-2008 J9VM - 20080314_17962_bHdSMr JIT - 20080130_0718ifx2_r8 GC - 200802_08) JCL - 20080314 ------------------------------------------------------------- TCP/IP IVP test... ------------------------------------------------------------- Wed Jul 2 13:11:54 EDT 2008 uid=8(STCRSE) gid=1(STCGROUP) using /etc/rdz/rsed.envvars ------------------------------------------------------------- TCP/IP resolver configuration (z/OS UNIX search order): ------------------------------------------------------------- Resolver Trace Initialization Complete -> 2008/07/02 13:11:54.745964 res_init Resolver values: Global Tcp/Ip Dataset = None Default Tcp/Ip Dataset = None Local Tcp/Ip Dataset = /etc/resolv.conf Translation Table = Default UserId/JobName = STCRSE Caller API = LE C Sockets Caller Mode = EBCDIC (L) DataSetPrefix = TCPIP (L) HostName = CDFMVS08 (L) TcpIpJobName = TCPIP (L) DomainOrigin = RALEIGH.IBM.COM (L) NameServer = 9.42.206.2 9.42.206.3 (L) NsPortAddr = 53 (L) ResolverTimeout = 10 (L) ResolveVia = UDP (L) ResolverUdpRetries = 1 (*) Options NDots = 1 (*) SockNoTestStor (*) AlwaysWto = NO (L) MessageCase = MIXED (*) LookUp = DNS LOCAL res_init Succeeded res_init Started: 2008/07/02 13:11:54.755363 res_init Ended: 2008/07/02 13:11:54.755371 ************************************************************************ MVS TCP/IP NETSTAT CS V1R9 TCPIP Name: TCPIP 13:11:54 Tcpip started at 01:28:36 on 06/23/2008 with IPv6 enabled ------------------------------------------------------------- host IP address: ------------------------------------------------------------- hostName=CDFMVS08 hostAddr=9.42.112.75 bindAddr=9.42.112.75 localAddr=9.42.112.75 Success, addresses match ------------------------------------------------------------- PassTicket IVP test... ------------------------------------------------------------- Success, PassTicket IVP finished normally ------------------------------------------------------------- RSE daemon IVP ended
Die Installation von Developer for System z stellt mehrere Installationsprüfprogramme (IVP, Installation Verification Programs) für die Basisservices und die optionalen Services bereit. Die IVP-Scripts befinden sich im Installationsverzeichnis (standardmäßig /usr/lpp/rdz/bin/).
fekfivpa | Verbindung zu TSO Commands Service mit APPC (optional) |
fekfivpd | RSE-Dämonverbindung |
fekfivpi | Verbindung mit TSO/ISPF-Client-Gateway von ISPF |
fekfivpj | JES Job Monitor-Verbindung |
fekfivpl | Sperrdämonverbindung |
fekfivpr | REXEC-Verbindung (optional) |
fekfivps | SCLMDT-Verbindung (optional) |
fekfivpt | TCP/IP konfigurieren |
fekfivpz | REXEC/SSH-Shell-Script (optional) |
Für die nachfolgenden Tasks wird vorausgesetzt, dass Sie aktivierter z/OS UNIX-Benutzer sind. Zum Aktivieren können Sie den TSO-Befehl OMVS absetzen. Mit dem Befehl exit können Sie zu TSO zurückkehren.
Für die Benutzer-ID, die die Installationsprüfprogramme (Installation Verification Programs, IVPs) ausführt, ist eine große Regionsgröße erforderlich, weil speicherintensive Funktionen (wie beispielsweise Java) ausgeführt werden. Sie sollten die Regionsgröße auf 131.072 Kilobyte (128 Megabyte) oder mehr setzen.
Das folgende Fehlerbeispiel ist ein deutliches Anzeichen für eine nicht ausreichende Regionsgröße. (Es können auch andere Fehler auftreten; z. B. schlägt das Starten von Java möglicherweise fehl.)
CEE5213S The signal SIGPIPE was received. %z/OS UNIX command%: command was killed by signal number 13 %line-number% *-* %REXX command% RC(137)
Bei allen Beispielbefehlen in diesem Abschnitt wird vorausgesetzt, dass bestimmte Umgebungsvariablen gesetzt sind. Wenn das der Fall ist, sind die IVP-Scripts über die Anweisung PATH verfügbar, und die Position der angepassten Konfigurationsdateien ist bekannt. Verwenden Sie die Befehle pwd und cd, um Ihr aktuelles Verzeichnis zu prüfen und das Verzeichnis mit den angepassten Konfigurationsdateien aufzurufen. Danach können Sie mit dem Shell-Script ivpinit die RSE-Umgebungsvariablen setzen. Sehen Sie sich hierzu das folgende Beispiel an ("$" ist die z/OS UNIX-Eingabeaufforderung):
$ pwd /u/userid $ cd /etc/rdz $ . ./ivpinit RSE configuration files located in /etc/rdz --default added /usr/lpp/rdz/bin to PATH
Der erste Punkt (".") in . ./ivpinit ist ein z/OS UNIX-Befehl zur Ausführung der Shell in der aktuellen Umgebung, damit die in der Shell gesetzten Umgebungsvariablen auch nach dem Beenden der Shell in Kraft bleiben. Der zweite Punkt bezieht sich auf das aktuelle Verzeichnis.
/usr/lpp/rdz/bin/fekfivpr 512 USERIDDie meisten fekfivp*-Scripts fordern außerdem die Position der angepassten Datei rsed.envvars an, wenn . ./ivpinit nicht zuerst ausgeführt wird.
$ EXPORT STEPLIB=$STEPLIB:TCPIP.SEZALOAD
Wenn zu einer vorhandenen STEPLIB eine Bibliothek ohne APF-Berechtigung hinzugefügt wird, werden die APF-Berechtigungen der vorhandenen STEPLIB-Dateien entfernt.
Beachten Sie auch, dass TCPIP.SEZALOAD vor CEE.SCEELKED eingefügt werden muss, wenn CEE.SCEELKED in LINKLIST oder STEPLIB verwendet wird. Andernfalls wird für die TCP/IP-REXX-Socketaufrufe ein Systemabbruch 0C1 ausgegeben.
Informationen zur Diagnostizierung von RSE-Verbindungsproblemen können Sie Konfigurationsprobleme lösen oder den technischen Hinweisen auf der Supportseite für Developer for System z (http://www-306.ibm.com/software/awdtools/rdz/support/) entnehmen.
Die Portverfügbarkeit für JES Job Monitor, den RSE-Dämon sowie optional für REXEC oder SSH können Sie durch Absetzen des Befehls netstat prüfen. Das Ergebnis sollte die von diesen Services verwendeten Ports zeigen. Sehen Sie sich dazu die folgenden Beispiele an ($ ist die z/OS UNIX-Eingabeaufforderung):
IPV4
$ netstat MVS TCP/IP NETSTAT CS VxRy TCPIP Name: TCPIP 13:57:36 User Id Conn Local Socket Foreign Socket State ------- ---- ------------ -------------- ----- RSED 0000004B 0.0.0.0..4035 0.0.0.0..0 Listen LOCKD 0000004C 0.0.0.0..4036 0.0.0.0..0 Listen JMON 00000037 0.0.0.0..6715 0.0.0.0..0 Listen
IPV6
$ netstat MVS TCP/IP NETSTAT CS VxRy TCPIP Name: TCPIP 14:03:35 User Id Conn State ------- ---- ----- RSED 0000004B Listen Local Socket: 0.0.0.0..4035 Foreign Socket: 0.0.0.0..0 LOCKD 0000004C Listen Local Socket: 0.0.0.0..4036 Foreign Socket: 0.0.0.0..0 JMON 00000037 Listen Local Socket: 0.0.0.0..6715 Foreign Socket: 0.0.0.0..0
Wenn Sie APPC für TSO Commands Service verwenden, ist Developer for System z bei der Initialisierung darauf angewiesen, dass TCP/IP mit dem richtigen Hostnamen konfiguriert ist. Dies impliziert, dass die verschiedenen TCP/IP- und Resolverkonfigurationsdateien ordnungsgemäß definiert sein müssen. Weitere Informationen zur TCP/IP- und Resolverkonfiguration enthält Anhang B. TCP/IP konfigurieren. Führen Sie den folgenden Befehl aus, um die aktuellen Einstellungen zu überprüfen:
fekfivpt
Der Befehl sollte eine Ausgabe wie im folgenden Beispiel zurückgeben ($ ist die z/OS UNIX-Eingabeaufforderung):
$ fekfivpt Wed Jul 2 13:11:54 EDT 2008 uid=1(USERID) gid=0(GROUP) using /etc/rdz/rsed.envvars current address space size limit is 1914675200 (1826.0 MB) maximum address space size limit is 2147483647 (2048.0 MB) ------------------------------------------------------------- TCP/IP resolver configuration (z/OS UNIX search order): ------------------------------------------------------------- Resolver Trace Initialization Complete -> 2008/07/02 13:11:54.745964 res_init Resolver values: Global Tcp/Ip Dataset = None Default Tcp/Ip Dataset = None Local Tcp/Ip Dataset = /etc/resolv.conf Translation Table = Default UserId/JobName = USERID Caller API = LE C Sockets Caller Mode = EBCDIC (L) DataSetPrefix = TCPIP (L) HostName = CDFMVS08 (L) TcpIpJobName = TCPIP (L) DomainOrigin = RALEIGH.IBM.COM (L) NameServer = 9.42.206.2 9.42.206.3 (L) NsPortAddr = 53 (L) ResolverTimeout = 10 (L) ResolveVia = UDP (L) ResolverUdpRetries = 1 (*) Options NDots = 1 (*) SockNoTestStor (*) AlwaysWto = NO (L) MessageCase = MIXED (*) LookUp = DNS LOCAL res_init Succeeded res_init Started: 2008/07/02 13:11:54.755363 res_init Ended: 2008/07/02 13:11:54.755371 ************************************************************************ MVS TCP/IP NETSTAT CS V1R9 TCPIP Name: TCPIP 13:11:54 Tcpip started at 01:28:36 on 06/23/2008 with IPv6 enabled ------------------------------------------------------------- host IP address: ------------------------------------------------------------- hostName=CDFMVS08 hostAddr=9.42.112.75 bindAddr=9.42.112.75 localAddr=9.42.112.75 Success, addresses match
Führen Sie den folgenden Befehl aus, um die RSE-Dämonverbindung zu überprüfen. Ersetzen Sie 4035 durch den vom RSE-Dämon verwendeten Port und USERID durch eine gültige Benutzer-ID.
fekfivpd 4035 USERID
Nach einer Aufforderung zur Kennworteingabe sollte der Befehl eine Ausgabe wie im folgenden Beispiel zurückgeben ($ ist die z/OS UNIX-Eingabeaufforderung):
$ fekfivpd 4035 USERID Wed Jul 2 15:00:27 EDT 2008 uid=1(USERID) gid=0(GROUP) using /etc/rdz/rsed.envvars current address space size limit is 1914675200 (1826.0 MB) maximum address space size limit is 2147483647 (2048.0 MB) Password: SSL is disabled connected 8108 570655399 Success
Führen Sie den folgenden Befehl aus, um die JES Job Monitor-Verbindung zu überprüfen. Ersetzen Sie 6715 durch die Portnummer von JES Job Monitor.
fekfivpj 6715
Der Befehl sollte die Bestätigungsnachricht von JES Job Monitor zurückgeben. Vergleichen Sie hierzu das folgende Beispiel ($ ist die z/OS UNIX-Eingabeaufforderung):
$ fekfivpj 6715 Wed Jul 2 15:00:27 EDT 2008 uid=1(USERID) gid=0(GROUP) using /etc/rdz/rsed.envvars current address space size limit is 1914675200 (1826.0 MB) maximum address space size limit is 2147483647 (2048.0 MB) hostName=CDFMVS08 hostAddr=9.42.112.75 Waiting for JES Job Monitor response... ACKNOWLEDGE01v03 Success
Führen Sie den folgenden Befehl aus, um die Sperrdämonverbindung zu überprüfen.
fekfivpl
Der Befehl sollte eine Ausgabe wie im folgenden Beispiel zurückgeben ($ ist die z/OS UNIX-Eingabeaufforderung):
$ fekfivpl Mon Jun 29 08:00:38 EDT 2009 uid=1(USERID) gid=0(GROUP) using /etc/rdz/rsed.envvars current address space size limit is 1914675200 (1826.0 MB) maximum address space size limit is 2147483647 (2048.0 MB) hostName=CDFMVS08 hostAddr=9.42.112.75 Registering user to Lock Daemon... Waiting for Lock Daemon response... Querying to Lock Daemon... Waiting for Lock Daemon response... USERID Unregistering user from Lock Daemon... Waiting for Lock Daemon response... Querying to Lock Daemon... Waiting for Lock Daemon response... Success
Überprüfen Sie die Verbindung mit dem TSO/ISPF-Client-Gateway von ISPF, indem Sie den folgenden Befehl ausführen:
fekfivpi
Der Befehl sollte die Ergebnisse der auf das TSO/ISPF-Client-Gateway von ISPF bezogenen Überprüfungen zurückgeben (Variablen, HFS-Module, Start und Stopp der TSO/ISPF-Sitzung). Vergleichen Sie hierzu das folgende Beispiel ($ ist die z/OS UNIX-Eingabeaufforderung):
$ fekfivpi Wed Jul 2 15:00:27 EDT 2008 uid=1(USERID) gid=0(GROUP) using /etc/rdz/rsed.envvars current address space size limit is 1914675200 (1826.0 MB) maximum address space size limit is 2147483647 (2048.0 MB) ------------------------------------------------------------- /etc/rdz/ISPF.conf content: ------------------------------------------------------------- ispmlib=ISP.SISPMENU isptlib=ISP.SISPTENU ispplib=ISP.SISPPENU ispslib=ISP.SISPSLIB sysproc=ISP.SISPCLIB,FEK.SFEKPROC ------------------------------------------------------------- Host install verification for RSE Review IVP log messages from HOST below : ------------------------------------------------------------- RSE connection and base TSO/ISPF session initialization check only *** CHECK : ENVIRONMENT VARIABLES - key variables displayed below : Server PATH = /usr/lpp/java/J5.0/bin:/usr/lpp/rdz/lib:/usr/lpp/ispf/bin: /bin:/usr/sbin:. STEPLIB = FEK.SFEKAUTH:FEK.SFEKLOAD _CMDSERV_BASE_HOME = /usr/lpp/ispf _CMDSERV_CONF_HOME = /etc/rdz _CMDSERV_WORK_HOME = /var/rdz ------------------------------------------------------------- *** CHECK : USS MODULES Checking ISPF Directory : /usr/lpp/ispf Checking modules in /usr/lpp/ispf/bin directory Checking for ISPF configuration file ISPF.conf RC=0 MSG: SUCCESSFUL ------------------------------------------------------------- *** CHECK : TSO/ISPF INITIALIZATION ( TSO/ISPF session will be initialized ) RC=0 MSG: SUCCESSFUL ------------------------------------------------------------- *** CHECK: Shutting down TSO/ISPF IVP session RC=0 MSG: SUCCESSFUL ------------------------------------------------------------- Host installation verification completed successfully -------------------------------------------------------------
Der Befehl fekfivpi kann mit den folgenden optionalen, nicht positionsgebundenen Parametern verwendet werden:
Überprüfen Sie die Verbindung mit dem TSO-Befehlsserver (bei Verwendung von APPC), indem Sie den folgenden Befehl ausführen. Ersetzen Sie USERID durch eine gültige Benutzer-ID:
fekfivpa USERID
Nach einer Aufforderung zur Kennworteingabe sollte der Befehl den APPC-Dialog zurückgeben. Sehen Sie sich dazu das folgende Beispiel an ($ ist die z/OS UNIX-Eingabeaufforderung):
$ fekfivpa USERID Enter password: Wed Jul 2 15:00:27 EDT 2008 uid=1(USERID) gid=0(GROUP) using /etc/rdz/rsed.envvars current address space size limit is 1914675200 (1826.0 MB) maximum address space size limit is 2147483647 (2048.0 MB) 20070607 13:57:18.584060 /usr/lpp/rdz/bin/fekfscmd: version=Oct 2003 20070607 13:57:18.584326 Input parms: 1.2.3.4 * NOTRACE USERID ******** 20070607 13:57:18.586800 APPC: Allocate succeeded 20070607 13:57:18.587022 Conversation id is 0DDBD3F80000000D 20070607 13:57:18.587380 APPC: Set Send Type succeeded 20070607 13:57:26.736674 APPC: Confirm succeeded 20070607 13:57:26.737027 Req to send recd value is 0 20070607 13:57:26.737546 APPC: SEND_DATA return_code = 0 20070607 13:57:26.737726 request_to_send_received = 0 20070607 13:57:26.737893 Send Data succeeded 20070607 13:57:26.738169 APPC: Set Prepare to Receive type succeeded 20070607 13:57:26.738580 APPC: Prepare to Receive succeeded 20070607 13:57:26.808899 APPC: Receive data 20070607 13:57:26.809122 RCV return_code = 0 20070607 13:57:26.809270 RCV data_received= 2 20070607 13:57:26.809415 RCV received_length= 29 20070607 13:57:26.809556 RCV status_received= 4 20070607 13:57:26.809712 RCV req_to_send= 0 20070607 13:57:26.809868 Receive succeeded :IP: 0 9.42.112.75 1674 50246 20070607 13:57:26.810533 APPC: CONFIRMED succeeded
Überprüfen Sie die Verbindung zu SCLM Developer Toolkit, indem Sie den folgenden Befehl ausführen:
fekfivps
Der Befehl sollte die Ergebnisse der auf SCLM Developer Toolkit bezogenen Überprüfungen zurückgeben (Variablen, HFS-Module, REXX-Laufzeit, Start und Stopp der TSO/ISPF-Sitzung). Vergleichen Sie hierzu das folgende Beispiel ($ ist die z/OS UNIX-Eingabeaufforderung):
$ fekfivps Wed Jul 2 15:00:27 EDT 2008 uid=1(USERID) gid=0(GROUP) using /etc/rdz/rsed.envvars current address space size limit is 1914675200 (1826.0 MB) maximum address space size limit is 2147483647 (2048.0 MB) ------------------------------------------------------------- /etc/rdz/ISPF.conf content: ------------------------------------------------------------- ispmlib=ISP.SISPMENU isptlib=ISP.SISPTENU ispplib=ISP.SISPPENU ispslib=ISP.SISPSLIB sysproc=ISP.SISPCLIB,FEK.SFEKPROC ------------------------------------------------------------- Host install verification for RSE Review IVP log messages from HOST below : ------------------------------------------------------------- *** CHECK : ENVIRONMENT VARIABLES - key variables displayed below : Server PATH = /usr/lpp/java/J5.0/bin:/usr/lpp/rdz/lib:/usr/lpp/ispf/bin: /bin:/usr/sbin:. STEPLIB = FEK.SFEKAUTH:FEK.SFEKLOAD _CMDSERV_BASE_HOME = /usr/lpp/ispf _CMDSERV_CONF_HOME = /etc/rdz _CMDSERV_WORK_HOME = /var/rdz _SCLMDT_CONF_HOME = /var/rdz/sclmdt _SCLMDT_WORK_HOME = /var/rdz _SCLMDT_TRANTABLE = FEK.#CUST.LSTRANS.FILE ------------------------------------------------------------- *** CHECK : JAVA PATH SETUP VERIFICATION RC=0 MSG: SUCCESSFUL ------------------------------------------------------------- *** CHECK : USS MODULES Checking ISPF Directory : /usr/lpp/ispf Checking modules in /usr/lpp/ispf/bin directory Checking for ISPF configuration file ISPF.conf Checking install bin Directory : /usr/lpp/rdz/bin RC=0 MSG: SUCCESSFUL ------------------------------------------------------------- *** CHECK : REXX RUNTIME ENVIRONMENT RC=0 MSG: SUCCESSFUL ------------------------------------------------------------- *** CHECK : TSO/ISPF INITIALIZATION ( TSO/ISPF session will be initialized ) RC=0 MSG: SUCCESSFUL ------------------------------------------------------------- *** CHECK: Shutting down TSO/ISPF IVP session RC=0 MSG: SUCCESSFUL ------------------------------------------------------------- Host installation verification completed successfully -------------------------------------------------------------
Der Befehl fekfivps kann mit den folgenden optionalen, nicht positionsgebundenen Parametern verwendet werden:
Führen Sie den folgenden Befehl aus, um die REXEC-Verbindung zu überprüfen. Ersetzen Sie 512 durch den von REXEC verwendeten Port und USERID durch eine gültige Benutzer-ID.
fekfivpr 512 USERID
Nachdem der Befehl Sie zur Eingabe eines Kennworts aufgefordert hat, sollte er den REXEC-Trace, eine Warnung zum Zeitlimit, die Java-Version und die RSE-Servernachricht zurückgeben. Sehen Sie sich hierzu das folgende Beispiel an ("$" ist die z/OS UNIX-Eingabeaufforderung):
$ fekfivpr 512 USERID Enter password: Wed Jul 2 15:00:27 EDT 2008 uid=1(USERID) gid=0(GROUP) using /etc/rdz/rsed.envvars current address space size limit is 1914675200 (1826.0 MB) maximum address space size limit is 2147483647 (2048.0 MB) $ EZYRC01I Calling function rexec_af with the following: EZYRC02I Host: CDFMVS08, user USERID, cmd cd /etc/rdz;export RSE_USER_ID=USERI D;./server.zseries -ivp, port 512 EZYRC19I Data socket = 4, Control socket = 6. RSE server IVP test CDFMVS08 -- Wed Jul 2 15:00:27 EDT 2008 uid=1(USERID) gid=0(GROUP) RSE configuration files located in /etc/rdz --default RSE userid is USERID --default ------------------------------------------------------------- Address Space size limits ------------------------------------------------------------- current address space size limit is 2147483647 (2048.0 MB) maximum address space size limit is 2147483647 (2048.0 MB) ------------------------------------------------------------- service history ------------------------------------------------------------- Fri Jun 19 00:01:00 2009 -- COPY -- HHOP760 v7600 created 18 Jun 2009 ------------------------------------------------------------- expect to see time out messages after a successful IVP test ------------------------------------------------------------- starting RSE server in background -- Fri Jun 19 15:59:05 EDT 2009 ------------------------------------------------------------- java version "1.5.0" Java(TM) 2 Runtime Environment, Standard Edition (build pmz31dev-20070201 (SR4)) IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 z/OS s390-31 j9vmmz3123-20070201 (JI T enabled) J9VM - 20070131_11312_bHdSMr JIT - 20070109_1805ifx1_r8 GC - 200701_09) JCL - 20070126 DStore Server Starting... Server Started Successfully 8108 Server running on: CDFMVS08
Connection error Server: error initializing socket: java.net.SocketTimeoutException: Accept timed out
Wenn Sie den vorherigen IVP-Test aus dem Abschnitt REXEC-Verbindung (optional) erfolgreich beendet haben, können Sie diesen Test überspringen.
Führen Sie den folgenden Befehl aus, um das von der REXEC- und SSH-Verbindung verwendete Shell-Script zu überprüfen:
fekfivpz
Der Befehl sollte eine Warnung zum Zeitlimit, die Java-Version und die RSE-Servernachricht zurückgeben. Sehen Sie sich hierzu das folgende Beispiel an ("$" ist die z/OS UNIX-Eingabeaufforderung):
$ fekfivpz Wed Jul 2 15:00:27 EDT 2008 uid=1(USERID) gid=0(GROUP) using /etc/rdz/rsed.envvars current address space size limit is 1914675200 (1826.0 MB) maximum address space size limit is 2147483647 (2048.0 MB) ------------------------------------------------------------- RSE server IVP test CDFMVS08 -- Wed Jul 2 15:00:27 EDT 2008 uid=1(USERID) gid=0(GROUP) RSE configuration files located in /etc/rdz --default RSE userid is USERID --default ------------------------------------------------------------- Address Space size limits ------------------------------------------------------------- current address space size limit is 2147483647 (2048.0 MB) maximum address space size limit is 2147483647 (2048.0 MB) ------------------------------------------------------------- service history ------------------------------------------------------------- Fri Jun 19 00:01:00 2009 -- COPY -- HHOP760 v7600 created 18 Jun 2009 ------------------------------------------------------------- expect to see time out messages after a successful IVP test ------------------------------------------------------------- starting RSE server in background -- Fri Jun 19 15:59:05 EDT 2009 ------------------------------------------------------------- java version "1.5.0" Java(TM) 2 Runtime Environment, Standard Edition (build pmz31dev-20070201 (SR4)) IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 z/OS s390-31 j9vmmz3123-20070201 (JI T enabled) J9VM - 20070131_11312_bHdSMr JIT - 20070109_1805ifx1_r8 GC - 200701_09) JCL - 20070126 DStore Server Starting... Server Started Successfully 8108 Server running on: CDFMVS08
Connection error Server: error initializing socket: java.net.SocketTimeoutException: Accept timed out
In diesem Kapitel erhalten Sie einen Überblick über die für Developer for System z verfügbaren Bedienerbefehle (oder Konsolbefehle). Wenn Sie sich nicht mit den Syntaxdiagrammen auskennen, die zur Erläuterung des Befehlsformats verwendet werden, lesen Sie die Informationen im Abschnitt Hinweise zum Lesen eines Syntaxdiagramms.
Mit dem Befehl START können Sie eine gestartete Task (STC) dynamisch starten. Die abgekürzte Fassung des Befehls ist der Buchstabe S.
Mit dem Befehl MODIFY können Sie Kenndaten einer aktiven Task dynamisch abfragen und ändern. Die abgekürzte Fassung des Befehls ist der Buchstabe F.
<Client-ID> : <Benutzer-ID> : <verbunden seit>
ProcessId(<Prozess-ID>) Memory Usage(<Belegung des Java-Heapspeichers>%) Clients(<Anzahl der Clients>) Order(<Startreihenfolge>) <Fehlerstatus>
In normalen Situationen ist <Fehlerstatus> leer. In Tabelle 18 sind die möglichen, nicht leeren Werte für <Fehlerstatus> dokumentiert.
Status | Beschreibung |
---|---|
*severe error* | Der Thread-Pool-Prozess hat einen nicht behebbaren Fehler festgestellt und die Operationen angehalten. In den anderen Statusfeldern werden die letzten bekannten Werte angezeigt. Verwenden Sie die Option CLEANUP des Änderungsbefehls DISPLAY PROCESS, um diesen Eintrag aus der Tabelle zu entfernen. |
*killed process* | Der Thread-Pool-Prozess wurde durch Java, z/OS UNIX oder einen Bedienerbefehl abgebrochen. In den anderen Statusfeldern werden die letzten bekannten Werte angezeigt. Verwenden Sie die Option CLEANUP des Änderungsbefehls DISPLAY PROCESS, um diesen Eintrag aus der Tabelle zu entfernen. |
*timeout* | Der Thread-Pool-Prozess hat dem RSE-Dämon während einer Clientverbindungsanforderung nicht zeitnah geantwortet. In den anderen Statusfeldern werden die aktuellen Werte angezeigt. Der Thread-Pool wird in zukünftigen Clientverbindungsanforderungen ausgeschlossen. Der Status *timeout* wird zurückgesetzt, wenn sich ein Client abmeldet, der von diesem Thread-Pool bereitgestellt wurde. |
Es werden weitere Informationen bereitgestellt, wenn die Option "DETAIL" des Änderungsbefehls DISPLAY PROCESS verwendet wird:
ProcessId(33555087) ASId(002E) JobName(RSED8) Order(1) PROCESS LIMITS: CURRENT HIGHWATER LIMIT JAVA HEAP USAGE(%) 10 56 100 CLIENTS 0 25 60 MAXFILEPROC 83 103 64000 MAXPROCUSER 97 99 200 MAXTHREADS 9 14 1500 MAXTHREADTASKS 9 14 1500
Das Feld 'ASId' ist die Adressraum-ID in Hexadezimalschreibweise. Die Tabelle zum Verarbeitungslimit zeigt die aktuelle Ressourcennutzung, die obere Grenze für die Ressourcennutzung und die Ressourcengrenze an. Beachten Sie, dass die definierte Grenze aufgrund von anderen Begrenzungsfaktoren möglicherweise nie erreicht wird.
E oder 0 oder OFF | Nur Fehlernachrichten |
W oder 1 | Fehlernachrichten und Warnungen. Dies ist die Standardeinstellung in rsecomm.properties. |
I oder 2 oder ON | Fehlernachrichten, Warnungen und Informationsnachrichten |
Ein detaillierter Trace bringt Leistungseinbußen mit sich und sollte nur auf Anweisung des IBM Support Center durchgeführt werden.
E oder 0 oder OFF | Nur Fehlernachrichten |
I oder 2 oder ON | Fehlernachrichten, Warnungen und Informationsnachrichten |
Ein detaillierter Trace bringt Leistungseinbußen mit sich und sollte nur auf Anweisung des IBM Support Center durchgeführt werden.
E oder 0 oder OFF | Nur Fehlernachrichten |
I oder 2 oder ON | Fehlernachrichten, Warnungen und Informationsnachrichten |
Ein detaillierter Trace bringt Leistungseinbußen mit sich und sollte nur auf Anweisung des IBM Support Center durchgeführt werden.
Ein detaillierter Trace bringt Leistungseinbußen mit sich und sollte nur auf Anweisung des IBM Support Center durchgeführt werden.
BPXM023I (stclock) Datei[(Member)] NOT LOCKED BPXM023I (stclock) Datei[(Member)] LOCKED BY Benutzer-ID
Wenn es dem RSE-Server nicht möglich ist, den Client mit dem Sperrdämon zu registrieren, wird die Konsolnachricht FEK513W generiert. Die in dieser Nachricht aufgeführten ASID- und TCB-Werte können mit der Ausgabe des Bedienerbefehls D GRS,RES=(*,Datei[(Member)]) verglichen werden, um zu ermitteln, welcher derzeitige Benutzer die Sperre hält.
Mit dem Befehl STOP können Sie eine aktive Task stoppen. Die abgekürzte Fassung des Befehls ist der Buchstabe P.
Es gibt keine produktspezifischen Konsolnachrichten für JES Job Monitor. Der Server greift für Aktionen, die von der Clientkomponente von Developer for System z ausgeführt werden, auf die von z/OS und JES generierten Konsolnachrichten zurück.
In Tabelle 19 werden die produktspezifischen Konsolnachrichten aufgelistet, die vom RSE-Dämon, vom RSE-Thread-Pool-Server und vom Sperrdämon generiert werden.
Nachrichten-ID | Nachrichtentext |
---|---|
FEK001I | RseDaemon being initialized in {0} bit mode |
FEK002I | RseDaemon started. (port={0}) |
FEK003I | Stop command being processed |
FEK004I | RseDaemon: Max Heap Size={0}MB and private AS Size={1}MB |
FEK005I | Server process started. (processId={0}) |
FEK009I | RseDaemon is waiting for the server process to start. |
FEK010I | (rsed.envvars location = {0}) |
FEK011I | (log directory = {0}) |
FEK100E | Daemon port/timeout value must be digits |
FEK101E | JRE {0} or higher required |
FEK102E | Invalid arguments received: {0} |
FEK103E | Almost Disk-Full in {0} |
FEK104E | Maximum number of processes has been reached |
FEK105E | Error in sending audit data (rc={0}) |
FEK110E | socket() failed. reason=({0}) |
FEK111E | setsockopt() failed. reason=({0}) |
FEK112E | bind() failed. reason=({0}) |
FEK113E | listen() failed. reason=({0}) |
FEK114E | accept() failed. reason=({0}) |
FEK115E | write() failed. reason=({0}) |
FEK116E | pipe() failed. reason=({0}) |
FEK117E | socketpair() failed. reason=({0}) |
FEK118E | select() failed. reason=({0}) |
FEK119E | _console() failed. reason=({0}) |
FEK130E | gsk_environment_open() failed. reason=({0}) |
FEK131E | gsk_attribute_set_enum(GSK_PROTOCOL_SSLV2) failed. reason=({0}) |
FEK132E | gsk_attribute_set_enum(GSK_PROTOCOL_SSLV3) failed. reason=({0}) |
FEK133E | gsk_attribute_set_enum(GSK_PROTOCOL_TLSV1) failed. reason=({0}) |
FEK134E | gsk_attribute_set_buffer(GSK_KEYRING_FILE) failed. reason=({0}) |
FEK135E | gsk_attribute_set_buffer(GSK_KEYRING_PW) failed. reason=({0}) |
FEK136E | gsk_environment_init() failed. reason=({0}) |
FEK137E | gsk_secure_socket_open() failed. reason=({0}) |
FEK138E | gsk_attribute_set_numeric_value(GSK_FD) failed. reason=({0}) |
FEK139E | gsk_attribute_set_buffer(GSK_KEYRING_LABEL) failed. reason=({0}) |
FEK140E | gsk_attribute_set_enum(GSK_SESSION_TYPE) failed. reason=({0}) |
FEK141E | gsk_attribute_set_callback(GSK_IO_CALLBACK) failed. reason=({0}) |
FEK142E | gsk_secure_socket_init() failed. reason=({0}) |
FEK143E | gsk_attribute_set_enum(GSK_CLIENT_AUTH_TYPE) failed. reason=({0}) |
FEK144E | gsk_get_cert_info failed. reason=({0}) |
FEK145E | gsk_secure_socket_read() failed. reason=({0}) |
FEK146E | gsk_secure_socket_write() failed. reason=({0}) |
FEK150E | RseDaemon abnormally terminated; {0} |
FEK201I | {0} Command has been processed |
FEK202E | Invalid Command Entered |
FEK203E | Invalid Display Command: Display Process|Client |
FEK204E | Invalid Cancel Command: Cancel ID=|User= |
FEK205E | Command was not processed owing to consecutive SWITCHs |
FEK206E | Audit Log facility is not active |
FEK207I | No Client to be displayed |
FEK208I | {0} canceled |
FEK209I | No Process to be displayed |
FEK210I | {0} canceled owing to duplicate logon |
FEK501I | Lock daemon started, port={0}, cleanup interval={1}, log level={2} |
FEK502I | Lock daemon terminating |
FEK510E | Lock daemon, missing port |
FEK511E | Lock daemon, wrong port, port={0} |
FEK512E | Lock daemon, socket error, port={0} |
FEK513W | Lock daemon, registration failed, ASID={0}, TCB={1}, USER={2} |
FEK514W | Lock daemon, wrong log level, log level={0} |
BPXM023I | (stclock) Datei[(Member)] NOT LOCKED |
BPXM023I | (stclock) Datei[(Member)] LOCKED BY Benutzer-ID |
BPXM023I | (stclock) Befehl, WRONG COMMAND |
BPXM023I | (stclock) Befehl, MISSING ARGUMENT |
BPXM023I | (stclock) Argument, WRONG ARGUMENT |
Das Syntaxdiagramm zeigt Ihnen, wie ein Befehl angegeben werden muss, damit das Betriebssystem Ihre Eingabe ordnungsgemäß interpretieren kann. Das Syntaxdiagramm wird von links nach rechts und von oben nach unten gelesen. Folgen Sie dabei der horizontalen Linie (dem Hauptpfad).
In Syntaxdiagrammen werden die folgenden Symbole verwendet:
Symbol | Beschreibung |
---|---|
>> | Markiert den Anfang des Syntaxdiagramms |
> | Zeigt an, dass das Syntaxdiagramm fortgesetzt wird |
| | Markiert Anfang und Ende eines Fragments oder Abschnitts des Syntaxdiagramms |
>< | Markiert das Ende des Syntaxdiagramms |
In Syntaxdiagrammen werden die folgenden Arten von Operanden verwendet:
>>--ERFORDERLICHER_OPERAND--><
>>-*------------------*->< *-OPTIONALER_OPERAND-*
*-STANDARDOPERAND-* >>-*-----------------*-><
Operanden werden als Schlüsselwörter oder Variablen klassifiziert:
Im folgenden Beispiel ist der Befehl USER ein Schlüsselwort. Der erforderliche variable Parameter ist Benutzer-ID, und der optionale variable Parameter ist Kennwort. Ersetzen Sie die variablen Parameter durch Ihre eigenen Werte:
>>--USER--Benutzer-ID-*----------*---------------------------------->< *-Kennwort-*
Wenn ein Diagramm ein Zeichen enthält, das kein alphanumerisches Zeichen ist (z. B. Klammern, Punkte, Kommata, Gleichheitszeichen und Leerzeichen), müssen Sie das Zeichen als Teil der Syntax eingeben. In diesem Beispiel muss die Eingabe OPERAND=(001 0.001) lauten:
>>--OPERAND--=--(--001-- --0.001--)------------------------><
Ein nach links weisender Pfeil in einer Gruppe von Operanden bedeutet, dass mehr als ein Operand ausgewählt oder ein einzelner Operand wiederholt werden kann:
>>--*----------------------*---------------------------->< *-WIEDERHOLBARER_OPERAND_1-* *-WIEDERHOLBARER_OPERAND_2-* *-<--------------------*
Wenn ein Diagramm mehr als eine Zeile umfasst, endet die erste Zeile mit einer einzelnen Pfeilspitze und die zweite Zeile beginnt mit einer einzelnen Pfeilspitze:
>>--| Die erste Zeile des Syntaxdiagramms, das mehr als eine Zeile umfasst |--> >--| Die Fortsetzung der Unterbefehle und/oder Parameter |---------><
Einige Diagramme können Syntaxfragmente enthalten, die zur Unterteilung zu langer oder zu komplexer Diagramme bzw. von Diagrammen mit zu vielen Wiederholungen dienen. Die Namen von Syntaxfragmenten sind in gemischter Groß-/Kleinschreibung angegeben und erscheinen im Diagramm sowie in der Überschrift des Diagramms. Das Fragment ist unterhalb des Hauptdiagramms dargestellt:
>>--| Syntaxfragment |--------------------------------------->< Syntaxfragment: |--ERSTER_OPERAND--,--ZWEITER_OPERAND--,--DRITTER_OPERAND--|
Dieses Kapitel soll Sie bei einigen allgemeinen Problemen unterstützen, die beim Konfigurieren von Developer for System z auftreten könnten. Es enthält die folgenden Abschnitte:
Weitere Informationen sind im Bereich 'Support' der Website zu Developer for System z (http://www-306.ibm.com/software/awdtools/rdz/support/) verfügbar. In diesem Bereich finden Sie die aktuellsten technischen Hinweise des Unterstützungsteams.
Die aktuellste Version der Dokumentation zu Developer for System z, einschließlich White Papers und anderer hilfreicher Informationen, finden Sie im Abschnitt 'Library' der Website.
Im Information Center zu Developer for System z (http://publib.boulder.ibm.com/infocenter/ratdevz/v7r6/index.jsp) ist die Clientkomponente von Developer for System z und ihre Interaktion mit dem Host (aus der Sicht des Clients) dokumentiert.
Wertvolle Informationen enthält auch die z/OS-Internetbibliothek mit der Adresse http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/.
Benachrichtigen Sie uns, wenn Sie denken, dass bestimmte Funktionen in Developer for System z fehlen. Unter der folgenden Adresse können Sie eine Erweiterungsanfrage (Request For Enhancement, RFE) öffnen:
https://www.ibm.com/developerworks/support/rational/rfe/
Developer for System z stellt einen Beispieljob, FEKLOGS, bereit, der alle z/OS UNIX-Protokolldateien sowie Installations- und Konfigurationsdaten für Developer for System z zusammenstellt.
Der Beispieljob FEKLOGS ist in FEK.#CUST.JCL enthalten, sofern Sie während der Anpassung und Übergabe des Jobs FEK.SFEKSAMP(FEKSETUP) keine andere Position angegeben haben. Weitere Details hierzu enthält der Abschnitt Anpassungskonfiguration.
Die Anpassung von FEKLOGS wird in der JCL beschrieben. Die Anpassung schließt die Bereitstellung einiger Schlüsselvariablen ein.
Developer for System z erstellt Protokolldateien, die Sie und das IBM Support Center bei der Feststellung und Lösung von Problemen unterstützen können. Nachfolgend sind die Protokolldateien, die auf Ihrem z/OS-Hostsystem erstellt werden können, übersichtlich aufgelistet. Überprüfen Sie neben diesen produktspezifischen Protokollen stets, ob das SYSLOG zugehörige Nachrichten enthält.
Nach MVS-basierten Protokollen kann über die entsprechende DD-Anweisung gesucht werden. z/OS UNIX-basierte Protokolldateien befinden sich in den folgenden Verzeichnissen:
Benutzerspezifische Protokolldateien werden in userlog/$LOGNAME gespeichert. Dabei ist userlog der kombinierte Wert der Anweisungen user.log und DSTORE_LOG_DIRECTORY in rsed.envvars und $LOGNAME ist die Anmeldebenutzer-ID (in Großbuchstaben). Wenn die Anweisung user.log in Kommentarzeichen gesetzt wurde oder nicht vorhanden ist, wird der Ausgangspfad des Benutzers verwendet. Der Ausgangspfad ist im OMVS-Sicherheitssegment der Benutzer-ID definiert. Wenn die Anweisung DSTORE_LOG_DIRECTORY in Kommentarzeichen gesetzt wurde oder nicht vorhanden ist, wird .eclipse/RSE/ an den Wert von user.log angehängt.
Die Protokolldateien des RSE-Dämons und RSE-Thread-Pools befinden sich im Dämonausgangsverzeichnis. Das Dämonausgangsverzeichnis steht hierbei für den Wert der Anweisung daemon.log in rsed.envvars. Wenn die Anweisung daemon.log in Kommentarzeichen gesetzt wurde oder nicht vorhanden ist, wird der Ausgangspfad der Benutzer-ID verwendet, die der gestarteten Task RSED zugeordnet ist. Das Ausgangsverzeichnis ist im Segment für die OMVS-Sicherheit der Benutzer-ID definiert.
Es werden normale Operationen protokolliert. Der Standardwert in der Beispiel-JCL FEK.#CUST.PROCLIB(JMON) ist SYSOUT=*.
Trace-Protokollierung. Der Standardwert in der Beispiel-JCL FEK.#CUST.PROCLIB(JMON) ist SYSOUT=*. Der Trace wird mit dem Parameter -TV aktiviert. Weitere Details hierzu enthält der Abschnitt Traceerstellung für JES Job Monitor.
Umgeleitete Daten von der Java-Standardausgabe stdout. Der Standardwert in der Beispiel-JCL FEK.#CUST.PROCLIB(LOCKD) ist SYSOUT=*.
Umgeleitete Daten von der Java-Standardfehlerausgabe stderr. Der Standardwert in der Beispiel-JCL FEK.#CUST.PROCLIB(LOCKD) ist SYSOUT=*.
Umgeleitete Daten von der Java-Standardausgabe stdout des RSE-Dämons. Der Standardwert in der Beispiel-JCL FEK.#CUST.PROCLIB(RSED) ist SYSOUT=*.
Umgeleitete Daten von der Java-Standardfehlerausgabe stderr des RSE-Dämons. Der Standardwert in der Beispiel-JCL FEK.#CUST.PROCLIB(RSED) ist SYSOUT=*.
Die Protokolldateien des RSE-Dämons und des RSE-Thread-Pools befinden sich in daemon-home. Dabei steht daemon-home für den Wert der Anweisung daemon.log in rsed.envvars. Wenn die Anweisung daemon.log in Kommentarzeichen gesetzt wurde oder nicht vorhanden ist, wird der Ausgangspfad der Benutzer-ID verwendet, die der gestarteten Task RSED zugeordnet ist. Das Ausgangsverzeichnis ist im Segment für die OMVS-Sicherheit der Benutzer-ID definiert.
Die RSE-bezogenen Komponenten erstellen diverse Protokolldateien. Alle Dateien werden in userlog/$LOGNAME gespeichert. Dabei ist userlog der kombinierte Wert der Anweisungen user.log und DSTORE_LOG_DIRECTORY in rsed.envvars und $LOGNAME ist die Anmeldebenutzer-ID (in Großbuchstaben). Wenn die Anweisung user.log in Kommentarzeichen gesetzt wurde oder nicht vorhanden ist, wird der Ausgangspfad des Benutzers verwendet. Der Ausgangspfad ist im OMVS-Sicherheitssegment der Benutzer-ID definiert. Wenn die Anweisung DSTORE_LOG_DIRECTORY in Kommentarzeichen gesetzt wurde oder nicht vorhanden ist, wird .eclipse/RSE/ an den Wert von user.log angehängt.
Protokollierung der Fault Analyzer-Integration. Dabei ist userlog der kombinierte Wert der Anweisungen user.log und DSTORE_LOG_DIRECTORY in rsed.envvars und $LOGNAME ist die Anmeldebenutzer-ID (in Großbuchstaben). Wenn die Anweisung user.log in Kommentarzeichen gesetzt wurde oder nicht vorhanden ist, wird der Ausgangspfad des Benutzers verwendet. Der Ausgangspfad ist im OMVS-Sicherheitssegment der Benutzer-ID definiert. Wenn die Anweisung DSTORE_LOG_DIRECTORY in Kommentarzeichen gesetzt wurde oder nicht vorhanden ist, wird .eclipse/RSE/ an den Wert von user.log angehängt.
Protokollierung der Kommunikation für die File Manager-Integration. Dabei ist userlog der kombinierte Wert der Anweisungen user.log und DSTORE_LOG_DIRECTORY in rsed.envvars und $LOGNAME ist die Anmeldebenutzer-ID (in Großbuchstaben). Wenn die Anweisung user.log in Kommentarzeichen gesetzt wurde oder nicht vorhanden ist, wird der Ausgangspfad des Benutzers verwendet. Der Ausgangspfad ist im OMVS-Sicherheitssegment der Benutzer-ID definiert. Wenn die Anweisung DSTORE_LOG_DIRECTORY in Kommentarzeichen gesetzt wurde oder nicht vorhanden ist, wird .eclipse/RSE/ an den Wert von user.log angehängt.
Protokollierung der Kommunikation für SCLM Developer Toolkit. Dabei ist userlog der kombinierte Wert der Anweisungen user.log und DSTORE_LOG_DIRECTORY in rsed.envvars und $LOGNAME ist die Anmeldebenutzer-ID (in Großbuchstaben). Wenn die Anweisung user.log in Kommentarzeichen gesetzt wurde oder nicht vorhanden ist, wird der Ausgangspfad des Benutzers verwendet. Der Ausgangspfad ist im OMVS-Sicherheitssegment der Benutzer-ID definiert. Wenn die Anweisung DSTORE_LOG_DIRECTORY in Kommentarzeichen gesetzt wurde oder nicht vorhanden ist, wird .eclipse/RSE/ an den Wert von user.log angehängt.
Wenn Sie über die Batchschnittstelle eine Verbindung zu CARMA öffnen, startet FEK.#CUST.SYSPROC(CRASUBMT) einen Server-Job CRAport (mit der Benutzer-ID als Eigner). Die Angabe port im Namen steht hier für den verwendeten TCP/IP-Port.
Wenn in der ausgewählten CARMA-Startmethode die DD-Anweisung CARMALOG angegeben ist, wird die CARMA-Protokollierung an diese DD-Anweisung im Server-Job umgeleitet. Andernfalls ist sie auf der SYSPRINT-Karte enthalten.
Die SYSPRINT-Karte des Server-Jobs enthält die CARMA-Protokollierung, sofern nicht die DD-Anweisung CARMALOG definiert ist.
Protokollierung der CARMA-Kommunikation. Dabei ist userlog der kombinierte Wert der Anweisungen user.log und DSTORE_LOG_DIRECTORY in rsed.envvars und $LOGNAME ist die Anmeldebenutzer-ID (in Großbuchstaben). Wenn die Anweisung user.log in Kommentarzeichen gesetzt wurde oder nicht vorhanden ist, wird der Ausgangspfad des Benutzers verwendet. Der Ausgangspfad ist im OMVS-Sicherheitssegment der Benutzer-ID definiert. Wenn die Anweisung DSTORE_LOG_DIRECTORY in Kommentarzeichen gesetzt wurde oder nicht vorhanden ist, wird .eclipse/RSE/ an den Wert von user.log angehängt.
Wenn das APPC-Administrationsdienstprogramm ein Profil für ein Transaktionsprogramm hinzufügt und modifiziert, wird sowohl das Profil als auch die JCL auf Syntaxfehler überprüft. Die Ausgaben dieser Phase umfassen Nachrichten zu Syntaxfehlern im TP-Profil, Verarbeitungsnachrichten des Dienstprogramms und JCL-Konvertierungsanweisungen. Die Protokollierung von Nachrichten dieser Phase wird von der Anweisung SYSPRINT DD für das Dienstprogramm ATBSDFMU gesteuert. Der Standardwert in der Beispiel-JCL FEK.SFEKSAMP(FEKAPPCC) ist SYSOUT=*. Weitere Details hierzu enthält die Veröffentlichung MVS Planning: APPC/MVS Management (IBM Form SA22-7599).
Wenn ein TP ausgeführt wird, werden die TP-Laufzeitnachrichten, z. B. Zuordnungs- und Beendigungsnachrichten, in das Protokoll geschrieben, das vom Schlüsselwort MESSAGE_DATA_SET im TP-Profil genannt wird. Der Standardwert in der Beispiel-JCL FEK.SFEKSAMP(FEKAPPCC) ist &SYSUID.FEKFRSRV.&TPDATE.&TPTIME.LOG. Weitere Details hierzu enthält die Veröffentlichung MVS Planning: APPC/MVS Management (IBM Form SA22-7599).
Ausgabe des Befehls fekfivpi -file (IVP-Test für das TSO/ISPF-Client-Gateway). Dabei ist userlog der kombinierte Wert der Anweisungen user.log und DSTORE_LOG_DIRECTORY in rsed.envvars und $LOGNAME ist die Anmeldebenutzer-ID (in Großbuchstaben). Wenn die Anweisung user.log in Kommentarzeichen gesetzt wurde oder nicht vorhanden ist, wird der Ausgangspfad des Benutzers verwendet. Der Ausgangspfad ist im OMVS-Sicherheitssegment der Benutzer-ID definiert. Wenn die Anweisung DSTORE_LOG_DIRECTORY in Kommentarzeichen gesetzt wurde oder nicht vorhanden ist, wird .eclipse/RSE/ an den Wert von user.log angehängt.
Ausgabe des Befehls fekfivps -file (IVP-Test für SCLMDT). Dabei ist userlog der kombinierte Wert der Anweisungen user.log und DSTORE_LOG_DIRECTORY in rsed.envvars und $LOGNAME ist die Anmeldebenutzer-ID (in Großbuchstaben). Wenn die Anweisung user.log in Kommentarzeichen gesetzt wurde oder nicht vorhanden ist, wird der Ausgangspfad des Benutzers verwendet. Der Ausgangspfad ist im OMVS-Sicherheitssegment der Benutzer-ID definiert. Wenn die Anweisung DSTORE_LOG_DIRECTORY in Kommentarzeichen gesetzt wurde oder nicht vorhanden ist, wird .eclipse/RSE/ an den Wert von user.log angehängt.
Wenn ein Produkt anormal beendet wird, wird ein Speicherauszug zur Unterstützung der Fehlerbestimmung erstellt. Verfügbarkeit und Position dieser Speicherauszüge hängen in hohem Maße von standortspezifischen Einstellungen ab. Es ist möglich, dass sie gar nicht oder an anderen Positionen als unten angegeben erstellt werden.
Wenn das Programm unter MVS ausgeführt wird, überprüfen Sie die Systemspeicherauszugsdateien und Ihre JCL (je nach Produkt) auf die folgenden DD-Anweisungen:
Weitere Informationen zu diesen DD-Anweisungen sind in den Veröffentlichungen MVS JCL Reference (IBM Form SA22-7597) und Language Environment Debugging Guide (IBM Form GA22-7560) enthalten.
Unter z/OS UNIX werden die meisten Speicherauszüge von Developer for System z durch die Java Virtual Machine (JVM) gesteuert.
Die JVM erstellt während ihrer Initialisierung eine Gruppe von Speicherauszugsagenten (SYSTDUMP und JAVADUMP). Sie können diese Speicherauszugsagenten mit der Umgebungsvariablen JAVA_DUMP_OPTS sowie in der Befehlszeile mit -Xdump außer Kraft setzen. JVM-Befehlszeilenoptionen sind in der Anweisung _RSE_JAVAOPTS der Datei rsed.envvars definiert. Ändern Sie die Speicherauszugseinstellungen nur auf Anweisung des IBM Support Center.
Folgende Arten von Speicherauszügen können erzeugt werden:
Der Speicherauszug wird in eine sequenzielle MVS-Datei geschrieben, deren Name standardmäßig die Form %uid.JVM.TDUMP.%job.D%y%m%d.T%H%M%S hat oder von der Umgebungsvariablen JAVA_DUMP_TDUMP_PATTERN bestimmt wird. Falls Sie keine Transaktionsspeicherauszüge erstellen möchten, fügen Sie die Umgebungsvariable IBM_JAVA_ZOS_TDUMP=NO zur Datei rsed.envvars hinzu.
Variable | Verwendung |
---|---|
%uid | Benutzer-ID |
%job | Jobname |
%y | Jahr (2-stellig) |
%m | Monat (2-stellig) |
%d | Tag (2-stellig) |
%H | Stunde (2-stellig) |
%M | Minute (2-stellig) |
%S | Sekunde (2-stellig) |
Der Speicherauszug wird in eine z/OS UNIX-Datei mit dem Namen CEEDUMP.yyyymmdd.hhmmss.pid geschrieben. Dabei stehen yyyymmdd für das aktuelle Datum, hhmmss für die aktuelle Uhrzeit und pid für die ID des aktuellen Prozesses. Die möglichen Positionen dieser Datei sind im Abschnitt Positionen für z/OS UNIX-Speicherauszüge beschrieben.
Der Speicherauszug wird in eine z/OS UNIX-Datei mit dem Namen HEAPDUMP.yyyymmdd.hhmmss.pid.TXT geschrieben. Dabei stehen yyyymmdd für das aktuelle Datum, hhmmss für die aktuelle Uhrzeit und pid für die ID des aktuellen Prozesses. Die möglichen Positionen dieser Datei sind im Abschnitt Positionen für z/OS UNIX-Speicherauszüge beschrieben.
Der Speicherauszug wird in eine z/OS UNIX-Datei mit dem Namen JAVADUMP.yyyymmdd.hhmmss.pid.TXT geschrieben. Dabei stehen yyyymmdd für das aktuelle Datum, hhmmss für die aktuelle Uhrzeit und pid für die ID des aktuellen Prozesses. Die möglichen Positionen dieser Datei sind im Abschnitt Positionen für z/OS UNIX-Speicherauszüge beschrieben.
Weitere Informationen zu JVM-Speicherauszügen enthält der Java Diagnostic Guide (IBM Form SC34-6358). LE-spezifische Informationen finden Sie im Language Environment Debugging Guide (IBM Form GA22-7560).
Die JVM überprüft alle nachfolgend angegebenen Positionen auf ihr Vorhandensein und auf die Schreibberechtigungen. An der ersten verfügbaren Position werden die CEEDUMP-, HEAPDUMP- und JAVADUMP-Dateien gespeichert. Denken Sie daran, dass genug freier Plattenspeicherplatz vorhanden sein muss, damit die Speicherauszugsdatei ordnungsgemäß geschrieben werden kann.
Die Traceerstellung für JES Job Monitor wird, wie in Bedienerbefehle beschrieben, vom Systembediener gesteuert.
Die RSE-bezogenen Komponenten erstellen diverse Protokolldateien. Die meisten Dateien werden in userlog/$LOGNAME gespeichert. Dabei ist userlog der kombinierte Wert der Anweisungen user.log und DSTORE_LOG_DIRECTORY in rsed.envvars und $LOGNAME ist die Anmeldebenutzer-ID (in Großbuchstaben). Wenn die Anweisung user.log in Kommentarzeichen gesetzt wurde oder nicht vorhanden ist, wird der Ausgangspfad des Benutzers verwendet. Der Ausgangspfad ist im OMVS-Sicherheitssegment der Benutzer-ID definiert. Wenn die Anweisung DSTORE_LOG_DIRECTORY in Kommentarzeichen gesetzt wurde oder nicht vorhanden ist, wird .eclipse/RSE/ an den Wert von user.log angehängt.
Das in ffs*.log, lock.log und rsecomm.log geschriebene Datenvolumen wird durch den Bedienerbefehl modify rsecommlog oder von der Einstellung debug_level in rsecomm.properties gesteuert. Ausführliche Informationen hierzu finden Sie in Bedienerbefehle und im Abschnitt RSE-Trace (optional).
Die Erstellung der Protokolldateien .dstore* wird von den Java-Startoptionen -DDSTORE_* gesteuert. Lesen Sie hierzu die Informationen unter Zusätzliche Java-Startparameter mit _RSE_JAVAOPTS definieren.
Die Protokolldateien des RSE-Dämons und des RSE-Thread-Pools befinden sich in daemon-home. Dabei steht daemon-home für den Wert der Anweisung daemon.log in rsed.envvars. Wenn die Anweisung daemon.log in Kommentarzeichen gesetzt wurde oder nicht vorhanden ist, wird der Ausgangspfad der Benutzer-ID verwendet, die der gestarteten Task RSED zugeordnet ist. Das Ausgangsverzeichnis ist im Segment für die OMVS-Sicherheit der Benutzer-ID definiert.
Das in rsedaemon*.log und rseserver.log geschriebene Datenvolumen wird durch die Bedienerbefehle modify rsedaemonlog und modify rseserverlog oder von der Einstellung debug_level in rsecomm.properties gesteuert. Ausführliche Informationen hierzu finden Sie in Bedienerbefehle und im Abschnitt RSE-Trace (optional).
Die Dateien serverlogs.count, stderr.*.log und stdout.*.log werden nur erstellt, wenn die Anweisung enable.standard.log in rsed.envvars aktiv ist oder wenn die Funktion mit dem Bedienerbefehl modify rsestandardlog on dynamisch aktiviert wurde.
Das spezifische Sperrdämonprotokoll befindet sich in der STDOUT DD der gestarteten Task LOCKD. Das in dieses Protokoll geschriebene Datenvolumen wird von dem Startparameter LOG gesteuert. Ausführliche Informationen hierzu finden Sie in Bedienerbefehle und im Abschnitt RSE-Trace (optional).
Den Umfang der von CARMA generierten Trace-Informationen kann der Benutzer steuern, indem er auf dem Client auf der Eigenschaftenregisterkarte der CARMA-Verbindung die 'Tracestufe' definiert. Folgende Optionen sind für die Tracestufe verfügbar:
Standardwert:
Fehler
Weitere Informationen zur Position der Protokolldateien enthält der Abschnitt Protokolldateien.
Mit der folgenden Prozedur können Informationen zusammengestellt werden, die notwendig sind, um Probleme bei Fehlerrückmeldungen für ferne Buildprozeduren zu diagnostizieren. Dieser Trace bringt Leistungseinbußen mit sich und sollte nur auf Anweisung des IBM Support Center durchgeführt werden. Alle in diesem Abschnitt enthaltenen Verweise auf HLQ beziehen sich auf das während der Installation von Developer for System z verwendete übergeordnete Qualifikationsmerkmal. Die Standardeinstellung für die Installation ist FEK, die jedoch nicht für Ihren Standort zutreffen muss.
//COBOL EXEC PGM=IGYCRCTL,REGION=2048K, //* PARM=('EXIT(ADEXIT(ELAXMGUX))', // PARM=('EXIT(ADEXIT(''MAXTRACE'',ELAXMGUX))', // 'ADATA', // 'LIB', // 'TEST(NONE,SYM,SEP)', // 'LIST', // 'FLAG(I,I)'&CICS &DB2 &COMP)
ABOUT TOO OPEN SIDEFILE1 - NAME = 'uid.DT021207.TT110823.M0000045.C0000000' SUCCESSFUL OPEN SIDEFILE1 - NAME = 'uid.DT021207.TT110823.M0000045.C0000000' ABOUT TOO OPEN SIDEFILE2 - NAME = 'uid.DT021207.TT110823.M0000111.C0000001' SUCCESSFUL OPEN SIDEFILE2 - NAME = 'uid.DT021207.TT110823.M0000111.C0000001' ABOUT TOO OPEN SIDEFILE3 - NAME = 'uid.DT021207.TT110823.M0000174.C0000002' SUCCESSFUL OPEN SIDEFILE3 - NAME = 'uid.DT021207.TT110823.M0000174.C0000002' ABOUT TOO OPEN SIDEFILE4 - NAME = 'uid.DT021207.TT110823.M0000236.C0000003' SUCCESSFUL OPEN SIDEFILE4 - NAME = 'uid.DT021207.TT110823.M0000236.C0000003'
22 //COBOL.WSEDSF1 DD DISP=MOD, // DSN=uid.ERRCOB.member.SF.Z682746.XML 23 //COBOL.WSEDSF2 DD DISP=MOD, // DSN=uid.ERRCOB.member.SF.Z682747.XML
Developer for System z erfordert, dass für das z/OS UNIX-Dateisystem und einige z/OS UNIX-Dateien bestimmte Berechtigungsbits gesetzt sind.
Remote Systems Explorer (RSE) ist die Komponente von Developer for System z, die Kernservices wie die Verbindung vom Client zum Host bereitstellt. Diese Komponente muss in der Lage sein, Tasks wie die Erstellung der Sicherheitsumgebung für den Benutzer auszuführen.
Das Dateisystem (HFS oder zFS), in dem Developer for System z installiert ist, muss mit gesetztem Berechtigungsbit SETUID angehängt werden. (Dies ist der Systemstandardwert.) Wenn Sie das Dateisystem mit dem Parameter NOSETUID anhängen, kann Developer for System z keine Sicherheitsumgebung für den Benutzer erstellen, sodass die Verbindungsanforderung fehlschlägt.
Mit dem TSO-Befehl ISHELL können Sie den aktuellen Status des Bits SETUID anzeigen. Wählen Sie in der ISHELL-Anzeige File_systems > 1. Mount table... aus, um die angehängten Dateisysteme aufzulisten. Mit dem Zeilenbefehl a können Sie die Attribute für das ausgewählte Dateisystem anzeigen. Das Feld "Ignore SETUID" sollte auf 0 gesetzt sein.
Remote Systems Explorer (RSE) ist die Komponente von Developer for System z, die Kernservices wie die Verbindung vom Client zum Host bereitstellt. Für die Ausführung von Tasks, z. B. die Umschaltung auf die Benutzer-ID des Clients, muss die Komponente programmgesteuert ausgeführt werden.
Während der SMP/E-Installation wird das z/OS UNIX-Programmsteuerungsbit dort gesetzt, wo es erforderlich ist, außer für die Java-Schnittstelle zu Ihrem Sicherheitsprodukt. Lesen Sie hierzu die Informationen unter Sicherheitsaspekte. Dieses Berechtigungsbit könnte verloren gehen, wenn Sie es nicht in einer manuell erstellten Kopie der Verzeichnisse von Developer for System z gesichert haben.
Folgende Dateien von Developer for System z müssen programmgesteuerte Dateien sein:
Verwenden Sie den z/OS UNIX-Befehl ls -E, ph>, um die erweiterten Attribute aufzulisten, in denen das Programmsteuerungsbit mit dem Buchstaben p markiert ist. Sehen Sie sich dazu das folgende Beispiel an ($ ist die z/OS UNIX-Eingabeaufforderung):
$ cd /usr/lpp/rdz $ ls -E lib/fekf* -rwxr-xr-x -ps- 2 user group 94208 Jul 8 12:31 lib/fekfdir.dll
Mit dem z/OS UNIX-Befehl extattr +p können Sie das Programmsteuerungsbit manuell setzen. Vergleichen Sie hierzu das folgende Beispiel ($ und # sind die z/OS UNIX-Eingabeaufforderung):
$ cd /usr/lpp/rdz $ su # extattr +p lib/fekf* # exit $ ls -E lib/fekf* -rwxr-xr-x -ps- 2 user group 94208 Jul 8 12:31 lib/fekfdir.dll
Remote Systems Explorer (RSE) ist die Komponente von Developer for System z, die Kernservices bereistellt, wie den Verbindungsaufbau des Clients mit dem Host. Für die Ausführung von Tasks, wie das Anzeigen detaillierter Informationen zur Prozessressourcennutzung, muss die Komponente APF-autorisiert ausgeführt werden.
Das z/OS UNIX-APF-Bit wird während der SMP/E-Installation gesetzt, wo es erforderlich ist. Dieses Berechtigungsbit könnte verloren gehen, wenn Sie es nicht in einer manuell erstellten Kopie der Verzeichnisse von Developer for System z gesichert haben.
Die folgenden Dateien von Developer for System z müssen APF-autorisiert sein:
Verwenden Sie den z/OS UNIX-Befehl ls -E, um die erweiterten Attribute aufzulisten, in denen das APF-Bit mit dem Buchstaben a markiert ist. Sehen Sie sich hierzu das folgende Beispiel an ("$" ist die z/OS UNIX-Eingabeaufforderung):
$ cd /usr/lpp/rdz $ ls -E bin/fekfrivp -rwxr-xr-x aps- 2 user group 114688 Sep 17 06:41 bin/fekfrivp
Verwenden Sie den z/OS UNIX-Befehl extattr +a, um das APF-Bit manuell zu setzen. Sehen Sie sich hierzu das folgende Beispiel an ("$" und "#" sind die z/OS UNIX-Eingabeaufforderungen):
$ cd /usr/lpp/rdz $ su # extattr +a bin/fekfrivp # exit $ ls -E bin/fekfrivp -rwxr-xr-x aps- 2 user group 114688 Sep 17 06:41 bin/fekfrivp
Einige der optionalen Services von Developer for System z erfordern, dass MVS-Lademodule für z/OS UNIX zur Verfügung stehen. Deshalb wird in z/OS UNIX ein Stub (eine Pseudodatei) mit aktiviertem Sticky Bit erstellt. Wenn der Stub ausgeführt wird, sucht z/OS UNIX nach einem MVS-Lademodul mit demselben Namen und führt dieses anstelle des Stubs aus.
Das Sticky Bit für z/OS UNIX wird während der SMP/E-Installation gesetzt, wo es erforderlich ist. Derartige Berechtigungsbits können verloren gehen, wenn Sie sie nicht in einer manuell erstellten Kopie der Verzeichnisse von Developer for System z gesichert haben.
Das Sticky Bit muss für die folgenden Dateien von Developer for System z aktiviert sein:
Verwenden Sie den z/OS UNIX-Befehl ls -l, um die Berechtigungen aufzulisten, in denen das Sticky Bit mit dem Buchstaben t markiert ist. Sehen Sie sich dazu das folgende Beispiel an ($ ist die z/OS UNIX-Eingabeaufforderung):
$ cd /usr/lpp/rdz $ ls -l bin/CRA* -rwxr-xr-t 2 user group 71 Jul 8 12:31 bin/CRASTART
Mit dem z/OS UNIX-Befehl chmod +t können Sie das Sticky Bit manuell setzen. Vergleichen Sie hierzu das folgende Beispiel ($ und # sind die z/OS UNIX-Eingabeaufforderung):
$ cd /usr/lpp/rdz $ su # chmod +t bin/CRA* # exit $ ls -l bin/CRA* -rwxr-xr-t 2 user group 71 Jul 8 12:31 bin/CRASTART
Mit dem Befehl netstat (TSO oder z/OS UNIX) können Sie eine Übersicht der zurzeit verwendeten Ports aufrufen. Die Ausgabe dieses Befehls sieht in etwa wie das folgende Beispiel aus. Die letzte Zahl in der Spalte "Local Socket" (nach "..") gibt die verwendeten Ports an. Da diese Ports bereits genutzt werden, können sie nicht für die Konfiguration von Developer for System z verwendet werden.
IPV4
MVS TCP/IP NETSTAT CS VxRy TCPIP Name: TCPIP 16:36:42 User Id Conn Local Socket Foreign Socket State ------- ---- ------------ -------------- ----- BPXOINIT 00000014 0.0.0.0..10007 0.0.0.0..0 Listen INETD4 0000004D 0.0.0.0..512 0.0.0.0..0 Listen RSED 0000004B 0.0.0.0..4035 0.0.0.0..0 Listen JMON 00000038 0.0.0.0..6715 0.0.0.0..0 Listen
IPV6
MVS TCP/IP NETSTAT CS VxRy TCPIP Name: TCPIP 12:46:25 User Id Conn State ------- ---- ----- BPXOINIT 00000018 Listen Local Socket: 0.0.0.0..10007 Foreign Socket: 0.0.0.0..0 INETD4 00000046 Listen Local Socket: 0.0.0.0..512 Foreign Socket: 0.0.0.0..0 RSED 0000004B Listen Local Socket: 0.0.0.0..4035 Foreign Socket: 0.0.0.0..0 JMON 00000037 Listen Local Socket: 0.0.0.0..6715 Foreign Socket: 0.0.0.0..0
Eine andere bestehende Einschränkung sind reservierte TCP/IP-Ports. Es gibt die beiden folgenden allgemeinen Bereiche, in denen TCP/IP-Ports reserviert werden:
Auf diese Datei verweist die DD-Anweisung PROFILE der gestarteten TCP/IP-Task, die oft den Namen SYS1.TCPPARMS(TCPPROF) hat.
Weitere Informationen zu diesen Anweisungen finden Sie im Communications Server: IP Configuration Guide (IBM Form SC31-8775).
Diese reservierten Ports können mit dem Befehl netstat portl (TSO oder z/OS UNIX) aufgelistet werden. Die erstellte Ausgabe entspricht in etwa dem folgenden Beispiel:
MVS TCP/IP NETSTAT CS VxRy TCPIP Name: TCPIP 17:08:32 Port# Prot User Flags Range IP Address ----- ---- ---- ----- ----- ---------- 00007 TCP MISCSERV DA 00009 TCP MISCSERV DA 00019 TCP MISCSERV DA 00020 TCP OMVS D 00021 TCP FTPD1 DA 00025 TCP SMTP DA 00053 TCP NAMESRV DA 00080 TCP OMVS DA 03500 TCP OMVS DAR 03500-03519 03501 TCP OMVS DAR 03500-03519
Weitere Informationen zum Befehl NETSTAT enthält die Veröffentlichung Communications Server: IP System Administrator's Commands (IBM Form SC31-8781).
Der RSE-Dämon ist ein z/OS UNIX-Java-Prozess und erfordert für die Ausführung seiner Funktionen eine große Regionsgröße. Deshalb ist es wichtig, dass für OMVS-Adressräume große Speichergrenzen festgelegt werden.
Der RSE-Dämon wird über JCL mit BPXBATSL gestartet. Die Regionsgröße von BPXBATSL muss gleich null sein.
Setzen Sie MAXASSIZE in SYS1.PARMLIB(BPXPRMxx) (zum Definieren der Standardregionsgröße bzw. -prozessgröße für den OMVS-Adressraum) auf mindestens 2G. Dies ist die zulässige Maximalgröße. Dieser Grenzwert gilt systemweit. Er ist daher für alle z/OS UNIX-Adressräume aktiv. Wenn Sie dies nicht wünschen, können Sie in Ihrer Sicherheitssoftware den Grenzwert auch nur für Developer for System z festlegen.
Dieser Wert kann mit folgenden Konsolbefehlen überprüft und dynamisch (bis zum nächsten IPL) gesetzt werden. Lesen Sie hierzu die Beschreibung in der Veröffentlichung MVS System Commands (IBM Form GC28-1781).
Überprüfen Sie ASSIZEMAX im OMVS-Segment der Dämonbenutzer-ID und setzen Sie das Feld auf 2147483647 oder vorzugsweise auf NONE, damit der Wert SYS1.PARMLIB(BPXPRMxx) verwendet wird.
Dieser Wert kann in RACF mit den folgenden TSO-Befehlen überprüft und gesetzt werden. Lesen Sie hierzu die Beschreibung in der Veröffentlichung Security Server RACF Command Language Reference (IBM Form SA22-7687).
Stellen Sie sicher, dass Regionsgrößen des OMVS-Adressraums nicht von den Systemexits IEFUSI oder IEALIMIT gesteuert werden. Eine Möglichkeit, dies zu erreichen, ist die Verwendung des Codes SUBSYS(OMVS,NOEXITS) in SYS1.PARMLIB(SMFPRMxx).
SYS1.PARMLIB(SMFPRMxx)-Werte können mit folgenden Konsolbefehlen überprüft und aktiviert werden. Lesen Sie hierzu die Beschreibung in der Veröffentlichung MVS System Commands (IBM Form GC28-1781).
Das Schlüsselwort MEMLIMIT in SYS1.PARMLIB(SMFPRMxx) legt fest, wie viel virtuellen Speicher eine 64-Bit-Task oberhalb der Grenze von 2GB zuweisen darf. Im Gegensatz zu dem Parameter REGION in JCL bedeutet MEMLIMIT=0M, dass der Prozess keinen virtuellen Speicher oberhalb der Grenze verwenden darf.
Wenn MEMLIMIT nicht in SMFPRMxx angegeben wird, ist der Standardwert 0M, das heißt, dass Tasks an die 2 GB (31 Bit) unterhalb der Grenze gebunden sind. Der in z/OS 1.10 auf 2G geänderte Standard ermöglicht 64-Bit-Tasks die Verwendung von bis zu 4 GB (2 GB unterhalb der Grenze und 2 GB durch MEMLIMIT).
SYS1.PARMLIB(SMFPRMxx)-Werte können mit folgenden Konsolbefehlen überprüft und aktiviert werden. Lesen Sie hierzu die Beschreibung in der Veröffentlichung MVS System Commands (IBM Form GC28-1781).
MEMLIMIT kann auch als Parameter auf der EXEC-Karte in JCL angegeben werden. Wenn der Parameter MEMLIMIT nicht angegeben ist, ist der Standard der in SMF definierte Wert. Dies gilt nicht, wenn REGION=0M angegeben ist. In diesem Fall ist der Standardwert NOLIMIT.
Falls Sie die APPC-Version von TSO Commands Service nicht nutzen können, können in zwei Bereichen Probleme auftauchen: beim Starten der APPC-Servertransaktion und beim Herstellen einer Verbindung zu RSE.
Die im Abschnitt APPC-Transaktion für TSO Commands Service (optional) angegebene REXX kann Ihnen bei der Lösung von APPC-Problemen helfen, denn sie ermöglicht Ihnen, APPC in ISPF-Anzeigen im Dialogbetrieb zu verwalten. Mit diesem Tool können Sie die APPC-Transaktion inaktivieren. Die Transaktion ist unverändert vorhanden, akzeptiert dann jedoch keine Verbindungen mehr.
Nachfolgend sind technische Hinweise aufgelistet, die derzeit auf der Supportwebsite (http://www-306.ibm.com/software/awdtools/rdz/support/) verfügbar sind. Zusätzliche Informationen entnehmen Sie bitte direkt der Supportwebsite.
SYS1.PARMLIB(BPXPRMxx) definiert viele z/OS UNIX-bezogene Begrenzungen, die erreicht werden können, wenn mehrere Clientkomponenten von Developer for System z aktiv sind. Die meisten BPXPRMxx-Werte können mit den Konsolbefehlen SETOMVS und SET OMVS dynamisch geändert werden.
Verwenden Sie den Konsolbefehl SETOMVS LIMMSG=ALL, damit unter z/OS UNIX Konsolnachrichten (BPXI040I) angezeigt werden, wenn Grenzwerte für BPXPRMxx annähernd überschritten werden.
Jede RSE-Verbindung startet mehrere Prozesse, die permanent aktiv sind. Neue Verbindungen können durch den in SYS1.PARMLIB(BPXPRMxx) gesetzten Grenzwert für die Anzahl der Prozesse zurückgewiesen werden. Dies gilt insbesondere, wenn Benutzer dieselbe UID gemeinsam benutzen (wie es z. B. bei Verwendung des Standard-OMVS-Segments der Fall ist).
Eine weitere Ursache für zurückgewiesene Verbindungen ist der Grenzwert für die Menge aktiver z/OS-Adressräume und z/OS UNIX-Benutzer.
Wenn Sie APPC für TSO Commands Service verwenden, muss für das Lesen und Schreiben einer MVS-Datei eine Dateisystemdomäne mit physischen Sockets verwendet werden. Wenn das Dateisystem nicht ordnungsgemäß definiert ist oder nicht genug Sockets hat, verhindert der Sperrenmanager (FFS) Lese-/Schreibanforderungen. Die Dateien ffs*.log enthalten dann Nachrichten wie die folgenden:
Prüfen Sie, ob das Member SYS1.PARMLIB(BPXPRMxx) die folgenden Anweisungen enthält:
FILESYSTYPE TYPE(UDS) ENTRYPOINT(BPXTUINT) NETWORK DOMAINNAME(AF_UNIX) DOMAINNUMBER(1) MAXSOCKETS(2000) TYPE(UDS)
Wenn Sie APPC für TSO Commands Service verwenden, kommt als weitere Ursache für dieses Problem in Frage, dass der TCP/IP-Resolver die Hostadresse nicht ordnungsgemäß auflösen kann, weil eine Resolverkonfigurationsdatei fehlt oder unvollständig ist. Ein deutlicher Hinweis auf dieses Problem ist die folgende Nachricht in lock.log:
clientip(0.0.0.0) <> callerip(<Host-IP-Adresse>)
Führen Sie das TCP/IP-Installationsprüfprogramm fekfivpt wie in Installationsprüfung beschrieben aus. Der Abschnitt der Ausgabe mit der Resolverkonfiguration sieht in etwa wie das folgende Beispiel aus:
Resolver Trace Initialization Complete -> 2008/07/02 13:11:54.745964 res_init Resolver values: Global Tcp/Ip Dataset = None Default Tcp/Ip Dataset = None Local Tcp/Ip Dataset = /etc/resolv.conf Translation Table = Default UserId/JobName = USERID Caller API = LE C Sockets Caller Mode = EBCDIC
Vergewissern Sie sich, dass die Definitionen in der von "Local Tcp/Ip Dataset" referenzierten Datei stimmen.
Wenn Sie für die IP-Resolver-Datei keinen Standardnamen verwenden, bleibt dieses Feld leer (bei Verwendung der z/OS UNIX-Suchreihenfolge). Fügen Sie in dem Fall die folgende Anweisung zu rsed.envvars hinzu. <Resolver-Datei> repräsentiert hier den Namen Ihrer IP-Resolver-Datei.
RESOLVER_CONFIG='<Resolver-Datei>'
Developer for System z ermöglicht Benutzern einer Workstation den Zugriff auf Mainframe-Computer, wenn diese selbst kein Mainframe-Computer ist. Wichtige Aspekte bei der Produktkonfiguration sind deshalb das Prüfen von Verbindungsanforderungen, das Bereitstellen von sicherer Kommunikation zwischen dem Host und der Workstation sowie das Autorisieren und Protokollieren der Aktivitäten.
Die von den Servern und Services von Developer for System z verwendeten Sicherheitsmechanismen sind nur wirksam, wenn das zugrunde liegende Dateisystem geschützt ist. Dies impliziert, dass die Programmbibliotheken und Konfigurationsdateien nur von vertrauenswürdigen Systemadministratoren aktualisiert werden können.
Dieses Kapitel enthält die folgenden Abschnitte:
Lesen Sie Wissenswertes zu Developer for System z, um mehr über grundlegende Designkonzepte von Developer for System z zu erfahren.
Developer for System z unterstützt mehrere Möglichkeiten für die Authentifizierung einer Benutzer-ID, die von einem Client bei der Herstellung einer Verbindung bereitgestellt wurde.
Beachten Sie, dass die vom Client bereitgestellten Authentifizierungsdaten nur einmalig, und zwar während der einleitenden Verbindungskonfiguration, verwendet werden. Sobald eine Benutzer-ID authentifiziert ist, werden die Benutzer-ID und die selbsterstellten PassTickets für alle Aktionen verwendet, die eine Authentifizierung erfordern.
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.
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.
Beachten Sie, dass diese Authentifizierungsmethode nur von der Verbindungsmethode des RSE-Dämons unterstützt wird und SSL aktiviert sein muss.
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:
Verschiedene Ebenen der Kommunikationssicherheit werden vom RSE unterstützt. Dieser steuert die gesamte Kommunikation zwischen dem Client und den Developer for System z-Services:
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.
Nachfolgend sehen Sie eine kurze Beschreibung des RSE-Verbindungsprozesses, die Ihnen helfen soll, die Portverwendung zu verstehen.
Alle externen Datenströme von Developer for System z, die den RSE-Server passieren, können mit SSL (Secure Sockets Layer) verschlüsselt werden. Die Verwendung von SSL wird von den Einstellungen in der Konfigurationsdatei ssl.properties gesteuert. Lesen Sie hierzu die Beschreibung im Abschnitt Mit SSL verschlüsselte Kommunikation.
Der Host-Connect-Emulator auf dem Client stellt eine Verbindung zu einem TN3270-Server auf dem Host her. Die Verwendung von SSL wird von TN3270 gesteuert. Diese Art der Verwendung ist im Communications Server IP Configuration Guide (IBM Form SC31-8775) dokumentiert.
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 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.
Abb. 40 stellt die TCP/IP-Ports dar, die mit Developer for System z verwendet werden können. Die Pfeilspitzen deuten an, welcher Teilnehmer für die Bindung (Pfeilspitzenseite) verantwortlich ist und welcher die Verbindung herstellt.
Definieren Sie für die Firewall, die Ihren z/OS-Host schützt, die folgenden Ports für die Client-Host-Kommunikation (unter Verwendung des TCP-Protokolls):
Mehrere Hostservices von Developer for System z werden in gesonderten Threads oder Adressräumen ausgeführt und verwenden TCP/IP-Sockets als Kommunikationsmechanismus. Alle diese Services nutzen RSE für die Kommunikation mit dem Client und beschränken ihren Datenstrom nur auf den Host. Für einige Services kann jeder verfügbare Port verwendet werden. Für andere kann der Systemprogrammierer wie folgt auswählen, welcher Port oder Portbereich verwendet werden soll:
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, sucht der CARMA-Miner, der als Benutzerthread in einem RSE-Thread-Pool aktiv ist, nach einem freien Port des Bereichs, der in der Konfigurationsdatei CRASRV.properties angegeben ist, 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. Sobald der Server mit dem Port verbunden ist, kann der Client Anforderungen an den Server senden und Ergebnisse empfangen.
Aus Sicht des TCP/IP ist demnach 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.
Nach der Anmeldung kann mit PassTickets innerhalb des RSE-Servers die Threadsicherheit gewährleistet werden. Dieses Feature kann nicht inaktiviert werden. PassTickets sind vom System generierte Kennwörter mit einer Lebensdauer von ca. 10 Minuten. Die generierten PassTickets basieren auf den DES-Verschlüsselungsalgorithmen, der Benutzer-ID, der Anwendungs-ID, einer Zeitmarke und einem geheimen Schlüssel. Dieser geheime Schlüssel ist eine 64-Bit-Zahl (16 Hexadezimalzeichen), die für Ihre Sicherheitssoftware definiert werden muss.
Nachfolgend sehen Sie eine kurze Beschreibung des RSE-Sicherheitsprozesses, die Ihnen helfen soll, die PassTicket-Verwendung zu verstehen.
Das eigentliche Kennwort des Clients wird nach der ersten Authentifizierung nicht mehr benötigt, da die mit SAF kompatiblen Sicherheitsprodukte sowohl PassTickets als auch reguläre Kennwörter überprüfen. Der RSE-Server generiert jedes Mal, wenn ein Kennwort erforderlich ist, ein PassTicket und verwendet dieses, sodass das Kennwort für den Client nur temporär gültig ist.
Durch die Verwendung von PassTickets kann RSE eine beliebige benutzerspezifische Sicherheitsumgebung einrichten, ohne dabei alle Benutzer-IDs und Kennwörter in einer Tabelle speichern zu müssen, was zu einer Beeinträchtigung führen könnte. Außerdem werden Clientauthentifizierungen ermöglicht, die keine wiederverwendbaren Kennwörter verwenden, wie X.509-Zertifikate.
Für Sicherheitsprofile in den Klassen APPL und PTKTDATA ist es erforderlich, PassTickets verwenden zu können. Diese Profile sind anwendungsspezifisch und haben daher keine Auswirkung auf Ihre aktuelle Systemkonfiguration.
Als Voraussetzung für anwendungsspezifische PassTickets müssen sowohl RSE als auch JES Job Monitor die gleiche Anwendungs-ID (APPLID) verwenden. Als Anwendungs-ID wird von beiden Servern standardmäßig FEKAPPL verwendet. Dies kann jedoch durch die Anweisung der APPLID in rsed.envvars für RSE und in FEJJCNFG für JES Job Monitor geändert werden.
Sie sollten OMVSAPPL nicht als Anwendungs-ID verwenden, da diese ID den geheimen Schlüssel zu den meisten z/OS UNIX-Anwendungen entschlüsselt. Sie sollten ebenso nicht die standardmäßige MVS-Anwendungs-ID (MVS gefolgt von der SMF-ID des Systems) verwenden, da diese ID den geheimen Schlüssel zu den meisten MVS-Anwendungen (einschließlich Benutzer-Batch-Jobs) entschlüsselt.
Achtung: Die Clientverbindungsanforderung schlägt fehl, wenn PassTickets nicht richtig konfiguriert sind. |
Developer for System z unterstützt die Prüfprotokollierung für Aktionen, die vom RSE-Dämon verwaltet werden. Die Prüfprotokolle werden als Textdateien im CSV-Format (Comma Separated Value) im Dämonprotokollverzeichnis gespeichert.
Die Prüffunktion wird von mehreren Optionen in rsed.envvars beeinflusst. Lesen Sie hierzu die Informationen unter Zusätzliche Java-Startparameter mit _RSE_JAVAOPTS definieren.
Mit dem Bedienerbefehl modify switch kann manuell zu einer neuen Prüfprotokolldatei gewechselt werden (siehe Bedienerbefehle).
Wenn im Dateisystem mit den Prüfprotokolldateien nur noch ein kleiner freier Speicherbereich verfügbar ist, wird eine Warnung an die Konsole gesendet. Diese Konsolnachricht (FEK103E) wird immer wieder angezeigt, bis das Speicherproblem gelöst ist. Eine Liste der von RSE generierten Konsolnachrichten finden Sie im Abschnitt Konsolnachrichten.
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.
Folgende Aktionen werden protokolliert:
Jede protokollierte Aktion wird (mit einer Datums-/Zeitmarke) im CSV-Format (Comma Separated Value) gespeichert, das von Automatisierungs- oder Datenanalysetools gelesen werden kann.
Prüfprotokolldateien haben die Berechtigungsbitmaske 640 (-rw-r-----). Dies bedeutet, der Eigner (z/OS UNIX-Benutzer-ID des RSE-Dämons) hat Lese- und Schreibzugriff auf die Dateien. Die Standardgruppe des Eigners hat Lesezugriff. 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 in der Klasse UNIXPRIV unternommen werden.
Developer for System z ermöglicht Clients den Zugriff auf die JES-Spooldatei über JES Job Monitor. Der Server etabliert Basiszugriffsbeschränkungen, die Sie mit den Standardschutzfeatures für die Spooldatei in Ihrem Sicherheitsprodukt erweitern können. Bedieneraktionen für Spooldateien (Hold, Release, Cancel und Purge) werden über die EMCS-Konsole ausgeführt, für die bedingte Berechtigungen konfiguriert werden müssen.
JES Job Monitor ermöglicht Benutzern von Developer for System z keinen umfassenden JES-Spoolzugriff. Es stehen nur die Befehle 'Hold', 'Release', 'Cancel' und 'Purge' zur Verfügung und dies standardmäßig nur für Spooldateien, deren Eigner der Benutzer ist. Die Befehle werden durch Auswahl der entsprechenden Option in der Clientmenüstruktur abgesetzt (keine Eingabeaufforderung). Mit Sicherheitsprofilen, die definieren, für welche Jobs die Befehle verfügbar sind, kann der Geltungsbereich der Befehle ausgedehnt werden.
Ähnlich wie das SDSF-Aktionszeichen SJ unterstützt auch JES Job Monitor den Befehl 'JCL anzeigen', um die JCL abzurufen, die die ausgewählte Jobausgabe erstellt hat. Diese wird in einem Editierfenster angezeigt. JES Job Monitor ruft die JCL von JES ab. Dies ist eine hilfreiche Funktion in Situationen, in denen das ursprüngliche JCL-Member nicht einfach auffindbar ist.
Aktion | JES2 | JES3 |
---|---|---|
Hold | $Hx(jobid)
x = {J, S oder T} |
*F,J=jobid,H |
Release | $Ax(jobid)
x = {J, S oder T} |
*F,J=jobid,R |
Cancel | $Cx(jobid)
x = {J, S oder T} |
*F,J=jobid,C |
Purge | $Cx(jobid),P
x = {J, S oder T} |
*F,J=jobid,C |
JCL anzeigen | Nicht zutreffend | Nicht zutreffend |
Die verfügbaren JES-Befehle, die in Tabelle 21 aufgelistet sind, sind standardmäßig auf Jobs beschränkt, deren Eigner der Benutzer ist. Mit der Anweisung LIMIT_COMMANDS kann dies geändert werden (siehe Abschnitt Konfigurationsdatei für JES Job Monitor (FEJJCNFG)).
Jobeigner | ||
---|---|---|
LIMIT_COMMANDS | Benutzer | Anderer Eigner |
USERID (Standard) | Zulässig | Nicht zulässig |
LIMITED | Zulässig | Zulässig, wenn die Berechtigung explizit in den Sicherheitsprofilen erteilt wird |
NOLIMIT | Zulässig | Zulässig, wenn die Sicherheitsprofile die Berechtigung enthalten oder die JESSPOOL-Klasse nicht aktiv ist |
Für den Schutz von SYSIN/SYSOUT-Dateien verwendet das JES die Klasse JESSPOOL. Ähnlich wie SDSF, wendet JES Job Monitor die Klasse JESSPOOL auch auf den Schutz von Jobressourcen an.
Wenn LIMIT_COMMANDS nicht auf USERID gesetzt ist, fordert JES Job Monitor die Berechtigung für das entsprechende Profil in der Klasse JESSPOOL an, wie in der folgenden Tabelle aufgeführt.
Befehl | JESSPOOL-Profil | Erforderlicher Zugriff |
---|---|---|
Hold | nodeid.userid.jobname.jobid | ALTER |
Release | nodeid.userid.jobname.jobid | ALTER |
Cancel | nodeid.userid.jobname.jobid | ALTER |
Purge | nodeid.userid.jobname.jobid | ALTER |
JCL anzeigen | nodeid.userid.jobname.jobid.JCL | READ |
Verwenden Sie in der vorherigen Tabelle die folgenden Ersetzungen:
Knoten-ID | NJE-Knoten-ID des Ziel-JES |
Benutzer-ID | Lokale Benutzer-ID des Jobeigners |
Jobname | Name des Jobs |
Job-ID | JES-Job-ID |
Wenn die Klasse JESSPOOL nicht aktiv ist, bewirken die Werte LIMITED und NOLIMIT für LIMIT_COMMANDS ein unterschiedliches Verhalten (siehe Tabelle 9). 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 unteren Beschränkungen 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 Konfigurationsdatei für JES Job Monitor (FEJJCNFG) dokumentiert.
Der Sicherheitsadministrator kann mit dieser Konfiguration unter Verwendung der Klassen OPERCMDS und CONSOLE differenzierte Berechtigungen zur Befehlsausführung definieren.
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.
Beachten Sie, dass JES Job Monitor die Konsole zur Ausführung eines Befehls nicht erstellen kann, wenn der Konsolname bereits verwendet wird. Um dies zu verhindern, kann der Systemprogrammierer in der JES Job Monitor-Konfigurationsdatei die Anweisung GEN_CONSOLE_NAME=ON setzen. Alternativ kann der Sicherheitsadministrator Sicherheitsprofile definieren, um zu verhindern, dass TSO-Benutzer eine Konsole erstellen. Die folgenden RACF-Beispielbefehle hindern jeden Benutzer (mit Ausnahme berechtigter Benutzer) am Erstellen einer TSO- oder SDSF-Konsole:
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. Mit der Anweisung LIMIT_VIEW kann dies geändert werden (siehe Abschnitt Konfigurationsdatei für JES Job Monitor (FEJJCNFG)).
Jobeigner | ||
---|---|---|
LIMIT_VIEW | Benutzer | Anderer Eigner |
USERID | Zulässig | Nicht zulässig |
NOLIMIT (default) | Zulässig | Zulässig, wenn die Sicherheitsprofile die Berechtigung enthalten oder die JESSPOOL-Klasse nicht aktiv ist |
Wenn Benutzer nur ihre eigenen JES-Spool-Jobs anzeigen können sollen, definieren Sie in der Konfigurationsdatei von JES Job Monitor (FEJJCNFG) die Anweisung "LIMIT_VIEW=USERID". Falls Benutzer auf weitere Jobs zugreifen müssen, jedoch nicht auf alle Jobs, können Sie die Standardschutzfeatures für Spooldateien verwenden, beispielsweise die Klasse JESSPOOL.
Denken Sie beim Definieren weiterer Schutzmaßnahmen daran, dass JES Job Monitor für den Zugriff auf Spooldateien (die SYSOUT-Anwendungsprogrammierschnittstelle) SAPI verwendet. Damit ist impliziert, dass der Benutzer für Spooldateien (selbst zum Anzeigen) zumindest die Berechtigung UPDATE haben muss. Diese Voraussetzung gilt nicht unter z/OS ab Version 1.7 (für JES3 unter z/OS ab Version 1.8). Für Anzeigefunktionen ist die Berechtigung READ ausreichend.
Weitere Informationen zum Schutz von JES-Spooldateien finden Sie im Security Server RACF Security Administrator's Guide (IBM Form SA22-7683).
Die externe Kommunikation (Client-Host) kann mit SSL (Secure Socket Layer) verschlüsselt werden. Dieses Feature ist standardmäßig inaktiviert und wird von den Einstellungen in ssl.properties gesteuert, wie im Abschnitt RSE-SSL-Verschlüsselung (optional) dokumentiert.
Aufgrund unterschiedlicher Architektur unterstützen der RSE-Dämon und der RSE-Server verschiedene Mechanismen zum Speichern von Zertifikaten. Dies impliziert, dass für den RSE-Dämon sowie den RSE-Server SSL-Definitionen und -Zertifikate erforderlich sind. Ein gemeinsam genutztes Zertifikat kann verwendet werden, wenn der RSE-Dämon und der RSE-Server dieselbe Zertifikatsverwaltungsmethode verwenden.
Zertifikatsspeicher | Erstellt und verwaltet von | RSE-Dämon | RSE-Server |
---|---|---|---|
Schlüsseldatei | SAF-konformes Sicherheitsprodukt | unterstützt | unterstützt |
Schlüsseldatenbank | gskkyman von z/OS UNIX | unterstützt | / |
Keystore | Java-Keytool | / | unterstützt |
SAF-konforme Schlüsseldateien können den privaten Schlüssel eines Zertifikats entweder in der Sicherheitsdatenbank oder mithilfe von ICSF (Integrated Cryptographic Service Facility) speichern, der Schnittstelle für Verschlüsselungshardware von System z.
ICSF wird für die Speicherung von privaten Schlüsseln für digitale Zertifikate empfohlen, da diese Methode sicherer als andere Lösungen zur Verwaltung von privaten Schlüsseln ohne ICSF ist. Mit ICSF wird sichergestellt, dass private Schlüssel unter dem ICSF-Masterschlüssel verschlüsselt werden und dass der Zugriff auf diese Schlüssel von allgemeinen Ressourcen in den Sicherheitsklassen CSFKEYS und CSFSERV gesteuert wird. Außerdem bietet ICSF eine bessere Betriebsleistung, da bei dieser Methode die Hardware Cryptographic Coprocessor verwendet.
Zum Verwalten von Kommunikation, die mit SSL verschlüsselt ist, verwendet der RSE-Dämon System SSL-Funktionen. Dies impliziert, dass SYS1.SIEALNKE von Ihrer Sicherheitssoftware programmgesteuert und RSE über LINKLIST oder die STEPLIB-Anweisung in rsed.envvars verfügbar sein muss.
Wenn SAF-konforme Schlüsseldateien für den RSE-Dämon oder RSE-Server verwendet werden, ist für die RSE-Benutzer-ID (STCRSE in den unteren Beispielbefehlen) die Genehmigung für den Zugriff auf die Schlüsseldatei und die zugeordneten Zertifikate erforderlich.
Weitere Details zur Aktivierung von SSL für Developer for System z finden Sie in Anhang A. SSL- und X.509-Authentifizierung konfigurieren.
Mit einem X.509-Zertifikat unterstützt der RSE-Dämon die eigene Authentifizierung der Benutzer. Voraussetzung hierfür ist die Verwendung der mit SSL verschlüsselten Kommunikation, da dies eine Erweiterung der Hostauthentifizierung mit einem in SSL verwendeten Zertifikat ist.
Der RSE-Dämon startet den Prozess zur Clientauthentifizierung mit der Prüfung des Clientzertifikats. Einige wichtige Aspekte, die geprüft werden, sind die Gültigkeitsdaten des Zertifikats und die Vertrauenswürdigkeit der Zertifizierungsstelle (CA), die das Zertifikat unterzeichnet hat. Optional kann auch eine Zertifikatswiderrufsliste (CRL) eines anderen Anbieters zu Rate gezogen werden.
Nachdem der RSE-Dämon das Zertifikat geprüft hat, ist es zur Authentifizierung bereit. Das Zertifikat wird an Ihr Sicherheitsprodukt zur Authentifizierung weitergegeben, sofern die rsed.envvars-Anweisung enable.certificate.mapping nicht auf false gesetzt ist. In diesem Fall führt der RSE-Dämon die Authentifizierung durch.
Bei erfolgreicher Authentifizierung legt der Authentifizierungsprozess die in dieser Sitzung zu verwendende Benutzer-ID fest. Diese wird dann vom RSE-Dämon getestet, um sicherzustellen, dass sie für das Hostsystem verwendbar ist, auf dem der RSE-Dämon aktiv ist.
In der letzten Überprüfung (die nicht nur bei Authentifizierungsverfahren mit X.509-Zertifikaten durchgeführt wird, sondern bei allen Verfahren) wird die Berechtigung der Benutzer-ID für die Verwendung von Developer for System z überprüft.
Wenn Sie mit den von TCP/IP verwendeten SSL-Sicherheitsklassifikationen vertraut sind: Die Kombination dieser Überprüfungsschritte entspricht den Spezifikationen der Stufe 3 der Clientauthentifizierung (höchste verfügbare Stufe).
Ein Bestandteil des Zertifikatsüberprüfungsprozesses besteht in der Prüfung, ob das Zertifikat von einer vertrauenswürdigen Zertifizierungsstelle (CA) unterschrieben wurde. Um dies ausführen zu können, muss der RSE-Dämon Zugriff auf ein Zertifikat haben, das die CA identifiziert.
Wenn für Ihre SSL-Verbindung die gskkyman-Schlüsseldatenbank verwendet wird, muss das CA-Zertifikat der Schlüsseldatenbank hinzugefügt werden.
Wenn eine SAF-Schlüsseldatei verwendet wird (empfohlene Methode), müssen Sie Ihrer Sicherheitsdatenbank das CA-Zertifikat als ein CERTAUTH-Zertifikat mit dem TRUST- oder HIGHTRUST-Attribut hinzufügen, wie in dem folgenden RACF-Beispielbefehl gezeigt wird:
Beachten Sie, dass in den Datenbanken der meisten Sicherheitsprodukte bereits Zertifikate von bekannten CAs mit dem Status NOTRUST vorhanden sind. Verwenden Sie die folgenden RACF-Beispielbefehle, um die vorhandenen CA-Zertifikate aufzulisten und um ein Zertifikat, basierend auf der zugeordneten Bezeichnung, als vertrauenswürdig zu markieren.
Sobald ein CA-Zertifikat Ihrer Sicherheitsdatenbank hinzugefügt ist, muss es mit der RSE-Schlüsseldatei verbunden werden, wie in dem folgenden RACF-Beispielbefehl gezeigt wird:
Weitere Informationen zum RACDCERT-Befehl enthält die Veröffentlichung Security Server RACF Command Language Reference (IBM Form SA22-7687).
Achtung: Wenn zur Authentifizierung eines Benutzers der RSE-Dämon anstelle Ihrer Sicherheitssoftware zugrunde gelegt wird, müssen Sie darauf achten, in der SAF-Schlüsseldatei bzw. der gskkyman-Schlüsseldatenbank die CAs mit den TRUST- und HIGHTRUST-Status nicht zu vermischen. Der RSE-Dämon kann zwischen diesen beiden Status nicht unterscheiden. Daher sind Zertifikate, die von einer CA mit TRUST-Status unterschrieben wurden, zur Authentifizierung der Benutzer-ID gültig. |
Falls gewünscht, können Sie den RSE-Dämon anweisen, eine oder mehrere Zertifikatswiderrufslisten (CRL) zu überprüfen. Dies erweitert den Sicherheitsschutz des Überprüfungsprozesses. Dafür werden der Datei rsed.envvars CRL-bezogene Umgebungsvariablen hinzugefügt. Informationen zu diesen Beispielvariablen enthält der Abschnitt RSE-Konfigurationsdatei rsed.envvars:
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.
Zertifikate werden mithilfe des RACDCERT-Befehls in RACF definiert, wie das folgende Beispiel zeigt:
RACDCERT ID(userid) ADD(dsn) TRUST WITHLABEL('Bezeichnung')
Die Benutzer-ID und das Hostnamenspaar sind gültig, wenn alle folgenden Bedingungen wahr sind:
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 }
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 dabei 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.
Die Benutzer-ID und das Hostnamenspaar sind gültig, wenn alle folgenden Bedingungen wahr sind:
Achtung: Der Sicherheitsadministrator muss sicherstellen, dass alle dem RSE-Dämon bekannten CAs sehr vertrauenswürdig sind, da der RSE-Dämon nicht überprüfen kann, ob der Unterzeichner des Clientzertifikats sehr vertrauenswürdig oder nur vertrauenswürdig ist. Weitere Informationen zu zugänglichen CA-Zertifikaten enthält der Abschnitt Prüfung der Zertifizierungsstelle (CA). |
Developer for System z unterstützt die Prüfung des Eingangsports, die eine Beschränkung des Hostzugriffs auf anerkannte TCP/IP-Adressen ermöglicht. Dieses Feature ist standardmäßig inaktiviert und erfordert die Definition des Sicherheitsprofils BPX.POE. Vergleichen Sie hierzu die folgenden RACF-Beispielbefehle:
Weitere Informationen zur Kontrolle des Netzzugriffs durch die Eingangsportüberprüfung enthält die Veröffentlichung Communications Server IP Configuration Guide (IBM Form SC31-8775).
Developer for System z ermöglicht CICS-Administratoren über Application Deployment Manager die für den Entwickler editierbaren CICS-Ressourcendefinitionen, deren Standardwerte sowie die Anzeige einer CICS-Ressourcendefinition mithilfe des CICS Resource Definition-Servers (CRD) zu steuern. Weitere Informationen zu den erforderlichen CICS-TS-Sicherheitsdefinitionen enthält CICSTS-Aspekte.
Die VSAM-Datei für das CRD-Server-Repository enthält alle Standardressourcendefinitionen und muss daher vor Aktualisierungen geschützt werden. Entwickler müssen jedoch die Möglichkeit haben, die hier gespeicherten Werte zu lesen.
Developer for System z stellt mehrere Transaktionen bereit, die der CRD-Server beim Definieren und Abfragen von CICS-Ressourcen verwendet. Wenn die Transaktion zugeordnet wird, stellt die Sicherheitsprüfung für CICS-Ressourcen (sofern aktiviert) sicher, dass die Benutzer-ID berechtigt ist, die Transaktions-ID zu verwenden.
Die Clientkomponente von Application Deployment Manager ruft mit CICS-TS-Web-Services oder der RESTful-Schnittstelle den CRD-Server auf. Die Verwendung von SSL für diese Kommunikation wird von der CICS-TS-Definition TCPIPSERVICE gesteuert. Diese Art der Verwendung ist im RACF Security Guide for CICS TS dokumentiert.
SCLM Developer Toolkit stellt optionale Sicherheitsfunktionen für die Builderstellung, die Umstufung und das Deployment bereit.
Wenn ein SCLM-Administrator die Sicherheit für eine Funktion aktiviert hat, wird SAF aufgerufen, um zu überprüfen, ob die geschützte Funktion mit der ID des Aufrufenden oder einer Ersatzbenutzer-ID ausgeführt werden darf.
Weitere Informationen zu den erforderlichen SCLM-Sicherheitsdefinitionen enthält der SCLM Developer Toolkit Administrator's Guide (IBM Form SC23-9801).
Es gibt mehrere Konfigurationsdateien für Developer for System z, deren Anweisungen Auswirkungen auf die Sicherheitskonfiguration haben. Auf der Basis der Informationen in diesem Kapitel können der Sicherheitsadministrator und Systemprogrammierer entscheiden, welche Einstellungen für die folgenden Anweisungen verwendet werden sollten.
Definieren, welche Jobaktionen durchgeführt werden können (mit Ausnahme von 'Durchsuchen' und 'Übergeben'). Weitere Informationen enthält der Abschnitt Aktionen für Beschränkungen der Jobziele.
Definieren, welche Spooldateien durchsucht werden können. Weitere Informationen enthält der Abschnitt Zugriff auf Spooldateien.
Die Anwendungs-ID, die zum Erstellen/Überprüfen von PassTicket verwendet wird. Weitere Informationen enthält der Abschnitt PassTickets verwenden.
Lehnen Sie das Speichern von Hostkennwörtern auf dem Client seitens der Benutzer ab. Weitere Informationen enthält der Abschnitt Zusätzliche Java-Startparameter mit _RSE_JAVAOPTS definieren.
Zeitgeber zum Trennen der Verbindung inaktiver Clients. Weitere Informationen enthält der Abschnitt Zusätzliche Java-Startparameter mit _RSE_JAVAOPTS definieren.
Die Anwendungs-ID, die zum Erstellen/Überprüfen von PassTicket verwendet wird. Weitere Informationen enthält der Abschnitt PassTickets verwenden.
Aktivieren der Überprüfung des Eingangsports. Weitere Informationen enthält der Abschnitt Eingangsport (POE) überprüfen.
Verwenden Sie Ihr Sicherheitsprodukt zum Authentifizieren der Benutzer mit einem X.509-Zertifikat. Weitere Informationen enthält der Abschnitt Clientauthentifizierung unter Verwendung von X.509-Zertifikaten.
Position der Prüfprotokolldateien. Weitere Informationen enthält der Abschnitt Prüfprotokollierung.
Position des RSE-Dämonzertifikats. Weitere Informationen enthält der Abschnitt Mit SSL verschlüsselte Kommunikation.
Name des RSE-Dämonzertifikats. Weitere Informationen enthält der Abschnitt Mit SSL verschlüsselte Kommunikation.
Position des RSE-Serverzertifikats. Weitere Informationen enthält der Abschnitt Mit SSL verschlüsselte Kommunikation.
Name des RSE-Serverzertifikats. Weitere Informationen enthält der Abschnitt Mit SSL verschlüsselte Kommunikation.
Verwendeter Keystoretyp (Java-Keystore oder SAF-Schlüsseldatei). Weitere Informationen enthält der Abschnitt Mit SSL verschlüsselte Kommunikation.
Passen Sie das Beispielmember FEKRACF an, das RACF- und z/OS UNIX-Beispielbefehle enthält, und übergeben sie es, um die Basissicherheitsdefinitionen für Developer for System z zu erstellen.
FEKRACF befindet sich in FEK.#CUST.JCL, sofern Sie bei der Anpassung und Übergabe des Jobs FEK.SFEKSAMP(FEKSETUP) keine andere Position angegeben haben. Weitere Details enthält der Abschnitt Anpassungskonfiguration.
Weitere Informationen zu RACF-Befehlen finden Sie in der Veröffentlichung RACF Command Language Reference (IBM Form SA22-7687).
In den folgenden Abschnitten sind die erforderlichen Schritte, die optionale Konfiguration und mögliche Alternativen beschrieben.
Der Sicherheitsadministrator muss die in Tabelle 26 aufgelisteten Werte kennen, um die Sicherheitskonfiguration abzuschließen. Diese Werte wurden in früheren Schritten der Installation und Anpassung von Developer for System z definiert.
Beschreibung |
|
Wert |
---|---|---|
Übergeordnetes Qualifikationsmerkmal für Developer for System z |
|
|
Übergeordnetes Qualifikationsmerkmal für die Anpassung von System z |
|
|
Name der gestarteten Task von JES Job Monitor |
|
|
Name der gestarteten Task des RSE-Dämons |
|
|
Name der gestarteten Task des Sperrdämons |
|
|
Anwendungs-ID |
|
Nachfolgend sind die Aktionen, die zur vollständigen Basissicherheitskonfiguration von Developer for System z erforderlich sind, übersichtlich aufgelistet. Um diese Anforderungen zu erfüllen, können je nach angestrebter Sicherheitsstufe verschiedene Methoden angewendet werden, wie in den unteren Abschnitten dokumentiert ist. Weitere Informationen zu den Sicherheitskonfigurationen von optionalen Developer for System z-Services enthalten die vorherigen Abschnitte.
Developer for System z verwendet eine Vielzahl von Sicherheitsmechanismen, um für den Client eine geschützte und kontrollierte Hostumgebung bereitzustellen. Zu diesem Zweck müssen mehrere Klassen und Sicherheitseinstellungen aktiv sein. Vergleichen Sie hierzu die folgenden RACF-Beispielbefehle:
SETROPTS LIST
SETROPTS GENERIC(FACILITY)
SETROPTS CLASSACT(FACILITY) RACLIST(FACILITY)
SETROPTS GENERIC(STARTED)
RDEFINE STARTED ** STDATA(USER(=MEMBER) GROUP(STCGROUP) TRACE(YES))
SETROPTS CLASSACT(STARTED) RACLIST(STARTED)
SETROPTS GENERIC(CONSOLE)
SETROPTS CLASSACT(CONSOLE) RACLIST(CONSOLE)
SETROPTS GENERIC(OPERCMDS)
SETROPTS CLASSACT(OPERCMDS) RACLIST(OPERCMDS)
SETROPTS GENERIC(APPL)
SETROPTS CLASSACT(APPL) RACLIST(APPL)
SETROPTS GENERIC(PTKTDATA)
SETROPTS CLASSACT(PTKTDATA) RACLIST(PTKTDATA)
RDEFINE PROGRAM ** ADDMEM('SYS1.CMDLIB'//NOPADCHK) UACC(READ)
SETROPTS WHEN(PROGRAM)
Achtung: Wenn "WHEN PROGRAM" aktiv ist, müssen einige Produkte (beispielsweise FTP) programmgesteuert sein. Testen Sie eine solche Definition, bevor Sie sie auf einem Produktionssystem aktivieren. |
SETROPTS GENERIC(SERVAUTH)
SETROPTS CLASSACT(SERVAUTH) RACLIST(SERVAUTH)
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 jedes Benutzers ist ebenfalls ein OMVS-Segment mit einer Gruppen-ID erforderlich.
Ersetzen Sie in den folgenden RACF-Beispielbefehlen die Platzhalter #userid, #user-identifier, #group-name und #group-identifier durch tatsächliche Werte:
ALTUSER #userid OMVS(UID(#user-identifier) HOME(/u/#userid) PROGRAM(/bin/sh) NOASSIZEMAX)
ALTGROUP #group-name OMVS(GID(#group-identifier))
Sie können das im Profil BPX.DEFAULT.USER der Klasse FACILITY definierte, gemeinsam genutzte OMVS-Segment verwenden, um die OMVS-Segmentanforderungen von Developer for System z zu erfüllen. Dies wird jedoch nicht empfohlen.
Für die meisten Dateien von Developer for System z reicht das Zugriffsrecht READ für Benutzer und ALTER für Systemprogrammierer aus. Ersetzen Sie den Platzhalter #sysprog durch gültige Benutzer-IDs oder RACF-Gruppennamen. Fragen Sie außerdem den Systemprogrammierer, der das Produkt installiert und konfiguriert hat, nach den korrekten Dateinamen. Der während der Installation verwendete Standard-High-Level-Qualifier ist FEK. Der Standard-High-Level-Qualifier 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
Einige der optionalen Komponenten von Developer for System z erfordern zusätzliche Sicherheitsdateiprofile. Ersetzen Sie die Platzhalter #sysprog, #ram-developer und #cicsadmin durch gültige Benutzer-IDs oder RACF-Gruppennamen:
ADDSD 'FEK.#CUST.LSTRANS.*.**' UACC(UPDATE) DATA('RATIONAL DEVELOPER FOR SYSTEM Z - SCLMDT')
PERMIT 'FEK.#CUST.LSTRANS.*.**' CLASS(DATASET) ACCESS(ALTER) ID(#sysprog)
SETROPTS GENERIC(DATASET) REFRESH
ADDSD 'FEK.#CUST.CRA*.**' UACC(READ) DATA('RATIONAL DEVELOPER FOR SYSTEM Z - CARMA')
PERMIT 'FEK.#CUST.CRA*.**' CLASS(DATASET) ACCESS(ALTER) ID(#sysprog)
PERMIT 'FEK.#CUST.CRA*.**' CLASS(DATASET) ACCESS(UPDATE) ID(#ram-developer)
SETROPTS GENERIC(DATASET) REFRESH
ADDSD 'FEK.#CUST.ADNREP*.**' UACC(READ) DATA('RATIONAL DEVELOPER FOR SYSTEM Z - ADN')
PERMIT 'FEK.#CUST.ADNREP*.**' CLASS(DATASET) ACCESS(ALTER) ID(#sysprog)
PERMIT 'FEK.#CUST.ADNREP*.**' CLASS(DATASET) ACCESS(UPDATE) ID(#cicsadmin)
SETROPTS GENERIC(DATASET) REFRESH
ADDSD 'FEK.#CUST.ADNMAN*.**' UACC(UPDATE) DATA('RATIONAL DEVELOPER FOR SYSTEM Z - ADN')
PERMIT 'FEK.#CUST.ADNMAN*.**' CLASS(DATASET) ACCESS(ALTER) ID(#sysprog)
SETROPTS GENERIC(DATASET) REFRESH
Verwenden Sie die folgenden RACF-Beispielbefehle für eine besser geschützte Konfiguration, bei der auch die Zugriffsberechtigung READ kontrolliert wird.
ADDGROUP (FEK) DATA('RATIONAL DEVELOPER FOR SYSTEM Z - HLQ STUB') OWNER(IBMUSER) SUPGROUP(SYS1)"
ADDSD 'FEK.*.**' UACC(NONE) DATA('RATIONAL DEVELOPER FOR SYSTEM Z')
ADDSD 'FEK.SFEKAUTH' UACC(NONE) DATA('RATIONAL DEVELOPER FOR SYSTEM Z')
ADDSD 'FEK.SFEKLOAD' UACC(NONE) DATA('RATIONAL DEVELOPER FOR SYSTEM Z')
ADDSD 'FEK.SFEKPROC' UACC(NONE) DATA('RATIONAL DEVELOPER FOR SYSTEM Z')
ADDSD 'FEK.#CUST.PARMLIB' UACC(NONE) DATA('RATIONAL DEVELOPER FOR SYSTEM Z')
ADDSD 'FEK.#CUST.CNTL' UACC(NONE) DATA('RATIONAL DEVELOPER FOR SYSTEM Z')
ADDSD 'FEK.#CUST.LSTRANS.*.**' UACC(NONE) DATA('RATIONAL DEVELOPER FOR SYSTEM Z - SCLMDT')
ADDSD 'FEK.#CUST.CRA*.**' UACC(NONE) DATA('RATIONAL DEVELOPER FOR SYSTEM Z - CARMA')
ADDSD 'FEK.#CUST.ADNREP*.**' UACC(NONE) DATA('RATIONAL DEVELOPER FOR SYSTEM Z - ADN')
ADDSD 'FEK.#CUST.ADNMAN*.**' UACC(NONE) DATA('RATIONAL DEVELOPER FOR SYSTEM Z - ADN')
PERMIT 'FEK.*.** CLASS(DATASET) ACCESS(ALTER) ID(#sysprog)
PERMIT 'FEK.SFEKAUTH CLASS(DATASET) ACCESS(ALTER) ID(#sysprog)
PERMIT 'FEK.SFEKLOAD CLASS(DATASET) ACCESS(ALTER) ID(#sysprog)
PERMIT 'FEK.SFEKLOAD CLASS(DATASET) ACCESS(ALTER) ID(#sysprog)
PERMIT 'FEK.SFEKLOAD CLASS(DATASET) ACCESS(ALTER) ID(#sysprog)
PERMIT 'FEK.SFEKPROC CLASS(DATASET) ACCESS(ALTER) ID(#sysprog)
PERMIT 'FEK.#CUST.PARMLIB CLASS(DATASET) ACCESS(ALTER) ID(#sysprog)
PERMIT 'FEK.#CUST.CNTL CLASS(DATASET) ACCESS(ALTER) ID(#sysprog)
PERMIT 'FEK.#CUST.LSTRANS.*.**' CLASS(DATASET) ACCESS(ALTER) ID(#sysprog)
PERMIT 'FEK.#CUST.CRA*.**' CLASS(DATASET) ACCESS(ALTER) ID(#sysprog)
PERMIT 'FEK.#CUST.ADNREP*.**' CLASS(DATASET) ACCESS(ALTER) ID(#sysprog)
PERMIT 'FEK.#CUST.ADNMAN*.**' CLASS(DATASET) ACCESS(ALTER) ID(#sysprog)
PERMIT 'FEK.SFEKAUTH' CLASS(DATASET) ACCESS(READ) ID(*)
PERMIT 'FEK.SFEKLOAD' CLASS(DATASET) ACCESS(READ) ID(*)
PERMIT 'FEK.SFEKPROC' CLASS(DATASET) ACCESS(READ) ID(*)
PERMIT 'FEK.#CUST.CNTL' CLASS(DATASET) ACCESS(READ) ID(*)
PERMIT 'FEK.SFEKAUTH' CLASS(DATASET) ACCESS(READ) ID(STCJMON)
PERMIT 'FEK.#CUST.PARMLIB' CLASS(DATASET) ACCESS(READ) ID(STCJMON)
PERMIT 'FEK.#CUST.LSTRANS.*.**' CLASS(DATASET) ACCESS(UPDATE) ID(*)
PERMIT 'FEK.#CUST.CRA*.**' CLASS(DATASET) ACCESS(UPDATE) ID(#ram-developer)
PERMIT 'FEK.#CUST.ADNREP*.**' CLASS(DATASET) ACCESS(READ) ID(*)
PERMIT 'FEK.#CUST.ADNREP*.**' CLASS(DATASET) ACCESS(UPDATE) ID(#cicsadmin)
PERMIT 'FEK.#CUST.ADNMAN*.**' CLASS(DATASET) ACCESS(UPDATE) ID(*)
PERMIT 'FEK.SFEKLOAD' CLASS(DATASET) ACCESS(READ) ID(#cicsts)
PERMIT 'FEK.SFEKPROC' CLASS(DATASET) ACCESS(READ) ID(#db2)
SETROPTS GENERIC(DATASET) REFRESH
Wenn Sie das Zugriffsrecht READ für Systemdateien kontrollieren möchten, müssen Sie Servern und Benutzern von Developer for System z die Berechtigung READ für folgende Dateien einräumen:
Die folgenden RACF-Beispielbefehle erstellen die gestarteten Tasks JMON, RSED und LOCKD mit der ihnen jeweils zugeordneten geschützten Benutzer-ID (STCJMON, STCRSE beziehungsweise STCLOCK) und der Gruppe STCGROUP. Ersetzen Sie die Platzhalter #group-id und #user-id-* durch gültige OMVS-IDs.
ADDGROUP STCGROUP OMVS(GID(#group-id)) DATA('GROUP WITH OMVS SEGMENT FOR STARTED TASKS')
ADDUSER STCJMON DFLTGROUP(STCGROUP) NOPASSWORD NAME('RDZ - JES JOBMONITOR') OMVS(UID(#user-id-jmon) HOME(/tmp) PROGRAM(/bin/sh) NOASSIZEMAX NOTHREADSMAX) DATA('RATIONAL DEVELOPER FOR SYSTEM Z')
ADDUSER STCRSE DFLTGROUP(STCGROUP) NOPASSWORD NAME('RDZ - RSE DAEMON') OMVS(UID(#user-id-rse) HOME(/tmp) PROGRAM(/bin/sh) ASSIZEMAX(2147483647) NOTHREADSMAX) DATA('RATIONAL DEVELOPER FOR SYSTEM Z')
ADDUSER STCLOCK DFLTGROUP(STCGROUP) NOPASSWORD NAME('RDZ - LOCK DAEMON') OMVS(UID(#user-id-lock) HOME(/tmp) PROGRAM(/bin/sh) NOASSIZEMAX) NOTHREADSMAX) DATA('RATIONAL DEVELOPER FOR SYSTEM Z')
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))
RDEFINE STARTED LOCKD.* DATA('RDZ - LOCK DAEMON') STDATA(USER(STCLOCK) GROUP(STCGROUP) TRUSTED(NO))
SETROPTS RACLIST(STARTED) REFRESH
Sie sollten überlegen, ob für die Benutzer-ID STCRSE Einschränkungen definiert werden müssen. Benutzer mit dem Attribut RESTRICTED können nicht auf geschützte Ressourcen (MVS) zugreifen, solange sie nicht ausdrücklich für den Zugriff berechtigt wurden.
ALTUSER STCRSE RESTRICTED
Um sicherzustellen, dass eingeschränkte Benutzer nicht über die 'anderen' Zugriffsbits Zugriff auf z/OS UNIX-Dateisystemressourcen erlangen, müssen Sie das Profil RESTRICTED.FILESYS.ACCESS in der Klasse UNIXPRIV mit UACC(NONE) definieren. Weitere Informationen zur Einschränkung von Benutzer-IDs finden Sie im Security Server RACF Security Administrator's Guide (IBM Form SA22-7683).
Achtung: Wenn Sie Einschränkungen für Benutzer-IDs festgelegt haben, müssen Sie die Berechtigung für den Zugriff auf eine Ressource explizit mit dem TSO-Befehl PERMIT oder dem z/OS UNIX-Befehl setfacl hinzufügen.
Dies ist unter anderem für Ressourcen erforderlich, für die die Dokumentation von Developer for System z UACC verwendet (wie das Profil ** in der Klasse PROGRAM) oder für die allgemeine z/OS UNIX-Konventionen gelten (beispielsweise, dass jeder Lese- und Ausführungsberechtigung für Java-Bibliotheken besitzt).
Testen Sie eine solche Definition, bevor Sie sie
auf einem Produktionssystem aktivieren. |
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 Konfigurationsdatei für JES Job Monitor (FEJJCNFG) dokumentiert.
Der folgende RACF-Beispielbefehl gewährt Benutzern von Developer for System z einen bedingten Zugriff auf eine eingeschränkte Gruppe von JES-Befehlen (Hold, Release, Cancel und Purge). Benutzer haben nur Ausführungsrechte, wenn sie die Befehle über JES Job Monitor absetzen. Ersetzen Sie den Platzhalter #console durch den aktuellen Konsolennamen.
RDEFINE OPERCMDS MVS.MCSOPER.#console UACC(READ) DATA('RATIONAL DEVELOPER FOR SYSTEM Z')
RDEFINE OPERCMDS JES%.** UACC(NONE)
PERMIT JES%.** CLASS(OPERCMDS) ACCESS(UPDATE) WHEN(CONSOLE(JMON)) ID(*)
SETROPTS RACLIST(OPERCMDS) REFRESH
Achtung: Wenn Sie in Ihrer Sicherheitssoftware die JES-Befehle mit dem universellen Zugriffsrecht NONE definieren, kann sich das negativ auf andere Anwendungen und Operationen auswirken. Testen Sie eine solche Definition, bevor Sie sie
auf einem Produktionssystem aktivieren. |
In Tabelle 27 und Tabelle 28 sehen Sie die Bedienerbefehle, die für JES2 und JES3 abgesetzt werden, sowie die eigenständigen Sicherheitsprofile zu deren Schutz.
Aktion | Befehl | OPERCMDS-Profil | Erforderlicher Zugriff |
---|---|---|---|
Hold | $Hx(jobid)
x = {J, S oder T} |
jesname.MODIFYHOLD.BAT jesname.MODIFYHOLD.STC jesname.MODIFYHOLD.TSU |
UPDATE |
Release | $Ax(jobid)
x = {J, S oder T} |
jesname.MODIFYRELEASE.BAT jesname.MODIFYRELEASE.STC jesname.MODIFYRELEASE.TSU |
UPDATE |
Cancel | $Cx(jobid)
x = {J, S oder T} |
jesname.CANCEL.BAT jesname.CANCEL.STC jesname.CANCEL.TSU |
UPDATE |
Purge | $Cx(jobid),P
x = {J, S oder T} |
jesname.CANCEL.BAT jesname.CANCEL.STC jesname.CANCEL.TSU |
UPDATE |
Aktion | Befehl | OPERCMDS-Profil | Erforderlicher Zugriff |
---|---|---|---|
Hold | *F,J=jobid,H |
jesname.MODIFY.JOB |
UPDATE |
Release | *F,J=jobid,R |
jesname.MODIFY.JOB |
UPDATE |
Cancel | *F,J=jobid,C |
jesname.MODIFY.JOB |
UPDATE |
Purge | *F,J=jobid,C |
jesname.MODIFY.JOB |
UPDATE |
Ihre Sicherheitssoftware verhindert, dass ein Benutzer in einer TSO-Sitzung eine Konsole JMON erstellt, weil er sich so als JES Job Monitor-Server ausgeben könnte. Auch wenn die Konsole erstellt werden kann, unterscheidet sich der Eingangsport (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 ist und der Benutzer nicht autorisiert ist, JES-Befehle über andere Mechanismen zu verwenden.
RSE benötigt die Zugriffsberechtigung UPDATE für das Profil BPX.SERVER, um die Sicherheitsumgebung für den Client-Thread erstellen/löschen zu können. Wenn dieses Profil nicht definiert ist, muss für RSE UID(0) verwendet werden.
Achtung: Mit dem Definieren des Profils BPX.SERVER wechselt z/OS UNIX vollständig von der Sicherheit auf UNIX-Ebene zur Sicherheit auf z/OS UNIX-Ebene, die bedeutend sicherer ist. Möglicherweise hat dies Auswirkungen auf andere z/OS UNIX-Anwendungen und -Operationen. Testen Sie eine solche Definition, bevor Sie sie
auf einem Produktionssystem aktivieren.
Weitere Informationen zu den verschiedenen Sicherheitsstufen finden Sie in der Veröffentlichung UNIX System Services Planning (IBM Form GA22-7800). |
Server mit der Berechtigung für BPX.SERVER müssen in einer sauberen, programmgesteuerten Umgebung ausgeführt werden. Dies impliziert, dass alle von RSE aufgerufenen Programme ebenfalls programmgesteuert sein müssen. Die Programmsteuerung von MVS-Ladebibliotheken wird von Ihrer Sicherheitssoftware verwaltet.
RSE verwendet die Systembibliothek (SYS1.LINKLIB), die Bibliothek der Laufzeit von Language Environment (CEE.SCEERUN*) und die Ladebibliothek des TSO/ISPF-Client-Gateways von ISPF (ISP.SISPLOAD).
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 Debug Tool.
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
RSE unterstützt die Verwendung von anderen Anwendungs-IDs als FEKAPPL. Ausführlichere Informationen dazu finden Sie im Abschnitt PassTicket-Unterstützung für RSE definieren. Die Klassendefinition APPL muss mit der eigentlichen, von RSE verwendeten Anwendungs-ID übereinstimmen.
Achtung: Die Clientverbindungsanforderung schlägt fehl, wenn das Anwendungsprofil nicht definiert ist oder wenn der Benutzer keinen Lesezugriff auf das Profil hat. |
Das Kennwort des Clients (oder andere Identifikationsmittel, wie ein X.509-Zertifikat) wird nur verwendet, um die Identität des Clients beim Herstellen der Verbindung zu überprüfen. Danach wird die Threadsicherheit mit PassTickets verwaltet.
PassTickets sind vom System generierte Kennwörter mit einer Lebensdauer von ca. 10 Minuten. Die generierten PassTickets basieren auf einem geheimen Schlüssel. Dieser Schlüssel ist eine 64-Bit-Zahl (16 Hexadezimalzeichen). Ersetzen Sie in den folgenden RACF-Beispielbefehlen den Platzhalter key16 durch eine vom Benutzer angegebene Hexadezimalzeichenfolge mit 16 Zeichen (0-9 und A-F).
RDEFINE PTKTDATA FEKAPPL UACC(NONE) SSIGNON(KEYMASKED(key16)) APPLDATA('NO REPLAY PROTECTION - DO NOT CHANGE') DATA('RATIONAL DEVELOPER FOR SYSTEM Z')
RDEFINE PTKTDATA IRRPTAUTH.FEKAPPL.* UACC(NONE) DATA('RATIONAL DEVELOPER FOR SYSTEM Z')
PERMIT IRRPTAUTH.FEKAPPL.* CLASS(PTKTDATA) ACCESS(UPDATE) ID(STCRSE)
SETROPTS RACLIST(PTKTDATA) REFRESH
RSE unterstützt die Verwendung von anderen Anwendungs-IDs als FEKAPPL. Entfernen Sie in rsed.envvars das Kommentarzeichen vor der Option "APPLID=FEKAPPL" und passen Sie diese an, um die Option zu aktivieren. Lesen Sie hierzu die Informationen unter Zusätzliche Java-Startparameter mit _RSE_JAVAOPTS definieren. Die Klassendefinition PTKTDATA muss mit der eigentlichen, von RSE verwendeten Anwendungs-ID übereinstimmen.
Sie sollten OMVSAPPL nicht als Anwendungs-ID verwenden, da diese ID den geheimen Schlüssel zu den meisten z/OS UNIX-Anwendungen entschlüsselt. Sie sollten ebenso nicht die standardmäßige MVS-Anwendungs-ID (MVS gefolgt von der SMF-ID des Systems) verwenden, da diese ID den geheimen Schlüssel zu den meisten MVS-Anwendungen (einschließlich Benutzer-Batch-Jobs) entschlüsselt.
Achtung: Die Clientverbindungsanforderung schlägt fehl, wenn PassTickets nicht richtig konfiguriert sind. |
Server mit der Berechtigung für BPX.SERVER müssen in einer sauberen, programmgesteuerten Umgebung ausgeführt werden. Dies 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).
Der RSE-Server verwendet die gemeinsam genutzte Java-Bibliothek von RACF (/usr/lib/libIRRRacf.so).
$ ls -Eog /usr/lib/libIRRRacf.so -rwxr-xr-x aps- 2 69632 Oct 5 2007 /usr/lib/libIRRRacf.so
Verwenden Sie die folgenden Beispielbefehle, um die Ergebnisse Ihrer Anpassungen in Bezug auf die Sicherheit anzuzeigen.
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.
Dieses Kapitel enthält die folgenden Abschnitte:
Abb. 41 zeigt eine allgemeine Übersicht des Layouts von Developer for System z auf Ihrem Hostsystem.
Die Beschreibung im vorherigen Abschnitt und in der Liste verdeutlichen die zentrale Rolle von RSE. Mit ein paar wenigen Ausnahmen läuft jede Clientkommunikation über RSE ab. Dies ermöglicht eine sicherheitsbezogene Netzkonfiguration, da nur eine eingeschränkte Menge an Ports für die Kommunikation zwischen Client und Host verwendet wird.
RSE besteht aus einem Dämonadressbereich, der Thread-Pooling und Adressräume steuert, um die Verbindungen und die Arbeitslast der Clients zu verwalten. Der Dämon wird als Sammelpunkt für Verbindungs- und Verwaltungszwecke eingesetzt, während die Thread-Pools die Clientarbeitslast verarbeiten. Auf Basis der in der Konfigurationsdatei rsed.envvars definierten Werte und der Summe aller Clientverbindungen können mehrere Adressräume von Thread-Pools durch den Dämon gestartet werden.
Abb. 42 zeigt eine grundlegende Sicht auf die Ressourcennutzung (Prozesse und Speicher) von RSE.
RSE ist eine Java-Anwendung, das heißt, sie ist in der z/OS UNIX-Umgebung aktiv. Dies ermöglicht eine einfache Portierung auf verschiedene Hostplattformen und direkte Kommunikation mit dem Client von Developer for System z, der ebenfalls eine Java-Anwendung ist (auf dem Eclipse-Framework basierend). Deshalb ist grundlegendes Wissen zur Arbeitsweise von z/OS UNIX und Java sehr hilfreich, um Developer for System z zu verstehen.
In z/OS UNIX wird ein Programm in einem Prozess ausgeführt, der mithilfe einer Prozess-ID (PID) identifiziert wird. Da jedes Programm in seinem eigenen Prozess aktiv ist, wird beim Aufrufen eines anderen Programms ein neuer Prozess erstellt. Auf den Prozess, der für das Starten eines anderen Prozesses verantwortlich ist, wird mithilfe einer übergeordneten Prozess-ID (Parent PID, PPID) verwiesen. Der neue Prozess wird als untergeordneter Prozess bezeichnet. Der untergeordnete Prozess kann in demselben Adressraum ausgeführt oder in einem neuen Adressraum gestartet (erstellt) werden. Ein neuer Prozess, der in demselben Adressraum ausgeführt wird, kann mit der Ausführung eines Befehls in TSO verglichen werden. Der in einem neuen Adressraum gestartete Prozess ähnelt dem Übergeben eines Batch-Jobs.
Beachten Sie, dass ein Prozess ein Einzelthread- oder ein Multithreadprozess sein kann. In einer Multithreadanwendung (wie RSE) konkurrieren die verschiedenen Threads um die Netzressourcen, als wären sie separate Adressräume (mit weniger Aufwand).
Wenn diese Prozessinformationen dem RSE-Beispiel in Abb. 42 zugeordnet werden, ergibt sich der folgende Flow:
Java-Anwendungen, wie RSE, ordnen Speicher nicht direkt zu, sondern mithilfe von Java-Speicherverwaltungsservices. Diese Services umfassen Funktionen wie das Zuordnen und Freigeben von Speicher sowie eine Garbage-Collection und werden innerhalb der Grenzwerte des Java-Heapspeichers ausgeführt. Die minimale und maximale Größe des Heapspeichers wird während des Systemstarts von Java (implizit oder explizit) definiert.
Um eine optimale Nutzung der verfügbaren Adressraumgröße zu erreichen, sollte die Größe des Heapspeichers umfangreich sein, um z/OS ausreichend Platz für die Speicherung einer variablen Menge von Systemsteuerungsblöcken (abhängig von der Anzahl aktiver Threads) zu lassen.
Abb. 43 zeigt eine Basisübersicht über die Eigner der Sicherheitsberechtigungsnachweise, die für verschiedene Tasks in Developer for System z verwendet werden.
Das Eigentumsrecht an einer Task kann in zwei Abschnitte unterteilt werden. Gestartete Tasks gehören der Benutzer-ID, die der gestarteten Task in Ihrer Sicherheitssoftware zugewiesen wird. Alle anderen Tasks, mit Ausnahme der RSE-Thread-Pools (RSEDx), gehören der Client-Benutzer-ID.
Abb. 43 zeigt gestartete Tasks in Developer for System z (LOCKD, JMON und RSED) sowie gestartete Beispieltasks und Beispielsystemservices, mit denen Developer for System z kommuniziert. Application Deployment Manager (ADM) ist innerhalb einer CICS-Region aktiv. FMNCAS ist die gestartete Task von File Manager. Das 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. File Manager startet beispielsweise einen neuen Adressraum für jede Datei (oder jedes Member), die (das) es für Developer for System z verarbeitet. 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 Abb. 43 aufgeführten Adressräume bleiben für einen längen Zeitraum im System sichtbar. z/OS UNIX wurde jedoch so entwickelt, dass es auch kurz andauernde, temporäre Adressräume gibt.
Abb. 44 zeigt eine schematische Übersicht des Verbindungsaufbaus eines Clients mit einem Host mithilfe von Developer for System z. Es wird außerdem eine kurze Erklärung zur Verwendung von PassTickets bereitgestellt.
Die obige Beschreibung zeigt das threadorientierte Design von RSE. Anstelle des Startens eines Adressraums für jeden Benutzer nutzen mehrere Benutzer einen Adressraum mit Einzel-Thread-Pool. Innerhalb des Thread-Pools ist jeder Miner (benutzerspezifischer Service) in seinem eigenen Thread aktiv, dem der Sicherheitskontext des Benutzers zugeordnet ist, um eine sichere Konfiguration zu gewährleisten. Das Design ist für eine große Anzahl von Benutzern mit eingeschränkter Ressourcennutzung bestimmt, deren Clients jedoch jeweils mehrere Threads verwenden (abhängig von den ausgeführten Tasks sind es 16 oder mehr).
Aus der Netzperspektive arbeitet Developer for System z ähnlich wie ein FTP im passiven Modus. Der Client stellt eine Verbindung mit einem Sammelpunkt (RSE-Dämon) her, trennt die Verbindung anschließend und stellt erneut eine Verbindung mit einer vom Sammelpunkt angegebenen Portnummer her. Die folgende Logik steuert die Auswahl des Ports, der für die zweite Verbindung verwendet wird:
Die Verwendung von PassTickets für alle z/OS-Services, die eine Authentifizierung erfordern, ermöglicht Developer for System z das beliebige Aufrufen dieser Services, ohne ein Kennwort speichern oder den Benutzer fortwährend danach fragen zu müssen. Die Verwendung von PassTickets für alle z/OS-Services macht außerdem ein alternatives Authentifizierungsverfahren während der Anmeldung möglich, beispielsweise durch Kennwörter für einmalige Anmeldungen und X.509-Zertifikate.
Abb. 45 zeigt eine schematische Übersicht darüber, wie der Sperrdämon festlegt, welcher Developer for System z-Client eine Dateisperre besitzt.
Innerhalb der Einzelserverkonfiguration von Developer for System z, bei der mehrere Benutzer einem Adressraum mit Einzel-Thread-Pool zugeordnet werden, verliert z/OS die Möglichkeit, zu verfolgen, wer die Sperre einer Datei oder eines Members besitzt. Systembefehle stoppen auf der Adressraumebene, die dem RSE-Thread-Pool entspricht.
Um dieses Problem zu umgehen, stellt Developer for System z den Sperrdämon zur Verfügung. Der Sperrdämon verfolgt alle Sperrungen für Dateien oder Member durch RSE-Benutzer sowie alle Sperrungen durch andere Produkte, beispielsweise ISPF.
Der RSE-Server registriert einen neu verbundenen Benutzer mit dem Sperrdämon. Die Registrierungsinformationen enthalten die Adressraumkennung (ASID des Thread-Pools), die benutzerspezifische ID des Tasksteuerblocks (TCB) und die Benutzer-ID.
Beachten Sie, dass die Registrierung nur während des Verbindungsaufbaus erfolgt, das heißt, dass keine RSE-Benutzer registriert werden, die bereits vor dem Start (oder Neustart) des Sperrdämons aktiv waren.
Wenn der Sperrdämon die Anfrage einer Datei empfängt (entweder mithilfe eines Abfragenoperatorbefehls oder vom Client über den RSE-Server), durchsucht der Dämon die GRS-Warteschlangen (Global Resource Serialization) des Systems. Wenn die ASID und der TCB mit der entsprechenden Kombination des registrierten Benutzers übereinstimmen, wird die Benutzer-ID als Sperreneigentümer zurückgegeben. Ist dies nicht der Fall, wird der Jobname bzw. die Benutzer-ID, der/die mit der ASID verknüpft ist, als Sperreneigentümer zurückgegeben.
Wenn die Registrierung fehlschlägt, wird eine Konsolnachricht (FEK513W) mit den Registrierungsinformationen angezeigt. Dies gibt einem Operator die Möglichkeit, die Werte mit der Ausgabe eines DISPLAY GRS,RES=(*,dataset*)-Operatorbefehls zu vergleichen, um den Sperreneigentümer zu finden.
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 Sperren ist, die Sperren mithilfe des RSE-Operatorbefehls modify cancel löschen, wie in Bedienerbefehle beschrieben. Während dieses Prozesses werden alle aktiven Sperren von Dateien aufgehoben, die mit diesem Benutzer verknüpft sind.
Abb. 46 zeigt eine Übersicht über die von Developer for System z verwendeten z/OS UNIX-Verzeichnisse. Die folgende Liste enthält Informationen zu jedem von Developer for System z verwendeten Verzeichnis, darüber, wie die Position geändert werden kann und wer die darin enthaltenen Daten verwaltet.
Die in einigen Verzeichnissen (wie in /var/rdz/projects/) enthaltenen Daten werden von Benutzern ohne Administratorrechte, beispielsweise Projektmanagern, verwaltet. Diese Benutzer haben möglicherweise kaum Aktualisierungsberechtigungen in z/OS UNIX. Wenn die Dateien von nur einer Benutzer-ID verwaltet werden, können dem Benutzer Aktualisierungsberechtigungen zugewiesen werden, indem die Benutzer-ID als Eigentümer des Verzeichnisses und der darin enthaltenen Daten festgelegt wird.
chown -R IBMUSER /var/rdz/projects/
Wenn mehrere Benutzer-IDs Aktualisierungsberechtigungen für das Verzeichnis benötigen, können Sie Gruppenberechtigungsbits verwenden.
ADDGROUP RDZPROJ OMVS(GID(1200)) CONNECT IBMUSER GROUP(RDZPROJ) ALTUSER IBMUSER DFLTGRP(RDZPROJ)
chgrp -R IBMUSER /var/rdz/projects/
chmod -R 775 /var/rdz/projects/
Im Gegensatz zu herkömmlichen z/OS-Anwendungen ist Developer for System z keine einzelne Anwendung, die von Workload Manager (WLM) auf einfache Weise erkannt wird. Developer for System z umfasst mehrere interagierende Komponenten, damit der Client auf die Host-Services und -daten zugreifen kann. Wie in Wissenswertes zu Developer for System z beschrieben, sind einige dieser Services in verschiedenen Adressräumen aktiv und werden somit verschiedenen WLM-Klassifikationen zugeordnet.
Dieses Kapitel enthält die folgenden Abschnitte:
Abb. 47 zeigt eine Basisübersicht über die Subsysteme, über die die Informationen zu den Verarbeitungsprozessen von Developer for System z an WLM weitergegeben werden.
Application Deployment Manager (ADM) ist innerhalb einer CICS-Region aktiv und befolgt deshalb die CICS-Klassifikationsregeln in WLM.
Der RSE-Dämon (RSED), der Sperrdämon (LOCKD) und JES Job Monitor (JMON) sind gestartete Tasks in Developer for System z (oder lang andauernde Batch-Jobs) mit individuellen Adressräumen.
Wie in RSE als Java-Anwendung dokumentiert, startet der RSE-Dämon für jeden RSE-Thread-Pool-Server (der eine variable Anzahl von Clients unterstützt) einen untergeordneten Prozess. Jeder Thread-Pool ist (mithilfe eines z/OS UNIX-Initiators, BPXAS) in einem separaten Adressraum aktiv. Da es sich hierbei um gestartete Prozesse handelt, werden diese nach den WLM-OMVS-Klassifikationsregeln und nicht nach den Klassifikationsregeln für gestartete Tasks klassifiziert.
Abhängig von den Aktionen der Benutzer können die Clients, die in einem Thread-Pool aktiv sind, eine Vielzahl anderer Adressräume erstellen. Abhängig von der Konfiguration von Developer for System z, können einige Verarbeitungsprozesse, wie TSO Commands Service (TSO cmd) oder CARMA, in anderen Subsystemen ausgeführt werden.
Die in Abb. 47 aufgeführten Adressräume bleiben für einen längen Zeitraum im System sichtbar. z/OS UNIX wurde jedoch so entwickelt, dass es auch kurz andauernde, temporäre Adressräume gibt. Diese temporären Adressräume sind im OMVS-Subsystem aktiv.
Während die RSE-Thread-Pools dieselbe Benutzer-ID und einen ähnlichen Jobnamen wie der RSE-Dämon verwenden, gehören alle von einem Thread-Pool gestarteten Adressräume der Client-Benutzer-ID, die die Aktion anfordert. Die Client-Benutzer-ID wird außerdem als Teil des Jobnamens für alle vom Thread-Pool gestarteten OMVS-basierten Adressräume verwendet.
Weitere Adressräume werden von anderen Services erstellt, die Developer for System z verwendet, wie File Manager (FMNCAS) oder z/OS UNIX-REXEC (USS-Build).
WLM verwendet Klassifikationsregeln, um im System eingehende Arbeit einer Serviceklasse zuzuordnen. Diese Klassifikation basiert auf Qualifikationsmerkmalen für Arbeit. Das erste (verbindliche) Merkmal ist der Subsystemtyp, der die Verarbeitungsanforderung empfängt. In Tabelle 29 werden die Subsystemtypen aufgeführt, die Verarbeitungsanforderungen von Developer for System z empfangen können.
Subsystemtyp | Beschreibung der Arbeit |
---|---|
ASCH | Die Verarbeitungsanforderungen umfassen alle APPC-Transaktionsprogramme, die von dem von IBM gelieferten APPC/MVS-Transaktionsscheduler (ASCH) geplant werden. |
CICS | Die Verarbeitungsanforderungen umfassen alle Transaktionen, die von CICS verarbeitet werden. |
JES | Die Verarbeitungsanforderungen umfassen alle Jobs, die von JES2 oder JES3 initialisiert werden. |
OMVS | Die Verarbeitungsanforderungen umfassen Arbeit, die in verzweigten untergeordneten Adressräumen von z/OS UNIX System Services verarbeitet wird. |
STC | Die Verarbeitungsanforderungen umfassen Arbeit, die von den Befehlen 'START' und 'MOUNT' initialisiert wird. STC umfasst außerdem Adressräume der Systemkomponente. |
Tabelle 30In Tabelle 2 werden zusätzliche Merkmale aufgeführt, die für die Zuordnung von Verarbeitungsprozessen zu einer bestimmten Serviceklasse verwendet werden können. Weitere Details zu den aufgelisteten Merkmalen enthält MVS Planning: Workload Management (IBM Form SA22-7602).
ASCH | CICS | JES | OMVS | STC | ||
---|---|---|---|---|---|---|
AI | Accountinformationen | x | x | x | x | |
LU | LU-Name (*) | x | ||||
PF | Ausführung (*) | x | x | |||
PRI | Priorität | x | ||||
SE | Name der Terminierungsumgebung | x | ||||
SSC | Objektgruppenname des Subsystems | x | ||||
SI | Subsysteminstanz (*) | x | x | |||
SPM | Subsystemparameter | x | ||||
PX | Sysplex-Name | x | x | x | x | x |
SY | Systemname (*) | x | x | x | ||
TC | Transaktions-/Jobklasse (*) | x | x | |||
TN | Transaktions-/Jobname (*) | x | x | x | x | x |
UI | Benutzer-ID (*) | x | x | x | x | x |
Wie unter Klassifikation für Verarbeitungsprozesse dokumentiert, erstellt Developer for System z unterschiedliche Typen von Verarbeitungsprozessen auf Ihrem System. Diese verschiedenen Tasks kommunizieren miteinander. Dafür ist die eigentliche Antwortzeit wichtig, um Zeitüberschreitungsprobleme bezüglich der Verbindungen zwischen den Tasks zu vermeiden. Deshalb sollten Tasks in Developer for System z in leistungsfähige Serviceklassen oder in Serviceklassen mit mittlerer Leistung mit hoher Priorität eingeordnet werden.
Es wird daher eine Überarbeitung und gegebenenfalls eine Aktualisierung Ihrer aktuellen WLM-Ziele empfohlen. Dies gilt insbesondere für herkömmliche MVS-Unternehmen, für die zeitkritische OMVS-Verarbeitungsprozesse neu sind.
In Tabelle 31 werden die Adressräume aufgelistet, die von Developer for System z verwendet werden. z/OS UNIX ersetzt den Wert "x" in der Spalte "Taskname" durch eine zufällige einstellige Zahl.
Beschreibung | Taskname | Verarbeitungsprozess |
---|---|---|
JES Job Monitor | JMON | STC |
Sperrdämon | LOCKD | STC |
RSE-Dämon | RSED | STC |
RSE-Thread-Pool | RSEDx | OMVS |
ISPF Client Gateway (TSO Commands Service und SCLMDT) | <Benutzer-ID>x | OMVS |
TSO Commands Service (APPC) | FEKFRSRV | ASCH |
CARMA (batch) | CRA<port> | JES |
CARMA (crastart) | <Benutzer-ID>x | OMVS |
CARMA (ISPF-Client-Gateway) | <Benutzer-ID> und <Benutzer-ID>x | OMVS |
MVS-Build (Batch-Job) | * | JES |
z/OS UNIX-Build (Shellbefehle) | <Benutzer-ID>x | OMVS |
z/OS UNIX-Shell | <Benutzer-ID> | OMVS |
File Manager-Task | <Benutzer-ID>x | OMVS |
Application Deployment Manager | CICSTS | CICS |
Die folgenden allgemeinen Hinweise zu WLM unterstützen Sie beim Definieren der Zieldefinitionen für Developer for System z:
Bei der Verwendung von Antwortzeitzielen:
Bei der Verwendung von Geschwindigkeitszielen:
Alle gestarteten Tasks von Developer for System z (RSE-Dämon, Sperrdämon und JES Job Monitor) warten Echtzeit-Clientanforderungen.
Beschreibung | Taskname | Verarbeitungsprozess |
---|---|---|
JES Job Monitor | JMON | STC |
Sperrdämon | LOCKD | STC |
RSE-Dämon | RSED | STC |
JES Job Monitor stellt alle Services mit Bezug zum JES bereit. Dazu gehören das Übergeben von Jobs, das Durchsuchen von Spooldateien und das Ausführen von JES-Bedienerbefehlen. 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.
Der Sperrdämon fragt die GRS-Serialisierungstabellen auf Client- und Bedieneranforderungen hin ab und vergleicht das Ergebnis mit bekannten Benutzern in Developer for System z. Sie sollten ein leistungsfähiges Geschwindigkeitsziel für einen Zeitraum angeben, da die Task WLM keine einzelnen Transaktionen zurückmeldet. Es wird eine minimale Ressourcennutzung erwartet.
Der RSE-Dämon führt die Clientanmeldung und -authentifizierung aus und verwaltet die verschiedenen RSE-Thread-Pools. Sie sollten ein leistungsfähiges Geschwindigkeitsziel für einen Zeitraum angeben, da die Task WLM keine einzelnen Transaktionen zurückmeldet. Es wird eine mäßige Ressourcennutzung mit einem Spitzenwert zu Beginn des Arbeitstages erwartet.
Die OMVS-Verarbeitungsprozesse können in zwei Gruppen unterteilt werden: RSE-Thread-Pools und alle anderen Verarbeitungsprozesse. Dies hat zur Ursache, dass alle Verarbeitungsprozesse, außer RSE-Thread-Pools, die Client-Benutzer-ID als Grundlage für den Adressraumnamen verwenden. (z/OS UNIX ersetzt den Wert "x" in der Spalte "Taskname" durch eine zufällige einstellige Zahl.)
Beschreibung | Taskname | Verarbeitungsprozess |
---|---|---|
RSE-Thread-Pool | RSEDx | OMVS |
ISPF Client Gateway (TSO Commands Service und SCLMDT) | <Benutzer-ID>x | OMVS |
CARMA (crastart) | <Benutzer-ID>x | OMVS |
CARMA (ISPF-Client-Gateway) | <Benutzer-ID> und <Benutzer-ID>x | OMVS |
z/OS UNIX-Build (Shellbefehle) | <Benutzer-ID>x | OMVS |
z/OS UNIX-Shell | <Benutzer-ID> | OMVS |
File Manager-Task | <Benutzer-ID>x | OMVS |
Ein RSE-Thread-Pool ist das Herzstück von Developer for System z. Beinahe alle Daten fließen durch diesen Pool und die Miners (benutzerspezifische Threads) innerhalb des Thread-Pools steuern die Aktionen der meisten anderen Tasks in Bezug auf Developer for System z. Sie sollten ein leistungsfähiges Geschwindigkeitsziel für einen Zeitraum angeben, da die Task WLM keine einzelnen Transaktionen zurückmeldet. Die Ressourcennutzung hängt im großen Maße von den Benutzeraktionen ab und kann deshalb schwanken. Es ist jedoch zu erwarten, dass sie erheblich ist.
Die restlichen Verarbeitungsprozesse werden alle aufgrund einer allgemeinen Namenskonvention für Adressräume derselben Serviceklasse zugeordnet. Für diese Serviceklasse sollten Sie ein Ziel für mehrere Zeiträume angeben. Für die ersten Zeiträume sollten Sie leistungsfähige Perzentilantwortzeitziele und für den letzten Zeitraum ein Geschwindigkeitsziel mit mittlerer Leistung angeben. Einige Verarbeitungsprozesse, wie das ISPF-Client-Gateway, melden WLM einzelne Transaktionen zurück.
Das ISPF-Client-Gateway ist ein ISPF-Service, der von Developer for System z aufgerufen wird, um nicht interaktive TSO- und ISPF-Befehle auszuführen. Dies schließt sowohl vom Client ausgegebene, explizite Befehle als auch von Developer for System z ausgegebene, implizite Befehle ein, z. B. das Abrufen einer PDS-Memberliste. Die Ressourcennutzung hängt im großen Maße von den Benutzeraktionen ab und kann deshalb schwanken. Es ist jedoch zu erwarten, dass sie minimal ist.
CARMA ist ein optionaler Developer for System z-Server, der für die Interaktion mit hostbasierten Software Configuration Managers (SCMs), wie CA Endevor® SCM, verwendet wird. Developer for System z lässt verschiedene Startmethoden für einen CARMA-Server zu. Einige davon werden als OMVS-Verarbeitungsprozess gehandhabt. Die Ressourcennutzung hängt im großen Maße von den Benutzeraktionen ab und kann deshalb schwanken. Es ist jedoch zu erwarten, dass sie minimal ist.
Wenn ein Client einen Build für ein z/OS UNIX-Projekt initialisiert, startet die z/OS UNIX-REXEC (oder SSH) eine Task, die zur Ausführung des Builds eine Reihe von z/OS UNIX-Shellbefehlen ausführt. Die Ressourcennutzung hängt im großen Maße von den Benutzeraktionen ab und kann deshalb schwanken. Es ist jedoch zu erwarten, dass sie mäßig bis erheblich ist (abhängig von der Größe des Projekts).
Dieser Verarbeitsprozess verarbeitet vom Client ausgegebene z/OS UNIX-Shellbefehle. 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.
Obwohl sie keine Adressräume von Developer for System z sind, sind die gestarteten untergeordneten Prozesse von File Manager hier aufgelistet. Das hat zur Ursache, dass sie auf Anforderung des Developer for System z-Clients gestartet werden können und dieselbe Namenskonvention wie Developer for System z-Tasks verwenden. Diese File Manager-Tasks verarbeiten nicht triviale MVS-Dateiaktionen, wie das formatierte Bearbeiten einer VSAM-Datei. 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.
JES-verwaltete Batchprozesse werden von Developer for System z auf verschiedene Weisen verwendet. Die bekannteste Nutzung ist für MVS-Builds, für die ein Job übergeben und überwacht wird, um sein Ende zu bestimmen. Developer for System z kann jedoch auch einen CARMA-Server mit Batchübergabe starten und mit ihm über TCP/IP kommunizieren.
Beschreibung | Taskname | Verarbeitungsprozess |
---|---|---|
CARMA (batch) | CRA<port> | JES |
MVS-Build (Batch-Job) | * | JES |
CARMA ist ein optionaler Developer for System z-Server, der für die Interaktion mit hostbasierten Software Configuration Managers (SCMs), wie CA Endevor® SCM, verwendet wird. Developer for System z lässt verschiedene Startmethoden für einen CARMA-Server zu. Einige davon werden als JES-Verarbeitungsprozess gehandhabt. Sie sollten ein leistungsfähiges Geschwindigkeitsziel für einen Zeitraum angeben, da die Task WLM keine einzelnen Transaktionen zurückmeldet. Die Ressourcennutzung hängt im großen Maße von den Benutzeraktionen ab und kann deshalb schwanken. Es ist jedoch zu erwarten, dass sie minimal ist.
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.
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.
Beschreibung | Taskname | Verarbeitungsprozess |
---|---|---|
TSO Commands Service (APPC) | FEKFRSRV | ASCH |
TSO Commands Service kann von Developer for System z als APPC-Transaktion gestartet werden, um nicht interaktive TSO- und ISPF-Befehle auszuführen. Dies schließt sowohl vom Client ausgegebene, explizite Befehle als auch von Developer for System z ausgegebene, implizite Befehle ein, z. B. das Abrufen einer PDS-Memberliste. Für diese Serviceklasse sollten Sie ein Ziel für mehrere Zeiträume angeben. Für die ersten Zeiträume sollten Sie leistungsfähige Perzentilantwortzeitziele angeben. Für den letzten Zeitraum sollten Sie ein Geschwindigkeitsziel mit mittlerer Leistung angeben. Die Ressourcennutzung hängt im großen Maße von den Benutzeraktionen ab und kann deshalb schwanken. Es ist jedoch zu erwarten, dass sie minimal ist.
Application Deployment Manager ist ein optionaler Developer for System z-Server, der innerhalb einer CICS Transaction Server-Region aktiv ist.
Beschreibung | Taskname | Verarbeitungsprozess |
---|---|---|
Application Deployment Manager | CICSTS | CICS |
Der optionale Application Deployment Manager-Server, der innerhalb einer CICSTS-Region aktiv ist, ermöglicht Ihnen das sichere Auslagern ausgewählter CICSTS-Verwaltungstasks an Entwickler. Die Ressourcennutzung hängt im großen Maße von den Benutzeraktionen ab und kann deshalb schwanken. Es ist jedoch zu erwarten, dass sie minimal ist. Der zu verwendende Serviceklassentyp hängt von den anderen in dieser CICS-Region aktiven Transaktionen ab und ist deshalb nicht im Detail beschrieben.
WLM unterstützt mehrere Verwaltungstypen, die Sie für CICS verwenden können:
Das Ziel ist auf eine Serviceklasse festgelegt, die die CICS-Adressräume verwaltet. Für diese Serviceklasse können Sie nur ein Ziel für die Ausführungsgeschwindigkeit festlegen. WLM verwendet für die Adressräume die JES- oder STC-Klassifikationsregeln. Es verwendet jedoch nicht die CICS-Subsystemklassifikationsregeln für Transaktionen.
Ein Antwortzeitziel kann in einer Serviceklasse festgelegt werden, die einer einzelnen Transaktion oder einer Gruppe von Transaktionen zugewiesen ist. WLM verwendet für die Adressräume die JES- oder STC-Klassifikationsregeln und die CICS-Subsystemklassifikationsregeln für Transaktionen.
Wie in Wissenswertes zu Developer for System z erklärt wird, ist RSE (Remote Systems Explorer) der zentrale Bestandteil von Developer for System z. RSE besteht aus einem Dämonadressbereich, der Thread-Pooling und Adressräume steuert, um die Verbindungen und die Arbeitslast der Clients zu verwalten. Der Dämon wird als Sammelpunkt für Verbindungs- und Verwaltungszwecke eingesetzt, während die Thread-Pools die Clientarbeitslast verarbeiten.
Dadurch wird RSE das Hauptziel für die Optimierung der Installation von Developer for System z. Wenn Sie allerdings Hunderte von Benutzern verwalten, die jeweils mindestens 16 Threads, eine bestimmte Speichermenge und mindestens einen Adressraum verwenden, müssen Developer for System z und z/OS richtig konfiguriert sein.
Dieses Kapitel enthält die folgenden Abschnitte:
Verwenden Sie die Informationen in diesem Abschnitt, um die normale und maximale Ressourcennutzung von Developer for System z zu berechnen und Ihre Systemkonfiguration entsprechend planen zu können.
Wenn Sie die in diesem Abschnitt vorhandenen Zahlen und Formeln verwenden, um die Grenzwerte für das System zu definieren, achten Sie darauf, dass Sie mit präzisen Berechnungen arbeiten. Planen Sie beim Festlegen der Begrenzungen für das System ausreichend Spielraum ein, um die Ressourcennutzung für temporäre oder andere Tasks sowie für Benutzer zu ermöglichen, die sich mehrfach gleichzeitig am Host anmelden (beispielsweise über RSE und TN3270).
Die folgenden Tabellen geben einen Überblick über die Anzahl der Adressräume, Prozesse und Threads, die von Developer for System z verwendet werden. Weitere Details zu den hier dargestellten Zahlen finden Sie in den darauffolgenden Abschnitten:
Tabelle 37 gibt einen allgemeinen Überblick über Schlüsselressourcen, die von gestarteten Tasks in Developer for System z verwendet werden. Diese Ressourcen werden nur einmal angelegt. Sie werden von allen Developer for System z-Clients gemeinsam genutzt.
Gestartete Task | Adressräume | Prozesse | Threads |
---|---|---|---|
JMON | 1 | 1 | 3 |
LOCKD | 1 | 3 | 10 |
RSED | 1 | 3 | 11 |
RSEDx | (a) | 2 | 10 |
Tabelle 38 gibt einen allgemeinen Überblick über Schlüsselressourcen, die von vorausgesetzten Softwareprogrammen verwendet werden. Diese Ressourcen werden für jeden Developer for System z-Client angelegt, der die entsprechende Funktion aufruft.
Vorausgesetzte Software | Adressräume | Prozesse | Threads |
---|---|---|---|
ISPF Client Gateway | 1 | 2 | 4 |
APPC-Administrator | 1 | 1 | 2 |
File Manager | 1 | 1 | 2 |
Tabelle 39 gibt einen allgemeinen Überblick über Schlüsselressourcen, die von jedem Developer for System z-Client bei der Ausführung der angegeben Funktion verwendet werden. Werte, die keine numerischen Werte sind (beispielsweise ISPF), verweisen auf den entsprechenden Wert in Tabelle 38.
Benutzeraktion
|
Adressräume
Benutzer-ID |
Prozesse
Benutzer-ID |
Threads Benutzer-ID RSEDx JMON |
||
---|---|---|---|---|---|
Anmelden | - | - | - | 16 | 1 |
Zeitgeber für Inaktivitätszeitlimit | - | - | - | 1 | - |
Komprimierung für PDS(E) aufheben | ISPF | ISPF | ISPF | - | - |
Datei öffnen | ISPF | ISPF | ISPF | - | - |
TSO-Befehl | ISPF | ISPF | ISPF | - | - |
z/OS UNIX-Shell | 1 | 1 | 1 | 6 | - |
MVS-Build | 1 | - | - | - | - |
z/OS UNIX-Build | 3 | 3 | 3 | - | - |
CARMA (batch) | 1 | 1 | 2 | 1 | - |
CARMA (crastart) | 1 | 1 | 2 | 4 | - |
CARMA (ispf) | 4 | 4 | 7 | 5 | - |
SCLMDT | ISPF | ISPF | ISPF | - | - |
File Manager-Integration | ISPF + FM | ISPF + FM | ISPF + FM | - | - |
Fault Analyzer-Integration | - | - | - | - | - |
In Tabelle 40 werden die Adressräume aufgelistet, die Developer for System z verwendet, wobei "u" in der Spalte "Anzahl" angibt, dass der Betrag mit der Anzahl der gleichzeitig aktiven Benutzer dieser Funktion multipliziert werden muss. z/OS UNIX ersetzt den Wert "x" in der Spalte "Taskname" durch eine zufällige einstellige Zahl.
Anzahl | Beschreibung | Taskname | Gemeinsame Nutzung | Endet nach |
---|---|---|---|---|
1 | JES Job Monitor | JMON | Ja | Nie |
1 | Sperrdämon | LOCKD | Ja | Nie |
1 | RSE-Dämon | RSED | Ja | Nie |
(a) | RSE-Thread-Pool | RSEDx | Ja | Nie |
1u | ISPF Client Gateway (TSO Commands Service und SCLMDT) | <Benutzer-ID>x | Nein | 15 Minuten oder Abmeldung des Benutzers |
1u | TSO Commands Service (APPC) | FEKFRSRV | Nein | 60 Minuten oder Abmeldung des Benutzers |
1u | CARMA (batch) | CRA<port> | Nein | 7 Minuten oder Abmeldung des Benutzers |
1u | CARMA (crastart) | <Benutzer-ID>x | Nein | 7 Minuten oder Abmeldung des Benutzers |
4u | CARMA (ispf) | (1)<Benutzer-ID> oder (3)<Benutzer-ID>x | Nein | 7 Minuten oder Abmeldung des Benutzers |
(b) | Simultane Verwendung von ISPF Client Gateway von 1 Benutzer | <Benutzer-ID>x | Nein | Fertigstellung der Task |
1u | MVS-Build (Batch-Job) | * | Nein | Fertigstellung der Task |
3u | z/OS UNIX-Build (Shellbefehle) | <Benutzer-ID>x | Nein | Fertigstellung der Task |
1u | z/OS UNIX-Shell | <Benutzer-ID> | Nein | Abmeldung des Benutzers |
(c) | File Manager | <Benutzer-ID>x | Nein | Fertigstellung der Task |
Verwenden Sie die Formel in Abb. 48, um die maximale Anzahl der Adressräume zu berechnen, die Developer for System z verwendet.
Dabei
X | SCLMDT | TSO über Client-Gateway | TSO über APPC |
---|---|---|---|
1 | Nein | Nein | Ja |
1 | Nein | Ja | Nein |
1 | Ja | Ja | Nein |
Y | |
---|---|
0 | Kein CARMA |
1 | CARMA (batch) |
1 | CARMA (crastart) |
4 | CARMA (ispf) |
Verwenden Sie die Formel in Abb. 49, um die maximale Anzahl der Adressräume zu berechnen, die ein Developer for System z-Client verwendet (temporäre Adressräume (nicht dokumentiert) werden nicht berücksichtigt).
Dabei
Die Definitionen in Tabelle 41 können die eigentliche Anzahl von Adressräumen begrenzen.
Position | Begrenzung | Beeinträchtigte Ressourcen |
---|---|---|
rsed.envvars | maximum.threadpool.process | Begrenzt die Anzahl von RSE-Thread-Pools |
IEASYMxx | MAXUSER | Begrenzt die Anzahl von Adressräumen |
ASCHPMxx | MAX | Begrenzt die Anzahl von APPC-Initiatoren für TSO Commands Service (APPC) |
In Tabelle 42 wird die Anzahl der Prozesse angegeben, die Developer for System z verwendet, wobei "u" in der Spalte "Adressräume" angibt, dass der Betrag mit der Anzahl der gleichzeitig aktiven Benutzer dieser Funktion multipliziert werden muss.
Prozesse | Adressräume | Beschreibung | Benutzer-ID |
---|---|---|---|
1 | 1 | JES Job Monitor | STCJMON |
3 | 1 | Sperrdämon | STCLOCK |
3 | 1 | RSE-Dämon | STCRSE |
2 | (a) | RSE-Thread-Pool | STCRSE |
2 | (b) | ISPF Client Gateway (TSO Commands Service und SCLMDT) | <Benutzer-ID> |
1 | 1u | TSO Commands Service (APPC) | <Benutzer-ID> |
1 | 1u | CARMA (batch) | <Benutzer-ID> |
1 | 1u | CARMA (crastart) | <Benutzer-ID> |
1 | 1u | CARMA (ispf) | <Benutzer-ID> |
1 | 3u | z/OS UNIX-Build (Shellbefehle) | <Benutzer-ID> |
1 | 1u | z/OS UNIX-Shell | <Benutzer-ID> |
1 | (c) | File Manager | <Benutzer-ID> |
(5) | (u) | SCLM Developer Toolkit | <Benutzer-ID> |
Verwenden Sie die Formel in Abb. 50, um die maximale Anzahl der Prozesse zu berechnen, die Developer for System z verwendet.
Dabei
X | SCLMDT | TSO über Client-Gateway | TSO über APPC |
---|---|---|---|
1 | Nein | Nein | Ja |
2 | Nein | Ja | Nein |
7 | Ja | Ja | Nein |
Y | |
---|---|
0 | Kein CARMA |
1 | CARMA (batch) |
1 | CARMA (crastart) |
4 | CARMA (ispf) |
Verwenden Sie die Formel in Abb. 51, um die maximale Anzahl der Prozesse zu berechnen, die ein Developer for System z-Client verwendet (temporäre Prozesse (nicht dokumentiert) werden nicht berücksichtigt).
Dabei
Die Definitionen in Tabelle 43 können die eigentliche Anzahl von Prozessen begrenzen.
Position | Begrenzung | Beeinträchtigte Ressourcen |
---|---|---|
BPXPRMxx | MAXPROCSYS | Begrenzt die Gesamtzahl von Prozessen |
BPXPRMxx | MAXPROCUSER | Begrenzt die Anzahl von Prozessen pro z/OS UNIX-Benutzer-ID |
Hinweis:
In Tabelle 44 ist die Anzahl der Threads angegeben, die von ausgewählten Developer for System z-Funktionen verwendet wird. Dabei gibt "u" in der Spalte "Threads" an, dass der Betrag mit der Anzahl von gleichzeitigen Benutzern dieser Funktion multipliziert werden muss. Die Anzahl der Threads wird pro Prozess angegeben, da Begrenzungen auf dieser Ebene festgelegt werden.
Threads |
Benutzer-ID | Beschreibung | ||
---|---|---|---|---|
RSEDx | Aktiv | Booten | ||
- | 3 + 1u | - | STCJMON | JES Job Monitor |
- | 10 | 2 | STCLOCK | Sperrdämon |
- | 11 | 2 | STCRSE | RSE-Dämon |
10 (a) + 16u | - | 1 (a) | STCRSE | RSE-Thread-Pool |
- | 4u (b) | 1u (b) | <Benutzer-ID> | ISPF Client Gateway (TSO Commands Service und SCLMDT) |
- | 2u | - | <Benutzer-ID> | TSO Commands Service (APPC) |
1u | 2u | - | STCRSE und <Benutzer-ID> | CARMA (batch) |
4u | 2u | - | STCRSE und <Benutzer-ID> | CARMA (crastart) |
5u | 4u | 3u | STCRSE und <Benutzer-ID> | CARMA (ispf) |
- | 1u (d) | 2u | <Benutzer-ID> | z/OS UNIX-Build (Shellbefehle) |
6u | 1u | - | STCRSE und <Benutzer-ID> | z/OS UNIX-Shell |
- | 2u (c) | - | <Benutzer-ID> | File Manager |
- | (5) | - | <Benutzer-ID> | SCLM Developer Toolkit |
1u | - | - | STCRSE | Zeitgeber für Inaktivitätszeitlimit |
Verwenden Sie die Formel in Abb. 52, um die maximale Anzahl der Threads zu berechnen, die von einem RSE-Thread-Pool verwendet werden. Verwenden Sie die Formel in Abb. 53, um die maximale Anzahl der Threads zu berechnen, die JES Job Monitor verwendet.
Dabei
X | SCLMDT | TSO über Client-Gateway | TSO über APPC | Zeitlimit |
---|---|---|---|---|
0 | Nein | Nein | Ja | Nein |
0 | Nein | Ja | Nein | Nein |
0 | Ja | Ja | Nein | Nein |
1 | Nein | Nein | Ja | Ja |
1 | Nein | Ja | Nein | Ja |
1 | Ja | Ja | Nein | Ja |
Y | |
---|---|
0 | Kein CARMA |
1 | CARMA (batch) |
4 | CARMA (crastart) |
5 | CARMA (ispf) |
Die Definitionen in Tabelle 45 können die eigentliche Anzahl von Threads in einem Prozess begrenzen. Diese Option ist vor allem für die RSE-Thread-Pools wichtig.
Position | Begrenzung | Beeinträchtigte Ressourcen |
---|---|---|
BPXPRMxx | MAXTHREADS | Begrenzt die Anzahl von Threads in einem Prozess |
BPXPRMxx | MAXTHREADTASKS | Begrenzt die Anzahl von MVS-Tasks in einem Prozess |
BPXPRMxx | MAXASSIZE | Begrenzt die Größe des Adressraums und damit den verfügbaren Speicher für Thread-bezogene Steuerblöcke |
rsed.envvars | Xmx | Legt die maximale Größe des Java-Heapspeichers fest. Dieser Speicher ist reserviert und deshalb nicht mehr für Thread-bezogene Steuerblöcke verfügbar. |
rsed.envvars | maximum.clients | Begrenzt die Anzahl von Clients (und damit ihre Threads) in einem RSE-Thread-Pool |
rsed.envvars | maximum.threads | Begrenzt die Anzahl von Client-Threads in einem RSE-Thread-Pool |
FEJJCNFG | MAX_THREADS | Begrenzt die Anzahl von Threads in JES Job Monitor |
RSE ist eine Java-Anwendung, die voraussetzt, dass bei der Planung der Speicherbelegung für Developer for System z zwei Speicherzuordnungsbegrenzungen berücksichtigt werden: für die Größe des Java-Heapspeichers und für die Größe der Adressräume.
Java bietet viele Services für die einfache Durchführung von Codierungsaufgaben für Java-Anwendungen an. Einer dieser Services betrifft die Speicherverwaltung.
Die Speicherverwaltung von Java reserviert große Speicherblöcke und verwendet diese für Speicheranforderungen der Anwendung. Dieser von Java verwaltete Speicher wird als Java-Heapspeicher bezeichnet. Die periodische Garbage-Collection (Defragmentierung) gibt nicht verwendeten Speicherplatz im Heapspeicher wieder frei und reduziert die Größe des Heapspeichers.
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 64 MB.
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 Operatorbefehl 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.
Die gewünschte Adressraumgröße wird während des Systemstarts angegeben, beispielsweise mit dem Parameter "REGION" in JCL. Systemeinstellungen können jedoch die eigentliche Adressraumgröße begrenzen. Lesen Sie den Abschnitt Größe des Adressraums, um mehr über diese Begrenzungen zu erfahren.
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.
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.
Wie oben beschrieben hängt die eigentliche Speicherbelegung von Developer for System z stark von der Benutzeraktivität ab. Einige Aktionen verwenden eine feste Speichermenge (beispielsweise die Anmeldung), während andere Aktionen einen variablen Speicherbedarf haben (zum Beispiel das Auflisten von Dateien mit einem angegebenen übergeordneten Qualifikationsmerkmal).
Beachten Sie, dass RSE die aktuelle Größe des Java-Heapspeichers und des Adressraums während des Systemstarts in der Konsolnachricht 'FEK004I' anzeigt.
Durchlaufen Sie eins der folgenden Szenarien, wenn die Überwachung ergibt, dass die aktuelle Größe des Java-Heapspeichers für die aktuelle Auslastung nicht ausreicht:
Die Anzeigen in den folgenden Abbildungen zeigen einige Beispielzahlen für die Ressourcennutzung einer Standardkonfiguration von Developer for System z mit einer Änderung. Die maximale Größe des Java-Heapspeichers ist auf 10 MB gesetzt. Ein kleiner Maximalwert führt zu einer größeren prozentualen Nutzung und die Größenbegrenzung des Heapspeichers wird früher erreicht.
Max Heap Size=10MB and private AS Size=1,959MB startup BPXM023I (STCRSE) ProcessId(268 ) Memory Usage(7%) Clients(0) Jobname Cpu time Storage EXCP -------- ----------- ------- ---------- JMON 0.01 2740 72 LOCKD 1.60 28.7M 14183 RSED 4.47 32.8M 15910 RSED8 1.15 27.4M 12612 logon 1 BPXM023I (STCRSE) ProcessId(268 ) Memory Usage(13%) Clients(1) Jobname Cpu time Storage EXCP -------- ----------- ------- ---------- JMON 0.01 2864 81 LOCKD 1.64 28.8M 14259 RSED 4.55 32.8M 15980 RSED8 3.72 55.9M 24128 logon 2 BPXM023I (STCRSE) ProcessId(268 ) Memory Usage(23%) Clients(2) Jobname Cpu time Storage EXCP -------- ----------- ------- ---------- JMON 0.02 2944 86 LOCKD 1.66 28.9M 14268 RSED 4.58 32.9M 16027 RSED8 4.20 57.8M 25205 logon 3 BPXM023I (STCRSE) ProcessId(268 ) Memory Usage(37%) Clients(3) Jobname Cpu time Storage EXCP -------- ----------- ------- ---------- JMON 0.02 3020 91 LOCKD 1.67 29.0M 14277 RSED 4.60 32.9M 16076 RSED8 4.51 59.6M 26327 logon 4 BPXM023I (STCRSE) ProcessId(268 ) Memory Usage(41%) Clients(4) Jobname Cpu time Storage EXCP -------- ----------- ------- ---------- JMON 0.02 3108 96 LOCKD 1.68 29.0M 14286 RSED 4.61 32.9M 16125 RSED8 4.77 62.3M 27404
logon 5 BPXM023I (STCRSE) ProcessId(268 ) Memory Usage(41%) Clients(4) ProcessId(33554706) Memory Usage(13%) Clients(1) Jobname Cpu time Storage EXCP -------- ----------- ------- ---------- JMON 0.03 3184 101 LOCKD 1.69 29.1M 14295 RSED 4.64 32.9M 16229 RSED8 4.78 62.4M 27413 RSED9 4.60 56.6M 24065
Abb. 54 und Abb. 55 zeigen ein Szenario, in dem sich 5 Clients bei einem RSE-Dämon mit einem 10-MB-Java-Heapspeicher anmelden.
Max Heap Size=10MB and private AS Size=1,959MB startup BPXM023I (STCRSE) ProcessId(212 ) Memory Usage(7%) Clients(0) Jobname Cpu time Storage EXCP -------- ----------- ------- ---------- JMON 0.01 2736 71 LOCKD 1.73 30.5M 14179 RSED 4.35 32.9M 15117 RSED8 1.43 27.4M 12609 logon BPXM023I (STCRSE) ProcessId(212 ) Memory Usage(13%) Clients(1) Jobname Cpu time Storage EXCP -------- ----------- ------- ---------- JMON 0.01 2864 80 LOCKD 1.76 30.6M 14255 RSED 4.48 33.0M 15187 RSED8 3.53 53.9M 24125 expand large MVS tree (195 data sets) BPXM023I (STCRSE) ProcessId(212 ) Memory Usage(13%) Clients(1) Jobname Cpu time Storage EXCP -------- ----------- ------- ---------- JMON 0.01 2864 80 LOCKD 1.78 30.6M 14255 RSED 4.58 33.1M 16094 RSED8 4.28 56.1M 24740 expand small PDS (21 members) BPXM023I (STCRSE) ProcessId(212 ) Memory Usage(13%) Clients(1) Jobname Cpu time Storage EXCP -------- ----------- ------- ---------- IBMUSER2 0.22 2644 870 JMON 0.01 2864 80 LOCKD 1.78 30.6M 14255 RSED 4.61 33.1M 16108 RSED8 4.40 56.2M 24937 open medium sized member (86 lines) BPXM023I (STCRSE) ProcessId(212 ) Memory Usage(13%) Clients(1) Jobname Cpu time Storage EXCP -------- ----------- ------- ---------- IBMUSER2 0.22 2644 870 JMON 0.01 2864 80 RSED 4.61 33.1M 16108 RSED8 8.12 62.7M 27044
Abb. 56 zeigt ein Szenario, in dem sich 1 Client bei einem RSE-Dämon mit einem 10-MB-Java-Heapspeicher anmeldet und ein Member der untergliederten Datei bearbeitet.
Die meisten Daten mit Bezug auf Developer for System z, die nicht in eine DD-Anweisung geschrieben werden, werden in einer z/OS UNIX-Datei gespeichert. Der Systemprogrammierer steuert, welche Daten an welcher Position gespeichert werden. Er hat allerdings keine Kontrolle über die gespeicherte Datenmenge.
Die Daten können in folgende Kategorien eingeteilt werden:
Wie in Konfigurationsprobleme lösen dokumentiert, speichert Developer for System z die RSE-bezogenen Hostprotokolle in den folgenden z/OS UNIX-Verzeichnissen:
Standardmäßig werden nur Fehlernachrichten und Warnungen in den Protokollen gespeichert. Bei einem ordnungsgemäßen Betrieb sollten diese Verzeichnisse also nur leere oder beinahe leere Dateien enthalten. (Prüfprotokolle werden dabei nicht berücksichtigt.)
Sie können das Protokollieren von Informationsnachrichten aktivieren (am besten nur auf Anweisung des IBM Support Center), wodurch die Größe der Protokolldateien deutlich zunimmt.
startup $ ls -l /var/rdz/logs total 144 -rw-rw-rw- 1 STCRSE STCGRP 33642 Jul 10 12:10 rsedaemon.log -rw-rw-rw- 1 STCRSE STCGRP 1442 Jul 10 12:10 rseserver.log logon $ ls -l /var/rdz/logs total 144 drwxrwxrwx 3 IBMUSER SYS1 8192 Jul 10 12:11 IBMUSER -rw-rw-rw- 1 STCRSE STCGRP 36655 Jul 10 12:11 rsedaemon.log -rw-rw-rw- 1 STCRSE STCGRP 1893 Jul 10 12:11 rseserver.log $ ls -l /var/rdz/logs/IBMUSER total 160 -rw-rw-rw- 1 IBMUSER SYS1 3459 Jul 10 12:11 ffs.log -rw-rw-rw- 1 IBMUSER SYS1 0 Jul 10 12:11 ffsget.log -rw-rw-rw- 1 IBMUSER SYS1 0 Jul 10 12:11 ffsput.log -rw-rw-rw- 1 IBMUSER SYS1 303 Jul 10 12:11 lock.log -rw-rw-rw- 1 IBMUSER SYS1 126 Jul 10 12:11 rmt_classloader_cache.jar -rw-rw-rw- 1 IBMUSER SYS1 7266 Jul 10 12:11 rsecomm.log -rw-rw-rw- 1 IBMUSER SYS1 0 Jul 10 12:11 stderr.log -rw-rw-rw- 1 IBMUSER SYS1 0 Jul 10 12:11 stdout.log logoff $ ls -l /var/rdz/logs total 80 drwxrwxrwx 3 IBMUSER SYS1 8192 Jul 10 12:11 IBMUSER -rw-rw-rw- 1 STCRSE STCGRP 36655 Jul 10 12:11 rsedaemon.log -rw-rw-rw- 1 STCRSE STCGRP 2208 Jul 10 12:11 rseserver.log $ ls -l /var/rdz/logs/IBMUSER total 296 -rw-rw-rw- 1 IBMUSER SYS1 6393 Jul 10 12:11 ffs.log -rw-rw-rw- 1 IBMUSER SYS1 0 Jul 10 12:11 ffsget.log -rw-rw-rw- 1 IBMUSER SYS1 0 Jul 10 12:11 ffsput.log -rw-rw-rw- 1 IBMUSER SYS1 609 Jul 10 12:11 lock.log -rw-rw-rw- 1 IBMUSER SYS1 126 Jul 10 12:11 rmt_classloader_cache.jar -rw-rw-rw- 1 IBMUSER SYS1 45157 Jul 10 12:11 rsecomm.log -rw-rw-rw- 1 IBMUSER SYS1 0 Jul 10 12:11 stderr.log -rw-rw-rw- 1 IBMUSER SYS1 176 Jul 10 12:11 stdout.log stop $ ls -l /var/rdz/logs total 80 drwxrwxrwx 3 IBMUSER SYS1 8192 Jul 10 12:11 IBMUSER -rw-rw-rw- 1 STCRSE STCGRP 36655 Jul 10 12:11 rsedaemon.log -rw-rw-rw- 1 STCRSE STCGRP 2490 Jul 10 12:12 rseserver.log
Abb. 57 zeigt die minimale Speicherbelegung des z/OS UNIX-Dateisystems bei der Verwendung von Debugstufe 2 (Informationsnachrichten).
Mit Ausnahme von Prüfprotokollen werden Protokolldateien bei jedem Neustart (bei der gestarteten RSE-Task) oder bei jeder Anmeldung (bei einem Client) überschrieben. Dadurch wird die Gesamtgröße begrenzt. Durch die Anweisung keep.last.log in rsed.envvars wird dies geringfügig geändert. Aufgrund dieser Anweisung kann RSE eine Kopie der vorherigen Protokolle beibehalten. Ältere Kopien werden immer gelöscht.
Wenn im Dateisystem mit den Prüfprotokolldateien nur noch ein kleiner freier Speicherbereich verfügbar ist, wird eine Warnung an die Konsole gesendet, sofern die Protokollierung aktiv ist. Diese Konsolnachricht (FEK103E) wird immer wieder angezeigt, bis das Speicherproblem gelöst ist. Eine Liste der von RSE generierten Konsolnachrichten finden Sie im Abschnitt Konsolnachrichten.
Die Definitionen in Tabelle 46 steuern, welche Daten in den Protokollverzeichnissen gespeichert werden und wo sich diese Verzeichnisse befinden.
Position | Anweisung | Funktion |
---|---|---|
resecomm.properties | debug_level | Standardprotokolldetailstufe festlegen |
rsed.envvars | keep.last.log | Eine Kopie der vorherigen Protokolle vor Start/Anmeldung beibehalten |
rsed.envvars | enable.audit.log | Prüftrace der Clientaktionen beibehalten |
rsed.envvars | enable.standard.log | Datenströme 'stdout' und 'stderr' des (bzw. der) Thread-Pools in eine Protokolldatei schreiben |
rsed.envvars | DSTORE_TRACING_ON | DataStore-Aktionsprotokollierung aktivieren |
rsed.envvars | DSTORE_MEMLOGGING_ON | DataStore-Protokollierung der Speicherbelegung aktivieren |
Bedienerbefehl | modify rsecommlog <Stufe> | Die Protokolldetailstufe von rsecomm.log dynamisch ändern |
Bedienerbefehl | modify rsedaemonlog <Stufe> | Die Protokolldetailstufe von rsedaemon.log dynamisch ändern |
Bedienerbefehl | modify rseserverlog <Stufe> | Die Protokolldetailstufe von rseserver.log dynamisch ändern |
Bedienerbefehl | modify rsestandardlog {on|off} | Die Aktualisierung von std*.*.log dynamisch ändern |
rsed.envvars | daemon.log | Ausgangspfad für gestartete RSE-Task und Prüfprotokolle |
rsed.envvars | user.log | Ausgangspfad für Benutzerprotokolle |
Zusammen mit vorausgesetzter Software wie dem ISPF-Client-Gateway schreibt Developer for System z auch temporäre Daten in /tmp und /var/rdz/WORKAREA. Das hier geschriebene Datenvolumen ist unvorhersehbar. In den Dateisystemen, in denen sich diese Verzeichnisse befinden, sollten Sie daher ausreichend freien Speicherbereich haben.
Developer for System z versucht immer, diese temporären Dateien zu bereinigen. Eine manuelle Bereinigung, wie im Abschnitt WORKAREA-Bereinigung (optional) dokumentiert, kann aber jederzeit durchgeführt werden.
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, die keine optionalen Komponenten von Developer for System z benötigen. Im Abschnitt RSE-Konfigurationsdatei rsed.envvars werden alle Variablen beschrieben, die in der Beispieldatei definiert sind. Bei den folgenden Variablen müssen Sie allerdings besonders vorsichtig sein:
RSE ist eine Java-Anwendung, das heißt, sie ist in der z/OS UNIX-Umgebung aktiv. Auf diese Weise wird BPXPRMxx ein entscheidendes PARMLIB-Member, weil es die Parameter enthält, mit denen die z/OS UNIX-Umgebung und die Dateisysteme gesteuert werden. BPXPRMxx wird in MVS Initialization and Tuning Reference (IBM Form SA22-7592) beschrieben. Die folgenden Anweisungen wirken sich auf Developer for System z aus:
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.
Die folgenden Definitionen sollten der EXEC-Karte in der JCL des Servers für Developer for System z hinzugefügt werden.
Die in FEJJCNFG definierten Umgebungsvariablen werden von JES Job Monitor verwendet. Die mit Developer for System z gelieferte Beispieldatei ist für kleine bis mittlere Installationen gedacht. Im Abschnitt Konfigurationsdatei für JES Job Monitor (FEJJCNFG) werden alle Variablen beschrieben, die in der Beispieldatei definiert sind. Bei den folgenden Variablen müssen Sie allerdings besonders vorsichtig sein:
IEASYSxx wird in MVS Initialization and Tuning Reference (IBM Form SA22-7592) beschrieben. Die folgenden Anweisungen wirken sich auf Developer for System z aus:
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 auf Developer for System z aus:
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 auf Developer for System z aus:
Da sich der Bedarf an Systemressourcen durch die Benutzerarbeitslast ändern kann, sollte das System regelmäßig überwacht werden, um die Ressourcennutzung zu messen. So können Rational Developer for System z und die Systemkonfiguration entsprechend Ihren Benutzeranforderungen angepasst werden. Als Unterstützung bei diesem Überwachungsprozess können die folgenden Befehle verwendet werden.
Benutzeraktivitäten in Developer for System z finden hauptsächlich in RSE-Thread-Pools statt. Zur optimalen Verwendung benötigen die Pools daher eine Überwachung. Zum RSE-Dämon können Informationen abgerufen werden, die nicht mit üblichen Systemüberwachungstools zusammengestellt werden können.
FEK004I RseDaemon: Max Heap Size=65MB and private AS Size=1,959MB
f rsed,appl=d p BPXM023I (STCRSE) ProcessId(16777456) Memory Usage(33%) Clients(4) Order(1)
Es werden weitere Informationen bereitgestellt, wenn die Option "DETAIL" des Änderungsbefehls DISPLAY PROCESS verwendet wird:
f rsed,appl=d p,detail BPXM023I (STCRSE) ProcessId(33555087) ASId(002E) JobName(RSED8) Order(1) PROCESS LIMITS: CURRENT HIGHWATER LIMIT JAVA HEAP USAGE(%) 10 56 100 CLIENTS 0 25 60 MAXFILEPROC 83 103 64000 MAXPROCUSER 97 99 200 MAXTHREADS 9 14 1500 MAXTHREADTASKS 9 14 1500
Die meisten z/OS UNIX-Begrenzungen, die für Developer for System z wichtig sind, können mithilfe von Bedienerbefehlen angezeigt werden. Mit einigen Befehlen wird sogar die aktuelle Verwendung und die obere Grenze für einen bestimmten Grenzwert angezeigt. Weitere Informationen zu diesen Befehlen enthält die Veröffentlichung MVS System Commands (IBM Form SA22-7627).
d omvs,o BPXO043I 13.10.16 DISPLAY OMVS 066 OMVS 000D ETC/INIT WAIT OMVS=(M7) CURRENT UNIX CONFIGURATION SETTINGS: MAXPROCSYS = 256 MAXPROCUSER = 16 MAXFILEPROC = 256 MAXFILESIZE = NOLIMIT MAXCPUTIME = 1000 MAXUIDS = 200 MAXPTYS = 256 MAXMMAPAREA = 256 MAXASSIZE = 209715200 MAXTHREADS = 200 MAXTHREADTASKS = 1000 MAXCORESIZE = 4194304 MAXSHAREPAGES = 4096 IPCMSGQBYTES = 2147483647 IPCMSGQMNUM = 10000 IPCMSGNIDS = 500 IPCSEMNIDS = 500 IPCSEMNOPS = 25 IPCSEMNSEMS = 1000 IPCSHMMPAGES = 25600 IPCSHMNIDS = 500 IPCSHMNSEGS = 500 IPCSHMSPAGES = 262144 SUPERUSER = BPXROOT FORKCOPY = COW STEPLIBLIST = USERIDALIASTABLE= SERV_LINKLIB = POSIX.DYNSERV.LOADLIB BPXLK1 SERV_LPALIB = POSIX.DYNSERV.LOADLIB BPXLK1 PRIORITYPG VALUES: NONE PRIORITYGOAL VALUES: NONE MAXQUEUEDSIGS = 1000 SHRLIBRGNSIZE = 67108864 SHRLIBMAXPAGES = 4096 VERSION = / SYSCALL COUNTS = NO TTYGROUP = TTY SYSPLEX = NO BRLM SERVER = N/A LIMMSG = NONE AUTOCVT = OFF RESOLVER PROC = DEFAULT AUTHPGMLIST = NONE SWA = BELOW
d omvs,l BPXO051I 14.05.52 DISPLAY OMVS 904 OMVS 0042 ACTIVE OMVS=(69) SYSTEM WIDE LIMITS: LIMMSG=SYSTEM CURRENT HIGHWATER SYSTEM USAGE USAGE LIMIT MAXPROCSYS 1 4 256 MAXUIDS 0 0 200 MAXPTYS 0 0 256 MAXMMAPAREA 0 0 256 MAXSHAREPAGES 0 10 4096 IPCMSGNIDS 0 0 500 IPCSEMNIDS 0 0 500 IPCSHMNIDS 0 0 500 IPCSHMSPAGES 0 0 262144 * IPCMSGQBYTES --- 0 262144 IPCMSGQMNUM --- 0 10000 IPCSHMMPAGES --- 0 256 SHRLIBRGNSIZE 0 0 67108864 SHRLIBMAXPAGES 0 0 4096
Wenn zusätzlich das Schlüsselwort PID=processid angegeben wird, zeigt der Befehl die oberen Grenzen und die aktuelle Verwendung für einen einzelnen Prozess an.
d,omvs,l,pid=16777456 BPXO051I 14.06.28 DISPLAY OMVS 645 OMVS 000E ACTIVE OMVS=(76) USER JOBNAME ASID PID PPID STATE START CT_SECS STCRSE RSED8 007E 16777456 67109106 HF---- 20.00.56 113.914 LATCHWAITPID= 0 CMD=java -Ddaemon.log=/var/rdz/logs - PROCESS LIMITS: LIMMSG=NONE CURRENT HIGHWATER PROCESS USAGE USAGE LIMIT MAXFILEPROC 83 103 256 MAXFILESIZE --- --- NOLIMIT MAXPROCUSER 97 99 200 MAXQUEUEDSIGS 0 1 1000 MAXTHREADS 9 14 200 MAXTHREADTASKS 9 14 1000 IPCSHMNSEGS 0 0 500 MAXCORESIZE --- --- 4194304 MAXMEMLIMIT 0 0 16383P
d omvs,p BPXO046I 14.35.38 DISPLAY OMVS 092 OMVS 000E ACTIVE OMVS=(33) PFS CONFIGURATION INFORMATION PFS TYPE DESCRIPTION ENTRY MAXSOCK OPNSOCK HIGHUSED TCP SOCKETS AF_INET EZBPFINI 50000 244 8146 UDS SOCKETS AF_UNIX BPXTUINT 64 6 10 ZFS LOCAL FILE SYSTEM IOEFSCM 14:32.00 RECYCLING HFS LOCAL FILE SYSTEM GFUAINIT BPXFTCLN CLEANUP DAEMON BPXFTCLN BPXFTSYN SYNC DAEMON BPXFTSYN BPXFPINT PIPE BPXFPINT BPXFCSIN CHAR SPECIAL BPXFCSIN NFS REMOTE FILE SYSTEM GFSCINIT PFS NAME DESCRIPTION ENTRY STATUS FLAGS TCP41 SOCKETS EZBPFINI ACT CD TCP42 SOCKETS EZBPFINI ACT TCP43 SOCKETS EZBPFINI INACT SD TCP44 SOCKETS EZBPFINI INACT PFS PARM INFORMATION HFS SYNCDEFAULT(60) FIXED(50) VIRTUAL(100) CURRENT VALUES: FIXED(55) VIRTUAL(100) NFS biod(6)
d omvs,pid=16777456 BPXO040I 15.30.01 DISPLAY OMVS 637 OMVS 000E ACTIVE OMVS=(76) USER JOBNAME ASID PID PPID STATE START CT_SECS STCRSE RSED8 007E 16777456 67109106 HF---- 20.00.56 113.914 LATCHWAITPID= 0 CMD=java -Ddaemon.log=/var/rdz/logs - THREAD_ID TCB@ PRI_JOB USERNAME ACC_TIME SC STATE 0E08A00000000000 005E6DF0 OMVS .927 RCV FU 0E08F00000000001 005E6C58 .001 PTX JYNV 0E09300000000002 005E6AC0 7.368 PTX JYNV 0E0CB00000000008 005C2CF0 OMVS 1.872 SEL JFNV 0E192000000003CE 005A0B70 OMVS IBMUSER 14.088 POL JFNV 0E18D000000003CF 005A1938 IBMUSER .581 SND JYNV
Für die Unterstützung einer großen Anzahl von Clients, die eine Verbindung mit dem Host herstellen, muss nicht nur Developer for System z, sondern auch Ihre Netzinfrastruktur in der Lage sein, die Arbeitslast zu verarbeiten. Die Netzverwaltung ist ein umfangreiches und gut dokumentiertes Thema, das nicht in der Dokumentation von Developer for System z behandelt wird. Aus diesem Grund werden nur die folgenden Verweise zur Verfügung gestellt.
In Developer for System z werden z/OS UNIX-Dateisysteme verwendet, um verschiedene Datentypen (beispielsweise Protokolle und temporäre Dateien) zu speichern. Verwenden Sie den z/OS UNIX-Befehl df, um anzuzeigen, 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.FEK.HHOP760) 3062/43200 4294967147 Available /var (OMVS.VAR) 27264/31680 4294967054 Available
Die folgende Beispielkonfiguration zeigt die erforderliche Konfiguration zur Unterstützung der folgenden Anforderungen:
Developer for System z versucht standardmäßig, 60 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 44 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 60 Benutzer einem einzigen Thread-Pool hinzufügt. (60*(16+1)=1020 und maximum.threads ist standardmäßig auf 1000 gesetzt.)
Es wäre möglich, maximum.threads zu erhöhen. Weil laut Anforderung allerdings pro Benutzer ein durchschnittlicher Java-Heapspeicher von 5 MB bereitgestellt werden soll, wird maximum.clients auf 50 verringert. Auf diese Weise (5*50 = 250) wird die standardmäßige maximale Größe des Java-Heapspeichers (256 MB) beachtet.
Mit 50 Clients pro Thread-Pool und der Anforderung zur Unterstützung von 500 Verbindungen werden somit 10 Thread-Pool-Adressräume benötigt.
Mithilfe der in diesem Kapitel bereits gezeigten Formeln und der Kriterien, die am Anfang dieses Abschnitts genannt wurden, kann die Ressourcennutzung festgelegt werden, die verarbeitet werden muss.
3 + A + N*(x + y + z) + (2 + N*0.01)
3 + 10 + 500*1 + 200*1 + 300*1 + (2 + 500*0.01) = 1020
x + y + z
1 + 1 + 1 = 3
7 + 2*A + N*(x + y + z) + (10 + N*0.05)
7 + 2*10 + 500*2 + 200*1 + 300*0 + (10 + 500*0.05) = 1562
(x + y + z) + 5*s
(2 + 1 + 0) + 5*0 = 3
9 + N*(16 + x + y + z) + (20 + N*0.1)
9 + 60*(16 + 1 + 4 + 0) + (20 + 60*0.1) = 1295
3 + N
3 + 500 = 503
500 + 3 = 503
Die 3 zusätzlichen Benutzer-IDs werden für STCJMON, STCLOCK und STCRSE (die Benutzer-IDs der gestarteten Tasks für Developer for System z) benötigt.
Da jetzt die Zahlen für die Ressourcennutzung bekannt sind, können die begrenzenden Anweisungen mit entsprechenden Werten angepasst werden.
Diese Änderung ist optional. RSE startet neue Thread-Pools, wenn erforderlich.
Nachdem Sie die Systemgrenzwerte, wie unter Begrenzungen 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. Abb. 58 zeigt die Ressourcennutzung, nachdem sich 495 Benutzer angemeldet haben. (Das Beispiel in der Abbildung zeigt nur die Anmeldung. Es sind keine Benutzeraktionen angegeben.)
BPXM023I (STCRSE) ProcessId(16779764) Memory Usage(10%) Clients(50) Order(1) ProcessId(67108892) Memory Usage(16%) Clients(50) Order(2) ProcessId(67108908) Memory Usage(10%) Clients(50) Order(3) ProcessId(67108898) Memory Usage(16%) Clients(50) Order(4) ProcessId(67108916) Memory Usage(16%) Clients(50) Order(5) ProcessId(67108897) Memory Usage(16%) Clients(50) Order(6) ProcessId(67108921) Memory Usage(16%) Clients(50) Order(7) ProcessId(83886146) Memory Usage(16%) Clients(50) Order(8) ProcessId(67108920) Memory Usage(16%) Clients(50) Order(9) ProcessId(3622 ) Memory Usage(8%) Clients(45) Order(10) Jobname Cpu time Storage EXCP -------- ----------- ------- ---------- JMON 1.74 43.0M 2753 LOCKD 10.05 31.9M 24621 RSED 6.65 40.1M 41780 RSED1 8.17 187.0M 76566 RSED2 13.04 184.9M 78946 RSED3 17.77 181.1M 76347 RSED4 11.63 174.9M 74638 RSED5 15.27 172.9M 72883 RSED6 13.85 180.8M 75031 RSED7 9.79 174.3M 76636 RSED8 21.59 176.1M 70583 RSED8 18.88 184.7M 76953 RSED9 9.52 189.8M 80490
z/OS ist ein sehr anpassungsfähiges Betriebssystem, bei dem (manchmal kleine) Systemänderungen eine enorme Auswirkung auf die Gesamtleistung haben können. Dieses Kapitel hebt einige der Änderungen hervor, die zu einer Verbesserung der Leistung von Developer for System z führen können.
Weitere Informationen zur Systemoptimierung finden Sie im MVS Initialization and Tuning Guide (IBM Form SA22-7591) sowie in der Veröffentlichung UNIX System Services Planning (IBM Form GA22-7800).
Das zFS (zSeries File System) und das HFS (Hierarchical File System) sind UNIX-Dateisysteme, die in einer z/OS UNIX-Umgebung verwendet werden können. Das zFS bietet jedoch die folgenden Features und Vorteile:
Wenn Sie mehr über das zFS erfahren möchten, lesen Sie die Veröffentlichung UNIX System Services Planning (IBM Form GA22-7800).
Jeder z/OS UNIX-Prozess mit einer STEPLIB, die vom übergeordneten Element zum untergeordneten Element oder über eine Exec weitergegeben wird, belegt einen erweiterten allgemeinen Speicherbereich (ECSA, Extended Common Storage Area) von ca. 200 Bytes. Wenn die Umgebungsvariable STEPLIB nicht oder mit STEPLIB=CURRENT definiert ist, gibt z/OS UNIX alle aktiven TASKLIB-, STEPLIB- und JOBLIB-Zuordnungen während einer Funktion fork(), spawn() oder exec() weiter.
In rsed.envvars ist die Standardeinstellung für Developer for System z mit STEPLIB=NONE codiert. Lesen Sie hierzu die Beschreibung in der Konfigurationsdatei rsed.envvars. Aus den oben genannten Gründen sollten Sie diese Anweisung nicht ändern und die resultierenden Dateien stattdessen in die LINKLIST oder den LPA (Link-Pack-Bereich) stellen.
Bestimmte Systembibliotheken und Lademodule werden von z/OS UNIX und Aktivitäten der Anwendungsentwicklung besonders häufig verwendet. Wenn Sie den Zugriff auf diese Bibliotheken und Module verbessern, indem Sie sie beispielsweise zum Link-Pack-Bereich (LPA) hinzufügen, können Sie die Systemleistung steigern. Weitere Informationen zu den nachfolgend beschriebenen SYS1.PARMLIB-Membern enthält die Veröffentlichung MVS Initialization and Tuning Reference (IBM Form SA22-7592).
Wenn C-Programme (einschließlich der z/OS UNIX-Shell) ausgeführt werden, verwenden sie häufig Routinen aus der LE-Laufzeitbibliothek (Language Environment). Für jeden Adressraum, der ein LE-fähiges Programm ausführt, werden ungefähr 4 MB der Laufzeitbibliothek in den Speicher geladen und in jede Verzweigung kopiert.
CEE.SCEELPA
Die Datei CEE.SCEELPA enthält eine Untergruppe der LE-Laufzeitroutinen, die besonders oft von z/OS UNIX verwendet werden. Sie sollten diese Datei zu SYS1.PARMLIB(LPALSTxx) hinzufügen, um einen maximalen Leistungsgewinn zu erzielen. Wenn Sie dieser Empfehlung folgen, werden die Module nur einmal von der Platte gelesen und an einer gemeinsam genutzten Position gespeichert.
LPA ADD MASK(*) DSNAME(CEE.SCEELPA)
Außerdem sollten Sie die LE-Laufzeitbibliotheken CEE.SCEERUN und CEE.SCEERUN2 in die LINKLIST stellen, indem Sie die Dateien zu SYS1.PARMLIB(LNKLSTxx) oder SYS1.PARMLIB(PROGxx) hinzufügen. Auf diese Weise entfällt der z/OS UNIX-Systemaufwand für die STEPLIB und das Ein-/Ausgabevolumen verringert sich infolge der Verwaltung durch LLA und VLF oder ähnliche Produkte.
Wenn Sie sich entschließen, diese Bibliotheken nicht in die LINKLIST zu stellen, müssen Sie in der Datei rsed.envvars die entsprechende STEPLIB-Anweisung konfigurieren. Lesen Sie hierzu die Beschreibung in der Konfigurationsdatei rsed.envvars. Obwohl diese Methode immer zusätzlichen virtuellen Speicher verwendet, können Sie die Leistung verbessern, indem Sie die LE-Laufzeitbibliotheken für LLA oder ein ähnliches Produkt definieren. Dadurch werden die Ein-/Ausgaben reduziert, die für das Laden der Module erforderlich sind.
Auf Systemen, deren primäre Aktivität die Anwendungsentwicklung ist, kann auch eine Leistungsverbesserung erreicht werden, wenn der Linkage-Editor in den dynamischen LPA gestellt wird. Hierfür müssen die folgenden Zeilen zu SYS1.PARMLIB(PROGxx) hinzugefügt werden:
LPA ADD MODNAME(CEEBINIT,CEEBLIBM,CEEEV003,EDCZV) DSNAME(CEE.SCEERUN) LPA ADD MODNAME(IEFIB600,IEFXB603) DSNAME(SYS1.LINKLIB)
Für die C/C++-Entwicklung können Sie außerdem die Compilerdatei CBC.SCCNCMP zu SYS1.PARMLIB(LPALSTxx) hinzufügen.
Die obigen 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).
Wenn Sie den Durchsatz der für z/OS UNIX durchgeführten Sicherheitsprüfung verbessern möchten, definieren Sie in der Klasse FACILITY Ihrer Sicherheitssoftware das Profil BPX.SAFFASTPATH. Dadurch wird für ein breites Spektrum von Operationen der Systemaufwand für die z/OS UNIX-Sicherheitsprüfungen verringert, z. B. für die Überprüfung des Dateizugriffs und des IPC-Zugriffs sowie für die Überprüfung der Eigentumsrechte an Prozessen. Weitere Informationen zu diesem Profil enthält die Veröffentlichung UNIX System Services Planning (IBM Form GA22-7800).
An jedem Standort gelten ganz bestimmte Anforderungen. Das Betriebssystem z/OS kann so angepasst werden, dass die verfügbaren Ressourcen optimal genutzt werden, um diese Anforderungen zu erfüllen. Bei der Auslastungsverwaltung definieren Sie Leistungsziele und ordnen jedem dieser Ziele eine geschäftliche Bedeutung zu. Sie definieren Arbeitsziele mit Geschäftsbegriffen, und das System entscheidet, wie viele Ressourcen (z. B. CPU und Speicher) der Arbeit zugeordnet werden müssen, um das angestrebte Ziel zu erreichen.
Indem Sie für die Prozesse von Developer for System z die richtigen Ziele festlegen, können Sie für eine ausgeglichene Leistung des Produkts sorgen. Nachfolgend sind dazu einige allgemeine Richtlinien aufgelistet.
Weitere Informationen zu diesem Thema finden Sie in der Veröffentlichung MVS Planning Workload Management (IBM Form SA22-7602).
Bei einem Heapspeicher fester Größe gibt es keine Erweiterung oder Verkleinerung, was in bestimmten Situationen zu einer deutlichen Leistungssteigerung führen kann. Generell ist die Verwendung eines Heapspeichers mit fester Größe jedoch keine gute Idee, weil sie den Start der Garbage-Collection hinauszögert, bis der Heapspeicher voll ist. Die dann ausgeführte Garbage-Collection ist dementsprechend umfangreich. Außerdem steigt das Fragmentierungsrisiko, sodass eine Heapkomprimierung erforderlich ist. Heapspeicher mit fester Größe sollten Sie daher nur nach gründlichen Tests bzw. unter Anleitung des IBM Support Center verwenden. Weitere Informationen zu Heapgrößen und Garbage-Collections enthält der Java Diagnostics Guide (IBM Form SC34-6650).
Der Heapspeicher einer z/OS Java Virtual Machine (JVM) hat standardmäßig eine Anfangsgröße von 1 Megabyte. Die maximale Größe liegt bei 64 Megabytes. Die Grenzwerte können Sie mit den Java-Befehlszeilenoptionen -Xms (Anfangsgröße) und -Xmx (maximale Größe) setzen.
In Developer for System z sind Java-Befehlszeilenoptionen in der Steueranweisung _RSE_JAVAOPTS der Datei rsed.envvars definiert. Eine diesbezügliche Beschreibung finden Sie im Abschnitt Zusätzliche Java-Startparameter mit _RSE_JAVAOPTS definieren.
#_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Xms128m -Xmx128m"
Mit der Option -Xquickstart kann die Startzeit einiger Java-Anwendungen verbessert werden. -Xquickstart bewirkt die teiloptimierte Ausführung des JIT-Compilers und ermöglicht so eine schnelle Kompilierung. Durch diese schnelle Kompilierung wird wiederum die Startzeit verkürzt.
-Xquickstart ist für Anwendungen geeignet, die eine kurze Laufzeit haben, und insbesondere für jene, bei denen die Ausführungszeit nicht auf eine geringe Anzahl von Methoden konzentriert ist. Die Option -Xquickstart kann den Durchsatz verringern, wenn sie für Anwendungen genutzt wird, die eine lange Laufzeit haben und häufig verwendete Methoden enthalten.
Fügen Sie am Ende der Datei rsed.envvars die folgende Anweisung hinzu, um die Option -Xquickstart für den RSE-Server zu aktivieren:
_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Xquickstart"
Die IBM Java Virtual Machine (JVM) bietet ab Version 5 die Möglichkeit, dass JVMs die Bootstrap-Klassen und Anwendungsklassen gemeinsam nutzen können, indem sie sie in einem Cache innerhalb des gemeinsam genutzten Speichers ablegt. Bei der gemeinsamen Nutzung von Klassen verwenden mehrere JVMs einen Cache gemeinsam, sodass insgesamt weniger virtueller Speicher belegt wird. Die gemeinsame Klassennutzung verkürzt außerdem die Startzeit für eine JVM, nachdem der Cache erstellt wurde.
Der Cache für gemeinsam genutzte Klassen ist von den aktiven JVMs unabhängig und bleibt über die Lebensdauer der JVM hinweg bestehen, die den Cache erstellt hat. Da der Cache für gemeinsam genutzte Klassen länger bestehen bleibt als jede JVM, wird er durch dynamische Aktualisierungen an alle Änderungen angepasst, die ggf. an JARs oder Klassen im Dateisystem vorgenommen wurden.
Der Systemaufwand für das Erstellen eines neuen Cache und das Füllen des Cache mit Daten ist minimal. Das Starten einer einzelnen JVM dauert im Vergleich zur gemeinsamen Nutzung von Klassen in der Regel 0 bis 5 % länger. Der genaue Unterschied im Zeitaufwand hängt davon ab, wie viele Klassen geladen werden. Bei einem mit Daten gefüllten Cache verkürzt sich die Startzeit für eine JVM im Vergleich zu einem System ohne gemeinsame Klassennutzung normalerweise um 10 bis 40 %. Die tatsächliche Beschleunigung ist vom Betriebssystem und von der Anzahl der geladenen Klassen abhängig. Bei mehreren gleichzeitig aktiven JVMs macht sich die Reduzierung der Gesamtstartzeit deutlicher bemerkbar.
Wenn Sie mehr über die gemeinsame Nutzung von Klassen erfahren möchten, lesen Sie den Java SDK and Runtime Environment User Guide.
Fügen Sie am Ende der Datei rsed.envvars die nachstehenden Anweisungen hinzu, um die gemeinsame Klassennutzung für den RSE-Server zu aktivieren. Die erste Anweisung definiert einen Cache mit dem Namen 'RSE' und mit Gruppenzugriff. Sie ermöglicht den Start des RSE-Servers, auch wenn die gemeinsame Klassennutzung scheitert. Die zweite Anweisung ist optional und setzt die Cachegröße auf 6 Megabytes. (Der Systemstandardwert liegt bei 16 MB.) Die dritte Anweisung fügt die Parameter für die gemeinsame Klassennutzung zu den Java-Startoptionen hinzu.
_RSE_CLASS_OPTS=-Xshareclasses:name=RSE,groupAccess,nonFatal #_RSE_CLASS_OPTS="$_RSE_CLASS_OPTS -Xscmx6m _RSE_JAVAOPTS="$_RSE_JAVAOPTS $_RSE_CLASS_OPTS"
Die theoretische maximale Größe des gemeinsam genutzten Cache liegt bei 2 GB. Die Cachegröße, die Sie angeben können, wird durch den auf dem System verfügbaren physischen Hauptspeicher und den verfügbaren Auslagerungsspeicher begrenzt. Da der virtuelle Adressraum eines Prozesses sowohl vom Cache für gemeinsam genutzte Klassen als auch vom Java-Heapspeicher verwendet wird, führt eine Erhöhung der maximalen Java-Heapgröße dazu, dass Sie einen entsprechend kleineren Cache für gemeinsam genutzte Klassen erstellen können.
Der Zugriff auf den Cache für gemeinsam genutzte Klassen wird durch Berechtigungen des Betriebssystems und Java-Sicherheitsberechtigungen beschränkt.
Standardmäßig wird für die Erstellung von Klassencaches die Sicherheit auf Benutzerebene verwendet, sodass nur der Benutzer, der den Cache erstellt hat, auf den Cache zugreifen kann. Unter z/OS UNIX gibt es die Option groupAccess, die allen Benutzern Zugriff gewährt, die zur Primärgruppe des Benutzers gehören, der den Cache erstellt hat. Zerstört werden kann ein Cache unabhängig von der verwendeten Zugriffsebene nur von dem Benutzer, der ihn erstellt hat, oder von einem Benutzer 'root' (UID 0).
Wenn Sie mehr über zusätzliche Sicherheitsoptionen bei Verwendung eines Java-Sicherheitsmanagers erfahren möchten, lesen Sie den Java SDK and Runtime Environment User Guide.
Einige der Einstellungen von SYS1.PARMLIB(BPXPRMxx) wirken sich bei gemeinsam genutzten Klassen auf den Durchsatz aus. Falsche Einstellungen können dazu führen, dass die gemeinsam genutzten Klassen nicht funktionieren. Diese Einstellungen können sich auch auf die Leistung auswirken. Weitere Informationen zur Verwendung dieser Parameter und zu ihrer Auswirkung auf die Leistung enthalten die Veröffentlichungen MVS Initialization and Tuning Reference (IBM Form SA22-7592) und UNIX System Services Planning (IBM Form GA22-7800). Die hinsichtlich der Verarbeitung gemeinsam genutzter Klassen wichtigsten BPXPRMxx-Parameter sind folgende:
Diese Einstellungen beeinflussen, wie viele gemeinsam genutzte Speicherseiten der JVM zur Verfügung stehen. Für einen z/OS UNIX-System Service (31 Bit) hat die gemeinsam genutzte Seite eine feste Größe von 4 KB. Gemeinsam genutzte Klassen versuchen standardmäßig, einen Cache mit einer Größe von 16 MB zu erstellen. Sie sollten IPCSHMMPAGES deshalb auf einen Wert größer als 4096 setzen.
Wenn Sie die Cachegröße mit -Xscmx festlegen, rundet die JVM den Wert auf das nächste volle Megabyte auf. Berücksichtigen Sie dies, wenn Sie IPCSHMMPAGES auf Ihrem System setzen.
Diese Einstellungen beeinflussen, wie viele Semaphore für UNIX-Prozesse zur Verfügung stehen. Gemeinsam genutzte Klassen verwenden für die Kommunikation zwischen JVMs IPC-Semaphore.
Der Cache für gemeinsam genutzte Klassen benötigt zum Speichern von Kennungsdaten der auf dem System vorhandenen Caches Plattenspeicherplatz. Diese Daten werden unter /tmp/javasharedresources gespeichert. Wenn das Verzeichnis mit den Kennungsdaten gelöscht wird, kann die JVM nicht die gemeinsam genutzten Klassen auf dem System identifizieren und muss den Cache neu erstellen.
Der Java-Zeilenbefehl -Xshareclasses kann mit verschiedenen Optionen verwendet werden, zu denen auch Dienstprogramme für die Cacheverwaltung gehören. Drei dieser Dienstprogramme sind im folgenden Beispiel enthalten ($ ist die z/OS UNIX-Eingabeaufforderung). Eine vollständige Übersicht über die unterstützten Befehlszeilenoptionen enthält der Java SDK and Runtime Environment User Guide.
$ java -Xshareclasses:listAllCaches Shared Cache OS shmid in use Last detach time RSE 401412 0 Mon Jun 18 17:23:16 2007 Could not create the Java virtual machine. $ java -Xshareclasses:name=RSE,printStats Current statistics for cache "RSE": base address = 0x0F300058 end address = 0x0F8FFFF8 allocation pointer = 0x0F4D2E28 cache size = 6291368 free bytes = 4355696 ROMClass bytes = 1912272 Metadata bytes = 23400 Metadata % used = 1% # ROMClasses = 475 # Classpaths = 4 # URLs = 0 # Tokens = 0 # Stale classes = 0 % Stale classes = 0% Cache is 30% full Could not create the Java virtual machine. $ java -Xshareclasses:name=RSE,destroy JVMSHRC010I Shared Cache "RSE" is destroyed Could not create the Java virtual machine.
Traditionell ist das Definieren von Ressourcen für CICS dem CICS-Administrator vorbehalten. Dass Anwendungsentwickler nur ungern mit dieser Aufgabe betraut werden, hat verschiedene Gründe:
Developer for System z unterstützt diesen Ansatz, denn CICS-Administratoren haben die Möglichkeit, die Standardwerte für CICS-Ressourcendefinitionen zu kontrollieren und die Anzeigemerkmale von CICS-Ressourcendefinitionsparametern mithilfe des CRD-Servers zu steuern, der Teil von Application Deployment Manager ist.
Der CICS-Administrator kann beispielsweise bestimmte Parameter für CICS-Ressourcendefinitionen bereitstellen, die nicht vom Anwendungsentwickler aktualisiert werden können. Andere Parameter für CICS-Ressourcendefinitionen können mit oder ohne Vorgabe von Standardwerten zur Aktualisierung freigegeben werden. Der CICS-Ressourcendefinitionsparameter kann auch ausgeblendet werden, um unnötige Komplexität zu vermeiden.
Sobald der Anwendungsentwickler mit den CICS-Ressourcendefinitionen zufrieden ist, können sie in der aktiven CICS-Testumgebung installiert werden. Sie können die Definitionen aber auch zur weiteren Bearbeitung und zur Genehmigung durch einen CICS-Administrator in ein Manifest exportieren. Der CICS-Administrator kann Änderungen an Ressourcendefinitionen mit dem Verwaltungsdienstprogramm (Batchdienstprogramm) oder dem Manifestverarbeitungstool implementieren.
Weitere Informationen zu den erforderlichen Schritten für die Konfiguration von Application Deployment Manager auf Ihrem Hostsystem enthält Application Deployment Manager (optional).
Durch die Anpassung von Application Deployment Manager werden die folgenden Services zu Developer for System z hinzugefügt:
Zum CRD-Server von Application Deployment Manager gehören der Server selbst, ein CRD-Repository, die zugehörigen CICS-Ressourcendefinitionen, Bindungsdateien für Web-Services (sofern die Web-Service-Schnittstelle verwendet wird) und ein Beispielhandler für Pipelinenachrichten. Der CRD-Server muss in einer Webverwaltungsregion (WOR, Web Owning Region) ausgeführt werden, die in der Dokumentation zu Developer for System z als 'primäre CICS-Verbindungsregion' bezeichnet wird.
Weitere Informationen zu den Application Deployment Manager-Services, die im aktuellen Release von Developer for System z enthalten sind, finden Sie im Information Center für Developer for System z: http://publib.ibm.com/infocenter/ratdevz/v7r6/index.jsp.
CICS Transaction Server stellt ab Version 4.1 Unterstützung für eine HTTP-Schnittstelle zur Verfügung, die mithilfe von RESTful-Prinzipien (Representational State Transfer) entworfen wurde. Diese RESTful-Schnittstelle ist jetzt die strategische CICSTS-Schnittstelle, die von Clientanwendungen verwendet wird. Die ältere Web-Service-Schnittstelle wurde eingefroren. Erweiterungen werden nur für die RESTful-Schnittstelle entwickelt.
Application Deployment Manager hält diese Absichtserklärung ein. Für alle Services, die ab Developer for System z Version 7.6 neu sind, ist der RESTful-CRD-Server erforderlich.
Falls gewünscht, können die RESTful- und Web-Service-Schnittstellen gleichzeitig in einer CICS-Region aktiv sein. In diesem Fall sind in der Region zwei CRD-Server aktiv. Beide Server verwenden gemeinsam dasselbe CRD-Repository. Beachten Sie, dass CICS einige Warnungen zu doppelten Definitionen ausgibt, wenn die zweite Schnittstelle in der Region definiert wird.
Eine CICS-Testumgebung kann aus mehreren MRO-Verbindungsregionen (Multi-Region Option) bestehen. Für diese Regionen haben sich im Laufe der Zeit inoffizielle Bezeichnungen eingeschlichen. So werden sie unter anderem als Terminalverwaltungsregion, Webverwaltungsregion, Anwendungsverwaltungsregion und Datenverwaltungsregion bezeichnet.
In einer Webverwaltungsregion wird die Unterstützung für CICS-Web-Services implementiert. In dieser Region muss der CRD-Server von Application Deployment Manager ausgeführt werden. Für Application Deployment Manager ist dies die primäre CICS-Verbindungsregion. Der CRD-Client implementiert eine Web-Service-Verbindung zur primären CICS-Verbindungsregion.
Nicht primäre CICS-Verbindungsregionen sind alle anderen Regionen, für die der CRD-Server Services bereitstellen kann. Zu diesen Services gehört die Anzeige von Ressourcen im IBM CICS-Explorer und das Definieren von Ressourcen mit dem Editor für CICS-Ressourcendefinitionen.
Wenn CICS-Ressourcendefinitionen der primären CICS-Verbindungsregion mit dem CICSPlex SM Business Application Services (BAS) verwaltet wird, kann der CRD-Server auch für alle anderen von den BAS verwalteten CICS-Regionen Services bereitstellen.
Nicht von den BAS verwaltete CICS-Regionen erfordern zusätzliche Änderungen, um Services vom CRD-Server nutzen zu können.
Aktionen, die der CRD-Server für die CICS-Ressourcen ausführt, werden in der CICS-CSDL-TD-Warteschlange protokolliert, die in der Regel auf DD MSGUSR in Ihrer CICS-Region zeigt.
Wenn Ihre CICS-Ressourcendefinitionen mit den CICSPlex SM Business Application Services (BAS) verwaltet werden, muss die EYUPARM-Anweisung BASLOGMSG von CICSPlex SM auf (YES) gesetzt sein, damit die Protokolle erstellt werden.
Die VSAM-Datei für das CRD-Server-Repository enthält alle Standardressourcendefinitionen und muss daher vor Aktualisierungen geschützt werden. Entwickler müssen jedoch die Möglichkeit haben, die hier gespeicherten Werte zu lesen. Beispiele für RACF-Befehle zum Schützen des CRD-Repositorys enthält der Abschnitt Dateiprofile definieren.
Wenn CICS eine SOAP-Nachricht empfängt, wird sie von einer Pipeline verarbeitet. Eine Pipeline ist eine Gruppe von Nachrichtenhandlern, die nacheinander ausgeführt werden. CICS liest die Pipelinekonfiguration, um festzustellen, welche Nachrichtenhandler in der Pipeline aufgerufen werden sollen. Ein Nachrichtenhandler ist ein Programm, in dem Web-Service-Anforderungen und -Antworten auf spezielle Weise verarbeitet werden können.
Application Deployment Manager stellt ein Beispiel für eine Pipelinekonfigurationsdatei bereit, das Aufrufe für einen Nachrichtenhandler und ein Verarbeitungsprogramm für den SOAP-Header enthält.
Der Pipelinenachrichtenhandler (ADNTMSGH) wird für die Sicherheit verwendet. Er verarbeitet die Benutzer-ID und das Kennwort im SOAP-Header. ADNTMSGH wird von der Beispielpipelinekonfigurationsdatei referenziert und muss deshalb in die CICS-RPL-Kette gestellt werden.
Eine von einer Pipeline aufgerufene Anwendung wird standardmäßig unter der Transaktions-ID CPIH ausgeführt. CPIH wird normalerweise gesetzt, wenn ein Mindestmaß an Berechtigungen erforderlich ist.
Developer for System z stellt mehrere Transaktionen bereit, die der CRD-Server beim Definieren und Abfragen von CICS-Ressourcen verwendet. Die Transaktions-IDs legt der CRD-Server je nach angeforderter Operation fest. Weitere Informationen zum Anpassen der Transaktions-IDs enthält Application Deployment Manager (optional).
Transaktion | Beschreibung |
---|---|
ADMS | Für Änderungen an CICS-Ressourcen, die vom Manifestverarbeitungstool angefordert werden. Diese Transaktion ist normalerweise für CICS-Administratoren bestimmt. Diese Transaktion erfordert eine hohe Berechtigungsstufe. |
ADMI | Für Anforderungen, die CICS-Ressourcen definieren, installieren oder deinstallieren. Diese Transaktion kann je nach Standortrichtlinien eine mittlere Berechtigungsstufe erfordern. |
ADMR | Für alle anderen Anforderungen, die CICS-Umgebungsinformationen oder -Ressourceninformationen abrufen. Diese Transaktion kann je nach Standortrichtlinien ein Mindestmaß an Berechtigungen erfordern. |
Einige oder alle der hier genannten Ressourcendefinitionsanforderungen der CRD-Servertransaktionen sollten geschützt werden. Sie sollten zumindest die Aktualisierungsbefehle schützen (Aktualisierung der Standard-Web-Service-Parameter, der Standarddeskriptorparameter und der Bindung zwischen Dateinamen), damit diese Befehle für das Definieren globaler Standardwerte für Ressourcen ausschließlich von CICS-Administratoren abgesetzt werden können.
Wenn die Transaktion zugeordnet wird, stellt die Sicherheitsprüfung für CICS-Ressourcen (sofern aktiviert) sicher, dass die Benutzer-ID berechtigt ist, die Transaktions-ID zu verwenden.
Die Ressourcenüberprüfung wird von der Option RESSEC der aktiven Transaktion, dem Systeminitialisierungsparameter RESSEC und - für den CRD-Server - vom Systeminitialisierungsparameter XPCT gesteuert.
Die Ressourcenüberprüfung findet nur statt, wenn der Systeminitialisierungsparameter XPCT einen anderen Wert als NO hat und die Option RESSEC der Transaktionsdefinition auf YES oder der Systeminitialisierungsparameter RESSEC auf ALWAYS gesetzt ist.
Die folgenden RACF-Befehle geben ein Beispiel für den Schutz von CRD-Servertransaktionen. Weitere Informationen zum Definieren der CICS-Sicherheit enthält der RACF Security Guide for CICSTS .
RALTER GCICSTRN SYSADM UACC(NONE) ADDMEM(ADMS)
PERMIT SYSADM CLASS(GCICSTRN) ID(#cicsadmin)
RALTER GCICSTRN DEVELOPER UACC(NONE) ADDMEM(ADMI)
PERMIT DEVELOPER CLASS(GCICSTRN) ID(#cicsdeveloper)
RALTER GCICSTRN ALLUSER UACC(READ) ADDMEM(ADMR)
SETROPTS RACLIST(TCICSTRN) REFRESH
Die SSL-Verschlüsselung des Datenstroms wird unterstützt, wenn der Application Deployment Manager-Client die Web-Service-Schnittstelle verwendet, um den CRD-Server aufzurufen. Die Verwendung von SSL für diese Kommunikation wird durch das Schlüsselwort SSL(YES) in der CICSTS-Definition TCPIPSERVICE gesteuert, wie in RACF Security Guide for CICSTS dokumentiert.
CICSTS stellt die Funktionalität zur Verfügung, Ressourcen und die Befehle für die Bearbeitung zu schützen. Bestimmte Application Deployment Manager-Aktionen (beispielsweise Berechtigungen zum Bearbeiten neuer Ressourcentypen erteilen) schlagen möglicherweise fehl, wenn die Sicherheit aktiv ist, aber nicht vollständig konfiguriert ist.
Prüfen Sie bei einem Funktionsfehler in Application Deployment Manager das CICS-Protokoll auf Nachrichten wie die folgende. Ergreifen Sie Maßnahmen zur Fehlerbehebung, die im RACF Security Guide for CICSTS dokumentiert sind.
DFHXS1111 %date %time %applid %tranid Security violation by user %userid at netname %portname for resource %resource in class %classname. SAF codes are (X'safresp',X'safreas'). ESM codes are (X'esmresp',X'esmreas').
Mit dem von Developer for System z bereitgestellten Verwaltungsdienstprogramm können CICS-Administratoren die Standardwerte für CICS-Ressourcendefinitionen vorgeben. Diese Standardwerte können schreibgeschützt oder für den Anwendungsentwickler editierbar sein.
Das Verwaltungsdienstprogramm stellt die folgenden Funktionen bereit:
Das Verwaltungsdienstprogramm wird vom Beispieljob ADNJSPAU in der Datei FEK.#CUST.JCL aufgerufen. Für die Verwendung dieses Dienstprogramms ist das Zugriffsrecht UPDATE für das CRD-Repository erforderlich.
ADNJSPAU ist in FEK.#CUST.JCL enthalten, sofern der z/OS-Systemprogrammierer während der Anpassung und Übergabe des Jobs FEK.SFEKSAMP(FEKSETUP) keine andere Position angegeben hat. Weitere Details hierzu enthält der Abschnitt Anpassungskonfiguration.
Das CRD-Repository für eine CICS-Testumgebung wird mit Eingabesteueranweisungen aktualisiert, für die die folgenden Syntaxregeln gelten:
Die folgenden Beispieldefinitionen folgen der Struktur der DFHCSDUP-Befehle, wie sie im CICS Resource Definition Guide for CICSTS definiert sind. Als einzige Abweichung wurden die folgenden Schlüsselwörter für die Anzeigeberechtigung eingefügt, um die Attributwerte in drei Berechtigungsgruppen zusammenzufassen:
UPDATE | Auf dieses Schlüsselwort folgende Attribute können von einem Anwendungsentwickler mit Developer for System z aktualisiert werden. Dieses Schlüsselwort wird standardmäßig für übergangene Attribute verwendet. |
PROTECT | Auf dieses Schlüsselwort folgende Attribute werden angezeigt, können jedoch nicht von einem Anwendungsentwickler mit Developer for System z aktualisiert werden. |
HIDDEN | Auf dieses Schlüsselwort folgende Attribute werden nicht angezeigt und können nicht von einem Anwendungsentwickler mit Developer for System z aktualisiert werden. |
Sehen Sie sich das folgende Codebeispiel für ADNJSPAU an.
//ADNJSPAU JOB <JOB-PARAMETER> //* //ADNSPAU EXEC PGM=ADNSPAU,REGION=1M //STEPLIB DD DISP=SHR,DSN=FEK.SFEKLOAD //ADMREP DD DISP=OLD,DSN=FEK.#CUST.ADNREPF0 //SYSPRINT DD SYSOUT=* //SYSIN DD * * * CICSPlex-SM-Parameter * DEFINE CPSMNAME( ) *DEFINE STAGINGGROUPNAME(ADMSTAGE) * * Manifestexportregel * DEFINE MANIFESTEXPORTRULE(installOnly) * * Standardwerte für CICS-Ressourcendefinitionen * Für übergangene Attribute wird standardmäßig UPDATE verwendet. * * Standardattribute für DB2TRAN * DEFINE DB2TRAN() UPDATE DESCRIPTION() ENTRY() TRANSID() * * Standardattribute für DOCTEMPLATE * DEFINE DOCTEMPLATE() UPDATE DESCRIPTION() TEMPLATENAME() FILE() TSQUEUE() TDQUEUE() PROGRAM() EXITPGM() DDNAME(DFHHTML) MEMBERNAME() HFSFILE() APPENDCRLF(YES) TYPE(EBCDIC) * * Standardattribute für FILE * DEFINE FILE() UPDATE DESCRIPTION() RECORDSIZE() KEYLENGTH() RECORDFORMAT(V) ADD(NO) BROWSE(NO) DELETE(NO) READ(YES) UPDATE(NO) REMOTESYSTEM() REMOTENAME() PROTECT DSNAME() RLSACCESS(NO) LSRPOOLID(1) STRINGS(1) STATUS(ENABLED) OPENTIME(FIRSTREF) DISPOSITION(SHARE) DATABUFFERS(2) INDEXBUFFERS(1) TABLE(NO) MAXNUMRECS(NOLIMIT) READINTEG(UNCOMMITTED) DSNSHARING(ALLREQS) UPDATEMODEL(LOCKING) LOAD(NO) JNLREAD(NONE) JOURNAL(NO) JNLSYNCREAD(NO) JNLUPDATE(NO) JNLADD(NONE) JNLSYNCWRITE(YES) RECOVERY(NONE) FWDRECOVLOG(NO) BACKUPTYPE(STATIC) PASSWORD() NSRGROUP() CFDTPOOL() TABLENAME()
* * Standardattribute für MAPSET * DEFINE MAPSET() UPDATE DESCRIPTION() PROTECT RESIDENT(NO) STATUS(ENABLED) USAGE(NORMAL) USELPACOPY(NO) ** Standardattribute für PROCESSTYPE * DEFINE PROCESSTYPE() UPDATE DESCRIPTION() FILE(BTS) PROTECT STATUS(ENABLED) AUDITLOG() AUDITLEVEL(OFF) * * Standardattribute für PROGRAM * DEFINE PROGRAM() UPDATE DESCRIPTION() CEDF(YES) LANGUAGE(LE370) REMOTESYSTEM() REMOTENAME() TRANSID() PROTECT API(CICSAPI) CONCURRENCY(QUASIRENT) DATALOCATION(ANY) DYNAMIC(NO) EXECKEY(USER) EXECUTIONSET(FULLAPI) RELOAD(NO) RESIDENT(NO) STATUS(ENABLED) USAGE(NORMAL) USELPACOPY(NO) HIDDEN JVM(NO) JVMCLASS() JVMPROFILE(DFHJVMPR) * * Standardattribute für TDQUEUE * DEFINE TDQUEUE() UPDATE DESCRIPTION() TYPE(INTRA) * Partitionsexterne Parameter DDNAME() DSNAME() REMOTENAME() REMOTESYSTEM() REMOTELENGTH(1) RECORDSIZE() BLOCKSIZE(0) RECORDFORMAT(UNDEFINED) BLOCKFORMAT() PRINTCONTROL() DISPOSITION(SHR) * Partitionsinterne Parameter FACILITYID() TRANSID() TRIGERRLEVEL(1) USERID() * Indirekte Parameter INDIRECTNAME() PROTECT WAIT(YES) WAITACTION(REJECT) * Partitionsexterne Parameter DATABUFFERS(1) SYSOUTCLASS() ERROROPTION(IGNORE) OPENTIME(INITIAL) REWIND(LEAVE) TYPEFILE(INPUT) * Partitionsinterne Parameter ATIFACILITY(TERMINAL) RECOVSTATUS(NO)
*
* Standardattribute für TRANSACTION
*
DEFINE TRANSACTION()
UPDATE DESCRIPTION()
PROGRAM()
TWASIZE(0)
REMOTESYSTEM() REMOTENAME() LOCALQ(NO)
PROTECT PARTITIONSET() PROFILE(DFHCICST)
DYNAMIC(NO) ROUTABLE(NO)
ISOLATE(YES) STATUS(ENABLED)
RUNAWAY(SYSTEM) STORAGECLEAR(NO)
SHUTDOWN(DISABLED)
TASKDATAKEY(USER) TASKDATALOC(ANY)
BREXIT() PRIORITY(1) TRANCLASS(DFHTCL00)
DTIMOUT(NO) RESTART(NO) SPURGE(NO) TPURGE(NO)
DUMP(YES) TRACE(YES) CONFDATA(NO)
OTSTIMEOUT(NO) WAIT(YES) WAITTIME(00,00,00)
ACTION(BACKOUT) INDOUBT(BACKOUT)
RESSEC(NO) CMDSEC(NO)
TRPROF()
ALIAS() TASKREQ()
XTRANID() TPNAME() XTPNAME()
*
* URDIMAP-Attribute
*
DEFINE URIMAP()
UPDATE USAGE(CLIENT)
DESCRIPTION()
PATH(/required/path)
TCPIPSERVICE()
TRANSACTION()
PROGRAM()
PROTECT ANALYZER(NOANALYZER)
ATOMSERVICE()
CERTIFICATE()
CHARACTERSET()
CIPHERS()
CONVERTER()
HFSFILE()
HOST(host.mycompany.com)
HOSTCODEPAGE()
LOCATION()
MEDIATYPE()
PIPELINE()
PORT(NO)
REDIRECTTYPE(NONE)
SCHEME(HTTP)
STATUS(ENABLED)
TEMPLATENAME()
USERID()
WEBSERVICE()
*
* Optionaler Dateiname für die Bindung von Dateinamen an VSAM-Dateinamen
*
*DEFINE DSBINDING() DSNAME()
/*
Die Unterstützung von UIRIMAP wurde dem Verwaltungsdienstprogramm in Developer for System z Version 7.6.1 hinzugefügt. Um die Unterstützung von URIMAP verwenden zu können, muss der VSAM-Datei des CRD-Repositorys eine maximale Satzgröße von 3000 zugeordnet werden. Bis zur Version 7.6.1 von Developer for System z verwendet der Zuordnungsjob des CRD-Beispielrepositorys eine maximale Satzgröße von 2000.
Wenn Sie ein älteres CRD-Repository verwenden, führen Sie die folgenden Schritte aus, um die Unterstützung von URIMAP zu aktivieren:
Das Verwaltungsdienstprogramm setzt die folgenden Nachrichten an die DD-Karte SYSPRINT ab. Die Nachrichten CRAZ1803E, CRAZ1891E, CRAZ1892E und CRAZ1893E enthalten Dateistatuscodes, VSAM-Rückkehrcodes, VSAM-Funktionscodes und VSAM-Rückkopplungscodes. Rückkehr-, Funktions- und Rückkopplungscodes für VSAM sind in der Veröffentlichung DFSMS Macro Instructions for Data Sets (IBM Form SC26-7408) dokumentiert. Dateistatuscodes sind in der Veröffentlichung Enterprise COBOL for z/OS Language Reference (IBM Form SC27-1408) dokumentiert.
Erläuterung: Das Verwaltungsdienstprogramm für Systemprogrammierer wurde erfolgreich beendet.
Benutzeraktion: Keine
Erläuterung: Das Verwaltungsdienstprogramm für Systemprogrammierer wurde mit Warnungen beendet, die während der Verarbeitung von Steueranweisungen festgestellt wurden.
Benutzeraktion: Überprüfen Sie die weiteren Warnungen.
Erläuterung: Das Verwaltungsdienstprogramm für Systemprogrammierer hat einen schwerwiegenden Fehler festgestellt.
Benutzeraktion: Überprüfen Sie die weiteren Warnungen.
Erläuterung: Das Verwaltungsdienstprogramm für Systemprogrammierer hat einen schwerwiegenden Fehler beim Öffnen des CRD-Repositorys festgestellt.
Benutzeraktion: Überprüfen Sie die VSAM-Statuscodes, -Rückkehr-, -Funktions- und -Rückkopplungscodes.
Erläuterung: Das Verwaltungsdienstprogramm für Systemprogrammierer hat eine nicht erkannte Eingabesteueranweisung gefunden.
Benutzeraktion: Überprüfen Sie, ob auf einen Befehl DEFINE ein Leerzeichen und dann das Schlüsselwort CPSMNAME, STAGINGGROUPNAME, MANIFESTEXPORTRULE, DSBINDING, DB2TRAN, DOCTEMPLATE, FILE, MAPSET, PROCESSTYPE, PROGRAM, TDQUEUE oder TRANSACTION folgt.
Erläuterung: Das Verwaltungsdienstprogramm für Systemprogrammierer verarbeitet die Eingabesteueranweisung (Schlüsselwort DEFINE).
Benutzeraktion: Keine
Erläuterung: Das Verwaltungsdienstprogramm für Systemprogrammierer hat eine ungültige Manifestexportregel gefunden.
Benutzeraktion: Überprüfen Sie, ob der Wert des Schlüsselworts MANIFESTEXPORTRULE 'installOnly', 'exportOnly' oder 'both' lautet.
Erläuterung: Das Verwaltungsdienstprogramm für Systemprogrammierer hat eine Steueranweisung DEFINE DSBINDING verarbeitet, bei der das Schlüsselwort DSNAME fehlt.
Benutzeraktion: Überprüfen Sie, ob die Steueranweisung DEFINE DSBINDING das Schlüsselwort DSNAME enthält.
Erläuterung: Das Verwaltungsdienstprogramm für Systemprogrammierer hat eine Steueranweisung DEFINE verarbeitet und für das benannte Schlüsselwort einen ungültigen Wert festgestellt.
Benutzeraktion: Überprüfen Sie, ob die Länge und der Wert des benannten Schlüsselworts korrekt ist.
Erläuterung: Das Verwaltungsdienstprogramm für Systemprogrammierer hat eine Steueranweisung DEFINE verarbeitet und für ein Schlüsselwort oder den Wert eines Schlüsselwortes einen Syntaxfehler festgestellt.
Benutzeraktion: Überprüfen Sie, ob der Wert des Schlüsselworts in runde Klammern eingeschlossen ist und unmittelbar auf das Schlüsselwort folgt. Das Schlüsselwort und der zugehörige Wert müssen sich in derselben Zeile befinden.
Erläuterung: Das Verwaltungsdienstprogramm für Systemprogrammierer hat beim Schreiben in das CRD-Repository einen doppelt vorhandenen Schlüssel gefunden. Dies ist ein Fehler.
Benutzeraktion: Überprüfen Sie die VSAM-Statuscodes, -Rückkehr-, -Funktions- und -Rückkopplungscodes.
Erläuterung: Das Verwaltungsdienstprogramm für Systemprogrammierer hat beim Schreiben in das CRD-Repository einen schwerwiegenden Fehler festgestellt.
Benutzeraktion: Überprüfen Sie die VSAM-Statuscodes, -Rückkehr-, -Funktions- und -Rückkopplungscodes.
Erläuterung: Das Verwaltungsdienstprogramm für Systemprogrammierer hat einen schwerwiegenden Fehler beim Lesen des CRD-Repositorys festgestellt.
Benutzeraktion: Überprüfen Sie die VSAM-Statuscodes, -Rückkehr-, -Funktions- und -Rückkopplungscodes.
Dieser Anhang soll Sie beim Imitieren einer TSO-Anmeldeprozedur durch das Hinzufügen von DD-Anweisungen und Dateien zur TSO-Umgebung in Developer for System z unterstützen.
TSO Commands Service ist die Komponente von Developer for System z, mit der TSO-Befehle und ISPF-Befehle (Batchbefehle) ausgeführt werden und die das Ergebnis an den anfordernden Client zurückgibt. Diese Befehle können implizit vom Produkt oder explizit vom Benutzer angefordert werden.
Die im Lieferumfang von Developer for System z enthaltenen Beispielmember erstellen eine minimale TSO/ISPF-Umgebung. Falls die Entwickler in Ihrem Unternehmen den Zugriff auf angepasste Bibliotheken oder auf Bibliotheken anderer Anbieter benötigen, muss der z/OS-Systemprogrammierer zur Umgebung von TSO Commands Service die erforderlichen DD-Anweisungen und Bibliotheken hinzufügen. Die zugrunde liegende Logik ist identisch mit der des TSO-Anmeldeverfahrens, auch wenn die Implementierung in Developer for System z eine andere ist.
Seit Version 7.1 bietet Developer for System z Optionen für den Zugriff auf TSO Commands Service an.
Bestimmen Sie anhand von rsed.envvars, welche Zugriffsmethode von Hosts ab Version 7.1 verwendet wird. Die Datei rsed.envvars befindet sich im Verzeichnis /etc/rdz, wenn bei der Konfiguration die Standardeinstellungen verwendet wurden.
Die Konfigurationsdatei ISPF.conf (standardmäßig im Verzeichnis /etc/rdz/) definiert die von Developer for System z verwendete TSO/ISPF-Umgebung. Es gibt nur eine aktive Konfigurationsdatei ISPF.conf, die alle Benutzer von Developer for System z verwenden.
Im Hauptabschnitt der Konfigurationsdatei sind die DD-Namen und die zugehörigen Dateiverkettungen definiert. Sehen Sie sich dazu das folgende Beispiel an:
sysproc=ISP.SISPCLIB,FEK.SFEKPROC ispmlib=ISP.SISPMENU isptlib=ISP.SISPTENU ispplib=ISP.SISPPENU ispslib=ISP.SISPSLIB ispllib=ISP.SISPLOAD myDD=HLQ1.LLQ1,HLQ2.LLQ2
Das TSO/ISPF-Client-Gateway erstellt standardmäßig ein temporäres ISPF-Profil für TSO Commands Service. Sie können das TSO/ISPF-Client-Gateway aber auch anweisen, die Kopie eines vorhandenen ISPF-Profils zu verwenden. Der Schlüssel dazu ist die Anweisung _RSE_CMDSERV_OPTS in rsed.envvars.
#_RSE_CMDSERV_OPTS="$_RSE_CMDSERV_OPTS&ISPPROF=&SYSUID..ISPPROF"
Entfernen Sie das Kommentarzeichen für die Anweisung (indem Sie das Nummernzeichen (#) vor der Anweisung entfernen) und geben Sie den vollständig qualifizierten Dateinamen des vorhandenen ISPF-Profils an, um diese Funktion zu nutzen.
Im Dateinamen können die folgenden Variablen verwendet werden:
Die Anwendung allocjob in ISPF.conf (die standardmäßig auf Kommentar gesetzt ist) zeigt auf eine Exec, mit der weitere Dateien nach Benutzer-ID angelegt werden können.
*allocjob = FEK.#CUST.CNTL(CRAISPRX)
Um diese Funktion zu nutzen, entfernen Sie das Kommentarzeichen für die Anweisung (indem Sie den Stern (*) vor der Anweisung entfernen) und geben Sie den vollständig qualifizierten Verweis auf die Zuordnungs-Exec an.
ISPF.conf unterstützt nur den Aufruf einer Zuordnungs-Exec. Für Aufrufe weiterer Execs von dieser Exec aus gibt es jedoch keine Begrenzung. Die Benutzer-ID des Clients, die als Parameter übergeben wird, ermöglicht den Aufruf personalisierter Zuordnungs-Execs. Sie können beispielsweise prüfen, ob das Member USERID'.EXEC(ALLOC)' vorhanden ist, und dieses ggf. ausführen.
Mit einer ausgeklügelten Variante dieses Members können Sie die vorhandenen TSO-Anmeldeverfahren wie folgt nutzen:
Falls die oben beschriebenen Szenarien mit Zuordnungs-Execs Ihren Anforderungen nicht genügen, können Sie andere Instanzen des RSE-Kommunikationsservers von Developer for System z mit jeweils einer eigenen ISPF.conf-Datei erstellen. Die folgende Methode hat im Wesentlichen den Nachteil, dass die Benutzer von Developer for System z eine Verbindung zu verschiedenen Servern auf demselben Host herstellen müssen, um die gewünschte TSO-Umgebung zu erhalten.
$ cd /etc/rdz $ mkdir /etc/rdz/tso2 $ cp rsed.envvars /etc/rdz/tso2 $ cp ISPF.conf /etc/rdz/tso2 $ ls /etc/rdz/tso2 ISPF.conf rsed.envvars $ oedit /etc/rdz/tso2/rsed.envvars -> ändern: _CMDSERV_CONF_HOME=/etc/rdz/tso2 -> Kommentarzeichen entfernen und ändern: -Ddaemon.log=/var/rdz/logs/tso2 -> am ENDE hinzufügen: # -- NEEDED TO FIND THE REMAINING CONFIGURATION FILES CFG_BASE=/etc/rdz CLASSPATH=.:$CFG_BASE:$CLASSPATH # -- $ oedit /etc/rdz/tso2/ISPF.conf -> ändern: nach Bedarf ändern
Mit den Befehlen im vorherigen Beispiel werden die Konfigurationsdateien für Developer for System z, die geändert werden müssen, in ein neu erstelltes Verzeichnis tso2 kopiert. Die Variable _CMDSERV_CONF_HOME in rsed.envvars muss aktualisiert werden, damit sie das neue Ausgangsverzeichnis in ISPF.conf definiert. Außerdem muss daemon.log aktualisiert werden, um eine neue Protokollposition zu definieren. (Die Position wird automatisch erstellt, wenn sie nicht vorhanden ist.) Mit der Aktualisierung von CLASSPATH wird sichergestellt, dass RSE die Konfigurationsdateien auffindet, die nicht nach tso2 kopiert wurden. Die Datei ISPF.conf selbst können Sie entsprechend Ihren Anforderungen aktualisieren. Beachten Sie, dass der ISPF-Arbeitsbereich (Variable _CMDSERV_WORK_HOME in rsed.envvars) von beiden Instanzen gemeinsam genutzt werden kann.
Jetzt müssen Sie nur noch eine neue gestartete Task für RSE erstellen, die eine neue Portnummer und die neuen Konfigurationsdateien in /etc/rdz/tso2 verwendet.
Weitere Informationen zu den oben gezeigten Aktionen finden Sie in den entsprechenden Abschnitten dieser Veröffentlichung.
Die Definition einer APPC-Transaktion besteht aus APPC-Parametern und Transaktions-JCL. Die Beispiel-JCL zur Erstellung einer APPC-Transaktion für Developer for System z, FEK.#CUST.JCL(FEKAPPCC), enthält zwei Optionen für das Definieren der Transaktions-JCL, mit und ohne ISPF-Unterstützung.
//SYSIN DD DDNAME=SYSINISP * verwenden Sie SYSINTSO oder SYSINISP
Der Client ruft die in der Transaktions-JCL definierte TSO/ISPF-Umgebung ab. Befolgen Sie daher die allgemeinen DD-Regeln, wenn Sie in diesem Abschnitt die Umgebung für den Client anpassen.
... //CMDSERV EXEC PGM=IKJEFT01,DYNAMNBR=50, // PARM='ISPSTART CMD(%FEKFRSRV TIMEOUT=60) NEWAPPL(ISR) NESTMACS' //SYSPROC DD DISP=SHR,DSN=FEK.SFEKPROC //ISPPLIB DD DISP=SHR,DSN=ISP.SISPPENU //ISPMLIB DD DISP=SHR,DSN=ISP.SISPMENU //ISPTLIB DD DISP=SHR,DSN=ISP.SISPTENU //ISPSLIB DD DISP=SHR,DSN=ISP.SISPSENU //ISPPROF DD DISP=(NEW,DELETE,DELETE),UNIT=SYSALLDA, // SPACE=(TRK,(1,1,5)),LRECL=80,RECFM=FB //SYSTSPRT DD SYSOUT=* //SYSPRINT DD SYSOUT=* //SYSTSIN DD DUMMY //MYDD DD DISP=SHR,DSN=HLQ1.LLQ1 // DISP=SHR,DSN=HLQ2.LLQ2
Wenn Sie die ISPF-Unterstützung ausgewählt haben, erstellt Developer for System z standardmäßig ein temporäres ISPF-Profil für TSO Commands Service. Sie können Developer for System z jedoch auch anweisen, die Kopie eines vorhandenen ISPF-Profils zu verwenden. Wie im Beispieljob FEK.SFEKSAMP(FEKAPPCC) beschrieben, müssen Sie folgende Schritte ausführen:
...
//COPY EXEC PGM=IEBCOPY * Klonen des vorhandenen ISPF-Profils (optional)
//SYSPRINT DD SYSOUT=*
//SYSUT1 DD DISP=SHR,DSN=&SYSUID..ISPROF//SYSUT2 DD DISP=(MOD,PASS),DSN=&&PROF,
// UNIT=SYSALLDA,
// LIKE=&SYSUID..ISPROF//*
//CMDSERV EXEC PGM=IKJEFT01,DYNAMNBR=50,
// PARM='ISPSTART CMD(%FEKFRSRV TIMEOUT=60) NEWAPPL(ISR) NESTMACS'
//*ISPPROF DD DISP=(NEW,DELETE,DELETE),UNIT=SYSALLDA,
//* SPACE=(TRK,(1,1,5)),LRECL=80,RECFM=FB
//ISPPROF DD DISP=(OLD,DELETE,DELETE),DSN=&&PROF
Die Beispieltransaktions-JCL ruft TSO Commands Service direkt auf, indem Sie den Namen des Service (FEKFRSRV) als Parameter an das Programm IKJEFT01 übergibt. Sie können diesen Schritt so ändern, dass eine andere Exec aufgerufen wird, die Zuordnungen ausgehend von der aktuellen Benutzer-ID vornimmt und dann TSO Commands Service aufruft.
Im Gegensatz zum TSO/ISPF-Client-Gateway als Zugriffsmethode können die im ISPF-Profil des Benutzers gespeicherten Variablen von dieser Exec genutzt werden, um die Anpassung der Umgebung zu unterstützen. Beachten Sie jedoch, dass Aktualisierungen des Profils am Ende der Sitzung verloren gehen, da Sie eine temporäre Kopie und nicht das eigentliche Profil verwenden.
Die Verwendung einer Zuordnungs-Exec in der APPC-Transaktion wird nicht unterstützt. Die obige Beschreibung wird auf "as-is"-Basis bereitgestellt.
Falls Sie mehrere eindeutige TSO-Umgebungen benötigen, können Sie verschiedene Instanzen des RSE-Kommunikationsservers von Developer for System z mit jeweils einer eigenen APPC-Transaktion erstellen. Die folgende Methode hat im Wesentlichen den Nachteil, dass die Benutzer von Developer for System z eine Verbindung zu verschiedenen Servern auf demselben Host herstellen müssen, um die gewünschte TSO-Umgebung zu erhalten.
$ cd /etc/rdz $ mkdir /etc/rdz/tso2 $ cp rsed.envvars /etc/rdz/tso2 $ ls /etc/rdz/tso2/ rsed.envvars $ oedit /etc/rdz/tso2/rsed.envvars -> Kommentarzeichen entfernen und ändern: _FEKFSCMD_TP_NAME_=FEKFTSO2 -> Kommentarzeichen entfernen und ändern: -Ddaemon.log=/var/rdz/logs/tso2 -> am ENDE hinzufügen: # -- NEEDED TO FIND THE REMAINING CONFIGURATION FILES CFG_BASE=/etc/rdz CLASSPATH=.:$CFG_BASE:$CLASSPATH # --
Die obigen Befehle erstellen ein neues Verzeichnis tso2 und kopieren die Konfigurationsdateien von Developer for System z, für die Änderungen erforderlich sind, an die neue Position. Die Variable _ FEKFSCMD_TP_NAME_ in rsed.envvars muss so aktualisiert werden, dass sie den Namen der neuen APPC-Transaktion definiert. Außerdem muss daemon.log aktualisiert werden, um eine neue Protokollposition für den Dämon zu definieren. (Die Position wird automatisch erstellt, wenn sie noch nicht vorhanden ist.) Mit der Aktualisierung von CLASSPATH wird sichergestellt, dass RSE die Konfigurationsdateien auffindet, die nicht nach tso2 kopiert wurden.
//FEKAPPCC JOB CLASS=A,MSGCLASS=A,MSGLEVEL=(1,1),NOTIFY=&SYSUID//* //TPADD EXEC PGM=ATBSDFMU //SYSSDLIB DD DISP=SHR,DSN=SYS1.APPCTP //SYSSDOUT DD SYSOUT=* //SYSPRINT DD SYSOUT=* //SYSIN DD DDNAME=SYSINISP * verwenden Sie SYSINTSO oder SYSINISP //SYSINISP DD DATA,DLM='QT' TPADD TPNAME(FEKFTSO2) ACTIVE(YES) TPSCHED_DELIMITER(DLM1) KEEP_MESSAGE_LOG(ERROR) MESSAGE_DATA_SET(&SYSUID..FEKFTSO2.&TPDATE..&TPTIME..LOG) DATASET_STATUS(MOD) CLASS(A) JCL_DELIMITER(DLM2) //FEKFTSO2 JOB CLASS=A,MSGCLASS=A,MSGLEVEL=(1,1) //* //CMDSERV EXEC PGM=IKJEFT01,DYNAMNBR=50, // PARM='ISPSTART CMD(%FEKFRSRV TIMEOUT=60) NEWAPPL(ISR) NESTMACS' //SYSPROC DD DISP=SHR,DSN=FEK.SFEKPROC //ISPPLIB DD DISP=SHR,DSN=ISP.SISPPENU //ISPMLIB DD DISP=SHR,DSN=ISP.SISPMENU //ISPTLIB DD DISP=SHR,DSN=ISP.SISPTENU //ISPSLIB DD DISP=SHR,DSN=ISP.SISPSENU //ISPPROF DD DISP=(NEW,DELETE,DELETE),UNIT=SYSALLDA, // SPACE=(TRK,(1,1,5)),LRECL=80,RECFM=FB //SYSTSPRT DD SYSOUT=* //SYSPRINT DD SYSOUT=* //SYSTSIN DD DUMMY //MYDD DD DISP=SHR,DSN=HLQ1.LLQ1 // DISP=SHR,DSN=HLQ2.LLQ2 DLM2 DLM1 QT
Erstellen Sie als Nächstes eine neue APPC-Transaktion, indem Sie den Beispieljob FEK.#CUST.JCL(FEKAPPCC) anpassen und übergeben, wie im obigen Beispiel gezeigt wird. Zusätzlich zur normalen Anpassung (die in der JCL beschrieben ist) müssen Sie TPNAME in TPNAME(FEKFTSO2) ändern, um eine Übereinstimmung mit der Definition von _FEKFSCMD_TP_NAME_ in der neuen rsed.envvars zu erzielen. Sie sollten außerdem den Namen in der Variablen MESSAGE_DATA_SET und den JOB-Namen der Transaktions-JCL ändern.
Jetzt müssen Sie nur noch eine neue gestartete Task für RSE erstellen, die eine neue Portnummer und die neuen Konfigurationsdateien in /etc/rdz/tso2 verwendet.
Weitere Informationen zu den oben gezeigten Aktionen finden Sie in den entsprechenden Abschnitten dieser Veröffentlichung.
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 Anhang können Sie die Koexistenz verschiedener Instanzen von Developer for System z planen, um sie dann gestützt auf dieses Konfigurationshandbuch anzupassen.
Die gemeinsame Nutzung bestimmter Komponenten von Developer for System z durch zwei (oder mehr) Instanzen ist zwar möglich, wird jedoch NUR empfohlen, wenn die Softwareversionen identisch sind und es außer Änderungen an Konfigurationsmembern keine weiteren Änderungen gibt. Developer for System z bietet genug Anpassungsspielraum für die Erstellung mehrerer Instanzen ohne Überschneidung. Wir raten Ihnen dringend, diese Anpassungsfeatures zu nutzen.
Weitere Informationen zu den folgenden Beispielbefehlen für die Archivierung und Wiederherstellung des Installationsverzeichnisses von Developer for System z enthält die Veröffentlichung UNIX System Services Command Reference (IBM Form SA22-7802).
Konfigurationsdateien (und Code) für System z können auf verschiedenen Systemen in einem Sysplex gemeinsam genutzt werden. Jedes System führt dabei eine eigene identische Kopie von Developer for System z aus, wenn einige Richtlinien eingehalten werden.
Unter ganz bestimmten Umständen können Sie (fast) alle anpassbaren Komponenten gemeinsam nutzen. Eines der Beispiele ermöglicht für die Nutzung vor Ort den Zugriff ohne SSL und für die Nutzung an einem anderen Standort die mit SSL verschlüsselte Kommunikation.
Achtung: Mit der gemeinsam genutzten Konfiguration ist es NICHT möglich, ein Wartungsrelease, eine technische Vorschau oder ein neues Release sicher zu testen. |
Wenn Sie eine andere Instanz einer aktiven Installation von Developer for System z konfigurieren möchten, führen Sie erneut die Anpassungsschritte für die Komponenten aus, die unterschiedlich sind. Verwenden Sie dazu verschiedene Dateien, Verzeichnisse und Ports, um Überschneidungen mit der aktuellen Konfiguration zu vermeiden.
In dem oben erwähnten SSL-Beispiel kann die aktuelle RSE-Dämonkonfiguration geklont werden. Im Anschluss daran können Sie die geklonte Konfiguration aktualisieren. Als Nächstes können Sie die JCL für den RSE-Dämonstart klonen und dann durch Angabe eines neuen TCP/IP-Ports und der Position der aktualisierten Konfigurationsdateien anpassen. Die MVS-Anpassungen (JES Job Monitor usw.) können von SSL-Instanzen und Nicht-SSL-Instanzen gemeinsam genutzt werden. Dies würde die folgenden Aktionen erforderlich machen:
$ cd /etc/rdz $ mkdir /etc/rdz/ssl $ cp rsed.envvars /etc/rdz/ssl $ cp ssl.properties /etc/rdz/ssl $ ls /etc/rdz/ssl/ rsed.envvars ssl.properties $ oedit /etc/rdz/ssl/rsed.envvars -> Kommentarzeichen entfernen und ändern: -Ddaemon.log=/var/rdz/logs/ssl -> am ENDE hinzufügen: # -- NEEDED TO FIND THE REMAINING CONFIGURATION FILES CFG_BASE=/etc/rdz CLASSPATH=.:$CFG_BASE:$CLASSPATH # -- $ oedit /etc/rdz/ssl/ssl.properties -> ändern: nach Bedarf ändern
Mit den vorangegangenen Befehlen werden die Konfigurationsdateien für Developer for System z, die geändert werden müssen, in ein neu erstelltes Verzeichnis ssl kopiert. Die Variable daemon.log in rsed.envvars muss aktualisiert werden, um eine neue Protokollposition zu definieren. (Die Position wird automatisch erstellt, wenn sie noch nicht vorhanden ist.) Die Aktualisierung für CLASSPATH stellt sicher, dass RSE die Konfigurationsdateien finden kann, die nicht nach ssl kopiert wurden. Die Datei ssl.properties selbst können Sie entsprechend Ihren Anforderungen aktualisieren.
Jetzt müssen Sie nur noch eine neue gestartete Task für RSE erstellen, die eine neue Portnummer und die neuen Konfigurationsdateien in /etc/rdz/ssl verwendet.
Weitere Informationen zu den oben gezeigten Aktionen finden Sie in den entsprechenden Abschnitten dieser Veröffentlichung.
Wenn Codeänderungen vorgenommen werden müssen (Wartungsrelease, technische Neuentwicklungen, neues Release) oder Ihre Änderungen ziemlich komplex sind, sollten Sie Developer for System z neu installieren. In diesem Abschnitt sind mögliche Konfliktpunkte zwischen den verschiedenen Installationen beschrieben.
Die folgende Liste gibt Ihnen einen kurzen Überblick über die Elemente, die bei den Instanzen von Developer for System z unbedingt verschieden sein sollten oder müssen:
Die einzelnen Elemente sind in der folgenden Übersicht detaillierter beschrieben.
//SYSIN DD * CREATE PROCEDURE SYSPROC.ELAXMRXX ( IN FUNCTION_REQUEST VARCHAR(20) CCSID EBCDIC ... , OUT RETURN_VALUE VARCHAR(255) CCSID EBCDIC ) PARAMETER STYLE GENERAL RESULT SETS 1 LANGUAGE REXX EXTERNAL NAME ELAXMRXX COLLID DSNREXCS WLM ENVIRONMENT ELAXMWDZ PROGRAM TYPE MAIN MODIFIES SQL DATA STAY RESIDENT NO COMMIT ON RETURN NO ASUTIME NO LIMIT SECURITY USER; COMMENT ON PROCEDURE SYSPROC.ELAXMRXX IS 'PLI & COBOL PROCEDURE PROCESSOR (ELAXMRXX), INTERFACE LEVEL 0.01'; GRANT EXECUTE ON PROCEDURE SYSPROC.ELAXMRXX TO PUBLIC; //
Dieser Abschnitt hebt die Installations- und Konfigurationsänderungen im Vergleich zu früheren Produktreleases hervor. Darüber hinaus finden Sie hier allgemeine Richtlinien für die Migration auf dieses Release. Weitere Informationen hierzu finden Sie in den entsprechenden Abschnitten dieses Handbuchs.
Wenn Sie mit einer früheren Version von Developer for System z arbeiten, sollten Sie die zugehörigen Anpassungsdateien speichern, bevor Sie die aktuelle Version von IBM Developer for System z installieren.
Anpassungsfähige Dateien von Developer for System z finden Sie an den folgenden Positionen:
Ältere Konfigurationen von Developer for System z dokumentieren ebenfalls Änderungen der Konfigurationsdateien anderer Produkte.
Definieren Sie eine APPC-Transaktionsklasse für TSO Commands Service.
Legen Sie z/OS UNIX-Systemstandardwerte fest.
Starten Sie die Server während des IPL.
Fügen Sie FEK.SFEKLPA zum LPA hinzu.
Berechtigen Sie FEK.SFEKAUTH für APF.
Fügen Sie FEK.SFEKAUTH und FEK.SFEKLOAD der LINKLIST hinzu.
Definieren Sie eine APPC-Transaktion für TSO Commands Service.
Ordnen Sie das APPC-Transaktionsprogramm einer TSO-Leistungsgruppe zu.
Ordnen Sie eine Anwendungsumgebung für eine gespeicherte DB2-Prozedur zu.
Definieren Sie eine APPC-Transaktionsklasse für TSO Commands Service.
Legen Sie z/OS UNIX-Systemstandardwerte fest.
Berechtigen Sie FEK.SFEKLOAD für APF.
Definieren Sie den RSE-Dämonport.
Definieren Sie den RSE-Dämonservice.
Definieren Sie die Position für den TSO Commands-Server.
Definieren Sie eine APPC-Transaktion für TSO Commands Service.
Ordnen Sie das APPC-Transaktionsprogramm einer TSO-Leistungsgruppe zu.
Ordnen Sie eine Anwendungsumgebung für eine gespeicherte DB2-Prozedur zu.
Definieren Sie eine APPC-Transaktionsklasse für TSO Commands Service.
Legen Sie z/OS UNIX-Systemstandardwerte fest.
Berechtigen Sie FEK.SFEKLOAD für APF.
Definieren Sie den RSE-Dämonport.
Definieren Sie den RSE-Dämonservice.
Definieren Sie eine APPC-Transaktion für TSO Commands Service.
Ordnen Sie das APPC-Transaktionsprogramm einer TSO-Leistungsgruppe zu.
Ordnen Sie eine Anwendungsumgebung für eine gespeicherte DB2-Prozedur zu.
Die folgenden Migrationshinweise sind spezifisch für Version 7.6.1. Sie gelten für eine Migration von Version 7.6 oder als Zusätze zu den vorhandenen Migrationshinweisen für Version 7.6.
Tabelle 47 gibt einen Überblick über Dateien, die in Version 7.6 angepasst werden. Die Beispielbibliotheken von Developer for System z, FEK.SFEKSAMP, FEK.SFEKSAMV und /usr/lpp/rdz/samples/, enthalten mehr als die hier aufgelisteten anpassbaren Member. Sie enthalten z. B. auch CARMA-Beispielquellcode und Jobs für die Kompilierung.
Member/Datei | Standardposition | Zweck | Migrationshinweise |
---|---|---|---|
FEKSETUP |
FEK.SFEKSAMP [FEK.#CUST.JCL] |
JCL für die Erstellung von Dateien und Verzeichnissen und zum Füllen derselben mit anpassbaren Dateien | Aktualisiert zum Einschließen neuer anpassbarer Member |
JMON |
FEK.SFEKSAMP(FEJJJCL) [FEK.#CUST.PROCLIB] |
JCL für JES Job Monitor | Hinzugefügte Option zum Ändern der LE-Optionen |
FEJJJCL |
FEK.SFEKSAMP [FEK.#CUST.PROCLIB(JMON)] |
Name des JMON-Members bei Lieferung | Siehe JMON-Member |
RSED |
FEK.SFEKSAMP(FEKRSED) [FEK.#CUST.PROCLIB] |
JCL für den RSE-Dämon | Keine |
FEKRSED |
FEK.SFEKSAMP [FEK.#CUST.PROCLIB(RSED)] |
Name des RSED-Members bei Lieferung | Siehe RSED-Member |
LOCKD |
FEK.SFEKSAMP(FEKLOCKD) [FEK.#CUST.PROCLIB] |
JCL für Sperrdämon | NEU, Anpassung erforderlich |
FEKLOCKD |
FEK.SFEKSAMP [FEK.#CUST.PROCLIB(LOCKD)] |
Name des LOCKD-Members bei Lieferung | Siehe LOCKD-Member |
ELAXF* |
FEK.SFEKSAMP [FEK.#CUST.PROCLIB] |
JCL für ferne Projektbuilds usw. | Keine |
FEKRACF |
FEK.SFEKSAMP [FEK.#CUST.JCL] |
JCL für Sicherheitsdefinitionen | Kleinere Aktualisierungen |
FEJJCNFG |
FEK.SFEKSAMP [FEK.#CUST.PARMLIB] |
Konfigurationsdatei für JES Job Monitor | Neue optionale Anweisungen sind hinzugekommen. |
FEJTSO |
FEK.SFEKSAMP [FEK.#CUST.CNTL] |
JCL für TSO-Übergabe | Keine |
CRA$VMSG |
FEK.SFEKSAMP [FEK.#CUST.JCL] |
JCL zur Erstellung der VSAM für CARMA-Nachrichten | Keine |
CRA$VDEF |
FEK.SFEKSAMP [FEK.#CUST.JCL] |
JCL zur Erstellung der VSAM für CARMA-Konfiguration | Keine |
CRA$VSTR |
FEK.SFEKSAMP [FEK.#CUST.JCL] |
JCL zur Erstellung der VSAM für angepasste CARMA-Informationen | Keine |
CRASUBMT |
FEK.SFEKSAMP [FEK.#CUST.CNTL] |
CLIST für CARMA-Batchstart | Keine |
CRASUBCA |
FEK.SFEKSAMP [FEK.#CUST.CNTL] |
CLIST für CARMA-Batchstart für den CA Endevor® SCM-RAM | NEU, Anpassung optional |
CRASHOW |
FEK.SFEKSAMP [FEK.#CUST.PARMLIB] |
CARMA-Konfiguration für den CA Endevor® SCM-RAM | NEU, Anpassung optional |
CRATMAP |
FEK.SFEKSAMP [FEK.#CUST.PARMLIB] |
CARMA-Konfiguration für den CA Endevor® SCM-RAM | NEU, Anpassung optional |
CRANDVRA | FEK.SFEKPROC | CARMA-Zuordnungs-REXX für den CA Endevor® SCM-RAM | NEU, Anpassung optional |
CRAISPRX |
FEK.SFEKSAMP [FEK.#CUST.CNTL] |
DD-Beispielzuordnungs-Exec für CARMA bei Verwendung des TSO/ISPF-Client-Gateways | Keine |
CRA#VSLM |
FEK.SFEKSAMP [FEK.#CUST.JCL] |
JCL zur Erstellung der VSAM für SCLM-RAM-Nachrichten | Keine |
CRA#ASLM |
FEK.SFEKSAMP [FEK.#CUST.JCL] |
JCL zur Erstellung der SCLM-RAM-Dateien | Keine |
CRA#VPDS |
FEK.SFEKSAMP [FEK.#CUST.JCL] |
JCL zur Erstellung der VSAM für PDS-RAM-Nachrichten | Keine |
CRA#CRAM |
FEK.SFEKSAMP [FEK.#CUST.JCL] |
JCL zur Kompilierung des Skeleton-RAM | Keine |
CRA#VCAD |
FEK.SFEKSAMP [FEK.#CUST.JCL] |
JCL zur Erstellung der CARMA-Konfigurationsdatei (VSAM) für den CA Endevor® SCM-RAM | NEU, Anpassung optional |
CRA#VCAS |
FEK.SFEKSAMP [FEK.#CUST.JCL] |
JCL zur Erstellung der VSAM-Datei für angepasste CARMA-Informationen für den CA Endevor® SCM-RAM | NEU, Anpassung optional |
CRA#UADD |
FEK.SFEKSAMP [FEK.#CUST.JCL] |
JCL zum Zusammenführen von RAM-Definitionen | NEU, Anpassung optional |
CRA#UQRY |
FEK.SFEKSAMP [FEK.#CUST.JCL] |
JCL zum Extrahieren von RAM-Definitionen | NEU, Anpassung optional |
CRAXJCL |
FEK.SFEKSAMP [FEK.#CUST.ASM] |
Beispielquellcode für die Ersetzung von IRXJCL | Keine |
CRA#CIRX |
FEK.SFEKSAMP [FEK.#CUST.JCL] |
JCL zur Kompilierung von CRAXJCL | Keine |
ADNCSDRS |
FEK.SFEKSAMP [FEK.#CUST.JCL] |
JCL zum Definieren des RESTful-CRD-Servers für die primäre CICS-Region | NEU, Anpassung optional |
ADNCSDTX |
FEK.SFEKSAMP [FEK.#CUST.JCL] |
JCL zum Definieren von alternativen Transaktions-IDs für die primäre CICS-Region | NEU, Anpassung optional |
ADNTXNC |
FEK.SFEKSAMP [FEK.#CUST.JCL] |
JCL zum Erstellen von alternativen Transaktions-IDs | NEU, Anpassung optional |
ADNMSGHC |
FEK.SFEKSAMP [FEK.#CUST.JCL] |
JCL zur Kompilierung von ADNMSGHS | Umbenannt, hieß ADNCMSGH |
ADNMSGHS |
FEK.SFEKSAMP [FEK.#CUST.COBOL] |
Beispielquellcode für den Pipelinenachrichtenhandler | Umbenannt, hieß ADNSMSGH |
ADNVCRD |
FEK.SFEKSAMP [FEK.#CUST.JCL] |
JCL zur Erstellung des CRD-Repositorys | Umbenannt, hieß ADNVSAM |
ADNCSDWS |
FEK.SFEKSAMP [FEK.#CUST.JCL] |
JCL zum Definieren des Web-Service-CRD-Servers für die primäre CICS-Region | Umbenannt, hieß ADNPCCSD |
ADNCSDAR |
FEK.SFEKSAMP [FEK.#CUST.JCL] |
JCL zum Definieren des CRD-Servers für nicht primäre CICS-Regionen | Umbenannt, hieß ADNARCSD |
ADNJSPAU |
FEK.SFEKSAMP [FEK.#CUST.JCL] |
JCL zur Aktualisierung der CRD-Standardwerte | Für den RESTful-Service wurden Definitionen hinzugefügt. Dies erfordert eine neue Anpassung. |
ADNVMFST |
FEK.SFEKSAMP [FEK.#CUST.JCL] |
JCL zur Erstellung und zum Definieren des Manifestrepositorys | Umbenannt, hieß ADNMFEST |
ELAXMSAM |
FEK.SFEKSAMP [FEK.#CUST.PROCLIB] |
JCL-Prozedur des WLM-Adressraums für den Stored Procedure Builder für PL/I und COBOL | Keine |
ELAXMJCL |
FEK.SFEKSAMP [FEK.#CUST.JCL] |
JCL zum Definieren des Stored Procedure Builder für COBOL und PL/I für DB2 | Keine |
FEKAPPCC |
FEK.SFEKSAMP [FEK.#CUST.JCL] |
JCL zum Erstellen einer APPC-Transaktion | Keine |
FEKAPPCL |
FEK.SFEKSAMP [FEK.#CUST.JCL] |
JCL zum Anzeigen einer APPC-Transaktion | Keine |
FEKAPPCX |
FEK.SFEKSAMP [FEK.#CUST.JCL] |
JCL zum Löschen einer APPC-Transaktion | Keine |
FEKLOGS |
FEK.SFEKSAMP [FEK.#CUST.JCL] |
JCL zum Erfassen von Protokolldateien | NEU, Anpassung optional |
rsed.envvars |
/usr/lpp/rdz/samples/ [/etc/rdz/] |
RSE-Umgebungsvariablen | Ältere Kopien müssen durch diese ersetzt werden. (Anschließend müssen die Anpassungen erneut vorgenommen werden.) |
ISPF.conf |
/usr/lpp/rdz/samples/ [/etc/rdz/] |
TSO/ISPF-Client-Gateway, Konfigurationsdatei | ISP.SISPCLIB wurde SYSPROC für SCLMDT hinzugefügt. |
CRASRV.properties |
/usr/lpp/rdz/samples/ [/etc/rdz/] |
CARMA-Konfigurationsdatei | Keine |
crastart.conf |
/usr/lpp/rdz/samples/ [/etc/rdz/] |
CARMA-Konfigurationsdatei für die Verwendung von CRASTART | Keine |
crastart.endevor.conf |
/usr/lpp/rdz/samples/ [/etc/rdz/] |
CARMA-Konfigurationsdatei für die Verwendung von CRASTART für den CA Endevor® SCM-RAM | NEU, Anpassung optional |
ssl.properties |
/usr/lpp/rdz/samples/ [/etc/rdz/] |
RSE-SSL-Konfigurationsdatei | Neue optionale Anweisungen sind hinzugekommen. |
rsecomm.properties |
/usr/lpp/rdz/samples/ [/etc/rdz/] |
RSE-Tracekonfigurationsdatei | Keine |
propertiescfg.properties |
/usr/lpp/rdz/samples/ [/etc/rdz/] |
Konfigurationsdatei für hostbasierte Eigenschaftsgruppen | Keine |
projectcfg.properties |
/usr/lpp/rdz/samples/ [/etc/rdz/] |
Konfigurationsdatei für hostbasierte Projekte | Keine |
FMIEXT.properties |
/usr/lpp/rdz/samples/ [/etc/rdz/] |
Konfigurationsdatei für File Manager-Integration | Ältere Kopien müssen durch diese ersetzt werden. (Anschließend müssen die Anpassungen erneut vorgenommen werden.) |
uchars.settings |
/usr/lpp/rdz/samples/ [/etc/rdz/] |
Konfigurationsdatei für nicht editierbare Zeichen | Keine |
Tabelle 48 gibt einen Überblick über Dateien, die in Version 7.5 angepasst werden. Die Beispielbibliotheken von Developer for System z, FEK.SFEKSAMP, FEK.SFEKSAMV und /usr/lpp/rdz/samples/, enthalten mehr als die hier aufgelisteten anpassbaren Member. Sie enthalten z. B. auch CARMA-Beispielquellcode und Jobs für die Kompilierung.
Member/Datei | Standardposition | Zweck | Migrationshinweise |
---|---|---|---|
FEKSETUP | FEK.SFEKSAMP
[FEK.#CUST.JCL] |
JCL für die Erstellung von Dateien und Verzeichnissen und zum Füllen derselben mit anpassbaren Dateien | NEU, Anpassung erforderlich |
JMON | FEK.SFEKSAMP(FEJJJCL)
[FEK.#CUST.PROCLIB] |
JCL für JES Job Monitor | STEPLIB in SFEKAUTH geändert |
RSED | FEK.SFEKSAMP(FEKRSED)
[FEK.#CUST.PROCLIB] |
JCL für den RSE-Dämon | NEU, Anpassung erforderlich |
ELAXF* | FEK.SFEKSAMP
[FEK.#CUST.PROCLIB] |
JCL für ferne Projektbuilds usw. | ELAXFTSO, ELAXFCP1 und ELAXFPP1 sind neu. |
FEKRACF | FEK.SFEKSAMP
[FEK.#CUST.JCL] |
JCL für Sicherheitsdefinitionen | NEU, erforderlich |
FEJJCNFG | FEK.SFEKSAMP
[FEK.#CUST.PARMLIB] |
Konfigurationsdatei für JES Job Monitor |
|
FEJTSO | FEK.SFEKSAMP
[FEK.#CUST.CNTL] |
JCL für TSO-Übergabe | Der Jobname kann jetzt eine Variable sein. |
CRAISPRX | FEK.SFEKSAMP
[FEK.#CUST.CNTL] |
DD-Beispielzuordnungs-Exec für CARMA bei Verwendung des TSO/ISPF-Client-Gateways | NEU, Anpassung optional |
CRAXJCL | FEK.SFEKSAMP
[FEK.#CUST.ASM] |
Beispielquellcode für die Ersetzung von IRXJCL | NEU, Anpassung optional |
CRA#CIRX | FEK.SFEKSAMP
[FEK.#CUST.JCL] |
JCL zur Kompilierung von CRAXJCL | NEU, Anpassung optional |
ADNSMSGH | FEK.SFEKSAMP
[FEK.#CUST.COBOL] |
Beispielquellcode für den Pipelinenachrichtenhandler | Ältere Kopien müssen durch diese ersetzt werden. (Anschließend müssen die Anpassungen erneut vorgenommen werden.) |
ADNPCCSD | FEK.SFEKSAMP
[FEK.#CUST.JCL] |
JCL zum Definieren des CRD-Servers für die primäre CICS-Region | Ältere Kopien müssen durch diese ersetzt werden. (Anschließend müssen die Anpassungen erneut vorgenommen werden.) |
ADNJSPAU | FEK.SFEKSAMP
[FEK.#CUST.JCL] |
JCL zur Aktualisierung der CRD-Standardwerte | NEU, Anpassung optional |
ADNMFEST | FEK.SFEKSAMP
[FEK.#CUST.JCL] |
JCL zur Erstellung und zum Definieren des Manifestrepositorys | NEU, Anpassung optional |
rsed.envvars | /usr/lpp/rdz/samples/
[/etc/rdz/] |
RSE-Umgebungsvariablen | Ältere Kopien müssen durch diese ersetzt werden. (Anschließend müssen die Anpassungen erneut vorgenommen werden.) |
ISPF.conf | /usr/lpp/rdz/samples/
[/etc/rdz/] |
TSO/ISPF-Client-Gateway, Konfigurationsdatei | Identisch mit der Datei ISPF.conf in SCLMDT Version 7.1 |
CRASRV.properties | /usr/lpp/rdz/samples/
[/etc/rdz/] |
CARMA-Konfigurationsdatei |
|
crastart.conf | /usr/lpp/rdz/samples/
[/etc/rdz/] |
CARMA-Konfigurationsdatei für die Verwendung von CRASTART | NEU, Anpassung optional |
FMIEXT.properties | /usr/lpp/rdz/samples/
[/etc/rdz/] |
Konfigurationsdatei für File Manager-Integration |
|
uchars.settings | /usr/lpp/rdz/samples/
[/etc/rdz/] |
Konfigurationsdatei für nicht editierbare Zeichen | NEU, Anpassung optional |
Tabelle 23 gibt einen Überblick über Dateien, die in Version 7.1 angepasst werden. Die Beispielbibliotheken von CARMA und Developer for System z, CRA.SCRASAMP, FEK.SFEKSAMP und /usr/lpp/wd4z/rse/lib/, enthalten mehr als die hier aufgelisteten anpassbaren Member. Sie enthalten z. B. auch CARMA-Beispielquellcode und Jobs für die Kompilierung.
Member/Datei | Standardposition | Zweck | Migrationshinweise |
---|---|---|---|
ELAXF* | FEK.SFEKSAMP | JCL für ferne Projektbuilds und sonstige Jobs | ELAXFADT ist neu. |
CRA$VMSG | CRA.SCRASAMP | JCL zur Erstellung der VSAM für CARMA-Nachrichten |
|
CRA$VDEF | CRA.SCRASAMP | JCL zur Erstellung der VSAM für CARMA-Konfiguration |
|
CRA$VSTR | CRA.SCRASAMP | JCL zur Erstellung der VSAM für angepasste CARMA-Informationen | Umbenannt, hieß CRASREPR |
CRASUBMT | CRA.SCRASAMP | CLIST für CARMA-Batchstart | DD-Anweisung CARMALOG hinzufügen |
CRA#VSLM | CRA.SCRASAMP | JCL zur Erstellung der VSAM für SCLM-RAM-Nachrichten | Umbenannt, hieß CRALREPR |
CRA#ASLM | CRA.SCRASAMP | JCL zur Erstellung der SCLM-RAM-Dateien | Umbenannt, hieß CRASALX |
CRA#VPDS | CRA.SCRASAMP | JCL zur Erstellung der VSAM für PDS-RAM-Nachrichten | Umbenannt, hieß CRATREPR |
CRA#CRAM | CRA.SCRASAMP | JCL zur Kompilierung des Skeleton-RAM | Umbenannt, hieß CRARAMCM |
FEKAPPCC | FEK.SFEKSAMP | JCL zum Erstellen einer APPC-Transaktion | Unterstützung von NEST in ISPF nutzen |
rsed.envvars |
/usr/lpp/wd4z/rse/lib/ [/etc/wd4z/] |
RSE-Umgebungsvariablen | Ältere Kopien müssen durch diese ersetzt werden. (Anschließend müssen die Anpassungen erneut vorgenommen werden.) |
FMIEXT.properties |
/usr/lpp/wd4z/rse/lib/ [/etc/wd4z/] |
Konfigurationsdatei für File Manager-Integration | NEU, Anpassung bei Nutzung erforderlich |
Dieser Anhang soll Sie bei einigen allgemeinen Problemen unterstützen, die beim Konfigurieren von SSL (Secure Sockets Layer) oder beim Überprüfen und/oder Modifizieren einer vorhandenen Konfiguration auftreten könnten. Dieser Anhang stellt auch eine Beispielkonfiguration zur Verfügung, um Benutzer zu unterstützen, die sich mit einem X.509-Zertifikat selbst authentifizieren.
Sichere Kommunikation bedeutet, dass Ihr DFV-Partner derjenige ist, der er zu sein vorgibt, und dass Informationen in einer Weise übertragen werden, die es anderen erschwert, die Daten abzufangen und zu lesen. SSL bietet diese Fähigkeiten für ein TCP/IP-Netz an. SSL verwendet digitale Zertifikate für Ihre Identifikation und ein Protokoll mit öffentlichen Schlüsseln, um die Kommunikation zu verschlüsseln. Weitere Informationen zu digitalen Zertifikaten und zu dem von SSL verwendeten Protokoll mit öffentlichen Schlüsseln finden Sie im Security Server RACF Security Administrator's Guide (IBM Form SA22-7683).
Welche Aktionen erforderlich sind, um die SSL-Kommunikation für Developer for System z zu konfigurieren, hängt von den genauen Anforderungen am jeweiligen Standort, vom verwendeten RSE-Kommunikationsverfahren und von den am Standort verfügbaren Ressourcen ab.
In diesem Anhang werden Sie die aktuellen RSE-Definitionen klonen, damit Sie eine zweite RSE-Dämonverbindung haben, die SSL verwendet. Außerdem werden Sie Ihre eigenen Sicherheitszertifikate erstellen, die von den verschiedenen Teilnehmern der RSE-Verbindung verwendet werden.
In diesem Anhang wird die folgende einheitliche Namenskonvention verwendet:
Für einige der nachfolgenden Tasks wird vorausgesetzt, dass Sie aktivierter z/OS UNIX-Benutzer sind. Zum Aktivieren können Sie den TSO-Befehl OMVS absetzen. Mit dem Befehl exit können Sie zu TSO zurückkehren.
Die von SSL verwendeten Identitätszertifikate und Schlüssel für die Verschlüsselung/Entschlüsselung werden in einer Schlüsseldatei gespeichert. Die jeweiligen Implementierungen dieser Schlüsseldatei sind vom Anwendungstyp abhängig.
Alle Implementierungen folgen jedoch dem gleichen Prinzip. Ein Befehl generiert ein Schlüsselpaar (einen öffentlichen Schlüssel und einen zugehörigen privaten Schlüssel). Anschließend wird der öffentliche Schlüssel in ein selbst signiertes Zertifikat (X.509) eingeschlossen, das als Zertifikatskette mit einem Element gespeichert wird. Diese Zertifikatskette und der private Schlüssel werden als ein (mit einem Aliasnamen bezeichneter) Eintrag in einer Schlüsseldatei gespeichert.
Der RSE-Dämon ist eine System SSL-Anwendung und verwendet eine Schlüsseldatenbankdatei. Diese Schlüsseldatenbank kann eine von gskkyman erstellte physische Datei oder eine von Ihrer SAF-kompatiblen Sicherheitssoftware (z. B. RACF) verwaltete Schlüsseldatei sein. Der (vom Dämon gestartete) RSE-Server ist eine Java-SSL-Anwendung und verwendet eine von keytool erstellte Keystoredatei oder eine Schlüsseldatei, die von Ihrer Sicherheitssoftware verwaltet wird.
Zertifikatsspeicher | Erstellt und verwaltet von | RSE-Dämon | RSE-Server |
---|---|---|---|
Schlüsseldatei | SAF-kompatibles Sicherheitsprodukt | unterstützt | unterstützt |
Schlüsseldatenbank | gskkyman in z/OS UNIX | unterstützt | / |
Keystore | Java-Keytool | / | unterstützt |
Für die Verbindung über SSL benötigen Sie den Keystore und die Schlüsseldatenbank (als z/OS UNIX-Datei oder als SAF-kompatible Schlüsseldatei):
STEPLIB=$STEPLIB:SYS1.SIEALNKE
Beachten Sie jedoch Folgendes:
Weitere Informationen zu RACF und digitalen Zertifikaten finden Sie im Security Server RACF Security Administrator's Guide (IBM Form SA22-7683). Die Dokumentation zu gskkyman ist in der Veröffentlichung System SSL Programming (IBM Form SC24-5901) enthalten. Die Dokumentation zu keytool ist unter http://java.sun.com/j2se/1.5.0/docs/tooldocs/solaris/keytool.html verfügbar.
Führen Sie diesen Schritt nicht aus, wenn Sie gskkyman zum Erstellen der RSE-Dämonschlüsseldatenbank und keytool zum Erstellen des RSE-Server-Keystores verwenden.
Der Befehl RACDCERT installiert und verwaltet private Schlüssel und Zertifikate in RACF. RACF unterstützt die Verwaltung mehrerer privater Schlüssel und Zertifikate in einer Gruppe. Diese Gruppen werden als Schlüsseldateien bezeichnet.
Details zum Befehl RACDCERT enthält die Veröffentlichung Security Server RACF Command Language Reference (IBM Form SA22-7687).
RDEFINE FACILITY IRR.DIGTCERT.LIST UACC(NONE) RDEFINE FACILITY IRR.DIGTCERT.LISTRING UACC(NONE) PERMIT IRR.DIGTCERT.LIST CLASS(FACILITY) ACCESS(READ) ID(stcrse) PERMIT IRR.DIGTCERT.LISTRING CLASS(FACILITY) ACCESS(READ) ID(stcrse) SETROPTS RACLIST(FACILITY) REFRESH RACDCERT ID(stcrse) GENCERT SUBJECTSDN(CN('rdz rse ssl') + OU('rdz') O('IBM') L('Raleigh') SP('NC') C('US')) + NOTAFTER(DATE(2017-05-21)) WITHLABEL('rdzrse') KEYUSAGE(HANDSHAKE) RACDCERT ID(stcrse) ADDRING(rdzssl.racf) RACDCERT ID(stcrse) CONNECT(LABEL('rdzrse') RING(rdzssl.racf) + DEFAULT USAGE(PERSONAL))
Das obige Beispiel beginnt mit der Erstellung der notwendigen Profile und dem Berechtigen der Benutzer-ID STCRSE für den Zugriff auf die Schlüsseldateien und auf Zertifikate, deren Eigner diese Benutzer-ID ist. Die Benutzer-ID muss mit der für die Ausführung des SSL-RSE-Dämons verwendeten Benutzer-ID übereinstimmen. Der nächste Schritt ist die Erstellung eines neuen, selbst signierten Zertifikats mit der Bezeichnung rdzrse. Es ist kein Kennwort erforderlich. Dieses Zertifikat wird dann einer neu erstellten Schlüsseldatei (rdzssl.racf) hinzugefügt. Für die Schlüsseldatei ist ebenso wie für das Zertifikat kein Kennwort erforderlich.
Das Ergebnis können Sie wie folgt mit der Option list überprüfen:
RACDCERT ID(stcrse) LIST Digital certificate information for user STCRSE: Label: rdzrse Certificate ID: 2QjW1OXi0sXZ1aaEqZmihUBA Status: TRUST Start Date: 2007/05/24 00:00:00 End Date: 2017/05/21 23:59:59 Serial Number: >00< Issuer's Name: >CN=rdz rse ssl.OU=rdz.O=IBM.L=Raleigh.SP=NC.C=US< Subject's Name: >CN=rdz rse ssl.OU=rdz.O=IBM.L=Raleigh.SP=NC.C=US< Private Key Type: Non-ICSF Private Key Size: 1024 Ring Associations: Ring Owner: STCRSE Ring: >rdzssl.racf<
Zertifikate können selbst signiert oder von einer Zertifizierungsstelle (CA) signiert sein. Bei einem von einer CA signierten Zertifikat garantiert die CA, dass der Eigner des Zertifikats derjenige ist, der er zu sein vorgibt. Durch den Signierungsprozess werden Ihrem Zertifikat die Berechtigungsnachweise der CA hinzugefügt (hierbei handelt es sich auch um ein Zertifikat). Dadurch wird es zu einer mehrteiligen Zertifikatskette.
Wenn Sie ein Zertifikat verwenden, das von einer Zertifizierungsstelle signiert wurde, können Sie Fragen zur Vertrauensprüfung durch den Client von Developer for System z vermeiden, wenn der Client der Zertifizierungsstelle bereits vertraut.
Zum Erstellen und Verwenden eines von einer CA signierten Zertifikats führen Sie die folgenden Schritte aus:
RACDCERT ID(stcrse) GENCERT WITHLABEL('rdzrse') . . .
RACDCERT ID(stcrse) GENREQ (LABEL('rdzrse')) DSN(dsn)
RACDCERT CERTAUTH LIST
RACDCERT CERTAUTH ALTER(LABEL('CA cert')) TRUST
Fügen Sie alternativ der Datenbank das CA-Zertifikat hinzu.
RACDCERT CERTAUTH ADD(dsn) WITHLABEL('CA cert') TRUST
RACDCERT ID(stcrse) ADD(dsn) WTIHLABEL('rdzrse') TRUST
RACDCERT ID(stcrse) ADDRING(rdzssl.racf)
RACDCERT ID(stcrse) CONNECT(ID(stcrse) LABEL('rdzrse') RING(rdzssl.racf))
RACDCERT ID(stcrse) CONNECT(CERTAUTH LABEL('CA cert') RING(rdzssl.racf))
In diesem Schritt wird eine neue Instanz der RSE-Konfigurationsdateien erstellt, damit die SSL-Konfiguration parallel mit den vorhandenen Instanzen ausgeführt werden kann. Bei den folgenden Beispielbefehlen wird davon ausgegangen, dass sich die Konfigurationsdateien in /etc/rdz/ befinden. Dies ist die im Abschnitt Anpassungskonfiguration verwendete Standardposition.
$ cd /etc/rdz $ mkdir ssl $ cp rsed.envvars ssl $ cp ssl.properties ssl $ ls ssl rsed.envvars ssl.properties
Die oben aufgeführten z/OS UNIX-Befehle erstellen ein Unterverzeichnis mit der Bezeichnung ssl und füllen es mit den Konfigurationsdateien, für die Änderungen erforderlich sind. Die anderen Konfigurationsdateien, das Installationsverzeichnis und die MVS-Komponenten können gemeinsam genutzt werden, weil sie nicht SSL-spezifisch sind.
Indem die meisten vorhandenen Konfigurationsdateien wiederverwendet werden, kann der Fokus auf die Änderungen gelegt werden, die zur Konfiguration von SSL tatsächlich erforderlich sind. Außerdem kann eine erneute vollständige RSE-Konfiguration vermieden werden. (Beispielsweise muss für ISPF.conf keine neue Position definiert werden.)
Bisher sind die Definitionen eine exakte Kopie der aktuellen Konfiguration. Dies impliziert, dass die Protokolle des neuen RSE-Dämons die aktuellen Serverprotokolldateien überschreiben. RSE muss auch die Positionen kennen, an denen die Konfigurationsdateien auffindbar sind, die nicht in das ssl-Verzeichnis kopiert wurden. Beide Probleme könnnen sie durch geringfügige Änderungen an rsed.envvars lösen.
$ oedit /etc/rdz/ssl/rsed.envvars -> Kommentarzeichen entfernen und ändern: -Ddaemon.log=/var/rdz/logs/ssl -> am ENDE hinzufügen: # -- NEEDED TO FIND THE REMAINING CONFIGURATION FILES CFG_BASE=/etc/rdz CLASSPATH=.:$CFG_BASE:$CLASSPATH # --
Die oben beschriebenen Änderungen definieren eine neue Protokollposition. (Wenn die Protokollposition nicht vorhanden ist, wird diese vom RSE-Dämon erstellt.) Durch die Änderungen wird auch der CLASSPATH aktualisiert, sodass die SSL-RSE-Prozesse zunächst das aktuelle Verzeichnis (/etc/rdz/ssl) und dann das Ursprungsverzeichnis (/etc/rdz) nach Konfigurationsdateien durchsucht.
Durch die Aktualisierung der Datei ssl.properties wird RSE angewiesen, die Kommunikation mit SSL zu verschlüsseln.
$ oedit /etc/rdz/ssl/ssl.properties -> ändern: enable_ssl=true -> Kommentarzeichen entfernen und ändern: daemon_keydb_file=rdzssl.racf -> Kommentarzeichen entfernen und ändern: daemon_key_label=rdzrse -> Kommentarzeichen entfernen und ändern: server_keystore_file=rdzssl.racf -> Kommentarzeichen entfernen und ändern: server_keystore_label=rdzrse -> Kommentarzeichen entfernen und ändern: server_keystore_type=JCERACFKS
Die oben beschriebenen Änderungen aktivieren SSL und teilen dem RSE-Dämon und RSE-Server mit, dass ihr (gemeinsam genutztes) Zertifikat in der Schlüsseldatei rdzssl.racf unter der Bezeichnung rdzrse gespeichert ist. Mit dem Schlüsselwort JCERACFKS wird dem RSE-Server mitgeteilt, dass eine SAF-kompatible Schlüsseldatei als Schlüsselspeicher verwendet wird.
Wie bereits angegeben werden wir eine zweite Verbindung erstellen, die SSL verwendet. Dafür muss ein neuer RSE-Dämon erstellt werden. Der RSE-Dämon kann eine gestartete Task oder ein Benutzerjob sein. Für die anfängliche Testkonfiguration werden wir einen Benutzerjob verwenden. Bei den folgenden Anweisungen wird davon ausgegangen, dass die Beispiel-JCL in FEK.#CUST.PROCLIB(RSED) enthalten ist. Dies ist die im Abschnitt Anpassungskonfiguration verwendete Standardposition:
//RSEDSSL JOB CLASS=A,MSGCLASS=A,MSGLEVEL=(1,1),USER=STCRSE //* //* RSE-DÄMON - SSL //* //RSED PROC IVP='', * 'IVP' für einen IVP-Test // PORT=4047, // HOME='/usr/lpp/rdz', // CNFG='/etc/rdz/ssl' //* //RSE EXEC PGM=BPXBATSL,REGION=0M,TIME=NOLIMIT, // PARM='PGM &HOME./bin/rsed.sh &IVP &PORT &CNFG' //STDOUT DD SYSOUT=* //STDERR DD SYSOUT=* //PEND //* //RSED EXEC RSED //*
Die SSL-Hostkonfiguration ist vollständig, und der RSE-Dämon für SSL kann mit der Übergabe des zuvor erstellten Jobs FEK.#CUST.PROCLIB(RSEDSSL) gestartet werden.
Die neue Konfiguration kann jetzt getestet werden, indem eine Verbindung mit dem Client mit Developer for System z hergestellt wird. Da Sie für SSL eine neue Konfiguration (durch Klonen der vorhandenen Konfiguration) erstellt haben, müssen Sie nun auf dem Client eine neue Verbindung mit dem Port 4047 für den RSE-Dämon konfigurieren.
Wenn die Verbindung hergestellt ist, beginnen Host und Client mit dem Handshakeverfahren, um einen sicheren Pfad einzurichten. Im Rahmen dieses Handshakeverfahrens werden Zertifikate ausgetauscht. Wenn die Clientkomponente von Developer for System z das Hostzertifikat oder die signierende CA nicht erkennt, fragt sie beim Benutzer an, ob dieses Zertifikat vertrauenswürdig ist.
Der Benutzer kann dieses Zertifikat als vertrauenswürdig akzeptieren, indem er auf die Schaltfläche 'Finish' klickt. Danach wird die Verbindungsinitialisierung fortgesetzt.
Wenn der Client ein Zertifikat einmal anerkannt hat, wird dieser Dialog nicht mehr angezeigt. Die Liste vertrauenswürdiger Zertifikate kann verwaltet werden. Wählen Sie dazu Fenster > Benutzervorgaben... > Ferne Systeme > SSL aus, um den folgenden Dialog aufzurufen:
Wenn die SSL-Kommunikation fehlschlägt, gibt der Client eine Fehlernachricht zurück. Weitere Informationen sind in den verschiedenen Server- und Benutzerprotokolldateien verfügbar. Lesen Sie die diesbezüglichen Beschreibungen in den Abschnitten Protokollierung des RSE-Dämons und des Thread-Pools und Protokollierung des RSE-Benutzers.
Mit einem X.509-Zertifikat unterstützt der RSE-Dämon die eigene Authentifizierung der Benutzer. Voraussetzung hierfür ist die Verwendung der mit SSL verschlüsselten Kommunikation, da dies eine Erweiterung der Hostauthentifizierung mit einem in SSL verwendeten Zertifikat ist.
Es gibt mehrere Wege zur Zertifikatsauthentifizierung für einen Benutzer. Lesen Sie hierzu den Abschnitt Clientauthentifizierung unter Verwendung von X.509-Zertifikaten. Die folgenden Schritte dokumentieren die Konfiguration, die zur Unterstützung der Methode erforderlich ist, bei der Ihre Sicherheitssoftware das Zertifikat unter Verwendung der HostIdMappings-Zertifikatserweiterung authentifiziert.
RACDCERT CERTAUTH ALTER(LABEL('HighTrust CA')) HIGHTRUST
RACDCERT ID(stcrse) CONNECT(CERTAUTH LABEL('HighTrust CA') + RING(rdzssl.racf))
Dies beendet die Konfiguration der Sicherheitssoftware für das CA-Zertifikat.
RDEFINE SERVAUTH IRR.HOST.CDFMVS08.RALEIGH.IBM.COM UACC(NONE)
PERMIT IRR.HOST.CDFMVS08.RALEIGH.IBM.COM CLASS(SERVAUTH) + ACCESS(READ) ID(stcrse)
SETROPTS CLASSACT(SERVAUTH) RACLIST(SERVAUTH) oder SETROPTS RACLIST(SERVAUTH) REFRESH
Dies beendet die Konfiguration der Sicherheitssoftware für die HostIdMappings-Erweiterung.
Führen Sie diesen Schritt nicht aus, wenn Sie eine SAF-kompatible Schlüsseldatei für die Schlüsseldatenbank des RSE-Dämons verwenden.
gskkyman ist ein shellbasiertes, menügeführtes z/OS UNIX-Programm, das eine z/OS UNIX-Datei erstellt, mit Daten füllt und verwaltet. Diese Datei enthält private Schlüssel, Zertifikatanforderungen und Zertifikate und wird als Schlüsseldatenbank bezeichnet.
PATH=$PATH:/usr/lpp/gskssl/bin export NLSPATH=/usr/lpp/gskssl/lib/nls/msg/En_US.IBM-1047/%N:$NLSPATH export STEPLIB=$STEPLIB:SYS1.SIEALNKE
$ cd /etc/rdz/ssl $ gskkyman Database Menu 1 - Create new database Enter option number: 1 Enter key database name (press ENTER to return to menu): rdzssl.kdb Enter database password (press ENTER to return to menu): rsessl Re-enter database password: rsessl Enter password expiration in days (press ENTER for no expiration): Enter database record length (press ENTER to use 2500): Key database /etc/rdz/ssl/rdzssl.kdb created. Press ENTER to continue. Key Management Menu 6 - Create a self-signed certificate Enter option number (press ENTER to return to previous menu): 6 Certificate Type 5 - User or server certificate with 1024-bit RSA key Select certificate type (press ENTER to return to menu): 5 Enter label (press ENTER to return to menu): rdzrse Enter subject name for certificate Common name (required): rdz rse ssl Organizational unit (optional): rdz Organization (required): IBM City/Locality (optional): Raleigh State/Province (optional): NC Country/Region (2 characters - required): US Enter number of days certificate will be valid (default 365): 3650 Enter 1 to specify subject alternate names or 0 to continue: 0 Please wait ..... Certificate created. Press ENTER to continue. Key Management Menu 0 - Exit program Enter option number (press ENTER to return to previous menu): 0 $ ls -l rdzssl.* total 152 -rw------- 1 IBMUSER SYS1 35080 May 24 14:24 rdzssl.kdb -rw------- 1 IBMUSER SYS1 80 May 24 14:24 rdzssl.rdb $ chmod 644 rdzssl.* $ ls -l rdzssl.* -rw-r--r-- 1 IBMUSER SYS1 35080 May 24 14:24 rdzssl.kdb -rw-r--r-- 1 IBMUSER SYS1 80 May 24 14:24 rdzssl.rdb
Das obige Beispiel beginnt mit der Erstellung einer Schlüsseldatenbank rdzssl.kdb mit dem Kennwort rsessl. Wenn die Datenbank vorhanden ist, wird sie mit Daten gefüllt. Dazu wird ein neues selbst signiertes Zertifikat erstellt, das für ca. 10 Jahre gültig ist (ohne Berücksichtigung des zusätzlichen Tages in Schaltjahren). Das Zertifikat wird unter der Bezeichnung rdzrse und mit dem bereits für die Schlüsseldatenbank verwendeten Kennwort (rsessl) gespeichert. (Dies ist eine RSE-Anforderung.)
gskkyman legt die Schlüsseldatenbank mit einer (sehr sicheren) Bitmaske (600 Berechtigungsbits) an, die nur dem Eigner Zugriff gewährt. Die Berechtigungen müssen weniger restriktiv gesetzt werden, sofern der Dämon nicht dieselbe Benutzer-ID wie der Ersteller der Schlüsseldatenbank verwendet. 644 (Eigner mit Lese-/Schreibzugriff; Lesezugriff für alle übrigen Benutzer) ist eine verwendbare Maske für den Befehl chmod.
Das Ergebnis können Sie wie folgt überprüfen, indem Sie im Untermenü Manage keys and certificates die Option Show certificate information auswählen:
$ gskkyman Database Menu 2 - Open database Enter option number: 2 Enter key database name (press ENTER to return to menu): rdzssl.kdb Enter database password (press ENTER to return to menu): rsessl Key Management Menu 1 - Manage keys and certificates Enter option number (press ENTER to return to previous menu): 1 Key and Certificate List 1 - rdzrse Enter label number (ENTER to return to selection menu, p for previous list): 1 Key and Certificate Menu 1 - Show certificate information Enter option number (press ENTER to return to previous menu): 1 Certificate Information Label: rdzrse Record ID: 14 Issuer Record ID: 14 Trusted: Yes Version: 3 Serial number: 45356379000ac997 Issuer name: rdz rse ssl rdz IBM Raleigh NC US Subject name: rdz rse ssl rdz IBM Raleigh NC US Effective date: 2007/05/24 Expiration date: 2017/05/21 Public key algorithm: rsaEncryption Public key size: 1024 Signature algorithm: sha1WithRsaEncryption Issuer unique ID: None Subject unique ID: None Number of extensions: 3 Enter 1 to display extensions, 0 to return to menu: 0 Key and Certificate Menu 0 - Exit program Enter option number (press ENTER to return to previous menu): 0
Das folgende Beispiel für ssl.properties zeigt, dass die Anweisungen daemon_* sich von dem zuvor aufgeführten Beispiel für eine SAF-Schlüsseldatei unterscheiden.
$ oedit /etc/rdz/ssl/ssl.properties -> ändern: enable_ssl=true -> Kommentarzeichen entfernen und ändern: daemon_keydb_file=rdzssl.kdb -> Kommentarzeichen entfernen und ändern: daemon_keydb_password=rsessl -> Kommentarzeichen entfernen und ändern: daemon_key_label=rdzrse -> Kommentarzeichen entfernen und ändern: server_keystore_file=rdzssl.racf -> Kommentarzeichen entfernen und ändern: server_keystore_label=rdzrse -> Kommentarzeichen entfernen und ändern: server_keystore_type=JCERACFKS
Die oben beschriebenen Änderungen aktivieren SSL und teilen dem RSE-Dämon mit, dass das Zertifikat in der Schlüsseldatei rdzssl.kdb unter der Bezeichnung rdzrse mit dem Kennwort rsessl gespeichert ist. Der RSE-Server verwendet weiterhin eine SAF-konforme Schlüsseldatei.
Führen Sie diesen Schritt nicht aus, wenn Sie eine SAF-kompatible Schlüsseldatei für den Keystore des RSE-Servers verwenden.
keytool -genkey generiert ein privates Schlüsselpaar und ein entsprechendes selbst signiertes Zertifikat, die als ein (mit einem Aliasnamen bezeichneter) Eintrag in einer (neuen) Keystoredatei gespeichert werden.
Alle Informationen können als ein Parameter übergeben werden. Durch die Längenbeschränkung der Befehlszeile sind jedoch folgende Interaktionen erforderlich:
$ cd /etc/rdz/ssl $ keytool -genkey -alias rdzrse -validity 3650 -keystore rdzssl.jks -storepass rsessl -keypass rsessl What is your first and last name? [Unknown]: rdz rse ssl What is the name of your organizational unit? [Unknown]: rdz What is the name of your organization? [Unknown]: IBM What is the name of your City or Locality? [Unknown]: Raleigh What is the name of your State or Province? [Unknown]: NC What is the two-letter country code for this unit? [Unknown]: US Is CN=rdz rse ssl, OU=rdz, O=IBM, L=Raleigh, ST=NC, C=US correct? (type "yes" or "no") [no]: yes $ ls -l rdzssl.* -rw-r--r-- 1 IBMUSER SYS1 1224 May 24 14:17 rdzssl.jks
Das oben erstellte selbst signierte Zertifikat ist für ca. 10 Jahre gültig (ohne Berücksichtigung des zusätzlichen Tages in Schaltjahren). Es wird in /etc/rdz/ssl/rdzssl.jks mit dem Aliasnamen rdzrse gespeichert. Das Kennwort (rsessl) stimmt mit dem Keystore-Kennwort überein. Dies ist eine RSE-Anforderung.
Das Ergebnis können Sie wie folgt mit der Option -list überprüfen:
$ keytool -list -alias rdzrse -keystore rdzssl.jks -storepass rsessl -v Alias name: rdzrse Creation date: May 24, 2007 Entry type: keyEntry Certificate chain length: 1 Certificate 1¨: Owner: CN=rdz rse ssl, OU=rdz, O=IBM, L=Raleigh, ST=NC, C=US Issuer: CN=rdz rse ssl, OU=rdz, O=IBM, L=Raleigh, ST=NC, C=US Serial number: 46562b2b Valid from: 5/24/07 2:17 PM until: 5/21/17 2:17 PM Certificate fingerprints: MD5: 9D:6D:F1:97:1E:AD:5D:B1:F7:14:16:4D:9B:1D:28:80 SHA1: B5:E2:31:F5:B0:E8:9D:01:AD:2D:E6:82:4A:E0:B1:5E:12:CB:10:1C
Das folgende Beispiel für ssl.properties zeigt, dass die Anweisungen server_* sich von dem zuvor aufgeführten Beispiel für eine SAF-Schlüsseldatei unterscheiden.
$ oedit /etc/rdz/ssl/ssl.properties -> ändern: enable_ssl=true -> Kommentarzeichen entfernen und ändern: daemon_keydb_file=rdzssl.racf -> Kommentarzeichen entfernen und ändern: daemon_key_label=rdzrse -> Kommentarzeichen entfernen und ändern: server_keystore_file=rdzssl.jks -> Kommentarzeichen entfernen und ändern: server_keystore_password=rsessl -> Kommentarzeichen entfernen und ändern: server_keystore_label=rdzrse -> Kommentarzeichen entfernen und ändern (optional): server_keystore_type=JKS
Die oben beschriebenen Änderungen aktivieren SSL und teilen dem RSE-Server mit, dass das Zertifikat in der Schlüsseldatei rdzssl.jks unter der Bezeichnung rdzrse mit dem Kennwort rsessl gespeichert ist. Der RSE-Dämon verwendet immer noch eine SAF-kompatible Schlüsseldatei.
Dieser Anhang soll Sie bei einigen allgemeinen Problemen unterstützen, die beim Konfigurieren von TCP/IP oder beim Überprüfen oder Modifizieren einer vorhandenen Konfiguration auftreten könnten.
Zusätzliche Informationen zur TCP/IP-Konfiguration finden Sie im Communications Server: IP Configuration Guide (IBM Form SC31-8775) und in der Veröffentlichung Communications Server: IP Configuration Reference (IBM Form SC31-8776).
Wenn Sie APPC für TSO Commands Service verwenden, ist Developer for System z bei der Initialisierung darauf angewiesen, dass TCP/IP mit dem richtigen Hostnamen konfiguriert ist. Dies impliziert, dass die verschiedenen TCP/IP- und Resolverkonfigurationsdateien ordnungsgemäß definiert sein müssen.
Sie können Ihre TCP/IP-Konfiguration mit dem Installationsprüfprogramm fekfivpt testen. Der Befehl sollte eine Ausgabe wie im folgenden Beispiel zurückgeben ($ ist die z/OS UNIX-Eingabeaufforderung):
$ fekfivpt Wed Jul 2 13:11:54 EDT 2008 uid=1(USERID) gid=0(GROUP) using /etc/rdz/rsed.envvars ------------------------------------------------------------- TCP/IP resolver configuration (z/OS UNIX search order): ------------------------------------------------------------- Resolver Trace Initialization Complete -> 2008/07/02 13:11:54.745964 res_init Resolver values: Global Tcp/Ip Dataset = None Default Tcp/Ip Dataset = None Local Tcp/Ip Dataset = /etc/resolv.conf Translation Table = Default UserId/JobName = USERID Caller API = LE C Sockets Caller Mode = EBCDIC (L) DataSetPrefix = TCPIP (L) HostName = CDFMVS08 (L) TcpIpJobName = TCPIP (L) DomainOrigin = RALEIGH.IBM.COM (L) NameServer = 9.42.206.2 9.42.206.3 (L) NsPortAddr = 53 (L) ResolverTimeout = 10 (L) ResolveVia = UDP (L) ResolverUdpRetries = 1 (*) Options NDots = 1 (*) SockNoTestStor (*) AlwaysWto = NO (L) MessageCase = MIXED (*) LookUp = DNS LOCAL res_init Succeeded res_init Started: 2008/07/02 13:11:54.755363 res_init Ended: 2008/07/02 13:11:54.755371 ************************************************************************ MVS TCP/IP NETSTAT CS V1R9 TCPIP Name: TCPIP 13:11:54 Tcpip started at 01:28:36 on 06/23/2008 with IPv6 enabled ------------------------------------------------------------- host IP address: ------------------------------------------------------------- hostName=CDFMVS08 hostAddr=9.42.112.75 bindAddr=9.42.112.75 localAddr=9.42.112.75 Success, addresses match
Der Resolver arbeitet für Programme als ein Client, der für die Auflösung von Namen in Adressen oder von Adressen in Namen auf Namensserver zugreift. Für die Anforderung eines aufrufenden Programms kann der Resolver auf verfügbare Namensserver zugreifen, lokale Definitionen verwenden (z. B. /etc/resolv.conf, /etc/hosts, /etc/ipnodes, HOSTS.SITEINFO, HOSTS.ADDRINFO oder ETC.IPNODES) oder eine Kombination aus beiden Möglichkeiten anwenden.
Beim Starten des Adressraums des Resolvers wird eine optionale Resolverkonfigurationsdatei gelesen, auf die die DD-Karte SETUP in der JCL-Prozedur des Resolvers zeigt. Wenn die Konfigurationsdaten nicht zur Verfügung stehen, greift der Resolver auf die anwendbare native MVS- oder z/OS UNIX-Suchreihenfolge ohne Angaben von GLOBALTCPIPDATA, DEFAULTTCPIPDATA, GLOBALIPNODES, DEFAULTIPNODES oder COMMONSEARCH zurück.
Es ist wichtig, dass Sie die von TCP/IP-Funktionen verwendete Suchreihenfolge für Konfigurationsdateien verstehen und wissen, wann Sie die Standardsuchreihenfolge mit Umgebungsvariablen, JCL oder anderen von Ihnen angegebenen Variablen außer Kraft setzen können. Ausgehend von diesen Kenntnissen können Sie Ihre Benennungsstandards für lokale Dateien und HFS-Dateien anpassen. Außerdem ist es bei der Fehlerdiagnose hilfreich zu wissen, welche Konfigurationsdatei oder HFS-Datei verwendet wird.
Ein anderer wichtiger Punkt ist, dass die Suche bei Anwendung einer Suchreihenfolge für Konfigurationsdateien bei der ersten gefundenen Datei beendet wird. Wenn Sie Konfigurationsdaten in eine Datei stellen, die nie gefunden wird, weil es in der Suchreihenfolge vorher eine andere Datei gibt oder die Datei nicht von der Suchreihenfolge, die die Anwendung gewählt hat, erfasst wird, kann es daher zu unerwarteten Ergebnissen kommen.
Bei der Suche nach Konfigurationsdateien können Sie TCP/IP mit DD-Anweisungen in den JCL-Prozeduren oder durch das Setzen von Umgebungsvariablen explizit mitteilen, wo sich die meisten Konfigurationsdateien befinden. Sie können TCP/IP die Position der Konfigurationsdateien aber auch dynamisch auf der Grundlage der Suchreihenfolgen ermitteln lassen. Diese Suchreihenfolgen sind im Communications Server: IP Configuration Guide (IBM Form SC31-8775) dokumentiert.
Während der Initialisierung des TCP/IP-Stacks verwendet die Konfigurationskomponente des TCP/IP-Stacks TCPIP.DATA, um den HOSTNAME des Stacks zu ermitteln. Zum Abrufen des Wertes wird die Suchreihenfolge für die z/OS UNIX-Umgebung verwendet.
Die Datei oder Tabelle, nach der gesucht wird, kann eine MVS-Datei oder eine HFS-Datei sein. Dies hängt von den Einstellungen in der Resolverkonfiguration und dem Vorhandensein bestimmter Dateien im System ab.
Die Basiskonfigurationsdatei des Resolvers enthält TCPIP.DATA-Anweisungen. Diese Datei wird wegen der enthaltenen Resolveranweisungen referenziert, aber auch, weil sie unter anderem das Dateipräfix (Wert der Anweisung DATASETPREFIX) für den Zugriff auf die in diesem Abschnitt genannten Konfigurationsdateien enthält.
Für den Zugriff auf die Basiskonfigurationsdatei des Resolvers wird diese Suchreihenfolge verwendet:
Wenn der Wert der Konfigurationsanweisung GLOBALTCPIPDATA für den Resolver definiert ist, wird er verwendet. (Lesen Sie hierzu auch den Abschnitt Wissenswertes zu Resolvern.) Es wird weiter nach einer zusätzlichen Konfigurationsdatei gesucht. Die Suche endet mit der nächsten gefundenen Datei.
Der Wert der Umgebungsvariablen wird verwendet. Die Suche scheitert, wenn die Datei nicht vorhanden ist oder anderweitig exklusiv zugeordnet ist.
Die dem DD-Namen in SYSTCPD zugeordnete Datei wird verwendet. In der z/OS UNIX-Umgebung hat ein untergeordneter Prozess keinen Zugriff auf die DD-Anweisung SYSTCPD. Dies ist darauf zurückzuführen, dass bei fork()- oder exec-Funktionsaufrufen die SYSTCPD-Zuordnung nicht vom übergeordneten Prozess übernommen wird.
USERID ist die Benutzer-ID, die der aktuellen Sicherheitsumgebung (Adressraum, Task oder Thread) zugeordnet ist.
JOBNAME ist der in der JCL-Anweisung JOB angegebene Name für Batch-Jobs oder der Prozedurname für eine gestartete Prozedur.
Wenn der Wert der Konfigurationsanweisung DEFAULTTCPIPDATA für den Resolver definiert ist, wird er verwendet. (Lesen Sie hierzu auch den Abschnitt Wissenswertes zu Resolvern.)
Die Umsetztabellen (EBCDIC zu ASCII und ASCII zu EBCDIC) werden referenziert, um die zu verwendenden Umsetzungsdateien zu ermitteln. Für den Zugriff auf diese Konfigurationsdatei wird die folgende Suchreihenfolge verwendet: (Die Suche endet mit der ersten gefundenen Datei.)
Dies ist der Name der mit dem TSO-Befehl CONVXLAT erzeugten Umsetztabelle.
USERID ist die Benutzer-ID, die der aktuellen Sicherheitsumgebung (Adressraum oder Task/Thread) zugeordnet ist.
JOBNAME ist der in der JCL-Anweisung JOB angegebene Name für Batch-Jobs oder der Prozedurname für eine gestartete Prozedur.
HLQ repräsentiert den Wert der Anweisung DATASETPREFIX in der Basiskonfigurationsdatei des Resolvers, der verwendet wird, wenn er aufgefunden wird. Andernfalls wird der Standard-HLQ TCPIP verwendet.
Standardmäßig versucht der Resolver zuerst, konfigurierte Domänennamensserver für Auflösungsanforderungen zu verwenden. Falls die Auflösungsanforderung nicht erfüllt werden kann, werden lokale Hosttabellen genutzt. Das Verhalten des Resolvers wird von TCPIP.DATA-Anweisungen gesteuert.
Die TCPIP.DATA-Resolveranweisungen definieren, ob und ggf. wie Domänennamensserver zu verwenden sind. Außerdem kann mit der Anweisung LOOKUP TCPIP.DATA gesteuert werden, wie Domänennamensserver und lokale Hosttabellen verwendet werden sollen. Weitere Informationen zu TCPIP.DATA-Anweisungen finden Sie in der Veröffentlichung Communications Server: IP Configuration Reference (IBM Form SC31-8776).
Der Resolver verwendet die spezifische Suchreihenfolge für Sitenamen von IPv4 uneingeschränkt für getnetbyname-API-Aufrufe. Die spezifische Suchreihenfolge für Sitenamen von IPv4 ist wie folgt. Die Suche endet mit der ersten gefundenen Datei:
Dies ist der Name der mit dem TSO-Befehl MAKESITE erstellten Informationsdatei HOSTS.SITEINFO.
Dies ist der Name der mit dem TSO-Befehl MAKESITE erstellten Informationsdatei HOSTS.ADDRINFO.
USERID ist die Benutzer-ID, die der aktuellen Sicherheitsumgebung (Adressraum oder Task/Thread) zugeordnet ist.
JOBNAME ist der in der JCL-Anweisung JOB angegebene Name für Batch-Jobs oder der Prozedurname für eine gestartete Prozedur.
HLQ repräsentiert den Wert der Anweisung DATASETPREFIX in der Basiskonfigurationsdatei des Resolvers, der verwendet wird, wenn er aufgefunden wird. Andernfalls wird der Standard-HLQ TCPIP verwendet.
Wie bereits erwähnt, ist Developer for System z bei der Initialisierung davon abhängig, dass TCP/IP mit dem richtigen Hostnamen konfiguriert ist, wenn Sie APPC verwenden. Dies impliziert, dass die verschiedenen TCP/IP- und Resolverkonfigurationsdateien ordnungsgemäß definiert sein müssen.
Im folgenden Beispiel geht es hauptsächlich um einige Konfigurationstasks für TCP/IP und den Resolver. Beachten Sie, dass es sich nicht um eine komplette Konfiguration für TCP/IP oder den Resolver handelt. Das Beispiel hebt nur einige wichtige Aspekte hervor, die auf Ihren Standort anwendbar sein könnten.
//TCPIP PROC PARMS='CTRACE(CTIEZB00)',PROF=TCPPROF,DATA=TCPDATA //* //* TCP/IP NETWORK //* //TCPIP EXEC PGM=EZBTCPIP,REGION=0M,TIME=1440,PARM=&PARMS //PROFILE DD DISP=SHR,DSN=SYS1.TCPPARMS(&PROF) //SYSTCPD DD DISP=SHR,DSN=SYS1.TCPPARMS(&DATA) //SYSPRINT DD SYSOUT=*,DCB=(RECFM=VB,LRECL=132,BLKSIZE=136) //ALGPRINT DD SYSOUT=*,DCB=(RECFM=VB,LRECL=132,BLKSIZE=136) //CFGPRINT DD SYSOUT=*,DCB=(RECFM=VB,LRECL=132,BLKSIZE=136) //SYSOUT DD SYSOUT=*,DCB=(RECFM=VB,LRECL=132,BLKSIZE=136) //CEEDUMP DD SYSOUT=*,DCB=(RECFM=VB,LRECL=132,BLKSIZE=136) //SYSERROR DD SYSOUT=*
; HOSTNAME gibt den TCP-Hostnamen dieses Systems an. Wenn kein ; Wert angegeben ist, wird für HOSTNAME standardmäßig der im PARMLIB-Member ; IEFSSNxx angegebene Knotenname verwendet. ; ; HOSTNAME ; ; DOMAINORIGIN gibt den Domänenursprung an, der an Hostnamen angehängt wird, ; die an den Resolver übergeben werden. Enthält ein Hostname ; Punkte, wird der Wert von DOMAINORIGIN nicht ; an den Hostnamen angehängt. ; DOMAINORIGIN RALEIGH.IBM.COM ; ; NSINTERADDR gibt die IP-Adresse des Namensservers an. ; LOOPBACK (14.0.0.0) gibt Ihren lokalen Namensserver an. Wenn kein ; Namensserver verwendet wird, codieren Sie keine Anweisung NSINTERADDR. ; (Setzen Sie die folgende Zeile NSINTERADDR auf Kommentar, wenn alle ; Namen durch eine Suche in der Standorttabelle aufgelöst werden sollen.) ; ; NSINTERADDR 14.0.0.0 ; ; TRACE RESOLVER bewirkt, dass ein vollständiger Trace für alle Abfragen an den ; Namensserver oder an Standorttabellen und alle entsprechenden Antworten auf die ; Benutzerkonsole geschrieben werden. Der Befehl ist nur für Debugzwecke bestimmt. ; ; TRACE RESOLVER
//RESOLVER PROC PARMS='CTRACE(CTIRES00)' //* //* RESOLVER FÜR IP-NAMEN - BEGINN MIT SUB=MSTR //* //RESOLVER EXEC PGM=EZBREINI,REGION=0M,TIME=1440,PARM=&PARMS //*SETUP DD DISP=SHR,DSN=USER.PROCLIB(RESSETUP),FREE=CLOSE
TCPIPJOBNAME TCPIP DomainOrigin RALEIGH.IBM.COM HostName CDFMVS08
Wie im Abschnitt Suchreihenfolgen in der z/OS UNIX-Umgebung erwähnt, enthält die Basiskonfigurationsdatei TCPIP.DATA-Anweisungen. Wenn der Systemname CDFMVS08 lautet, sehen wir, dass /etc/resolv.conf mit SYS1.TCPPARMS(TCPDATA) synchron ist. (TCPDATA gibt an, dass der Systemname als Hostname verwendet werden soll.) Es liegen keine DNS-Definitionen vor, sodass die Standorttabellen durchsucht werden.
# Resolver /etc/hosts-Datei cdfmvs08 9.42.112.75 cdfmvs08 # CDFMVS08 Host 9.42.112.75 cdfmvs08.raleigh.ibm.com # CDFMVS08 Host 127.0.0.1 localhost
Der minimale Inhalt dieser Datei bezieht sich auf das aktuelle System. Im obigen Beispiel sind cdfmvs08 und cdfmvs08.raleigh.ibm.com als gültige Namen für die IP-Adresse des z/OS-Systems definiert.
Wenn ein Domänennamensserver (DNS) verwendet werden würde, würde der DNS die /etc/hosts-Informationen enthalten und /etc/resolv.conf und SYS1.TCPPARMS(TCPDATA) würden Anweisungen enthalten, die den DNS für das System identifizieren.
Um Unklarheiten zu vermeiden, sollten die Konfigurationsdateien für TCP/IP und den Resolver synchron sein.
Beschreibung des Dateityps | Betroffene APIs | Mögliche Dateien |
---|---|---|
Basiskonfigurationsdateien des Resolvers | Alle APIs |
|
Umsetztabellen | Alle APIs |
|
Lokale Hosttabellen |
endhostent endnetent getaddrinfo gethostbyaddr gethostbyname gethostent GetHostNumber GetHostResol GetHostString getnameinfo getnetbyaddr getnetbyname getnetent IsLocalHost Resolve sethostent setnetent |
IPV4
IPV6
|
Wenn Sie feststellen, dass der TCP/IP-Resolver die Hostadresse nicht ordnungsgemäß auflösen kann, liegt dies höchstwahrscheinlich daran, dass eine Resolverkonfigurationsdatei fehlt oder unvollständig ist. Ein deutlicher Hinweis auf dieses Problem ist die folgende Nachricht in lock.log:
clientip(0.0.0.0) <> callerip(<Host-IP-Adresse>)
Führen Sie zur Überprüfung das TCP/IP-Installationsprüfprogramm fekfivpt wie in Installationsprüfung beschrieben aus. Der Abschnitt der Ausgabe mit der Resolverkonfiguration sieht in etwa wie das folgende Beispiel aus:
Resolver Trace Initialization Complete -> 2008/07/02 13:11:54.745964 res_init Resolver values: Global Tcp/Ip Dataset = None Default Tcp/Ip Dataset = None Local Tcp/Ip Dataset = /etc/resolv.conf Translation Table = Default UserId/JobName = USERID Caller API = LE C Sockets Caller Mode = EBCDIC
Vergewissern Sie sich, dass die Definitionen in der von "Local Tcp/Ip Dataset" referenzierten Datei stimmen.
Wenn Sie für die IP-Resolver-Datei keinen Standardnamen verwenden, bleibt dieses Feld leer (bei Verwendung der z/OS UNIX-Suchreihenfolge). Fügen Sie in dem Fall die folgende Anweisung zu rsed.envvars hinzu. <Resolver-Datei> repräsentiert hier den Namen Ihrer IP-Resolver-Datei.
RESOLVER_CONFIG='<Resolver-Datei>'
Dieser Anhang soll Sie bei einigen allgemeinen Problemen unterstützen, die beim Konfigurieren von INETD oder beim Überprüfen oder Modifizieren einer vorhandenen Konfiguration auftreten könnten. INETD wird von Developer for System z verwendet, um REXEC/SSH-Funktionalitäten bereitzustellen.
Der Dämon INETD führt das Service-Management für ein IP-Netz durch. Er verringert die Systembelastung, indem er andere Dämonen nur bei Bedarf aufruft und intern mehrere einfache Internetservices (wie echo) bereitstellt. INETD liest die Konfigurationsdatei inetd.conf, um zu bestimmen, welche zusätzlichen Services bereitgestellt werden müssen. ETC.SERVICES wird für die Verknüpfung von Services mit Ports verwendet.
Die Services, die auf INETD zurückgreifen, sind in inetd.conf definiert. Diese Datei wird während der Startzeit von INETD gelesen. Die Standardposition und der Standardname für inetd.conf lauten /etc/inetd.conf. Ein Beispiel für eine Datei inetd.conf finden Sie unter /samples/inetd.conf.
Für Einträge in inetd.conf gelten die folgenden Syntaxregeln:
Jeder Eintrag umfasst sieben positionsgebundene Felder im folgenden Format:
Servicename Sockettyp Protokoll Option_wait Benutzer-ID Serverprogramm Serverprogrammargumente
Für Protokoll kann der Wert tcp[4|6] oder udp[4|6] als weitere Qualifizierung des Servicenamens angegeben werden. Der Servicename und das Protokoll müssen mit einem Eintrag in ETC.SERVICES übereinstimmen, bis auf die "4" oder "6", die im Eintrag in ETC.SERVICES nicht enthalten sein sollte.
Die Werte sndbuf und rcvbuf geben die Größe des Sendepuffers und des Empfangspuffers an. Die von 'n' repräsentierte Größe kann in Bytes angegeben werden. Sie können aber auch ein 'k' oder 'm' hinzufügen, wenn Sie Kilobytes oder Megabytes angeben möchten. Die Reihenfolge, in der Sie sndbug und rcvbuf angeben, ist beliebig.
Mit der Option wait oder nowait.wait wird angegeben, dass der Dämon ein Einzelthreaddämon ist und die nächste Anforderung erst bedienen kann, wenn die erste abgeschlossen ist. Wenn nowait angegeben ist, setzt INETD bei Empfang einer Verbindungsanforderung an einem Datenstromsocket ein 'accept' ab. Wenn 'wait' angegeben ist, muss der Server das 'accept' absetzen, sofern es sich um einen Datenstromsocket handelt.
Der Wert max gibt die maximal zulässige Anzahl von Benutzern an, die innerhalb eines Intervalls von 60 Sekunden einen Service anfordern dürfen. Der Standardwert liegt bei 40. Wird der Maximalwert überschritten, wird der Service-Port geschlossen.
Benutzer-ID ist die Benutzer-ID, unter der der verzweigte Dämon ausgeführt werden muss. Diese Benutzer-ID kann von der INETD-Benutzer-ID abweichen. Welche Berechtigungen dieser Benutzer-ID erteilt werden, hängt von den Anforderungen des Service ab. Die INETD-Benutzer-ID benötigt die Berechtigung BPX.DAEMON, um den verzweigten Prozess auf diese Benutzer-ID umzuschalten.
Der optionale Wert Gruppe ist durch einen Punkt (.) von der Benutzer-ID getrennt und ermöglicht die Ausführung des Servers mit einer Gruppen-ID, die von der Standardgruppen-ID für diese Benutzer-ID abweicht.
INETD verwendet ETC.SERVICES, um den Services, die von INETD unterstützt werden müssen, Portnummern und Protokolle zuzuordnen. Diese Datei kann eine MVS-Datei oder eine z/OS UNIX-Datei sein. Ein Beispiel ist in SEZAINST(SERVICES) enthalten, das auch unter /usr/lpp/tcpip/samples/services verfügbar ist. Die Suchreihenfolge für ETC.SERVICES hängt davon ab, ob INETD mit einer z/OS UNIX-Methode oder einer nativen MVS-Methode gestartet wird.
Für die Spezifikation der Serviceinformationen gelten die folgenden Syntaxregeln:
Jeder Eintrag umfasst vier positionsgebundene Felder im folgenden Format:
Servicename Portnummer/Protokoll Aliasnamen
Für den Zugriff auf ETC.SERVICES unter z/OS UNIX wird diese Suchreihenfolge verwendet. Die Suche endet mit der ersten gefundenen Datei:
USERID ist die Benutzer-ID, die zum Starten von INETD verwendet wird.
.HLQ repräsentiert den Wert der Anweisung DATASETPREFIX in der Basiskonfigurationsdatei des Resolvers, der verwendet wird, wenn er aufgefunden wird. Andernfalls wird der Standard-HLQ TCPIP verwendet.
Für den Zugriff auf ETC.SERVICES in der nativen MVS-Umgebung wird diese Suchreihenfolge verwendet. Die Suche endet mit der ersten gefundenen Datei:
Die der DD-Anweisung SERVICES zugeordnete Datei wird verwendet.
USERID ist die Benutzer-ID, die zum Starten von INETD verwendet wird.
.JOBNAME ist der in der JCL-Anweisung JOB angegebene Name für Batch-Jobs oder der Prozedurname für eine gestartete Prozedur.
HLQ repräsentiert den Wert der Anweisung DATASETPREFIX in der Basiskonfigurationsdatei des Resolvers, der verwendet wird, wenn er aufgefunden wird. Andernfalls wird der Standard-HLQ TCPIP verwendet.
Verwechseln Sie nicht die PORT-Definitionen (oder PORTRANGE-Definitionen) in PROFILE.TCPIP mit Ports, die in ETC.SERVICES definiert sind. Diese Ports werden jeweils für verschiedene Zwecke verwendet. Anhand der in PROFILE.TCPIP definierten Ports stellt TCPIP fest, ob ein Port für einen bestimmten Service reserviert ist. ETC.SERVICES wird von INETD verwendet, um einem Service einen Port zuzuordnen.
Wenn INETD eine Anforderung an einem überwachten Port empfängt, richtet er eine untergeordnete Prozessverzweigung (mit dem angeforderten Service) ein, die die Bezeichnung inetdx hat. Hier steht inetd für den Jobnamen für INETD (der von der Startmethode abhängig ist) und x für eine einstellige Zahl.
Dies kompliziert die Portreservierung. Wenn ein überwachter INETD-Port in PROFILE.TCPIP reserviert ist, sollte der Name der gestarteten JCL-Prozedur für den z/OS UNIX-Kernel-Adressraum verwendet werden, damit fast jeder Prozess an den Port gebunden werden kann. Dieser Name ist normalerweise OMVS, sofern im Parameter STARTUP_PROC des PARMLIB-Members BPXPRMxx nicht explizit ein anderer Name angegeben ist.
In der nachfolgenden Auflistung ist erläutert, wie der Jobname ausgehend von der Umgebung, in der die Anwendung ausgeführt wird, bestimmt werden kann:
Der INETD-Prozess erstellt eine temporäre Datei /etc/inetd.pid, die die Prozess-ID (PID) des derzeit ausgeführten Dämons INETD enthält. Mithilfe dieses PID-Wertes werden syslog-Einträge identifiziert, die von dem INETD-Prozess stammen. Dieser PID-Wert wird außerdem für Befehle bereitgestellt, die einen solchen Wert benötigen, z. B. kill. Darüber hinaus wird die PID als Sperrmechanismus verwendet, um zu verhindern, dass mehr als ein INETD-Prozess aktiv ist.
Die z/OS UNIX-Implementierung von INETD befindet sich standardmäßig in /usr/sbin/inetd und unterstützt zwei optionale, nicht positionsgebundene Startparameter:
/usr/sbin/inetd [-d] [inetd.conf]
Sie sollten INETD während des IPL starten. Am häufigsten geschieht dies von /etc/rc oder /etc/inittab aus (nur unter z/OS ab Version 1.8). Sie können den Dämon auch von einem Job oder einer gestarteten Task aus starten, indem Sie BPXBATCH verwenden, oder in einer Shellsitzung eines Benutzers mit entsprechender Berechtigung.
Wenn INETD unter z/OS UNIX vom Initialisierungs-Shell-Script /etc/rc gestartet wird, sucht der Dämon in der z/OS UNIX-Suchreihenfolge nach ETC.SERVICES. Eine Beispieldatei /etc/rc ist im Lieferumfang als /samples/rc enthalten. Zum Starten von INETD können die folgenden Beispielbefehle verwendet werden.
# Start INETD _BPX_JOBNAME='INETD' /usr/sbin/inetd /etc/inetd.conf & sleep 5
Unter z/OS ab Version 1.8 gibt es eine alternative Methode (/etc/inittab), um während der Initialisierung von z/OS UNIX Befehle abzusetzen. Bei Verwendung von /etc/inittab haben Sie die Möglichkeit, den Parameter respawn zu definieren, der den Prozess automatisch neu startet, wenn er beendet ist. (Für einen zweiten Neustart innerhalb von 15 Minuten wird ein WTOR an den Bediener gesendet.) Wenn INETD unter Verwendung von /etc/inittab gestartet wird, sucht der Dämon in der z/OS UNIX-Suchreihenfolge nach ETC.SERVICES. Eine Beispieldatei /etc/inittab ist im Lieferumfang als /samples/inittab enthalten. Zum Starten von INETD kann der folgende Beispielbefehl verwendet werden.
# Start INETD inetd::respfrk:/usr/sbin/inetd /etc/inetd.conf
Die Startmethode BPXBATCH funktioniert für gestartete Tasks und für Benutzerjobs. Vergessen Sie nicht, dass INETD ein Hintergrundprozess ist, sodass der BPXBATCH-Schritt, der INETD startet, innerhalb weniger Sekunden nach dem Start beendet ist. Wenn INETD von BPXBATCH gestartet wird, sucht der Dämon in der z/OS UNIX-Suchreihenfolge nach ETC.SERVICES. Die im folgenden Codebeispiel aufgelistete JCL ist eine Beispielprozedur zum Starten von INETD. (Der Schritt KILL entfernt einen ggf. vorhandenen aktiven INETD-Prozess.)
//INETD PROC PRM= //* //KILL EXEC PGM=BPXBATCH,REGION=0M, // PARM='SH ps -e | grep inetd | cut -c 1-10 | xargs -n 1 kill' //* //INETD EXEC PGM=BPXBATCH,REGION=0M, // PARM='PGM /usr/sbin/inetd &PRM' //STDERR DD SYSOUT=* //* STDIN, STDOUT und STDENV nehmen standardmäßig den Wert /dev/null an. //*
// PARM='PGM /usr/sbin/inetd //''SYS1.TCPPARMS(INETCONF)'' &PRM'
Wenn INETD von einer Shellsitzung aus gestartet wird, verwendet der Dämon die z/OS UNIX-Suche nach ETC.SERVICES. Die folgenden Beispielbefehle können (von einer Person mit ausreichender Berechtigung) zum Stoppen und Starten von INETD verwendet werden. (# ist die z/OS UNIX-Eingabeaufforderung.)
# ps -e | grep inetd 7 ? 0:00 /usr/sbin/inetd # kill 7 # _BPX_JOBNAME='INETD' /usr/sbin/inetd &
INETD ist ein z/OS UNIX-Prozess und erfordert daher, dass die Sicherheitssoftware gültige OMVS-Definitionen für die INETD zugeordnete Benutzer-ID enthält. Für die Benutzer-ID müssen UID, HOME und PROGRAM gesetzt sein. Außerdem muss GID für die Standardgruppe des Benutzers gesetzt sein. Wenn INETD von /etc/rc oder /etc/inittab gestartet wird, wird die Benutzer-ID vom z/OS UNIX-Kernel übernommen. Standardmäßig lautet sie OMVSKERN.
ADDGROUP OMVSGRP OMVS(GID(1)) ADDUSER OMVSKERN DFLTGRP(OMVSGRP) NOPASSWORD + OMVS(UID(0) HOME('/') PROGRAM('/bin/sh'))
INETD ist ein Dämon, der Zugriff auf Funktionen wie setuid() haben muss. Die Benutzer-ID, mit der INETD gestartet wird, benötigt daher für das Profil BPX.DAEMON in der Klasse FACILITY die Zugriffsberechtigung READ. Wenn das Profil nicht definiert ist, muss zwingend UID 0 verwendet werden.
PERMIT BPX.DAEMON CLASS(FACILITY) ACCESS(READ) ID(OMVSKERN)
Die INETD-Benutzer-ID benötigt außerdem die Zugriffsberechtigung EXECUTE für das Programm inetd (/usr/sbin/inetd), die Berechtigung READ für den Zugriff auf die Dateien inetd.conf und ETC.SERVICES sowie die Zugriffsberechtigung WRITE für /etc/inetd.pid. Wenn Sie INETD ohne UID 0 ausführen möchten, können Sie für das Profil SUPERUSER.FILESYS in der Klasse UNIXPRIV die Zugriffsberechtigung CONTROL einrichten, damit die erforderlichen Rechte für z/OS UNIX-Dateien vorhanden sind.
Programme, die eine Dämonberechtigung benötigen, müssen programmgesteuert sein, wenn BPX.DAEMON in der Klasse FACILITY definiert ist. Bei Verwendung des INETD-Standardprogramms (/usr/sbin/inetd) ist dies bereits der Fall. Für Kopien oder eine angepasste Version müssen Sie die Programmsteuerung jedoch manuell definieren. Mit dem Befehl extattr +p können Sie eine z/OS UNIX-Datei zu einer programmgesteuerten Datei machen. Mit der RACF-Klasse PROGRAM können Sie aus einem MVS-Lademodul ein programmgesteuertes Modul machen.
Systemprogrammierer, die INETD von ihrer Shellsitzung aus neu starten müssen, verwenden ihre Berechtigungen für den Start von INETD. Deshalb müssen sie dieselben Rechte wie die reguläre INETD-Benutzer-ID haben. Darüber hinaus benötigen sie die Berechtigung, den INETD-Prozess aufzulisten und zu stoppen. Diese Berechtigung kann auf verschiedenen Wegen erteilt werden.
Für Benutzer-IDs von Personen wird dies nicht empfohlen, weil es keine z/OS UNIX-bezogenen Einschränkungen gibt.
Über den Befehl su kann der Benutzer ein Benutzer mit der UID 0 werden. Dies ist die empfohlene Konfiguration.
In der Veröffentlichung UNIX System Services Command Reference (IBM Form SA22-7802) erfahren Sie mehr über die Befehle extattr und su. Weitere Informationen zur Klasse UNIXPRIV und zu BPX.*-Profilen in der Klasse FACILITY finden Sie in der Veröffentlichung UNIX System Services Planning (IBM Form GA22-7800). Weitere Informationen zum Definieren von OMVS-Segmenten und zur Klasse PROGRAM enthält der Security Server RACF Security Administrator's Guide (IBM Form SA22-7683).
Developer for System z ist bei der Verwaltung von REXEC und/oder SSH auf INETD angewiesen. Das Produkt kann zusätzliche Anforderungen stellen, die über die oben beschriebenen Anforderungen an die INETD-Konfiguration hinausgehen.
REXEC (oder SSH) wird für die beiden folgenden Zwecke verwendet. Lesen Sie hierzu auch den Abschnitt REXEC (oder SSH) verwenden (optional).
Die fernen Aktionen in z/OS UNIX-Unterprojekten erfordern keine speziellen Einstellungen. Für die alternative Startmethode für den RSE-Server sind jedoch spezielle Einstellungen erforderlich.
Die Umgebungseinstellungen von INETD werden übergeben, wenn ein Prozess gestartet wird. Die Berechtigungen für die INETD-Benutzer-ID müssen ordnungsgemäß gesetzt sein, damit INETD den RSE-Server starten kann.
Der REXEC-Dämon (oder SSH-Dämon), der von INETD gestartet wird, wenn ein Client eine Verbindung mit dem Port 512 (bzw. zum Port 22) herstellt, führt die Authentifizierung durch, startet den RSE-Server und gibt die Portnummer für die weitere Kommunikation an den Client zurück. Die dem RSE-Dämon (SSH-Dämon) in inetd.conf zugeordnete Benutzer-ID benötigt hierfür die folgenden Berechtigungen:
Dieser Anhang soll Sie bei einigen allgemeinen Problemen unterstützen, die beim Konfigurieren von APPC (Advanced Program-to-Program Communication) oder beim Überprüfen oder Modifizieren einer vorhandenen Konfiguration auftreten könnten.
Zusätzliche Informationen zur APPC-Verwaltung und zu den nachfolgend beschriebenen PARMLIB-Membern enthalten die Veröffentlichungen MVS Planning: APPC/MVS Management (IBM Form SA22-7599) und MVS Initialization and Tuning Reference (IBM Form SA22-7592).
Beachten Sie, dass es sich nicht um eine komplette Konfiguration für APPC handelt. Das Beispiel hebt nur einige wichtige Aspekte hervor, die auf Ihren Standort anwendbar sein könnten.
Das Member SYS1.SAMPLIB(ATBALL) enthält eine Liste und Beschreibungen aller APPC-bezogenen Member (Beispielmember) in SYS1.SAMPLIB.
APPC/MVS speichert die Konfigurationsdaten in den folgenden SYS1.PARMLIB-Membern und in zwei VSAM-Dateien:
Ein Transaktionsprogramm ist ein Anwendungsprogramm, das über APPC mit einem Transaktionsprogramm auf demselben oder einem anderen System kommuniziert, um auf Ressourcen zuzugreifen. Die APPC-Konfiguration für Developer for System z aktiviert ein neues Transaktionsprogramm mit dem Namen FEKFRSRV, das auch als TSO Commands Service bezeichnet wird.
Der folgende Job ist eine Verkettung der Beispielmember SYS1.SAMPLIB(ATBTPVSM) und SYS1.SAMPLIB(ATBSIVSM) und kann zum Definieren der APPC-VSAMs verwendet werden.
//APPCVSAM JOB <Jobparameter> //* //* ACHTUNG: Dies ist keine JCL-Prozedur und kein vollständiger Job. //* Vor Verwendung dieses Beispiels müssen Sie die folgenden //* Änderungen vornehmen: //* 1. Passen Sie die Jobparameter an Ihre Systemanforderungen an. //* 2. Ersetzen Sie ****** durch die Platteneinheit für die APPC-VSAMs. //* //TP EXEC PGM=IDCAMS //SYSPRINT DD SYSOUT=* //SYSIN DD * DEFINE CLUSTER (NAME(SYS1.APPCTP) - VOLUME(******) - INDEXED REUSE - SHAREOPTIONS(3 3) - RECORDSIZE(3824 7024) - KEYS(112 0) - RECORDS(300 150)) - DATA (NAME(SYS1.APPCTP.DATA)) - INDEX (NAME(SYS1.APPCTP.INDEX)) //* //SI EXEC PGM=IDCAMS //SYSPRINT DD SYSOUT=* //SYSIN DD * DEFINE CLUSTER (NAME(SYS1.APPCSI) - VOLUME(******) - INDEXED REUSE - SHAREOPTIONS(3 3) - RECORDSIZE(248 248) - KEYS(112 0) - RECORDS(50 25)) - DATA (NAME(SYS1.APPCSI.DATA)) - INDEX (NAME(SYS1.APPCSI.INDEX)) //*
APPC ist eine Implementierung des LU-6.2-Protokolls der Systemnetzwerkarchitektur (SNA). Die SNA stellt Formate und Protokolle bereit, die verschiedene physische und logische SNA-Komponenten definieren, z. B. die logische Einheit (LU, Logical Unit). LU 6.2 ist ein Typ logischer Einheiten, der speziell für die Kommunikation zwischen Anwendungsprogrammen konzipiert ist.
Wenn Sie die SNA in MVS verwenden möchten, müssen Sie VTAM (Virtual Telecommunications Access Method) installieren und konfigurieren. Die APPC-Systemtasks können erst verwendet werden, wenn VTAM aktiv ist.
Der APPC-spezifische Teil der VTAM-Konfiguration umfasst drei Schritte:
Der im Beispielmember SYS1.SAMPLIB(ATBAPPL) verwendete ACBNAME (MVSLU01) kann an die Standards Ihres Standortes angepasst werden. Er muss jedoch mit den Definitionen im Member SYS1.PARMLIB(APPCPMxx) übereinstimmen.
MVSLU01 APPL ACBNAME=MVSLU01, C APPC=YES, C AUTOSES=0, C DDRAINL=NALLOW, C DLOGMOD=APPCHOST, C DMINWNL=5, C DMINWNR=5, C DRESPL=NALLOW, C DSESLIM=10, C LMDENT=19, C MODETAB=LOGMODES, C PARSESS=YES, C SECACPT=CONV, C SRBEXIT=YES, C VPACING=1
Weitere Informationen zur Konfiguration von VTAM enthält der Communications Server IP SNA Network Implementation Guide (IBM FormSC31-8777).
Zur Aktivierung und Unterstützung des Datenaustauschs zwischen Systemen müssen an Standorten LUs (logische Einheiten) definiert werden, zwischen denen Sitzungen stattfinden können. Voraussetzung für eine APPC/MVS-Verarbeitung - auch auf einem einzelnen System - ist, dass an einem Standort mindestens eine LU definiert ist. LUs gehören zu den Elementen, die in SYS1.PARMLIB(APPCPMxx) definiert werden.
TSO Commands Service erfordert, dass APPC mit einer Basis-LU für die Bearbeitung ein- und abgehender Anforderungen konfiguriert ist.
Die LU-Definition muss dem Member SYS1.PARMLIB(APPCPMxx) hinzugefügt werden und die Parameter BASE und SCHED(ASCH) enthalten. Das Member APPCPMxx gibt auch an, welche VSAM-Dateien mit Transaktionsprofilen (TP) und Nebeninformationen (SI) verwendet werden sollen.
Das folgende Codebeispiel zeigt ein SYS1.PARMLIB(APPCPMxx)-Member, das für TSO Commands Service verwendet werden kann.
LUADD ACBNAME(MVSLU01) BASE SCHED(ASCH) TPDATA(SYS1.APPCTP) SIDEINFO DATASET(SYS1.APPCSI)
Wenn ein System mehrere LU-Namen hat, müssen Sie ggf. Änderungen vornehmen, je nachdem, welche LU das System als Basis-LU auswählt. Die Basis-LU für das System wird wie folgt bestimmt:
Falls es auf Ihrem System eine LU mit den Parametern BASE und NOSCHED gibt, wird diese LU als Basis-LU verwendet werden, TSO Commands Service würde jedoch nicht funktionieren, weil diese LU keinen Transaktionsscheduler für die Bearbeitung von Anforderungen an die Transaktion FEKFRSRV hat. Wenn Sie den Parameter NOSCHED dieser LU nicht entfernen können, setzen Sie die Umgebungsvariable _FEKFSCMD_PARTNER_LU in rsed.envvars auf die LU, für die die Parameter BASE und SCHED(ASCH) definiert sind. Beispiel:
_FEKFSCMD_PARTNER_LU=MVSLU01
Weitere Informationen zu rsed.envvars enthält der Abschnitt RSE-Konfigurationsdatei rsed.envvars.
Der APPC/MVS-Transaktionsscheduler (mit dem Standardnamen ASCH) leitet bei eingehenden Dialoganforderungen Transaktionsprogramme ein und steuert den zeitlichen Ablauf dieser Programme. Das Member SYS1.PARMLIB(ASCHPMxx) steuert seine Funktionen unter anderem mit Transaktionsklassendefinitionen.
Die für TSO Commands Service verwendete APPC-Transaktionsklasse muss genug APPC-Initiatoren haben, damit für jeden Benutzer von Developer for System z ein Initiator verfügbar ist.
TSO Commands Service erfordert außerdem die Angabe der Standardspezifikationen in den Abschnitten OPTIONS und TPDEFAULT.
Das folgende Codebeispiel zeigt das Member SYS1.PARMLIB(ASCHPMxx), das für TSO Commands Service verwendet werden kann.
CLASSADD CLASSNAME(A) MAX(20) MIN(1) MSGLIMIT(200) OPTIONS DEFAULT(A) TPDEFAULT REGION(2M) TIME(5) MSGLEVEL(1,1) OUTCLASS(X)
Die in den obigen Schritten dokumentierten Konfigurationsänderungen können jetzt aktiviert werden. Hierfür gibt es - je nach vorliegender Situation - verschiedene Möglichkeiten:
Fügen Sie diese Befehle zu SYS1.PARMLIB(COMMNDxx) hinzu, damit sie beim Systemstart gestartet werden.
Mit den Konsolbefehlen D APPC und D ASCH kann die APPC-Konfiguration überprüft werden. Weitere Informationen zu den genannten Konsolbefehlen enthält die Veröffentlichung MVS System Commands (IBM Form GC28-1781).
Wenn APPC/MVS aktiv ist, kann TSO Commands Service von Developer for System z definiert werden. Lesen Sie hierzu die Beschreibung im Abschnitt APPC-Transaktion für TSO Commands Service (optional).
Für eine dokumentierte Definition der APPC-Transaktion müssen Sie FEK.#CUST.JCL(FEKAPPCC) anpassen und übergeben.
Die APPC-Transaktion kann auch interaktiv über die APPC-ISPF-Schnittstelle definiert werden. Diese Schnittstelle ist in einem White Paper dokumentiert. In diesem White Paper ist auch beschrieben, wie die APPC-Transaktion für die Erfassung benutzerspezifischer Accountinformationen konfiguriert werden kann.
Das White Paper APPC and WebSphere Developer für System z (IBM Form SC23-5885-00) ist in der Internetbibliothek für Developer for System z unter http://www-306.ibm.com/software/awdtools/rdz/library/ verfügbar.
// PARM='ISPSTART CMD(%FEKFRSRV TIMEOUT=60) NEWAPPL(ISR) NESTMACS'
Developer for System z unterstützt alternative Optionen für die APPC- und VTAM-Konfiguration, von denen nachfolgend einige dokumentiert sind.
Der Standardtransaktionsname für TSO Commands Service ist "FEKFRSRV". Lesen Sie hierzu die Informationen unter APPC-Transaktion für TSO Commands Service (optional). Im gleichen Abschnitt ist unter anderem angegeben, dass dieser Name geändert werden kann, wenn die Transaktion für APPC definiert wird.
Falls Sie den Transaktionsnamen in APPC ändern, muss der neue Name _FEKFSCMD_TP_NAME_ in rsed.envvars zugeordnet werden. Lesen Sie hierzu die Beschreibung im Abschnitt RSE-Konfigurationsdatei rsed.envvars.
APPC ist ein Kommunikationsprotokoll, über das ein Programm (der Partnerknoten) mit einem Programm auf dem Host (dem lokalen Knoten) interagieren kann. Bei Developer for System z sind der Partnerknoten (TSO Commands-Server) und der lokale Knoten (RSE-Server) auf demselben z/OS-System aktiv. Standardmäßig verwenden beide für die Kommunikation untereinander dieselbe Basis-LU-Definition.
In rsed.envvars können Sie in der Anweisung _FEKFSCMD_PARTNER_LU_ einen alternativen Partner-LU-Namen für TSO Commands Service angeben. Lesen Sie hierzu die Beschreibung im Abschnitt RSE-Konfigurationsdatei rsed.envvars. Die lokale LU kann nicht geändert werden und muss immer eine gültige Basis-LU (mit den Schlüsselwörtern BASE und SCHED) sein.
VTAM unterstützt eine sichere APPC-Konfiguration, bei der die Kommunikation zwischen der Partner-LU und der lokalen LU für die Sicherheitssoftware definiert werden muss.
Sie können diese Konfiguration aktivieren, indem Sie zur VTAM-Definition der lokalen LU (Basis-LU) VERIFY=REQUIRED hinzufügen. Die Sicherheitsdefinitionen müssen in der Klasse APPCLU erfolgen. Lesen Sie die diesbezüglichen Informationen in der Veröffentlichung MVS Planning: APPC/MVS Management (IBM Form SA22-7599).
Wenn diese Konfiguration in VTAM aktiv ist und die Konfiguration in Ihrer Sicherheitssoftware noch nicht abgeschlossen ist, kann die Kommunikation mit TSO Commands Service nicht initialisiert werden. Das Systemprotokoll enthält in dem Fall keine Nachricht, dass VTAM den Aufbau der Verbindung zurückgewiesen hat. Der APPC-IVP-Test (fekfivpa) scheitert mit der Nachricht "Return code 1 - Allocate Failure no retry".
In diesem Anhang werden die Hostvoraussetzungen und die zusätzlich erforderliche Software für diese Version von Developer for System z aufgelistet.
Eine aktuelle Liste der erforderlichen und optionalen Voraussetzungen enthält die Veröffentlichung Rational Developer for System z Prerequisites (IBM Form SC23-7659) in der Onlinebibliothek für Developer for System z unter http://www-01.ibm.com/software/awdtools/rdz/library/.
Die in diesem Abschnitt aufgelisteten Produkte sind alle zum Zeitpunkt der Veröffentlichung dieses Handbuchs verfügbar. Rufen Sie die Website "IBM Software Support Lifecycle" unter http://www.ibm.com/software/support/lifecycle/ auf, um zu prüfen, ob ein ausgewähltes Produkt zu dem Zeitpunkt, an dem Sie die zugehörige Funktion in Developer for System z verwenden möchten, immer noch verfügbar ist.
Für die Verwendung von Developer for System z ist die folgende Umgebung mit den entsprechenden Voraussetzungen erforderlich:
Auf dem Host muss eine der folgenden Versionen installiert sein:
Programmnummer | Produktname | Erforderliche PTFs oder Service-Level |
---|---|---|
5694-A01 | z/OS Version 1.11 |
ISPF:
TCP/IP:
|
5694-A01 | z/OS Version 1.10 |
ISPF:
TCP/IP:
|
5694-A01 | z/OS Version 1.9 |
ISPF:
TCP/IP:
|
5694-A01 | z/OS Version 1.8 |
ISPF:
TCP/IP:
|
Die zugehörige Produktwebsite ist:
Um Developer for System z installieren zu können, muss eine der folgenden Versionen installiert sein:
Programmnummer | Produktname | Erforderliche PTFs oder Service-Level |
---|---|---|
5655-G44 | IBM System Modification Program Extended (SMP/E) für z/OS Version 3.5 | Kein PTF oder Service-Level erforderlich |
5655-G44 | IBM System Modification Program Extended (SMP/E) für z/OS Version 3.4 | Kein PTF oder Service-Level erforderlich |
Die zugehörige Produktwebsite ist:
Für eine Unterstützung von Anwendungen, die Remote Systems Explorer (RSE) verwenden, muss eine der folgenden Versionen auf dem Host installiert sein:
Programmnummer | Produktname | Erforderliche PTFs oder Service-Level |
---|---|---|
5655-R32 | IBM 64-Bit SDK for z/OS, Java 2 Technology Edition Version 6.0 | Service-Release 7 |
5655-R31 | IBM 31-Bit SDK for z/OS, Java 2 Technology Edition Version 6.0 | Service-Release 7 |
5655-N99 | IBM 64-Bit SDK for z/OS, Java 2 Technology Edition Version 5.0 | Service-Release 11 |
5655-N98 | IBM 31-Bit SDK for z/OS, Java 2 Technology Edition Version 5.0 | Service-Release 11 |
Die zugehörige Produktwebsite ist:
Die in diesem Abschnitt aufgelisteten Produkte und angegebenen Softwareprogramme sind zur Unterstützung bestimmter Features von Developer for System z erforderlich. Der Workstation-Client von Developer for System z kann ohne diese vorausgesetzten Produkte fehlerfrei installiert werden. Zur Laufzeit müssen die als erforderlich angegebenen Produkte jedoch installiert und betriebsbereit sein, damit das entsprechende Feature ordnungsgemäß funktionieren kann.
Programmnummer | Produktname | Erforderliche PTFs oder Service-Level |
---|---|---|
5694-A01 | z/OS Version 1.11 |
HLASM Kein PTF oder Service-Level erforderlich
XL C/C++ Kein PTF oder Service-Level erforderlich
SCLM Kein PTF oder Service-Level erforderlich
LE (PL/I) Kein PTF oder Service-Level erforderlich
TN3270 Kein PTF oder Service-Level erforderlich |
5694-A01 | z/OS Version 1.10 |
HLASM Kein PTF oder Service-Level erforderlich
XL C/C++ Kein PTF oder Service-Level erforderlich
SCLM Kein PTF oder Service-Level erforderlich
LE (PL/I) Kein PTF oder Service-Level erforderlich
TN3270 Kein PTF oder Service-Level erforderlich |
5694-A01 | z/OS Version 1.9 |
HLASM Kein PTF oder Service-Level erforderlich
XL C/C++ Kein PTF oder Service-Level erforderlich
SCLM
LE (PL/I) Kein PTF oder Service-Level erforderlich
TN3270 Kein PTF oder Service-Level erforderlich |
5694-A01 | z/OS Version 1.8 |
HLASM Kein PTF oder Service-Level erforderlich
XL C/C++ Kein PTF oder Service-Level erforderlich
SCLM
LE (PL/I)
TN3270 Kein PTF oder Service-Level erforderlich |
Die zugehörige Produktwebsite ist:
Die zugehörige Produktwebsite ist:
Die zugehörige Produktwebsite ist:
Die zugehörige Produktwebsite ist:
Die zugehörige Produktwebsite ist:
Die zugehörige Produktwebsite ist:
Um in Developer for System z entwickelte oder bearbeitete COBOL-Programme kompilieren zu können, muss eine der folgenden Versionen auf dem Host installiert sein:
Programmnummer | Produktname | Erforderliche PTFs oder Service-Level |
---|---|---|
5655-S71 | IBM Enterprise COBOL für z/OS Version 4.2 | Kein PTF oder Service-Level erforderlich |
5655-S71 | IBM Enterprise COBOL für z/OS Version 4.1 | Kein PTF oder Service-Level erforderlich |
5535-G53 | IBM Enterprise COBOL für z/OS Version 3.4 | Kein PTF oder Service-Level erforderlich |
Die zugehörige Produktwebsite ist:
Um in Developer for System z entwickelte oder bearbeitete PL/I-Programme kompilieren zu können, muss eine der folgenden Versionen auf dem Host installiert sein:
Programmnummer | Produktname | Erforderliche PTFs oder Service-Level |
---|---|---|
5655-H31 | IBM Enterprise PL/I für z/OS Version 3.9 | Kein PTF oder Service-Level erforderlich |
5655-H31 | IBM Enterprise PL/I für z/OS Version 3.8 | Kein PTF oder Service-Level erforderlich |
5655-H31 | IBM Enterprise PL/I für z/OS Version 3.7 | Kein PTF oder Service-Level erforderlich |
5655-H31 | IBM Enterprise PL/I für z/OS Version 3.6 | Kein PTF oder Service-Level erforderlich |
Die zugehörige Produktwebsite ist:
Für eine Unterstützung von fernem Debugging aus Developer for System z heraus muss eine der folgenden Versionen auf dem Host installiert sein:
Programmnummer | Produktname | Programmiersprache | Erforderliche APARs, PTFs oder Service-Level |
---|---|---|---|
5655-V50 | IBM Debug Tool for z/OS Version 10.1 | COBOL, PL/I, C/C++, Assembler und zusätzliche Features | Alle verfügbaren Korrekturen und Service-Level |
5655-U27 | IBM Debug Tool for z/OS Version 9.1 | COBOL, PL/I, C/C++, Assembler und zusätzliche Features | Alle verfügbaren Korrekturen und Service-Level |
5655-S16 | IBM Debug Tool Utilities and Advanced Functions for z/OS Version 8.1.0 | COBOL, PL/I, C/C++, Assembler und zusätzliche Features | Alle verfügbaren Korrekturen und Service-Level |
5655-S17 | IBM Debug Tool for z/OS Version 8.1.0 | COBOL, PL/I, Assembler, C/C++ | Alle verfügbaren Korrekturen und Service-Level |
Die zugehörige Produktwebsite ist:
Ab Version 9 werden Debug Tool for z/OS sowie Debug Tool Utilities and Advanced Functions in einem Angebot zusammengefasst.
Für eine Unterstützung von Anwendungen mit eingebetteten CICS-Anweisungen muss eine der folgenden Versionen installiert sein:
Programmnummer | Produktname | Erforderliche PTFs oder Service-Level |
---|---|---|
5655-S97 | IBM CICS Transaction Server für z/OS Version 4.1 | Kein PTF oder Service-Level erforderlich |
5697-E93 | IBM CICS Transaction Server für z/OS Version 3.2 | UK34221 |
5697-E93 | IBM CICS Transaction Server für z/OS Version 3.1 | UK15767, UK15764, UK11782, UK11294, UK12233, UK12521, UK15261, UK15271, UK34221, UK34078 |
Die zugehörige Produktwebsite ist:
Eine vollständige Liste der Spezifikationen für die Laufzeitanforderungen finden Sie in der Dokumentation zu Enterprise Service Tools im Information Center für IBM Rational Developer for System z unter http://publib.boulder.ibm.com/infocenter/ratdevz/v7r6/.
Für eine Unterstützung von Anwendungen, die IMS Database und Data Communications verwenden, muss eine der folgenden Versionen auf dem Host installiert sein:
Programmnummer | Produktname | Erforderliche PTFs oder Service-Level |
---|---|---|
5635-A02 | IBM IMS Version 11.1 | Kein PTF oder Service-Level erforderlich |
5635-A01 | IBM IMS Version 10.1 | Kein PTF oder Service-Level erforderlich |
5655-J38 | IBM IMS Version 9.1 | Kein PTF oder Service-Level erforderlich |
Die zugehörige Produktwebsite ist:
Für eine Unterstützung von DB2 muss eine der folgenden Versionen auf dem Host installiert sein:
Programmnummer | Produktname | Erforderliche PTFs oder Service-Level |
---|---|---|
5635-DB2 | IBM DB2 für z/OS Version 9.1 | Kein PTF oder Service-Level erforderlich |
5625-DB2 | IBM DB2 Universal Database für z/OS Version 8.1 | Kein PTF oder Service-Level erforderlich |
Die zugehörige Produktwebsite ist:
Für eine Jazz-basierte Quellcodeverwaltung mithilfe von fernen Projekten in Developer for System z muss die folgende Version installiert sein.
Programmnummer | Produktname | Erforderliche PTFs oder Service-Level |
---|---|---|
5724-V82 | Rational Team Concert for System z - Server Version 2.0 |
FMID HAHA200 - Team Server
FMID HAHB200 - Toolkit
FMID HAHC200 - Job Monitor
FMID HAHD200 - BuildForge Agent
|
Die zugehörige Produktwebsite ist:
Für eine Unterstützung der Integration von File Manager muss eine der folgenden Versionen auf dem Host installiert sein:
Programmnummer | Produktname | Erforderliche PTFs oder Service-Level |
---|---|---|
5655-U29 | IBM File Manager for z/OS Version 10.1 |
|
Die zugehörige Produktwebsite ist:
Für eine Unterstützung der Integration von Fault Analyzer muss eine der folgenden Versionen auf dem Host installiert sein:
Programmnummer | Produktname | Erforderliche PTFs oder Service-Level |
---|---|---|
5655-V51 | IBM Fault Analyzer Version 10.1 | Kein PTF oder Service-Level erforderlich |
5655-U28 | IBM Fault Analyzer Version 9.1 | Kein PTF oder Service-Level erforderlich |
5655-S15 | IBM Fault Analyzer Version 8.1 | Kein PTF oder Service-Level erforderlich |
Die zugehörige Produktwebsite ist:
Um SCLM Developer Toolkit verwenden zu können, muss eine der folgenden Versionen auf dem Host installiert sein:
Programmnummer | Produktname | Erforderliche PTFs oder Service-Level |
---|---|---|
5695-014 | IBM Library for REXX on zSeries Version 1.4 | Kein PTF oder Service-Level erforderlich |
5695-014 | IBM Library for REXX on zSeries Alternate Library Version 1.4.0 (FMIDs HWJ9143, JWJ9144) | Kein PTF oder Service-Level erforderlich |
Auf der Produktwebsite steht eine Version von REXX/370 Alternate Library zur Verfügung:
Wenn Sie für ein sicheres Deployment in SCLM Developer Toolkit sftp oder scp verwenden möchten, müssen die IBM Ported Tools für z/OS (unter z/OS UNIX) installiert sein.
Auf der Produktwebsite steht eine Version von IBM Ported Tools for z/OS zur Verfügung:
Für JAVA/J2EE-Builds mit SCLM Developer Toolkit muss Apache Ant (unter z/OS UNIX) installiert sein.
Apache Ant ist ein Java-basiertes Open-Source-Build-Tool, das Sie von der Produktwebsite herunterladen können:
CA Endevor® Software Change Manager Release 12 muss installiert sein, um die Schnittstelle für CA Endevor® SCM in Developer for System z verwenden zu können.
CA Endevor® SCM ist ein Produkt von CA. Die zugehörige Produktwebsite ist:
http://www.ca.com/us/products/product.aspx?ID=259
In diesem Dokument werden die folgenden Veröffentlichungen referenziert:
Titel der Veröffentlichung | Formnummer | Bezug | Referenzwebsite |
---|---|---|---|
Java Diagnostic Guide | SC34-6650 | Java 5.0 | http://www.ibm.com/developerworks/java/jdk/diagnosis/ |
Java SDK and Runtime Environment User Guide | / | Java 5.0 | http://www-03.ibm.com/servers/eserver/zseries/software/java/ |
Program Directory for IBM Rational Developer for System z | GI11-8298 | Developer for System z | http://www-306.ibm.com/software/awdtools/rdz/library/ |
Rational Developer for System z Common Access Repository Manager Developer's Guide | SC23-7660 | Developer for System z | http://www-306.ibm.com/software/awdtools/rdz/library/ |
Rational Developer for System z Voraussetzungen | SC23-7659 | Developer for System z | http://www-306.ibm.com/software/awdtools/rdz/library/ |
Rational Developer für System z Handbuch für den Schnelleinstieg in die Hostkonfiguration | GI11-3191 | Developer for System z | http://www-306.ibm.com/software/awdtools/rdz/library/ |
Rational Developer für System z Hostplanung | GI11-3123 | Developer for System z | http://www-306.ibm.com/software/awdtools/rdz/library/ |
SCLM Developer Toolkit Administrator's Guide | SC23-9801 | Developer for System z | http://www-306.ibm.com/software/awdtools/rdz/library/ |
APPC and WebSphere Developer for System z | SC23-5885 | White Paper | http://www-306.ibm.com/software/awdtools/rdz/library/ |
Communications Server IP Configuration Guide | SC31-8775 | z/OS 1.9 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Communications Server IP Configuration Reference | SC31-8776 | z/OS 1.9 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Communications Server IP Diagnosis Guide | GC31-8782 | z/OS 1.9 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Communications Server IP System Administrator's Commands | SC31-8781 | z/OS 1.9 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Communications Server SNA Network Implementation Guide | SC31-8777 | z/OS 1.9 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Communications Server SNA Operations | SC31-8779 | z/OS 1.9 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Cryptographic Services System SSL Programming | SC24-5901 | z/OS 1.9 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
DFSMS Macro Instructions for Data Sets | SC26-7408 | z/OS 1.9 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
DFSMS Using data sets | SC26-7410 | z/OS 1.9 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Language Environment Customization | SA22-7564 | z/OS 1.9 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Language Environment Debugging Guide | GA22-7560 | z/OS 1.9 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
MVS Initialization and Tuning Guide | SA22-7591 | z/OS 1.9 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
MVS Initialization and Tuning Reference | SA22-7592 | z/OS 1.9 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
MVS JCL Reference | SA22-7597 | z/OS 1.9 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
MVS Planning APPC/MVS Management | SA22-7599 | z/OS 1.9 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
MVS Planning Workload Management | SA22-7602 | z/OS 1.9 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
MVS System Commands | SA22-7627 | z/OS 1.9 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Security Server RACF Command Language Reference | SA22-7687 | z/OS 1.9 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Security Server RACF Security Administrator's Guide | SA22-7683 | z/OS 1.9 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
TSO/E Customization | SA22-7783 | z/OS 1.9 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
TSO/E REXX Reference | SA22-7790 | z/OS 1.9 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
UNIX System Services Command Reference | SA22-7802 | z/OS 1.9 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
UNIX System Services Planning | GA22-7800 | z/OS 1.9 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
UNIX System Services User's Guide | SA22-7801 | z/OS 1.9 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Using REXX and z/OS UNIX System Services | SA22-7806 | z/OS 1.9 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Resource Definition Guide | SC34-6430 | CICS TS 3.1 | http://www-03.ibm.com/systems/z/os/zos/bkserv/zapplsbooks.html |
Resource Definition Guide | SC34-6815 | CICSTS 3.2 | http://www-03.ibm.com/systems/z/os/zos/bkserv/zapplsbooks.html |
Resource Definition Guide | SC34-7000 | CICSTS 4.1 | https://publib.boulder.ibm.com/infocenter/cicsts/v4r1/index.jsp?topic=/com.ibm.cics.ts.home.doc/library/library_html.html |
RACF Security Guide | SC34-6454 | CICS TS 3.1 | http://www-03.ibm.com/systems/z/os/zos/bkserv/zapplsbooks.html |
RACF Security Guide | SC34-6835 | CICSTS 3.2 | http://www-03.ibm.com/systems/z/os/zos/bkserv/zapplsbooks.html |
RACF Security Guide | SC34-7003 | CICSTS 4.1 | https://publib.boulder.ibm.com/infocenter/cicsts/v4r1/index.jsp?topic=/com.ibm.cics.ts.home.doc/library/library_html.html |
Language Reference | SC27-1408 | Enterprise COBOL für z/OS | http://www-03.ibm.com/systems/z/os/zos/bkserv/zapplsbooks.html |
In diesem Dokument werden die folgenden Websites referenziert:
Beschreibung | Referenzwebsite |
---|---|
Developer für System z - Information Center | http://publib.boulder.ibm.com/infocenter/ratdevz/v7r6/index.jsp |
Developer für System z - Support | http://www-306.ibm.com/software/awdtools/rdz/support/ |
Developer für System z - Library | http://www-306.ibm.com/software/awdtools/rdz/library/ |
Homepage von Developer for System z | http://www-306.ibm.com/software/awdtools/rdz/ |
Empfohlene Services für Developer for System z | http://www-01.ibm.com/support/docview.wss?rs=2294&context=SS2QJ2&uid=swg27006335 |
Verbesserungsvorschlag für Developer for System z | https://www.ibm.com/developerworks/support/rational/rfe/ |
z/OS-Internetbibliothek | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Information Center für CICSTS | https://publib.boulder.ibm.com/infocenter/cicsts/v4r1/index.jsp |
Download von Apache Ant | http://ant.apache.org/ |
Java-Keytool-Dokumentation | http://java.sun.com/j2se/1.5.0/docs/tooldocs/solaris/keytool.html |
Homepage der CA-Unterstützung | https://support.ca.com/ |
Die folgenden Veröffentlichungen können Antworten auf Fragen enthalten, die vielleicht bei der Konfiguration erforderlicher Hostkomponenten auftauchen.
Titel der Veröffentlichung | Formnummer | Bezug | Referenzwebsite |
---|---|---|---|
ABCs of z/OS System Programming Volume 9 (z/OS UNIX) | SG24-6989 | Redbook | http://www.redbooks.ibm.com/ |
System Programmer's Guide to: Workload Manager | SG24-6472 | Redbook | http://www.redbooks.ibm.com/ |
TCPIP Implementation Volume 1: Base Functions, Connectivity, and Routing | SG24-7532 | Redbook | http://www.redbooks.ibm.com/ |
TCPIP Implementation Volume 3: High Availability, Scalability, and Performance | SG24-7534 | Redbook | http://www.redbooks.ibm.com/ |
TCP/IP Implementation Volume 4: Security and Policy-Based Networking | SG24-7535 | Redbook | http://www.redbooks.ibm.com/ |
© Copyright IBM Corporation - 2010
Trotz sorgfältiger Bearbeitung können technische Ungenauigkeiten oder Druckfehler in dieser Veröffentlichung nicht ausgeschlossen werden. Die Angaben in diesem Handbuch werden in regelmäßigen Zeitabständen aktualisiert. Die Änderungen werden in Überarbeitungen oder in Technical News Letters (TNLs) bekannt gegeben. IBM kann ohne weitere Mitteilung jederzeit Verbesserungen und/oder Änderungen an den in dieser Veröffentlichung beschriebenen Produkten und/oder Programmen vornehmen.
Verweise in diesen Informationen auf Websites anderer Anbieter dienen lediglich als Benutzerinformationen und stellen keinerlei Billigung des Inhalts dieser Websites dar. Das über diese Websites verfügbare Material ist nicht Bestandteil des Materials für dieses IBM Produkt. Die Verwendung dieser Websites geschieht auf eigene Verantwortung.
Werden an IBM Informationen eingesandt, können diese beliebig verwendet werden, ohne dass eine Verpflichtung gegenüber dem Einsender entsteht.
Lizenznehmer des Programms, die Informationen zu diesem Produkt wünschen mit der Zielsetzung: (i) den Austausch von Informationen zwischen unabhängigen, erstellten Programmen und anderen Programmen (einschließlich des vorliegenden Programms) sowie (ii) die gemeinsame Nutzung der ausgetauschten Informationen zu ermöglichen, wenden sich an folgende Adresse:
Die Bereitstellung dieser Informationen kann unter Umständen von bestimmten Bedingungen - in einigen Fällen auch von der Zahlung einer Gebühr - abhängig sein.
Die Lieferung des im Dokument aufgeführten Lizenzprogramms sowie des zugehörigen Lizenzmaterials erfolgt auf der Basis der IBM Rahmenvereinbarung bzw. der Allgemeinen Geschäftsbedingungen von IBM, der IBM Internationalen Nutzungsbedingungen für Programmpakete oder einer äquivalenten Vereinbarung.
Alle in diesem Dokument enthaltenen Leistungsdaten stammen aus einer kontrollierten Umgebung. Die Ergebnisse, die in anderen Betriebsumgebungen erzielt werden, können daher erheblich von den hier erzielten Ergebnissen abweichen. Einige Daten stammen möglicherweise von Systemen, deren Entwicklung noch nicht abgeschlossen ist. Eine Gewährleistung, dass diese Daten auch in allgemein verfügbaren Systemen erzielt werden, kann nicht gegeben werden. Darüber hinaus wurden einige Daten unter Umständen durch Extrapolation berechnet. Die tatsächlichen Ergebnisse können davon abweichen. Benutzer dieses Dokuments sollten die entsprechenden Daten in ihrer spezifischen Umgebung prüfen.
Alle Informationen zu Produkten anderer Anbieter stammen von den Anbietern der aufgeführten Produkte, deren veröffentlichten Ankündigungen oder anderen allgemein verfügbaren Quellen. IBM hat diese Produkte nicht getestet und kann daher keine Aussagen zu Leistung, Kompatibilität oder anderen Eigenschaften machen. Fragen zu den Leistungsmerkmalen von Produkten anderer Anbieter sind an den jeweiligen Anbieter zu richten.
Die oben genannten Erklärungen bezüglich der Produktstrategien und Absichtserklärungen von IBM stellen die gegenwärtige Absicht von IBM dar, unterliegen Änderungen oder können zurückgenommen werden und repräsentieren nur die Ziele von IBM.
Diese Veröffentlichung enthält Beispiele für Daten und Berichte des alltäglichen Geschäftsablaufes. Sie sollen nur die Funktionen des Lizenzprogramms illustrieren; sie können Namen von Personen, Firmen, Marken oder Produkten enthalten. Alle diese Namen sind frei erfunden; Ähnlichkeiten mit tatsächlichen Namen und Adressen sind rein zufällig.
Diese Veröffentlichung enthält Musteranwendungsprogramme, die in Quellensprache geschrieben sind und Programmiertechniken in verschiedenen Betriebsumgebungen veranschaulichen. Sie dürfen diese Beispielprogramme kostenlos kopieren, ändern und verteilen, wenn dies zu dem Zweck geschieht, Anwendungsprogramme zu entwickeln, zu verwenden, zu vermarkten oder zu verteilen, die mit der Anwendungsprogrammierschnittstelle für die Betriebsumgebung konform sind, für die diese Beispielprogramme geschrieben wurden. Diese Beispiele wurden nicht unter allen denkbaren Bedingungen getestet. IBM kann deshalb nicht garantieren, dass die Zuverlässigkeit, Wartungsfreundlichkeit und Funktion dieser Programme gegeben ist. Die Beispielprogramme werden auf der Grundlage des gegenwärtigen Zustands (auf "as-is"-Basis) und ohne Gewährleistung zur Verfügung gestellt. IBM haftet nicht für Schäden, die durch Verwendung oder im Zusammenhang mit den Beispielprogrammen entstehen.
IBM, das IBM Logo und ibm.com sind Marken oder eingetragene Marken der International Business Machines Corp. Weitere Produkt- und Servicenamen können Marken von IBM oder von anderen Unternehmen sein. Eine aktuelle Liste der IBM Marken finden Sie im Web unter www.ibm.com/legal/copytrade.shtml.
Rational ist eine Marke der International Business Machines Corporation und der Rational Software Corporation in den USA und/oder anderen Ländern.
Intel®, das Intel-Logo, Intel Inside, das Intel Inside-Logo, Intel Centrino, das Intel Centrino-Logo, Celeron, Intel Xeon, Intel SpeedStep, Itanium und Pentium® sind Marken oder eingetragene Marken der Intel Corporation oder deren Tochtergesellschaften in den USA oder anderen Ländern.
Microsoft®, Windows® und das Windows-Logo sind Marken oder eingetragene Marken der Microsoft Corporation in den USA und/oder anderen Ländern.
Java und alle Java-basierten Marken und Logos sind Marken oder eingetragene Marken von Sun Microsystems, Inc. in den USA und/oder anderen Ländern.
UNIX ist eine eingetragene Marke von The Open Group in den USA und anderen Ländern.