Für die strukturierte Programmierung ist Cobol denkbar ungeeignet heißt es. Moderne Sprachen wie PL/1, Pascal, ADA sind da weitaus besser dran. Nur beherrscht Cobol den Softwaremarkt. Geht man davon aus, daß dies auch noch eine Weile so bleiben wird, muß man sich also Gedanken machen, wie man auch in nächster Zukunft mit Cobol leben kann. Die Frage lautet: "Ist strukturierte Programmierung mit Cobol möglich?"

Über das Thema strukturierte Programmierung ist im allgemeinen und in Cobol im besonderen schon viel geschrieben worden. Nur sind die dabei gemachten Vorschläge so allgemeiner Art, daß es einem Praktiker schwer fällt, sie in die tägliche kosten- und terminbelastete Arbeit einfließen zu lassen. Vorschläge wie "es gibt gute und schlechte GO TO's, man soll nur die Guten verwenden,", sind nicht gerade als Kochrezept zu verwenden. Das liegt häufig daran daß die Literatur versucht, hundertprozentige Lösungen anzubieten, die sich dann nur schwer in die Praxis umsetzen lassen.

Innerhalb unserer Projektarbeiten haben wir darüber nachgedacht und sind zu der Meinung gekommen, daß

A) eine Lösung, die 80 - 90 Prozent aller Fälle gut löst, ausreicht,

B) die Regeln einfach und objektiv überprüfbar sein müssen und

C) die Regeln sich in mehreren Projekten bewähren müssen.

Wir haben solche Regeln gefunden und sind nach mehreren Projekten sehr zufrieden damit.

Da wir ja nicht Neues erfinden, sondern lediglich Cobol strukturiert programmieren wollten, griffen wir auf die allseits bekannten Grundelemente der strukturierten Programmierung zurück.

Top-Down-Approach

Ein Modul wird in Kapitel (Sektion) hierarchisch gegliedert (Abb. 1). Der Kapitelname besteht aus zwei Teilen:

A) Die Hierarchieeinordnung der Sektion, dann ein Bindestrich und

B) der möglichst aussagekräftige Kapitelname.

Jeder Block in Abbildung 1 stellt eine Sektion dar. Läßt man im Prefix des Sektionnamens (Hierachieordnung) die letzte Stelle weg, so sieht man, aus welcher hierarchisch übergeordneter Sektion der Aufruf erfolgte. (Beispiel: H12 - wird von H1 - aufgerufen.) Der letzte Block in Abb.1 ist eine sogenannte "U-Sektion". Diese fügt sich nicht in die sonstige Baumhierarchie ein, sondern hat Netzwerkcharakter. Ihr Merkmal ist, daß sie von mindestens zwei verschiedenen Sektionen aufgerufen wird und, daß man ihr den Aufrufer nicht ansieht.

Der strukturelle Block wird in Cobol als Sektion dargestellt. Es gibt nur einen Eingang und einen Ausgang. Der einzig zugelassene Paragraph ist der EXIT-Paragraph. Er steht unmittelbar vor der EXIT-Anweisung, die die letzte in der Sektion sein muß.

Beispiel:

------------------------------------------------------------------------------------------------

H1-VERARBEITUNG SECTION.

PERFORM H11-INIT.

IF KZ-LAND = K-SCHWEIZ

THEN GO TO H1-EXIT.

PERFORM H12-....

UNTIL S-ENDE = K-JA.

MOVE ....

H1-EXIT.

------------------------------------------------------------------------------------------------

H11-INIT SECTION.

.

.

.

H11-EXIT. EXIT.

------------------------------------------------------------------------------------------------

Jede Sektion darf nur durch PERFORM oder PERFORM...UNTIL...aufgerufen werden. Verlassen werden darf die Sektion nur über EXIT-Anweisung. Da ja keine sonstigen Paragraphen erlaubt sind, ist der GO TO also nur zum Ende der Sektion (EXIT-Paragraph) erlaubt! Die ALTER-Anweisung ist selbstverständlich verboten.

Manche Compiler (Siemens) machen den Eingangsparagraphen notwendig; nach unserem Verständnis darf er aber nicht angesprungen werden.

Steuerungsanweisungen

Nachfolgend sollen Anweisungen erläutert werden, die den Programmablauf beeinflussen. Für jegliche Steuerung im Programmablauf gilt der Grundgedanke, diese deutlich von den Verarbeitungsanweisungen abzuheben: Damit wird die Durchschaubarkeit eines Modul deutlich besser.

