COBOL IM 21. JAHRHUNDERT:

EINE PROGRAMMIERSPRACHE

WIRD MODERNISIERTCOBOL hat sich in den letzten Jahren stark weiterentwickelt. Die Programmiersprache lässtsich heute in modernen Entwicklungsumgebungen wie Eclipse oder Visual Studio einsetzen undverfügt über alle Sprachelemente, die für die Integration in aktuelle Plattformen nötig sind.Neue Compiler können aus COBOL- direkt Java-Byte-Code erzeugen, sodass die Ausführungvon COBOL-Programmen in der JVM möglich ist. Unternehmen können COBOL damit sowohl inder Entwicklung als auch im produktiven Betrieb flexibel in offenen Systemen nutzen. In diesemArtikel stellen wir dar, wie sich das moderne COBOL in neuen Anwendungen verwenden lässt,und adressieren darüber hinaus das immer stärker werdende Generationenproblem imBereich COBOL und Wartung von Altsystemen.

m e h r z u m t h e m a :online.microfocus.com/next-generation-cobol-deonline.microfocus.com/awareness-de

74 75

Programmiersprachen. Transaktionsinten -sive Anwendungen mit vielen parallelarbeitenden Nutzern, wie sie in Banken,Versicherungen, in Industrie und Handeloder bei Buchungssystemen in der Touristikzum Einsatz kommen, sind heute wie vordreißig Jahren in COBOL programmiert.

Der Bestand an COBOL-Applikationenist dementsprechend immens: Er wird aufmehr als 220 Milliarden Codezeilen welt-

In der Softwareentwicklung stehen derzeitThemen wie Apps und Mashups oderFrameworks für mobile Systeme, wieTitanium oder Rhodes, im Mittelpunkt derAufmerksamkeit. Demgegenüber führtCOBOL fast ein Schattendasein. Doch dieöffentliche Wahrnehmung und die tatsäch-liche Bedeutung klaffen bei COBOL schonseit langem weit auseinander, denn nachwie vor ist COBOL eine der wichtigsten

■ 1955: FLOW-MATIK, der Vorläufer von COBOL, wird vonGrace Hopper entworfen. FLOW-MATIK dient vor allem derProgrammierung kaufmännischer Aufgaben.

■ 1959: Das US-Verteidigungsministerium und diverseIndustrieunternehmen gründen CODASYL (COnference onDAta SYstems Languages). Auf der Basis von FLOW-MATICwird die neue Programmiersprache COBOL entwickelt. Zielist es, eine hardwareunabhängige, standardisierte und pro-blemorientierte Sprache für die Erstellung von Programmenfür den betriebswirtschaftlichen Bereich zu generieren.

■ 1960: COBOL 60 wird von CODASYL verabschiedet und inden kommerziellen Verkauf gebracht.

■ 1968: USA Standard COBOL 1968: Die vorhergehendenStandards von COBOL verschiedener Organisationen werdendurch ANSI zu einem untereinander kompatiblen Standardzusammengefasst.

■ 1974: American National Standard COBOL 1974: Weiter ent -wicklung und Verbesserung der Sprache durch die CODASYL.

■ 1985: COBOL-85: Mit Begrenzern wie END-IF und END-PERFORM entsteht erstmals die Möglichkeit, in COBOLbeliebig geschachtelte Entscheidungs- (IF, EVALUATE) undWiederholungsanweisungen (PERFORM) zu schreiben unddamit die so genannte „Strukturierte Programmierung“ inCOBOL zu praktizieren. Bei der Weiterentwicklung derStandardisierung wird explizit auf Abwärtskompatibilitätgeachtet, um eine Koexistenz von Programmen verschiedenerCOBOL-Versionen zu ermöglichen.

■ 1997: Rund 300 Milliarden Zeilen Quellcode werden fürGeschäftsprozesse weltweit eingesetzt. Davon sind 80 % inCOBOL und 20 % in restlichen existierenden Programmier -sprachen geschrieben.

■ 1999: 50 % aller kritischen Applikationen werden in COBOLprogrammiert.

■ 2002: COBOL 2002: Wesentliche Änderungen des aktuellenStandards COBOL 2002 sind die Übernahme der Erwei -terungen durch X/Open, die explizite Unterstützung von inter-nationalen Zeichensätzen einschließlich Unicode, die objekto-rientierte Programmierung sowie bedingte Kompilierung.Zeitgemäße Aspekte der Programmierung, zum BeispielObjektorientierung und dynamische Speicherverwaltung, wer-den dadurch ermöglicht.

■ 2010: Micro Focus schlägt mit Visual COBOL die Brücke zwi-schen .NET und Java und integriert die COBOL-Entwicklungin die populären Entwicklungsumgebungen von Eclipse undMicrosoft Visual Studio.

■ 2012: Die objektorientierte COBOL-Syntax wird von MicroFocus für eine nahtlose Integration von COBOL in die .NET-Welt signifikant vereinfacht und erweitert. COBOL-Kundenstehen mit Visual COBOL alle Möglichkeiten offen, problem-los den jeweiligen Code für die Zielplattform beziehungsweisefür das jeweilige Framework (.NET, Java Frameworks, Cloud)zu generieren.

Rolf Becking

(rolf.becking@microfocus.com)

ist Senior Technical Account Manager bei Micro

Focus. Seine Schwerpunkte sind Softwareent -

wicklung, die Integration verschiedener

Programmiersprachen und die Modernisierung

von Anwendungssystemen auf offene Systeme.

Mathias Mezger

(mathias.mezger@microfocus.com)

ist als Senior Solution Architect bei Micro Focus

zuständig für die Modernisierung von Mainframe-

Anwendungslandschaften. Seine Tätigkeits -

schwerpunkte sind IBM Mainframes VSE, OS390

bis z/OS, VSAM, CICS und COBOL.

d i e au toren

Kasten 1: Meilensteine von COBOL.

f achar t i ke l

5/2012

weit geschätzt. Diese Basis sichert COBOLeine langfristige Zukunft. Große Unter -nehmen sehen in COBOL weiterhin einewichtige Säule für Geschäftsanwen dungen,die sie in ihren langfristigen Planungenberücksichtigen. Eine Abkehr von COBOLwürde für die Anwender jedenfalls einenenormen Aufwand bedeuten und dieRisiken, die mit zwangsläufig jedem neuenSoftwareprojekt verbunden sind, wärenunüberschaubar. Zudem sind die mitCOBOL erstellten Anwendungen ausgetes -tet und langjährig bewährt und hinsichtlichStabilität, Performance und Verfüg barkeitnicht so leicht zu übertreffen.

COBOL im Generationswechsel Bei vielen Anwendern ist in Zusammen -hang mit COBOL in den letzten Jahrenallerdings ein Problem aufgetaucht, das mitder Technologie unmittelbar gar nichts zutun hat: In der Software ent wicklung für die„großen“ Systeme hat ein umfassender per-soneller Generations wechsel begonnen.Viele erfahrene COBOL-Entwickler, die inden 70er und 80er Jahren auf den damalsüblichen Host-Systemen ihr Handwerkgelernt haben, sind bereits aus dem

Berufsleben ausgeschieden und die verblie-benen werden in absehbarer Zeit folgen.

Die nachrückende Generation von Soft -wareentwicklern kommt aus einer ganz

Abb. 1: Modernes COBOL: Entwicklung unter der Entwicklungsumgebung von Eclipse.

Abb. 2: Modernes COBOL: Entwicklung unter der Entwicklungsumgebung vonVisual Studio.

f achar t i ke l

Veränderungen auf jeden beliebigenRechner zu portieren.

Re-Hosting des produktivenBetriebsDurch die Verlagerung nicht nur der Ent -wicklung, sondern auch des produktivenBetriebs auf die offenen Plattformen Linux,Unix und Windows werden zum einen dieAnforderungen der neuen Entwickler -genera tion erfüllt, zum anderen könnenUnternehmen so bestehende Investitionenin COBOL nun in neue Architekturen wieJVM oder .NET gleichwertig einbinden.Damit wird also ein hohes Maß anInvestitionssicherheit für bestehendeCOBOL-Systeme geschaffen.

In der offenen Welt von Windows, Unixund Linux sind für COBOL-CompilerSchnittstellen zu anderen Sprachen, insbe-sondere zu C/C#, Visual Basic, zurWindows-API und zu Java, unverzichtbar.Sprachen, die in nativen Code (Objekt-Code auf dem jeweiligen Betriebssystem)übersetzt werden, wie zum Beispiel C, kön-nen relativ einfach von COBOL aufgerufenwerden oder selbst COBOL-Programmeaufrufen. Der neueste COBOL-Compiler„Visual COBOL“ von Micro Focus ist inder Lage, den Quellcode für unterschiedli-che Zielplattform und Frameworks zugenerieren:

■ Als nativen Code unter Linux, Unixund Windows, zum Beispiel für die Ver -bindung zu C.

■ Als Microsoft Intermediate Language(MSIL) für das .NET-Framework unterWindows.

■ Als Java-Byte-Code für die Java VirtualMachine (JVM) und damit auch fürLinux, Unix und Windows.

76 77

umgebung die Anforderungen einer moder-nen Tool-Landschaft erfüllt. Die Entwick -lungsprozesse oder auch Methoden wie dieagile Entwicklung sind vor diesem Hinter -grund weitgehend sprachunabhängig.Damit kann der Know-how-Transfer bezie-hungsweise der Generationenwechsel aufsanfte Art durchgeführt werden.

Mit COBOL ist das problemlos möglich,denn alle aktuellen IDEs und Methodenwerden unterstützt. Es spielt keine Rollemehr, in welcher Entwicklungsumgebungdie Programme erstellt werden. Selbst dedi-zierte Mainframe-Programme werden heu-te nicht nur am Großrechner entwickelt,sondern auch per „Offload Development”am PC und können bei Bedarf auch aufanderen Plattformen wie Linux, Unix undWindows zum Einsatz gebracht werden,strikt nach dem alten Ansatz: „Write once,run anywhere”. Voraussetzung dafür war,dass sich COBOL in den letzten beidenJahrzehnten mehr und mehr von derMainframe-Plattform gelöst hat. Die hoheStandardisierung der Sprache erlaubt es,ein COBOL-Programm in der Regel ohne

anderen Welt und ist an andere Prozesse,Methoden und Werkzeuge gewöhnt. Dieseneue Ent wick lergeneration auf eine klassi-sche Entwick lungs umgebung fürMainframes mit Green-Screen und ohneMaus zu zwingen, kann keine Perspektivesein. Gerade die kreativen Köpfe ließen sichso nur schwer an ein Unternehmen binden.Diese Ent wickler wollen – ob Host odernicht – mit modernen Entwicklungsumge -bungen wie Eclipse oder Visual Studioarbeiten (siehe Abbildung 1 und Abbildung2). Dabei geht es nicht einfach um persön-liche Vorlieben oder Aversionen: DieseEntwickler arbeiten mit ihren vertrautenTools und Methoden deutlich produktiver.Mit dem Verweis auf eine hoheTransaktionssicherheit und eine riesigeCode-Basis lassen sich diese Ent wicklerihre Präferenzen auch nicht mehr ausreden.

Mittlerweile zeigt sich jedoch auch, dasses für die kommenden Entwickler genera -tionen nicht mehr so sehr darauf ankommt,in welcher Sprache entwickelt wird – ob inJava, COBOL oder C# –, sondern vielmehrdarauf, dass die jeweilige Entwicklungs -

Abb. 3: Visual COBOL – ohne unnötigen Ballast, entsprechend der Notationenmoderner Programmiersprachen und trotzdem echtes COBOL.

Abb. 4: Codebeispiel in COBOL, Visual COBOL und C#. Visual COBOL ist deutlich schlanker als klassisches OO-COBOLund nähert sich an die Notation von Sprachen wie C# an.

f achar t i ke l

5/2012

Dadurch kann ein COBOL-Programmsowohl in der .NET Common LanguageRuntime als auch in der JVM laufen undunterscheidet sich zur Laufzeit fast nichtmehr von einem Java- oder C#-Programm.Die Syntax des objektorientierten COBOL(OO-COBOL) ermöglicht dabei dieDefinition und den Aufruf von Klassen undMethoden über Sprachgrenzen hinweg.

Modernes COBOL – also ein COBOL,das die Ausrichtung auf die Host-Welt hin-ter sich gelassen hat – spiegelt diese Ent -wicklung schon in seiner eigenen Aus -gestaltung wider. So hat Visual COBOLvon Micro Focus die Einbindung von Codein die managed Welt sehr stark vereinfacht,indem es dem Entwickler bereits eine pas-sende Syntax dafür zur Verfügung stellt(Codebeispiele in Abbildung 3 und Abbil -dung 4). Modernes COBOL verzichtet aufunnötigen Ballast und implementiert dieSyntaxnotationen der modernen Program -miersprache. Formal steht COBOL daherheute mit C# und Java auf einer Stufe.Durch solche Erweiterungen der COBOL-Sprache können nun Anwendungen gebautwerden, die aus vorhandenen COBOL-Geschäftsprozessen und einer C#- oderJava-Oberfläche bestehen und in einergemeinsamen Laufzeitumgebung wie JVModer .NET genutzt werden können.

Damit lassen sich Altsysteme nach einerMigration mit ihrem hohen COBOL-Anteilin den Geschäftsprozessen in die Zukunftübernehmen und gleichzeitig modernisie-ren. Auf dieser Basis ist es dann auch pro-blemlos möglich, neue Plattformen – etwader mobilen Systeme (beispielsweise unterAndorid) oder des Cloud-Computing (bei-spielsweise mit MS Azure) – mit in COBOLgeschriebener Geschäftslogik zu versorgen.

COBOL und Java verbindenBei der Integration von COBOL in aktuelleTechnologien steht heute insbesondere dieVerbindung mit Java hoch im Kurs, weilviele Anwender (auch) in dieser Pro gram -miersprache entwickeln und entsprechendeRessourcen damit bereits vorhanden sind.Auch eingefleischte Mainframe-Betreibersind heute ja nicht mehr reine COBOL-Anwender, denn wer seine Enterprise-Applikationen in COBOL pflegt, setztparallel für Web-Applikationen oder fürmobile Systeme häufig Java ein. Eine engeVerbindung gerade dieser beiden Pro -grammiersprachen ist daher für die Weiter -entwicklung der Systeme von besonderemInteresse.

Verbindung per JNIBei der Verbindung von Java mit anderenSprachen stellt sich generell das Problem,dass Java in einer virtuellen Maschine(JVM) läuft. Ruft man von dort Pro -gramme auf, die zu einem Maschinencode,dem so genannten nativen Code (DLLsunter Windows oder Shared Objects/Li -braries unter Unix/Linux) kompiliert undgelinkt sind, so bietet die JVM dafür mitdem Java Native Interface (JNI) eine ent-sprechende Schnittstelle an. Dabei stellensich jedoch zwei Herausforderungen:

1. Das JNI ist etwas kompliziert.2. Beim Aufruf des JNI wird die JVM ver-

lassen und ihr damit die Kontrolle ent-zogen.

Die Folgen können recht unangenehm sein:Stürzt beispielsweise das native Programmwegen eines Fehlers ab, wird damit auchdie JVM automatisch beendet.

In Web- oder Applikationsservern kanndas JNI daher nicht verwendet werden.Aber auch wenn man sich nicht innerhalbeines solchen Servers bewegt, ist eineVerbindung via JNI nicht einfach zu hand-haben. Ein COBOL-Programm muss näm-lich an die Gegebenheiten der Java-Weltangepasst werden. So arbeitet die Java-Laufzeitumgebung grundsätzlich multi-threaded, wofür ein COBOL-Programmnormalerweise nicht vorgesehen ist. Dazukommt das Problem der Inkompatibilitätder Datentypen: So ist ein String in Javanicht gleich einem String in COBOL.Solche Probleme lassen sich technisch zwarlösen, aber die Aufgabe ist alles andere alstrivial und erfordert einigen Aufwand.

Auch der umgekehrte Aufruf – vonCOBOL zu Java – gestaltet sich nichtwesentlich leichter. Der Aufruf als solcherlässt sich in COBOL, das mittlerweile jaüber objektorientierte Spracherweiterun -gen verfügt, immerhin einfacher erstellen.Zudem muss die COBOL-Laufzeitum -gebung in der Lage sein, die gewünschteJVM zu laden. Die Anbieter von COBOL-Compilern haben in der Regel für dieseThemen einen jeweils proprietären Ansatzgewählt, um dem Programmierer dasCodieren der JNI.API zu ersparen.

Verbindung per JCAWeb- und Applikationsserver können alter-nativ zu JNI-basierten Lösungen eine Pro -tokoll-Schnittstelle nutzen, die es ermöglicht,mit einem externen Server zu kom muni -

