Mit dem IBM® SCLM Developer Toolkit können Sie nicht nur einen Build für Komponenten in z/OS-Hostsprache, sondern auch für Java™- und J2EE-Projekte erstellen. Für eine adäquate Nutzung dieser Services müssen Sie verstehen, wie die SCLM-Buildverarbeitung
funktioniert.
Für Hostsprachen werden noch immer die Standard-SCLM-Build-Umsetzerservices verwendet.
Die Buildumsetzer für Java/J2EE
sind jedoch nicht Teil des Standardprodukts SCLM, sondern im Lieferumfang des SCLM
Developer Toolkit enthalten. Diese Umsetzer müssen in die Definition aller SCLM-Projekte aufgenommen werden, aus denen
J2EE-Anwendungen erstellt werden sollen.
Anmerkung: Der SCLM-Administrator sollte sich im SCLM
Developer Toolkit Installation and Customization Guide informieren, wie SCLM für Java/J2EE-Anwendungen anzupassen ist.
Ein Build für Host-Member kann direkt oder unter Verwendung einer ARCHDEF mit Standard-SCLM-Build-Umsetzern
erstellt werden. Das SCLM Developer
Toolkit stellt eine SCLM-Ansicht bereit, in der Sie
SCLM-Services, einschließlich Build-Services, für SCLM-Member ausführen können. Auf diese Weise kann die Fernentwicklung
hostbasierter Sprachen und Anwendungen von derselben Eclipse-Workbench unterstützt werden. Der Explorer-Modus und der Entwicklermodus des
Developer Toolkit stellen hierfür eine Art fernes Portal
zu SCLM bereit, das die Eclipse-Schnittstelle benutzt. Anwendungen können auf dieselbe Weise und mit denselben Services wie auf der ISPF-Schnittstelle
erstellt werden. Hostentwickler werden demzufolge kaum Schwierigkeiten bei der Verwendung der SCLM-Services über diese Schnittstelle haben. Die SCLM-Build-Services für vorhandene Komponenten in Hostsprache
sind ausführlich in der Veröffentlichung
Software Configuration and Library Manager (SCLM) Guide and Reference beschrieben. Nachfolgend sind die verschiedenen verfügbaren
Buildeinstellungen beschrieben:
- Einstellungen für Buildmodus
- Sie können folgende Buildmodi angeben:
- Bedingt
- Bei einem bedingten Build werden alle geänderten oder von einer Veränderung an einem enthaltenen Abschnitt betroffenen Module kompiliert und verknüpft.
Die Verarbeitung wird beim ersten Buildfehler gestoppt.
- Erzwungen
- Bei einem erzwungenen Build werden alle Module kompiliert und verknüpft, ganz gleich, ob Sie für den Build erforderlich sind oder nicht.
- Bericht
- Bei einem Berichtsbuild wird ermittelt, was geschehen würde, wenn ein bedingter oder nicht
bedingter Build angefordert wird, ohne den Build tatsächlich zu erstellen.
- Nicht bedingt
- Bei einem nicht bedingten Build wird ähnlich wie beim bedingten Build die Verarbeitung aller Module auch bei Fehlern fortgesetzt.
- Informationen
- Gibt Informationen im XML-Format zurück, die die Umsetzer (z. B. Compiler) beschreiben, die für die Builderstellung für den ausgewählten Abschnitt
verwendet werden. Zu diesen Informationen gehören die Umsetzernamen, die angegebenen Optionen und die für die einzelnen Umsetzer
angelegten Dateigruppen. Wenn Sie diesen Modus mit einer Architekturdefinition verwenden, werden die Informationen für jedes Member zurückgegeben, für
das ein Build erstellt wird. In diesem Modus wird der Build nicht tatsächlich erstellt, ähnlich wie im Modus 'Bericht'.
Anmerkung: Bei der Java/J2EE-Buildverarbeitung ist das Verhalten im nicht bedingten Buildmodus möglicherweise nicht so genau vorhersagbar wie
bei Komponenten in Hostsprache. Dies hängt mit der Art der
Java/J2EE-Kompilierung und der Generierung von Archivdateien zusammen.
Für die
Java/J2EE-Buildverarbeitung sollten Sie den bedingten Modus nutzen. Auch im bedingten Modus werden alle Java-Kompilierungsfehler gemeldet.
- Buildbereich
- Sie können folgende Buildbereiche angeben:
- Beschränkt
- Es werden alle erforderlichen Module, die direkt von der angegebenen Architektur referenziert werden, kompiliert und verknüpft.
- Normal
- Es werden alle vom beschränkten Bereich abgedeckten Module sowie die übergeordneten Ada-Abhängigkeiten kompiliert und verknüpft.
- Untergeordnete Einheit
- Es werden alle vom normalen Bereich abgedeckten Module sowie die direkt referenzierten untergeordneten Ada-Abhängigkeiten kompiliert und verknüpft.
- Erweitert
- Es werden alle vom normalen Bereich abgedeckten Module sowie die über- und untergeordneten Ada-Abhängigkeiten kompiliert und verknüpft.
Anmerkung: Bei der Java/J2EE-Buildverarbeitung wird jeder ausgewählte Bereich interpretiert, als hätten Sie 'NORMAL' ausgewählt.
- Zusätzliche Einstellungen
- Sie können außerdem die folgenden Einstellungen angeben:
- Build für Gruppe
- Diese Einstellung gibt die SCLM-Gruppe an, in der der Build erstellt wird. (Wenn die Quelle beispielsweise in einer hierarchisch übergeordneten Testgruppe enthalten ist und Sie
für den Build Ihre hierarchisch niedrigere Entwicklungsgruppe ausgewählt haben, werden alle resultierenden Module/Objekte/Listen und Buildzuordnungen in Ihrer hierarchisch untergeordneten Entwicklungsgruppe
erstellt.)
- Nur Fehlerliste
- Mit dieser Einstellung können Sie angeben, ob alle Listenausgaben des Buildprozessors angezeigt werden sollen oder nur die für Umsetzerschritte, die mit einem
inakzeptablen Rückkehrcode abgeschlossen wurden. (Diese Ausgaben werden im Operationsprotokoll zurückgegeben.)
- Bericht erstellen
- Diese Einstellung gibt an, ob ein Buildbericht erstellt werden soll. Der Bericht wird im Operationsprotokoll zurückgegeben und in der
sequenziellen Datei gespeichert, die von der Einstellung
Name der Dateigruppe für Buildberichte referenziert wird, sofern diese Einstellung angegeben ist.
- Buildnachricht
- Ist diese Einstellung auf 'ja' gesetzt, werden Buildnachrichten im Operationsprotokoll zurückgeben oder, bei Anforderung eines Batch-Jobs, in der Batch-Ausgabe. Wenn der Name einer Dateigruppe für Buildnachrichten
angegeben ist, werden die Nachrichten auch in diese Dateigruppe aufgenommen.
- Name der Dateigruppe für Buildlisten
- Wenn dieser Name angegeben ist, werden die Buildlisten in die genannte Dateigruppe aufgenommen.
- Name der Dateigruppe für Build-Exits
- Wenn dieser Name angegeben ist, werden Nachrichten vom Build-Exit in die genannte Dateigruppe aufgenommen.
- Batch-Build
- Wählen Sie diese Einstellung aus, wenn Sie einen JES-Batch-Job (Build im Hintergrund) unter z/OS übergeben möchten, um die Buildanforderung zu verarbeiten. An den Client werden der Jobname und die Job-ID zurückgegeben. Falls in den SCLM-Vorgaben die Batch-Überwachung ausgewählt wurde, überwacht der
Developer Toolkit Client den Batch-Job und benachrichtigt Sie automatisch, wenn der Job beendet ist, so dass Sie die Jobausgabe zurück auf den Client abrufen können. Für die Dateianpassung des Batch-Build-Jobs werden die SCLM-Build-Skeletons auf dem Host genutzt. Zusätzlich können Sie im Builddialog
die Schaltfläche Jobkarten-JCL... auswählen, um eine Jobkarte einzugeben. Wenn Sie
Jobkarten-JCL... ausgewählt haben, können Sie die Jobkarte im Dialogfenster bearbeiten. Klicken Sie zum Speichern der Änderungen auf OK. Sie können auch Build-Jobkarten verwenden. Wenn Sie eine Standardjobkarte wiederherstellen möchten, nachdem Sie sie bearbeitet haben, speichern Sie eine leere Jobkarte, bearbeiten
Sie sie erneut, und klicken Sie auf Abrufen.
Dadurch wird die Standardjobkarte in dem Zustand wiederhergestellt, den sie bei der ersten Anzeige des Dialogfensters hatte.
Standard-Build-Jobkarten können in der Datei SITE.conf oder
in der Datei project.conf für Ihr SCLM-Projekt angegeben werden. Weitere Informationen zu dieser Konfigurationsdatei für die Systeminstallation bzw. das Projekt finden Sie im Abschnitt
'SITE and project-specific options' des SCLM Developer Toolkit
Installation and Customization Guide.
Bei der Buildverarbeitung für J2EE-Anwendungen
sollten Sie auf der Build-Jobkarte das Minimum für den Regionsparameter
(REGION=512M) angeben, um Fehler durch unzureichenden Speicher zu vermeiden.
Mit SCLM-Builds können Sie die gesamte Kompilierung und Linkbearbeitung für eine vollständige Anwendung oder Abschnitte einer Anwendung in nur einem Job durchführen.
Detaillierte Informationen zur Builderstellung für Java/J2EE-Anwendungen finden Sie im Abschnitt Build für Java/J2EE-Anwendungen erstellen.