proetcon.de > Software-Migration > CoJaC > Migrationsaspekte
CoJaC Migrationsaspekte FAQ Testkonvertierung Download
[CoJaC]

MIGRATIONSPFADE

Die nachfoldende Tabelle zeigt beispielhaft die Migrationspfade der Basiskomponenten in das entsprechende Migrationsziel auf.

Basissystem Zielsystem
COBOL
(COBOL85, IBM, MFC, ...)
Java 1.6
Middleware
(Tuxedo, Pathway, CICS, ...)
Java-Webservices
Files Relationale Datenbank
Embedded SQL
(Oracle, DB2, ...)
Dynamisches SQL
(Oracle, DB2, MS SQL Server, ...)
DOWNLOAD
[PDF] CoJaC-Datenblatt
[PDF] "BEST OF 2012"-Zertifikat
[PDF] FAQ zur COBOL-Java-Migration
[PDF] Success Story ITZBund
[Basis- und Zielsystem]

ARCHITEKTURMIGRATION

Die Migration geht weit über eine reine Programmtransformation hinaus und beinhaltet ebenso eine Architekturmigration:
  • Online-Programme (Server) werden als Webservices im Java-Zielsystem bereitgestellt.
  • COBOL-Batch-Programme werden in autonome Java-Programme transformiert (1:1-Migration).
Die nebenstehende Grafik skizziert beispielhaft die Architektur einer typischen COBOL-Applikation und das daraus resultierende Java-Zielsystem.

CoJaC-LAUFZEITSYSTEM

[Beispiele für die Nutzung des Java-Laufzeitsystems]
Beispiele für die Anwendung des CoJaC-Laufzeitsystems
Das Laufzeitsystem stellt in der Java-Zielumgebung Klassen für die Abarbeitung der migrierten Programme zur Verfügung. Dazu gehören Klassen für die COBOL-Datentypen (numerische und alphanumerische Daten) und Basisklassen für Arrays und Strukturen. Weiterhin existieren Methoden, welche die Funktionalität solcher COBOL-Anweisungen implementieren, für die in Java keine native Anweisungen existieren (z.B. STRING und INSPECT). Weitere Bestandteile sind statische Methoden zur Abbildung der Intrinsic Functions, Methoden für die Typkonvertierung und Klassen, welche die Funktionalität der Schnittstellen (Files, SQL, Middleware) bereitstellen. Das Laufzeitsystem bildet die Grundlage für einen kompakten, wartbaren Java-Code.
[Beispiel für Migration in Webservices]
Beispiel für die Middleware-Migration

MIDDLEWARE-MIGRATION

COBOL-Server, die unter der Steuerung einer Middleware (eines Transaktionsmonitors) arbeiten, werden von CoJaC optional in Java-Webservices übersetzt. Dabei werden Middleware-spezifische Daten und Anweisungen entfernt bzw. durch entsprechende Webservice-Funktionalität ersetzt. Die Schnittstelle ändert sich dabei inhaltlich nicht. Die Webservices verarbeiten die gleichen Messages wie vorher die COBOL-Server. Notwendige Konvertierungen kapselt das Laufzeitsystem, welches auch die Verwaltung der Transaktionen übernimmt.

FILE-MIGRATION

[Beispiel für Konvertierung der Files]
Beispiel für die File-Migration
Die in COBOL verwendeten Datenfiles werden bei der Migration nach Java in Datenbanktabellen umgesetzt. Dabei werden die verschiedenen Organisationsformen und Zugriffsmethoden berücksichtigt. Die Struktur der Tabellen leitet sich aus der Datensatzstruktur ab, welche dem File über die FD-Struktur in der FILE SECTION zugeordnet ist. Das Laufzeitsystem kapselt die Datenbankzugriffe und stellt Methoden bereit, welche die COBOL-Anweisungen zur File-Arbeit (OPEN, READ, READ NEXT, CLOSE, ...) abbilden. Durch die Migration der Files in Datenbanktabellen werden die Daten auch für andere Anwendungen und Werkzeuge zugänglich gemacht.
[Beispiele für die Konvertierung von Embedded SQL]
Beispiele für die Migration von Embedded SQL

MIGRATION VON EMBEDDED SQL

Statische SQL-Anweisungen, die in den COBOL-Quelltext eingebettet sind, werden von CoJaC in dynamische SQL-Anweisungen konvertiert. In das Java-Laufzeitsystem wurden Methoden zur Verwaltung der Datenbankverbindung, zum Datenbankzugriff, zum Lesen und Schreiben von Daten in die Hostvariablen sowie zur Fehlerbehandlung integriert, welche die im Basissystem vorhandene Funktionalität abbilden. Mit dem Übergang zu dynamischem SQL sind erfahrungsgemäß keine Laufzeitnachteile verbunden. Gleichzeitig wird die flexible Erstellung und Änderung von SQL-Anweisungen ermöglicht.

MIGRATION DER MASKEN

[Beispiel für die Migration der Masken mit MaTriX]
Beispiel für die Migration der Masken mit MaTriX
Für die Maskenmigration existieren je nach Kundenanforderung verschiedene, optionale Möglichkeiten:
  1. Beibehalten der existierenden Masken: Da die Schnittstelle zu den migrierten Webservices inhaltlich unverändert bleibt, können die Clients bis auf einige geringe technische Anpassungen unverändert beibehalten werden. Für den Anwender ist die Migration dann transparent.
  2. Automatisierte Migration: Die Masken können mit unserem Tool MaTriX automatisiert in Web2.0-basierte Oberflächen konvertiert werden.
  3. Neuentwicklung: Die Masken können je nach Kundenanforderung z.B. als Java Server Pages (JSP) neu entwickelt werden.