Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

05.06.1998 - 

Thema der Woche

Cobol-Bestände zum Ausschlachten freigegeben

Die GAD, die rund 80000 Bankarbeitsplätze mit PL1- und Cobolcodierten Funktionen versorgt, plant den Paradigmawechsel. Sie deklariert Java zur Standardsprache. "Weg von Host-prozeduralen Monolithen hin zu Client-Server-Multitier-Applikationen und Network-Computing", steckt Hans-Peter Berger, GAD-Abteilungsleiter Verfahren und Methoden, das Ziel ab.

Zu den Kunden der GAD zählen die nordrhein-westfälischen Volksbanken, Spar- und Darlehenskassen, im Sprachgebrauch des Softwarehauses "Primärbanken", sowie die "Zentralbanken" Deutsche Genossenschafts Bank, Frankfurt am Main, und die Westdeutsche Genossenschafts-Zentralbank eG in Düsseldorf. Für die erstgenannten Publikumsbanken erstellten die Münsteraner zusammen mit der Genossenschafts Rechenzentrale Norddeutschland GmbH (GRZ), Hannover, ab 1989 die 10000 Module umfassende Cobol-Host-Anwendung "BB3".

Als die IBM signalisierte, die damit arbeitende Bankenhardware "4700" aus dem Verkehr zu ziehen, entstand 1994 eine BB3-Client-Server-Variante. Dafür wurde die an die Hardware angelehnte Logik auf das Betriebssystem OS/2 umgeschrieben und um Client-Server-Funktionen ergänzt. Dennoch läuft auch diese Anwendungsversion zu 80 Prozent Mainframe-basiert.

1994 bis 1997 entwickelte die GAD das Zentralbankinformationssystem "ZIS 3". Weil diese Applikation aus 4000 PL1-Modulen die Weiterentwicklung einer WGZ-Bank-Anwendung war, bediente sich die GAD auch weiterhin dieser Host-Sprache. "So ist der Anteil der PL1- und Cobol-Programme heute noch höher als 90 Prozent", berichtet Berger. "In dieser Hinsicht sind wir ein altmodisches Haus."

Doch nun soll sich alles ändern: "Als wir 1996 immer noch nicht objektorientiert entwickelten, mußten wir uns fragen, ob das so weitergehen soll." Seither beschäftigen sich die Münsteraner mit der Frage: "Wie kriegen wir den Paradigmawechsel hin?"

Geänderte Anforderungen seitens der Kunden und neue technische Möglichkeiten sind der Grund für den Umstieg. "Heute haben die Banken straffe, geschlossene Prozesse, die wir stringent in der IT abbilden", führt Berger aus. Doch das Bankengeschäft ändere sich. Prozesse beim Kunden würden mit denen der Banken verknüpft. Diversifizierungen in den Finanzhäusern forderten zudem verschiedene Kombinationen vorhandener Prozesse.

Das Arbeiten mit Monolithen, die effizient sind, weil sie in einem hohem Maße integriert und miteinander verwoben wurden, schließt Flexibilität aus. Obwohl die GAD über eine etablierte Benutzeranforderungsverwaltung verfügt, vergehe etwa ein Jahr, bis die Wünsche in einem neuen Software-Release implementiert seien. "Das dauert schlichtweg zu lang", resümiert Berger. "Die Anforderung an uns lautet deshalb: Ihr müßt schneller reagieren. Sie heißt nicht: Macht Objektorientierung! Das ist lediglich eine Schlußfolgerung."

Berger ist klar, daß es nicht mit einem Wechsel von dem "arg geschwätzigen Cobol" zu einer objektorientierten Sprache getan ist. Für ihn muß sich die Denke der Entwickler ändern. Sie müßten etwa lernen, Vorhandenes aus Klassenbibliotheken einzusetzen, statt Lösungen zu codieren.

Obwohl der Schulungsaufwand für Java unter Umständen höher ist als für ein objektorientiertes Cobol, kommt letzteres für Berger nicht in Frage: "Cobol-OO ist der Wurmfortsatz einer altmodischen Sprache, der ihr das Deckmäntelchen der Objektorientierung verleiht." Wie bei allen Hybridsprachen sieht er eine zu große Gefahr des Rückfalls in alte Gewohnheiten. Java lief bei der Evaluierung anderen rein objektorientierten Sprachen den Rang ab, weil die Aussicht auf Plattformunabhängigkeit allzu verlockend erschien.

Derzeit sammelt die GAD Java-Erfahrungen in zwei Pilotprojekten, deren Ergebnisse im Sommer ausgeliefert werden sollen. Davon stellt "Profi-Bank" eine Electronic-Banking-Anwendung dar, die einen direkten Austausch mit Geschäftskunden ermöglichen soll. 15 Mitarbeiter des Softwarehauses sind mit der Realisierung betraut.

In Relation zum gesamten Mitarbeiterstamm der GAD ist die Java-Mannschaft noch klein. Das Haus beschäftigt etwa 350 Mitarbeiter, in der GRZ und den Fachabteilungen der Banken arbeiten weitere rund 450 Beschäftigte mit der Software-Entwicklungswelt der GAD. In drei Jahren sollen allein 100 GAD-Softwarespezialisten fit in Objektorientierung sein.

Berger erläutert, wie das funktionieren soll: "Ich gehe von einer Viertelung unserer Entwicklungsmannschaft aus." Bei jedem vierten Mitarbeiter liege die Einstellung noch nicht so lange zurück, als daß er an der Hochschule nicht objektorientiertes Denken gelernt hätte. Diese Leute seien erst mühsam in PL1 und Cobol geschult worden und froh, zur Objektorientierung zurückzukehren.

Ein weiteres Viertel sei flexibel genug, umzudenken. Diese Mitarbeiter bräuchten nicht motiviert zu werden, sie hätten bereits mitbekommen, daß die Objektorientierung keine Eintagsfliege ist. "Allerdings", so Berger, "müssen wir hier Geld in die Hand nehmen" - für eine etwa sechsmonatige Ausbildung.

Fluktuation sorgt dafür, daß 25 Prozent der Belegschaft nicht mit objektorientierter Technologie in Berührung kommen. Das verbleibende Viertel der GAD-Mitarbeiter sei vonnöten, um die bestehenden Anwendungen mindestens fünf Jahre zu warten und weiterzuentwickeln. Außerdem sollen die in PL1 und Cobol codierten Prozesse mit den vorhandenen Mitteln in Einzelprozesse aufgeteilt und isoliert werden. Die gekapselten Module aber werden sich mit Hilfe eines Component Brokers aus der neuen objektorientierten Umgebung aufrufen und nach Bedarf zusammenbinden lassen.

Der Umbruch bei der GAD ist ein kompletter, von der Programmiersprache bis zur Arbeitsweise der Entwickler durchdacht und strukturiert. Broker-Middleware ermöglicht die Einbindung der Altanwendungen als Ganzes oder in Teilen. Unternehmen, die auf Komponententechnik setzen, haben die Freiheit zu wählen, ob und in welchen Schritten sie die Legacy-Systeme migrieren, ersetzen oder lediglich kapseln. Aus Individuallösungen werden in diesem Zuge wiederverwendbare Bauteile.

Die GAD ist mit ihrem radikalen Wechsel zur Objektorientierung und der Entscheidung für Java kein Einzelfall. Auch für den deutschen Fiskus brechen neue Zeiten an. In dem Projekt "Fiscus" wird eine bundeseinheitliche Finanzsoftware entwickelt, die die Steuern in mindestens fünf verschiedenen Systemen der 16 Bundesländer berechnen und verwalten soll. Dieses Java-System löst Assembler- und Cobol-Programme ab.

Die Gründe für den Ersatz der Altanwendungen ähneln denen der GAD und entspringen dem Wunsch nach einer größeren Flexibilität der DV. Klaus-Dieter Rudolph, Fiscus-Projektleiter beim Bundesamt für Finanzen, erläutert: "Die Wartbarkeit der heutigen Systeme nimmt aufgrund immer häufigerer Steuerrechtsänderungen und kürzerer Technologiezyklen rapide ab. Das Projekt soll die Finanzverwaltung vor einer schleichenden Funktionsunfähigkeit bewahren."

Da für Fiscus eine "moderne Infrastruktur" vorgesehen sei, habe sich die Frage, ob Cobol sich als Implementierungssprache eigne, gar nicht gestellt. Cobol-Programmierung kommt für Rudolph nur noch für "Adapterprogramme" in Betracht, die die Verbindung von objektorientierten Applikationen zu Altsystemen darstellen.

Die am Projekt beteiligten Finanzbehörden haben sich nach der Pilotentwicklung für das Java-Framework der IBM "San Francisco" als Entwicklungsplattform entschieden. Die Komponenten stellen Middleware-Funktionen zur Verfügung, die Fiscus zu einem verteilten objektorientierten System wachsen lassen können.

Das ist der Trend: Neue Projekte werden objektorientiert aufgesetzt. Dabei geht es nicht wie beim Wechsel von 3GL- zu 4GL-Tools darum, schneller oder automatisierter zu entwickeln.

Streckenweise wird gar nicht entwickelt, sondern auf Bewährtes oder Kaufbares zurückgegriffen. Objekte, Pattern, Frameworks, Broker und Komponenten erlauben einen Mix aus den Bauteilen.

Diesen Pragmatismus kennzeichnet auch die Entwicklung im Hause Daimler-Benz. Charakteristisch ist etwa der Einsatz verschiedener Sprachen - auch von Cobol: "Die meisten Neuentwicklungen in unserem Haus sind objektorientiert", so Wilfried Reimann, Leiter Informatik, Methoden und Verfahren bei Daimler-Benz. "Doch gibt es Applikationsteile, die aktuell noch in Cobol entwickelt, dann gekapselt und als Objekt-Server benutzt werden."

Bei dem Hersteller moderner Edelkutschen entstehen sogar noch komplett neue Modulstrukturen in Cobol, doch mit Blick auf die Einbindung in eine bunte Komponentenlandschaft. Cobol bietet laut Reimann die Möglichkeit, auf Daten, die zum großen Teil in dem Datenhaltungssystem "CA-IDMS" liegen, zuzugreifen sowie bewährte Strukturen für die modernen Systeme nutzbar zu machen. Es habe beispielsweise keinen Sinn, sämtliche Auftragssysteme von heute auf morgen zu ersetzen. Das erfordere vielmehr einen "langen Übergangszeitraum" von fünf bis zehn Jahren.

Funktionale Überschneidungen von Alt- und Neuanwendungen sind unvermeidbar. So könnten neue Ordersysteme gleich für die Bestellung neuer Fahrzeugtypen eingerichtet werden, während die alten Anwendungen für die älteren Modelle zuständig blieben. Da sich die Bestellverfahren und -abläufe jedoch entsprechen müßten, wären eigentlich eine Reihe von Funktionen doppelt zu codieren. Um sich das zu ersparen, werden bestehende gekapselte Funktionen sowohl den neuen als auch alten Programmen zu Verfügung gestellt. Dabei können objektorientierte Anwendungen zwar auf herkömmlich geschriebene Bauteile zugreifen, die integrierte Cobol-Software aber nicht auf Objekte.

Die Möglichkeit der Mehrfachverwendung ist laut Reimann ein guter Grund für einen Cobol-Anteil auch bei Neuentwicklungen, zumal sich Cobol seit Jahren als stabile Mainframe-Sprache bewährt habe: "Cobol hat eine ganz tolle Eigenschaft: Es ist sehr, sehr stabil." Geht es allerdings um objektorientierte Entwicklung, schließt der Software-Ingenieur den Sprachklassiker im OO-Gewand aus. "Leute, die heute Ahnung von Objekttechnologie haben, beschäftigen sich mit Smalltalk, C++ und zunehmend mit Java."

Das sieht Johann Vry von der Neuen Landbuch Gesellschaft mbH & Co. KG (NLB), Verden, ganz anders. Für ihn erscheint der Schritt von prozeduralen Cobol-Programmen zur objektorientierten Entwicklung nur mit den entsprechenden Spracherweiterungen machbar. Sie sicherten Schnittstellen zu existenten Quellcode-Programmen. Zugleich ermöglichten sie die Überführung der bisherigen Daten aus Dateisystemen in Objektstrukturen und eine relationale Datenhaltung.

Das kleine Softwarehaus aus Verden stellt Steuerprogramme für DOS-Systeme her. Bisher kam dabei der "CA-Realia"-Compiler zum Einsatz. Künftig soll die Software auf Windows 95 laufen. Mit der Umstellung auf 32 Bit findet der Wechsel zur Objektorientierung statt. Die NLB setzt nun den Compiler von Micro Focus ein.

Vry hofft auf einen "gleitenden Übergang", zumal das Softwarehaus auch bisher keine Monolithen, sondern Module entwickelt habe. Jedes dieser Unterprogramme werde etwa achtmal verwendet. Doch nun sei die Grenze erreicht: "Die wollen wir mit der Objektorientierung durchbrechen." Die künftigen NLB-Programme sollen sich leichter als bisher anpassen und warten lassen sowie letztlich eine wettbewerbsgemäße Preisgestaltung ermöglichen.

Als Alternative zu "Object-Cobol" wäre für das Nordlicht Vry lediglich C++ in Frage gekommen. Für Object Cobol habe jedoch das bessere objektorientierte Sprachkonzept gesprochen. Außerdem war für die Entscheidung zugunsten des Cobol-Compilers wesentlich, daß die Mitarbeiter keine gänzlich neue Sprache lernen mußten. Die Gefahr, sich zwar der Spracherweiterungen zu bedienen, aber den Paradigmawechsel nicht zu vollziehen, sieht er bei seinen Leuten nicht.

Zeitzeichen

Der Cobol-Markt lebt auf. Indikatoren gibt es genügend, verläßliche Zahlen jedoch kaum. IDC-Analysten

befragten Ende vergangenen Jahres weltweit rund 240 Unternehmen, welche Aktivitäten sie bezüglich Objektorientierung planen oder bereits betreiben. Nur 8,8 Prozent gaben an, sie wollten in diesem Jahr bestehende Applikationen migrieren, mehr als 70 Prozent signalisierten, sie hätten nichts dergleichen vor. In laufenden Entwicklungsprojekten nutzen 25,6 Prozent Cobol und PL1, 18,8 Prozent C und 24,3 Prozent C++ (Überschneidungen sind berücksichtigt).

Wie die Marktforscher von Ovum prognostizieren, wird der weltweite Markt von Anwendungsentwicklungswerkzeugen bis zum Jahr 2001 jährlich um 13 Prozent auf 12,5 Milliarden Dollar wachsen.

Sowohl Acucorp (früher Acucobol) mit 20 Prozent und einem Gewinn von rund einer Million Dollar als auch Micro Focus wuchsen 1997 überproportional. Micro Focus konnte für das vergangene Geschäftsjahr, das am 31. Januar endete, einen Umsatz von 167,3 Millionen Dollar verbuchen. Das entspricht 36 Prozent Wachstum im Vergleich zum Vorjahr, in dem ein Verlust von 10,5 Millionen Dollar zusammenkam.

Im OO-Markt ermittelte IDC ebenfalls eine Steigerungsrate von 33,8 Prozent bis zum Jahr 2001. Die Wachstumszahlen entsprechen der gestiegenen Nachfrage nach Programmierern sowohl in der objektorientierten als auch der strukturierten Anwendungsentwicklung (siehe Grafik).

