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.

27.10.1978 - 

10 Jahre Normierte Programmierung bei Olympia:

400 000 generierte Cobol-Statements - und kein Ende in Sicht!

Bereits Mitte der 60er Jahre entschied man sich in der EDV-Abteilung der Olympia Werke AG in Wilhelmshaven, Cobol als

Haupt-Programmiersprache einzusetzen. Dies war eine wichtige Entscheidung auf dem Wege zur Standardisierung unserer Programmierung. Konsequenterweise folgte anschließend die inhaltliche Standardisierung, das heißt die Entwicklung von Programmier-Richtlinien und sogenannten Muster- oder Rahmenprogrammen. Die letzte Stufe bildete dann 1970 die Entwicklung und konsequente Einführung eines Cobol-Programmgenerators. Damit wurden die Richtlinien "automatisiert" und gleichzeitig der - wegen des anerkannt guten Dokumentationsgehaltes coboltypische - hohe Routine-Schreibaufwand erheblich minimiert. Bis heute wurden rund 800 Cobol-Programme bei Olympia mit Hilfe des Programm-Generators erzeugt, davon über 50 IMS-Batch-Programme

(= etwa 60 Prozent des gesamten vorhandenen Programm-Volumens). In der Zwischenzeit wurde die Effektivität des Generators ständig gesteigert; es wurden Anpassungen an DIN 66220 und Konzern-Richtlinien vorgenommen und verschiedene Anwenterwünsche berücksichtigt. Doch im großen und ganzen ist seit Jahren eine unveränderte Generatar-Version im permanenten Einsatz.

Während der ersten, unter anderem von EDV-Zeitungen und Schulungs-Instituten forcierten NP-Euphorie, wurden NP-Generatoren gut verkauft und auch damit gearbeitet. Die dann einsetzende Programmgeneratoren-Schwemme bewirkte unseres Erachtens in der zweiten Phase das genaue Gegenteil: Der Anwender hatte die Qual der Wahl! Welches Softwarehaus und welche Beratungsfirma hat inzwischen keinen eigenen Generator als Visitenkarte anzubieten? Statt sich zusammenzutun und ein gemeinsames Produkt zu entwickeln und zu vertreiben - was sicherlich wohl dem Produkt als auch dem Benutzer gut bekommen wäre -, erschienen fast wöchentlich neue Generatoren mit neuen Namen und Funktions-Schattierungen.

Von der "Götterdämerung", der Strukturierten und strukturierenden Programmierung bis hin zu POP (= Programmierung ohne Programmierer) und dem Dr.-Maurer-Zitat "DIN 66220 als warnendes Beispiel" wurde alles getan, um den EDV-Anwender vollends zu verwirren.

Obwohl man mit Jedem Artikel zu diesem langbärtigen Thema befürchten muß, diese Verunsicherung weiter voranzutreiben und wir ferner das Risiko eingehen, von hochkarätigen Software-Philosophen als verbohrte "NP-Ostfriesen" bezeichnet zu werden, meinen wir, daß ein nachweisbarer, in der Praxis über lange Jahre erzielter Rationalisierungs- und Standardisierungserfolg (siehe Überschrift) noch unentschlossene EDVer am ehesten überzeugen sollte.

Dabei ist sogar die Einsatzentscheidung für ein ganz bestimmtes "Software-Werkzeug zur Erstellung von Programmen" von sekundärer Bedeutung.

Ausgerechnet der "Pro-Normierte-Programmierung-Artikel" eines Anwenders in der CW-Nr. 36/78 gab uns den letzten Anstoß für diesen Artikel. Wir sind nämlich gerade der entgegengesetzten Ansicht, daß eher hochqualifizierte Programmierer - zumindest bei uns im Hause - zu der Einsicht bereit sind, sich Routine-Kodierungen per Generator vom Leibe zu halten, denn:

Nicht die selbst kodierte Statementanzahl zählt, sondern letztlich das Ergebnis! Nicht ein Programmgenerator sollte als "Schmarrn" bezeichnet werden, sondern höchstens das, was der Generator einem Programmierer abnimmt. Ebenso volkstümlich ausgedrückt sind nach

unseren Erfahrungen 400 000 generierte Cobol-Routine-Statements als Summe bestimmt nicht mehr als "Schmarrn" zu bezeichnen.

Zukunftsaussichten

Mittlerweile setzt sich bei den NP-Für- und Wider-Artikeln die auch unserer Meinung nach richtige Ansicht durch, daß Normierte Programmierung und Strukturierte Programmierung sich nicht gegenseitig ausschließen (CW 5/77, CW 23/78, CW 27/78).

Wir sind sogar der Meinung, daß die Normierte Programmierung als gutes Beispiel für die Strukturierte Programmierung herangezogen werden sollte.

Da ein Programm nicht nur aus Instruktions- sondern auch aus Definitionsblöcken besteht, die sich ebenfalls standardisieren und generieren lassen, ist unseres Erachtens der Oberbegriff "Standardisierte Programmierung" angebrachter. Zukünftige Compiler werden eventuell in der Lage sein, Entscheidungstabellen und strukturierende Makros aufzulösen, sie werden aber kaum ein NP-Rahmenprogramm erzeugen.

Grund 1: Die normierte Programmierung ist vorwiegend nur in der BRD bekannt ! In diesem Punkt hat die GES mit ihrer in der CW 20/78 veröffentlichten NP/SP-Gegenüberstellung, die die NP-Diskussion wieder neu ausgelöst hat recht!

Grund 2: Es ist davon auszugehen, daß die am häufigsten eingesetzte, kodieraufwendige Programmiersprache Cobol nicht von heute auf morgen von den Hardware-Herstellern eingestampft, sondern eher noch weiter ausgebaut wird (siehe IBM-VS-Cobol mit neuen

PL/1-ähnlichen Instruktionen). Deshalb hat auch heute noch ein

Cobol-NP-Generator auf lange Sicht eine Zukunft, da zukünftige, neue Cobol-Definitionen und -Instruktionen/Auflösungen stets innerhalb eines vorgenerierten SP/NP-Rahmens eingeschoben werden können.

SP-Generator-Leistungsprofil

SP steht hier für Standardisierte Programmierung und schließt Strukturierte und Normierte Programmierung ein. Mit dem auf unsere Standards zugeschnittenen SP-Generator Olygen, der jederzeit durch relativ einfache Tabellenänderungen auf eigene Haus-Standards (zum Beispiel für Datei-, Feld- und Paragraphennamen) umgestellt werden kann, sind folgende Cobol-Programmteile über schnell erlernbare, selbstsprechende instruktionslose Parameter generierbar:

Dieser skizzierte Generierungsumfang wird sicherlich heute von mehreren angebotenen Programmgeneratoren erbracht und kann bei einer Auswahlentscheidung schnell abgehakt werden. Schulungsaufwand, Service, Inputaufwand und Generierungstechnik (zentrale oder intregierte Programmablaufsteuerung) sind weitere Bewertungsfaktoren, ferner ein über den Input leicht zu beeinflussenden Output, damit folgende Programmablaufvarianten möglich sind:

- DIN 66220-Unterstützung für n sequentielle Dateien und n Gruppenstufen, ferner

- Direkter Zugriff auf Platten-Dateien, Datenbanken und Tabellen in allen Programm-Ebenen, wobei insbesondere gruppenschlüsselabhängige Direkt-Zugriffe durch hierfür speziell vorgesehene Programmblöcke besonders einfach sind

- Mehrphasen-Programm-Generierung per Minimal-Input (zum Beispiel 1 Karte = zirka 300 Cobol-Statements)

- Unsortierte Verarbeitung ohne Gruppenbegriffe

- Datei-Abhängigkeitsverarbeitung und anderes mehr.

Wenn von einem NP/SP-Generator diese Varianten unterstützt werden, treffen unserer Meinung nach fast alle in der GES-Tabelle

(CW-Nr. 20/78) aufgeführten Mängel der Normierten Programmierung nicht mehr zu, insbesondere der häufig aufgeführte Nachteil, daß die DIN 66220-NP-Programmierung nur maßgeschneidert für die Verarbeitung sequentieller Dateien sei.

*B.-D. Voss ist Leiter der Systemprogrammierung; P. Kruse Leiter der Systementwicklung/Programmierung bei der Olympia Werke AG, Wilhelmshaven.