Für alle Schleifeninformationen ist der PERFORM anzuwenden. Diesem Befehl sieht man den Schleifencharakter direkt an; ja, man erkennt sogar sofort, unter welchen Bedingungen die Schleife beendet wird (PERFORM...UNTIL). Die Verarbeitungsanweisungen innerhalb einer Schleife werden als eigene Sektion ausgelagert.

Die Endbedingung einer Schleife gilt es besonders zu beachten:

______________________________________________________

A) SCHLEIFE, DEREN ENDEBEDINGUNG V O R H E R ABGEFRAGT WIRD:

PERFORM H1-VERARBEITUNG UNTIL S-ENDE = K-JA.

B) SCHLEIFE, DEREN ENDEBEDINBUNG N A C H H E R ABGEFRAGT WIRD:

PERFORM H1-VERARBEITUNG.

PERFORM H1-VERARBEITUNG UNTIL S-ENDE = K-JA.

______________________________________________________

Diese Form mag auf den ersten Blick eigenartig erscheinen. Bei näherem Hinsehen zeigt sich aber, daß es eine deutlichere Darstellung als die Schleifenbildung mit dem GO TO ist. Übrigens, OR-Verknüpfungen sind auch für Bedingungen unter UNTIL zugelassen.

Übersicht über die wichtigsten Regeln:

1. Die Sektionen müssen hierarchisch gegliedert sein.

2. Eine Sektion darf nur mit PERFORM aufgerufen werden (PERFORM...THRU...ist verboten). Der Aufruf muß hierarchisch stimmen.

3. Innerhalb einer Sektion ist nur der EXIT-Paragraph erlaubt. Die GO TO-Anweisung darf sich nur auf den EXIT-Paragraphen der betreffenden Sektion beziehen.

4. Literale (außer Null und Eins) sind verboten.

5. Namen müssen aussagestark sein.

Die "verschachtelten" IF's werden unserer Meinung nach zu Unrecht in jedem Fall als unübersichtlich angesehen. Grundlage für einen geschachtelten IF-Befehl sollte immer eine Entscheidungstabelle sein, die auch als Dokumentation im Code erscheinen muß. Regel: Enthält ein Cobol-Satz mehr als ein IF, so muß eine Entscheidungstabelle (ET) als Kommentar eingefügt werden (das übt in ET's). Weiterhin muß die Entscheidungstabelle natürlich auch spiegelbildlich codiert werden (geschachtelter IF):

______________________________________________________

*ET: UPRO DATEI SEQ. SCHREIBEN

*

*B1: S-ERSTER-AUFRUF-JA J J N N

*B2: S-ENDE-JA J N J N

*---------------------------------------------------------------------------------------

*A1: H0-OPEN X

*A2: H1-SCHREIBEN X X

*A3: H2-CLOSE X

*A4: H3-FEHLER X

*----------------------------------------------------------------------------------------

IF S-ERSTER-AUFRUF-JA

THEN

lF S-ENDE-JA

THEN

PERFORM H3-FEHLER

ELSE

PERFORM H0- OPEN

PERFORM H1-SCHREIBEN

ELSE

IF S-ENDE-JA

THEN

PERFORM H2-CLOSE

ELSE

______________________________________________________

Entgegen langläufiger Ansicht halten wir den GO TO ....DEPENDING ON für ungeeignet. Es kommt unseren Beobachtungen nach relativ selten vor, daß sich durchgängige Nummernkreise von selbst anbieten. Meist wird krampfhaft versucht diese aufzubauen, um sie für den GO TO...DEPENDING ON zu verwenden. Auch hier verwenden wir wieder den IF. Allerdings sollte hier nicht eingerückt werden, da ja die CASE-Ausprägung umfangreicher Art sein kann (Abb. 2).

Es fällt sicherlich auf, daß der Schreibaufwand bewußt hoch gehalten wird. Dieses "viele Schreiben" ist eine überaus lohnende Investition, denn ein Programm wird nur einmal geschrieben, aber zigmal analysiert. Es soll eben alles getan werden, um Programme verständlich zu machen. Daher ergibt es sich fast zwangsläufig, daß Literale (außer Null und Eins) verboten sind. Vergleichen sie einmal die beiden nachfolgenden Befehle:

MOVE 5 To KZ-Land.

MOVE K-Schweiz To KZ-Land. Wer noch nicht überzeugt ist, die nächste Mehrwertsteueränderung kommt bestimmt.

Cobol ist sicherlich nicht die optimalste Sprachbasis für die strukturierte Programmierung. Aber die aufgestellten Regeln lassen doch ein akzeptables Qualitätsniveau erreichen. Weiterhin sind die Regeln einfach anwendbar und objektiv überprüfbar.

*Jochen Rosowski ist Geschäftsführer der Gedo GmbH, Bielefeld

_AU:Jochen Rosowski