---

RPG ist großartig, nutzen Sie die Möglichkeiten

von Scott Klement

Die Antwort lautet klar: beide. Ich werde erläutern, warum ich diese Sprache bevorzuge, aber auch auf die Regeln eingehen, die befolgt werden sollten, um wirklich moderne Anwendungen zu erstellen. Im heutigen zweiten Teil setzt der Autor die Ausführungen zu Programmiertechniken, Regeln und Standards in RPG fort. Teil 1 des Artikels ist in der Novemberausgabe 2007 von NEWSolutions erschienen.

Empfehlenswerte Regeln bei der Entwicklung mit RPG

Wer seine Anwendungen nicht aktualisiert oder seine Technologien nicht verbessert, gerät unweigerlich ins Hintertreffen. Unglücklicherweise geschieht genau das in der System i Industrie recht häufig. Die Anwendungen laufen so gut, dass Programmierer allzu oft dazu neigen, Anwendungen genauso zu schreiben, wie sie es vor 10 oder 15 Jahren bereits getan haben. Das wiederum hat dazu geführt, dass viele Menschen glauben, RPG sei nicht in der Lage, moderne Funktionalität bereitzustellen. Oft wird RPG sogar noch mit dem 5250 Green Screen in Verbindung gebracht, als seien diese beiden eine untrennbare Paarung. Ein Umdenken kann hier nur erreicht werden, indem man vorführt, dass RPG zu weit mehr in der Lage ist, als Green Screens zu produzieren. Und dies wiederum geschieht am effektvollsten, indem man seine Programme aktualisiert.

Nachfolgend finden sie eine (wahrscheinlich nicht völlig erschöpfende) Liste von Regeln, die heutzutage beim Schreiben von neuen RPG- Programmen berücksichtigt werden sollten.

Gekapselte Geschäfts- und Datenbanklogik

Beim „Einkapseln“ wird der betroffene Code isoliert und seine Funktion mehr oder minder verborgen. Die dahinter stehende grundsätzliche Idee ist, dass ein Programm, das eine Subprozedur aufruft, keine Kenntnis davon haben muss und sich ebenso wenig darum kümmern muss, wie diese Subprozedur arbeitet. Es sollte unter Beibehaltung der Parameterliste möglich sein, die Arbeitsweise einer Subprozedur völlig zu ändern, wobei das aufrufende Programm weiterhin fehlerfrei abläuft, ohne von der vorgenommenen Änderung überhaupt etwas wahrzunehmen. Würde beispielsweise eine Subprozedur existieren, die die Abfrage eines Artikelpreises zur Aufgabe hat, dann sollte es dem aufrufenden Programm gleichgültig sein, in welcher physischen Datei ein Artikelpreis gespeichert ist oder ob überhaupt eine Datenbank für diesen Zweck benutzt wird. Vielleicht wird in fünf Jahren gar keine Preisdatei mehr verwendet, sondern die Artikelpreise werden durch Aufaddieren der aktuellen Marktpreise der benötigten Rohmaterialien (aus dem Internet) ermittelt. Mit dem Einkapseln von Code lassen sich Kosten für die Wartung des Codes senken, da sich Veränderungen vornehmen lassen, ohne alle Programme zu ändern und zu neu testen, die die Subprozedur aufrufen.

Vermischen Sie niemals Geschäfts- und Darstellungslogík

Geschäftslogik ist die Logik, die den Geschäftsablauf abbildet. Wie werden Daten gespeichert? Welche Werte sind in Feldern zulässig? Wie werden Preise ermittelt? Wie fließen Kosten in die Buchhaltung ein? All dies hat wenig damit zu tun, wie die Bildschirminhalte aussehen, die dem Endbenutzer präsentiert werden. Die Benutzerschnittstelle sollte immer fein säuberlich von der Geschäftslogik getrennt gehalten werden. In der Zukunft kommt möglicherweise irgendwann der Wunsch auf, die Anzeigetechnologie zu ändern. Werden heute noch Green Screens verwendet, so sollen vielleicht schon morgen Web- oder grafische Oberflächen zum Einsatz kommen. Oder vielleicht soll die Geschäftslogik geändert werden, um sie über ein SQL-Statement oder einen Web-Service zugreifbar zu machen. Code sollte immer so entwickelt werden, dass er sich modernisieren lässt, ohne ihn völlig neu schreiben zu müssen.

