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.
Teil 1 befasste sich mit einem V5R1 Rückblick, ferner der Erweiterung der Datenstrukturen. Teil 1 ist in der Dezemberausgabe 2003 und im Internet veröffentlicht.
Verbesserte I/O Operationen
Seit Einführung der Definitions-Spezifikationen wurde immer wieder der Wunsch geäußert, KLists in den D-Spezifikationen verwenden zu können. Diese Forderung wurde nach Einführung von V5R1 noch vehementer vorgetragen, da KLists innerhalb der Freiform-Rechenbestimmungen nicht erlaubt waren. Um aufrichtig zu sein, es bestanden eigentlich immer schon Probleme, eine gute Syntax für die Definition einer KList in den D-Spezifikationen zu finden. So werden mit V5R2 nun einige Alternativen angeboten. Diese speziellen Neuerungen sind fast alle auf Verwendung in den Freiform-Rechenbestimmungen beschränkt, da die in den herkömmlichen Rechenbestimmungen zur Verfügung stehenden 14 Zeichen in Faktor 1 und im Ergebnisfeld einfach nicht ausreichen.
Schlüssel-Liste für indexierte I/Os
Die einzelnen Suchargumente eines zusammengesetzten Schlüssels können nun direkt in der I/O Operation ohne vorherige KList Definition angegeben werden, wie das nachfolgende Beispiel zeigt:
/Free CHAIN (Order(17).Id: CustNo)OrderRec; /End-Free
In diesem Beispiel sind die Suchargumente, aus denen sich der Schlüssel zusammensetzt, direkt in dem Statement angegeben. Die Suchargumente können beliebige Ausdrücke enthalten. Darüber hinaus muss, anders als bei KLists, jedes Suchargument dem zugehörigen Schlüsseltyp entsprechen. Stimmen Länge oder Format nicht überein, wird für das Suchargument eine Anpassung vorgenommen, die ähnlich der Anpassung des Quellenarguments an die Ergebnisfeldvariable in einem EVAL Statement vorgenommen wird. Tatsächlich sind bei der Angabe einer Liste von Schlüsseln in indexierten I/O Operationen nun die gleichen Operationscode-Erweiterungen zulässig, die auch für das EVAL Statement gelten. Dies gilt nicht nur für die Operation CHAIN, sondern auch für alle anderen schlüsselbasierten I/O Operationen: SETLL, SETGT, READE, READPE und DELETE. Auch null-capable keys sind mit dieser Syntax unterstützt. Soll nach einem null key in einer Datei gesucht werden, wird als Suchargument ein null-capable Feld codiert und der null flag für das Feld gesetzt. Um dies zu ermöglichen, ist das Attribut null-capable nun auch für null-capable Felder in extern beschriebenen Datenstrukturen und LIKEREC Datenstrukturen zulässig.
Key Datenstruktur
Obwohl eigentlich davon ausgegangen werden kann, dass die „list-of-keys“ Syntax künftig die bevorzugte Art und Weise sein wird, um Suchargumente zu codieren, bieten wir trotzdem eine neue Technik an. Diese kommt in etwa einer Klist gleich, kann aber in den D-Spezifikationen definiert werden. Spezifiziert man %KDS(DSName) als Suchargument, werden die Elemente des zusammengesetzten Schlüssels den Unterfeldern der angegebenen Datenstruktur entnommen. Wird nur ein Teilschlüssel benötigt, legt ein optionaler zweiter Parameter fest, wie viele Unterfelder benutzt werden sollen. Beispiel:
D Keys DS QUALIFIED D Id 5A D PartNo 5U 0 D Color 10I 0 /Free CHAIN %KDS(Keys:2) OrderRec; /End-Free
In diesem Beispiel bilden die Unterfelder Keys.Id und Keys.Part den zusammengesetzten Schlüssel. Hier gelten die gleichen Regeln, die auch für Schlüssellisten Anwendung finden. Decken sich Format oder Größe der Suchargumente nicht mit den entsprechenden Schlüsselfeldern, wird eine entsprechende Anpassung vorgenommen. Dies funktioniert auch hervorragend in Verbindung mit EXTNAME(…:KEY), einer Funktion, die man als extern beschriebene Schlüsselliste beschreiben könnte.
- 7 Euro/Monat NEWSabo digital - sofort zugreifen.
- 13,5 Euro/Monat NEWSabo plus inklusive 5x Login & Print-Ausgabe - sofort zugreifen.
Ähnliche Artikel:
