COBOL-Anwendungen bilden heute in der Regel die Geschäftslogik ab, während für die Front-End-Systeme andere Technologien zum Einsatz kommen. Dabei haben sich in den letzten Jahren zahlreiche, recht unterschiedliche Techniken etabliert – von der Programmierung mit WinAPI über Object COBOL sowie die Einbindung anderer Programmiersprachen bis hin zu HTML. Jede dieser Techniken hat ihre Vor- und Nachteile, was dem Anwender die Möglichkeit gibt, seine Front-Ends ganz auf die eigenen Anforderungen auszurichten. Wer COBOL-Anwendungen mit dem alten Green Screen identifiziert, hat Recht und Unrecht zugleich. Einerseits hat sich COBOL aus der Programmierung von Bediener-Oberflächen schon seit längerem ausgeklinkt, insofern ist „Pure COBOL“ tatsächlich „Green COBOL“ – andererseits bedienen sich heutige COBOL-Anwendungen längst sämtlicher Technologien des modernen Oberflächenzaubers und sind daher „up to date“.

Zum dauerhaften Erfolg von COBOL als Programmiersprache hat nicht zuletzt beigetragen, dass bei ihrem praktischen Einsatz schon seit langem ein recht modernes Konzept angewendet wird: die Trennung von Geschäftslogik und Front-End-Systemen. Das Design von Dialogfenstern und Buttons hat COBOL anderen Programmiersprachen und -konzepten überlassen und sich stattdessen auf die Kernprozesse konzentriert. Hier, wo es um komplizierte Algorithmen geht, wo beispielsweise aufwändige versicherungsmathematische Zusammenhänge abgebildet werden, wo große Datenvolumen abzuarbeiten sind, ist COBOL in seinem eigentlichen Element – und hier lässt es sich hinsichtlich Performance, Stabilität und Verfügbarkeit auch nicht so leicht übertreffen. Die Abkopplung von der doch rascheren Wechseln unterworfenen Front-End-Technologie hat COBOL denn auch zu einer in der IT ungewöhnlichen Dauerhaftigkeit verholfen – die großen COBOL-Anwendungen der großen Unternehmen laufen oft schon seit zehn oder zwanzig Jahren erfolgreich.

Dieser Erfolg setzt auf der anderen Seite natürlich voraus, dass eine solche Technologie auch in der Lage sein muss, sich jeweiligen Neuerungen und Moden zu bedienen. Anders ausgedrückt: Dauerhaft können COBOL-Kernsysteme nur sein, weil sie problemlos mit den unterschiedlichsten Front-Ends zu Rande kommen. In der Tat steht heute eine breite Palette von Technologien bereit, mit denen COBOL-Applikationen ihren Kontakt zur Außenwelt aufnehmen können.

WinAPI – der direkte Weg

Front-End heißt heute GUI – und GUI bedeutet in den meisten Fällen, dass die Benutzer einer COBOL-Anwendung auf ihrem Bildschirm eine Windows-Oberfläche erwarten. Das lässt sich mit COBOL wie mit jeder anderen Programmiersprache am unmittelbarsten durch den direkten Aufruf von WinAPI-Funktionen realisieren. Mit dieser Technik kann der Entwickler Betriebssystem-Funktionen über eine definierte Schnittstelle ansprechen; zu diesen Funktionen gehören auch solche, die die Bildschirmdarstellung steuern. Die Dokumentation aller Aufrufe liegt in der WIN32-SDK-Referenz vor. WinAPI ist eine Microsoft-Technik und dementsprechend sind WinAPI-Aufrufe etwa für Visual Basic oder C recht einfach. Allerdings ist diese Schnittstelle keine spezielle COBOL-Schnittstelle, weshalb beispielsweise die Datentypen nicht COBOL-konform sind – Typen wie Icon oder Handle kennt COBOL nun mal nicht. Dementsprechend muss ein COBOL-Programm für WinAPI vorbereitet werden, wofür heute COBOL-Anbieter wie Micro Focus spezielle Typendefinitionen zur Verfügung stellen. Die Anweisung

01 int is typedef pic s9(09) comp-5

würde zum Beispiel festlegen, wie eine Integer-Variable von COBOL übernommen wird. Mit diesen Vorbereitungen können WinAPI-Funktionen aus COBOL per CALL-Befehl aufgerufen werden. Die Call-Convention regelt dabei die Konformität des vom COBOL-Compiler generierten Funktionsaufrufs zur Spezifikation der WinAPI- Schnittstelle bezüglich Namenskonventionen und der Art der Parameterübergabe:

Call Convention 74 is WINAPI

Die Abbildung der COBOL-Datentypen erfolgt dabei gemäß C-Konvention in der Working-Storage Section, wobei zu beachten ist, ob sie als Parameter „by value“ oder „by reference“ übergeben werden müssen. Auf diese Weise kann beispielsweise die Funktion CreateWindowsEx genutzt werden, die ein Fenster mit den üblichen, parametrisierten Eigenschaften wie Position, Höhe, Breite usw. aufbaut. Diese Funktion wird dann in der COBOL-Anwendung aufgerufen:

Call WinAPI CreateWindwosEx using
by value 0 Size Dword-Len
by reference App-ClassName
by reference App-WindowsTitle,
by value App-dwStyle
by value h“8000“ size Word-Len
by value 0 size Word-Len
…

Nicht zuletzt auf Grund der Vielzahl von WinAPI-Funktionen, die für die Gestaltung einer Dialogmaske erforderlich sind, ist die Anwendung dieser Technik sehr komplex. Sie erfordert einen hohen Verständnis- und Programmieraufwand. Andererseits stehen alle WinAPI-Aufrufe direkt zur Verfügung, es werden keine zusätzlichen Bibliotheken benötigt; auch deshalb bietet diese Technik eine sehr gute Performance. Außerdem steht das volle Spektrum der WinAPI zur Verfügung, also uneingeschränkt die gesamte Windows-Funktionalität, was bei vielen anderen Techniken nicht gegeben ist.

Object COBOL – der neue Ansatz

Die COBOL-Anbieter haben in der Vergangenheit immer wieder Techniken entwickelt, um den Programmierern die Erstellung von Windows-Oberflächen zu erleichtern, sie also von den hohen Anforderungen der WinAPI fernzuhalten. So hat Micro Focus schon in den 90er Jahren die objektorientierte Erweiterung Object COBOL entwickelt, die mittlerweile in den neuen COBOL-Standard COBOL 2002 eingegangen ist.

Während COBOL eine prozedurale Sprache ist, die ihre Anweisungen sequentiell abarbeitet, verfolgt Object COBOL naturgemäß einen ganz anderen Ansatz. Hier werden wie überall in der OOP-Welt Klassen, Objekte, Methoden usw. definiert – allerdings wird dafür die COBOL-Syntax verwendet. Object COBOL ist also eine Mischung aus OOP-Konzepten und COBOL-Sprachelementen. Damit ist zunächst einmal eine Kommunikation mit anderen objektorientierten Sprachen relativ einfach zu realisieren. Während es beispielsweise nicht möglich ist, mit einem „normalen“ COBOL-Call eine Methode aufzurufen, die Excel als OLE-Server zur Verfügung stellt, ist das in Object COBOL genauso einfach wie in Visual Basic. Die Gestaltung eines Front-Ends erfolgt dementsprechend, wie man es von OO-Sprachen gewohnt ist: die COBOL-Hersteller bieten die entsprechenden Klassenbibliotheken an, die der Entwickler in seine Applikationen einbindet.

Auch in COBOL werden in Klassen Daten und zugehörige Funktionalität zu einer Einheit zusammengefasst. Sie bestehen aus Daten und Methoden, also aus Funktionen, die mit diesen Daten arbeiten. Sie und werden im Programm deklariert; zum Beispiel so:

Class-control
SDIFrame is class „sdiframe“
CharacterArray is class „chararray“
OrderedCollection is class „ordrdcoll“
MenuBar is class „menubar“

Die Objekte sind die Realisierung eines konkreten Exemplars einer Klasse zur Laufzeit und bestehen aus den in der Klasse definierten Daten und Methoden. Ihre Verwaltung erfolgt über einen einmaligen Zugriffsschlüssel – die Objekt-Referenz.

Working storage section
wsEventManager object reference.
WsWindow object reference.

Die Codierung innerhalb von COBOL erfolgt durch das Registrieren der verwendeten Klassen,

EventManager is class „p2emgr“
MainWindows is class „MainWin“

das Erzeugen einer neuen Instanz der Klasse,

invoke MainWindows „new“ using wsDesktop
returning wsWindow

sowie den Zugriff auf die Methoden dieser Klasse.

invoke wsWindow „create“
invoke wsWindow „show“

Eine Mischung von prozeduralen und objektorientierten Programmteilen ist bei dieser Technik durchaus erlaubt, so dass sich Front- und Back-End-Programmierung sehr sauber verbinden lassen. Für den Einsatz dieser Technik ist entscheidend, dass sich die Entwickler in den OOP-Ansatz hineindenken; gerade für COBOL-Programmierer dürfte das die größte Hürde sein. Andererseits ist auch Object COBOL ein COBOL, man muss also keine neue Programmiersprache lernen. Wer OOP verstanden hat, tut sich mit diesem Ansatz auf jeden Fall leichter als mit der reinen WinAPI-Programmierung.

HTML für Ein-Schritt-Transaktionen

Eine sehr einfache Methode, eine COBOL-Anwendung mit einem grafischen Front-End zu versehen, bietet heute HTML. Der wichtigste Vorteil dabei ist, dass mit dem Web-Browser ein komplettes, universelles und standardisiertes Front-End-System zur Verfügung steht. Dieses System übernimmt alle Darstellungsfunktionen, während die eigentliche Applikation ganz Server-seitig arbeitet; Front-End und Back-End sind hier vollständig getrennt. Das Verfahren für die Verarbeitung von Daten in einer Browser-Anwendung ist mittlerweile bekannt und gilt auch für COBOL: Nach Eingabe einer Web-Adresse wird die HTML-Seite dem Benutzer angezeigt, er füllt die Maske aus und schickt sie am Schluss zum Web-Server, der über standardisierte Schnittstellen – wie CGI – das benötigte COBOL-Programm startet. Dieses übernimmt mit einer Accept-Anweisung die Daten aus der CGI-Schnittstelle in die jeweiligen COBOL-Datenfelder. Daran schließt sich die Verarbeitung gemäß der Geschäftslogik der Anwendung an. Die Ergebnisse werden mit einer Display-Anweisung dargestellt und dabei wieder per CGI nach außen gereicht; schließlich endet das COBOL-Programm mit „Stop Run“ und gibt die Kontrolle an den Web-Server zurück, der die Ausgabe an den Browser schickt.

So gut sich dieses Verfahren für zahlreiche Aufgaben eignen mag, für die Anforderungen, die üblicherweise mit COBOL realisiert werden, ergibt sich hier ein Problem: Der Aufruf von COBOL aus HTML ist „stateless“. Es gibt keine Möglichkeit den Zustand einer Anwendung nach Rückgabe der Kontrolle an den Web-Server festzuhalten, der Prozess verschwindet aus dem Speicher. Nach der Ausführung kappt der Web-Server die Verbindung zum Programm und es werden keine Informationen vom letzten Dialogschritt erhalten. Ketten von Programmen, wie sie in größeren COBOL-Anwendungen üblich sind, sind damit nicht abbildbar. Der einzige Ausweg wäre die Speicherung der absolvierten Dialogschritte vom COBOL-Programm aus – beispielsweise in einer Datenbank. Dies würde aber umfangreiche Programm-Änderungen bedeuten, denn man müsste ja auch eine eigene Benutzerkontrolle für diese Dialogschritte durchführen.

So stehen den unübersehbaren Vorteilen der HTML-Technik – wie universelle Verfügbarkeit und standardisierte Sprache – beim Einsatz als Front-End für COBOL-Anwendungen doch auch deutliche Nachteile gegenüber: Die Zustandslosigkeit von HTML erlaubt nur Ein-Schritt-Transaktionen, was bei komplexeren Applikationen oft zu wenig ist. Dass HTML außerdem keine Funktionstasten unterstützt, ist da schon fast vernachlässigenswert.

Ende Teil 1

Da sich moderne COBOL-Anwendungen auf die Abbildung der Geschäftslogik konzentrieren, werden für die Front-End-Systeme regelmäßig andere Technologien verwendet. Neben der im ersten Teil dargestellten Programmierung mit WinAPI, Object COBOL und HTML ist heute insbesondere die Einbindung anderer Programmiersprachen wie Visual Basic oder Java wichtig geworden. Eine leistungsfähige Alternative stellt dabei das Dialog-System von Micro Focus dar.