The State of the Object Industry 1997. How Companies use Object Technology.

Cobol auf dem Seziertisch

Alle können Cobol. Die Sprache ist strukturiert, lesbar, wartbar, stabil, standardisiert, praktisch auf allen Plattformen verfügbar und kann mit flachen, hierarchischen sowie relationalen Datensystemen zusammenarbeiten. So oder ähnlich lauten die Argumente, die Cobol-Verfechter, Hersteller wie Kunden, Kritikern entgegengeschleudern. Die Opposition hingegen will lieber heute als morgen modernisieren, migrieren, selektieren oder ausmustern. Sie ist der Meinung, daß Unternehmen mit einer Cobol-Umgebung nicht schnell genug auf wechselnde Marktanforderungen reagieren können.

Dennoch gibt es zur Zeit offenbar zuwenig erfahrene Cobol-Programmierer, sonst würden nicht anläßlich der Euro- und Jahr-2000-Umstellung sogar 70jährige Ruheständler zur Restaurierung der Cobol-Antiquitäten in die Betriebe geholt. Wartbarkeit und Lesbarkeit bewerten Gegner als "Geschwätzigkeit" und Redundanz.

Cobol impliziert rund 3000 Regeln. "Die Sprache muß gepaukt werden", behauptet Reiner Kraft, Wissenschaftlicher Mitarbeiter der Gesellschaft für Mathematik und Datenverarbeitung (GMD), St. Augustin. Das strukturierte Programmieren, das mit der Wasserfallmethode korrespondiert, die Einteilung in Sections, Datenstrukturen in Form von Feldern beschränkter Größe und Records (Datensätze), die Orientierung am Lochkartenformat (eine Anweisung pro Zeile, Einhaltung von Spaltenformaten), Sprunganweisungen, Kompilieren für jede neue Plattform - das alles gilt nicht mehr als zeitgemäß.

Tatsächlich stammt der aktuelle Standard der Ende der 50er Jahre entwickelten imperativen Common Business Oriented Language aus dem Jahr 1985. Etwa 1989 kamen sogenannte "intrinsic functions", Funktionen, die einen Wert liefern und in unterschiedlichen Anweisungen benutzbar sind, hinzu. 1997 sollte eigentlich ein neuer ISO-Standard verabschiedet werden, der im wesentlichen die objektorientierten Erweiterungen berücksichtigt. Doch dazu kam es nicht; beispielsweise unterstützten einige Hersteller Mehrfachvererbung, andere nicht. Nun soll es frühestens im Jahr 2000 soweit sein.

"Das ist reichlich spät", kommentiert GMD-Mann Kraft. Das Institut arbeitet an dem Cobol-Transformator "Rococo", der erhaltenswerte Teile erkennen, herauslösen und objektorientiert ummodeln soll. Kunden hofft die Gesellschaft vor allem im Zuge der Umstellungen auf den Euro und das Jahr 2000 zu finden.

Unternehmen wie die Münchener Rückversicherungs-Gesellschaft setzen das Standard-Cobol ein. Die DV basiert zu 80 Prozent auf dem Mainframe und nahezu ausschließlich auf Cobol-Logik. Herstellerspezifische Erweiterungen wie Objektfunktionen kommen, so Udo Baumann, Mitglied der Direktion Zentralbereich Informatik des Versicherers, nicht in Frage.

Seit rund zwei Jahren bieten etwa die IBM, Micro Focus und Acucobol (seit kurzem Acucorp) objektorientierte Erweiterungen an. Die Siemens-Nixdorf Informationssysteme AG, die für ihre BS-2000-Systeme eigene Cobol-Compiler baut, kündigt ebenfalls ein objektorientiertes Cobol an. Wann das fertig sein soll, steht noch nicht fest. Darüber hinaus verfügen die meisten Cobol-Varianten aber auch über GUI-Funktionen, Schnittstellen zu relationalen Datenbanken, den Microsoft-Applikationen und zum Web.