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.

25.07.1986

Zusätzliche mathematische Funktionen außerhalb der Norm:Neues ANSI-Cobol-Konzept wird zum Zankapfel

WASHINGTON/MÜNCHEN (kul) - Mit der Erweiterung von Cobol um mathematische Funktionen soll sich jetzt ein Unterausschuß des American National Standards Institute (ANSI) beschäftigen. Falls der Vorschlag offiziell angenommen wird, sehen Experten in den USA und der Bundesrepublik darin einen gravierenden Rückschlag für den Standardisierungsgedanken.

Die neuen Features sollen vor allem mathematische Funktionen einschließen, die bisher mit Fortran assoziiert wurden, unter anderem die Berechnung von Quadratwurzeln und trigonometrischen Funktionen. Findet das Konzept Anerkennung, hat das X3H4-Komitee des ANSI künftig die Möglichkeit, neue Cobol-Features einzubringen, ohne daß der langwierige Standardisierungsprozeß durchlaufen werden muß. Für die Einführung des mathematischen Komplexes ist nicht geplant, eine weitere Revision der Programmiersprache abzuwarten.

Für Spracherweiterungen, die dem Normungsprozeß unterliegen, setzen Fachleute demgegenüber einen Zeitraum zwischen 10 und 15 Jahren an. Die Fertigstellung des Cobol-85-Standards beispielsweise dauerte elf Jahre.

Einig sind sich die ANSI-Mitglieder, daß Cobol als Programmiersprache durch die Erweiterungen eine Aufwertung erfahren würde. Innerhalb des Komitees hat sich jedoch eine relativ starke Lobby formiert, die jegliche Änderungen der Sprache außerhalb des Standards strikt ablehnt: Die Vertreter dieser Interessengruppe befürchten, daß jedes Abweichen vom Normgedanken dem "Wildwuchs" Tür und Tor öffnen werde.

Daraus wiederum resultiere unweigerlich eine Verunsicherung der Softwareindustrie und der Benutzer. Durch ständige Ergänzungen des Sprachkonzepts würden die Anbieter gezwungen, ihre Compiler laufend zu überarbeiten. Dies führe jedoch dazu, daß ein stabiler Standard nicht länger gegeben sei.

Umstritten ist das Konzept des amerikanischen Normungsausschusses auch in bundesdeutschen Fachkreisen. So spricht sich Harry Sneed, Geschäftsführer der Software Engineering Service GmbH (SES), Neubiberg bei München, entschieden gegen eine Erweiterung von Cobol um mathematische Funktionen aus: "Ich fürchte, ein solches Aufblähen würde die Sprache verderben. Wir sind jetzt schon auf dem besten Wege dazu."

Seiner Erfahrung nach arbeiten die meisten Cobol-Programmierer in der Bundesrepublik ohnehin nur mit einer Untermenge der Sprache, vor allem mit Move- und Compute-Befehlen. Auf diese Weise ließen sich normalerweise die im kommerziellen Bereich notwendigen Berechnungen problemlos ausführen.

Wunsch nach kompatibler DC-Schnittstelle

Als unbedingt erforderlich empfindet Sneed vielmehr eine kompatible Datenkommunikationsschnittstelle für Cobol. Kernpunkt des Problems ist für ihn die DB/DC-Umgebung, die bisher nicht standardisiert ist. Seiner Ansicht nach wird dieser Problemkreis bei den Sprachen der vierten Generation entschieden besser und einfacher gelöst, nur gebe es hier keine einheitlichen Richtlinien und jeder Hersteller gehe seinen eigenen Weg. Sneed: "Eine Standardisierung im 4GL-Bereich wäre von entscheidender Bedeutung. Cobol um mathematische Funktionen zu erweitern, erscheint mir hingegen so überflüssig wie ein Kropf."

Michael Rölke, Geschäftsführer der GFU Cyrus + Rölke mbH Computerservice in Köln, möchte vor allem eine Trennlinie ziehen zwischen dem PC-Bereich und COBOL-Applikationen auf dem Großrechner. Auf dem Mainframe, so Rölke, sei die Problematik nicht relevant. Da verbindliche Sprachschnittstellen gegeben seien, bestehe die Möglichkeit, Fortran-Unterprogramme in ein Cobol-Programm mit einzubinden. Hier sei folglich keine Notwendigkeit gegeben, mathematische Subfunktionen in die Sprache selbst zu integrieren.

Anders stelle sich die Situation bei PC- oder auch bei MDT-Anwendungen dar. Da die Compiler hier nicht aus einer Hand kämen, könne nur in den seltensten Fällen mit einer wirklichen Kompatibilität gerechnet werden. "Der Stand der verschiedenen Fortran- und Cobol-Compiler", meint Rölke, ist so unterschiedlich, daß es dazwischen keine wirklich gute Brücke gibt."

Den mathematischen Komplex in Form von Subfunktionen in die Sprache zu integrieren, hält der GFU-Geschäftsführer allerdings nicht für weise. Bei einem solchen Ansatz komme es zu einem Zurechtbiegen der Sprache zu einem Zweck, für den sie eigentlich nicht gedacht sei.

Um den steigenden mathematischen Anforderungen im kommerziellen Bereich gerecht zu werden, schlägt Rölke deshalb einen anderen Lösungsansatz vor: Er setzt auf die Verwendung eines zusätzlichen Programmpakets, das dem Benutzer mittels einer Call-Routine den Aufruf der mathematischen Funktionen aus einem Cobol-Programm heraus erlaubt. Hierbei müsse es sich um eine klare, externe Komponente handeln die mit der eigentlichen Sprache nichts zu tun habe. Somit sei auch gewährleistet, daß am Grundgedanken des Cobol-Standards nicht gerüttelt werde.

Ausklammerung ein sehr gefährlicher Ansatz

Eine Verstärkung von Cobol in mathematischer Hinsicht hält auch Hans-Jürgen Hänler, Geschäftsführer der Orgasoft Cooperation GmbH Neuried bei München, nicht für notwendig. Werde in einem Standardisierungskonzept ein gesamter Sprachkomplex ausgeklammert, stelle dies sogar einen sehr gefährlichen Ansatz dar. "Aus der Sicht der immer wieder propagierten Herstellerunabhängigkeit, so Hänler, "ist das ein totgeborenes Kind. Wir werden jeden Rückschritt in puncto Standardisierung blockieren."

Die endgültige Entscheidung darüber, ob das grundlegende Erweiterungsmodell vom ANSI akzeptiert wird, liegt letztlich bei den SW-Anbietern: Diese Lobby verfügt innerhalb des ANSI-Komitees über 14 der 21 Sitze.