Es gibt heute eine ganze Reihe von Sprachen, die weit mehr als COBOL – auch in der OOP-Variante – ihren Fokus auf die Gestaltung von GUIs legen. Für das Rapid Application Development (RAD) wird man COBOL nicht einsetzen. Diese Arbeitsteilung, die COBOL für die Geschäftslogik verwendet und andere Programmiersprachen, beispielsweise Visual Basic (VB), Delphi oder Java für die heute in der Regel graphischen Oberflächen, hat sich mittlerweile vielfach – auch in sehr großen Anwendungen – bewährt.
Die Probleme, die dabei zu lösen sind, liegen in den Unterschieden der Sprachkonzepte und Schnittstellen, in der Anpassung unterschiedlicher Datentypen sowie generell in der verschiedenartigen Architektur der Systeme. Während im klassischen Ansatz einer Großrechner-Anwendung das Programm startet und irgendwann mal eine Maske aktiviert, ist es bei den GUI-Sprachen genau umgekehrt: Hier ist der Ausgangspunkt die Oberfläche und diese ruft das COBOL-Programm auf. Die Steuerung liegt also in der Regel bei der Oberfläche: Java (oder VB) ruft COBOL.

Der RAD-Klassiker: Visual Basic

Aus Visual Basic erfolgt der Aufruf der COBOL-Logik als eigenständige DLL. Dazu sind drei Schritte erforderlich:

Definition der Schnittstelle in VB, zum Beispiel:

Type COBOL Interface
p1 as String
p2 as Integer
p3 as String
End Type

Definition der COBOL-DLL in VB als Unterprogramm:

Declare Sub MFDLL Lib „MFDLL.dll“ ()
Declare Sub REALWORK Lib „MFDLL.dll“
(CallInterface as COBOLInterface)

Damit kann das Unterprogramm in VB mit einem Call-Befehl aufgerufen werden:

Call REALWORK(CallInterface)

VB ist sehr verbreitet, relativ einfach zu erlernen, bekanntlich aber nur für die Windows-Welt verfügbar. Wer ein universelleres Front-End benötigt, wird daher vielleicht eher zu Java greifen, einer Sprache, die mittlerweile sehr häufig für die Programmierung von Front-End-Systemen für COBOL-Anwendungen eingesetzt wird. Nicht zuletzt deshalb stehen heute für die Verbindung COBOL/Java eine Reihe sehr ausgefeilter Techniken zur Verfügung.


Abbildung 1: Eine Java-Komponente ruft eine COBOL-Komponente mit Hilfe der COBOL-Java-Domain

Hallo? Java ruft COBOL

Java verfügt mit dem „Java Native Interface“ über eine eigene Schnittstelle zum Aufruf anderer Sprachen wie C oder auch COBOL. Daher kann ein in Java erstelltes Front-End auch eine in COBOL realisierte Geschäftslogik aktivieren. Dieses Interface ist jedoch sehr komplex und schwierig zu programmieren, es setzt fundierte Kenntnisse der Parameterstruktur in beiden Welten voraus. Daher tun sich erfahrungsgemäß sowohl erfahrene Java- als auch COBOL-Entwickler mit dieser Möglichkeit schwer.

Dementsprechend gibt es diverse Technologien, die hier weiterhelfen. Dabei hat der Entwickler, der eine COBOL-Applikation mit einer Java-Oberfläche ausstatten will, die Wahl zwischen zwei Möglichkeiten: dem direkten Aufruf und dem Wrapping. Für beide Fälle hat Micro Focus die COBOL-Java-Domain konzipiert, die in der Entwicklungsumgebung Net Express von Micro Focus enthalten ist. Es handelt sich dabei um eine Klassenbibliothek, die eine plattformunabhängige Schnittstelle zwischen COBOL und Java implementiert. Die COBOL-Java-Domain besteht aus der Java-Klasse mfcobol.runtime, die es Java-Objekten ermöglicht, direkt COBOL-Objekte und -Prozeduren aufzurufen. Und sie enthält eine Erweiterung des COBOL-Laufzeitsystems, damit COBOL-Programme auch auf Java-Objekte zugreifen können. Diese Domain stellt alle Mittel für das Laden, Aufrufen und Canceln von COBOL-Programmen aus Java und umgekehrt zur Verfügung.


Abbildung 2: Wrapping von COBOL für den Aufruf aus einem Java-Programm