Erstellen Sie statt monolithischer Programme eine umfangreiche Bibliothek mit Services

Angenommen, Sie wollten eine eigene Programmiersprache erfinden, die nur die Belange Ihres Unternehmens abdecken soll. Welche Operations-Codes würden Sie bereitstellen? Würden Sie möglicherweise Operations-Codes wie z. B. AuftragErstellen, ArtikelHinzufügen, AuftragAnzeigen, ArtikelBerechnen oder AlsBezahltMarkieren vorsehen?

Planen Sie Ihre Anwendung als Serie relativ simpler Routinen, die eine einzelne Aufgabe unabhängig von allem anderen erledigen. Es sollte gelingen, komplette Anwendungen schlicht durch selektives Aufrufen dieser einzelnen Routinen zu entwickeln. Diese Routinen sollten so gestaltet sein, dass sie auch von anderen Programmiersprachen aufrufbar sind. Das gestattet eine Wiederverwendung dieser Tools – unabhängig von in der Zukunft beschrittenen Wegen.

Verwenden sie Prototypes statt CALL/CALLB/PARM

Es überwältigt mich immer wieder, wenn ich jemanden immer noch die alten RPG-Operations-Codes CALL, CALLB, PLIST und PARM verwenden sehe. Mit Prototypes lässt sich all das abwickeln, was diese alten Operations-Codes erledigen. Überdies wurden alle Verbesserungen, die in den vergangenen 11 Jahren bezüglich des Aufrufs von Programmen, Prozeduren und Methoden eingebracht wurden, nur noch für Prototypes vorgenommen. Verharren Sie nicht bei der Benutzung der alten Methoden zum Aufruf von Routinen, sonst besteht die Gefahr, dass Sie für immer im 20sten Jahrhundert gefangen bleiben.

Verwenden Sie String-Operationen anstelle von Feldgruppen

Vor der Verfügbarkeit von RPG IV war eine ordnungsgemäße String-Manipulation in RPG nicht möglich, Programmierer halfen sich dadurch, dass sie Zeichenketten in eine Feldgruppe mit einstelligen alphanumerischen Feldern übertrugen und diese Feldgruppe dann für die Manipulation der Zeichenkette verwendeten. Diese Vorgehensweise ist übrigens seit 1995 nicht mehr erforderlich! Es bricht mir jedes Mal fast das Herz, wenn ich sehe, dass dieses Verfahren heute immer noch angewandt wird.

Verwenden Sie Ausdrücke anstelle von ADD/MULT/SUB/DIV

In heutigen RPG Programmen werden für alle mathematischen Operationen Ausdrücke eingesetzt. In modernen Programmen werden die alten Operationscodes ADD, MULT, SUB und DIV nicht mehr verwendet.

Schreiben Sie Procedures und keine Subroutinen

Es gibt heute keinen guten Grund mehr, beim Schreiben von neuem Code noch Subroutinen einzusetzen. Subroutinen sind auf die Benutzung globaler Variablen anstelle von lokalen Variablen oder Parametern beschränkt, was die Wartung des Codes erschwert. Moderner Code verwendet ausschließlich Subprocedures.  

Verwenden Sie benannte Indikatoren anstelle von numerischen Bezugszahlen