zieren. Dabei können Web-Services oder dieJava-Connector-Archi tecture (JCA) verwen-det werden. Compiler-Anbieter wie MicroFocus stellen Tools und Verfahren bereit, mitdenen ein COBOL-Programm einen Web-Service aufrufen kann oder aber selbst alsWeb-Service beziehungsweise J2EE-Servicein einem COBOL-Server eingesetzt werdenkann, sodass es für einen entsprechendenAufruf zur Verfügung steht.

Auf diese Weise werden die Probleme derJNI zwar umgangen, allerdings stehen nunzwei Server nebeneinander: einer für Javaund einer für COBOL. Diese Konstellationkann für Anwendungssysteme, die transak-tionsorientiert arbeiten, zu einer echtenHerausforderung werden. Die beiden Ser -ver arbeiten nämlich mit unterschiedlichenTransaktionen, die zwar miteinander koor-diniert werden können, aber nicht in einergemeinsamen Transaktion zusammenge-fasst werden. Im Anwendungsfall bedeutetdas, dass ein verändernder Datenzugriff desJava-Programms im aufgerufenen COBOL-Programm nicht weiter verarbeitet werdenkann, da er noch nicht von der umschlie-ßenden Java-Transaktion durch einCommit abgeschlossen worden ist. Diesmag in vielen Applikationen keine Rollespielen, hat sich aber bei der Migration vontransaktionsorientierten Systemen miteinem generierten Frontend – zum Beispieldem VisualAge-Generator für CICS – alsechtes Problem herausgestellt, an dem einekomplette Migration einer solchen An -wendung scheitern kann. Gerade die gro-ßen COBOL-Systeme sind in vielen Fällenstark transaktionsorientiert.

COBOL als Java-Byte-CodeAus der Welt schaffen lassen sich derartigeProbleme letzten Endes nur durch einengrundsätzlicheren Ansatz: Mit der Kompi -lierung von COBOL- zu Java-Byte-Code,wie sie „Visual COBOL“ von Micro Focusseit einiger Zeit bietet, wird endlich eineechte Integration von COBOL und Javaermöglicht. Die Kompilierung zu Java-Byte-Code erlaubt es, jedes klassischeCOBOL-Programm zu einer Java-Klasse zukompilieren, die von der JVM ausgeführtwerden kann. Damit lassen sich bestehendeCOBOL-Altanwendungen ohne jede Ver -än derung als Java-Byte-Code ausführen.Dabei muss allerdings offen bleiben, inwie-weit es sinnvoll ist, bestehende COBOL-Programme ohne jegliche Erweiterungen inJava-Byte-Code zu kompilieren, denn ohneeine Java-Umgebung, in die das jeweilige

f achar t i ke l

78 79

Programm integriert werden soll, hat derJava-Byte-Code gegenüber dem nativenCode keine Vorteile. Wie eine Integrationprogrammtechnisch aussehen könnte, zei-gen die folgenden Beispiele.

Definition einer KlasseFür die Aufrufbarkeit aus der rein objekto-rientierten Java-Welt muss das aufzurufendeCOBOL-Programm eine Klasse und diedazu gehörenden Methoden zur Verfügungstellen. Die COBOL-Syntax wurde spätes -tens seit dem ISO-2002-Standard um ent-sprechende Konstrukte erweitert, die MicroFocus als Compiler-Hersteller noch einmalvereinfacht hat. Für die Definition einerKlasse reicht ein class-id-Paragraph mit demNamen der Klasse, für die Definition einerdazu gehörenden Methode der method-id-Paragraph mit dem Namen der Methode:

class-id BizLogic.. working-storage section.. method-id CountTo.

Der COBOL-Code der Methode CountTosoll später betrachtet werden. Die imFolgenden skizierte Java Klasse JavaOutputimplementiert ein Interface:

public class JavaOutput implements ICallback {@Overridepublic void SendMessage(String arg0) {

System.out.println("Java says" + arg0);}

}

Dieses Interface wurde hier einmal imCOBOL-Code definiert:

interface-id ICallback.method-id SendMessage.procedure division using by value msg as string.end method.

end interface.

Die Syntax procedure division using by valuemsg as string dürfte manchen COBOL-Programmierer überraschen. Aber dasBeispiel zeigt, dass es tatsächlich möglichist, in COBOL bei einem Parameter anzu-geben, wie er übergeben werden soll (Javaübergibt alle Parameter als reine Input-Parameter by value), und auch noch, wel-chen Datentyp der jeweilige Parameter hat.as string bedeutet dabei, dass es sich um einDatenfeld vom Java-Datentyp string han-delt. Eine Beschreibung der Parameter in

der Linkage Section kann COBOL natür-lich wie bisher verarbeiten, ist damit aberüberflüssig geworden. Die Konvertierungder Datentypen besorgt der COBOL-Compiler beziehungsweise die COBOL-Laufzeitumgebung. Ohne eine derartigeKonvertierung kann die Anwendung je -doch nicht laufen – dafür sind die Unter -schiede zwischen COBOL- und Java-Datentypen zu groß.

InstanziierungDie beschriebene COBOL-Klasse und dieJava-Klasse müssen nun noch instanziiertwerden. Das erfolgt durch ein kleines Java-Programm:

public class JavaCounter{

public static void main(String[] args) {JavaOutput rcv = new JavaOutput();BizLogic bl = new BizLogic();bl.CountTo(10, rcv);

}}

Hier zeigt sich, dass die Codierung keiner-lei Rückschlüsse darauf zulässt, ob es sichbei den zu instanziierenden Klassen umJava- oder um COBOL-Klassen handelt.

Implementierung einer Methodeund ParameterübergabeDie Implementierung der COBOL-Metho -de CountTo erfolgt ebenso einfach wie dieeiner Java-Methode:

class-id BizLogic.working-storage section.method-id CountTo.local-storage section.01 i binary-long.01 formatted pic zzz9.procedure division using by value n1 as binary-long,

by value callmeback as type ICallback.perform varying i from 1 by 1 until i > n1move i to formattedinvoke callmeback::SendMessage(formatted)

end-performend method.

end class.

Wichtig ist hier die Parameterübergabe ausJava mit:

bl.CountTo(10, rcv);

Diese entspricht in COBOL dem folgendenProcedure Division Header:

procedure division using by value n1 as binary-long,by value callmeback as type ICallback.

Der Parameter n1 kommt hier als Java-Datentyp binary-long an, ohne jemals in einerLinkage Section erwähnt worden zu sein.Die internen COBOL-Daten sind in derLocal-Storage Section definiert, womit demmulti-threaded Verhalten der Java-WeltRechnung getragen wird, denn Local-Storage-Daten sind in COBOL thread-lokal.

Als zweiter Parameter wird by value call-meback as type ICallBack übergeben. Das istfür COBOL sehr ungewöhnlich, denn hierwird ohne Definition in der LinkageSection ein Parameter übergeben, der alsImplementierung des Interface ICallBacktypisiert wird, also eine Object Referenceauf die Java-Klasse JavaOutput darstellt, diedas in COBOL definierte Interface ICallBackin Java implementiert.

Der Code der MethodeDer Code der Methode CountTo zeigt, dasses sich um einen ganz gewöhnlichen proze-duralen COBOL-Code handelt, wie er injedem beliebigen COBOL-Programm exis -tieren könnte. Bemerkenswert ist dabei derAufruf der Java-Methode SendMessage ausCOBOL, weil hier eine besondereSchreibweise verwendet wird:

invoke callmeback::SendMessage(formatted)

Da in COBOL der Punkt „.” schon belegtist, muss hier auf die Schreibweise „::” aus-gewichen werden. Ansonsten ist die objekt -orientierte Syntax von COBOL der Java-Syntax so ähnlich geworden, dass sich einJava-Programmierer ohne Probleme zu -recht finden kann.

Das Beispiel zeigt, wie sehr sich COBOLweiter entwickelt hat. Die Ausführung vonCOBOL-Programmen in der JVM ist heuteRealität. Die zur Verfügung gestellte Syntaxerlaubt eine komfortable und nahtloseIntegration mit der Java-Welt. BeideSprachen können in Visual COBOL forEclipse gemeinsam programmiert und miteinem Debugger analysiert werden.

Anwender können auf diese WeiseCOBOL und Java auf hohem Niveau ver-binden. Damit lassen sich bestehendeInvestitionen in COBOL-Code weiter nut-zen, ohne dass man auf die Möglichkeitenvon Java verzichten müsste. Das ist eineinteressante Perspektive, die zeigt, wieanpassungsfähig die angeblich alte Pro -grammiersprache COBOL ist. ■

f achar t i ke l