Vor Verwendung dieser Informationen sollten die allgemeinen Hinweise im Abschnitt Bemerkungen gelesen werden.
Diese Ausgabe bezieht sich auf IBM Rational Developer für System z Version 7.1.1 (Programmnummer 5724-T07) und, sofern in neuen Ausgaben nichts anderes angegeben ist, auf alle folgenden Releases und Modifikationen.
Veröffentlichungen können über den zuständigen IBM Ansprechpartner oder die zuständige IBM Geschäftsstelle bezogen werden. Veröffentlichungen sind nicht bei der unten angegebenen Adresse erhältlich.
Am Ende dieser Veröffentlichung befindet sich ein Vordruck für ein Antwortschreiben.
Werden an IBM Informationen eingesandt, können diese beliebig verwendet werden, ohne dass eine Verpflichtung gegenüber dem Einsender entsteht.
Diese Veröffentlichung ist eine Übersetzung des Handbuchs
IBM Rational Developer for System z Version 7.1.1 Host Configuration,
IBM Form SC23-7658-01,
herausgegeben von International Business Machines Corporation, USA
(C) Copyright International Business Machines Corporation 2007
(C) Copyright IBM Deutschland GmbH 2007
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 für System z. Es enthält Konfigurationsanweisungen für IBM Rational Developer für System z Server 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 für System z, IBM WebSphere Developer für zSeries und 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 für System z Version 7.1.1 auf ihrem z/OS-Hostsystem installieren und konfigurieren möchten. Voraussetzung für die Verwendung dieses Handbuchs ist, dass Sie mit z/OS-UNIX- und MVS-Hostsystemen vertraut sind.
In diesem Dokument werden die folgenden Veröffentlichungen referenziert:
Titel der Veröffentlichung | IBM Form | Bezug | Referenz-Link |
---|---|---|---|
Java Diagnostic Guide | SC34-6650 | Java 5.0 | http://www.ibm.com/developerworks/java/jdk/diagnosis/index.html |
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-00 | RD/z | http://www-306.ibm.com/software/awdtools/rdz/library/index.html |
Program Directory for IBM Rational Developer for System z Common Access Repository Manager | GI11-8299-00 | RD/z | http://www-306.ibm.com/software/awdtools/rdz/library/index.html |
Program Directory for IBM Software Configuration and Library Manager (SCLM) Developer Toolkit | GI11-8306-00 | RD/z | http://www-306.ibm.com/software/awdtools/rdz/library/index.html |
Rational Developer for System z Application Deployment Manager User's Guide | SC23-7661 | RD/z | http://www-306.ibm.com/software/awdtools/rdz/library/index.html |
Rational Developer for System z Common Access Repository Manager Developer's Guide | SC23-7660 | RD/z | http://www-306.ibm.com/software/awdtools/rdz/library/index.html |
Rational Developer für System z Hostplanung | GI11-3123-00 | RD/z | http://www-306.ibm.com/software/awdtools/rdz/library/index.html |
SCLM Developer Toolkit Installation und Anpassung | SC12-4101 | RD/z | http://www-306.ibm.com/software/awdtools/rdz/library/index.html |
ABCs of z/OS System Programming Volume 9 | SG24-6989 | Redbook | http://www.redbooks.ibm.com/ |
APPC and WebSphere Developer for System z | SC23-5885 | White Paper | http://www-306.ibm.com/software/awdtools/rdz/library/index.html |
Host Based Projects in WebSphere Developer for System z Version 7.0 | White Paper | http://www-306.ibm.com/software/awdtools/rdz/library/index.html | |
Setting up SSL for RSE Communication | SC23-5816 | White Paper | http://www-306.ibm.com/software/awdtools/rdz/library/index.html |
Communications Server Bookshelf | F1A1BK61 | z/OS 1.7 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Communications Server IP Configuration Guide | SC31-8775 | z/OS 1.7 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Communications Server IP Configuration Reference | SC31-8776 | z/OS 1.7 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Communications Server IP Diagnosis Guide | GC31-8782 | z/OS 1.7 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Communications Server IP System Administrator's Commands | SC31-8781 | z/OS 1.7 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Communications Server SNA Network Implementation Guide | SC31-8777 | z/OS 1.7 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Cryptographic Services System SSL Programming | SC24-5901 | z/OS 1.7 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Language Environment Customization | SA22-7564 | z/OS 1.7 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Language Environment Debugging Guide | GA22-7560 | z/OS 1.7 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
MVS Bookshelf | IEA2BK60 | z/OS 1.7 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
MVS Initialization and Tuning Guide | SA22-7591 | z/OS 1.7 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
MVS Initialization and Tuning Reference | SA22-7592 | z/OS 1.7 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
MVS JCL Reference | SA22-7597 | z/OS 1.7 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
MVS Planning APPC/MVS Management | SA22-7599 | z/OS 1.7 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
MVS Planning Workload Management | SA22-7602 | z/OS 1.7 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
MVS System Commands | SA22-7627 | z/OS 1.7 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Security Server RACF Command Language Reference | SA22-7687 | z/OS 1.7 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Security Server RACF Security Administrator's Guide | SA22-7683 | z/OS 1.7 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
UNIX System Services Command Reference | SA22-7802 | z/OS 1.7 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
UNIX System Services File System Interface Reference | SA22-7808 | z/OS 1.7 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
UNIX System Services Planning | GA22-7800 | z/OS 1.7 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
UNIX System Services User's Guide | SA22-7801 | z/OS 1.7 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Installieren Sie die erforderlichen FMIDs für die folgenden Funktionen. Installationsinformationen zu den verschiedenen FMIDs finden Sie in den entsprechenden Program-Directory-Veröffentlichungen.
Benötigte Funktion von IBM Rational Developer für System z | Zu installierende FMIDs | Installations- und Konfigurationsinformationen |
---|---|---|
|
HHOP710, HSD3310* |
optional
|
|
HCMA710, HHOP710** |
optional
|
|
HSD3310 |
|
(*) Developer für System z erfordert eine Verbindung zum TSO Commands Service unter z/OS. Diese Verbindung wird auf eine der folgenden Arten bereitgestellt:
(**) CARMA erfordert eine hostbasierte Schnittstelle. HHOP710 stellt diese Funktion bereit. Wenn Sie auf die Installation von HHOP710 verzichten möchten, können Sie eine selbst erstellte hostbasierte Schnittstelle verwenden.
Sie müssen die folgenden, in der Veröffentlichung SCLM Developer Toolkit Installation und Anpassung (IBM Form SC12-4101) beschriebenen SCLMDT-Anpassungsschritte ausführen:
Ausführliche Anweisungen für die SMP/E-Installation der einzelnen FMIDs können Sie den entsprechenden Program-Directory-Veröffentlichungen entnehmen, die in Tabelle 2 aufgelistet sind.
Für Developer für System z gibt es eine Liste vorausgesetzter Software, die installiert und betriebsbereit sein muss, damit das Produkt funktioniert. Außerdem gibt es eine Liste zusätzlich erforderlicher Software zur Unterstützung bestimmter Features von Developer für System z. Zur Laufzeit muss diese zusätzlich erforderliche Software installiert und betriebsbereit sein, damit das entsprechende Feature ordnungsgemäß funktionieren kann.
Eine Liste der Produkte, die für Ihre Version von Developer für System z vorausgesetzt werden bzw. zusätzlich erforderlich sind, enthält die Veröffentlichung Rational Developer für System z Hostplanung (IBM Form GI11-3123-00).
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.
Sie müssen die folgenden, in der Veröffentlichung SCLM Developer Toolkit Installation und Anpassung (IBM Form SC12-4101) beschriebenen SCLMDT-Anpassungsschritte ausführen:
Sie können Ihre TCP/IP-Konfiguration mit dem TSO-Befehl HOMETEST testen. Weitere Informationen zu diesem Befehl enthält der Abschnitt TSO Commands der Veröffentlichung Communications Server IP System Administrator's Commands (IBM Form SC31-8781).
Beispielausgabe des Befehls HOMETEST:
Running IBM MVS TCP/IP CS V1R7 TCP/IP Configuration Tester The FTP configuration parameter file used will be "SYS1.TCPPARMS(FTPDATA)" TCP Host Name is: CDFMVS08 Using Name Server to Resolve CDFMVS08 The following IP addresses correspond to TCP Host Name: CDFMVS08 9.42.112.75 The following IP addresses are the HOME IP addresses defined in PROFILE.TCPIP: 9.42.112.75 127.0.0.1 All IP addresses for CDFMVS08 are in the HOME list! Hometest was successful - all Tests Passed!
Die Benutzer-ID eines Benutzers von Developer für 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
Zu den folgenden Hostservices (und somit zu den zugehörigen Ports) muss der Client eine Verbindung herstellen können. An allen anderen von Developer für System z verwendeten Ports gibt es nur Hostdatenverkehr. Das bedeutet, dass für die Firewall, die den Host schützt, nur die aufgelisteten Ports von Developer für System z definiert werden müssen.
INETD ist ein z/OS-UNIX-Serverprozess, der für die Einrichtung der Client-Host-Verbindungen von Developer für System z erforderlich ist. 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.
Weitere Informationen zu INETD-Berechtigungen enthält Anhang D. INETD konfigurieren.
Remote Systems Explorer (RSE) ist die Komponente von Developer für System z, die Kernservices wie die Verbindung vom Client zum Host bereitstellt.
Die Konfiguration von Developer für System z erfordert mehr als die üblichen Systemprogrammiererberechtigungen, so dass eine gewisse Mindestunterstützung von anderen eingeplant werden sollte. In der folgenden Liste sind die wichtigsten Bereiche aufgeführt:
Developer für System z und Common Access Repository Manager (CARMA) unterstützen das Klonen einer Installation auf einem anderen System, so dass Sie nicht auf jedem System eine SMP/E-Installation durchführen müssen.
Für das Deployment auf anderen Systemen sind die nachfolgenden Dateigruppen, Verzeichnisse und Dateien obligatorisch. Falls Sie eine Datei an eine andere Position kopiert haben, um sie anzupassen, muss die entsprechende Datei in den folgenden Listen durch Ihre angepasste Datei ersetzt werden.
Dieser Abschnitt hebt die Installations- und Konfigurationsänderungen im Vergleich zu früheren Produktreleases hervor. Weitere Informationen hierzu finden Sie in den entsprechenden Abschnitten dieses Handbuchs.
Wenn Sie mit einer früheren Version von Developer für System z arbeiten, sollten Sie die zugehörigen Anpassungsdateien speichern, bevor Sie das Upgrade auf Version 7.1.1 installieren. Falls Sie planen, mehrere Instanzen von Developer für System z auszuführen, lesen Sie vor Beginn der Anpassung Anhang A. Mehrere Instanzen von Developer für System z ausführen.
Tabelle 3 und Tabelle 4 geben einen Überblick über die Dateien, die ab Developer für System z und CARMA Version 6.0.1 angepasst worden sein können. In Tabelle 5 sind die Anpassungen aufgelistet, die während der Installation von Developer für System z und CARMA ab Version 6.0.1 an Dateigruppen sowie an vorausgesetzten und zusätzlich erforderlichen Produkten vorgenommen werden.
Member | Standardposition in Version 6.0.1 | Standardposition in Version 7.0/7.1 | Zweck |
---|---|---|---|
FEJJCNFG |
HLQ.SFEJSAMP (HLQ = FEJ) |
HLQ.SFEKSAMP (HLQ = FEK) |
Konfigurationsdatei für JES Job Monitor |
FEJJJCL |
HLQ.SFEJSAMP (HLQ = FEJ) |
HLQ.SFEKSAMP (HLQ = FEK) |
JCL für JES Job Monitor |
FEJTSO |
HLQ.SFEJSAMP (HLQ = FEJ) |
HLQ.SFEKSAMP (HLQ = FEK) |
JCL für TSO-Übergabe |
FEKAPPCC | nicht vorhanden |
HLQ.SFEKSAMP (HLQ = FEK) |
JCL zum Erstellen einer APPC-Transaktion |
FEKAPPCL | nicht vorhanden |
HLQ.SFEKSAMP (HLQ = FEK) |
JCL zum Anzeigen einer APPC-Transaktion |
FEKAPPCX | nicht vorhanden |
HLQ.SFEKSAMP (HLQ = FEK) |
JCL zum Löschen einer APPC-Transaktion |
FEKFRTAD |
HLQ.SFEKSAMP (HLQ = FEK) |
(neuer Member-Name FEKAPPCC) | JCL zum Erstellen einer APPC-Transaktion |
FEKFRDIS |
HLQ.SFEKSAMP (HLQ = FEK) |
(neuer Member-Name FEKAPPCL) | JCL zum Anzeigen einer APPC-Transaktion |
FEKFRDEL |
HLQ.SFEKSAMP (HLQ = FEK) |
(neuer Member-Name FEKAPPLX) | JCL zum Löschen einer APPC-Transaktion |
ELAXF* |
HLQ.SCCUSAMP (HLQ = CCU) |
HLQ.SFEKSAMP (HLQ = FEK) |
JCL für ferne Projekt-Builds usw. |
ELAXMSAM |
HLQ.SCCUSAMP (HLQ = CCU) |
HLQ.SFEKSAMP (HLQ = FEK) |
JCL-Prozedur des WLM-Adressbereichs für den Stored Procedure Builder für PL/I und COBOL |
ELAXMJCL |
HLQ.SCCUSAMP (HLQ = CCU) |
HLQ.SFEKSAMP (HLQ = FEK) |
JCL zum Definieren des Stored Procedure Builder für COBOL und PL/I für DB2 |
ADNVSAM | nicht vorhanden |
HLQ.SFEKSAMP (HLQ = FEK) |
JCL zum Definieren des ADM-CRD-Repositorys |
ADNPCCSD | nicht vorhanden
|
HLQ.SFEKSAMP (HLQ = FEK) |
JCL zum Aktivieren des CRD-Servers in der primären CICS-Region |
ADNCMSGH | nicht vorhanden |
HLQ.SFEKSAMP (HLQ = FEK) (in Version 7.0 nicht vorhanden) |
JCL zum Kompilieren des Pipelinenachrichten-Handlers |
ADNSMSGH | nicht vorhanden |
HLQ.SFEKSAMP (HLQ = FEK) |
Beispielquellcode für den Pipelinenachrichten-Handler |
ADNARCSD | nicht vorhanden |
HLQ.SFEKSAMP (HLQ = FEK) |
JCL zum Aktivieren des CRD-Servers in den nicht primären CICS-Regionen |
CRASUBMT |
HLQ.SCRACLST (HLQ = CRA) |
HLQ.SCRACLST (HLQ = CRA) |
CLIST zum Übergeben von JCL für einen CARMA-Server |
CRAMREPR |
HLQ.SCRASAM (HLQ = CRA) |
HLQ.SCRASAMP (neuer Member-Name in Version 7.1: CRA$VMSG)(HLQ = CRA) |
JCL zur Erstellung der VSAM für CARMA-Nachrichten |
CRAREPR |
HLQ.SCRASAM (HLQ = CRA) |
HLQ.SCRASAMP (neuer Member-Name in Version 7.1: CRA$VDEF)(HLQ = CRA) |
JCL zur Erstellung der VSAM für CARMA-Konfiguration |
CRASREPR |
HLQ.SCRASAM (HLQ = CRA) |
HLQ.SCRASAMP (neuer Member-Name in Version 7.1: CRA$VSTR)(HLQ = CRA) |
JCL zur Erstellung der VSAM für angepasste CARMA-Informationen |
CRALREPR |
HLQ.SCRASAM (HLQ = CRA) |
HLQ.SCRASAMP (neuer Member-Name in Version 7.1: CRA#VSLM)(HLQ = CRA) |
JCL zur Erstellung der VSAM für SCLM-RAM-Nachrichten |
CRASALX |
HLQ.SCRASAM (HLQ = CRA) |
HLQ.SCRASAMP (neuer Member-Name in Version 7.1: CRA#ASLM)(HLQ = CRA) |
JCL zum Erstellen der SCLM-RAM-Dateigruppen |
CRATREPR |
HLQ.SCRASAM (HLQ = CRA) |
HLQ.SCRASAMP (neuer Member-Name in Version 7.1: CRA#VPDS)(HLQ = CRA) |
JCL zur Erstellung der VSAM für PDS-RAM-Nachrichten |
Datei | Standardposition in Version 6.0.1 | Standardposition in Version 7.0/7.1 | Zweck |
---|---|---|---|
rsed.envvars | /usr/lpp/wd4z/rse/lib/ | /usr/lpp/wd4z/rse/lib/ | RSE-Konfigurationsdatei |
rsecomm.properties | /usr/lpp/wd4z/rse/lib/ | /usr/lpp/wd4z/rse/lib/ | RSE-Trace-Konfigurationsdatei |
ssl.properties | /usr/lpp/wd4z/rse/lib/ | /usr/lpp/wd4z/rse/lib/ | RSE-SSL-Konfigurationsdatei |
setup.env.zseries | /usr/lpp/wd4z/rse/lib/ | (wird nicht mehr angepasst) | Export von RSE-Umgebungsvariablen |
projectcfg.properties | (nicht vorhanden) | /usr/lpp/wd4z/rse/lib/ | Konfigurationsdatei für Hostprojekte |
FMIEXT.properties | (nicht vorhanden) | /usr/lpp/wd4z/rse/lib/ (in Version 7.0 nicht vorhanden) | File-Manager-Konfigurationsdatei |
CRASRV.properties | /usr/lpp/wd4z/rse/lib/ | /usr/lpp/wd4z/rse/lib/ | CARMA-Konfigurationsdatei |
rexxsub | /usr/lpp/wd4z/rse/lib/ | (wird nicht mehr angepasst) | CARMA-z/OS-UNIX-REXX zum Ausführen der MVS-CLIST CRASUBMT |
Member/Datei | Standardposition | Erforderliche Anpassung |
---|---|---|
BPXPRMxx | SYS1.PARMLIB | Setzen Sie MAXASSIZE auf mindestens 2147483647. |
PROGxx | SYS1.PARMLIB | Berechtigen Sie HLQ.SFEKLOAD für APF. |
ASCHPMxx | SYS1.PARMLIB | Definieren Sie eine APPC-Transaktionsklasse für den TSO Commands Service. |
services | /etc/ | Definieren Sie den RSE-Dämon. |
inetd.conf | /etc/ | Definieren Sie den RSE-Dämon. |
ISPF.conf | /etc/SCLMDT/CONFIG/ | Definieren Sie die Position für den TSO Commands Server. |
/ | APPC | Definieren Sie eine APPC-Transaktion für den TSO Commands Service. |
/ | WLM | Ordnen Sie das APPC-Transaktionsprogramm einer TSO-Leistungsgruppe zu. |
/ | WLM | Weisen Sie der gespeicherten DB2-Prozedur eine Anwendungsumgebung zu. |
Wenn Sie mit einer früheren Version von Developer für System z arbeiten, sollten Sie die zugehörigen Anpassungsdateien speichern, bevor Sie Version 7.1.1 installieren. Lesen Sie hierzu den Abschnitt Bereits konfigurierte Dateien sichern.
Alle in diesem Abschnitt enthaltenen Verweise auf HLQ beziehen sich auf den während der Installation von Developer für System z verwendeten High Level Qualifier. Die Standardeinstellung für die Installation ist FEK, die jedoch nicht für Ihren Standort zutreffen muss.
Sie können die LINKLIST-Anforderung umgehen, indem Sie eine STEPLIB-Anweisung zu rsed.envvars hinzufügen. Lesen Sie hierzu den Abschnitt RSE-Konfigurationsdatei rsed.envvars anpassen.
MAXASSIZE definiert die Regionsgröße des Adressbereichs/Adressierungsprozesses. Setzen Sie MAXASSIZE in SYS1.PARMLIB(BPXPRMxx) auf mindestens 2147483647.
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 SA22-7627).
1. DISPLAY OMVS,O 2. SETOMVS MAXASSIZE=2147483647
Weitere Informationen zu anderen Positionen, an denen die Größe des Adressbereichs gesetzt oder eingeschränkt werden kann, finden Sie im Abschnitt Größe des Adressbereichs.
Das Modul FEJJMON in der Ladebibliothek HLQ.SFEKLOAD muss für APF berechtigt werden, damit JES Job Monitor auf JES-Spool-Dateien zugreifen kann.
Wenn Sie sich an Ihrem Standort nach den IBM Empfehlungen gerichtet haben, sind die APF-Berechtigungen in SYS1.PARMLIB(PROGxx) definiert. Weitere Informationen zum Definieren von APF-Berechtigungen enthält die Veröffentlichung MVS Initialization and Tuning Reference (IBM Form SA22-7592).
Zu Testzwecken können APF-Berechtigungen auch dynamisch erteilt werden. Solche Berechtigungen sind bis zum nächsten IPL des Systems gültig. Der erforderliche Konsolbefehl sieht wie folgt aus:
SETPROG APF,ADD,DSN=HLQ.SFEKLOAD,SMS
Weitere Informationen zum Befehl SETPROG enthält die Veröffentlichung MVS System Commands (IBM Form SA22-7627).
JES Job Monitor ist die Komponente für die gesamte JES-Konnektivität von Developer für System z. Bestimmte Aspekte können in einer Konfigurationsdatei an die Anforderungen Ihres Standorts angepasst werden.
Sie finden die Beispielkonfigurationsdatei in:
HLQ.SFEKSAMP(FEJJCNFG)
Die Datei umfasst eine Reihe von Definitionen für Umgebungsvariablen. Kommentarzeilen beginnen mit dem Nummernzeichen (#). Die Beispielkonfigurationsdatei ist in Abb. 1 aufgelistet.
SERV_PORT=6715 CODEPAGE=UTF-8 HOST_CODEPAGE=IBM-1047 TZ=EST5EDT #LIMIT_VIEW=USERID LISTEN_QUEUE_LENGTH=5 MAX_DATASETS=32 MAX_THREADS=200 TIMEOUT_INTERVAL=1200 TIMEOUT=3600 AUTHMETHOD=RACF #_BPXK_SETIBMOPT_TRANSPORT=<TCP/IP-Stack-Name>
Folgende Definitionen sind erforderlich:
Folgende Definitionen sind optional. Wenn Sie diese Definitionen übergehen, werden die angegebenen Standardwerte verwendet.
JES Job Monitor ist die Komponente für die gesamte JES-Konnektivität von Developer für System z. Dazu muss auf dem System ein Server aktiv sein (Benutzerjob oder STC). Erstellen Sie den JES Job Monitor Server gemäß den Standards an Ihrem Standort. Führen Sie dazu die Anpassungsschritte in HLQ.SFEKSAMP(FEJJJCL) aus.
Falls Sie die Trace-Erstellung für JES Job Monitor zu Diagnosezwecken aktivieren müssen, fügen Sie zur PARM-Zeile -TV hinzu. Der Trace bringt Leistungseinbußen mit sich und sollte nur auf Anweisung des IBM Support Center durchgeführt werden.
//JMONITOR EXEC PGM=FEJJMON,TIME=1440,REGION=0M, // PARM=('POSIX(ON),ENVAR("_CEE_ENVFILE=DD:ENVIRON")/ -TV')
Die Trace-Erstellung kann auch mit Konsolbefehlen gesteuert werden. Der erste Befehl in der folgenden Liste aktiviert den Trace für einen Job mit dem Namen JMON und der zweite inaktiviert den Trace.
1. F JMON,APPL=-TV 2. F JMON,APPL=-TN
JES Job Monitor kann als Benutzerjob oder gestartete Task (STC) ausgeführt werden. Wenn Sie JMON als STC definieren möchten, müssen Sie die folgende Task implementieren:
//JMON PROC HLQ=FEK, // PRM= //* //* RD/Z JES JOB MONITOR //* //JMONITOR EXEC PGM=FEJJMON,TIME=1440,REGION=0M, // PARM=('POSIX(ON),ENVAR("_CEE_ENVFILE=DD:ENVIRON")/&PRM') //STEPLIB DD DISP=SHR,DSN=&HLQ..SFEKLOAD //ENVIRON DD DISP=SHR,DSN=&HLQ..SFEKSAMP(FEJJCNFG) //SYSPRINT DD SYSOUT=* //SYSABEND DD SYSOUT=* //SYSOUT DD SYSOUT=* //SYSIN DD DUMMY //*SYSTCPD DD DISP=SHR,DSN=SYS1.TCPIP.DATA
Zur leichteren Referenzierung sollte der Member-Name mit dem Namen der Prozedur übereinstimmen. (Im obigen Beispiel ist dies der Name JMON.)
Verwenden Sie zum Erstellen einer solchen Benutzer-ID den folgenden Beispielbefehl. Die Angabe userid steht hier für die besprochene Benutzer-ID, groupid für die Gruppen-ID und uid für die UNIX-ID.
ADDUSER userid DFLTGRP(groupid) NOPASSWORD OMVS(UID(uid) HOME(/tmp) PROGRAM(/bin/sh))
a. SETROPTS GENERIC(STARTED) b. RDEFINE STARTED ** STDATA(USER(=MEMBER)) c. SETROPTS CLASSACT(STARTED) d. SETROPTS RACLIST(STARTED)
Zum Hinzufügen von JES Job Monitor als STC sind die folgenden RACF-Befehle erforderlich. In diesem Befehlen ist jmon der Name des JCL-Members und userid die ID des Benutzers, dessen Berechtigungen verwendet werden.
a. RDEFINE STARTED jmon.* STDATA(USER(userid)) b. SETROPTS RACLIST(STARTED) REFRESH
Weitere Informationen zu gestarteten Tasks und zur Sicherheit enthält der Security Server RACF Security Administrator's Guide (IBM Form SA22-7683).
Der Systembediener kann auf der Konsole die folgenden Befehle absetzen. (In diesem Befehlen ist JMON der STC-Name von JES Job Monitor.)
a. Start JMON b. stoP JMON c. Display A,JMON
Mit den entsprechenden Berechtigungen können Sie diese Befehle in SDSF eingeben. In diesem Fall müssen Sie den Befehlen allerdings einen Schrägstrich ('/') voranstellen. Weitere Informationen zu Konsolbefehlen enthält die Veröffentlichung MVS System Commands (IBM Form SA22-7627).
Die dem JES Job Monitor Server zugeordnete Benutzer-ID benötigt die Zugriffsberechtigung READ für die Ladebibliothek HLQ.SFEKLOAD von Developer für System z.
Starten Sie den Benutzerjob oder die STC, den bzw. die Sie mit den obigen Schritten definiert haben. Falls der Job mit dem Rückkehrcode 66 endet, ist HLQ.SFEKLOAD nicht für APF berechtigt.
Benutzer können erst Operationen über JES Job Monitor ausführen, wenn sie berechtigt sind, auf die Klasse OPERCMDS zuzugreifen. Sie können diese Zugriffsberechtigung bedingt erteilen, so dass Benutzer nur Zugriff haben, wenn sie JES Job Monitor verwenden. Für eine Überprüfung dieses bedingten Zugriffs muss die Klasse CONSOLE aktiv und auf der Konsole der Name JMON definiert sein. (JMON ist der einzige gültige Name.)
Ihr Sicherheitsadministrator müsste beispielsweise die folgenden RACF-Befehle absetzen:
1. SETROPTS CLASSACT(CONSOLE) 2. RDEFINE CONSOLE JMON UACC(READ) 3. SETROPTS RACLIST(CONSOLE) REFRESH
Mit den folgenden RACF-Befehlen können Sie Benutzer für das ausschließliche Absetzen von JES2-Befehlen über JES Job Monitor berechtigen. Die Angabe id steht hier für die Benutzer- oder Gruppen-ID der Benutzer von Developer für System z.
1. RDEFINE OPERCMDS JES2.** UACC(NONE) 2. PERMIT JES2.** CLASS(OPERCMDS) ID(id) ACCESS(CONTROL) WHEN(CONSOLE(JMON)) 3. SETROPTS RACLIST(OPERCMDS) REFRESH 4. SETROPTS GENERIC(OPERCMDS) REFRESH
JES Job Monitor ermöglicht Benutzern von Developer für System z keinen umfassenden JES-Spool-Zugriff. Es stehen nur die in Tabelle 6 aufgelisteten Befehle zur Verfügung. Die Befehle werden durch Auswahl der entsprechenden Option in der Clientmenüstruktur abgesetzt (keine Eingabeaufforderung). Durch die unten beschriebenen Techniken wird der Geltungsbereich der Befehle weiter eingeschränkt.
Befehl | JES2 | JES3 |
---|---|---|
Hold | $Hjobid | *F,J=jobid,H |
Release | $Ajobid | *F,J=jobid,R |
Cancel | $Cjobid | *F,J=jobid,C |
Purge | $Cjobid,P | *F,J=jobid,C |
Benutzer, die nicht berechtigt sind, diese Konsolbefehle auszuführen, können trotzdem Jobs übergeben und Jobausgaben lesen, wenn sie für den Zugriff auf Spool-Dateien berechtigt sind.
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 Spool-Dateien verwenden, z. B. die Klasse JESSPOOL in RACF.
Denken Sie beim Definieren weiterer Schutzmaßnahmen daran, dass JES Job Monitor für den Zugriff auf Spool-Dateien (die SYSOUT-Anwendungsprogrammierschnittstelle) SAPI verwendet. Damit ist impliziert, dass der Benutzer für Spool-Dateien (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-Spool-Dateien finden Sie im Security Server RACF Security Administrator's Guide (IBM Form SA22-7683).
Developer für System z stellt Beispiel-JCL-Prozeduren bereit, die für die JCL-Generierung, die Fernerstellung von Projekt-Builds 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. Damit wird außerdem sichergestellt, dass die Entwickler dieselben Prozeduren mit denselben Compileroptionen und Compilerversionen verwenden.
SMP/E installiert diese Beispiel-JCL-Prozeduren in HLQ.SFEKSAMP. Wenn Sie diese Prozeduren verwenden möchten, gehen Sie wie folgt vor:
Die zu kopierenden und anzupassenden Prozeduren 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 | Beispielprozeduren für die DB2-Vorverarbeitung von 'EXEC SQL'-Anweisungen, die in COBOL-Programme eingebettet sind |
ELAXFCOT | Beispielprozeduren 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 |
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 | Beispielprozeduren für die DB2-Vorverarbeitung von 'EXEC SQL'-Anweisungen, die in PLI-Programme eingebettet sind |
ELAXFPLT | Beispielprozeduren 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 |
ELAXFUOP | Beispielprozedur für die Generierung des UOPT-Schritts beim Erstellen von Programmen, die in CICS- oder IMS-Subsystemen ausgeführt werden |
Tabelle 8 enthält eine Prüfliste für die in den ELAXF*-Prozeduren verwendeten High Level Qualifier der verschiedenen Produkte.
Produkt | Standard-HLQ | Wert |
---|---|---|
RD/z | FEK | |
CICS | CICSTS31.CICS | |
DB2 | DSN810 | |
IMS | IMS | |
COBOL | IGY.V3R4M0 | |
PL/I | IBMZ.V3R6M0 | |
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, kopieren Sie sie in eine private Bibliothek, und fordern Sie die Benutzer von Developer für System z auf, zu den Jobmerkmalen auf dem Client (direkt nach der JOB-Karte) eine JCLLIB-Karte hinzuzufügen. Passen Sie nicht die Beispiel-JCL in der Installationsdateigruppe an, denn diese Member könnten bei einer Wartung ersetzt werden und Ihre Anpassungen löschen.
//MYJOB JOB <Jobparameter> //PROCS JCLLIB ORDER=(HLQ.SFEKSAMP)
Die Namen der Prozeduren und der einzelnen Prozedurschritte stimmen mit den Standardmerkmalen des Clients überein. Falls Sie den Namen einer Prozedur oder eines Prozedurschritts ändern möchten, sollten Sie auch die entsprechende Merkmaldatei des Clients aktualisieren. Das Ändern der Namen von Prozeduren oder Prozedurschritten ist nicht zu empfehlen.
Ab Version 7.1 ist das Definieren der APPC-Transaktion optional. Standardmäßig verwendet Developer für System z jetzt das SCLM Developer Toolkit für die Bereitstellung des TSO Commands Service. Die entsprechende Konfiguration wird in rsed.envvars vorgenommen und ist im Abschnitt RSE-Konfigurationsdatei rsed.envvars anpassen beschrieben.
// PARM='ISPSTART CMD(%FEKFRSRV TIMEOUT=60) NEWAPPL(ISR) NESTMACS'
Der TSO Commands Service wird als das APPC-Transaktionsprogramm FEKFRSRV implementiert und muss aktiv sein, damit Developer-für-System-z-Verbindungen zwischen Host und Client hergestellt werden können. FEKFRSRV fungiert als ein Hostserver, der die von der Workstation über TCP/IP abgesetzten TSO-Befehle ausführt. Auf der Workstation ist APPC nicht erforderlich. Die Workstation kommuniziert über TCP/IP mit FEKFRSRV. Jede Workstation 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 | Dateigruppenname von TPDATA
|
|
APPC | Zu verwendender Transaktionsname (möglicherweise nicht vorhanden)
|
|
APPC | Zu verwendende APPC-Transaktionsklasse
|
|
WLM/SRM | TSO-Leistungsgruppe und -Domäne
|
|
RACF | Jeder Benutzer von Developer für System z hat Zugriff auf ein
OMVS-Segment. (Dies ist erforderlich.)
|
|
RACF | Jeder Benutzer von Developer für System z muss Lesezugriff (READ) auf
HLQ.SFEKPROC(FEKFRSRV) haben.
|
Weitere Informationen zum WLM/SRM-Management finden Sie in der Veröffentlichung MVS Planning Workload Management (IBM Form SA22-7602) . Weitere Informationen zu OMVS-Segmenten und Profilen für Dateigruppenschutz enthält der Security Server RACF Security Administrator's Guide (IBM Form SA22-7683).
Als Systemprogrammierer oder APPC-Administrator müssen Sie die Commands-Funktion wie folgt konfigurieren:
CLASSADD CLASSNAME(A) MAX(20) MIN(1) MSGLIMIT(200)
Für die Integration der gespeicherten DB2-Beispielprozedur (Stored Procedure Builder für PL/I und COBOL) in Ihr System sind die folgenden Anpassungsschritte erforderlich. Für die Ausführung dieser Schritte benötigen Sie die Unterstützung eines WLM-Administrators und eines DB2-Administrators.
Nach der Ausführung von SMP/E enthalten die Beispielbibliothek HLQ.SFEKSAMP und die Prozedurenbibliothek HLQ.SFEKPROC die in Tabelle 10 aufgelisteten Member der gespeicherten DB2-Prozedur.
Member | Zweck |
---|---|
HLQ.SFEKSAMP(ELAXMJCL) | Beispiel-JCL zum Definieren des Stored Procedure Builder für COBOL und PL/I für DB2 |
HLQ.SFEKSAMP(ELAXMSAM) | Beispiel-JCL-Prozedur des WLM-Adressbereichs für den Stored Procedure Builder für PL/I und COBOL |
HLQ.SFEKPROC(ELAXMREX) | REXX-Code für den Stored Procedure Builder für PL/I und COBOL |
Die Komponente Enterprise Service Tools (EST) von Developer für 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:
Für die Ausführung der folgenden Tasks benötigen Sie die Unterstützung Ihres CICS-Administrators:
Die bidirektionalen Umsetzungen von EST werden vom Modul FEJBDTRX in der Umgebung CICS Service Flow Runtime (SFR) ausgeführt. Das Modul FEJBDTRN wird aufgerufen, wenn in dem von EST generierten Code bidirektionale Umsetzungen erforderlich sind (d. h., wenn die Felder von Nachrichten mit verschiedenen bidirektionalen Attributen einander zugeordnet werden).
Wenn autoinstall auf autoINactive gesetzt ist, definieren Sie das Programm FEJBDTRX mit dem Befehl CEDA für CICS. Beispiel:
CEDA DEF PROG(FEJBDTRX) LANG(LE) G(xxx)
Von EST generierter Code kann die BIDI-Konvertierung auch in anderen Umgebungen als CICS SFR unterstützen (z. B. in Batch-Anwendungen). 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 (HLQ.SFEKLOAD) verknüpfen.
Application Deployment Manager (ADM) bietet eine einheitliche Deployment-Strategie und Deployment-API für alle Komponenten von Rational Developer für System z.
Darüber hinaus stellt ADM einen CRD-Client (CICS Resource Definition) und einen hostbasierten Server bereit, die Folgendes ermöglichen:
Developer für System z stellt drei Transaktionen bereit, die der CRD-Server beim Definieren und Abfragen von CICS-Ressourcen verwendet. Für standortspezifische Anpassungen steht COBOL-Beispielquellcode zur Verfügung.
Weitere Informationen zu ADM enthält der Rational Developer für System z Application Deployment Manager User's Guide (IBM Form SC23-7661).
Die folgenden Anpassungsschritte sind zum Aktivieren des CRD-Servers erforderlich.
Wenn Sie mit einer früheren Version des CRD-Servers arbeiten, sollten Sie die zugehörigen Anpassungsdateien speichern, bevor Sie Version 7.1.1 installieren. Lesen Sie hierzu den Abschnitt Bereits konfigurierte Dateien sichern.
Kopieren Sie die anzupassenden Member aus dem Installationsverzeichnis in eine persönliche Bibliothek, und passen Sie die Kopien an, um das Überschreiben der Member bei einer Wartung zu verhindern:
optional (Pipelinenachrichten-Handler)
optional (CSD-Update für nicht primäre Regionen)
Passen Sie den Job ADNVSAM an, und übergeben Sie ihn, um die VSAM-Datei für das CRD-Server-Repository anzulegen und zu initialisieren. Anpassungsanweisungen finden Sie in der in ADNVSAM enthaltenen Dokumentation.
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 und dass mehrere Adressbereiche in die VSAM schreiben. Hierfür ist eine korrekte Konfiguration erforderlich.
Der CRD-Server muss für die primäre Verbindungsregion definiert werden. Diese Region verarbeitet die Web-Service-Anforderungen von Developer für System z.
CEDA INSTALL GROUP(ADNPCRGP)
Der Pipelinenachrichten-Handler (ADNSMSGH) wird für die Sicherheit verwendet. Er verarbeitet die Benutzer-ID und das Kennwort im SOAP-Header. ADNSMSGH wird von der Pipelinekonfigurationsdatei referenziert und muss deshalb in die CICS-RPL-Kette gestellt werden. ADNSMSGH wird auch verwendet, um die Transaktions-ID - je nach angeforderter Operation - auf ADMD, ADMR oder ADMI zu setzen. Bei Bedarf können Sie ADNSMSGH für die Verwendung anderer Transaktions-IDs anpassen.
Standardmodul verwenden:
ADNSMSGH anpassen:
Der CRD-Server kann auch mit nicht primären Verbindungsregionen verwendet werden. Dabei handelt es sich in der Regel um AOR-Regionen (Application Owning Regions).
CEDA INSTALL GROUP(ADNARRGP)
Wenn Sie mit einer früheren Version von Developer für System z arbeiten, sollten Sie die zugehörigen Anpassungsdateien speichern, bevor Sie Version 7.1.1 installieren. Lesen Sie hierzu den Abschnitt Bereits konfigurierte Dateien sichern.
Falls Sie sich nicht mit z/OS UNIX auskennen, sollten Sie einen erfahrenen z/OS-UNIX-Administrator oder anderen UNIX-Administrator bitten, Sie bei der Ausführung der in diesem Kapitel beschriebenen Tasks zu unterstützen.
Die für die aufgeführten Tasks erforderlichen z/OS-UNIX-Befehle werden hier kurz für Sie beschrieben. Weitere Informationen zu diesen Befehlen entnehmen Sie bitte der Veröffentlichung UNIX System Services Command Reference (IBM Form SA22-7802), sofern nichts anderes angegeben ist.
Für die nachfolgenden Tasks wird vorausgesetzt, dass Sie aktivierter zOS-UNIX-Benutzer sind. Zum Aktivieren können Sie den TSO-Befehl OMVS absetzen. Mit dem Befehl exit können Sie zu TSO zurückkehren.
MVS bietet mit dem Befehl OEDIT die Möglichkeit, z/OS-UNIX-Dateien mit ISPF zu bearbeiten. Sie können diesen Befehl in TSO und OMVS verwenden.
Bei den meisten z/OS-UNIX-Dateien ist der Schreibzugriff auf den Eigner der Datei beschränkt. Es gibt mehrere Möglichkeiten, diese Einschränkung zu umgehen.
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.
Der Benutzer hat Lese- und Schreibrechte für alle Dateien und kann alle Verzeichnisse lesen oder durchsuchen. Die Zugriffsberechtigung CONTROL (oder eine höhere Zugriffsberechtigung) für dieses Sicherheitsprofil fügt zur Liste der Berechtigungen den Schreibzugriff für alle Verzeichnisse hinzu.
Wenn Sie mehr über die z/OS-UNIX-Sicherheit erfahren möchten, lesen Sie die Veröffentlichung UNIX System Services Planning (IBM Form GA22-7800).
Alle Pfadangaben in diesem Kapitel, die /usr/lpp/wd4z/ enthalten, beziehen sich auf den während der Installation von Developer für System z verwendeten Pfad. Der Standardpfad ist /usr/lpp/wd4z/; an Ihrem Standort kann jedoch ein anderer Pfad verwendet worden sein.
Sie können Ihre TCP/IP-Konfiguration mit dem TSO-Befehl HOMETEST testen. Weitere Informationen zu diesem Befehl enthält die Veröffentlichung Communications Server IP System Administrator's Commands (IBM Form SC31-8781).
Die folgenden Veröffentlichungen enthalten hilfreiche Informationen zu z/OS UNIX:
Sie sollten die Datei /usr/lpp/wd4z/rse/lib/rsed.envvars in ein neues Verzeichnis kopieren (z. B. in /etc/wd4z/) und die Kopie anpassen, damit die Datei im Falle einer Wartung nicht überschrieben wird. Sie müssen dann aber auch die folgenden Dateien aus dem Installationsverzeichnis (standardmäßig /usr/lpp/wd4z/rse/lib/) an die neue Position kopieren:
Die in Tabelle 11 aufgelisteten Dateien müssen auch kopiert werden, wenn Sie planen, die optionalen Features zu verwenden, zu denen diese Dateien gehören:
Datei | Funktion |
---|---|
projectcfg.properties | Hostbasierte Projekte
Lesen Sie hierzu den Abschnitt Konfiguration von Hostprojekten in projectcfg.properties anpassen (optional). |
FMIEXT.properties | File Manager Integration
Lesen Sie hierzu den Abschnitt File Manager Integration in FMIEXT.properties anpassen (optional). |
CRASRV.properties | CARMA
Lesen Sie hierzu IBM Common Access Repository Manager (CARMA) aktivieren (optional). |
Die Beispielbefehle
erstellen ein Verzeichnis mit dem Namen /etc/rd4z und kopieren rsed.envvars aus dem aktuellen Verzeichnis in das Verzeichnis /etc/rd4z. Wiederholen Sie den Kopierbefehl für die verbleibenden Dateien.
Das Ergebnis des Kopiervorgangs können Sie mit dem Befehl ls /etc/wd4z überprüfen. Die Ausgabe dieses Befehls sollte in etwa wie die folgende aussehen, wobei $ die z/OS UNIX-Eingabeaufforderung ist:
$ ls /etc/wd4z /etc/wd4z rsecomm.properties server.zseries ssl.properties rsed.envvars setup.env.zseries
1. mkdir /usr/lpp/wd4z/rse/lib/cust 2. ln -s /usr/lpp/wd4z/rse/lib/cust /etc/wd4z
Alle Clientverbindungsmethoden von Developer für System z verwenden die in der Datei rsed.envvars gesetzten Variablen. Standardmäßig befindet sich die Datei im Installationsverzeichnis /usr/lpp/wd4z/rse/lib/. Sie kann aber auch wie im vorherigen Schritt in ein anderes Verzeichnis kopiert worden sein. Die bereitgestellte Beispieldatei enthält die in Abb. 4 aufgelisteten Anweisungen. Kommentarzeilen beginnen mit einem Nummernzeichen (#).
#============================================================= # (1) erforderliche Anpassungen JAVA_HOME=/usr/lpp/java/J1.4 RSE_HOME=/usr/lpp/wd4z TZ=EST5EDT LANG=C PATH=/bin:/usr/sbin:. _RSE_CLASS_OPTS="" _RSE_JAVAOPTS="" #_RSE_JAVAOPTS="$_RSE_JAVAOPTS -DTSO_SERVER=APPC" #============================================================= # (2) erforderliche Anpassungen, wenn SCLMDT verwendet wird _CMDSERV_BASE_HOME=/usr/lpp/SCLMDT _CMDSERV_BASE_LOAD=BWB.SBWBLOAD _CMDSERV_CONF_HOME=/etc/SCLMDT _CMDSERV_WORK_HOME=/var/SCLMDT STEPLIB=NONE #STEPLIB=$_CMDSERV_BASE_LOAD _RSE_CMDSERV_OPTS="" #============================================================= # (3) optionale Anpassungen #_RSE_PORTRANGE=8108-8118 #_FEKFLOCK_USERID_=user_id #_FEKFLOCK_JOBNAME_=job_name #_FEKFSCMD_TP_NAME_=tp_name #_FEKFSCMD_PARTNER_LU_=lu_name #============================================================= # (4) nur auf Anweisung des IBM Support Center ändern RSE_LIB=$RSE_HOME/rse/lib ICU_LIB=$RSE_HOME/icuc/lib _CEE_RUNOPTS="ALL31(ON) HEAP(32M,32K,ANYWHERE,KEEP,,) TRAP(ON)" _CEE_DMPTARG=$HOME/.eclipse/RSE/$RSE_USER_ID _BPX_SHAREAS=YES _BPX_SPAWN_SCRIPT=YES PATH=$JAVA_HOME/bin:$RSE_LIB:$_CMDSERV_BASE_HOME/bin:$PATH LIBPATH=$JAVA_HOME/bin:$JAVA_HOME/bin/classic:$ICU_LIB:$RSE_LIB:. CLASSPATH=$RSE_LIB:$RSE_LIB/dstore_core.jar:$RSE_LIB/clientserver.jar CLASSPATH=$CLASSPATH:$RSE_LIB/dstore_extra_server.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-1.4.3.jar:$RSE_LIB/cdtparser.jar CLASSPATH=$CLASSPATH:$RSE_LIB/wdzBidi.jar:$RSE_LIB/fmiExtensions.jar CLASSPATH=.:$CLASSPATH _RSE_CMDSERV_OPTS="&SESSION=SPAWN$_RSE_CMDSERV_OPTS" _RSE_JAVAOPTS="$_RSE_JAVAOPTS -DSCLMDT_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 -Dcom.ibm.cacheLocalHost=true" _RSE_JAVAOPTS="$_RSE_JAVAOPTS -showversion" _RSE_JAVAOPTS="$_RSE_JAVAOPTS -Duser.home=$HOME" _RSE_JAVAOPTS="$_RSE_JAVAOPTS -Dclient.username=$RSE_USER_ID" _RSE_JAVAOPTS="$_RSE_JAVAOPTS $_RSE_CLASS_OPTS" _RSE_SERVER_CLASS=com.ibm.etools.systems.dstore.core.server.Server _RSE_SERVER_TIMEOUT=120000 #============================================================= # (5) zusätzliche Umgebungsvariablen
Folgende Definitionen sind erforderlich:
Standardmäßig verwendet Developer für System z das SCLM Developer Toolkit für den TSO Commands Service. APPC wird verwendet, wenn die folgende _RSE_JAVAOPTS-Option nicht auf Kommentar gesetzt ist:
_RSE_JAVAOPTS="$_RSE_JAVAOPTS -DTSO_SERVER=APPC"
Wenn das SCLM Developer Toolkit für den TSO Commands Service verwendet wird oder das SCLMDT-Plug-in in der Clientkomponente von Developer für System z installiert ist, sind die folgenden Definitionen erforderlich.
Developer für System z verwendet standardmäßig die LINKLIST, um auf die Ladebibliothek des SCLM Developer Toolkit zuzugreifen. STEPLIB wird verwendet, wenn die folgende STEPLIB-Anweisung nicht auf Kommentar gesetzt ist:
STEPLIB=$_CMDSERV_BASE_LOAD
Folgende Definitionen sind optional. Wenn Sie diese Definitionen übergehen, werden Standardwerte verwendet.
Die folgenden Definitionen sind erforderlich und sollten nur auf Anweisung des IBM Support Center geändert werden.
STEPLIB=CEE.SCEERUN:CEE.SCEERUN2:CBC.SCLBDLL
STEPLIB=$STEPLIB:CEE.SCEERUN:CEE.SCEERUN2:CBC.SCLBDLL
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 Port-Bereich steht nicht in Verbindung mit den Ports des RSE-Dämons oder den REXEC/SSH-Ports.
Nachfolgend sehen Sie eine kurze Beschreibung des RSE-Verbindungsprozesses, die Ihnen helfen soll, die Port-Verwendung zu verstehen.
Wenn Sie den Port-Bereich für die Kommunikation des Clients mit z/OS angeben möchten, entfernen Sie das Kommentarzeichen aus der folgenden Zeile in rsed.envvars, und ändern Sie die Zeile:
#_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 Port-Nummern von 8108 bis einschließlich 8117 verwendet werden können.) Die vom RSE-Server verwendete Port-Nummer wird wie folgt ermittelt:
Mit den verschiedenen _RSE_*OPTS-Anweisungen bietet die Datei rsed.envvars die Möglichkeit, zusätzliche Parameter für Java anzugeben, wenn der RSE-Server gestartet wird.
Die in rsed.envvars enthaltenen Beispieloptionen können durch Entfernen des Kommentarzeichens aktiviert werden.
Wenn ein Client eine Verbindung anfordert, greift Developer für System z auf den INETD-Service zurück, um den RSE-Server (Remote Systems Explorer) zu starten. INETD ist ein z/OS UNIX-Standarddämon, der andere Dämonen verwaltet, die die eigentliche Arbeit ausführen (in diesem Falle das Starten des RSE-Servers). INETD wird nicht im Rahmen der Anpassung von Developer für System z konfiguriert. Anhang D. INETD konfigurieren enthält dennoch wertvolle Informationen hierzu.
Developer für System z unterstützt mehrere Methoden für den Start des RSE-Servers.
Sie müssen, je nach vorgesehener Arbeitsweise der Benutzer, mindestens eine dieser Methoden anpassen.
Als berechtigter Benutzer können Sie den Befehl ps -e absetzen, um zu überprüfen, ob INETD aktiv ist. Die Ausgabe muss einen Verweis auf INETD enthalten. Beispiel (# ist die z/OS-UNIX-Eingabeaufforderung):
# ps -e PID TTY TIME CMD 7 ? 0:00 /usr/sbin/inetd
rse 4035/tcp #Developer für System z RSE
Der verwendete Port muss mit dem auf dem Client definierten Port übereinstimmen. Auf dem Client wird der Port während der Erstellung einer neuen z/OS-Verbindung festgelegt.
rse stream tcp nowait OMVSKERN /usr/lpp/wd4z/rse/lib/fekfrsed rsed -d /usr/lpp/wd4z/rse/lib -t 60
Alle Angaben nach diesem INETD-Argument sind Serverargumente. Das erste Serverargument ist der Servername.
rse stream tcp nowait OMVSKERN /usr/lpp/wd4z/rse/lib/fekfrsed rsed -d /etc/wd4z
Folgende Definitionen sind optional. Wenn Sie diese Definitionen übergehen, werden Standardwerte verwendet.
a. # ps -e | grep inetd 50331687 ? 0:00 /usr/sbin/inetd b. # kill 50331687 c. # _BPX_JOBNAME='INETD' /usr/sbin/inetd d. # netstat | grep 4035 INETD4 00000B6A 0.0.0.0..4035 0.0.0.0..0 Listen
ICH408I USER(IBMUSER ) GROUP(SYS1 ) NAME(IBMUSER ) BPX.DAEMON CL(FACILITY) INSUFFICIENT ACCESS AUTHORITY ACCESS INTENT(READ ) ACCESS ALLOWED(NONE )
Es gibt keine spezifische Konfiguration für Developer für System z für die Verwendung des INETD-REXEC-Befehlsservers (oder -SSH-Befehlsservers). Der Client muss jedoch zwei Werte kennen, um über REXEC/SSH eine RSE-Verbindung herstellen zu können:
Standardmäßig ist dies das Installationsverzeichnis (/usr/lpp/wd4z/rse/lib/). Die Datei server.zseries gehört allerdings zu den Dateien, die ebenfalls kopiert werden müssen, wenn Sie rsed.envvars in ein anderes Verzeichnis, z. B. in /etc/wdz4/, kopieren.
Ein von REXEC verwendeter allgemeiner Port ist 512. Für eine schnelle Überprüfung können Sie den Befehl NETSTAT verwenden. Sehen Sie sich dazu das folgende Beispiel an ($ ist die z/OS-UNIX-Eingabeaufforderung):
$ netstat | grep 512 INETD4 0000002E 0.0.0.0..512 0.0.0.0..0 Listen
Zur Verifizierung können Sie in /etc/inetd.conf und /etc/services die verwendete Port-Nummer ü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.
Dieser Schritt ist nur erforderlich, wenn für den TSO Commands Service das SCLM Developer Toolkit verwendet wird (Standardmethode). Er ist nicht erforderlich, wenn Sie für den TSO Commands Service APPC verwenden.
Das SCLM Developer Toolkit benötigt zum Erstellen einer für die Ausführung von ISPF-Services gültigen Umgebung Definitionen in ISPF.conf. Zu dieser ISPF-Umgebung muss der TSO Commands Service hinzugefügt werden.
ISPF.conf wird während der Anpassung des SCLM Developer Toolkit erstellt. Diese Anpassung ist in der Veröffentlichung SCLM Developer Toolkit Installation und Anpassung (IBM Form SC12-4101) beschrieben. Die Standardposition ist /etc/SCLMDT/CONFIG; an Ihrem Standort kann jedoch ein anderer Pfad verwendet worden sein.
Fügen Sie die folgenden Zeilen zu ISPF.conf hinzu. HLQ steht hier für den bei der Installation von Developer für System z verwendeten High Level Qualifier (standardmäßig FEK).
********************************************** * Developer für System z - TSO Commands Server ********************************************** sysexec=HLQ.SFEKPROC
Das Ergebnis sollte wie das Beispiel in Abb. 5 aussehen.
sysproc=ISP.SISPCLIB ispmlib=ISP.SISPMENU isptlib=ISP.SISPTENU ispplib=ISP.SISPPENU ispslib=ISP.SISPSLIB ispllib=BWB.SBWBLOAD ********************************************** * Developer für System z - TSO Commands Server ********************************************** sysexec=FEK.SFEKPROC
Die Installation von Developer für System z stellt mehrere Installationsprüfprogramme (IVP, Installation Verification Programs) für den RSE-Server bereit. Die IVP-Scripts befinden sich im Installationsverzeichnis (standardmäßig /usr/lpp/wd4z/rse/lib/).
Bei allen Beispielbefehlen in diesem Abschnitt wird vorausgesetzt, dass die RSE-Umgebungsvariablen gesetzt sind. Wenn das der Fall ist, sind die IVP-Scripts über die Anweisung PATH verfügbar, und die Position von rsed.envvars ist bekannt. Verwenden Sie die Befehle pwd und cd, um Ihr aktuelles Verzeichnis zu prüfen und das Verzeichnis mit der angepassten Datei rsed.envvars aufzurufen. Danach können Sie mit dem Shell-Script setup.env.zseries die RSE-Umgebungsvariablen setzen. Sehen Sie sich hierzu das folgende Beispiel an ($ ist die z/OS-UNIX-Eingabeaufforderung):
$ pwd /etc $ cd /etc/wd4z $ . ./setup.env.zseries
Das Shell-Script . ./setup.env.zseries befindet sich in demselben Verzeichnis wie rsed.envvars und exportiert die Umgebungsvariablen, damit sie von anderen Prozessen verwendet werden können. Der erste Punkt (".") in . ./setup.env.zseries 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/wd4z/rse/lib/fekfivpr 512 USERIDDie meisten fekfivp*-Scripts fordern außerdem die Position der angepassten Datei rsed.envvars an, wenn . ./setup.env.zseries nicht zuerst ausgeführt wird.
$ echo $STEPLIB none $ STEPLIB=TCPIP.SEZALOAD
oder
$ echo $STEPLIB SOME.STEPLIB.DATASET $ STEPLIB=$STEPLIB:TCPIP.SEZALOAD
Informationen zur Diagnostizierung von RSE-Verbindungsproblemen können Sie Anhang B. Konfigurationsprobleme lösen oder den technischen Hinweisen auf der Supportseite zu Developer für System z (http://www-306.ibm.com/software/awdtools/devzseries/support/) entnehmen.
Die Port-Verfügbarkeit für JES Job Monitor, REXEC, SSH und den RSE-Dämon 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 V1R7 TCPIP Name: TCPIP 13:57:36 User Id Conn Local Socket Foreign Socket State ------- ---- ------------ -------------- ----- INETD4 00000014 0.0.0.0..22 0.0.0.0..0 Listen INETD4 00000030 0.0.0.0..512 0.0.0.0..0 Listen INETD4 0000004B 0.0.0.0..4035 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 V1R7 TCPIP Name: TCPIP 14:03:35 User Id Conn State ------- ---- ----- INETD4 00000018 Listen Local Socket: 0.0.0.0..22 Foreign Socket: 0.0.0.0..0 INETD4 00000046 Listen Local Socket: 0.0.0.0..512 Foreign Socket: 0.0.0.0..0 INETD4 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
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: $ EZYRC01I Calling function rexec_af with the following: EZYRC02I Host: CDFMVS08, user USERID, cmd cd /etc/wd4z;export RSE_USER_ID=USERI D;./server.zseries -ivp, port 512 EZYRC19I Data socket = 4, Control socket = 6. expect to see time out messages after a successful IVP test 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 Server Started Successfully 1272 Server running on: CDFMVS08
$ java.net.SocketTimeoutException: Accept timed out at java.net.PlainSocketImpl.socketAccept(Native Method) at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:384) at java.net.ServerSocket.implAccept(ServerSocket.java:471) at java.net.ServerSocket.accept(ServerSocket.java:442) at com.ibm.etools.systems.dstore.core.server.ConnectionEstablisher. ...
Wenn Sie den vorherigen IVP-Test aus dem Abschnitt REXEC-Verbindung 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:
fekfivps
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):
$ fekfivps $ java version "1.5.0" expect to see time out messages after a successful IVP test 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 Server Started Successfully 1751 Server running on: CDFMVS08$
$ java.net.SocketTimeoutException: Accept timed out at java.net.PlainSocketImpl.socketAccept(Native Method) at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:384) at java.net.ServerSocket.implAccept(ServerSocket.java:471) at java.net.ServerSocket.accept(ServerSocket.java:442) at com.ibm.etools.systems.dstore.core.server.ConnectionEstablisher. ...
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 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 Port-Nummer 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 Waiting for JES Job Monitor response... ACKNOWLEDGE01v03 Success
Dieser IVP-Test ist nur notwendig, wenn Sie das SCLM Developer Toolkit für den TSO Commands Service oder das Client-Plug-in verwenden.
Überprüfen Sie bei Verwendung von SCLM Developer die Verbindung zum TSO Commands Server, indem Sie den folgenden Befehl ausführen.
fekfivpc
Der Befehl sollte die Ergebnisse der auf das 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):
$ fekfivpc ------------------------------------------------------------- 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/wd4z/rse/lib:/usr/lpp/SCLM DT/bin:/bin:/usr/sbin:. STEPLIB = BWB.SBWBLOAD _CMDSERV_BASE_HOME = /usr/lpp/SCLMDT _CMDSERV_CONF_HOME = /etc/SCLMDT _CMDSERV_WORK_HOME = /var/SCLMDT ------------------------------------------------------------- *** CHECK : HFS MODULES Checking install Directory : /usr/lpp/SCLMDT Checking for BWB modules in /bin directory 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 fekfivpc kann mit mehreren optionalen, nicht positionsgebundenen Parametern verwendet werden:
Führen Sie diese Prozedur nur aus, wenn Sie APPC für den TSO Commands Service konfiguriert haben.
Überprüfen Sie (bei Verwendung von APPC) die Verbindung zum TSO Commands Server, 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: 20070607 13:57:18.584060 /usr/lpp/wd4z/rse/lib/fekfscmd: version=Oct 2003 20070607 13:57:18.584326 Input parms: 1.2.3.4 * NOTRACE USERID ******** 20070607 13:57:18.585132 TP_name set via envvar: FEKFRSRV 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
Informationen zur Diagnostizierung von RSE-Verbindungsproblemen können Sie Anhang B. Konfigurationsprobleme lösen oder den technischen Hinweisen auf der Supportseite zu Developer für System z (http://www-306.ibm.com/software/awdtools/devzseries/support/) entnehmen.
Alle Verbindungsmethoden der Clientkomponente von Developer für System z verwenden die in der Datei ssl.properties gesetzten SSL-Variablen (Secure Sockets Layer). Standardmäßig befindet sich die Datei im Installationsverzeichnis /usr/lpp/wd4z/rse/lib/. Die Datei ssl.properties gehört allerdings zu den Dateien, die ebenfalls kopiert werden müssen, wenn Sie rsed.envvars in ein anderes Verzeichnis, z. B. in /etc/wdz4/, kopieren. Die bereitgestellte Beispieldatei enthält die in Abb. 6 aufgelisteten Anweisungen. Kommentarzeilen beginnen mit einem Nummernzeichen (#).
# Setzen Sie dieses Merkmal zum Aktivieren von SSL auf true. enable_ssl=false ################################### # Dämonmerkmale # Die vom Dämon zu verwendende Schlüsseldatei und das # zu verwendende Kennwort müssen angegeben werden. # Der Schlüsselkennsatz muss angegeben werden, wenn # kein Standardschlüssel verwendet wird. #daemon_keydb_file= #daemon_keydb_password= #daemon_key_label= ################################### # Servermerkmale # Die vom Server zu verwendende Keystore-Datei und das # zu verwendende Kennwort müssen angegeben werden. #server_keystore_file= #server_keystore_password=
Die Dämon- und Servermerkmale müssen nur gesetzt werden, wenn Sie SSL aktivieren. Weitere Informationen zur SSL-Konfiguration enthält Anhang E. SSL konfigurieren.
Alle Verbindungsmethoden der Clientkomponente von Developer für System z verwenden die in der Datei rsecomm.properties gesetzten Variablen. Standardmäßig befindet sich die Datei im Installationsverzeichnis /usr/lpp/wd4z/rse/lib/. Die Datei rsecomm.properties gehört allerdings zu den Dateien, die ebenfalls kopiert werden müssen, wenn Sie rsed.envvars in ein anderes Verzeichnis, z. B. in /etc/wdz4/, kopieren. Die bereitgestellte Beispieldatei enthält die in Abb. 7 aufgelisteten Anweisungen. Kommentarzeilen beginnen mit einem Nummernzeichen (#).
# server.version - NICHT ÄNDERN! server.version=5.0.0 # Protokollstufe # 0 - Fehlernachrichten protokollieren # 1 - Fehlernachrichten und Warnungen protokollieren # 2 - Fehlernachrichten, Warnungen und Informationen protokollieren # 3 - Fehlernachrichten, Warnungen, Informationen und Debug-Nachrichten protokollieren debug_level=1 # Protokollposition # Log_To_StdOut # Log_To_File log_location=Log_To_File
Wenn Sie log_location=Log_To_File (die Standardeinstellung) auswählen, werden die Protokollnachrichten in home/.eclipse/RSE/USERID/rsecomm.log geschrieben. Hier steht home für den im OMVS-Segment des Benutzers definierten Ausgangspfad (bzw. den im Standard-OMVS-Segment definierten Ausgangspfad, falls der Benutzer kein eigenes OMVS-Segment hat), und USERID ist die ID des angemeldeten Benutzers (in Großbuchstaben).
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 Merkmale dieser Projekte können jedoch nicht vom Client geändert werden und sind nur bei bestehender Verbindung zum Host verfügbar.
Die Position der Projektdefinitionen ist in der Datei projects.properties festgelegt. Die Datei befindet sich standardmäßig im Installationsverzeichnis /usr/lpp/wd4z/rse/lib/. Die Datei projectcfg.properties gehört allerdings zu den Dateien, die ebenfalls kopiert werden müssen, wenn Sie rsed.envvars in ein anderes Verzeichnis, z. B. in /etc/wdz4/, kopieren.
Die bereitgestellte Beispieldatei enthält die in Abb. 8 aufgelisteten Anweisungen. Kommentarzeilen beginnen mit einem Nummernzeichen (#).
# # 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/wd4z/projects
Die einzige zu ändernde Variable ist PROJECT-HOME. Dieser Wert (standardmäßig /var/wd4z/projects) ist das Basisverzeichnis für Projektdefinitionen.
Weitere Informationen zu hostbasierten Projekten enthält das White Paper Host Based Projects in WebSphere Developer for System z Version 7.0 in der Internetbibliothek zu Developer für System z (http://www-306.ibm.com/software/awdtools/devzseries/library/).
Developer für 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 für z/OS stellt umfassende Tools für die Arbeit mit MVS-Dateigruppen 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 für System z wird nur das Anzeigen/Bearbeiten von MVS-Dateigruppen (einschließlich VSAM KSDS und ESDS) unterstützt.
Beachten Sie, dass Sie das Produkt IBM File Manager für z/OS gesondert bestellen, installieren und konfigurieren müssen. Welche Version des File Manager für Ihre Version von Developer für System z erforderlich ist, können Sie der Veröffentlichung Rational Developer für System z Hostplanung (IBM Form GI11-3123-00) entnehmen. Die Installation und Anpassung dieses Produkts ist nicht in diesem Handbuch beschrieben.
Die von Developer für System z benötigten File-Manager-Definitionen sind in FMIEXT.properties gespeichert. Diese Datei befindet sich standardmäßig im Installationsverzeichnis (/usr/lpp/wd4z/rse/lib/). Die Datei FMIEXT.properties gehört allerdings zu den Dateien, die ebenfalls kopiert werden müssen, wenn Sie rsed.envvars in ein anderes Verzeichnis, z. B. in /etc/wdz4/, kopieren.
Die bereitgestellte Beispieldatei enthält die in Abb. 9 aufgelisteten Anweisungen. Kommentarzeilen beginnen mit einem Nummernzeichen (#).
# Erweiterungsmerkmale für File Manager Integration (FMI) # startup.script=/usr/lpp/wd4z/rse/lib/fmiSub startup.port=1957 startup.range=100 startup.fmload=FMN.SFMNMOD1 startup.jobcard1=//JOBCARD JOB <Jobparameter> startup.jobcard2=//* startup.jobcard3=//* startup.sysout=*
Common Access Repository Manager (CARMA) (FMID HCMA710) ist eine Produktivitätshilfe für Entwickler, die APIs für Software Configuration Manager (SCM) erstellen. Mit diesen APIs können Anwendungen (z. B. Developer für System z) auf die SCM zugreifen.
Wenn Sie mit einer früheren CARMA-Version arbeiten, sollten Sie die zugehörigen Anpassungsdateien speichern, bevor Sie Version 7.1.1 installieren. Lesen Sie hierzu den Abschnitt Bereits konfigurierte Dateien sichern.
Nach der Installation von CARMA müssen Sie die folgenden Konfigurationsschritte ausführen:
In Tabelle 2 sind Handbücher aufgelistet, in denen Sie weitere Informationen zu CARMA und zur Verwendung von CARMA finden.
Den Umfang der von CARMA generierten Trace-Informationen kann der Benutzer steuern, indem er auf dem Client auf der Registerseite Merkmale der CARMA-Verbindung die Trace-Stufe definiert. Folgende Optionen sind für die Trace-Stufe verfügbar:
Die Standardeinstellung ist
Fehler
. Weitere Informationen zur Position der Protokolldateien enthält der Abschnitt Position von Protokolldateien.
Alle in diesem Abschnitt enthaltenen Verweise auf HLQ beziehen sich auf den während der Installation von CARMA verwendeten High Level Qualifier. Die Standardeinstellung für die Installation ist CRA, die jedoch nicht für Ihren Standort zutreffen muss.
Führen Sie zum Konfigurieren Ihres MVS-Hosts die folgenden Schritte aus:
Falls Sie sich nicht mit z/OS UNIX auskennen, sollten Sie einen erfahrenen z/OS-UNIX-Administrator oder anderen UNIX-Administrator bitten, Sie bei der Ausführung der in diesem Abschnitt beschriebenen Tasks zu unterstützen.
Die für die aufgeführten Tasks erforderlichen z/OS-UNIX-Befehle werden hier kurz für Sie beschrieben. Weitere Informationen zu diesen Befehlen entnehmen Sie bitte der Veröffentlichung UNIX System Services Command Reference (IBM Form SA22-7802), sofern nichts anderes angegeben ist.
Alle Pfadangaben in diesem Abschnitt, die /usr/lpp/wd4z/ enthalten, beziehen sich auf den während der Installation von Developer für System z (nicht von CARMA) verwendeten Pfad. Der Standardpfad ist /usr/lpp/wd4z/; an Ihrem Standort kann jedoch ein anderer Pfad verwendet worden sein.
Führen Sie die folgenden Schritte aus, um die zusammen mit IBM Rational Developer für System z (FMID HHOP710) installierten CARMA-z/OS-UNIX-Komponenten zu konfigurieren:
cp /usr/lpp/wd4z/rse/lib/CRASRV.properties /etc/wd4z
# CARMA-Konfigurationsoptionen # port.start=5227 port.range=100 startup.script.name=/usr/lpp/wd4z/rse/lib/rexxsub clist.dsname='HLQ.SCRACLST(CRASUBMT)'
Repository Access Manager (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 enthält der Rational Developer für System z Common Access Repository Manager Developer's Guide (IBM Form SC23-7660).
Das Developer Toolkit von IBM Software Configuration and Library Manager (SCLM)(FMID HSD3310) 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.
Das im Lieferumfang von Developer für System z enthaltene SCLM Developer Toolkit ist 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ört die Synchronisation mit SCLM auf dem Großrechner sowie die Build-Erstellung, die Assemblierung und das Deployment des J2EE-Codes vom Großrechner.
In Tabelle 2 sind Handbücher aufgelistet, in denen Sie weitere Informationen zum SCLM Developer Toolkit sowie zur Installation, Anpassung und Verwendung des Toolkit finden.
Benutzer der Clientkomponente von Developer für System z müssen das Ergebnis bestimmter Hostanpassungen, z. B. der TCP/IP-Port-Nummern, kennen, damit der Client fehlerfrei funktioniert. Die erforderlichen Informationen können Sie der Prüfliste in Tabelle 12 entnehmen.
Anpassung | Wert |
---|---|
Port-Nummer von JES Job Monitor Server (Standard: 6715)
Lesen Sie die Beschreibung für SERV_PORT im Abschnitt Konfigurationsdatei für JES Job Monitor (FEJJCNFG) anpassen. |
|
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 Build-Erstellung anpassen. |
|
Namen der ELAXF*-Prozeduren und/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 Build-Erstellung anpassen. |
|
Name der gespeicherten DB2-Prozedur (Standard: ELAXMSAM)
Lesen Sie die Informationen zu gespeicherten DB2-Prozeduren in Anhang A. Mehrere Instanzen von Developer für System z ausführen. |
|
Position der gespeicherten DB2-Prozedur, sofern sie nicht in einer Prozedurenbibliothek des Systems enthalten ist
Lesen Sie hierzu den Abschnitt ELAXM*-Member für gespeicherte DB2-Prozedur anpassen (optional). |
|
Für RSE verwendete Verbindungsmethode (Dämon, REXEC oder SSH)
Lesen Sie hierzu den Abschnitt INETD-Dämon und -REXEC/SSH für RSE konfigurieren. |
|
TCP/IP-Port-Nummer des RSE-Dämons (Standard: 4035)
Lesen Sie hierzu den Abschnitt INETD-RSE-Dämon konfigurieren. |
|
Pfad zum Shell-Script server.zseries für
REXEC/SSH (Standard: /usr/lpp/wd4z/rse/lib; empfohlener Pfad: /etc/wd4z)
Lesen Sie hierzu den Abschnitt INETD-REXEC (oder -SSH) konfigurieren. |
|
REXEC- oder SSH-Port-Nummer (Standard 512 bzw. 22)
Lesen Sie hierzu den Abschnitt INETD-REXEC (oder -SSH) konfigurieren. Anmerkung:
Ferne (hostbasierte) Aktionen für z/OS-UNIX-Unterprojekte erfordern, dass auf dem Host REXEC oder
SSH aktiv ist. |
|
Position der CRA#ASLM-JCL für das Anlegen von CARMA-SCLM-RAM-Dateigruppen
Lesen Sie die Anmerkung zu CRA#ASLM im Abschnitt SCLM-RAM aktivieren. |
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 für System z führen können.
Weitere Informationen zur Systemoptimierung finden Sie im MVS Initialization and Tuning Guide (IBM Form SA22-7591) und 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. Der RSE-Server startet mehrere Prozesse, und für jede Clientverbindung gibt es einen privaten RSE-Server. Die Zahlen können sich daher schnell stark summieren.
In rsed.envvars ist die Standardeinstellung für Developer für System z mit STEPLIB=NONE codiert. Lesen Sie hierzu die Beschreibung im Abschnitt RSE-Konfigurationsdatei rsed.envvars anpassen. Aus den oben genannten Gründen sollten Sie diese Anweisung nicht ändern und die resultierenden Dateigruppen stattdessen in die LINKLIST oder den LPA (Link-Pack-Bereich) stellen.
Wenn Sie die Steueranweisung STEPLIB nicht verwenden, müssen Sie den Inhalt der Datei rsed.envvars überprüfen, um festzustellen, ob Ihre STEPLIB-Anweisung die erste Anweisung ist.
STEPLIB=first.steplib.dataset:second.steplib.dataset
STEPLIB=$STEPLIB:first.steplib.dataset:second.steplib.dataset
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 Adressbereich, der ein LE-fähiges Programm ausführt, werden ungefähr 4 MB der Laufzeitbibliothek in den Speicher geladen und in jede Verzweigung kopiert.
Die Dateigruppe CEE.SCEELPA enthält eine Untergruppe der LE-Laufzeitroutinen, die besonders oft von z/OS UNIX verwendet werden. Sie sollten diese Dateigruppe 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 Dateigruppen 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 des Managements 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 im Abschnitt RSE-Konfigurationsdatei rsed.envvars anpassen. 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 Compilerdateigruppe 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 finden Sie in der Veröffentlichung UNIX System Services Planning (IBM Form GA22-7800).
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, so dass 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.
Wenn Sie die gemeinsame Klassennutzung für den RSE-Server aktivieren möchten, entfernen Sie das Kommentarzeichen für die folgende Steueranweisung in rsed.envvars. Die diesbezügliche Beschreibung finden Sie im Abschnitt Zusätzliche Java-Startparameter mit _RSE_*OPTS definieren (optional). 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.)
_RSE_CLASS_OPTS=-Xshareclasses:name=RSE,groupAccess,nonFatal #_RSE_CLASS_OPTS="$_RSE_CLASS_OPTS -Xscmx6m
Die theoretische maximale Größe des gemeinsam genutzten Cache liegt bei 2 GB. Die Cachegröße, die Sie angeben können, wir durch den auf dem System verfügbaren physischen Hauptspeicher und den verfügbaren Auslagerungsspeicher begrenzt. Da der virtuelle Adressbereich eines Prozesses sowohl vom Cache für gemeinsam genutzte Klassen als auch vom Java-Heap-Speicher verwendet wird, führt eine Erhöhung der maximalen Java-Heap-Größ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, so dass 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-SecurityManager 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 Parameter sind die BPXPRMxx-Parameter.
Diese Einstellungen beeinflussen, wie viele gemeinsam genutzte Speicherseiten der JVM zur Verfügung stehen. Für einen z/OS-UNIX-Systemservice (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 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 finden Sie im 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.
Bei einem Heap-Speicher 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 Heap-Speichers mit fester Größe jedoch keine gute Idee, weil sie den Start der Garbage-Collection hinauszögert, bis der Heap-Speicher voll ist. Die dann ausgeführte Garbage-Collection ist dementsprechend umfangreich. Außerdem steigt das Fragmentierungsrisiko, so dass eine Heap-Komprimierung erforderlich ist. Heap-Speicher mit fester Größe sollten Sie daher nur nach gründlichen Tests bzw. unter Anleitung des IBM Support Center verwenden. Weitere Informationen zu Heap-Größen und Garbage-Collections enthält der Java Diagnostics Guide (IBM Form SC34-6650).
Der Heap-Speicher einer z/OS-JVM hat standardmäßig eine Anfangsgröße von einem 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 für 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_*OPTS definieren (optional).
#_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Xms128m -Xmx128m"
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. Beim Workload-Management 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 für 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).
In bestimmten Situationen, z. B. beim Testen eines Upgrades, kann die Ausführung mehrerer aktiver Instanzen von Developer für System z auf demselben System erwünscht sein. Manche Ressourcen können jedoch nicht gemeinsam genutzt werden, z. B. TCP/IP-Ports, so dass die Standardeinstellungen nicht immer anwendbar sind. Anhand der Informationen in diesem Anhang können Sie die Koexistenz verschiedener Instanzen von Developer für System z planen, um sie dann gestützt auf dieses Konfigurationshandbuch anzupassen.
Die gemeinsame Nutzung bestimmter Komponenten von Developer für 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 Konfigurations-Membern keine weiteren Änderungen gibt. Developer für System z bietet genug Anpassungsspielraum für die Erstellung mehrerer Instanzen ohne Überschneidung. Wir raten Ihnen dringend, diese Anpassungsfeatures zu nutzen.
Unter ganz bestimmten Umständen können Sie (fast) alle anpassbaren Komponenten gemeinsam nutzen. Eines der Beispiele ermöglicht für die Nutzung vor Ort den Zugriff ohne SSL und für die Nutzung an einem anderen Standort die mit SSL verschlüsselte Kommunikation.
Wenn Sie eine andere Instanz einer aktiven Installation von Developer für System z konfigurieren möchten, führen Sie erneut die Anpassungsschritte für die Komponenten aus, die verschieden sind. Verwenden Sie dazu verschiedene Dateigruppen/Verzeichnisse/Ports, um Überschneidungen mit der aktuellen Konfiguration zu vermeiden.
In dem oben erwähnten SSL-Beispiel können die aktuellen RSE-Serveranpassungen geklont werden. Im Anschluss daran können Sie die geklonte Datei ssl.properties aktualisieren. 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:
Wenn Codeänderungen vorgenommen werden müssen (Wartungsrelease, technische Neuentwicklungen, neues Release) oder Ihre Änderungen ziemlich komplex sind, sollten Sie Developer für 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 für 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 Anhang soll Sie bei einigen allgemeinen Problemen unterstützen, die beim Konfigurieren von Developer für System z auftreten könnten.
Weitere Informationen sind im Bereich 'Support' der Website zu Developer für System z (http://www-306.ibm.com/software/awdtools/devzseries/support/) verfügbar. In diesem Bereich finden Sie die aktuellsten technischen Hinweise des Unterstützungsteams.
Die aktuellste Version der Dokumentation zu Developer für System z, einschließlich White Papers und anderer hilfreicher Informationen, finden Sie im Abschnitt 'Library' der Website.
Wertvolle Informationen enthält auch die z/OS-Internetbibliothek mit der Adresse http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/.
Developer für 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 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 folgenden Verzeichnissen:
Die meisten Protokolldateien befinden sich in home/.eclipse/RSE/USERID/. Home steht hier für den im OMVS-Segment des Benutzers definierten Ausgangspfad (bzw. den im Standard-OMVS-Segment definierten Ausgangspfad, falls der Benutzer kein eigenes OMVS-Segment hat). USERID ist die ID des angemeldeten Benutzers (in Großbuchstaben).
/tmp/ enthält Dateien, die vor der Prüfung der Benutzer-ID erstellt wurden.
Es werden normale Operationen protokolliert. Der Standardwert in der Beispiel-JCL HLQ.SFEKSAMP(FEJJJCL) ist SYSOUT=*.
Trace-Protokollierung. Der Standardwert in der Beispiel-JCL HLQ.SFEKSAMP(FEJJJCL) ist SYSOUT=*. Der Trace wird mit dem Parameter -TV aktiviert. Weitere Details hierzu enthält der Abschnitt Start-JCL für JES Job Monitor anpassen.
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 HLQ.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 HLQ.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).
Die zu RSE gehörenden Komponenten erstellen mehrere Protokolldateien. Die meisten dieser Dateien befinden sich im Verzeichnis Home/.eclipse/RSE/USERID/. Home steht hier für den im OMVS-Segment des Benutzers definierten Ausgangspfad (bzw. den im Standard-OMVS-Segment definierten Ausgangspfad, falls der Benutzer kein eigenes OMVS-Segment hat). USERID ist die ID des angemeldeten Benutzers (in Großbuchstaben).
Das in ffs*.log, lock.log und rsecomm.log geschriebene Datenvolumen wird von der Einstellung debug_level in rsecomm.properties gesteuert. Weitere Details hierzu enthält der Abschnitt RSE-Trace-Konfiguration in rsecomm.properties anpassen (optional).
Diese Datei enthält ein Protokoll des Dämons vor der Anmeldung.
Ausgabe des Befehls fekfivpc -file (IVP-Test bezogen auf das SCLM Developer Toolkit). Home steht hier für den im OMVS-Segment des Benutzers definierten Ausgangspfad (bzw. den im Standard-OMVS-Segment definierten Ausgangspfad, falls der Benutzer kein eigenes OMVS-Segment hat). USERID ist die ID des angemeldeten Benutzers (in Großbuchstaben).
Weitere Einzelheiten hierzu enthält der Abschnitt TSO-Commands-Service-Verbindung (bei Verwendung von SCLMDT).
Protokollierung für Fault Analyzer Integration. Home steht hier für den im OMVS-Segment des Benutzers definierten Ausgangspfad (bzw. den im Standard-OMVS-Segment definierten Ausgangspfad, falls der Benutzer kein eigenes OMVS-Segment hat). USERID ist die ID des angemeldeten Benutzers (in Großbuchstaben).
Wenn Sie eine Verbindung zum File Manager öffnen, wird ein Serverjob mit der Benutzer-ID als Eigner gestartet. Der Name des Jobs ist FEKport. Die Angabe port steht hier für den verwendeten TCP/IP-Port.
Die SYSPRINT-Karte des Serverjobs enthält die FMI-Serverprotokollierung.
Protokollierung der FMI-Kommunikation. Home steht hier für den im OMVS-Segment des Benutzers definierten Ausgangspfad (bzw. den im Standard-OMVS-Segment definierten Ausgangspfad, falls der Benutzer kein eigenes OMVS-Segment hat). USERID ist die ID des angemeldeten Benutzers (in Großbuchstaben).
Das in diese Datei geschriebene Datenvolumen wird von der Einstellung debug_level in rsecomm.properties gesteuert. Weitere Details hierzu enthält der Abschnitt RSE-Trace-Konfiguration in rsecomm.properties anpassen (optional).
Wenn Sie eine Verbindung zu CARMA öffnen, startet HLQ.SCRACLST(SCRASUBMT) einen Serverjob CRAport (mit der Benutzer-ID als Eigner). Die Angabe port im Namen steht hier für den verwendeten TCP/IP-Port.
Wenn in HLQ.SCRACLST(SCRASUBMT) die DD-Anweisung CARMALOG angegeben ist, wird die CARMA-Protokollierung an diese DD-Anweisung im Serverjob umgeleitet. Andernfalls ist sie auf der SYSPRINT-Karte enthalten.
Der Protokollierungsumfang wird durch die Einstellung Trace-Stufe auf dem Client bestimmt. Weitere Details zum Festlegen der Trace-Stufe enthält IBM Common Access Repository Manager (CARMA) aktivieren (optional).
Die SYSPRINT-Karte des Serverjobs enthält die CARMA-Protokollierung, sofern nicht die DD-Anweisung CARMALOG definiert ist.
Protokollierung der CARMA-Kommunikation. Home steht hier für den im OMVS-Segment des Benutzers definierten Ausgangspfad (bzw. den im Standard-OMVS-Segment definierten Ausgangspfad, falls der Benutzer kein eigenes OMVS-Segment hat). USERID ist die ID des angemeldeten Benutzers (in Großbuchstaben).
Das in diese Datei geschriebene Datenvolumen wird von der Einstellung debug_level in rsecomm.properties gesteuert. Weitere Details hierzu enthält der Abschnitt RSE-Trace-Konfiguration in rsecomm.properties anpassen (optional).
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 Speicherauszüge von Developer für 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 &userid.JVM.TDUMP.&jobname.D&date.T&time 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.
Der Speicherauszug wird in eine z/OS-UNIX-Datei mit dem Namen CEEDUMP.jjjjmmdd.hhmmss.pid geschrieben. Hier stehen jjjjmmdd 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.jjjjmmdd.hhmmss.pid.TXT geschrieben. Hier stehen jjjjmmdd 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.jjjjmmdd.hhmmss.pid.TXT geschrieben. Hier stehen jjjjmmdd 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 finden Sie im Java Diagnostics Guide (IBM Form SC34-6650). LE-spezifische Informationen sind im Language Environment Debugging Guide (IBM Form GA22-7560) enthalten.
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.
Remote Systems Explorer (RSE) ist die Komponente von Developer für 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 Programmsteuerungsbit dort, wo es erforderlich ist, gesetzt.
Sie können dieses Ergebnis mit dem Befehl ls -lE fekf* überprüfen, dessen Ausgabe in etwa wie das folgende Beispiel aussieht. ($ ist die z/OS-UNIX-Eingabeaufforderung.)
$ ls -lE /usr/lpp/wd4z/rse/lib/fekf* -rwxr-xr-x -ps- 2 user group 94208 Jun 12 16:21 /usr/lpp/wd4z/rse/lib/fekfdir.dll -rwxr-xr-x -ps- 2 user group 143360 Jun 12 16:21 /usr/lpp/wd4z/rse/lib/fekfdivp -rwxr-xr-x --s- 2 user group 480 Jun 12 16:21 /usr/lpp/wd4z/rse/lib/fekfivpa -rwxr-xr-x --s- 2 user group 342 Jun 12 16:21 /usr/lpp/wd4z/rse/lib/fekfivpc -rwxr-xr-x --s- 2 user group 445 Jun 12 16:21 /usr/lpp/wd4z/rse/lib/fekfivpd -rwxr-xr-x --s- 2 user group 1491 Jun 12 16:21 /usr/lpp/wd4z/rse/lib/fekfivpj -rwxr-xr-x --s- 2 user group 883 Jun 12 16:21 /usr/lpp/wd4z/rse/lib/fekfivpr -rwxr-xr-x --s- 2 user group 307 Jun 12 16:21 /usr/lpp/wd4z/rse/lib/fekfivps -rwxr-xr-x -ps- 2 user group 139264 Jun 12 16:21 /usr/lpp/wd4z/rse/lib/fekflock -rwxr-xr-x -ps- 2 user group 196608 Jun 12 16:21 /usr/lpp/wd4z/rse/lib/fekfrsed -rwxr-xr-x --s- 2 user group 42443 Jun 12 16:21 /usr/lpp/wd4z/rse/lib/fekfscmd
Setzen Sie die folgenden Befehle ab, wenn das Programmsteuerungsbit manuell gesetzt werden muss. Hier wird vorausgesetzt, dass Sie das Standardinstallationsverzeichnis (/usr/lpp/wd4z/rse/lib/) verwendet haben.
1. cd /usr/lpp/wd4z/rse/lib 2. extattr +p fekfdir.dll fekfivp fekflock fekfrsed
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 eines der folgenden Beispiele aus. Die letzte Zahl in der Zeile bzw. 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 für System z verwendet werden.
IPV4
MVS TCP/IP NETSTAT CS V1R7 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 INETD4 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 V1R7 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 INETD4 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 zwei allgemeine Bereiche, in denen TCP/IP-Ports reserviert werden:
Auf diese Dateigruppe 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 sieht in etwa wie das folgende Beispiel aus:
MVS TCP/IP NETSTAT CS V1R7 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-Server ist ein Java-UNIX-Prozess und erfordert für seine Funktionen eine große Regionsgröße. Deshalb ist es wichtig, dass für OMVS-Adressbereiche große Speichergrenzen festgelegt werden.
INETD startet einen RSE-Server, wenn ein Client eine Verbindung zum RSE-Dämon-Port herstellt oder mit REXEC/SSH das Start-Script aufruft. Hierfür werden die Speichergrenzen von INETD verwendet, die demzufolge entsprechend groß festgelegt sein müssen.
Setzen Sie MAXASSIZE in SYS1.PARMLIB(BPXPRMxx) (zum Definieren der Standardregionsgröße bzw. -prozessgröße für den OMVS-Adressbereich) auf mindestens 2147483647.
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 SA22-7627).
Überprüfen Sie ASSIZEMAX im OMVS-Segment der Clientbenutzer-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-Adressbereichs nicht von den System-Exits 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 SA22-7627).
Mit der folgenden Prozedur können Informationen zusammengestellt werden, die notwendig sind, um Probleme bei Fehlerrückmeldungen für ferne Build-Prozeduren 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 den während der Installation von Developer für System z verwendeten High Level Qualifier. 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.SF1.Z682746.XML 23 //COBOL.WSEDSF2 DD DISP=MOD, // DSN=uid.ERRCOB.member.SF1.Z682747.XML
Falls Sie die APPC-Version des 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 den TSO Commands Service definieren 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 Transaktion inaktivieren. Die Transaktion ist jedoch unverändert vorhanden, akzeptiert dann allerdings keine Verbindungen mehr.
Nachfolgend sind technische Hinweise aufgelistet, die derzeit auf der Unterstützungswebsite (http://www-306.ibm.com/software/awdtools/devzseries/support/) verfügbar sind. Zusätzliche Informationen entnehmen Sie bitte direkt der Unterstützungswebsite.
SYS1.PARMLIB(BPXPRMxx) definiert viele z/OS-UNIX-bezogene Begrenzungen, die erreicht werden können, wenn mehrere Clientkomponenten von Developer für System z aktiv sind. Die meisten BPXPRMxx-Werte können mit den Konsolbefehlen SETOMVS und SET OMVS dynamisch geändert 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-Adressbereiche und z/OS-UNIX-Benutzer.
Für das Lesen und Schreiben einer MVS-Dateigruppe muss 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 der Member SYS1.PARMLIB(BPXPRMxx) die folgenden Anweisungen enthält:
FILESYSTYPE TYPE(UDS) ENTRYPOINT(BPXTUINT) NETWORK DOMAINNAME(AF_UNIX) DOMAINNUMBER(1) MAXSOCKETS(200) TYPE(UDS)
Wenn Sie eine dynamische virtuelle IP-Adresse (VIPA) für mehrere TCPIP-Stacks verwenden, muss die Zuordnung ephemerer Ports für den gesamten Sysplex so koordiniert werden, dass das 4-Tupel (die Kombination aus Quellen- und Ziel-IP-Adressen und Ports) für jede Verbindung eindeutig bleibt. Zu diesem Zweck können Sie den optionalen Parameter SYSPLEXPORTS zur ersten Anweisung VIPADISTRIBUTE hinzufügen. Eine diesbezügliche Beschreibung finden Sie im Communications Server IP Configuration Guide (IBM Form SC31-8775).
Wenn Sie dieses Verfahren anwenden, vergewissern Sie sich, dass die Coupling-Facility-Struktur EZBEPORT (mit Informationen zur Sysplex-Port-Zuordnung) definiert wurde. Informationen hierzu finden Sie im Communications Server SNA Network Implementation Guide (IBM Form SC31-8777).
Sollten Sie nach dem Durchlesen dieses Handbuchs und der technischen Hinweise auf der Unterstützungswebsite (http://www-306.ibm.com/software/awdtools/devzseries/support/) noch immer Schwierigkeiten haben und Hilfestellung von der IBM Unterstützungsfunktion benötigen, stellen Sie die folgenden Informationen in einem Problemsatz für IBM zusammen:
Die folgenden Informationen sind für die Lösung von Verbindungsproblemen hilfreich.
Bei Verwendung des SCLM Developer Toolkit für den TSO Commands Service (Standardmethode)
Bei Verwendung von APPC für den TSO Commands Service
Stellen Sie alle Informationen bereit, die für funktionale Probleme relevant erscheinen, z. B.:
Dieser Anhang soll Sie bei einigen allgemeinen Problemen unterstützen, die beim Konfigurieren von TCP/IP oder beim Überprüfen und/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).
Developer für System z ist bei der Initialisierung davon abhängig, dass TCP/IP mit dem richtigen Hostnamen konfiguriert ist. Dies impliziert, dass die verschiedenen TCP/IP- und Resolver-Konfigurationsdateien ordnungsgemäß definiert sein müssen.
Sie können Ihre TCP/IP-Konfiguration mit dem TSO-Befehl HOMETEST testen. Weitere Informationen zum Befehl HOMETEST enthält die Veröffentlichung Communications Server IP System Administrator's Commands (IBM Form SC31-8781).
Beispielausgabe des Befehls HOMETEST:
Running IBM MVS TCP/IP CS V1R7 TCP/IP Configuration Tester The FTP configuration parameter file used will be "SYS1.TCPPARMS(FTPDATA)" TCP Host Name is: CDFMVS08 Using Name Server to Resolve CDFMVS08 The following IP addresses correspond to TCP Host Name: CDFMVS08 9.42.112.75 The following IP addresses are the HOME IP addresses defined in PROFILE.TCPIP: 9.42.112.75 127.0.0.1 All IP addresses for CDFMVS08 are in the HOME list! Hometest was successful - all Tests Passed!
Der Auflöser 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 Auflöser 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 Adressbereichs des Auflösers wird eine optionale Auflöserkonfigurationsdateigruppe gelesen, auf die die DD-Karte SETUP in der JCL-Prozedur des Auflösers zeigt. Wenn die Konfigurationsdaten nicht zur Verfügung stehen, greift der Auflöser 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 Dateigruppen und HFS-Dateien anpassen. Außerdem ist es bei der Fehlerdiagnose hilfreich zu wissen, welche Konfigurationsdateigruppe 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-Stack verwendet die Konfigurationskomponente des TCP/IP-Stack TCPIP.DATA, um den HOSTNAME des Stack 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-Dateigruppe oder eine HFS-Datei sein. Dies hängt von den Einstellungen in der Auflöserkonfiguration und dem Vorhandensein bestimmter Dateien im System ab.
Die Basiskonfigurationsdatei des Auflösers enthält TCPIP.DATA-Anweisungen. Diese Datei wird wegen der enthaltenen Auflöseranweisungen referenziert, aber auch, weil sie unter anderem das Dateigruppenprä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 Auflösers wird diese Suchreihenfolge verwendet:
Wenn der Wert der Konfigurationsanweisung GLOBALTCPIPDATA für den Auflöser definiert ist, wird er verwendet. (Lesen Sie hierzu auch den Abschnitt Wissenswertes zu Auflösern.) 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 Dateigruppe 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 (Adressbereich 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.
Wenn der Wert der Konfigurationsanweisung DEFAULTTCPIPDATA für den Auflöser definiert ist, wird er verwendet. (Lesen Sie hierzu auch den Abschnitt Wissenswertes zu Auflösern.)
Die Umsetztabellen (EBCDIC-ASCII und ASCII-EBCDIC) werden referenziert, um die zu verwendenden Umsetzungsdateigruppen 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 (Adressbereich 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 Auflösers, der verwendet wird, wenn er angegeben ist. Andernfalls wird der Standard-HLQ TCPIP verwendet.
Standardmäßig versucht der Auflöser 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 Auflösers wird von TCPIP.DATA-Anweisungen gesteuert.
Die TCPIP.DATA-Auflöseranweisungen 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 Auflöser verwendet die spezifische Suchreihenfolge für Sitenamen von IPV4 uneingeschränkt für getnetbyname-API-Aufrufe. Spezifische Suchreihenfolge für Sitenamen von IPV4 (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 (Adressbereich 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 Auflösers, der verwendet wird, wenn er angegeben ist. Andernfalls wird der Standard-HLQ TCPIP verwendet.
Wie bereits erwähnt, ist Developer für System z bei der Initialisierung davon abhängig, dass TCP/IP mit dem richtigen Hostnamen konfiguriert ist. Dies impliziert, dass die verschiedenen TCP/IP- und Resolver-Konfigurationsdateien ordnungsgemäß definiert sein müssen.
Im folgenden Beispiel geht es hauptsächlich um einige Konfigurations-Tasks für TCP/IP und den Auflöser (Resolver). Beachten Sie, dass es sich nicht um eine komplette Konfiguration für TCP/IP oder den Auflöser 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-NETZ //* //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 Auflöser ü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 Debug-Zwecke 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, so dass 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 Auflöser (Resolver) synchron sein.
Beschreibung des Dateityps | Betroffene APIs | Mögliche Dateien |
---|---|---|
Basiskonfigurationsdatei des Auflösers | 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
|
Dieser Anhang soll Sie bei einigen allgemeinen Problemen unterstützen, die beim Konfigurieren von INETD oder beim Überprüfen und/oder Modifizieren einer vorhandenen Konfiguration auftreten könnten.
Der Dämon INETD führt das Servicemanagement 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 Socket-Typ 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 Einzel-Thread-Dä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 Datenstrom-Socket ein 'accept' ab. Wenn wait angegeben ist, muss der Server das 'accept' absetzen, sofern es sich um einen Datenstrom-Socket 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 verschieden sein. 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, Port-Nummern und Protokolle zuzuordnen. Diese Datei kann eine MVS-Dateigruppe 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 Port-Nummer/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 Auflösers, der verwendet wird, wenn er angegeben ist. 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 Dateigruppe:
Die der DD-Anweisung SERVICES zugeordnete Dateigruppe 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 Auflösers, der verwendet wird, wenn er angegeben ist. 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 Port-Reservierung. Wenn ein überwachter INETD-Port in PROFILE.TCPIP reserviert ist, sollte der Name der gestarteten JCL-Prozedur für den z/OS-UNIX-Kernel-Adressbereich 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. Mit Hilfe 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]
Es ist ratsam, INETD während des IPL zu 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 Shell-Sitzung 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 STCs und für Benutzerjobs. Vergessen Sie nicht, dass INETD ein Hintergrundprozess ist, so dass 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 in Abb. 11 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, // PARM='SH ps -e | grep inetd | cut -c 1-10 | xargs -n 1 kill' //* //INETD EXEC PGM=BPXBATCH,TIME=NOLIMIT,REGION=0M, // PARM='PGM /usr/sbin/inetd &PRM' //STDERR DD PATH='/tmp/bpxbatch.start.inetd.stderr', // PATHOPTS=(OWRONLY,OCREAT,OTRUNC), // PATHMODE=SIRWXU //* STDIN, STDOUT und STDENV nehmen standardmäßig den Wert /dev/null an. //* Die Ausgabe des Dämons INETD kann durch syslogd-Einstellungen gesteuert werden. //*
// PARM='PGM /usr/sbin/inetd //''SYS1.TCPPARMS(INETCONF)'' &PRM'
Wenn INETD von einer Shell-Sitzung aus gestartet wird, sucht der Dämon in der z/OS-UNIX-Suchreihenfolge 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.)
1. # ps -e | grep inetd 7 ? 0:00 /usr/sbin/inetd 2. # kill 7 3. # _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 Shell-Sitzung 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. Diese Konfiguration wird empfohlen.
Wenn Sie mehr über die Befehle extattr und su erfahren möchten, lesen Sie die Veröffentlichung UNIX System Services Command Reference (IBM Form SA22-7802). 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 zu den OMVS-Segmentdefinitionen und zur Klasse PROGRAM enthält der Security Server RACF Security Administrator's Guide (IBM Form SA22-7683).
Developer für System z ist bei der Einrichtung der Verbindung zwischen Client und Host auf INETD angewiesen. Das Produkt stellt zusätzliche Anforderungen, die über die oben beschriebenen Anforderungen an die INETD-Konfiguration hinausgehen.
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 RSE-Dämon, der von INETD gestartet wird, wenn ein Client eine Verbindung zum Port 4035 herstellt, führt die Authentifizierung durch, startet den RSE-Server und gibt die Port-Nummer für die weitere Kommunikation an den Client zurück. Die dem RSE-Dämon zugeordnete Benutzer-ID benötigt hierfür die folgenden Berechtigungen:
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.
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. Secure Sockets Layer (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 enthält der Security Server RACF Security Administrator's Guide (IBM Form SA22-7683).
Welche Aktionen erforderlich sind, um die SSL-Kommunikation für Developer für 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 Verbindung haben, die SSL verwendet. Sie werden sowohl die REXEC-Methode als auch die Methode mit der Dämonverbindung für SSL konfigurieren. Außerdem werden Sie Ihre eigenen Sicherheitszertifikate erstellen, die von den verschiedenen Teilnehmern der RSE-Verbindung verwendet werden. Für diese gesamte Prozedur werden Sie die folgenden Schritte ausführen:
In diesem Anhang wird die folgende einheitliche Namenskonvention verwendet:
Für die meisten nachfolgenden Tasks wird vorausgesetzt, dass Sie aktivierter zOS-UNIX-Benutzer sind. Zum Aktivieren können Sie den TSO-Befehl OMVS absetzen. Mit dem Befehl exit können Sie zu TSO zurückkehren.
In diesem Schritt wird eine neue Instanz des RSE-Servers und des RSE-Dämons erstellt. Die neuen Instanzen werden parallel zu den vorhandenen Instanzen ausgeführt. So ist sichergestellt, dass die SSL-Tests nicht den normalen Betrieb behindern. Bei den folgenden Beispielbefehlen wird vorausgesetzt, dass sich die Konfigurationsdateien in /etc/wd4z/ befinden. Lesen Sie hierzu die Empfehlung im Abschnitt Konfigurationsdatei rsed.envvars in einem anderen Verzeichnis speichern.
$ cd /etc/wd4z $ mkdir ssl $ cp * ssl cp: FSUM6254 "ssl" is a directory (not copied) $ ls ssl rsecomm.properties server.zseries ssl.properties rsed.envvars setup.env.zseries $ cd ssl $ su # oedit /etc/services rsessl 4047/tcp #Developer für System z RSE mit SSL
Hinzufügen des Service, der den Port 4047 verwendet
# oedit /etc/inetd.conf rsessl stream tcp nowait OMVSKERN /usr/lpp/wd4z/rse/lib/fekfrsed rsed -d /etc/wd4z/ssl
Hinzufügen des rsessl-Dämons, der das Konfigurationsverzeichnis /etc/wd4z/ssl verwendet
# ps -e | grep inetd 7 ? 0:00 /usr/sbin/inetd # kill 7 # _BPX_JOBNAME='INETD' /usr/sbin/inetd # exit $ netstat | grep 4047 INETD4 00016619 0.0.0.0..4047 0.0.0.0..0 Listen
Die oben aufgeführten Befehle erstellen ein Unterverzeichnis mit dem Namen ssl und füllen es mit den obligatorischen Konfigurationsdateien. Es müssen (noch) keine Konfigurationsänderungen vorgenommen werden. Das Installationsverzeichnis und die MVS-Komponenten können gemeinsam genutzt werden, da sie nicht SSL-spezifisch sind. Sie müssen jedoch einen neuen Dämon (rsessl) erstellen, der die neuen Konfigurationsdateien verwendet. Dem neuen Dämon wird der Port 4047 zugeordnet.
Weitere Informationen zu den oben gezeigten Aktionen enthält z/OS-UNIX-Komponenten von Developer für System z aktivieren.
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.
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 Sicherheitssoftware (z. B. RACF) verwaltete Schlüsseldatei sein. Der (vom Dämon oder von REXEC gestartete) RSE-Server ist eine Java-SSL-Anwendung und verwendet eine von keytool erstellte Keystore-Datei. RACF bietet derzeit keine vordefinierte Unterstützung für Java SSL.
Für die Verbindung über REXEC benötigen Sie somit nur die Keystore-Datei:
Für die Verbindung über den Dämon benötigen Sie den Keystore und die Schlüsseldatenbankdatei:
Weitere Informationen zu RACF und digitalen Zertifikaten enthält der Security Server RACF Security Administrator's Guide (IBM Form SA22-7683). Die Dokumentation zu gskkyman ist in der Veröffentlichung Cryptographic Services System SSL Programming (IBM Form SC24-5901) enthalten. Die Dokumentation zu keytool finden Sie unter http://java.sun.com/j2se/1.4.2/docs/tooldocs/solaris/keytool.html.
Der Befehl "keytool -genkey" 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 V1) eingeschlossen, das als Zertifikatkette mit einem Element gespeichert wird. Diese Zertifikatkette und der private Schlüssel werden als ein (mit einem Aliasnamen bezeichneten) Eintrag in einer (neuen) Keystore-Datei gespeichert.
Alle Informationen können als ein Parameter übergeben werden. Durch die Längenbeschränkung der Befehlszeile sind jedoch einige Interkationen erforderlich.
$ keytool -genkey -alias wd4zrse -validity 3650 -keystore wd4zssl.jks -storepass rsessl -keypass rsessl What is your first and last name? [Unknown]: wd4z rse ssl What is the name of your organizational unit? [Unknown]: wd4z 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=wd4z rse ssl, OU=wd4z, O=IBM, L=Raleigh, ST=NC, C=US correct? (type "yes" or "no") [no]: yes $ ls rsecomm.properties server.zseries ssl.properties rsed.envvars setup.env.zseries wd4zssl.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/wd4z/ssl/wd4zssl.jks mit dem Aliasnamen wd4zrse gespeichert. Das Kennwort (rsessl) stimmt mit dem Keystore-Kennwort überein. Dies ist eine RSE-Anforderung.
Das Ergebnis können Sie mit der Option -list überprüfen:
$ keytool -list -alias wd4zrse -keystore wd4zssl.jks -storepass rsessl -v Alias name: wd4zrse Creation date: May 24, 2007 Entry type: keyEntry Certificate chain length: 1 Certificate 1¨: Owner: CN=wd4z rse ssl, OU=wd4z, O=IBM, L=Raleigh, ST=NC, C=US Issuer: CN=wd4z rse ssl, OU=wd4z, 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
Der Dämon ist, wie bereits erwähnt, eine System-SSL-Anwendung, die eine Schlüsseldatenbankdatei verwendet. Diese Datei kann eine von gskkyman erstellte physische Datei oder eine RACF-Schlüsseldatei sein. Für die Verwaltung privater Schlüssel und Zertifikate für System SSL sind RACF-Schlüsseldateien die bevorzugte Methode.
Führen Sie diesen Schritt nicht aus, wenn Sie gskkyman für System SSL 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.
Ausführliche Informationen zum Befehl RACDCERT können Sie der Veröffentlichung Security Server RACF Command Language Reference (IBM Form SA22-7687) entnehmen.
RDEFINE FACILITY IRR.DIGTCERT.LIST UACC(NONE) RDEFINE FACILITY IRR.DIGTCERT.LISTRING UACC(NONE) PERMIT IRR.DIGTCERT.LIST CLASS(FACILITY) ACCESS(READ) ID(omvskern) PERMIT IRR.DIGTCERT.LISTRING CLASS(FACILITY) ACCESS(READ) ID(omvskern) SETROPTS RACLIST(FACILITY) REFRESH RACDCERT ID(omvskern) GENCERT SUBJECTSDN(CN('wd4z rse ssl') + OU('wd4z') O('IBM') L('Raleigh') SP('NC') C('US')) + NOTAFTER(DATE(2017-05-21)) WITHLABEL('wd4zrse') KEYUSAGE(HANDSHAKE) RACDCERT ID(omvskern) ADDRING(wd4zssl.racf) RACDCERT ID(omvskern) CONNECT(LABEL('wd4zrse') RING(wd4zssl.racf) + DEFAULT USAGE(PERSONAL))
Das obige Beispiel beginnt mit der Erstellung der notwendigen Profile und dem Berechtigen der Benutzer-ID OMVSKERN für den Zugriff auf die Schlüsseldateien. Die Benutzer-ID muss mit der in /etc/inetd.conf für den SSL-RSE-Dämon codierten Benutzer-ID übereinstimmen. Der nächste Schritt ist die Erstellung eines neuen selbst signierten Zertifikats mit der Bezeichnung wd4zrse. Es ist kein Kennwort erforderlich. Dieses Zertifikat wird dann zu einer neu erstellten Schlüsseldatei (wd4zssl.racf) hinzugefügt. Für die Schlüsseldatei ist ebenso wie für das Zertifikat kein Kennwort erforderlich. Die Lebensdauer des Zertifikats entspricht der des mit keytool erstellten Zertifikats.
Das Ergebnis können Sie mit der Option list überprüfen:
RACDCERT ID(omvskern) LIST Digital certificate information for user OMVSKERN: Label: wd4zrse 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=wd4z rse ssl.OU=wd4z.O=IBM.L=Raleigh.SP=NC.C=US< Subject's Name: >CN=wd4z rse ssl.OU=wd4z.O=IBM.L=Raleigh.SP=NC.C=US< Private Key Type: Non-ICSF Private Key Size: 1024 Ring Associations: Ring Owner: OMVSKERN Ring: >wd4zssl.racf<
Führen Sie diesen Schritt nicht aus, wenn Sie RACF für System SSL verwenden.
gskkyman ist ein Shell-basiertes, 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
$ gskkyman Database Menu 1 - Create new database 2 - Open database 3 - Change database password 4 - Change database record length 5 - Delete database 6 - Create key parameter file 0 - Exit program Enter option number: 1 Enter key database name (press ENTER to return to menu): wd4zssl.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/wd4z/ssl/wd4zssl.kdb created. Press ENTER to continue. Key Management Menu Database: /etc/wd4z/ssl/wd4zssl.kdb 1 - Manage keys and certificates 2 - Manage certificates 3 - Manage certificate requests 4 - Create new certificate request 5 - Receive requested certificate or a renewal certificate 6 - Create a self-signed certificate 7 - Import a certificate 8 - Import a certificate and a private key 9 - Show the default key 10 - Store database password 11 - Show database record length 0 - Exit program Enter option number (press ENTER to return to previous menu): 6 Certificate Type 1 - CA certificate with 1024-bit RSA key 2 - CA certificate with 2048-bit RSA key 3 - CA certificate with 4096-bit RSA key 4 - CA certificate with 1024-bit DSA key 5 - User or server certificate with 1024-bit RSA key 6 - User or server certificate with 2048-bit RSA key 7 - User or server certificate with 4096-bit RSA key 8 - User or server certificate with 1024-bit DSA key Select certificate type (press ENTER to return to menu): 5 Enter label (press ENTER to return to menu): wd4zrse Enter subject name for certificate Common name (required): wd4z rse ssl Organizational unit (optional): wd4z 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 Database: /etc/wd4z/ssl/wd4zssl.kdb 1 - Manage keys and certificates 2 - Manage certificates 3 - Manage certificate requests 4 - Create new certificate request 5 - Receive requested certificate or a renewal certificate 6 - Create a self-signed certificate 7 - Import a certificate 8 - Import a certificate and a private key 9 - Show the default key 10 - Store database password 11 - Show database record length 0 - Exit program Enter option number (press ENTER to return to previous menu): 0 $ ls -l total 152 -rwxr-xr-x 1 IBMUSER SYS1 333 May 24 13:52 rsecomm.properties -rwxr-xr-x 1 IBMUSER SYS1 6067 May 24 13:52 rsed.envvars -rwxr-xr-x 1 IBMUSER SYS1 332 May 24 13:52 server.zseries -rwxr-xr-x 1 IBMUSER SYS1 645 May 24 13:52 setup.env.zseries -rwxr-xr-x 1 IBMUSER SYS1 638 May 24 13:52 ssl.properties -rw-r--r-- 1 IBMUSER SYS1 1224 May 24 14:17 wd4zssl.jks -rw------- 1 IBMUSER SYS1 35080 May 24 14:24 wd4zssl.kdb -rw------- 1 IBMUSER SYS1 80 May 24 14:24 wd4zssl.rdb $ chmod 644 wd4zssl.kdb $ chmod 644 wd4zssl.rdb $ ls -l total 152 -rwxr-xr-x 1 IBMUSER SYS1 333 May 24 13:52 rsecomm.properties -rwxr-xr-x 1 IBMUSER SYS1 6067 May 24 13:52 rsed.envvars -rwxr-xr-x 1 IBMUSER SYS1 332 May 24 13:52 server.zseries -rwxr-xr-x 1 IBMUSER SYS1 645 May 24 13:52 setup.env.zseries -rwxr-xr-x 1 IBMUSER SYS1 638 May 24 13:52 ssl.properties -rw-r--r-- 1 IBMUSER SYS1 1224 May 24 14:17 wd4zssl.jks -rw-r--r-- 1 IBMUSER SYS1 35080 May 24 14:24 wd4zssl.kdb -rw-r--r-- 1 IBMUSER SYS1 80 May 24 14:24 wd4zssl.rdb
Das obige Beispiel beginnt mit der Erstellung einer Schlüsseldatenbank mit der Bezeichnung wd4zssl.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 unter der Bezeichnung wd4zrse 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. Masken mit 640 Bits (Eigner mit Lese-/Schreibzugriff, Gruppe des Eigners mit Lesezugriff) oder 644 Bits (Eigner mit Lese-/Schreibzugriff; Lesezugriff für alle übrigen Benutzer) sind verwendbare Masken für den Befehl chmod.
Das Ergebnis können Sie überprüfen, indem Sie im Untermenü Manage keys and certificates die Option Show certificate information auswählen:
$ gskkyman Database Menu 1 - Create new database 2 - Open database 3 - Change database password 4 - Change database record length 5 - Delete database 6 - Create key parameter file 0 - Exit program Enter option number: 2 Enter key database name (press ENTER to return to menu): wd4zssl.kdb Enter database password (press ENTER to return to menu): rsessl Key Management Menu Database: /etc/wd4z/ssl/wd4zssl.kdb 1 - Manage keys and certificates 2 - Manage certificates 3 - Manage certificate requests 4 - Create new certificate request 5 - Receive requested certificate or a renewal certificate 6 - Create a self-signed certificate 7 - Import a certificate 8 - Import a certificate and a private key 9 - Show the default key 10 - Store database password 11 - Show database record length 0 - Exit program Enter option number (press ENTER to return to previous menu): 1 Key and Certificate List Database: /etc/wd4z/ssl/wd4zssl.kdb 1 - wd4zrse 0 - Return to selection menu Enter label number (ENTER to return to selection menu, p for previous list): 1 Key and Certificate Menu Label: wd4zrse 1 - Show certificate information 2 - Show key information 3 - Set key as default 4 - Set certificate trust status 5 - Copy certificate and key to another database 6 - Export certificate to a file 7 - Export certificate and key to a file 8 - Delete certificate and key 9 - Change label 10 - Create a signed certificate and key 11 - Create a certificate renewal request 0 - Exit program Enter option number (press ENTER to return to previous menu): 1 Certificate Information Label: wd4zrse Record ID: 14 Issuer Record ID: 14 Trusted: Yes Version: 3 Serial number: 45356379000ac997 Issuer name: wd4z rse ssl wd4z IBM Raleigh NC US Subject name: wd4z rse ssl wd4z 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 Label: wd4zrse 1 - Show certificate information 2 - Show key information 3 - Set key as default 4 - Set certificate trust status 5 - Copy certificate and key to another database 6 - Export certificate to a file 7 - Export certificate and key to a file 8 - Delete certificate and key 9 - Change label 10 - Create a signed certificate and key 11 - Create a certificate renewal request 0 - Exit program Enter option number (press ENTER to return to previous menu): 0
Die Zertifikate liegen jetzt vor, so dass RSE beginnen kann, SSL zu verwenden. Welche Werte in ssl.properties angegeben werden müssen, hängt von den Definitionen ab, die Sie in den obigen Schritten ausgewählt haben.
$ oedit ssl.properties
Die SSL-Hostkonfiguration ist jetzt fertig gestellt. Sie können sie testen, indem Sie eine Verbindung zur Clientkomponente von Developer für System z herstellen. Da Sie für SSL eine neue Konfiguration (durch Klonen der vorhandenen Konfiguration) erstellt haben, müssen Sie nun eine neue Verbindung mit folgenden Kenndaten definieren:
STEPLIB=SYS1.SIEALNKE
STEPLIB=$STEPLIB:SYS1.SIEALNKE
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 für System z das Hostzertifikat 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 Protokolldateien verfügbar (home/.eclipse/RSE/USERID/* und /tmp/rsedaemon.log). Lesen Sie die diesbezügliche Beschreibung im Abschnitt RSE-Protokollierung.
Dieser Anhang soll Sie bei einigen allgemeinen Problemen unterstützen, die beim Konfigurieren von APPC (Advanced Program-to-Program Communication) oder beim Überprüfen und/oder Modifizieren einer vorhandenen Konfiguration auftreten könnten.
Zusätzliche Informationen zum APPC-Management 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.
Der Member SYS1.SAMPLIB(ATBALL) enthält eine Liste und Beschreibungen aller APPC-bezogenen Member (Beispiel-Member) in SYS1.SAMPLIB.
APPC/MVS speichert die Konfigurationsdaten in SYS1.PARMLIB-Membern und zwei VSAM-Dateigruppen:
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 für System z aktiviert ein neues Transaktionsprogramm mit dem Namen FEKFRSRV, das auch als TSO Commands Service bezeichnet wird.
Der in Abbildung 14 dargestellte Beispieljob ist eine Verkettung der Beispiel-Member 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, z. B. die logische Einheit (LU, Logical Unit), definieren. 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-System-Tasks können erst verwendet werden, wenn VTAM aktiv ist.
Der APPC-spezifische Teil der VTAM-Konfiguration umfasst drei Schritte:
Der im Beispiel-Member 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 zum Konfigurieren von VTAM finden Sie im Communications Server Bookshelf (F1A1BK61 for z/OS 1.7).
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.
Der TSO Commands Service erfordert, dass APPC mit einer Basis-LU für die Bearbeitung ein- und abgehender Anforderungen konfiguriert ist.
Die LU-Definition muss zum Member SYS1.PARMLIB(APPCPMxx) hinzugefügt werden und die Parameter BASE und SCHED(ASCH) enthalten. Der Member APPCPMxx gibt auch an, welche VSAM-Dateigruppen mit Transaktionsprofilen (TP) und Nebeninformationen (SI) verwendet werden sollen.
Abb. 16 zeigt ein Beispiel für einen SYS1.PARMLIB(APPCPMxx)-Member, der für den 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, der TSO Commands Service würde jedoch nicht funktionieren, weil diese LU keinen Transaktions-Scheduler 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 anpassen.
Der APPC/MVS-Transaktions-Scheduler (mit dem Standardnamen ASCH) leitet bei eingehenden Dialoganforderungen Transaktionsprogramme ein und steuert den zeitlichen Ablauf dieser Programme. Der Member SYS1.PARMLIB(ASCHPMxx) steuert seine Funktionen unter anderem mit Transaktionsklassendefinitionen.
Die für den TSO Commands Service verwendete APPC-Transaktionsklasse muss genug APPC-Initiatoren haben, damit für jeden Benutzer von Developer für System z ein Initiator verfügbar ist.
Der TSO Commands Service erfordert außerdem die Angabe der Standardspezifikationen in den Abschnitten OPTIONS und TPDEFAULT.
Abb. 17 zeigt ein Beispiel für einen SYS1.PARMLIB(ASCHPMxx)-Member, der für den 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 angegebenen Konsolbefehlen enthält die Veröffentlichung MVS System Commands (IBM Form SA22-7627).
Wenn APPC/MVS aktiv ist, kann der TSO Commands Service von Developer für System z definiert werden. Lesen Sie hierzu die Beschreibung im Abschnitt APPC-Transaktion für den TSO Commands Service definieren.
Für eine dokumentierte Definition der APPC-Transaktion müssen Sie HLQ.SFEKSAMP(FEKAPPCC) anpassen und übergeben. HLQ steht hier für den High Level Qualifier, der während der Installation von Developer für System z verwendet wurde (standardmäßig FEK).
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 for System z (IBM Form SC23-5885) ist in der Internetbibliothek zu Developer für System z unter http://www-306.ibm.com/software/awdtools/devzseries/library/ verfügbar.
// PARM='ISPSTART CMD(%FEKFRSRV TIMEOUT=60) NEWAPPL(ISR) NESTMACS'
Die vorliegenden Informationen wurden für Produkte und Services entwickelt, die auf dem deutschen Markt angeboten werden.
Möglicherweise bietet IBM die in dieser Dokumentation beschriebenen Produkte, Services oder Funktionen in anderen Ländern nicht an. Informationen über die gegenwärtig im jeweiligen Land verfügbaren Produkte und Services sind beim IBM Ansprechpartner erhältlich. Hinweise auf IBM Lizenzprogramme oder andere IBM Produkte bedeuten nicht, dass nur Programme, Produkte oder Services von IBM verwendet werden können. An Stelle der Produkte, Programme oder Dienstleistungen können auch andere, ihnen äquivalente Produkte, Programme oder Dienstleistungen verwendet werden, solange diese keine gewerblichen oder anderen Schutzrechte der IBM verletzen. Die Verantwortung für den Betrieb von Fremdprodukten, Fremdprogrammen und Fremddienstleistungen liegt beim Kunden.
Für in diesem Handbuch beschriebene Erzeugnisse und Verfahren kann es IBM Patente oder Patentanmeldungen geben. Mit der Auslieferung dieses Handbuchs ist keine Lizenzierung dieser Patente verbunden. Lizenzanforderungen sind schriftlich an folgende Adresse zu richten (Anfragen an diese Adresse müssen auf Englisch formuliert werden):
Trotz sorgfältiger Bearbeitung können technische Ungenauigkeiten oder Druckfehler in dieser Veröffentlichung nicht ausgeschlossen werden. Die Angaben in dieser Dokumentation werden in regelmäßigen Zeitabständen aktualisiert. Die Änderungen werden in Überarbeitungen bzw. neuen Auflagen der Veröffentlichung bekanntgegeben. 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 Handbuch aufgeführten Lizenzprogramms sowie des zugehörigen Lizenzmaterials erfolgt im Rahmen der Allgemeinen Geschäftsbedingungen der IBM, der Internationalen Nutzungsbedingungen der IBM 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 Merkmalen machen. Fragen zu den Leistungsmerkmalen von Produkten anderer Anbieter sind an den jeweiligen Anbieter zu richten.
Die oben genannten Erklärungen bezüglich der Produktstrategien und Absichtserklärungen von IBM stellen die gegenwärtige Absicht von IBM dar, unterliegen Änderungen oder können zurückgenommen werden und repräsentieren nur die Ziele von IBM.
Diese Veröffentlichung enthält Beispiele für Daten und Berichte des alltäglichen Geschä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.
COPYRIGHTLIZENZ:
Diese Veröffentlichung enthält Beispielanwendungsprogramme, die in Quellensprache geschrieben sind. 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. Sie dürfen diese Beispielprogramme kostenlos kopieren, ändern und verteilen, wenn dies zu dem Zweck geschieht, Anwendungsprogramme zu entwickeln, verwenden, vermarkten oder zu verteilen, die mit der Anwendungsprogrammierschnittstelle konform sind, für die diese Beispielprogramme geschrieben wurden.
Kopien oder Teile der Musterprogramme bzw. daraus abgeleiteter Code müssen folgenden Copyrightvermerk beinhalten:
(C) (Name Ihrer Firma) (Jahr). Teile des vorliegenden Codes wurden aus Beispielprogrammen der IBM Corp. abgeleitet. (C) Copyright IBM Corp. _Jahr/Jahre angeben_. Alle Rechte vorbehalten.
Folgende Namen sind Marken oder eingetragene Marken der International Business Machines 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.
Microsoft, Windows, Windows NT und das Windows-Logo sind Marken oder eingetragene Marken der Microsoft Corporation in den USA und/oder anderen Ländern.
UNIX ist eine eingetragene Marke von The Open Group.
Andere Unternehmens-, Produkt- und Servicenamen können Marken oder Servicemarken anderer Unternehmen sein.