Vor Verwendung dieser Informationen sollten Sie die allgemeinen Hinweise unter Bemerkungen lesen.
Diese Ausgabe bezieht sich auf IBM Rational Developer for System z Version 8.0.1 (Programmnummer 5724-T07) und - sofern in neuen Ausgaben nicht anders angegeben - auf alle nachfolgenden Releases und Modifikationen.
Diese Veröffentlichung ist eine Übersetzung des Handbuchs
IBM Rational Developer for System z Version 8.0.1,
Administrator's Guide for SCLM Developer Toolkit,
IBM Form SC23-9801-02,
herausgegeben von International Business Machines Corporation, USA
© Copyright International Business Machines Corporation 2010
© Copyright IBM Deutschland GmbH 2010
Informationen, die nur für bestimmte Länder Gültigkeit haben und für Deutschland, Österreich und die Schweiz nicht zutreffen, wurden in dieser Veröffentlichung im Originaltext übernommen.
Möglicherweise sind nicht alle in dieser Übersetzung aufgeführten Produkte in Deutschland angekündigt und verfügbar; vor Entscheidungen empfiehlt sich der Kontakt mit der zuständigen IBM Geschäftsstelle.
Änderung des Textes bleibt vorbehalten.
In diesem Dokument wird die Konfiguration von IBM® Software Configuration and Library Manager (SCLM) beschrieben, die für die SCLM Developer Toolkit-Funktion von IBM Rational Developer for System z benötigt wird.
Im weiteren Verlauf dieses Handbuchs werden die folgenden Namen verwendet:
Die in diesem Dokument enthaltenen Informationen beziehen sich auf alle Rational Developer for System z Version 8.0.1-Pakete, einschließlich IBM Rational Developer for zEnterprise.
Dieses Dokument enthält Informationen für Administratoren von SCLM-Projekten, die mit dem SCLM Developer Toolkit verwendet werden. Dies umfasst Projekte, für die Java- und z/OS UNIX System Services-Komponentensprachen verwendet werden, sowie konventionelle SCLM-Projekte.
Die Administratoren dieser Projekte sollten mit z/OS UNIX System Services, REXX-Scripts, dem Java-Compiler sowie mit SCLM-Projekt- und Sprachdefinitionen vertraut sein.
Diese Veröffentlichung bezieht sich nicht auf die Implementierung und das Laden des Produktes "SCLM", das im Lieferumfang des z/OS-Betriebssystems enthalten ist. Ebensowenig wird die Installation und Konfiguration des SCLM Developer Toolkits berücksichtigt, das eine Funktion von Rational Developer for System z ist.
Weitere Informationen zu diesen Aufgaben finden Sie im ISPF Software Configuration and Library Manager Project Manager's and Developer's Guide (IBM Form SC34-4817) sowie im Handbuch Rational Developer for System z Hostkonfiguration (IBM Form SC12-4062).
Um die Aufgaben zur Anpassung und Projektdefinition ausführen zu können, muss der SCLM-Administrator bestimmte für Developer for System z anpassbare Werte kennen, wie in Tabelle 1 beschrieben. Wenden Sie sich an den z/OS-Systemprogrammierer, der für die Installation und Anpassung von Developer for System z verantwortlich ist, wenn Sie weitere Informationen benötigen.
Beschreibung | Standardwert | Entsprechende Quelle | Wert |
---|---|---|---|
Musterbibliothek für Developer for System z | FEK.SFEKSAMP | SMP/E-Installation | |
Musterverzeichnis für Developer for System z | /usr/lpp/rdz/samples | SMP/E-Installation | |
Java-Bin-Verzeichnis | /usr/lpp/java/J5.0/bin | rsed.envvars - $JAVA_HOME/bin | |
Ant-Bin-Verzeichnis | /usr/lpp/Ant/apache-ant-1.7.1/bin | rsed.envvars - $ANT_HOME/bin | |
WORKAREA-Ausgangsverzeichnis | /var/rdz | rsed.envvars - $_CMDSERV_CONF_HOME | |
Ausgangsverzeichnis für SCLMDT-Projektkonfigurationen | /etc/rdz/sclmdt | rsed.envvars | |
VSAM für Umsetzung langer/kurzer Namen | FEK.#CUST.LSTRANS.FILE | rsed.envvars - $_SCLMDT_TRANTABLE |
In diesem Kapitel wird erläutert, wie der SCLM-Administrator SCLM für die Verwendung mit dem SCLM Developer Toolkit anpassen kann.
Im Folgenden finden Sie eine Zusammenfassung des Prozesses, der für Java- und J2EE-Builds mit den mitgelieferten Umsetzern ausgeführt wird.
Die ARCHDEF enthält die Member, aus denen das JAVA/J2EE-Projekt besteht. Diese verdeutlichen als Kurznamendarstellung, wie das Projekt in einem Eclipse-Arbeitsbereich gespeichert ist.
Die ARCHDEF selbst wird erstellt. Dabei wird ein vorerstellter Sprachüberprüfungsumsetzer (J2EEANT) aufgerufen. Der Umsetzer liest das J2EE-Erstellungs- script, das in der ARCHDEF durch das Schlüsselwort SINC referenziert wird, und überschreibt die angegebenen Eigenschaften in der Entwurfs-Ant-XML, die durch die Eigenschaften SCLM-ANTXML(A) referenziert wird. Das Erstellungsscript wird, wenn es durch SCLM Developer Toolkit erstellt wird, in SCLM mit einer Sprache des Typs J2EEANT gespeichert (1).
Eine ARCHDEF generiert Java-Klassen für Java-Quellcode, der mit dem Schlüsselwort INCLD in der ARCHDEF angegeben wird (2). Jede ARCHDEF kann auch eine J2EE-Archivierungsdatei generieren, wie z. B. eine JAR-, WAR- oder EAR-Datei. Das erstellte J2EE-Objekt ist abhängig von dem entsprechenden referenzierten Erstellungsscript und der Verwendung des ARCHDEF-Schlüsselworts OUT1 (3), (B).
Wenn die ARCHDEF erstellt wird, wird der vorerstellte Sprachüberprüfungsum- setzer ausgeführt, der mit dem Erstellungsscript verknüpft ist (im SCLM-Typ J2EEBLD). Dieser ermittelt, welche Teile der ARCHDEF neu erstellt werden müssen (einschließlich verschachtelter ARCHDEFs (4), die durch die Verwendung des Schlüsselworts INCL in der ARCHDEF identifiziert werden). Diese Teile werden dann in den Dateisystem-Arbeitsbereich von z/OS UNIX System Services kopiert. Ant kompiliert und generiert die erforderlichen JAVA/J2EE-Objekte, die durch das Erstellungsscript und die ARCHDEF angegeben werden. Externe JAR- oder Klassenreferenzen, die in Ihrem IDE-Projekt aufgelöst werden müssen, werden mit dem in der Eigenschaft CLASSPATH_JARS definierten Pfad aufgelöst (C).
SCLM verarbeitet anschließend jede einzelne ARCHDEF-Komponente, indem alle Sprachumsetzer ausgeführt werden, die mit der Komponente verknüpft sind. Der JAVA-Sprachumsetzer, der mit dem Java-Quellcode verknüpft ist, kopiert die erstellten Klassendateien zurück in SCLM.
Schließlich ermittelt der ARCHDEF-Umsetzer, welche J2EE-Objekte erstellt wurden (JAR, WAR, EAR), und kopiert diese Teile zurück in SCLM.
Es ist wichtig, eine separate ARCHDEF für jede Anwendungskomponente zu erstellen, die möglicherweise eine Unternehmensanwendung (EAR) darstellt. Eine EAR-Datei, die eine WAR-Datei enthält, die wiederum eine EJB-JAR-Datei enthält, sollte daher eine ARCHDEF für die JAR-Datei haben, eine ARCHDEF für die WAR-Datei mit einem INCL der EJB-JAR-ARCHDEF. Die EAR-ARCHDEF sollte in diesem Fall ein INCL der WAR-ARCHDEF umfassen.
Das folgende Beispiel zeigt den JAR-Code:
* * Initially generated on 10/05/2006 by SCLM DT V2 * LKED J2EEOBJ * J2EE Build translator * * Source to include in build * INCLD AN000002 V2TEST * com/Angelina.java * INCLD V2000002 V2TEST * com/V2Java1.java (2) * INCLD V2000003 V2TEST * V2InnerClass.java * * * Nested SCLM controlled jars to include * * INCL V2JART1 ARCHDEF * DateService.jar (4) * * * Build script and generated outputs * SINC V2JARB1(1) J2EEBLD * J2EE JAR Build script * OUT1 * J2EEJAR * V2TEST.jar (3) * LIST * J2EELIST
Das folgende Beispiel zeigt das zugehörige JAR-Script:
<ANTXML> <project name="JAVA Project" default="jar" basedir="."> <property name="env" environment="env" value="env"/> <property name="SCLM_ARCHDEF" value="V2JAR1"/> <property name="SCLM_ANTXML" value="BWBJAVAA"/> (A) <property name="SCLM_BLDMAP" value="YES"/> <property name="JAR_FILE_NAME" value="V2TEST.jar"/> (B) <property name="CLASSPATH_JARS" value="/var/SCLMDT/CLASSPATH"/> (C) <property name="ENCODING" value="IBM-1047"/> </ANTXML>
Folgende Objekte werden generiert:
Für das SCLM Developer Toolkit sind neue Sprachumsetzer erforderlich, die in SCLM für JAVA/J2EE-Unterstützung definiert sind. Diese Sprachumsetzer werden in den FEK.SFEKSAMV-Membern bereitgestellt, wie im Folgenden aufgeführt:
Umsetzer | Beschreibung |
---|---|
BWBTRANJ | Muster-Standardmember-Umsetzer. Keine Syntaxanalyse. Ähnelt SCLM FLM@TEXT. Dieser Umsetzer kann angepasst werden, um die Sprachdefinitionen J2EEPART, J2EEBIN, BINARY und TEXT zu erstellen. |
BWBTRANS | Muster-SQLJ-Sprachumsetzer. LANG=SQLJ |
BWBTRAN1 | Muster-JavaSprachumsetzer. LANG=JAVA |
BWBTRAN2 | Muster-JAVA/J2EE-Sprachumsetzer einschließlich Ant (für mehrfache Java-Kompilierungen und JAR-, WAR- und EAR-Builds). |
BWBTRAN3 | Muster-J2EE-Sprachumsetzer für Unterstützung von SCLM ARCHDEF J2EE. LANG=J2EEOBJ |
Der SCLM-Administrator muss diese Muster kopieren, eventuell umbenennen und anschließend in der Bibliothek PROJDEFS.LOAD für jedes SCLM-Projekt erstellen, bei dem Java-Unterstützung benötigt wird. Diese Umsetzer müssen in der Projektdefinition hinzugefügt oder kompiliert werden.
Eine Musterprojektdefinition für JAVA/J2EE-Projekte und Hostkomponenten ist im Muster BWBSCLM angegeben.
Die Musterumsetzer definieren die folgenden Sprachen:
Dieser Überprüfungsumsetzer ermittelt, welche Teile erstellt werden müssen (einschließlich verschachtelter ARCHDEFs), und kopiert diese Teile abhängig von den Erstellungsmodi in das WORKAREA-Verzeichnis von z/OS UNIX System Services. Eine Entwurfs-Ant-XML wird dynamisch angepasst anhand der Erstellungsscripts sowie der Teile, die im Arbeitsbereich erstellt wurden, der Ant verwendet. Die Klassendateien werden an die JAVA/JAVABIN-Sprachumsetzer übermittelt, um diese in SCLM zu speichern. Die erstellten J2EE-Objekte, wie JAR-, WAR- oder EAR-Dateien werden an den ARCHDEF-Sprachumsetzer (J2EEOBJ) übermittelt, um in SCLM gespeichert zu werden.
Der Java-Umsetzer kompiliert die Quellen- in Ausgabeklassen. Die Klasse wird in SCLM im Typ JAVACLAS gespeichert. Die Java-Kompilierungsausgabe wird im Typ JAVALIST gespeichert.
Klassenpfadabhängigkeiten können durch Speichern von abhängigen JARs im Klassenpfadverzeichnis berücksichtigt werden, das im $GLOBAL-Memberparameter CLASSPATH_JARS angegeben ist. Weitere Informationen finden Sie unter $GLOBAL.
Es wird empfohlen, SCLM-Ziel-Quellendateien mit RECFM=VB, LRECL=1024 für alle JAVA/J2EE-Quellen zu erstellen, die vom Toolkit-Client aus in SCLM gespeichert werden sollen, um lange Datensatztypen zu ermöglichen.
Die Editoren auf dem Eclipse-basierten Client erstellen Dateien mit verschiedener Datensatzlänge. Um die Integrität zu wahren, sollten die Host-Zieldatensätze in SCLM ebenfalls dem Typ RECFM=VB entsprechen. Wenn Datensätze mit festgelegter Satzlänge (RECFM=FB) verwendet werden, werden bei importierten Membern Leerzeichen am Ende des Datensatzes angehängt.
Für die Unterstützung von JAVA/J2EE müssen verschiedene SCLM-Typen erstellt werden. Einige dieser Typen sind obligatorisch und müssen erstellt werden, damit die JAVA/J2EE-Unterstützung funktionieren kann.
Für die folgenden SCLM-Typen werden Standard-Datensatzattribute des Typs DSORG=PO TRACKS(1,5) DIR=50 BLKSIZE=0 (durch das System festgelegt) empfohlen.
Darüber hinaus werden für Satzformat und Satzlänge folgende Attribute empfohlen:
SCLM-Typ | RECFM | LRECL |
---|---|---|
ARCHDEF | FB | 80 |
J2EEBLD | FB | 256 |
JAVALIST | VB | 255 |
J2EELIST | VB | 255 |
DBRMLIB | VB | 256 |
JAVACLAS | VB | 256 |
J2EEEAR | VB | 256 |
J2EEJAR | VB | 256 |
J2EEWAR | VB | 256 |
SQLJSER | VB | 256 |
Weitere Quell-Dateigruppentypen für Java/J2EE | VB | 1024 |
Die Teile mit ausgeschriebenem Namen in jedem ARCHDEF-Member stellen die JAVA/J2EE-Projektstruktur dar. Die ARCHDEF für ein bestimmtes Projekt kann beim Migrieren in neuen Projekten dynamisch auf dem Client erstellt werden oder aktualisiert werden, wenn einem vorhandenen Projekt neue Teile hinzugefügt werden.
Die SCLM ARCHDEF ist die primäre SCLM-Datei zum Definieren der Elemente eines JAVA/J2EE-Projekts. In Bezug auf JAVA/J2EE-Anwendungen repräsentiert die ARCHDEF, wie die J2EE-Anwendung im Projektarbeitsbereich der Client-IDE strukturiert ist.
Die Projektdateistruktur der Anwendung wird in der ARCHDEF repliziert (unter Verwendung des Kurznamens des SCLM-Hosts, um die Struktur des ausgeschriebenen Namens zuzuordnen). Zusatzschlüsselwörter in der ARCHDEF, wie LINK, SINC und OUT1, geben in SCLM die J2EE-Spezifik dieses Projekts an. Der Quellcode umfasst ein JAVA/J2EE-Erstellungsscript, um den Erstellungsprozess dieses Projekts zu vereinfachen.
DBRMLIB wird für die Unterstützung von SQLJ benötigt und speichert die Datenbankanforderungsmodule.
Für jedes JAVA/J2EE-Projekt, das in SCLM gespeichert wird, wird ein separater SCLM-Typ benötigt. Dadurch werden Konflikte in Dateien mit demselben Namen vermieden, die bei JAVA/J2EE-Projekten auftreten können. Weitere Informationen finden Sie unter J2EE-Projekte SCLM zuordnen.
In diesem Abschnitt werden die SCLM-Memberformate beschrieben.
Das Format $GLOBAL hat den Typ J2EEBLD und die Sprache J2EEPART. Es muss den Namen $GLOBAL verwenden. Die Variablen werden im Tag-Sprachformat definiert.
$GLOBAL gibt die Standardeigenschaften für das SCLM-Projekt für JAVA/J2EE-Erstellungsprozesse an. Dieses muss im SCLM-Typ J2EEBLD gespeichert werden.
Eine detaillierte Beschreibung der $GLOBAL-Memberparameter finden Sie unter $GLOBAL.
Sehen Sie sich das folgende Codemuster an:
<property name="ANT_BIN" value="/usr/lpp/Ant/apache-Ant-1.6.0/bin/Ant"/> <property name="JAVA_BIN" value="/usr/lpp/java/IBM/J1.4/bin"/> <property name="_SCLMDT_CONF_HOME" value="/etc/rdz/sclmdt/CONFIG"/> <property name="_SCLMDT_WORK_HOME" value="/var/rdz/WORKAREA"/> <property name="CLASSPATH_JARS" value="/var/rdz/CLASSPATH"/>
Das Format J2EE-ARCHDEF hat den Typ ARCHDEF und die Sprache ARCHDEF.
Die ARCHDEF verwendet Standard-SCLM-Architektur-Schlüsselwörter, um SCLM anzuweisen, wie die Erstellung der ARCHDEF verarbeitet werden soll.
Das folgende Beispiel zeigt den JAR-Code:
* * Initially generated on 10/05/2006 by SCLM DT V2 * LKED J2EEOBJ * J2EE Build translator * * Source to include in build * INCLD AN000002 V2TEST * com/Angelina.java * INCLD V2000002 V2TEST * com/V2Java1.java * INCLD V2000003 V2TEST * V2InnerClass.java * * * Build script and generated outputs * SINC V2JARB1 J2EEBLD * J2EE JAR Build script * OUT1 * J2EEJAR * V2TEST.jar * LIST * J2EELIST
Das folgende Beispiel zeigt den WAR-Code:
* * Initially generated on 5 Sep 2006 by SCLM DT V2 * LKED J2EEOBJ * J2EE Build translator * * Source to include in build * INCLD DA000026 SAMPLE5 * JavaSource/service/dateController.java * INCLD XX000001 SAMPLE5 * .classpath * INCLD XX000002 SAMPLE5 * .project * INCLD XX000003 SAMPLE5 * .websettings * INCLD XX000004 SAMPLE5 * .website-config * INCLD OP000002 SAMPLE5 * WebContent/operations.html * INCLD MA000001 SAMPLE5 * WebContent/META-INF/MANIFEST.MF * INCLD IB000001 SAMPLE5 * WebContent/WEB-INF/ibm-web-bnd.xmi * INCLD IB000002 SAMPLE5 * WebContent/WEB-INF/ibm-web-ext.xmi * INCLD WE000001 SAMPLE5 * WebContent/WEB-INF/web.xml * INCLD MA000002 SAMPLE5 * WebContent/theme/Master.css * INCLD BL000001 SAMPLE5 * WebContent/theme/blue.css * INCLD BL000002 SAMPLE5 * WebContent/theme/blue.htpl * INCLD LO000013 SAMPLE5 * WebContent/theme/logo_blue.gif * * * Build script and generated outputs * SINC SAMPLE5 J2EEBLD * J2EE WAR Build script * OUT1 * J2EEWAR * Sample5.war * LIST * J2EELIST
Das folgende Beispiel zeigt den EJB-Code:
LKED J2EEOBJ * INCLD XX000001 SAMPLE3 * .classpath * INCLD XX000002 SAMPLE3 * .project * INCLD MA000004 SAMPLE3 * ejbModule/META-INF/MANIFEST.MF * INCLD EJ000004 SAMPLE3 * ejbModule/META-INF/ejb-jar.xml * INCLD IB000003 SAMPLE3 * ejbModule/META-INF/ibm-ejb-jar-bnd.xmi * INCLD XX000008 SAMPLE3 * ejbModule/com/ibm/ejs/container/_EJSWrapper * * _Stub.java * INCLD XX000009 SAMPLE3 * ejbModule/com/ibm/ejs/container/_EJSWrapper * * _Tie.java * INCLD XX000010 SAMPLE3 * ejbModule/com/ibm/websphere/csi/_CSIServant * * _Stub.java * INCLD XX000011 SAMPLE3 * ejbModule/com/ibm/websphere/csi/_Transactio * * nalObject_Stub.java * INCLD DA000005 SAMPLE3 * ejbModule/myEJB/DateBean.java * INCLD DA000006 SAMPLE3 * ejbModule/myEJB/DateBeanBean.java * INCLD DA000007 SAMPLE3 * ejbModule/myEJB/DateBeanHome.java * INCLD EJ000001 SAMPLE3 * ejbModule/myEJB/EJSRemoteStatelessDateBean * * Home_1a4c4c85.java * INCLD EJ000002 SAMPLE3 * ejbModule/myEJB/EJSRemoteStatelessDateBean_ * * _1a4c4c85.java * INCLD EJ000003 SAMPLE3 * ejbModule/myEJB/EJSStatelessDateBeanHomeBea * * nHomeBean_1a4c4c85.java * INCLD XX000012 SAMPLE3 * ejbModule/myEJB/_DateBeanHome_Stub.java * INCLD XX000013 SAMPLE3 * ejbModule/myEJB/_DateBean_Stub.java * INCLD XX000014 SAMPLE3 * ejbModule/myEJB/_EJSRemoteStatelessDateBean * * Home_1a4c4c85_Tie.java * INCLD XX000015 SAMPLE3 * ejbModule/myEJB/_EJSRemoteStatelessDateBean * * _1a4c4c85_Tie.java * INCLD XX000016 SAMPLE3 * ejbModule/org/omg/stub/javax/ejb/_EJBHome_ * * Sub.java * INCLD XX000017 SAMPLE3 * ejbModule/org/omg/stub/javax/ejb/_EJBObject * * _Stub.java * INCLD XX000018 SAMPLE3 * ejbModule/org/omg/stub/javax/ejb/_Handle_St * * ub.java * INCLD XX000019 SAMPLE3 * ejbModule/org/omg/stub/javax/ejb/_HomeHandl * * e_Stub.java * INCLD DA000008 SAMPLE3 * ejbModule/services/DateBeanServices.java * INCLD XX000020 SAMPLE3 * ejbModule/services/_DateBeanServices_Stub. * * java * SINC SAMPLE3 J2EEBLD * J2EE EJB JAR Build script * OUT1 * J2EEJAR * DateService.jar * LIST * J2EELIST
Das folgende Beispiel zeigt den EAR-Code:
LKED J2EEOBJ * INCLD XX000001 SAMPLE6 * .classpath * INCLD XX000002 SAMPLE6 * .project * INCLD AP000001 SAMPLE6 * META-INF/application.xml * INCL SAMPLE3 ARCHDEF * DateService.jar * INCL SAMPLE5 ARCHDEF * Sample5.war * * SINC SAMPLE6 J2EEBLD * J2EE EAR Build script * OUT1 * J2EEEAR * Sample6.ear * LIST * J2EELIST
Das Format des J2EE-Ant-Erstellungsscripts hat den Typ J2EEBLD und die Sprache J2EEANT. Der Name kann bis zu acht Zeichen lang sein und die Variablen werden im Tag-Sprachformat definiert. Die Erstellungsscripts für JAR, WAR und EAR ähneln sich sehr. Die unten angegebene Syntax wird für ein WAR-Erstellungsscript angezeigt. Für JAR- und EAR-Erstellungsscripts sind die Variablen identisch, mit der Ausnahme, dass EAR_NAME und JAR_NAME anstelle von WAR_NAME verwendet werden.
Im folgenden Beispiel wird das Mustererstellungsscript angezeigt:
<ANTXML> <project name="J2EE Project type" default="web-war" basedir="."> <property name="env" environment="env" value="env"/> <property name="SCLM_ARCHDEF" value="ARCHDEF name"/> <property name="SCLM_ANTXML" value="ANTXML name"/> <property name="SCLM_BLDMAP" value="Include Buildmap"/> <property name="JAVA_SOURCE" value="Include Java Source"/> <property name="J2EE_HOME" value="${env.J2EE_HOME}"/> <property name="JAVA_HOME" value="${env.JAVA_HOME}"/> <property name="CLASSPATH_JARS" value="Classpath Directory location"/> <property name="CLASSPATH_JARS_FILES" value="Jar/class filenames"/> <property name="ENCODING" value="Codepage"/> <property name="DEBUG_MODE" value="debug_mode"/> <!-- WAR-Dateiname, der durch diesen Erstellungsprozess erzeugt wird --> <!-- Suffix ".war" einschließen --> <property name="WAR_NAME" value="War name" /> <path id="build.class.path"> <pathelement location="."/> <pathelement location="${J2EE_HOME}/lib/j2ee.jar"/> <pathelement location="${CLASSPATH_JARS}/jdom.jar"/> <fileset dir="." includes="**/*.jar"/> <fileset dir="${CLASSPATH_JARS}" includes="**/*.jar, **/*.zip"/> </path> </ANTXML>
Kundendefinierte Variablen werden bei Erstellungsanforderungen während der Ausführung des Ant-Erstellungsscripts dynamisch durch die SCLM-Erstellungs- scripts überschrieben. Diese Variablen werden auf die unter Tabelle 3 angezeigten Werte gesetzt.
Variable | Beschreibung |
---|---|
J2EE-Projektname | Java/J2EE-Projekttyp, der erstellt wird. Dabei handelt es sich um einen temporären Projektnamen, der im Erstellungsscript für Ant für die Verwendung während der Erstellung festgelegt wird. Für diesen werden folgende Werte festgelegt:
|
SCLM_ARCHDEF | ARCHDEF-Name oder ARCHDEF, die erstellt wird. |
SCLM_ANTXML | Name der Entwurf-Ant-XML, die für die Erstellung verwendet werden soll. |
SCLM_BLDMAP | Wert "Yes" oder "No". Wenn "Yes" festgelegt werden soll, schließen Sie die SCLM-Buildzuordnung im Verzeichnis MANIFEST in JAR, WAR oder EAR ein. Stellt die Prüfung und die Buildzuordnung der eingeschlossenen Teile bereit. |
JAVA_SOURCE | Wert "Yes" oder "No". Wenn "Yes" festgelegt werden soll, schließen Sie die Java-Quelle in JAR, WAR oder EAR ein. |
CLASSPATH_JARS | Klassenpfadverzeichnis von z/OS UNIX System Services, das zur Auflösung der Klassenpfadabhängigkeiten bei der Erstellung verwendet wird. Alle JAR-Dateien in diesem Verzeichnis werden im Klassenpfad verwendet. |
CLASSPATH_JARS_FILES | Namen der einzelnen JAR- und Klassendateien, die bei der Erstellung eingeschlossen werden sollen. Diese können in Form einer Liste nach folgendem Beispiel angegeben werden: <property name="CLASSPATH_JARS_FILES" value="V2J4.jar,V2J3.jar" /> |
ENCODING | ASCII- oder EBCDIC-Codepage für JAVA. Dabei handelt es sich um die Codepage, in der der JAVA-Quellcode auf dem z/OS-Host gespeichert wird. Beispiel:
|
JAR_FILE_NAME EJB_NAME WAR_NAME EAR_NAME |
Name der JAR-, EJB-JAR-, WAR- oder EAR-Datei. |
DEBUG_MODE | Auf "on" gesetzt, um Developer Toolkit anzuweisen, keine Erstellungsdateien aus dem Verzeichnis WORKAREA zu löschen. Dies ist sinnvoll, wenn Sie die Struktur einer erstellten Java/J2EE-Anwendung prüfen müssen. |
Java-Quellcode innerhalb einer ARCHDEF kann Klassenpfadabhängigkeiten mit anderen Java-Bibliotheken oder -klassen haben. Wenn diese Abhängigkeiten sich in Java-Komponenten befinden, die in derselben ARCHDEF-Struktur enthalten sind, werden diese Klassenpfadabhängigkeiten im Rahmen der ARCHDEF-Erstellung aufgelöst (unabhängig davon, ob der Erstellungsmodus bedingt oder erzwungen ist).
Eine J2EE-ARCHDEF-Komponente kann jedoch Klassenpfadabhängigkeiten mit externen JARs oder sogar Membern aus anderen ARCHDEFs haben. In diesem Fall kann das mit der ARCHDEF verknüpfte J2EE-Erstellungsscript die Klassenpfadabhängigkeiten mit folgenden Schlüsselwörtern steuern:
Dieses Verzeichnis kann mit CLASSPATH-Dateien über die Client-Team-Funktion "JAR-Dateien hochladen" aktualisiert werden, um JAR-Dateien vom Client in das Klassenpfadverzeichnis zu kopieren. Darüber hinaus steht die Funktion "Datei von SCLM in Klassenpfad kopieren" zur Verfügung, um in SCLM gespeicherte JAR-Dateien in das Klassenpfadverzeichnis zu kopieren.
Das folgende Beispiel zeigt das JAR-Script:
<ANTXML> <project name="JAVA Project" default="jar" basedir="."> <property name="env" environment="env" value="env"/> <property name="SCLM_ARCHDEF" value="V2JAR1"/> <property name="SCLM_ANTXML" value="BWBJAVAA"/> <property name="SCLM_BLDMAP" value="YES"/> <property name="JAR_FILE_NAME" value="V2TEST.jar"/> <property name="CLASSPATH_JARS" value="/var/rdz/CLASSPATH"/> <property name="ENCODING" value="IBM-1047"/> </ANTXML>
Das folgende Beispiel zeigt das WAR-Script:
<ANTXML> <project name="J2EE WAR Project" default="web-war" basedir="."> <property name="env" environment="env" value="env"/> <property name="SCLM_ARCHDEF" value="SAMPLE5"/> <property name="SCLM_ANTXML" value="BWBWEBA"/> <property name="SCLM_BLDMAP" value="YES"/> <property name="JAVA SOURCE" value="YES"/> <property name="J2EE_HOME" value="${env.J2EE_HOME}"/> <property name="JAVA_HOME" value="${env.JAVA_HOME}"/> <property name="CLASSPATH_JARS" value="/var/rdz/CLASSPATH"/> <property name="ENCODING" value="IBM-1047"/> <!-- WAR-Dateiname, der durch diesen Erstellungsprozess erzeugt wird --> <property name="WAR_NAME" value="Sample5.war" /> <path id="build.class.path"> <pathelement location="."/> <pathelement location="${J2EE_HOME}/lib/j2ee.jar"/> <pathelement location="${CLASSPATH_JARS}/jdom.jar"/> <fileset dir="${CLASSPATH_JARS}" includes="**/*.jar, **/*.zip"/> </path> </ANTXML>
Das folgende Beispiel zeigt das EJB-Script:
<ANTXML> <project name="J2EE EJB Project" default="EJBBuild" basedir="."> <property name="env" environment="env" value="env"/> <property name="SCLM_ARCHDEF" value="SAMPLE3"/> <property name="SCLM_ANTXML" value="BWBEJBA"/> <property name="SCLM_BLDMAP" value="NO"/> <property name="J2EE_HOME" value="${env.J2EE_HOME}"/> <property name="JAVA_HOME" value="${env.JAVA_HOME}"/> <property name="CLASSPATH_JARS" value="/var/rdz/CLASSPATH"/> <property name="ENCODING" value="IBM-1047"/> <property name="EJB_NAME" value="DateService.jar"/> <path id="build.class.path"> <pathelement location="."/> <pathelement location="${J2EE_HOME}/lib/j2ee.jar"/> <pathelement location="${CLASSPATH_JARS}/jdom.jar"/> <fileset dir="${CLASSPATH_JARS}" includes="**/*.jar, **/*.zip"/> </path> </ANTXML>
Das folgende Beispiel zeigt das EAR-Script:
<ANTXML> <project name="J2EE EAR Project" default="j2ee-ear" basedir="."> <property name="env" environment="env" value="env"/> <property name="SCLM_ARCHDEF" value="SAMPLE6"/> <property name="EAR_NAME" value="Sample6.ear"/> <property name="SCLM_ANTXML" value="BWBEARA"/> <property name="SCLM_BLDMAP" value="NO"/> <property name="J2EE_HOME" value="${env.J2EE_HOME}"/> <property name="JAVA_HOME" value="${env.JAVA_HOME}"/> <property name="CLASSPATH_JARS" value="/var/rdz/CLASSPATH"/> <path id="build.class.path"> <pathelement location="."/> <pathelement location="${J2EE_HOME}/lib/j2ee.jar"/> <pathelement location="${CLASSPATH_JARS}/jdom.jar"/> <fileset dir="${CLASSPATH_JARS}" includes="**/*.jar, **/*.zip"/> </path> <target name="common"> <echo message="BuildName: ${Ant.project.name}" /> <echo message="BuildHome: ${basedir}" /> <echo message="BuildFile: ${Ant.file}" /> <echo message="BuildJVM: ${Ant.java.version}" /> </target> </ANTXML>
In diesem Abschnitt werden Muster-Ant-Erstellungsentwürfe aufgelistet, die in der Bibliothek FEK.SFEKSAMV bereitgestellt werden. Diese Mustermember können in den SCLM-Typ J2EEBLD in der SCLM-Hierarchie kopiert werden, um durch die JAVA/J2EE-Erstellungsscripts referenziert und verwendet zu werden. Die JAVA/J2EE-Erstellungsscripts sind Eigenschaftsvariablendateien, die die Ant-XML-Entwurfsdateien überschreiben.
Die angegebenen Muster-J2EE-Erstellungsentwürfe für die Erstellung einer einfachen JAR-Datei, eines SQLJ-Projekts, einer EJB-JAR-, WAR- oder EAR-Datei oder für die Implementierung können im Allgemeinen ohne Anpassung durch den Benutzer verwendet werden. Beachten Sie jedoch, dass manche J2EE-Projekte möglicherweise nicht dem Standardmodell entsprechen. In diesem Fall müssen die bereitgestellten Ant-XML-Entwürfe angepasst werden.
Eine detaillierte Beschreibung der Erstellungsscripts, Ant-Entwürfe und Beispiele zum JAVA/J2EE-Erstellungsprozess ist im Benutzerhandbuch für SCLM Developer Toolkit enthalten, das mit dem Client-Plug-in geliefert wird.
Muster-Ant-XML-JAVA-Erstellungsentwurf
Dieser Ant-Entwurf wird von einem Java-Erstellungsscript verwendet, um mehrere Java-Programme zu kompilieren und optional eine Java-Archivdatei (JAR) zu erstellen, deren Struktur durch eine angegebene ARCHDEF bestimmt wird.
Muster-Ant-XML-J2EE-EJB-Erstellungsentwurf
Dieser Ant-Entwurf wird von einem J2EE-Erstellungsscript verwendet, um ein EJB-Projekt zu kompilieren oder zu erstellen. Dabei wird üblicherweise eine EJB-JAR-Datei erstellt, deren Struktur von einer angegebenen ARCHDEF bestimmt wird.
Muster-Ant-XML-J2EE-WEB-Erstellungsentwurf
Dieser Ant-Entwurf wird von einem J2EE-Erstellungsscript verwendet, um ein WEB-Projekt zu kompilieren oder zu erstellen, wobei üblicherweise eine WEB-Archivdatei (WAR) erstellt wird.
Muster-Ant-XML-J2EE-EAR-Assemblierungsentwurf
Dieser Ant-Entwurf wird von einem J2EE-Erstellungsscript als Assemblierungsprozess in Vorbereitung für die J2EE-Anwendungsimplementierung verwendet. Bei diesem Prozess werden EAR-Dateien erstellt, die auf einem Webanwendungsserver implementiert werden können, z. B. auf einem WebSphere-Anwendungsserver.
Muster für Java-/SQLJ-Erstellungsscript Dieser Ant-Entwurf wird von einem J2EE-Erstellungsscript zur Kompilierung oder Erstellung eines JAR-Projekts verwendet, das SQLJ verwendet.
Muster für EJB-/SQLJ-Erstellungsscript Dieser Ant-Entwurf wird von einem J2EE-Erstellungsscript zur Kompilierung oder Erstellung eines EJB-Projekts verwendet, das SQLJ verwendet.
Muster für die Konvertierung von Cloud 9 in SCLM DT
Muster zum Aktualisieren von SQLJ-SER-Dateien innerhalb einer JAR-Datei bei der Implementierung mit db2sqljcustomize
Muster für db2sqljcustomize, wobei der ausgeschriebene Eigenschaftsname die angegebene JAR-Datei aus der entsprechenden Gruppen- und Typ-Speicherposition in SCLM in das durch "dest" angegebene Zielverzeichnis speichert
Diese Musterroutine passt die in den ausgewählten JAR-Dateien enthaltenen SER-Dateien für die Implementierung mit db2sqljcustomize an.
Muster-SCLM-Erstellungsumsetzer für die Benachrichtigung bei SYSXML-Erstellungsfehlern für COBOL.
IBM SCLM Developer Toolkit bietet die Möglichkeit, Projekte in SCLM zu verwalten, zu erstellen und zu implementieren. In diesem Abschnitt wird beschrieben, wie die SCLM-Projektstruktur konfiguriert werden muss, um die Entwicklung verteilter Anwendungen wie JAVA/J2EE zu unterstützen.
Bei vielen JAVA/J2EE-Projekten wird eine ausführbare EAR-Datei erstellt. Diese Anwendung ist eine Gruppe von Projekten, üblicherweise EJBs und Webanwendungen. Innerhalb der IDE-Umgebungen werden diese im Allgemeinen als einzelne Projektstrukturen entwickelt, die mit einem EAR-Projekt verbunden sind. Diese Strukturform mit mehreren Projekten wird nicht direkt in SCLM abgebildet. Das bedeutet, dass ein SCLM-Projekt nicht mit einem anderen SCLM-Projekt verknüpft werden kann, um eine zusammengefasste Projektstruktur zu erhalten. SCLM bietet jedoch durch die Verwendung von Typen die Möglichkeit, eine Struktur mit mehreren Projekten innerhalb eines SCLM-Projekts zu erstellen.
SCLM-Projekte können mit mehreren Quellentypen definiert werden. Jeder Typ kann ein einzelnes IDE-Projekt enthalten. Wenn man mehrere Eclipse-IDE-Projekte in SCLM ohne eine Art der Trennung speichern würde, würden die Klassenpfad- und Projektdateien des Projekts bei der Hinzufügung der Projekte in SCLM überschrieben werden. Die Verwendung verschiedener Quellentypen ermöglicht die sichere Speicherung dieser und aller anderen mit dem Projekt verknüpften Dateien in SCLM.
Diese Zuordnung bewirkt, dass die IDE-Projekte in SCLM unabhängig gespeichert werden, wobei der Typ als wichtigstes Differenzierungsmerkmal dient. EJB1 wird z. B. im SCLM-Projekt SCLMPRJ1 unter Typ EJB1 gespeichert. Durch die Verwendung dieser Struktur ist es möglich, die IDE-Projektstruktur als unabhängige Typen innerhalb des SCLM-Projekts abzubilden.
Es ist daher wichtig, in der SCLM-Projektstruktur zu berücksichtigen, dass verschiedene IDE-basierte Projekte in einer einzelnen SCLM-Projektstruktur zugeordnet werden. Bei großen SCLM-Projekten kann es problematisch sein, zusätzliche Projekttypen hinzuzufügen, da hierbei eine Änderung der SCLM-Projektdefinition, eine Neuerstellung der SCLM-Projektdefinition und die Dateizuordnung für die neuen Typen erforderlich ist.
Diese Struktur ist nicht auf Projekte im J2EE-Stil beschränkt, sondern kann auch in Situationen angewendet werden, in denen mehrere Projekte entwickelt werden, die eine Form der Abhängigkeit voneinander beinhalten.
Die folgende Liste enthält Empfehlungen für die Zuordnung von J2EE-Projekten (und anderen) in SCLM:
Die Verwendung mehrerer SCLM-Typen zur Speicherung einzelner IDE-Projekte ist auch bei die Verarbeitung der ARCHDEF-Struktur für die Erstellung dieser IDE-Projekte zu berücksichtigen.
Die ARCHDEF-Datei enthält die Liste der Dateien, die zu einem Build gehören. In einem J2EE-Kontext kann bei einer Erstellung eine EAR-Datei erstellt werden, die aus mehreren WAR- und JAR-Dateien besteht. Diese Isolation von Projekten ähnelt der Typstruktur, die das Projekt in SCLM definiert. Durch die Verwendung einer übergeordneten ARCHDEF, die sich auf die zum Build gehörenden Teile bezieht, wird eine strukturierte Erstellungsumgebung bereitgestellt. Dies betrifft die effektive Definition der Projektstruktur beim Definieren der Typen in SCLM.
Eine strukturierte Definition des Projekts bietet folgende Vorteile:
Beim Erstellen von Anwendungen mit Verweisen oder Abhängigkeiten auf andere Buildobjekte, z. B. JAR-Dateien, andere Projekte oder andere Klassen, können folgende Vorgehensweisen verwendet werden:
SCLM Developer Toolkit bietet mehrere Implementierungsfunktionen. Sie können Unternehmensarchivdateien (Enterprise Archive, EAR) auf jedem WebSphere Application Server (WAS) implementieren. Zusätzlich kann jede mit dem SCLM Developer Toolkit erstellte oder gesteuerte Komponente mit einem anpassbaren Implementierungsscript verteilt werden. Es werden Musterscripts bereitgestellt, mit denen eine EAR-Datei unter Verwendung der Befehle für sicheres Kopieren (SCP) und sicheres FTP (SFTP) auf einen fernen Host kopiert werden kann.
Im Zentrum der Implementierung stehen im wesentlichen zwei Scripts. Das erste Script, das durch den Benutzer geändert wird, ist das Eigenschaftenscript. Es enthält eine Liste der Parameter für den Implementierungsvorgang. Das zweite ist das Aktionsscript, das die erforderlichen Schritte für die Ausführung des Implementierungsvorgangs enthält.
Die Implementierung wird vom Client-Plugin von SCLM Developer Toolkit aus gestartet. Der Implementierungstyp wird durch Auswahl der entsprechenden Schaltfläche auf dem Implementierungsbildschirm ausgewählt. Abhängig von der ausgewählten Implementierungsaktion werden entsprechende Daten im Eigenschaftenscript ausgefüllt. In den meisten Scripts ist eine Eigenschaft mit dem Namen SCLM_ANTXML vorhanden, die den Membernamen des entsprechenen Aktionsscripts enthält. Developer Toolkit verwendet das generierte Eigenschaftenscript und überträgt es auf das Aktionsscript, bevor das resultierende Aktionsscript aufgerufen wird.
Im Folgenden wird eine Liste der Muster-Ant-Implementierungsaktionsscripts angezeigt, die in der Bibliothek FEK.SFEKSAMV bereitgestellt werden. Diese Mustermember können in den SCLM-Typ J2EEBLD in der SCLM-Hierarchie kopiert werden, um von den generierten Eigenschaftensscripts referenziert und verwendet zu werden. Die generierten Eigenschaftenscripts sind Eigenschaftenvariablendateien, mit denen die unten dargestellten Ant-XML-Implementierungsaktionsscripts überschrieben werden. Diese Scripts müssen mit einer Texttypsprache, z. B. TEXT oder J2EEPART, gespeichert werden.
Member | Beschreibung |
---|---|
BWBDEPLA | WAS-EAR-Implementierung. |
BWBRDEPL | Ferne WAS-EAR-Implementierung. |
BWBSCOPY | Secure-Copy-Implementierung. Kopiert ein Erstellungsobjekt über SCP von einem Host auf einen anderen. |
BWBSFTP | Sichere FTP-Implementierung. Kopiert ein Buildobjekt von einem Host auf einen anderen über SFTP. |
Um diese Erstellungsscripts von mehreren Gruppen aus aufrufen zu können, muss der Administrator die Scripts erstellen und auf die höchste im Projekt verfügbare Gruppenebene hochstufen.
Abhängig von den generierten Scripttypen unterscheidet sich die Vorgehensweise geringfügig.
Bei der Implementierung von WebSphere Application Server (WAS) verweist die Eigenschaft SCLM_ANTXML nicht auf ein Ant-Aktionsscript, sondern stattdessen auf ein JACL-Aktionsscript. Alternativ können Sie das Tool "wsadmin" verwenden, das im Lieferumfang von WAS unter z/OS enthalten ist.
Für das Tool "wsadmin" wird ein JACL-Script als Leitfaden für den Implementierungsprozess benötigt. Wenn diese Implementierungmethode verwendet wird, muss das JACL-Script als ASCII-Datei in einem z/OS UNIX-Verzeichnis erstellt werden, bevor der Implementierungsprozess aufgerufen werden kann.
Bei der Anpassung von Developer for System z wird ein Muster-(ASCII-)JACL-Script unter /etc/rdz/sclmdt/CONFIG/scripts/deploy.jacl bereitgestellt (wobei /etc/SCLMDT das Standard-etc-Verzeichnis für SCLM Developer Toolkit ist).
Zusätzliche JACL-Beispiele sind in der Dokumentation von WebSphere Application Server (WAS) enthalten.
Die Verzeichnispositionen des Tools "wsadmin" (wsadmin.sh) und des JACL-Scripts (deploy.jacl) können auf der Benutzervorgabenseite unter Team > SCLM-Vorgaben > Build-Script-Optionen konfiguriert werden. Der SCLMDT-Client wird verwendet, um ein Implementierungsscript zu generieren, das anschließend für die Erstellung verwendet werden kann. (Der Implementierungsprozess wird durch eine Implementierungsfunktionsanforderung für das Implementierungsscript ausgelöst, das im SCLM-Typ J2EEBLD gespeichert ist).
Die Muster-Aktionsscripts, die im SCLM-Typ J2EEBLD für die WAS-Implementierung oder ferne WAS-Implementierung gespeichert werden müssen, sind BWBDEPLA und BWBRDEPL.
SCLM Developer Toolkit bietet eine Möglichkeit zur Implementierung von Dateien, die im SCLM-Repository für das Dateisystem von z/OS UNIX System Services auf derselben logischen Partition gespeichert sind. Dadurch steht eine einfache Methode zur Verfügung, um Objekte, die von SCLM erstellt wurden, in einer Umgebung zu implementieren, in der diese ausgeführt oder über die sichere Implementierung auch auf einem fernen Host implementiert werden können. Diese Vorgehensweise wird unten beschrieben.
Es ist kein Muster-Aktionsscript für diese Aktion vorhanden. Wählen Sie die entsprechenden Member aus SCLM aus und verwenden Sie die Schaltfläche "SCLM-Member einschließen", um das benötigte Eigenschaftenscript zu generieren. Dadurch werden die Dateien von der ausgewählten SCLM-Speicherposition in ein angegebenes Verzeichnis im Dateisystem von z/OS UNIX System Services kopiert. Dieses Verzeichnis muss bereits vorher vorhanden sein. Andernfalls wird ein Fehler angezeigt.
Diese Option bietet eine Möglichkeit, implementierbare Objekte auf einen fernen Host zu kopieren, indem die Befehle für sicheres Kopieren (SCP) und sicheres FTP (SFTP) verwendet werden. Indem die Eigenschaftenscripts für sichere Implementierung gemeinsam mit den Include-SCLM-Membern verwendet werden, können die benötigten Dateien aus der SCLM-Hierarchie ausgewählt werden, an eine Speicherposition im Dateisystem von z/OS UNIX System Services kopiert werden und anschließend unter Verwendung der Befehle für sicheres Kopieren (SCP) und sicheres FTP (SFTP) von diesem z/OS UNIX System Services-Dateisystem aus auf das Zielsystem kopiert werden.
Die Muster-Aktionsscripts, die für die sichere Implementierung im SCLM-Typ J2EEBLD gespeichert werden müssen, sind BWBSCOPY und BWBSFTP.
IBM Ported Tools for z/OS stellt folgende Funktionen bereit:
Die Public-Key-Authentifizierung stellt eine Alternative zur interaktiven Anmeldung dar und kann im Rahmen des sicheren Implementierungsvorgangs von Developer Toolkit automatisiert werden.
Damit die Public-Key-Authentifizierung wie gewünscht arbeiten kann, können Sie entweder eine Ersatzbenutzer-ID für die Implementierung verwenden oder alle Benutzer konfigurieren, für die Sie Implementierungsfunktionen bereitstellen möchten.
Anweisungen zum Einrichten der automatisierten schlüsselbasierten Authentifizierung mit ssh-agent und ssh-add finden Sie im Benutzerhandbuch für IBM Ported Tools für z/OS. Informationen zur Verwendung der Ersatzbenutzer-ID für SCLM Developer Toolkit finden Sie unter SCLM-Sicherheit.
Sie können auch eigene Ant-Scripts erstellen, um die Implementierung auf andere Weise auszuführen. In Ihren Scripts können Sie durch Verwendung des Ant-Tags <exec> jedes Programm aufrufen, das im z/OS UNIX System Services-Dateisystem verfügbar ist. Wenn Sie diese Methode verwenden, können die Erstellungsscripts andere Programme, z. B. FTP aufrufen, um die Implementierung auszuführen. Weitere Informationen zur Erstellung von Ant-Scripts finden Sie in der Onlinedokumentation für Ant unter http://ant.apache.org/.
Aus dem SCLM Developer Toolkit-Plugin übertragene Quellendateien können in SCLM entweder als ASCII oder EBCDIC gespeichert werden.
Generell werden alle Quellen in SCLM in EBCDIC gespeichert, um direkt in ISPF/SCLM unterz/OS angezeigt und bearbeitet werden zu können. Wenn Sie den Code nicht direkt auf dem Host anzeigen oder bearbeiten möchten, können Sie den Code direkt (d. h. als übertragene Binärdatei) an der Position speichern, wo die Quelle in SCLM gespeichert wird. Dabei wird die ASCII/UNICODE-Codepage des ursprünglichen Clients verwendet. Da keine Umsetzung von ASCII in EBCDIC erforderlich ist, erhalten Sie auf diese Weise ein besseres Leistungsverhalten bei der Speicherung und beim Import von großen Projekten aus SCLM sowie bei JAVA/J2EE-Erstellungen.
SCLM Developer Toolkit ermittelt, ob eine Datei binär übertragen wurde oder ob eine Umsetzung von ASCII in EBCDIC stattfindet, indem die SCLM-Sprache überprüft wird, die der Datei oder dem Member zugeordnet ist. Anschließend überprüft SCLM Developer Toolkit, ob diese SCLM-Sprache in der Datei TRANSLATE.conf mit einem TRANLANG-Schlüsselwort eingetragen ist.
SCLM-Sprachumsetzer | Beschreibung |
---|---|
JAVA | Java-Quellcode-Member gespeichert als EBCDIC. Erstellt durch Verwendung des Musters BWBTRAN1. |
SQLJ | SQLJ-Member gespeichert als EBCDIC. Erstellt durch Verwendung des Musters BWBTRANS. |
JAVABIN | Java-Quellen-Member gespeichert als ASCII. Erstellt durch Verwendung des Musters BWBTRAN1. |
J2EEPART | J2EE-Dateien, bei denen keine Syntaxanalyse erforderlich ist, gespeichert als EBCDIC. Erstellt durch Verwendung des Musters BWBTRAN1. |
J2EEBIN | J2EE-Dateien, bei denen keine Syntaxanalyse erforderlich ist, gespeichert als Binär- oder ASCII-Dateien. Erstellt durch Verwendung des Musters BWBTRAN1. |
SQLJ | SQLJ-Quellenmember gespeichert als EBCDIC. Erstellt durch Verwendung des Musters BWBTRANS. |
SQLJBIN | SQLJ-Quellenmember, gespeichert als ASCII. Erstellt durch Verwendung des Musters BWBTRANS. |
TEXT | Standard-TEXT-Umsetzer, wenn keine Syntaxanalyse erforderlich ist, gespeichert als EBCDIC. Erstellt durch Verwendung des Musters BWBTRAN1. |
BINARY | Standard-Binärsprachumsetzer, wenn keine Syntaxanalyse erforderlich ist. Erstellt durch Verwendung des Musters BWBTRAN1. |
Als Standardverwendung wird ASCII/EBCDIC-Konvertierung vorausgesetzt. Dies bedeutet, dass Dateien, die im Eclipse-Plugin angezeigt und bearbeitet werden, auch direkt auf dem Host in ISPF/SCLM angezeigt und bearbeitet werden können.
Die Verwendung von ASCII (binär übertragen) empfiehlt sich bei der Projektmigration sowie zur Leistungsverbesserung beim Importieren und Erstellen, da diese Dateien keine Umsetzung erfordern. Dies gilt nur, wenn keine Bearbeitung in ISPF/SCLM erforderlich ist.
Abhängig vom verwendeten SCLM-Sprachumsetzer kann die Quelle entweder in ASCII oder EBCDIC erstellt werden.
Um die Nutzbarkeit auf verschiedenen Plattformen zu gewährleisten, werden alle implementierbaren Dateien erstellt, wie JAR-, WAR- und EAR-Dateien. Dadurch entsprechen alle enthaltenen Objekte dem Typ ASCII, unabhängig davon, ob ein Teil des Quellcodes als EBCDIC gespeichert ist.
Hinweis zur JAVA/J2EE-Erstellung: Wenn der Java-Quellcode in ASCII gespeichert wird, muss das Erstellungsscript die ASCII-Codepage mit der Eigenschaftsvariablen ENCODING angeben, damit der Java-Quellcode ordnungsgemäß kompiliert werden kann.
Beispiel:
<property name="ENCODING" value="ISO8859-1"/>
Das aufgerufene Ant-Script wird den Java-Befehl mit dem Wert ENCODING=ISO8859-1 verwenden, um die ASCII-Quelle zu kompilieren. Die Standard-ENCODING-Codepage ist die EBCDIC-Codepage IBM-1047.
Als Teil des JAVA/J2EE-Erstellungsprozesses werden einige zusätzliche Informationen benötigt, um die Erstellungen erfolgreich ausführen zu können. Wenn die Erstellungen in z/OS UNIX System Services ausgeführt werden, werden Informationen benötigt, z. B. die Speicherposition des Java-Produkts, des Ant-Produkts sowie die Speicherposition der Konfigurationsdateien und des Arbeitsbereichs von SCLM Developer Toolkit.
Darüber hinaus kann es erforderlich sein, verschiedene Versionen von Ant oder Java für verschiedene SCLM-Entwicklungsgruppen zu verwenden. Das Member $GLOBAL kann daher gruppenspezifisch sein. Die Umgebungsvariablen, die in $GLOBAL festgelegt sind, können durch spezifische Erstellungsscript-Variableneinstellungen überschrieben werden.
Ein Mustermember BWBGLOB wird in der Bibliothek FEK.SFEKSAMV bereitgestellt. Dieses Mustermember muss im SCLM-Typ J2EEBLD in der SCLM-Hierarchie als Member $GLOBAL kopiert und mit einer gültigen Nicht-Parsing-Sprache gespeichert werden, z. B. TEXT (wie im Sprachumsetzer FLM@TEXT in der Bibliothek SISPMACS bereitgestellt).
Das Member $GLOBAL stellt dem JAVA/J2EE-Erstellungsprozess derzeit folgende Informationen zur Verfügung:
Variable | Beschreibung |
---|---|
ANT_BIN | Dateisystem-Verzeichnispfad von z/OS UNIX System
Services für die Ant-Laufzeit
Beispiel: <property name="ANT_BIN" value="/usr/lpp/apache-Ant-1.6.0/bin/Ant"/> |
JAVA_BIN | z/OS UNIX System
Services-Dateisystem-Verzeichnispfad für Java-Kompilierung/Laufzeit
Beispiel: <property name="JAVA_BIN" value="/usr/lpp/java/5.0/bin"/> |
_SCLMDT_WORK_HOME | Die Speicherposition des WORKAREA-Verzeichnisses von SCLM Developer Toolkit
Beispiel: <property name="_SCLMDT_WORK_HOME" value="/var/rdz"/> |
_SCLMDT_CONF_HOME | Die Speicherposition des CONFIG-Verzeichnisses von SCLM Developer Toolkit
Beispiel: <property name="_SCLMDT_CONF_HOME" value="/etc/rdz/sclmdt"/> |
CLASSPATH_JARS | Klassenpfadverzeichnis des z/OS UNIX System
Services-Dateisystems, das für JAVA-Kompilierungen verwendet wird. Alle JAR-Dateien, die sich in diesem Verzeichnis befinden, werden im Klassenpfad verwendet.
Beispiel: <property name="CLASSPATH_JARS" value="/var/rdz/CLASSPATH"/> |
TRANTABLE | VSAM-Datei, die die Namensumsetzungen für Lang-/Kurznamen enthält
Beispiel: <property name="TRANTABLE" value="FEK.#CUST.LSTRANS.FILE"/> |
DEBUG_MODE | Setzen Sie diese Einstellung auf "on", wenn Developer Toolkit keine Java/J2EE-Builddateien aus dem z/OS UNIX System
Services-Dateisystem löschen soll.
Dies ist sinnvoll, wenn Sie die Struktur der erstellten Ausgaben im USS-Dateisystem für Fehlerbehebungszwecke anzeigen möchten. |
Wenn diese Variablen für alle Gruppenebenen im SCLM-Projekt festgelegt werden sollen, empfiehlt es sich, ein einziges $GLOBAL-Member auf der höchsten Hierarchieebene zu erstellen. Wenn der JAVA/J2EE-Buildumsetzer ausgeführt wird, sucht dieser die Hierarchie ausgehend von der Gruppenebene, die die Erstellung ausführt, und verwendet das erste $GLOBAL-Member, das er im Typ J2EEBLD findet.
Wenn verschiedene Einstellungen erforderlich sind, z. B. für verschiedene Entwicklungsgruppen, kann in jeder dieser Entwicklungsgruppen ein $GLOBAL-Member erstellt werden.
Die Datei TRANSLATE.conf stellt Schlüsselwörter bereit, um zu ermitteln, wie der Code in SCLM gespeichert ist. Die Konfigurationsdatei enthält Schlüsselwörter, die ermitteln, wie Dateien abhängig von ihrer Sprachdefinition auf den Host übertragen werden. Spezifische Schlüsselwörter bestimmen, ob Dateien mit einem bestimmten Sprachtyp binär sind, übertragen und gespeichert werden oder ob die textbasierte Quelle das ASCII-Format beibehält, statt standardmäßig von ASCII in EBCDIC konvertiert zu werden.
Darüber hinaus steuern die SCLM-Sprachdefinitionen, ob ausgeschriebene Dateinamen in passende gültige kurze Hostnamen konvertiert werden, die in SCLM gespeichert werden. Diese Zuordnung von Lang- zu Kurznamen wird durch die SCLM-VSAM für die Umsetzung von Lang- und Kurznamen gesteuert.
TRANSLATE.conf ist gespeichert in /etc/rdz/sclmdt/CONFIG. Sie können die Datei mit dem TSO-Befehl OEDIT bearbeiten.
Das folgende Beispiel zeigt den Code "TRANSLATE.conf". Dieser muss angepasst werden, um Ihrer Systemumgebung zu entsprechen. Kommentarzeilen beginnen mit einem Stern (*).
*============================================================= * cross system sharing TRANVRLS = NO *============================================================= * codepage CODEPAGE ASCII = ISO8859-1 CODEPAGE EBCDIC = IBM-1047 *============================================================= * ascii/ebcdic translation TRANLANG JAVABIN TRANLANG J2EEBIN TRANLANG J2EEOBJ TRANLANG TEXTBIN TRANLANG BINARY TRANLANG DOC TRANLANG XLS *============================================================= * long/short name translation LONGLANG JAVA LONGLANG SQLJ LONGLANG J2EEPART LONGLANG JAVABIN LONGLANG J2EEBIN LONGLANG J2EEOBJ LONGLANG DOC LONGLANG XLS
Die folgenden Schlüsselwörter gelten innerhalb der Datei TRANSLATE.conf:
Es muss eine Codepage-Anweisung für ASCII und EBCDIC für SCLM Developer Toolkit vorhanden sein, um zu ermitteln, wie übertragene Dateien konvertiert werden sollen.
Es muss eine Codepage-Anweisung für ASCII und EBCDIC für SCLM Developer Toolkit vorhanden sein, um zu ermitteln, wie übertragene Dateien konvertiert werden sollen.
SCLM verwendet VSAM Record Level Sharing (RLS), um die gemeinsame Nutzung des VSAM-Datensatzes zu ermöglichen und die Integrität in einer gemeinsam genutzten Umgebung zu erhalten. Der VSAM-Datensatz muss mit der richtigen STORAGECLASS für die Verwendung von RLS definiert werden. Weitere Informationen zu RLS finden Sie im Dokument DFSMS(TM) Using Data Sets (IBM Form SC26-7410-09).
Beachten Sie, dass es kein Gleichheitszeichen (=) in dieser Anweisung gibt, um das TRANLANG-Schlüsselwort und den Namen des (Dummy-)Sprachumsetzer s zu trennen.
Wenn die SCLM-Sprache nicht im Schlüsselwort LONGLANG angegeben ist, wird vorausgesetzt, dass die Clientdatei bereits im Host-Kurznamenformat vorliegt (höchstens 8 Zeichen). Die Datei wird in dieser Form gespeichert.
Beachten Sie, dass es kein Gleichheitszeichen (=) in dieser Anweisung gibt, um das LONGLANG-Schlüsselwort und den Namen der SCLM-Sprache zu trennen.
Es wurde eine Funktion bereitgestellt, um bestimmte Einstellungen auf SITE-Installationsebene oder auf einer bestimmten SCLM-Projektebene vornehmen zu können. Folgende Optionen können derzeit konfiguriert werden:
Es können alle oder auch keine dieser Optionen festgelegt werden. Wenn diese Optionen nicht festgelegt werden, werden in den Programmen Standardwerte verwendet. Einige dieser Optionen können in der Datei SITE.conf festgelegt werden, andere auf projektspezifischer Ebene in SCLM. Alternativ kann auch auf eine SITE-spezifische Datei verzichtet werden. Die Optionen werden dann nur auf Projektebene in SCLM festgelegt. Jobkarteninformationen können überschrieben werden, indem Sie Ihre eigene angegebene Jobkarte verwenden, die in der IDE eingegeben wird.
Diese Funktion wird aktiviert durch Erstellen der Datei SITE.conf im z/OS UNIX-Verzeichnis /etc/rdz/sclmdt/CONFIG/PROJECT/ (wobei /etc/rdz/sclmdt das Standard-etc-Verzeichnis für SCLM Developer Toolkit ist). Dieses Verzeichnis wird während der Anpassung von Developer for System z erstellt.
Eine Musterdatei SITE.conf wird im Verzeichnis /usr/lpp/rdz/samples/ bereitgestellt. Kopieren Sie dieses Verzeichnis und die Anweisungen Ihren Anforderungen entsprechend. Sie können die Datei mit dem TSO-Befehl OEDIT bearbeiten.
Das folgende Beispiel zeigt die Konfigurationsdatei SITE.conf.
* SCLM Developer Toolkit Site Specific option
*
* SCM Approver processing applies to this project?
BUILDAPPROVER=NONE
PROMOTEAPPROVER=NONE
*
* Change Code entry on check-in is mandatory?
CCODE=N
*
*
* To allow promotion by architecture definition only,
* set the value of PROMOTEONLYFROMARCHDEF to Y
PROMOTEONLYFROMARCHDEF=N
*
* Foreground or On-line builds/promotes allowed for this project?
FOREGROUNDBUILD=Y
FOREGROUNDPROMOTE=Y
*
* Batch Build default jobcard
BATCHBUILD1=//SCLMBILD JOB (#ACCT),'SCLM BUILD',CLASS=A,MSGCLASS=X,
BATCHBUILD2=// NOTIFY=&SYSUID,REGION=512M
BATCHBUILD3=//*
BATCHBUILD4=//*
*
* Batch Promote default jobcard
BATCHPROMOTE1=//SCLMPROM JOB (#ACCT),'SCLM PROMOTE',CLASS=A,MSGCLASS=X,
BATCHPROMOTE2=// NOTIFY=&SYSUID,REGION=128M
BATCHPROMOTE3=//*
BATCHPROMOTE4=//*
*
* Batch Migrate default jobcard
BATCHMIGRATE1=//SCLMMIGR JOB (#ACCT),'SCLM MIGRATE',CLASS=A,MSGCLASS=X,
BATCHMIGRATE2=// NOTIFY=&SYSUID,REGION=128M
BATCHMIGRATE3=//*
BATCHMIGRATE4=//*
*
* Batch Deployment default jobcard
BATCHDEPLOY1=//SCLMDPLY JOB (#ACCT),'SCLM DEPLOY',CLASS=A,MSGCLASS=X,
BATCHDEPLOY2=// NOTIFY=&SYSUID,REGION=128M
BATCHDEPLOY3=//*
BATCHDEPLOY4=//*
*
* BUILD Security flag for SAF/RACF security call and possible Surrogate
* ID switch
BUILDSECURITY=N
*
* Project list flag if set to N will stop users selecting * as project
* filter. This may avoid long catalog searches for all SCLM projects.
*
PROJECTLISTALL=Y
*
* Large temporary dataset allocations for users are set in the
* product. The maximum temporary dataset allocation is SPACE(15,75)
* tracks. To alter the maximum dataset allocation, uncomment and
* modify the primary and secondary extent values below to your own
* values. The SPACE values represent number of TRACKS.
*TEMPDSN=SPACE(15,75)
Es ist auch möglich, projektspezifische Konfigurationseinstellungen zu verwenden, die verwendet werden, um ein einzelnes SCLM-Projekt zu konfigurieren. Diese überschreiben die SITE-spezifischen Werte, wenn eine Datei des Typs SITE.conf vorhanden ist. Wenn Sie projektspezifische Werte festlegen möchten, müssen Sie eine Datei mit dem Namen <project>.conf im Verzeichnis /PROJECT erstellen, wobei <project> der SCLM-Projektname ist (keine Unterscheidung von Groß-/Kleinschreibung).
Eine Muster-Konfigurationsdatei wird im Verzeichnis /usr/lpp/rdz/samples/ als Datei SCLMproject.conf bereitgestellt. Kopieren Sie dieses Muster mit dem richtigen Zielnamen in das PROJECT-Verzeichnis und passen Sie die Anweisungen Ihren Anforderungen entsprechend an.
Sie können die Datei mit dem TSO-Befehl OEDIT bearbeiten. Das folgende Beispiel zeigt den Projektkonfigurationscode.
* SCLM Developer Toolkit Project Specific option * * SCM Approver processing applies to this project? BUILDAPPROVER=BREEZE PROMOTEAPPROVER=BREEZE * * Change Code entry on check-in is mandatory? CCODE=Y * * Foreground or On-line builds/promotes allowed for this project? FOREGROUNDBUILD=N FOREGROUNDPROMOTE=N * * Batch Build default jobcard BATCHBUILD1=//SCLMBILD JOB (#ACCT),'SCLM BUILD',CLASS=A,MSGCLASS=X, BATCHBUILD2=// NOTIFY=&SYSUID,REGION=512M BATCHBUILD3=//* BATCHBUILD4=//* * * Batch Promote default jobcard BATCHPROMOTE1=//SCLMPROM JOB (#ACCT),'SCLM PROMOTE',CLASS=A,MSGCLASS=X, BATCHPROMOTE2=// NOTIFY=&SYSUID,REGION=128M BATCHPROMOTE3=//* BATCHPROMOTE4=//* * * BUILD Security flag for SAF/RACF security call and possible Surrogate * ID switch BUILDSECURITY=N * PROMOTE Security flag for SAF/RACF security call and possible * Surrogate ID switch PROMOTESECURITY=N * J2EE DEPLOY security flag for SAF/RACF security call and possible * Surrogate ID switch DEPLOYSECURITY=N
Alle aufgelisteten Optionen sind optional. Wenn in SITE.conf oder project.conf keine Angaben gemacht werden, werden Standardwerte verwendet.
BUILDAPPROVER=approval product/NONE | Geben Sie den Namen des Freigabeprodukts an, das für den Erstellungsprozess verwendet wird. Derzeit wird nur IBM Breeze für SCLM unterstützt. Dieses Produkt wird mit dem Schlüsselwort BREEZE ausgewählt. Die Standardeinstellung ist NONE. |
PROMOTEAPPROVER=approval product/NONE | Geben Sie den Namen des Freigabeprodukts an, das für den Umstufungsprozess verwendet wird. Derzeit wird nur IBM Breeze für SCLM unterstützt. Wenn PROMOTEAPPROVER auf BREEZE gesetzt ist, werden bei einer Umstufung Breeze-spezifische Felder angezeigt. Die Standardeinstellung ist NONE. |
CCODE=N/Y | Legen Sie Y fest, um den Änderungscode-Eintrag beim Check-In als Pflichtfeld zu definieren. Der Standardwert ist N, wobei der Änderungscode-Eintrag nicht obligatorisch ist. |
FOREGROUNDBUILD=Y/N | Legen Sie N fest, um Vordergrund-Builds einzuschränken. Die Standardeinstellung ist Y, wobei Vordergrund-Builds zulässig sind. |
FOREGROUNDPROMOTE=Y/N | Legen Sie N fest, um Vordergrund-Umstufungen einzuschränken. Die Standardeinstellung ist Y, wobei Vordergrund-Umstufungen zulässig sind. |
BATCHBUILD1=Job card 1 BATCHBUILD2=Job Card 2 BATCHBUILD3=Job Card 3 BATCHBUILD4=Job Card 4 |
Legen Sie eine Standard-Batch-Jobkarte für den Erstellungsprozess fest. Verschiedene Projekte können verschiedene Account-Codes oder Jobklassen verwenden. Mit der Option für die Angabe von projektspezifischen Jobkarten ist dieses Szenario möglich. |
BATCHPROMOTE1=Job card 1 BATCHPROMOTE2=Job card 2 BATCHPROMOTE3=Job card 3 BATCHPROMOTE4=Job card 4 |
Legen Sie einen Standard-Batch-Job für den Umstufungsprozess fest. Verschiedene Projekte können verschiedene Account-Codes oder Jobklassen verwenden. Mit der Option für die Angabe von projektspezifischen Jobkarten ist dieses Szenario möglich. |
BATCHMIGRATE1=Job card 1 BATCHMIGRATE2=Job card 2 BATCHMIGRATE3=Job card 3 BATCHMIGRATE4=Job card 4 |
Legen Sie einen Standard-Batch-Job für den Migrationsprozess fest. Verschiedene Projekte können verschiedene Account-Codes oder Jobklassen verwenden. Mit der Option für die Angabe von projektspezifischen Jobkarten ist dieses Szenario möglich. |
BUILDSECURITY=Y/N | Geben Sie Y an, um den SAF/RACF-Sicherheitsaufruf für den Erstellungsschritt aufzurufen und eventuell einen Wechsel zur Ersatz-ID auszuführen. Weitere Informationen finden Sie unter SCLM-Sicherheit. |
PROMOTESECURITY=Y/N | Geben Sie Y an, um den SAF/RACF-Sicherheitsaufruf für den Umstufungsschritt aufzurufen und eventuell einen Wechsel zur Ersatz-ID auszuführen. Weitere Informationen finden Sie unter SCLM-Sicherheit. |
DEPLOYSECURITY=Y/N | Geben Sie Y an, um den SAF/RACF-Sicherheitsaufruf für den Implementierungsschritt aufzurufen und eventuell einen Wechsel zur Ersatz-ID auszuführen. Weitere Informationen finden Sie unter SCLM-Sicherheit. |
ASCII=ASCII codepage | Geben Sie die ASCII-Codepage an, mit der die in TRANSLATE.conf angegebene ASCII-Codepage überschrieben werden soll. Beispiel:
ASCII=UTF-8 |
EBCDIC=EBCDIC codepage | Geben Sie die EBCDIC-Codepage an, mit der die in TRANSLATE.conf angegebene EBCDIC-Codepage überschrieben werden soll. Beispiel:
EBCDIC=IBM-420 |
TRANLANG=SCLM Language | Geben Sie einen TRANLANG-Parameter an, der zur Liste der TRANLANG-Parameter hinzugefügt werden soll, die in TRANSLATE.conf angegeben sind.
Beispiel:
TRANLANG=DOC |
NOTRANLANG=SCLM Language | Verwenden Sie das Schlüsselwort NOTRANLANG, um bereits angegebene TRANLANG-Parameter aus der für dieses SCLM-Projekt zulässigen Liste zu entfernen, wie in TRANSLATE.conf angegeben. Beispiel:
NOTRANLANG=JAVA |
LONGLANG=SCLM Language | Geben Sie einen LONGLANG-Parameter an, der zur Liste der LONGLANG-Parameter hinzugefügt werden soll, die in TRANSLATE.conf angegeben sind.
Beispiel:
LONGLANG=DOC |
NOLONGLANG=SCLM Language | Verwenden Sie das Schlüsselwort NOLONGLANG, um bereits angegebene LONGLANG-Parameter aus der für dieses Projekt zulässigen SCLM-Liste, wie in TRANSLATE.conf angegeben, zu entfernen. Beispiel:
NOLONGLANG=COBOL |
BIDIPROP=LANG=SCLM Language/* TextOrient=LTR/RTL TextType=Visual/Logical SymetricSwap=On/Off NumericSwap=On/Off |
Verwenden Sie das Schlüsselwort BIDIPROP, um die Standardwerte für bidirektionale Sprachen auf SCLM-Sprachen zu setzen. LANG= kann entweder auf alle SCLM-Sprachen oder auf bestimmte SCLM-Sprachen gesetzt werden. Bidirektionale Unterstützung ist nur unter Developer for System z möglich. |
PROJECTLISTALL=Y | Wenn das Projektlistenattribut auf N gesetzt ist, können Benutzer * nicht als Projektfilter verwenden. Dadurch werden zeitaufwändige Benutzerkatalogsuchen nach allen SCLM-Projekten vermieden. |
Die Datei TRANSLATE.conf legt die Standardeinstellungen für die Codepageunterstützung und Standard-SCLM-Sprachunterstützung fest, die in SCLM Developer Toolkit zugewiesen werden sollen. In diesem Beispiel hat TRANSLATE.conf die unten angegebenen Werte.
CODEPAGE ASCII = ISO8859-1 CODEPAGE EBCDIC = IBM-1047 * TRANLANG JAVABIN TRANLANG J2EEBIN TRANLANG J2EEOBJ TRANLANG TEXTBIN TRANLANG BINARY TRANLANG DOC TRANLANG XLS * LONGLANG JAVA LONGLANG SQLJ LONGLANG DOC LONGLANG XLS LONGLANG J2EEPART LONGLANG JAVABIN LONGLANG J2EEBIN LONGLANG J2EEOBJ
Verschiedene SCLM-Projekte, die verschiedene Datentypen speichern, möglicherweise in verschiedenen Landessprachen, können diese Standardeinstellungen überschreiben. Daher kann die Projektkonfigurationsdatei SCLMPRJ1.conf für das SCLM-Projekt SCLMPRJ1 folgende Überschreibungseinstellungen haben:
* Überschreibungen für arabische Codepages * ASCII=UTF-8 EBCDIC=IBM-420 * * Projektspecifische TRANLANG- und LONGLANG-Einträge * TRANLANG=DOC LONGLANG=DOC
Dadurch werden die Codepages für Quellenumsetzungen auf das arabische Codepage-Paar gesetzt. Darüber hinaus wird eine SCLM-Sprache des Typs DOC zu den Standardwerten aus TRANSLATE.conf hinzugefügt.
Das SCLM-Projekt SCLMPRJ2 kann andere Überschreibungseinstellungen in SCLMPRJ2.conf haben:
* Überschreibungen für hebräische Codepages * ASCII=UTF-8 EBCDIC=IBM-424 * * Projektspecifische TRANLANG- und LONGLANG-Einträge * TRANLANG=DOC TRANLANG=XLS NOTRANLANG=JAVABIN NOTRANLANG=J2EEBIN NOTRANLANG=J2EEOBJ LONGLANG=DOC LONGLANG=XLS NOLONGLANG=COBOL NOLONGLANG=J2EEPART NOLONGLANG=JAVABIN NOLONGLANG=J2EEBIN NOLONGLANG=J2EEOBJ
Dadurch werden die Codepages für Quellenumsetzungen auf das hebräische Codepage-Paar gesetzt. Darüber hinaus werden SCLM-Sprachen des Typs DOC und XLS zu den Standardwerten aus TRANSLATE.conf hinzugefügt. In diesem Fall werden jedoch die in TRANSLATE.conf festgelegten Standardwerte gelöscht. Dies ist nicht unbedingt erforderlich, da es nicht problematisch ist, zusätzliche Einstellungen zu verwenden. Auf diese Weise wird jedoch veranschaulicht, wie ein Projekt so eingerichtet werden kann, dass nur die erforderlichen SCLM-Sprachen für ein bestimmtes SCLM-Projekt vorhanden sind.
Die BIDIPROP-Werte, die in SITE.conf angegeben sind, können durch beliebige BIDIPROP-Werte überschrieben werden, die in den SCLM-projektspezifischen Dateien <project>.conf angegeben sind. In SITE.conf wird beispielweise Folgendes festgelegt:
* * ---------------- SITE SPECIFIC BIDI OPTIONS ------------------ * * * BiDi Language default properties * BIDIPROP=LANG=* TextOrient=LTR TextType=Visual SymetricSwap=Off NumericSwap=Off
Dadurch werden alle SCLM-Sprachen auf die angegebenen Einstellungen gesetzt. Nun kann Folgendes in der Datei ADMIN10.conf festgelegt werden:
* * BiDi Language default properties BIDIPROP=LANG=JAVA TextOrient=RTL TextType=Visual SymetricSwap=On NumericSwap=Off BIDIPROP=LANG=COBOL TextOrient=RTL TextType=Logical SymetricSwap=Off NumericSwap=Off
Diese Einstellungen überschreiben die Einstellungen in SITE.conf für die JAVA- und COBOL-Sprachdefinitionen. Alle anderen Sprachen erhalten die Standardeinstellungen, wie in SITE.conf angegeben.
SQLJ ist eine Spracherweiterung für Java. Es handelt sich dabei um eine Technologie, mit der Java-Programmierer Datenbankkommunikation in Programmen integrieren können. SQLJ bietet eine Möglichkeit, statisches, eingebettetes SQL zu erzeugen, das im Allgemeinen eine bessere Leistung bietet als dynamische Äquivalente wie JDBC.
SCLM Developer Toolkit wird mit Musterscripts geliefert, die Ihnen ermöglichen, SQLJ-fähige Java-Programme unter Verwendung von DB2 zu erstellen.
In diesem Kapitel werden die Grundlagen von SQLJ erläutert und es wird beschrieben, wie diese bei der Verwendung von SCLM Developer Toolkit angewendet werden.
SQL ist ein Akronym für Structured Query Language. Dabei handelt es sich um eine offene Sprache, die für das Abfragen, Hinzufügen, Löschen und Ändern von Daten in einem Managementsystem für relationale Datenbanken (RDMS) verwendet wird.
Diese Sprache wurde erstmals in den 1970er Jahren in einem frühen IBM Datenbankprodukt implementiert: System R. Seitdem wurde SQL weiterentwickelt, standardisiert (durch ANSI und ISO) und ist in verschiedensten Versionen auf zahlreichen Datenbanksystemen verwendet worden.
DB2 ist ein vielfach eingesetztes Datenbanksystem, das ursprünglich für die Mainframeplattform entwickelt und seitdem für viele andere Plattformen erweitert wurde. Es ist das Standardmanagementsystem für relationale Datenbanken unter z/OS.
DB2 UDB Version 8 ist die Version, auf der die Erstellungsscripts von SCLM Developer Toolkit basieren. Verweise auf DB2 in diesem Kapitel beziehen sich speziell auf DB2 UDB Version 8.
JDBC steht für Java Database Connectivity. Auf dem Gebiet der Java-Entwicklung ist dies eine bekannte und weit verbreitete Technologie für die Implementierung von Datenbankinteraktionen. JDBC ist eine API auf Aufrufebene, d. h. SQL-Anweisungen werden als Zeichenfolgen an die API übergeben, die diese dann auf dem RDMS ausführt. Daher kann der Wert dieser Zeichenfolgen während der Laufzeit geändert werden, wodurch JDBC dynamisch wird.
JDBC-Programme werden langsamer ausgeführt als funktional entsprechende SQLJ-Programme. Ein Vorteil dieser Lösung ist jedoch das als "Write once, call anywhere" (Einmal schreiben, überall aufrufen) bekannte Konzept. Da keine Interaktion bis zur Laufzeit erforderlich ist, können JDBC-Programme zwischen verschiedenen Systemen mit minimalem Aufwand übertragen werden.
SQLJ ist eine Spracherweiterung, die für Datenbanktransaktionen in Java-Anwendungen verwendet wird. Dabei wird statischer, integrierter SQLJ-Code erzeugt. Dieser Begriff setzt sich zusammen aus "SQL", was für Structured Query Language steht, und "J", was für Java steht.
SQLJ ist statisch, da die SQL-Anweisungen, die während der Laufzeit ausgeführt werden, bekannt sind, wenn das Programm assembliert wird. Hierin besteht ein Unterschied zu JDBC. In JDBC können die ausgeführten Abfragen jederzeit geändert werden.
SQLJ ist integriert, denn während des Bindens wird ein serialisiertes Formular der SQL-Anweisungen des Programms an die Datenbank übergeben. Die Datenbank verwendet diese serialisierten Daten, um optimierte Zugriffspfade zu den referenzierten Tabellen zu ermitteln. In JDBC kann die Datenbank erst ermitteln, welche Anweisungen ausgeführt werden sollen, wenn sie diese während der Laufzeit von der Anwendung erhält. Daher muss die Datenbank die Zugriffspfade während der Laufzeit ermitteln. Dadurch entsteht ein Systemaufwand, der bei der Verwendung von SQLJ vermieden wird.
Diese Tabelle basiert auf Materialien, die im Kapitel 5.2 des Redbooks DB2 UDB for z/OS Version 8: Everything You Ever Wanted to Know, ... and More enthalten sind.
SQLJ (statisch) | JDBC (dynamisch) | |
---|---|---|
LEISTUNG | Meistens ist statisches SQL schneller als dynamisches SQL, da während der Laufzeit nur die Berechtigung für Pakete und Pläne vor der Ausführung des Programms überprüft werden muss. | Bei dynamischen SQL-Anweisungen muss eine Syntaxanalyse der SQL-Anweisungen ausgeführt werden, die Berechtigung für die Tabellen/Anzeige muss geprüft werden und der Optimierungspfad muss ermittelt werden. |
AUTORISIERUNG | In SQLJ gewährt der Anwendungsinhaber die EXECUTE-Berechtigung für den Plan oder das Paket und der Empfänger dieses GRANT muss die Anwendung wie geschrieben ausführen. | In JDBC gewährt der Anwendungsinhaber Berechtigungen für alle zugrunde liegenden Tabellen, die von der Anwendung verwendet werden. Der Empfänger dieser Berechtigungen kann alle Vorgänge ausführen, die diese Berechtigungen zulassen, z. B. diese außerhalb der Anwendung verwenden, für die die Berechtigungen ursprünglich gewährt wurden. Die Anwendung kann nicht steuern, welche Vorgänge der Benutzer ausführen kann. |
DEBUGGING | SQLJ ist keine Anwendungs- programmierschnittstelle, sondern eine Spracherweiterung. Dies bedeutet, dass die SQLJ-Tools die SQL-Anweisungen in Ihrem Programm kennen und diese während des Programmentwicklungsprozesses auf korrekte Syntax und Berechtigungen prüfen. | JDBC ist eine reine Anwendungs- programmierschnittstelle auf Aufrufebene. Dies bedeutet, dass der Java-Compiler keinerlei Informationen zu den SQL-Anweisungen hat. Diese erscheinen nur als Argumente für Methodenaufrufe. Wenn eine Ihrer Anweisungen fehlerhaft ist, kann dieser Fehler erst während der Laufzeit abgefangen werden, wenn die Datenbank den Fehler meldet. |
ÜBERWACHUNG | Mit SQLJ erhalten Sie eine wesentlich bessere Systemüberwachung und Leistungsberichterstattung. Statische SQL-Pakete liefern Ihnen die Namen der Programme, die zu einem beliebigen Zeitpunkt ausgeführt werden. Dies ist überaus nützlich für die Überprüfung der CPU-Belegung durch die verschiedenen Anwendungen, bei Sperrproblemen (wie Deadlock oder Zeitlimitüberschreitung) usw. | Während Sie mit SQLJ den Namen des aktuell ausgeführten Programms ermitteln können, werden mit JDBC alle Vorgänge durch dasselbe Programm ausgeführt. Dadurch wird die Überwachung und Lokalisierung von Problembereichen erschwert. |
AUSFÜHRLICHKEIT | Da SQLJ-Anweisungen in reiner SQL-Syntax codiert werden, ohne dass diese in eine Java-Methode eingeschlossen werden müssen, sind die Programme leichter zu lesen, wodurch sie einfacher verwaltet werden können. Da außerdem ein Teil des Standardcodes, der explizit in JDBC codiert werden muss, automatisch in SQLJ generiert wird, sind in SQLJ geschriebene Programme meistens kürzer als funktional entsprechende JDBC-Programme. | In JDBC müssen alle SQL-Anweisungen in API-Aufrufe eingeschlossen werden, wodurch im Allgemeinen ein undeutlicher und ausführlicher Code entsteht. |
Ein serialisiertes Profil ist ein Code, der in SQLJ geschrieben wurde und mit der Erweiterung .sqlj in eine Datei eingefügt wird. Im ersten Schritt der Programmerstellung (später ausführlicher erläutert) wird die Datei .sqlj dem SQLJ-Umsetzer zugeführt.
Der Umsetzer erstellt zwei Typen von Ausgaben. Der erste Typ ist Java-Quellcode (.java). Dieser Quellcode ist die Java-Implementierung des Codes innerhalb der SQLJ-Datei.
Der zweite Ausgabetyp ist ein serialisiertes Profil (.ser). Diese Datei enthält alle SQL-Anweisungen aus der .sqlj-Datei in serialisierter Form. Dieses Profil muss dem Programm während der Laufzeit zur Verfügung stehen und kann auch verwendet werden, um eine Bindung mit dem RDMS herzustellen.
DBRM steht für Database Request Module (Datenbankanforderungsmodul). Dabei handelt es sich um die konventionelle serialisierte DB2-Darstellung der SQL-Anweisungen in einem Programm. Ein Programm kann z. B. in COBOL geschrieben sein. Dieses Programm wird durch DB2 vorverarbeitet. Dabei wird ein Datenbankanforderungsmodul erstellt, das für die Bindung mit einem bestimmten DB2-Subsystem verwendet wird.
Dieser Prozess unterscheidet sich in Bezug auf SQLJ geringfügig. Im Zusammenhang mit DB2 UDB Version 8 wird dieser Vorgang als Kompatibilitätsmodus bezeichnet. Das Dienstprogramm db2sqljcustomize kann mit optionalen Befehlszeilenargumenten bereitgestellt werden, die die Erstellung eines Datenbankanforde- rungsmoduls veranlassen. Dieses Datenbankanforderungsmodul kann anschließend durch Verwendung konventioneller Vorgehensweisen, z. B. durch ein REXX-Script, das durch einen SCLM-Benutzerexit aufgerufen wird, an DB2 gebunden werden.
Bevor erläutert wird, wie SCLM Developer Toolkit zum Erstellen von SQLJ-Programmen verwendet werden kann, wird an dieser Stelle zunächst der manuelle Prozess beschrieben. Dieser Prozess bezieht sich auf die DB2-Implementierung von SQLJ. Dabei werden drei Befehle mit den Bezeichnungen sqlj, db2sqljcustomize und db2bind verwendet. Beachten Sie, dass der Bindungsschritt optional in db2sqljcustomize ausgeführt werden kann, daher wird db2bind nicht in allen Fällen benötigt.
Der SQLJ-Umsetzer (nicht zu verwechseln mit einem SCLM-Sprachumsetzer) verwendet SQLJ-Quellendateien als Eingabe und erstellt Java-Quellcode (Dateien des Typs .java) und serialisierte Profile (Dateien des Typs .ser).
Die SQLJ-Sprache selbst wird in diesem Handbuch nicht erläutert. Nutzen Sie die Website http://www.sql.org, um Hinweise zur Entwicklung von SQLJ-Code zu erhalten.
Die Anzahl der pro .sqlj-Datei generierten serialisierten Profile ist abhängig von der Anzahl der Verbindungskontext-Klassen, die im SQLJ-Code referenziert werden. Ein serialisiertes Profil wird für jede Klasse generiert.
Viele SQLJ-Quellendateien verweisen nur auf eine bestimmte Verbindungskontextklasse und generieren daher nur ein serialisiertes Profil. Die serialisierten Profile werden anhand der Reihenfolge benannt, in der sie in der Quellendatei angegeben werden.
Für den Namen wird das folgende Format verwendet:
Programmname_SJProfileX.ser
Dabei gilt:
Beispiel:
Eingabe: Customer.sqlj (referenziert eine Verbindungskontextklasse) Ausgabe: Customer.java Customer_SJProfile0.ser Und optional, wenn das Argument -compile=true für sqlj bereitgestellt wird: Customer.class
Nach dem Generieren der serialisierten Profile müssen diese angepasst werden. Der hierfür in DB2 Version 8 verwendetet Befehl ist db2sqljcustomize. In früheren Versionen wurde der Befehl db2profc verwendet. Jeder Aufruf des Customizers sollte einem Aufruf mit dem SQLJ-Umsetzer entsprechen. Das heißt, wenn ein Aufruf des Umsetzers fünf Profile generiert hat, müssen diese fünf Profile einem Aufruf der Profilanpassungsfunktion als Eingabe zugeführt werden. Anders ausgedrückt bedeutet dies, dass jeder einzelne Programmname mit einem Aufruf für jedes einzelne Dienstprogramm verknüpft wird. Beachten Sie, dass der Programmname dem Eingabequellen-Dateinamen ohne die Erweiterung .sqlj entspricht.
Bei der Anpassung werden dem serialisierten Profil DB2-spezifische Informationen hinzugefügt, die während der Laufzeit verwendet werden. Andere Optionen, wie automatisches Binden, können durch Befehlszeilenswitches konfiguriert werden. Wenn Sie eine ältere Version von DB2 verwenden oder wenn Sie die Attribute gendbrm und dbrmdir für db2sqljcustomize festlegen, wird eine DBRM-Datei generiert. Diese Datei wird später für die Bindung an die Datenbank verwendet. Mit dem universellen Treiber von DB2 UDB 8+ können Sie auf die Erstellung eines Datenbankanforderungsmoduls verzichten und die Bindung stattdessen mit den serialisierten Profilen herstellen, die mit dem SQLJ-Umsetzer generiert wurden.
Binden ist der letzte Schritt im Prozess der SQLJ-Programmerstellung. In DB2 Version 8 wird für das Binden der Befehl db2sqljbind verwendet. Sie können auch automatisches Binden festlegen, indem Sie den Befehl db2sqljcustomize ausführen. Beim Binden wird ein Zugriffspfad zu den DB2-Tabellen für Ihre serialisierten SQL-Anweisungen erstellt. Diese Anweisungen sind entweder in Form eines Datenbankanforderungsmoduls oder eines serialisierten Profils verfügbar.
Standardmäßig werden vier Pakete erstellt, eins für jede Isolationsstufe. Sie können entweder mit der konventionellen Methode binden, bei der ein Datenbankanforderungsmodul verwendet wird, oder mit der neuen universellen Methode, bei der stattdessen serialisierte Profile verwendet werden.
Bevor die SCLM-Typen und -Umsetzer erläutert werden, sollen die Unterschiede zwischen einem SCLM-Sprachumsetzer (kurz SCLM-Umsetzer) und dem SQLJ-Umsetzer sqlj beschrieben werden, der in DB2 bereitgestellt wird.
In SCLM muss jede definierte Sprache einen Umsetzer haben, damit bekannt ist, wie diese Sprache verarbeitet werden kann. Diese Umsetzer unterscheiden sich von dem SQLJ-Umsetzer sqlj: Bei letzterem handelt es sich um ein Befehlszeilendienstprogramm, das eine SQLJ-Quellendatei aufruft und serialisierte Profile und Java-Quellcode erstellt.
Nachdem diese Unterscheidung verdeutlicht wurde, sollen die SCLM-Typen und SCLM-Umsetzer erläutert werden, die mit dem SQLJ-Erstellungsprozess verbunden sind.
Ein SCLM-Umsetzer für SQLJ wird bereitgestellt und sollte als Sprachtyp für den gesamten SQLJ-Quellcode zugewiesen werden, der in SCLM gespeichert wird. Für diesen neuen Umsetzer müssen zusätzliche SCLM-Typen definiert werden. Der SCLM-Umsetzer für SQLJ ist ähnlich aufgebaut wie der JAVA-Umsetzer, enthält jedoch weitere IOTYPE-Definitionen für die SCLM-Ausgabetypen SQLJSER und DBRMLIB. Wenn Sie keine DBRM-Dateien während des Anpassungsvorgangs generieren möchten, kann dieser DBRMLIB IOTYPE aus der SQLJ-Sprachdefinition entfernt werden.
Innerhalb der Projektdefinition muss der Administrator den neuen SCLM-Umsetzer und zusätzliche Typen definieren.
SQLJSER | Dies ist erforderlich, um die Dateien der serialisierten Profile zu speichern (Dateien des Typs .ser), die in den Konvertierungs- und Anpassungsschritten erstellt oder angepasst wurden. Es wird empfohlen, diese SCLM-Typ-Dateigruppe als recfm=VB, lrecl= 256 zu definieren. |
DBRMLIB | Ein Typ, der die generierten DBRM-Dateien enthalten muss, die im Anpassungsschritt erstellt werden. Dieser Typ wird nur für Kunden benötigt, die generierte DBRM-Dateien im Rahmen des DB2-Bindeprozesses verwenden. |
Um hohe Flexibilität zu gewährleisten, kann der SQLJ-Erstellungsprozess angepasst werden. Auf diese Weise können unterschiedliche Standortkonfigurationen und eine beliebige Kombination von Parametern berücksichtigt werden, die an sqlj und db2sqljcustomize übergeben werden müssen.
In diesem Abschnitt werden die Konzepte der Implementierung von SQLJ mit SCLM Developer Toolkit beschrieben. Hier erfahren Sie, wie Sie den Erstellungsprozess anpassen können, um die Anforderungen Ihres Standorts zu berücksichtigen.
Während der SQLJ-Umsetzung und Profilanpassung ruft SCLM Developer Toolkit dieselben Java-Klassen direkt auf, die von den Befehlen sqlj und db2sqljcustomize verwendet werden. Beachten Sie, dass die Argumente, die an den SCLM DT-Umsetzungs- und Anpassungsprozess übergeben werden, exakt übereinstimmen. Wenn Sie eine umfassende Beschreibung aller Befehlszeilenparameter für jeden Befehl erhalten möchten, ziehen Sie das Benutzerhandbuch für DB2 Universal Database zu Rate.
Wenn Sie den Assistenten "Zu SCLM hinzufügen" verwendet haben, erhält das für Ihr SQLJ-Programm verwendete Erstellungsscript denselben Membernamen wie die Archdef. Wenn z. B. die Archdef für Ihr sqlj-Projekt SCLM10.DEV1.ARCHDEF(SQLJ01) ist, finden Sie das Erstellungsscript unter SCLM10.DEV1.J2EEBLD(SQLJ01).
In diesem Erstellungsscript ist ein Verweis auf das Master-Erstellungsscript vorhanden. Dieser befindet sich in der Eigenschaft. Der größte Teil der Konfiguration, die für die Umsetzungs- und Anpassungsschritte aufgeführt ist, wird in dieser Datei ausgeführt.
Jede in Tabelle 9 aufgeführte Eigenschaft wird im BWBSQLB-Erstellungsscript angezeigt. Die Eigenschaften liegen im XML-Format vor und lauten wie folgt:
Beim Konfigurieren des Scripts müssen die Werte für alle relevanten Eigenschaften geändert werden.
Name | Wert | Beschreibung |
---|---|---|
sqlj.exec | usr/lpp/rdz/bin/bwbsqlc.rex | Gibt die Speicherposition der sqlj- & db2sqljcustomize-Exec-Routine bwbsqlc.rex an, die im Installationsverzeichnis von Developer for System z gespeichert ist. |
sqlj.class | sqlj.tools.Sqlj | Geben Sie den SQLJ-Klassennamen an. Dies ist der Name der Klasse, die durch das SQLJ-Dienstprogramm aufgerufen wird. Üblicherweise muss dieser Wert nicht geändert werden. |
sqlj.bin | /db2path/bin | Geben Sie die Speicherposition des DB"-SQLJ-Verzeichnisses "bin" an, wo das SQLJ-Script gespeichert ist. |
sqlj.cp | /db2path/jcc/classes/sqlj.zip | Geben Sie die Speicherposition von sqlj.zip für das Einschließen des Klassenpfads an. |
sqlj.arg | -compile=false status linemap=NO db2optimize | Geben Sie unten globale Eigenschaftsargumente für die SQLJ-Verarbeitung an. |
Jede in Tabelle 10 aufgeführte Eigenschaft wird im BWBSQLB-Erstellungsscript angezeigt. Die Eigenschaften liegen im XML-Format vor, wie folgt:
<property name= NAME value= VALUE />
Beim Konfigurieren des Scripts müssen die Werte für alle relevanten Eigenschaften geändert werden.
Name | Wert | Beschreibung |
---|---|---|
sqljdb2cust.class | com.ibm.db2.jcc.sqlj.Customizer | Geben Sie den Anpassungsklassennamen für sqlj db2 an. Üblicherweise muss dieser Wert nicht geändert werden. |
db2sqljcust.cp |
/db2path/jcc/classes/db2jcc.jar: ./SRC: /db2path/jcc/classes/db2jcc_license_cisuz.jar |
Klassenpfadeinstellungen für das Anpassungsdienst- programm. Vollständig qualifizierte Pfadnamen müssen in XML angegeben werden. |
db2sqljcust.arg | -automaticbind NO -onlinecheck YES -staticpositioned YES -bindoptions â ISOLATION(CS)â -genDBRM | Allgemeine Argumente für das Anpassungsdienst- programm. |
db2sqljcust.propfile | user.properties | Temporärer Eigenschaftendateiname, der an ein Benutzereigenschafts-Ermittlungsscript für dynamische Eigenschaftswerte übergeben wird. Behalten Sie die Standardeinstellung bei. |
db2sqljcust.userpgm | NONE, wenn Sie das Script umgehen möchten. Andernfalls müssen Sie den vollständig qualifizierten Pfad- und Dateinamen des Benutzerscripts angeben. | Dieses Script wird direkt vor dem Anpassungsdienst- programm ausgeführt. Dadurch wird eine Eigenschaftendatei dyna- misch aktualisiert, die als Ein- gabe für das Anpassungs- dienstprogramm verwen- det wird. |
Das SQLJ-Erstellungsscript, das in SCLM Developer Toolkit enthalten ist, wurde entwickelt, um im DB2 UDB v8-Kompatibilitätsmodus zu arbeiten. Dieser Modus unterstützt das DB2-Konzept der Datenbankanforderungsmodule anstelle des Bindens durch serialisierte Profile. Um die serialisierten Profile verwenden zu können, müssen Änderungen in BWBSQLB vorgenommen werden. Dies wird im Unterabschnitt Bindung [Serialisiertes Profil] erläutert.
Abgesehen von der Bindungsmethode müssen Sie bei der Anpassung des Erstellungsprozesses für Ihren Standort wahrscheinlich die Argumente für sqlj und db2sqljcustomize anpassen, um Ihre Datenbankumgebung, Isolationsrichtlinie und andere Faktoren zu berücksichtigen. Vielleicht möchten Sie auch Ihre eigenen Scripts verwenden, um dynamische Eigenschaften für diese Argumente festzulegen, um z. B. einen Paketnamen, der mit dem Eingabedateinamen verbunden ist, auf effiziente Weise zu erstellen.
In SCLM Developer Toolkit können Sie Ihre eigenen Anpassungsscripts angeben. Alle Angaben im ANT-XML-Erstellungsprozess verwenden das Konzept der "Eigenschaften". Dabei handelt es sich um XML-Property-Elemente, die ein Name-Wert-Paar angeben. So werden z. B. im db2sqljcustomize-Schritt im Erstellungsscript BWBSQLB die globalen Befehlszeilenargumente, die an db2sqljcustomize weitergegeben werden sollen, in einem Eigenschaftselement mit dem Namen db2sqljcust.arg und dem Standardwert -automaticbind NO -onlinecheck YES -staticpositioned YES -bindoptions "ISOLATION(CS)" genDBRM lang=EN-AU definiert.
Wenn Sie die angegebenen Argumente ändern möchten, können Sie das Erstellungsscript bearbeiten, um den Wert der Eigenschaft zu ändern. Dabei werden die Eigenschaften global geändert. Andernfalls können Sie Ihr eigenes Anpassungsscript in den Prozess einbinden.
Um Ihr eigenes angepasstes Eigenschaftsscript einzubinden, geben Sie den Namen Ihres Scripts in db2sqljcust.userpgm sowie den Namen der Eigenschaftendatei, in die geschrieben werden soll, in db2sqljcust.propfile an.
Das in db2sqljcust.userpgm angegebene Script wird direkt vor dem db2sqljcustomize-Prozess ausgeführt. Ihr Script aktualisiert dynamisch die in db2sqljcust.userpgm angegebene Eigenschaftendatei. Diese Eigenschaftendatei wird als Eingabe für den db2sqljcustomize-Prozess verwendet, da der Erstellungsprozess beide Eigenschaften in der dynamisch aktualisierten Eigenschaftendatei sowie die bereits im Erstellungsscript definierten Eigenschaften verkettet.
Das in db2sqljcust.userpgm angegebene Script wird durch die folgenden Argumente bereitgestellt, wenn es ausgeführt wird:
Die Eigenschaften sollten in der Datei im folgenden Format festgelegt werden, wobei eine Eigenschaftsdeklaration pro Zeile angegeben wird:
argument=value Beispiel: singlepkgname= pkgname
Beispiel:
pkgversion=1 url=jdbc:db2://site1.com:80/MVS01 qualifier=DBT singlepkgname= SQLJ986
Die angepasste Routine wird einmal pro Datei aufgerufen. Schließlich werden die Argumenteigenschaften verwendet, um die erforderliche Argumentenfolge für den Aufruf von "db2sqljcustomize" zu erstellen. Beispiel:
db2sqljcustomize -automaticbind NO -collection ${db2.collid} -url ${db2.url} -user ${db2.user} -password ???????? -onlinecheck YES -qualifier ${db2.qual} -staticpositioned YES -pkgversion ${db2.packversion} -bindoptions "ISOLATION (CS)" -genDBRM -DBRMDir DBRMLIB -singlepkgname ${db2.pack}
DB2 verwendet traditionell ein Datenbankanforderungsmodul (DBRM) für diesen Zweck. Das Datenbankanforderungsmodul wird durch den Befehl db2sqljcustomize erstellt, wenn das Attribut gendbrm bereitgestellt wird. Ohne dieses Attribut setzt der Befehl voraus, dass Sie die Bindung durch serialisierte Profile herstellen möchten, und erstellt kein Datenbankanforderungsmodul.
Wenn Sie diesen Parameter angeben, berücksichtigt SCLM Developer Toolkit die generierten Datenbankanforderungsmodule und speichert diese in SCLM für doe zukünftige Verwendung. Ein Vorteil dieses Verfahrens ist, dass Sie eine DB2-Bindung einfach in einem SCLM-Benutzerexit ausführen können, z. B. dem Build-/Copy-Exit.
Da der Build-/Copy-Benutzerexit automatisch mit einer Liste aktualisierter Objekte bereitgestellt wird, können Sie nur die geänderten Module erneut binden. Auf diese Weise werden ineffiziente Vorgänge durch redundantes Binden vermieden.
Um die Bindung von Datenbankanforderungsmodulen zu konfigurieren, müssen die folgenden vier Schritte ausgeführt werden:
<!-- specify global property arguments below for sqlj processing --> <property name="sqlj.arg" value="-compile=false -status -linemap=no"/>
Argument | Beschreibung |
---|---|
compile=false | Wenn diese Option auf "false" gesetzt wird, wird vermieden, dass der SQLJ-Umsetzer automatisch den zu erstellenden Java-Quellcode kompiliert. SCLM Developer Toolkit verwendet die generierte Quelle in seinem eigenen Erstellungsprozess. Daher wird empfohlen, die Option immer auf "false" zu setzen. |
linemap=no | Gibt an, ob die Zeilennummern in Java-Ausnahmebedingungen den Zeilennummern in den SQLJ-Quellendateien (.sqlj-Dateien) entsprechen oder den Zeilennummern in der Java-Quellendatei, die durch die SQLJ-Umsetzerdateien generiert wird (.java-Datei). Dafür ist eine Datei des Typs .class erforderlich. Deshalb muss no festgelegt werden, wenn das Argument in Verbindung mit compile=false verwendet wird. |
status | Gibt eine sofortige Statusanzeige der SQLJ-Verarbeitung aus. |
<property name="db2sqljcust.arg" Value='-automaticbind NO -onlinecheck YES -bindoptions "ISOLATION(CS)" -gendbrm'/>
Argument | Beschreibung |
---|---|
automaticbind no | Wenn auf "no" gesetzt, führt der Customizer keine Bindung aus, wenn die Anpassung abgeschlossen ist. |
onlinecheck yes | Führen Sie eine Onlineprüfung des mit dem Parameter url angegebenen Systems aus. Standardmäßig wird "yes" festgelegt, wenn url angegeben wird, andernfalls "no". |
Bindoptions ISOLATION(CS) | Weist den Binder an, ein einzelnes Paket zu erstellen (Cursorstabilität). Wird in Verbindung mit singlepkgname verwendet (dynamisch festgelegt). |
gendbrm | Weist den Customizer an, DBRM-Dateien zu generieren. |
Legen Sie die Speicherposition Ihres Benutzerprogramms in BWBSQLB fest. Dadurch erhält der Erstellungsprozess die Information, wo sich das Routenerweiterungsscript befindet, das zum Berechnen der dynamischen Eigenschaften verwendet wird.
Die entscheidende Eigenschaft, die dynamisch konfiguriert werden soll, ist singlepkgname. Dies ist der Name des Pakets, mit dem eine Bindung erstellt werden soll. Jedes Programm erhält einen eindeutigen Paketnamen. In diesem einfachen Beispiel sind dies die ersten acht Buchstaben des Programmnamens.
Da im Anpassungsschritt singlepkgname verwendet wird, stimmt der Name des Pakets mit dem Namen des Datenbankanforderungsmoduls überein.
Als neue Lösung für das Binden von SQLJ-Programmen wird die Verwendung von serialisierten Profilen (Dateien des Typs .ser) empfohlen. Diese neue Lösung musste eingeführt werden, da das serialisierte Profil dieselbe Funktion ausführt wie das Datenbankanforderungsmodul und ein serialisiertes Bild der Anweisungen im Programm bereitstellt.
Mit einigen kleinen Änderungen am Erstellungsscript BWBSQLB können Sie SCLM Developer Toolkit für die Verwendung der neuen Methode konfigurieren. Dabei müssen nur die für "db2sqljcustomize" bereitgestellten Argumente geändert werden, indem der Befehlszeilenwechsel "gendbrm" gelöscht und "automaticbind" auf "YES" gesetzt wird.
Um die Bindung für serialisierte Profile zu konfigurieren, müssen die folgenden drei Schritte ausgeführt werden:
Es gibt keine Befehlszeilenparameter für den sqlj-Umsetzer, die nur für die Bindung mit serialisierten Profilen gelten. Es werden jedoch die für dieses bestimmte Beispiel festgelegten Argumente gezeigt.
<!-- specify global property arguments below for sqlj processing --> <property name="sqlj.arg" value="-compile=false -status -linemap=no"/>
Argument | Beschreibung |
---|---|
compile=false | Wenn diese Option auf "false" gesetzt wird, wird vermieden, dass der SQLJ-Umsetzer automatisch den zu erstellenden Java-Quellcode kompiliert. SCLM Developer Toolkit verwendet die generierte Quelle in seinem eigenen Erstellungsprozess. Daher wird empfohlen, die Option immer auf "false" zu setzen. |
linemap=no | Gibt an, ob die Zeilennummern in Java-Ausnahmebedingungen den Zeilennummern in den SQLJ-Quellendateien (.sqlj-Dateien) entsprechen oder den Zeilennummern in der Java-Quellendatei, die durch die SQLJ-Umsetzerdateien generiert wird (.java-Datei). Dafür ist eine Datei des Typs .class erforderlich. Deshalb muss no festgelegt werden, wenn das Argument in Verbindung mit compile=false verwendet wird. |
status | Gibt eine sofortige Statusanzeige der SQLJ-Verarbeitung aus. |
<property name="db2sqljcust.arg" Value='-automaticbind YES -onlinecheck YES'/>
Argument | Beschreibung |
---|---|
automaticbind yes | Wenn auf "yes" gesetzt, führt der Customizer auch dann eine Bindung aus, wenn die Anpassung abgeschlossen ist. Wenn auf "no" gesetzt, muss die Bindung gesondert mit dem Befehl db2bind ausgeführt werden. |
onlinecheck yes | Führen Sie eine Onlineprüfung des mit dem Parameter url angegebenen Systems aus. Standardmäßig wird "yes" festgelegt, wenn url angegeben wird, andernfalls "no". |
Legen Sie die Speicherposition Ihres Benutzerprogramms in BWBSQLB fest. Dadurch erhält der Erstellungsprozess die Information, wo sich das Routenerweiterungsscript befindet, das zum Berechnen der dynamischen Eigenschaften verwendet wird.
<property name="db2sqljcust.userpgm" value="/u/dba/sqljcust.rex"/>
SCLM Developer Toolkit bietet optionale Sicherheitsfunktionen für die Builderstellung, Umstufung und Implementierung.
Sie können ein Sicherheitsattribut für die Erstellung, Umstufung und Implementierung in den SITE-/PROJECT-Konfigurationsdateien festlegen. Weitere Informationen zu den SITE-/PROJECT-Konfigurationsdateien finden Sie unter SITE- und projektspezifische Optionen. Die folgenden Anweisungen steuern das jeweilige Sicherheitsattribut der Erstellungs-, Umstufungs- und Implementierungsfunktion:
Die Erstellungs-, Umstufungs- und Implementierungsfunktion in SCLM verwendet die Sicherheitsschnittstelle SAF/RACROUTE, welche von allen gängigen Sicherheitsprodukten unterstützt wird.
Die aufgeführten Musterbefehle gelten für RACF. Wenn Sie ein anderes Sicherheitsprodukt verwenden, ziehen Sie die entsprechende Dokumentation zu Rate.
Der Sicherheitsadministrator definiert die erforderlichen Profile in der XFACILIT-Klasse mit dem Befehl RDEFINE sowie die Zugriffsberechtigungen mit dem Befehl PERMIT. In Tabelle 11 erfahren Sie, welche Profile definiert werden müssen.
Funktion | XFACILIT-Profil | Erforderlicher Zugriff |
---|---|---|
Build | SCLM.BUILD.project.projdef.group.type.member | READ |
Promote | SCLM.PROMOTE.project.projdef.group.type.member | READ |
Deploy | SCLM.DEPLOY.server.application.node.cell.project.projdef.group.type | READ |
In der unten stehenden Liste wird die Bedeutung der verschiedenen Profilteilnamen beschrieben:
SCLM | Konstante, gibt ein SCLM-Funktionsprofil an |
BUILD | Konstante, gibt die BUILD-Funktion an |
PROMOTE | Konstante, gibt die PROMOTE-Funktion an |
DEPLOY | Konstante, gibt die DEPLOY-Funktion an |
project | SCLM-Projektname oder * für alle Projekte |
projdef | Alternativer Projektname (standardmäßig übereinstimmend mit dem Projektnamen) oder * für alle alternativen Projekte |
Group | SCLM-Gruppe, die erstellt/umgestuft/implementiert werden soll, oder * für alle Gruppen |
Type | SCLM-Typ oder * für alle Typen |
Member | SCLM-Member, das erstellt/umgestuft/implementiert werden soll, oder * für alle Member |
Server | Ziel-Implementierungsserver (SERVER_NAME im Ant-Implementierungsscript) oder * für alle Server |
Application | Name der Ziel-WAS-Anwendung (APPLICATION_NAME im Ant-Implementierungsscript) oder * für alle Anwendungen |
Node | Name des Ziel-WAS-Knotens (NODE_NAME im Ant-Implementierungsscript) oder * für alle Knoten |
Cell | Name der Ziel-WAS-Zelle (CELL_NAME im Ant-Implementierungsscript) oder * für alle Zellen |
Die Erstellungs-, Umstufungs- und Implementierungsfunktionen unterstützen die Verwendung einer Ersatzbenutzer-ID zum Ausführen der Funktion. Wenn diese aktiviert ist, bewirken alle autorisierten Aufrufe der Funktion, dass die Funktion mit den Berechtigungen der Ersatzbenutzer-ID anstelle der anfordernden Benutzer-ID ausgeführt wird.
Die Aktivierung der Ersatzbenutzer-ID ist profilspezifisch und wird gesteuert durch die Zeichenfolge "SUID=userid" im Feld APPLDATA im Sicherheitsprofil, wobei userid die Ersatzbenutzer-ID ist. Wenn die Zeichenfolge vorhanden ist, wird die Ersatzbenutzer-ID verwendet, wenn nicht, wird die Benutzer-ID des Anforderers verwendet.
In diesem Beispiel werden die Sicherheitsproduktdefinitionen aufgelistet, die benötigt werden, um die Erstellungsfunktion für ein bestimmtes Projekt zu schützen. Dasselbe Muster kann verwendet werden, um die Umstufungsfunktion zu schützen, indem die Regel SCLM.BUILD.* durch die Regel SCLM.PROMOTE.* ersetzt wird.
Die folgende Profildefinition schützt alle Member für die Erstellung im Projekt =TESTPROJ auf der Gruppenebene PROD. Darüber hinaus wird eine Ersatzbenutzer-ID definiert.
RDEFINE XFACILIT SCLM.BUILD.TESTPROJ.TESTPROJ.PROD.*.* UACC(NONE) APPLDATA('SUID=IBMUSER') SETROPTS RACLIST(XFACILIT) REFRESH
In diesem Beispiel wird ein SCLM-Erstellungsprofil definiert. Dabei gilt Folgendes:
Das folgende Beispiel zeigt Sicherheitsberechtigungen, die für einzelne Benutzer (oder Benutzergruppen) für das TESTPROJ-Projekt des vorherigen Beispiels definiert wurden:
PERMIT SCLM.BUILD.TESTPROJ.TESTPROJ.PROD.*.* CLASS(XFACILIT) ID(USERID) ACCESS(READ)
Der Wert PERMIT entspricht dem ursprünglichen RDEFINE-Profil und erlaubt dem Benutzer USERID, ein beliebiges Member aus dem Projekt TESTPROJ und der Gruppe PROD zu erstellen. Da eine Ersatzbenutzer-ID im Anwendungsdatenfeld (APPLDATA) des entsprechenden Profils gespeichert ist, wird der BUILD unter dieser Ersatzbenutzer-ID verarbeitet (in diesem Fall IBMUSER).
Im Folgenden sehen Sie ein Beispiel für die Erstellung eines Implementierungsprofils.
RDEFINE XFACILIT SCLM.DEPLOY.SERVERY.TESTAPP.NODE1.CELL1.TESTPROJ.TESTPROJ.PROD.J2EEDEP UACC(NONE)
WAS-Details:
SCLM-Projektdetails:
Weitere Informationen:
Das folgende Beispiel zeigt Sicherheitsberechtigungen, die für eine Benutzergruppe des zuvor definierten Implementierungsprofils definiert wurden:
PERMIT SCLM.DEPLOY.SERVERY.TESTAPP.NODE1.CELL1.TESTPROJ.TESTPROJ.PROD.J2EEDEP CLASS(XFACILIT) ID(J2EEGRP) ACCESS(READ)
Dies entspricht dem ursprünglichen RDEFINE-Profil und erlaubt allen Benutzern, die zur RACF-Gruppe J2EEGRP gehören, auf dem obigen Server und von denselben SCLM-Projektdetails aus zu implementieren.
Auch wenn die meisten Erstellungen und Umstufungen über den Developer Toolkit-Client initialisiert werden, besteht außerdem die Möglichkeit, Erstellungs- und Umstufungskonfigurationsdateien im z/OS UNIX System Services-Dateisystem einzurichten und diese Erstellungen oder Umstufungen durch den CRON-(Zeit-)Service in UNIX System Services zu initialisieren.
Wenn Sie diese Methode verwenden, wird der SCLM Developer Toolkit-Client nicht benötigt, da die relevanten Erstellungs- und Umstufungsparameter aus einer z/OS UNIX System Services-Dateisystem-Konfigurationsdatei gelesen werden und an die Hostkomponente von Developer Toolkit für die Verarbeitung in SCLM übermittelt werden.
Unten finden Sie eine Beschreibung der Muster von SCLM Developer Toolkit, die über CRON initialisierte Erstellungen und Umstufungen bereitstellen. Diese Muster sind im Musterverzeichnis von Developer for System z unter /usr/lpp/rdz/samples/ verfügbar. Eine Kopie, die Ihren Anforderungen angepasst werden kann, wurde während der Anpassung von Developer for System z unter /etc/rdz/sclmdt/script/ abgelegt.
Die Variablen PATH und STEPLIB im systemweiten Profil (/etc/profile) oder Benutzerprofil (/u/userid/.profile) müssen festgelegt werden, um die CRON-Jobs ($PATH) zu lokalisieren und die SCLM Developer Toolkit-Lademodule ($STEPLIB) zu lokalisieren, wenn die SCLM Developer Toolkit-Lademodule sich nicht in der LINKLIST befinden. Beispiel:
PATH=/etc/rdz/sclmdt/script:$PATH STEPLIB=FEK.SFEKLOAD:FEK.SFEKAUTH:$STEPLIB
Nachdem die CRON-Jobs zur Variablen PATH hinzugefügt wurden, können diese durch Verketten der Ausgabe aus parameter_exec in processing_exec ausgeführt werden. Die Ausgabe kann anschließend an eine Ausgabeprotokolldatei übertragen werden.
Syntax
parameter_exec | processing_exec > output.log
Das Zeichen "|" ist das Verkettungszeichen von z/OS UNIX.
Beispiel für den Aufruf
Wenn Sie die angegebenen Musternamen verwenden, kann die CRON-Erstellungs-Exec wie folgt aufgerufen werden ($ ist die z/OS UNIX-Eingabeaufforderung):
$ BWBCRONB | BWBCRON1 > $HOME/bwbcronb.log 30 19 * * 1-5 BWBCRONB | BWBCRON1 > /u/userid/bwbcronb.log ;
Weitere Informationen zu den verfügbaren CRON-Services und dem Format CRONTAB finden Sie in den Dokumenten UNIX System Services Command Reference (IBM FORM SA22-7802-11) und UNIX System Services Planning (IBM FORM GA22-7800-16).
Alternativ können Sie den Online-z/OS UNIX-Befehl man verwenden:
In diesem Abschnitt werden die Jobmuster BWBCRON1, BWBCRONB, BWBCRONP angezeigt, die in der SFEKSAMV-Bibliothek bereitgestellt werden.
Das folgende Beispiel zeigt den BWBCRON1-Code.
/* REXX */ /* Customize STEPLIB, _SCLMDT_CONF_HOME and _SCLMDT_WORK_HOME */ /* The STEPLIB should reflect the load libraries for Rational Developer for System z. If these datasets resides in the LINKLIST then set STEPLIB to '' . */ STEPLIB = 'FEK.SFEKLOAD:FEK.SFEKAUTH' /* The Environment variables _SCLMDT_CONF_HOME and _SCLMDT_WORK_HOME determines the HOME directories where the configuration files and workarea reside for SCLM Developer Toolkit. Refer to the Rational Developer for System z configuration file /etc/rdz/rsed.envvars for the correct value. */ _SCLMDT_CONF_HOME = '/etc/rdz/sclmdt' _SCLMDT_WORK_HOME = '/var/rdz' /* SAMPLE USEAGE */ COMMAND : BWBCRONB|BWBCRON1 > BWBCRONB.log (passes build parameter list to BWBCRON1 & outputs to BWBCRONB.log) */ /* DO NOT ALTER BELOW */ CALL ENVIRONMENT 'STEPLIB',STEPLIB CALL ENVIRONMENT '_SCLMDT_CONF_HOME',_SCLMDT_CONF_HOME CALL ENVIRONMENT '_SCLMDT_WORK_HOME',_SCLMDT_WORK_HOME CALL BWBINT EXIT
Das folgende Beispiel zeigt den BWBCRONB-Code.
/* REXX */ /* SAMPLE BUILD PARAMETER FILE USED FOR CRON INITIATED BUILDS */ /* Update Build parameters below */ /* if parameter required as Blank then set as '' */ FUNCTION = 'BUILD' PROJECT = '' /* SCLM Project */ PROJDEF = '' /* Alt proj definition */ TYPE = '' /* SCLM Type */ MEMBER = '' /* SCLM Member name */ GROUP = '' /* SCLM Group */ GROUPBLD = '' /* Build at Group */ REPDGRP = '' /* Users Development group */ BLDREPT = 'Y' /* Generate Build report */ BLDLIST = 'Y' /* Generate List on error */ BLDMSG = 'Y' /* Generate Build Messages */ BLDSCOPE = 'N' /* Build Scope E/L/N/S */ BLDMODE = 'C' /* Build Mode C/F/R/U */ BLDMSGDS = '' /* Message dataset */ BLDRPTDS = '' /* Report dataset */ BLDLSTDS = '' /* list dataset */ BLDEXTDS = '' /* Exit dataset */ SUBMIT = 'BATCH' /* Online or Batch */ /* IF running in BATCH and require a JCL JOBCARD to override the default then add up to 4 lines of JOBCARD lines. Specify in the format of LINE. and include LINECNT variable for number of lines. */ LINECNT = 2 LINE.1 = '//SCLMBLD JOB (XXX),SCLMBUILD,MSGCLASS=X,NOTIFY=&SYSUID,' LINE.2 = '// CLASS=A,REGION=0M' /* DO NOT ALTER PARM BUILD VARIABLE BELOW */ PARM1 = 'SCLMFUNC='FUNCTION'&PROJECT='PROJECT'&PROJDEF='PROJDEF||, '&TYPE='TYPE'&MEMBER='MEMBER'&GROUP='GROUP'&GROUPBLD='GROUPBLD||, '&REPDGRP='REPDGRP'&BLDREPT='BLDREPT'&BLDLIST='BLDLIST||, '&BLDMSG='BLDMSG'&BLDSCOPE='BLDSCOPE'&BLDMODE='BLDMODE||, '&BLDMSGDS='BLDMSGDS'&BLDRPTDS='BLDRPTDS'&BLDLSTDS='BLDLSTDS||, '&BLDEXTDS='BLDEXTDS'&SUBMIT='SUBMIT /* outputs parameter string as input to BWBCRON1 */ SAY PARM1 If (SUBMIT = 'BATCH') & (LINECNT > 0) then Do SAY '<JOBCARD>' Do i = 1 to LINECNT SAY LINE.i End SAY '</JOBCARD>' End
Das folgende Beispiel zeigt den BWBCRONP-Code.
/* SAMPLE PROMOTE PARAMETER FILE USED FOR CRON INITIATED PROMOTES */ /* Update Promote parms below in quotes. */ /* if parameter required as Blank then set as '' */ FUNCTION = 'PROMOTE' PROJECT = '' /* SCLM Project */ PROJDEF = '' /* Alt proj definition(opt) */ TYPE = '' /* SCLM Type */ MEMBER = '' /* SCLM Member name */ GROUP = '' /* SCLM Group */ GROUPPRM = '' /* Promote at Group (opt) */ REPDGRP = '' /* Users Development group */ PRMREPT = 'Y' /* Generate Promote report */ PRMMSG = 'Y' /* Generate Promote Messages*/ PRMSCOPE = 'N' /* Promote Scope E/L/N/S */ PRMMODE = 'C' /* Promote Mode C/F/R/U */ PRMMSGDS = '' /* Message dataset */ PRMRPTDS = '' /* Report dataset */ PRMEXTDS = '' /* Exit dataset */ SUBMIT = 'BATCH' /* Online or Batch */ /* IF running in BATCH and require a JCL JOBCARD to override the default then add up to 4 lines of JOBCARD lines. Specify in the format of LINE. and include LINECNT variable for number of lines. */ LINECNT = 2 LINE.1 = '//SCLMBLD JOB (XXX),SCLMBUILD,MSGCLASS=X,NOTIFY=&SYSUID,' LINE.2 = '// CLASS=A,REGION=0M' /* DO NOT ALTER PARM PROMOTE VARIABLE BELOW */ PARM1 = 'SCLMFUNC='FUNCTION'&PROJECT='PROJECT'&PROJDEF='PROJDEF||, '&TYPE='TYPE'&MEMBER='MEMBER'&GROUP='GROUP'&GROUPPRM='GROUPPRM||, '&REPDGRP='REPDGRP'&PRMREPT='PRMREPT||, '&PRMMSG='PRMMSG'&PRMSCOPE='PRMSCOPE'&PRMMODE='PRMMODE||, '&PRMMSGDS='PRMMSGDS'&PRMRPTDS='PRMRPTDS'&PRMEXTDS='PRMEXTDS||, '&SUBMIT='SUBMIT /* outputs parameter string as input to BWBCRON1 */ SAY PARM1 If (SUBMIT = 'BATCH') & (LINECNT > 0) then Do SAY '<JOBCARD>' Do i = 1 to LINECNT SAY LINE.i End SAY '</JOBCARD>' End
SCLM Developer Toolkit, eine Funktion von IBM Rational Developer for System z, bietet eine Möglichkeit, mit der verteilte Anwendungen, die in Eclipse geschrieben sind, mit Software Configuration and Library Manager (SCLM) verwaltet und erstellt werden können. Dies ist das Managementsystem für IBM z/OS-Quellcode.
Die Sprache und Tools, die von verteilten und Mainframe-Benutzern verwendet werden, unterscheiden sich ebenso wie die verwendeten Umgebungen. Durch Kenntnis der entscheidenden Konzepte beider Umgebungen ist es möglich, diese erfolgreich in einer kohäsiven Struktur zu integrieren.
Im Hinblick auf die Anwendungsstruktur besteht SCLM Developer Toolkit aus einer Serie von Eclipse-Plugins mit entsprechendem z/OS-Host-Code, der die Verwendung von HTTP- und RSE-Transporten ermöglicht. Für den Betrieb registriert der Eclipse-Entwickler ein Arbeitsbereichsprojekt in SCLM. Die Dateien im Projekt können zu einem SCLM-Projekt hinzugefügt werden, ein- und ausgecheckt und optional erstellt und implementiert werden. Alle dieses Services werden über das Team-Aktionsmenü gesteuert. Aus Sicht des SCLM-Administrators können Projekte, Typen, Sprachen und zugeordnete erstellte Umsetzer erstellt werden. Die Funktionen, wie Änderungs- und Berechtigungscodes, sind abhängig von den Anforderungen.
Aus dem Blickwinkel eines Java/J2EE-Entwicklers sind folgende Konzepte zur Beschreibung von SCLM hilfreich:
Das z/OS-Dateisystem unterstützt nur Dateinamenlängen von acht Zeichen. Die Schnittstelle von SCLM Developer Toolkit bietet einen Umsetzungsservice, der die Unterstützung von normalen Java-Langnamenskonventionen ermöglicht. Bestimmte SCLM-Dateien müssen den Einschränkungen für die Benennung entsprechen. Diese beziehen sich vor allem auf die in J2EE ARCHDEF-Format beschriebene ARCHDEF-Struktur.
Jede Datei (in der SCLM-Terminologie als "Member" bezeichnet), die in einem SCLM-Projekt gespeichert wird, wird in einer Dateigruppe gespeichert. Die Dateigruppe, in der die Datei gespeichert ist, wird durch den SCLM-Typ identifiziert. Der Typ ist Teil des Dateinamens. In Bezug auf SCLM hat der Name das Format SCLM-Projekt.Gruppe.Typ mit einer zugewiesenen Sprache. In einem SCLM-Projekt können zahlreiche Typen definiert werden. Mithilfe dieser Typen können zwei Dateien mit demselben Namen innerhalb desselben SCLM-Projekts gespeichert werden. Jedes Projekt kann zahlreiche Typen enthalten. Durch die Verwendung von Typen ist es möglich, mehrere Eclipse-Projekte in einem SCLM-Projekt zu speichern, auch wenn jedes IDE-Projekt möglicherweise Dateien mit der Bezeichnung ".project" und ".classpath" enthält. Wenn diese Dateien nicht durch die Verwendung von Typen unterschieden werden, wird nur eine Kopie der Dateien in SCLM gespeichert.
Der SCLM-Administrator ist verantwortlich für die Definition der SCLM-Typen. Wenn Sie ein Projekt in SCLM gemeinsam nutzen, muss Ihnen bekannt sein, welchen Typ Sie beim Speichern der Objekte in SCLM verwenden müssen.
Wenn Sie eine Datei zu SCLM hinzufügen, müssen Sie diese mit einer bestimmten Sprachdefinition speichern. Auch hier ist der SCLM-Administrator verantwortlich für die Definition der Sprachen. Diese Definition steuert das Verhalten von SCLM, wenn Dateien in und aus dem Hostsystem übertragen werden. Durch Verwendung der Sprachdefinition ist es möglich, zu definieren, ob ein bestimmter Dateityp aus einem ausgeschriebenen Namen umgesetzt wird, als binäres Objekt gespeichert wird oder in ASCII oder EBCDIC umgesetzt wird (native z/OS-Codierung). Eine Sprachedefinition des Typs JAVABIN kann z. B. zu einem Binärobjekt mit einem umgesetzten Langnamen gehören. Alternativ kann WEBHTML so definiert werden, dass eine Textdatei mit umgesetztem Langnamen repräsentiert wird, die in ASCII gespeichert wird. Die Zahl der Sprachdefinitionen wird objektweise definiert. Es muss bekannt sein, welche Sprache verwendet werden soll, um sicherzustellen, dass die Datei gespeichert wird und ordnungsgemäß aus SCLM abgerufen werden kann. Die Sprache definiert auch, wie SCLM ein Objekt erstellt.
Jeder Datei, die durch SCLM gesteuert wird, ist eine bestimmte Zahl von Eigenschaften zugeordnet. Diese Eigenschaften werden für die Zuordnung zwischen der IDE-Datei und den entsprechenden SCLM-Eigenschaften verwendet. Wenn ein Serviceaufruf an SCLM gerichtet wird, werden diese Daten gelesen, um die entsprechenden Serviceparameter zu formulieren. Sie können diese im Eigenschaftenmenü anzeigen, wenn Sie ein durch SCLM gesteuertes Member aus Eclipse markieren.
Wenn Sie ein Projekt in SCLM gemeinsam nutzen, müssen Sie auch angeben, welcher Entwicklungsgruppe Sie angehören. SCLM-Projektstrukturen sind hierarchisch aufgebaut.
Der Code wird zunächst auf DEVELOPMENT-Ebene gespeichert. Nachdem dieser erfolgreich erstellt und getestet wurde, kann der Code auf die TEST-Ebene hochgestuft werden. Nach erfolgreichen Tests kann der Code anschließend auf die PRODUCTION-Ebene hochgestuft werden. Dabei handelt es sich im Allgemeinen um das entwickelte Produkt. Wenn ein Fehler im Code auf Produktionsebene gefunden wird, werden die entsprechenden Dateien, die bearbeitet werden müssen, um den Fehler zu beheben, in die Entwicklungsebene herunterkopiert und der Erstellungsprozess wird erneut gestartet. Der Code, aus dem die Anwendung besteht, wird nicht in die Entwicklungsebene herunterkopiert. SCLM verfolgt die Elemente, die den Build bilden, sowie die Ebene, auf der diese gespeichert sind.
Innerhalb der Entwicklungsebene können mehrere Gruppen vorhanden sein. Dadurch kann Code, der auf der Entwicklungsebene gespeichert wird, getrennt verwaltet werden. SCLM bietet außerdem Steuerelemente, die das Verhalten von Codes, die in verschiedenen Entwicklungsgruppen gespeichert sind, im Hinblick auf die Umstufungsmöglichkeiten bestimmen.
Die Struktur eines IDE-Projekts besteht im Allgemeinen aus mindestens einem IDE-Projekt. Durch die Speicherung jedes IDE-Projekts in einem anderen SCLM-Typ wird diese Struktur erhalten. Die ARCHDEF-Datei definiert dann die Dateien, aus denen ein IDE-Projekt besteht. Jedes SCLM-Projekt kann mehrere ARCHDEFs haben. Es ist möglich, dass eine ARCHDEF andere ARCHDEFs referenziert. Daher kann eine Struktur mit mehreren IDE-Projekten für den Erstellungsprozess definiert werden. Die ARCHDEF ist dabei die wichtigste Methode für die Definition einer Erstellungsliste für SCLM. Dies lässt sich am ehesten mit einem make-Prozess vergleichen. Die ARCHDEF listet die Dateien auf, die den Build bilden, und gibt ein Erstellungsscript an, mit dem Sie die Speicherposition von externen JARs oder Klassen angeben können. Weitere Informationen hierzu finden Sie im Bereich "Benutzerhandbuch" des Onlinehilfesystems.
Wenn ein IDE-Projekt im Arbeitsbereich erstellt wird, wird automatisch eine Beschreibungsdatei generiert und unter dem Namen .project gespeichert. Dieses XML-Dokument enthält Beschreibungen sämtlicher Builder und Spezifiken, die dem Projekt zugeordnet sind."Builder" sind Programme zur inkrementellen Projekterstellung, die abhängig vom Projektinhalt einen bestimmten Buildstatus erstellen. Wenn sich der Inhalt des Projekts ändert, wird diese Datei aktualisiert."Spezifiken" definieren und verwalten die Zuordnung zwischen einem angegebenen Projekt und einem bestimmten Plug-in oder einer Komponente.
Die .classpath-Datei beschreibt den Pfad, der zum Auffinden externer JARs und Klassen verwendet wird, die durch den Quellcode in Ihrem IDE-Projekt referenziert werden. Die funktional entsprechende Funktion während einer Erstellung durch SCLM Developer wird mit der Anweisung CLASSPATH_JARS in den Ant-Erstellungsscripts definiert. Diese Anweisung beschreibt den Pfad auf dem z/OS-Host, der zum Auffinden von externen JARs und Klassen verwendet wird, die durch den Quellcode in Ihrem IDE-Projekt referenziert werden.
Sowohl .classpath als auch .project werden verwendet, um Ihre IDE-Projektkonfiguration beizubehalten, damit diese in einem anderen Arbeitsbereich neu erstellt werden kann. Aus diesem Grund wird empfohlen, dass beide als Teil des IDE-Projekts in SCLM eingecheckt werden.
Ein wichtiger Aspekt bei der Projektentwicklung, insbesondere bei J2EE-Projekten, sind die verschiedenen ausführbaren Anwendungsdateien, die erstellt werden können. Ausführbare Java-Projektdateien werden häufig als JAR-, WAR-, RAR- oder EAR-Dateien paketiert.
JAR-Dateien beziehen sich üblicherweise auf Standard-Java-Anwendungen oder Enterprise Java Beans (EJB).
WAR-Dateien werden für Webanwendungen erstellt. Üblicherweise setzen sich diese aus Java-Servlets, JSPs und HTML-Dateien zusammen. WAR-Anwendungen stellen oft das Front-End von webbasierten Anwendungen dar. Diese Anwendungen können sich auf andere JAR-Dateien beziehen, z. B. EJB-Dateien für bestimmte Services. Jede WAR-Datei enthält eine Datei web.xml. Diese beschreibt die Zusammensetzung der WAR-Anwendung im Hinblick auf Java, HTML und die verwendeten Bibliotheksservices.
Die Entwicklung von RAR-Dateien wird derzeit nicht in SCLM Developer Toolkit unterstützt.
EAR-Dateien repräsentieren Unternehmensanwendungen. Diese Anwendungen setzen sich aus JAR- und WAR-Dateien zusammen. In J2EE-Sprache ist die Erstellung der EAR-Datei die Assemblierung der konstituierenden JAR- und WAR-Dateien. Diese Assemblierungsmethode ermöglicht die Erstellung von EAR-Anwendungen, die sich effektiv aus bestimmten Komponenten zusammensetzen (JAR/WAR). Die tatsächliche Zusammensetzung der Anwendung wird in der Datei "application.xml" beschrieben. Die EAR-Datei selbst ist kein eigenständiges ausführbares Objekt. Die EAR-Datei muss in einem J2EE-Container wie Websphere Application Server (WAS) installiert werden. Die Installation der EAR-Datei wird als "Implementierung" bezeichnet. Eine implementierte EAR-Anwendung kann über die WAS-Umgebung aufgerufen werden. Der Prozess der Implementierung ist ein separater Vorgang, der unabhängig vom Erstellungsprozess ausgeführt wird. Die Implementierung beinhaltet die physische Installation der EAR-Anwendung.
Für die Entwicklung von J2EE-Anwendungen kann daher die Entwicklung mehrerer separater Komponenten wie WAR- und JAR-Dateien erforderlich sein. Diese Dateien werden gemeinsam in einer EAR-Datei assembliert. Die EAR-Datei kann dann in einem J2EE-Container (z. B. WAS) für die Verwendung implementiert werden.
Im Eclipse-Arbeitsbereich liegen die Projekte nah beieinander, d. h. sie können in der IDE-Umgebung hinsichtlich der Paketierung auf andere IDE-Projekte verweisen. In SCLM muss jedes dieser IDE-Projekte (z. B. WAR-, JAR- und EAR-Projekte) einem einzelnen SCLM-Projekt zugewiesen werden, wobei die Projekte durch die Verwendung verschiedener SCLM-Typen unterschieden werden. Der Grund hierfür ist, dass es allgemeine Dateinamen gibt, die in vielen IDE-Projekten verwendet werden, z. B. ".project", ".classpath", "web.xml" und "application.xml". Durch die Verwendung unterschiedlicher Typen können mehrere Teile mit demselben Namen innerhalb eines SCLM-Projekts vorhanden sein. Weitere Informationen zur Zuordnung finden Sie unter J2EE-Projekte SCLM zuordnen.
Aus der SCLM-Perspektive lässt sich die Entwicklung der EAR-Anwendung am besten durch die Verwendung einer ARCHDEF-Struktur mit mehreren Ebenen darstellen. In SCLM bilden die übergeordneten ARCHDEFs, in vielen SCLM-Projekten als Paket bezeichnet, den Scheitelpunkt der ARCHDEF-Struktur, gefolgt von der EAR-Anwendung und Referenzen auf niedrigerer Ebene (WAR- und JAR-Dateien), aus denen die EAR-Anwendung besteht. Diese Struktur ermöglicht die Verwendung von Builds auf hoher und niedriger Ebene sowie die Verwendung von vollständigen oder bedingten Builds. Die ARCHDEFs bieten somit eine Möglichkeit, mit der es auch möglich ist, die J2EE-Projektelemente innerhalb des SCLM-Projekts zu definieren.
Derzeit unterstützt der zentrale Bestandteil von SCLM keine Speicherung von Codes mit Datei- bzw. Membernamen, die länger als acht Zeichen sind.
Codes, z. B. Java- und andere PC-Client-Codes, haben üblicherweise viel längere Namen und enthalten auch Pfadinformationen (Paketierung) als Teil des Namens. Codes mit benannten Teilen, die länger als acht Zeichen sind, müssen daher mit einem Dienstprogramm für die Umsetzung von Lang- in Kurznamen bearbeitet werden, damit diese Teile in SCLM mit einer Namenslänge von höchtens acht Zeichen gespeichert werden können.
In einer Tabelle für die Umsetzung von ausgeschriebenen Namen in Kurznamen werden die ausgeschriebenen Namen (echten Namen) und die entsprechenden Kurznamen (wie in SCLM gespeichert) erfasst. Diese Tabellen werden über SCLM gespeichert und aufgerufen und in einem VSAM-Datensatz gespeichert. Diese Funktionalität wurde in SCLM mit der vorläufigen Programmkorrektur für APAR OA11426 für z/OS 1.4 und höher eingeführt. Für z/OS 1.8 und höher wird diese vorläufige Programmkorrektur nicht benötigt.
Der Konvertierungsalgorithmus führt folgende Schritte aus:
Beispiel
Ausgeschriebener Name | Kurzname in SCLM PDS oder PDSE |
---|---|
com/ibm/workbench/testprogram.java | TE000001 |
source/plugins/Phantom/.classpath | XX000001 |
Das SCLM-Programm FLMLSTRN wurde zum Lesen und Aktualisieren der VSAM-Umsetztabelle erstellt. SCLM Developer Toolkit verwendet dieses Programm zum Lesen und Aktualisieren von korrelierenden Lang- und Kurznamen.
Die VSAM-Datei, die zum Speichern der Umsetztabelle verwendet wird, ist eine Datei in Schlüsselfolge mit variabler Länge mit einem definierten Alternativindex und -pfad. Ein Musterjob wird in SCLM bereitgestellt, um diese VSAM-Datei zuzuordnen.
Die interne Struktur des VSAM-Clusters ist wie folgt gestaltet:
1 ls_record, 3 ls_short_name char(08), 3 ls_lngname_key char(50), 3 ls_long_name char(1024);
Eine Muster-Jobsteuersprache für die Zuordnung der VSAM-Datei für die Umsetzung von Lang-/Kurznamen sehen Sie in Schritt 6: Konfigurieren der VSAM-Datei für Lang-/Kurznamentabellen.
Das Programm FLMLSTRN wird mit dem ISPF-SELECT-Service mit einem der in Tabelle 12 aufgelisteten Parameter aufgerufen.
Syntax:
"SELECT PGM(FLMLSTRN) PARM(keyword)"
Beispiel für Aufruf:
"SELECT PGM(FLMLSTRN) PARM(TRANSLATE)"
Schlüsselwortdatensatz | Verarbeitung | Beschreibung |
---|---|---|
FINDLONG | Einzeln | Findet einen ausgeschriebenen Namen für einen bestimmten Kurznamen |
FINDSHORT | Einzeln | Findet einen Kurznamen für einen bestimmten ausgeschriebenen Namen |
TRANSLATE | Einzeln | Findet einen Kurznamen, falls vorhanden, oder ordnet einen neuen Kurznamen zu, falls keiner vorhanden ist |
MIGRATE | Mehrfach | Sucht nach mehreren ausgeschriebenen Namen |
IMPORT | Mehrfach | Sucht nach mehreren Kurznamen |
Die Verarbeitung erfolgt in gleicher Weise wie bei FINDSHORT, und zwar folgendermaßen:
Die Funktionen MIGRATE und IMPORT wurden eingeführt, um das Leistungsverhalten bei einer großen Zahl von umzusetzenden Langnamen (MIGRATE) bzw. bei einer großen Zahl von durchsuchten Kurznamen (IMPORT) zu verbessern.
Beide Funktionen, MIGRATE und IMPORT, lesen eine durch Variablen blockierte sequenzielle Datei mit LRECL=1036, die als DD LSTRNPRC zugeordnet wird.
Vor dem Aufruf enthält diese Datei abhängig von der aufgerufenen Funktion Kurznamen oder ausgeschriebene Namen in den entsprechenden Formaten und Spalten.
Nach dem Aufruf enthält LSTRNPRC sowohl den Kurznamen als auch den korrelierenden ausgeschriebenen Namen.
Die Datei hat folgendes Format:
1 pr_record, 3 pr_short_name char(08), 3 pr_long_name char(1024);
Das folgende Beispiel zeigt einen Muster-REXX-Code für den Aufruf des Umsetzungsprozesses für Lang-/Kurznamen.
/* REXX **************************************************************/ /* Sample to translate long name to a short name */ /*********************************************************************/ Address TSO "FREE FI(LSTRANS)" "FREE FI(LSTRNPTH)" "ALLOC DD(LSTRANS) DA('FEK.#CUST.LSTRANS.FILE') SHR REUSE" "ALLOC DD(LSTRNPTH) DA('FEK.#CUST.LSTRANS.FILE.PATH') SHR REUSE" /* Create short name for long name com/ibm/phantom.txt */ FLMLSLNG = "com/ibm/phantom.txt" Address ISPEXEC "VPUT (FLMLSLNG) PROFILE" Address ISPEXEC "SELECT PGM(FLMLSTRN) PARM(TRANSLATE)" LSRC=RC If LSRC > 0 Then Do Address ISPEXEC "VGET (FLMLSERR,FLMLSER1) PROFILE" Say "LS ERROR LINE 1 ==>" FLMLSERR Say "LS ERROR LINE 2 ==>" FLMLSER1 Return End Else Do Address ISPEXEC "VGET (FLMLSSHR,FLMLSLNG) PROFILE" Say " Shortname = " FLMLSSHR Say " Longname = " FLMLSLNG End Address TSO "FREE FI(LSTRANS)" "FREE FI(LSTRNPTH)"
In diesem Anhang wird die Anwendungsprogrammierschnittstelle (API) für die Host-Services von SCLM Developer Toolkit erläutert. Die API verwendet ein XML-basiertes Anforderungs- und Antwortformat und muss über z/OS UNIX Systems Services aufgerufen werden.
Mit der API können Benutzer die Host-Services von SCLM Developer Toolkit mit ihrem eigenen Client/Plugin und ihrer eigenen Transportschicht verwenden, falls gewünscht.
Ein Muster-Java-Programm (mit Eingabe und Ausgabe) wird bereitgestellt. Dabei wird die SCLMDT-Host-Services-API mit einem HTTP-Server als Transportmechanismus aufgerufen.
Viele der Funktionsanforderungen basieren auf den aktuellen SCLM-Host-Services. Weitere Informationen zu ähnlichen Parametereinstellungen für allgemeine Funktionen finden Sie im SCLM-Handbuch sowie in der Dokumentation für das relevante z/OS-Release.
Der folgende Musterbefehl veranschaulicht, wie die SCLMDT-Host-Services aufgerufen werden können:
cat sclmdt_request.xml | BWBXML > sclmdt_response.xml
cat | z/OS UNIX-Befehl zum Anzeigen von Textdateien |
sclmdt_request.xml | Die XML-Eingabedatei mit der Benutzeranforderung |
| | z/OS UNIX-Befehl zum Umleiten der Ausgabe des vorherigen Befehls über eine Pipe als Eingabe für den nächsten Befehl |
BWBXML | Das XML-Konvertierungsscript, das im Verzeichnis /bin von Developer for System z gespeichert ist und die SCLMDT-Serviceschnittstelle aufruft |
> | z/OS UNIX-Befehl zum Umleiten der Ausgabe des vorherigen Befehls in eine Datei |
sclmdt_response.xml | Die XML-Ausgabedatei, die die Serviceantwort enthält |
export PATH=/usr/lpp/rdz/bin:$PATH
Das folgende Beispiel zeigt das XML-Schema für SCLMDT-Befehle, die in der XML-Eingabedatei referenziert werden. Dieses Muster ist auch als Member BWBXSD1 in der Musterbibliothek FEK.SFEKSAMV verfügbar.
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"> <xs:element name="SCLMDT-INPUT"> <xs:complexType> <xs:all> <xs:element name="SERVICE-REQUEST"> <xs:complexType> <xs:all> <xs:element name="service"> <xs:simpleType> <xs:restriction base="xs:string"> <!-- Specifies native TSO or ISPF service call --> <xs:enumeration value="ISPF"/> <xs:enumeration value="TSO"/> <xs:enumeration value="SCLM"/> </xs:restriction> </xs:simpleType> </xs:element> <xs:element name="session" minOccurs="0"> <xs:simpleType> <xs:restriction base="xs:string"> <!-- Default NONE : Session terminates after service call --> <xs:enumeration value="NONE"/> <!-- Reuseable ISPF session stays active between calls --> <xs:enumeration value="REUSE"/> </xs:restriction> </xs:simpleType> </xs:element> <!-- Use existing ISPF profile in call --> <xs:element name="ispprof" type="xs:string" minOccurs="0"/> <!-- Free form TSO/ISPF command --> <xs:element name="command" type="xs:string" minOccurs="0"/> <!-- List of all SCLM DT functions available --> <!-- sclmfunc : SCLM function selected --> <xs:element name="sclmfunc" minOccurs="0"> <xs:simpleType> <xs:restriction base="xs:string"> <!-- Build parms : project,projdef,group,repdgrp,type,member,bldmode,bldlist, bldrept,bldmsg,bldmsgds,bldlist,bldlstds,bldextds,groupbld,submit --> <xs:enumeration value="PROMOTE"/> <!-- SCLM promote function --> <!-- Promote parms : project,projdef,group,repdgrp,type,member,prmmode,prmrept, prmmsg,prmsgds,prmextds,groupprm,submit -->
<xs:enumeration value="EDIT"/> <!-- EDIT member --> <!-- Edit parms : project,projdef,group,repdgrp,type,member,lang --> <!-- Note: member transferred to DTinstall/WORKAREA --> <xs:enumeration value="BROWSE"/> <!-- Browse member --> <!-- Browse parms : project,projdef,group,repdgrp,type,member,lang --> <!-- Note: member transferred to DTinstall/WORKAREA --> <xs:enumeration value="SAVE"/> <!-- Save edited member --> <!-- Save parms : project,projdef,group,repdgrp,type,member,lang --> <!-- Note: member received from DTinstall/WORKAREA --> <xs:enumeration value="DELETE"/> <!-- SCLM delete member --> <!-- Delete parms : project,projdef,group,repdgrp,type,member,delflag --> <xs:enumeration value="UNLOCK"/> <!-- SCLM unlock member --> <!-- Unlock parms : project,projdef,group,repdgrp,type,member --> <xs:enumeration value="DEPLOY"/> <!-- J2EE deploy function --> <!-- Deploy parms : project,projdef,group,repdgrp,type,member, depmode,depsec,groupdpy --> <xs:enumeration value="REPORT"/> <!-- SCLM project list --> <!-- Report parms : project,projdef,reptype,repdgrp,repccode,replang, repacode,repmem,repgrp,repmode,repbmap --> <xs:enumeration value="MIGDSN"/> <!-- List non-sclm datasets & members --> <!-- Migdsn parms : project,projdef,groupdev,migmem,migdsn --> <xs:enumeration value="MIGPDS"/> <!-- Migrate NON-SCLM datasets to SCLM --> <!-- Migpds parms : project,projdef,group,type,migfile,migmode, authcode,ccode,migonly --> <xs:enumeration value="INFO"/> <!-- SCLM member status information --> <!-- Info parms : project,projdef,group,repdgrp,type,member,lang --> <xs:enumeration value="UPDATE"/> <!-- update SCLM member information --> <!-- Update parms : project,projdef,group,repdgrp,type,member, lang,ccode,authcode --> <xs:enumeration value="AUTHUPD"/> <!-- Change SCLM member authcode --> <!-- Authupd parms : project,projdef,group,type,member,authcode --> <xs:enumeration value="VERLIST"/> <!-- SCLM list versions --> <!-- Verlist parms : project,projdef,group,repdgrp,type,member --> <xs:enumeration value="VERBROW"/> <!-- SCLM browse versions --> <!-- Verbrow parms : project,projdef,group,repdgrp,type,member --> <xs:enumeration value="VERREC"/> <!-- SCLM recover versions --> <!-- Verbrow parms : project,projdef,group,repdgrp,type,member --> <xs:enumeration value="VERDEL"/> <!-- SCLM delete versions --> <!-- Verdel parms : project,projdef,group,repdgrp,type,member -->
<xs:enumeration value="VERHIST"/> <!-- SCLM version history --> <!-- Verhist parms : project,projdef,group,repdgrp,type,member --> <xs:enumeration value="REPUTIL"/> <!-- SCLM DBUTIL report --> <!-- Reputil parms : project,projdef,group,repdgrp,type,member --> <xs:enumeration value="PROJGRPS"/> <!-- Retrieve SCLM groups for a project --> <!-- Projgrps parms : project,projdef --> <xs:enumeration value="J2EEMIG"/> <!-- Migrate project into SCLM --> <!-- J2eemig parms : project,projdef,group,type,member,lang,migmode, projarch,archtype,authcode,ccode,j2eetype,j2eesinc,J2eefile, sclmrefs,archac,archcc,submit --> <xs:enumeration value="J2EEMIGB"/> <!-- Batch migrate project into SCLM --> <!-- J2eemigb parms : project,projdef,group,type,member,lang,migmode, authcode,ccode --> <xs:enumeration value="J2EEIMP"/> <!-- Import SCLM project --> <!-- J2eeimp parms : project,projdef,group,repdgrp,type,member,repacode, repccode,replang,reparchm,reparcht,reparchg,replang --> <xs:enumeration value="PROJINFO"/> <!-- Retrieve SCLM project information --> <!-- Projinfo parms : project,projdef,repdgrp --> <xs:enumeration value="LRECL"/> <!-- Retrieve LRECL of SCLM dataset --> <!-- Reputil parms : project,projdef,group,repdgrp,type --> <xs:enumeration value="JOBSTAT"/> <!-- Retrieve status of batch job --> <!-- Jobstat parms : project, jobfunc,jobname,jobid --> <xs:enumeration value="JARCOPY"/> <!-- Copies SCLM JAR into cpath directory --> <!-- Jarcopy parms : project,projdef,group,repdgrp,type,classdir,jarname --> </xs:restriction> </xs:simpleType> </xs:element>
<!-- List of common function parameters --> <!-- project : SCLM project --> <xs:element name="project" type="xs:string" minOccurs="0"/> <!-- projdef : SCLM project definition --> <xs:element name="projdef" type="xs:string" minOccurs="0"/> <!-- group : SCLM group selected --> <xs:element name="group" type="xs:string" minOccurs="0"/> <!-- repdgrp : Users SCLM development group --> <xs:element name="repdgrp" type="xs:string" minOccurs="0"/> <!-- type : SCLM type --> <xs:element name="type" type="xs:string" minOccurs="0"/> <!-- member : SCLM member --> <xs:element name="member" type="xs:string" minOccurs="0"/> <!-- lang : SCLM language for the member --> <xs:element name="lang" type="xs:string" minOccurs="0"/> <!-- submit : submission type either online or batch --> <xs:element name="submit" type="xs:string" minOccurs="0"/> <!-- sclmfunc=build : additional parameter options --> <!-- bldscope : Build scope --> <xs:element name="bldscope" type="xs:string" minOccurs="0"/> <!-- bldmode : Build mode --> <xs:element name="bldmode" type="xs:string" minOccurs="0"/> <!-- bldlist : Translator listing only if error --> <xs:element name="bldlist" type="xs:string" minOccurs="0"/> <!-- bldrept : build report generated --> <xs:element name="bldrept" type="xs:string" minOccurs="0"/> <!-- bldmsg : build messages generated --> <xs:element name="bldmsg" type="xs:string" minOccurs="0"/> <!-- bldmsgds: build messages dataset name --> <xs:element name="bldmsgds" type="xs:string" minOccurs="0"/> <!-- bldrptds : build report dataset name --> <xs:element name="bldrptds" type="xs:string" minOccurs="0"/> <!-- bldlstds : build list dataset name --> <xs:element name="bldlstds" type="xs:string" minOccurs="0"/> <!-- bldextds : build exit dataset name --> <xs:element name="bldextds" type="xs:string" minOccurs="0"/> <!-- groupbld : SCLM group to build against --> <xs:element name="groupbld" type="xs:string" minOccurs="0"/>
<?xml version="1.0" encoding="ISO-8859-1" ?> <!-- sclmfunc=promote : additional parameter options --> <!-- prmscope : Promote scope --> <xs:element name="prmscope" type="xs:string" minOccurs="0"/> <!-- prmmode : Promote mode --> <xs:element name="prmmode" type="xs:string" minOccurs="0"/> <!-- prmrept : Promote report generated --> <xs:element name="prmrept" type="xs:string" minOccurs="0"/> <!-- prmmsg : Promote messages generated --> <xs:element name="prmmsg" type="xs:string" minOccurs="0"/> <!-- prmmsgds: Promote messages dataset name --> <xs:element name="prmmsgds" type="xs:string" minOccurs="0"/> <!-- prmrptds : Promote report dataset name --> <xs:element name="prmrptds" type="xs:string" minOccurs="0"/> <!-- prmextds : Promote exit dataset name --> <xs:element name="prmextds" type="xs:string" minOccurs="0"/> <!-- groupprm : SCLM group to promote from --> <xs:element name="groupprm" type="xs:string" minOccurs="0"/> <!-- sclmfunc=delete : additional parameter option --> <!-- delflag : either text|acct|txbm|bmap|all --> <xs:element name="delflag" type="xs:string" minOccurs="0"/> <!-- sclmfunc=deploy : additional parameter options --> <!-- depmode : If set to 'R' then deploy report only --> <xs:element name="depmode" type="xs:string" minOccurs="0"/> <!-- depsec : set to Y if using surrogate userids --> <xs:element name="depsec" type="xs:string" minOccurs="0"/> <!-- groupdpy : SCLM group deploying from --> <xs:element name="groupdpy" type="xs:string" minOccurs="0"/> <!-- sclmfunc=report : additional parameter options --> <!-- reptype : type|* - SCLM type to report on --> <xs:element name="reptype" type="xs:string" minOccurs="0"/> <!-- repmem : member|*|filter - SCLM member to report on --> <xs:element name="repmem" type="xs:string" minOccurs="0"/> <!-- replang : lang|* - SCLM language to filter with --> <xs:element name="replang" type="xs:string" minOccurs="0"/> <!-- repgrp : group|* - SCLM group to filter on --> <xs:element name="repgrp" type="xs:string" minOccurs="0"/> <!-- repccode : SCLM changecode to filter on --> <xs:element name="repccode" type="xs:string" minOccurs="0"/> <!-- repmode : D|E developer mode or explorer mode --> <xs:element name="repmode" type="xs:string" minOccurs="0"/> <!-- repbmap : If ON then report on build maps --> <xs:element name="repbmap" type="xs:string" minOccurs="0"/> </xs:all> </xs:complexType> </xs:element> </xs:all> </xs:complexType> </xs:element> </xs:schema>
Das folgende Beispiel zeigt die Grundstruktur der XML-Eingabedatei, wobei #function die aufgerufene Funktion repräsentiert und #parameter und #value einen Parameter und dessen Wert repräsentieren.
<?xml version="1.0"?> <SCLMDT-INPUT xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="sclmdt.xsd"> <SERVICE-REQUEST> <service>SCLM</service> <session>NONE</session> <sclmfunc>#function</sclmfunc> <#parameter>#value</#parameter> ... </SERVICE-REQUEST> </SCLMDT-INPUT>
Die folgende Liste enthält allgemeine Anmerkungen zu den Parametern und der Art und Weise, wie diese in der vorliegenden Veröffentlichung dokumentiert werden:
Diese Funktion ändert den Berechtigungscode eines Members.
>>-AUTHUPD--*----------*-GROUP-MEMBER-PROJECT-TYPE->< *-AUTHCODE-* *-PROJDEF--* *----<-----*
Erforderliche Parameter:
Optionale Parameter:
Diese Funktion kopiert ein Member aus SCLM in das z/OS UNIX-Verzeichnis WORKAREA/userid/EDIT/. Es wird keine Bearbeitungssperre in SCLM ausgeführt.
>>-BROWSE---*----------*-GROUP-MEMBER-PROJECT-TYPE->< *-PROJDEF--*
Erforderliche Parameter:
Optionale Parameter:
Diese Funktion weist SCLM an, Softwarekomponenten den Architekturdefinitionen für das Projekt entsprechend zu kompilieren, zu verlinken und zu integrieren.
>>-BUILD----*----------*-GROUP-GROUPBLD-MEMBER-PROJECT-REPDGRP-TYPE->< *-BLDEXTDS-* *-BLDLIST--* *-BLDLSTDS-* *-BLDMODE--* *-BLDMSGDS-* *-BLDREPT--* *-BLDRPTDS-* *-BLDSCOPE-* *-PROJDEF--* *-SUBMIT---* *----<-----*
Erforderliche Parameter:
Optionale Parameter:
Diese Funktion löscht ein SCLM-Member.
>>-DELETE---*----------*-GROUP-MEMBER-PROJECT-TYPE->< *-DELFLAG--* *-PROJDEF--* *----<-----*
Erforderliche Parameter:
Optionale Parameter:
Die DEPLOY-Funktion führt das Implementierungsscript aus, das durch das Member referenziert wird, um eine J2EE-Unternehmensarchivdatei (EAR) aus USS oder SCLM auf einem Websphere Application Server (WAS) zu implementieren. Weitere Informationen zum Erstellen eines Implementierungsscriptmembers finden Sie im Benutzerhandbuch zu SCLM Developer Toolkit.
>>-DEPLOY---*----------*-GROUP-MEMBER-PROJECT-TYPE->< *-DEPMODE--* *-DEPSEC---* *-GROUPDPY-* *-PROJDEF--* *-REPDGRP--* *----<-----*
Erforderliche Parameter:
Optionale Parameter:
Diese Funktion kopiert ein Member aus SCLM in das z/OS UNIX-Verzeichnis WORKAREA/userid/EDIT/. Außerdem wird eine SCLM-Sperre für das Member mit der Benutzer-ID als Zugriffsschlüssel erstellt.
>>-EDIT-----*----------*-GROUP-MEMBER-PROJECT-TYPE->< *-AUTHCODE-* *-PROJDEF--* *----<-----*
Erforderliche Parameter:
Optionale Parameter:
Diese Funktion stellt Informationen zum Status des SCLM-Members bereit.
>>-INFO-----*----------*-GROUP-MEMBER-PROJECT-TYPE->< *-LANG-----* *-PROJDEF--* *-REPDGRP--* *----<-----*
Erforderliche Parameter:
Optionale Parameter:
Diese Funktion importiert ein Projekt im JAR-Format (komprimiert) aus SCLM in das z/OS UNIX-Verzeichnis /var/rdz/WORKAREA/userid. Die JAR-Projektdatei kann anschließend auf den Client kopiert werden. Der Name der Projektdatei wird im Schlüsselwort J2EEFILE der (XML-)Funktionsausgabe zurückgegeben.
>>-J2EEIMP--*----------*-PROJECT-REPDGRP->< *-GROUP----* *-MEMBER---* *-PROJDEF--* *-REPACODE-* *-REPARCHG-* *-REPARCHM-* *-REPARCHT-* *-REPCCODE-* *-REPLANG--* *-TYPE-----* *----<-----*
Erforderliche Parameter:
Optionale Parameter:
Diese Funktion nimmt eine komprimierte Datei (JAR-Format) aus dem USS-Verzeichnis, extrahiert diese und migriert alle darin enthaltenen Member in SCLM, wobei ausgeschriebene Namen bei Bedarf in Kurznamen umgesetzt werden.
>>-J2EEMIG--*----------*-GROUP-J2EEFILE-LANG-MEMBER-PROJECT-TYPE->< *-ARCHAC---* *-ARCHCC---* *-ARCHTYPE-* *-AUTHCODE-* *-CCODE----* *-J2EESINC-* *-J2EETYPE-* *-MIGMODE--* *-PROJARCH-* *-PROJDEF--* *-SCLMREFS-* *-SUBMIT---* *----<-----*
Erforderliche Parameter:
Optionale Parameter:
Mit dieser Funktion wird der BATCH-Job für die Migration eingerichtet und ausgeführt.
>>-J2EEMIGB-*----------*-GROUP-LANG-MEMBER-PROJECT-TYPE->< *-ARCHTYPE-* *-AUTHCODE-* *-CCODE----* *-MIGMODE--* *-PROJARCH-* *-PROJDEF--* *----<-----*
Erforderliche Parameter:
Optionale Parameter:
Diese Funktion kopiert eine in SCLM gespeicherte JAR-Datei in ein z/OS UNIX-Verzeichnis, das als CLASSPATH-Verzeichnis verwendet werden kann.
>>-JARCOPY--*----------*-CLASSDIR-GROUP-JARNAME-PROJECT-REPDGRP-TYPE->< *-PROJDEF--*
Erforderliche Parameter:
Optionale Parameter:
Diese Funktion ruft den Status eines bestimmten Batch-Jobs ab.
>>-JOBSTAT--JOBFUNC-JOBID-JOBNAME-PROJECT-><
Parameter:
Diese Funktion ruft die Länge eines logischen Satzes einer SCLM-Dateigruppe ab.
>>-LRECL----*----------*-GROUP-PROJECT-REPDGRP-TYPE->< *-PROJDEF--*
Erforderliche Parameter:
Optionale Parameter:
Diese Funktion listet ausgewählte Dateigruppen und Member auf, die nicht in SCLM verwaltet werden (für anschließende Migration nach SCLM).
>>-MIGDSN---*----------*-MIGDSN-MIGMEM-PROJECT->< |__PROJDEF_|
Erforderliche Parameter:
Optionale Parameter:
Diese Funktion migriert ausgewählte Dateigruppen und Member, die nicht SCLM-verwaltet sind, in SCLM.
>>-MIGPDS---*----------*-GROUP-PROJECT-TYPE->< |_PROJDEF__|
Erforderliche Parameter:
Optionale Parameter:
Diese Funktion ruft die SCLM-Gruppen für ein ausgewähltes Projekt ab.
>>-PROJGRPS-*----------*-PROJECT->< *-PROJDEF--*
Erforderliche Parameter:
Optionale Parameter:
Diese Funktion ruft die SCLM-Projektinformationen für ein ausgewähltes Projekt ab.
>>-PROJINFO-*----------*--PROJECT-REPDGRP->< *-PROJDEF--*
Erforderliche Parameter:
Optionale Parameter:
Diese Funktion stuft ein SCLM-Member (oder eine Archdef) in der SCLM-Gruppenhierarchie hoch, entsprechend der Architekturdefinition des Projekts und der Projektdefinition.
>>-PROMOTE--*----------*-GROUP-GROUPPRM-MEMBER-PROJECT-REPDGRP-TYPE->< *-PRMEXTDS-* *-PRMMODE--* *-PRMMSG---* *-PRMMSGDS-* *-PRMREPT--* *-PRMRPTDS-* *-PRMSCOPE-* *-PROJDEF--* *-SUBMIT---* *----<-----*
Erforderliche Parameter:
Optionale Parameter:
Die Funktion zur Berichterstellung stellt einen DBUTIL-Hierarchiebericht für das Projekt bereit, entsprechend den verwendetetn Berichtparametern und Filtern.
>>-REPORT---*----------*-PROJECT-REPDGRP-REPGRP-REPMEM-REPTYPE->< *-PROJDEF--* *-REPACODE-* *-REPBMAP--* *-REPCCODE-* *-REPLANG--* *-REPMODE--* *----<-----*
Erforderliche Parameter:
Optionale Parameter:
Der DBUTIL-Service ruft Informationen aus der Projektdatenbank ab und erstellt eine angepasste Ausgabe sowie einen Bericht. Dieser beschreibt den Inhalt der Projektdatenbank basierend auf den Auswahlkriterien, die Sie angeben.
>>-REPUTIL--*----------*-GROUP-MEMBER-PROJECT-REPDGRP-TYPE->< *-PROJDEF--*
Erforderliche Parameter:
Optionale Parameter:
Diese Funktion kopiert ein Member aus dem Verzeichnis WORKAREA/userid/EDIT/ in die Entwicklungsgruppe eines Benutzers in SCLM. Ein neues Member wird erstellt, wenn das Member nicht in der SCLM-Projekthierarchie vorhanden ist.
>>-SAVE-----*----------*-GROUP-MEMBER-PROJECT-TYPE->< *-PROJDEF--*
Erforderliche Parameter:
Optionale Parameter:
Diese Funktion gibt ein SCLM-Member frei, das mit der EDIT-Funktion gesperrt wurde.
>>-UNLOCK---*----------*-GROUP-MEMBER-PROJECT-TYPE->< *-PROJDEF--* *-REPDGRP--* *----<-----*
Erforderliche Parameter:
Optionale Parameter:
Diese Funktion aktualisiert die Memberinformationen in SCLM.
>>-UPDATE---*----------*-GROUP-MEMBER-PROJECT-TYPE->< *-AUTHCODE-* *-CCODE----* *-LANG-----* *-PROJDEF--* *-REPDGRP--* *----<-----*
Erforderliche Parameter:
Optionale Parameter:
Diese Funktion zeigt eine Version eines Members aus der Dateigruppe der Versionen an.
>>-VERBROW--*----------*-GROUP-MEMBER-PROJECT-REPDGRP-TYPE->< *-PROJDEF--*
Erforderliche Parameter:
Optionale Parameter:
Diese Funktion löscht die Informationen über ein versionsgesteuertes oder geprüftes Member aus SCLM.
>>-VERDEL---*----------*-GROUP-MEMBER-PROJECT-REPDGRP-TYPE->< *-PROJDEF--*
Diese Funktion löscht alle älteren Versionen eines Members in SCLM.
Erforderliche Parameter:
Optionale Parameter:
Diese Funktion zeigt das Versionsprotokoll einer ausgewählten Memberversion in SCLM.
>>-VERHIST--*----------*-GROUP-MEMBER-PROJECT-REPDGRP-TYPE->< *-PROJDEF--*
Erforderliche Parameter:
Optionale Parameter:
Diese Funktion listet die verschiedenen Versionen für ein bestimmtes Member auf.
>>-VERLIST--*----------*-GROUP-MEMBER-PROJECT-REPDGRP-TYPE->< *-PROJDEF--*
Erforderliche Parameter:
Optionale Parameter:
Diese Funktion stellt eine ausgewählte Version eines Members in der Entwicklungsgruppe wieder her.
>>-VERREC---*----------*-GROUP-MEMBER-PROJECT-REPDGRP-TYPE->< *-PROJDEF--*
Erforderliche Parameter:
Optionale Parameter:
Ein Muster-Java-Programm (mit Eingabe und Ausgabe) wird bereitgestellt. Dabei wird die SCLMDT-Host-Services-API mit einem HTTP-Server als Transportmechanismus aufgerufen.
Die Musteranforderung im folgenden Beispiel ruft die BUILD-Funktion auf, um das ALLOCEXT-Member im SCLMVCM-Projekt zu kompilieren und zu verknüpfen.
<?xml version="1.0"?> <SCLMDT-INPUT xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="sclmdt.xsd"> <SERVICE-REQUEST> <service>SCLM</service> <session>REUSE</session> <bldrept>Y</bldrept> <groupbld>DEV1</groupbld> <projdef>SCLMVCM</projdef> <bldmode>C</bldmode> <repdgrp>DEV1</repdgrp> <sclmfunc>BUILD</sclmfunc> <member>ALLOCEXT</member> <project>SCLMVCM</project> <group>TEST</group> <type>SOURCE</type> </SERVICE-REQUEST> </SCLMDT-INPUT>
Das folgende Beispiel zeigt ein Muster-Java-Programm (in Eclipse) unter Verwendung der oben angegebenen XML-Eingabeanforderung. Bei der Ausführung stellt dieses Programm eine URL-Verbindung mit dem HTTP-Server unter z/OS (CDFMVS08) her, wobei der XML-Eingabedatenstrom als POST-Anforderung an die BWBXML-CGI-Routine übergeben wird.
package com.ibm.sclmCaller; import java.io.*; import java.net.*; import java.util.*; public class XMLBLD { public static void main(String[] args) { try { BufferedReader in = new BufferedReader(new FileReader("C:\\logon.txt")); String logon = in.readLine(); in.close(); Date d = new Date() ; System.out.println("START Transfer DATE/TIME is :" + d.toString() ); // URL details for CGI POST URL url = new URL("http", "CDFMVS08", 8080, "/BWBXML"); HttpURLConnection con = (HttpURLConnection) url.openConnection(); con.setUseCaches(false); con.setDoInput(true); con.setDoOutput(true); con.setRequestMethod("POST"); con.setRequestProperty( "Authorization", "Basic " + Base64Encoder.encode( logon )); System.out.println("At url openConnection.. "); // POST CGI routines doPut(url, con); doGet(url, con); Date c = new Date() ; System.out.println("TOTAL Completion DATE/TIME is :" + c.toString() ); } catch (IOException exception) { System.out.println("Error: " + exception); } } public static void doPut(URL url, HttpURLConnection con) throws IOException { PrintWriter out = new PrintWriter(con.getOutputStream()); // Below is a sample inline XML input for an ISPF service request // This could alternatively be read from an external file out.println( "<?xml version=\"1.0\"?>" ); out.println( "<SCLMDT-INPUT" ); out.println( "xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\"" ); out.println( "xsi:noNamespaceSchemaLocation=\"sclmdt.xsd\">" ); out.println( "<SERVICE-REQUEST>" ); out.println( "<service>SCLM</service>" ); out.println( "<session>NONE</session>" ); out.println( "<ispprof>IBMUSER.TEST.ISPPROF</ispprof>" ); out.println( "<sclmfunc>BUILD</sclmfunc>" ); out.println( "<project>SCLMVCM</project>" ); out.println( "<projdef>SCLMVCM</projdef>" ); out.println( "<member>ALLOCEXT</member>" ); out.println( "<group>TEST</group>" ); out.println( "<type>SOURCE</type>" ); out.println( "<repdgrp>DEV1</repdgrp>" ); out.println( "<groupbld>DEV1</groupbld>" ); out.println( "<bldrept>Y</bldrept>" ); out.println( "<bldmsg>Y</bldmsg>" ); out.println( "<bldmode>C</bldmode>" ); out.println( "</SERVICE-REQUEST>" ); out.println( "</SCLMDT-INPUT>" ); out.flush(); out.close();
} public static void doGet(URL url, HttpURLConnection con) throws IOException { BufferedReader in; try { System.out.println("About to accept response from Server"); in = new BufferedReader(new InputStreamReader(con.getInputStream())); System.out.println("Response from Server received"); } catch (FileNotFoundException exception) { InputStream err = ((HttpURLConnection)con).getErrorStream(); if (err == null) throw exception ; in = new BufferedReader(new InputStreamReader(err)); } String line; while ((line = in.readLine()) != null) System.out.println(line); in.close(); } }
Das folgende Beispiel zeigt die Musterausgabe der BUILD-Funktion, die mit dem Muster-Java-Programm aufgerufen wurde.
Abb. 26 zeigt die Musterausgabe der BUILD-Funktion, die mit dem Muster-Java-Programm aufgerufen wurde.
START Transfer DATE/TIME is :Wed Mar 26 09:44:03 WST 2008 At url openConnection.. About to accept response from Server Response from Server received <?xml version="1.0"?> <SCLMDT-OUTPUT> <SERVICE-REQUEST> <service>SCLM</service> <session>NONE</session> <ispprof>IBMUSER.TEST.ISPPROF</ispprof> <sclmfunc>BUILD</sclmfunc> <project>SCLMVCM</project> <projdef>SCLMVCM</projdef> <member>ALLOCEXT</member> <group>TEST</group> <type>SOURCE</type> <repdgrp>DEV1</repdgrp> <groupbld>DEV1</groupbld> <bldrept>Y</bldrept> <bldmsg>Y</bldmsg> <bldmode>C</bldmode> </SERVICE-REQUEST> <SERVICE-RESPONSE> <RETURN-CODE>0</RETURN-CODE> <REASON-CODES> <REASON-CODE ID="BWB00158">SELECT DETAILS-- BUTTON FOR BUILD MESSAGES, REPORTS, LISTINGS</REASON-CODE> </REASON-CODES> <BUILD-MESSAGES> <BUILD-MESSAGE ID="FLM42000">- BUILD PROCESSOR INITIATED - 09:53:01 ON 2008/03/26</BUILD-MESSAGE> <BUILD-MESSAGE ID="FLM46000">- BUILD PROCESSOR COMPLETED - 09:53:01 ON 2008/03/26</BUILD-MESSAGE> </BUILD-MESSAGES> <BUILD-REPORT> <![CDATA[ *********************************************************************** *********************************************************************** ** ** ** ** ** SOFTWARE CONFIGURATION AND LIBRARY MANAGER (SCLM) ** ** ** ** B U I L D R E P O R T ** ** ** ** 2008/03/26 09:53:01 ** ** ** ** PROJECT: SCLMVCM ** ** GROUP: DEV1 ** ** TYPE: SOURCE ** ** MEMBER: ALLOCEXT ** ** ALTERNATE: SCLMVCM ** ** SCOPE: NORMAL ** ** MODE: CONDITIONAL ** ** ** ** ** *********************************************************************** *********************************************************************** 1 *** B U I L D O U T P U T S G E N E R A T E D *** Page 1 MEMBER TYPE VERSION KEYWORD ------ ---- ------- ------- ******* NO MODULES GENERATED ******* 1 ******* B U I L D M A P S G E N E R A T E D ******* Page 2 (REASON FOR REBUILD) MEMBER TYPE VERSION MEMBER TYPE ------ ---- ------- ------- ---- ***** NO BUILD MAPS GENERATED ***** 1 ******* B U I L D O U T P U T S D E L E T E D ******* Page 3 MEMBER TYPE VERSION KEYWORD ------ ---- ------- ------- ******* NO MODULES DELETED ******* 1 ******* B U I L D M A P S D E L E T E D ******* Page 4 (REASON FOR DELETE) MEMBER TYPE VERSION MEMBER TYPE ------ ---- ------- ------- ---- ***** NO BUILD MAPS DELETED ***** ]]> </BUILD-REPORT> <SCLM-MESSAGES> <SCLM-MESSAGE ID="FLM87107">- BUILD SUCCEEDED FOR MEMBER ALLOCEXT AT 09:53:01, CODE: 0</SCLM-MESSAGE> </SCLM-MESSAGES> </SERVICE-RESPONSE> <OPERATIONS-LOG> <![CDATA[ Status: 200 Content-Type: text/plain Entering BWBINT (Service initialization) Host driver level : V4 12Feb08 09:52:57.48 Function ID timestamp = ID35577 Environment variables : 1 CONTENT_TYPE application/x-www-form-urlencoded 2 QUERY_STRING 3 PATH /usr/lpp/rdz/bin:/bin:.:/usr/sbin:/usr/lpp/internet/bin:/usr/lpp/ internet/sbin:/usr/lpp/java/J5.0/bin 4 AUTH_TYPE Basic 5 DOCUMENT_URI /BWBXML 6 SHELL /bin/sh 7 HTTPS OFF 8 HTTP_USER_AGENT Java/1.5.0 9 HTTP_ACCEPT text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2 10 RULE_FILE //DD:CONF 11 SERVER_PORT 8080 12 CONTENT_LENGTH 554 13 PATH_INFO 14 GATEWAY_INTERFACE CGI/1.1 15 _CEE_RUNOPTS ENVAR("_CEE_ENVFILE=//DD:ENV") 16 REFERER_URL 17 _BPX_SPAWN_SCRIPT YES 18 _ ./BWBCRON1 19 CLASSPATH .:/usr/lpp/internet/server_root/CAServlet 20 REMOTE_ADDR 192.168.124.236 21 REQUEST_METHOD POST 22 STEPLIB CURRENT 23 CGI_TRANTABLE FEK.#CUST.LSTRANS.FILE 24 LANG C 25 REMOTE_USER IBMUSER 26 LIBPATH /bin:/usr/lpp/internet/bin:/usr/lpp/internet/sbin 27 FSCP IBM-1047 28 SERVER_ADDR 56. 9.42.112.75 29 HTTP_CONNECTION keep-alive 30 PATH_TRANSLATED 31 HTTP_HOST CFDFMVS08 32 SERVER_TOKEN 1 33 HTTP_CACHE_CONTROL no-cache 34 SERVER_SOFTWARE IBM HTTP Server/V5R3M0 35 _BPX_SHAREAS YES 36 NETCP ISO8859-1 37 DOCUMENT_ROOT /usr/lpp/rdz/bin 38 REPORTBITS 77 39 COUNTERDIR NULL 40 LC_ALL en_US.IBM-1047 41 SERVER_PROTOCOL HTTP/1.1 42 _BPX_USERID IBMUSER 43 _SCLMDT_CONF_HOME /etc/rdz/sclmdt 44 HTTPS_KEYSIZE 45 JAVA_HOME /usr/lpp/java/J5.0/ 46 TZ EST5EDT 47 SCRIPT_NAME /BWBXML 48 _BPX_BATCH_SPAWN SPAWN 49 _CEE_ENVFILE //DD:ENV 50 NLSPATH /usr/lib/nls/msg/%L/%N:/usr/lpp/internet/%L/%N:/usr/ lib/nls/msg/En_US.IBM-1047/%N 51 DOCUMENT_NAME /usr/lpp/rdz/bin/BWBXML 52 _SCLMDT_WORK_HOME /var/rdz 53 HTTP_PRAGMA no-cache 54 SERVER_NAME CDFMVS08 Timecheck1:09:52:57.49 Connection Protocol : HTTP Server Name : CDFMVS08 Server Port : 8080 SCRT check: /var/rdz/WORKAREA/scrtTimeStamp Time:1206492777 File: 1206492602 Timecheck2:09:52:57.51 Timecheck2b:09:52:57.51 FSCP = IBM-1047 NETCP = ISO8859-1 _SCLMDT_CONF_HOME = /etc/rdz/sclmdt _SCLMDT_WORK_HOME = /var/rdz CGI_TRANTABLE = FEK.#CUST.LSTRANS.FILE Server PATH = /usr/lpp/rdz/bin:/bin:.:/usr/sbin:/usr/lpp/internet/ bin:/usr/lpp/internet/sbin:/usr/lpp/java/J5.0/bin Check: userdir = /var/rdz/WORKAREA/IBMUSER Timechecklsa:09:52:57.51 Timecheck3:09:52:57.51 ** Development Group = DEV1 ** Selected Group = TEST Plugin version : NONE Host version : 4.1.0 Temporary data set prefix set to : SCLMVCM.IBMUSER Timecheck4:09:52:58.04 Parameters to be written to temporary data set 'SCLMVCM.IBMUSER.SCLMDT. VCMISPF.ID35577' :ISPPROF=IBMUSER.TEST.ISPPROF&SCLMFUNC=BUILD &PROJECT=SCLMVCM&PROJDEF=SCLMVCM&MEMBER=ALLOCEXT&GROUP=TEST &TYPE=SOURCE&REPDGRP=DEV1&GROUPBLD=DEV1&BLDREPT=Y&BLMSG=Y&BLDMODE=C /etc/rdz/sclmdt;/var/rdz /usr/lpp/rdz/bin:/bin:.:/usr/sbin:/usr/lpp/internet/bin:/usr/lpp/internet/ sbin:/usr/lpp/java/J5.0/bin/~~FEK.#CUST.LSTRANS.FILE Processing SCLM request : Value for SESSFLG = NONE Value for SESSION = NONE Value for SCLMFUNC = BUILD Value for PROJ = SCLMVCM Value for PROJDEF = SCLMVCM Value for Development GROUP = DEV1 Value for Selected GROUP = TEST Value for TYPE = SOURCE Value for LANG = NONE Value for MEMBER = ALLOCEXT Value for J2EEFILE = NONE Value for PROFDSN = IBMUSER.TEST.ISPPROF Value for PARMS = NONE pcnt = 3 parmline.1 = ISPF SELECT CMD(BWBBLD ID35577 SCLMVCM.IBMUSER SCLMVCM SCLMVCM TEST DEV1 SOURCE ALLOCEXT /) NEST LANG(CREX) time check before ISPZINT call :09:52:58.17 time check after ISPZINT call :09:53:02.51 ispzint rc = 0 check: respline count = 226 *** ISPZINT OUTPUT *** Content-type: text/plain Entering ISPZINT (Service initialization) About to read from fileno(stdin) = 0 Data read from STDIN is ISPF SELECT CMD(BWBBLD ID35577 SCLMVCM.IBMUSER SCLMVCM SCLMVCM TEST DEV1 SOURCE ALLOCEXT /) NEST LANG(CREX) EPOCH secs = 1206492778 Local Date & time: Tue Mar 25 20:52:58 2008 Hour: 20 Min: 52 Sec 58 Function ID timestamp = ID075178 Environment variables: 0 QUERY_STRING= 1 CONTENT_TYPE=application/x-www-form-urlencoded 2 PATH=/usr/lpp/rdz/bin:/bin:.:/usr/sbin:/usr/lpp/internet/bin:/usr/lpp/ internet/sbin:/usr/lpp/java/J5.0/bin 3 AUTH_TYPE=Basic 4 DOCUMENT_URI=/BWBXML 5 SHELL=/bin/sh 6 HTTPS=OFF 7 HTTP_ACCEPT=text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2 8 HTTP_USER_AGENT=Java/1.5.0 9 SERVER_PORT=8080 10 RULE_FILE=//DD:CONF 11 GATEWAY_INTERFACE=CGI/1.1 12 PATH_INFO= 13 CONTENT_LENGTH=554 14 _CEE_RUNOPTS=ENVAR("_CEE_ENVFILE=//DD:ENV") 15 _BPX_SPAWN_SCRIPT=YES 16 REFERER_URL= 17 _=/u/SCLMDTIS/bin/ISPZINT 18 CLASSPATH=.:/usr/lpp/internet/server_root/CAServlet 19 STEPLIB=CURRENT 20 REQUEST_METHOD=POST 21 REMOTE_ADDR=192.168.128.236 22 CGI_TRANTABLE=FEK.#CUST.LSTRANS.FILE 23 LANG=C 24 LIBPATH=/bin:/usr/lpp/internet/bin:/usr/lpp/internet/sbin 25 REMOTE_USER=IBMUSER 26 SERVER_ADDR=9.42.112.75 27 FSCP=IBM-1047 28 PATH_TRANSLATED= 29 HTTP_CONNECTION=keep-alive 30 SERVER_TOKEN=1 31 HTTP_HOST=CDFMVS08 32 _BPX_SHAREAS=YES 33 SERVER_SOFTWARE=IBM HTTP Server/V5R3M0 34 HTTP_CACHE_CONTROL=no-cache 35 REPORTBITS=77 36 DOCUMENT_ROOT=/usr/lpp/rdz/bin 37 NETCP=ISO8859-1 38 COUNTERDIR=NULL 39 LC_ALL=en_US.IBM-1047 40 _SCLMDT_CONF_HOME=/etc/rdz/sclmdt 41 _BPX_USERID=IBMUSER 42 SERVER_PROTOCOL=HTTP/1.1 43 JAVA_HOME=/usr/lpp/java/J5.0/ 44 HTTPS_KEYSIZE= 45 TZ=EST5EDT 46 _CEE_ENVFILE=//DD:ENV 47 _BPX_BATCH_SPAWN=SPAWN 48 SCRIPT_NAME=/BWBXML 49 NLSPATH=/usr/lib/nls/msg/%L/%N:/usr/lpp/internet/%L/%N: /usr/lib/nls/msg/En_US.IBM-1047/%N 50 _SCLMDT_WORK_HOME=/var/rdz 51 DOCUMENT_NAME=/usr/lpp/rdz/bin/BWBXML 52 SERVER_NAME=CDFMVS08 53 HTTP_PRAGMA=no-cache Number of environment variables is 54 Connection Protocol = HTTP Server Name = CDFMVS08 Server Port = 8080 ***ERROR: Unable to get status information for ISPZTSO FSCP = IBM-1047 NETCP = ISO8859-1 Server PATH = /usr/lpp/rdz/bin:/bin:.:/usr/sbin:/usr/lpp/internet/bin:/ usr/lpp/internet/sbin:/usr/lpp/java/J5.0/bin/ ISPF standalone function invoked ISPF COMMAND = ISPF SELECT CMD(BWBBLD ID35577 SCLMVCM.IBMUSER SCLMVCM SCLMVCM TEST DEV1 SOURCE ALLOCEXT /) NEST LANG(CREX) ISPF PROFILE = NONE Re-usable ISPF session = About to spawn task for ISPZTSO Parameters passed to ISPZTSO - PROFILE Return code from ISPZTSO is 0 About to process PROFILE data in /tmp/IBMUSER.ID075178.ISPF.SYSTSPRT About to malloc() 252 bytes for profdat Temporary data set prefix set to : SCLMVCM About to call bpxwdyn to allocate VCMTEMP Allocating data set SCLMVCM.ISPF.VCMISPF.ID075178 to the VCMTEMP DD 1024 bytes of ISPF SELECT CMD(BWBBLD ID35577 SCLMVCM.IBMUSER SCLMVCM SCLMVCM TEST DEV1 SOURCE ALLOCEXT /) NEST LANG(CREX) written to VCMTEMP 1024 bytes of /etc/rdz;/var/rdz written to VCMTEMP 1024 bytes of /usr/lpp/rdz/bin:/bin:.:/usr/sbin:/usr/lpp/internet/bin: /usr/lpp/internet/sbin:/usr/lpp/java/J5.0/bin/~~ written to VCMTEMP Parameter to be passed to ISPZTSO CALL *(ISPZCNT) 'ISPF ID075178 SCLMVCM NONE ISPF SELECT CMD(BWBBLD ID35577 SCLMVCM.IBMUSER SCLMVCM SCLMVCM TEST DEV1 SOURCE ALLOCEXT /) NEST LANG(CREX)' About to spawn task for ISPZTSO Parameters passed to ISPZTSO - CALL *(ISPZCNT) 'ISPF ID075178 SCLMVCM NONE ISPF SELECT CMD(BWBBLD ID35577 SCLMVCM.IBMUSER SCLMVCM SCLMVCM TEST DEV1 SOURCE ALLOCEXT /) NEST LANG(CREX)' Return code from ISPZTSO is 0 About to open /tmp/IBMUSER.ID075178.ISPF.SYSTSPRT IKJ56003I PARM FIELD TRUNCATED TO 100 CHARACTERS Entering ISPZCNT (ISPF Initialization) Parameters ISPF ID075178 SCLMVCM NONE ISPF SELECT CMD(BWBBLD ID35577 SCLMVCM.IBMUSER SCLMVCM SCLMVCM TEST DEV1 REC: ispmlib=isp.sispmenu Allocation successful for ISPMLIB REC: isptlib=isp.sisptenu Allocation successful for ISPTLIB REC: ispplib=isp.sisppenu Allocation successful for ISPPLIB REC: ispslib=bzz.sbzzsenu,isp.sispsenu,isp.sispslib Allocation successful for ISPSLIB REC: ISPF_timeout = 300 NOTE: Data set allocations took 0.28 elapsed seconds Running user ISPF command: ISPSTART CMD(BWBBLD ID35577 SCLMVCM.IBMUSER SCLMVCM SCLMVCM TEST DEV1 SOURCE ALLOCEXT /) NEST <ISPINFO> ISPF COMMAND : ISPSTART CMD(BWBBLD ID35577 SCLMVCM.IBMUSER SCLMVCM SCLMVCM TEST DEV1 SOURCE ALLOCEXT /) NEST LANG(CREX) N <ISPF> Entering BWBBLD Temporary data set prefix : SCLMVCM.IBMUSER about to allocate VCMISPF rc from alloc is 0 Translate table allocated successfully SCLMDT CONFIG directory = /etc/rdz/sclmdt SCLMDT Working directory = /var/rdz SCLMDT Translate table = FEK.#CUST.LSTRANS.FILE ****** BUILD PARMS ****** PROJECT = SCLMVCM PROJDEF (Project Name) = SCLMVCM GROUP (SCLM Group) = TEST GROUPBLD (Build at group) = DEV1 TYPE (SCLM Type) = SOURCE MEMBER (SCLM Build Member) = ALLOCEXT BLDSCOPE (Build Scope) = N BLDMODE (Build Mode) = C BLDLIST (Listing Flag ) = Y BLDREPT (Report Flag ) = Y BLDMSG (Messages Flag ) = Y BLDLSTDS (Listing Data set name) = BLDRPTDS (Report Data set name) = BLDMSGDS (Messages Data set name) = BLDEXTDS (Exit Data set name) = SUBMIT (Submission type) = ONLINE ****** End PARMS ****** projfile = /etc/rdz/sclmdt/CONFIG/PROJECT/SCLMVCM.conf Security Flag set to N rc from FLMMSGS alloc is 0 PARMS=SCLMVCM,SCLMVCM,DEV1,SOURCE,ALLOCEXT,,N,C,Y,Y,,tmpmsg, tmprpt,tmplst,BLDEXIT BWBBLD CHECK: PARMS = SCLMVCM,SCLMVCM,DEV1,SOURCE,ALLOCEXT,, N,C,Y,Y,,tmpmsg,tmprpt,tmplst,BLDEXIT *** BUILD SUCCESSFUL *** Cleaning up workarea directories ********************** SCLM MESSAGES *********************** FLM87107 - BUILD SUCCEEDED FOR MEMBER ALLOCEXT AT 09:53:01, CODE: 0 ************************************************************** *** XML-NOTE *** Reference tagged SERVICE-RESPONSE </ISPF> RC=0 </ISPINFO> ISPRC = 0 *********************** ISPLOG CONTENTS *********************** 1 Time *** ISPF transaction log *** Userid: IBMUSER Date: 08/03/26 Page: 09:53 Start of ISPF Log - - - - Session # 1 ---------------------- 09:53 TSO - Command - - BWBBLD ID35577 SCLMVCM.IBMUSER SCLMVCM SCLMVCM TEST DEV1 SOURCE ALLOCEXT / 09:53 TSO - Command - - FLMCMD 09:53 BUILD,SCLMVCM,SCLMVCM,DEV1,SOURCE,ALLOCEXT ,,N,C,Y,Y,,tmpmsg,tmprpt,tmplst,BLD 09:53 EXIT 09:53 End of ISPF Log - - - - - Session # 1 ---------------------- ********************* END ISPLOG CONTENTS ********************* IKJ56247I FILE ISPLLIB NOT FREED, IS NOT ALLOCATED Leaving ISPZCNT READY END return code from ISPFInit = 0 PROCESSING COMPLETE End of SCLM Processing FUNC: BUILD - Cleaning up old 'SCLMVCM.IBMUSER.SCLMDT.VCMISPF.ID35577' EXIT BWBINT 09:53:02.86 WITH RC=0 ]]> </OPERATIONS-LOG> </SCLMDT-OUTPUT> TOTAL Completion DATE/TIME is :Wed Mar 26 09:44:11 WST 2008
In diesem Abschnitt werden die Erweiterungen des Java/J2EE-Erstellungsprozesses unter Verwendung des Erstellungsdienstprogramms von Rational Application Developer for WebSphere Software (früher AST: Application Server Toolkit) beschrieben. Das Erstellungsdienstprogramm von Rational Application Developer for WebSphere Software wird als Teil von Rational Application Developer (RAD) bereitgestellt. RAD muss separat angefordert, installiert und konfiguriert werden. Die Installation und Anpassung dieses Produkts wird in diesem Handbuch nicht beschrieben. Verwenden Sie die im Lieferumfang von RAD enthaltene Dokumentation, wenn Sie Anweisungen zur Installation und Anpassung der Funktionen des Erstellungsdienstprogramms benötigen. In diesem Abschnitt wird das Erstellungsdienstprogramm von Rational Application Developer for WebSphere im Folgenden als "Erstellungsdienstprogramm" bezeichnet.
Mit dem Erstellungsdienstprogramm ist es möglich, replizierte Projektarbeitsbereiche aus der IDE, die in SCLM gespeichert wurden, unter Verwendung des automatischen Modus von Eclipse unter z/OS mit SCLM zu erstellen.
Dieser Abschnitt sollte in Verbindung mit dem Onlinebenutzerhandbuch für SCLM Developer Toolkit und dem im Lieferumfang des Produkts enthaltenen Installations- und Anpassungshandbuch verwendet werden. SCLM Developer Toolkit stellt Java/J2EE-Sprachumsetzer für SCLM bereit, um vollständige Java/J2EE-Erstellungsfunktionen zu ermöglichen.
SCLM Developer Toolkit bietet nicht nur Funktionen zum Speichern von JAVA/J2EE-Quellcode und -Objekten, sondern durch diese Umsetzer auch die Möglichkeit, in SCLM Java/J2EE-Anwendungen zu erstellen und vollständig zu verwalten. Diese Sprachumsetzer unterstützen folgende Java/J2EE-Objekte: Java-Klassen, Java-Archivdateien (JAR), Enterprise Java Beans (EJB-JAR-Dateien), Webarchivdateien (WAR) und Unternehmensarchivdateien (EAR).
SCLM Developer Toolkit wird im Erstellungsdienstprogramm integriert, um die Replikation von SCLM-J2EE-Projekten im Arbeitsbereich des Erstellungsdienstprogramms unter UNIX System Services unter z/OS zu steuern. Die replizierten Projekte werden anschließend durch ARCHDEF-Erstellungsprozesse erstellt, die Erstellungsdienstprogrammscripts referenzieren. Mustererstellungsscripts werden in SCLM Developer Toolkit bereitgestellt. Objekte, die bei der Builderstellung/Kompilierung entstehen, werden in SCLM gespeichert.
Das Erstellungsdienstprogramm unterstützt Builds aller J2EE-Projekte, die unter Rational Application Developer V7 unterstützt werden. Projekte, die in früheren Versionen von RAD erstellt wurden, müssen in einen RAD V7-Arbeitsbereich auf dem IDE-Client migriert werden, bevor sie zu SCLM hinzugefügt werden können. Normale Eclipse-Java-Projekte werden ebenfalls unterstützt.
Java/J2EE-Objekte werden in SCLM wie folgt gespeichert:
SCLM Developer Toolkit umfasst einen nativen ANT-Erstellungsprozess für Java/J2EE-Unterstützung. Weitere Informationen hierzu finden Sie im SCLM Developer Toolkit-Onlinebenutzerhandbuch-Plug-in und Installations-/Anpassungshandbuch.
Das Erstellungsdienstprogramm von Rational Application Developer for WebSphere Software aktiviert die Java/J2EE-Buildunterstützung, indem die Eclipse-IDE-Umgebung unter z/OS beim Erstellen vollständig repliziert wird.
Vergleichbar mit dem ANT-Erstellungsprozess verwendet der Prozess des Erstellungsdienstprogramms die Archdef, die die Member enthält, aus denen das Java/J2EE-Projekt zusammengesetzt ist. Dabei handelt es sich um eine Kurznamendarstellung der Struktur des Projekts im Eclipse-Arbeitsbereich.
Der Benutzer kann entweder den Erstellungsdienstprogramm-Prozess oder den nativen ANT-Erstellungsprozess auswählen, indem das Erstellungsscript (referenziert durch die ARCHDEF) mit dem entsprechenden Sprachumsetzer zugewiesen wird:
Die Archdef ruft bei der Erstellung den vorerstellten Sprachüberprüfungsumsetzer (J2EEAST) auf. Der Sprachtyp J2EEAST wird dem Erstellungsscript zugewiesen, das in der Archdef mit dem Schlüsselwort SINC referenziert wird. Dieser Sprachumsetzer kopiert alle Archdef-Komponenten für die Erstellung mit dem Erstellungsdienstprogramm in das z/OS UNIX System Services-Dateisystem.
Projektkomponenten und Java-Quellcode können in SCLM als EBCDIC oder ASCII gespeichert werden. Im Erstellungsdienstprogramm werden Textkomponenten und Java-Quellcode standardmäßig in ASCII im USS-Arbeitsbereich umgesetzt, bevor der Erstellungsprozess ausgeführt wird.
Das Erstellungsdienstprogramm von Rational Application Developer for WebSphere Software wird als Teil von Rational Application Developer (RAD) bereitgestellt. RAD muss separat angefordert, installiert und konfiguriert werden. Die Installation und Anpassung dieses Produkts wird in diesem Handbuch nicht beschrieben. Verwenden Sie die im Lieferumfang von RAD enthaltene Dokumentation, wenn Sie Anweisungen zur Installation und Anpassung der Funktionen des Erstellungsdienstprogramms benötigen. Das Verzeichnispaket des Erstellungsdienstprogramms wird im z/OS UNIX-Dateisystem gespeichert.
Für den J2EE-Erstellungsprozess können umfangreiche Regionsgrößen erforderlich sein, um Fehler im Zusammenhang mit unzureichendem Speicherplatz zu vermeiden. Um umfangreiche Online-Erstellungen zu berücksichtigen, geben Sie mindestens einen Wert von REGION=512M im RSE-Dämon von Developer for System z an (standardmäßig ist dies die von RSED gestartete Task). Für die Stapelverarbeitung wird empfohlen, diesen Regionsgrößenparameter in der Batch-JOBCARD anzugeben.
Die anfängliche J2EEAST-Verarbeitung ähnelt J2EEANT, wobei der Sprachumsetzer aus der Archdef ermittelt, welche Teile neu erstellt werden müssen, abhängig vom Erstellungsmodus (bedingt oder erzwungen). Die Projektquellendateien und enthaltenen Objekte werden anschließend in den Arbeitsbereich des UNIX Systems Services-Dateisystems für das Erstellungsdienstprogramm kopiert. Das Ausführungsscript und die Build-XML, die in SCLM unter Typ J2EEBLD gespeichert sind, werden ebenfalls in denselben Arbeitsbereich kopiert. Das Ausführungsscript wird aufgerufen, um Eclipse im automatischen Modus unter z/OS zu starten und die referenzierte Anwendungsbuild-XML auszuführen. Das Erstellungsdienstprogramm kompiliert und generiert die erforderlichen Java/J2EE-Objekte, die durch das Ausführungsscript, die Build-XML und die Archdef angegeben sind.
J2EEAST überprüft die generierten Objekte und wählt für die SCLM-Aktualisierung nur die Teile/Objekte aus, die aufgrund des Erstellungsmodus in SCLM (bedingt/erzwungen) neu erstellt werden mussten.
SCLM verarbeitet die einzelnen Archdef-Komponenten, indem jeder Sprachumsetzer, der mit der Komponente verknüpft ist, ausgeführt wird. Der JAVA-Sprachumsetzer, der jedem ausgewählten Java-Quellenmember zugeordnet ist, kopiert die jeweils zugeordneten Klassendateien zurück in SCLM.
Der abschließende Teil des Erstellungsprozesses ist die Verarbeitung der ARCHDEF selbst, wobei der Sprachumsetzer J2EEOBJ ausgeführt wird. Dieser Archdef-Umsetzer ermittelt, welche J2EE-Objekte generiert wurden (JAR, WAR, EAR), und kopiert diese Teile zurück in SCLM.
Die Implementierung und Verwendung erfolgt folgendermaßen:
Für das Erstellungsdienstprogramm werden bestimmte Sprachumsetzer für die J2EE-Quelle, die ARCHDEF und das Erstellungsscript zugewiesen.
Muster für das Generieren dieser Sprachen in einem SCLM-Projekt werden in SCLM Developer Toolkit in der Installationmusterbibliothek unter SBWBSAMP bereitgestellt.
Hierbei handelt es sich um einen Sprachumsetzer der Script-XML des Erstellungsdienstprogramms.
Zusammenfassung: SAMPLE: BWBTRAN4
Der Überprüfungsumsetzer J2EEAST wird aufgerufen, wenn die Archdef erstellt wird. J2EEAST ist der Sprachtyp der J2EEBLD-Build-XML, die mit dem Schlüsselwort SINC in der Archdef referenziert wird. Dieser Überprüfungsumsetzer kopiert den ausgewählten Quellcode und alle Archdef-Objekte unabhängig vom Erstellungsmodus in den z/OS-HFS-Arbeitsbereich. Zum Erstellungszeitpunkt wird dieser als Projektarbeitsbereich referenziert. Dieser Projektarbeitsbereich wird temporär im Arbeitsbereich von SCLM Developer Toolkit gespeichert. SCLM DT erstellt einen temporären Projektarbeitsbereich unter der folgenden Verzeichnisstruktur: /var/SCLMDT/WORKAREA/userid/project/group/type/member/project
Das Erstellungsdienstprogramm benötigt die vollständige Projektstruktur, daher werden alle Projektkomponenten in das UNIX System Services-Dateisystem kopiert. Alle textbasierten Komponenten werden als ASCII in den Projektarbeitsbereich kopiert. Die Build-XML wird auch in den HFS-Arbeitsbereich kopiert. Die Build-XML enthält Projektdetails und J2EE-Buildanforderungen sowie andere Eigenschaftendetails, die durch SCLM referenziert werden.
Die Build-XML referenziert ein zugeordnetes Erstellungsdienstprogramm-Ausführungsscript. Dieses Ausführungsscript wird auch in den Arbeitsbereich (EBCDIC) kopiert. Wenn es ausgeführt wird, startet es Eclipse im automatischen Modus unter z/OS, um die Anwendungsbuild-XML auszuführen. Die aktuelle Implementierung bewirkt eine vollständige Erstellung im Arbeitsbereich. SCLM verarbeitet jedoch nur die ausgewählten Teile, wenn bedingte Erstellung angefordert wurde, und der Umsetzer ermittelt anhand des Erstellungsmodus, welche generierten Objekte in SCLM aktualisiert werden müssen.
Generierte J2EE-Objekte wie JAR-, WAR- oder EAR-Archivdateien werden in SCLM gespeichert, wenn der Archdef-Umsetzer J2EEOBJ ausgeführt wird. Die ausgewählten Klassendateien werden protokolliert und in SCLM aktualisiert, wenn die Archdef die einzelnen Java-Komponenten (Java-Umsetzer) verarbeitet.
Hierbei handelt es sich um einen Archdef-Sprachumsetzer, der durch das Schlüsselwort LKED referenziert wird.
Zusammenfassung: SAMPLE: BWBTRAN3
Dies ist der endgültige Buildumsetzer, der während des ARCHDEF-Erstellungsprozesses aufgerufen wird. Dieser Umsetzer ermittelt, welche J2EE-Objekte zuvor im Umsetzer J2EEAST erstellt wurden, und kopiert diese Objekte mit dem angegebenen generierten Kurznamen in SCLM.
Hierbei handelt es sich um einen Sprachumsetzer des Java-Quellcodes, der in EBCDIC gespeichert ist.
Zusammenfassung: SAMPLE: BWBTRAN1
Der Sprachtyp für Java-Quellcode wird durch das Muster BWBTRAN1 definiert. Der Java-Umsetzer ermittelt, welcher Buildtyp für den Java-Quellcode ausgegeben wurde. Hinweis: Diese Sprachdefinition muss Java-Programmen zugewiesen werden, wenn Sie den Java-Quellcode in EBCDIC auf dem Host speichern möchten (d. h. der Quellcode kann über ISPF direkt auf dem Host angezeigt und bearbeitet werden). Der Vorteil des Definierens von Programmen mit dieser Sprachdefinition liegt darin, dass der Quellcode direkt auf dem z/OS-Host bearbeitet und angezeigt werden kann. Nachteilig ist, dass Codepagekonvertierungen vorgenommen werden müssen, wenn Projekte vom Client auf den Host migriert oder importiert werden.
Hierbei handelt es sich um einen Sprachumsetzer des Java-Quellcodes, der in ASCII gespeichert ist.
Zusammenfassung: SAMPLE: BWBTRAN1
Der Sprachtyp ähnelt Java und wird beim Speichern von Java-Quellcode als ASCII in SCLM verwendet.
Hierbei handelt es sich um einen Sprachumsetzer der J2EE-Textkomponente, die in EBCDIC gespeichert ist.
Zusammenfassung: SAMPLE: BWBTRANJ
J2EEPART ist ein Sprachtyp, der eine JAVA/J2EE-Komponente angibt und durch das Muster BWBTRANJ definiert wird. Es wird keine spezielle Syntaxanalyse bei der Erstellung dieser Sprachdefinition ausgeführt. Nicht-Java-Quellcode oder J2EE-Komponenten, für die ASCII/EBCDIC-Sprachkonvertierung erforderlich ist, können unter dieser Sprachdefinition generisch eingefügt werden, wenn keine spezielle Build-Syntaxanalyse benötigt wird (z. B. HTML, XML, .classpath, .project, Definitionstabellen). Optional kann die Sprachdefinition TEXT verwendet werden.
Hierbei handelt es sich um einen Sprachumsetzer des Java-Quellcodes, der in EBCDIC gespeichert ist.
Zusammenfassung: SAMPLE: BWBTRANJ
Sprachtyp, der die binär oder in ASCII gespeicherte JAVA/J2EE-Komponente angibt und durch das Muster BWBTRANJ definiert wird. Es wird keine spezielle Syntaxanalyse bei der Erstellung dieser Sprachdefinition ausgeführt. JAVA/J2EE-Binärdateien und -Textdateien, die als ASCII gespeichert werden sollen, können generisch unter dieser Sprachdefinition eingefügt werden, wenn keine gesonderte Syntaxanalyse benötigt wird.
Ebenso wie die konventionelle J2EE-Build-Servicemethode umfasst die Methode des Erstellungsdienstprogramms Erstellungsscripts, die in der ARCHDEF durch das Schlüsselwort SINC referenziert werden.
Das aufgerufene Erstellungsscript ist eine Erstellungsscriptanwendung zum Erstellen von XML, die für jedes J2EE-Projekt angepasst wird und eindeutig ist. Dieses Erstellungsscript referenziert außerdem ein Erstellungsdienstprogramm-RUN-Script, das globale Erstellungsdienstprogramm-Eigenschaften und Eclipse-Laufzeitbefehle enthält, um Eclipse unter z/OS im automatischen Modus zu starten und die ausgewählte Build-XML auszuführen. Im Allgemeinen wird das angepasste BWBASTR-Script von allen Erstellungsdienstprogramm-Build-Scripts verwendet. Der Sprachtyp muss für alle Erstellungsdienstprogramm-Erstellungsscripts J2EEAST sein. Der Sprachtyp für das BWBASTR-Script sollte ein Nur-Text-Sprachumsetzer sein, z. B. TEXT oder J2EEPART.
Das Ausführungsscript des Erstellungsdienstprogramms (BWBASTR), die Muster-Erstellungsscripts für Java/Jar-Projekte (BWBASTJ), EJB-Projekte (BWBASTEJ), Anwendungsclientprojekte (BWBASTAP), Webprojekte (BWBASTW) und EAR-Projekte (BWBASTE) können aus der SCLM Developer Toolkit-AST-Musterbibliothek im Typ J2EEBLD in die SCLM-Projekte des Kunden kopiert werden.
Das Format des Erstellungsscript enthält folgende Elemente:
Ebenfalls enthalten sind die AST-ANT-Routinen zum Generieren des erforderlichen Projekts. Die in SCLM benötigten Erstellungsscripts sind geänderte Versionen der folgenden durch AST bereitgestellten Muster:
Die folgenden Routinen wurden aus dem Handbuch zu Application Server Toolkit extrahiert.
Diese Task importiert ein vorhandenes Dateisystemprojekt in einen Arbeitsbereich.
Attribut | Beschreibung | Erforderlich |
---|---|---|
ProjectName | Name des zum importierenden Projekts | Ja |
ProjectLocation | Die vollständig qualifizierte Speicherposition des Projekts (entweder unter dem Arbeitsbereich oder an anderer Stelle im Dateisystem) | Nein, die Standardeinstellung ist ${workspaceLocation}/${projectName} |
Beispiel: Importieren eines Projekts, das unter dem Arbeitsbereichsverzeichnis gespeichert ist, aber derzeit nicht im Arbeitsbereich vorhanden ist:
<projectImport ProjectName="myProject"/>
Diese Task erstellt das angegebene Projekt.
Attribut | Beschreibung | Erforderlich |
---|---|---|
ProjectName | Name des zu erstellenden Projekts. | Ja |
BuildType | Buildtyp. | Nein, die Standardeinstellung ist "Incremental". Kann "Incremental" oder "Full" sein. |
FailOnError | Gibt an, ob Erstellungen bei einem Fehler fehlschlagen sollen. | Nein, die Standardeinstellung ist "true". |
DebugCompilation | Gibt an, ob eine Fehlerbehebung für Kompilierungen ausgeführt werden soll. | Nein, die Standardeinstellung ist "true". |
Quiet (veraltet) | Gibt an, ob Nachrichten ausgegeben werden sollen. | Nein, Standardeinstellung ist "false". |
ShowErrors | Gibt an, ob Projektfehler im Ant-Erstellungsprotokoll anezeigt werden sollen. | Nein, die Standardeinstellung ist "true". |
SeverityLevel | Die Problemebene, nach der Erstellungsfehler gezählt und als solche behandelt werden sollen. | Nein, die Standardeinstellung ist "ERROR". Kann "ERROR", "WARNING" oder "INFORMATION" sein. |
CountValidationErrors | Gibt an, ob Überprüfungsprobleme als Projektfehler zählen sollen. | Nein, die Standardeinstellung ist "true". |
PropertyCountName | Eigenschaft zum Empfangen der Fehlerzählung für das Projekt. | Nein, die Standardeinstellung ist "ProjectErrorCount". |
PropertyMessagesName | Eigenschaft zum Empfangen der Fehlernachrichten für das Projekt. | Nein, die Standardeinstellung ist "ProjectErrorMessages". |
Beispiele:
<projectBuild ProjectName="myProject" />
<projectBuild ProjectName="myProject" failonerror="true" DebugCompilation="false" BuildType="full" /> <echo message="projectBuild: projectName=${projectName} project Error Count=${ProjectErrorCount} project Error Messages=${ProjectErrorMessages}" />
Diese Task führt denselben Vorgang aus wie der EJB-JAR-Datei-Exportassistent für den Export eines EJB-Projekts in eine EJB-JAR-Datei. Diese Task ist nicht verfügbar in Produkten, die keine EJB-Entwicklungstools enthalten.
Attribut | Beschreibung | Erforderlich |
---|---|---|
EJBProjectName | Name des EJB-Projekt (Groß-/Kleinschreibung muss beachtet werden). | Ja |
EJBExportFile | Absoluter Pfad der EJB-JAR-Datei. | Ja |
ExportSource | Legt fest, ob Quellendateien eingeschlossen werden oder nicht. | Nein, Standardeinstellung ist "false". |
Overwrite | Legt fest, ob die Datei überschrieben wird, falls schon vorhanden. | Nein, Standardeinstellung ist "false". |
Beispiel: Exportieren des Projekts "EJBProject" nach "EJBProject.jar"
<ejbExport EJBProjectName="EJBProject" EJBExportFile="EJBProject.jar"/>
Diese Task führt denselben Vorgang aus wie der WAR-Datei-Exportassistent für den Export eines Webprojekts in eine WAR-Datei.
Attribut | Beschreibung | Erforderlich |
---|---|---|
WARProjectName | Name des Webprojekts (Groß-/Kleinschreibung muss beachtet werden) | Ja |
WARExportFile | Absoluter Pfad der WAR-Datei | Ja |
ExportSource | Legt fest, ob Quellendateien eingeschlossen werden oder nicht. | Nein, Standardeinstellung ist "false". |
Overwrite | Legt fest, ob die Datei überschrieben wird, falls schon vorhanden. | Nein, Standardeinstellung ist "false". |
Beispiel: Exportieren des Projekts "ProjectWeb" nach "ProjectWeb.war"
<warExport WARProjectName="ProjectWeb" WARExportFile="ProjectWeb.war"/>
Diese Task führt denselben Vorgang aus wie der WAR-Datei-Exportassistent für den Export eines Webprojekts in eine WAR-Datei.
Attribut | Beschreibung | Erforderlich |
---|---|---|
EARProjectName | Name des EAR-Projekts (Groß-/Kleinschreibung muss beachtet werden) | Ja |
EARExportFile | Absoluter Pfad der EAR-Datei | Ja |
ExportSource | Legt fest, ob Quellendateien eingeschlossen werden oder nicht. | Nein, Standardeinstellung ist "false". |
IncludeProjectMetaFiles | Legt fest, ob die Metadatendateien des Projekts, die den Java-Erstellungspfad, die Projektnamen usw. enthalten, eingeschlossen werden sollen. Wird verwendet beim Neuimport von binären Projekten. | Nein, Standardeinstellung ist "false". |
Overwrite | Legt fest, ob die Datei überschrieben wird, falls schon vorhanden. | Nein, Standardeinstellung ist "false". |
Beispiel: Exportieren des Projekts "EARProject" nach "EARProject.ear"
<earExport EARProjectName="EARProject" EARExportFile="EARProject.ear"/>
Diese Task führt denselben Vorgang aus wie der WAR-Datei-Exportassistent für den Export eines Webprojekts in eine WAR-Datei.
Attribut | Beschreibung | Erforderlich |
---|---|---|
AppClientProjectName | Name des Anwendungsclientprojekts (Groß-/Kleinschreibung muss beachtet werden) | Ja |
AppClientExportFile | Absoluter Pfad der Anwendungsclient-JAR-Datei | Ja |
ExportSource | Legt fest, ob Quellendateien eingeschlossen werden oder nicht. | Nein, Standardeinstellung ist "false". |
Overwrite | Legt fest, ob die Datei überschrieben wird, falls schon vorhanden. | Nein, Standardeinstellung ist "false". |
Beispiel: Exportieren des Projekts "ProjectClient" nach "ProjectClient.jar":
<appClientExport AppClientProjectName="ProjectClient" AppClientExportFile="ProjectClient.jar"/>
Das AST-Ausführungsscript wird referenziert durch AST-Erstellungsscripts (type=J2EEBLD lang=TEXT).
/* This is a sample build script to build J2EE projects using Application Server toolkit (AST) on z/OS. AST is the headless mode Eclipse builder which is a separate installable item outside of SCLM Developer toolkit. This sample script will need customizing and should reside in the SCLM type of J2EEBLD being invoked from a J2EE archdef member via the SINC archdef keyword. It should be stored with a text language such as TEXT or J2EEPART. The BUILDFILE and WORKSPACE arguments are passed internally from the J2EE AST language translator within SCLM Developer Toolkit */ parse arg $args parse var $args BUILDFILE WORKSPACE /*------------------ User Customization ----------------------------*/ /* Customize the following variable settings : AST_DIR and JAVA_DIR */ /* AST_DIR is the z/OS eclipse directory where AST is installed */ AST_DIR='/u/AST/eclipse' /* JAVA_DIR is the appropriate z/OS Java bin directory */ /* Set to the Java bin that is packaged in the AST delivery */ JAVA_DIR='/u/AST/eclipse/jdk/bin' /*------------------ End user customization ------------------------*/ /* The rest of the sample should not have to be modified */ say 'AST Eclipse directory = 'AST_DIR say 'Java bin directory = 'JAVA_DIR say 'BUILDFILE = 'BUILDFILE say 'WORKSPACE = 'WORKSPACE If SUBSTR(WORKSPACE,1,1) /= '/' Then Do say 'ERROR : Invalid WORKSPACE ... Build terminated' exit 8 End /* The following parameters are set for headless Eclipse invocation */ /* Java memory parameter options of min 256M & max 512M set */ /* Increase max memory parameter if Java memory failure */ M_parm = '-Xms256m -Xmx512m' A_parm = '-Dfile.encoding=ISO8859-1 -Xnoargsconversion' D_parm = '-Dwtp.autotest.noninteractive=true' cp_parm = '-cp 'AST_DIR'/startup.jar org.Eclipse.core.launcher.Main' ap_parm = '-application com.ibm.etools.j2ee.ant.RunAnt' w_parm = '-data "'workspace'"' f_parm = '-f 'buildfile PARMS = M_parm' 'A_parm' 'D_parm' 'cp_parm' 'ap_parm' 'w_parm' 'f_parm /* Java dumping options have been turned off to prevent java dumps */ /* on memory allocation failures */ JAVA_NODUMP='export JAVA_DUMP_OPTS="ONANYSIGNAL(NONE)"' JAVA_CMD = JAVA_DIR'/java 'PARMS AST_BUILD = JAVA_NODUMP' ; 'JAVA_CMD say "Invoking java launch of Eclipse ..." say AST_BUILD say "Executing ..." AST_BUILD ASTrc = rc If ASTrc = 23 Then say 'WARNING: UNINITIALIZED workspace' Else If ASTrc = 15 Then say 'ERROR : WORKSPACE is already BEING USED' If ASTrc /= 0 then Do say 'ERROR : BUILD FAILED - return code = 'ASTrc EXIT 8 End EXIT 0
Das folgende Erstellungsscript hat type=J2EEBLD lang=J2EEAST. Es kann einen beliebigen Namen haben (bis zu 8 Zeichen). Variablen werden im Standard-XML-Format definiert.
<!-- BWBASTJ: J2EE JAR Sample for AST This is a sample build XML script to be run using AST Eclipse headless mode on z/OS. The SCLM Build script will be copied into the appropriate workarea directory on the z/OS USS filesystem. The projectlocation keyword will be overlaid dynamically with the appropriate assigned workspace. Ensure that the projectlocation line is left as is : Customize the project and property variables below project name : Change ASTJAR to the project name of the Java application AST_SHSCRIPT : Name of skeleton AST run script for build SCLM_ARCHDEF : Name of archdef to be built JAR_FILE_NAME : Name of created JAR SCLM_BLDMAP : If YES then include in MANIFEST directory in JAR. Provides audit and build map of parts included --> <project name="ASTJAR" default="init" basedir="."> <property name="AST_SHSCRIPT" value="ASTRUN"/> <property name="SCLM_ARCHDEF" value="JAR1"/> <property name="JAR_FILE_NAME" value="ASTjar.jar"/> <property name="SCLM_BLDMAP" value="NO"/> <target name="init"> <projectImport projectname="${ant.project.name}" projectlocation="$WORKSPACE" /> <Eclipse.refreshLocal resource="${ant.project.name}" depth="infinite" /> <echo message="refresh done" /> <projectBuild ProjectName="${ant.project.name}" failonerror="true" DebugCompilation="true" BuildType="full" /> <jar update="true" destfile="${JAR_FILE_NAME}"> <fileset dir="." excludes="**/*.java"/> </jar> </target> </project>
Das folgende Erstellungsscript hat type=J2EEBLD lang=J2EEAST.
<!-- BWBASTW: J2EE Sample for AST This is a sample build XML script to be run using AST Eclipse headless mode on z/OS. The SCLM Build script will be copied into the appropriate workarea directory on the z/OS USS filesystem. The projectlocation keyword will be overlaid dynamically with the appropriate assigned workspace. Ensure that the projectlocation line is left as is : Customize the project and property variables below project name : Change ASTWAR to the project name of the WAR application AST_SHSCRIPT : Name of skeleton AST run script for build SCLM_ARCHDEF : Name of archdef to be built WAR_NAME : Name of created WAR SCLM_BLDMAP : If YES then include in MANIFEST directory in WAR. Provides audit and build map of parts included --> <project name="ASTWAR" default="init" basedir="."> <property name="AST_SHSCRIPT" value="BWBASTR"/> <property name="SCLM_ARCHDEF" value="WAR1"/> <property name="WAR_NAME" value="ASTwar.war" /> <property name="SCLM_BLDMAP" value="NO"/> <target name="init"> <projectImport projectname="${ant.project.name}" projectlocation="$WORKSPACE" /> <Eclipse.refreshLocal resource="${ant.project.name}" depth="infinite" /> <echo message="refresh done" /> <projectBuild ProjectName="${ant.project.name}" failonerror="true" DebugCompilation="true" BuildType="full" /> <warExport WARProjectName="${ant.project.name}" ExportSource="true" WARExportFile="${WAR_NAME}"/> </target> </project>
Das folgende Erstellungsscript hat type=J2EEBLD lang=J2EEAST.
<!-- BWBASTEJ: J2EE EJB Sample for AST This is a sample build XML script to be run using AST Eclipse headless mode on z/OS. The SCLM Build script will be copied into the appropriate workarea directory on the z/OS USS filesystem. The projectlocation keyword will be overlaid dynamically with the appropriate assigned workspace. Ensure that the projectlocation line is left as is : Customize the project and property variables below project name : Change ASTEJB to the project name of the EJB application AST_SHSCRIPT : Name of skeleton AST run script for build SCLM_ARCHDEF : Name of archdef to be built EJB_NAME : Name of created EJB JAR SCLM_BLDMAP : If YES then include in MANIFEST directory in JAR, WAR, or EAR. Provides audit and build map of parts included --> <project name="ASTEJB" default="init" basedir="."> <property name="AST_SHSCRIPT" value="ASTRUN"/> <property name="SCLM_ARCHDEF" value="EJB1"/> <property name="EJB_NAME" value="ASTejb.jar" /> <property name="SCLM_BLDMAP" value="NO" /> <target name="init"> <projectImport projectname="${ant.project.name}" projectlocation="$WORKSPACE" /> <Eclipse.refreshLocal resource="${ant.project.name}" depth="infinite" /> <echo message="refresh done" /> <projectBuild ProjectName="${ant.project.name}" failonerror="true" DebugCompilation="true" BuildType="full" /> <ejbExport ExportSource="true" EJBProjectName="${ant.project.name}" EJBExportFile="${EJB_NAME}"/> </target> </project>
Das folgende Erstellungsscript hat type=J2EEBLD lang=J2EEAST.
<!-- BWBASTE: J2EE EAR Sample for AST This is a sample build XML script to be run using AST Eclipse headless mode on z/OS. The SCLM Build script will be copied into the appropriate workarea directory on the z/OS USS filesystem. The projectlocation keyword will be overlaid dynamically with the appropriate assigned workspace at build time. Ensure that the projectlocation line is left as is. Customize the project and property variables below project name : Change ASTEAR to the project name of the EAR application AST_SHSCRIPT : Name of skeleton AST run script for build SCLM_ARCHDEF : Name of archdef to be built EAR_NAME : Name of created EAR SCLM_BLDMAP : If YES then include in MANIFEST directory in JAR, WAR, or EAR. Provides audit and build map of parts included --> <project name="ASTEAR" default="init" basedir="."> <property name="AST_SHSCRIPT" value="BWBASTR"/> <property name="SCLM_ARCHDEF" value="EAR1"/> <property name="EAR_NAME" value="ASTear.ear"/> <property name="SCLM_BLDMAP" value="NO"/> <target name="init"> <projectImport projectname="${ant.project.name}" projectlocation="$WORKSPACE" /> <Eclipse.refreshLocal resource="${ant.project.name}" depth="infinite" /> <echo message="refresh done" /> <projectBuild ProjectName="${ant.project.name}" failonerror="true" DebugCompilation="false" BuildType="full" /> <earExport EARProjectName="${ant.project.name}" ExportSource="true" EARExportFile="${EAR_NAME}"/> </target> </project>
Das Format für die ARCHDEF ist dasselbe wie für den normalen J2EEANT-Erstellungsprozess.
SINC SCRIPT1 J2EEBLD INCLD XX000001 SOURCE INCL PAULWAR2 ARCHDEF OUT1 * J2EEEAR LIST * J2EELIST LKED J2EEOBJ
SCLM bietet SQLJ-Unterstützung durch die Java/J2EE-Buildumsetzer, die in SCLM Developer Toolkit enthalten sind. Diese Umsetzer in Verbindung mit den AST-Erstellungsscripts bieten Unterstützung zum Speichern und Erstellen von SQLJ-Projekten. Sie bieten außerdem Integrationspunkte, mit denen in Kundenroutinen db2-sqlj-Anpassungseigenschaften festgelegt werden können und die den db2-Bindungsprozess in den SCLM-Erstellungs- und Umstufungsschritten durch SCLM-Erstellungs- und Umstufungs-Exits unterstützen.
Weitere Informationen zur SQLJ-Unterstützung finden Sie im Benutzerhandbuch für SCLM Developer Toolkit.
Die SQLJ-Unterstützung in SCLM (unter Verwendung der AST-Methode) kann wie folgt zusammengefasst werden:
DB2-SQLJ-Unterstützung muss installiert sein. Das folgende DB2-Verzeichnis (oder ein anderes Verzeichnis, abhängig vom Standort-Installationsverzeichis) muss im z/OS USS-Dateisystem gespeichert werden: /usr/lpp/db2/db2810/* (dies ist das DB2 v8-Verzeichnis). Dieses Verzeichnis wird für die Anpassung des SQLJ-Erstellungsscripts benötigt. Für SQLJ sind Klassenpfadabhängigkeiten unter /usr/lpp/db2/db2810/jcc/classes/sqlj.zip vorhanden. Für db2sqljcustomize sind die Klassenpfadabhängigkeiten unter /usr/lpp/db2/db2810/jcc/classes/ db2jcc.jar gespeichert.
Ein neuer Sprachumsetzer für SQLJ wird bereitgestellt und sollte als Sprachtyp für den gesamten SQLJ-Quellcode zugewiesen werden, der in SCLM gespeichert wird. Für den neuen Umsetzer müssen zusätzliche SCLM-Typen definiert werden. Der neue Umsetzer ist ähnlich aufgebaut wie der JAVA-Umsetzer, enthält jedoch weitere IOTYPE-Definitionen für die SCLM-Ausgabetypen SQLJSER und DBRMLIB. Wenn der Kunde keine DBRM-Dateien während des db2sqljcustomize-Schritts generiert, kann dieser DBRMLIB IOTYPE aus der SQLJ-Sprachdefinition entfernt werden. (Verwenden Sie die SQLJ-Muster-Umsetzungsdefinition BWBTRANS.) Generieren Sie innerhalb der Projekt-PROJDEF den neuen SQLJ-Umsetzer und die zusätzlichen Typen folgendermaßen:
Kunden müssen SQLJ-DB2-Eigenschaften im Haupt-SQLJ-Erstellungsscript (Muster BWBASTSQ) definieren, das im Typ J2EEBLD gespeichert wird. Diese Eigenschaften werden in den Schritten "sqlj" und "db2sqljcustomize" verwendet.
Im Folgenden finden Sie eine Liste der erforderlichen "sqlj"- und "db2sqljcustomize"-Eigenschaftendefinitionen.
<!-- specify the JAVA bin runtime location --> <property name="JAVA_BIN" value="/usr/lpp/java/J5.0/bin"/>
<!-- specify the location of the sqlj & db2sqljcustomize exec routine bwbsqlc.rex (sample BWBSQLC) --> <!-- By default this sample should be located or copied to the SCLM DT install directory --> <property name="sqlj.exec" value="/etc/SCLMDT/bwbsqlc.rex"/> <!-- specify global property arguments below for sqlj processing --> <property name="sqlj.arg" value="-compile=false -status -linemap=NO -db2optimize"/>
<!-- specify the db2jcc.jar location to be included in the db2sqljcustomize classpath --> <property name="db2sqljcustomize.cp" value="/usr/lpp /db2/db2810/jcc/classes/db2jcc.jar":./SRC:/usr/lpp/db2810/jcc/ classes/db2jcc_license_cisuz.jar"/ > <!-- specify global property arguments below for db2sqljcustomize --> <property name="db2sqljcustomize.arg" value='-automaticbind NO -onlinecheck YES -staticpositioned YES -bindoptions "ISOLATION(CS)" -genDBRM'/> <!-- Below is the temporary property file name to be passed to a User property routine for storing additional argument properties It requires no tailoring --> <property name="db2sqljcustomize.propfile" value="user.properties"/> <!-- Below is the name of an optional user program which will be run immediately before the db2sqljcustomize process. It dynamically updates a property file db2sqljcustomize.propfile to be used as input to the db2sqljcustomize command The db2sqljcustomize routine (property: sqlj.exec) will concatenate and use both argument properties set in this build.xml (db2sqljcustomize.arg) and the argument properties read from the user property file. The user routine will be passed the following arguments basedir : Base directory which is the workspace directory propfile : The name of the property file to create (temporary file to be created in workspace) sqljf : All the .ser file names to be processed by db2sqljcustomize Note: The property file being created needs to be basedir'/'propfile The properties should be set in the file in the following format argument=value (eg: singlepkgname=longname:pkgname) (one argument declaration per line) eg: singlepkgname=src/TeSQLJ986_SJProfile0.ser:SQLJ986 singlepkgname=src/TeSQLJ987_SJProfile0.ser:SQLJ987 pkgversion=1 url=jdbc:db2://site1.com:80/MVS01 qualifier=DBT If no User program is required specify : <property name="sqlj.userpgm" value="NONE"/> --> <property name="sqlj.userpgm" value="/u/userdir/BWBSQLD"/> *** end of property settings ***
Die Argumenteigenschaften werden verwendet, um die erforderliche Argumentzeichenfolge im Aufruf von SQLJ oder db2sqljcustomize zu erstellen. Beispiel:
db2sqljcustomize -automaticbind NO -collection ${db2.collid} -url ${db2.url} -user ${db2.user} -password ???????? -onlinecheck YES -qualifier ${db2.qual} -staticpositioned YES -pkgversion ${db2.packversion} -bindoptions "ISOLATION(CS)" -genDBRM -DBRMDir DBRMLIB -singlepkgname ${db2.pack}
* * LKED J2EEOBJ * J2EE Build translator * * Source to include in build * INCLD XX000001 ASTSQLJ * .classpath INCLD XX000002 ASTSQLJ * .project INCLD XX000103 ASTSQLJ * .runtime INCLD BU000082 ASTSQLJ * build.xml INCLD DE000155 ASTSQLJ * deploy.xml INCLD SQ000001 ASTSQLJ * SQLJAntScripts/sqlj.customize.xml INCLD SQ000002 ASTSQLJ * builder/sqlJava.java INCLD SQ000003 ASTSQLJ * builder/sqlJava.sqlj INCLD TE000137 ASTSQLJ * Tester.java INCLD SQ000004 ASTSQLJ * builder/sqlJava_SJProfile0.ser * * Build script and generated outputs * SINC ASTSQLJ J2EEBLD * J2EE JAR Build script OUT1 * J2EEJAR LIST * J2EELIST
<project name="ASTSQLJ" default="compile" basedir="."> <property name="AST_SHSCRIPT" value="BWBASTR"/> <property name="SCLM_ARCHDEF" value="ASTSQLJ"/> <property name="JAR_FILE_NAME" value="ASTSQLJ.jar"/> <!-- specify the JAVA bin runtime location --> <property name="JAVA_BIN" value="/u/java/J5.0/bin"/> <!-- specify the db2jcc.jar location to be included in the db2sqljcustomize classpath --> <property name="db2sqljcustomize.cp" value="/usr/lpp/products/db2/db2810/jcc/ classes/db2jcc.jar:.:/usr/lpp/products/db2/db2810/jcc/classes/ db2jcc_license_cisuz.jar"/> <!-- specify global property arguments below for sqlj processing --> <property name="sqlj.arg" value="-compile=false -status -linemap=NO -db2optimize"/> <!-- specify global property arguments below for db2sqljcustomize --> <property name="db2sqljcustomize.arg" value='-automaticbind NO -onlinecheck YES -bindoptions "ISOLATION(CS)" -genDBRM'/> <!-- specify the location of the db2sqljcustomize exec routine BWBSQLC --> <property name="db2sqljcustomize.exec" value="/u/SCLMDT/bwbsqlc.rex&cdqg;/> <!-- Below is the name of the user program to be run as part of the db2sqljcustomize process . It dynamically updates a property file to be used as input to the db2sqljcustomize command --> <property name="sqlj.userpgm" value="NONE"/> <target description="Pre-Compile SQLJ Files" name="sqlj"> <echo> SQLJ TRANSLATOR </echo> <apply executable="java" skipemptyfilesets="true" type="file" failonerror="true" logerror="true"> <arg line="-Dfile.encoding=ISO8859-1 -Xnoargsconversion"/> <arg line="sqlj.tools.Sqlj"/> <arg line="${sqlj.arg}"/> <!-- SER Files --> <fileset dir="."> <patternset> <include name="**/*.sqlj"/> </patternset> </fileset> </apply> </target> <target description="Customize SQLJ Files" name="db2sqljcustomize" depends="sqlj"> <!-- Below just echoes properties into a property file db2 props -> <apply executable="${db2sqljcustomize.exec}" skipemptyfilesets ="true" parallel="true" type="file" failonerror="true" relative="true"> <arg value="${basedir}"/> <arg value="${db2sqljcustomize.cp}"/> <arg value="${sqlj.userpgm}"/> <arg value="${db2sqljcustomize.propfile}"/> <arg value="db2sqljcustomize ${db2sqljcustomize.arg}"/> <arg value="sqlj-source"/> <!-- SER Files --> <fileset dir="."> <patternset> <include name="**/*.ser"/> </patternset> </fileset> </apply> </target> <target name="compile" depends="db2sqljcustomize"> <projectImport projectname=&odq;ASTSQLJ&cdqg; projectlocation="$WORKSPACE" /> <eclipse.refreshLocal resource=&odq;ASTSQLJ&cdqg;depth="infinite" /> <echo message="refresh done" /> <projectBuild ProjectName=&odq;ASTSQLJ&cdqg;failonerror="true" DebugCompilation="true" BuildType="full" /> <jar update="true" destfile="${JAR_FILE_NAME}"> <fileset dir="." excludes="**/*.java"/> </jar> </target> </project>
Standardmäßig wird der Java-Quellcode als ASCII in den USS-Arbeitsbereich kopiert, bevor die Kompilierungserstellungen ausgeführt werden. Dies gilt auch, wenn der Java-Quellcode in SCLM als EBCDIC gespeichert wird.
Wenn der Benutzer anfordert, dass Java-Quellcode in der Archivdatei (JAR) enthalten sein soll, wird der Quellcode standardmäßig in ASCII gespeichert. Es ist jedoch möglich, die Erstellungsscripts so zu konfigurieren, dass der Java-Quellcode in den Arbeitsbereich kopiert und im EBCDIC-Format kompiliert wird. Wenn Java-Quellcode eingeschlossen werden soll, wird dieser daher im EBCDIC-Format vorliegen.
Um den Java-Quellcode im EBCDIC-Format einzuschließen, müssen folgende Erstellungsscripts entsprechend geändert werden, und zwar folgendermaßen:
In WebSphere Application Server sind zahlreiche Musterprojekte vorhanden. Diese können entweder mithilfe von vorerstellten EARs implementiert werden oder mit einem ANT-Erstellungsprozess assembliert werden. An dieser Stelle finden Sie ein Beispiel für die Verwendung von SCLM Developer Toolkit zum Einchecken des Projekts in SCLM und Erstellen/Implementieren unter z/OS. Dabei wird AST als Erstellungsprozess verwendet. PlantsByWebSphere ist ein J2EE-Projekt, mit dem ein Online-Einkaufsshop für Pflanzen eingerichtet wird. Es besteht aus den folgenden vier Komponenten:
In diesem Dokument wird ein Szenario beschrieben, bei dem diese Quelle in eine Eclipse-Projektstruktur eingefügt, in Developer Toolkit eingecheckt und auf dem Host erstellt und implementiert wird.
* * LKED J2EEOBJ * J2EE Build translator * * Source to include in build * INCL PLANTWE1 ARCHDEF INCL PLANTWE2 ARCHDEF INCL PLANTEJB ARCHDEF * INCLD XX000002 PLANTEAR * .project INCLD OR000005 PLANTEAR * .settings/org.Eclipse.wst.common.component INCLD OR000006 PLANTEAR * .settings/org.Eclipse.wst.common.project.fa * cet.core.xml INCLD BU000147 PLANTEAR * EarContent/build.xml INCLD BU000148 PLANTEAR * EarContent/Database/PLANTSDB/build.xml INCLD MA000028 PLANTEAR * EarContent/META-INF/MANIFEST.MF INCLD AP000004 PLANTEAR * EarContent/META-INF/application.xml INCLD IB000007 PLANTEAR * EarContent/META-INF/ibm-application-bnd.xmi INCLD IB000008 PLANTEAR * EarContent/META-INF/ibm-application-ext.xmi INCLD WA000004 PLANTEAR * EarContent/META-INF/was.policy INCLD PL000017 PLANTEAR * EarContent/Database/PLANTSDB/PLANTSDB.zip INCLD OR000001 PLANTEAR * .settings/org.Eclipse.core.resources.prefs INCLD SE000049 PLANTEAR * EarContent/META-INF/ibmconfig/cells/default * Cell/security.xml INCLD VA000001 PLANTEAR * EarContent/META-INF/ibmconfig/cells/default * Cell/applications/defaultApp/deployments/de * faultApp/variables.xml * * Build script and generated outputs * SINC PLANTEAR J2EEBLD * J2EE EAR Build script OUT1 * J2EEEAR LIST * J2EELIST
<project name="PBWProject" default="init" basedir="."> <property name="AST_SHSCRIPT" value="ASTRUN"/> <property name="SCLM_ARCHDEF" value="PLANTEAR"/> <property name="EAR_NAME" value="PlantsByWebSphere.ear"/> <target name="init"> <projectImport projectname="PBWProject" projectlocation="$WORKSPACE" /> <Eclipse.refreshLocal resource="PBWProject" depth="infinite" /> <echo message="refresh done" /> <projectBuild ProjectName="PBWProject" failonerror="true" DebugCompilation="false" BuildType="full" /> <earExport EARProjectName="PBWProject" EARExportFile="${EAR_NAME}"/> </target> </project>Für PLANTWE1 muss EJB sich zum Zeitpunkt der Erstellung im Klassenpfad befinden. Ändern Sie daher das Erstellungsscript von PLANTWE1, indem Sie eine Eigenschaft für CLASSPATH_JARS_FILES und den Wert "PlantsByWebSphereEJB.jar" hinzufügen.
#----------------------------------------------------------------- # # Sample JACL script for J2EE application deployment # #----------------------------------------------------------------- # # IBM SCLM Developer Toolkit uses the IBM WebSphere Application Server # wsadmin tool to deploy J2EE applications to WAS running on z/OS. The # wsadmin tool requires a JACL script to guide the deployment process. # Hence the JACL script must be installed under UNIX Systems services # (USS) before the deployment process can be invoked. # This sample JACL script should require no customization. source /u/WebSphere/V6R0/AppServer/samples/bin/AdminUtil.jacl proc ex1 {args} { #-------------------------------------------------------------- # set arguments #-------------------------------------------------------------- set app [lindex $args 0] set appName [lindex $args 1] set cellName [lindex $args 2] set nodeName [lindex $args 3] set serverName [lindex $args 4] #-------------------------------------------------------------- # set up globals #-------------------------------------------------------------- global AdminConfig global AdminControl global AdminApp #-------------------------------------------------------------- # -- was a earfile name supplied #-------------------------------------------------------------- if {[llength $app] == 0} { puts "deploy: Error -- No application specified." return } #-------------------------------------------------------------- # -- was the appname supplied #-------------------------------------------------------------- if {[llength $appName] == 0} { puts "deploy: Error -- Application name not specified." return } #-------------------------------------------------------------------- # Create J2C Resource Adapter #-------------------------------------------------------------------- createJ2CResourceAdapter $nodeName $serverName #-------------------------------------------------------------------- # Setup security cell #-------------------------------------------------------------------- set secAuthAlias "$cellName/samples" set secDescript "JAAS Alias for WebSphere Samples" set secUserID "samples" set secPassword "s1amples" createJAASAuthenticationAlias $cellName $secAuthAlias $secDescript $secUserID $secPassword #-------------------------------------------------------------------- # Create JDBC Provider #-------------------------------------------------------------------- set templName "Cloudscape JDBC Provider (XA)" # All Samples that need JDBC Provider should use/share this one set provName "Samples Cloudscape JDBC Provider (XA)" createJDBCProvider $nodeName $serverName $templName $provName #-------------------------------------------------------------------- # Create Datasource #-------------------------------------------------------------------- set templName "Cloudscape JDBC Driver XA DataSource" set dsName "PLANTSDB" set dsJNDI "jdbc/PlantsByWebSphereDataSource" set dsDesc "Data source for the Plants by WebSphere entity beans" set dsAuthMech "BASIC_PASSWORD" set dbName "\${APP_INSTALL_ROOT}/\${CELL}/PlantsByWebSphere.ear/ Database/PLANTSDB" set secAuthAlias "N_O_N_E" set connAttrs "upgrade=true" createDatasource $nodeName $serverName $provName $templName $dsName $dsJNDI $dsDesc $dsAuthMech $dbName $secAuthAlias $connAttrs #-------------------------------------------------------------------- # Create Connection Factory (use builtin_rra) #-------------------------------------------------------------------- set dsName "PLANTSDB" set cfName "PLANTSDB_CF" set cfAuthMech "BASIC_PASSWORD" set secAuthAlias "N_O_N_E" set cfi "javax.resource.cci.ConnectionFactory" createConnectionFactory $nodeName $serverName $provName $dsName $cfName $cfAuthMech $secAuthAlias $cfi #-------------------------------------------------------------------- # Create Mail Session #-------------------------------------------------------------------- set provName "Built-in Mail Provider" set msName "PlantsByWebSphere Mail Session" set jndiName "mail/PlantsByWebSphere" set mailTransportHost "yourcompany.ComOrNet" set mailFrom "userid@yourcompany.ComOrNet" createMailSession $cellName $nodeName $provName $msName $jndiName $mailTransportHost $mailFrom #-------------------------------------------------------------- # Setup options for the deployment # Additinal options can be added here as required # For Example: # lappend app_options -update # lappend app_options -appname MyAppName # lappend app_options -contextroot MyAppName # lappend app_options -preCompileJSPs # lappend app_options -defaultbinding.force # for a full list of options please use the AdminApp command # wsadmin [return] # $AdminApp options - generic options # or # $AdminApp options MyApp.ear - valid options for your ear file # lappend app_options -node WXP-KEFA25B #-------------------------------------------------------------- puts "deploy: installing the application" set app_options [list -server $serverName] lappend app_options -node $nodeName lappend app_options -verbose lappend app_options -usedefaultbindings lappend app_options -deployejb lappend app_options -deployejb.dbtype DERBY_V10 #-------------------------------------------------------------- # Install the application onto the server #-------------------------------------------------------------- $AdminApp install $app $app_options #-------------------------------------------------------------- # Save all the changes #-------------------------------------------------------------- puts "deploy: saving the configuration" $AdminConfig save #-------------------------------------------------------------- # Start the installed application #-------------------------------------------------------------- puts "Starting the application..." set appManager [$AdminControl queryNames cell=$cellName, node=$nodeName,type=ApplicationManager, process=$serverName,*] $AdminControl invoke $appManager startApplication $appName puts "Started the application successfully..." puts "deploy: done." } #----------------------------------------------------------------- # Main #----------------------------------------------------------------- if { !($argc == 5) } { puts "deploy: This script requires 5 parameter: ear file name, application name, cell name, node name and server name" puts "e.g.: deploy /WebSphere/AppServer/installableApps/ jmsample.ear myapp1 myCell myNode myServer" } else { set application [lindex $argv 0] set appName [lindex $argv 1] set cellName [lindex $argv 2] set nodeName [lindex $argv 3] set serverName [lindex $argv 4] ex1 $application $appName $cellName $nodeName $serverName }
In diesem Abschnitt werden die Implementierungs- und Konfigurationsprobleme für den Aufruf und die Verwendung von SCLM über Build Forge dargestellt. Das Kapitel enthält Anpassungs- und Testmuster für SCLM-Erstellungen und -Umstufungen.
Der Build Forge-Konsolenserver befindet sich im Allgemeinen auf einer Clientplattform und muss mit einem SCLM-Serviceaufruf im Projektbereich der Konsole konfiguriert werden. Dieses SCLM-konfigurierte Projekt stellt beim Starten eine Verbindung mit dem Build Forge-Agentenserver unter z/OS her, der zuvor gestartet worden sein muss. Mit dem RDz Build Forge-Plug-in können Konsolenprojekte aus der RDz-Umgebung gestartet werden, indem eine Socketverbindung mit dem Konsolenserver hergestellt wird. Die Ausgabe aus abgeschlossenen Projektausführungen kann auch aus dem RDz-Build Forge-Plug-in innerhalb von RDz aufgerufen werden.
http://www-01.ibm.com/support/docview.wss?&rs=3099&uid=swg24016541
Um die richtige Plug-in-Version hochzuladen, führen Sie eine Aktualisierung von Ihrem Serverstandort aus (unter http://<Hostname_der_Konsole>/prism/eclipse/updateSite/site.xml).
Starten Sie den Build Forge-Agenten unter z/OS. Der Standardport für den Agenten ist 5555. Beispiel:
bfagent -s -f /install_directory/bfagent-7.1.1.007/src/bfagent.conf
start BF console -> go to servers select hostname (hostname:port) test connection (using z/OS id authentication)
Die Musterantwort lautet wie folgt:
Agent Test Initiated Host:hostname Port:5555 Agent Version: 7.1.1.007 Authentication: userid Platform: os/390 18.00 03 Functional Test: OK Agent Test Completed (Duration 9s) Set up a project in the BF console and run.
Die folgende Mindestkonfiguration wird benötigt, um SCLM-Funktionen in Build Forge zu aktivieren.
Diese Benutzer-ID muss eine gültige Benutzer-ID mit entsprechendem Kennwort für das z/OS-System sein, auf dem der Agent ausgeführt wird und auf dem Sie den SCLM-Service ausführen möchten. Die Zugriffsgruppe kann eine vorhandene Zugriffsgruppe oder Standardzugriffsgruppe sein, die auf dem Konsolenserver mit den entsprechenden Rechten gespeichert ist: Verwaltung -> Zugriffsgruppen.
Testen Sie die Verbindung mit dem Host, indem Sie auf Verbindung testen klicken. Dadurch wird ein Verbindungstest für den Serveragenten durchgeführt, der unter z/OS ausgeführt wird. Ein erfolgreicher Test sieht wie folgt aus:
Agent Test Initiated Host:pthisd1.au.ibm.com Port:5555 Agent Version: 7.1.1.007 Authentication: IBMUSER Platform: os/390 18.00 03 Functional Test: OK Agent Test Completed (Duration 9s)
Weisen Sie Ihrem Servernamen BF_NAME zu. (Beispiel: PTHISD1)
Konfigurieren Sie die folgenden SCLM DT-Umgebungsvariablen:
Nun müssen SCLM-Projekte für die verschiedenen SCLM-Serviceanforderungen konfiguriert werden. Die unten stehenden Muster gelten für SCLM-Erstellungs- und -Umstufungsservices. Diese sind im Allgemeinen die wichtigsten Services, die für die Build Forge-Jobplanung geeignet sind. Die Projektscriptmuster basieren auf dem Format SCLM XML API, das im SCLM Developer Toolkit Administratorhandbuch dokumentiert wird.
Das folgende Muster ist ein konfiguriertes Buildmuster, das in der Host-Dateigruppe SAMPLIB (BWBBFBLD) verteilt wird.
echo '<?xml version-"1.0"?>' > Build_input.txt echo '<SCLMDT-INPUT' >> Build_input.txt echo 'xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"' >> Build_input.txt echo 'xsi:noNamespaceSchemaLocation="sclmdt.xsd">' >> Build_input.txt echo '<SERVICE_REQUEST>' >> Build_input.txt echo '<service>SCLM</service>' >> Build_input.txt echo '<session>NONE</session>' >> Build_input.txt echo '<ispprof>HLQ.SCLMDT.ISPPROF</ispprof>' >> Build_input.txt echo '<sclmfunc>BUILD</sclmfunc>' >> Build_input.txt echo '<project>PROJECT</project>' >> Build_input.txt echo '<projdef>PROJDEF</projdef>' >> Build_input.txt echo '<member>MEMBER</member>' >> Build_input.txt echo '<group>GROUP</group>' >> Build_input.txt echo '<type>TYPE</type>' >> Build_input.txt echo '<repdgrp>DEVGRP</repdgrp>' >> Build_input.txt echo '<groupbld>BLDGRP</groupbld>' >> Build_input.txt echo '<bldmode>C</bldmode>' >> Build_input.txt echo '<bldlist>Y</bldlist>' >> Build_input.txt echo '<bldlstds>NONE</bldlstds>' >> Build_input.txt echo '<bldrept>Y</bldrept>' >> Build_input.txt echo '<bldscope>N</bldscope>' >> Build_input.txt echo '<bldmsg>Y</bldmsg>' >> Build_input.txt echo '<bldmsgds>NONE</bldmsgds>' >> Build_input.txt echo '<bldextds>NONE</bldextds>' >> Build_input.txt echo '</SERVICE-REQUEST>' >> Build_input.txt echo '<SCLMDT-INPUT>' >> Build_input.txt cat Build_input.txt | BWBXML >Build_output.txt cat Build_output.txt
Konfigurieren Sie das obige Muster für Ihr SCLM-Projekt sowie Gruppe, Typ, Member und Buildoptionen, wie in der SCLM DT-Anwendungsprogrammierschnittstelle im Abschnitt ANHANG C für Buildfunktionen angegeben.
Fügen Sie dieses konfigurierte Muster zum ersten Schritt im Projekt "SCLM Build sample1" hinzu.
Alle anderen Felder können den Standardwert beibehalten. (Dieser Schritt übernimmt die Haupt-Projektumgebungseinstellungen.)
Klicken Sie auf Projetke -> SCLM Build sample1 -> Projekt starten. Die Ausgabe der Erstellung wird in der Konsole unter VORGÄNGE -> Build-Tag zurückgegeben.
Die Anforderungs- und Antwortausgabe wird ebenfalls im z/OS Unix Systems Services-Verzeichnis gespeichert, das durch den in der Serverkonfiguration angegebenen PATH bestimmt wird. Im vorherigen Beispiel für Server PTHISD1 mit PATH=/u/IBMUSER/BUILDFORGE würden die Anforderungs- und Antwortdateien in folgendem Verzeichnis gespeichert werden:
/u/IBMUSER/BUILDFORGE/SCLM_Build1_sample/BUILD_1 : >ls Build_input.txt Build_output.txt
Die obigen Anforderungs- und Antwortdateien können im angepassten Erstellungsschritt umbenannt werden.
Die Schritte im vorherigen Abschnitt können repliziert werden, um ein SCLM-Umstufungsprojekt in Build Forge zu erstellen. Ersetzen Sie das Erstellungsscript durch ein Umstufungsscriptmuster im "COMMAND"-Bereich des Projekts. Das folgende Muster ist ein konfiguriertes Umstufungsmuster, das in der Host-Dateigruppe SAMPLIB (BWBBFPRM) verteilt wird.
echo '<?xml version="1.0"?>' > Promote_input.txt echo '<SCLMDT-INPUT' >> Promote_input.txt echo 'xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"' >> Promote_input.txt echo 'xsi:noNamespaceSchemaLocation="sclmdt.xsd">' >> Promote_input.txt echo '<SERVICE-REQUEST>' >> Promote_input.txt echo '<service>SCLM</service>' >>Promote_input.txt echo '<session>NONE</session>' >>Promote_input.txt echo '<ispprof>HLQ.SCLMDT.ISPPROF</ispprof>' >>Promote_input.txt echo '<sclmfunc>PROMOTE</sclmfunc>' >>Promote_input.txt echo '<project>PROJECT</project>' >>Promote_input.txt echo '<projdef>PROJDEF</projdef>' >>Promote_input.txt echo '<member>MEMBER</member>' >>Promote_input.txt echo '<group>GROUP</group>' >>Promote_input.txt echo '<type>TYPE</type>' >>Promote_input.txt echo '<repdgrp>DEVGRP</repdgrp>' >>Promote_input.txt echo '<groupprm>PRMGRP</groupprm>' >>Promote_input.txt echo '<prmmode>C</prmmode>' >>Promote_input.txt echo '<prmrept>Y</prmrept>' >>Promote_input.txt echo '<prmscope>N</prmscope>' >>Promote_input.txt echo '<prmmsg>Y</prmmsg>' >>Promote_input.txt echo '<prmmsgds>NONE</prmmsgds>' >>Promote_input.txt echo '<prmextds>NONE</prmextds>' >>Promote_input.txt echo '</SERVICE-REQUEST>' >>Promote_input.txt echo '</SCLMDT-INPUT>' >>Promote_input.txt cat Promote_input.txt | BWBXML >Promote_output.txt cat Promote_output.txt
Konfigurieren Sie das obige Muster mit Ihren entsprechenden Angaben für SCLM-Projekt, Gruppe, Typ, Member und Umstufungsoptionen, wie in Anhang C. SCLM Developer Toolkit-API zur Umstufungsfunktion angegeben.
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 zuständigen 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. Anstelle der Produkte, Programme oder Services können auch andere ihnen äquivalente Produkte, Programme oder Services verwendet werden, solange diese keine gewerblichen oder andere Schutzrechte der IBM verletzen. Die Verantwortung für den Betrieb der Produkte, Programme oder Dienstleistungen in Verbindung mit Fremdprodukten und Fremddienstleistungen liegt beim Kunden, soweit nicht ausdrücklich solche Verbindungen erwähnt sind.
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 hier enthaltenen Informationen werden in regelmäßigen Zeitabständen aktualisiert und als Neuausgabe veröffentlicht. 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 werden lediglich als Service für den Kunden bereitgestellt 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ängig voneinander erstellten Programmen und anderen Programmen (einschließlich des vorliegenden Programms) sowie (ii) die gemeinsame Nutzung der ausgetauschten Informationen zu ermöglichen, wenden sich an folgende Adresse:
Die Bereitstellung dieser Informationen kann unter Umständen von bestimmten Bedingungen - in einigen Fällen auch von der Zahlung einer Gebühr - abhängig sein.
Die Lieferung des im Dokument aufgeführten Lizenzprogramms sowie des zugehörigen Lizenzmaterials erfolgt auf der Basis der IBM Rahmenvereinbarung bzw. der Allgemeinen Geschäftsbedingungen von IBM, der IBM Internationalen Nutzungsbedingungen für Programmpakete oder einer äquivalenten Vereinbarung.
Alle in diesem Dokument enthaltenen Leistungsdaten stammen aus einer kontrollierten Umgebung. Die Ergebnisse, die in anderen Betriebsumgebungen erzielt werden, können daher erheblich von den hier erzielten Ergebnissen abweichen. Einige Daten stammen möglicherweise von Systemen, deren Entwicklung noch nicht abgeschlossen ist. Eine Gewährleistung, dass diese Daten auch in allgemein verfügbaren Systemen erzielt werden, kann nicht gegeben werden. Darüber hinaus wurden einige Daten unter Umständen durch Extrapolation berechnet. Die tatsächlichen Ergebnisse können davon abweichen. Benutzer dieses Dokuments sollten die entsprechenden Daten in ihrer spezifischen Umgebung prüfen.
Alle Informationen zu Produkten anderer Anbieter stammen von den Anbietern der aufgeführten Produkte, deren veröffentlichten Ankündigungen oder anderen allgemein verfügbaren Quellen. IBM hat diese Produkte nicht getestet und kann daher keine Aussagen zu Leistung, Kompatibilität oder anderen Merkmalen machen. Fragen zu den Leistungsmerkmalen von Produkten anderer Anbieter sind an den jeweiligen Anbieter zu richten.
Aussagen über Pläne und Absichten von IBM unterliegen Änderungen oder können zurückgenommen werden und repräsentieren nur die Ziele von IBM.
Diese Veröffentlichung enthält Beispiele für Daten und Berichte des alltäglichen Geschäftsablaufes. Sie sollen nur die Funktionen des Lizenzprogramms illustrieren; sie können Namen von Personen, Firmen, Marken oder Produkten enthalten. Alle diese Namen sind frei erfunden; Ähnlichkeiten mit tatsächlichen Namen und Adressen sind rein zufällig.
Diese Veröffentlichung enthält Musteranwendungsprogramme, die in Quellensprache geschrieben sind und Programmiertechniken in verschiedenen Betriebsumgebungen veranschaulichen. Sie dürfen diese Musterprogramme kostenlos kopieren, ändern und verteilen, wenn dies zu dem Zweck geschieht, Anwendungsprogramme zu entwickeln, zu verwenden, zu vermarkten oder zu verteilen, die mit der Anwendungsprogrammierschnittstelle für die Betriebsumgebung konform sind, für die diese Musterprogramme geschrieben werden. Diese Beispiele wurden nicht unter allen denkbaren Bedingungen getestet. Daher kann IBM die Zuverlässigkeit, Wartungsfreundlichkeit oder Funktion dieser Programme weder zusagen noch gewährleisten. Die Musterprogramme werden auf der Grundlage des gegenwärtigen Zustands (auf "as-is"-Basis) und ohne Gewährleistung zur Verfügung gestellt. IBM haftet nicht für Schäden, die durch die Verwendung dieser Musterprogramme entstehen.
IBM, das IBM Logo und ibm.com sind Marken oder eingetragene Marken von International Business Machines Corp. in den USA und/oder anderen Ländern. Andere Produkt- und Servicenamen können Marken von IBM oder anderen Unternehmen sein. Eine aktuelle Liste der IBM Marken finden auf der Webseite www.ibm.com/legal/copytrade.shtml.
Rational ist eine Marke der International Business Machines Corporation und der Rational Software Corporation in den USA und/oder anderen Ländern.
Intel, das Intel-Logo, Intel Inside, das Intel Inside-Logo, Intel Centrino, das Intel Centrino-Logo, Celeron, Intel Xeon, Intel SpeedStep, Itanium und Pentium sind Marken der Intel Corporation in den USA und/oder anderen Ländern.
Microsoft, Windows und das Windows-Logo sind Marken oder eingetragene Marken der Microsoft Corporation in den USA und/oder anderen Ländern.
Java und alle auf Java basierenden Marken und Logos sind Marken oder eingetragene Marken von Sun Microsystems, Inc. in den USA und/oder anderen Ländern.
UNIX ist eine eingetragene Marke von The Open Group in den USA und anderen Ländern.