Rolf Becking

30. November 2017

Arbeiten mit Visual COBOL 3.0 for Eclipse

• Konzept der Eclipse IDE und Konsequenzen für die Arbeitsweise

• Wann ist Eclipse die „richtige“ IDE für Visual COBOL?

• Muss ich unbedingt ein Projekt anlegen?

• Vom einfachen zu komplexeren Projekten, Remote Projekte

• Unterschiede managed/unmanaged Code

• Konfiguration: wo stellt man was ein?

• Highlights: neue Features in Visual COBOL 3.0

• Fragen …

Unsere Themen im heutigen Webinar

• Eclipse ist aus einem Projekt bei der IBM entstanden

• IBM Visual Age for Java

• Ziel: Erstellen einer integrierten Entwicklungsumgebung für Java

• Quellcode wurde später von IBM als Open Source freigegeben

• Die Eclipse Foundation ist jetzt für die weitere Entwicklung verantwortlich (https://www.eclipse.org/org/foundation/)

• Eclipse ist außer für die Java-Entwicklung für die Verwendung unterschiedlicher Programmiersprachen ausgelegt

Konzept der Eclipse IDE

• Visual COBOL for Eclipse ist ein Eclipse Plugin zur Entwicklung von Anwendungen mit Visual COBOL

• Editor, Compiler, Debugger, …

• Das Installationspaket von Visual COBOL for Eclipse wird mit einer Eclipse IDE ausgeliefert

• Aktuell Eclipse 4.6 (64bit) (Neon)

• Auch andere Eclipse Versionen können per Plugin Installation genutzt werden (4.4.1, 4.4.2, 4.5 und 4.6 (32bit))

Konzept der Eclipse IDE

• Eclipse ist die „richtige“ IDE …

• Wenn nicht ausschließlich für die Windows-Welt entwickelt wird

• Zugriff auf alle unterstützten Unix/Linux-Plattformen über Remote Projekte

• … aber natürlich auch Entwicklung für Windows unter Windows möglich

• Wenn die Java-Technologie genutzt werden soll oder eine Integration der COBOL-Applikationen in die Java-Welt geplant ist

• Wenn die .NET-Technologie nicht von Interesse ist

• Ansonsten ist die Frage Eclipse oder Visual Studio mehr eine Frage persönlicher Präferenzen

Ist Eclipse die “richtige” IDE für mich?

• Eclipse arbeitet grundsätzlich mit Projekten

• Eclipse Projekte werden in einem sogenannten „Workspace“ verwaltet, einem (lokalen) Verzeichnis

• Lokale Projekte werden innerhalb des Workspace Ordners angelegt

• Pro Projekt ein separates Verzeichnis!!!

• Remote Projekte liegen auf dem Remote System• Existieren im lokalen Workspace nur als implizite Verweise

Konzept der Eclipse IDE

• Besteht eine Anwendung aus unterschiedlichen Programmier-sprachen, so ist für jede Sprache ein Projekt erforderlich

• Auf Projektebene werden dann zur Bearbeitung der Programme die entsprechenden Tools geladen

• Editor, Compiler, Debugger

• Dies ist insbesondere für die Kombination von COBOL und Java der Fall

• Ein Java-Projekt und ein COBOL JVM Projekt

• Referenzen für Aufrufe auf das jeweilige Projekt erforderlich

Konzept der Eclipse IDE

• Nein, Visual COBOL 3.0 for Eclipse kann auch ein einzelnes Programm laden, editieren, compilieren und sogar ausführen, auch im Debugger

• Hat man allerdings mehrere Programme zu bearbeiten, kommt man ohne Projekte nicht wirklich zurecht

• Das Arbeiten mit Eclipse Projekten ist nicht so kompliziert, wie es auf den ersten Blick erscheinen mag

Muss ich unbedingt ein Projekt anlegen?

• Auch die Frage, wie ein Projekt gebaut (Build) werden soll, wird auf Projektebene festgelegt

• Unterschiedliche Ausgabeformate in separaten Projekten erzeugen

• Eine Mischung aus .exe, .dll und .gnt würde drei verschiedene Projekte erforderlich machen

• Dies ist mit ein Grund, warum das Importieren von Net Express Projekten nicht empfohlen wird, zumindest nicht in jedem Fall

• Kann zu sehr vielen unterschiedlichen Eclipse-Projekten führen

• Auch unterschiedliche Compiler-Direktiven können ein Grund für mehrere Projekte sein

Konzept der Eclipse IDE

• Verzeichnisstruktur: Workspace-Verzeichnis

• Projekt1

• New_Configuration.bin

• Projekt2

• New_Configuration.bin

• Projekt3

• New_Configuration.bin

Konzept der Eclipse IDE

• Die IDE trennt klar zwischen Sourcen und Build-Artefakten (.exe, .dll) und speichert diese in separaten Verzeichnissen

• Auf der Projektebene werden alle projekt-spezifischen Einstellungen vorgenommen

• 32/64 bit, Ausgabeformat, Compiler-Direktiven, Anweisungen für den Linker

• Eclipse kann direkt mit Software Configuration Tools zusammenarbeiten (Subversion, Git, …)

Konzept der Eclipse IDE

• Das Hinzufügen von Sourcen bedeutet in der Regel das Laden der Sourcen aus einem solchen Repository

• Aber auch Sourcen, die nicht in einem Repository abgelegt sind, können auf unterschiedliche Weise in das Projekt aufgenommen werden

• Dabei werden die Sourcen in der Regel in das Projekt-verzeichnis kopiert, können aber auch als Link hinzugefügt werden (direkter Zugriff auf ursprünglichen Speicherort)

Konzept der Eclipse IDE

• COBOL-Sourcen zum Projekt hinzufügen:

• Dazu gibt es (mindestens) drei verschiedene Vorgehensweisen:

• Source-Dateien im Windows Explorer markieren und kopieren und in der Eclipse IDE im COBOL-Explorer einfügen (copy and paste).

• Dann – falls erforderlich - die Funktion „Refresh“ im Projekt-Menü aufrufen (rechte Maustaste auf dem Projekt-Namen)

• Source-Dateien im Windows Explorer in das Projekt-Verzeichnis kopieren und dann die Funktion „Refresh“ im Projekt-Menü aufrufen (rechte Maustaste auf dem Projekt-Namen)

Konzept der Eclipse IDE: Projektaufbau

13

• Oder…

• Import-Funktion im Projekt-Menü:

• Import

• Import

• General

• File System

• Oder aus Software Repository über

• Team, Git, ….

Konzept der Eclipse IDE: Projektaufbau

14

• Eclipse ist nicht dafür konzipiert, Programme und/oder Projekte zwischen verschiedenen Entwicklern zu teilen!!!

• Sourcen gehören in ein Repository, aus dem die Entwickler sie entleihen können

• Jeder Entwickler hat seinen eigenen (lokalen) Workspace und exklusiv von ihm verwendete Projekte

• Koordination erfolgt über das Repository

• Ermöglicht die Nachvollziehbarkeit, Versionskontrolle, etc.

Konzept der Eclipse IDE

• Mehrere Programme können zu einer .exe-Datei zusammen gelinkt werden

• Start-Programm angeben!

• Es können auch alle Programme zu einzelnen Executablesgeneriert werden, aber auch zu .dlls oder int/gnt

• Auch diese können direkt unter Kontrolle des Debuggers ausgeführt werden

Arbeiten mit Projekten

• Die Mischung verschiedener Ausgabeformate in einer Anwendung macht es erforderlich, mehrere Projekte für die Anwendung anzulegen

• Eine Anwendung kann aber auch aus anderen Gründen in mehrere Projekte unterteilt werden

• Wegen der Verzeichnisstruktur von Eclipse Projekten können weitere Konfigurationsschritte erforderlich sein, um der Anwendung alle Teile zur Verfügung zu stellen

Arbeiten mit Projekten

• Dazu bieten sich die folgenden Möglichkeiten an:

• Definition eines gemeinsamen Ausgabepfades für alle Projekte über einen Linked Folder

• Nicht zu empfehlen, da das Ausgabeverzeichnis bei einem kompletten Buildoder Clean des Projekts gelöscht wird!

• Unter den Projekteigenschaften Micro Focus / Build Configuration / Events im Post-build Event die Ausgaben der jeweiligen Projekte in ein gemeinsames Verzeichnis kopieren

• Neu: benötigte Projekte zum Micro Focus / Build Path / Projects addieren

Arbeiten mit Projekten

• Remote Projekte liegen auf einem entfernten Unix/Linux-System (Sourcen, Copy-Dateien, …)

• Die Programme werden auf dem entfernten System compiliert, gelinkt und ausgeführt bzw. gedebugged

• Die Steuerung erfolgt aus der lokalen Eclipse IDE

• Verbindung über Samba/NFS oder RSE (Eclipse Framework)

• RSE mit SSH ist die bevorzugte Verbindungstechnik

• Arbeiten wie mit lokalen Projekten!

Arbeiten mit Remote Projekten

• Moderne Cross-Plattform Entwicklung für COBOL

20

Visual COBOL® Remote Projekte

Visual COBOL® Development Hub für Linux u. UNIX- Standalone Compile und Debug-

Umgebung- Source Code, Datendateien etc.,

verbleiben auf der Zielplattform-

Visual COBOL® for Eclipse- Eclipse IDE auf Windows-/Linux-Desktop

für maximale Leistung- Lokale oder Remote Projekte

• Debug Configurations unterstützen alle Funktionen des Debuggers mit unterschiedlichen Konfigurationstypen

• COBOL Application

• COBOL Attach to Process

• COBOL Coredump

• COBOL Unit Test

• COBOL Wait for Application Attachment

• und spezielle Konfigurationen für Enterprise Server und COBOL JVM Applikationen

Debug Configurations

• Diese beziehen sich immer auf ein Projekt

• Sourcen, Copy-Dateien und Debug-Informationen (.idy) werden aus dem Projekt geladen

• Programme, die nicht im aktuellen Projekt liegen, aber bei der Ausführung der Applikation geladen werden, können ebenfalls jederzeit gedebugged werden

• Unter den Tabs für „Source“ und „Debug Symbols“ die Verzeichnisse der Source- und Copy-Dateien sowie der .idy-Dateien angeben

Debug Configurations

• Managed Code Projekte im Eclipse-Umfeld sind COBOL JVM Projekte

• Compilierung von COBOL zum Java Bytecode

• Um diese von Java aus aufzurufen, sind Referenzen aus dem Java Projekt auf die entsprechenden COBOL JVM Projekte erforderlich

• Diese müssen vorab erfolgreich compiliert („Build“) worden sein und im Java Projekt unter „Project References“ angegeben werden

Arbeiten mit Projekten: Managed Code

• 32/64 bit-Default konfigurierbar

• Window / Preferences / Micro Focus / Builder

• Default Platform Target

• Parallele Compilierung auf multi-prozessor Maschinen

• Aktivieren unter Window / Preferences / Micro Focus / Builder

• Maximum number of compilations to execute concurrently

• Refactoring

• Umbenennen einer Variablen im Programm oder

• Extrahieren der Variablen in eine Copy-Datei

Arbeiten mit der Eclipse IDE: Neu in Version 3.0

DEMO

Arbeiten mit Visual COBOL 3.0 for Eclipse

Nächste Schritte

Kostenlose Testversion herunterladen oderUpdate auf Version 3.0 für Visual COBOL Kunden

microfocus.com/VIsualCOBOL

Arbeiten mit Visual COBOL 3.0

for EclipseVielen Dank für Ihre Aufmerksamkeit!

Fragen?