Es spricht nichts dagegen, Bezugszahlen in Ihren Programmen zu verwenden. Jede Programmiersprache verfügt über ein Konzept für Flags oder Boolsche Felder, in RPG werden sie eben Bezugszahlen genannt. Alle Variablen in einem Programm sollten „sprechende“ Bezeichnungen tragen, die den sich dahinter verbergenden Zweck erkennen lassen. Wenn ich Code lese und dabei auf eine Variable namens ErrorOccurred stoße, ist es eigentlich völlig klar, dass sie auf *ON gesetzt wird, wenn ein Fehler aufgetreten ist und auf *OFF, wenn dies nicht der Fall ist. Wenn ich hingegen eine Variable mit dem Namen *IN74 sehe, habe ich keine Vorstellung davon, was damit gemeint sein könnte. Sicher, es lässt sich natürlich herausfinden, aber das kostet Zeit und senkt die Produktivität. Schreiben Sie Ihre Programme so, dass sie einfach zu warten und zu verfolgen sind. Verwenden Sie integrierte Funktionen (BIFs – Built-In Functions) als Ersatz für Bezugszahlen, wo immer dies möglich ist. An Stellen, wo dies nicht möglich ist, sollten numerische Bezugszahlen zumindest durch benannte Indikatoren ersetzt werden. Es gibt heute keinen Grund mehr, in einem RPG-Programm numerische Bezugszahlen zu verwenden.

Qualifizieren Sie Ihre Datenstrukturen

Wenn ich eine in Ihrem Programm benutzte Variable sehe, sollte es allein vom Namen her schon offensichtlich sein, ob diese Variable Teil einer Datenstruktur ist. Allzu oft habe ich Programme gelesen und mich gefragt, wo um Himmels Willen diese oder jene Variable gesetzt wurde, um dann letztlich herauszufinden, dass in einer vorhergehenden Codezeile schlicht eine Datenstruktur verändert wurde. Früher war es schwierig, in RPG-Programmen gewöhnliche Variablen von Variablen zu unterscheiden, die Teile einer Datenstruktur waren. Im heutigen RPG sollten nur qualifizierte Datenstrukturen verwendet werden, damit keine Zweifel mehr aufkommen können.

Verwenden Sie qualifizierte Strukturen für Dateien

Die Regel, dass Unterfelder einer Datenstruktur offensichtlich zu erkennen sein sollten, gilt in gleicher Weise auch für die Felder von Dateien. RPG bietet die Möglichkeit, qualifizierte, extern beschriebene Datenstrukturen für die Felder einer Datei zu verwenden. Ich persönlich benenne diese Datenstrukturen gern nach dem Dateinamen. Lautet der Name einer Datei beispielsweise KUNDEN, dann lese ich diese Datei in eine Datenstruktur namens KUNDEN1 ein. Benötige ich zu einem Zeitpunkt mehr als einen Satz im Speicher, lautet die zweite Datenstruktur KUNDEN2 usw. Da die Datenstrukturen qualifiziert sind, werden in meinem Code die Felder als KUNDEN1.Kundennr, KUNDEN1.Adresse, KUNDEN1.Telefon usw. angesprochen. Diese Namensvergabe macht es im Programm jederzeit deutlich, aus welcher Datei die einzelnen Felder stammen und erlaubt eine einfache Namensunterscheidung zwischen unterschiedlichen Dateien. Der seit V4R5 verfügbare Operationscode EVAL-CORR erlaubt eine einfache Übertragung von Feldern mit übereinstimmenden Feldnamen in die entsprechenden Felder einer anderen Datenstruktur.

Nutzen Sie Funktionen anderer Programmiersprachen

Eine der größten Herausforderungen bei der RPG-Entwicklung ist das Fehlen frei verfügbarer Tools und Add-Ins für die Sprache. Nehmen wir einmal an, Sie benötigten eine Routine, mit deren Hilfe Sie Daten in ein Excel-Arbeitsblatt schreiben können oder vielleicht eine Bibliothek mit Routinen zur Generierung von Graphiken und Charts. Für Sprachen wie C und Java sind zahlreiche Tools für solche Aufgabenstellungen verfügbar, für RPG hingegen nur äußerst wenige. Aber lassen Sie sich davon nicht aufhalten. Nutzen Sie die RPG-Möglichkeiten zum Aufruf von in anderen Sprachen geschriebenen Programmen, Prozeduren und Methoden. In RPG lassen sich Java-Routinen oder beliebige ILE-Sprachroutinen einfach durch Erstellen der korrekten Prototypen direkt aufrufen. Auf diese Weise eröffnet sich die Welt der Tools von Drittanbietern (viele davon sind kostenlos erhältlich), ohne auf die Vorteile der Sprache RPG verzichten zu müssen.

