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]'
Dabei gilt Folgendes:
-p
++ Gibt die Portnummer (Portnr) an, an dem der Server empfangsbereit ist, um mit den Clients zu kommunizieren.
-V
++ Gibt den Ausführlichkeitgrad des Server an. ++ Sie können diesen Parameter bis zu dreimal angeben (maximale Ausführlichkeit).
-a
++ 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.
++ Sie können die Modi 1 und 2 nur verwenden, wenn die Serverlademodule über eine APF-autorisierte Bibliothek ausgeführt werden.
-n
++ 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.
-q
++ 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.
-t
++ Startet die Traceerstellung dieses Server-Jobs und schreibt Ausgaben in STDOUT. ++ Dieser Parameter wird normalerweise nur für das Debugging verwendet.

Prozedur

++ Führen Sie zum Starten eines z/OS-Build-Servers die folgenden Schritte mit CCURUN.JCL (für z/OS) oder mit CCURUNU.JCL (für USS) aus:
  1. ++ Fügen Sie eine Jobkarte hinzu.
  2. ++ Ändern Sie bei Bedarf die Parameter in der Anweisung PARM der EXEC-Karte. (Informationen hierzu finden Sie in der obigen Parameterliste.)
  3. ++ Ä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.
  4. ++ Ä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.
  5. ++ Geben Sie CCUBLOG als sequenzielle Datei an. ++ In diese Datei wird das Protokoll des Build-Servers geschrieben.
  6. ++ Ändern Sie bei Bedarf die Parameteranweisung (PARM=) für Ihren Job (siehe folgendes Beispiel).
  7. Übergeben Sie den Job.

Beispiel

++ Im Folgenden finden Sie ein Beispiel für JCL, das den Build-Server als Batchprogramm für z/OS-Builds startet:
//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.

Anmerkung: ++ In diesem Fall kann das Build-Script auch Programme ohne APF-Autorisierung festlegen. ++ In einem JCL-Script mit mehreren Schritten kann ein autorisiertes Programm jedoch nicht nach einem Programm ohne Autorisierung ausgeführt werden.

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

++ Darüber hinaus kann es auch vorkommen, dass die Komponenten, die den Build-Server aufrufen, Nachrichten ausgeben müssen, wenn die Kommunikation mit dem Build-Server fehlschlägt. ++ Wenn Sie diese Nachrichten in einer anderen Sprache als Englisch zurückgeben möchten, ändern Sie die Einstellung für die Umgebungsvariable CCU_CATALOG auf der Clientmaschine. ++ Der Wert für CCU_CATALOG ist eine Zeichenfolge wie die folgende (in einer einzigen Zeile):
  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.

++ Um für das USS-Shell-Script "ccubldw.sh" eine bestimmte Sprache festzulegen, müssen Sie eine Anweisung wie die folgende hinzufügen (in einer einzigen Zeile):
  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).


Feedback