Build-Server unter z/OS starten
Unter z/OS können Sie den Build-Server zum Ausführen von z/OS- oder USS-Builds konfigurieren. Wenn Sie beide Arten von Builds benötigen, müssen Sie zwei Server starten, die jeweils an einem für die einzelnen Build-Typen eindeutigen TCP/IP-Port empfangsbereit sind.
Syntax
Sie starten einen Build- Server mithilfe von z/OS-JCL-Befehlen. Die Parameterzeile hat folgende Syntax:
![Syntax: // PARM= '-p <portno> [-V ...] [-a {2|1|0} [-n <n>] [-q <q>] [-t]'](../images/gegl_core_starting_server_zos.gif)
- Gibt die Portnummer (Portnr) an, an dem der Server empfangsbereit ist, um mit den Clients zu kommunizieren.
- Gibt den Ausführlichkeitgrad des Server an. Sie können diesen Parameter bis zu dreimal angeben (maximale Ausführlichkeit).
- Gibt den Authentifizierungsmodus an:
- 2
- Serverstatus: A (autorisiert). Der Server-Code wurde in einer APF-autorisierten Bibliothek installiert. Wenn Sie einen Build mit dem fernen Build-Client initialisieren, müssen Sie die Builddeskriptoroption destUserID mit einer gültigen TSO-Benutzer-ID und destPassword mit einem gültigen TSO-Kennwort angeben. Der Server führt die Buildtransaktion unter den Zugriffsrechten und der Berechtigung dieser Benutzer-ID durch. Modus 2 ist der Standardmodus.
- 1
- Serverstatus: A. Sie können eine gültige TSO-Benutzer-ID und ein Kennwort angeben. Der Server führt die Buildtransaktion unter den Zugriffsrechten und der Berechtigung dieses Benutzers durch. Wenn Sie keine Benutzer-ID und kein Kennwort angeben, wird die Buildtransaktion mit den Zugriffsrechten und der Berechtigung der Benutzer-ID durchgeführt, die dem Build-Server-Job zugeordnet ist.
- 0
- Serverstatus: A oder U (nicht autorisiert). Wenn der Status "U" ist, schlägt das Ausführen APF-autorisierter Buildprogramme fehl. Wenn Sie eine TSO-Benutzer-ID und ein -Kennwort angeben, ignoriert der Server diese und die Buildtransaktion wird mit den Zugriffsrechten und der Berechtigung der Benutzer-ID ausgeführt, die dem Build-Server-Job zugeordnet ist.
- Gibt die Anzahl der gleichzeitig ablaufenden Builds an. Der Standardwert ist 1. Legen Sie für n die Anzahl an gleichzeitig ablaufenden Builds fest, die Sie zulassen möchten. Sobald n Builds gleichzeitig ausgeführt werden, stellt der Build-Server alle weiteren Anforderungen in die Warteschlange. Wenn ein Build abgeschlossen ist, wird der erste Build in der Warteschlange übergeben.
- Gibt die Größe der Warteschlange (q) für Clients an. Der Standardwert ist 10. Jeder Warteschlangenclient verwendet ein TCP/IP-Socket. Wenn Sie für diesen Parameter einen zu hohen Wert festlegen, sind daher unter Umständen mehr Sockets erforderlich als verfügbar sind. Dies kann zu unvorhersehbaren Ergebnissen führen. Wenn die Warteschlange voll ist, werden alle weiteren Clients vom Server abgelehnt. In diesem Fall versucht der Build-Client jedoch, den Build erneut zu erstellen.
- Startet die Traceerstellung dieses Server-Jobs und schreibt Ausgaben in STDOUT. Dieser Parameter wird normalerweise nur für das Debugging verwendet.
Prozedur
- Fügen Sie eine Jobkarte hinzu.
- Ändern Sie bei Bedarf die Parameter in der Anweisung PARM der EXEC-Karte. (Informationen hierzu finden Sie in der obigen Parameterliste.)
- Ändern Sie die Anweisung STEPLIB DD so, dass sie auf den Datensatz verweist, der die Lademodule des Build-Servers enthält. Diese Bibliothek enthält alle Lademodule des fernen Build-Servers.
- Ändern Sie die Anweisung CCUWJCL DD so, dass sie auf den Datensatz verweist, der die JCL zum Ausführen eines einzelnen Build-Jobs enthält. Hierbei sollte es sich um eine geänderte Version von CCUMVS.JCL (für z/OS-Builds) oder von CCUUSS.JCL (für USS-Builds) handeln.
- Geben Sie CCUBLOG als sequenzielle Datei an. In diese Datei wird das Protokoll des Build-Servers geschrieben.
- Ändern Sie bei Bedarf die Parameteranweisung (PARM=) für Ihren Job (siehe folgendes Beispiel).
- Übergeben Sie den Job.
Beispiel
//jobcard
//*------------------------------------------------------
//RUNPGM EXEC PGM=CCUMAIN,DYNAMNBR=30,REGION=7400K,TIME=NOLIMIT,
// PARM='-p 2604 -a 2 -n 3 -q 20'
//STEPLIB DD DSN=CCUBLD.LOADLIB,DISP=SHR
//CCUWJCL DD DISP=SHR,DSN=CCUBLD.JCL(CCUMVS) for z/OS builds
//*CCUWJCL DD DISP=SHR,DSN=CCUBLD.JCL(CCUUSS) for USS builds
//STDOUT DD SYSOUT=*
//STDERR DD SYSOUT=*
//CCUBLOG DD SYSOUT=*
Wenn Sie die JCL für USS-Builds ändern möchten,
verschieben Sie den Kommentaranzeiger (* in //*CCUWJCL)
in die vorherige Zeile hinter //.Besondere Hinweise zu z/OS-Builds
Wenn Sie den Server unter z/OS über eine APF-autorisierte Bibliothek starten (erforderlich in den Modi 1 und 2, optional im Modus 0), kann das Build-Script ein APF-autorisiertes Programm als ausführbares Programm angeben.
Wenn der Server nicht über eine APF-autorisierte Bibliothek gestartet wird, kann das Build-Script nur Programme ohne APF-Autorisierung als ausführbare Programme angeben.
Sprache für vom Build-Server zurückgegebene Nachrichten festlegen
Der Build-Server unter z/OS gibt Nachrichten in den Sprachen zurück, die in der folgenden Tabelle aufgeführt sind. Englisch ist die Standardeinstellung.
| Sprache | Code |
|---|---|
| Brasilianisches Portugiesisch | ptb |
| Chinesisch, vereinfacht | chs |
| Chinesisch, traditionell | cht |
| Amerikanisches Englisch | enu |
| Französisch | fra |
| Deutsch | deu |
| Italienisch | ita |
| Japanisch | jpn |
| Koreanisch | kor |
| Spanisch | esp |
Wenn der Build-Server Nachrichten in einer anderen Sprache als Englisch zurückgeben soll, ändern Sie die Einstellung für die Umgebungsvariable CCU_LANG auf der Clientmaschine. Die Variable enthält einen der Sprachencodes, die in der obigen Tabelle aufgeführt wurden. Um Nachrichten beispielsweise in Französisch zurückzugeben, müssten Sie die Variable CCU_LANG auf "fra" setzen.
gemeinsam_genutzte_ressourcen\eclipse\plugins
\com.ibm.etools.egl.distributedbuild_version\executables\ccu.cat.xxx
- gemeinsam_genutzte_ressourcen
- Das Produktverzeichnis für gemeinsam genutzte Ressourcen, z. B. C:\Programme\IBM\SDP70Shared unter Windows oder /opt/IBM/SDP70Shared unter Linux. Wenn Sie vor der Installation des aktuellen Produkts eine frühere Version eines IBM® Produkts installiert und beibehalten haben, das EGL enthält, müssen Sie ggf. das bei der früheren Installation eingerichtete Verzeichnis für gemeinsam genutzte Ressourcen angeben.
- version
- Die installierte Version des Plug-ins. Falls mehrere Plug-ins vorhanden sind, verwenden Sie dasjenige mit der neuesten Versionsnummer, es sei denn, Sie benötigen eine ältere Version.
- xxx
- Der Code für die gewünschte Sprache. Hierbei handelt es sich um einen der Codes, die in der obigen Tabelle aufgelistet sind.
Wenn der Build-Server unter USS ausgeführt wird und Sie Nachrichten in einer anderen Sprache als als Englisch zurückgeben möchten, müssen Sie zudem auch den Inhalt des Shell-Scripts "ccubldw.sh" ändern. Dieses Script wird bei der Installation der USS-Build-Server-Komponente angepasst.
Zur Unterstützung mehrerer Sprachen in USS müssen Sie für jede Sprache eine andere USS-Build-Server-Komponente starten. Dabei muss jede Komponente an einem anderen Port empfangsbereit sein und eine andere Version des Scripts verwenden.
export CCU_CATALOG=
/Installationsverzeichnis/usr/lpp/EnterpriseDeveloper
/BuildServer/ccu.cat.xxx
- Installationsverzeichnis
- Das Verzeichnis, in dem die USS-Build-server-Komponente installiert wird.
- xxx
- Der Code für die vom Script unterstützte Sprache. Hierbei handelt es sich um einen der in Kleinbuchstaben angegebenen Codes in der obigen Tabelle.
Weitere Details zur Konfiguration des Build-Servers
Weitere Details zum Konfigurieren eines Build-Servers finden Sie im Programmverzeichnis "IBM Rational COBOL Runtime for z/Series" (GI10-3242).