Direkter Aufruf

Die Implementierung des Aufrufs erfolgt in der Java-Source mit Übergabe eines Parameter-Arrays an die COBOL-Java-Domain, die dafür sorgt, dass die gewünschte COBOL-Komponente aufgerufen wird. Damit innerhalb des Wechsels zwischen den Sprachen kein Bruch im Datentransfer entsteht, wurde eine eindeutige Datentypkonvertierung zwischen den Sprachen festgelegt. So kann jede Seite mit den für sie typischen Formaten arbeiten, und die COBOL-Java-Domain übernimmt die Konvertierung der internen Darstellung.

Sobald ein Java-Objekt mit COBOL-Programmen kommunizieren will, braucht es nur das mit Micro Focus COBOL gelieferte Package mfcobol zu importieren. Dieses enthält die API, die unabhängig von der jeweiligen Plattform eine Kommunikation mit COBOL ermöglicht. Darin sind Methoden enthalten, die das Laden von Bibliotheken auch ohne Angabe der betriebssystemspezifischen Endungen (.dll für Windows, .so oder .sl für UNIX bzw. HP-UX usw.) übernehmen, so dass mit der Methode cobcall auch prozedurale COBOL-Programme direkt aufgerufen werden. Die Methode erhält zwei Parameter: den Namen der Prozedur, die aufgerufen werden soll, und eine Objekttabelle mit den eigentlichen Parametern:

import mfcobol.*
class BasicCobcall
{
…
public void callupro ( )
{
int a = 5;
long b = 9;
Object myParms[]={a, b};
retcode=runtime.cobcall („myprog“,myParms);
}

Für die betreffende COBOL-Routine ist es gleich, ob sie von einem anderen COBOL-Programm oder von Java aufgerufen wird; dementsprechend muss sie auch nicht verändert werden:

Program-id. myprog.
Linkage section.
01 a pic s9(9) comp-5.
01 b pic s9(18) comp-5.
Procedure division using a b.
…

Wrapping

Während beim direkten Aufruf eines COBOL-Programms aus Java die entsprechende Klassenbibliothek des Micro Focus COBOL-Runtime-Systems direkt aufgerufen wird und der entsprechende Programmname sowie seine Parameter beim Aufruf übergeben werden, verfolgt das „Wrapping“ den Ansatz, das aufzurufende COBOL-Programm in eine Java-Klasse einzubetten oder – anders ausgedrückt – zu „verpacken“. Für die aufrufende Java-Applikation ist der Aufruf von Methoden dieser Wrapper-Klasse nicht von dem Aufruf beliebiger anderer Java-Klassen zu unterscheiden. Dadurch bleibt es der Java-Applikation und ihren Programmierern völlig verborgen, dass hier eigentlich unter der Hand ein COBOL-Programm aufgerufen wird. Der Java-Programmierer braucht sich bei dieser Methode nicht damit zu belasten, wie denn die COBOL-Runtime-Klasse heißt, wo er sie findet und wie sie aufgerufen wird.

Beim Wrapping übernehmen das die Assistenten in Net Express: Der Class-Wizard erstellt zunächst eine COBOL-Klasse und dazu analog eine Java-Klasse. Mit dem Methoden-Wizard werden nun der COBOL-Klasse die entsprechenden Methoden hinzugefügt und für die Java-Klasse analoge Methoden generiert, welche die COBOL-Methoden aufrufen. Die COBOL-Methoden werden anschließend um die klassische COBOL-Logik oder mit den entsprechenden Aufrufen („CALL“) auf existierende COBOL-Programme ergänzt, die die prozedurale COBOL-Logik enthalten. Hier fühlt sich der COBOL-Programmierer zu Hause. Den aufrufenden Code in der Java-Wrapper-Klasse bekommt er von den Net Express Assistenten generiert und seinen Java-Kollegen kann er eine fertige Java-Klasse zur Verfügung stellen, die die Kommunikation zwischen Java und COBOL enthält.

Auch die Anbindung von grafischen Oberflächen über andere Programmiersprachen weist Vor- und Nachteile auf. Einerseits lassen sich die Stärken anderer Sprachen gezielt nutzen – beispielsweise die GUI-Fähigkeiten, Rapid Application Development usw. Andererseits muss natürlich entsprechendes Know-how vorhanden sein, wobei COBOL-Programmierer sich unter Umständen mit der objektorientierten Denkweise vertraut machen müssen. Auf jeden Fall aber werden für ein und dasselbe Projekt zwei unterschiedliche Entwicklungsumgebungen benötigt, was negative Auswirkungen auf das Projektmanagement haben kann. Schließlich sollte man nicht vernachlässigen, dass die dargestellte Kombination zweier Programmiersprachen zu Performance-Einbußen führen kann. Um diese zu kompensieren ist wiederum ein großes Java-Know-how erforderlich.


Abbildung 3: Einsatz von HTML als GUI für eine COBOL-Anwendung

Was eigenes: Dialog System

Neben den auf Standard-Technologien beruhenden Möglichkeiten haben die Hersteller auch eigene Front-End-Techniken entwickelt, um COBOL-Entwicklern die Gestaltung von Front-End-Systemen im Rahmen ihres Entwicklungssystems zu vereinfachen. So bietet Micro Focus mit seinem „Dialog System“ ein eigenständiges Werkzeug für die Erstellung grafischer Oberflächen, das in der Entwicklungsumgebung Net Express enthalten und weitgehend in die Philosophie der COBOL-Entwicklung integriert ist.

Net Express Dialog System nimmt eine klare Trennung der einzelnen Schichten vor, die Oberfläche wird in einer separaten Datei abgelegt. Die erforderlichen Arbeitsschritte bestehen aus der Definition oder dem Import der Datenfelder, dem Zeichnen der Oberfläche per Mausklick sowie der Definition und Behandlung von Ereignissen. Dabei kann die Steuerung des Systems sowohl ereignisorientiert als auch prozedural erfolgen. In einem Fall ist Dialog System das steuernde Element, das die COBOL-Module als Unterprogramme aufruft, in einem anderen Fall wird das Dialog System aus COBOL heraus wie ein Unterprogramm aktiviert. Das GUI bietet die üblichen Zeichenobjekte – wie Fenster, Felder, Buttons, Boxen, Text, Bitmaps usw. Daneben lassen sich auch Objekte, die nicht direkt in Dialog System zur Verfügung stehen, einsetzen. Dabei kann die Erzeugung und Steuerung des Objektes über ein separates OO COBOL-Programm basierend auf der OO GUI-Klassenbibliothek erfolgen – mit einer automatischen Generierung von Objekten für List View, Table View, Slider, Progress Bar usw. Außerdem können ActiveX Controls verwendet werden, die in beliebigen Programmiersprachen implementiert sein können und die eigenständige Software-Komponenten mit definierter Funktionalität für die Oberflächengestaltung zur Verfügung stellen.

Will man für den Presentation Layer einer Anwendung die Vorzüge der Windows-Plattform nutzen, die Verarbeitungslogik aber auf anderen Systemen (z.B. Unix, Linux) ablaufen lassen, so kann die Verteilung der Anwendung mittels der Technik des Client-Server-Bindings erfolgen. In Dialog System gibt es dafür einen speziellen Wizard, der die automatische Generierung des COBOL-Clients und des Programmrahmens für den COBOL-Server übernimmt, wobei eine klare Trennung zwischen dem Client mit der GUI-Logik und den Geschäftsprozessen im Back-End erfolgt.

Mit Dialog System lassen sich sehr leicht grafische Oberflächen erstellen, die sehr gut auf COBOL abgestimmt sind; der Aufbau verteilter Anwendungen ist auf diese Weise problemlos möglich. Allerdings handelt es sich um ein herstellerspezifisches Produkt, und da nicht alle Zeichenobjekte direkt verfügbar sind, muss der Entwickler gewisse Erweiterungen durch User Controls und ActiveX-Elemente selbst vornehmen.

Die bisher dargestellten Möglichkeiten, COBOL-Anwendungen mit grafischen Front-Ends auszustatten, zeigen, dass es dafür keine ideale Lösung gibt, die alles abdeckt. Jede Technik hat spezifische Vor- und Nachteile, die je nach Anforderungen mehr oder weniger ins Gewicht fallen – alle gemeinsam haben sie den Benutzer heute fast vollständig vom Green Screen erlöst.

Sie erreichen den Autor Dr. Rainer Doh, Redaktion PR-COM GmbH, unter der Mailadresse Rainer.Doh@pr-com.de