Verwenden Sie wo immer möglich SQL, niemals hingegen OPNQRYF

Es gibt Situationen, in denen es beim Arbeiten mit Datenbankdateien immer noch Sinn macht, die Native Record-I/O-Funktionen in RPG zu benutzen, speziell, wenn es sich um Transaktionsdateien handelt, bei denen jeweils nur ein Satz zu einer Zeit abgearbeitet wird. Geht es jedoch darum, Routinen für Set-basierte Verarbeitung zu schreiben, ist SQL die richtige Wahl. Mit dem Embedded SQL PreProcessor lassen sich SQL-Statements in RPG ebenso einfach benutzen wie RPG Operationscodes. Die Leistungsfähigkeit und Funktionsvielfalt macht SQL zu einem natürlichen Tool für die Selektion einer Reihe von Sätzen, die bestimmten Kriterien entsprechen. Verwenden Sie OPNQRYF nicht mehr in modernen Anwendungen. OPNQRYF ist klar und deutlich eine Hinterlassenschaft aus der Vergangenheit. SQL ist leistungsfähiger, einfacher zu benutzen (wenn man es einmal erlernt hat) und erheblich schneller als OPNQRYF.

Verwenden Sie keine Green Screens mehr!

Bitte helfen Sie mit, den Mythos zu beenden, RPG sei nur für die Green Screen Programmierung geeignet. Die 5250 Datenstationen gehören technologisch in die 70er Jahre. Selbst MS-DOS Programme der frühen 80er Jahre waren bereits erheblich fortschrittlicher. Es ist wirklich an der Zeit, sich zu bewegen. Abbildung 1 zeigt ein Beispiel, wie ein RPG-Bildschirm heutzutage aussieht. Abbildung 2 zeigt auf ähnliche Weise das Erscheinungsbild von Druckausgaben.

Heutige Anwendungen ersetzen 5250 Green Screens durch Web-Schnittstellen. Das geschieht nicht nur für nach außen sichtbare, sondern auch für interne Anwendungen, selbst dann, wenn sie nur für die Nutzung durch Mitarbeiter bestimmt sind, die im gleichen Büro sitzen, in dem sich auch das System i befindet. Web-Schnittstellen bieten eine „Thin Client“ Funktionalität, bei der die gesamte Programmlogik (sowohl Geschäfts- als auch Anzeigelogik) auf dem Server residiert. Das vereinfacht die Entwicklung, Verteilung und Wartung der Anwendung im Vergleich zu den „Thick Client“ Lösungen der Client/Server Programme vergangener Tage erheblich. CGIDEV2 bietet PRG Programmierern eine einfache Möglichkeit, Web-Schnittstellen in einer reinen RPG-Umgebung einzusetzen. Hält man die Geschäftslogik von der Anzeigelogik sauber getrennt, ist es überdies einfach, RPG in Verbindung mit Java, .Net oder PHP einzusetzen, um ein ausgeklügeltes Web-Frontend zu realisieren.

Die Regeln der Zukunft

Einige maßgebliche IBM-Mitarbeiter haben mir versichert, dass RPG für die Dauer der heute absehbaren Zukunft weiterentwickelt und verbessert werden wird. Das verspricht weitere moderne Funktionen im Lauf der Jahre. Das bedeutet aber nicht, dass Sie damit fortfahren können, Programme so zu schreiben, wie sie es bereits in den 80er und 90er Jahren getan haben. Die Computertechnologie entwickelt sich stetig weiter und Ihre Programme sollten der Entwicklung folgen.

Es muss ja nicht gleich alles auf einmal entwickelt werden. Beginnen Sie einfach, moderne Techniken Schritt für Schritt in Ihre Programme einzubringen. Wenn diese Programme dann im Lauf der Zeit moderner, leichter zu verwalten und flexibler werden und gefälligere Oberflächen erhalten, werden auch Ihre Benutzer erkennen, dass RPG eine wirklich hervorragende Spreche ist. Die Darstellungslogik kann nicht nur dort eingesetzt werden wo sie im Betrieb die Produktivität erhöht sondern auch dort wo sie alte Systeme durch neue ersetzt.