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.

28.07.1978 - 

Erfahrungen eines Systemanalytikers:

"Sauber" strukturieren - auch in RPG

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.