RPG IV Erweiterungen in V5R2
Die V5R2 RPG Erweiterungen bauen auf den in V5R1 gelegten Grundlagen auf
von Hans Boldt
Über den Autor
Hans Boldt (boldt@ca.ibm.com) ist Softwareentwickler des RPG Entwicklungsteams im IBM Labor Toronto.
Über den Übersetzer
Übersetzt und für den deutschsprachigen Markt überarbeitet von Joachim Riener.
Die in den fünf Releases zwischen V3R1 (dem ersten RPG IV Release) und V5R1 vorgenommenen Verbesserungen sind in vieler Hinsicht von größerer Bedeutung als der Wechsel von RPG III nach RPG IV. Das erste Release von RPG IV war im Grunde nichts weiter als ein RPG III mit neuer Syntax. Die seit dieser Zeit vorgenommenen funktionalen Veränderungen jedoch begründen die wesentlichen Vorteile der RPG Programmierung. Die Mitglieder des RPG Entwicklungsteams haben diesen Trend in V5R2 konsequent fortgesetzt. Neben den unterschiedlichsten Veränderungen bietet V5R2 wichtige Verbesserungen in der Datenstrukturierung und in den I/O Operationscodes. Die V5R2 RPG IV Erweiterungen bauen auf den in V5R1 gelegten Grundlagen auf. Viele der neu eingebrachten Erweiterungen bedingen die Nutzung von V5R1 Funktionen. Neben den unterschiedlichsten Veränderungen bietet V5R2 wichtige Verbesserungen in der Datenstrukturierung und in den I/O Operationscodes. Bevor wir uns aber mit diesen Neuerungen befassen, wollen wir zuerst nochmals einen Blick auf die mit V5R1 eingeführten Erweiterungen werfen.
V5R1 Rückblick
Die deutlichsten und gleichzeitig auch kontroversesten RPG Verbesserungen in V5R1 bezogen sich auf die Freiform-Rechenbestimmungen. Statements zwischen den Anweisungen /Free und /End-Free werden in einem freien Format spezifiziert. Wie in fast allen Programmiersprachen der vergangenen 40 Jahre können Statements auch die Aufgabe haben, die logische Struktur des Programmcodes darzustellen. Die Statements werden, beginnend mit dem Operationscode, gefolgt von Faktor1, Faktor2 und dem Ergebnisfeld codiert.
Die aber wohl entscheidendste Veränderung war die Einführung der Schlüsselworte QUALIFIED und LIKEDS in den Definitions-Spezifikationen. Das Schlüsselwort QUALIFIED brachte das Konzept der qualifizierten Namen in die Sprache ein. Auf Unterfelder in qualifizierten Datenstrukturen muss nicht mit dem Unterfeldnamen allein, sondern mit der Syntax DSName.SubfName verwiesen werden. Optisch wirkt das wie ein lediglich mit einem Präfix versehener Unterfeldname, aber es verbirgt sich sehr viel mehr an Funktionalität dahinter.
Eine Datenstruktur kann unter Verwendung des Schlüsselwortes LIKEDS definiert werden und übernimmt damit alle Unterfelder einer anderen Datenstruktur. Eine LIKEDS Datenstruktur muss – zur Vermeidung von Namenskollisionen – notwendigerweise eine qualifizierte Datenstruktur sein. Dies kann sich für Prozedurprototypen sehr nützlich auswirken, da Prozedurparameter sich mit LIKEDS definieren lassen. Das Programm in Abbildung 1 zeigt ein solches Beispiel. Der Parameter der Prozedur Proc ist mittels LIKEDS wie die Datenstruktur DS definiert. Somit ist innerhalb der Prozedur der Parameter Result als Datenstruktur mit den gleichen Unterfeldern wie die Datenstruktur itemdesc definiert. Dieses Verfahren birgt eine gewisse Eleganz, so dass man davon ausgehen kann, dass es sich als bevorzugte Technik zur Übergabe von Datenstrukturen an Prozeduren durchsetzen wird.
Erweiterungen für Datenstrukturen
Die Erweiterungen für Datenstrukturen in V5R2 bauen auf der Funktionalität von QUALIFIED und LIKEDS auf. Die in V5R1 eingeführten qualifizierten Namen werden als einfach qualifiziert betrachtet. Einfach qualifizierte Namen haben das Format A.B (zwei Namen, getrennt durch einen Punkt, optional gefolgt von einem Feldgruppenindex).
Mit V5R2 werden voll qualifizierte Namen eingeführt, die aus mehr als einer Qualifizierungsebene bestehen können, wobei jedem Namen ein Feldgruppenindex folgen kann. Solch ein voll qualifizierter Name wäre zum Beispiel:
- DS(I).Subf.A(J).X Annähernd 100 Qualifikationsebenen sind hierbei zulässig.
Wie werden solche Datenstrukturen definiert? Zu diesem Zweck wurden keine neuen Schlüsselworte eingeführt. Aber zwei bereits bekannte Schlüsselworte sind nun an anderen Stellen zulässig.
DIM
Das Schlüsselwort DIM ist in einer Datenstrukturdefinition nicht erlaubt. DIM definiert eine Array-Datenstruktur, was so etwas wie eine mehrfach vorkommende Datenstruktur ist, bei der der Index zum Zugriff auf ein Unterfeld der Datenstruktur explizit codiert werden muss. Die Datenstruktur muss qualifiziert definiert werden, da ein voll qualifizierter Name benötigt wird, um auf Unterfelder von Array-Datenstrukturen zu verweisen. DS(77).Subf zum Beispiel verweist auf das Unterfeld Subf im 77sten Element der Array-Datenstruktur DS. Abbildung 2 zeigt die Codierung und Verwendung einer solchen Array-Datenstruktur. Beachtet werden sollte hierbei besonders der voll qualifizierte Name in dem Zuordnungs-Statement. Abweichend von einfach qualifizierten Namen in V5R1 dürfen qualifizierte Namen in V5R2 jetzt mit Leerstellen zwischen den Namen codiert werden.
LIKEDS
Die andere, tiefgreifendere Verbesserung ist, dass das Schlüsselwort LIKEDS jetzt innerhalb von Unterfelddefinitionen erlaubt ist. Anders ausgedrückt, ein Unterfeld einer Datenstruktur kann nun selbst wiederum eine Datenstruktur sein. Auch hier sind voll qualifizierte Namen erforderlich, um auf Unterfelder solcher Datenstrukturen verweisen zu können, da nun mehr als eine Qualifikationsebene vorliegt. In Abbildung 3 ist das Unterfeld Part eine Unterfelddatenstruktur, was bedeutet, dass die Unterfelder der referenzierten Datenstruktur übernommen werden.
Die Schlüsselworte LIKEDS und DIM lassen sich innerhalb der gleichen Datenstruktur kombiniert verwenden, was letztlich komplexe Gebilde wie eine „Feldgruppe von Strukturen“ ermöglicht. In gewisser Weise gleicht dies der Codierung überlappender Unterfelder mit dem Schlüsselwort OVERLAY, aber die geschachtelten Datenstrukturen bieten eine erheblich größere Funktionalität. Sie bilden die Struktur der Daten weitaus deutlicher ab, besonders dann, wenn eine tiefe Staffelung vorliegt. Das Beispiel in Abbildung 4 verfügt über gestaffelte Strukturen mit einer Tiefe von 3 Ebenen. Diese Technik ist eine der Möglichkeiten, mehrdimensionale Feldgruppen in RPG zu codieren. Beachtenswert in diesem Beispiel ist eine weitere Besonderheit in der Codierung. Die Datenstrukturen PartInfo und OderDetail werden nur als LIKEDS Unterfelder in anderen Datenstrukturen verwendet. Da die beiden Datenstrukturen selbst ansonsten nicht verwendet werden, um Daten aufzunehmen (und da somit für diese Datenstrukturen kein Speicher erforderlich ist), werden sie als Based definiert. Die Pointervariable Template wird nicht tatsächlich an irgendeiner anderen Stelle als Pointer verwendet. Sie dokumentiert nur, dass es sich bei der Datenstruktur um eine structure template Definition handelt.
Eine der weiteren V5R2 Verbesserungen bei der Arbeit mit Datenstrukturen bietet das Schlüsselwort EXTNAME, das um einen zusätzlichen Parameter erweitert wurde. Mit diesem Parameter lässt sich steuern, welcher Typ von Unterfeldern in die extern beschriebene Datenstruktur eingebracht werden soll. Wird *Input als letzter Parameter codiert, werden nur die eingabefähigen Felder des Satzes eingeschlossen, *Output umfasst nur die ausgabefähigen Felder, *All alle Felder und *Key nur die Schlüsselfelder des Satzes. *Key erweist sich als besonders nützlich in Verbindung mit der Funktion %KDS (eine nähere Erläuterung folgt noch).
Für die D-Spezifikationen wurde ein neues Schlüsselwort eingeführt. Das Schlüsselwort LIKEREC ist vergleichbar mit dem Schlüsselwort LIKEDS. Anstelle der Definition einer Datenstruktur basierend auf einer anderen Datenstruktur (LIKEDS) definiert LIKEREC nun eine Datenstruktur auf Basis eines Satzformates. Das bedeutet, dass die Unterfelder der Datenstruktur entsprechend den Feldern des angegebenen Satzformates angelegt werden. Ein optional zu verwendender zweiter Parameter legt fest, welche Felder eingeschlossen werden sollen: *Input, *Output, *All oder *Key Felder. Das Schlüsselwort LIKEREC kann überall dort codiert werden, wo auch die Verwendung von LIKEDS erlaubt ist, einschließlich in Unterfeldern einer Datenstruktur.
Schließlich wurde das Schlüsselwort DTAARA um die Fähigkeit erweitert, den Namen der eigentlichen Data Area als Variable zu spezifizieren. Wird beispielsweise folgende Codierung gewählt: DTAARA(*Var:Name), enthält die Variable Name später den tatsächlichen Namen der Data Area zum Ausführungszeitpunkt.
Teil 2 befasst sich mit dem Thema „Verbesserte I/O Operationen“ im Hinblick auf spezielle Neuerungen.
Ähnliche Artikel:
