GÖTTINGEN (hö) - "Die Praxis hat gezeigt, daß Anwendungsprogramme häufig ungeordnet und unübersichtlich geschrieben sind und damit fehlerhaft und wartungsunfreundlich werden", so Jürgen Westernhagen, Systemanalytiker bei der Alcan Aluminiumwerke GmbH, Göttingen. Westernhagen, der mit einem IBM-System/3 arbeitet, hat zudem festgestellt, daß solche Probleme besonders häufig bei RPG-Programmen auftreten. Um dem entgegenzuwirken und den Softwarekosten-Anstieg zu bremsen, empfiehlt er die "immer mehr an Bedeutung gewinnende" Strukturierte Programmierung. Hier seine Gründe:
Die Strukturierte Programmierung soll hier nicht zum wiederholten Male wissenschaftlich durchleuchtet werden sondern vielmehr ihre Verwendbarkeit als praxisorientierte Programmiertechnik für RPG-II-Anwender dargestellt werden.
Ziel des strukturierten Programmierens ist, die Programmierproduktivität zu steigern, die Programmierfehler zu reduzieren, den Wartungsaufwand zu vermindern.
Im RPG II lassen sich jedoch nicht alle Forderungen der Strukturierten Programmierung wie zum Beispiel die Beschränkung der Ablaufsteuerung (ohne GOTOs) oder der Datenverfügbarkeit realisieren. Die wesentlichsten Grundlagen jedoch können auch im RPG II verwirklicht werden: Hierarchisches Programmgefüge, Blockstruktur und zentrale Ablaufsteuerung. Nur reichen sie nicht aus, um dem anfangs erwähnten Ziel näherzukommen. Vielmehr ist zusätzlich erforderlich, die Sprachelemente des RPG zu begrenzen, um so zu einer gewissen "Normung" in der Codierung zu gelangen.
1. Die Verwendung der Bezugszahlen sollte beschränkt und festgelegt werden:
BZ 1-9 Satzdefinition in der Eingabe
BZ 10 1.Zyklus
BZ 11-20 wiederverwendbare Anzeigen in der Verarbeitung (C-Bestimmungen)
BZ 21-49 Definition von +/-/0/b in der Eingabe
BZ 50 Fehleranzeige
BZ 60-89 nicht wiederzuverwertende Anzeigen, zum Beispiel Fortführung in die Ausgabe
BZ 90/99 Ausgabesteuerung, zum Beispiel EXCPT
2. Wegen der besseren Übersichtlichkeit in der Verarbeitung sollten in der Eingabe definierte Felder Rückschluß auf die entsprechende Datei zulassen. Beispiel:
I KUSTAMM KF
I KUNAME (Name)
I KUAN (Anschrift)
I KULAN (Lieferanschrift)
3. Die in der Verarbeitung (C-Best.) definierten Felder sollten einer Namensgebung unterliegen, wie etwa
Summenfelder CSKG (Summe Kilogramm)
Vergleichsf. CVJahr (Vergleich Jahr)
Zähler I, Il, I2 etc.
4. Programmlabels sollten nach einem bestimmten Schema gebildet werden: Programmiererkurzzeichen + Numerierung aufsteigend (WS010, WS020, etc.)
Hinsichtlich der Verwendung von Unterprogrammen ergeben sich insbesondere bei externen, wiederverwendbaren Upros folgende Forderungen bezüglich der Normung:
5. Unterprogrammname maximal vierstellig wie SAMM
6. im Upro definierte Felder setzen sich zusammen aus Uproname + zweistelligem Begriff, wie SAMMXY
7. im Upro definierte Labels setzen sich zusammen aus Uproname + zweistellige Numerierung, wie SAMM01
8. Zähler im Upro werden nicht mit I sondern wie mit J, J1 etc. benannt.
Mit der Erfüllung der Forderungen in den Punkten 6 bis 8 werden Namensprobleme weitestgehend vermieden.
Weiterhin sollte eine Programmkurzbeschreibung sowie die Beschreibung der wesentlichen Bezugszahlen zu Beginn eines Haupt- und Unterprogrammes selbstverständlich sein.
Nachdem die Forderungen bezüglich der Programmnormung aufgestellt sind, können nun die Regeln für die Strukturierte Programmierung definiert werden:
þIn sich geschlossene Programmfunktionen sollten als Unterprogramme codiert werden. Ist die Funktion wiederverwendbar, sollte ein externes Upro erstellt werden. (COPY-Funktion.) Das Hauptprogramm ist im Idealfall nur Steuerleiste für die Unterprogramme.
þBezugszahlen können, wenn der zweite Punkt erfüllt ist, wiederverwendet werden und tragen damit zur besseren Übersichtlichkeit bei.
þDie für RPG charakteristische "Verknüpfung" von Eingabe, Ausgabe und Verarbeitung, die durch die Verwendung von Bezugszahlen in Ein- und Ausgabe
þIn der Ausgabe sollte anstatt mit Literalen besser mit in der Verarbeitung gefüllten Feldern oder mit indizierten Feldgruppen gearbeitet werden (bei Fehlertexten etc.).
Unter Berücksichtigung der Punkte 1 bis 8 und der genannten Regeln sollte es doch möglich sein, auch im RPG übersichtliche und "saubere" Programme zu erstellen.